Software Configuration Management

UNIT II

Topics to be Covered SCM Plan SCM Support Functions The Requirement Phase Design Control The Implementation Phase The Test Phase SCM for Tools Configuration Accounting The Software Configuration Audit

Contd., Control must be maintained over the following items Operational Concepts Requirements Specifications Design Documents Source Code Object Code Test Plans Test cases, test configurations, and test results Maintanance and development tools User Manuals Maintenance manulas Interface Control documents

Contd.,

Design Baselines are established at appropriate points, Requirement Baseline Specification Baselines Design Baselines Unit Baselines Integration Baseline (Component & System) Operational Baseline

Definitions

Baseline - The arrangement of related entities that make up a particularsoftware configuration. Any change made to a software system relates toa specific baseline. Baselines can be defined at each stage of the software life-cycle, for example functional baseline, design baseline, product baseline, etc.

Contd.,

Change - the act, process or result of being altered.

Change control - keeping track of the process of making a modification.

Configuration - A mode of arrangement, confirmation or outline; the relative position of the component parts of a system, for example the relative positions of the stars and planets in the solar system.

Contd.,

Configuration management - "The discipline of developing uniform descriptions of a complex product at discrete points in its life-cycle with a view to controlling systematically the manner in which the product evolves“

Software change control - keeping track of the process of making modifications to a software system.

Contd.,

Software configuration - The current state of the software system and the interrelationship between the constituent components. These would typically be the source code, the data files and the documentation.

Software configuration management - Configuration management related specifically to software systems.

Contd.,

Software documentation - the written record of facts about a software system recorded with the intent to convey purpose, content and clarity.

Variant - Source and object specialised to different platforms. For example, Microsoft Word for Windows for the PC and Microsoft Word for Windows for the Macintosh are variants of the same product.

Contd.,

Version - A version represents a small change to a software configuration. In software configuration management terms one refers to versions of a given baseline rather than dealing with a proliferation of baselines.

Version control - Keeping track of baselines, versions of baselines and the relationships between them.

Key points Configuration management activities fall into

four broad categories:1. The identification of the components and

changes;2. The control of the way the changes are made;3. Auditing the changes - making the current state

visible so that adherence to requirements can be assessed;

4. Status accounting - recording and documenting all the activities that have taken place.

Software Configuration Management Chapter 7: Software Configuration Management - Part 1 The most frustrating software problems are often caused by poor

software configuration management (SCM). For example, a bug fixed at one time reappears; a developed and tested feature is missing; or a fully tested program suddenly doesn’t work.

SCM helps to reduce these problems by coordinating the work products of many different people who work on a common project. With such control, can get problems such as;•Simultaneous update - When two or more programmers work separately on the same program, the last one to make changes can easily destroy the other work.

•Shared code - Often, when a bug is fixed in code shared by several programmers, some of them are not notified;

Contd.,

•Common code - In large systems, when common program functions are modified, all the users need to know.•Versions - Most large programs are developed in evolutionary releases. With one release in customer use, one in test, and a third in development, bug fixes must be propagated between them.

These problems stem from a lack of control. The key is to have a control system that answers the following questions:

•What is my current software configuration? •What is its status? •How do I control changes to my configuration? •How do I inform everyone else of my changes? •What changes have been made to my software? •Do anyone else’s changes affect my software?

SOFTWARE PRODUCT NOMENCLATURE

•System - The package of all the software that meet’s the user’s requirements.

•Subsystem - Comprise large systems, such as communications, display, and processing;

•Product - Components of subsystems, such as control program, compliers, and utilities of an operating system.

•Component - Components of a product, such as supervisor and scheduler of a control program.

•Module - Lowest level of components is modules. Typically implement individual functions that are relatively small and self-contained, such as queue management and interrupt dispatcher.

Contd., During implementation, two things are happening. First, the modules

are being developed, enhanced, tested, and repaired from detailed design and implementation through system test. Second, the modules are being assembled into components, products, subsystems, and systems. During this building process, the modules are consistently being changed to add functions or repair problems. This process is supported by a hierarchy of tests:

•Unit test - A separate test for each individual module; •Integration test - As the modules are integrated into components,

products, subsystems, and systems, their interfaces and interdependencies are tested to insure they are properly designed and implemented.

•Function test - When integration results in a functionally operable build, it is tested in a component test, product test, subsystem test, and finally in a system test;

Contd., •Regression test - At each integration test

(here called a spin), a new product is produced. This is the first tested to insure that it hasn’t regressed, or lost functions present in a previous build.

