3. Traditional Software Configuration Management Process

Traditional SCM process is looked upon as the best fit solution to handling changes in software projects. Traditional SCM process identifies the functional and physical attributes of a software at various points in time and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle.

The SCM process further defines the need to trace the changes and the ability to verify that the final delivered software has all the planned enhancements that are supposed to be part of the release.

The traditional SCM identifies four procedures that must be defined for each software project to ensure a good SCM process is implemented. They are

Most of this section will cover traditional SCM theory. Do not consider this as boring subject since this section defines and explains the terms that will be used throughout this document.

3.1. Configuration Identification

Software is usually made up of several programs. Each program, its related documentation and data can be called as a "configurable item"(CI). The number of CI in any software project and the grouping of artifacts that make up a CI is a decision made of the project. The end product is made up of a bunch of CIs.

The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the software development life cycle. Each new baseline is the sum total of an older baseline plus a series of approved changes made on the CI

A baseline is considered to have the following attributes

  1. Functionally complete

    A baseline will have a defined functionality. The features and functions of this particular baseline will be documented and available for reference. Thus the capabilities of the software at a particular baseline is well known.

  2. Known Quality

    The quality of a baseline will be well defined. i.e. all known bugs will be documented and the software will have undergone a complete round of testing before being put define as the baseline.

  3. Immutable and completely recreatable

    A baseline, once defined, cannot be changed. The list of the CIs and their versions are set in stone. Also, all the CIs will be under version control so the baseline can be recreated at any point in time.

3.2. Configuration Control

The process of deciding, co-ordinating the approved changes for the proposed CIs and implementing the changes on the appropriate baseline is called Configuration control.

It should be kept in mind that configuration control only addresses the process after changes are approved. The act of evaluating and approving changes to software comes under the purview of an entirely different process called change control.

3.3. Configuration Status Accounting

Configuration status accounting is the bookkeeping process of each release. This procedure involves tracking what is in each version of software and the changes that lead to this version.

Configuration status accounting keeps a record of all the changes made to the previous baseline to reach the new baseline.

3.4. Configuration Authentication

Configuration authentication (CA) is the process of assuring that the new baseline has all the planned and approved changes incorporated. The process involves verifying that all the functional aspects of the software is complete and also the completeness of the delivery in terms of the right programs, documentation and data are being delivered.

The configuration authentication is an audit performed on the delivery before it is opened to the entire world.

3.5. Tools that aid Software Configuration Management

Free Software Tools TODO: need some writeup here on each tool. Free software tools that help in SCM are

  1. Concurrent Versions System (CVS)

  2. Revision Control System (RCS)

  3. Source Code Control System (SCCS)

Commercial Tools

  1. Rational ClearCase

  2. PVCS

  3. Microsoft Visual SourceSafe

3.6. SCM and SEI Capability Maturity Model

The Capability Maturity Model defined by the Software Engineering Institute (SEI) for Software describes the principles and practices to achieve a certain level of software process maturity. The model is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is designed towards organizations in improving their software processes for building better software faster and at a lower cost.

The Software Engineering Institute (SEI) defines five levels of maturity of a software development process. They are denoted pictorially below.

Associated with each level from level two onwards are key areas which an organization is required to focus on to move on to the next level. Such focus areas are called as Key Process Areas (KPA) in CMM parlance. As part of level 2 maturity, one of the KPAs that has been identified is SCM.

Thus any project that has a good SCM process can be leveraged as satisfying one of the KPAs of CMM. We will cover this in more detail in the section on using SCM to leverage Open Source Projects (See Section 4.2)