Configuration Management, Software Project Management

Configuration Management Dibyesh Giri Nepal

Configuration Management Configuration Management is the process which controls the changes made to a system and manages the different versions of the evolving software product. Configuration management involves the development and application of procedures and standards for managing an evolving system and releasing them to customers. Procedures should be developed for building systems and releasing them to customers. Standards should be developed for recording and processing proposed system changes and identifying and storing different versions of the system. CM may be part of a more general software quality management process. In some organizations, the same manager may share quality management and configuration management responsibilities.

Configuration Management • • • •

Software may be released by the developers to a quality assurance team who are responsible for checking that the system is of acceptable quality. It is then passed to the configuration management team who become responsible for controlling changes to the software. Controlled systems are sometimes called baselines as they are a starting point for controlled evolution. Reasons why systems exist in different configurations. 1. For different computers. 2. For different operating systems. 3. Incorporating client-specific functions, etc.

Configuration Management • Configuration managers are responsible for keeping track of the differences between software versions and for ensuring that new versions are derived in a controlled way. • Configuration managers are responsible for ensuring that these new versions are released to the correct customers at appropriate time. • The configuration management process and associated documentation should be based on a set of standards. Within an organization, these standards should be published in a configuration management handbook or as part of a quality handbook. e.g. IEEE standard 8281983, which is a standard for configuration management plans.

Configuration Management Mainframe Version

PC Version DEC-Digital Electronic Configuration

Initial System

VMS Version

DEC Version

Workstation Version Unix Version

Sun Version

Configuration Management – CM Planning • CM takes over control of systems after they have been developed. • Planning CM process must start during system development. • A CM plan should be developed as part of the overall project planning process.

Configuration Management – CM Planning The CM plan should include at least the following information: • • • • • •

The definition of what entities are to be managed and a formal scheme for identifying these entities. A statement of who takes responsibility for the configuration management procedures and for submitting controlled entities to the configuration management team. The configuration management policies which are used for change control and version management. A description of the records of the configuration management process which should be maintained. A description of the tools to be used for configuration management and the process to be applied when using these tools. A definition of the configuration database which will be used to record configuration information.

Configuration Management – CM Planning An important part of the CM plan is the definition of responsibilities. It should define who is responsible for the delivery of each document or software component to quality assurance and configuration management. It may also define the reviewers of each document. The person responsible for document delivery need not be the same as the person responsible for producing the document. To simplify interfaces, it is often convenient to make project managers or team leaders responsible for all of the documents produced by their team.

Configuration Management – CM Planning •

• • • • •

Configuration Item identification In the course of developing a large software system, thousands of documents are produced. Many of these are technical working documents which present a snapshot of ideas for further development These documents are subject to frequent and regular change. A key task of the configuration management planning process is to decide exactly which items ( or classes of item) are to be controlled. Documents or groups of related documents under configuration control are formal documents or configuration items Project plans, specifications, designs, programs and test data suits are normally maintained as configuration items. However, all documents which may be necessary for future system maintenance should be controlled.

Configuration Management – CM Planning • • • •

Configuration Item identification The document naming scheme must assign a unique name to all documents under configuration control. There will be relationship between documents. e.g. design documents will be associated with programs. These relationships can be recorded implicitly by organizing the naming scheme so that related documents have a common root to their name. This leads to hierarchical naming scheme.

Configuration Management – CM Planning Configuration Item identification Hierarchical naming Scheme: PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE PCL-TOOLS/EDIT/HELP/QUERY/HELPEFRAMES/FR-1 • These names have a number of components. The initial part of the name is the project name, PCL-TOOS. • There are four separate tools. PCL-TOOLS/COMPILE PCL-TOOLS/BIND PCL-TOOLS/EDIT PCL-TOOLS/MAKE-GEN • The problem with naming schemes of this sort is that they are project-based. • Components are identified as being associated with a particular project.

Configuration Management – CM Planning • • • •

The Configuration Database As part of the configuration management plan, a database schema to record configuration information should be defined. The configuration database is used to record all relevant information relating to configurations. Its principal functions are to assist with assessing the impact of system changes and to provide management information about the CM process. As well as defining the database schema, procedures for recording and retrieving project information must also be defined as part of the Configuration Management Planning Process.

Configuration Management – CM Planning The Configuration Database A configuration database must be able to provide answers to a variety of queries about system configurations. Typical queries might be:

3. 4. 5. 6. 7. 8.

Which customers have taken delivery of a particular version of the system? What hardware and operating system configuration is required to run a given system version? How many versions of a system have been created and what were their creation dates? What versions of a system might be affected if a particular component is changed? How many change requests are outstanding on a particular version? How many reported faults exist in a particular version?