Once an initial product is stabilized, a first baseline is established. Each baseline is a permanent database, together with all the changes that produced it. Only tested code and approved changes are in the baseline, which is fully protected.

The key SCM tasks are: Configuration control Change management Revisions Deltas Conditional code.

CONFIGURATION CONTROL The task of configuration control revolves around one

official copy of the code. The simplest way to protect every system revision is to keep a separate official copy of each version.

Contd.,

However, when two or more groups work on separate copies of the same or similar versions of common code, they often make different changes to correct the same problem. A good rule of thumb is that no two separate copies of a program can be kept identical. If separate copies exist, they must be assumed to differ; even if they were the same, they will soon diverge.

Only keep one official copy of any code that is used by several groups. Working copies may occasionally be used, but a common library must be the official source for all this common code, and only officially approved changes can be permitted into this library.

Contd., REVISIONS Keep track of every change to every module and test case.

There is one latest official version and every prior version is identified and retained; these obsolete copies can be used to trace problems.

A numbering system must separately identify each test, module, component, product, and system.

VERSIONS Often, several different functions can be implemented by the

same module with only modest coding differences. For example, different memory management code may be needed to handle expansion beyond the standard 512K. Then, a different use a standard management module below 512K, and one using a mode switch beyond 512K.

Contd., Since these are different programs, they have different

designations, such as MEM and MEML. Each would have its own sequence of revisions and revision numbering schemes.

DELTAS Versions solves the problem of different functional needs

for the same module but introduces multiple copies of the same code. The reason is that most of the code in the two modules would be identical. One, however, may have an additional routine to handle memory limits testing and mode switching (in the case of the 512K memory limits problem). Since they are stored as separate modules, however, there is no way to make sure all changes made to one are incorporated into the other.

CONDITIONAL CODE Another way of handling slight variations between

modules is to use some form of conditional program construction. For example, a billing program might use different functions depending on the need for a state sales tax. The source program would contain various tax versions, but none would be included in the final system unless called for at system installation.

The use of conditional code simplifies code control because there is only one official copy of each module. The number of version combinations is also minimized.

Contd.,

There are disadvantages, however. The most important is that end users must specify all parameters and then perform a special and perhaps complex installation process. Also, thew system generation process becomes more complex with system growth.

Baselines

Baseline scope Baseline control Configuration Management Records

Baselines

Baseline is the official source for code and the repository for all completed work.

It is the official standard on which subsequent work is based on which only authorized changes or additions are made.

It contains all the project code, and each level is uniquely named so it can be distinguished from all others.

Baseline ScopeBASELINE SCOPE. Items to be included in the implementation phase are:

•The current level of each module, including source and object code•The current level of each test case, including source and object code•The current level of each assemble, compiler, editor, or other tool used•The current level of any special test or operational data•The current level of all macros, libraries, and files•The current level of any installation or operating procedures

•The current level of operating systems and hardware, if pertinent Retain every change, no matter how minor it seems.

BASELINE CONTROL

Controlled flexibility is accomplished by providing the programmers with private working copies of any part of the baseline. They can try new changes, conduct tests, etc. without disturbing anyone else. When ready, new changes can be incorporated into the baseline, after assuring the changes are compatible and no new code causes regressions.

Every proposed change must be tested against a trial version of the new baseline to make sure it does not invalidate any other changes.

CONFIGURATION MANAGEMENT RECORDS Every change proposal is documented and authorized

before being made. The documentation includes the reason for the change, the potential cost in time, the person responsible for the change, and the products affected.

Detailed records are especially crucial when hardware and software changes are made simultaneously. Just because the programs run doesn’t mean they will continue to run if hardware changes.

Should always have problem reports, which document every problem and the precise conditions that caused it.

The expect list details every function and planned feature for every component in each new baseline.

CONFIGURATION MANAGEMENT RESPONSIBILITIES

The configuration manager is the central control point for system changes and has the following responsibilities:

•Develop, document, and distribute the SCM procedures;•Establish the system baseline, including backup provisions;•Insure that no unauthorized changes are made to the baseline;•Insure that all baseline changes are recorded in sufficient detail so the can be reproduced or backed out;•Insure that all baseline changes are regression tested;•Provide the focal point for exception resolution.

Contd., MODULE OWNERSHIP To insure integrity of modules, each module should have

an owner. Of course, each person usually owns more than one module at a time.

The module owner’s responsibilities are:•Know and understand the module design;•Provide advice to anyone who works on or interfaces with the module;•Serve as a technical control point for all module modifications, including both enhancement and repair;•Insure module integrity by reviewing all changes and conducting periodic regression tests

