ePS_RFP_Attach_10_CM Plan_20170214.pdf

Distribution Notice D: Authorized to the Department of Defense (DoD) and DoD Contractors only. This document is for administrative or operational use, as of the date of approval for this document. Refer to the Program Manager (PM), PMW 220 Navy Enterprise Business Solutions (Navy EBS), Program Executive Office Enterprise Information System (PEO EIS), Washington Navy Yard, 1325 10th St. SE, Bldg. 196, Washington, D.C. 20374 for additional document requests.

Handling and Destruction Notice: Comply with distribution statement and destroy by any method that will prevent disclosure of contents or reconstruction of the document.

Configuration Management Plan

Electronic Procurement System

Version: 1.0

Date: 5 January 2016 electronic Procurement System Request for Proposal

Attachment 10: Configuration Management greg.mcconnell@kildagroup.com Typewritten text Solicitation # N00039-17-R-0002

EPS

Configuration Management Plan Filename:

EPS_CMP_v1p0.doc Page:

2/142 Version:

Version 1.0

Date of Creation:

5 January 2016

Released by:

B. C. URBON Date

Program Manager

Navy Enterprise Business Solutions Program Office ePS

Configuration Management Plan

Filename:

ePS_CMP_v1p0.doc Page:

3/142 Version:

Version 1.0

Date of Creation:

5 January 2016

Document History

VERSION DATE

DESCRIPTION OF

CHANGE

RESPONSIBLE

INDIVIDUAL

1.0 14 December 2015 Initial Document – Cleaned up Table and Appendices

Sonja Mooney

Page:

4/142

Table of Contents

Executive summary

1 Introduction

1.1 Purpose

1.2 Scope

1.3 Overall Description

1.4 CM Program Objectives

1.5 CM Pillar Characteristics

1.6 CMP Maintenance

2 Configuration Management Functions & Principles

2.1 Configuration Management & Planning

2.1.1 Function

2.1.2 Principle

2.1.3 Activity

2.2 Configuration Identification

2.2.1 Function

2.2.2 Principle

2.2.3 Activity

2.3 Configuration Change Control

2.3.1 Function

2.3.2 Principle

2.3.3 Activity

2.4 Configuration Status Accounting

2.4.1 Function

2.4.2 Principle

2.4.3 Activity

2.5 Configuration Verification & Audit

2.5.1 Function

2.5.2 Principle

2.5.3 Activity

2.6 Data & Document Management

2.6.1 Function

2.6.2 Principle

2.6.3 Activity

3 Configuration Management Paradigms

3.1 Product – Platform

3.2 Acquirer – Supplier

3.3 Acquisition – Operational Paradigm

3.4 Data – Document Paradigm

3.5 Family of Systems (FoS) Paradigm

4 CONFIGURATION management tools

4.1 Management Tools

Page:

5/142

5 Organizational Roles & Responsibilities

5.1 Configuration Management Roles

5.2 CM Program Participants

5.3 CM Program Stakeholders

6 Software Product Configuration Management

6.1 Material Solution Analysis (MSA) CM Tasks

6.1.1 Calculate CM Personnel Requirement

6.1.2 Material Solution Analysis (MSSA) CM Deliverables

6.2 Technology Maturation and Risk Reduction (TMRR) CM Tasks

6.2.1 Update functional baseline

6.2.2 Ensure all Required Information Captured

6.2.3 Distribute Updated CMP

6.2.4 Technology Maturation and Risk Reduction (TMRR) CM Deliverables

6.3 Development and Deployment (D&D) CM Tasks

6.3.1 Physical Configuration Audit

6.3.2 Update Product Baseline

Development and Deployment (D&D) CM Deliverables

6.3.3 Verify CMP Implementation

6.3.4 Development and Deployment (D&D) CM Deliverables

6.4 Operation and Support (O&S) CM Tasks

6.4.1 Create As-Installed Baseline

6.4.2 Capture Configuration Item Disposal Status

6.4.3 Update CMP

6.4.4 Operational and Support (O&S) CM Deliverables

7 Platform Configuration Management

7.1. Baseline Management CM Tasks

7.1.1 Management of Planning & Requirements Documents

7.1.2 Create To-Be Baseline

7.1.3 Baseline Management CM Deliverables

7.2 Release Management CM Tasks

7.2.1 Create Integrated Risk Assessment

7.2.2 Coordinate Platform Local Configuration Control Board (PLCCB)

7.2.3 Release Management CM Deliverables

7.3 Sustainment CM Tasks

7.3.1 Monitor As-Installed Baseline

7.3.2 Platform Configuration Audit

7.3.3 Review Platform Configuration Status Accounting Reports

7.3.4 Sustainment CM Deliverables

7.4 Disposal CM Tasks

7.4.1 Change Request for End of Life

7.4.2 Platform Baseline Update

7.4.3 Platform Configuration Status Accounting Records

7.4.4 Disposal CM Deliverables

8 Appendicies

Page:

6/142

8.1 Appendix A: Product Task & Deliverable Cross Reference

8.2 Appendix B: Configuration Management Training Plan

8.3 Appendix C: Configuration Items

8.3.1 Selection Criteria

8.3.2 Naming Convention

8.3.3 Control Levels

