Software Configuration Management

Chetak Baliga, February 5th, 2001

ABSTRACT

This paper also includes a sample plan for setting up a SCM system as well as some of the metrics for which the configuration manager might want to keep records.

• Introduction
  
  
• The Importance of SCM to an Organization
  
  
• The Four Areas of Software Configuration
  
  
  • Configuration Identification
    
    
  • Change Control
    
    
  • Configuration Accounting Status
    
    
  • Audits and Reviews
    
    
  • Relationship of the Four Areas
    
    
• Automation and SCM



• Why Automation?
  
  
• Tools for SCM
  
  
• Challenges for SCM



• Remote and Distributed Development
  
  
• Multiple Versions
  
  
• Setting up a SCM System



• SCM Set Up Plan
  
  
• Metrics
  
  


• Conclusion
  
  
• References
  

Software configuration management is one of the foundations of software engineering. It is used to track and manage the emerging product and its versions. This is to assure quality of the product during development, and operational maintenance of the product. SCM ensures that all people involved in the software process know what is being designed, developed, built, tested, and delivered. Through SCM the design requirements can be traced to the final software product. Software configuration management prevents the software process from becoming unmanageable by controlling change and maintaining system integrity. It identifies and controls the configuration of software, hardware,and the tools that are used throughout the development cycle.

Table of Contents

All organizations exercise some form of software configuration management, though many would not recognize it as such. It can be a simple as the single programmer that keeps track of the programs progress, errors, and requirements in his head to the large software company that uses strict software configuration management practices during development.

As programs have become larger and more complex since the 1960's the development of SCM techniques has become more important. Developers need SCM to improve productivity, reduce cost and to keep the project progressing to completion. It becomes even more important when software is developed by outsourcing and by distributed development. SCM gives the developers a means to coordinate the work of numerous people on a common product whether they work in close proximity or over a wide geographical area. Without a good software configuration management plan projects can, and will, become increasingly difficult to control and can reach the point where the project has to be discontinued because it cannot be fixed.

Table of Contents

SCM responsibilities are also identified. Defining responsibility can be handled several ways. A single configuration manager can be responsible for the entire SCM. Or individuals can given ownership of modules for the life of the project, and they then control all changes to the modules. On large projects a change control board, with several appointees, may be appointed to oversee changes. If the project is large enough there may be several CCBs.

The SCI that are identified determine the baseline(s) that is associated with the project. The number and types of baselines will depend upon the project. Baselines are the core of SCM they provide a stable platform for work to continue from. Only authorized changes can be made to the baseline, and all changes are recorded as deltas until such time as a new baseline is generated.

Figure 1 is an example of a baseline scheme.(Pressman, 1997)

Figure 1

Once the form is submitted to the change control authority (CCA) it is then examined for validity, the impact of the change and the cost. The change is then approved, or disapproved by the CCA. If it is approved it is applied to the software and regression testing is done to be sure that the change has not effected other parts of the system.

Records are kept of all changes approved and disapproved. This allows for history reports to be generated when required.

Table of Contents

The configuration status accounting database holds the records showing the products history, how the product has evolved, and where the system is at anytime in relation to the current baseline. Administration uses status accounting to track and report on all SCIs formally identified and controlled. The status accounting database also maintains records to support SCM auditing.

Due to the large amount of complex data that status accounting tracks it is generally supported by automated processes.

The generating of status accounting reports makes it possible for management and the developers to appraise changes to the system. The reports allow people to better communicate by letting them see what others have done and how things have changed in the system.

Table of Contents

The formal review looks at the technical correctness of any software configuration item(SCI) that has been modified. An SCI is looked at to determine any omissions, potential side effects, and its consistency with other SCIs. Formal reviews are conducted for all but the most trivial changes.(Pressman, 1997)

The audit completes the technical review by looking at the SCI for characteristics that generally are not considered during the review. Some of these characteristics are: has the formal review been done, have all software engineering standards been followed, and have the changes been noted, dated, and author specified?

Auditing gives us a picture of how close the current software system mirrors the software system pictured in the baseline, and the requirements document. Auditing provides the mechanism for establishing a new baseline. The final stages of an audit are used to sanction the new baseline.(Bersoff, 1988) Verifying and validating any changes that have occurred ensures that a perspective baseline is consistent with the previous baseline. Baseline auditing and sanctioning is one of the major ways we assure product integrity in computer systems and software development.(Ratcliff, 1987)

Auditing increases software visibility and establishes traceability. It helps to avoid costly redesign and refits. The developers and the customer are able to use the audits to agree on what has been designed and built.

Table of Contents

Table of Contents

Why Automation?

Table of Contents

An important tool for software configuration management is a database management system with a data dictionary. Such a system can be used throughout the projects life-cycles, and helps maintain consistency and integrity between the configuration items in the project. Tools such as ECLIPSE's "Object Management System" OMS maintain object hierarchies and record changes and transformation to the objects in the system. OMS provides traceability of SCIs throughout their life-cycles. Tools such as OMS are used for the entire life-cycle.(Ratcliff, 1987)

Tools have also been developed to support specific parts of the development process. Such tools include version trackers, consistency controllers, and build tools.

Version trackers are used to maintain records of revisions that are made to source code modules. When new releases, or versions, are generated the new version can be tested and compared against past versions, and reconstituted whenever necessary. This gives the project a history of its source code. Many version trackers, like CVS (Control Version System), only save the differences between the code, and not the entire code for each version, to save storage space.(Configuration Management Yellow Pages)

Consistency controllers are used to ensure that the object code corresponds to the source code. The dependencies amongst files are recorded so that when the source code is changed the corresponding object code is recreated. These tools complement the version control tools.