Contd., Module ownership insures design continuity by

providing a single focus for all module changes. Its disadvantages are that it depends on the skill and availability of individuals and it only provides design control at the detailed level. These disadvantages can be countered by using a back-up “buddy” system between module owners and by maintaining an overall design responsibility to monitor and control the software structure, interfaces, macros, and conventions.

THE CHANGE CONTROL BOARD

On moderate through large projects, a change control board (CCB) (sometimes called the Configuration Control Board) is needed to insure every change is properly considered and coordinated.

Contd., The CCB should include some members from

development, documentation, test, assurance, maintenance, and release. The CCB reviews each request for change and approves it, disapproves it, or requests more information.

Depending on project size, several CCBs may be needed, each with expertise authority over a specific area. Some examples are: overall design and module interfaces, the control program, the applications component, user interfaces, and development tools. With multiple CCBs, a system-level CCS is needed to resolve disputes between these lower-level boards.

Contd., A CCB typically needs the following information on each proposed

change:•Size - How many new/changed LOC?•Alternatives - How else can it be done?•Complexity - Is the change within a single component or does it involve others?•Schedule - When?•Impact - What are future consequences?•Cost - What are potential costs and savings?•Relationship with other changes - Will another change supersede or invalidate this one, or does it depend on other changes?•Test - Are there special test requirements?•Resources - Are the needed people available to do the work?•System impact - What are the memory, performance

Contd.,•Benefits - What are the expected benefits?•Politics - Are there special considerations such as who is requesting the change or whom it will affect?•Change maturity - How long has the change been under consideration?If the change is to fix a customer-related problem, other information may be required:•A definition of the problem the change is intended to fix;•The conditions under which the problem was observed;•A copy of the trouble report;•A technical description of the problem;•The names of other programs affected.

CCB PROBLEMS

Do not waive a review just because change activity has become a bottleneck. It is precisely at the time of heaviest change and testing activity that loss of control is most likely and CCB review is most needed.

Select CCB members with care. They have the power to block any part of the project so these assignments should not be treated lightly. The project’s software development manager should personally chair the highest-level CCB.

THE NEED FOR AUTOMATED TOOLS

Without automated tools, changes can easily be lost or done without proper procedures.

SCM Plan The First step in establishing an SCM system is to develop

a Software Configuration Management Plan. This includes

- Objectives

- Responsibilities

- Approach and methods to be used

Sample SCMP Content

1. Overview

SCM Objective

System Overview

2. SCM Organization

SCM Responsibilities

Configuration Control Board Members

Configuration Control Board Charters

Product Assurance relationships

Contd.,3. SCM Methods

Baselines and contentsIdentification SystemControl systemAuditingStatus AccountingCM support tools

4. SCM ProceduresProcedures ManualForms and records

SCM Implementation

5. SCM Implementation

Personnel Plan

System support plan

Budget

Key Implementation Checkpoints

SCM Support Functions The following functions are required to provide adequate

support and effective control

- A protected baseline for the operational concept, specifications, design, implementation, test, and tools.

- A protected file with a description of all changes and revisions

- Means for each software engineer to read any unlocked element in the baseline

- A private workspace where charged-out designs or implementations can be modified

- Templates that assist in the preparation of new design, implementation, or test descriptions

Contd., A procedure for making approved charged-outs that permits saftware

engineers to obtain any available baseline element for their private workspace and lock out the SCM copy function to prevent anyone else from making simultaneous changes

A charge-in procedure that 1. Verifies that this is the person who charged-out the element2. Checks the format of the revision3. Checks that the revision has been authorized4. Enters a new revision description into the baseline5. Creates a change log6. Identifies changed items in the new revision7. Removes the lock

Contd., 8. For interface changes, obtains permission from participating module

owners before recording the revision A procedure for making approved deletions of defunct elements A way to collect, format, and produce consolidated system documents

containing the key element descriptions for any given baseline A way to check that all elements and relevant desctiptions have been

carried over between baselines A centralized data dictionary containing the official record of all named

items and their formats A where-used record of every use of every interface and data item in

the sytem.

The Requirement Phase

Requirement changes Requirement Baselines and change

control External Specifications

The Requirement Phase To ensure that the user’s needs are properly

understood before designing and implementing a system to meet them.

Gathering relevant information on the user’s needs and distilling the critical items.

Requirement Changes Requirement uncertainty is that the early design will likely

