Attachment 12 Software CMP.pdf

Treasury Office of the Chief Information Office

Software Configuration Management Plan

[Version 2.6]

Department of the Treasury

Document Version Log

System/Project: Treasury Application Systems Support Contract (ASSC) Document Title: Software Configuration Management Plan

Publication/ Submission Date Version

Change Location (if applicable)

Change Description (if applicable) Writer/Editor

8/15/04 V1.0 Initial Issue 11/05/04 V2.0 • Made nomenclature consistent

• Added FCA and PCA

• Corrected approvals

01/10/05 V2.1 • Changed Version Managing Software (VMS) to Version Manager (VM);

• Changed Request Tracking Software (RTS) to Tracker;

• Added Section 3.8 – Systems Analyst;

• Sorted Section 4.1 – Configuration Items;

• Removed detailed description of project categories from Section

4.3 – ASSC Project Categories;

• Removed the Software Trouble Request (STR) category from Section 5.2

– Change Requests;

• Added Appendix G - Configuration Management Work Products;

• Numerous minor edits throughout the document;

2/4/05 V2.2 Added section 8 on improving the SQC process.

2/6/05 V2.2 Entire Document Edited Section 8 with SEPG comments; Added bookmarks throughout the plan.

2/16/05 V2.3 Section 9.1 Updated SCM Plan –9.1 Conduct Senior Management Project Planning Review(s)

V2.4 Appendix D and E Added FCA and PCA instructions.

4/11/2005 V.2.5 Entire Document Updated and edited SCM Plan to V2.5. Updated FCA, PCA, & their Instructions

5/20/2005 v2.6 Updated the Process Efficiency / Improvement sections

03/10/2006 V2.6 Section 4.3.2 Edited this section with SEPG comments

Software Configuration Management Plan

Table of Contents

1 Introduction 2 Scope 3 ASSC Software Configuration Management Group

3.1 ASSC Change Control Board (CCB)

3.2 ASSC Project Manager (ASSC PM)

3.3 Project Manager (PM) / Team Lead (TL)

3.4 Test Manager (TM)

3.5 Software Configuration Manager (SCM)

3.6 Software Quality Assurance Manager (SQAM)

3.7 Developer

3.8 Systems Analyst

4 Configuration Identification

4.1 Configuration Items

4.2 Configuration Management Records

4.3 ASSC Projects

4.3.1 ASSC Project Categories

4.3.2 ASSC Project Category Policy

5 Configuration Control

5.1 Configuration Control Tools

5.2 Change Requests

5.3 Configuration Management Orientation and Training

5.4 Configuration Control of Configuration Management Work Products

6 Configuration Status Accounting

6.1 CM Repository and Baselines

6.2 Status and Communication

6.3 Status Documentation

7 Configuration Audits

7.1 Functional Configuration Audit

7.2 Physical Configuration Audit

8 SCM Process Improvement

8.1 Overview

8.2 Procedure for Measurements and Analysis

9 Configuration Management Reporting

9.1 Conduct Senior Management Project Planning Review(s)

Appendix A: Approval Appendix C: SCR Migration Lifecycle Diagram Appendix D: Functional Configuration Audit Appendix E: Physical Configuration Audit Appendix F: Configuration Management Work Products Appendix G: Configuration Management Measure Worksheet

Software Configuration Management Plan (SCMP)

1 Introduction Software Configuration Management (SCM) is a discipline applying technical and administrative direction and supervision over the life cycle of Software Configuration Items (SCIs).

The SCM process manages and tracks changes made to the project software, hardware and documentation components, and establishes and maintains the integrity of these components throughout the project life cycle.

Effective SCM includes the following steps:

• Identification and Documentation of the functional and physical characteristics of SCIs

• Change Control of the SCIs and the related documentation

• Status Accounting of proposed and approved changes

• Design Review and Configuration Audit to verify conformance of the SCIs to the documented requirements SCM is not accomplished at any specific point in a project. Instead, it is integrated with the definition, design, development, and maintenance of the project life cycle.

A Software Configuration Management Plan (SCMP) defines all of the activities, processes, procedures, roles, responsibilities, and resources necessary to implement SCM for a project. Once reviewed and approved, the SCMP is used as the basis for performing SCM activities throughout the life cycle of the project.

