Difference between revisions of "Chapter 6: Software Configuration Management"

Revision as of 22:15, 24 August 2015

6-1 CHAPTER 6 SOFTWARE CONFIGURATION MANAGEMENT ACRONYMS CCB Configuration Control Board CM Configuration Management FCA Functional Configuration Audit PCA Physical Configuration Audit SCCB Software Configuration Control Board SCI Software Configuration Item SCM Software Configuration Management SCMP Software Configuration Management Plan SCR Software Change Request SCSA Software Configuration Status Accounting SDD Software Design Document SEI/ CMMI Software Engineering Institute’s Capability Maturity Model Integration SQA Software Quality Assurance SRS Software Requirement Specification INTRODUCTION A system can be defined as the combination of interacting elements organized to achieve one or more stated purposes [1]. The configuration of a system is the functional and physical characteris - tics of hardware or software as set forth in techni - cal documentation or achieved in a product [1]; it can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to serve a particular purpose. Configuration man - agement (CM), then, is the discipline of identify - ing the configuration of a system at distinct points in time for the purpose of systematically control - ling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle. It is formally defined as A discipline applying technical and admin - istrative direction and surveillance to: iden - tify and document the functional and physi - cal characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compli - ance with specified requirements. [1] Software configuration management (SCM) is a supporting-software life cycle process that benefits project management, development and maintenance activities, quality assurance activi - ties, as well as the customers and users of the end product. The concepts of configuration management apply to all items to be controlled, although there are some differences in implementation between hardware CM and software CM. SCM is closely related to the software qual - ity assurance (SQA) activity. As defined in the Software Quality knowledge area (KA), SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by plan - ning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. SCM activities help in accomplishing these SQA goals. In some proj - ect contexts, specific SQA requirements prescribe certain SCM activities 6-4 SWEBOK® Guide

V3.0

roles to be involved in the SCM process need to be clearly identified. Specific responsibilities for given SCM activities or tasks also need to be assigned to organizational entities, either by title or by organizational element. The overall author - ity and reporting channels for SCM should also be identified, although this might be accomplished at the project management or quality assurance planning stage. 1.3.2. SCM Resources and Schedules [2*, ann. Ds8] [3*, c23] Planning for SCM identifies the staff and tools involved in carrying out SCM activities and tasks. It addresses scheduling questions by establishing necessary sequences of SCM tasks and identify - ing their relationships to the project schedules and milestones established at the project manage - ment planning stage. Any training requirements necessary for implementing the plans and train - ing new staff members are also specified. 1.3.3. Tool Selection and Implementation [3*, c26s2, c26s6] [4*, c29s5] As for any area of software engineering, the selection and implementation of SCM tools should be carefully planned. The following ques - tions should be considered: • Organization: what motivates tool acquisi - tion from an organizational perspective? • Tools: can we use commercial tools or develop them ourselves? • Environment: what are the constraints imposed by the organization and its techni - cal context? • Legacy: how will projects use (or not) the new tools? • Financing: who will pay for the tools’ acquisition, maintenance, training, and customization? • Scope: how will the new tools be deployed— for instance, through the entire organization or only on specific projects? • Ownership: who is responsible for the intro - duction of new tools? • Future: what is the plan for the tools’ use in the future? • Change: how adaptable are the tools? • Branching and merging: are the tools’ capa - bilities compatible with the planned branch - ing and merging strategies? • Integration: do the various SCM tools inte - grate among themselves? With other tools in use in the organization? • Migration: can the repository maintained by the version control tool be ported to another version control tool while maintaining com - plete history of the configuration items it contains? SCM typically requires a set of tools, as opposed to a single tool. Such tool sets are some - times referred to as workbenches. In such a con - text, another important consideration in plan - ning for tool selection is determining if the SCM workbench will be open

(in other words, tools 

from different suppliers will be used in differ - ent activities of the SCM process) or integrated (where elements of the workbench are designed to work together). The size of the organization and the type of projects involved may also impact tool selection (see topic 7, Software Configuration Manage - ment Tools). 1.3.4. Vendor/Subcontractor Control [2*, c13] [3*, c13s9, c14s2] A software project might acquire or make use of purchased software products, such as compilers or other tools. SCM planning considers if and how these items will be taken under configura - tion control (for example, integrated into the proj - ect libraries) and how changes or updates will be evaluated and managed. Similar considerations apply to subcontracted software. When using subcontracted software, both the SCM requirements to be imposed on the subcontractor’s SCM process as part of the subcontract and the means for monitoring com - pliance need to be established. The latter includes consideration of what SCM information must be available for effective compliance monitoring. 6-6 SWEBOK® Guide

V3.0

insights leading to process changes and corre - sponding updates to the SCMP. Software libraries and the various SCM tool capabilities provide sources for extracting infor - mation about the characteristics of the SCM process (as well as providing project and man - agement information). For example, information about the time required to accomplish various types of changes would be useful in an evalua - tion of the criteria for determining what levels of authority are optimal for authorizing certain types of changes and for estimating future changes. Care must be taken to keep the focus of the surveillance on the insights that can be gained from the measurements, not on the measurements themselves. Discussion of software process and product measurement is presented in the Soft - ware Engineering Process KA. Software mea - surement programs are described in the Software Engineering Management KA. 1.5.2. In-Process Audits of SCM [3*, c1s1] Audits can be carried out during the software engineering process to investigate the current sta - tus of specific elements of the configuration or to assess the implementation of the SCM process. In-process auditing of SCM provides a more for - mal mechanism for monitoring selected aspects of the process and may be coordinated with the SQA function (see topic 5, Software Configura - tion Auditing). 2. Software Configuration Identification [2*, c8] [4*, c29s1.1] Software configuration identification identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. These activities provide the basis for the other SCM activities. 2.1. Identifying Items to Be Controlled [2*, c8s2.2] [4*, c29s1.1] One of the first steps in controlling change is identifying the software items to be controlled. This involves understanding the software config - uration within the context of the system configu - ration, selecting software configuration items, developing a strategy for labeling software items and describing their relationships, and identifying both the baselines to be used and the procedure for a baseline’s acquisition of the items. 2.1.1. Software Configuration [1, c3] Software configuration is the functional and phys - ical characteristics of hardware or software as set forth in technical documentation or achieved in a product. It can be viewed as part of an overall system configuration. 2.1.2. Software Configuration Item [4*, c29s1.1] A configuration item (CI) is an item or aggre - gation of hardware or software or both that is designed to be managed as a single entity. A soft - ware configuration item (SCI) is a software entity that has been established as a configuration item [1]. The SCM typically controls a variety of items in addition to the code itself. Software items with potential to become SCIs include plans, specifi - cations and design documentation, testing mate - rials, software tools, source and executable code, code libraries, data and data dictionaries, and documentation for installation, maintenance, operations, and software use. Selecting SCIs is an important process in which a balance must be achieved between pro - viding adequate visibility for project control pur - poses and providing a manageable number of controlled items. 2.1.3. Software Configuration Item Relationships [3*, c7s4] Structural relationships among the selected SCIs, and their constituent parts, affect other SCM activities or tasks, such as software building or analyzing the impact of proposed changes. Proper tracking of these relationships is also important for supporting traceability. The design of the identification scheme for SCIs