Software Configuration Management: Function or Discipline?

Software Configuration Management:
Function or Discipline?

Alexa Marshall, PROSOFT

Your configuration and product information is either current and accurate, or it's not. If it is not, you will spend all of your time trying to correct it and bringing it up to date. If you are lucky enough to find engineers who remember what the data should be, you will discover that they have moved on to another task and have no interest in correcting old data. And while you are out auditing and correcting, your product has continued to change. Does this sound familiar?

As long as software configuration management (SCM) is viewed as a function performed separately from engineering, your configuration data will never be current and accurate and your SCM personnel will always be in the position of begging for data from engineers who naturally have more interest in engineering than in the accuracy of yesterday's configuration. This problem cannot be corrected by merely adding a configuration/product database to automate SCM. Adding a database without changing the underlying philosophy only means that your SCM people will be begging for data to put in the database rather than for data to put onto a form. The answer is to make SCM a discipline that is an integral part of the engineering process and then automate that process.

Making SCM a discipline rather than a function requires the adoption of the following three concepts:

All products must be released from SCM.
The corrective action system is the crux of both the engineering process and SCM.
Automating a process does not mean implementing a database.

All Products Must be Released from SCM

Suppose the policy is that products should be in SCM prior to release, rather than that they must be released from SCM. When the rule is only a should, the releasing organization (usually the contract office) is allowed to accept products for delivery from the engineers. If the engineers have plenty of time to make their deadlines, they are likely to follow the policy and place the item in SCM prior to its delivery. If the engineers are scrambling to make a deadline, they are likely to give the item directly to the releasing organization so that the deadline can be met. The engineers intend to put the item in SCM later, when there is time, but if they are behind on this deadline, they are usually behind on the next deadline, too. Meanwhile, only the engineers responsible for the delivery and the releasing organization know that a new version of the item has been issued. No one else is even aware that the configuration and product information maintained by SCM is no longer accurate.

By making it a program policy that the releasing organization accepts products only from SCM, delivering to SCM becomes the engineers' goal. The engineers cannot take credit for a task until its products have been turned over to and accepted by SCM. The engineers then have a vested interest in providing the necessary configuration data to SCM in a timely manner while it is still fresh in their minds. There is no need to audit the products held by SCM against what has been delivered, because no product is delivered by going around SCM. If you expand this policy so that part of the SCM acceptance criteria is a successful rebuild of the product, you will also be ensuring that the product is recreatable without any special knowledge. If the engineer primarily responsible for the item wins the lottery and departs for Tahiti, the item can still be maintained because the SCM group will have the tools and knowledge needed to independently rebuild it. This policy must be fully endorsed and enforced by management to be effective.

The Corrective Action System is the Crux of
Both the Engineering Process and SCM

The following is a typical, generic corrective action system scenario:

Someone finds and reports a problem with a product. An engineer researches the problem and determines what needs to be changed to fix the problem. A review board composed of engineers or their managers or both approves change development. An engineer retrieves the item to be fixed from the SCM repository and makes the necessary changes. The engineer submits the updated items to an SCM holding area for review. SCM rebuilds the changed item. A configuration control board (CCB) composed of engineers reviews the change and determines whether it fixed the problem and is of sufficient quality to be baselined. The problem is closed and the SCM repository is updated with the files from the holding area.

All of the tasks described in this scenario have an impact on the product's configuration. Almost all of the participants in this scenario are engineers. SCM personnel only play a supporting role, that of the corrective action system administrators. Some may argue that the corrective action system paradigm does not cover new development, but as long as a newly developed item can be submitted for review and approval without a problem report, the paradigm will hold true. What are the advantages of making the corrective action system the heart of the engineering and SCM processes?

SCM records are always current and accurate.
The product is centrally located in the SCM repository, which ensures that the current version is known and readily available to everyone.
Because all items given to SCM are reviewed and approved by technically cognizant engineers in a controlled holding area prior to their acceptance into the product area, corruption of the product area is minimized or eliminated.
Using a what-you-see-is-what-you-get approach at the CCB eliminates the need for a separate implementation verification cycle.

Automating a Process Does Not Mean Implementing a Database

Frequently, the only advantage gained by creating a database to back up a hardcopy form is that the data is more accessible for reporting. Adding a database to a process may slow the process down if the data is entered into the database by one person or organization. Successful process automation requires

Breaking the process flow(s) into discrete phases.
Limiting the data to be collected in each phase to what is appropriate for that phase; for example, the person who has a problem with a product should not be forced to diagnose the problem before being allowed to report it.
Assigning personnel to phases based on the role that they play in the process.
Encouraging (or requiring) personnel responsible for a phase to enter the data themselves (as opposed to having them write it down for a third party to enter).
Providing sufficient data security and ease of entry to foster a willingness among process participants to use the automation.
For those phases that require multiple participants, e.g., review boards, allowing the users to act concurrently rather than serially, just as they would in the manual process.

Automating the corrective action system (SCM) process has many benefits, including:

Reduction of paper and its associated cost (the paper, reproduction, storage).
Cycle time reduction for the corrective action system through the use of electronic notification and electronic review and configuration boards.
Increased data reliability (errors tend to creep in when data is transferred from hard copy to a database; these errors are eliminated when the data is collected electronically).
The corrective action system and SCM records are readily available and accessible to the engineers from their working environment.

As long as SCM is treated as a function that is performed separately from engineering rather than as a part of the engineering process, it will be difficult, costly, and inaccurate. To be successful, SCM must be treated as an engineering discipline, which is everyone's responsibility. In the same way that quality cannot be inspected into a product, software configuration management cannot be audited into a product.

Alexa Marshall
PROgressive SOFTware Solutions, INC. (PROSOFT)
106 Dwight Park Circle
Syracuse, NY 13209
Voice: 315-461-9855
Fax: 315-461-9856

About the Author

Alexa Marshall has over 16 years experience in defense software management. She has led software quality assurance and software configuration management teams on software projects that consisted of from 25 to over 1,000 engineers and support staff. She wrote the requirement specification for a fully automated problem reporting/change control system, which is fully implemented and is in use today, supporting 6 million lines of Ada code and associated documentation. The methodology implemented as a result of her expertise served as the foundation for PROSOFT's creation of XStream, a configuration management software system. Marshall previously authored "Demystifying Software Configuration Management" in the May 1995 issue of CrossTalk.