be changed many times. A premature requirement freeze will likely occur due to late

design decision which leads to ill-informed and excessive late changes.

If the requirement cannot be completely specified at the beginning of the project, they must be gradually evolved.

Throughout the requirement definition and feedback process, change is constant, and means are needed to control it.

A baseline will be established as a design foundation.

Requirements Baselines and change control Each change is submitted on a design change request

(DCR) form and reviewed, approved, and tracked with the same discipline as design and code changes.

The software configuration Identification(SCI) system uniquely identifies every project development item.

A simplified SCI tree is shown as follows

SCI Tree Structure

Design Control The CCB controls the design changes, and SCM maintains

complete records of every change and rationale. The SCI then connects each design element back to the

specifications.

Contd.,

Contd., The additional SCM facilities needed for detailed design are Templates for module specifications and design skeletons. Means to ensure, when a module contains multiple routines,

that a complete set of these routines is included in the baseline for each module.

Means to verify that all routines match the module interfaces Means to ensure that all data items are consistent with the

data dictionary Inclusion of all interfaces and data definitions in the where-

used listing.

Design Control

The Implementation Phase With a fully controlled design, implementation can start on

a solid foundation.

As implementation proceeds, design problems will be found and design changes will be needed, as a consequence design documentation is updated.

Contd., Some special SCM functions needing during

implementation phase are Source code charge-out and charge-in facilities Read-only access to specification and object code The ability to compile modules, to link them with baselined

object programs, and to use them in private workspaces A procedure for making approved changes to module

specifications. An SCM procedure to ensure that any new source code is

consistent with the module specification.

The Test Phase Once the program is put into baseline, all further changes must

be controlled. The major concerns are Problem incidents Temporary patches Permanent bug fixes and enhancements

In addition, precise and complete records must be maintained of every test run and test cases used, the configurations on which they were run, and the results.

In addition, it is essential to have a control system for tracking bug reports.

Contd., SCM should have the following capabilities Means for creating new bug reports, logging them, and

maintaining status records Means for closing bug reports Periodic reporting of bug status

Contd., Finally procedures are needed to handle the development of

simultaneous versions of the same program which requires A version description for each deliverable The capability to establish separate baselines for copies of

any given modules, as well as their source and object code A means to release baseline version with different design

descriptions or deltas Separate control over charge-out, charge-in, compile, link

and copy for each version The capability to selectively merge separate developmental

deltas into a common program version

SCM for Tools To maintain a standard tool set under configuration control

and to establish a new tool baseline whenever any change is made.

Different types of tool capabilities, and procedures for their use, support SCM activities. Depending on the situation, these tool capabilities can be made available with some combination of manual tools, automated tools providing a single SCM capability, automated tools integrating a range of SCM (and perhaps other) capabilities, or integrated tool environments which serve the needs of multiple participants in the software engineering process (for example, SCM, development, V&V).

Contd., Automated tool support becomes increasingly important,

and increasingly difficult to establish, as projects grow in size and as project environments become more complex. These tool capabilities provide support for:

the SCM Library the software change request (SCR) and approval procedures code (and related work products) and change management tasks reporting software configuration status and collecting SCM measurements software configuration auditing managing and tracking software documentation performing software builds managing and tracking software releases and their delivery

Contd.,

Configuration Accounting Software configuration accounting is the recording and

reporting of information needed for effective management of the software configuration.

To maintain a continuous record of the status of all baselined items. It also provides valuable insurance against disaster. The information required for comprehensive status accounting includes the time at which each baseline was established. When each software configuration item and change was included in the

baseline A description of each configuration item The status of each software-related engineering change

Contd., The description of each software change The status of each software change The documentation status for each baseline The changes planned for each identified future baseline

Contd., The general change requirement are A configuration item index that lists each configuration

item along with its creation date, current released version, and the versions of its component items

Change logs that show the history of the changes made to the source files, as well as their release histories

All discrepancy reports All change requests

The software configuration audit

To ensure that the SCM practices and procedures are rigorously followed.

Generally advisible to have SCM conduct frequent self-audits with an independent party occasionally performing spot checks.

The general ground rules for SCM audits are They are periodically needed to ensure the integrity of the

software baselines. A successful audit is performed before every major baseline

change

Contd., The audit team consists of qualified technical people who

are not involved in the specific tasks being audited. The audit verifies that changes to the baseline are

implemented as intended The auditing function is an integral part of the SCM system SCM auditing is continuous, with increased frequency and

depth as development progresses.

Contd.,

End of UNIT II