Configuration Management Document Page

Configuration Management

Traditionally, when working programmers hear the words "Configuration Management", they react negatively, like "run and run as fast as you can." It's true that CM can be perceived as slowing programming down, because it adds some extra steps to the daily programming process. These steps also take away some of the "shoot from the hip" facility that many good programmers are known for, and they naturally rebel against the imposed discipline, seeing it as a restrictive environment. If the project is small, with only one or two people working on an application, and if the application is not too involved, CM issues may never be a problem, even if no configuration management is applied. For example, think of the homework assignments you have done in previous classes.

On larger, longer projects that require more manpower, these CM issues become more important. The truth of the matter is, CM can save time in the long run, if a good plan is set up to begin with, and then followed throughout the development cycle. Often CM can facilitate recovery from mistakes, can provide insurance against "stepping on" each other's code, and can help in producing requirement verification and traceability to reassure the customer. If you have ever felt the frustration of working all night to get an algorithm to run, only to have it fail the next time you run it because someone changed the code (without your knowledge and without making a backup copy first), you can appreciate that CM will help to prevent that from happening. I'll tell you a story or three sometime…

The whole idea behind basic CM is that at periodic intervals, the source files are "frozen" so that no further changes to those versions can be made. From this point on, any changes to the code require making a working copy of the file (a process known as "checking out" the file), modifying the copy, then saving that file as the new version ("checking in" the file). This provides the traceability and recovery (called "roll-back") capability that can save your bacon. There are automated applications that will do this (and a lot more!) for you, but you can mimic their operation by a do-it-yourself plan that enforces the same discipline on the programming team.

The CMMI Standard Approach (For Comparison Only)

A typical standard CMMI-compliant Software Configuration Management Plan document consists of the following sections:

Scope
1. Identification
2. Introduction
3. Relationship to Other Plans
Referenced Documents
SwCM Management
1. Organization
2. SwCM Responsibilities
SwCM Activities
1. Configuration Identification
2. Configuration Control
  1. Document and Software Control
  2. Document and Software Release
  3. Labeling, Packaging, Storage, Handling, and Delivery
  4. Non-Deliverable Software and Documents
  5. Configuration Status Accounting
3. Interface Control
4. Subcontractor or COTS Software Control
SwCM Schedules
SwCM Personnel Resources
SwCM Software/Hardware Resources
SwCMP Maintenance
1. Acronyms

Outline of YOUR Deliverable

