The Software Configuration Management Process
As with any system, “unmanaged change is very possibly the largest single cause of failure to deliver systems on time and within budget.”4 Software Configuration Management (SCM) "is the process whose objective is the identification of the configuration of software at discrete points in time and the systematic control of changes to the identified configuration for the purpose of maintaining software integrity and traceability throughout the software life cycle.”4 In other words, SCM is the process of controlling all items necessary to meet the specified requirements and/or any other contractual obligations. These items include but are not limited to: code, documentation, and data sets. Configuration management applies in the same context in SW (Software) as it does in HW (Hardware). It is a critical aspect for reliable SW.
It is up to you: Watch this video (Youtube link) if you want to understand better the importance of Software Configuration Management Process.
NASA Software Configuration Management Guidebook
SW is typically divided into items. These items are the product or project level delivery of software and are called computer software configuration items (CSCIs). These items do not include each individual SW component. The term is used to describe the top-level contractually obligated SW deliveries.
“The configuration of software at a discrete point in time is known as a baseline. Thus, a baseline is the documentation and software that make up a CSCI at a given point in its life cycle.”4
SCM is made up of identification, control, status accounting and authentication.
- Identification: Defines each SW baseline and dictates what items (documentation, code, etc) represents the various baselines throughout the life-cycle
- Control: The process of managing all SW related changes
- Status Accounting: The process of tracing changes. This process is critical in reliability and repeatability. This process is also a key factor in identifying lessons learned
- Authentication: The verification process of SW deliverables
It is up to you: Click on the hotspots below to get more detailed definitions and examples that illustrate the importance of each element in the Software Configuration Management. The content below was created by using the sources 4 and 11 listed in the references section. The user may switch to the full screen mode in order to improve readability.
SCM is managed by the configuration management officer or by a specific/separate SCM manager depending on the project size. The SCM process plays a vital role in “managing software development, operation, maintenance, and enhancement.”4
SCM plays different roles depending on the life-cycle of the project. In the initial phases, SCM will focus more on the SW processes and plans as well as control of initial requirements. As the project progresses, requirements and test plans become the focus of SCM.
- Once development begins, SCM will focus on controlling the architecture (such as block and case diagrams) and then transition to managing the detailed design. Managing the architecture usually occurs around the preliminary design review (PDR) and managing the detailed design usually occurs around the critical design review (CDR).
- By implantation, SCM will manage the SW build (code) and appropriate documentation. This is the first instance in which the code becomes under CM control.
- By integration and test (usually after the Test Readiness Review (TRR)), all changes will require a change request (CR).
- During acceptance, SCM is responsible of turning control over to the acquirer. This is termed as the as-built baseline.
- During the final phase (support and maintenance), SCM strictly enforces change control of anything SW related. All changes must be approved through upper management at a change control board (CCB).
As a side note, SCM, as with all CM, should be structured in such a manner that it aids in development and does not impede development thus causing schedule delays. Interim or informal CM control should be used under the approval and discretion of the SW assurance manager or management team. Informal CM should not occur after a formal baseline has been established.