Build tools are used to set the dependencies between components. They dictate how the project is built from the components. The are a form of 'make files'. Build tools help to maintain consistency when components are being linked together.

A project may have a system library. This is a repository for all documents, code, changes, development tools, tests and results, and versions of the project. It uses security measures to prevent unauthorized changes. It provides many, or all, of the functions described in the tools above. It also archives all the information that is important to the project. This data can then be used after the project is finished to do a post analysis of the project.

Once the tools have been selected the automation process should be introduced to the organization in a non-intrusive manner. The tools should not be a burden for the developers to use.

Table of Contents

Remote and Distributed Development

For networked or geographically remote systems a central repository is used to hold all source code. Security must be in place to allow access to authorized users only. Procedures must be in place to handle the check in/ check out for files. A CM tool can be used that will handle the files and the security details.

There are four variations for handling a mixed platform network.(Topics on Software Configuration)

1. There is no client SCM tool and no NFS (Network File System) - The developers must telnet to the central repository and then use FTP to move the files back and forth.
   
2. There is no client SCM tool but there is NFS- The developers still log into the repository host, but now they have access to the files without copying them back and forth. This system is used when the CM tool you are using doesn't support all of the platforms you are using.
   
3. There is a client tool but no NFS - the CM tool must find its way to the files in the repository without sharing the repositories file system. Because it does not use NFS it isn't limited to NFS environments.
4. There is a client tool and there is NFS - This is the best system. The CM is transparent to the users. The users check out, work on, and check in files as though they were on a local disk. There are a number of commercial tools for doing this.
   
5. NOTE: Since there are few tools that can work on all platforms the system must be set up for the features and platforms that you want to support.
   

Subcontractor control must be provided for at the beginning of the software project. The subcontractors must be able to meet the specifications that are supplied to them from the prime developer. The amount of control that is given to the development subcontractors can vary. These can include:(Marciniak, 1994)

1. Authority to design, develop, build, test and deliver specified SCIs.
   
2. Limited design authority for modifying code or performing coding and unit testing.
   
3. No design responsibility.

Table of Contents

Whenever a change is requested all versions must be examined to see how the change effects them. Therefore it is necessary to keep records on:

• How many versions are there?
  
• When was each version created?
  
• What hardware and operating system configuration is needed to run that version?
  
• Each version must have records of all documentation, test data, users manuals, etc. pertinant to it.
  
• If a particular version is changed how many other versions are effected by the change?
  
• Which customers have which version?
  

Keeping track of all the versions and all of their related documentation requires a lot of resources. There are several tools available that help to simplify the process. (See Tools for SCM)

Table of Contents

SCM Set Up Plan

• Scope and purpose
  
• Organization and resources
  
• CM activities for:
  
  • Identification
    
  • Change Control
    
  • Accounting Status
    
  • Audits
    
  
  
• Interface Control
  
• CM's milestones and schedules
  
• Notes and appendices (Marciniak, 1994)
  

Organization and resources --To set up a software configuration management plan the configuration manager must be familiar with the needs of the organization. The size of the project and the resources allocated to it will govern how extensive the SCM plan will be.

CM activities -- Identify all documents and software configuration items (SCI) that will be under SCM control such as: project plans, specifications, designs, programs, tools, and test suites. (For more information follow the links above). Define a document naming scheme and show interrelations between SCIs. Delegate and define responsibility for change control. Draw up procedures for change control, system building, and version management.

Interface control -- Specifies how the interface documents (interface between computers) will be will be reviewed and released to configuration control.

CM's milestones and schedules -- Tracks the progress of the configuration mangement plan.

When the plan is complete it should guarantee traceability and integrity, and protect the baseline throughout the life cycle of the project.

Table of Contents

• Number of total changes completed
  
• Number of change requests outstanding
  
• Number of change requests rejected
  
• Current number of versions
  
• Modification history for SCIs
  
  • Identy of the SCI
    
  • Author
    
  • Creation date
    
  • Date of modification
    
  • Modifications done
    
  • Modifier's name
    
  • Reason for change
    
• All test data
  
• Current status of bugs (See figure 2). By examining the data shown in figure 2 we can see the number of bugs that are opened, resolved, fixed or active.(Cusumano, 1997)
  

The SCM plan should be flexible enough to allow for modifications throughout the life cycle of the project. SCM requires a lot of effort and resources but the results are worth it. It prevents having to reimplement code that may be lost when two, or more, developers work on the same code. And it helps to trace and identify changes that took place during development.

Table of Contents

• [1] Humphrey, W.S., Managing the Software Process, Addison-Wesley, 1990
• [2] Pressman, R.S., Software Engineering: A practioner's Approach 4th Edition, McGraw-Hill 1997
• [3] Johnson, J., Skoglund R., Wisniewski J., Program Smarter Not Harder, McGraw-Hill, 1995
• [4] Ratcliff, B., Software Engineering: Principles and Methods, Blackwell Scientific Publications, 1987
• [5] Sommerville, I., Software Engineering 4th Edition, Addison-Wesley, 1992
• [6] Bersoff, E.H., Elements of Software Configuration Management, IEEE Publication, 1988
• [7] Ghezzi, C., Jazayeri, M., Mandioli, D., Fundamentals of Software Engineering, Prentice-Hall, 1991
• [8] Editor; Marciniak, J.J., Encyclopedia of Software Engineering, John Wiley and Sons, 1994
• [9] Cusumano, M.A., Selby, R.W., How Microsoft Builds Software, Communications of the ACM, June 1997/Vol. 40, No. 6