Appendix_3 _NARA_CMP.docx

TEMPLATE for

CONFIGURATION MANAGEMENT PLAN

(CMP)

For <System Name>

Version 2.1

Status: Final August 17th, 2012

For the

NATIONAL ARCHIVES AND

RECORDS ADMINISTRATION

<System Name>.CMP.docx iii <Date> V2.1 Configuration Management Plan Template

ENTERPRISE CM MANAGER SIGNATURE PAGE

(This page is not required as part of the System CMP Document)

Signature acknowledges that you agree with the Configuration Management Plan and will abide by the details as stated within.

Recommendation for Approval:

Configuration Management Plan For <System Name>

SIGNATURE PAGE

Signature acknowledges that you agree with the Configuration Management Plan and will abide by the details as stated within.

Recommendation for Approval:

Name Date Title: Project Manager

Name Date Title: System Owner

Document Change Control Sheet Document Title: <System Name> Configuration Management Plan Date (Enter the date of the document update –mm/dd/yy) Version # (See Appendix F “Classification of Document Changes”) Author Name of individual(s) performing the updated to the document) Status (Draft, Final) Revision Description (Describe in summary what was included in this version of the document)

Table of Contents

List of Tables

Configuration Management Plan

This Configuration Management Plan (CMP) establishes the technical direction, administrative direction and surveillance for the management of configuration items (i.e., software, hardware, and documentation) associated with the <System Name > that are to be placed under configuration control. <In developing this section of the CMP, the Project Manager is encouraged to use supplemental information that accurately describes project specific CM planning. CM Planning consists of identifying CM staffing requirements based on scope and complexity of product and the activities being performed. Also additional questions should be asked such as determining how CM is being performed; who is performing CM; what projects or systems require CM? Are there CM Tools and templates available for usage, etc.>

1.1 Purpose

The purpose of developing a CMP is to ensure that the integrity of all work products developed by a system development project is maintained throughout the system life cycle. CM is a full life cycle activity applicable to all project work products including hardware, software, procedures, and documentation. CM is implemented for externally deliverable products, designated internal work products, and designated support tools used by the system.

The purpose of this document is to specify the Configuration Management (CM) procedures that are to be used by <System Name>. These CM procedures are used to establish, modify, integrate, and manage all Configuration Items (CIs) that are developed by the <System Name> project in support of developing, deploying, operating, and maintaining the <System Name> system. These procedures are applicable to all Configuration Items (CIs) developed and maintained by or on behalf of the <System Name>.

This CMP applies to all individuals and groups that develop CIs for the <System Name> system. The <System Name> CM Manager will monitor and audit project processes and products to ensure compliance with the CM procedures defined in this CMP, and all applicable NARA SDLC policies. If necessary, the <System Name> CM Manager will assist project personnel with training and implementation of these CM practices.

1.3 References

Table 1.1-1 below lists the reference documents used in the development of this CMP (e.g., Project Management Plan (PMP), other PMP subsidiary plans (e.g., Change Management Plan, Quality Management Plan (QMP), etc.), Project Charter, CCB Charter, etc.).

Table 1.1-1. Reference Documents

2.0 Configuration Management Responsibility

Describe the overall responsibility for CM within the <System Name>. This section defines the allocation of responsibilities and authorities for CM activities to organizations or individuals within the project.

<When developing this section of the CMP, the Project Manager is encouraged to use supplemental information (e.g. CM Planning Matrix etc….) that accurately describes the CM Responsibilities.>

2.1 Configuration Management Roles and Responsibilities

In this section, summarize all project roles associated with CM and their corresponding responsibilities and roles. Using Appendix B "Project CM Personnel”, assign specific personnel assigned for each role and provide associated contact information. (Examples are shown below. Please modify the roles in this table as appropriate to the project.)

Table 2-1-1: CM Roles and Responsibilities

2.2 Assumptions

Describe a list of assumptions specific to the <System Name>, which might impact the cost, schedule, or ability to perform configuration management activities on the <System Name>. Configuration Management assumptions include, but are not limited to: (Please add or remove assumptions specific to achieve project configuration management goals as applicable to the project.)

· The Project Management will support configuration management goals.

· The Project will have adequate project management.

