SDLC Guide - Config Mgmt

Document Sample
SDLC Guide - Config Mgmt Powered By Docstoc
					       SDLC Guide
Configuration Management

 Office of the Chief Information Officer (OCIO)
            DRAFT – June 30, 2003

                         SDLC Guide – Configuration Management

                                      Revision History
   Date        Version               Description         Custodian/Organization
mm/dd/yyyy   1.0          Initial publication.           / OCIO

                                        SDLC Guide – Configuration Management

                                                         Table of Contents

Overview................................................................................................................................... 1
Configuration Management Disciplines ................................................................................ 2
 Step 1: Identifying Configuration Items .................................................................................. 4
 Step 2: Establishing Baselines ............................................................................................... 6
 Step 3: Configuration Control (Change Control) .................................................................... 9
   Procedures for Controlling Changes ................................................................................. 11
   Levels of Authority ............................................................................................................ 13
   Documentation ................................................................................................................. 15
 Step 3: Configuration Status Accounting ............................................................................. 17
 Step 4: Audits and Reviews ................................................................................................. 18
   Audits ............................................................................................................................... 18
   Technical Reviews ............................................................................................................ 19
 Step 5: Release Processing ................................................................................................. 19
Tailoring Software Configuration Management to Different Software Environments ..... 21
Planning for Software Configuration Management ............................................................ 22
Software Configuration Management—A Sample .............................................................. 23
  Design and Development Procedure ................................................................................... 25
  Build Procedure ................................................................................................................... 26
  Issues Procedure ................................................................................................................. 27
  Change Procedure ............................................................................................................... 28
  Software Repository ............................................................................................................. 29
The Configuration Management Plan Template .................................................................. 30
  Completing the Template ..................................................................................................... 31
  Maintaining the Plan ............................................................................................................ 35
  Controlling Changes to Third-Party Software ....................................................................... 36
A. Software Configuration Management Checklist ............................................................. 37
B. Sample Software Change Request Forms ...................................................................... 38
  Sample 1 .............................................................................................................................. 38
  Sample 2 .............................................................................................................................. 40

                                     SDLC Guide – Configuration Management

Tables and Figures
Table 1: Baseline Descriptions ................................................................................................. 8
Table 2: SCR Severity Levels ................................................................................................. 15
Table 3: Configuration Management Plan Content ................................................................. 31

Figure 1. High-Level View of Configuration Management.......................................................... 3
Figure 2. Configuration Control Process .................................................................................. 10
Figure 3. Example of Implementing CM and its Interfacing Processes .................................... 24

                            SDLC Guide – Configuration Management

Configuration management (CM) is a system for managing the evolution of software products
during the initial stages of development and during all stages of maintenance. A software
product encompasses the complete set of computer programs, procedures, and associated
documentation and data designated for delivery to a user. CM should also control all
supporting software used in development, even though not part of the software product.
The CM system is the collection of activities performed during a software engineering project
      Determine and identify the entities of the software product that need to be controlled
      Ensure that those entities have necessary and accurate definitions and documentation
      Ensure that changes to the entities are made in a controlled manner
      Ensure that the correct version of the entities/software product is being used
      Determine, at any point in time, the status of an entity (for example, whether a specific
       entity is completed, being changed, waiting to be tested, or released to the customer)

SDLC Guide – Configuration Management           1                                       10/19/2011
                           SDLC Guide – Configuration Management

Configuration Management Disciplines
You use CM disciplines to simultaneously coordinate configurations of many different
representations of the software product (for example, source code, re-locatable code,
executable code, and documentation). In practice, the various kinds of software being
developed (for example, commercial, embedded, original equipment manufacturer) dictate the
ways in which you perform CM disciplines. The degree of formal documentation required within
and across different lifecycle management phases (for example, research, product
development, operations, and maintenance) will also vary.
The use of interactive software development environments extends the concepts of CM to
managing evolutionary changes that occur during the routine generation of specifications,
designs, and implementation of code, as well as to the more rigidly documented and controlled
baselines defined during development and system maintenance. The effectiveness of the CM
system increases in proportion to the degree that its disciplines are an explicit part of the
normal day-to-day activities of those involved in the software development and maintenance
Figure 1 presents a diagram showing how the CM disciplines interact at the highest level.

SDLC Guide – Configuration Management         2                                    10/19/2011
                            SDLC Guide – Configuration Management

                   Configuration Management Plan

                             Identification      S
                      u                              Identification of software items to be controlled
                           Baseline Definition   A   Configuration record at a point in time
                             Configuration       i    Control of change and libraries
                               Control           n

                                                      Criteria and authority as defined in the
                                                      Configuration Management Plan
                             New Release?

             Figure 1. High-Level View of Configuration Management

The Configuration Management Plan provides information on the requirements and
procedures necessary for the configuration management activities of the software engineering
project. It specifies:
      Who will be responsible for accomplishing the planned activities
      What activities will be performed
      When the activities will be performed in coordination with the project schedule
      What tools and human resources will be required to perform the activities
      The overall system configuration

SDLC Guide – Configuration Management            3                                                       10/19/2011
                            SDLC Guide – Configuration Management

The CM process has six primary steps:

   1. Identifying configuration items

   2. Establishing baselines

   3. Controlling changes (configuration control)

   4. Performing configuration status accounting

   5. Performing audits and reviews

   6. Managing releases
Appendix A provides a checklist of some of the activities commonly associated with the basic
SCM disciplines. You can modify this list to include additional activities that are appropriate to
the size and complexity of your specific software engineering project.

Step 1: Identifying Configuration Items
The first step in the SCM system is to identify the configuration items to be controlled and, as
the project progresses, to identify the structure of the intermediate or complete software
products. This is a critical step in the system since you use the identification scheme
throughout the lifecycle of the software product. The levels of authority assigned responsibility
for each configuration item will vary depending on the complexity of the software product, the
size of the development team, and the management style of the responsible organization.
Configuration identification includes selecting configuration items (CIs), assigning unique CI
identifiers, documenting the CIs, and establishing and managing configuration baselines. A CI
is a system component (hardware or software) or logical group of components that satisfy an
end-use function. CIs are uniquely identified and placed under configuration control. At a
minimum, CIs include:
      The system itself, defined as the top-level CI
      All COTS software and hardware needed for the system (or application) to function or
       required for re-procurement
      Application software components already designated as CIs
      Project support software essential for system maintenance, including debuggers, test
       scripts, and configuration checkers

SDLC Guide – Configuration Management            4                                     10/19/2011
                            SDLC Guide – Configuration Management