2 Scope The general SCM processes in this plan are applicable to all projects under the Application Systems Support Contract (ASSC). Individual projects may have additional and/or unique SCM requirements because of the development environment, tools to be used, or its selected development methodology. Project specific SCM requirements, plans or tailoring actions will be documented in the Project Plan (PP) of the individual project.

The SCMP and the SCM section of the PP comprise the documented SCMP of the project.

3 ASSC Software Configuration Management Group This subsection describes the specific positions that make up the ASSC SCM group. Each of these positions is associated with a fully funded Government position. These are the resources that have been designated as necessary to accomplish the SCM activities required for the ASSC.

3.1 ASSC Change Control Board (CCB)

The ASSC CCB is the governing body that authorizes the identification of SCIs and controls changes to the approved baselines. The ASSC CCB examines requested changes to systems, directs the change request impact analysis when necessary, and approves, denies, or defers the changes proposed for the system. The ASSC CCB may also prioritize changes based on release functionality.

The project customer fulfills the function of the ASSC CCB under the ASSC contract.

3.2 ASSC Project Manager (ASSC PM)

The PM has complete responsibility for the project. The PM directs, controls, administers, and regulates the development of the hardware and/or software system. The PM is ultimately responsible to the customer. The PM responsibilities include:

• managing the development effort and the requested tasks

• preparing, implementing and maintaining the project

• evaluating the planning and output

Mar 10, 2006

SCMP v2.6

• interfacing with the customer

• interfacing with company management

3.3 Project Manager (PM) / Team Lead (TL)

The Project Manager/Team Lead has direct responsibility for the software development.

Responsibilities include:

• planning the software development and software test tasks associated with the software development effort

• preparing, implementing, and maintaining the software development standards in accordance with the contractual standards for the development of software

• managing the software development and software test tasks associated with the software effort

• interfacing with program management, and project management

• coordinating inter-group tasks

• providing technical consultation and review as necessary

• evaluating, promoting and releasing Software Change Requests (SCRs) into production

3.4 Test Manager (TM)

The TM has responsibility for the testing of the project. The TM directs, controls, administers, and regulates the project test system. The TM is ultimately responsible to the PM for all aspects of testing for the project. TM responsibilities include:

• managing the development of formal test plans, formal test case designs, and the formal testing of the system and comprising subsystems

• managing the test equipment and simulation development

• managing the system test environment

3.5 Software Configuration Manager (SCM)

The SCM is a senior professional with experience in design, software and system integration activities. Responsibilities include:

• managing the baseline of the ASSC systems, subsystems, hardware configuration items, and software configuration items

• preparing the Change Status Reports

• participating in the formal design reviews

• managing the configuration repository and database(s)

• reviewing SCM change documentation

• maintaining and auditing of the software libraries

• interfacing with the Software Quality Assurance Manager

3.6 Software Quality Assurance Manager (SQAM)

A software professional with the following responsibilities:

• evaluating the software products in internal and in-process reviews

• providing day-to-day advice on the interpretation of the software standards

• performing and/or assisting the customer in performing the User Acceptance Testing

(UAT)

• interfacing with the Project Manager/Team Lead

3.7 Developer

The software developer is a professional with experience in software design and development.

Responsibilities include:

• designing, implementing, integrating and testing activities

• leading internal design reviews

• preparing and reviewing software documentation

3.8 Systems Analyst

A software professional with the following responsibilities:

• performing requirements gathering and documentation efforts

• performing system testing as required

4 Configuration Identification Configuration identification refers to the steps required to isolate items to be controlled, track their status, and report their configuration. It includes the selection and definition of all functional and physical characteristics that make up a system. This delineation allows the individuals involved in the evolution of the system to communicate effectively using a common language. It provides a basis for applying configuration control to the development and integration of the system. When accomplished correctly, configuration identification results in a complete and accurate representation of the system.

Standard Configuration Items (CIs) may include User Requirements, Functional Requirements, System Design, Test Procedures, and all code releases. The CIs are those items that are identified as requiring configuration management. At specific points in the project life cycle, these CIs are baselined as an approved configuration. These baselines act as measurable progress points and quality checkpoints, create a basis for subsequent development, and facilitate the control of future changes.