· The Project Manager or the delegated authority e.g. Configuration Manager will Train project staff in configuration management principles and requirements.

· The Project Manger or the delegated authority e.g. Configuration Manager will ensure adequate project staff training and support in configuration management tool usage.

· Access to contractor facilities, resources, and work products will be provided, as required, to allow reliable monitoring of contractor activities and work products.

· All items defined at any control level will be maintained in the NARA designated CM tool.

2.3 Limitations

Describe any limitation that may impact the administration of CM activities for the <System Name>. Examples of limitations are provided below. (Please add or remove limitations specific to achieve project configuration management goals as applicable to the project.)

· No access to NARA designated CM tool.

· No staff trained in configuration management principles and practices.

· No project staff trained and no support in configuration management tool usage.

3.0 Configuration Management Activities

Projects are required to adhere to the following CM principles:

Major CM Principles:

· Configuration Identification;

· Change Control;

· Configuration Status Accounting;

· Configuration Audits and Reviews;

Additional CM Principles:

· Release Management;

· CM support to other functional area activities, as required, and

· Sub-contractor CM Methodology How projects adopt these principles may differ based on the size of the project and the complexity of the system being developed. Small projects may elect to share configuration management resource with other projects, while large projects may need dedicated configuration management resources. The key CM functions and guidelines defined in this template are the integral part of the CM process.

3.1 Guidelines for establishing Configuration Items

The purpose of Configuration Identification is to determine the discrete CIs that get established by the project so they can be tracked and managed throughout the system life cycle.

This section documents the guidelines that are to be use by <System Name> for identifying CIs. Appendix C” Selecting Configuration Items” provides some general rules of thumb that can be used to determine whether the results if specific project activities result in work products that should be considered a CI.

Naming conventions, combined with labels, are used to uniquely identify CIs that are placed under CM for the <System Name>. The project should establish a naming convention that uniquely identifies each CI and enables its different versions to be tracked and managed. The guidelines presented in Appendix D “Naming and Labeling Configuration Items” can be used to determine how the project will name, classify, and catalog CIs. This information can be maintained in document format, via a database, or by using a CM tool depending upon the needs of the project. For large, complex projects having thousands of CI, an automated CM tool will likely be required.

3.2 Change Control

Change control procedures ensure that any proposed change to a CI is logged, classified, evaluated, and approved or disapproved. The procedures also ensure that all approved changes are implemented, tested, verified, and incorporated into a new baseline.

2.1 2.2

Changes to system elements and their associated documentation are classified according to the impact of the change, the urgency of the change, and the approval authority that is needed. Depending on the scope, schedule, and cost of the change there may be numerous people and/or groups that must review and approve the changes. Review and approval authority for project developed and project managed CIs is defined in the <System Name> CCB Charter. Changes to NARA’s production environment will typically need to be approved by the IT Operations CCB and for Standalone applications the changes will be approved by the System CCB. Changes to project scope and budget will generally need to be approved by NARA’s Architecture Review Board or Executive Steering Committee.

There are two types of Change Control Processes: -The Systemand The Operations Change Control Process

3.2.1 System Change Control Board Process:

Changes covered under System Change Control process and governed by the System CCB include:

· Deviations and Waivers: A deviation is granted for temporary, short-term relief of a requirement whereby future builds/deliveries will be in compliance. A waiver is granted for permanent relief of a requirement. Deviation and Waivers are approved by the System CCB.

· Scope Changes: Any changes to the requirements must be approved by the System CCB.

· Any other change impacting the project cost or schedule, e.g., TRR change.

3.2.2 Operations Change Control Board Process

Once system elements have been built and verified, they must progress through the deployment activities of the SDLC where the system’s operating capability is developed, installed, and validated. Deployment activities require coordination between the CCB of the project and CCB for NARA’s Enterprise IT Operations (i.e., the Operational CCB) where ever required. The initial release of the system and any changes to the system once in production must be reviewed and approved by the Operational CCB and prioritized for resolution based upon their impact and risk. Projects should identify and define how they will prioritize and manage the need for system changes that are recognized in production operations, for example:

· Emergency Fix: A Change is identified as an emergency fix, when it causes a total system failure or adversely impacts the users in any way. In the case of an emergency fix, the focus is to stabilize the operating environment and/or resolve the customer’s needs immediately. In these cases, the formal change request procedures may need to be expedited or temporarily circumvented, provided that the risk of regression faults does not exceed the business impact of the current outage. In emergency situations notification is sent to CCB Chair, Project Manager, Systems Engineering, CM Lead, and Operations Lead to make them aware of the issue. After the fix is implemented, the formal Change Request (CR) is submitted and the Operational CCB process is followed through to completion to maintain baseline information and support potential audits.

· Urgent Fixes: Urgent fixes are issues that fall short of true emergency fixes but impact functionality where immediate action is required. In these cases, the Operational CCB review and approval will occur and updates to affected system elements will be performed prior to implementation in a regularly scheduled release. All such changes will be retrofit into the subsequent product baseline.

· Expedited Fixes: Expedited fixes are changes that are required to be implemented in a timely manner but do not adversely impact the operation and use of the system (e.g., Security critical patches). After the fix is implemented, all such changes will be retrofit into the subsequent product baseline.

· Maintenance Releases: Maintenance releases are scheduled updates to the production system, provide fixes to address known defects, and are subject to Operational CCB approval

Change Requests (CRs) are used to initialize the above procedure for making changes to CI. Changes are categorized according the types of modifications managed by the project (e.g., enhancement, requirements change, or design change) and the urgency of the change as defined in the section above. . Appendix I “Change Request Form and Instructions” provides a sample CR form that can be modified based upon the needs of the project.

Changes to configuration items must be authorized and approved by the appropriate Change Control Board (CCB).

2.3

3.3.1 Classification of Document Changes

Definitions of document changes specifically for documents are described in detail in Appendix F “Classification of Document Changes.”

3.4 Configuration Status Accounting

Configuration Status Accounting (CSA) procedures are used to record and report on the information that is needed to manage configuration items, e.g., Status of Deviations and Waivers, number of change Requests by status (open, closed, implemented status of approved changes etc.).

2.4

3.4.1 Release Management

The focus of Release Management is the protection of the live environment and its services through the use of formal procedures and checks. Identify each specific release, including a description of the functionality to be delivered in each release, as further described in Section 3.4.2. Refer to Appendix G “Release Conventions” for release management conventions.

3.4.2 Version Description Document (VDD)

The VDD is the primary change control document used to identify all CIs associated with a release of a system element or composite system for the purposes of verification, integration, or deployment. The VDD provides a summary of the features and contents of the CIs that constitute a specific release.

(This template is currently under development by the Enterprise CM Team.)

3.5 Configuration Audit

A Configuration Audit is an independent evaluation of a product to ascertain compliance to CM requirements and CM standards. . It is used to assess the product's baseline or release status, and determine whether the product is complete as delivered. Audits of CM activities are also performed to assess effectiveness of the project’s CM procedures and to identify areas for improvement.

There are three types of audits in Configuration Management:

· Functional Configuration Audits (FCA);

· Physical Configuration Audits (PCA) and

· Configuration Management (CM) Internal Audits.

Configuration audits for the <System Name> are defined in the following paragraphs. Project Managers are encouraged to develop Standard Operating Procedures (SOPs) in support of all CM Audits to ensure consistency and repeatability of processes.

(Please note that FCAs and PCAs are required when the System is new or evolving through a technical refresh of hardware and/or software. Otherwise, Systems that are in Operations and Maintenance (O&M) shall perform audits/verifications based on Change Request implementations.)

2.5

3.5.1 Functional Configuration Audit (FCA)

The purpose of the FCA is to validate that the system as developed satisfies stakeholder and functional requirement as allocated to the design. i.e., the “right system” has been built. FCA(s) are part of SDLC validation activities and usually performed at the completion of the development phase of the SDLC prior to the O&M gate review.

3.5.2 Physical Configuration Audit (PCA)

The purpose of the PCA report is to verify the system, as-built, satisfies the system requirements and conforms to the design (i.e., system “built right”). PCAs may be performed iteratively or concurrently as part of verification activities during the development phase of the SDLC and in conjunction with systems integration activities.

3.5.3 Configuration Management (CM) Internal Audits

The CM Team performs internal audits to confirm documented procedures are followed, such as:

Change Control – The CM Team audits activities and outputs to determine if they are in compliance with the Change Control Procedures.

Data Collection – The CM Team audits files and folders in NARA Enterprise CM tool to verify compliance with the Version Control and Naming Standard.

CM Audits – The CM Team conducts audits to verify compliance with the other CM procedures.

CR Workflow – The CM Team monitors the audit trail of CR documentation packages from initiation through closure.

Change Request Documentation – The CM Team examines records to verify that appropriate process related fields are properly populated.

3.5.4 CM Reviews

As per NARA’s SDLC, a system will evolve through a series of stages from concept exploration, through design, development, and utilization/support. SDLC stages provide logical breakpoints, called gate reviews, during which schedules, cost estimates, and technical capabilities can be reviewed and assessed. Gate reviews are used to ensure that project plans get updated to reflect more accurate estimates based upon actual project progress – and ensure that the system meets requirements and can still be delivered on time and in accordance with its business case. Gate reviews provide management visibility into a project and enable more effective risk management. Gate reviews are performed by NARA’s governance boards.

The CM team participates in and supports project gate reviews to ensure that project work products have been correctly identified by the project and disseminated to reviewer and CM Team. CM may also play a role in technical reviews that are performed internal to the project and within an SDLC stage such as:

Typical Design Stage Reviews

· System Requirements Review (SRR)

· Preliminary Design Review (PDR)

· Detail Design Review (DDR)

Typical Development Stage Reviews

· Test Readiness Reviews (TRR)

· Production Readiness Reviews (PRR)

Note: NARA 805 System Development Life Cycle (SDLC) specifies the method by which gateway reviews are tailored to the size and scope of the project. All deliverables required by the SDLC process should be checked into the Project CM repository before moving to the next phase.

4.0 Contractor CM Oversight

Contractors are required to submit a CM plan that documents the details for their respective CM program. The contractor’s CMP will be consistent with the <System Name> CMP as appropriate. Additionally, the contractor’s CMP and CM activities will be compliant with all contractual documents for the <System Name>. The contractor’s CMP must specify control for subcontractor activities if any; including subcontractor monitoring, audits and reviews to be performed, subcontractor change control process, and verification of all subcontractor deliverables.

Note: The Contractor’s CMP should be a deliverable to the <System Name> and is subject to review and acceptance by the appropriate <System Name> personnel The <System Name> PM or the delegated authority monitors the contractor’s CM activities to assess compliance with their procedures as defined in their CMP through performance, product and process reviews, and the conduct of informal CM audits.

2.6

5.0 Configuration Management Resources

Discuss the products, tools, personnel, and training required to implement CM activities for <System Name> as described in Appendix E “Configuration Management Support.” This appendix provides the document developer with current Enterprise CM Tools information and available supplemental artifacts that may be used for tailoring of a specific project.

<In developing this section of the CMP, the Project Manager is encouraged to use supplemental information that accurately describes project specific CM resources. In addition, please contact the NARA Enterprise CM Team for CM artifacts samples for use in developing project specific CM documentation.>

6.0 CM Plan Maintenance

The <System Name> CM Manager is responsible for the development and maintenance of Configuration Management Plan. At a minimum, the CMP will be reviewed annually and updated as needed throughout the entire project lifecycle to ensure the relevance and adequacy to plan and manage CM activities. The CMP is under CM control.

7.0 CM Training

Identify the CM training that will be required and provided for <System Name> staff members and the schedule for the training activities.

Training is required for the <System Name> CM process, the CM environment and tool usage. As the <System Name> matures, training will be required for new employees and for environmental and usage changes.

Appendix A: Acronyms

Table A-1: Acronyms Appendix B: Project CM Personnel

CM Manager

Quality Management

Testing

Release Manager

Table B-1: Project CM Personnel

Note: Add any other personnel as needed.

Appendix C: Selecting Configuration Items

Configuration Item Selection The following rules-of-thumb may be considered when identifying the discrete CIs of a project or system. A CI can be any item produced by a project team that requires controlled, managed access and version control. CIs can be hardware, software, firmware documentation, procedures, models, databases, training courses, etc. Projects will need to establish numbering schemes and CI classifications appropriate to the systems they are developing. Although configuration control may need to be more rigorous for system elements than project management work products, it is required in both cases.

· Is the item a schedule-critical, high risk, high cost, high criticality, and/or a safety related item?

· Is the item a system element or component that has been allocated system requirements as part of the system design?

· Will it be necessary to have an accurate record of the exact configuration of the item and the status of changes to the item throughout the system life cycle?

· Can the item be independently/ individually verified or validated?

· Does a single, approved, authorized version of the item need to be established.

· Is the item already in use in other projects (previous or existing)?

· Will there be a need to ensure timely and controlled incorporation of modifications into the item?

· Will access to the item need to be controlled, and provided to many project team members?

· Does the item represent a record or will a record of the item’s evolution need to be maintained?

Appendix D: Naming and Labeling Configuration Items

The following guidelines should be reviewed to determine the Configuration Items (CIs):

Identifying Configuration Items: Identify the CIs to be controlled at the different stages of the SDLC. The PM and SE identifies all the CIs for various stages of the SDLC after completion of Concept Phase. NARA has developed a comprehensive list of CIs to be developed under various phases of Lifecycle of a system. The project teams are required to develop a tailoring plan for CIs during development, evaluation, and maintenance phase of Systems. Please refer to the SDLC activity and artifacts listed in the attached link for tailoring plan for CIs.

Naming Configuration Items: Identify schema for assigning naming convention to CIs.

Acquiring Configuration Items: Identify the controlled libraries for the CIs. Describe how the code, documentation and baseline items are to be placed under appropriate library.

Naming Convention The naming convention for the CIs is organized into two (2) parts: CI type and the type of file. File names consist of a combination of the file or CI title with an underscore between each word in the title and file type extension, as shown Table D-1, Examples of File or CI. These CIs are tagged with version labels as described in Appendix D “Naming and Labeling Configuration Items.”

Table D-1: Examples of CI Identifiers Labeling Configuration Items (CIs) The following paragraph describes the labeling conventions for documentation CIs and Work products. The Labeling Standards table below identifies the baseline, type of deliverable, document acronym (if applicable), version number of the deliverable (release 1.0 or 1.1, etc.) plus the date of the deliverable. Each item is explained below the table.

Table D-2: Labeling Standards Where “n”BL defines the type of baseline:

Table D-3: Types of Baselines Where “nnnn” defines the type of deliverable:

· Strict

· Managed

· Contractual Docs (Contractor Deliverables)

· Work Products Where “AAA” defines the document acronym: e.g., CMP, PMP, QMP and TMP.

Where “vx.x” defines the version number of the deliverable, e.g., v1.0, v2.2, etc.

Where mm/dd/yy defines the month, day, and year of the deliverable as listed on the front page of the document.

NOTE: Additional labels can be applied as needed by the system.

Configuration Item (CI) Control Levels Provide definitions for the CM control levels appropriate to the <System Name>. Some samples are shown below. The table shows representations for each level with examples of work products, required reviews, and approval authority.

There are three (3) levels of CM control that Configuration Items (CIs) and Work Products are placed under.

· Strict Control – This is the highest level of CM control. Items placed under strict control require formal approval from the CCB (or other NARA governance boards or review authorities), and are explicitly versioned controlled. Formal Quality Management (QM) Peer Review or SDLC verification and review procedures must be adhered to for items under Strict Control. Items placed under strict control must be checked into the CM repository and follow project naming and labeling standards.

· Managed Control – This is an intermediate level of CM control. Items under Managed Control are version controlled but do not require formal governance review or formal signature approval. Items under managed control receive project level Peer Review or SDLC verification. Items placed under managed control must be checked into the CM repository and follow project naming and labeling standards.

· Minimal Control – These are items that do not require formal CM, or governance review but must be maintained for general project management or records management purposes (e.g., Meeting Minutes, Agendas, Presentations, Reports, etc.). Item under minimal control should be checked into the CM repository for recording keeping and audit support purposes.

Examples of Configuration Items and Work Products The following table shows examples of configuration items and work products for each level of control, required reviews, and approval authority. (There can be multiple approval authorities based on the needs of the project. Please modify as relevant to the project.)

· Requirements

· Design

· Management Plans

· Deliverables agreed upon between contractor and government

· Quality Assurance / Testing Review

· Peer Review

· Technical Writer (if available)

· Document Chair

· Designated Reviewers

· COR

· Change Control Board

· Document Chair

· COR

· Project Forms

· Project Templates

· Project Checklists

· Project specific documents

· Schedules

· Standard Operating Procedures (SOPs)

· Peer Review, when appropriate

· Manager/Owner’s Review

· Technical Writer (if available)

· Document Owner

· COR (If required)

· Work products under development

· Non-controlled items like Meeting Minutes

Table D-4: Configuration Management (CM) Control Levels Baseline Identification This section describes the program baselines associated with program phases and milestones.

Definitions: A baseline identifies an agreed-to description of the attributes of a product at a point in time and provides a known configuration to which changes are addressed.

Note: Baseline identification is defined both as the selection of the documents which identify and define the configuration baseline characteristics of an item and as the documents/products themselves.

The examples below show the most common baselines and their descriptions.

· Concept Baseline (CBL) The CBL documents the activities performed during concept exploration and baselines the related project documentation developed during the initiation phase.

· Functional Baseline (FBL) The FBL is created when the business requirements are translated into technical requirements and are mutually agreed upon between user and customer. The FBL is established at the completion of the System Requirements Review (SRR).

· Allocated Baseline (ABL) The ABL represents the next logical progression from the functional baseline and represents the link between the design process and the development process. The ABL begins at the conclusion of System Requirements (SR) and is formally established at the completion of Product Acceptance Test (PAT).

· Product Baseline (PBL) The PBL contains the approved documentation for defining a CI during the production, operation, and maintenance phase of the system’s lifecycle. The PBL is established upon formal acceptance. The PBL encompasses all releases for the present increment and each prior increment.

Note: It is suggested that all the baselines listed above may not be applicable to your project, e.g., Operational Systems may use only Product Baselines; new projects may use all baselines. Infrastructure hardware is controlled by Asset Management whereas applications loaded on the hardware are baselined, e.g., desktop image.

Configuration Management Libraries (CML) The CML is divided into four separate areas; an area for CIs that are placed under strict/managed control, the static library, staging area and physical library. These areas are discussed as follows:

· Strict/Managed Control Area – The Strict/Managed control area is an area of the CML that maintains the integrity of the <System Name> CI. These items are kept in the CM tool.

· Static Library – The static library is the area where items are placed for general information and review. Items that are placed in the static library can be modified by the CM Team only. The specific location of the static will reside on the shared drive for the <System Name>. The items placed in this location will be labeled as “read-only.”

· Staging Area – The staging area is the area where CIs are kept prior to being checked into PVCS Version Manager. The specific location of the workfile resides on the C Drive for each user for the <System Name>.

· Physical Library – The physical library stores and maintains physical work products, such as Commercial Off the Shelf (COTS) CDs, facility drawings, or signed copies of accepted documents. A secure environment will be designated by the <System Name> CM Manager to store and maintains the items placed in the physical library. In addition, the CM Manager will maintain a catalog list of items and place that list under version control in the Strict/Managed Control Area.

Appendix E: Configuration Management Support

Configuration Management (CM) Organizational Products The <System Name> CM Manager has identified and developed procedures to govern the daily execution and management of the <System Name>. Systems Application and will continue to do so as needed. As these procedures are implemented, they will continue to be reviewed to determine their impact on the execution of this plan. All the Standard Operating Procedures (SOPs) will be checked into the PVCS Version Manager CM repository. At a minimum, the following CM artifacts will be implemented by the <System Name>. Project Team:

· <System Name>. System CCB Charter

· <System Name>. System CCB Process SOP

· <System Name>. System CR Form NARA Enterprise CM Tools It is encouraged to use Enterprise CM tools for Version Control and Change Management.

Appendix F: Classification of Document Changes

Major or Minor Document Updates The CI version number is the version number (Version 1.0) on the cover page of a document. It is used to indicate the progressive updates to a document. Changes to CIs can be either major or minor.

A major document update may include documentation of new program activities or extensive rework and is indicated by an increment to the next whole number, for example, 7.0 to 8.0 (these numbers are version numbers listed on the front page of the document). The document owner determines whether the updates are major or minor.

A minor document update to documents may include, but is not limited to, spelling, grammar corrections, enhancements, or clarification. A minor release is indicated by an increment of .1; for example, 7.4 to 7.5 (these numbers are version numbers listed on the front page of a document).

Appendix G: Release Conventions The following paragraph describes sample labeling conventions for scheduled releases, e.g. Maintenance Release. Project will need to define labeling and numbering conventions for identifying iterations of project work products and system releases.

<System Name>_X.Y.Ya, e.g. CMRS_1.1.2a Where <System Name> is constant, e.g., CMRS, ERA, etc.

X is the Release Number, e.g. 1. (A release life cycle refers to the phases of implementation of a composite, integrated system element. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the system.)

Y.Y is the build number, e.g. 1.2. (As a rule, a build is a pre-release version and as such is identified by a build number, rather than by a release number. Iterative (repeated) builds are an important part of the development process and is used for testing purposes. Throughout development, application components are collected and repeatedly compiled for testing purposes, to ensure a reliable final product.

A is an out of schedule build or partial build.

Appendix H: Key Terms and Definitions A CI is any document, diagram, software component, file, model, hardware element, database, or procedure developed by the <system name> project that requires version control and access control, and must be managed throughout the life cycle of the system.

Work products are aggregates of numerous CIs such as documents with embedded diagrams, composite software systems containing numerous software modules, or composite system elements containing hardware, software, and process components.

Versions are iterations of individual CIs or composite work products that reflect changes in structure or content from the previous version.

Releases are formalized updates to work products that are: (a) assigned specific release identifiers, (b) given official release dates, (c) formally reviewed and vetted, (d) widely and formally disseminated, and (e) usually the outcome of specific project activities prescribed by <System Name> Program Plan. All versions of a work product are not necessarily releases, i.e., numerous intermediate versions of a work product (and its component CIs) may be developed prior to an official release.

Version Control is the process of tracking and controlling the changes to a specific CI or work product.

Staging (build or assembly) is the activity of combining and integrating composite work products from their component CIs and rendering those work products in whatever formats are appropriate for the distribution of a release. In software development parlance, this is analogous to the build, and packaging of a software release. In systems engineering parlance, this is analogous to assembly, integration, and packaging of system elements.

A baseline is a specific release of a work product and each of its component CIs that are aggregated as a composite set of related files, under version control and configuration management (usually in a CM tool), and staged for release. A baseline also contains any staging instructions that describe how to assemble the work product from its component parts and verify the assembly.

Configuration Management is the process of managing the individual CIs that constitute a composite work product, i.e., configuration. Configuration management is used to manage the collection and integration of CIs that comprise a work product, with each component CI being separately maintained and managed under version control.

Release Management is the process of disseminating, tracking, and controlling a composite set of work products (e.g., a software release or a sub-system build) that are under configuration management.

Appendix I: Change Request Form and Instructions Change Request (CR) (For specific instructions for each field see pages 2 and 3)

*Change Requests (CRs) that impact NARANet will be processed by the NARANet staff.

image2.emf

SDLC_Activity_Detail_N_CIs.doc image3.emf

Change_Request_Form.doc Change Request (CR)

(For specific instructions for each field see pages 2 and 3)

Contact Information:

Submitter’s Name:

Phone:

Organization:

Change Information:

Submit Date:

Requested Completion Date:

Title of Change:

Description of Change:

Requirement(s) Affected:

Project(s) Affected:

Product Owner(s)/Project Manager(s) Name:

Configuration Item(s) Affected:

Related Changes:

Priority:

FORMCHECKBOX

High

FORMCHECKBOX

Medium

FORMCHECKBOX

Low

Will this result in a configuration change to NARANet or a System on NARANet? (If YES, complete the Type of Change field)

FORMCHECKBOX

YES

FORMCHECKBOX

NO

FORMCHECKBOX

DON’T KNOW

Type of Change:

FORMCHECKBOX

Fix to Existing System

FORMCHECKBOX

Configuration Update to Existing System

FORMCHECKBOX

New System (For the New Systems only provide the following :)

· Transition to Operations Documentation (TTO)

· IT Security Scan Information and Approval

· System Security Plan (SSP)

Is this request for coordination/informational only?

Is the work going to be performed outside of NARANet Staff? (If YES, continue with the questions below)

FORMCHECKBOX

YES

FORMCHECKBOX

NO

Work Plan:

Test Plan:

Back-Out Plan:

Planned/Potential Application Outages:

Additional Personnel Resource Requirements:

Security Impact Assessment Questionnaire Section:

Security Impact Assessment Questionnaire (see legend on specific instructions on page 3):

Will this modification change security controls?

FORMCHECKBOX

YES

FORMCHECKBOX

Will this modification introduce new hardware or software?

FORMCHECKBOX

YES

FORMCHECKBOX

*Change Requests (CRs) that impact NARANet will be processed by the NARANet staff.

Contact Information

Submitter Name: The name of the person submitting the request

Phone Number: The phone number of the person submitting the request

Organization: The office symbols of the person submitting the request

Change Information

Submit Date: The date the request is submitted

Requested Completion Date: The date that the requestor wishes the request to be implemented by. If a short turnaround for the request is necessary, please provide a business justification. Note that the actual implementation date will depend on the priority and complexity of the request as well as the resources available. If the request will result in a change to NARANet or a System on NARAnet an estimated implementation date will be negotiated at the Technical Review Board.

Title of Change: A brief title to describe the change

Description of Change: Provide a description of the work that is expected to be performed to fulfill this request.

Requirement Affected: Describe the requirement(s) affected or which requirement(s) previously established will not be met.

Project Affected: Provide the name of any project/s (if any) that are related or may be impacted by this work.

Product Owner(s)/Project Manager(s): Provide the name of the individual(s) responsible for all aspects of the application.

Configuration Items Affected: A list of the CIs Nomenclature (Hardware/Software/Documentation) affected by the change.

Related Changes: Enter the ID number of other changes related to this change.

Priority:

· High: Significant impact that is causing work to slow or stop.

· Medium: May be impacting work but for which there is a work-around.

· Low: Low impact or where a work-around is easily followed.

Will this result in a configuration change to NARANet or a System on NARANet? (If YES, complete the Type of Change field)

Type of Change: Select from the list of options and provide the applicable documentation as indicated.

Is this request for coordination/informational only? If this request is being submitted for CCB approval only and no work is being asked of NARANet Staff, check YES. The CCB must review and disposition any proposed changes to the NARA Infrastructure. Protocol requires that RFCs be submitted and NARANet Staff be notified of any change to NARA systems, thus RFCs may be submitted to document work performed outside of NARANet Staff.

Plans (Optional, unless the request is coordination/informational only)

Work Plan: A basic step by step description of all tasks and steps to be accomplished in the execution of the proposed change. This plan is to be thorough and is to include all steps necessary to ensure completeness and quality of the implementation. Referencing of manufacturer processes and procedures or other standard documentation is encouraged.

Test Plan: Complete listing of all steps and tests to be performed to assure that the intended results of the change have been achieved (that the changed/upgraded system is fully operational with no loss of functionality, performance, or availability). This area should also include the name of any individual(s) who will be performing or assisting in the testing.

Back-Out Plan: A complete process/procedure identifying all steps and actions that will be accomplished to thoroughly return the system to its original configuration, should the upgrade to the system not be successful. If this plan includes the requirement for recovering the system from backup tapes, this must be clearly documented including all steps to verify that backups are successful prior to executing the requested change.

Planned/Potential application outages: A list of applications that may need to be taken offline during implementation of change.

Additional personnel/staff resource requirements: A list of personnel that may be necessary for the implementation of plans.

Security Impact Assessment Questionnaire Section:

Security Impact Assessment Questionnaire: Provide the impact of this change to security requirements of the system(s).

Answers to Security Impact Assessment Questionnaire Legend:

· N, N = Minor Modification (No Security Impact)

· Y, Y = Major Modification ST&E, Possible Re-Authorization

· Y, N = Can this modification be verified with documentation only?

· Y = Major Modification Documentation Only

1. “As is-to be” system diagrams and inventory

2. Modification to system description and control sections of SSP

3. Draft Security Impact (risk) Assessment

· N = Major Modification ST&E

1. “As is-to be” system diagrams and inventory

2. Modification to system description and control sections of SSP

3. Risk Assessment Update

4. Schedule ST&E

NOTE: For further guidance in completing the Security Impact Assessment Questionnaire, please contact a representative from the IT Organization.

image1.emf