Interstage ASM Overview - Fujitsusoftware.fujitsu.com/jp/manual/manualfiles/M080264/B1WD2471/01ENZ... · uninstallation of CentraSite. • Interstage ADM Lifecycle Management User

Interstage Application and Service Management V10.0

Overview

B1WD-2471-01ENZ0(00)October 2008

Trademarks Interstage and Enabler are trademarks of Fujitsu Limited in Japan and/or other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

UNIX is a registered trademark of the Open Group in the United States and in other countries.

Linux is a registered trademark of Linus Torvalds.

Other company names and product names are trademarks or registered trademarks of their respective owners.

Copyright © FUJITSU LIMITED 2008

All rights reserved, including those of translation into other languages. No part of this manual may be reproduced in any form whatsoever without the written permission of Fujitsu Limited.

[High Risk Activity]

The Customer acknowledges and agrees that the Product is designed, developed and manufactured as contemplated for general use, including without limitation, general office use, personal use, household use, and ordinary industrial use, but is not designed, developed and manufactured as contemplated for use accompanying fatal risks or dangers that, unless extremely high safety is secured, could lead directly to death, personal injury, severe physical damage or other loss (hereinafter "High Safety Required Use"), including without limitation, nuclear reaction control in nuclear facility, aircraft flight control, air traffic control, mass transport control, medical life support system, missile launch control in weapon system. The Customer shall not use the Product without securing the sufficient safety required for the High Safety Required Use. In addition, Fujitsu (or other affiliate's name) shall not be liable against the Customer and/or any third party for any claims or damages arising in connection with the High Safety Required Use of the Product.

Interstage ASM Overview 2

Contents

1 What is Interstage ASM?.................................................. 9

1.1 Architecture and Interfaces .................................................................13

1.2 Usage and Installation Scenarios........................................................15

2 Lifecycle Management (LCM)........................................... 17

2.1 Applications and Services ...................................................................17

2.2 Navigation and Information Retrieval .................................................18

2.3 Requirements Management (RQM) .....................................................19

2.4 Change Management (CHM) ................................................................21

2.5 Release Management (RLM) ................................................................23

2.6 Process Control ....................................................................................26

2.7 Security and Access Control ...............................................................29

2.8 Customization and Extension..............................................................30

3 Software Configuration Management (SCM) .................. 31

3.1 Projects in SCM.....................................................................................31

3.2 Project Definition ..................................................................................32

3.3 Resource and Version Management...................................................33

3.4 Configuration Management .................................................................37

3.5 Products.................................................................................................40


3.7 Change Control .....................................................................................42

3.8 Reporting ...............................................................................................43

3.9 Integration with LCM ............................................................................43

3.10 Integration in Development Environments ........................................44


3.11 Setup and Customization.....................................................................45

4 Document Management (DMS) ........................................ 47

4.1 Document Libraries ..............................................................................47

4.2 Document Editing and Versioning ......................................................49

4.3 Read-only Access to Documents........................................................51

4.4 Document Retrieval ..............................................................................51

4.5 Reporting ...............................................................................................52

4.6 DMS and SCM........................................................................................52


4.8 Change Control .....................................................................................53

4.9 Setup and Customization.....................................................................54

5 Source Code Analysis (SCA) ........................................... 55

5.1 Cubes .....................................................................................................55

5.2 Source Code Scanning.........................................................................56

5.3 Analysis .................................................................................................57

5.4 Analysis Results ...................................................................................61


6 Quality Assessment (QAM).............................................. 62

6.1 Indicators, Entities and Measurements ..............................................62

6.2 Assessments .........................................................................................63

6.3 Basic Analysis of Indicator Values .....................................................64

6.4 Problem Analysis ..................................................................................65

6.5 Quality Evaluation by Values and Thresholds...................................65

6.6 Trend Analysis and History .................................................................66

6.7 Quality Comparisons............................................................................66


6.8 Quality Reports .....................................................................................66


7 SOA Asset Management (CentraSite) ............................. 67

7.1 SOA Assets and Metadata ...................................................................67

7.2 Metadata Definition...............................................................................69

7.3 Navigation and Information Retrieval .................................................70

7.4 Impact Analysis.....................................................................................70

7.5 Classification.........................................................................................71

7.6 Packaging ..............................................................................................71

7.7 Change Notification ..............................................................................71

7.8 Registry Federations ............................................................................72

7.9 System Integration................................................................................72


8 Common Components ..................................................... 73

8.1 Control Center (COC) ...........................................................................73

8.2 Repositories ..........................................................................................76

9 Common Features ............................................................ 78

9.1 Audit Logging........................................................................................78

9.2 Reporting ...............................................................................................78

9.3 Single Sign-On ......................................................................................78


9.5 Customization and Extension..............................................................80

Glossary ............................................................................................. 81



About this Manual This manual is an introduction to the Fujitsu Interstage Application and Service Management suite – hereafter referred to as Interstage ASM.

The manual is structured as follows:

Title Description

Chapter 1 What is Interstage ASM? Provides an introduction to Interstage ASM, its main components and architecture.

Chapter 2

Lifecycle Management (LCM)

Describes the features and basic concepts of the lifecycle management components.

Chapter 3

Software Configuration Management (SCM)

Describes the features and basic concepts of SCM.

Chapter 4

Document Management (DMS)

Describes the features and basic concepts of DMS.

Chapter 5

Source Code Analysis (SCA)

Describes the features and basic concepts of SCA.

Chapter 6 Quality Assessment (QAM) Describes the features and basic concepts of QAM.

Chapter 7

SOA Asset Management (CentraSite)

Describes the features and basic concepts of CentraSite.

Chapter 8 Common Components Provides an overview of the common components of Interstage ASM.

Chapter 9 Common Features Provides an overview of the features that are common to all Interstage ASM components.

Readers of this Manual This manual is written for everybody interested in Interstage ASM. It offers a basic introduction for readers who do not know Interstage ASM and for those who have already started using the product. The manual does not require any special knowledge.

Abbreviations This manual uses the following abbreviations for Interstage products and components:

Interstage ASM Interstage Application and Service Management suite

Interstage BPM Interstage Business Process Manager

Interstage ADM Interstage Application Development Cycle Manager product of Interstage ASM

Interstage SQA Interstage Software Quality Analyzer product of Interstage ASM

CHM Change Management component of Interstage ASM

COC Control Center component of Interstage ASM

DMS Document Management component of Interstage ASM

LCM Lifecycle management components (CHM, RLM, RQM) of Interstage ASM

QAM Quality Assessment component of Interstage ASM

RLM Release Management component of Interstage ASM

RQM Requirements Management component of Interstage ASM

SCA Source Code Analysis component of Interstage ASM

SCM Software Configuration Management component of Interstage ASM

Related Documentation Apart from this manual, the following documentation on Interstage ASM is available:

• Interstage ADM Installation Instructions: A PDF manual describing the installation and uninstallation of Interstage ADM.

• Interstage SQA Installation Instructions: A PDF manual describing the installation and uninstallation of Interstage SQA.

• CentraSite Installation Instructions: A PDF manual describing the installation and uninstallation of CentraSite.

• Interstage ADM Lifecycle Management User Guide: An online manual describing how to work with the lifecycle management (LCM) components of Interstage ASM from the client interface.

• Interstage ADM Software Configuration Management User Guide: An online manual describing how to work with the Software Configuration Management (SCM) component of Interstage ASM from the client interface.

• Interstage ADM Document Management User Guide: An online manual describing how to work with the Document Management (DMS) component of Interstage ASM from the client interface.


• Interstage SQA Source Code Analysis User Guide: An online manual describing how to work with the Source Code Analysis (SCA) component of Interstage ASM from the client interface.

• Interstage SQA Quality Assessment User Guide: An online manual describing how to work with the Quality Assessment (QAM) component of Interstage ASM from the client interface.

• CentraSite User Guide: An online manual describing how to work with the SOA Asset Management (CentraSite) component of Interstage ASM from the client interface.

• Interstage ASM Control Center User Guide: An online manual describing how to work with the Control Center (COC) component of Interstage ASM from the client interface.

• Interstage ASM Administration Guide: A PDF manual describing the administration and configuration of Interstage ASM.

• Interstage ASM Customization Guide: A PDF manual describing how to extend, localize and customize Interstage ASM.

• Interstage ADM Software Configuration Management Migration Guide: A PDF manual describing how to migrate projects from other source code management systems to the SCM component of Interstage ASM.

• Interstage ADM Command Line Interface: A PDF manual describing the Interstage ADM command line interface.

Additionally, the following documents of Fujitsu Enabler are of relevance:

• Enabler Administration: A PDF manual describing the administration of Enabler servers and repositories.

• Enabler WebDAV Interface: A PDF manual describing how to set up the working environment for accessing files managed in a repository using WebDAV clients.


1 What is Interstage ASM? Interstage Application and Service Management (Interstage ASM) is a suite of products, components and tools that support you in managing the services, software products and applications of your company. Interstage ASM covers the entire lifecycle of services and applications, ranging from requirements and change management through software development, maintenance, and quality assessment to release and asset management.

With its features, Interstage ASM helps you control your development processes, improve the quality of your software, reduce development and maintenance costs, comply with regulatory acts and govern your company's services and applications. Repository-based technology and a wide range of interfaces make Interstage ASM very scalable, reliable, flexible and customizable.

Interstage ASM consists of the following products and components. The white boxes show the products, the dark grey boxes the components they consist of:

CentraSiteCentraSite

Interstage SQAInterstage SQA

Software and DocumentationManagement

QualityAssessment

(QAM)

QualityAssessment

(QAM)

Source CodeAnalysis

(SCA)

Source CodeAnalysis

(SCA)

SOA AssetManagement(CentraSite)

SOA AssetManagement(CentraSite)

Common Components (Enabler Repository, Control Center (COC))Common Components (Enabler Repository, Control Center (COC))

DocumentManagement

(DMS)

DocumentManagement

(DMS)

SoftwareConfigurationManagement

(SCM)

SoftwareConfigurationManagement

(SCM)

Lifecycle Management Analysis and Assessment

Interstage ADM

RequirementsManagement

(RQM)


(RQM)

ReleaseManagement

(RLM)

ReleaseManagement

(RLM)

ChangeManagement

(CHM)

ChangeManagement

(CHM)


(RQM)


(RQM)

ReleaseManagement

(RLM)

ReleaseManagement

(RLM)

ChangeManagement

(CHM)

ChangeManagement

(CHM)


Lifecycle Management The lifecycle management (LCM) components of Interstage ASM enable you to initiate and control all the activities involved in the lifecycle of services and applications:

• Requirements Management (RQM) supports you in collecting and sorting out all the requirements related to your services and applications. With RQM, you can manage any type of requirement, ranging from requests for new services to enhancement proposals for existing applications. You can describe requirements at different levels of detail, change, prioritize and categorize them, and maintain dependencies between them.

• Change Management (CHM) supports you in controlling all the changes made to your services and applications. You can define any type of change request and maintain all the information related to it, for example, the results of an impact analysis or design and review documents. The change requests can be linked to the items they affect, for example, source code managed with the Software Configuration Management (SCM) component of Interstage ASM. You can prioritize and categorize change requests and maintain dependencies between them.

• Release Management (RLM) supports you in creating, planning and monitoring the various versions and releases of your services and applications. For each service or application, you can define any number of releases, which in turn can be divided into several iterations. Each release can be linked to the components it consists of, for example, source code configurations managed with the SCM component of Interstage ASM. You can categorize and prioritize releases, maintain descriptive and related information for each of them, and create dependencies between them.

The lifecycle management components are tightly integrated with each other: Requirements and change requests can be defined for services and applications as a whole and be assigned to the releases where they are implemented. Requirements can result in one or more change requests, which are implemented in different releases of one or more services or applications.

Any activities carried out in RQM, CHM and RLM are controlled by processes. These may be simple workflow or complex business processes defined with Interstage Business Process Manager (Interstage BPM). Process control ensures that all activities are conducted properly, in time and by the appropriate persons.

With their support of different processes and additional customizing features (user-defined attributes, extensions), the lifecycle management components can be tailored to any customer environment. In addition, you can integrate them with external systems like customer relationship management and bug tracking systems on the front end as well as build, test and deployment systems on the back end. This release of Interstage ASM comes with an integration of Bugzilla, one of the most popular bug tracking systems.

The lifecycle management components are bundled with SCM and DMS in the Interstage Application Development Cycle Manager (Interstage ADM) product. The Enterprise Edition provides for integration with Interstage BPM, while the Standard Edition does not.

For details and concepts of the lifecycle management components, see Chapter 2.


Software and Documentation Management The software and documentation management components of Interstage ASM provide team support, configuration management and version control for your service and application development projects:

• Software Configuration Management (SCM) supports you in controlling the source code and other resources related to your services and applications. SCM enables the management of software development projects that range from simple applications to complex, distributed systems. Multi-user access and parallel development are supported by check-in/out and synchronization features and sophisticated security mechanisms. A project's resources are managed in configurations, which can be grouped in releases and products. The resources, configurations and releases can be controlled and integrated with the CHM and RLM lifecycle management components of Interstage ASM. While SCM is optimized for usage in the Eclipse IDE, it can easily be integrated into other development environments. For details and concepts of SCM, see Chapter 3.

• Document Management (DMS) supports you in writing and maintaining the documentation related to your services and applications. While any documents can be managed with DMS, the focus is on documents that are created in the software development lifecycle, ranging from product definitions through specifications and review reports to user documentation and marketing material. To this end, DMS provides document-specific views for software development projects managed with SCM. The projects and documents can be accessed and handled in DMS without any adaptation. For details and concepts of DMS, see Chapter 4.

DMS is based on SCM and bundled with it as well as with the lifecycle management components in the Interstage Application Development Cycle Manager (Interstage ADM) product.

Analysis and Assessment The analysis and assessment components of Interstage ASM support you in the maintenance of your services and applications and provide means to monitor and increase their quality:

• Source Code Analysis (SCA) supports you in maintaining the source code of your software systems, including mainframe and legacy software. Source code of various programming languages can be scanned and then be analyzed, for example, in order to understand the code's logical structure and determine the impact of changes. SCA provides interfaces for navigating the code's structure and dependencies, and offers metrics and statistic values. The SCA interfaces and high-performance scanners allow you to analyze even large amounts of source code quickly and efficiently. Analysis results can be stored and managed using DMS. For details and concepts of SCA, see Chapter 5.


• Quality Assessment (QAM) supports you in analyzing and monitoring the quality of source code. For any source code scanned with SCA, you can retrieve metrics and derive or calculate appropriate quality indicators. You can use these indicators for a detailed quality assessment and problem analysis of the source code as well as for comparisons and trend analyses over time. The assessment results can be visualized as text and graphics and output to appropriate reports. For details and concepts of QAM, see Chapter 6.

• SOA Asset Management (CentraSite) supports you in managing and governing your SOA environment and enables you to achieve control and transparency across all IT resources related to it. CentraSite stores and manages metadata for your SOA assets (e.g. Web services). Sophisticated browsing and information retrieval capabilities allow you to easily understand which services are available across departments, who uses them and what business values they offer. They help you analyze the impact of changes before they are applied to the SOA resources. For details and concepts of CentraSite, see Chapter 7.

CentraSite is available as an individual product. SCA and QAM are bundled in the Interstage Software Quality Analyzer (Interstage SQA) product.

Common Components The common components of Interstage ASM provide basic and integrative features for all the other components:

• Control Center (COC) provides central access and common features for the Interstage ASM components. References and access data for any number of Interstage ASM systems as well as other systems (e.g. file systems, source code control systems) can be stored and maintained in a central repository, enabling direct access to these systems. You can structure the data, describe them by properties and maintain your personal favorite lists. In COC, you define the categories which are to be used in other Interstage ASM components. Furthermore, COC enables full-text search across different SCM projects and DMS libraries.

• Enabler is the repository management system at the heart of Interstage ASM. It provides the foundation for the integrated storage and management of data, flexible and high-performance access to this data by users and applications, and team coordination. All Interstage ASM components store their data in one or more repositories.

For details and concepts of the common components of Interstage ASM, see Chapter 8.

Common Features The Interstage ASM components have several features in common. These include security and access control concepts, single sign-on, logging and reporting features, customization and extension. For details, see Chapter 9.



1.1 Architecture and Interfaces The following illustration provides an overview of the Interstage ASM architecture and interfaces:

ClientInterfaceClient

Interface

Functionality and Java API

RQMRQM

SCAServerSCA

Server

CHMCHM RLMRLM SCMSCM DMSDMS SCASCA QAMQAM COCCOCCentraSite

CentraSite

SearchServer

SearchServer

CommandLine

Interface

CommandLine

InterfaceWeb

InterfaceWeb

InterfaceWebDAVInterfaceWebDAVInterface

UDDIInterface

UDDIInterface

The functionality of Interstage ASM is implemented in Java and exposed at the Java API.

The Interstage ASM components store their data in Enabler repositories, which are located on one or more Enabler servers.

For scanning source code and obtaining the required analysis data, SCA uses a high-performance code analyzer based on OLAP (Online Analytical Processing) technology. This is referred to as the SCA server.

SCM and DMS provide full text search which is based on search indices. These indices are created and maintained on one or more search servers.

The users of Interstage ASM can work with the following interfaces:

• Client interface The client interface is a graphical user interface that offers the complete Interstage ASM functionality. The client interface is based on Eclipse technology and implemented as Eclipse plug-ins. As such, it can be installed and operated in the following ways: Stand-alone variant: The stand-alone variant is based on the Eclipse RCP (rich client platform) technology. It includes the Eclipse plug-ins of the Interstage ASM components you have installed as well as all features of the Eclipse Workbench required to operate them. This means there is no need to separately install Eclipse. The stand-alone variant of the client interface is the main interface for all Interstage ASM users and components. Existing Eclipse environment: You can install and use the plug-ins of the Interstage ASM components within an existing Eclipse environment. This is particularly suitable for SCM: If you use Eclipse for software development, the SCM functionality can be integrated seamlessly with it. In a similar way, you can add the analysis features of SCA or CentraSite to your development environment.

• Command line interface The command line interface consists of batch files for Microsoft Windows and shell scripts for UNIX/Linux. It offers the complete SCM functionality as well as basic functionality of other components. You can use the command line interface for batch processing (e.g. create builds in SCM or perform regular source code scans in SCA) as well as for integrating Interstage ASM functionality into third-party tools and solutions without the need for programming.

• Web interface SCM and DMS offer a Web interface in addition to the client interface. The Web interface is servlet-based and allows for performing specific SCM and DMS activities from a Web browser.

• WebDAV interface The WebDAV interface is made available by the Enabler WebDAV services and used in SCM and CentraSite. The Enabler WebDAV services provide folder/file views of the data stored in a repository. Via WebDAV shares, the folders and files can be accessed from any WebDAV-compatible client (e.g. Microsoft Internet Explorer or Microsoft Office) in any Internet location. In SCM, you can define a WebDAV share for each protected configuration and access the folders and files in read-only mode. CentraSite uses WebDAV shares to provide its repository functionality.

• UDDI interface In addition to its JAXR-compliant Java API, CentraSite offers a UDDI (Universal Description, Discovery and Integration) interface, which allows you to integrate it in your SOA environment and use it like any standard UDDI registry. The UDDI interface can be deployed as a Web application on any Web/application server of your choice.


1.2 Usage and Installation Scenarios Interstage ASM is implemented as a three-tier application involving clients, Web/application servers and the Interstage ASM server components. SCM and DMS support a pure client/server scenario in addition.

The following illustration provides an overview of the installation and usage scenarios:

Clientinterface

Command line interface

Interstage ASM functionality and API

Interstage ASM client

Clientinterface

Command line interface


Interstage ASM client

Enabler server

Repository

LAN TCP/IP

SCA server

Web client


Web/application server

Interstage ASM Web applications(remote interface)

HTTP / HTTPS

HTTP / HTTPS Firewall

Search server

TCP/IP

WebDAVinterface

WebDAVclient

TCP/IPUDDI

interface

TCP/IP TCP/IP

TCP/IP


Users can work with the Interstage ASM components and interfaces in the following way:

• Client and command line interfaces: Users work from Interstage ASM clients, where the client and/or command line interface including all the Interstage ASM client functionality are installed. The clients access the repositories and Interstage ASM servers by HTTP or HTTPS via a Web/application server where the Interstage ASM Web applications are installed. The Web applications include the Interstage ASM API and functionality. They forward requests and data to the repositories and server components and return the responses to the clients. The Web applications are also referred to as the remote interface of Interstage ASM. SCM and DMS users can also work directly with repositories from their clients by TCP/IP without using the remote interface. The same is true for access to SCA servers when carrying out analyses. CentraSite users access repositories from the client interface both directly by TCP/IP and via the WebDAV interface, which runs on a Web/application server. On the same or a different Web/application server, the CentraSite UDDI interface may be deployed.

• Web interface of SCM and DMS: Users can work from any Web browser. They connect to the repositories via HTTP or HTTPS and a Web/application server where the Interstage ASM Web applications are installed.

• WebDAV interface: Users can access CentraSite repositories and protected configurations of SCM from any WebDAV client via the WebDAV interface.


2 Lifecycle Management (LCM) LCM enables you to initiate and control all the activities involved in the lifecycle of services and applications. It includes the following components:

• Requirements Management (RQM): Supports you in collecting and sorting out all the requirements related to your services and applications.

• Change Management (CHM): Supports you in controlling all the changes made to your services and applications.

• Release Management (RLM): Supports you in creating, planning and monitoring the various versions and releases of your services and applications.

The LCM components are tightly integrated with each other. Any activities carried out in them are controlled by processes. This ensures that all activities are conducted properly, in time and by the appropriate persons.

The data created and managed with LCM is stored in a repository. Users can access the data using the client interface. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of LCM and introduce basic concepts.

2.1 Applications and Services With LCM, you control the activities involved in the lifecycle of applications and services. An application is, for example, a software product suite like Interstage ASM or a tool developed by your company. A service could be an infrastructure service or a Web service.

LCM allows you to represent and describe any type of application and service. For each application and service, you can create and maintain any number of releases using RLM. With RQM and CHM, you can define requirements and change requests for applications and services and then assign them to individual releases where they are implemented.

Any application, service, release, requirement or change request is represented by a corresponding item in LCM. It is described by properties and associations with other items. Additionally, you can assign categories and add any number of descriptive files as attachments to each item.

The following illustration shows sample applications and services with releases, requirements and change requests as they are displayed at the client interface.


All items and all data related to them are stored in a repository. You can use the same repository for managing all of your services and applications. Alternatively, you can distribute the data to multiple repositories, the only condition being that all information related to a specific service or application is kept in one repository.

2.2 Navigation and Information Retrieval LCM provides you with various means and ways to obtain information on your services and applications and the related releases, requirements and change requests:

• Navigation: The client interface displays all the items and their associations with other items in a tree view which you can navigate like any standard folder structure. For each item you select in the structure, comprehensive details are displayed immediately. These include information on the selected item as well as on other items related to it.

• Filters: Sophisticated filter mechanisms allow you to reduce the displayed items and details to exactly the ones you are interested in.

• Reports: Reports at different levels and for different items allow you to obtain any information you need. The reports can be customized as required.


2.3 Requirements Management (RQM) RQM supports you in collecting and sorting out all the requirements related to your services and applications.

Requirements A requirement is a documented need of what a particular service or application should be or do in order for it to be of value or use to a stakeholder.

With RQM, you can define and manage any type of requirement, such as:

• User or customer requirements, whose fulfillment would improve the user's or customer's business or satisfaction. For example, this could be requests to provide new features or services or to make an application easier to use or less error prone.

• Business requirements, whose fulfillment would improve your own business. For example, this could be requests to increase revenue, improve the infrastructure or develop a software product for a specific market.

• Functional and non-functional requirements, whose fulfillment would lift restrictions or change the behavior of an application or service. These include, for example, the need to migrate a software product to a new platform or to meet specific quality criteria.

Defining Requirements You define requirements for specific applications or services. When a requirement is to be fulfilled, you typically assign it to the relevant release or releases of the application or service.

The name of a requirement is generated automatically by RQM using a prefix defined at the application or service and a consecutive number.

Describing Requirements You can describe a requirement at different levels of detail. You can:

• Summarize the requirement in a short description.

• Provide important information related to the requirement in a long description.

• Specify the stakeholders who submitted the requirement.

• Describe the use cases of interest for the requirement.

• Attach any files which provide further details, for example, requirement documents supplied by customers or use case analyses made with third-party tools.

Using the customization facilities of LCM, you can define additional descriptive properties for requirements as needed by your organization.


Grouping and Organizing Requirements RQM provides you with various means to sort, group and organize the requirements related to your services and applications:

• Assignment to applications or services: An initial grouping and sorting is achieved by the fact that a requirement is always assigned to a specific service or application.

• Priority and Rank: To each requirement, you can assign a priority and a rank, which indicate its importance compared to others.

• Risk and Benefit: You can specify how risky and useful it is to implement each requirement.

• Categories: You can group and sort requirements by assigning appropriate categories to them. The categories you can specify are defined in COC.

Scheduling Requirements Requirements are typically scheduled by assigning them to one or more releases of the services or applications where they are to be fulfilled. Independent of release assignments, you can specify a date by which the fulfillment of the requirement is requested.

Planning is usually not performed on requirements as such, but by the releases to which the requirements are assigned and the change requests resulting from them. However, using the customization facilities of LCM, you can define any properties for requirements which you can use for scheduling and planning.

Managing Requirement Dependencies You can create and maintain dependencies between any of the requirements related to a service or application. A dependency means that a specific (requisite) requirement needs to be fulfilled before another (dependent) requirement can be fulfilled.

Reviewing and Changing Requirements As a requirement moves through its lifecycle, it can undergo changes and reviews. Any of the properties of a requirement can be updated, attachments can be added and removed. Reviewers of a requirement can supply comments, for example, to state the reason why they accept or reject the requirement.

Requirements and Change Requests A requirement typically results in one or more change requests which are managed in CHM. You can create new change requests or assign existing ones to each requirement. When you schedule a requirement by assigning it to a release, a corresponding change request is automatically created.

Reports allow you to obtain comprehensive information on the change requests associated with a requirement, their status and the activities being performed on them.


2.4 Change Management (CHM) Change Management (CHM) supports you in controlling all the changes made to your services and applications.

Change Requests With CHM, you describe and control changes to your applications or services by change requests. A change request is a call for a specific adjustment of a service or application, for example, a request to fix a bug in a component of a software product or to modify a specific behavior of a service.

Change requests typically result from requirements or incidents reported in a bug tracking or customer relationship management system. For example, a requirement to migrate a software product to a new platform may result in several change requests for each of the affected components or even for each piece of code.

Defining Change Requests Change requests can be created in the following ways:

• When you schedule a requirement by assigning it to a release in RQM, a change request is automatically created and assigned to the same release for implementation.

• CHM can be integrated with different incident management and bug tracking systems. Reporting an incident or bug in such a system can result in the automatic definition of a corresponding change request in CHM. In the current release, CHM comes with an integration of the Bugzilla bug tracking system, which you can configure and use in this way: When a bug is reported in Bugzilla, a corresponding change request is automatically created and linked to the bug in Bugzilla. Bugzilla is the master, and information about bugs (e.g. state, priority, responsible user) is continuously synchronized in CHM.

• You can explicitly define any number of change requests for your applications and services, associate them with requirements, and assign them to the releases where they are implemented.

The names of change requests are generated automatically by CHM using a prefix defined at the application or service and a consecutive number.

Describing and Organizing Change Requests You can describe a change request at different levels of detail. In a short description, you can summarize the purpose of the change request; in a long description, you can provide all the important information related to the change request.

To each change request, you can attach any files which provide further details, for example, bug reports, incident analyses and histories, or code review reports.


Change requests are grouped initially by the fact that they are always created for a specific application or service. In addition, you can group, sort and organize them by assigning them different types (e.g. bug fix, enhancement request), priorities, and categories defined in COC.

Using the customization facilities of LCM, you can define additional properties for change requests which you can use to further describe and organize them.

Scheduling and Implementing Change Requests A change request is typically fulfilled in a specific release of a service or application. Therefore, you schedule a change request by assigning it to the appropriate release. A change request can be scheduled for exactly one release. If similar changes are to be carried out in different releases, you can copy the corresponding change request to each of them.

For each change request, you can specify the planned effort in hours, days, weeks, months or years, as well as a deadline date.

In order to fulfill a change request, it is usually necessary to create, modify or delete one or more specific items, for example, specific source code files of an application, or configuration items of a service. These items are typically maintained in a source code or configuration management system such as SCM. They reside in one of the configurations defined for the release to which you assigned the change request. For details on a release's configurations, see Section 2.5.

When you create, modify or delete items, you assign them to the appropriate change request. For example, when you commit changes to source code files in SCM, you can or even must specify the appropriate change request.

In CHM, the items affected by a change request are represented by corresponding links, which are referred to as changed items. Within Interstage ASM, these links typically point to items managed in SCM. The links are created automatically when a corresponding SCM action is performed. From the links, you can at any time obtain an overview of the changes being performed for each change request.

Managing Change Request Dependencies You can create and maintain dependencies between any of the change requests related to a service or application. A dependency means that a specific (requisite) change request needs to be implemented before another (dependent) change request can be fulfilled.


2.5 Release Management (RLM) RLM supports you in creating, planning and monitoring the various versions and releases of your services and applications.

Releases For each application and service managed in LCM, you can create and maintain any number of releases. A release is an initial or upgraded version of an application or service including all artifacts which make it complete and functional.

With RLM, you can define releases for any purpose and scope. For example, a release of a software product may be the first edition of this product, a new major version, a new minor version, a service pack or a fix. A release of a service may be created for providing a new feature to its users or for making the service itself available to an additional user group.

Defining Releases Definition of a release for an application or service includes the following:

• New release or successor release: In RLM, you can define brand new releases as well as successors of existing releases. A release without a predecessor is usually the first release of a service or application. Later releases are typically defined as successors of a previous release.

• Release name: You can choose any names for your releases. Typically, the names follow the rules of your company and include version numbers and identifiers, such as 'V3.0 SP2' or '7.0.1.8'.

• Description: You can describe a release at different levels of details. You can provide a short description stating the release's purpose and a long description. Furthermore, you can add any files as attachments to the release, for example, the release plan or design and specification documents.

• Requirements and Change Requests: The work which is to be carried out for a release is to a great extent defined by requirements and change requests which you manage in RQM and CHM. To each release, you therefore assign the requirements and change requests which you intend to fulfill. For more details on requirements and change requests, see the Sections 2.3 and 2.4.

• Artifacts: A release consists of the artifacts that make it complete or functional. These artifacts can be of any nature. For example, a release of a software product may comprise code developed in different projects as well as documentation. The artifacts are typically developed and maintained in source code or configuration management systems such as SCM.


In RLM, you define a release’s contents by creating links to the relevant structures in such systems. These links are referred to as configurations. Within Interstage ASM, a configuration in RLM typically links to a configuration of SCM. RLM and SCM ensure that these links are always kept up-to-date, for example, when SCM configurations are renamed or SCM releases are split. However, an RLM configuration can also be a link to any external system or site which can be addressed by a URL.

• Custom properties: Using the customization facilities of LCM, you can define additional descriptive properties for releases as needed by your organization.

The client interface at any time provides an overview of your releases and their definitions. Furthermore, various reports are available which allow you to obtain comprehensive information on the releases, the assigned change requests, requirements and configurations, their status and the activities being performed on them.

Scheduling and Planning Releases Release scheduling and planning data can be maintained in the following ways:

• Release schedules and plans in any format and created with any tool can be added as attachments to each release.

• For each release, you can specify the planned rollout date. Using the customization facilities of LCM, you can define additional release properties for scheduling and planning purposes.

Implementing Releases Releases are implemented by carrying out the required changes in the release’s configurations. These changes are governed by the change requests assigned to the release.

Building, Verifying and Deploying Releases RLM is focused on the definition, planning and progress monitoring of releases. Tools for building, verifying or deploying releases can be integrated with RLM by using appropriate processes and by means of the customization and extension facilities of LCM.


Using Release Iterations For purposes like agile development, you can divide a release into several iterations. For example, you could define iterations for delivering different builds of an application to a quality assurance department or for shipping alpha or beta versions to one or more customers.

Each iteration fulfills a specific subset of the requirements and change requests scheduled for the release. An iteration can be completed and delivered independent of other iterations.

Iterations share their assigned requirements and change requests with their release. This means that all the requirements and change requests fulfilled in an iteration are also considered fulfilled in the release.

Iterations are described by the same properties as releases and assigned processes of their own.

Linking Related Information to a Release The implementation of a release may be influenced by activities or information in other applications, services or external systems. For example, a release of an application may depend on specific releases of other applications.

On the other hand, a release may itself have impacts on data and activities of other applications, services or external systems. For example, a Web service whose metadata are maintained in CentraSite may depend on the development of a specific release of another service.

RLM allows you to express such dependencies of a release by creating links to any number of items and data of other systems. Such links may relate to:

• Applications and services managed with LCM

• Projects, releases and configurations of SCM

• Document libraries managed with DMS

• Cube items of SCA

• Quality assessments of QAM

• Registry objects managed with CentraSite

• Any external systems and files that are addressable by a URL, for example, folders in a file system, Web pages, WebDAV documents and collections, or incidents in Bugzilla.

From links relating to LCM, SCM, DMS, SCA, QAM or CentraSite items, you can open the appropriate perspectives of the Interstage ASM client interface and immediately start working on the items. For example, from an SCM link, you can open the Interstage SCM perspective. The SCM project referenced by the link is selected in the navigator, and you can immediately browse and manipulate its resources. From a link relating to an external system or file, you can open your Web browser with the respective URL.


2.6 Process Control Any work you carry out on applications, services, requirements, change requests, releases and release iterations in LCM is controlled by processes. Process control ensures that all tasks are conducted properly, in time and by the appropriate persons.

Processes and Activities A process defines the activities that must or may be performed in the lifecycle of an application, service, release, release iteration, requirement or change request, and the possible transitions between these activities. In addition, a process has a start and one or more exits which define when the process is finished.

A simple process for a change request or a release may look like this:

Plan Implement Test completed

rejected

start

reject

fix

reject

The process defines the following activities, which are depicted in the boxes: 'Plan', 'Implement' and 'Test'. 'start' is the process start, 'completed' and 'rejected' are the exits. The arrows indicate the possible transitions between the start, activities and exits of the process. The transitions can be named, for example, 'reject' or 'fix'. If they are not named, the target activity is used as the name.

LCM supports processes of any complexity and granularity. In the example above, the process is simple but the activities are very coarse. A complex process could, for example, define several activities instead of just one for the planning, implementation and test phases. In typical scenarios, you will use rather simple processes for applications, services, release iterations and requirements, and more complex ones for change requests and releases.

As an application, service, release, release iteration, requirement or change request moves through its lifecycle, different users carry out the activities defined by the process. The users who are assigned to carry out a specific activity are referred to as the responsible users for this activity. In the sample process above, the 'Plan' activity could be assigned to a project manager, the 'Implement' activity to software developers, and the 'Test' activity to members of a quality assurance team. When defining process activities, you can specify user roles for restricting the possible responsible users to those having at least one of these roles.


Defining Processes The processes to be used in LCM can be defined in one of the following ways:

• Interstage Business Process Manager (Interstage BPM): Interstage BPM allows you to define processes of any complexity and granularity. It also provides the execution environment for these processes. This means that the activities which users carry out in LCM are controlled by Interstage BPM. LCM manages links to the processes and the data related to the activities in its repository. It also provides the user interface for working on the activities and the mechanisms to synchronize with Interstage BPM. Interstage BPM processes which are to be used with LCM must follow certain conventions and use specific nodes and actions provided by LCM. For details, refer to the Interstage ASM Customization Guide.

• XML files: You can define processes in XML files and then import the definitions to the repository where you manage your applications and services. This is suitable for workflow processes which are rather simple and coarse. The activities of such processes are carried out under full control of LCM.

LCM comes with sample process definitions for both options. You can use them in your environment or customize them as required.

Assigning Processes to Items and Starting Process Execution For each application, service, release, release iteration, requirement and change request you create in LCM, you can specify the process to be followed in the item's lifecycle. Items which are created automatically, for example, change requests created by assigning requirements to releases, are assigned a default process. For each application and service, you can specify different default processes for releases, release iterations, requirements and change requests.

The first activity defined by the process is created and activated automatically, and the responsible users can start working on it. If the process defines several activities in parallel following its start, all of them are created and activated. An exception to this are activities of Interstage BPM processes and subprocesses which are not synchronized with LCM.

Future activities defined by the process are not created automatically in the beginning, but only as required when the application, service, release, release iteration, requirement or change request moves forward in its lifecycle. However, you can at any time create such future activities manually, for example, for planning purposes. These activities are activated as they are reached in the execution of the process.

Work can only be performed for active activities, i.e. for the activities which are activated as they are reached in the execution of the process.


Planning Activities By default, activities do not provide options for specifying detailed planning data, such as the planned and estimated efforts, start dates and end dates. However, using the customization facilities of LCM, you can at any time define such activity properties as required by your organization. You may also integrate project planning tools which evaluate the data specified.

Working on Activities Working on activities means carrying out the tasks involved in them. For example, working on the 'Implementation' activity in the sample process depicted above will involve changing source code and documentation as required by the change request to which the process is assigned.

The work can be performed by the users responsible for the activity and as long as the activity is active.

Completing Activities and Processes When you have performed all the tasks involved in an activity, you complete the activity. By completing an activity, you perform the transition to one of the following activities defined by the process or to one of the process’ exits.

Once an exit of a process is reached, the process is completed. The application, service, release, release iteration, requirement or change request to which the process is assigned can no longer be changed. If changes are required after process completion, you can restart the corresponding process from the beginning, or create new items and execute their assigned process.

Using Subactivities Subactivities allow you to split up the work involved in an activity. For example, if the process defines rather coarse activities like the 'Implementation' activity in the example above, you can define subactivities for performing individual tasks or for assigning specific tasks to individual developers.

You can define subactivities for any activity which is not yet completed. Subactivities can be completed and reactivated independently as required as long as their parent activity is active. Activating or completing the parent activity also activates or completes all its subactivities.


Information on Activities LCM provides you with different means and ways to obtain information on activities:

• Personal activity list: At the client interface, you can display a list of all activities to which you are assigned as a responsible user. You can filter the list and customize the details display as required.

• Activity lists for applications, services, releases, release iterations, requirements and change requests: The navigation view of the client interface lists the activities for each application, service, release, release iteration, requirement and change request.

• Reports: Reports at different levels are available which include information on activities.

• Notification: Users can be notified by email when activities are completed and transitions to subsequent activities or process exits are performed. Processes defined in Interstage BPM can provide for additional notifications, for example, when the planned start or end date of an activity is reached.

2.7 Security and Access Control LCM is governed by the security and access control mechanisms based on roles and authorities, which are common to all Interstage ASM components. These mechanisms are described in detail in Section 9.4. The following sections describe the specifics and additions that apply to LCM.

Roles and Authorities You define roles and their authority assignments globally for all services and applications in a repository. Predefined roles are available for controlling access to applications and services, requirements, change requests and releases.

At each application and service, you can assign specific roles to users for controlling the access to the application or service itself and to its requirements, change requests and releases.

Authorities are predefined for actions on applications, services, releases, requirements, and change requests as well as for actions on specific properties and attachments of these items. Process activities are governed by the authorities defined for the respective applications, services, releases, release iterations, requirements or change requests.

LCM allows you to customize roles as well as authorities and their scope. For example, you can specify and modify the authorities required to change specific properties of items.


Responsible Users Each application, service, release, release iteration, requirement and change request has one or more responsible users at a time. Only the responsible users and users with appropriate privileged write authorities in their role can make changes to the item.

The responsible users of an application, service, release, release iteration, requirement or change request are identical to the responsible users of all related process activities which are currently active. You can change the responsible users both at the activities and at the corresponding item.

Update and Delete Protection Applications, services, releases, release iterations, requirements and change requests as well as their properties, attachments and associations with other items can be protected against any modification and deletion, independent of user roles and authorities. Such a protection is not set by users, but by the processes that control the items. For example, when a process is completed, the related application, service, release, release iteration, requirement or change request is protected against any further modification.

2.8 Customization and Extension LCM offers various options that allow you to configure and customize it to suit your needs.

The following features can be customized for each repository where you manage services and applications:

• User roles and authorities: You can adapt the predefined user roles and authorities and add new ones.

• Processes: You can adapt the processes shipped with LCM and define additional ones.

• Associations: You can adapt the possible associations between items and the way they can be displayed and processed at the user interface.

• User-defined attributes: You can adapt specific properties of items and define additional ones. The properties you can adapt or define are referred to as user-defined attributes. For each user-defined attribute, you can specify, for example, whether it is visible at the user interface, useable as a filter, and editable when a corresponding item is created. You can also supply your own methods that dynamically calculate or derive the attribute value at runtime. For example, such a method could calculate efforts or durations of specific activities.

Customer-specific methods for user-defined attributes make use of the Interstage ASM Java API. This API also allows you to develop your own applications that access LCM data and integrate LCM with other systems.

For details on customization and extension of LCM, refer to the Interstage ASM Customization Guide.


3 Software Configuration Management (SCM) SCM supports you in controlling the source code and other resources related to your services and applications. SCM enables the management of software development projects that range from simple applications to complex, distributed systems. Multi-user access and parallel development are supported by check-in/out and synchronization features and sophisticated security mechanisms. A project's resources are managed in configurations, which can be grouped in releases and products. The resources, configurations and releases can be controlled and integrated with the CHM and RLM lifecycle management components of Interstage ASM. While SCM is optimized for usage in the Eclipse IDE, it can easily be integrated into other development environments.

The software development projects managed by SCM are stored in one or more repositories. Users can access the data using the client, command line, Web interface, and WebDAV interfaces. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of SCM and introduce basic concepts.

3.1 Projects in SCM SCM manages the resources (folders and files), that make up a software product or component, in projects. SCM supports projects of any size, ranging from small applications to large software systems consisting of various components and subcomponents.

Each SCM project consists of one or more configurations. A configuration represents a specific status of a project's resources, for example, a specific build of a product or component. SCM distinguishes between working configurations, where resources can be created, changed or deleted, and snapshots or protected configurations, where no changes can be carried out.

The configurations of a project can be grouped in one or more releases, for example, to represent specific versions, variants or editions of the software product or component managed in the project.

Creating a project in SCM means creating its first release (default name: 1.0). Each new SCM release includes a working configuration (default name: MAIN) and a first snapshot, the so-called base configuration (default name: BASE). Starting from these initial items, you can create new configurations and releases as required. For more details on managing releases and configurations, see Section 3.4.

The illustration below shows the 'Interstage QA' project managed in SCM. The project has two releases, '1.0' and '2.0'. Release '2.0' consists of a working configuration, 'MAIN', and three snapshots, 'Build 1 – 2007-08-01', 'Build 2 – 2007-08-15', and the base configuration, ‘BASE’. The 'SCM' folder in 'MAIN' has been expanded to show the resources managed in this configuration.


ProjectRelease

Workingconfiguration

SnapshotSnapshot

ReleaseBase configuration

An SCM project and the resources it contains are stored in a repository. A repository can contain any number of projects. Users of SCM can access projects stored in the same repository or in different repositories on the same or different servers. This allows you to implement a scalable, high-performance software configuration management environment in your company and helps you organize an unlimited number of development projects.

3.2 Project Definition SCM projects can be created in one of the following ways:

• Sharing Eclipse projects or folders: Any development work available as a project in the Eclipse development environment can be shared as an SCM project using the standard Eclipse 'share project' team support function. Similarly, the command line interface allows you to share any folder in a file system as an SCM project. Sharing means creating the SCM project with its first release, working and base configuration in an existing or new repository. You can then add all or part of the Eclipse project's or folder's contents to the SCM project using the ’commit’ team support function.


• Migrating projects: SCM offers a migration framework that allows you to move or migrate development projects from different version control and configuration management systems to SCM projects, for example, from Microsoft Visual Source Safe or CVS. The SCM migration framework also enables you to move projects between repositories and SCM installations.

3.3 Resource and Version Management SCM supports all common resource and version management features provided by modern source code management systems. Versioning helps you keep track of changes and revert to a defined status of a project, if required.

Resources and Resource Versions Resources in SCM are all the files and folders that make up a project. All the resources are versionable. Committing a new resource to an SCM project means creating its first version in the repository and activating version control for it. A new version of a file is created each time a user commits changes made to it in the project. New versions of folders are created automatically by SCM as required.

The resources of an SCM project are managed in the project's configurations. Each configuration can contain exactly one version of a specific resource. On the other hand, a specific version of a resource can be included in several configurations.

Resource Creation You create resources independent of SCM in a local workspace or file system, and then commit them to a working configuration of an SCM project. In an Eclipse environment, for example, you can create folders and files in your local workspace. As long as you do not commit these resources to a corresponding SCM project, they are ignored by all SCM actions. This has the advantage that temporary or private resource structures can coexist with resources managed with SCM in a local workspace without affecting or being affected by SCM activities.

SCM provides synchronization and merge features that support you in adding new resources to existing SCM projects. In addition, name patterns can be defined for local resources that are to be ignored in such synchronization and merge operations.

Check-out and Commit Changing resources managed in SCM projects involves the following steps:

1. Check out the resources from a working configuration of the SCM project to a local workspace or file system: A check-out creates a new project in the local environment or updates an existing one, and copies the current version of the specified resources to it. You can check out an entire SCM project, project substructures, or single resources.

2. Change the resources in the local workspace or file system. You can do this at any place and any time using any tool, and independent of a connection to the SCM project and repository.


3. Commit the changed resources to the working configuration of the SCM project: For each file, a new version is created, which contains the changes. The new version replaces the previous one in the working configuration.

Before a commit is executed, SCM compares the resources in your local environment with the current and previous versions stored in the repository. This ensures that only resources changed locally are copied to the repository, and that changes made by other users and already stored in the repository are not overwritten. If there are such changes, the commit operation is aborted. You can then either merge the local resources with the ones stored in the repository, or carry out a commit that overrides the changes in the repository.

Synchronize and Update SCM supports an unlimited number of users working in parallel on the resources of a project. It provides features and options that help you synchronize your local working environment with the resources stored in the repository.

You can at any time compare the resources checked out to your local working environment with the current versions of these resources in the repository. The client interface provides graphical views which display the differences including information on which versions of the resources are more up to date. Additionally, you can compare the contents of files using an Eclipse-internal compare editor or external editors that can be configured for SCM.

If there are differences between the resources in your local environment and those in the repository, you can decide to:

• Commit your local changes to the repository. Changes made by other users and already committed to the repository can be overridden.

• Update your local environment with the resources stored in the repository. Changes made to the resources in the local environment can be overridden.

• Merge your own changes with the ones made by other users and then commit the result to the repository. Merging can be done manually or using the auto merge feature provided by SCM. The auto merge function can merge files with changes that do not cause conflicts, for example, when the changes were made in different lines of the files.

Version History SCM keeps an exact history of all versions of each file resource. The history includes the individual resource versions as well as additional information on each version:

• Predecessor, successor and parallel versions.

• Date and time the version was created.

• User who created the version.

• Information on whether the version is the result of a merge operation.


• Comment specified by the user for the commit operation by which the version was created.

• Change requests managed in CHM for which the version was created.

You can display the version history of file resources at the client and Web interfaces. A tree view and filters are available for adapting the display as required.

From the version history, you can:

• View the contents of each version.

• Export specific resource versions.

• Compare versions with each other using internal or external compare editors.

• Restore an old version of a resource, i.e. make the old version the current one.

Versioning and Resource Deletion Resources can be deleted from a working configuration of an SCM project. When this is done, the resource versions are not physically deleted but remain stored in the repository. The reason is that the resource versions may be part of other configurations. From the version history, you can restore versions of deleted resources, if required.

Resource Locks Resources of an SCM project can be locked for exclusive access. Only the user who has locked a resource can commit changes to it. The usage of resource locks is particularly useful in distributed development environments where several developers are working on the same resources: It avoids frequent merge operations and helps reduce the amount of resource versions.

Local Resource Monitoring Monitors can be set up for any local projects that are created by a check-out of resources. Such monitors allow you to keep track of changes that are carried out in the local workspaces but not yet checked in. For example, you can easily find out whether resources are already worked on by somebody else before changing or locking them. Thus, conflicts and merge operations can be avoided.

Usage of local resource monitors can be enforced for each SCM project. If it is not enforced, it can be enabled for each individual check-out, or activated and deactivated later at the local project.


Read-only Access and Export If you do not want to change resources in an SCM project but only need read access or local copies, you have the following options:

• Navigate project structures and view files directly in the repository using the client, Web or WebDAV interface.

• Export resources from the project to an external file system. The exported resources are independent of SCM.

• Check out resources in read-only mode, preventing accidental changes in the local working environment.

Navigation and Retrieval SCM offers various features and options that help you find the resources you are looking for:

• Navigation: In the client and Web interfaces, you can navigate SCM projects and their contents like in any standard tree view. Individual versions of resources can be accessed in the version history.

• Search: The client and Web interfaces provide sophisticated search features, including full-text search across multiple projects. You can search for resources by name, contents (full-text search), and properties (e.g. date of last modification, committing user). You can execute a search in one or more specific files and folders within a configuration as well as for one or more configurations, releases, or projects in a repository.

• Lost & Found: Each SCM project has a Lost & Found folder which holds all the resources that are no longer part of any configuration. This may be the case, for example, because configurations or the resources themselves have been deleted. From the Lost & Found folder, you can export the resources or open their version history.


3.4 Configuration Management SCM provides various features and options for creating and managing the configurations a project consists of and the releases by which they are grouped. This allows you to maintain different collections of the project's resources for different purposes.

Releases Each SCM project consists of at least one release. In SCM, a release is used to group configurations for representing a specific version, variant or edition of a project. A new release can be created based on a previous release. SCM distinguishes between the following types of release:

• Follow-up release: A follow-up release is a natural successor of another release in a development thread. For example, release 2.0 is a successor of release 1.0.

• Branch release: A branch release is a branch within a release. Branch releases are typically used for managing service packs or fixes of one release while the next (follow-up) release is already in progress. For example, release 1.0 could have branch releases named 1.1 and 1.2, and a follow-up release 2.0.

• Linked release: A linked release represents a release of another SCM project or a project not managed with SCM. Linked releases are used to express dependencies between projects and to actually link projects with each other. If a linked release relates to a release of another SCM project, you can navigate its contents as usual, independent on whether the release being linked is located in the same or a different repository.

SCM offers various features and functions for managing releases. You can:

• Create new releases.

• Link and unlink releases of other projects.

• Split a release into two or more releases.

• Close a release when work on it has finished, and reopen a closed release. Closing a release means protecting all of its working configurations against further changes. One of the release's configurations is marked as the 'released' configuration.

• Delete the contents of obsolete file versions in all configurations of a release.

• Create release-specific reports, including change reports across releases.

• Rename and delete existing releases.

Configurations A release of an SCM project consists of one or more configurations. A configuration represents a specific status of a project's resources within a release. With each release, its first working configuration (default name: MAIN) is created. Starting from this first configuration, you can create new configurations as required.


Users carry out their work in the working configurations of releases. A check-out is related to exactly one working configuration, and changes are committed to this working configuration.

You can save the current status of a working configuration, i.e. the current versions of all the resources contained in it, by creating a snapshot. A snapshot is a labeled and protected configuration that cannot be changed. Snapshots are typically used to retain specific statuses of a project within a release for purposes like builds, testing, quality assurance, service packs, fixes or dedicated deliveries to customers. With each release, its first snapshot, the so-called base configuration (default name: BASE), is created automatically. In a follow-up or branch release, the base configuration is identical to the configuration from which the release was created.

The working configuration from which you create a snapshot remains unchanged, and users can continue working on it without even having to be aware of the snapshot creation.

Based on snapshots, you can create new branches within a release. A branch is a new working configuration whose initial contents are the same as those of the snapshot on which it is based. Branches are useful, for example, to create and maintain different variants of the same software within a release or to support development teams who need stable versions of project components while work on these components continues in other branches. In each branch of a project, you can create snapshots and even new branches.

SCM offers various features and options related to configurations. You can:

• Display and navigate the configurations of SCM projects in the client and Web interfaces using different views and filters.

• Show the users who are currently working on a configuration.

• Change the working configuration to which a check-out is related. This is useful, for example, when new branches or releases are created after you have checked out resources, and you want to check in your changes to the new branch or release. It avoids repeated check-outs of the same resources. You can also disconnect your local resource copies entirely from the SCM project from which you checked them out.

• Lock an entire working configuration. Only the user who has locked the configuration can commit changes to it or modify it in another way. Locking is useful, for example, when running automated build scripts which rely on a stable and consistent state of a configuration.

• Create new snapshots and branches.

• Close branches. Closing a branch means protecting its working configuration against further changes. The working configuration thus becomes similar to a snapshot. It can be used as the basis for a new branch, if required.

• Compare configurations with each other.

• Create configuration-specific reports, including change reports across configurations.

• Rename and delete existing configurations.


Configuration Lifecycle Software development usually follows a company-specific lifecycle. SCM supports lifecycles for configurations, which define states and transitions between these states. Every configuration can be assigned exactly one state at a time. The state information helps you understand and control the software development process and shows the evolution of a release over time.

SCM comes with a default lifecycle for configurations, which defines the states and state transitions shown in the following graphics.

qa

in development

released

archived

In a typical scenario, the states of this lifecycle would be assigned to configurations as follows: Working configurations have the 'in development' state, while snapshots retained for quality assurance are in the 'qa' state. The 'archived' state is assigned to snapshots that are no longer used, and the 'released' state to the final configuration within a release.

SCM allows you to customize the default configuration lifecycle as required by renaming existing states and adding new ones. Additionally, the states of the default lifecycle can be adapted at each individual SCM project, allowing for flexible and dynamic integration into any existing development process.

SCM also provides options for automating state transitions: A state can be assigned the 'unique' property, which specifies that only one configuration within a release can have this state at a certain time. If a unique state is set for a configuration, another configuration having this state is automatically moved to the 'archived' state by SCM.


3.5 Products SCM provides product-oriented views and management of software development projects: Configurations of different releases and projects can be bundled in products and thus be structured and managed together. For example, you can check out or export all configurations of a product together, or take a snapshot of all configurations in one operation.

A product consists of member releases. A member release can be a release of an SCM project or represent a product or project not managed with SCM. For releases of SCM projects, you can assign exactly one configuration to a product. Products can be located in any SCM repository. Member releases may reside in the same repository or in different ones.

SCM offers various features and options for managing products. You can:

• Navigate product structures at the client interface.

• Create new products, and assign and deassign member releases.

• Change the configurations referenced by member releases.

• Check out a product: This means checking out all or selected configurations of the member releases to corresponding projects in your local workspace.

• Export a product: This means exporting all or specific resources of all or selected configurations of the member releases to an external folder. You can export each configuration to a corresponding subfolder of the external folder. Alternatively, all the resources can be exported to a single target structure, ignoring to which configurations they belong. This allows you, for example, to eliminate duplicate folders and files in the external folder.

• Create a product snapshot: This means creating a snapshot of the member releases’ configurations assigned to the product. You can choose to replace the existing configurations included in the product by the new snapshots.

• Lock a product: This means locking all working configurations assigned to the product.

• Create and manage product releases: Similar to SCM projects, products can have one or more releases. These can be branch releases or follow-up releases. Product releases can be managed in the same way as project releases.

• Link products, i.e. assign a release of one product as a member to another product.

• Rename and delete products.


3.6 Security and Access Control SCM applies the security and access control mechanisms based on roles and authorities, which are common to all Interstage ASM components. These mechanisms are described in detail in Section 9.4. Additionally, SCM controls access to its items and resources by means of access groups and access rights.

The following graphics shows the different elements of the SCM access model:

User

Access Group Authorities

Role

is member of

Project

is assigned to

defines a set of

hasAccess Rights

Resource

are assigned to

has

Product Repository

Access Groups Access groups define the users who are allowed to work on a project, product, or repository. Each project or product can be assigned up to eight access groups. Access to a repository as well as project creation in a repository can be limited to the members of up to eight access groups.

Access groups are standard user groups available on the servers hosting SCM repositories. System administrators can create and maintain these groups using their standard tools.

Roles and Authorities Roles and authorities can be defined for each project and are valid for all actions in this project. The same applies to the assignment of roles to users. Roles defined for one projects can be shared with other projects in the same repository.


Access Rights In order to carry out a specific operation on a resource, you not only need an appropriate role but also appropriate access rights to the resource. SCM distinguishes between the following access rights that can be assigned to resources:

• Owner: Users with owner rights can delete resources and change the access rights assigned to them. Owner rights include all other types of rights.

• Write: Users with write rights can check out and modify resources. Write rights include read rights.

• Read: Users with read rights can access resources for reading.

By default, all users of the access groups assigned to a project are given owner rights to all resources. Specific access rights can be set for individual users at each resource. The access rights set for a folder are inherited by all resources created in it. The user who creates a resource is automatically assigned owner rights to it.

3.7 Change Control SCM offers various features and options at different levels that allow you to control the changes carried out in projects:

• Integration with CHM: Any work on resources in SCM projects can be controlled by change requests maintained with the CHM lifecycle management component. For details, see Section 3.9.

• Configuration lifecycles: Defined states can be assigned to configurations so that company-specific standards can be adhered to. For details, see Section 3.4.

• Reports: All kinds of activities on repositories, projects, releases, configurations and resources can be evaluated by creating corresponding reports. For details, see Section 3.8.

• Version history: The version history of resources provides information on when and by whom the resources have been created, modified or deleted. For details, see Section 3.3.

• Local resource monitoring: Monitors can be set up for any local projects that are created by a check-out of resources, allowing you to keep track of changes that are carried out in the local workspaces but not yet checked in. For details, see Section 3.3.

• Change notifications: You can request change notifications by email when resources are committed, locked or unlocked. Subscriptions for notifications can be made at any level of a project’s structure.


3.8 Reporting SCM provides various reports which allow you to retrieve any information you need on projects, releases, configurations, folders, files and versions.

The following types of report are available:

• Audit reports: These reports provide information on activities and actions performed in a repository, project, release, configuration, folder or file. In addition, history information can be retrieved for individual resources and releases.

• Change reports: Change reports provide both statistical and detailed information on the changes carried out in releases, configurations, folders and files.

• Property reports: Property reports output information on the general properties of projects, releases, configurations, folders and files. Project structure reports provide a tree view of all releases contained in a project, including their dependencies.

The reports can be output in different formats (e.g. XML, HTML, CSV) and be customized as required.

3.9 Integration with LCM SCM can be integrated tightly with LCM, particularly with the RLM and CHM components. This allows you to control the work in your SCM projects by means of the processes which govern the applications, services, releases and change requests in LCM. For details on LCM, refer to Chapter 2.

CHM Integration Any work on resources in SCM projects can be controlled by change requests maintained in CHM. This basically works as follows:

In CHM, you define change requests and assign them to the appropriate releases of your applications or services, where they are to be implemented. To these releases, you link the working configurations of one or more SCM projects in which the changes are carried out. When you commit changes to resources of these working configurations in SCM, you can specify one or more of the change requests available in the releases. You thus assign the resources modified in SCM as changed items to the change requests in CHM. The access control mechanisms of LCM and SCM ensure that only the responsible users can commit changes for a change request.

SCM offers options to enforce strict change request control for a project. This means that whenever a user creates resources or commits changes, he/she must specify an appropriate change request.


RLM Integration In RLM, you define the artifacts that make up a release of an application or service by links to the relevant resource structures. These links are referred to as configurations. Within Interstage ASM, an RLM configuration typically links to an SCM configuration. An RLM release can include links to different SCM configurations within the same or different SCM projects and releases.

RLM and SCM provide various features to synchronize their releases and configurations with each other. These include the following:

• When you create a project in SCM, you can trigger RLM to create a corresponding application, release and link, or to link the working configuration of the new SCM release to an existing RLM release. Similarly, creating a release in an SCM project whose configurations are already associated with RLM releases, lets you create RLM releases or new links in existing releases of the corresponding applications.

• Generally, all SCM operations ensure that existing links in RLM are either not affected or are updated as required.

Deleting an item in SCM or RLM never removes associated items in the other system. This is to ensure data integrity within each of the systems. The only inconvenience of this behavior is the effect that releases in RLM could have ‘dangling’ references to deleted configurations in SCM.

3.10 Integration in Development Environments SCM can be integrated and used with various software development environments.

By its nature, SCM is integrated best in the Eclipse IDE. The complete functionality is made available through the SCM Eclipse plug-ins which you can add to any Eclipse installation. Thus, it can be used together with other Eclipse-based tools.

When using other development environments, you have the following possibilities of managing your software with SCM:

• You can make your resources available in Eclipse projects and use the client interface for version and configuration management. For working on the (checked out) resources, you can continue to use your own development environment.

• You can use the command line interface of SCM from within your own development environment to carry out version and configuration management functions. Various development environments, for example, Microsoft Visual Studio, offer the possibility to fully integrate commands of third-party tools into their interfaces.


3.11 Setup and Customization SCM offers various options that allow you to configure and customize it to suit your needs.

SCM Project Settings For each individual SCM project, you can configure the following:

• File name patterns: You can specify name patterns for files to be ignored in commit and update operations, to which the SCM auto-merge can be applied, or whose contents should be evaluated in reports.

• Change control: You can enforce the specification of change requests managed in CHM for all commit operations.

• Local resource monitors: You can enforce the usage of local resource monitors.

• User roles: You can adapt the predefined user roles and add new ones as required.

• Lifecycles: You can adapt the predefined configuration states and add new ones as required.

The settings can be shared by several projects. Additionally, the default settings available when projects are created can be customized to your needs.

Repository-Wide Settings In addition to project-specific settings, the following repository-wide settings can be made:

• Change control: You can enable or disable change control by CHM, and specify the LCM repository where the corresponding applications, services, releases and change requests are managed.

• Mail settings: You can enable or disable the sending of change notification emails, and specify the SMTP mail server and mail settings to be used.

• Search settings: You can enable or disable the search feature for a repository, and specify the server and directory where the search index for the repository is located.

• Delta storage of resource versions: If this setting is enabled, only the differences between two file versions are stored instead of the entire contents of both versions. This allows you to reduce the amount of disk space required.

• Audit log settings: You can enable or disable the recording of all read access operations in the audit log.

• Repository access and project creation: You can restrict access to a repository to specific access groups and specify if only repository administrators or specific access groups are allowed to create new projects in the repository.


Extensions to SCM In addition to the above setup and customization options, SCM offers means to extend its functionality: Most of the SCM actions offer extension hooks to which customer-specific methods can be attached. Customer-specific methods can be invoked before, during or after execution of an SCM action. Examples for such extensions are:

• Check whether a commit is allowed before it is executed.

• Count the number of changed lines or reformat source code according to company-specific rules during a commit.

• Synchronize third-party tools or reporting systems with SCM after a specific action has been performed.

• Send notifications to project members after a specific action has been performed.

Customer-specific methods for extension hooks make use of the Interstage ASM Java API. This API also allows you to develop your own applications that access SCM repositories and use the SCM functionality.

An additional way to extend SCM is the definition of custom attributes and relations for the SCM entities. This is useful, for example, to integrate other systems and tools, which can store their data with the SCM entities in the repository.


4 Document Management (DMS) DMS supports you in writing and maintaining the documentation related to your services and applications. While any documents can be managed with DMS, the focus is on documents that are created in the software development lifecycle, ranging from product definitions through specifications and review reports to user documentation and marketing material. To this end, DMS provides document-specific views for software development projects managed with SCM. The projects and documents can be accessed and handled in DMS without any adaptation.

The documents managed by DMS are stored in one or more repositories. Users can access the data using the client, command line or Web interface. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of DMS and introduce basic concepts.

4.1 Document Libraries DMS manages and organizes documents in document libraries (also referred to as DMS libraries). A document library can contain any number of documents (files) of any type. The documents can be organized in folders like in a file system:

A document library and the folders and documents it contains are stored in a repository. A repository can contain any number of document libraries. Users of DMS can access document libraries stored in the same repository or in different repositories on the same or different servers.


DMS provides various functions for setting up and managing document libraries and their structure. You can:

• Create new document libraries and repositories as well as access existing ones.

• Create folders and documents in document libraries.

• Import folders and documents from external file systems.

• Export folders and documents to external file systems.

• Copy and move folders and documents within a document library, between libraries and between libraries and external file systems.

• Create shortcuts in document libraries that relate to folders or documents in the same library or in other libraries. The related folders and documents thus become visible and accessible at the shortcut's location.

• Delete document libraries, folders, documents and shortcuts.

The client and Web interfaces allow you to navigate document libraries like in any standard tree view. You can expand and collapse structures and execute actions on selected libraries, folders or documents from toolbars and context menus.

Library Editions DMS lets you save the current contents of document libraries in so-called library editions. The structure and documents of a library edition can be viewed but no longer be changed. Work continues on the current contents of the document library.

The following illustration shows the 'Interstage Documentation' document library. One library edition, 'Review 2007-02-20' has been created. Afterwards, a new folder, 'COC' has been added to the 'Specifications' folder in the document library.

Document Library

Library Edition

You can create any number of editions for a document library as well as delete obsolete editions.


4.2 Document Editing and Versioning Documents managed with DMS are versionable. Versioning helps you keep track of changes and revert to a previous status of documents, if required.

Creating a document in a document library means creating its first version. A new version of a document is created each time a user checks in changes to it to the document library.

In contrast to documents, folders in document libraries are not versionable, because they solely serve to organize the documents in the libraries. Carrying out a DMS action for a folder means doing so for every document contained in the folder.

Document and Folder Creation You can create documents and folders of document libraries directly in the corresponding repository in several ways. In the client and Web interfaces, you can:

• Explicitly create folders and documents using corresponding menu options.

• Copy and paste folders and documents from other document libraries or external file systems.

• Import folders and documents from external file systems.

Document Editing Changes to existing documents are not carried out directly in the repository but in local workspaces or file systems. The following steps are involved in changing a document:

1. Check out the document from the document library: The document is copied from the repository to the local workspace or file system. In the repository, it is locked, preventing changes and check-out by other users. The same user can check out a document several times, each check-out overwriting the local copy of the document with the one stored in the repository.

2. Edit the document in the local workspace or file system. You can do this at any place and any time using any tool, and independent of a connection to the document library and repository. For example, you can check out documents to a mobile computer while you are in the office and connected to the network, and work on the documents at home where you do not have such a connection.

3. Check in the changed document to the document library in the repository: A new version of the document is created, which contains the changes. The previous version remains unchanged.

The client interface offers options for carrying out step 1 and 2 in a single action: You can open a document for editing within the client interface or in an external editor. When doing so, the document is checked out implicitly. An explicit check-in is still required in this case, i.e. the document is not checked in automatically, for example, each time you save it to disk. This is to avoid the creation of unnecessary versions in the document library, and facilitates working without connection to the repository.


Version History DMS keeps an exact history of all versions of each document. The history includes the individual document versions as well as additional information, for example, when and by whom each version was created and the comment specified by the user who checked in a new version.

You can display the version history of documents in the client and Web interfaces. From the version history, you can:

• View the contents of each document version.

• Compare versions with each other using internal or external compare editors.

• Restore an old version of a document, i.e. make the old version the current one.

Versioning and Document Deletion Documents can be deleted from a document library. When this is done, the document's existing versions are not physically deleted but remain stored in the repository. The reason is that the document versions may be part of saved library editions that must not be changed.

In the client and Web interfaces, deleted documents that do not occur in any library edition are listed in a Lost & Found folder. From this folder, you can, for example, export documents or display their version history. From the version history, you can restore versions of deleted documents, if required.

Document Locks Documents are locked automatically in the repository when they are checked out, and unlocked when they are checked in. The same applies to folders.

DMS offers additional options related to locks on documents. You can:

• Explicitly lock documents and folders without checking them out to prevent them from being changed.

• Explicitly unlock documents and folders.

• Undo the check-out of documents and folders. This means that the original documents or folders are unlocked in the repository without changes being checked in.


4.3 Read-only Access to Documents When you want to just view the contents of documents, you can do so from the client and Web interfaces without having to check out the documents. Viewing is possible at any time, independent on whether a document has been checked out by another user.

You can check out documents in read-only mode. In contrast to a usual check-out in read/write mode, a check-out in read-only mode does not lock the documents in the repository. This means that the documents can still be checked out by other users in parallel. Checking out documents in read-only mode is useful, for example, in the following cases:

• Obtain local copies of documents in order to navigate them in the client interface independent of a connection to the repository, for example, on a mobile computer.

• Parallel work on compound documents: Compound documents consist of several documents which are interlinked with each other. For example, a Web page may contain links to other pages or images. To work on one member of a compound document, it is usually required to have access to the other members, too. However, if you check out all members of a compound document in order to work on just one of them, other users cannot do the same at the same time because the documents are locked. The solution to this is that each user checks out all members of the compound document in read-only mode, and uses read/write mode only for the member he/she wants to change.

When you have checked out a document in read-only mode, newer versions of it may be created in the repository at any time. This is indicated at the client interface. You can decide to update your local copy of the document by a new check-out or continue using the old copy.

4.4 Document Retrieval DMS offers various features and options that help you find the documents you are looking for:

• Navigation: In the client and Web interfaces, you can navigate document libraries like in any standard tree view. While the Web interface allows for browsing the repository contents, the navigator of the client interface provides an integrated view of document libraries as they are stored in the repository and of your local workspace. You know at any time which copy of a document (local or repository) you are looking at, and which is more up-to-date.

• Version history: Individual versions of documents can be accessed in the version history at the client and Web interfaces.


• Search: The client and Web interfaces provide sophisticated search features, including full-text search across multiple document libraries. You can search for documents (and folders) by name, contents (full-text search), properties (e.g. date of last modification, check-in comment), and categories. You can execute a search in one or more selected documents or folders within a library as well as for one or more libraries in a repository including or not including library editions.

• URL access: You can access document libraries, folders, and documents directly using a corresponding URL. For example, you can send such a URL to another user by email. The other user can navigate directly to the corresponding library, folder or file in the client or Web interface by invoking the Go to option and entering the URL. A URL can also be used to address a specific library, folder or document at the Web or command line interface or even from outside DMS.

• Categorization: When using DMS together with COC, you can assign a category to each version of a document. When you search for documents, you can use categories as search criteria. Categories are defined centrally in COC.

4.5 Reporting DMS provides various reports which allow you to retrieve any information you need on document libraries, editions, folders, documents and versions.

The following types of report are available:

• Audit reports: These reports provide information on activities and actions performed on an entire document library or repository, a folder or a document. In addition, history information can be retrieved for individual documents.

• Change reports: Change reports provide both statistical and detailed information on the changes carried out in documents, folders, or library editions.

The reports can be output in different formats (e.g. XML, HTML, CSV) and be customized as required.

4.6 DMS and SCM DMS is focused on the management of documents that are created in the software development lifecycle. These may be any kind of documents, for example, product definitions, specifications, review reports, user documentation and marketing material.

SCM projects may include many of such documents spread across various folders which also contain source code and other files. With DMS, you can provide document-specific views on the SCM projects, which only show the documents that are of relevance to specific user groups, for example, managers, reviewers, or technical writers. The users can work on the documents using DMS functions in the usual way and do not need to care about SCM-specific features and functions (e.g. releases, configurations, synchronization).

Using DMS upon SCM projects basically works as follows: In DMS, you can access any SCM project as a document library. If the project has several releases or working configurations, you can access each of them individually as a document library.


By default, you can see and access all the folders and files of the SCM project. Using filters, you can determine which folders and files are to be included in the display, and thus provide for any document-specific views. The filters can be switched off and on as needed.

In DMS, you can add, change and delete folders and documents in document libraries mapped to SCM projects as usual, provided you have appropriate roles and access rights and the folders and documents are not locked or protected. The changes carried out in DMS are visible immediately in SCM in the relevant projects and configurations.

In summary, DMS works with the same items as SCM, providing different views on them. DMS items map to SCM items as follows:

• Document libraries map to working configurations in releases of SCM projects. When you create a document library, a corresponding SCM project with a release (1.0), working configuration (MAIN) is created.

• Library editions map to SCM snapshots. When you access an SCM project as a document library in DMS, the snapshots are available as library editions.

• Folders and documents map to the corresponding SCM resources.

In addition to the same items, DMS also makes use of several SCM features as described in the remaining sections of this chapter.

4.7 Security and Access Control DMS applies the same security and access control mechanisms as SCM. These mechanisms are described in detail in Section 3.6. In DMS:

• Access groups can be assigned to document libraries and repositories.

• Roles and authorities can be defined for each document library and shared with other libraries. DMS provides its own default roles and authorities, which are different from SCM.

• Access rights can be set on folders and documents just like in SCM.

4.8 Change Control DMS offers various features and options that allow you to control the changes carried out in document libraries:

• Integration with CHM: Any work on folders and documents in DMS libraries can be controlled by change requests maintained with the CHM lifecycle management component. Integration with CHM is achieved in the same way as in SCM. For details, see Section 3.9.

• Reports: All kinds of activities on document libraries can be evaluated by creating corresponding reports. For details, see Section 4.5.

• Version history: The version history of documents provides information on when and by whom the documents have been created, modified or deleted. For details, see Section 4.2.


• Change notifications: You can request change notifications by email when folders and documents are checked in, locked or unlocked.

4.9 Setup and Customization DMS offers various options that allow you to configure and customize it to suit your needs.

Document Library Settings For each individual document library, you can configure the following:

• User roles: You can adapt the predefined user roles and add new ones as required.

• Change control: You can enforce the specification of change requests managed in CHM for all commit operations.

The settings can be shared by several document libraries. Additionally, the default settings available when document libraries are created can be customized to your needs.

Repository-Wide Settings In addition to library-specific settings, the following repository-wide settings can be made:

• Change control: You can enable or disable change control by CHM, and specify the LCM repository where the corresponding applications, services and change requests are managed.

• Mail settings: You can enable or disable the sending of change notification emails, and specify the SMTP mail server and mail settings to be used.

• Search settings: You can enable or disable the search feature for a repository, and specify the server and directory where the search index for the repository is located.

• Delta storage of document versions: If this setting is enabled, only the differences between two document versions are stored instead of the entire contents of both versions. This allows you to reduce the amount of disk space required, depending on the types of documents.

• Audit log settings: You can enable or disable the recording of all read access operations in the audit log.

• Repository access and library creation: You can restrict access to a repository to specific access groups and specify if only repository administrators or specific access groups are allowed to create new document libraries in the repository.

Extensions to DMS Extensions to the functionality of DMS can be achieved by extensions to SCM. For details, see Section 3.11.


5 Source Code Analysis (SCA) SCA supports you in maintaining the source code of your software systems, including mainframe and legacy software. Source code of various programming languages can be scanned and then be analyzed, for example, in order to understand the code's logical structure and determine the impact of changes. SCA provides interfaces for navigating the code's structure and dependencies, and offers metrics and statistic values. The SCA interfaces and high-performance scanners allow you to analyze even large amounts of source code quickly and efficiently. Analysis results can be stored and managed using DMS.

The SCA server scans the source code and maintains the scan results on which source code analysis is based. Scan configurations and analysis data are stored in a repository. Source code scanning can be invoked from the client and command line interface, analysis is carried out in the client interface. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of SCA and introduce basic concepts.

5.1 Cubes In SCA, you carry out source code analysis on so-called cubes. An SCA cube is an OLAP cube resulting from a source code scan. It includes entities that represent source code elements (e.g. programs, variables, statements) as well as their interrelationships.

When carrying out a source code analysis, you can navigate and query an SCA cube, for example, in order to understand the structure and dependencies of the underlying source code. Entities can be filtered and selected, for example, to determine the impact of a change request.

Cubes are created and maintained on the SCA server. An SCA server can host any number of cubes for different sets of source code. Users of SCA can access cubes stored on the same SCA server or on different servers. This allows you to implement a scalable, high-performance environment in your company.

You access SCA cubes and carry out analyses from the client interface. For each cube, you add a corresponding item in the SCA navigator. From this item, you can configure the code scanner, execute a scan and start or continue analyses. The item representing the cube, the scan configuration as well as information on individual scans and analyses are stored in a repository.

The following illustration shows some SCA cube items and analyses.


5.2 Source Code Scanning Source code analysis starts with scanning the source code on the SCA server, building a corresponding cube.

The SCA scanners support a variety of programming languages and source code, ranging from mainframe software to Java:

• Programming languages: COBOL, PL/I, Assembler, NATURAL, Java

• Database definitions: SQL, IMS, ADABAS, UDS

• Transaction system definitions: CICS, UTM

• Job control language (JCL)

SCA supports the scanning of huge software systems that include any combination of the above types of source code. Configuration options allow you to determine which source code files and types are to be included and how specific constructs in the source code are to be handled.

Scanning is very fast: Within one hour, about 10 million lines of code can be scanned. Scanning 20 million lines of code takes about 90 minutes. This allows you to repeat scans as often as required, for example, when changes have been made in the source code, or different configuration options should be used.

Scanning analyzes the source code and extracts information on different types of entities from it. Examples for such entities are: source code type, programs, sections, symbols, variable definitions, tables, segments etc. From this information, the SCA cube is built. The cube includes additional information, which is calculated from the scan results, and links the entities with each other.


Scan Preparation and Execution Preparation of a source code scan involves the following:

• Source code: The source code must be available on the SCA server. For example, source code managed with SCM can be checked out or exported to a folder on the SCA server, or mainframe code can be transferred to the SCA server using tools like FTP.

• Configuration: The scan configuration can be set up and changed from the client interface. The configuration is stored in the SCA repository and can be used for multiple scans.

Scanning can be started at any time from the client or command line interface. The scan command of the command line interface can be invoked via scheduling functions of the underlying operating system (for example, AT on Microsoft Windows). This allows you, for example, to scan huge software systems every night so that users can analyze the most up-to-date sources in the morning.

Information on when a scan has been started and finished is recorded in a log in the SCA repository allowing you to follow up the scan history for each SCA cube.

5.3 Analysis The actual analysis of source code is carried out based on the information contained in an SCA cube. Users work with the client interface, which offers views and features that allow you to efficiently analyze code for different purposes.

You start a source code analysis from an SCA cube item. You can start a new analysis or open an existing one to continue working on it. SCA ensures that only one user can work on a specific analysis at a time.

The code analysis is carried out in different SCA views. The available views and their contents depend on the underlying source code and on the scan configuration. For example, when analyzing COBOL code including JCL and SQL definitions, corresponding views are provided showing the entities extracted from the sources.

5.3.1 Dependency Navigation One way to carry out source code analysis with SCA is to navigate the code structure by following dependency relationships between entities. This is suitable, for example, if you need to understand the structure of a software package, or to determine which entities may be affected by changes to a specific piece of code.

The client interface provides a view where you can navigate dependencies extracted from the source code as shown by the following COBOL sample:


5.3.2 Analysis by Selection Analysis by selection allows you to determine in detail the impact of changes on the whole source code represented in an SCA cube.

Selections are made in the SCA views that show details of specific types of entities in tables. Single or multiple values contained in any columns of these tables can be included in or excluded from a selection. When including or excluding entities in/from a selection, related entities in other tables and views are selected or deselected implicitly, and the views are adapted accordingly. This means that each view displays exactly those entities that are of interest and relevance to you.


For example, if you know a specific column of an SQL table, you could find out easily which programs carry out changes in this column as follows:

1. In the SQL Table Columns view, include the table column of interest in the selection.

2. Display the Statements view: It shows only program statements (e.g. SELECT, INSERT, UPDATE) that carry out operations on the table column selected in step 1.

3. Include the UPDATE statement or statements of interest in the selection. The Programs view displays the programs where the selected statements occur.

Another example would be to obtain all source code elements where any variables of a specific type (e.g. DATE) occur in order to determine the impact of a problem. The first step here would be to select all variables of the relevant data type in the Variables view. In further steps, the selection could be narrowed to specific programs, tables, statements, jobs etc.

Selection by Search SCA provides a search facility that helps you find and select specific entities in the different views and tables. The search facility allows to search for specific strings or patterns with wildcards (*, ?) in each of the available columns of any table.

For example, you could search for all SQL statements in a software system by specifying 'SQL' as the search term to be found in the 'Access Type' column, which is part of the table displayed in the Statements view.

The search result is displayed in a separate view. You can include or exclude single or all of the found entities in/from your selection, updating all the other entity views accordingly.

Selection by SQL Queries Another way to perform selections in an efficient way is to write and execute SQL queries that retrieve entities in any of the available tables and columns.

In a query, you typically use a sequence of SELECT statements. Each statement works on the results of the previous statement. You can select and deselect entities as well as invert and undo selections. The results of queries are immediately reflected in the entity views of SCA.

Queries are stored in the SCA repository as part of the analysis data. They can be executed as often as required, with or without previous adaptation. Using queries is particularly helpful for selecting the same initial set of data each time you open an analysis, for example, all programs and variables related to a specific topic.


Selection by Scan Problems SCA identifies and records problems that occur in the scanning of source code. Such problems may be due to missing source files (e.g. include files or copybooks) or statements that are unknown to the scanner, but may also be actual programming bugs.

SCA lists all problems found in a separate view from which they can be included and excluded in/from selections in the same way as source code entities. When including a problem in a selection, the entity views of SCA are adapted accordingly, showing only the entities where the problem occurs. You can thus easily locate problems in the source code and correct them as required.

Selection Overview and History SCA keeps an overview and history of all selections you have made in an analysis session. The overview and history includes manual selections as well as selections made via searches and queries.

In the overview and history, you can:

• Undo and redo individual selection steps.

• Undo all selections to start from the beginning.

• Remove selections.

Any of these actions are reflected immediately in the entity views of SCA.

Additionally, you can save the selections shown in the overview and history as an SQL query in the repository. This allows you to repeat these selections quickly and easily later in a new analysis session by just executing the query.

5.3.3 Source Code Review SCA allows you to view any of the scanned source files directly from the client interface. This means that you can at any time review the source code, for example, to find out more about the context of specific elements.

Source files can be viewed independent of any entities or for specific entities. When viewing a source file for a specific entity, the file is opened at the entity's position. This allows you to locate the relevant code quickly without having to search or browse the whole file.


5.3.4 Metrics and Statistics SCA provides metrics and statistic values for the scanned source code. These values can be used as the basis for specific analysis and evaluation tasks, for example, function point analysis or quality management reports.

Metrics and statistic values are available for all of the scanned source code as well as for the entities currently contained in a selection. The values include, for example, numbers of function points, lines of code, source files, variables, and statements.

5.4 Analysis Results Analysis results include the entities, metrics data and scan problems that you identify as relevant based on your analysis. For example, when carrying out source code analysis for a change request, you would add all entities which require modification to the analysis result. Additionally, you could include metrics and statistic values for reporting purposes.

Any entity, metrics values and scan problems available in SCA can be added to an analysis result. To each entity in the result, you can assign a comment and category for explanation, identification and retrieval purposes.

The analysis result is stored in XML format in the SCA repository together with the analysis data. It is loaded automatically and used as the basis when continuing an existing analysis. You can expand, update and reduce the analysis result at any time.

You can generate reports of analysis results in different formats, for example, HTML or XML, and save them to any file system. In this way, the analysis results can be made available and used outside of SCA. The HTML output of an analysis result can also be checked in to a DMS library, where you can handle it like any other document.

In addition, you can copy all or part of an analysis result to text documents or spreadsheets for further processing. For example, you could use Microsoft Excel to produce diagrams and calculations based on the analysis result.

5.5 Security and Access Control SCA is governed by the security and access control mechanisms based on user roles and authorities, which are common to all Interstage ASM components. These mechanisms are described in detail in Section 9.4.

Roles and their authority and user assignments are defined globally for an SCA repository. They apply to all source code analyses in the repository.


6 Quality Assessment (QAM) QAM supports you in analyzing and monitoring the quality of source code. For any source code scanned with SCA, you can retrieve metrics and derive or calculate appropriate quality indicators. You can use these indicators for a detailed quality assessment and problem analysis of the source code as well as for comparisons and trend analyses over time. The assessment results can be visualized as text and graphics and output to appropriate reports.

Quality assessments are based on cubes created and maintained with SCA. You carry out quality assessments from the client interface. Measurements can be taken from the client or command line interface. All QAM data is stored in a repository. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of QAM and introduce basic concepts.

6.1 Indicators, Entities and Measurements In QAM, you analyze and monitor the quality of source code by means of indicators. Indicators are derived or calculated from metrics which are obtained from the source code. For example, metrics could be the lines of code or the number of function points in a program. From these metrics, the following indicators can be derived or calculated:

• Lines of code: directly derived from the lines of code metrics.

• Number of function points: directly derived from the number of function points metrics.

• Number of function points per lines of code: calculated by dividing the number of function points by the lines of code.

QAM does not retrieve the basic metrics from the source code as such, but from SCA cubes. An SCA cube is the result of a source code scan in SCA. It includes entities that represent source code elements (e.g. programs, variables, statements) as well as their interrelationships. For more details on source code scanning and SCA cubes, refer to Chapter 5.

QAM supports quality assessments with SCA cubes for source code of the following programming languages: Java, COBOL, Assembler, PL/I, and NATURAL. It comes with predefined sets of metrics which can be retrieved for each type of source code. For each metric, a corresponding indicator is available which you can use immediately. You can also define indicators of your own, combining the predefined metrics by any arithmetic operations.

The metrics and the corresponding indicator values relate to specific entities in the SCA cube. For Java, the main entities are packages and classes, for COBOL, Assembler, PL/I and NATURAL, the main entities are programs. Details are available down to a very granular level, for example, individual methods in Java classes or statements in a COBOL program.


The metrics and indicator values for a quality assessment are retrieved from the SCA cubes by taking measurements. You can take any number of measurements for a quality assessment, for example, to perform a trend analysis over time for different versions of the same source code.

Measurements can be started from the client interface or command line interface. The command line interface command can be invoked via scheduling functions of the underlying operating system or from within other programs. This allows you, for example, to integrate the measurements in an automated software build process, where the current indicator values are obtained for each build.

The assessments you create in QAM as well as their indicators, entities and measurements are stored in a repository and accessible at any time from the client interface.

6.2 Assessments In QAM, you can create any number of assessments and group them in folders as required.

For each assessment, you specify the following:

• SCA cube: This is the SCA cube to which the source code to be analyzed has been scanned. The cube determines the type of the source code (Java, COBOL, Assembler, PL/I or NATURAL) and the available indicators. In a single assessment, you can include source code from different SCA cubes and thus of different languages. This allows you to analyze the quality of software products that comprise heterogeneous source code. On the other hand, any number of quality assessments with different indicators can be carried out for the same SCA cube.

• Entities: A quality assessment can cover all relevant entities available in the specified SCA cube. Using filters, you can exclude entities from the assessment. For example, you can exclude specific Java packages and classes or COBOL programs contained in specific source code files.

• Indicators: These are the indicators to be used.

When you create an assessment or at any later time, you can take a measurement to obtain the current metrics and indicator values for your source code. These are the basis for your quality analysis.

The client interface provides a navigation view where you can see and browse all your quality assessments with their indicators, entities and measurements as shown in the following illustration.


6.3 Basic Analysis of Indicator Values A basic quality assessment of source code consists in analyzing and evaluating the indicator values obtained by one or more measurements.

The client interface provides you with comfortable ways to display indicator values from different points of view and at different levels of detail:

• Tables: By simply selecting elements in the navigation view, you can display the indicator values for all or individual entities and measurements in a table. For example, selecting an entity displays a table of all indicators and their values obtained in each measurement for this entity. Selecting the Entities node displays the cumulated indicator values for all entities and measurements. For a selected measurement, the table shows the values of all indicators for each entity. By default, the tables display the values for all indicators, entities or measurements available in an assessment. Using filters, you can restrict the lines and columns to those you are interested in.

• Charts: Selecting a row in the table displays a graphical representation of the indicator values it contains. For example, selecting a row containing an entity and its indicator values for a measurement displays the values in a bar chart. Selecting a line containing an indicator with its values for different measurements displays a corresponding line chart.


• Details: For each individual indicator value contained in the table, you can display comprehensive details related to the entity for which it was obtained. For example, for an indicator that calculates the function points of a Java class or COBOL program, the details show the function points for each method or statement.

6.4 Problem Analysis Indicator values may point out various types of problems and defects in your source code. QAM provides you with means to exactly locate and analyze these problems:

• The details display for each indicator value shows where a problem occurs. For example, an indicator may point out that there are methods with invalid names in a Java class. The details display tells you the names and locations of these methods.

• From the navigation and details displays, you can open the relevant source code to thoroughly analyze a problem. For example, from the details display you can open the source code of a Java class containing invalid method names.

6.5 Quality Evaluation by Values and Thresholds Indicator values as such are absolute numbers obtained by measurements. In order to interpret the actual quality of source code, you have to judge whether these values are good or bad.

Specific indicators allow you to make this judgment immediately from their absolute values. For example, you will usually not accept Java classes containing methods with an invalid name length. Therefore, a corresponding indicator value other than 0 expresses bad quality.

For other indicators, the values must be in specific ranges in order to meet the quality criteria defined globally for your company or for specific software components. These ranges are defined by thresholds. For example, up to a certain number of function points, a program may be considered good. Up to a higher number, the quality would be acceptable, and beyond a third number the quality would be bad because the program would be too complex and hard to maintain.

QAM enables you to obtain an immediate overview of your source code’s quality by means of colors assigned to indicator value ranges: For each indicator, you can define any number of value ranges by specifying their thresholds. To each value range, you assign a color and a name. For example, you could assign green/‘OK’ to the range of good values, yellow/‘attention’ to the next range, and red/‘unacceptable’ to the rest.

The colors you specify are used in the tables displaying the indicator values. This allows you to quickly and easily judge the quality of your source code.


6.6 Trend Analysis and History QAM enables you to analyze the quality of source code and its evolution over time. This is achieved by taking measurements of different versions of the same source using the same indicators. For example, you could take a measurement for each build of an application or at specific milestones during software development.

The views of the client interface allow you to quickly and easily compare the indicator values obtained with individual measurements. The tables with the indicator values and colors and the line charts provide an immediate overview of positive as well as negative trends.

You can keep any measurements and their indicator values as long as required. This history is useful, for example, for auditing purposes and for evaluations of how the quality of a software product has evolved over time.

6.7 Quality Comparisons QAM provides you with various means and ways to compare the quality of different sets of source code, for example, the source code of different applications.

A vital prerequisite for such comparisons is the application of uniform quality criteria to all the source code. This is achieved by using the same indicators with identical threshold values for the relevant assessments. QAM facilitates the maintenance of identical indicators in that it allows you to copy them between any of your assessments.

Usage of the same indicators is in itself a way to evaluate the quality of a set of source code compared to others. In addition, QAM offers you means to directly compare indicator values collected in different assessments and measurements: You can add indicators, entities and measurements of any assessment to a selection, and then apply the selection as a filter to the tables and charts provided by QAM. The indicator values in the tables and charts thus provide for direct comparison of the elements in the selection.

6.8 Quality Reports You can at any time generate a report of the current contents of the QAM tables, charts and details display. You can output reports in different formats (e.g. HTML or XML), and save them to any file system. In this way, the assessment results can be made available and used outside of QAM.

6.9 Security and Access Control QAM is governed by the security and access control mechanisms based on user roles and authorities, which are common to all Interstage ASM components. These mechanisms are described in detail in Section 9.4.

You define roles and their authority assignments globally for all quality assessments in a repository. At each assessment, you can assign specific roles to users for controlling the access to the assessment itself and to its indicators, entities and measurements.


7 SOA Asset Management (CentraSite) CentraSite supports you in managing and governing your SOA environment and enables you to achieve control and transparency across all IT resources related to it. CentraSite stores and manages metadata for your SOA assets (e.g. Web services). Sophisticated browsing and information retrieval capabilities allow you to easily understand which services are available across departments, who uses them and what business values they offer. They help you analyze the impact of changes before they are applied to the SOA resources.

The metadata managed with CentraSite are stored in a repository. Users can access these data using the client interface, which also integrates the WebDAV interface. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of CentraSite and introduce basic concepts.

7.1 SOA Assets and Metadata The IT resources or assets of a service-oriented architecture typically comprise Web services and application integration models as well as related artifacts including business process and information models.

CentraSite does not store or manage the assets themselves but descriptive metadata and information on them. This information and the CentraSite browsing, analysis and retrieval features based on it allow you to analyze and understand the structures and interdependencies of the SOA assets and the impact of changes to them.

CentraSite Registry and Repository CentraSite stores and manages the metadata for your SOA assets as object and folder/file structures in an Enabler repository. The object structures are referred to as the CentraSite registry, the folder/file structures as the CentraSite repository.

The following illustration shows object and folder structures as displayed at the client interface.


Objects in the CentraSite Registry Folders in the CentraSite Repository

Registry Objects The information contained in the CentraSite registry is organized and represented by so-called registry objects and associations between them. The registry objects, their properties, types and structures follow the paradigms of the JAXR and UDDI standards.

Important registry object types for describing SOA assets are the following:

• Organization: A registry object of this type represents an organization involved in the SOA, for example, an enterprise or part of an enterprise that provides services.

• Service: Registry objects of this type represent services provided by an organization, for example, Web services. A service is described by service bindings, specification links, interfaces and operations, which are also represented by registry objects of the corresponding types.

• Taxonomy and Category: Taxonomies are structured collections of categories which are used to classify other registry objects. For details on classifications, see Section 7.5.

CentraSite allows you to define registry object types of your own as well as to modify and delete types you have created.


Each registry object has a set of properties that describe it. CentraSite distinguishes between predefined properties, which cannot be changed, and custom properties. You can define and modify custom properties of your choice for any object type as well as for individual registry objects.

In addition to properties, registry objects are characterized by associations and implicit references with other objects. These describe how the SOA asset represented by a registry object is related to other assets or artifacts in its environment. Registry objects can also have any number of links to resources (e.g. folders or files) that are managed outside the registry, for example, in the CentraSite repository or on a WebDAV server. A link to an external resource is represented by the URL of this resource, which is stored in the registry.

Repository Folders and Files The CentraSite repository typically holds files that are related to registry objects, for example, the WSDL files of services or XPDL and schema definition files. Folders and files held in the repository can be linked to objects stored in the registry. In fact, some features of CentraSite, such as the import of a Web service, create entries in the repository as well as corresponding objects in the registry.

7.2 Metadata Definition CentraSite allows you to manually create any objects, folders and files in its registry and repository. However, you will typically use other means to build the metadata that describe your SOA assets.

Import CentraSite includes powerful import features which can extract data from various sources and create the corresponding items in the registry and repository. You can import:

• XML schemas from a Web server or file system.

• Web services from a Web server, file system or UDDI server.

• Any CentraSite data contained in an archive which you have created with the CentraSite export function before.

Integrated Systems CentraSite can be integrated with different systems in your SOA environment, for example, Interstage BPM. These systems use CentraSite as their integration and storage platform. They create, update and retrieve all the required metadata in the registry and repository. For more details on system integration, see Section 7.9.

Registry Federation CentraSite registries can participate in a federation and obtain read-only copies of registry objects from other CentraSite or UDDI registries. For more details, see Section 7.8.


7.3 Navigation and Information Retrieval CentraSite provides you with various means and ways to obtain information on your SOA assets and on how they are interrelated:

• Navigation: The client interface displays the registry objects and repository folders and files in structures which you can navigate like in any standard tree view.

• Association graphs: Registry objects and their associations and implicit references with other objects can be navigated in graphs at the client interface. Filters allow you to determine exactly which registry objects, associations and references are displayed. The graphs can be displayed, sized and printed in different ways.

• Details and environment: The client interface provides various views which show all the details and environment of a selected item. From these views, you can navigate to other items and display their details.

• Search: CentraSite includes sophisticated search features which help you quickly find any objects in the registry. You can search for registry objects by simple and complex conditions. For example, you can search for services by their name, their providing organization, their operations and/or their interfaces. Alternatively, you can use queries in XQuery format of any complexity to retrieve the objects you are looking for.

• Personal Favorites: Each user can create and maintain a list of his/her favorite registry objects, folders and files. This allows for fast and easy access to these items and their related information.

7.4 Impact Analysis Impact analyses help you determine how your SOA environment would be affected by changes to specific assets and artifacts. In CentraSite, you can carry out both graphical and textual impact analyses on the registry objects that represent your SOA assets:

• Graphical impact analysis: You can carry out impact analyses using the association graphs at the client interface. The graphs show how the registry objects and thus the SOA assets are interrelated with each other and how changes would affect them.

• Textual impact analysis: CentraSite allows you to easily retrieve lists of registry objects which are related in some way to a selected object and thus would be affected by changes to this object. Like with the association graphs, you can specify filters to determine exactly which registry objects and associations are to be taken into account.

The CentraSite navigation, details display and search features described in Section 7.3 provide you with additional, powerful means to retrieve registry objects that are related with each other in specific ways and thus perform impact analyses.

In addition, CentraSite automatically performs an implicit impact analysis whenever you attempt to perform an operation that might violate overall system integrity by breaking usage relationships, for example, when you try to delete a service that is still in use by a business process.


7.5 Classification Classifications are a powerful way to organize and categorize registry objects and facilitate later retrieval. Classifying registry objects means assigning categories of one or more taxonomies to them.

CentraSite supports both internal and external classifications:

• Internal classifications use taxonomies and categories which are stored and maintained in the CentraSite registry. You can create and maintain any number of taxonomies and categories in a registry.

• External classifications use taxonomies and categories which are not maintained in CentraSite but, for example, in an external UDDI registry.

7.6 Packaging CentraSite allows you to organize and group registry objects of any type by assigning them to packages. You can create and maintain any number of packages for different purposes.

Specific CentraSite functions allow you to handle all members of a package in a single operation. For example, when you export a package, all of its members are exported.

7.7 Change Notification CentraSite provides features and functions for notifying you about changes to registry objects: You can register notification requests for any number of registry objects. Whenever such an object changes, you are notified accordingly.

CentraSite distinguishes between passive and active notifications.

• Passive notifications: When a registry object for which you have registered a notification request changes, a corresponding alert is set and displayed in your personal list of notifications.

• Active notifications: You can mark notification requests for registry objects as 'active'. CentraSite offers functions for retrieving the users who have registered active notification requests for specific objects. Such functions can be used, for example, to send an email to all these users.


7.8 Registry Federations CentraSite provides support for federated registries. The registries participating in a federation can be different CentraSite registries as well as any UDDI-compliant registries.

Federation support in CentraSite is based on the replication of registry objects: From any CentraSite or UDDI registry, you can obtain read-only copies of registry objects you are interested in and store them in the CentraSite registry where you intend to access and navigate them. You can specify exactly which objects you want to copy and include or exclude related objects.

You can access, browse and display the copies like any other objects in your registry and even link them to other objects by associations. Changes and write operations are forbidden.

Synchronization mechanisms ensure that your copies are always kept up-to-date as the original objects may undergo changes in their registry. If you no longer need access to the objects, you can delete the copies from your registry and remove the connection to their original registry.

Federation in CentraSite is based on mediators which perform the data transfer and synchronization between the registries. For each type of registry (CentraSite, UDDI), a specific type of mediator is used. Additional mediators can be implemented as required.

7.9 System Integration CentraSite provides interfaces which follow common standards and thus allow for easy and seamless integration with your SOA environment:

• Java API: The Java API of CentraSite is fully compliant with JAXR, the Java API for XML registries.

• UDDI interface: With its UDDI interface, CentraSite can be accessed and used like any standard UDDI registry. In this release, CentraSite supports UDDI Version 2.

For more details on JAXR and UDDI, refer to their official documentation, for example, in the Internet.

7.10 Security and Access Control CentraSite is governed by the security and access control mechanisms based on user roles and authorities, which are common to all Interstage ASM components. These mechanisms are described in detail in Section 9.4.

Roles and their authority and user assignments are defined globally for a CentraSite registry and repository.


8 Common Components The common components of Interstage ASM provide basic and integrative features for all the other components and tools. The following sections provide an overview and describe basic concepts of these common components:

• Control Center (COC)

• Repositories

8.1 Control Center (COC) COC provides central access and common features for the Interstage ASM components. References and access data for any number of Interstage ASM systems as well as other systems (e.g. file systems, source code control systems) can be stored and maintained in a central repository, enabling direct access to these systems. You can structure the data, describe them by properties and maintain your personal favorite lists. In COC, you define the categories which are to be used in other Interstage ASM components. Furthermore, COC enables full-text search across different SCM projects and DMS libraries.

The data created and managed with COC is stored in a repository. Users can access the data using the client interface. For more details on the Interstage ASM products, components, interfaces and usage scenarios, see Chapter 1.

The following sections provide an overview of the features and services of COC and introduce basic concepts.

System Integration COC provides direct access to any LCM applications and services, SCM projects, DMS libraries, SCA cubes, QAM assessments and CentraSite registries from a common and uniform user interface. Additionally, external systems, for example, Web sites, file systems or source code management systems, can be linked to and accessed from COC.

Integration is done by creating links to all of the systems in question in COC. The links can be organized and structured in folders as required.


Main folder for SCA cube links

Main folder for SCM project links

Main folder for DMS library links

Main folder for external links

Main folder for CentraSite registry links

Main folder for QAM assessment links

Main folder for LCM service and application links

You can create any number of links of the following types:

• QAM assessment links: A QAM assessment link relates to a quality assessment defined in QAM.

• SCA cube links: An SCA cube link relates to an item that represents a cube managed with SCA.

• SCM project links: An SCM project link relates to an SCM project, release or configuration. You can create project links to different releases and configurations of the same project and of different projects.

• LCM application and service links: An application or service link relates to an application or service managed in LCM.

• DMS library links: A DMS library link relates to a specific DMS library.

• External links: An external link can relate to any external system or file that is addressable by a URL. For example, external links can address folders in a file system, Web pages, WebDAV documents and collections, or incidents in Bugzilla.

• CentraSite registry links: A CentraSite registry link relates to an object in a CentraSite registry.


From the links and the main folders (e.g. SCA Cubes), you can open the corresponding perspectives of the client interface and immediately start working on the items referenced by the links. For example, from an SCM project link, you can open the Interstage SCM perspective. The SCM project referenced by the link is selected in the navigator, and you can immediately navigate and manipulate its resources. From an external link, you can open your Web browser with the respective URL.

Links and folders can be created, modified, copied, moved and deleted at any time.

Personal Favorites Each user can create and maintain a list of links to his/her favorite systems. This is particularly useful when many systems are integrated in COC, but the user needs access to only some of them.

In addition, COC allows you to easily open your personal list of activities in LCM.

Search Across Systems From COC, you can execute searches across multiple SCM projects and DMS libraries. You can search for documents, files and folders by name, contents (full-text search), properties (e.g. date of last modification, committing user), and categories.

Categories Categories help you organize and administer applications, services, requirements, change requests and releases in LCM, documents in DMS, and analysis results in SCA. For example, when you search for DMS documents, you can use categories as search criteria. In LCM, you can specify categories as filters for applications, services, requirements, change requests and releases displayed at the client interface.

Categories are defined in COC and stored in the COC repository. The categories are organized in the following taxonomies: 'DMS Categories, 'SCA Categories' and 'LCM Categories'. The taxonomy determines for which items the categories defined in it are available: The categories in 'DMS Categories' are available in DMS, the ones in 'SCA Categories' in SCA, and the ones in 'LCM Categories' in LCM.

In each of the taxonomies, you can define any number of categories. Each category in turn can have any number of subcategories.

The following illustration shows the defined taxonomies with sample categories.


Security and Access Control COC is governed by the security and access control mechanisms based on user roles and authorities, which are common to all Interstage ASM components. These mechanisms are described in detail in Section 9.4.

Roles and their authority and user assignments are defined globally for a COC repository. The COC roles and authorities determine which users are allowed to create and maintain categories and links to different systems. Access to the systems as such is controlled by these systems' own mechanisms, i.e. the access control mechanisms of LCM, SCM, DMS, SCA, QAM, CentraSite or external systems.

8.2 Repositories Enabler is the repository management system at the heart of Interstage ASM. It provides the foundation for the integrated storage and management of data, flexible and high-performance access to this data by users and applications, and team coordination. All Interstage ASM components store their data in one or more Enabler repositories.

Distribution of Information You can use one repository for managing all your data. However, you will usually distribute the information to several repositories, particularly when many users and large amounts of data are involved. A typical Interstage ASM installation could use repositories as follows:

• One or more repositories for hosting software development projects and document libraries managed with SCM and DMS, depending on the number of projects and libraries, the amount of data and the number of users.

• One repository for SOA asset management with CentraSite.

• One repository for LCM, SCA, QAM and COC. Since the amount of data created and maintained with these components is not very high, one repository is usually sufficient. However, you may just as well use different repositories, for example, for different departments or components.


Repository Access and Administration Users of Interstage ASM access repositories and the data they contain solely via the Interstage ASM interfaces. They do not need to care about the repositories as such or about how and where their data is stored.

The Interstage ASM components offer basic options for creating and starting repositories. For maintaining repositories, system administrators can use the Enabler administration tools, which are included in Interstage ASM.


9 Common Features All of the Interstage ASM components have the following features in common:

• Audit logging

• Reporting

• Single sign-on

• Security and access control

• Customization and extension

The following sections provide an overview of these common features.

9.1 Audit Logging All Interstage ASM components record any actions carried out in a log. The log consists of several log files which are stored in the relevant repositories.

The log files as well as different reports based on them can be used for auditing purposes. They allow you to retrieve detailed information on your data, to control the changes carried out, and even to check for unauthorized access.

Reorganization functions are available that allow you to remove obsolete entries from the log files, for example, to reduce disk space usage.

9.2 Reporting All Interstage ASM components offer comprehensive reports for different purposes and at different levels of detail. They allow you to retrieve information of any nature on the items stored in your repositories.

Reports can be output in different formats, for example, XML, HTML or CSV, and you can customize them as required.

9.3 Single Sign-On Interstage ASM supports single sign-on for all of its components at the client interface. This means that you log on once and then can work with any of the tools and repositories to which you are granted access.

User authentication can be configured to an Active Directory or LDAP server, or to user and password files created specifically for Interstage ASM. Users and user groups are managed at the operating system level as usual, for example, in the Active Directory or LDAP server, and there is no need to duplicate them to Interstage ASM.


9.4 Security and Access Control Interstage ASM includes a sophisticated access concept that allows you to define exactly which users can work on specific data and which actions these users can carry out.

The Interstage ASM access concept is based on user roles and authorities that control the execution of specific actions. Individual components of Interstage ASM provide additional security mechanisms involving access rights, locks or other protections set on specific items. For details on these specifics, refer to the corresponding chapters of this manual.

The following illustration provides an overview of the basic access concept of Interstage ASM:

User AuthoritiesRolehas defines a

set of

An authority is the right to execute a single Interstage ASM action. A role defines a set of authorities. By assigning one or more roles to a user, the user is granted the permission to execute the actions defined by the authorities which are included in the roles. The user is prevented from executing actions for which the roles do not contain the corresponding authorities.

Authorities can have a so-called permission type, which expresses for what type of action they are valid. Interstage ASM distinguishes between the following basic action and permission types: Create, Delete, Read, Write. In addition, there are the PrivilegedRead and PrivilegedWrite permission types, which represent special privileges for read or write operations. For example, in LCM you usually need to be the responsible user of an item in order to work on it. This check is by-passed for users with an appropriate PrivilegedWrite authority.

All Interstage ASM components come with predefined sets of roles and authorities. You can change the predefined roles by adding or removing authorities, delete existing roles and add roles of your own. Some of the Interstage ASM components even allow you to define and use your own authorities.

Users can be assigned different roles in each of the Interstage ASM components. To simplify the management of huge numbers of users, you can specify a default role in each component, which is assigned automatically to all users who are not given a role explicitly.

Roles and their authority and user assignments are stored in the same repository as the data of the Interstage ASM components they apply to. The management of roles is facilitated by export, import and copy mechanisms, which allow you, for example, to transfer roles from one repository or project to another.


9.5 Customization and Extension Interstage ASM is extremely flexible and customizable. Its components provide you with various options to configure and adapt their behavior, functionality and user interfaces to suit your needs.

Additionally, you can extend the functionality of Interstage ASM components with your own customized methods, which make use of the Interstage ASM Java API. This also allows you to integrate Interstage ASM with other systems.

The customization and extension options of Interstage ASM are described in detail in the Interstage ASM Customization Guide.


Glossary

Access Group

A group of users who are allowed to work on an SCM repository, project or product or a DMS repository or document library.

Access Right

The right a user has to an item. The following types of access rights are distinguished: read, write, owner.

Application

A collection of software, procedures and documentation which perform productive tasks for users.

Authority

The permission to execute a single action. Authorities are assigned to roles.

Branch

A development line in an SCM project. Any number of branches can be created based on the same snapshot allowing users to work in parallel on different versions and variants of the same software.

Change Request

A call for a specific adjustment of a service or application, for example, a request to fix a bug in a component of a software product or to modify a specific behavior of a service.

Configuration

A set of resource versions in an SCM project that are managed together. A configuration contains exactly one version of a resource. A specific resource version can be a member of several configurations.

DMS Library

See Document Library.


Document

A file in DMS.

Document Library

A structured collection of documents managed in DMS.

Eclipse

An open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software. For details, refer to http://www.eclipse.org/.

Indicator

A value that is derived from one or more metric values in a well-defined matter and describes the quality of source code.

JAXR – Java API for XML Registries

A standard API for Java platform applications to access and programmatically interact with various kinds of XML-based metadata registries.

Library Edition

A structured collection of document versions in DMS which cannot be changed. An edition serves to save a specific status of a document library. It corresponds to a snapshot in SCM.

Lifecycle

A description of the evolution of entities. A lifecycle defines stages or states that entities may go through as well as transitions between them.

OLAP – Online Analytical Processing

An approach to quickly provide answers to analytical queries that are multidimensional in nature. The core of any OLAP system is an OLAP cube (also called a multidimensional cube or a hypercube).

Process

A set of linked activities that take an input and transform it to create an output.


http://www.eclipse.org/

Product

A collection of releases of different projects in SCM, which can be managed together.

Registry

A collection of object structures which represent SOA assets in CentraSite.

Release

In SCM, a collection of configurations which represents a specific version, variant or edition of a project. Each SCM project has at least one release.

In RLM, an initial or upgraded version of an application or service including all artifacts which make it complete and functional.

Repository

A logical unit for storing and managing entities as well as the underlying data model. A repository is based on an Enabler datastore, which forms the physical storage unit.

In CentraSite, the term repository is used for a structure of folders and files which describe SOA assets.

Requirement

A documented need of what a particular service or application should be or do in order for it to be of value or use to a stakeholder.

Resource

A folder or file in SCM.

Role

A collection of authorities that control which actions can be carried out by a user to whom the role is assigned.

SCA Cube

An OLAP cube which is the result of a source code scan and the base for source code analyses in SCA and quality assessments in QAM. An SCA cube includes entities that represent source code elements (e.g. programs, variables, statements) as well as their interrelationships.



SCM Project

A structured collection of resources that make up a software product or component managed in SCM. An SCM project has at least one release and one configuration.

Service

A discretely defined set of contiguous or autonomous business or technical functionality, for example, an infrastructure or Web service.

Snapshot

A protected configuration in SCM whose existing assignments of resource versions cannot be changed. A snapshot serves to save a specific status of an SCM project.

SOA – Service-Oriented Architecture

A software architecture that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes regardless of the operating systems or programming languages underlying those applications.

State

An individual stage of the lifecycle through which configurations pass in SCM.

UDDI – Universal Description, Discovery and Integration

An OASIS standard for Web-based registries that expose information about a business or other entity and their technical interfaces.

Version

An instance of an item serving to record a particular stage in the history of the item.

WebDAV

Web-based Distributed Authoring and Versioning. A set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote Web servers.