The baselines are agreed upon through formal reviews involving users, developers, and the system sponsors. All parties must agree that user requirements are clearly defined and that functional requirements are unambiguous, complete, consistent, relevant, feasible, and verifiable. After this group has agreed on a baseline, they pass that information to the SCM as a basis for future change control.

4.1 Configuration Items

All software developed and maintained under the ASSC contract which have been identified as a Software Configuration Item (SCI) by the Project Manager/Team Lead include but are not limited to the following:

• Code

• Compilers

• Data Management Plan

• Design Documents

• Drawings

• Internal Work Orders (IWO)

• Internal Work Proposals (IWP)

• Measurement and Analysis Plan

• Preliminary Project Plans

• Process Descriptions

• Product Data Files

• Product Specifications

• Product Technical Publications

• Project Plans

• Project Schedules

• Quality Assurance Audit Reports

• Release Notes

• Requirements Documents

• Server Configurations

• Software Configuration Management Plan

• Software Quality Assurance Plan

• Test Plans

• Test Procedures

• Unit Test Procedures

• User Manuals

4.2 Configuration Management Records

The management of configuration records is accomplished through the following typical work products:

• Revision history of configuration items

• Change log

• Copy of the change requests

• Status of configuration items

• Differences between baselines

Examples of these work products can be viewed in Appendix G.

4.3 ASSC Projects

All software developed and maintained under the ASSC contract which has been identified as a CI by the Project Manager must be controlled through Version Manager (VM). Each active project includes source code, documentation, and build files. Go to the ASSC portal for a list of the ASSC projects. This plan applies to all ASSC projects.

4.3.1 ASSC Project Categories

Please see the InfoPro Treasury ASSC SDLC Workflow and Processes Handbook, Addendum H: Policy – Project Category Determination for a description of project category assignments.

4.3.2 ASSC Project Category Policy

All projects in all categories under change management must be reproducible. The documentation package (baseline and all changes) must be sufficient to produce a working system in a disaster recovery situation. The entire system (without data) must be reproducible from the artifact repository. To demonstrate disaster recovery, production backup tapes may only be used to recover database structure and current data, but no program files, configuration files or configuration settings.

All database changes must be scripted and included in the deployment plan for the release in which they are made.

5 Configuration Control Control is maintained over the configuration of the work product baseline. This control includes tracking the configuration of each of the configuration items, approving a new configuration if necessary, and updating the baseline.

Configuration control is the process of evaluating, coordinating, approving, and implementing all approved changes to functional and physical characteristics of the baselined CIs. These changes may occur internally during project development or externally after items are delivered for customer approval. They may involve new requirements or modifications indicated through testing and review. The purpose of configuration control is to protect the integrity of the baseline, estimate the potential cost and schedule effects of suggested changes, and support effective decision-making regarding proposed changes.

It is important to note that configuration control is not implemented until after CIs are identified and baselined (i.e., frozen) through a formal review process. After those baselines are set and communicated to the PM/TL and the SCM, any future changes must be cleared through the configuration control process. The configuration control process is initiated when any individual with knowledge of the project identifies a potential need for system modification. This need may be identified during design, development, testing, or deployment. Changes can arise from new requirements, software bugs, problems identified in testing, or acceptance issues. Regardless of who identifies the potential need or what its nature is, when it is identified the procedure for approving or implementing the change is essentially the same.

When applied to software, configuration control is accomplished through a set of procedures that preserve the integrity of the system when approved changes are made or when restoration of the system is required due to disaster or other unusual circumstances. Software control ensures that changes to computer programs are developed and tested using valid copies of programs and test databases, and that such changes do not adversely affect system users. Software control procedures are particularly important for documenting and tracking maintenance changes during the operation phase of the life cycle. However, software control is also important for controlling changes during the planning, development, and installation of systems and system enhancements.

5.1 Configuration Control Tools

InfoPro completed the implementation of Tracker for the ASSC in early 2004. This suite of configuration management tools includes:

• VM organizes, manages and protects software during the development process. VM automates common tasks and protects against lost changes, overwrites and content errors.

• Tracker captures, manages and communicates software defects, project issues and change requests. Change requests are linked with the development files managed by VM, providing a traceable and complete set of dependent information including affected code, issues, changes, responsibilities and status.

These tools automate many tasks associated with the SDLC workflow and thus support the implementation of repeatable processes and configuration management. They maintain the revision history of configuration items and the archives of the baselines.

