commit - 701b64df7b83e0a2f4636ef1b3f54a181dd89dfa
commit + ebd51ffce5c8b80f223e558695b88fadea00c513
blob - dbbef9fd7cebf92e8de7005fb9b26e8f1a9dc3a5
blob + 51103d23cbb2ca8a1a69123f6956bf8552683eb6
--- 6_software_configuration_management.md
+++ 6_software_configuration_management.md
-**CHAPTER 6**
+## Chapter 6: Software Configuration Management
-**SOFTWARE CONFIGURATION MANAGEMENT**
+**Acronyms**
-##### ACRONYMS
-
CCB Configuration Control Board
CM Configuration Management
FCA Functional Configuration Audit
SQA Software Quality Assurance
SRS Software Requirement Specification
-##### INTRODUCTION
+**Introduction**
A system can be defined as the combination of interacting elements organized to
achieve one or more stated purposes [1]. The configuration of a system is the
-functional and physical 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 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
+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.
+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
The breakdown of topics for the Software Configuration Management KA is shown
in Figure 6.1.
-**1. Management of the SCM Process**
+### 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
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
-[2*, c6, ann. D] [3*, introduction] [4*, c29]
+#### 1.1. Organizational Context for SCM
+<!-- [2*, c6, ann. D] [3*, introduction] [4*, c29] -->
+
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.
containing hardware and firmware elements. In this case, SCM activities take
place
-Figure 6.1. Breakdown of Topics for the Software Configuration Management KA
+
in parallel with hardware and firmware CM activities and must be consistent
with system-level CM. Note that firmware contains hardware and software;
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_
-[2, c6, ann. D, ann. E] [3, c2, c5]
-[5, c19s2.2]
+#### 1.2. Constraints and Guidance for the SCM Process_
+<!-- [2, c6, ann. D, ann. E] [3, c2, c5] [5, c19s2.2] -->
+
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.
+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
-1.3. Planning for SCM
-[2, c6, ann. D, ann. E] [3, c23] [4, c29]
+<!-- [2, c6, ann. D, ann. E] [3, c23] [4, c29] -->
The planning of an SCM process for a given project should be consistent with
the organizational context, applicable constraints, commonly accepted
characterized by frequent build-test-deploy cycles. SCM activities must be
planned accordingly.
-1.3.1. SCM Organization and Responsibilities
-[2, ann. Ds5, ann. Ds6] [3, c10-11]
-[4, introduction, c29]
+##### 1.3.1. SCM Organization and Responsibilities
+<!-- [2, ann. Ds5, ann. Ds6] [3, c10-11] [4, 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
should also be identified, although this might be accomplished at the project
management or quality assurance planning stage.
-1.3.2. SCM Resources and Schedules
-[2, ann. Ds8] [3, c23]
+##### 1.3.2. SCM Resources and Schedules
+<!-- [2, ann. Ds8] [3, c23] -->
+
Planning for SCM identifies the staff and tools involved in carrying out SCM
activities and tasks. It addresses scheduling questions by establishing
necessary sequences of SCM tasks and 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.
+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
-[3, c26s2, c26s6] [4, c29s5]
+##### 1.3.3. Tool Selection and Implementation
+<!-- [3, c26s2, c26s6] [4, c29s5] -->
+
As for any area of software engineering, the selection and implementation of
SCM tools should be carefully planned. The following questions should be
considered:
- Organization: what motivates tool acquisition from an organizational
-perspective?
+ perspective?
- Tools: can we use commercial tools or develop them ourselves?
- Environment: what are the constraints imposed by the organization and its
-technical context?
+ technical context?
- Legacy: how will projects use (or not) the new tools?
- Financing: who will pay for the tools’ acquisition, maintenance, training,
-and customization?
+ and customization?
- Scope: how will the new tools be deployed— for instance, through the entire
-organization or only on specific projects?
+ 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?
+- 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
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
-[2, c13] [3, c13s9, c14s2]
+##### 1.3.4. Vendor/Subcontractor Control
+<!-- [2, c13] [3, c13s9, c14s2] -->
+
A software project might acquire or make use of purchased software products,
such as compilers or other tools. SCM planning considers if and how these items
will be taken under configuration control (for example, integrated into the
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.
+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
-[2, c12] [3, c24s4]
+##### 1.3.5. Interface Control
+<!-- [2, c12] [3, c24s4] -->
+
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
documents. In this case, SCM planning for interface control takes place within
the context of the system-level process.
-_1.4. SCM Plan_
-[2, ann. D] [3, c23] [4, c29s1]
+#### 1.4. SCM Plan
+<!-- [2, ann. D] [3, c23] [4, c29s1] -->
+
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)
- Introduction (purpose, scope, terms used)
- SCM Management (organization, responsibilities, authorities, applicable
-policies, directives, and procedures)
+ policies, directives, and procedures)
- 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.
+ 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
-[3, c11s3]
+#### 1.5. Surveillance of Software Configuration Management
+
+<!--[3, 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.
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
-[3, c9s2, c25s2–s3]
+##### 1.5.1. SCM Measures and Measurement
+<!-- [3, 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
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
-[3, c1s1]
+##### 1.5.2. In-Process Audits of SCM
+<!-- [3, c1s1] -->
+
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. Inprocess 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
+investigate the current status of specific elements of the configuration or to
+assess the implementation of the SCM process. Inprocess 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**
- [2*, c8] [4*, c29s1.1]
+### 2. Software Configuration Identification
+<!-- [2*, c8] [4*, c29s1.1] -->
+
Software configuration identification identifies items to be controlled,
establishes identification schemes for the items and their versions, and
establishes the tools and techniques to be used in acquiring and managing
controlled items. These activities provide the basis for the other SCM
activities.
-_2.1. Identifying Items to Be Controlled_
-[2, c8s2.2] [4, c29s1.1]
+#### 2.1. Identifying Items to Be Controlled
+<!-- [2, c8s2.2] [4, c29s1.1] -->
+
One of the first steps in controlling change is identifying the software items
to be controlled.
identifying both the baselines to be used and the procedure for a baseline’s
acquisition of the items.
-2.1.1. Software Configuration
-[1, c3]
+##### 2.1.1. Software Configuration
+<!-- [1, c3] -->
+
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
-[4, c29s1.1]
+##### 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
+<!-- [4, c29s1.1] -->
+
+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
between providing adequate visibility for project control purposes and
providing a manageable number of controlled items.
-2.1.3. Software Configuration Item
-Relationships
-[3, c7s4]
+##### 2.1.3. Software Configuration Item Relationships
+<!-- [3, c7s4] -->
+
Structural relationships among the selected SCIs, and their constituent parts,
affect other SCM activities or tasks, such as software building or analyzing
the impact of proposed changes. Proper tracking of these relationships is also
important for supporting traceability. The design of the identification scheme
for SCIs 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.
+structure, as well as the need to support the evolution of the software
+items and their relationships.
-2.1.4. Software Version
-[1, c3] [4, c29s3]
+##### 2.1.4. Software Version
+<!-- [1, c3] [4, c29s3] -->
+
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
-[1, c3]
+##### 2.1.5. Baseline
+<!-- [1, c3] -->
+
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
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
-[3, c18]
+##### 2.1.6. Acquiring Software Configuration Items
+<!-- [3, c18] -->
+
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
figure is based on the waterfall model for purposes of illustration only; the
subscripts used in the figure indicate versions
-Figure 6.2. Acquisition of Items
+
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
defined in the SCMP. Following approval, the item is incorporated into the
software baseline according to the appropriate procedure.
-_2.2. Software Library_
-[3, c1s3] [4, c29s1.2]
+#### 2.2. Software Library
+<!-- [3, c1s3] [4, c29s1.2] -->
+
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.
+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**
- [2, c9] [4, c29s2]
+### 3. Software Configuration Control
+<!-- [2, c9] [4, c29s2] -->
+
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
activities is useful in measuring change traffic and breakage as well as
aspects of rework.
-3.1. Requesting, Evaluating, and Approving Software Changes
-[2*, c9s2.4] [4*, c29s2]
+#### 3.1. Requesting, Evaluating, and Approving Software Changes
+<!-- [2*, c9s2.4] [4*, c29s2] -->
+
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
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.
+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
-[2, c9s2.2] [3, c11s1] [4, c29s2]
+##### 3.1.1. Software Configuration Control Board
+<!-- [2, c9s2.2] [3, c11s1] [4, c29s2] -->
+
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
+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
(SCCB). The activities of the CCB are typically subject to software quality
audit or review.
-3.1.2. Software Change Request Process
-[3, c1s4, c8s4]
+##### 3.1.2. Software Change Request Process
+<!-- [3, c1s4, c8s4] -->
+
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
problem-reporting system can facilitate the tracking of solutions for reported
problems.
-3.2. Implementing Software Changes
-[4, c29]
+#### 3.2. Implementing Software Changes
+<!-- [4, c29] -->
+
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
+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.
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
-Figure 6.3. Flow of a Change Control Process
+
source code. Software engineers check modules out of the repository, make
changes, document the changes, and then save the edited modules in the
environment. Finally, they may be as elementary as a rudimentary change control
system provided with an operating system.
-_3.3. Deviations and Waivers_
-[1, c3]
+#### 3.3. Deviations and Waivers
+<!-- [1, c3] -->
+
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.
process is used for gaining approval for deviations from, or waivers of, the
provisions.
-**4. Software Configuration Status Accounting**
- [2*, c10]
+### 4. Software Configuration Status Accounting
+<!-- [2*, c10] -->
+
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.
+management consisting of the recording and reporting of information needed to
+manage a configuration effectively.
-_4.1. Software Configuration Status Information_
-[2, c10s2.1]
+#### 4.1. Software Configuration Status Information
+<!-- [2, c10s2.1] -->
+
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
and reporting tasks; this could be a database capability, a standalone tool,
or a capability of a larger, integrated tool environment.
-4.2. Software Configuration Status Reporting
-[2, c10s2.4] [3, c1s5, c9s1, c17]
+#### 4.2. Software Configuration Status Reporting
+<!-- [2, c10s2.4] [3, c1s5, c9s1, c17] -->
+
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
Examples include the number of change requests per SCI and the average time
needed to implement a change request.
-**5. Software Configuration Auditing**
- [2, c11]
+### 5. Software Configuration Auditing
+<!-- [2, c11] -->
+
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
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_
-[2, c11s2.1]
+#### 5.1. Software Functional Configuration Audit
+<!-- [2, c11s2.1] -->
+
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_
-[2, c11s2.2]
+#### 5.2. Software Physical Configuration Audit
+<!--[2, c11s2.2] -->
+
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_
-[2, c11s2.3]
+#### 5.3. In-Process Audits of a Software Baseline
+<!-- [2, c11s2.3] -->
+
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**
- [2, c14] [3, c8s2]
+### 6. Software Release Management and Delivery
+<!-- [2, c14] [3, c8s2] -->
+
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
the version. The software library is a key element in accomplishing release and
delivery tasks.
-6.1. Software Building
-[4, c29s4]
+#### 6.1. Software Building
+<!-- [4, c29s4] -->
+
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
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,
+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.
verification. Outputs of the build process might be needed for future reference
and may become quality assurance records.
-_6.2. Software Release Management_
-[4, c29s3.2]
+#### 6.2. Software Release Management
+<!--[4, c29s3.2] -->
+
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
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_._
+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
+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
+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.
been received. This tool capability might also maintain information on various
target platforms and on various customer environments.
-**7. Software Configuration Management Tools**
- [3, c26s1] [4, c8s2]
+### 7. Software Configuration Management Tools
+<!-- [3, c26s1] [4, c8s2] -->
+
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
+_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.
+ 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.
+ 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 status changes, milestones
-reached).
+ events notification (for example, change request status changes, milestones
+ reached).
-Project-related support tools mainly support workspace management for
+_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 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.
-##### MATRIX OF TOPICS VS. REFERENCE MATERIAL
+### Matrix of topics vs. Reference material
-##### IEEE 828-2012
+IEEE 828-2012
-##### [2]
+[2]
Hass 2003
-##### [3]
+[3]
Moore 2006
-##### [5]
+[5]
Sommerville 2011
-##### [4]
+[4]
-**1. Management of the SCM
-Process**
- 1.1. Organizational Context for
- SCM
- c6, ann.D introduction c29
+**1. Management of the SCM Process**
+ 1.1. Organizational Context for SCM c6, ann.D introduction c29
+ 1.2. Constraints and Guidance for the SCM Process c6, ann.D, ann.E c2 c19s2.2 c29 intro
+ 1.3. Planning for SCM c6, ann.D, ann.E c23 c29
+ 1.3.1. SCM Organization and Responsibilities ann.Ds5–6 c10–11 c29 intro
+ 1.3.2. SCM Resources and Schedules ann.Ds8 c23
+ 1.3.3. Tool Selection and Implementation c26s2; s6 c29s5
+ 1.3.4. Vendor/Subcontractor Control c13 c13s9–c14s2
+ 1.3.5. Interface Control c12 c24s4
+ 1.4. SCM Plan ann.D c23 c29s1
+ 1.5. Surveillance of Software Configuration Management c11s3
+ 1.5.1. SCM Measures and Measurement c9s2; c25s2–s3
+ 1.5.2. In-Process Audits of SCM c1s1
+**2. Software Configuration Identification** c29s1.1
+ 2.1. Identifying Items to Be Controlled c8s2.2 c29s1.1
+ 2.1.1. Software Configuration
+ 2.1.2. Software Configuration Item c29s1.1
+ 2.1.3. Software Configuration Item Relationships c7s4
+ 2.1.4. Software Version c29s3
-1.2. Constraints and Guidance
-for the SCM Process
+IEEE 828-2012
-c6, ann.D,
-ann.E
-c2 c19s2.2 c29 intro
+[2]
-1.3. Planning for SCM
-c6, ann.D,
-ann.E
-c23 c29
+Hass 2003
-1.3.1. SCM Organization and
-Responsibilities
-ann.Ds5–6 c10–11 c29 intro
+[3]
+Moore 2006
-1.3.2. SCM Resources and
-Schedules
-ann.Ds8 c23
+[5]
+Sommerville 2011
-1.3.3. Tool Selection and
-Implementation
-c26s2; s6 c29s5
+[4]
-
-1.3.4. Vendor/Subcontractor
-Control
-c13 c13s9–c14s2
-
-
-1.3.5. Interface Control c12 c24s4
-1.4. SCM Plan ann.D c23 c29s1
-1.5. Surveillance of Software
-Configuration Management
-c11s3
-
-
-1.5.1. SCM Measures and
-Measurement
-
-
-c9s2;
-c25s2–s3
-1.5.2. In-Process Audits of
-SCM
-c1s1
-
-**2. Software Configuration
-Identification**
- c29s1.1
-
-
-2.1. Identifying Items to Be
-Controlled
-c8s2.2 c29s1.1
-
-
-2.1.1. Software Configuration
-2.1.2. Software Configuration
-Item
-c29s1.1
-
-
-2.1.3. Software Configuration
-Item Relationships
-c7s4
-
-
-2.1.4. Software Version c29s3
-
-
-##### IEEE 828-2012
-
-##### [2]
-
-
-Hass 2003
-
-##### [3]
-
-
-Moore 2006
-
-##### [5]
-
-
-Sommerville 2011
-
-##### [4]
-
-
-2.1.5. Baseline
-2.1.6. Acquiring Software
-Configuration Items
-c18
-
-
-2.2. Software Library c1s3 c29s1.2
-
-**3. Software Configuration
-Control**
- c9 c29s2
-
-
-3.1. Requesting, Evaluating, and
-Approving Software Changes
-c9s2.4 c29s2
-
-
-3.1.1. Software Configuration
-Control Board
-c9s2.2 c11s1 c29s2
-
-
-3.1.2. Software Change
-Request Process
-c1s4, c8s4
-
-
-3.2. Implementing Software
-Changes
-c29
-
-
-3.3. Deviations and Waivers
-
-**4. Software Configuration
-Status Accounting**
- c10
-
-
-4.1. Software Configuration
-Status Information
-c10 s2.1
-
-
-4.2. Software Configuration
-Status Reporting
-c10s2.4
-c1s5, c9s1,
-c17
-
-**5. Software Configuration
-Auditing**
- c11
-
-
-5.1. Software Functional
-Configuration Audit
-c11s 2 .1
-
-
-5.2. Software Physical
-Configuration Audit
-c11s 2. 2
-
-
-5.3. In-Process Audits of a
-Software Baseline
-c11s2.3
-
+ 2.1.5. Baseline
+ 2.1.6. Acquiring Software Configuration Items c18
+ 2.2. Software Library c1s3 c29s1.2
+**3. Software Configuration Control** c9 c29s2
+ 3.1. Requesting, Evaluating, and Approving Software Changes c9s2.4 c29s2
+ 3.1.1. Software Configuration Control Board c9s2.2 c11s1 c29s2
+ 3.1.2. Software Change Request Process c1s4, c8s4
+ 3.2. Implementing Software Changes c29
+ 3.3. Deviations and Waivers
+**4. Software Configuration Status Accounting** c10
+ 4.1. Software Configuration Status Information c10 s2.1
+ 4.2. Software Configuration Status Reporting c10s2.4 c1s5, c9s1, c17
+**5. Software Configuration Auditing** c11
+ 5.1. Software Functional Configuration Audit c11s 2 .1
+ 5.2. Software Physical Configuration Audit c11s 2. 2
+ 5.3. In-Process Audits of a Software Baseline c11s2.3
**6. Software Release Management and Delivery** c14 c8s2 c29s3
6.1. Software Building c29s4
- 6.2. Software Release
- Management
- c29s3.2
-**7. Software Configuration Management Tools**
- c26s1
+ 6.2. Software Release Management c29s3.2
+**7. Software Configuration Management Tools** c26s1
-##### FURTHER READINGS
+**Further Readings**
Stephen P. Berczuk and Brad Appleton, _Software Configuration Management
Patterns: Effective Teamwork, Practical Integration_ [6].
development organizations improve their processes. At maturity level 2, it
suggests configuration management activities.
-##### REFERENCES
+**References**
[1] ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary , ISO/
IEC/IEEE, 2010.