When documenting the configuration items, you record their functional and physical
characteristics as detailed in technical documentation such as specifications, drawings, and
associated lists. Examples of items managed in the SCM system include:
      Management plans
      Specifications (requirements, design)
      User documentation
      Test plans, test design, case, and procedure specifications
      Test data and test generation procedures
      Support software used in development, even though not part of the delivered software
      Data dictionaries and various cross-references
      Source code (on machine-readable media)
      Executable code (the run-time system)
      Libraries
      Databases (data that is processed and data that is part of a program)
      Maintenance documentation (for example, listings and detail design descriptions)
Effective management of the development of a software product requires careful definition of
the configuration items. You also need to define changes to these items since the changes,
along with the project baselines, specify the evolution of the software product. SCM includes
all of the entities of the software product as well as their various representations in
documentation. The entities are not all subject to the same SCM disciplines at the same time.
Support software is the class of software that may or may not be delivered with the software
product, but is necessary for designing, enhancing, or testing the changes made during the life
of the product. Support software can be user-furnished, developed in-house, leased from a
vendor, or purchased off-the-shelf. In SCM, the focus is on describing the necessary controls
used to manage support software. Developers and maintainers need to ensure that the
support software is available for use for as long as the software product is in use. Whenever
you establish a production baseline, it is very important to archive all environmental and
support tools along with the production code.
Software tools used in development, especially compilers and middleware, should be placed
under configuration control so their identities and versions are included in the baseline data
about each release.

SDLC Guide – Configuration Management          5                                     10/19/2011
                            SDLC Guide – Configuration Management

You also need to consider the hierarchy of entities managed during the SCM system. There
are several different ways of structuring the entities in this hierarchy:
      As a three-level hierarchy consisting of configuration items, components, and units
      Based on the interrelationships between the software being developed and the other
       software entities used during development and testing (for example, support software,
       test software, and the operating system).
      Based on the intermediate products generated in the process of building the software
       product; for example:
          o Modifiable entities (such as source code, document, test data)
          o Compilation entities (such as compilers, support software)
          o Configuration items (such as different representations created in the process of
             producing deliverables).
An important aspect of configuration identification is to use a formal naming convention for
each entity. You should apply this naming convention, which typically uses a combination of
mnemonic labels and version numbers, to all components of a configuration item. In
establishing the naming convention, you should also consider system constraints such as
name length or composition. Consistent application of this identification scheme is crucial to
accurately tracking the software engineering process.