Configuration Management – Change Management • Change is a fact of life for large Software System. • This requires corresponding changes to be made to the software. There is therefore a need for a system to ensure that changes are recorded and applied to the system in “a cost-effective” way. • Change management procedures should be designed to ensure that the costs and benefits of change are properly analyzed and that changes to a system are made in a controlled way. • Change management processes involve technical change analysis, cost-benefit analysis and change tracking. • The first stage in the change management process is to complete a Change Request Form (CRF). This is a formal document where the requester sets out the change required to the system.

Configuration Management – Change Management Change Request Form Project: Proteus/PCL-Tools Number:23/94 Change requester: I. RGP Date: 1/08/2007 Request change: When a component is selected from the structure, display the name of the file where it is stored. Change analyser: BNB Analysis date: 10/08/2007 Component affected: Display-Icon-Select, Display-Icon-Display Associated components: FileTable Change assessment: Relatively simple to implement as a file name table is available. Requires the design and implementation of a display field. No changes to associated components are required. Change priority: Low Change implementation: Estimated effort: 0.5 days Date of CCB: 15/08/2007 CCB decision date:02/09/2007(Change Control Board) CCB decision: Accept change, Change to be implemented in Release 2.1 Change Implementer: Date of change: Date submitted to QA: QA decision: Date submitted to CM: Comments

Configuration Management – Change Management • The CM team, rather than the system developers, is responsible for building a new version or release of the software. • Change requests are themselves configuration items. They should be registered in the configuration database. • As software components are changed, a record of the changes made to each component should be maintained. This is sometimes called the derivation history of a component. • The procedural nature of this process means that a change process model can be designed and integrated with a version management system. This model may then be interpreted so that the right documents are passed to the right people at the right time. e.g. Lifespan.

Configuration Management – Version and Release Management Version and release management are the processes of identifying and keeping track of different versions and release of a system. A system version is an instance of a system that differs, in some way, from other instances. New versions of the system may have different functionality, performance or may repair system faults. Some versions may be functionally equivalent but designed for different hardware or software configurations. If there are only small differences between versions, one of these is sometimes called a variant of the other.

Configuration Management – Version and Release Management A system release is a version that is distributed to customers. Each system release should either include new functionality or should be intended for a different hardware platform. Normally, there are more versions of a system than release. Some versions may never be released to customers. e.g. versions may be created within an organization for internal development or for testing.

Configuration Management – Version and Release Management A release is not just an executable program or set of programs. It usually also includes: • Configuration files defining how the release should be configured for particular installations. • Data files which are needed for successful system operation. • An installation program which is used to help install the system on target hardware. • Electronic and paper documentation describing the system.

Configuration Management – Version and Release Management All above information must be made available on some medium which can be read by customers for that software. For large systems, this may be magnetic tape. For smaller systems, floppy disks may be used. Increasingly, however, releases are distributed on CD-ROM disks because of their large storage capacity. When a system release is produced, it is important to record the versions of the operating system, libraries, compilers and other tools used to build the software. If it has to be rebuilt at some later date, it may be necessary to reproduce the exact platform configuration.

Configuration Management – Version and Release Management

Version Identification Identifying versions of a system appears to be straightforward. Linear Scheme – 1.0 subsequent 1.1,1.2,1.3,… At some stage it is decided to create release 2.0 and process starts again 2.1,2.2,2.3,… Version Management tools such as SCCS (Rochkind, 1975) support this approach to version identification.

Configuration Management – Version and Release Management Version Management Linear Scheme is simple but it has associated problems: • When should a new release (i.e. a new branch in the derivation graph) rather than a new version be created? •

•

If several versions are created from a single parent, how should be they numbered? e.g. say a system is intended to run on a number of different computer architectures. These are all derived from a single base release numbered 1.0. Should the versions be numbered 1.1, 1.2 and so on, implying sequential derivation?

If many versions of a system are created and distributed to different customers, should the version naming scheme include some customer identifier? Each customer or system user may have a unique version of the system. These identification problems arise because the naming scheme implies a linear derivation of versions whereas the actual logical derivation structure is a network structure.

Configuration Management – Version and Release Management Version Management An alternative to a numeric naming structure is to use a symbolic naming scheme. e.g. rather than refer to Version 1.1.2, a particular instance of a system might be referred to as V1/VMS/DBserver. This implies that this is of version of database server for a Digital computer running the VMS operating system. This has some advantages over the linear scheme but, again, it does not truly represent the derivation structure.