InfoPro will provide training with these tools to team members as part of the Tracker and VM implementation effort.

5.2 Change Requests

There is one category of request for a change to a project’s configuration. This change request is managed through Tracker. The change request is referred to as a Software Change Request (SCR) and it is used to manage five (5) different types of requests:

• Bug Fixes

• Data Fixes

• Enhancements

• System Maintenance Requests

• User Support Requests

There is one method for creating and managing change requests for ASSC documents, templates and processes.

5.2.1 Software Change Requests (SCRs)

5.2.1.1 An SCR is submitted either verbally or through written documentation by the client to the PM/TL. The PM/TL evaluates the request and enters it into Tracker.

5.2.1.2 The PM/TL assigns one or more Developers through Tracker, to implement the change. The assigned Developer(s) are notified via an email generated by Tracker.

5.2.1.3 The Developer(s) program and unit test the SCR.

5.2.1.4 After the Developer(s) complete the programming and unit testing to their satisfaction, they enter the successful results into Tracker. The PM/TL is notified of the successful results via an email generated by Tracker.

5.2.1.5 The PM/TL reviews the change and enters the successful status into Tracker. The PM/TL promotes the code in VM to Integration Testing.

5.2.1.6 The Test Manager is notified via an email generated by Tracker that the Test Team can begin Integration Testing. Integration Testing issues are resolved between the PM/TL, the Developer(s), and the Test Manager.

5.2.1.7 After the Test Team completes the Integration Testing to their satisfaction, the Test Manager is notified and enters the results into Tracker. The PM/TL is notified of the results via an email generated by Tracker.

5.2.1.8 The PM/TL notifies the customer that the SCR is ready for User Acceptance Testing (UAT). The Project Manager/Team Lead is responsible for arranging and managing the UAT.

5.2.1.9 The Project Manager/Team Lead arranges with the SCM for the release of the SCR into a UAT environment.

5.2.1.10 After the UAT has been completed to the satisfaction of the customer, the results are documented through entry into Tracker. The CM is notified of the approved results via an email generated by Tracker.

5.2.1.11 The Project Manager/Team Lead designates and documents the version (release number) with which the change or fix will be deployed within the Version Control Application (VCA).

5.2.1.12 The Project Manager/Team Lead arranges with the SCM for the release of the SCR into production.

5.3 Configuration Management Orientation and Training

Training in Configuration Management activities and responsibilities will occur at two levels.

The initial level is a general orientation on the Configuration Management activities and responsibilities as well as a brief introduction to CMMI if necessary. The initial level of training is an orientation for all new hires or individuals to the ASSC team. This orientation is part of the in processing orientation for these individuals. This orientation will include an overview on conducting Configuration Management activities and the importance of processes and product quality.

The second level training is a “hands-on” orientation to both Version Manager and Tracker. The second level is a more detailed level and includes the “how to do” Configuration Management activities such as baselining and auditing activities. The training material and training attendance lists are maintained in Version Manager.

5.4 Configuration Control of Configuration Management Work Products

The SCMP and the work products generated as part of the configuration management processes will be placed in VM.. Control is maintained over the configuration of the work product baseline through tracking the configuration of each of the configuration items, approving a new configuration if necessary, and updating the baseline. (see Section 5.2 – Change Requests)

The typical work products used to track change requests include the:

• Revision history of configuration items

• Archives of the baselines

Examples of these work products can be viewed in Appendix G.

6 Configuration Status Accounting The configuration status accounting process is managed by the SCM. The configuration status accounting process is used to maintain project baselines and monitor status throughout the SDLC. This is accomplished by tracking and checking the baseline at the designated milestones reviews identified in the Project Plan.

Configuration accounting procedures detail the documentation of configuration item baselines and changes to the baselines. Additional requirements established during the project life cycle are tracked as changes to the baseline. The additional requirements may impact the system’s interface, functionality, behavior, performance, operation, quality, security, or constraints.

6.1 CM Repository and Baselines

Project baselines (documentation or code) are added to the CM repository as they are developed.

The CM repository for a project is composed of two components:

• a software code repository

• a set of project development folders for the management of documentation and artifacts