8.3.4 Serena Dimensions

8.3.5 CI Baselines and Documents Identification

8.4 Appendix D: Technical Baseline Reports

8.5 Appendix E: Technical Baseline Hierarchical Structure View

8.6 Appendix F: CCB Charter

8.7 Appendix G: RFC Process

8.8 Appendix H: RFC Template

8.8.1 CR Classes

8.8.2 Priority Levels

8.9 Appendix I: Configuration Control Board Agenda Minutes

8.10 Appendix J: Functional and Physical Configuration Audit Report Template

8.11 Appendix K: Functional and Physical Configuration Audit Standard Process

8.13 Appendix M: Process Improvement Metrics

8.14 Appendix N: Data & Document Management Conventions

8.15 Appendix O: Trigger List for CRs

9 References

10 Acronyms List

List of Tables Table 1: Configuration Management Tools

Table 2: CM Program Participant Roles & Responsibilities

Table 3: CM Program Stakeholder Roles & Responsibilities Table 4: Product Task & Deliverable Cross Reference

Table 5: Configuration Item Selection Criteria Checklist Table 6: Technical Baseline Report & Source Data Table

List of Figures Figure 1: Top Level Configuration Management Activity Model

Figure 2: ePS Staffing Hierarchy

Page:

7/142

EXECUTIVE SUMMARY

The Electronic Procurement System (ePS) Configuration Management Plan (CMP) serves as the primary Configuration Management (CM) document for the ePS Program. The ePS overarching

CM strategy will be captured in this CMP, which will establish the procedures and guidelines for

CM processes, define responsibilities, specify requirements for making modifications to

Configuration Items (CIs), and facilitate the implementation of standardized CM practices.

In October 2011 and September 2014, Office of the Secretary of Defense (OSD) declared the sunset of its mandated Standard Procurement System (SPS), set a timeline to cease its operations, and further, directed each Service Component to plan and budget for future contracting capabilities. Rather than specifying a specific solution that may not be usable in all environments, DON has mandated common output formats, data sources, and internal controls that any contract writing system (CWS) must meet. Because the ePS program will be DON-specific, and there are no joint requirements, it continues to be a non-Joint Requirements

Oversight Council (JROC) interest program and is not subject to JROC oversight.

The need for the ePS is driven by DON’s intent to solve the immediate problem posed by sunsetting the SPS as well as the DON’s larger need for a true “end-to-end” contracting system in keeping with the resiliency of modern provisioning of IT services, moving away from rigid, legacy systems.

The DON’s vision for the ePS is driven by three basic principles. The first principle is a renewed commitment to a future Program based on the DON’s CWS requirements. The second principle is adherence to business principles codified in Federal and DON Information Technology (IT) acquisition processes. The final driving principle is capitalization on IT trends and a push to exploit them when practical.

The ePS Program will provide the DON with standardized, seamless, end-to-end contract management (i.e. sourcing) of services, supplies, and construction. The ePS will also support mission-related assistance through the use of assistance agreements such as grants. The ePS will deliver the following functional/technical capabilities:

Provide robust functional capabilities to support the end-to-end Procure-to-Pay (P2P) process

Capture data at the source (i.e., no redundant data entry via touch labor)

Leverage a data-centric and standard-compliant design for data storage and exchanges

Enforce business process controls and system controls to support a clean audit opinion

Inform decision making through available, accurate, timely, and visible reporting

Comply with DON-specific architecture and environmental constraints (e.g., Navy/Marine

Corps Internet (NMCI)/ Next Generation Enterprise Network (NGEN))

Deliver a flexible solution that allows changes to be made promptly and cost-effectively

Support 100% of the DON contracting actions in a fully auditable and traceable environment

Provide a secure computing environment that implements critical security controls and capabilities

Page:

8/142

The ePS provides the potential for the Navy and Marine Corps to develop a true end-to-end electronic procurement system capable of processing contract requirements from inception to closeout in a fully electronic and data-centric fashion. The ePS will serve as system of record for the full electronic contract file. The system will have the flexibility to interface with other electronic systems as needed to meet the needs of all stakeholders, and as defined in statutes, regulations, and approved business practices. Data captured through system automation and distributed through interface transactions are critical elements in supporting the DON’s Financial

Improvement Program (FIP) and in enabling DON’s vision of clean financial statements.

The ePS program will follow Information Technology Infrastructure Library (ITIL) processes to manage the five CM pillars identified in Industry Standard 649B and DoDI 5000.02 as well as the PEOEISINST4130.3 Life Cycle Configuration Management Organizational Standard

Process Book.

Page:

9/142

1 INTRODUCTION

1.1 Purpose

The Configuration Management Plan (CMP) is a tool used to establish the overall approach for the CM requirement for the ePS system. The purpose of this document is to identify and describe the overall policies and methods for the CM activities to be used during the system life cycle and will be updated progressively as the work proceeds and the necessity arises. The primary intention of this CMP is to provide overall information on the CM policy and methods to be adopted and implemented for the ePS program including: submitting, planning, approving, and implementing changes.

CM implementation requires a balanced and continuous application of CM functions and their underlying principles throughout the lifecycle of the ePS program. To manage continuous CM application throughout the ePS Program, specified CM paradigms and associated roles are identified in this CMP.

The high-level CM process for the ePS Program provides CM guidance to systems or software engineering IPTs and those that provide technical support services. Figure 1 delineates the

Configuration Management Activity Model. The high-level CM process steps include:

Configuration Management & Planning

Configuration Identification

Configuration Change Control

Configuration Status Accounting

Configuration Verification and Audits

Figure 1: Top Level Configuration Management Activity Model

Page:

10/142

This CMP focuses on directing the following actions:

1. Configuration management actions in support of the Capability Development Document

(CDD). These are actions taken to make certain that any future changes to the CDD or

System Requirements, or development of future ePS functionality beyond the Initial

Build, follow approved configuration management guidelines. One example is to identify changes desired by stakeholders that could affect overall ePS operations, and gain approval before such changes are made. This will ensure the developed system meets requirements and continues to support all users.

2. Configuration management actions in support of the Navy Enterprise Service Bus

(NESB) used in ePS data exchange.

3. Formally document problems associated with the functional interfaces and the communications network, as reported by users, and additional or changed requirements, including enhancement suggestions.

This CMP will describe the overall technical and administrative direction and control for ePS during the total system life cycle, including operational phases. Serena Dimensions will be used to manage and control this document.

1.2 Scope

CM is a system engineering discipline that formalizes the management of the configuration of a system and controls changes to the system throughout its lifecycle. The key principles of CM ensure that all components of the system can be uniquely identified, managed, and that any previous version of the system can be readily reproduced. CM is the formal process to track changes to any approved baseline configuration throughout the entire program lifecycle. It ensures all approved changes are properly documented to ensure accurate configuration identification and interoperability with software. CM will manage all changes to program configuration baselines using the Configuration Control Board (CCB) to prepare, justify, evaluate, coordinate, adjudicate, and implement Requests for Change (RFCs) of affected

Configuration Items (CIs) and baseline configuration documentation.

The scope of CM in the ePS program includes planning, recording, controlling, reporting, change processing, tracking implementation status, and validating compliance requirements throughout all phases of the change process during the lifecycle of the program.

The scope of this CMP specifies the requirements for performing CM within the DON ePS

Program. It assigns responsibilities, defines roles and promulgates the PEO EIS approach to satisfying the CM of product and data in each phase of the program lifecycle. This document identifies the policies, processes, procedures, methods, tools, and organizational responsibilities that will support the implementation of the program’s CM strategy. This CMP applies to all software, COTS products, documentation, and physical media used by ePS and supporting contractor teams to support various activities, including requirements, system engineering, interface management, implementation, testing, data management and configuration

Page:

11/142 management. This document is intended to serve as the model by which ePS will be established, maintained and enhanced in the future.

The information contained in this CMP will be used to provide CM guidance and policy for the development of applicable CM standard operating procedures that would document day-to-day performance of activities with the CM program; however, it can be used as a basis for implementing ongoing business process improvement as needed throughout the life of ePS.

1.3 Overall Description

The implementation of a formal and structured CM program ensures that the appropriate ePS project artifacts are identified and captured in the ePS Change Management process and related procedures. These processes and procedures provide objectives, requirements, and step-by-step instruction on the performance activities within the CM program for ePS. This CMP establishes the method for identifying, implementing, controlling, accounting for, and auditing changes to the approved ePS configuration baseline, as it exists at any point in time.

DoDI 5000.02 guidance for CM is that the Program Manager (PM) will use a configuration management approach to establish and control product attributes and the technical baseline across the total system life cycle. This approach will identify, document, audit, and control the functional and physical characteristics of the system design; track any changes; provide an audit trail of program design decisions and design modifications; be integrated with the Systems

Engineering Plan (SEP) and technical planning; and be consistent with the Intellectual Property

Strategy. At completion of the system level Critical Design Review (CDR), the PM will assume control of the initial product baseline, to the extent that the competitive environment permits.

1.4 CM Program Objectives

The CM program is the mechanism to evaluate proposed changes, notify impacted functional areas or groups in advance of forthcoming changes, and to insure an orderly and accurate integration of new capabilities and features. The CM program and approach is flexible enough to provide applicability across multiple applications while ensuring a standard program for version control of the base platform.

The objectives of the CM program described within are to:

Implement the configuration management policies established by the DoDI 5000.02 and

PEO-EIS.

Compile consistent configuration data that defines baseline identification of ePS configuration items, their features, and their capabilities at any point in time.

Provide consistent and unified status accounting of all baseline documents and changes thereto; and, provide a mechanism for requesting changes to the ePS baseline.

Provide a method for obtaining a coordinated review of proposed changes to ePS.

Track configuration control decisions.

Page:

12/142

Make configuration identification data available to functional areas needing data for supporting and configuring applications using ePS.

Define a mechanism for obtaining certification and accreditation and/or Authority to

Operate (ATO) which validates the security of the system.

1.5 CM Pillar Characteristics

Each CM pillar has representing characteristics that identify what type of activity or information should be captured. Those characteristic elements are as follows:

Management and Planning – Selection, Tailoring, Guidance, and Oversight;

Configuration Identification – Attributes, Identifiers, and Baselines;

Configuration Change Control – Manage Changes;

Configuration Status Accounting – CM Information and Status;

Configuration Verification and Audits – Verify Performance and Consistency;

1.6 CMP Maintenance

The CMP is a living document and as a result additions, deletions, and modifications will occur as it is utilized. It will be updated as additional configuration activities are defined as the work proceeds and the necessity arises. Changes to this document after acceptance of the initial version require approval of the CCB.

Page:

13/142

2 CONFIGURATION MANAGEMENT FUNCTIONS &

PRINCIPLES

2.1 Configuration Management & Planning

2.1.1 Function

Configuration management is a systems development discipline that promotes the proper identification of the configuration, control of changes, and records the change implementation status of the physical and functional characteristics of the ePS system.

Configuration Management identifies what is required, designed, and produced. It also provides for the evaluation of changes including effects on technical and operational performance. This leads to making the configuration visible and understood by all the parties involved with the project. Configuration management is therefore the means through which integrity and continuity of the system’s design, and decisions made regarding technical performance, producibility, operability, and supportability are recorded, communicated, and controlled.

Configuration management covers three basic essential interdependent activities:

Identify CIs for CM control that establish baselines

Track and control changes to the baselines and CIs utilizing Serena Dimensions

Establish the integrity of the baseline through keeping true record of each baseline and performing configuration audits

2.1.2 Principle

A fully integrated CM policy is achieved by applying the principles of CM and process management across all areas. This enables the identification of common items or data across program areas, ensures implementation of repeatable processes, enables total lifecycle tracking, and measures effectiveness, performance and compliance with ePS goals and objectives. This will also enable ePS leadership to identify and include the appropriate level of resources necessary to efficiently and effectively conduct CM. The ePS CM Lead will ensure implementation of CM throughout the applicable phases of the lifecycle to provide consistency among the product, platform, requirements, information, and the suppliers.

The following team members participate in the delivery of artifacts (software, documents, etc.) to support the development of the ePS product:

Project Management

Engineering Management

Configuration Control Board

Requirements

Software Quality Assurance

Page:

14/142

Data Architecture

Logistics Support

Documentation/Data Management

2.1.3 Activity

The ePS Configuration Manager will provide the direction and resources necessary to enact and accomplish this plan. The following members will provide execution information for inclusion into this plan: The IPT Lead and other affected groups review and provide commitment/approval to the plan. The IPT/CM Group establishes the CM system, determines and procures appropriate tools, and develops detailed procedures to implement CM activities. The CM program includes a change management system, to include impact analysis of RFC, categorization, and prioritization. The IPT Lead/PM schedules formal reviews and status reporting of CM activity in the IPT schedule and documents the requirement for these reviews. The CM Manager collects work products, measures (if appropriate), and improvement information derived from planning and performing to reviewing the effectiveness of CM activities. The IPT Lead/PM analyzes the measurements, if collected, to develop improvement objectives for CM. The IPT Lead/PM appoints the members of the CCB and serves (or delegates someone to serve) as the CCB Chair.

The Document Manager (DM) or Configuration Support Manager is responsible for tracking and storage of deliverables, action items, minutes, decisions and other documentation. The Quality

Assurance (QA) Manager ensures all Software Quality Assurance (SQA) analysts work within the CM plan’s guidelines. Also the QA Manager ensures that the SQA analysts are testing from official CM releases. The SQA Analysts are responsible for testing installed COTS releases, as

CM provides releases. Applicable Information Assurance (IA) Controls will be implemented to address all appropriate CM activities. Refer to ePS Acquisition Information Assurance Strategy

(AIAS) version 1.2 for further IA detail located in the Enterprise Content Management System

(ECMS) collaboration repository.

The ePS CM will manage in accordance with this CMP, assign responsibilities, measure performance, train personnel or obtain appropriate training, and assess options for process improvements.

2.2 Configuration Identification

2.2.1 Function

The objective of configuration identification is to incrementally establish and maintain the current basis for control and status accounting of a system and its CIs throughout their respective lifecycles. Configuration identification is the formal step of identifying the configuration of an item (i.e., name, location, version), and documenting its’ functional and physical characteristics.

It further allows for documenting engineering changes and assures there are no impacts on current baselines. All artifacts, plans, metrics and other program items are maintained under configuration control but not all items will be designated as CIs to be managed in a more controlled manner.

Page:

15/142

2.2.2 Principle

Configuration identification is the basis from which the configuration of products are defined, structured, and labeled to provide traceability throughout the product’s lifecycle. Product identifiers are assigned so that one product can be distinguished from another. A series of like units of a product is assigned a unique product group identifier when it is unnecessary or impractical to identify individual units, but necessary to correlate units to a family of systems

(FoS) to maintain interface integrity. All documents reflecting product performance, functional, or physical requirements and other product information are uniquely identified in a baseline so that they can be correctly associated with the applicable configuration of the product. All determined CIs will be named and managed according to the naming convention and control levels identified in Appendix C.

2.2.3 Activity

The IPT Lead/PM or the CM Manager identifies the specific IPT-related items under configuration control. Future Technical Data Packages (TDPs), Software Development Folders

(SDFs), and other required CI artifacts (see Appendix C) shall be included in this set as appropriate. The IPT/CM Group uses existing identification systems (may be at a level higher than the IPT) or when no appropriate system of unique identification exists, creates a system, and assigns unique identifiers (including the associated baseline) to specified items. The