For your project, should you decide to implement a SCMP (even though you're not required to write one), you should decide on a configuration management method or a tool to use, then write up what you will do and how you will do it in your CM plan document. This CM plan section of your SDF will likely be a new document for you, since you may not have been required to produce such a thing for your CMSI 401 project.

For this document, you must identify the following items: the software configuration management process you will use for your project; how it will be used; and the baseline version(s) you expect to generate. If you will not be using a tool for CM, you should describe the methodology you will use to implement your CM plan in detail, including how you will configure your code, how you plan to maintain multiple versions, and how you will recover from errors or back out of changes when needed.

The document should have the following outline:

            7.0.      Introduction
            7.1       SwCM Activities
            7.1.1     Configuration Identification
            7.1.2     Configuration Control
            7.1.2.1   Document and Software Release
            7.1.2.2   Non-Deliverable Software
            7.2       SwCM Schedules
            7.3.      SwCM Software/Hardware Resources

The introduction should state, simply, something to the effect that "this is the configuration management plan for the <whatever_your_project_is> CSCI"; for example:

This Software Configuration Management (SCM) Plan (SwCMP or SCMP) describes the Software Configuration Management (SwCM) organization and practices that are applied consistently and uniformly throughout the life cycle of the <whatever_your_project_is> Computer Software Configuration Item (CSCI). SwCM is the process used during software development and maintenance to identify, control, report and audit configured software products. All activities identified in this SCMP are performed by <your name here>.

Section 7.1 is a paragraph which talks about the activities for which this plan has the details. For example:

Since this is a single-person development effort, the programmer is responsible for determining the CSCIs. CSCIs are placed under configuration management in accordance with this plan. Each CSCI and/or releasable software work product, including associated support software required for development, test or maintenance of the CSCI, are identified with unique names, acronyms, and numbers.

For a list of software configuration items and their identification numbers (if any), refer to SDF Section 6.3. The CSCI functional baseline is established at release of the associated software product, at which time the allocated and product baselines are established.

The remaining paragraphs of section 7.1 are detailed descriptions of the CM processes you will use. In 7.1.1, describe the different parts and assign them names. In 7.1.2, if you are using a tool such as CVS, provide some information about how the tool is being set up and used to control the project artifacts, and give some specific command examples. Regardless of CM method, you must show the directory structure of the project, indicating what directories will be used for which modules of code. If graphics objects are being used, include them in the descriptions. Likewise, if a database engine is being used, describe how the database files will be controlled. Elaborate on your security mechanisms; how can you keep from being able to erase something by accident?
In 7.1.2.1 if there are any work products that you will develop, such as prototypes, list them and state that they are not required to be released, even though they are in the repository.

During the course of the project, you will produce/release at least an alpha version, a beta version, and the final version of your product. These releases must be shown in your CM plan in Section 7.2. Section 7.3 will itemize the software and hardware resources that specifically pertain to the CM process as you've defined it. Be sure to include enough detail in your procedures so that someone else could come along after you and maintain your project!

For Your Information and Edification

Since our teams in this class are small, it is probably OK for everyone to be operating in the CM tool (or participating in the plan) by checking out code, and checking it in when they are finished. In the industry, however, one person on the project team will be designated as "Software Configuration Management Officer" or "SCMO" (pronounced "schmoe"). This person will be the one in charge of performing builds for release and testing. The SCMO is a very powerful part of the development team, since she has the final say in whether a product is built successfully. There is usually also a Software Configuration Control Board, or SCCB, which is responsible for the review of all changes and additions to the code. The SCMO is frequently the leader of the SCCB.

And as if that isn't enough, there is also frequently a group called the "Engineering Review Board" or ERB, which has responsibility for reviewing any engineering change from the standpoint of the software architecture, as a first line of defense to ensure that changes to the software will be properly implemented, will not have adverse or negative affects on its operation (i.e., create bugs), and that the organization is made aware of the change. The ERB may even shoot down a requested change so that it never even comes to fruition!

A number of good CM tools are available. One of the most widely used is the free program called CVS. This program has versions available for all operating systems, and is easy to install, configure, and learn. The CVS tool is available for download from the CVS site. There are also complete directions for use, and "man" pages available, so I won't go into CVS too deeply here.

Another CM method is the "frozen directory" method (I just made the name up, you can call it whatever you wish.) In this CM plan, code is put into a directory that has a specific naming convention (usually including the date somehow) and is set to "read-only" status. Frequently, the owner of the files is changed to be one person on the team (the SCMO) with the remainder of the group's write privileges removed so the files cannot be changed. Because the method is not an application, increased discipline and vigilance are needed to ensure that everything works correctly and everyone adheres to the plan.

Two other programs, which are built in to the UNIX O/S, are called "SCCS" and "RCS". The Source Code Control System, or SCCS, was initially developed in 1972 by Marc Rochkind at Bell Telephone Laboratories. Though SCCS lacks some of the amenities of RCS (a natural result of its early date of development), it is a generally equivalent system and has a few capabilities that RCS does not. As you might guess from the company where it originated, SCCS traditionally has been part of AT&T-derived UNIX distributions. Though its initial implementation was not done in a UNIX environment, SCCS was quickly reimplemented under UNIX V6 and was distributed as part of the Programmer's Workbench (PWB) from AT&T. RCS, which stands for Revision Control System, was developed by Walter F. Tichy at Purdue University in the early 1980s. Implemented later than SCCS, and with full knowledge of it, RCS is a more user-friendly system, and in most ways a more powerful one.

No matter what method or tool is used, as standalone and integration testing is performed on your code, modules or subcomponents should be configured, that is, submitted to the "protected" area. As subsequent tests and/or integration testing is performed, link the piece to be tested with the configured versions of the software, rather than linking with unconfigured copies. In other words set up a build process that will use the checked-in, latest version of every file in the project except the one you are testing. This way you will know precisely what versions of what modules you are working with. Any bugs that show up in the testing process will most likely be due to the module you are testing, assuming that the checked-in versions have been completed, tested, and integrated. Any errors that are found not to be due to the test module can then be more accurately traced and repaired, since the versions will be controlled.

Next Document