VM is the ASSC tool which serves as the software code repository. The tool used for a specific project can be found documented in the Project Plan for those cases where a customer specified tool is required. Changes to baselines and releases of products built from the repository are systematically controlled through change control and auditing functions. The repository provides storage, retrieval, sharing, archiving, and backup functions for CIs. The documentation for each baselined CI is stored in electronic format. The documentation uniquely identifies each CI with a specific description, release number, date, and change status, and also names the owner of the CI.

The documentation includes information as to what was deployed and how it was deployed.

After completion of a project, the SCM archives all baseline documentation to a system maintenance folder.

A minimum of two baselines will be generated for each project:

• a baseline is generated prior to the application being released for the User Acceptance Test (UAT)

• a baseline is generated prior to the application being released into production

Projects may include additional baselines where appropriate during the earlier stages of the project’s life cycle.

6.1.1 Baseline Creation

The project team will do the following to create a baseline:

• ensure all documentation is brought up to date for the current stage of the project’s life cycle. The documentation will be promoted to the appropriate level in VM to uniquely identify it for the baseline being prepared.

• All files for deployment will be promoted to the appropriate level in VM to uniquely identify them for the baseline being prepared.

6.1.2 Code or Documentation Release

The project team will do the following to release code or documentation for a change:

• the CIs should be properly documented

• approval or authorization to change the code should be obtained from the

ASSC CCB.

• For documentation, the version in the project development folders will be copied and versioned. The prior version will be moved into the archive folder for that document.

6.2 Status and Communication

The SCM will make all documentation available electronically to the Project Team and the Customer. Configuration Item status will be recorded and communicated to the project team and management. These are the primary inputs for the CM status accounting process.

6.2.1 Minutes of Customer Meetings

Documents, discussions, and decisions pertaining to configuration accounting.

6.2.2 Work Product List (WPL)

The WPL documents which work product items are designated as CIs for the system under development. It also records the baseline technical documentation of a system controlled by CM. Recorded data may include the system name/release/version, title of the document, publication date, and revision number.

The WPL should accompany the Physical Configuration Audit (PCA) documentation.

6.2.3 Software Code Repository

Provides the status of the project code, listing all code modules associated with the system and what modules may be checked out or checked in.

6.3 Status Documentation

To document status at designated milestones or when required by the Project Manager, the project team will do the following:

• Provide the document version number and date for all project documentation.

• Ensure all completed or updated code modules have been checked-in and then prepare a report of current code modules including version information.

This status report will provide the project manager with the information that differentiates deliverables, documentation and code.

7 Configuration Audits

Configuration audits examine configuration records (e.g., the required products and related documents submitted for inclusion in a baseline) to accomplish the following:

• Verify the success of the change control and identification processes

• Ensure the configuration records are complete, clearly presented, and internally consistent

System evaluations include configuration audits to check for adherence to standards and support reviews.

Audits are not intended to make qualitative evaluations of the programmatic or technical content of the product. Instead, they help ensure that those types of reviews and evaluations are not applied to products that are not ready for such a review.

7.1 Functional Configuration Audit

A Functional Configuration Audit (FCA) validates that a system is developed in accordance with the requirement definition (i.e., in compliance with the Requirements Document). It ensures that technical documentation and test analysis reports accurately specify functional, operational, performance, and design characteristics. Every requirement is matched to design criteria, which is in turn is matched to a test scenario.

In systems engineering, an FCA is an important part of quality assurance and is an important activity within configuration management. An FCA ensures that the functionality of a configuration item as demonstrated by the test and evaluation effort is the same as that documented in the Development Specification and the Product Specification for that configuration item.

An FCA may be conducted as determined by a senior manager for each configuration item, or a continuous audit may be conducted progressively over the development of the configuration item.

Where the functionality of a particular configuration item may depend on other configuration items, the FCA may not be complete until system integration. FCA audit will occur at least twice; once prior to TRR and again prior to the PRR.

7.2 Physical Configuration Audit

A Physical Configuration Audit (PCA) validates the system baseline. The PCA ensures items specified are physically available for acceptance testing or to be placed into production.

A PCA is part of the configuration management activities undertaken within the quality assurance activities of systems engineering. A PCA examines the as-built configuration item against the various specifications such as product specifications and other design data, and ensures that the physical as-built configuration is the same as that described by these specifications.

A PCA is conducted twice; once prior to the TRR and prior to the PRR. The PRR is on the final version (the as-built version) of each configuration item.