Configuration Manager and support team establishes and maintains a database of the assigned configuration identifiers, and reports them in the Configuration Status Accounting Report

(CSAR), as required. This CM team then assigns unique tracking numbers to various types of change requests related to work products and existing baselines and maintains a product baseline database.

2.3 Configuration Change Control

2.3.1 Function

Configuration control is the exercising of established procedures to classify, approve or disapprove, implement, and confirm changes to the agreed upon specifications and baselines.

The objective of configuration change control is to manage preparation, justification, evaluation, coordination, disposition, and implementation of proposed engineering changes and deviations to effected CIs and baseline configuration documentation.

2.3.2 Principle

Configuration Change Control allows for the efficient change processing and communication of change information that will impact the current baseline and preserving current system interfaces. All deviations are documented and evaluated for cost and effectiveness. This action allows the ability to communicate through proper channels the status and contents of changes.

A unique change identifier enables tracking of the change request and the status of implementation and verification of the approved change.

Page:

16/142

2.3.3 Activity

The CCB periodically meets to approve baselines of IPT/CM WG products and processes and to review proposed changes. This CMP provides detail on the prioritization and categorization of change requests. CCB secretariat document CCB agendas and maintain minutes of these meetings. The IPT/CM WG tracks the delivery of releases and associated changes to approved baselines. The IPT/CM WG establishes and maintains CM libraries of IPT/CM WG products, processes and approved baselines; levels of control; and procedures for authorized access to controlled configuration items. Applicable IA Controls will be implemented to address all appropriate CM activities. Refer to ePS AIAS version 1.2 for further IA detail in ECMS.

2.4 Configuration Status Accounting

2.4.1 Function

Configuration accounting is the formal recording and reporting of data relating to configuration identification, approval status of proposed changes, and implementation status of approved changes during all phases of ePS. The purpose of CSA is to provide highly reliable source configuration information to support all project activities. CSA assists in establishing procedures between COTS vendors and government databases to ensure the integrity of the configuration information is correctly applied. These procedures are evaluated to allow the recording and reporting the changes in the databases.

Configuration status accounting activities collect data that can be used to measure various aspects of program effectiveness and to assess product completeness and quality. The three primary types of configuration status accounting reports identified for the ePS program are listed below:

Configuration Item Lists

Audit Reports

CR Reports

2.4.2 Principle

The intent of CSA is to accurately and timely facilitate the extraction of configuration information to make determination on the proposed changes, deployment, and etcetera. This will help alleviate the possibility of improper decision on erroneous data that can increase cost and impact efficacy.

2.4.3 Activity

The CM team will maintain a repository for collecting and reporting data relating to configuration identification, approval status of proposed changes, and implementation status of approved changes during all phases of ePS. This may be in the form of a database or other automated data management system. They document the specifications for ePS in the approved

CM Tool, Dimensions, and include the appropriate method(s) for accessing this repository and archiving the data. Applicable IA Controls will be implemented. Refer to ePS AIAS version 1.2 for further IA detail in ECMS.

Page:

17/142

2.5 Configuration Verification & Audit

2.5.1 Function

The Configuration Verification and Audit (CVA) function is the formal evaluation of the characteristics of a CI to verify that the CI has achieved the requirements specified to demonstrate the achievement of those specified requirements. CVA allows the government to examine and verify the “to be fielded” configuration of a validated system against performance requirements, test plans, etc. to resolve any discrepancies between product(s) tested and current associated documentation.

2.5.2 Principle

CVA offers verification between current configuration and attendant documentation in support of established requirements. Audits and review actions are performed to verify that the product matches the CIs described in the specification and other documents and that the package is reviewed prior to release, This will preclude the possibility of maintaining inaccurate manuals, wrong replacements, or obsolescence items.

2.5.3 Activity

The IPT/CM WG performs periodic audits to confirm that repositories of configuration identifiers, CSARs and product baselines are complete, consistent and accurate. The CM

Manager oversees resolution of reported deficiencies identified during these audits. The IPT/CM

WG also conducts audits of the functional characteristics of the products to verify they have achieved the requirements specified in the functional and allocated configuration documentation

(also referred to as a Functional Configuration Audit (FCA)). Audits will be conducted of the as-built product configurations against the technical documentation to establish or verify the product baseline (also referred to as a Physical Configuration Audit (PCA)). Testing audits will be performed to assure quality and to assess the correctness, reliability, usability, and performance of the new ePS in a test environment utilizing test data only. Applicable IA

Controls will be implemented. Refer to ePS AIAS version 1.2 for further IA detail in ECMS.

2.6 Data & Document Management

2.6.1 Function

Data and Document Management (DDM) is a discipline that monitors all recorded administrative, managerial, financial, and technical configuration information, regardless of medium or characteristics. It includes ownership and approval of documentation and data, versioning of documentation and software, and document and data repository control and access.

The DDM function is not part of the top level CM activity model but will be addressed during the ePS system lifecycle.

Page:

18/142

2.6.2 Principle

DDM defines the relevant scope of the data, plan for the data, acquire and provide data responses, and develop processes to fit the context and environment in which they will be performed. DDM identifies data products and views so that their requirements and attributes can be controlled as well as control data repositories, data products, data views, and metadata using the ePS Change Management process.

2.6.3 Activity

Currently, CM is using a suite of tools that provides end to-end closed loop for configuration management data. This begins with configuration identification and proceeds through change requests, control board authorizations, development status/history, testing status/history, client promotion, release management, version control, baseline identification, support for audits, and reporting on CM process metrics. Applicable IA Controls will be implemented. Refer to ePS

AIAS version 1.2 for further IA detail in ECMS.

Page:

19/142

3 CONFIGURATION MANAGEMENT PARADIGMS

A paradigm is a set of ideas used for understanding or explaining a particular set of related items.

CM paradigms, as related to ePS, are defined in the context of the relationship between products and platforms, acquirer and supplier, acquisition and operational environments, data and document management and Family of Systems (FoS). See sections below.

3.1 Product – Platform

The relationship between the ePS COTS software solution and applicable hardware located at designated hosting centers will be configured to optimize the DON operational environment (as delineated in the ePS functional requirements set). This platform shall be supported by a traditional Test & Evaluation (T&E) as depicted in the ePS T&E Strategy (TES). Subsequently, User Acceptance Testing (UAT) shall support fielding coordination, configuration data transition, and communication between product and platform stakeholders.

3.2 Acquirer – Supplier

The relationship between PMW220 and selected ePS COTS software vendor(s) will be under contract to provide product services. This relationship is responsible for both the monitoring of supplier performance under contract or agreement and the funding for delivery of required products and/or services. The Configuration Manager maintains communication, reviews CM deliverables, and clearly articulates CM requirements to the activities, agencies, and /or contractors acting as suppliers providing services, products, and/or product support. The relationship between the acquirer and the supplier will be documented within the applicable change process identified within this CMP to ensure required change visibility or approval authority is maintained.

3.3 Acquisition – Operational Paradigm

PMW220 has the responsibility to acquire ePS and provide operational support. The Deputy

Assistant Secretary of the Navy – Acquisition and Procurement (DASN (AP)), as the functional sponsor, will manage and allocate requirements to meet capabilities, provide traceability to end products, and manage changes and releases to baselines as part of the hardware and software acquisition Configuration Management life cycle activities from Pre Milestone A to Post Initial

Operational Capability (IOC). Post IOC through Disposal, software support will be provided to the DON. The program office will manage the as-installed baseline, lifecycle sustainment of existing software design and services, changes to include escalated trouble tickets, system modification, and disposal. In addition, the DON may provide future capability requirements to support acquisition Configuration Management that the program office may utilize in the modernization process.

3.4 Data – Document Paradigm

PEO-EIS declares information and data a valuable asset and has established the detailed controls necessary to specify which information is to be managed via ePS. Metadata is selected to enable

Page:

20/142 effective identification, storage, and retrieval of data so that the creation and retention of data can be properly managed. This CMP will ensure the integrity and timeliness of data, data elements, data structures, and data views by applying the principles of Configuration Management. Data

Management and CM are two disciplines critical to the success of any project. They are strongly related and integrated in their scope, application, and elements. Both are disciplines whose ultimate purpose is ensuring the integrity of the products they support. The ePS CM program is defined for the control of ePS product data and is valid for the formal control of data assets as well. ePS shall maintain a revision history at each instance of the incorporation of approved changes and when a new baseline is struck. This baseline defines the configuration of the data asset at a point in time and ensures that data products satisfy requirements.

3.5 Family of Systems (FoS) Paradigm

ePS shall operate within a FoS. Changes to applicable systems within this FoS must be reviewed by all affected system(s). All testing must be coordinated to ensure the integrated design operates as the requirements dictate. Additional tasks and deliverables must be met to comply with the requirements from both system owners. Both system owners must attend CCB meetings to jointly render decisions on submitted changes to either system. Testing will be performed in a lab and during each installation to ensure the system operates and the performance tested accurately.

4 CONFIGURATION MANAGEMENT TOOLS

4.1 Management Tools

Table 1 identifies the anticipated tools for use in developing the ePS Program. Tools used by the vendor will be listed when the vendor is identified including updating the engineering table.

Table 1: Configuration Management Tools

Configuration

Management Tool

Description Position/IPT

Responsibility

Dynamic Object-

Oriented

Requirements

Systems (DOORS)

DOORS is a requirements management application for optimizing requirements communication, collaboration and verification of requirements throughout your organization and supply chain.

Rational DOORS allows capture, trace, analyze and manage changes to information while maintaining compliance to regulations and standards.

Requirements Lead

Page:

21/142

Configuration

Management Tool

Description Position/IPT

Responsibility

Serena Dimensions

Serena Dimensions is a process-based software change and configuration management tool. It provides functionality to enable integrated collaborative peer review, change visualization, and auditability throughout the development lifecycle.

Dimensions provide platform support for a variety of software development tools.

CM Lead

System Architect

System Architect is an enterprise architecture solution for visualizing, analyzing, and communicating enterprise architecture and business process analysis. This solution provides decision support, process optimization, and integration into solution delivery. Rational System Architect addresses all aspects of your organization's enterprise architecture, including modeling, publishing, analysis, and execution.

DODAF Architect

Extracts, Transform and Load (ETL)

ETL systems integrate data from multiple applications, typically developed and supported by different vendors or hosted on separate computer hardware. ETL extracts data from source databases, transforms the data for quality, formatting requirements and business rules; and then loads the data into a target database. Data from the source contracting databases will be extracted, transformed to meet purchased ePS platform requirements and loaded into the new ePS database for the HCA's to continue operations.

DM Lead

Enterprise Content

Management

(ECM) Solutions

Enterprise content management (ECM) is a set of defined processes that allow an agency or organization to obtain, organize, store and deliver information crucial to its operation in the most effective manner possible.

DM Lead

Page:

22/142

5 ORGANIZATIONAL ROLES & RESPONSIBILITIES

SSC-A’s CM program defines the method for providing CM of work products, components, and other selected items. CM establishes and maintains the integrity of the work products of an

Integrated Product Team (IPT) throughout the IPT lifecycle using identification, control, configuration status accounting, and configuration audits. The following sections delineate the anticipated roles and responsibilities, process participants, and process stakeholders throughout the CM program steps. It should be noted that all roles and responsibilities are subject to change based on resource availability, changes in requirements, or changes in program scope.

5.1 Configuration Management Roles

Figure 2 depicts the programmatic roles and titles for ePS staffing hierarchy, which should be noted that are subject to change based on resource availability, changes in requirements, or changes in program scope.

Figure 2: ePS Staffing Hierarchy

Page:

23/142

5.2 CM Program Participants

Participants within ePS involved in the CM program are listed below in Table 2. These participants are directly involved in executing the program steps.

Table 2: CM Program Participant Roles & Responsibilities

CM Program Participant Roles & Responsibilities

Program Manager

(PM)

Provide oversight over all CM functions, roles, and responsibilities

Establish budget requirements to accomplish CM tasking, e.g., processes, personnel, and tools

Ensure that contractual and data requirements for CM are defined within appropriate documentation

Document and resolve any contractual or data rights deficiencies in contractual documentation as required

Configuration

Management (CM)

Manager

Lead collection of CM program metrics and process improvement initiatives to ensure that program requirements are included in future

PEO EIS CM standardization and implementation updates

Ensure that CM requirements have been established and documented in a CMP according to applicable CM policy, standards, organizational processes, procedures, and templates

Collects work products, measures (if appropriate), and improvement information derived from planning and performing to review the effectiveness of CM activities

Manage CM tasking requirements for budgeting efforts

Ensure that contracts, data requirements and deliverables for CM are described within appropriate documentation

Establish and maintain baselines to ensure that all data, configurations, and technical documentation are identified, captured, and controlled

Lead the CM Group

Establish and facilitate CCB process for RFCs

Support formal configuration audits as required

Collect CM program metrics, process, and status to the IPT Lead

IPT Lead/PM

Ensure that funding and personnel resources are available to meet CM requirements and enable the effective implementation of the CM process and activities Assigns and monitors the resources and tasking; obtains objective verification of CM from QA

Takes corrective actions as necessary, and report process progress to senior leadership and other appropriate stakeholders

Responsible for implementation of this process

Provide Systems Engineering support, as applicable

IPT/CM Working

Group (WG)

Guiding body that provide CM guidance and technical oversight for the ePS CM plan, CI’s, baselines, and configuration audits

Ensure that CM requirements are followed according to applicable

CM policy, standards, organizational processes, procedures, and templates

Page:

24/142

CM Program Participant Roles & Responsibilities

Performs the CM tasks

Participate in the CCB to approve submitted RFCs

Reports progress periodically and makes recommendations for process improvement to the CM Manager;

Attends CM training

Invite applicable SMEs for technical support

Configuration

Control Board

(CCB)

Owns the Go/No Go recommendations to deploy a release candidate into production.

Develop and maintain change management processes

Approves new product and process baselines

Adjudicates and oversees all proposed changes to existing baselines

Maintain status of approved RFC

Ensure efficient, timely processing of RFCs

Document Manager

(DM)

Responsible for tracking and storage of deliverables, action items, minutes, decisions and other documentation

5.3 CM Program Stakeholders

Stakeholders within or associated with ePS involved in the CM program are listed below in

Table 3. This list is not inclusive of the stakeholders for the ePS program and should not be interpreted as such.

Table 3: CM Program Stakeholder Roles & Responsibilities

CM Program Stakeholder Roles & Responsibilities

Program Executive

Office for Enterprise

Information Systems

(PEO EIS)

Dedicated to the Planning and Execution of Program management for the DON ePS Program

Heads of

Contracting

Activities (HCAs)

Responsible for ensuring that appropriate management controls are in place to effectively integrate with ePS

DON 11 Offices for procurement of goods and services:

o BUMED o MSC o NAVAIR o NAVFAC o NAVSEA o NAVSUP o MARCORSYSCOM o ONR o SPAWAR o SSP o USMC HQ I&L

Risk Manager Controls the Risk Management Process

Develops and implements risk response

Page:

25/142

CM Program Stakeholder Roles & Responsibilities

Tracks risk status

Uses of Risk Exchange tool

Information

Assurance (IA)

Manager

Provides overall security oversight of the DON ePS program

Conducts certification and accreditation activities in accordance with the DIARMF

Quality Assurance

(QA) Manager

Reviews risk management activities

Ensures adherence to QA Process

Quality Assurance

(QA) Analysts

Responsible for testing installed COTS releases, as CM provides releases

Page:

26/142

6 SOFTWARE PRODUCT CONFIGURATION MANAGEMENT

6.1 Material Solution Analysis (MSA) CM Tasks

6.1.1 Calculate CM Personnel Requirement

Specific details for man hours are unknown at this time.

6.1.2 Material Solution Analysis (MSSA) CM Deliverables

CM Personnel Budget Submitted for Cost Documents o Cost Analysis Requirements Document (CARD), Program Life Cycle Cost Estimate

(PLCCE), Spend Plan, or Logistics Requirements Funding Summary (LRFS)

Contract Documentation Created According to Requirements o The following documentation will be developed to support the contractual requirements; Request for Proposal (RFP), Statement of Work (SOW), Contract Data

Requirements List (CDRL), Data Item Description (DID)

6.2 Technology Maturation and Risk Reduction (TMRR) CM Tasks

6.2.1 Update functional baseline

This task ensures all applicable products, approved change requests, and supporting documentation is recorded as part of the functional baseline.

6.2.2 Ensure all Required Information Captured

This task ensures all applicable products, approved change requests, and supporting documentation is recorded as part of the functional baseline.

6.2.3 Distribute Updated CMP

This task ensures that the competencies receive an updated copy of the ePS CMP upon release to be used within the required acquisition documentation.

6.2.4 Technology Maturation and Risk Reduction (TMRR) CM Deliverables

Functional Baseline Report o Generate a report to reflect the current functional baseline information in preparation to meet the combined Systems Requirements Review (SRR) and Systems Functional

Review (SFR) event entry criteria

Configuration Status Accounting Report o Generate a report that provides a current status of all configuration items and applicable metadata information

Updated Acquisition Documentation o The Acquisition Strategy, Systems Engineering Plan, and Product Support Strategy will contain CM information as transcribed from the released CMP.

Page:

27/142

6.3 Development and Deployment (D&D) CM Tasks

6.3.1 Physical Configuration Audit

This event reviews processes, services, product definition information, documented verification of compliance with requirements and inspection of products to confirm that products have achieved their required attributes and conform to release product configuration definition information.

6.3.2 Update Product Baseline

This task ensures all applicable products, approved change requests and supporting documentation is recorded as part of the product baseline.

Verify CMP Implementation

This task encompasses an audit that will be conducted to verify documented processes have been implemented according to the CMP.

Development and Deployment (D&D) CM Deliverables

Physical Configuration Audit Report o Generate a report of the findings based on the audit conducted

Product Baseline Report o Generate a report to reflect the current product baseline information in preparation to meet the Critical Design Review (CDR) event entry criteria

Process Audit Report o Generate a report of the findings based on the audit conducted

6.3.3 Verify CMP Implementation

This task encompasses an audit that will be conducted to verify documented processes have been implemented according to the CMP.

6.3.4 Development and Deployment (D&D) CM Deliverables

Physical Configuration Audit Report o Generate a report of the findings based on the audit conducted

Product Baseline Report o Generate a report to reflect the current product baseline information in preparation to meet the Critical Design Review (CDR) event entry criteria

Process Audit Report o Generate a report of the findings based on the audit conducted

6.4 Operation and Support (O&S) CM Tasks

6.4.1 Create As-Installed Baseline

This task ensures all applicable product baseline physical items, approved change requests, and supporting documentation is recorded to support the creation of an as-installed baseline.

Page:

28/142

6.4.2 Capture Configuration Item Disposal Status

For each configuration item in the baseline, disposal information will be monitored and captured as part of the baseline.

6.4.3 Update CMP

This task ensures that the competencies receive an updated copy of the ePS CMP upon release to be used within the required acquisition documentation.

6.4.4 Operational and Support (O&S) CM Deliverables

As-Installed Baseline Report o Generate a report to reflect the current product baseline information in preparation to meet the In Service Review (ISR) event entry criteria

Updated Baseline Report o Generate a report to reflect the disposal status of the affected configuration item for the applicable baseline

Released CMP o The updated CMP will be released to reflect approved changes based on continuous process improvement inputs

Page:

29/142

7 PLATFORM CONFIGURATION MANAGEMENT

The platform CM tasks and deliverables indicated below are applicable to all of ePS.

7.1. Baseline Management CM Tasks

7.1.1 Management of Planning & Requirements Documents

This task encompasses pertinent documentation that pertains to HCA-specific platform requirements. This documentation may be used in the planning of the FoS to be installed on the

HCA platform.

7.1.2 Create To-Be Baseline

This task ensures all applicable platform baseline systems, approved RFCs, and supporting documentation is recorded to support the as-planned baseline.

7.1.3 Baseline Management CM Deliverables

Baseline Planning & Requirements Documents o Planning and Requirement documents are included as part of the “to-be” baseline

Advanced Coordinated Fielding Plan o Updated high-level schedule outlining the systems identified for installation, the platforms they will be installed on, and the proposed availability date

To-Be Baseline Report o Generate a report to…