Software Configuration Management
The purpose of Software Configuration Management (SCM) is to provide a common operating framework in which activities such as building software and documenting SCM plans, and Version Description Documents (VDD) can be shared between management, team members, and software quality engineering (SQE) representatives. The expected SCM building of software is delivered to test labs for verification and validation by SQE. Components of SCM is making sure software configuration has identification, change control, SCM status accounting and SCM audits and reviews are performed.
For 20 years, I was an SCM engineer working for the Boeing Defense and Space programs for B-2 Stealth Bomber, F-22 Raptor, Advanced Systems, and Airborne Early Warning & Control (AEW&C) in Australia. I was able to put together an SCM team to get ClearCase and ClearQuest installed when working for AEW&C and F-22 Raptor programs.
Software Configuration Management Items
Software configuration management (SCM) items are the software while under the development for programs, data, documents such as the software requirements specification, test cases that are referred to as SCM items during the software engineering development.
SCM provides for systematic evolution of a software under development and provides for:
■ Controlled change
Goals for Software Configuration Management
The goals for an SCM must include planned activities to ensure that software work products are identified, controlled, and made available. Changes to identified software work products are controlled, and affected groups and individuals must be informed of the status and content of all software baselines. Baselines include the following:
■ Phase and discipline
■ Requirements analysis
■ Software design and specification
■ Software programming and implementation
■ Testing and integration
■ Test plans and data
■ Release of operational software.
The baseline is a specification or a product that has been formally reviewed and agreed upon and serves as the basis for further software development.
SCM goals are provided in Figure 8.1.
SCM identification includes setting and maintaining software engineering baselines, which define the architecture, components, and software developments at any point in time. It is the basis by which changes to any part of SCM are identified, documented, and later tracked through software programming, design, development, testing, and final delivery to labs and customers. SCM incrementally establishes and maintains the definitive current basis and
Figure 8.1 Software Configuration Management goals.
its configuration items (Cis) throughout their product life cycle from software engineering development, production, deployment, to operational support. Software configuration control includes evaluation of all change requests and change proposals, and their approval or disapproval. SCM covers all the processes that control any modifications to the designs of hardware, firmware, software, and documentation.
The information about the effectiveness of a software engineering process is necessary for management, team members, and employees, and so it should be made available through SCM engineering. Software changes should be documented, and the information should always be checked for any updates. Updated information for the Cis is available in the SCM database.
The responsibilities for SCM are as follows:
■ Implement the SCM program and SCM requirement for software baselines.
■ Establish and maintain a software change request (SCR) tracking database for reviews.
■ Develop and document the SCM plans and operating procedures and documents.
■ Form an Engineering Review Board (ERB) that will prepare and distribute its agendas, record the status of SCM change requests, and review and approve the requests.
■ Produce and distribute SCM status plans and reports.
■ Coordinate SCRs with respective individuals to implement approved changes and to resolve and fix all SCR problems.
■ Make sure that software quality representatives (SQR) are included in all ERB meetings.
Integration Build and Release
The role of an integration build and release engineer is to construct software systems and set up software components. They combine the work of many SCM teams and assemble software builds for integration and release. Software integration is the process of bringing the works of different SCM teams together, testing them, and making adequate changes to produce software systems with required performance.
There are two types of integration used by SCM: merge and assembly integrations. Merge integration involves the solutions of changes made by SCM teams to common files and components. It should always be remember that merge integration requires the knowledge of changes made to software systems.
The integration build and release methods provide required steps to be conducted for integration and checkout of informal software engineering builds. The SCM engineers, software design/development teams, and test engineers need to develop a strategy for planning, design, execution, data collection, and test evaluations.
The software builds and integration activities are formal and flexible and prepare for the software and systems integration phase for the work product.
The strategy for software integration builds and release provides a road map that describes the steps to be conducted as part of the implementation of software to start integration activities. When a strategy is planned, adequate resources are required. This strategy should be flexible and promote an approach that could show change.
Sometimes, planning by a senior engineer, program and project managers need to track the progress of program and project, and also need to do the following:
■ Conduct effective technical reviews.
■ Show different integration techniques and software approach.
■ Involve software engineering designers from the start to the end of the work in SCM.
Assembly integration provides baselines for software components that could be large pieces of the overall software system. Assembly integration can occur during software build times and SCM activities, and can bring together source components of software builds. Different types and levels of assembly integration are used based on the size of the software build systems. At certain levels, software
Figure 8.2 Software system integration.
systems must have a well-defined architecture to use the assembly integration.
There are three assembly integration scenarios required for the SCM teams to develop the software system independently and perform assembly integration.
The first level of assembly integration is referred to subsystem, and the second level is software system integration for A and B as shown in Figure 8.2.
Software Configuration Management Methods
SCM methods are used for the development of software engineering programs and maintenance of computer software engineering tools. There are a variety of SCM methods used by many software programs worldwide. The terminology, definitions, or terms used by SCM can be different depending on what software program you work in. An example is; ERB and SCR can be used and defined. Another definition is Version Description Document (VDD), which I have seen and used in all my 31 years of working in military and aerospace programs. What is defined in the software program or project by the SCM methods determines the terms to be used while working on a software engineering program.
As a software designer, I know that my software design activities are important and comfortable to release software code for SCM to configure and control along with building software code changes or updates to release for test, verification, validation, and delivery to customers. There are more about SCM organizations that software designers do not know. Many software designers feel SCM has no understanding of software engineering, and I beg to differ that there are numerous software designers who want to know the role of SCM.
The SCM activities are necessary to
■ Establish and maintain the software engineering identification process and control changes to identified software products and their related integration and documentation.
■ Record and report information needed to manage software products effectively, including the status of proposed changes and the implementation status of approved changes.
■ Maintain auditable records of all applicable software products help verify conformance to specifications, interface control documents, contract requirements, and as-built software configurations.
The SCM build engineer will perform tasks related to software construction and configuration control that include creation of a folder to store documentation of the build, software source code changes, and records of computer program development. Software build requests (SBRs) are written, and a build procedure checklist is provided to assemble, compile, and link source codes; build archive copies; provide listings for use in software engineering development, test, and delivery support; and document the VDD.
Berczuk, S. P., Appleton, B., 2003, Software Configuration Management Patterns: Effective Team-Work Practical Integration, First Edition. Boston, MA: Addison-Wesley. ISBN 0-201-74117-2.
White, B. A., 2000, Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction, Boston, MA: Addison-Wesley. ISBN 0-201-60478-7.