8 SCM Process Improvement

8.1 Overview

SCM metrics provide specific information on the evolving product and insight into the functioning of the SCM process. A related goal of monitoring the SCM process is to discover opportunities for process improvement. Quantitative measurements against SCM process metrics provide a good means for monitoring the effectiveness of SCM activities on an ongoing basis. These measurements are useful in characterizing the current state of the process as well as providing a basis for making comparisons over time. Analysis of the measurements may produce insights leading to process changes and corresponding updates to the SCMP.

8.2 Procedure for Measurements and Analysis

The Software Configuration Management (SCM) metrics focus on identifying and tracking SCM tasks at the project level. This provides a complete view of the level and performance of SCM being applied. The Configuration Manager (CM) is responsible for implementing this process.

Use the following steps and the worksheet from Appendix G to determine the SCM metrics:

1. Identify SCM metrics to be collected which can improve application development, help in improving SCM processes, and meet SCM objectives.

• At a minimum, collect the following SCM metric at the project level:

• Collect the Measurement and Analysis efforts being expended for the time it takes to create the Physical Configuration Audit (PCA) and the time it takes to complete, validate, and enter the PCA (free from issues and corrections) into the project artifact repository.

2. Establish a metrics collection process. The more automated the process can be, the better the metrics collection will be. This may involve scripting/coding a metric collection solution or acquiring a metrics collection technology. In the case of timing the process, we can entrust this to the members involved in the process, specifically the PM’s and the CM.

3. Determine what will be reported for the SCM metrics for future collection.

4. Periodically, the CM will review the metrics, identify opportunities for improvement, and work with the SEPG to prepare action plans to implement improvement efforts.

9 Configuration Management Reporting

9.1 Conduct Senior Management Project Planning Review(s)

Configuration management activities are reviewed with senior management as part of the weekly project management activities. The ASSC Project Manager meets bi-weekly with the ASSC Program manager and COTR at the bi-weekly contract review meetings to discuss any configuration management issues. The Software Configuration Manager meets with the ASSC Project Manager on an exception basis as necessary.

The ASSC Project Manager and project development team, including the Software Configuration Manager (SCM) are involved in a number of reviews during the course of the project (for instance, the PRR). The reviews will include internal reviews by the development team and formal reviews at designated milestones. The ASSC Project Manager will brief senior management, the customer, and any pertinent external organizations. During this time the configuration management process will be discussed as part of the overall implementation of the SDLC.

Appendix A: Approval

The following approvals are necessary for this deliverable:

• ASSC Program Manager

• ASSC Project Manager

• Software Quality Assurance

Organization Position Name Signature (location of signature)

Signatures are desired but not always possible. Consider:

1. Obtaining approval via email. Place a copy of the email on this page (cut and paste it here).

2. In the event the approver does not respond, send an email clearly indicating a response due date; otherwise a default acceptance will occur. Provide several business days for the response due date. Just prior to the response due date; try a follow-up email and possibly a phone call. If there is no response, the day after the due date send an email indicating a default acceptance. File a copy of all the emails on this page.

Appendix B: Glossary

Please refer to the SDLC Workflow and Processes Handbook for a combined Glossary of terms.

Appendix C: SCR Migration Lifecycle Diagram

Appendix D: Functional Configuration Audit Below is the FCA form. Complete it, obtain appropriate approvals, and place it into Version Manager. Detailed instructions follow after this form.

Functional Configuration Audit (FCA) Checklist

Functional Configuration Audit A Functional Configuration Audit (FCA) validates that a system is developed in accordance with the requirement definition that is outlined in the Requirements Traceability Matrix. A FCA occurs prior to production.

Project Name: _______________________________________ Date: __________ Release # ______________________

Requirements pre-TRR Yes No N/A

1. Is the Requirements Traceability Matrix updated to reflect the test results and under Version Managing Software control?

2. Are any Waivers required?

Requirements pre-PRR

1. Is the Requirements Traceability Matrix updated to reflect the test results and under Version Managing Software control?

2. Has the customer signed off on any waivers (if required)?

Name of individual conducting FCA Date:

Check one:

Results reviewed satisfy the requirements and are accepted (See attached comments).

Results reviewed do not satisfy requirements (See attached comments and list of deficiencies).

SCM Approved by: __________________________________ Date: _____________