Step 2: Establishing Baselines
A baseline:
      Consists of one or more approved configuration identification documents that describe
       the functional, physical, or procedural characteristics of the CI
      Has been formally reviewed and agreed upon
      Serves as the basis for further development
      Can only be changed through formal configuration control procedures (only the project’s
       CCB has the authority to approve changes to documents and to establish new
A baseline is like a snapshot of the aggregate of software components as they exist at a given
point in time. You define and create baselines in accordance with the SCM Plan and the phase
of the project’s lifecycle.
During each phase of the software lifecycle, configuration items that are completed and
accepted by the approval authority become the baseline for that phase. Baselines, plus
approved changes from those baselines, constitute the current configuration identification:
      Higher-level baselines may be an aggregate of associated lower-level baselines that are
       rolled up and included in the higher-level baseline.

SDLC Guide – Configuration Management           6                                    10/19/2011
                            SDLC Guide – Configuration Management

      When a developer has finished writing a document and it has been reviewed and
       approved, it can be used as part of a baseline.
      Once established, a baseline never changes.
The development of baselines is an iterative process that progressively converts a project’s
functional and physical requirements into more and more detailed descriptive documents, and
finally into software and hardware. The documentation that comprises each successive
baseline is not an independent grouping of information, but additional information that extends
and expands the detail described in the previous baseline. Each project Configuration
Management Plan should list the complete contents of each baseline.
Baselines are closely related to the life cycle. As a CI progresses through its development life
cycle, the following baselines will be established at specific points or milestones in the life
      Functional Baseline - The functional baseline is the approved documentation,
       established by the acceptance or approval of the software or system specification, that
       describes the system (or product) functional characteristics. After completion of the
       software requirement review and approval of the Functional Requirements Document
       during the requirements analysis phase, you establish the functional baseline and
       maintain it throughout the project lifecycle.
      Allocated Baseline – The allocated baseline is the approved documentation that
       describes the design of the functional and interface characteristics that are allocated
       from a higher-level CI. All fielded systems must have an allocated baseline to support
       test, training, and maintenance. After completion of the software specification review
       and approval of the software requirements specification, you establish the allocated
       baseline. Typically, the organization responsible for maintaining the functional products
       described in the baseline documents is also responsible for maintaining this baseline
       throughout the project lifecycle.
      Developmental Baseline – After the approval of the technical documentation that
       defines the functional and detailed design (including documentation of interfaces and
       databases for the computer software)—normally during the time frame spanning the
       preliminary design review and the critical design review—you establish the
       developmental baseline and maintain it throughout the project lifecycle.
      Product Baseline – The product baseline consists of completed and accepted system
       components and the corresponding documentation that identifies these products. This
       baseline supports the ability to accurately duplicate software, purchase COTS, and
       modify COTS. The product baseline includes source code on electronic media, COTS
       (hardware and software), maintenance and user manuals, vendor-supplied COTS
       manuals, purchase specifications for modified COTS, system and hardware drawings,
       version description documents, and code listings. After approval of the product
       specification and the last formal functional configuration audit (FCA), you establish the

SDLC Guide – Configuration Management           7                                     10/19/2011
                              SDLC Guide – Configuration Management

       product baseline and maintain it throughout the project lifecycle, including the
       operations and maintenance phase and the disposition phase.

Table 1: Baseline Descriptions

 Baseline           Description
 Functional            Initial documentation that describes a CI’s functional, physical, interface, and/or
 Baseline (FBL)         procedural characteristics, as well as its constraints
                       Examples: System Specification, a requirements document
 Allocated             Describes a configuration item’s functional, physical, interface and/or procedural
 Baseline (ABL)         characteristics allocated from a higher-level configuration item
                       May include interface requirements with interfacing configuration items, and additional
                       Supports test, training, and maintenance
                       Examples: requirements documents, requirements analysis
 Developmental         Documents from the prior baseline plus the design document, drawings, parts lists,
 Baseline               user manual, and test documents that have been approved by that time
 Product Baseline      Describes all the CI’s necessary functional and physical characteristics, prior to
 (PBL)                  production or at the end of development
                       Describes the ―as-designed‖ CI
                       Formally established when all the necessary documents have been approved
                       Includes the documents from the prior baseline plus the source code and test
                        documentation (plans, procedures, results)
                       Supports the ability to accurately duplicate software, purchase COTS, and modify
 Subsequent            Document types similar to the Product Baseline, except that the documents are newer
 Baselines              revisions

Configuration baseline documents include both project documents and any other user-support
documents subject to change when the project changes. You should maintain baseline
documents throughout the life of the project, including the operations and maintenance phase
and the disposition phase. You are required to identify baseline documentation, including
application software components and COTS products, as a CI and to maintain it under
baseline control. This applies even if the project may not control the updating of the item (for
example, COTS software). You should use a version number to uniquely identify different
versions of applications software. Because COTS items (hardware or software) are not
developed in-house, they are not subject to the same level of configuration control as other

SDLC Guide – Configuration Management                  8                                             10/19/2011
                            SDLC Guide – Configuration Management

CIs. However, if the project modifies or configures a COTS product, it is then subject to the
same configuration control procedures as any other CI.

Step 3: Configuration Control (Change Control)
Configuration control is the systematic proposal, justification, evaluation, coordination,
approval (or disapproval), and implementation of changes after you formally establish the
functional baseline, and you extend it to include the allocated and product baselines once you
establish them. For each engineering change or problem report initiated against a formally
identified configuration item, configuration control:
      Evaluates the change or problem to determine its necessity and impact
      Ensures that the project team controls changes to configuration items
      Reduces the possibility of making changes that may later adversely affect functionality
      Maintains consistency between component parts of a system
The proper authority (as defined in the project CM Plan) should approve the changes.
After changes have been approved, the project team:
      Implements approved changes
      Tests to verify that the change was correctly implemented
      Tests to verify that no unexpected side effects have occurred as a result of the change
      Updates and reviews the affected documentation
The Configuration Management Plan should detail the processes for implementing software
and hardware changes. As part of any change implementation, you should deliver supporting
documentation, including user-support documentation.
Figure 2 provides a diagram of the configuration control process.

SDLC Guide – Configuration Management           9                                    10/19/2011
                           SDLC Guide – Configuration Management

                 Baseline Definition

                  Propose change                Modification, improvement, or fix for error

                  Identify baseline         t   Identify components to be changed
                    Review and
                                            A   Impact assessment of change by authority as
                 evaluate proposed
                                            c     stated in Configuration Management Plan
                      Approve               n
                      change?               t
                           Yes              g

                 Implement change               Code copied to development area

                     Verify (test)
                                                Module and system test

                       Accept          No


                    configuration               Notify users of change

                 Form new baseline

              Figure 2. Configuration Control Process

SDLC Guide – Configuration Management           10                                            10/19/2011
                            SDLC Guide – Configuration Management

The configuration control process involves three elements:
      Procedures for controlling changes to a software product
      Levels of authority (for example, Configuration Control Board) for formally evaluating
       and approving or disapproving proposed changes to the software
      Documentation, such as administrative forms and supporting technical and
       administrative material, for formally initiating and defining a proposed change to a
       software system
Many automated tools support the configuration control process. The major ones aid in
controlling software change after the project reaches the coding stage. Automation of other
functions, such as library access control, software and document version maintenance, change
recording, and document reconstruction, greatly enhance both the control and maintenance

Procedures for Controlling Changes
Changes occur at all phases in the software lifecycle. Design or implementation changes may
be necessary if requirements change, or when deficiencies are identified in the design or
implementation approach to a stable requirement. Testing may uncover defects that require
changes in the code or the design and requirements. Changes must be made to the right
version of the code, testing must verify performance of the change and the integrity of the
remaining software, and all associated documentation must be updated to be consistent with
the final code.
A mechanism is needed to process change requests (for example, discrepancies, failure
reports, requests for new features) from a variety of sources throughout the development
process and during operation and support of the software product. This mechanism should
extend to a definition of a process to track, evaluate, and implement change requests into a
new version and new release of the software. Generally, no single procedure can meet the
needs of all levels of change management and approval levels.
The minimum activities needed for processing changes include:
      Defining the information needed for approving the requested change
      Identifying the review process and routing of information
      Describing the control of the libraries used to process the change
      Developing a procedure for implementing each change in the code, the documentation,
       and the released software product

SDLC Guide – Configuration Management          11                                     10/19/2011
                            SDLC Guide – Configuration Management

For example, the SCR lifecycle detailed below provides an example of a formal process for
addressing change requests and problem reports. You can adopt it for use on your project,
modify for use on your project, or reject in favor of another SCR lifecycle. Modify the tool and
position names as required for your project, and sure that the roles and responsibilities you
provide align with those you have defined.
       1. Submission of an SCR. The SCR’s originator enters the information into the PVCS
          Tracker. All other sources of SCRs (for example, customer, user, and so on) submit
          them to the Configuration Management Specialist. PVCS Tracker assigns a unique
          SCR number to each SCR.
       2. SCR Review. Each SCR must be submitted to the Technical Board. The technical
          board reviews it to determine if the SCR is against a CI’s baseline.
       3. SCR Approval. The CCB approves or disapproves proposed change(s) to baselined
          products of a CI. These decisions are documented in the CM Log.
       4. Assignment of Responsibility. The Technical Lead is responsible for assigning a
          CCB-approved SCR to a specific member of the project team for implementation.
       5. Documentation Revisions. Determine and update the documents affected by the
       6. Configuration Review. Review the changed documents – including source code
       7. Source Code Check Out. The development team member responsible for the SCR
          checks out the affected source code from the repository using PVCS Version
          Manager, as appropriate.
       8. Implement Changes. The responsible development team member will make the
          required changes and perform the necessary unit tests.
       9. Check in the Affected Source Code. After the unit tests have been conducted, the
          development team member responsible for the changes checks the corrected
          software into the PVCS Version Manager.
       10. Independent Verification and Validation Testing (IV&VT). IV&VT will be
           performed on large projects, and peer review will be used for smaller projects. (See
           OCIO Project Documentation guide for details.)
       11. SCR Closure. After successful acceptance test completion, revision of all affected
           documentation, and Project Manager’s CCB approval, the technical lead sets the
           SCR to ―Pending Closure‖ and documents the action in the Project Manager’s CM
The techniques and methods for implementing control and status reporting in SCM generally
center around the operation of software libraries (repositories). Software libraries are a
controlled collection of software and related documentation designed to aid in software
development, use, and maintenance. Software libraries provide the means for identifying and

SDLC Guide – Configuration Management          12                                     10/19/2011
                             SDLC Guide – Configuration Management

labeling baselined entities, and for capturing and tracking the status of changes to those
Historically, libraries have been composed of hardcopy documentation and of software on
machine-readable media, but the trend is moving toward creating and maintaining all
information on machine-readable media. This trend, which encourages the increased use of
automated tools, leads to higher productivity. The trend also means that the libraries are a part
of the software engineering working environment. The SCM functions associated with the
libraries have to become part of the software engineering environment, making the process of
configuration management more transparent to the software developers and maintainers.
The number and kind of libraries vary from project to project or organization to organization
according to variations in the access rights and needs of their users, which are directly related
to levels of control. The items maintained in the libraries may vary in physical form based on
the level of technology of the software tools. When the management of the libraries is
automated, the libraries that represent different levels of control may be functionally (logically)
different even though they are physically the same. The insertion of entities and changes to
entities in a controlled library should produce an auditable authorization trail.
The names of libraries may vary, but fundamentally there are three kinds: dynamic, controlled,
and static. The dynamic library, sometimes called the programmer's library, holds newly
created or modified software entities (units/modules or data files and associated
documentation). This is the library programmers use when developing code. It is freely
accessible to the programmer responsible for that unit at any time. It is the programmers'
workspace and the programmers usually control it.
The controlled library, sometimes called the master library, is used for managing the current
baseline(s) and for controlling changes made to them. This is the library where the
components and units of a configuration item that have been promoted for integration are
maintained. Copies can be freely made for use by programmers and others. Changes to
components or units in this library must be authorized by the responsible authority (which
could be a configuration control board or other body with delegated authority).
The static library, sometimes called the software repository, archives various baselines
released for general use. This is the library where the master copies plus authorized copies of
software configuration items that have been released for operational use are maintained.
Copies of these masters can be made available to requesting organizations.

Levels of Authority
The levels of authority required for approving changes to configuration items under SCM
control can vary. The level of control needed to authorize changes depends on the level of the
item in relation to the product as a whole. The system or contractual requirements may dictate
the level of authority needed. For example, internally controlled software tools typically require
fewer change controls than critical software. Levels of authority can vary throughout the
software lifecycle. For example, changes to code in the development cycle usually require a

SDLC Guide – Configuration Management           13                                      10/19/2011
                            SDLC Guide – Configuration Management

lower level of control to be authorized than changes to the same code after it has been
released for general use. The level of authority can also depend on how broadly the change
impacts the system. A change affecting specifications during the requirements analysis phase
has less impact than a change affecting software in operational use. Likewise, changes to draft
versions of documents are less controlled than changes to final versions.
Configuration Control Boards (CCBs) enable the implementation of change controls at optimum
levels of authority and scope. CCBs can exist in a hierarchical fashion (for example, at the
program, system design, and program product level), or one board may have authority over all
levels of the change process. In most organizations, the CCB is composed of senior-level
managers. They include representatives from the major software, hardware, test, engineering,
and support organizations defined in the SCM Plan. The purpose of the CCB is to control major
issues such as schedule, function, and the configuration of the system as a whole. The CCB
functions can be included in formal computer-aided software engineering (CASE) tools.
Some of the functions of the CCB include:
      Directing the entire configuration management effort
      Resolving all problems and situations that arise during the effort
      Using the SCM system as its primary decision-making resource
      Taking into account organizational management considerations for decision making
      Orchestrating all activities from the beginning to the approval of the baselines for SCM
      Determining which products should be baselined or managed, the method to be used,
       and the order in which they should be done
      Resolving all issues, such as the most suitable product name to be used from among
       numerous documented aliases (multiple aliases often occur when an SCM system was
       not originally in place)
You can assign the more technical issues—those that do not relate to issues of performance,
cost, and schedule—to a Software Configuration Control Board (SCCB). The SCCB discusses
issues related to specific schedules for partial functions, interim delivery dates, common data
structures, design changes, and so on. This is the place for decision-making concerning the
items that must be coordinated across configuration items, but that do not require the attention
of high-level management. The SCCB members should be technically adept in the details of
their area, while the CCB members are more concerned with broad management issues facing
the project as a whole and with customer issues.
Depending on the size and nature of the software project, the SCCB may consist of a single
librarian, multiple librarians, or include many SCCBs, each with a different functional
responsibility for ensuring that changes are implemented and tested according to standard
procedures and that hardware/software interfaces and interfaces between software modules

SDLC Guide – Configuration Management          14                                    10/19/2011
                               SDLC Guide – Configuration Management

are not violated. The SCCB also focuses on overall project management responsibility for
ensuring that design or requirements specifications are not violated and that software changes
are implemented according to cost and schedule constraints. The size and structure of SCCBs
normally change over the lifecycle of the software.
To simplify the task of the SCCB, you should establish formal procedures for an initial analysis
of each change to aid the board in prioritizing the change. You should also establish review
and testing requirements for prospective changes. Results from reviewing and testing the
change should then be submitted to the SCCB to assist in evaluating the change.

System Change Requests (SCRs) are the formal mechanism within a project for requesting
and tracking changes to software and documentation. The individual initiating an SCR enters
the change information into PVCS Tracker, which generates a unique SCR number used to
identify and track an SCR through its lifecycle.
The SCR is used to capture important information about the change and to track the status of
a change from its proposal to its eventual disposition. A typical SCR form contains a narrative
description of the change or problem, information to identify the source of the report, and some
basic information to aid in evaluating the report. An SCR is submitted only against baselined
software or documentation. Anyone associated with the project can submit an SCR, but
members of the software development team more typically submit SCRs. A sample Software
Change Request Form is provided in Appendix B.
SCRs are classified by their severity or priority level. Severity is determined from the user’s
perspective. The CCB determines the SCR’s priority.

Table 2: SCR Severity Levels

 SCR Severity Level        Description
 Showstopper                  Used to correct a system halt in the production environment
 (Critical or Emergency)
                              The change can and often is implemented immediately prior to approval from
                               the CCB Chairperson, or by the Chairperson’s designee
                              After the system is restored, the SCR is processed as a routine request and
                               all members of the CCB review its impact assessment
 High                         Used when production operation is adversely affected and no workaround
                              The change can be and is often implemented with an expedited review by the
                               CCB, CCB Chairperson, or by the Chairperson’s designee
                              This category is similar to showstopper; however, steps in the change request
                               process are not bypassed

SDLC Guide – Configuration Management              15                                           10/19/2011
                             SDLC Guide – Configuration Management

SCR Severity Level       Description
Routine                     Used when a proposed change may affect the technical integrity of the
(Medium or Normal)           system, but does not halt production
                            Must be approved by the CCB prior to its implementation
Low                         Used when changes to a CI may affect the technical integrity of the release
                             but have a low degree of technical complexity, minimal or no cost/schedule
                             impact, and doesn’t negatively affect prior collaborative decisions
                            Approval of administrative changes is granted by the CCB Chairperson, or by
                             the Chairperson’s designee

The Software Change Authorization (SCA) form is used to control changes to all software and
documents under SCM control, and software and documents that have been released to SCM.
Software developers use the SCA form to submit changes to software and documents to SCM
in order to update the master library. A sample Software Change Authorization Form is
provided in Appendix L.
Several reports may be needed to support the configuration status accounting needs. Typical
reports include:
      A list of all SCRs by status (for example, open, closed)
      A monthly summary of the SCRs and SCAs
      All SCRs submitted per unit or software component within a selected range of submittal
      The status of all documentation under SCM control
      A version description document

SDLC Guide – Configuration Management             16                                           10/19/2011
                            SDLC Guide – Configuration Management

Step 3: Configuration Status Accounting
The purpose of configuration status accounting (CSA) is to record, store, maintain, correlate,
and report the status of an evolving CI throughout the system life cycle. CSA requires that all
software and related documentation be carefully tracked from initial development, through the
approval or disapproval of changes, to the implementation of changes. CSA records and
monitors all changes to baselines. As a result of this effort, CSA maintains traceability of the
hierarchy of requirements from the stated user need at the top, through the functional and
allocated baseline documentation, and down to the lowest level of the product baseline.
Configuration status accounting:
      Provides the project manager with the data necessary to gauge and report project
      Provides a mechanism for maintaining a record of how the software has evolved and
       where the software is at any time relative to the information contained in baseline
      Answers the questions:
          o What happened?
          o Who did it?
          o When did it happen?
          o What else will be affected?
      Allows you, at any point in the software lifecycle, to provide the current content of a
       given software configuration item or computer software component
If the entity is a software design description, a status accounting mechanism should allow
developers to easily pull together any text files, graphic files, and data files that may comprise
the document. Likewise, change requests to software products should be easy to track, and
the status of these requests should be readily reproducible in an organized manner.
Each time you assign a new or updated identification to a software configuration item, you
make a status report entry. Each time a change is approved, you make a status report entry.
Each time a configuration audit is conducted, the results are reported as part of a status
reporting task. Output from a status accounting report can be placed in an online database so
that software developers or maintainers can access change information by keyword category.
Status accounting reports are generated on a regular basis and are intended to keep
management and practitioners apprised of important changes.
The status account should be capable of providing data on the status and history of any
configuration item, and should contain the information necessary to enable the rebuild of any
previous baseline.

SDLC Guide – Configuration Management           17                                     10/19/2011
                            SDLC Guide – Configuration Management

Configuration status accounting increases in complexity as the software lifecycle progresses
because of the multiple software representations that emerge with later baselines. This
complexity generally results in larger amounts of data to be recorded and reported.
You should maintain status accounting reports in electronic files at logical transition points in
the software lifecycle. For example, when a baseline configuration advances from the design
phase to the implementation (coding) phase, you should file a record of this action in the
configuration records. Similarly, when a newly developed or modified module has been
approved for system testing and integration, you should record this transition in status.

Step 4: Audits and Reviews
The project team conducts audits and reviews to verify that:
      The software product matches the configuration item descriptions in the specifications
       and documents
      The package being reviewed is complete
      The performance of the product fulfills the requirements of the user or customer
Generally, you should perform a physical configuration audit (PCA) and a functional
configuration audit (FCA) of configuration items prior to the release of a software product
baseline or an updated version of a product baseline. The PCA determines whether all items
identified as being part of the configuration are present in the product baseline. The audit also
establishes that the correct version and revision of each part are included in the product
baseline and that they correspond to information contained in the baseline’s configuration
status report. The project team performs the FCA on each software configuration item to
determine that it satisfies the functions defined in the specifications or contracts for which it
was developed.

A configuration audit is a formal review of a project to assess compliance with the
Configuration Management Plan. Software configuration audits:
      Provide the mechanism for determining the degree to which the current state of the
       software mirrors the software depicted in baseline and requirements documentation
      Increases software visibility and establishes the traceability of changes throughout the
      Reveals whether the project requirements are being satisfied and whether the intent of
       the preceding baseline has been fulfilled
      Enable project management to evaluate the integrity of the software product being
       developed, resolve issues that may have been raised by the audit, and correct defects
       in the development process

SDLC Guide – Configuration Management           18                                     10/19/2011
                           SDLC Guide – Configuration Management

There are two types of audits that you should perform before releasing a product baseline or a
revision of an existing baseline: a physical configuration audit (PCA) and a functional
configuration audit (FCA).
You perform a PCA to determine whether all items identified as being part of the configuration
are present in the product baseline. The audit must establish that the correct version and
revision of each part are included in the product baseline and that they correspond to
information contained in the baseline’s configuration status report.
You conduct an FCA to ensure that each item of the software product has been tested or
inspected to determine that it satisfies the functions defined in the specifications. You must
perform an FCA for application software, COTS products, and customized products that satisfy
a functional requirement. The system tester and the project configuration manager are
responsible for the FCA.
An important aspect of these two audits is the assurance that all documentation (change
requests, test data, and reports, and so on) relevant to the release are current and complete.
In large software projects, audits may be necessary throughout the evolution of a product to
ensure conformance with planned configuration management actions and to prevent significant
problems from being encountered just prior to release. There should always be an audit of the
configuration items at the time a product is released. This will vary according to the baseline
being released and the criteria for the audit as stated in the SCM Plan.
If the team finds anomalies during audits, they should correct them and identify and correct the
root cause of the problem to ensure that the problem does not resurface.

Technical Reviews
Formal technical reviews are performed throughout the project, although SCM disciplines
generally do not initiate or direct reviews. Quite often the mechanisms that SCM uses to
process changes are the same mechanisms that other functions such as Software Quality
Assurance use to organize and process items in the reviews that they conduct. SCM supports
reviews and provides the mechanism for acting on changes resulting from the reviews.

Step 5: Release Processing
You must describe major releases of software so that the recipient understands what you have
delivered. Often the recipient will need installation instructions and other data concerning the
release. The installation instructions should define the environment in which the software
product will run—both hardware and software. The release package typically includes
documentation (often referred to as the version description document). The more critical or the
larger the software product, the more complete the documentation needs to be. SCM verifies
that the release package is complete and ready to be delivered.
After a release is completed, you should capture a configuration baseline that associates
components and their versions with the release identity of the whole product. This way, you

SDLC Guide – Configuration Management         19                                     10/19/2011
                            SDLC Guide – Configuration Management

can create a release or trace the presence of a component version. This feature is likely to be
associated with a configuration management tool that controls software ―builds,‖ producing a
report that lists all of the components.

SDLC Guide – Configuration Management          20                                    10/19/2011
                           SDLC Guide – Configuration Management

Tailoring Software Configuration Management to Different
Software Environments
You should practice Software Configuration Management disciplines as a part of every
software engineering project. The completeness and level of detail for the configuration
management disciplines depend on the size, complexity, and importance of the project.
For small user/developer projects a simple version control mechanism can be utilized to track
development activities. One example is a three-digit numbering system (for example, 1.2.3)
where 1 is the number of the current accepted release; 2 identifies a certain level of
development that has been verified as achieved (reset when the higher field changes), and 3 is
changed with routine development (again reset when the higher field changes).
When you can allow more development freedom, formal configuration management may apply
after the developer has achieved a level of functionality or confidence to release to users. In
this situation, a development ―freeze‖ would occur with verification of the functionality of the
software. Items to be configured would then be booked into a configuration management tool
or library. All further changes or development would then be checked in and out, and controlled
to a documented process. For larger, more complex software projects, this formal configuration
management process could be used at the start of the development activity. Appendix A
provides a diagrammatic representation of how SCM fits into the software development
The level of formality associated with SCM depends on the risks to be mitigated. Using a broad
definition of SCM as those processes capturing a logical snapshot of a dynamic development
process, the formality can range from totally informal to fully controlled with auditable
processes. Software with minimal risks associated with loss of historical or baseline
information may have no formally defined process. For instance, the software developer may
decide which versions should be kept based on a personal risk assessment. At the other end
of the formality scale, large projects introduce processes to assure the capture of a useful set
of final and intermediate deliverables with rules for changes to the deliverables. As there is a
cost to the implementation of formal procedures, it is important to select processes that
minimize risks proportioned to their costs.
The disciplines of SCM apply to the development of programmed logic, regardless of the form
of packaging used for the application. Whether software is released for general use as
programs (for example, RAM or DRAM) or embedded in read-only memory (ROM), it is a form
of logic. Therefore, you can and should extend SCM disciplines to include development of the
software’s component parts (for example, source code and executable code).

SDLC Guide – Configuration Management         21                                    10/19/2011
                            SDLC Guide – Configuration Management

Planning for Software Configuration Management
Planning for software configuration management (SCM) is essential to its success. The routine
clerical-type functions associated with SCM are repetitious and fairly easy to automate. The
more important disciplines of SCM, such as defining a scheme for identifying the configuration
items, components, and units, or the systematic review of changes before authorizing their
inclusion in a program, are activities that require engineering judgment. Relating engineering
judgment with management decisions, while also providing the necessary clerical support
without slowing the decision-making process, is the critical role of SCM planning. Effective
SCM involves planning how all of these activities are to be performed, and performing the
activities in accordance with the plan.
The planning and application of SCM is very sensitive to the context of the project and the
organization being served. If SCM is applied as a corporate policy, it must be done in such a
way that the details of a particular SCM system are reexamined for each project (or phase for
very large projects). It must take into consideration the size, complexity, and criticality of the
software project being managed; and the number of individuals, amount of personnel turnover,
and organizational form and structure. The Configuration Management chapter in this guide
provides additional information on creating the Configuration Management Plan.

SDLC Guide – Configuration Management           22                                    10/19/2011
                           SDLC Guide – Configuration Management

Software Configuration Management—A Sample
This section provides a detailed example of one method for implementing software
configuration management (SCM) and its interfacing processes. The figure below represents
how these various processes link to a SCM system that consists of a document management
center, a software archive, and a secure software repository. The text following the diagram
describes each process and its interfacing arrangements to the SCM system.

SDLC Guide – Configuration Management        23                                   10/19/2011
                                     SDLC Guide – Configuration Management

                 Software Design & Development Process
                              or Life Cycle

                                                                                                        Investigate & Authorize


                    Testing and Verification                             Software Change Process

                                           Source                                                 Source
                                            Code                                                   Code
                 Software                                               Software
                Documents                                              Documents

                                            Access Controlled By Software Configuration Manager

                              Document                           Software                             Secure
                             Management                          Archive                             Software
                               Center                                                               Repository

                  Source                                                                                            Master
                   Code                                                                                             Code
                                            Build                                      Issue
                                           Record                                     Records

                         Build Procedure                                              Issue Procedure

                                                                                       Issue                              Issued
                                                                                     Authorized                           Copies

Figure 3. Example of Implementing CM and its Interfacing Processes

SDLC Guide – Configuration Management                                24                                                            10/19/2011
                            SDLC Guide – Configuration Management

Design and Development Procedure
The project team develops the software to a design and development process or lifecycle. The
deliverables for this process can include source code with its associated documentation.

                                 Software Design & Development Process
                                                 or Life Cycle


As development is completed or the project is at a predetermined point (such as a software
module), the project team:
      Freezes the design and then verifies it against its specified requirements
      Tests using a test procedure that will also generate results
      Identifies all items that constitute the software and its supporting documentation, and
       places them under formal configuration management

SDLC Guide – Configuration Management                     25                          10/19/2011
                                  SDLC Guide – Configuration Management

                      Testing and Verification

                Software                  Code

                              Access Controlled By Software Configuration Manager

                            Document                       Software            Secure
                            Management                     Archive            Software
                             Center                                           Repository

Build Procedure
Assembling the software system usually involves using tools to transform the source item or
modules that the developer produces into executable programs. The exact procedure used to
build a piece of software can affect its operation; therefore, the project team controls and
documents each procedure.


                                         Build Procedure

SDLC Guide – Configuration Management                         26                           10/19/2011
                            SDLC Guide – Configuration Management

The build procedure includes definitions of the tools involved (including versions) and their
settings. It may call up ―make‖ files, ―linker‖ files, ―batch‖ files, and so on. The project team
manages these files in the same way as source modules, and these files are subject to the
same controls. The project team ensures that the decision to build a new version is
appropriately authorized and documented. The documentation (build record) will include the
new version number and a list of all the relevant modules (with their version numbers). The
build procedure may include the input of the overall version number into the software.
Following the build, the project team archives the new version of the program, together with all
of the source files required (including library files, header files, make and linker files). The
Configuration Manager control this archive, which will provide the facility to rebuild the program
at some future date.

                                     Issue                 Code


                                   Issue Procedure

                                    Issue                     Issued
                                  Authorized                  Copies

Issues Procedure
The project team:
      Uses each new version of a program to produce new master disks and store them
       under controlled-access conditions
      Write protects every master disk after creation
      Allocates a unique serial number, updates documentation, and archives any old master
      Restricts access to the master disk to the Configuration Manager or designated deputy
      Never runs the program from the master disk

SDLC Guide – Configuration Management          27                                     10/19/2011
                               SDLC Guide – Configuration Management

      Does not use the master disks for any purpose other than creating other disks

Change Procedure
During the lifetime of a software module, it is likely that it will become necessary to modify it.
The project team carries out modifications in a controlled manner. A software change is
initiated by the submission of a Software Change Request, which specifies the change
required or fault reported, reasons for the change, and an indication of priority.


                                                                     Investigate & Authorize


                Testing and Verification        Software Change Process


After the Software Change Request is submitted, the project team investigates it. The
      Identifies the software modules affected, including any effects on other modules or
       overall program features
      Identifies the effort required to implement and verify the change
      References the module(s) and documentation held in the software repository.
After the Software Change Request is authorized by the appropriate level of authority, the
project team implements the change. The software change then enters the testing, verification,
and review process. Following review, the project team authorizes and issues the new version,

SDLC Guide – Configuration Management            28                                            10/19/2011
                            SDLC Guide – Configuration Management

and archives the previous version (software and documentation). The project team
appropriately modifies and re-issues all associated documentation, and archives the change
The project team informs all users of the availability and reason for the new version, and
carefully controls and documents the withdrawal of old versions.

Software Repository
The software repository is a secure container to which the Configuration Manager controls
access. Although the control of the software documentation is as important as the actual
software, the repository may be as simple as a drawer for disk storage and a file with
appropriate control forms.

SDLC Guide – Configuration Management          29                                    10/19/2011
                            SDLC Guide – Configuration Management

The Configuration Management Plan Template
Configuration management defines the interaction between a number of activities extending
throughout the lifecycle of the product. The Configuration Management Plan functions as the
focal point for integrating and maintaining the necessary details for configuration management.
The Configuration Management Plan is a dynamic document that is maintained by approved
changes throughout the life of the software product.
The Configuration Management Plan:
      Describes how to implement configuration management (CM) standards and
       procedures for all information systems life cycle (ISLC) projects at the United States
      Describes the CM requirements, responsibilities, resources, and processes used to
       support the project
      Defines the functional CM roles and responsibilities, policies, and procedures
      Identifies the project’s configuration items (CIs) and related documentation
      Outlines the tools and procedures to control changes to the system after the life-cycle
       activities of a project have begun
      Controls the establishment and maintenance of production, testing, training, and
       development libraries
Configuration management plans generally include:
      Identification – Identify and label all functional and physical characteristics of hardware
       and software.
      Control – Ensure that the evaluation, coordination, approval, and implementation of all
       approved changes are made according to the established configuration baseline.
      Accounting – Provide the administrative support required for maintaining system
       baselines and monitoring the system through the life cycle.
      Audits – Examine the products and related documents included in a baseline to ensure
       that they are complete, clearly presented, and internally consistent. Audits also ensure
       that further changes to the system follow a methodical, documented procedure.
The plan is used to:
      Identify specific configuration management concerns
      Define what the Configuration Management Plan will and will not address
      Identify the configuration items and how they will be managed
      State the actions that software engineering will perform

SDLC Guide – Configuration Management          30                                     10/19/2011
                             SDLC Guide – Configuration Management

      State supporting activities that are required to maintain visibility of the evolving
       configuration of the software products
      Support management in the process of evaluating and implementing changes to each
      Assure that the changes have been properly and completely incorporated into each
       software product

Completing the Template
The following table provides more complete descriptions of the information you should provide
in the Configuration Management Plan.

Table 3: Configuration Management Plan Content

         Section                                            Content
 1. Introduction             Describe how to implement Configuration Management (CM) for
                             the project.
 1.1 Project Description     Provide the project name, project code, primary objectives, and
 1.2 Scope                   Explain that the CM Plan applies to the CIs, the documents that
                             describe them, and the CM functions that support the systems
                             that project team members develop or maintain.
 1.3 Overview of Project     Describe the project that this plan applies to.
 1.4 Document Overview       List and describe each section in the document, including
 1.5 Project Documents       List the key project references and deliverables produced to this
 1.6 For Additional          Explain who prepared the document, who will make changes,
 Information or Changes      how to request changes, and who to contact for additional
 2. CM Team as Part of       Identify and describe the configuration management team as it
 the Project’s               relates to the project’s organizational structure.
 Organizational Structure

SDLC Guide – Configuration Management            31                                      10/19/2011
                           SDLC Guide – Configuration Management

        Section                                           Content
2.1 Organization Chart     Describe your project’s organizational make up. Show the
                           hierarchical relationship among the project manager, technical
                           (engineering), and support groups (CM, QA, and test, as
                           applicable). If your project does not have its own CM function,
                           show the organizational relationship between your project and the
                           functional CM that you will use on the project (for example, from
                           the next higher tier, the division level, or higher). Be sure to
                           describe each block in the diagram.
2.2 Roles and              Identify all the participants in this project’s CM activities, and the
Responsibilities           responsibilities, tasks, and/or activities that each role holds for
                           establishing, performing, and evaluating the configuration
                           management functions on this project.
3. Configuration Item      Identify the person responsible for selecting configuration items,
Selection                  identify and describe the selected configuration items, and define
                           how the configuration items will be developed and/or maintained.
3.1 CI Naming Schema       Explain how you will change the basic COTS name to indicate
                           changed / customized versions. If this is not a COTS product,
                           explain all the naming standards and expand this section.
4. Configuration           Identify the document set you will develop for each configuration
Identification             item.
5. Configuration Control   Describe the organizational structure of the project-level
                           configuration control board, along with details about the
                           configuration control process.

SDLC Guide – Configuration Management         32                                       10/19/2011
                       SDLC Guide – Configuration Management

        Section                                       Content
5.1 Configuration       Describe the CCB’s role of:
Control Board (CCB)
                              Controlling major issues such as schedule, function, and
                               configuration of the system as a whole
                              Authorizing changes to baselines, configuration items, and
                              Controlling interfaces, including organization, phase,
                               software, and hardware interfaces
                        Reference your CCB Charter, and identify the chairperson and
                        members of your CCB.
                        If your project has an Information Technology Review Board
                        (ITRB), or an Information Technology Working Group (ITWG),
                        document and describe their responsibilities and composition
                        here. The ITRB’s function is usually to perform impact analyses
                        on change requests that have the potential to affect many areas,
                        effective cost management, or the ability to meet scheduled
                        milestones. This Board typically includes representatives from the
                        areas of documentation, training, usability, interface design,
                        quality assurance, testing, networking, and engineering.
                        Identify the chairperson and members of your ITRB and/or ITWG.

SDLC Guide – Configuration Management     33                                     10/19/2011
                            SDLC Guide – Configuration Management

        Section                                          Content
5.2 Hierarchical Position   Provide a brief description of your project CCB’s place within the
of Project-Level CCB        United States Mint organizational hierarchy (for example, division
                            and/or branch).
                            Define and describe the interface between your project’s CCB
                            and the CCB in the tiers above yours, the CCBs in the tiers below
                            yours (if applicable), and the CCBs in the same tier as yours.
                            Describe the necessary and appropriate actions to take when
                            your project’s CCB decisions have an impact on other CCBs.
                            Reference any Federal legislation, United States Mint directives,
                            United States Mint policies, and so on that provide instructions of
                            what to do when impacts occur.
                            Conversely, when the United States Mint Enterprise CCB (or
                            other higher-tier CCB) decisions have an impact on your
                            organization, clearly define the necessary and appropriate
                            actions. Reference any applicable documents that provide
                            instructions for these actions.
                            If the information above is in your project’s CCB Charter,
                            reference the Charter rather than repeating the information. You
                            should also attach the Charter to this document as an appendix.
                            Provide a graphical depiction of your project’s hierarchical
                            position. Be sure to include CCB names and project names as
5.3 Configuration           Describe the tools used to provide support and documentation for
Control Resources           CM activities.
5.4 Release Process
5.5 Promotion Model         Provide an explanation and a graphical depiction of your project’s
                            promotion model.
5.6 Migration Approval      Explain the coordination that your project requires when migrating
                            code or hardware between different environments.
                            Specify the titles, any special circumstances, and any other
                            information that clarifies how the migration approval form will be
                            used on your project. For all special circumstances (that is, major
                            upgrades only), be sure to include a narrative description
                            explaining exactly how to complete the form

SDLC Guide – Configuration Management         34                                     10/19/2011
                            SDLC Guide – Configuration Management

         Section                                           Content
 6.0 Configuration Status    Report the status of changes and of builds.
 6.1 CSA Data                Identify the records, and the data contained in the records,
                             actually being kept on your project.
 6.2 CSA Reports             Identify the CSA reports your project will generate, and specify
                             the frequency and distribution for each report.
 7.0 Configuration           Describe the configuration review and audits for the project.
 Reviews and Audits
 7.1 Configuration           Explain the configuration review process and describe the
 Reviews                     configuration review teams.
 7.2 Configuration Audits    Provide a list of the audits to be performed and when they will be
                             performed (use project milestones, not actual dates). If the audits
                             are still to be determined, list the milestone when the decision will
                             be made.
 A. Glossary                 Provide a glossary (in alphabetical order) of all terms, acronyms,
                             and abbreviations used in this document.
 B. References               List all references that you used to prepare this Configuration
                             Management Plan.
 C. Migration Approval       Insert a current version of the Migration Approval Signoff Form.
 Signoff Form

Maintaining the Plan
Maintaining the Configuration Management Plan throughout the life of the software product is
especially important because the disciplines of identification, configuration control, status
reporting, and release processing apply throughout the maintenance part of the lifecycle. You
can expect differences in how you manage change processing, and all participants need to
understand these differences.
You should periodically review each project’s Configuration Management Plan to assess the
effectiveness of the approach and the extent to which project staff are following configuration
management procedures. This allows you to adjust the Configuration Management Plan to
improve the staff’s ability to follow the procedures and allows you to incorporate more effective
approaches as they are developed.

SDLC Guide – Configuration Management           35                                     10/19/2011
                           SDLC Guide – Configuration Management

Controlling Changes to Third-Party Software
Control of changes to support third-party software presents a special challenge when planning
configuration management activities. These software entities are usually maintained at a
different site from the primary software product and are usually not subject to the same
Configuration Management Plan. Controls should be in place to identify the dependencies on
third-party software and to ensure the continued availability of all required support software
including compilers, operating system, and so on. It may be desirable to retain support
software and documentation along with the primary software product.

SDLC Guide – Configuration Management         36                                   10/19/2011
                           SDLC Guide – Configuration Management

A. Software Configuration Management Checklist
    Create procedures to ensure identification and control of all configuration items and
    baselines including necessary changes to those items.
    Identify appropriate tools or methods to support the configuration system, including
    change control and methods of backup.
    Document procedures for review and authorized release of products consistent with the
    level of testing applied.
    Develop a mechanism for coordinating software updates at all user locations.
    Create procedures for replication and subsequent verification and product identification
    When a configuration management software tool is employed, clearly document the use
    of that tool.
    Develop a mechanism to support the labeling or other means of identification of third-
    party supplied products including, where necessary, integration into the configuration
    management system.
    Develop a mechanism to ensure that software or designs produced or modified externally
    to the organization (for example by a contractor) are fully integrated into the configuration
    control process.
    Determine how you will tailor the software configuration management system to
    accommodate the size and complexity of the project.

SDLC Guide – Configuration Management         37                                     10/19/2011
                           SDLC Guide – Configuration Management

B. Sample Software Change Request Forms
Sample 1
                                                            SCR Number
1.   Submitted by:                                          Date:         /   /
2.   Software Program/
     Document Name:
3.   SCR Type: (1- Development, 2 - Problem, 3 - Enhancement)
4.   Short Task Description:

5.   Detail Description

6.   Submitter’s          1 = Critical 2 = Very Important 3 = Important
     Priority [  ]        4 = Inconvenient 5 = Interesting
7.   CCB Action:                                     CCB Priority [ ]
8.   Assigned to:                                    Target
                                                     Release Date
9.   Solution Comments:

SDLC Guide – Configuration Management        38                           10/19/2011
                          SDLC Guide – Configuration Management

10.   Other Affected Software Configuration Items:

11.   I&T Approval                                   Date:
      SCM                                            Date:
12.   Actual                                         Date:
13.   Closed by                                      Date:
14.   SQA                                            Date:

SDLC Guide – Configuration Management        39              10/19/2011
                                        SDLC Guide – Configuration Management

Sample 2
Software Change Request (SCR)                                 Requirement #________                          SCR#_________
Originator:_____________________                                  Date:______________Release#_________
  ( ) New requirement                    ( ) System problem                                 ( )Suggestion for improvement
  ( ) Requirement change                 ( ) User interface problem                         ( ) Other:_______________
  ( ) Design change                      ( ) Documentation correction

  ( ) High                               ( ) Medium                                         ( ) Low

Please attach supporting documentation (screen/report printouts, document pages affected, and so on) for the requested change

              Status                      Approval Date                                 Initials/Comments
 Reviewed & Estimated
 On Hold
 Approved for Change
 Code Updated
 Documentation Updated


New Release#_________

Please attach supporting documentation for review & estimates (analysis, resource estimates, layouts, document pages affected, and so on)

SDLC Guide – Configuration Management                              40                                                     10/19/2011
                       SDLC Guide – Configuration Management

SDLC Guide – Configuration Management   41           10/19/2011

Shared By: