Difference between revisions of "Chapter 6: Software Configuration Management"
(→Software Configuration Management Tools) |
|||
(54 intermediate revisions by the same user not shown) | |||
Line 14: | Line 14: | ||
{{Acronym|name=SQA|description=Software Quality Assurance}} | {{Acronym|name=SQA|description=Software Quality Assurance}} | ||
{{Acronym|name=SRS|description=Software Requirement Specification}} | {{Acronym|name=SRS|description=Software Requirement Specification}} | ||
− | |||
}} | }} | ||
Line 21: | Line 20: | ||
defined as | defined as | ||
+ | A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance 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 activities, 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 quality 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 planning, 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 project contexts, specific SQA requirements prescribe certain SCM activities. | ||
+ | The SCM activities are management and planning of the SCM process, software configuration identification, software configuration control, software configuration status accounting, software configuration auditing, and software release management and delivery. The Software Configuration Management KA is related to all the other KAs, since the object of configuration management is the artifact produced and used throughout the software engineering process.}} | ||
− | Software | + | {{IntroSection|title=Breakdown of Topics for Software Configuration Management|body= |
− | + | The breakdown of topics for the Software Configuration Management KA is shown in Figure 6.1.}} | |
+ | [[File:software-configuration-management.jpg|thumb|400px|frame|Figure 6.1: Breakdown of Topics for the Software Configuration Management KA ]] | ||
− | + | ==Management of the SCM Process== | |
− | + | ||
− | + | SCM controls the evolution and integrity of a product by identifying its elements; managing and controlling change; and verifying, recording, and reporting on configuration information. From the software engineer’s perspective, SCM facilitates development and change implementation activities. A successful SCM implementation requires careful planning and management. This, in turn, requires an understanding of the organizational context for, and the constraints placed on, the design and implementation of the SCM process. | |
− | + | ||
− | to be clearly identified. Specific responsibilities | + | ===Organizational Context for SCM=== |
− | for given SCM activities or tasks also need to be | + | {{RightSection|{{referenceLink|number=2|parts=c6, ann. D}} {{referenceLink|number=3|parts=introduction}}{{referenceLink|number=4|parts=c29}}}} |
− | assigned to organizational entities, either by title | + | To plan an SCM process for a project, it is necessary to understand the organizational context and the relationships among organizational elements. SCM interacts with several other activities or organizational elements. The organizational elements responsible for the software engineering supporting processes may be structured in various ways. Although the responsibility for performing certain SCM tasks might be assigned to other parts of the organization (such as the development organization), the overall responsibility for SCM often rests with a distinct organizational element or designated individual. Software is frequently developed as part of a larger system containing hardware and firmware elements. In this case, SCM activities take place in parallel with hardware and firmware CM activities and must be consistent with system-level CM. Note that firmware contains hardware and software; therefore, both hardware and software CM concepts are applicable. SCM might interface with an organization’s quality assurance activity on issues such as records management and nonconforming items. Regarding the former, some items under SCM control might also be project records subject to provisions of the organization’s quality assurance program. Managing nonconforming items is usually the responsibility of the quality assurance activity; however, SCM might assist with tracking and reporting on software configuration items falling into this category. Perhaps the closest relationship is with the software development and maintenance organizations. It is within this context that many of the software configuration control tasks are conducted. Frequently, the same tools support development, maintenance, and SCM purposes. |
− | or by organizational element. The overall | + | |
− | + | ===Constraints and Guidance for the SCM Process=== | |
− | + | {{RightSection|{{referenceLink|number=2|parts=c6, ann. D, ann. E}} {{referenceLink|number=3|parts=c2, c5}} {{referenceLink|number=5|parts=c19s2.2}}}} | |
− | identified, although this might be accomplished | + | Constraints affecting, and guidance for, the SCM |
− | at the project management or quality assurance | + | process come from a number of sources. Policies |
+ | and procedures set forth at corporate or other | ||
+ | organizational levels might influence or prescribe | ||
+ | the design and implementation of the SCM process | ||
+ | for a given project. In addition, the contract | ||
+ | between the acquirer and the supplier might contain | ||
+ | provisions affecting the SCM process. For | ||
+ | example, certain configuration audits might be | ||
+ | required, or it might be specified that certain items | ||
+ | be placed under CM. When software products to | ||
+ | be developed have the potential to affect public | ||
+ | safety, external regulatory bodies may impose | ||
+ | constraints. Finally, the particular software life | ||
+ | cycle process chosen for a software project and | ||
+ | the level of formalism selected to implement the | ||
+ | software affect the design and implementation of | ||
+ | the SCM process. Guidance for designing and implementing an | ||
+ | SCM process can also be obtained from “best | ||
+ | practice,” as reflected in the standards on software engineering issued by the various standards organizations | ||
+ | (see Appendix B on standards). | ||
+ | |||
+ | ===Planning for SCM=== | ||
+ | {{RightSection|{{referenceLink|number=2|parts=c6, ann. D, ann. E}} {{referenceLink|number=3|parts=c23}} {{referenceLink|number=4|parts=c29}}}} | ||
+ | The planning of an SCM process for a given | ||
+ | project should be consistent with the organizational | ||
+ | context, applicable constraints, commonly | ||
+ | accepted guidance, and the nature of the | ||
+ | project (for example, size, safety criticality, and | ||
+ | security). The major activities covered are software | ||
+ | configuration identification, software configuration | ||
+ | control, software configuration status | ||
+ | accounting, software configuration auditing, and | ||
+ | software release management and delivery. In | ||
+ | addition, issues such as organization and responsibilities, | ||
+ | resources and schedules, tool selection | ||
+ | and implementation, vendor and subcontractor | ||
+ | control, and interface control are typically considered. | ||
+ | The results of the planning activity are | ||
+ | recorded in an SCM Plan (SCMP), which is typically | ||
+ | subject to SQA review and audit. | ||
+ | Branching and merging strategies should be | ||
+ | carefully planned and communicated, since they | ||
+ | impact many SCM activities. From an SCM standpoint, | ||
+ | a branch is defined as a set of evolving source | ||
+ | file versions [1]. Merging consists in combining | ||
+ | different changes to the same file [1]. This typically | ||
+ | occurs when more than one person changes a | ||
+ | configuration item. There are many branching and | ||
+ | merging strategies in common use (see the Further | ||
+ | Readings section for additional discussion). | ||
+ | The software development life cycle model | ||
+ | (see Software Life Cycle Models in the Software | ||
+ | Engineering Process KA) also impacts SCM | ||
+ | activities, and SCM planning should take this | ||
+ | into account. For instance, continuous integration | ||
+ | is a common practice in many software development | ||
+ | approaches. It is typically characterized by | ||
+ | frequent build-test-deploy cycles. SCM activities | ||
+ | must be planned accordingly. | ||
+ | |||
+ | ====SCM Organization and Responsibilities==== | ||
+ | {{RightSection|{{referenceLink|number=2|parts=ann. Ds5, ann. Ds6}} {{referenceLink|number=3|parts=c10-11}} {{referenceLink|number=4|parts=introduction, c29}}}} | ||
+ | To prevent confusion about who will perform | ||
+ | given SCM activities or tasks, organizational 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 authority | ||
+ | and reporting channels for SCM should also be | ||
+ | identified, although this might be accomplished | ||
+ | at the project management or quality assurance | ||
planning stage. | planning stage. | ||
− | + | ||
− | SCM | + | ====SCM Resources and Schedules==== |
− | Resources | + | {{RightSection|{{referenceLink|number=2|parts=ann. Ds8}} {{referenceLink|number=3|parts=c23}}}} |
− | and | + | Planning for SCM identifies the staff and tools |
− | Schedules | + | involved in carrying out SCM activities and tasks. |
− | + | It addresses scheduling questions by establishing | |
− | Planning for SCM identifies the staff and tools | + | necessary sequences of SCM tasks and identifying |
− | involved in carrying out SCM activities and tasks. | + | their relationships to the project schedules |
− | It addresses scheduling questions by establishing | + | and milestones established at the project management |
− | necessary sequences of SCM tasks and | + | planning stage. Any training requirements |
− | + | necessary for implementing the plans and training | |
− | + | new staff members are also specified. | |
− | and milestones established at the project | + | |
− | + | ====Tool Selection and Implementation==== | |
− | + | {{RightSection|{{referenceLink|number=3|parts=c26s2, c26s6}} {{referenceLink|number=4|parts=c29s5}}}} | |
− | necessary for implementing the plans and | + | As for any area of software engineering, the |
− | + | selection and implementation of SCM tools | |
− | + | should be carefully planned. The following questions | |
− | + | should be considered: | |
− | Tool | + | |
− | Selection | + | * Organization: what motivates tool acquisition from an organizational perspective? |
− | and | + | * Tools: can we use commercial tools or develop them ourselves? |
− | Implementation | + | * Environment: what are the constraints imposed by the organization and its technical context? |
− | + | * Legacy: how will projects use (or not) the new tools? | |
− | As for any area of software engineering, the | + | * Financing: who will pay for the tools, acquisition, maintenance, training, and customization? |
− | selection | + | * Scope: how will the new tools be deployed — for instance, through the entire organization or only on specific projects? |
− | should be carefully planned. The following | + | * Ownership: who is responsible for the introduction 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 capabilities compatible with the planned branching and merging strategies? | |
− | Organization: | + | * Integration: do the various SCM tools integrate 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 complete history of the configuration items it contains? | |
− | + | ||
− | + | SCM typically requires a set of tools, as | |
− | Tools: | + | opposed to a single tool. Such tool sets are sometimes |
− | develop them ourselves? | + | referred to as workbenches. In such a context, |
− | + | another important consideration in planning | |
− | Environment: | + | for tool selection is determining if the SCM |
− | imposed by the organization and its | + | workbench will be open (in other words, tools |
− | + | from different suppliers will be used in different | |
− | + | activities of the SCM process) or integrated | |
− | + | (where elements of the workbench are designed | |
− | Legacy: how will projects use (or not) the | + | |
− | new tools? | + | |
− | + | ||
− | Financing: | + | |
− | acquisition, maintenance, training, and | + | |
− | customization? | + | |
− | + | ||
− | Scope: how will the new tools be | + | |
− | for instance, through the entire organization | + | |
− | or only on specific projects? | + | |
− | + | ||
− | Ownership: who is responsible for the | + | |
− | + | ||
− | + | ||
− | + | ||
− | Future: what is the plan for the | + | |
− | the future? | + | |
− | + | ||
− | Change: how adaptable are the tools? | + | |
− | + | ||
− | Branching and merging: are the | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | Integration: do the various SCM tools | + | |
− | + | ||
− | + | ||
− | use in the organization? | + | |
− | + | ||
− | Migration: can the repository maintained by | + | |
− | the version control tool be ported to another | + | |
− | version control tool while maintaining | + | |
− | + | ||
− | + | ||
− | contains? | + | |
− | SCM | + | |
− | opposed to a single tool. Such tool sets are | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | workbench will be | + | |
− | open | + | |
− | + | ||
− | from different suppliers will be used in | + | |
− | + | ||
− | + | ||
− | integrated | + | |
− | (where elements of the workbench are designed | + | |
to work together). | to work together). | ||
− | The size of the organization and the type of | + | The size of the organization and the type of |
− | projects involved may also impact tool selection | + | projects involved may also impact tool selection |
− | (see | + | (see topic 7, Software Configuration Management |
− | + | Tools). | |
− | + | ||
− | + | ====Vendor/Subcontractor Control==== | |
− | Vendor/Subcontractor | + | {{RightSection|{{referenceLink|number=2|parts=c13}} {{referenceLink|number=3|parts=c13s9, c14s2}}}} |
− | Control | + | A software project might acquire or make use of |
− | + | purchased software products, such as compilers | |
− | A software project might acquire or make use of | + | or other tools. SCM planning considers if and |
− | purchased software products, such as compilers | + | how these items will be taken under configuration |
− | or | + | control (for example, integrated into the project |
− | how these items will be taken under | + | libraries) and how changes or updates will be |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
evaluated and managed. | evaluated and managed. | ||
− | Similar considerations apply to subcontracted | + | Similar considerations apply to subcontracted |
− | software. When using subcontracted software, | + | software. When using subcontracted software, |
− | both | + | both the SCM requirements to be imposed on |
− | the subcontractor’s SCM process as part of the | + | the subcontractor’s SCM process as part of the |
− | subcontract and the means for monitoring | + | subcontract and the means for monitoring compliance |
− | + | need to be established. The latter includes | |
− | + | consideration of what SCM information must be | |
− | consideration of what SCM information must be | + | |
available for effective compliance monitoring. | available for effective compliance monitoring. | ||
− | + | ||
− | + | ====Interface Control==== | |
− | + | {{RightSection|{{referenceLink|number=2|parts=c12}} {{referenceLink|number=3|parts=c24s4}}}} | |
− | insights leading to process changes and | + | When a software item will interface with |
− | + | another software or hardware item, a change | |
− | + | to either item can affect the other. Planning for | |
− | Software | + | the SCM process considers how the interfacing |
− | capabilities provide sources for extracting | + | items will be identified and how changes to the |
− | + | items will be managed and communicated. The | |
− | + | SCM role may be part of a larger, system-level | |
− | process (as well as providing project and | + | process for interface specification and control; |
− | + | it may involve interface specifications, interface | |
− | + | control plans, and interface control documents. | |
− | about the time required to accomplish various | + | In this case, SCM planning for interface control |
− | types of changes would be useful in an | + | takes place within the context of the systemlevel |
− | + | process. | |
− | + | ||
− | authority are optimal for authorizing certain types | + | ===SCM Plan=== |
− | of changes and for estimating future changes. | + | {{RightSection|{{referenceLink|number=2|parts=ann. D}} {{referenceLink|number=3|parts=c23}} {{referenceLink|number=4|parts=c29s1}}}} |
− | Care must be taken to keep the focus of the | + | The results of SCM planning for a given project |
− | surveillance on the insights that can be gained | + | are recorded in a software configuration management |
− | from the measurements, not on the measurements | + | plan (SCMP), a “living document” which |
− | themselves. Discussion of software process and | + | serves as a reference for the SCM process. It is |
− | product measurement is presented in the | + | maintained (that is, updated and approved) as |
− | + | necessary during the software life cycle. In implementing | |
− | + | the SCMP, it is typically necessary to | |
− | + | develop a number of more detailed, subordinate | |
− | + | procedures defining how specific requirements | |
+ | will be carried out during day-to-day activities— | ||
+ | for example, which branching strategies will be | ||
+ | used and how frequently builds occur and automated | ||
+ | tests of all kinds are run. | ||
+ | Guidance on the creation and maintenance of | ||
+ | an SCMP, based on the information produced by | ||
+ | the planning activity, is available from a number | ||
+ | of sources, such as [2*]. This reference provides | ||
+ | requirements for the information to be contained | ||
+ | in an SCMP; it also defines and describes six categories | ||
+ | of SCM information to be included in an | ||
+ | SCMP: | ||
+ | |||
+ | * Introduction (purpose, scope, terms used) | ||
+ | * SCM Management (organization, responsibilities,authorities, applicable policies, directives, and procedures) | ||
+ | * A software project might acquire or make use of SCM Activities (configuration identification, configuration control, and so on) | ||
+ | * SCM Schedules (coordination with other project activities) | ||
+ | * SCM Resources (tools, physical resources, and human resources) | ||
+ | * SCMP Maintenance. | ||
+ | |||
+ | ===Surveillance of Software Configuration Management=== | ||
+ | {{RightSection|{{referenceLink|number=3|parts=c11s3}}}} | ||
+ | After the SCM process has been implemented, | ||
+ | some degree of surveillance may be necessary | ||
+ | to ensure that the provisions of the SCMP are | ||
+ | properly carried out. There are likely to be specific | ||
+ | SQA requirements for ensuring compliance | ||
+ | with specified SCM processes and procedures. | ||
+ | The person responsible for SCM ensures that | ||
+ | those with the assigned responsibility perform | ||
+ | the defined SCM tasks correctly. The software | ||
+ | quality assurance authority, as part of a compliance | ||
+ | auditing activity, might also perform this | ||
+ | surveillance. | ||
+ | The use of integrated SCM tools with process | ||
+ | control capability can make the surveillance | ||
+ | task easier. Some tools facilitate process compliance | ||
+ | while providing flexibility for the software | ||
+ | engineer to adapt procedures. Other tools | ||
+ | enforce process, leaving the software engineer | ||
+ | with less flexibility. Surveillance requirements | ||
+ | and the level of flexibility to be provided to the | ||
+ | software engineer are important considerations | ||
+ | in tool selection. | ||
+ | |||
+ | ====SCM Measures and Measurement==== | ||
+ | {{RightSection|{{referenceLink|number=3|parts=c9s2, c25s2–s3}}}} | ||
+ | SCM measures can be designed to provide specific | ||
+ | information on the evolving product or to | ||
+ | provide insight into the functioning of the SCM | ||
+ | process. A related goal of monitoring the SCM | ||
+ | process is to discover opportunities for process | ||
+ | improvement. Measurements of SCM processes | ||
+ | provide a good means for monitoring the effectiveness | ||
+ | of SCM activities on an ongoing basis. | ||
+ | These measurements are useful in characterizing | ||
+ | the current state of the process as well as in | ||
+ | providing a basis for making comparisons over | ||
+ | time. Analysis of the measurements may produce insights leading to process changes and corresponding | ||
+ | updates to the SCMP. | ||
+ | Software libraries and the various SCM tool | ||
+ | capabilities provide sources for extracting information | ||
+ | about the characteristics of the SCM | ||
+ | process (as well as providing project and management | ||
+ | information). For example, information | ||
+ | about the time required to accomplish various | ||
+ | types of changes would be useful in an evaluation | ||
+ | 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 Software | ||
+ | Engineering Process KA. Software measurement | ||
+ | programs are described in the Software | ||
Engineering Management KA. | Engineering Management KA. | ||
− | + | ||
− | In-Process | + | ====In-Process Audits of SCM==== |
− | Audits | + | {{RightSection|{{referenceLink|number=3|parts=c1s1}}}} |
− | of | + | Audits can be carried out during the software |
− | SCM | + | engineering process to investigate the current status |
− | + | of specific elements of the configuration or to | |
− | Audits can be carried out during the software | + | assess the implementation of the SCM process. |
− | engineering process to investigate the current | + | In-process auditing of SCM provides a more formal |
− | + | mechanism for monitoring selected aspects | |
− | + | of the process and may be coordinated with the | |
− | assess the implementation of the SCM process. | + | SQA function (see topic 5, Software Configuration |
− | In-process auditing of SCM provides a more | + | Auditing). |
− | + | ||
− | + | ==Software Configuration Identification== | |
− | of the process and may be coordinated with the | + | {{RightSection|{{referenceLink|number=2|parts=c8}} {{referenceLink|number=4|parts=c29s1.1}}}} |
− | SQA function (see topic 5, Software | + | |
− | + | Software configuration identification identifies | |
− | + | items to be controlled, establishes identification | |
− | + | schemes for the items and their versions, and | |
− | Software Configuration Identification | + | establishes the tools and techniques to be used in |
− | + | acquiring and managing controlled items. These | |
− | Software | + | activities provide the basis for the other SCM |
− | 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 | + | |
activities. | activities. | ||
− | + | ||
− | Identifying | + | ===Identifying Items to Be Controlled=== |
− | Items | + | {{RightSection|{{referenceLink|number=2|parts=c8s2.2}} {{referenceLink|number=4|parts=c29s1.1}}}} |
− | to | + | One of the first steps in controlling change is |
− | Be | + | identifying the software items to be controlled. |
− | Controlled | + | This involves understanding the software configuration |
− | + | within the context of the system configuration, | |
− | One | + | selecting software configuration items, |
− | identifying the software items to be controlled. | + | developing a strategy for labeling software items |
− | This involves understanding the software | + | and describing their relationships, and identifying |
− | + | both the baselines to be used and the procedure | |
− | + | ||
− | + | ||
− | + | ||
− | 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. | for a baseline’s acquisition of the items. | ||
− | + | ||
− | Software | + | ====Software Configuration==== |
− | Configuration | + | {{RightSection|{{referenceLink|number=1|parts=c3}}}} |
− | + | Software configuration is the functional and physical | |
− | Software | + | characteristics of hardware or software as set |
− | configuration is the functional and | + | forth in technical documentation or achieved in |
− | + | a product. It can be viewed as part of an overall | |
− | + | ||
− | forth in technical documentation or achieved in | + | |
− | a product. It can be viewed as part of an overall | + | |
system configuration. | system configuration. | ||
− | + | ||
− | Software | + | ====Software Configuration Item==== |
− | Configuration | + | {{RightSection|{{referenceLink|number=4|parts=c29s1.1}}}} |
− | Item | + | A configuration item (CI) is an item or aggregation |
− | + | of hardware or software or both that is | |
− | A | + | designed to be managed as a single entity. A software |
− | + | configuration item (SCI) is a software entity | |
− | + | that has been established as a configuration item | |
− | designed to be managed as a single entity. A | + | [1]. The SCM typically controls a variety of items |
− | + | in addition to the code itself. Software items with | |
− | + | potential to become SCIs include plans, specifications | |
− | that has been established as a configuration item | + | and design documentation, testing materials, |
− | [1]. The SCM typically controls a variety of items | + | software tools, source and executable code, |
− | in addition to the code itself. Software items with | + | code libraries, data and data dictionaries, and |
− | potential to become SCIs include plans, | + | documentation for installation, maintenance, |
− | + | operations, and software use. | |
− | + | Selecting SCIs is an important process in | |
− | + | which a balance must be achieved between providing | |
− | + | adequate visibility for project control purposes | |
− | code libraries, data and data dictionaries, and | + | and providing a manageable number of |
− | documentation for installation, maintenance, | + | controlled items. |
− | operations, and software use. | + | |
− | Selecting | + | ====Software Configuration Item Relationships==== |
− | which a balance must be achieved between | + | {{RightSection|{{referenceLink|number=3|parts=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 | |
− | controlled items. | + | changes. Proper tracking of these relationships |
− | + | is also important for supporting traceability. | |
− | Software | + | The design of the identification scheme for SCIs should consider the need to map identified items |
− | Configuration | + | to the software structure, as well as the need to |
− | Item | + | support the evolution of the software items and |
− | Relationships | + | their relationships. |
− | + | ||
− | Structural relationships among the selected | + | ====Software Version==== |
− | SCIs, | + | {{RightSection|{{referenceLink|number=1|parts=c3}} {{referenceLink|number=4|parts=c29s3}}}} |
− | SCM | + | Software items evolve as a software project proceeds. |
− | building or analyzing the impact of proposed | + | A version of a software item is an identified |
− | changes. Proper tracking of these relationships | + | instance of an item. It can be thought of as a |
− | is also important for supporting traceability. | + | state of an evolving item. A variant is a version of |
− | The design of the identification scheme for SCIs | + | a program resulting from the application of software |
− | + | diversity. | |
− | to the software structure, as well as the need to | + | |
− | support the evolution of the software items and | + | ====Baseline==== |
− | their relationships. | + | {{RightSection|{{referenceLink|number=1|parts=c3}}}} |
− | + | A software baseline is a formally approved version | |
− | Software | + | of a configuration item (regardless of media) |
− | Version | + | that is formally designated and fixed at a specific |
− | + | time during the configuration item’s life cycle. | |
− | Software items evolve as a software project | + | The term is also used to refer to a particular version |
− | + | of a software configuration item that has | |
− | + | been agreed on. In either case, the baseline can | |
− | + | only be changed through formal change control | |
− | + | procedures. A baseline, together with all | |
− | state of an evolving item. A variant is a version of | + | approved changes to the baseline, represents the |
− | a program resulting from the application of | + | current approved configuration. Commonly used baselines include functional, |
− | + | allocated, developmental, and product baselines. The functional baseline corresponds | |
− | + | to the reviewed system requirements. The allocated | |
− | + | baseline corresponds to the reviewed | |
− | Baseline | + | software requirements specification and software |
− | + | interface requirements specification. The | |
− | A software baseline is a formally approved | + | developmental baseline represents the evolving |
− | + | software configuration at selected times during | |
− | + | the software life cycle. Change authority for | |
− | that is formally designated and fixed at a specific | + | this baseline typically rests primarily with the |
− | time during the configuration item’s life cycle. | + | development organization but may be shared |
− | The term is also used to refer to a particular | + | with other organizations (for example, SCM or |
− | + | Test). The product baseline corresponds to the | |
− | + | completed software product delivered for system | |
− | been agreed on. In either case, the baseline can | + | integration. The baselines to be used for a |
− | only be changed through formal change | + | given project, along with the associated levels of |
− | + | authority needed for change approval, are typically | |
− | + | identified in the SCMP. | |
− | approved changes to the baseline, represents the | + | |
− | current approved configuration. | + | ====Acquiring Software Configuration Items==== |
− | Commonly used baselines include | + | {{RightSection|{{referenceLink|number=3|parts=c18}}}} |
− | + | Software configuration items are placed under | |
− | + | SCM control at different times; that is, they are | |
− | baselines. The functional baseline corresponds | + | incorporated into a particular baseline at a particular |
− | to the reviewed system requirements. The | + | point in the software life cycle. The triggering |
− | + | event is the completion of some form of formal | |
− | + | acceptance task, such as a formal review. Figure | |
− | software | + | 6.2 characterizes the growth of baselined items as |
− | + | the life cycle proceeds. This figure is based on the | |
− | + | waterfall model for purposes of illustration only; | |
− | developmental baseline represents the evolving | + | the subscripts used in the figure indicate versions of the evolving items. The software change request |
− | software configuration at selected times during | + | |
− | the software life cycle. Change authority for | + | |
− | this baseline typically rests primarily with the | + | |
− | development organization but may be shared | + | |
− | with other organizations (for example, SCM or | + | |
− | Test). The product baseline corresponds to the | + | |
− | completed software product delivered for | + | |
− | + | ||
− | + | ||
− | given project, along with the associated levels of | + | |
− | authority needed for change approval, are | + | |
− | + | ||
− | + | ||
− | + | ||
− | Acquiring | + | |
− | Software | + | |
− | Configuration | + | |
− | Items | + | |
− | + | ||
− | Software | + | |
− | SCM control at different times; that is, they are | + | |
− | incorporated into a particular baseline at a | + | |
− | + | ||
− | + | ||
− | event is the completion of some form of formal | + | |
− | acceptance task, such as a formal review. Figure | + | |
− | 6.2 characterizes the growth of baselined items as | + | |
− | the life cycle proceeds. This figure is based on the | + | |
− | waterfall model for purposes of illustration only; | + | |
− | the subscripts used in the figure indicate versions | + | |
− | + | ||
− | + | ||
− | + | ||
− | of the evolving items. The software change request | + | |
(SCR) is described in section 3.1. | (SCR) is described in section 3.1. | ||
− | In acquiring an SCI, its origin and initial | + | In acquiring an SCI, its origin and initial integrity |
− | + | must be established. Following the acquisition | |
− | + | of an SCI, changes to the item must be formally | |
− | + | approved as appropriate for the SCI and | |
− | + | the baseline involved, as defined in the SCMP. | |
− | + | Following approval, the item is incorporated into | |
− | + | the software baseline according to the appropriate | |
− | the baseline involved, as defined in the SCMP. | + | |
− | Following approval, the item is incorporated into | + | |
− | the software baseline according to the appropriate | + | |
procedure. | procedure. | ||
− | + | [[File:Acquisition of Items.jpg|thumb|400px|frame|Figure 6.2. Acquisition of Items]] | |
− | + | ||
− | Library | + | ===Software Library=== |
− | + | {{RightSection|{{referenceLink|number=3|parts=c1s3}} {{referenceLink|number=4|parts=c29s1.2}}}} | |
− | A software library is a controlled collection of | + | A software library is a controlled collection of |
− | software and related documentation designed to | + | software and related documentation designed to |
− | aid in software development, use, or maintenance | + | aid in software development, use, or maintenance |
− | [1]. It is also instrumental in software release | + | [1]. It is also instrumental in software release management |
− | + | and delivery activities. Several types of | |
− | + | libraries might be used, each corresponding to the | |
− | libraries might be used, each corresponding to the | + | software item’s particular level of maturity. For |
− | software item’s particular level of maturity. For | + | example, a working library could support coding |
− | example, a working library could support coding | + | and a project support library could support testing, |
− | and a project support library could support | + | while a master library could be used for finished |
− | + | products. An appropriate level of SCM control | |
− | + | (associated baseline and level of authority for | |
− | + | change) is associated with each library. Security, | |
− | + | in terms of access control and the backup facilities, | |
− | + | is a key aspect of library management. | |
− | + | The tool(s) used for each library must support | |
− | change) is associated with each library. Security, | + | the SCM control needs for that library — both in |
− | in terms of access control and the backup | + | terms of controlling SCIs and controlling access |
− | + | to the library. At the working library level, this is | |
− | + | a code management capability serving developers, | |
− | The tool(s) used for each library must support | + | maintainers, and SCM. It is focused on managing |
− | the SCM control needs for that | + | the versions of software items while supporting |
− | terms of controlling SCIs and controlling access | + | the activities of multiple developers. At |
− | to the library. At the working library level, this is | + | higher levels of control, access is more restricted |
− | a code management capability serving | + | and SCM is the primary user. |
− | + | These libraries are also an important source | |
− | + | of information for measurements of work and | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | higher levels of control, access is more restricted | + | |
− | and SCM is the primary user. | + | |
− | These libraries are also an important source | + | |
− | of information for measurements of work and | + | |
progress. | progress. | ||
− | + | ||
− | Software Configuration Control | + | ==Software Configuration Control== |
− | + | {{RightSection|{{referenceLink|number=2|parts=c9}} {{referenceLink|number=4|parts=c29s2}}}} | |
− | Software | + | Software configuration control is concerned |
− | with managing changes during the software | + | with managing changes during the software |
− | life cycle. It covers the process for determining | + | life cycle. It covers the process for determining what changes to make, the authority for approving |
− | what changes to make, the authority for | + | certain changes, support for the implementation |
− | + | of those changes, and the concept of formal | |
− | + | deviations from project requirements as well as | |
− | + | waivers of them. Information derived from these | |
− | + | activities is useful in measuring change traffic | |
− | deviations from project requirements as well as | + | |
− | waivers of them. Information derived from these | + | |
− | activities | + | |
and breakage as well as aspects of rework. | and breakage as well as aspects of rework. | ||
− | + | ||
− | Requesting, | + | ===Requesting, Evaluating, and Approving Software Changes=== |
− | Evaluating, | + | {{RightSection|{{referenceLink|number=2|parts=c9s2.4}} {{referenceLink|number=4|parts=c29s2}}}} |
− | and | + | The first step in managing changes to controlled |
− | Approving | + | items is determining what changes to make. The |
− | Software | + | software change request process (see a typical |
− | Changes | + | flow of a change request process in Figure 6.3) |
− | + | provides formal procedures for submitting and | |
− | The first step in managing changes to controlled | + | recording change requests, evaluating the potential |
− | items is determining what changes to make. The | + | cost and impact of a proposed change, and |
− | software change request process (see a typical | + | accepting, modifying, deferring, or rejecting |
− | flow of a change request process in Figure 6.3) | + | the proposed change. A change request (CR) is |
− | provides formal procedures for submitting and | + | a request to expand or reduce the project scope; |
− | recording change requests, evaluating the | + | modify policies, processes, plans, or procedures; |
− | + | modify costs or budgets; or revise schedules | |
− | + | [1]. Requests for changes to software configuration | |
− | accepting, modifying, deferring, or rejecting | + | items may be originated by anyone at any |
− | the proposed change. A change request (CR) is | + | point in the software life cycle and may include |
− | a request to expand or reduce the project scope; | + | a suggested solution and requested priority. One |
− | modify policies, processes, plans, or procedures; | + | source of a CR is the initiation of corrective |
− | modify | + | action in response to problem reports. Regardless |
− | [1]. Requests for changes to software | + | of the source, the type of change (for example, |
− | + | defect or enhancement) is usually recorded on the | |
− | + | ||
− | point in the software life cycle and may include | + | |
− | a suggested solution and requested priority. One | + | |
− | source of a CR is the initiation of corrective | + | |
− | action in response to problem reports. Regardless | + | |
− | of the source, the type of change (for example, | + | |
− | defect or enhancement) is usually recorded on the | + | |
Software CR (SCR). | Software CR (SCR). | ||
− | This provides an opportunity for tracking | + | This provides an opportunity for tracking |
− | defects and collecting change activity | + | defects and collecting change activity measurements |
− | + | by change type. Once an SCR is received, | |
− | + | a technical evaluation (also known as an impact | |
− | a technical evaluation (also known as an impact | + | analysis) is performed to determine the extent of |
− | analysis) is performed to determine the extent of | + | the modifications that would be necessary should |
− | the modifications that would be necessary should | + | the change request be accepted. A good understanding |
− | the change request be accepted. A good | + | of the relationships among software |
− | + | (and, possibly, hardware) items is important for | |
− | + | this task. Finally, an established authority — commensurate | |
− | (and, possibly, hardware) items is important for | + | with the affected baseline, the SCI |
− | this task. Finally, an established | + | involved, and the nature of the change — will |
− | + | evaluate the technical and managerial aspects | |
− | + | of the change request and either accept, modify, | |
− | involved, and the nature of the | + | reject, or defer the proposed change. |
− | evaluate the technical and managerial aspects | + | [[File:Flow of a Change Control Process.jpg|thumb|400px|frame|Figure 6.3. Flow of a Change Control Process]] |
− | of the change request and either accept, modify, | + | |
− | reject, or defer the proposed change. | + | ====Software Configuration Control Board==== |
− | + | {{RightSection|{{referenceLink|number=2|parts=c9s2.2}} {{referenceLink|number=3|parts=c11s1}} {{referenceLink|number=4|parts=c29s2}}}} | |
− | 6 | + | The authority for accepting or rejecting proposed |
− | 3. | + | changes rests with an entity typically known as a |
− | Software | + | Configuration Control Board (CCB). In smaller |
− | Configuration | + | projects, this authority may actually reside with |
− | Control | + | the leader or an assigned individual rather than a |
− | Board | + | multiperson board. There can be multiple levels |
− | + | of change authority depending on a variety of criteria— | |
− | The authority for accepting or rejecting proposed | + | such as the criticality of the item involved, |
− | changes rests with an entity typically known as a | + | the nature of the change (for example, impact on |
− | Configuration Control Board (CCB). In smaller | + | budget and schedule), or the project’s current |
− | projects, this authority may actually reside with | + | point in the life cycle. The composition of the |
− | the leader or an assigned individual rather than a | + | CCBs used for a given system varies depending |
− | multiperson board. There can be multiple levels | + | on these criteria (an SCM representative would |
− | of change authority depending on a variety of | + | always be present). All stakeholders, appropriate |
− | + | to the level of the CCB, are represented. When | |
− | + | the scope of authority of a CCB is strictly software, | |
− | the nature of the change (for example, impact on | + | it is known as a Software Configuration |
− | budget and schedule), or the project’s current | + | Control Board (SCCB). The activities of the CCB |
− | point in the life cycle. The composition of the | + | are typically subject to software quality audit or |
− | CCBs used for a given system varies depending | + | |
− | on these criteria (an SCM representative would | + | |
− | always be present). All stakeholders, appropriate | + | |
− | to the level of the CCB, are represented. When | + | |
− | the scope of authority of a CCB is strictly | + | |
− | + | ||
− | + | ||
− | Control Board (SCCB). The activities of the CCB | + | |
− | are typically subject to software quality audit or | + | |
review. | review. | ||
− | + | ||
− | Software | + | ====Software Change Request Process==== |
− | Change | + | {{RightSection|{{referenceLink|number=3|parts=c1s4, c8s4}}}} |
− | Request | + | An effective software change request (SCR) process |
− | Process | + | requires the use of supporting tools and procedures |
− | + | for originating change requests, enforcing | |
− | An effective software change request (SCR) | + | the flow of the change process, capturing CCB decisions, and reporting change process |
− | + | information. A link between this tool capability | |
− | + | and the problem-reporting system can facilitate | |
− | + | the tracking of solutions for reported problems. | |
− | + | ||
− | + | ===Implementing Software Changes=== | |
− | + | {{RightSection|{{referenceLink|number=4|parts=c29}}}} | |
− | CCB decisions, and reporting change process | + | Approved SCRs are implemented using the |
− | information. A link between this tool capability | + | defined software procedures in accordance with |
− | and the problem-reporting system can facilitate | + | the applicable schedule requirements. Since a |
− | the tracking of solutions for reported problems. | + | number of approved SCRs might be implemented |
− | + | simultaneously, it is necessary to provide a means | |
− | Implementing | + | for tracking which SCRs are incorporated into |
− | Software | + | particular software versions and baselines. As |
− | Changes | + | part of the closure of the change process, completed |
− | + | changes may undergo configuration audits | |
− | Approved SCRs are implemented using the | + | and software quality verification—this includes |
− | defined software procedures in accordance with | + | ensuring that only approved changes have been |
− | the applicable schedule requirements. Since a | + | made. The software change request process |
− | number of approved SCRs might be implemented | + | described above will typically document the |
− | simultaneously, it is necessary to provide a means | + | SCM (and other) approval information for the |
− | for tracking which SCRs are incorporated into | + | change. |
− | particular software versions and baselines. As | + | Changes may be supported by source code version |
− | part of the closure of the change process, | + | control tools. These tools allow a team of |
− | + | software engineers, or a single software engineer, | |
− | + | to track and document changes to the source code. | |
− | and software quality verification—this includes | + | These tools provide a single repository for storing |
− | ensuring that only approved changes have been | + | the source code, can prevent more than one software |
− | made. The software change request process | + | engineer from editing the same module at |
− | described above will typically document the | + | the same time, and record all changes made to the source code. Software engineers check modules |
− | SCM | + | out of the repository, make changes, document |
− | change. | + | the changes, and then save the edited modules |
− | Changes may be supported by source code | + | in the repository. If needed, changes can also be |
− | + | discarded, restoring a previous baseline. More | |
− | + | powerful tools can support parallel development | |
− | software engineers, or a single software engineer, | + | and geographically distributed environments. |
− | to track and document changes to the source code. | + | These tools may be manifested as separate, |
− | These tools provide a single repository for storing | + | specialized applications under the control of an |
− | the source code, can prevent more than one | + | independent SCM group. They may also appear |
− | + | as an integrated part of the software engineering | |
− | + | environment. Finally, they may be as elementary | |
− | the same time, and record all changes made to the | + | as a rudimentary change control system provided |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | source code. Software engineers check modules | + | |
− | out of the repository, make changes, document | + | |
− | the changes, and then save the edited modules | + | |
− | in the repository. If needed, changes can also be | + | |
− | discarded, | + | |
− | powerful tools can support parallel development | + | |
− | and geographically distributed environments. | + | |
− | These tools may be manifested as separate, | + | |
− | specialized applications under the control of an | + | |
− | independent SCM group. They may also appear | + | |
− | as an integrated part of the software engineering | + | |
− | environment. Finally, they may be as elementary | + | |
− | as a rudimentary change control system provided | + | |
with an operating system. | with an operating system. | ||
− | + | ||
− | Deviations | + | ===Deviations and Waivers=== |
− | and | + | {{RightSection|{{referenceLink|number=1|parts=c3}}}} |
− | Waivers | + | The constraints imposed on a software engineering |
− | + | effort or the specifications produced during the | |
− | The constraints imposed on a software | + | development activities might contain provisions |
− | + | that cannot be satisfied at the designated point | |
− | + | in the life cycle. A deviation is a written authorization, | |
− | development activities might contain provisions | + | granted prior to the manufacture of an |
− | that | + | item, to depart from a particular performance or |
− | in the life cycle. A deviation is a written | + | design requirement for a specific number of units |
− | + | or a specific period of time. A waiver is a written | |
− | + | authorization to accept a configuration item or | |
− | item, to depart from a particular performance or | + | other designated item that is found, during production |
− | design requirement for a specific number of units | + | or after having been submitted for inspection, |
− | or a specific period of time. A waiver is a | + | to depart from specified requirements but is nevertheless |
− | + | considered suitable for use as-is or after | |
− | + | rework by an approved method. In these cases, a | |
− | other designated item that is found, during | + | formal process is used for gaining approval for |
− | + | deviations from, or waivers of, the provisions. | |
− | + | ||
− | to depart from specified requirements but is | + | ==Software Configuration Status Accounting== |
− | + | {{RightSection|{{referenceLink|number=2|parts=c10}}}} | |
− | + | Software configuration status accounting (SCSA) | |
− | rework by an approved method. In these cases, a | + | is an element of configuration management consisting |
− | formal process is used for gaining approval for | + | of the recording and reporting of information |
− | deviations from, or waivers of, the provisions. | + | needed to manage a configuration effectively. |
− | + | ||
− | Software Configuration Status Accounting | + | ===Software Configuration Status Information=== |
− | + | {{RightSection|{{referenceLink|number=2|parts=c10s2.1}}}} | |
− | Software configuration status accounting (SCSA) | + | The SCSA activity designs and operates a system |
− | is an element of configuration management | + | for the capture and reporting of necessary |
− | + | information as the life cycle proceeds. As in any information system, the configuration status information | |
− | + | to be managed for the evolving configurations | |
− | + | must be identified, collected, and maintained. | |
− | + | Various information and measurements are needed | |
− | + | to support the SCM process and to meet the configuration | |
− | Software | + | status reporting needs of management, |
− | Configuration | + | software engineering, and other related activities. |
− | Status | + | The types of information available include the |
− | Information | + | approved configuration identification as well as |
− | + | the identification and current implementation status | |
− | The SCSA activity designs and operates a | + | of changes, deviations, and waivers. |
− | + | Some form of automated tool support is necessary | |
− | + | to accomplish the SCSA data collection and | |
− | information as the life cycle proceeds. As in any | + | reporting tasks; this could be a database capability, |
− | information system, the configuration status | + | a stand-alone tool, or a capability of a larger, |
− | + | integrated tool environment. | |
− | + | ||
− | + | ===Software Configuration Status Reporting=== | |
− | + | {{RightSection|{{referenceLink|number=2|parts=c10s2.4}} {{referenceLink|number=3|parts=c1s5, c9s1, c17}}}} | |
− | Various information and measurements are needed | + | Reported information can be used by various |
− | to support the SCM process and to meet the | + | organizational and project elements—including |
− | + | the development team, the maintenance team, | |
− | + | project management, and software quality activities. | |
− | software engineering, and other related activities. | + | Reporting can take the form of ad hoc queries |
− | The types of information available include the | + | to answer specific questions or the periodic |
− | approved | + | production of predesigned reports. Some information |
− | the identification and current implementation | + | produced by the status accounting activity |
− | + | during the course of the life cycle might become | |
− | + | ||
− | Some form of automated tool support is | + | |
− | + | ||
− | + | ||
− | reporting tasks; this could be a database | + | |
− | + | ||
− | + | ||
− | integrated tool environment. | + | |
− | + | ||
− | Software | + | |
− | Configuration | + | |
− | Status | + | |
− | Reporting | + | |
− | + | ||
− | Reported information can be used by various | + | |
− | organizational and project elements—including | + | |
− | the development team, the maintenance team, | + | |
− | project management, and software quality | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | production of predesigned reports. Some | + | |
− | + | ||
− | + | ||
− | during the course of the life cycle might become | + | |
quality assurance records. | quality assurance records. | ||
− | In addition to reporting the current status of the | + | In addition to reporting the current status of the |
− | configuration, | + | configuration, the information obtained by the |
− | SCSA can serve as a basis of various | + | SCSA can serve as a basis of various measurements. |
− | + | Examples include the number of change | |
− | + | requests per SCI and the average time needed to | |
− | requests per SCI and the average time needed to | + | implement a change request. |
− | implement a change request. | + | |
− | + | ==Software Configuration Auditing== | |
− | Software Configuration Auditing | + | {{RightSection|{{referenceLink|number=2|parts=c11}}}} |
− | + | A software audit is an independent examination | |
− | A software audit is an independent | + | of a work product or set of work products to |
− | + | assess compliance with specifications, standards, | |
− | + | contractual agreements, or other criteria [1]. | |
− | assess compliance with specifications, standards, | + | Audits are conducted according to a well-defined |
− | contractual | + | process consisting of various auditor roles and |
− | Audits are conducted according to a well-defined | + | responsibilities. Consequently, each audit must |
− | process consisting of various auditor roles and | + | be carefully planned. An audit can require a number |
− | responsibilities. Consequently, each audit must | + | of individuals to perform a variety of tasks |
− | be carefully planned. An audit can require a | + | over a fairly short period of time. Tools to support the planning and conduct of an audit can greatly |
− | + | ||
− | + | ||
− | over a fairly short period of time. Tools to support | + | |
− | + | ||
− | + | ||
− | the planning and conduct of an audit can greatly | + | |
facilitate the process. | facilitate the process. | ||
− | Software | + | Software configuration auditing determines |
− | the extent to which an item satisfies the required | + | the extent to which an item satisfies the required |
− | functional and physical characteristics. Informal | + | functional and physical characteristics. Informal |
− | audits of this type can be conducted at key points | + | audits of this type can be conducted at key points |
− | in the life cycle. Two types of formal audits might | + | in the life cycle. Two types of formal audits might |
− | be required by the governing contract (for | + | be required by the governing contract (for example, |
− | + | in contracts covering critical software): the | |
− | + | Functional Configuration Audit (FCA) and the | |
− | Functional | + | Physical Configuration Audit (PCA). Successful |
− | Physical Configuration Audit (PCA). Successful | + | completion of these audits can be a prerequisite |
− | completion of these audits can be a prerequisite | + | for the establishment of the product baseline. |
− | for the establishment of the product baseline. | + | |
− | + | ===Software Functional Configuration Audit=== | |
− | Software | + | {{RightSection|{{referenceLink|number=2|parts=c11s2.1}}}} |
− | Functional | + | The purpose of the software FCA is to ensure that |
− | Configuration | + | the audited software item is consistent with its |
− | Audit | + | governing specifications. The output of the software |
− | + | verification and validation activities (see | |
− | The purpose of the software FCA is to ensure that | + | Verification and Validation in the Software Quality |
− | the audited software item is consistent with its | + | KA) is a key input to this audit. |
− | governing specifications. The output of the | + | |
− | + | ===Software Physical Configuration Audit=== | |
− | + | {{RightSection|{{referenceLink|number=2|parts=c11s2.2}}}} | |
− | Verification and Validation in the Software | + | The purpose of the software physical configuration |
− | + | audit (PCA) is to ensure that the design and | |
− | + | reference documentation is consistent with the | |
− | + | ||
− | Software | + | |
− | Physical | + | |
− | Configuration | + | |
− | Audit | + | |
− | + | ||
− | The purpose of the software physical | + | |
− | + | ||
− | + | ||
− | reference documentation is consistent with the | + | |
as-built software product. | as-built software product. | ||
− | + | ||
− | In-Process | + | ===In-Process Audits of a Software Baseline=== |
− | Audits | + | {{RightSection|{{referenceLink|number=2|parts=c11s2.3}}}} |
− | of | + | As mentioned above, audits can be carried out |
− | a | + | during the development process to investigate |
− | Software | + | the current status of specific elements of the configuration. |
− | Baseline | + | In this case, an audit could be applied |
− | + | to sampled baseline items to ensure that performance | |
− | As mentioned above, audits can be carried out | + | is consistent with specifications or to |
− | during the development process to investigate | + | ensure that evolving documentation continues to |
− | the current status of specific elements of the | + | be consistent with the developing baseline item. |
− | + | ||
− | + | ==Software Release Management and Delivery== | |
− | to sampled baseline items to ensure that | + | {{RightSection|{{referenceLink|number=2|parts=c14}} {{referenceLink|number=3|parts=c8s2}}}} |
− | + | In this context, release refers to the distribution | |
− | + | of a software configuration item outside the development activity; this includes internal | |
− | ensure that evolving documentation continues to | + | releases as well as distribution to customers. When |
− | be consistent with the developing baseline item. | + | different versions of a software item are available |
− | + | for delivery (such as versions for different platforms | |
− | Software Release Management and | + | or versions with varying capabilities), it is |
− | Delivery | + | frequently necessary to recreate specific versions |
− | + | and package the correct materials for delivery of | |
− | In | + | the version. The software library is a key element |
− | release | + | |
− | refers to the | + | |
− | + | ||
− | + | ||
− | the | + | |
− | releases as well as distribution to customers. When | + | |
− | different versions of a software item are available | + | |
− | for delivery (such as versions for different | + | |
− | + | ||
− | + | ||
− | frequently necessary to recreate specific versions | + | |
− | and package the correct materials for delivery of | + | |
− | the version. The software library is a key element | + | |
in accomplishing release and delivery tasks. | in accomplishing release and delivery tasks. | ||
− | + | ||
− | Software | + | ===Software Building=== |
− | Building | + | {{RightSection|{{referenceLink|number=4|parts=c29s4}}}} |
− | + | Software building is the activity of combining the | |
− | Software building is the activity of combining the | + | correct versions of software configuration items, |
− | correct versions of software configuration items, | + | using the appropriate configuration data, into an |
− | using the appropriate configuration data, into an | + | executable program for delivery to a customer or |
− | executable program for delivery to a customer or | + | other recipient, such as the testing activity. For |
− | other recipient, such as the testing activity. For | + | systems with hardware or firmware, the executable |
− | systems with hardware or firmware, the executable | + | program is delivered to the system-building activity. |
− | program is delivered to the system-building | + | Build instructions ensure that the proper build |
− | + | steps are taken in the correct sequence. In addition | |
− | + | to building software for new releases, it is usually | |
− | steps are taken in the correct sequence. In addition | + | also necessary for SCM to have the capability to |
− | to building software for new releases, it is usually | + | reproduce previous releases for recovery, testing, |
− | also necessary for SCM to have the capability to | + | |
− | reproduce previous releases for recovery, testing, | + | |
maintenance, or additional release purposes. | maintenance, or additional release purposes. | ||
− | Software is built using particular versions of | + | Software is built using particular versions of |
− | supporting tools, such as compilers (see | + | supporting tools, such as compilers (see Compiler |
− | + | Basics in the Computing Foundations KA). | |
− | + | It might be necessary to rebuild an exact copy of | |
− | It might be necessary to rebuild an exact copy of | + | a previously built software configuration item. In |
− | a previously built software configuration item. In | + | this case, supporting tools and associated build |
− | this case, supporting tools and associated build | + | instructions need to be under SCM control to |
− | instructions | + | ensure availability of the correct versions of the |
− | ensure availability of the correct versions of the | + | tools. |
− | tools. | + | A tool capability is useful for selecting the correct |
− | A tool capability is useful for selecting the | + | versions of software items for a given target |
− | + | environment and for automating the process of | |
− | + | building the software from the selected versions | |
− | environment and for automating the process of | + | and appropriate configuration data. For projects |
− | building the software from the selected versions | + | with parallel or distributed development environments, |
− | and appropriate configuration data. For projects | + | this tool capability is necessary. Most |
− | with parallel or distributed development | + | software engineering environments provide this |
− | + | capability. These tools vary in complexity from | |
− | + | requiring the software engineer to learn a specialized | |
− | software engineering environments provide this | + | scripting language to graphics-oriented |
− | capability. These tools vary in complexity from | + | approaches that hide much of the complexity of |
− | requiring the software engineer to learn a | + | |
− | + | ||
− | + | ||
− | approaches that hide much of the complexity of | + | |
an “intelligent” build facility. | an “intelligent” build facility. | ||
− | The build process and products are often | + | The build process and products are often subject |
− | + | to software quality verification. Outputs of the build process might be needed for future reference | |
− | + | and may become quality assurance records. | |
− | + | ||
− | + | ===Software Release Management=== | |
− | + | {{RightSection|{{referenceLink|number=4|parts=c29s3.2}}}} | |
− | the build process might be needed for future | + | Software release management encompasses the |
− | + | identification, packaging, and delivery of the | |
− | + | elements of a product — for example, an executable | |
− | + | program, documentation, release notes, and | |
− | Software | + | configuration data. Given that product changes |
− | Release | + | can occur on a continuing basis, one concern for |
− | Management | + | release management is determining when to issue |
− | + | a release. The severity of the problems addressed | |
− | Software release management encompasses the | + | by the release and measurements of the fault densities |
− | identification, | + | of prior releases affect this decision. The |
− | elements of a | + | packaging task must identify which product items |
− | + | are to be delivered and then select the correct | |
− | + | variants of those items, given the intended application | |
− | configuration | + | of the product. The information documenting |
− | can occur on a continuing basis, one concern for | + | the physical contents of a release is known |
− | release management is determining when to issue | + | as a version description document. The release |
− | a release. The severity of the problems addressed | + | notes typically describe new capabilities, known |
− | by the release and measurements of the fault | + | problems, and platform requirements necessary |
− | + | for proper product operation. The package to be | |
− | + | released also contains installation or upgrading | |
− | packaging task must identify which product items | + | instructions. The latter can be complicated by the |
− | are to be delivered and then select the correct | + | fact that some current users might have versions |
− | variants of those items, given the intended | + | that are several releases old. In some cases, release |
− | + | management might be required in order to track | |
− | + | distribution of the product to various customers | |
− | + | or target systems — for example, in a case where | |
− | + | the supplier was required to notify a customer of | |
− | as a version description document | + | newly reported problems. Finally, a mechanism |
− | . | + | to ensure the integrity of the released item can be |
− | + | implemented — for example by releasing a digital | |
− | notes typically describe new capabilities, known | + | signature with it. A tool capability is needed for supporting |
− | problems, and platform requirements necessary | + | these release management functions. It is useful |
− | for proper product operation. The package to be | + | to have a connection with the tool capability |
− | released also contains installation or upgrading | + | supporting the change request process in order to |
− | instructions. The latter can be complicated by the | + | map release contents to the SCRs that have been |
− | fact that some current users might have versions | + | received. This tool capability might also maintain |
− | that are several releases old. In some cases, release | + | information on various target platforms and on |
− | management might be required in order to track | + | |
− | distribution of the product to various customers | + | |
− | or target | + | |
− | the supplier was required to notify a customer of | + | |
− | newly reported problems. Finally, a mechanism | + | |
− | to ensure the integrity of the released item can be | + | |
− | + | ||
− | signature with it. | + | |
− | + | ||
− | these | + | |
− | + | ||
− | + | ||
− | supporting the change request process in order to | + | |
− | map release contents to the SCRs that have been | + | |
− | received. This tool capability might also maintain | + | |
− | information on various target platforms and on | + | |
various customer environments. | various customer environments. | ||
− | + | ||
− | Software Configuration Management Tools | + | ==Software Configuration Management Tools== |
− | + | {{RightSection|{{referenceLink|number=3|parts=c26s1}} {{referenceLink|number=4|parts=c8s2}}}} | |
− | When discussing software configuration | + | When discussing software configuration management |
− | + | tools, it is helpful to classify them. SCM | |
− | + | tools can be divided into three classes in terms | |
− | tools can be divided into three classes in terms | + | of the scope at which they provide support: individual |
− | of the scope at which they provide support: | + | support, project-related support, and companywide- |
− | + | process support. | |
− | + | ||
− | - | + | ''Individual support tools'' are appropriate and |
− | + | typically sufficient for small organizations or | |
− | Individual | + | development groups without variants of their |
− | support | + | software products or other complex SCM requirements. |
− | tools | + | They include: |
− | + | ||
− | typically | + | * Version control tools: track, document, and store individual configuration items such as source code and external documentation. |
− | development groups without variants of their | + | * Build handling tools: in their simplest form, such tools compile and link an executable version of the software. More advanced building tools extract the latest version from the version control software, perform quality checks, run regression tests, and produce various forms of reports, among other tasks. |
− | software products or other complex SCM | + | * Change control tools: mainly support the control of change requests and events notification (for example, change request statuschanges, milestones reached). |
− | + | ||
− | + | ''Project-related support tools'' mainly support | |
− | + | workspace management for development teams | |
− | Version control tools: track, document, and | + | and integrators; they are typically able to support |
− | store individual configuration items such as | + | distributed development environments. Such |
− | source code and external documentation. | + | tools are appropriate for medium to large organizations |
− | + | with variants of their software products | |
− | Build handling tools: in their simplest form, | + | and parallel development but no certification |
− | such tools compile and link an executable | + | |
− | version | + | |
− | building tools extract the latest version from | + | |
− | the version control software, perform | + | |
− | + | ||
− | + | ||
− | various forms of reports, among other tasks. | + | |
− | + | ||
− | Change | + | |
− | control of change requests and events | + | |
− | + | ||
− | + | ||
− | + | ||
− | Project-related | + | |
− | support | + | |
− | tools | + | |
− | + | ||
− | workspace management for development teams | + | |
− | and | + | |
− | + | ||
− | + | ||
− | tools are appropriate for medium to large | + | |
− | + | ||
− | + | ||
− | and | + | |
requirements. | requirements. | ||
− | Companywide-process | + | |
− | support | + | ''Companywide-process support tools'' can typically |
− | tools | + | automate portions of a companywide process, |
− | + | providing support for workflow managements, | |
− | + | roles, and responsibilities. They are able | |
− | + | to handle many items, data, and life cycles. Such | |
− | + | tools add to project-related support by supporting | |
− | + | a more formal development process, including | |
− | + | ||
− | + | ||
− | to handle many items, data, and life cycles. Such | + | |
− | tools add to project-related support by supporting | + | |
− | a more formal development process, including | + | |
certification requirements. | certification requirements. | ||
+ | |||
+ | {{EndSection|title=Further Readings|body= | ||
+ | |||
+ | Stephen P. Berczuk and Brad Appleton, | ||
Software Configuration Management | Software Configuration Management | ||
− | + | Patterns: Effective Teamwork, Practical | |
− | + | Integration [6]. | |
− | + | ||
− | + | This book expresses useful SCM practices and | |
− | + | strategies as patterns. The patterns can be implemented | |
− | + | using various tools, but they are expressed | |
− | Patterns: | + | |
− | Effective | + | |
− | Teamwork, | + | |
− | Practical | + | |
− | Integration | + | |
− | + | ||
− | This book expresses useful SCM practices and | + | |
− | strategies as patterns. The patterns can be | + | |
− | + | ||
− | + | ||
in a tool-agnostic fashion. | in a tool-agnostic fashion. | ||
− | “CMMI for Development,” Version 1.3, pp. | + | |
+ | “CMMI for Development,” Version 1.3, pp. | ||
137–147 [7]. | 137–147 [7]. | ||
− | This model presents a collection of best | + | |
− | + | This model presents a collection of best practices | |
− | + | to help software development organizations | |
− | improve their processes. At maturity level 2, it | + | improve their processes. At maturity level 2, it |
suggests configuration management activities. | suggests configuration management activities. | ||
− | + | }} | |
− | + | {{EndSection|title=References|body= | |
− | ISO/IEC/IEEE | + | {{reference |
− | 24765:2010 | + | |number=1 |
− | Systems | + | |author= |
− | and | + | |article= |
− | Software | + | |publication=ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary |
− | Engineering—Vocabulary | + | |edition= |
− | + | |publisher=ISO/IEC/IEEE | |
− | IEC/IEEE | + | |issue= |
− | + | |date=2010 | |
− | IEEE | + | |part= |
− | Std. | + | |link= |
− | 828-2012, | + | }}{{reference |
− | Standard | + | |number=2 |
− | + | |author= | |
− | + | |article= | |
− | Management | + | |publication=IEEE Std. 828-2012, Standard forConfiguration Management in Systems and Software Engineering |
− | in | + | |edition= |
− | Systems | + | |publisher=IEEE |
− | and | + | |issue= |
− | Software | + | |date=2012 |
− | Engineering | + | |part= |
− | + | |link= | |
− | + | }}{{reference | |
− | + | |number=3 | |
− | Management | + | |author=A.M.J Hass |
− | Principles | + | |article= |
− | and | + | |publication=Configuration Management |
− | Practices | + | Principles and Practices |
− | + | |edition=1st ed. | |
− | Wesley | + | |publisher=Addison Wesley |
− | + | |issue= | |
− | + | |date=2003 | |
− | Engineering | + | |part= |
− | , 9th | + | |link= |
− | ed. | + | }} |
− | + | {{reference | |
− | The | + | |number=4 |
− | Road | + | |author=I. Sommerville |
− | Map | + | |article= |
− | to | + | |publication=Software Engineering, 9th ed. |
− | Software | + | |edition=9th ed. |
− | Engineering: | + | |publisher=Addison Wesley |
− | A | + | |issue= |
− | Standards-Based | + | |date=2011 |
− | Guide | + | |part= |
− | + | |link= | |
− | Wiley-IEEE Computer Society Press | + | }} |
− | + | {{reference | |
− | + | |number=5 | |
− | Configuration | + | |author=J.W. Moore |
− | Management | + | |article= |
− | Patterns: | + | |publication=The Road Map to Software |
− | Effective | + | Engineering: A Standards-Based Guide |
− | Teamwork, | + | |edition= |
− | Practical | + | |publisher=Wiley-IEEE Computer Society Press |
− | Integration | + | |issue= |
− | + | |date=2006 | |
− | Addison | + | |part= |
− | + | |link= | |
− | Development, Version 1.3 | + | }}{{reference |
− | Engineering Institute | + | |number=6 |
− | http:// | + | |author=S.P. Berczuk and B. Appleton |
− | resources.sei.cmu.edu/library/asset-view. | + | |article= |
− | cfm?assetID=9661 | + | |publication=Software Configuration Management Patterns: Effective Teamwork, Practical Integration |
+ | |edition= | ||
+ | |publisher=Addison Wesley Professional | ||
+ | |issue= | ||
+ | |date=2003 | ||
+ | |part= | ||
+ | |link= | ||
+ | }}{{reference | ||
+ | |number=7 | ||
+ | |author=CMMI Product Team | ||
+ | |article=CMMI for Development, Version 1.3 | ||
+ | |publication= | ||
+ | |edition= | ||
+ | |publisher=Software Engineering Institute | ||
+ | |issue= | ||
+ | |date=2010 | ||
+ | |part= | ||
+ | |link=http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9661 | ||
+ | }}{{ReferenceList}}}} |
Latest revision as of 11:10, 26 August 2015
Contents
- 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
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 characteristics of hardware or software as set forth in technical 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 management (CM), then, is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling 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 administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance 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 activities, 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 quality 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 planning, 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 project contexts, specific SQA requirements prescribe certain SCM activities.
The SCM activities are management and planning of the SCM process, software configuration identification, software configuration control, software configuration status accounting, software configuration auditing, and software release management and delivery. The Software Configuration Management KA is related to all the other KAs, since the object of configuration management is the artifact produced and used throughout the software engineering process.
The breakdown of topics for the Software Configuration Management KA is shown in Figure 6.1.
1 Management of the SCM Process
SCM controls the evolution and integrity of a product by identifying its elements; managing and controlling change; and verifying, recording, and reporting on configuration information. From the software engineer’s perspective, SCM facilitates development and change implementation activities. A successful SCM implementation requires careful planning and management. This, in turn, requires an understanding of the organizational context for, and the constraints placed on, the design and implementation of the SCM process.
1.1 Organizational Context for SCM
To plan an SCM process for a project, it is necessary to understand the organizational context and the relationships among organizational elements. SCM interacts with several other activities or organizational elements. The organizational elements responsible for the software engineering supporting processes may be structured in various ways. Although the responsibility for performing certain SCM tasks might be assigned to other parts of the organization (such as the development organization), the overall responsibility for SCM often rests with a distinct organizational element or designated individual. Software is frequently developed as part of a larger system containing hardware and firmware elements. In this case, SCM activities take place in parallel with hardware and firmware CM activities and must be consistent with system-level CM. Note that firmware contains hardware and software; therefore, both hardware and software CM concepts are applicable. SCM might interface with an organization’s quality assurance activity on issues such as records management and nonconforming items. Regarding the former, some items under SCM control might also be project records subject to provisions of the organization’s quality assurance program. Managing nonconforming items is usually the responsibility of the quality assurance activity; however, SCM might assist with tracking and reporting on software configuration items falling into this category. Perhaps the closest relationship is with the software development and maintenance organizations. It is within this context that many of the software configuration control tasks are conducted. Frequently, the same tools support development, maintenance, and SCM purposes.
1.2 Constraints and Guidance for the SCM Process
Constraints affecting, and guidance for, the SCM process come from a number of sources. Policies and procedures set forth at corporate or other organizational levels might influence or prescribe the design and implementation of the SCM process for a given project. In addition, the contract between the acquirer and the supplier might contain provisions affecting the SCM process. For example, certain configuration audits might be required, or it might be specified that certain items be placed under CM. When software products to be developed have the potential to affect public safety, external regulatory bodies may impose constraints. Finally, the particular software life cycle process chosen for a software project and the level of formalism selected to implement the software affect the design and implementation of the SCM process. Guidance for designing and implementing an SCM process can also be obtained from “best practice,” as reflected in the standards on software engineering issued by the various standards organizations (see Appendix B on standards).
1.3 Planning for SCM
The planning of an SCM process for a given project should be consistent with the organizational context, applicable constraints, commonly accepted guidance, and the nature of the project (for example, size, safety criticality, and security). The major activities covered are software configuration identification, software configuration control, software configuration status accounting, software configuration auditing, and software release management and delivery. In addition, issues such as organization and responsibilities, resources and schedules, tool selection and implementation, vendor and subcontractor control, and interface control are typically considered. The results of the planning activity are recorded in an SCM Plan (SCMP), which is typically subject to SQA review and audit. Branching and merging strategies should be carefully planned and communicated, since they impact many SCM activities. From an SCM standpoint, a branch is defined as a set of evolving source file versions [1]. Merging consists in combining different changes to the same file [1]. This typically occurs when more than one person changes a configuration item. There are many branching and merging strategies in common use (see the Further Readings section for additional discussion). The software development life cycle model (see Software Life Cycle Models in the Software Engineering Process KA) also impacts SCM activities, and SCM planning should take this into account. For instance, continuous integration is a common practice in many software development approaches. It is typically characterized by frequent build-test-deploy cycles. SCM activities must be planned accordingly.
1.3.1 SCM Organization and Responsibilities
To prevent confusion about who will perform given SCM activities or tasks, organizational 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 authority 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
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 identifying their relationships to the project schedules and milestones established at the project management planning stage. Any training requirements necessary for implementing the plans and training new staff members are also specified.
1.3.3 Tool Selection and Implementation
As for any area of software engineering, the selection and implementation of SCM tools should be carefully planned. The following questions should be considered:
- Organization: what motivates tool acquisition 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 technical 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 introduction 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 capabilities compatible with the planned branching and merging strategies?
- Integration: do the various SCM tools integrate 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 complete history of the configuration items it contains?
SCM typically requires a set of tools, as opposed to a single tool. Such tool sets are sometimes referred to as workbenches. In such a context, another important consideration in planning for tool selection is determining if the SCM workbench will be open (in other words, tools from different suppliers will be used in different 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 Management Tools).
1.3.4 Vendor/Subcontractor Control
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 configuration control (for example, integrated into the project 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 compliance need to be established. The latter includes consideration of what SCM information must be available for effective compliance monitoring.
1.3.5 Interface Control
When a software item will interface with another software or hardware item, a change to either item can affect the other. Planning for the SCM process considers how the interfacing items will be identified and how changes to the items will be managed and communicated. The SCM role may be part of a larger, system-level process for interface specification and control; it may involve interface specifications, interface control plans, and interface control documents. In this case, SCM planning for interface control takes place within the context of the systemlevel process.
1.4 SCM Plan
The results of SCM planning for a given project are recorded in a software configuration management plan (SCMP), a “living document” which serves as a reference for the SCM process. It is maintained (that is, updated and approved) as necessary during the software life cycle. In implementing the SCMP, it is typically necessary to develop a number of more detailed, subordinate procedures defining how specific requirements will be carried out during day-to-day activities— for example, which branching strategies will be used and how frequently builds occur and automated tests of all kinds are run. Guidance on the creation and maintenance of an SCMP, based on the information produced by the planning activity, is available from a number of sources, such as [2*]. This reference provides requirements for the information to be contained in an SCMP; it also defines and describes six categories of SCM information to be included in an SCMP:
- Introduction (purpose, scope, terms used)
- SCM Management (organization, responsibilities,authorities, applicable policies, directives, and procedures)
- A software project might acquire or make use of SCM Activities (configuration identification, configuration control, and so on)
- SCM Schedules (coordination with other project activities)
- SCM Resources (tools, physical resources, and human resources)
- SCMP Maintenance.
1.5 Surveillance of Software Configuration Management
After the SCM process has been implemented, some degree of surveillance may be necessary to ensure that the provisions of the SCMP are properly carried out. There are likely to be specific SQA requirements for ensuring compliance with specified SCM processes and procedures. The person responsible for SCM ensures that those with the assigned responsibility perform the defined SCM tasks correctly. The software quality assurance authority, as part of a compliance auditing activity, might also perform this surveillance. The use of integrated SCM tools with process control capability can make the surveillance task easier. Some tools facilitate process compliance while providing flexibility for the software engineer to adapt procedures. Other tools enforce process, leaving the software engineer with less flexibility. Surveillance requirements and the level of flexibility to be provided to the software engineer are important considerations in tool selection.
1.5.1 SCM Measures and Measurement
SCM measures can be designed to provide specific information on the evolving product or to provide insight into the functioning of the SCM process. A related goal of monitoring the SCM process is to discover opportunities for process improvement. Measurements of SCM processes provide a good means for monitoring the effectiveness of SCM activities on an ongoing basis. These measurements are useful in characterizing the current state of the process as well as in providing a basis for making comparisons over time. Analysis of the measurements may produce insights leading to process changes and corresponding updates to the SCMP. Software libraries and the various SCM tool capabilities provide sources for extracting information about the characteristics of the SCM process (as well as providing project and management information). For example, information about the time required to accomplish various types of changes would be useful in an evaluation 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 Software Engineering Process KA. Software measurement programs are described in the Software Engineering Management KA.
1.5.2 In-Process Audits of SCM
Audits can be carried out during the software engineering process to investigate the current status of specific elements of the configuration or to assess the implementation of the SCM process. In-process auditing of SCM provides a more formal mechanism for monitoring selected aspects of the process and may be coordinated with the SQA function (see topic 5, Software Configuration Auditing).
2 Software Configuration Identification
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
One of the first steps in controlling change is identifying the software items to be controlled. This involves understanding the software configuration within the context of the system configuration, 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
Software configuration is the functional and physical 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
A configuration item (CI) is an item or aggregation of hardware or software or both that is designed to be managed as a single entity. A software 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, specifications and design documentation, testing materials, 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 providing adequate visibility for project control purposes and providing a manageable number of controlled items.
2.1.3 Software Configuration Item Relationships
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 should consider the need to map identified items to the software structure, as well as the need to support the evolution of the software items and their relationships.
2.1.4 Software Version
Software items evolve as a software project proceeds. A version of a software item is an identified instance of an item. It can be thought of as a state of an evolving item. A variant is a version of a program resulting from the application of software diversity.
2.1.5 Baseline
A software baseline is a formally approved version of a configuration item (regardless of media) that is formally designated and fixed at a specific time during the configuration item’s life cycle. The term is also used to refer to a particular version of a software configuration item that has been agreed on. In either case, the baseline can only be changed through formal change control procedures. A baseline, together with all approved changes to the baseline, represents the current approved configuration. Commonly used baselines include functional, allocated, developmental, and product baselines. The functional baseline corresponds to the reviewed system requirements. The allocated baseline corresponds to the reviewed software requirements specification and software interface requirements specification. The developmental baseline represents the evolving software configuration at selected times during the software life cycle. Change authority for this baseline typically rests primarily with the development organization but may be shared with other organizations (for example, SCM or Test). The product baseline corresponds to the completed software product delivered for system integration. The baselines to be used for a given project, along with the associated levels of authority needed for change approval, are typically identified in the SCMP.
2.1.6 Acquiring Software Configuration Items
Software configuration items are placed under SCM control at different times; that is, they are incorporated into a particular baseline at a particular point in the software life cycle. The triggering event is the completion of some form of formal acceptance task, such as a formal review. Figure 6.2 characterizes the growth of baselined items as the life cycle proceeds. This figure is based on the waterfall model for purposes of illustration only; the subscripts used in the figure indicate versions of the evolving items. The software change request (SCR) is described in section 3.1. In acquiring an SCI, its origin and initial integrity must be established. Following the acquisition of an SCI, changes to the item must be formally approved as appropriate for the SCI and the baseline involved, as defined in the SCMP. Following approval, the item is incorporated into the software baseline according to the appropriate procedure.
2.2 Software Library
A software library is a controlled collection of software and related documentation designed to aid in software development, use, or maintenance [1]. It is also instrumental in software release management and delivery activities. Several types of libraries might be used, each corresponding to the software item’s particular level of maturity. For example, a working library could support coding and a project support library could support testing, while a master library could be used for finished products. An appropriate level of SCM control (associated baseline and level of authority for change) is associated with each library. Security, in terms of access control and the backup facilities, is a key aspect of library management. The tool(s) used for each library must support the SCM control needs for that library — both in terms of controlling SCIs and controlling access to the library. At the working library level, this is a code management capability serving developers, maintainers, and SCM. It is focused on managing the versions of software items while supporting the activities of multiple developers. At higher levels of control, access is more restricted and SCM is the primary user. These libraries are also an important source of information for measurements of work and progress.
3 Software Configuration Control
Software configuration control is concerned with managing changes during the software life cycle. It covers the process for determining what changes to make, the authority for approving certain changes, support for the implementation of those changes, and the concept of formal deviations from project requirements as well as waivers of them. Information derived from these activities is useful in measuring change traffic and breakage as well as aspects of rework.
3.1 Requesting, Evaluating, and Approving Software Changes
The first step in managing changes to controlled items is determining what changes to make. The software change request process (see a typical flow of a change request process in Figure 6.3) provides formal procedures for submitting and recording change requests, evaluating the potential cost and impact of a proposed change, and accepting, modifying, deferring, or rejecting the proposed change. A change request (CR) is a request to expand or reduce the project scope; modify policies, processes, plans, or procedures; modify costs or budgets; or revise schedules [1]. Requests for changes to software configuration items may be originated by anyone at any point in the software life cycle and may include a suggested solution and requested priority. One source of a CR is the initiation of corrective action in response to problem reports. Regardless of the source, the type of change (for example, defect or enhancement) is usually recorded on the Software CR (SCR). This provides an opportunity for tracking defects and collecting change activity measurements by change type. Once an SCR is received, a technical evaluation (also known as an impact analysis) is performed to determine the extent of the modifications that would be necessary should the change request be accepted. A good understanding of the relationships among software (and, possibly, hardware) items is important for this task. Finally, an established authority — commensurate with the affected baseline, the SCI involved, and the nature of the change — will evaluate the technical and managerial aspects of the change request and either accept, modify, reject, or defer the proposed change.
3.1.1 Software Configuration Control Board
The authority for accepting or rejecting proposed changes rests with an entity typically known as a Configuration Control Board (CCB). In smaller projects, this authority may actually reside with the leader or an assigned individual rather than a multiperson board. There can be multiple levels of change authority depending on a variety of criteria— such as the criticality of the item involved, the nature of the change (for example, impact on budget and schedule), or the project’s current point in the life cycle. The composition of the CCBs used for a given system varies depending on these criteria (an SCM representative would always be present). All stakeholders, appropriate to the level of the CCB, are represented. When the scope of authority of a CCB is strictly software, it is known as a Software Configuration Control Board (SCCB). The activities of the CCB are typically subject to software quality audit or review.
3.1.2 Software Change Request Process
An effective software change request (SCR) process requires the use of supporting tools and procedures for originating change requests, enforcing the flow of the change process, capturing CCB decisions, and reporting change process information. A link between this tool capability and the problem-reporting system can facilitate the tracking of solutions for reported problems.
3.2 Implementing Software Changes
Approved SCRs are implemented using the defined software procedures in accordance with the applicable schedule requirements. Since a number of approved SCRs might be implemented simultaneously, it is necessary to provide a means for tracking which SCRs are incorporated into particular software versions and baselines. As part of the closure of the change process, completed changes may undergo configuration audits and software quality verification—this includes ensuring that only approved changes have been made. The software change request process described above will typically document the SCM (and other) approval information for the change. Changes may be supported by source code version control tools. These tools allow a team of software engineers, or a single software engineer, to track and document changes to the source code. These tools provide a single repository for storing the source code, can prevent more than one software engineer from editing the same module at the same time, and record all changes made to the source code. Software engineers check modules out of the repository, make changes, document the changes, and then save the edited modules in the repository. If needed, changes can also be discarded, restoring a previous baseline. More powerful tools can support parallel development and geographically distributed environments. These tools may be manifested as separate, specialized applications under the control of an independent SCM group. They may also appear as an integrated part of the software engineering environment. Finally, they may be as elementary as a rudimentary change control system provided with an operating system.
3.3 Deviations and Waivers
The constraints imposed on a software engineering effort or the specifications produced during the development activities might contain provisions that cannot be satisfied at the designated point in the life cycle. A deviation is a written authorization, granted prior to the manufacture of an item, to depart from a particular performance or design requirement for a specific number of units or a specific period of time. A waiver is a written authorization to accept a configuration item or other designated item that is found, during production or after having been submitted for inspection, to depart from specified requirements but is nevertheless considered suitable for use as-is or after rework by an approved method. In these cases, a formal process is used for gaining approval for deviations from, or waivers of, the provisions.
4 Software Configuration Status Accounting
Software configuration status accounting (SCSA) is an element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively.
4.1 Software Configuration Status Information
The SCSA activity designs and operates a system for the capture and reporting of necessary information as the life cycle proceeds. As in any information system, the configuration status information to be managed for the evolving configurations must be identified, collected, and maintained. Various information and measurements are needed to support the SCM process and to meet the configuration status reporting needs of management, software engineering, and other related activities. The types of information available include the approved configuration identification as well as the identification and current implementation status of changes, deviations, and waivers. Some form of automated tool support is necessary to accomplish the SCSA data collection and reporting tasks; this could be a database capability, a stand-alone tool, or a capability of a larger, integrated tool environment.
4.2 Software Configuration Status Reporting
Reported information can be used by various organizational and project elements—including the development team, the maintenance team, project management, and software quality activities. Reporting can take the form of ad hoc queries to answer specific questions or the periodic production of predesigned reports. Some information produced by the status accounting activity during the course of the life cycle might become quality assurance records. In addition to reporting the current status of the configuration, the information obtained by the SCSA can serve as a basis of various measurements. Examples include the number of change requests per SCI and the average time needed to implement a change request.
5 Software Configuration Auditing
A software audit is an independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria [1]. Audits are conducted according to a well-defined process consisting of various auditor roles and responsibilities. Consequently, each audit must be carefully planned. An audit can require a number of individuals to perform a variety of tasks over a fairly short period of time. Tools to support the planning and conduct of an audit can greatly facilitate the process. Software configuration auditing determines the extent to which an item satisfies the required functional and physical characteristics. Informal audits of this type can be conducted at key points in the life cycle. Two types of formal audits might be required by the governing contract (for example, in contracts covering critical software): the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA). Successful completion of these audits can be a prerequisite for the establishment of the product baseline.
5.1 Software Functional Configuration Audit
The purpose of the software FCA is to ensure that the audited software item is consistent with its governing specifications. The output of the software verification and validation activities (see Verification and Validation in the Software Quality KA) is a key input to this audit.
5.2 Software Physical Configuration Audit
The purpose of the software physical configuration audit (PCA) is to ensure that the design and reference documentation is consistent with the as-built software product.
5.3 In-Process Audits of a Software Baseline
As mentioned above, audits can be carried out during the development process to investigate the current status of specific elements of the configuration. In this case, an audit could be applied to sampled baseline items to ensure that performance is consistent with specifications or to ensure that evolving documentation continues to be consistent with the developing baseline item.
6 Software Release Management and Delivery
In this context, release refers to the distribution of a software configuration item outside the development activity; this includes internal releases as well as distribution to customers. When different versions of a software item are available for delivery (such as versions for different platforms or versions with varying capabilities), it is frequently necessary to recreate specific versions and package the correct materials for delivery of the version. The software library is a key element in accomplishing release and delivery tasks.
6.1 Software Building
Software building is the activity of combining the correct versions of software configuration items, using the appropriate configuration data, into an executable program for delivery to a customer or other recipient, such as the testing activity. For systems with hardware or firmware, the executable program is delivered to the system-building activity. Build instructions ensure that the proper build steps are taken in the correct sequence. In addition to building software for new releases, it is usually also necessary for SCM to have the capability to reproduce previous releases for recovery, testing, maintenance, or additional release purposes. Software is built using particular versions of supporting tools, such as compilers (see Compiler Basics in the Computing Foundations KA). It might be necessary to rebuild an exact copy of a previously built software configuration item. In this case, supporting tools and associated build instructions need to be under SCM control to ensure availability of the correct versions of the tools. A tool capability is useful for selecting the correct versions of software items for a given target environment and for automating the process of building the software from the selected versions and appropriate configuration data. For projects with parallel or distributed development environments, this tool capability is necessary. Most software engineering environments provide this capability. These tools vary in complexity from requiring the software engineer to learn a specialized scripting language to graphics-oriented approaches that hide much of the complexity of an “intelligent” build facility. The build process and products are often subject to software quality verification. Outputs of the build process might be needed for future reference and may become quality assurance records.
6.2 Software Release Management
Software release management encompasses the identification, packaging, and delivery of the elements of a product — for example, an executable program, documentation, release notes, and configuration data. Given that product changes can occur on a continuing basis, one concern for release management is determining when to issue a release. The severity of the problems addressed by the release and measurements of the fault densities of prior releases affect this decision. The packaging task must identify which product items are to be delivered and then select the correct variants of those items, given the intended application of the product. The information documenting the physical contents of a release is known as a version description document. The release notes typically describe new capabilities, known problems, and platform requirements necessary for proper product operation. The package to be released also contains installation or upgrading instructions. The latter can be complicated by the fact that some current users might have versions that are several releases old. In some cases, release management might be required in order to track distribution of the product to various customers or target systems — for example, in a case where the supplier was required to notify a customer of newly reported problems. Finally, a mechanism to ensure the integrity of the released item can be implemented — for example by releasing a digital signature with it. A tool capability is needed for supporting these release management functions. It is useful to have a connection with the tool capability supporting the change request process in order to map release contents to the SCRs that have been received. This tool capability might also maintain information on various target platforms and on various customer environments.
7 Software Configuration Management Tools
When discussing software configuration management tools, it is helpful to classify them. SCM tools can be divided into three classes in terms of the scope at which they provide support: individual support, project-related support, and companywide- process support.
Individual support tools are appropriate and typically sufficient for small organizations or development groups without variants of their software products or other complex SCM requirements. They include:
- Version control tools: track, document, and store individual configuration items such as source code and external documentation.
- Build handling tools: in their simplest form, such tools compile and link an executable version of the software. More advanced building tools extract the latest version from the version control software, perform quality checks, run regression tests, and produce various forms of reports, among other tasks.
- Change control tools: mainly support the control of change requests and events notification (for example, change request statuschanges, milestones reached).
Project-related support tools mainly support workspace management for development teams and integrators; they are typically able to support distributed development environments. Such tools are appropriate for medium to large organizations with variants of their software products and parallel development but no certification requirements.
Companywide-process support tools can typically automate portions of a companywide process, providing support for workflow managements, roles, and responsibilities. They are able to handle many items, data, and life cycles. Such tools add to project-related support by supporting a more formal development process, including certification requirements.
Stephen P. Berczuk and Brad Appleton, Software Configuration Management Patterns: Effective Teamwork, Practical Integration [6].
This book expresses useful SCM practices and strategies as patterns. The patterns can be implemented using various tools, but they are expressed in a tool-agnostic fashion.
“CMMI for Development,” Version 1.3, pp. 137–147 [7].
This model presents a collection of best practices to help software development organizations improve their processes. At maturity level 2, it suggests configuration management activities.
[1] ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/IEC/IEEE, 2010.
[2] IEEE Std. 828-2012, Standard forConfiguration Management in Systems and Software Engineering, IEEE, 2012.
[3] A.M.J Hass, Configuration Management
Principles and Practices, 1st ed., Addison Wesley, 2003.
[4] I. Sommerville, Software Engineering, 9th ed., 9th ed., Addison Wesley, 2011.
[5] J.W. Moore, The Road Map to Software
Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006.
[6] S.P. Berczuk and B. Appleton, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Addison Wesley Professional, 2003.
[7] CMMI Product Team, "CMMI for Development, Version 1.3", Software Engineering Institute, 2010, http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9661.