How to complete the Functional Configuration Audit (FCA)

The following numbers relate exactly to the FCA form in Appendix D of the Software Configuration Management Plan.

The recommended technique is to copy the FCA form from the SCM Plan, paste it into a blank document, and append the minutes of the FCA directly after the form. This keeps any notes and comments with the form.

Requirements –Pre-TRR

1) Is the Requirements Traceability Matrix updated to reflect the test results and under Version

Managing Software control? The RTM must be updated and checked into Version Manager. Please supply the file location and revision level in VM.

2) Are any Waivers required? In the event that the software must be released with a known bug or other functional problem, the customer must be made aware that there is a problem. Any documentation of this nature should be noted in the FCA minutes.

Requirements –Pre-PRR

1) Is the Requirements Traceability Matrix updated to reflect the test results and under Version

Managing Software control? The RTM must be updated and checked into Version Manager. Please supply the file location and revision level in VM.

2) Has the customer signed off on any Waivers (if required)? In the event that the software must be released with a known bug or other functional problem, the customer must be made aware that there is a problem. Any documentation of this nature should be noted in the FCA minutes.

Remember that the FCA should be checked into Version Manager under the documentation area of the applicable software release. Please also notify Software Quality Assurance and the ASSC Project Manager that this document is completed, and where it is located in Version Manager, plus the revision level.

Appendix E: Physical Configuration Audit

Below is the PCA form. Complete it, obtain appropriate approvals, and place it into Version Manager.

Physical Configuration Audit (PCA) Checklist

Physical Configuration Audit A Physical Configuration Audit (PCA) validates the system baseline. The PCA ensures that items specified are physically available for acceptance testing or to be placed into Production. Hence there is a PCA occurring prior to the user acceptance test and prior to production.

Project Name: _______________________________________ Date: __________ Release # ______________________

The following requirements and tasks shall be available and accomplished at the PCA.

Requirements - pre- TRR Yes No NA

1. Approved final draft of the Deployment Plan.

2. Release Notes.

3. FCA minutes for each configuration item.

Requirements – pre-PRR

1. Approved final Deployment Plan.

2. Final Release Notes.

3. FCA minutes with revisions as necessary for each configuration item.

Tasks

1. Ensure the discrepancies noted during the FCA on each CI have been corrected.

2. Review Deployment Plan.

3. Review Release Notes.

Name of individual conducting PCA Date:

Check one:

Results reviewed satisfy the requirements and are accepted (See attached comments).

Results reviewed do not satisfy requirements (See attached comments and list of deficiencies).

SCM Approved by: _______________________________________ Date: _____________

How to complete the Physical Configuration Audit (PCA)

The following numbers relate exactly to the PCA form in Appendix E of the Software Configuration Management Plan.

The recommended technique is to copy the PCA form from the SCM Plan, paste it into a blank document, and append the minutes of the PCA directly after the form. This keeps any notes and comments with the form.

Requirements - Pre-TRR (This is a document review)

1) Approved final draft of the Deployment Plan: The deployment plan should be clear enough so that someone other than the developer should be able to deploy the software release. All instructions should start with the file location in Version Manager.

2) Release Notes: This is the project Release Notes for the applicable release. Locate and review the document in Version Manager and supply the path, file name, and revision level.

3) FCA minutes for each configuration item: Locate and review the document in Version Manager and supply the path, file name, and revision level.

Requirements - Pre-PRR (This is a document review)

1) Approved final draft of the Deployment Plan: The deployment plan should be clear enough so that someone other than the developer should be able to deploy the software release. All instructions should start with the file location in Version Manager.

2) Final Release Notes: These are the project Release Notes for the applicable release. Locate and review the document in Version Manager and supply the path, file name, and revision level.

3) FCA minutes with revisions as necessary for each configuration item: Same as for Pre-Test, but now in final form with changes noted.

Tasks

1) Ensure the discrepancies noted during the FCA on each CI have been corrected: Discrepancies should be noted in the PCA minutes, and the version labels of the changed files must be updated.

a) All Configuration Items, including source code, scripts, documentation related to this release must be promoted to the appropriate level in VM. Within Version Manager there are ways to assign version labels to blocks of files simultaneously as long as all the files in that block are at their tip revision.

Files which have been checked out for the next release must be version labeled individually to be sure you label the release number on the correct revision.

2) Review deployment plan. The installation plan will be specific to a given project, but it should include:

a) Details which the “gatekeeper” can follow to implement the production release. This can be a CD of files, SQL scripts, or whatever is required, but it should always refer back to Version Manager and the applicable file locations.

b) A rollback procedure in the event the upgrade fails.

c) The ideal time frame for the installation to occur, such as when users do not need the system. There are also rules about no system changes while the Secretary is traveling, so the installer must know if this affects rollout.

d) All code to be placed on the target server (and/ or workstation if the application is client/ server based) should be in a release folder. The structure of the build folder can be specific to a project, but it should closely match the server configuration. Within the build folder should be a configuration folder if specific system settings need to be made to the server or workstation, such as IIS virtual directories, registry settings, ODBC settings, etc.

e) The release folders, where applicable, can be compared to the test server’s directories.

f) The software Configuration manager will review individual software files between the pre-test and pre-production “snapshots”. Several software tools/products will be used to compare program source code and database scripts. The following three products may be used as applicable.

i) An Oracle change management tool will be used to make a baseline both before and after implementation of a software release. The tool will show details of individual changes.

ii) Microsoft SQL2000 or 6.5 – Enterprise Manager can generate a SQL script which could recreate the database on the same server or a different server to compare database changes. The resulting ASCII files can be compared using the KDiff3 tool.

iii) Kdiff3 tool – can look at program source code differences between new source code and the baseline. The tool compares the text input files or directories against the baseline software under Version Manager. The tool shows the differences line by line and character by character.

3) Review Release Notes. Once the new release has been deployed, verify that nothing changed between final release and actual deployment, and note any exceptions in the PCA minutes, plus follow up to insure that the Version Manager files are current.

a) Typical situations that would arise are forgotten virtual directories, and server file folder permissions

(which may be more restrictive than the test environment) may affect user access.

b) Be sure that every exception is noted and corrected.

Remember that the PCA should be checked into Version Manager under the documentation area of the applicable software release. Please also notify Software Quality Assurance and the ASSC Project Manager that this document is completed, and where it is located in Version Manager, plus the revision level.

Appendix F: Configuration Management Work Products

Figure 1

Figure 1 above is a snapshot of a Version Manager screen which shows:

• Window Left: Version Manager directory structure

• Window Top-Right: File List

• Window Bottom-Right: Revision History for Selected File

Figure 2

Figure 2 above is a snapshot of a Version Manager screen which shows a workfile change history.

Figure 3

Figure 3 above is a snapshot of a Tracker screen which shows:

• Window Left: Query selections

• Window Top-Right: List of All Software Changes Requests (SCRs)

• Window Bottom-Right: the detail for the selected SCR

Figure 4

Figure 4 above is a snapshot of a Tracker screen which shows:

• Window Left: Query selections

• Window Top-Right: List of Open Software Changes Requests (SCRs)

• Window Bottom-Right: the detail for the selected Open SCR l

Figure 5

Figure 5 above is a snapshot of a Tracker screen which shows:

• Window Left: Query selections

• Window Top-Right: List of Closed Software Changes Requests (SCRs)

• Window Bottom-Right: the detail for the selected Closed SCR

Figure 6

Figure 6 above is a snapshot of a Version Manager screen which is used to select two (2) workfiles and subsequently display their differences.

Figure 7

Figure 7 above is a snapshot of a Version Manager screen which is used to show the differences between two (2) different versioned files.

Software Configuration Management Plan (SCMP)

Appendix G: Configuration Management Measure Worksheet

Process Efficiency: Software Configuration Management Worksheet

Project:

Data Recorder:

Date:

Data for collection: Time

Reference:

SCM Plan v 2.5 Sections 8, Appendix G

Data definition:

(e.g. for times, include when to start times and when to end

Time:

It is calculated by the difference between the starting and ending times of the process.

Start time is recorded at the time the PCA worksheet is opened on the desktop of the individual who is conducting the Configuration Management process.

End time is recorded upon saving the completed PCA form and checking it into VM.

Measurement Method Measurement Comment / Initials

1) Start time: direct observation of system time on the PM's system when the PCA form is opened

2) End time: verified value on the CM's system time at the point the CM commits the approved PCA to VM

3) Calculated elapsed time of process