The growth in cost and importance of software to my unit has caused my squadron to address the improvement of software development across the agency. One of the products of this program is a series of guidebooks that define the squadron concept of the assurance processes which are used in software development. This is the Software Configuration Management Guidebook which describes software configuration management in a way that is compatible with practices in industry and at Air Force Squadrons. Software configuration management is a key software development process, and is essential for doing software assurance.
This guidebook defines Software Configuration Management (SCM) and describes its constituent functions, processes, and procedures. The guidebook also describes a generic set of organizational elements and responsibilities for operation of SCM. It defines the role of SCM, its interfaces and its functions throughout the software development life cycle. This guidebook also provides a basis for tailoring SCM for different projects with different life cycles and project specific requirements.
Code Can Accelerate
Configuration Management BOF
Software Configuration Management CollectiveProper application of software configuration management is a key component in the development of quality software. Changes to the software under development are usually a significant cause of changes to a project's schedule and budget; unmanaged change is very possibly the largest single cause of failure to deliver systems on time and within budget.
SCM is the process that has been developed to control and manage change. Change is inevitable during the software development life cycle. Changes to the software come from both external and internal sources. External changes originate from users, from evolution of operational environments, and from improvements in technology. Internal changes come from improved designs and methods, from incremental development, and from correction of errors. A properly implemented SCM process is the project manager's best friend and potential salvation in coping with change.
This guidebook is written for software project managers who must plan for SCM for their project, for SCM practitioners who will implement SCM, and for software developers and acquirers who will be affected by it. The style of the guidebook is intended to be tutorial rather than directive. It is hoped that the reader will find the following sections an easily understood introduction to software configuration management and a useful guide to planning and implementing SCM in a software development project.
Software configuration management 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.
In order to accomplish the objective given in the above definition, there are four identified SCM functions: 1) identification of the components that make up the software system and that define its functional characteristics; 2) control of changes to those components; 3) reporting of status of the processing of change requests and, for approved requests, their implementation status; and 4) authentication that the controlled items meet their requirements and are ready for delivery.
The components of a software system that are controlled by the SCM process include project documentation, product documentation, code, data, and any other items needed to meet a set of requirements or contractual obligations. All of these items can be controlled by the same SCM process.
SCM requires that processes and procedures be put in place to identify the baselines that are to be established and their contents, to control the CSCIs and their individual elements to prevent unauthorized change, to process requests for changes to those baselines and report on status of changes, and to authenticate that a given configuration contains all of its required components and that it satisfies the functional and performance requirements given in the requirement document. That is, SCM consists of four basic processes:
Configuration Identification
Configuration Control
Configuration Status Accounting
Configuration Authentication
Configuration identification is the process of defining each baseline to be established during the software life cycle and describing the software configuration items and their documentation that make up each baseline. First, the software must be grouped into configuration items. Once the CSCIs and their components have been selected, some way of designating the items must be developed. This is done by the development of a numbering and naming scheme that correlates the code and data items with their associated documentation. Finally, the CSCIs must be described by the documentation of their functional, performance, and physical characteristics.
Configuration control is the process of evaluating, coordinating, and deciding on the disposition of proposed changes to the configuration items, and for implementing approved changes to baselined software and associated documentation. The change control process ensures that changes which have been initiated are classified and evaluated, approved or disapproved, and that those approved are implemented, documented, and verified.
Configuration status accounting is the process used to trace changes to the software. It ensures that status is recorded, monitored, and reported on both pending and completed actions affecting software baselines. This process also defines the current as-built status of the code and associated documentation.
Configuration authentication is the process of verifying that a deliverable software baseline contains all of the items which are required for that delivery, and that these items have themselves been verified, i.e., they satisfy their requirements. The authentication function usually consists of two "audits": a functional configuration audit (FCA) and a physical configuration audit (PCA). Functional audits authenticate that the software has been tested to assure that it performs in accordance with requirements in the baseline documentation. Physical audits authenticate that the software to be delivered contains all of the required components, documents, and data.
During the software requirements phase, the software concept and allocated system requirements are analyzed and documented as software requirements. Test planning begins, with a method for verifying each requirement identified and included in a preliminary test plan. Risks are identified and risk management control mechanisms are established. The size and scope of the remainder of the project is reevaluated, and changes in resources and schedules are made. Methods, standards, and procedures are detailed and put in place.
During this phase, the provider CMO should complete the final SCM Plan and submit it to the acquirer for review. The acquirer CMO will evaluate the provider's SCM Plan to ascertain that all of the SCM requirements are satisfied, and that the plan is complete and the procedures to be used are clearly stated. As part of the SCM planning, the staff required to perform SCM will have been determined and the assignment of the SCM staff will begin in this phase. Upon agreement between the acquirer and the provider, the Provider SCM Plan is placed under provider configuration management.
The software requirements baseline is struck after the completion of this phase and the satisfactory resolution of issues raised at the phase ending Software Requirements Review (SRR). The major component of the requirements baseline is the approved software requirements specification and interface requirements documents. However, it should also contain other relevant provider management documentation such as development plans, assurance and SCM plans, test plans, etc. These management and development documents detail the approach to managing, developing, testing, assuring, and controlling the software. They include or refer to applicable standards and procedures that will be adhered to during the development of the software.
The contents of the software requirements baseline become a permanent part of all succeeding baselines and are the basis against which the remaining development effort is authenticated. Any proposed change to this baseline will follow the change control process described in the Software Configuration Control within the SCM Process.
The objective of the software architectural design phase is to develop an overall design for the software, allocating all of the requirements to software components. The software requirements are controlled and managed, and the contents of the requirements baseline are changed only by a formal process. The phase ends with the preliminary design review, during which the acquirer and provider agree on the architecture of the system that is to be produced. Rework and action items resulting from the review are tracked and completed.
The software allocated baseline contains the architectural design of the system and documents showing how the requirements are allocated to the design. This baseline is struck after the completion of this phase and the resolution of any problems raised at the Software Preliminary (Architectural) Design Review (PDR). The baseline contains all the updated documents from the Requirements baseline, along with the architectural design specification. The baseline may also contain a software build (or release) plan and test plans. If present, these plans are usually still at a high level, with general functions assigned to the proposed builds or releases.
The contents of the software allocated baseline become a permanent part of all later baselines and a part of the basis against which the remaining development effort is authenticated. Any proposed change to this baseline will follow the change control process described in the Software Configuration Control within the SSCM Process.
The objectives of the software integration and test phase are to integrate the software units into a completed system, discover and correct any nonconformances, and prepare for the formal acceptance of the system. The phase ending review is the test readiness review, during which the developer provides to the acquirer evidence that the software system is ready for acceptance testing. During this phase, the test plan is executed, the documentation is updated and completed, and the products are finalized for delivery. The provider CMO will begin to prepare the Version Description Document (VDD).
The provider's testing organization uses the code baseline, which should include baselined test plans, to test and integrate the CSCIs and then to integrate them into a deliverable system.
After the controlled software components have been integrated and tested, the integrated software is placed under configuration management control in the program library. Once under control, the tested software can only be changed by an approved CR or as the result of a nonconformance (discrepancy) report that requires corrective action.
After the system testing has been completed and put under formal control, an FCA is performed to authenticate that the actual performance of the CSCIs complies with the requirements stated in the baselined software requirements document. This is accomplished by evaluating the test methods, procedures, reports, and other engineering and design documentation.
After the FCA has been successfully completed, a PCA is conducted to examine the as-built CSCIs against required deliverables, usually as defined in a contract deliverables requirements list (CDRL). The provider performs the PCA to ensure that all deliverable items are present and complete, and the system is ready to be turned over for acceptance testing by the acquirer or designated representative.
The phase ends with the Test Readiness Review (TRR). After resolution of any problems found during the TRR, the software product (or integrated) baseline is struck. This baseline contains the deliverable software and documents, updated to show as-built design. Along with the software, all other deliverable items, such as populated data bases and tables, computer installation procedures, and test beds are part of this baseline. The software is ready for system level integration testing and acceptance testing.
It is important for my squadron to follow this phases in order to provide the authorized software and hardware. With all the technology changes today we have to be able to keep up with the best and more up to date technology.