Configuration Management – Version and Release Management Version Management

V1.0

V1.1b

V1.1.1

V1.1

V1.2

V2.0

V2.1

V2.2

V1.1a

Version derivation structure

Configuration Management – Version and Release Management Version Management • Customer • Development language • Development status • Hardware platform • Creation date New system versions should always be created by the CM team rather than the system developers. System developers should not have write access to this database.

Configuration Management – Version and Release Management Release Management • New versions of a system may be created to fix reported faults or as part of the development process. • Creating a new system version involves creating new source code and building the system. • Creating a release, however, is more complex and expensive. As well as creating new source code and system building, data and configuration files may have to be prepared and new documentation written. The release must be packaged and distributed to customers.

Configuration Management – Version and Release Management Release Management Over the lifetime of a system, changes are likely to be proposed on a fairly regular basis. • Corrective changes are intended to fix faults. • Perfective changes are intended to implement new requirements. • Adaptive changes are intended to change the system to make it operate in a new environment. • The configuration manager must decide how often the components affected by these changes should be rebuilt into a new version or release of the system.

Configuration Management – Version and Release Management Release Management When a new release of a system is created, the changes which have been made may introduce new faults or bring other existing faults to light. The more changes to system, the more new faults will be introduced. If a release incorporates a large number of changes, it is likely that there will be a correspondingly a large number of new faults. These have to fixed in the next system release.

Configuration Management – Version and Release Management Release Management Lehman suggested that if a lot of new functionality was introduced in one release of a system, it would be necessary to issue another release fairly quickly. • This suggests that it is unwise to change too much of a system’s functionality at once. Otherwise an excessive number of faults may be introduced.

Configuration Management – Version and Release Management Release Management • A good change strategy is to interleave fault repair release immediately after the Enhanced release. • All serious faults (faults which cause system corruption) should be repaired before functional or behavioral changes are applied. Enhanced release

Repair release

Repair release

Figure – System Release Strategy

Enhanced release

Repair release

Configuration Management – Version and Release Management Version Management Tools Version management involves managing large amounts of information and ensuring that system changes are recorded and controlled. • There are several CASE tools available to support version management. • For UNIX platforms, the most widely used version management systems are SCCS (Rochkind, 1975) and RCS (Tichy,1985). • Version management system control a repository of configuration items where the contents of that repository are immutable (i.e. cannot be changed).

Configuration Management – Version and Release Management Version management tools All version management systems provide a comparable basic set of capabilities although some have more sophisticated facilities than others. Examples of the capabilities which may be included in a version management system are: 3. Version and release identification 4. Controlled change 5. Storage management 6. Change history recording

Configuration Management – CM Tools Configuration Management Tools • • • • • • • • •

VSS – Visual Source Safe for documents. VSTS - Visual Studio Team System VAJ - Visual Age for Java for source files. RCE – Revision Control Engine. Software Manager – Information from virtual sky. QVCS – Quma Version Control System. Source Code Manager. SCLM – Software Configuration Library Manager. CVS – Concurrent Version System.

Configuration Management – CM Tools VSS • VSS is used through out the life cycle. The purpose of this tool is identifying the configurable items in the project. Keep those in repository and maintain version controlling. • It is a Version control tool. • VSS is a virtual library of computer files. • VSS is a common repository • In VSS store the information like FRS, SRS, TP, Test cases documents • In VSS documents read only but not modifying • If we want to modify that first we need to check out (download) the required file to our local system then modify the file and then check in (upload) the modified one.

Configuration Management – CM Tools VSS • Virtual Source Safe... Visual SourceSafe (VSS) is a client/server application which acts as a storage system for files. • A file stored in a VSS server is not available via the standard file system, instead, it must be accessed through the VSS client tools Tool. • Mainly useful to developer, for storing code and maintains version copying a code from VSS By developers is called CHECK-IN Upload the code in to VSS is called CHECKOUT.

Configuration Management – CM Tools VSS-VSTS • Microsoft recently developed a team collaboration tool called "Visual Studio Team System" (VSTS). This tool allows source control management and several other software development management tools. • Microsoft will be promoting VSTS in future instead of VSS. However, next few years, VSS will still be the most popular source control system due to it's easy to use user interface, simple configurations and availability of experienced users. • Visual Source Safe is available as part of Visual Studio .NET products. • The following are the various versions currently in use by majority of the development teams: • Visual Source Safe 5.0 • Visual Source Safe 6.0 • Visual Source Safe 2005 Visual Source Safe 2005 is available as part of the Visual Studio 2005 suite of products.