M6785423R4907_Attch 3_CMP_1SEP2022.pdf

PROGRAM EXECUTIVE OFFICE DIGITAL & ENTERPRISE SERVICES

(PEO DIGITAL) UNITED STATES MARINE CORPS (USMC)

CONFIGURATION MANAGEMENT PLAN (CMP)

Version 1.0 01 September 2022

DISTRIBUTION STATEMENT A: Approved for public release. Distribution is unlimited.

DESTRUCTION NOTICE: This document will be destroyed by any method that will prevent disclosure of contents or reconstruction of the document.

PEO Digital USMC CMP 1 September 2022 ii

PROGRAM EXECUTIVE OFFICE DIGITAL & ENTERPRISE SERVICES (PEO

DIGITAL) UNITED STATES MARINE CORPS (USMC)

CONFIGURATION MANAGEMENT PLAN (CMP)

Submitted by:

THOMAS CARROLL

Deputy, Assistant Program Executive Office-Engineer & USMC Lead Engineer Program Executive Office Digital and Enterprise Services

Approved by:

ANDREW RODGERS

Marine Corps Enterprise Network, Director Program Executive Office Digital and Enterprise Services iii

Executive Summary

This Configuration Management Plan (CMP) was developed as mandated in Department of Defense Instruction 5000 (Series), for Program Executive Office Digital & Enterprise Services (PEO Digital) to implement consistent Configuration Management (CM) and change control practices for all United States Marine Corps (USMC) services of record managed within the PEO Digital Marine Corps Enterprise Network (MCEN) Director’s authority.

CM USMC service offerings will be implemented within PEO Digital as an enterprise “way-to-do-business” to effectively manage and maintain USMC system baselines and configured items.

The elements of CM captured in this CMP are as follows:

• Configuration Planning and Management

• Configuration Identification

• Configuration Verification and Audits

• Configuration Control

• Configuration Status Accounting

• Configuration Data Management

Processes and procedures described in this document are to be implemented to ensure delivered configuration items meet the intended configured design. A Configuration Item (CI) may consist of hardware, software, interfaces, firmware, drawings, and documentation and shall be under rigorous configuration control from cradle to grave. These CIs are to be defined, documented, tracked, and accounted for with a complete audit trail of decisions and design modifications throughout their lifecycle.

The implemented change control process will provide stakeholders with current and accurate infrastructure inventory data. This data will be used for service planning purposes, solution development, procurement efforts, system updates, refresh efforts, and cost analysis. All functional areas, including service management, engineering, logistics, finance, contracts, cyber security, and CM will actively participate as Subject Matter Experts through all acquisition processes.

All PEO Digital USMC services are to adopt the processes and procedures as designated in this PEO Digital USMC CMP. Exceptions to the PEO Digital USMC CMP will be granted through obtaining a portfolio/service specific addendum to this CMP signed by the MCEN Director as the approving authority of PEO Digital USMC CMP. Service CMP addendums shall be attached as an annex to the PEO Digital USMC CMP.

iv

REVISION HISTORY

Revision Version Summary of Changes Date Approved Initials

1.0 Replacing “N&I” with “PEO Digital”

throughout this CMP (Add Agile and Processes) v

TABLE OF CONTENTS

1.0 INTRODUCTION

Purpose

Scope

Objectives

Applicability

2.0 REFERENCE DOCUMENTS

Government Documents

Marine Corps Systems Command Documents

Non-Governmental Documents

3.0 ORGANIZATION AND RESPONSIBILITIES

Purpose

Configuration Management Organization, Roles, and Responsibilities

4.0 CONFIGURATION PLANNING AND MANAGEMENT

Configuration Management Plans

Types of Configuration Management Plans

5.0 CONFIGURATION ITEM IDENTIFICATION

Engineering Change Proposal Naming Convention

Document Identification

Document Naming Convention

Baseline Identification

5.4.1 System Versioning Number

5.4.2 Hardware (HW) Versioning

5.4.3 Software (SW) Versioning

5.4.3.1 SW Version Description (SVD)

Configuration Baselines

5.5.1 Functional Baseline

5.5.2 Allocated Baseline

5.5.3 Product Baseline

5.5.4 Operational Baseline

vi

6.0 CONFIGURATION VERIFICATION AND AUDITS

Types of Audits

6.1.1 Functional Configuration Audits

6.1.2 Physical Configuration Audits

6.1.3 Configuration Status Accounting (CSA)

6.1.4 Asset Audits

6.1.5 Acquisition Processes

Metrics

7.0 CONFIGURATION CONTROL

Change Control Methods

Engineering Change Proposals

7.2.1 Engineering Change Proposal Change Priorities

Engineering Change Proposal Types

7.3.1 Class I Changes

7.3.2 Class II Changes

Configuration Control Authority

Change Management

7.5.1 Review Boards

7.5.1.1 Engineering Review Board

7.5.1.2 Configuration Control Board

7.5.1.2.1 Configuration Control Board Levels

7.5.1.2.2 Configuration Control Board Activities

7.5.1.2.3 Configuration Control Board Membership

Hardware/Software/Firmware/Interface Configuration Management

Emergency Change Approval

Other Product Changes

7.8.1 Asset Management

7.8.2 Changes to Commercial Off-the-Shelf Items/Government Off-the-Shelf Items 35

7.8.3 Changes to Non-Developmental Items

8.0 DATA MANAGEMENT

Technical Data Management

Data Identification vii

Data Management Tools

8.3.1 Definitive Media Library

8.3.2 BMC Remedy

8.3.3 SharePoint

8.3.3.1 PEO Digital Configuration Management Library - TBD

APPENDIX A - Abbreviations, Definitions/Descriptions and Acronyms ................................. A-1

APPENDIX B - PEO Digital USMC SCCB Charter Template ................................................. B-1

APPENDIX C - PEO Digital USMC PfM CCB Charter Template ........................................... C-1

APPENDIX D - PEO Digital USMC ERB Charter Template .................................................... D-1

APPENDIX E - PEO Digital USMC System Version Number/Baseline Version Memorandum Template ................................................................................................................. E-1

APPENDIX F - PEO Digital USMC System Version Description Template ............................ F-1

APPENDIX G - SOP for Creating CRQ & ECP Template in Remedy ...................................... G-1

APPENDIX H - PREPARATION FOR AUDITS...................................................................... H-1

APPENDIX I - SYSTEM ENGINEERING AGILE IMPLEMENTATION GUIDE ................ I-1

APPENDIX J - CLOUD BASED SUBSCRIPTION SERVICES ............................................. J-1

LIST OF TABLES

Table 1: Configuration Management Roles and Responsibilities

Table 2: Document Naming Convention

Table 3: System Versioning Numbering

Table 4: Hardware Versioning Guidance

Table 5: Software Versioning Guidance

Table 6: Change Management Board Hierarchy

Table 7: Service Configuration Control Board Roles and Responsibilities

Table 8: Portfolio Configuration Control Board Roles and Responsibilities

LIST OF FIGURES

Figure 1: Charter Signatures

Figure 2: PEO Digital USMC Change Control Process Workflow

Figure 3: Parallel Process IAVA/Class II Digit Quick Turnaround

1.0 INTRODUCTION

This Program Executive Office Digital and Enterprise Services (PEO Digital) United States Marine Corps (USMC) Configuration Management Plan (CMP) was developed for PEO Digital.

The PEO Digital USMC CMP is to document and implement consistent configuration-controlled processes for all USMC services and supersedes the Portfolio Manager Supporting Establishment System Configuration Management Strategy. At PEO Digital, programs and projects are referred to as services. The USMC Portfolios are Platform Application Services, Digital Workplace Services, Infrastructure Services, Cyber & Operational Services, End User Services, Strategic Sourcing Services, and Public Safety Systems. Through this CMP, the PEO provides standard processes with consistent methods to manage configuration data items for all USMC systems supported by the PEO Digital Portfolio Managers (PfMs) to deliver high quality information technology (IT) solutions in a timely, efficient, and effective manner.

PEO Digital USMC services are to follow CM standard procedures to define, manage, document, implement, account for, and audit changes to requirements, CIs, and baselined technical data.

Effective planning, execution, and maintenance using defined processes will assist in informed decision-making. The E-ITSM structure may be utilized for Service Transition framework objectives, adhering to approved policy / process guides as required. This plan describes the methods by which PEO Digital Marine Corps Enterprise Network (MCEN) Director will structure CM in the development and acquisition of solutions and related hardware/software/service contract, and serves as the operational CM document for PEO Digital portfolio led services.

Purpose

This document defines the practices and procedures required to accomplish CM for each USMC service managed within the PEO Digital organization structure. It provides guidance and direction for identifying, controlling, and managing CIs throughout the life cycle process from development to disposal.

Scope

This CMP applies to all PEO Digital USMC services to include the development, production, sustainment, and disposal of CIs. Key CM principles are applied to ensure components and systems are uniquely identified, managed, and documented in their resident Network Environment, e.g., MCEN, Public Safety Network (PSNet), etc. The intended audience for this document is PEO Digital USMC service leads, supporting competencies, contractors and Navy supporting team and its contractors. The audience is to inform, communicate, collaborate, and coordinate with external commands or agencies such as Combat Development and Integration (CD&I); Marine Forces Cyberspace Command (MARFORCYBER); Marine Corps Cyberspace Operations Group (MCCOG); Information, Command, Control, Communications, and Computers (IC4); Marine Corps Installations Command (MCICOM); and Network Battalions, as applicable. This document provides the same level of coordination with supporting agencies development contractors, suppliers, and/or integrators (hereafter referred to as System Integrator (SI)), and/or other organizations supporting data center environments containing IT infrastructure equipment procured by Marine Corps Systems Command (MCSC). The designated processes and practices will apply to PEO Digital USMC review boards, Working Groups (WGs), Technical Interchange Meetings, and other Government forums who have oversight responsibilities for services in specific PEO Digital USMC Portfolios.

Utilizing Agile within PEO Digital is still relatively new and acquisition processes have not been fully integrated into Agile. CM when utilizing an Agile process is still required, however, at this time, the exact process has not yet been developed within the organization. As guidance is developed, it will be incorporated into this CMP, see (Appendix I).

In the case of an SI managing Government system baselines in their organization owned environment, the SI is to provide an SI CMP. All SI CMPs are to align their CM processes to address and coordinate with the identified processes, products, functions, and objectives described in this plan.

The PEO Digital USMC CMP is the responsibility of the Assistant Deputy - Assistant Program Executive Office - Engineering (AD-APEO-E) or designated PEO Digital USMC Configuration Manager (CfM) and is a living document to be updated at a minimum of every two years, or as needed to support changing service requirements and to capture evolving process maturity requirements.

The Office of Primary Responsibility (OPR) for CM of PEO Digital USMC services is the APEO – E. The PEO Digital USMC CMP will be signed by the MCEN Director. All deviations from the scope of this plan shall be documented, approved, and signed by the MCEN Director.

All deviations will be attached as an addendum to the PEO Digital USMC CMP.

Objectives

The PEO Digital USMC CM objective is to implement an effective CM process to include the following:

• Ensuring effective, organized, predictable, traceable, repeatable, and accountable processes are implemented.

• Identifying, establishing, verifying, and managing CIs and functional, allocated, and product baseline configurations.

• Engineering Change Proposals (ECP) form (or equivalent) is prerequisite document / artifact required for approving changes to service / system baselines.

• Tracking all changes to hardware, software, interfaces, documentation, drawings, and services.

• Maintaining and providing a complete audit trail of all proposed, approved, unapproved, and rejected engineering changes.

• Managing configured data in a centralized Government designated tool, e.g., Topic, SharePoint, BMC Remedy, Configuration Management Database (CMDB), Definitive Media Library (DML), etc.

• Performing audits to ensure CI changes are consistently managed in accordance with (IAW) documented processes, policies, and procedures.

• Applying configuration control to approved baseline documents, including, but not limited to requirements, specifications, designs, drawings, and diagrams.

• Implementing, facilitating, and supporting the Engineering Review Board (ERB) and Configuration Control Board (CCB) processes and decisions.

• Defining, implementing, evaluating, and documenting processes and process improvements.

Applicability

This document is applicable to all USMC hardware, software, solutions, and joint CIs that are assigned to PEO Digital.

2.0 REFERENCE DOCUMENTS

The references provided below contain CM standards, guidelines, instructions, and processes used to compile this CMP. The latest version of these referenced documents should be consulted.

Government Documents

CNSSI 1253

DI-IPSC-81442

DoD 5000

Committee on National Security Systems Instruction Data Item Description Software Version Description Defense Acquisition System Directive (Series)

DoD 5010.12 Acquisition and Management of Technical Data DoDI 5230.24 Distribution Statements on Technical Documents MIL-HDBK-61 Military Handbook Configuration Management Guidance

MIL-STD-499

Engineering Management

Marine Corps Systems Command Documents

MCSCO 4130.1 MCSC Configuration Management Policy SED-HDBK-003A MCSC CM Implementation Handbook

Non-Governmental Documents

EIA/IEEE 12207.0 Standard for Information Technology – Software Development and Life Cycle Processes

EIA Standard 836 Configuration Management – Data Exchange and Interoperability

ANSI/EIA Standard 649 National Consensus Standard for Configuration Management IEEE Std 15288.2-2014 IEEE Standard for Technical Reviews and Audits on Defense

Programs ISO 10007 Quality Management Systems – Commercial CM Guidelines

3.0 ORGANIZATION AND RESPONSIBILITIES

The PEO Digital MCEN Director has the overarching responsibility for CM and has delegated the USMC process development to be created by Command Operations Office (COO). These processes are to be consistent and implemented for all PEO Digital USMC services. CM is the responsibility of the PfM for all services within their portfolio. This CMP supports all PEO Digital USMC services. Organizational roles and responsibilities are identified in Table 1.

Purpose

To achieve a successful CM organization, it is the responsibility of PEO Digital leadership to identify and enforce the following:

• CM organization

• CM roles and responsibilities

• CM Management representatives

• Conflict resolution

• Training, as required

Configuration Management Organization, Roles, and Responsibilities

Table 1 identifies the CM organizations involved in the CM efforts with defined CM roles and responsibilities.

Table 1: Configuration Management Roles and Responsibilities

Member/Membership Roles / Responsibilities Alternative Role to Perform Responsibilities

MCEN Director

Responsible for CM processes and practices to be established and executed for all PEO Digital Command Strategy and Business Office (CSBO)/Command Operations Office (COO) and Portfolios.

PfM

Performs all duties of the PfM MCSES as a backup when needed.

Deputy, Assistant Program Executive Office - Engineer

Provides oversight of the establishment of CM practices in the program office per the MCSCO 4130.1A, Configuration Management Policy. AD-APEO-E Provides oversights of the CM practices defined within the PEO Digital USMC CMP.

Assistant Deputy, Assistant Program Executive Office - Engineer

Reports, monitors, and provides oversight for CM and Change Management (ChM) processes as stated in the PEO Digital USMC CMP.

CfM

Oversees planning and development of the PEO Digital USMC CMP and engineering efforts.

Collaborates service CM efforts and deviations with Portfolio Manager (PfM) PEO Digital USMC CfM Manager.

Ensures Service CMP Addendums are in alignment with this CMP guidance.

Validate digit designations for Class I ECPs.

Member/Membership Roles / Responsibilities Alternative Role to Perform Responsibilities

Portfolio Manager

Ensures CM and ChM processes are utilized as stated in the PEO Digital USMC CMP. SLSE or designated CfM

Responsible for development of service configured baselines. SLSE

Implements CM processes for PEO Digital to enforce rigorous control and management of changes made throughout the systems life cycle to include:

• Configuration Management and Planning

• Configuration Identification

• Configuration Control

• CSA

• Configuration Verification and Validation

• Configuration Audits PfM PEO Digital USMC CfM

CfM

Approves the service’s baseline configuration.

SLSE or CfM Reviews ECP and change control processes through service life cycle.

Ensures configuration management and ChM processes are being followed as documented in the PEO Digital

USMC CMP.

Not applicable

Ensures service CIs follow change control process as identified in the CMP. SLSE or CfM

Deputy Portfolio Manager

Alternate to the PfM for all activities within the Portfolio. PfM

Lead Assistant Portfolio Manager – Engineer (L APM-E)

Executes ChM and control IAW the PEO Digital USMC CMP. CfM Oversees all service within the portfolio.

Project Officer Manage and support business capability needs for a service (project or program) for its lifecycle Service Owner

Design future business solutions Manages engineering changes to the service

Service Owner

Oversees the planning, development, and execution of all services.

SLSE Has signature authority for SCCB.

Service Lead Logistician

Oversees the planning, development, and execution of their service logistic efforts. Matrix Logistics Support

Service Lead Systems Engineer (SLSE)

Oversees the planning, development, and execution of their service engineering and CM efforts.

Selected SE or CFM

Executes CM related guidance.

Manages the service’s baseline configuration.

Ensures Service CM is being conducted and IAW the PEO Digital USMC CMP.

Member/Membership Roles / Responsibilities Alternative Role to

Documents all processes that deviate from the PEO Digital USMC CMP guidance.

Performs daily CM activities to include:

• Controls and maintains all CM products and procedures specific to service

• Manages CI changes

• Updates Baseline

• Manage Documentation

• Configures systems

• Tracks action items

Roles Responsibilities Alternative Role to

PEO Digital USMC Configuration Manager (CfM)

Defines and develops processes to ensure data is captured and the configuration of the system is maintained in Government owned asset management tools

AD-APEO-E

Collaborates with service level assigned CM support members to resolve CM issues within each Portfolio Identifies gaps in CM activities and processes Provides CM expertise to PEO Digital, and leadership and guidance to the Portfolios and the CM support members Ensures technical data is captured, tracked, and maintained Ensures service documentation is available and posted to specific sites Reports CM activities to leadership Participates in the command-wide CM community of practice Coordinates and participates in meetings to assist in developing and documenting processes to improve CM execution IAW PEO Digital Policies and Guidance Oversees and conducts audits of systems configuration to set and/or verify baseline validity Provides training for developed processes Identifies CM support for team/services assignment

Portfolio Configuration Management Support Member

Manages Portfolio services configured baselines and configuration items

Not applicable

Participates in service meetings pertaining to modifications or changes to the baseline Manages the configured data in the associated tools Provides CSA Reporting Reports Portfolio CM activities to PEO Digital USMC CfM.

Supports PEO Digital CM Working Group and activities.

PEO Digital Lead

ISSM

Ensures organizational CM practices meet NIST, CNSSI, DoD, USMC, and PEO Digital policies.

PEO Digital/Deputy Cybersecurity Director

Evaluates CM against Risk Management Framework (RMF) requirements and authorizations.

Service ISSM Evaluates service CM practices against RMF requirements and authorizations. PEO Digital Lead ISSM

4.0 CONFIGURATION PLANNING AND MANAGEMENT

The PEO Digital USMC CMP provides CM guidelines and processes to ensure all baselines are established and maintained. This plan identifies the processes, responsibilities, and activities that all personnel, WGs and/or Agile Teams must follow to maintain a valid technical baseline. All data documenting configured baselines must be under rigorous CM to safeguard designated and approved valid baselines and the integrity of their associated documentation and artifacts. The review boards and with decision-making authority will require a signed charter to designate the empowered authority of its members.

Figure 1 depicts the required approval signatures for the various charters.

SCCB PfM

CCBERB

Service Lead Systems Engineer

(SLSE)

Service Owner Portfolio Manager

Figure 1: Charter Signatures

Configuration Management Plans

This CMP describes how CM will be accomplished and how consistency between the service definition, the service configuration, and the configuration management records are achieved and maintained throughout the applicable phases of the product’s life cycle. Both the Government and the contractor should use CMPs to document and execute their respective CM service requirements.

Types of Configuration Management Plans

There are four possible types of CMPs or Addendum:

• PEO Digital USMC CMP

• PEO Digital USMC Service CMP Addendum

• SI CMPs

• PEO Digital CMP (Naval) - TBD

The PEO Digital USMC CMP is generated by the Government as an overarching plan for all services supported at PEO Digital USMC. This plan is intended to manage the life cycle of all USMC CIs under PEO Digital control.

The PEO Digital USMC Service CMP addendums represent deviations and additional requirements, or processes not addressed in the PEO Digital USMC CMP. All addendums must be signed by the PfM. All approved addendums will be included in the PEO Digital USMC

CMP.

The SI CMP is prepared by the SI and describes the CM policies, procedures, and processes that are followed within their organization during development and through delivery of a product to the Government. The SI must ensure that their CMP activities support the policies, processes, and procedures outlined within the PEO Digital USMC CMP. The Government must coordinate, review, and concur the SI’s CMP to ensure they are consistent with the CM requirements provided in the contractual requirements document, e.g., Statement of Work (SOW), Statement of Operations (SOO), and Performance Work Statement (PWS).

An overarching PEO Digital CMP, for the Naval organization, is to be developed.

5.0 CONFIGURATION ITEM IDENTIFICATION

Under the ITSM construct, CIs refer to all components that need to be managed in order to deliver an IT Service (i.e., in ITSM each laptop is considered a CI). However, acquisition CIs are used to accurately identify attributes that define all aspects (i.e., Form, Fit, Function and Interface) of each component that makes up a System (i.e., each model of a laptop is a CI vice every laptop). There is a distinction between an Asset and a CI. One or more assets may make up a single CI (for instance, a system with a hundred laptops (aka assets) would have a single CI:

the laptop model). In addition, not all assets are CI’s (for instance, Ethernet cables may be assets but are not tracked as a CI). The CI is a change-controlled product (e.g., hardware, software, interfaces, firmware, or documentation) that satisfy an end user function and requires separate CM with the purpose of creating, tracking, and maintaining the defined data for an approved baseline. All assets (or group of assets) should be evaluated to determine if they qualify as a CI (see MIL-HDBK-61 that contains CI criteria questions to help make that determination). CIs may be an individual item, or may be a significant part of a system or higher-level CI. It is necessary to define the functional and physical characteristics of a CI in sufficient detail so that it may be developed, tested, evaluated, produced, procured, inspected, accepted, operated, maintained, and supported under the rigor of CM control.

Each CI shall be designated at an appropriate level for documenting performance attributes and managing changes to those attributes. CIs are verified to ensure they conform to and perform as defined in the configuration documentation.

CI identification is to be conducted IAW MIL-HDBK-61, CM Guidance. CIs are to be uniquely identified for tracking purposes and the associated data may include some or all the following:

• Part numbers

• Serial numbers

• Commercial and Government Entity codes

• Item Unique Identification numbers

• HW/SW versions

• Nomenclatures

• Model numbers

• Manufacture names

Engineering Change Proposal Naming Convention

All ECPs (reference 7.2) will be entered into BMC Remedy and will be assigned a standardized unique identifier (a Change Request [CRQ] number) automatically by BMC Remedy. The automatically generated CRQ number will be the official ECP number (i.e., CRQ0000002765355).

Document Identification

Documentation reflecting performance, functional, or physical requirements or other product related information must be assigned a unique identifier. Other documents in service repositories are recommended to follow the same naming schema as provided below.

The document’s major and minor version number only changes when the documents are updated and approved. A major version update is i.e., v1.0 to v2.0, or v4.15 to v5.0, and a minor version update is i.e., v1.15 to v1.16, or v1.24 to v1.25. Major versions are to be approved by the PfM, whereas a minor version is to be approved by the Service Owner.

Document Naming Convention

There are four service levels of originating documentation activities within PEO Digital for

USMC:

• PEO Digital USMC Command Strategy and Business Office (CSBO)

• PEO Digital USMC COO

• PEO Digital USMC Portfolio

• PEO Digital USMC Services

Table 2 provides guidelines for document naming convention.

Table 2: Document Naming Convention 1st Field:

Service Level: i.e., CSBO, COO, PfM, Service (assigned at lowest IPT level)

2nd Field:

Document Title

3rd Field:

Document Version (may not be required depending on document type)

4th Field:

Status

5th Field:

Date

CSBO

COO

PfM

Service

Use common abbreviations;

CMP, ICD, SRS,

SSS, SSDD, SVD,

etc. or short title

The version once signed.

The first time the document is signed is Version 1.0.

Some documents may not require a version number, in which case this field can be omitted.

Major changes to the document are a first digit change (i.e., 2.0).

Minor changes to the document are a second digit change (i.e., Version 2.1).

DRAFT,

FINAL,

CURRENT

YYYYMMDD

Examples:

• CSBO_SVN_v2.0_Draft_20220325

• COO_WBS_v3.0_Final_20220602

• Digital_Workplace_Services_SEP_v7.0_Draft_20220501

• Enterprise_Integration_Modernization_ESS_v3.0_20220410

Metadata tagging will be used to identify specifics of a product, such as event types (e.g., Test Readiness Review [TRR], System Verification Review [SVR], ERB, CCB, etc.), versions, status, dates, competency, and ownership of documents (e.g., logistics, engineering, service management, cybersecurity, etc.) and therefore will not be included in the service file name. For DEVDOCs follow the DEVDOC Naming Standards guidance.

Baseline Identification

The baseline identifies a specification or product that has been formally reviewed and agreed upon/approved and may only be changed through the prescribed formal change control process.

Baselines are the fundamental basis of CM and provide traceability from the high-level capabilities developed in the early engineering analysis phase to the detailed design accomplished in the Engineering and Manufacturing Development (EMD) phase.

Baseline maturation is assessed at technical reviews. The baseline is set after all changes from the review have been identified, verified, validated, and adjudicated/closed.

5.4.1 System Versioning Number

PEO Digital has implemented a four-digit structure for the System Version Number (SVN) for the PEO Digital organizational structure as documented in this plan. The SVN is applied to the systems and services – the fundamental structural unit of any service, system, hardware, software, and is used to identify the Services Configuration Baseline. The SVN is made up of the Hardware Version and/or Software Version numbers at a minimum. Any change, based on a Class I ECP, to a system, hardware, or software will require an update to the SVN. All CI updates are accomplished using and engineering change as described in the CMP and change control processes. This provides the traceability of a configuration that has been changed in accordance with approved processes. Any change, based on a Class I ECP, to a system, hardware, or software will require an update to the SVN. If a release is to contain changes with different assigned digits, the release number will be assigned as the highest digit level included in the release. The SVN is tracked in a System Version Number/Baseline Memorandum (see Appendix E). See section 7.3.1 and 7.3.2 for detailed definitions of Class I and Class II criteria.

Table 3 identifies the four-digit SVN structure. Note that the definitions/criteria for the System Versioning schema are not finite and may drive discussion in order to appropriately assign a digit change, especially when referring to Agile services.

Table 3: System Versioning Numbering

Digit 1st 2nd 3rd 4th

Definition

One-digit baseline identifier assigned to the system that includes HW and SW that represents a system, reflects an approved performance / product baseline (PBL), advances in number as additional service / system level baselines emerge, and is accompanied by a system or system / subsystem specification.

New, updated, or possibly clarifications to Capabilities Documents will typically result in a 1st digit change. Adding new User Requirements to the functional baseline would result in a 1st digit change.

One-digit sequential number assigned to each release that increases functionality / capability and is within the approved baseline functionality / capability as described in the applicable specifications.

Major HW or SW feature is changed or added to the core system.

New system capability (small c) where the Capability Document already covers User Requirement, but the capability has not yet been developed / executed in the existing system.

One-digit identifier that indicates addition of minor updates or patches (not related to Information Assurance & Vulnerability Assessment [IAVA] compliance).

SW changes to improve stability and usability.

Changes a core* application or more than one non-core application.

Technical Refresh of HW (typically a single component type, e.g., laptop, server, router, etc.).

*Core Application:

An Application that is critical to the function of the device (such as the Operating System or an application that must be present for the user to accomplish their mission).

One-digit identifier that indicates incorporation of site or application specific files or data.

SW changes due to IAVA compliance.

Device driver (new / updates).

SW configuration updates.

SW corrections found during 1st/2nd digit testing to meet design requirements.

Firmware updates.

Administrative Changes

5.4.2 Hardware (HW) Versioning

HW will be tracked using a four-digit versioning schema. All versions are to be captured on the System Version Number/Baseline Memorandum, (see Appendix E). In addition, all HW changes are to be documented by an ECP, located in the BMC Remedy Change Management (ChM) Console using the ECP template. Also, all HW can be tracked by ensuring that all fields in the MCSC Tab are completed within the Asset Management Console. The MCSC fields in BMC Remedy currently consist of 1) MCSC Team Name, (to be renamed due to PEO Digital reorganization), 2) MCSC System Name, 3) MCSC Subsystem Name, 4) MCSC System Version and 5) MCSC Subsystem Version. The Service Owner (SO) will determine which HW modifications to implement, depending on priority, impact, schedule, and cost via the change control process. Each HW release will be identified using the versioning definition below. For all HW changes, the Portfolio L APM-E must concur that proposed HW changes fall within the category of Class I and Class II changes during appropriate events. See section 7.3.1 and 7.3.2 for detailed definitions of Class I and Class II criteria.

Table 4 identifies the four-digit Hardware Versioning schema.

Table 4: Hardware Versioning Guidance

Definition Initial hardware release, defining a user requirement.

User requirement change.

One-digit baseline identifier assigned to the hardware that reflects an approved performance or

PBL.

New hardware capability.

Significant number of CIs replaced (cumulative CI changes that would individually be 3rd digit).

One-digit sequential number assigned to each hardware release that increase functionality / capability and within the approved baseline functionality or capability as described in the applicable specifications.

HW update or tech refresh, such as End User Device (EUD), server, router, switch, etc.

Updates without capability additions proposed to resolve known fixes or issues.

Improvements to stability and usability.

One-digit identifier that indicates addition of a minor update.

Significant number of firmware updates that individually would be 4th digit.

Firmware updates.

Administrative Changes

Discriminating Criteria

May include adaptive actions to perform other than original Concept of Operations

(CONOPS) /

functionality.

May include adaptive actions to improve original

CONOPS

/functionality (i.e., threshold requirement not previously met).

May be in response to Trouble Reports.

N/A

5.4.3 Software (SW) Versioning

SW and Firmware (FW) will be tracked using a four-digit versioning schema. All versions are to be captured on the System Version Number/Baseline Memorandum, (see Appendix E). In addition, all SW/FW changes are to be documented by an ECP, located in the BMC Remedy ChM Console using the ECP template. All SW/FW changes will be reviewed and approved for fielding by the PEO Digital PfM. The Government will determine which SW/FW modifications to implement depending on priority, impact, schedule, and cost. Each SW/FW release will be identified using the versioning definition below. For all SW/FW changes, the Portfolio L APM-E must concur that proposed SW/FW changes fall within the category of Class I changes during appropriate events. See section 7.3.1 and 7.3.2 for detailed definitions of Class I criteria.

Table 5 identifies the four-digit Software Versioning schema.

Table 5: Software Versioning Guidance

Digit 1st 2nd 3rd 4th

Definition Significant changes to SW and/or Department of Defense Architecture Framework integrated architectures, e.g., interfaces, interoperability, integration, functionality, new requirements capabilities, etc.

Capability is changed or added to the core system.

Add enhancements to existing features.

Changes a core application or more than one non-core application.

Changes to improve stability and usability.

IAVA compliance.

Changes due to IAVA compliance.

Device driver (new / updates).

Configuration updates.

SW corrections found during 1st /2nd digit testing to meet specification(s).

Patch – release only.

Able to install fixes on an installed software base at affected sites.

Must be nondestructive.

Permits replacement of one or more individual files, including Operating System.

Administrative Changes

Discriminating Criteria

May include adaptive actions that add new interfaces or significantly change interoperability in support of new

CONOPS /

functionality.

May include adaptive actions that modify original

CONOPS /

functionality.

May include Operating System changes.

May introduce new Commercial Off-the-Shelf (COTS)/Governmen t Off-the-Shelf

(GOTS).

May be in response to Trouble Reports.

May include Operating System updates.

May include cyclical

COTS/GOTS

upgrades.

May include SW changes to meet specifications following testing.

5.4.3.1 SW Version Description (SVD)

PEO Digital USMC services consist of a variation of assembled Commercial Off-the-Shelf (COTS)/Government-Off-the-Shelf (GOTS) items, but modifications to fit the users need may exist. For services containing SW, an SVD is required for each SW version release. The SVD will describe details of the release, including new features, fixed and known problems. This will include, but not limited to, SW, firmware, documentation, and their associated version number.

If using a supplier provided SVD, it will be identified in a contract requirements vehicle, e.g., SOW, SOO, PWS, or Contract Data Requirements List. The SVD contains the Identification of the System by providing an overview, applicable documents, SW contents, all changes installed, installation instructions, and any possible problems or known errors. For an SVD example (see Appendix F).

Configuration Baselines

The configuration baseline is a fixed reference point that defines and documents the configuration of a system at a specified time. CM uses the Functional Baseline (FBL), Allocated Baseline (ABL), PBL, and Operational Baseline (OBL) to manage the CIs that will be supported and maintained throughout the systems life cycle. CM uses the artifacts produced to support technical reviews that document the FBLs, ABLs, PBLs, OBLs to manage the configuration of the systems. In accordance with CNSSI 1253 the PEO Digital services must store, at a minimum, the last two baselines that defines the configuration of their systems. The FBL, ABL, PBL, and OBL will be tracked within the System Version Number/Baseline Memorandum that will be signed by the appropriate authority making the change. The memo is to contain all applicable information documenting the state and content of the baseline. The PEO will sign all memos for 1st digit changes unless delegated to the MCEN Director. The PfM is to sign the memo for all 2nd digit changes. All updates for 3rd and 4th digit changes and Class II ECPs may be signed by the SO or PfM and appended to the original baseline memo signed by the PfM as a change page.

Upon the next PfM signature, those changes will be officially rolled into the memo. For template of the memo and directions on how to complete (see Appendix E).

All changes to an approved baseline must be submitted as an ECP and follow the change control process as described in this PEO Digital USMC CMP.

5.5.1 Functional Baseline

The FBL describes the system's intended performance (i.e., functional, interoperability, and interface characteristics) and the verification that demonstrates the achievement of those specified requirements. The FBL is established and put under configuration control at the System Requirements Review for services using Waterfall or Agile acquisition stage. It is usually verified with a SVR and/or a Functional Configuration Audit (FCA) for the same service. For services undergoing Agile methodologies, the FBL is documented using the information within the Agile service (e.g., User Stories, Backlog, Kanban, etc.) and is verified in increments prior to each release during Agile reviews. Service teams should coordinate with PEO Digital USMC leadership to determine the best way to document the FBL. All data documenting CI changes to the FBL are to be under CM control and verified that they are managed IAW this CMP’s change control process. The data is to be maintained as applied in the CMBD, DML, and/or PEO Digital USMC CM Library.

5.5.2 Allocated Baseline

The ABL designates the CIs that will form a system and then allocates the system functional and performance requirements across the CIs. It includes all functional and interface characteristics that are allocated from those of a higher-level CI or from the system itself, derived requirements, interface requirements with other CIs, design restraints, and the verification required to demonstrate the achievement of specified functional and interface characteristics. All data documenting CI changes to the ABL are to be under CM control and verified they are managed IAW this CMP’s change control process.

For a Waterfall or Agile service, the ABL is typically established at the Preliminary Design Review; however, it can be established at Critical Design Review / Non-Developmental Item Integration Review (NIR). For Agile services, the ABL should be established prior to the first release and updated during each subsequent release during the design reviews within each release. The configuration control of CIs that make up the ABL are validated through audits and are maintained in the CMBD, DML, and/or PEO Digital USMC CM Library.

5.5.3 Product Baseline

The PBL describes the detailed design for production, fielding/deployment, and operations and support. The PBL prescribes all necessary physical characteristics (i.e., form, fit, and function) and selected functional characteristics designated for production acceptance testing and production test requirements. The PBL will include the design/integration documentation for hardware and software CIs. A Physical Configuration Audit (PCA) must be performed to verify that the design documentation matches the design of the delivered product with participation of the appointed CM member(s). For Waterfall or Agile services, the initial PBL is established at the CDR/NIR and the CIs are maintained in the CMDB, DML, and/or PEO Digital USMC CM

Library. For Agile services, the initial PBL should be established prior to the first release and updated during each subsequent release.

The PBL represents the full Technical Data Package (TDP). The TDPs may include specifications, architectures, drawings, analysis models, Bill of Material (BOM), and/or production acceptance test requirements of the system. All data documenting CI changes to the PBL are to be under CM control and verified they are managed IAW this CMP’s change control process.

5.5.4 Operational Baseline

Upon establishment of the PBL, the Operational Baseline (OBL) is established at the conclusion of the system development and is fielded into operations. The OBL is derived from the PBL design information, and consists of procedures, configurations, and other technical information needed by operators and support personnel to operate, maintain, and dispose of the fielded product.

6.0 CONFIGURATION VERIFICATION AND AUDITS

PEO Digital USMC provides support to a networking environment that manages numerous assets on MCEN and PSNet. PEO Digital USMC Portfolios will manage the configuration baselines and maintain control of all procured assets. Verification and audits are required to maintain accurate baseline data and traceability of numerous CIs for networking environments.

Configuration verification audits must be performed by all services on their assets to verify the technically specified form, fit, function and interface of all approved CIs are met. It must be performed to ensure the CI attributes and documentation are complete, CIs are under CM control, and baselines are accurate and consistent with the item’s life cycle support requirement phases as defined in the Systems Engineering Technical Review (SETR) processes. Additional audits and reviews may be necessary to identify readiness and technical maturity as well as evaluate risk and readiness for the next phase of the engineering process or refresh efforts. Audit findings will verify item(s) involved are still meeting the specified form, fit, function and interface performance attributes. The item’s current configuration must match its approved CI documentation.

Audits reinforce the CM rigor of managing changes to the defined performance and functional requirements, design, and ensure accurate documentation is achieved for all approved baselines.

Miscellaneous audits are used to support data call efforts for service management, procurement, sustainability, and logistics. It is used to verify the configuration of baselines and ensure updates are applied and managed per the processes defined within this CMP. Audit criteria can be flexible and is easily modified for appropriate data calls to support the business objectives of PEO Digital and the sustainment efforts for approved configured baselines.

Types of Audits

PEO Digital performs four types of audits: FCA, PCA, CSA and Asset Audits. These audits capture all CIs, associated changes, and update all documentation their changes affect. These items are to be under CM control for the entire life cycle of the CI. For additional information for planning an audit, (see Appendix H).

6.1.1 Functional Configuration Audits

The FCA is conducted to verify the system meets its functional requirements as designed. CM, quality, engineering, logistics, and test organizations present evidence that the product functions IAW all its specified requirements. The FCA is conducted on hardware, firmware, and software CIs to ensure that the technical documentation accurately reflects the functional characteristics of each asset. FCAs are conducted independently after verification activities. At the conclusion of the FCA, an SVR may be performed to verify the item has achieved the requirements specified in its functional and/or allocated configuration documentation. FCAs, testing, and SVRs cannot be conducted at the same time. CM will verify all audited CIs are under configuration control and following the processes documented in this PEO Digital USMC CMP.

6.1.2 Physical Configuration Audits

A CI may consist of the following: HW, SW, interfaces, firmware, drawings, and documentation.

Therefore, the PCA is a required comprehensive audit of any of the CI types that shows development is complete, the production item was built IAW its engineering specifications, and engineering requirements and all differences between configurations have been reconciled. The audit validates that the physical end item is representative of all system documentation from top-level requirements down to individual engineering drawings at the lowest levels and confirms the “as-built” configuration (product baseline) matches the “as designed” (functional baseline) configuration. It is used to validate many of the supporting processes used by the contractor (as applicable) in the production of an item and to verify other elements of the item that may have been impacted/redesigned after completion of the FCA. This audit confirms that the manufacturing development processes, quality control system, measurement and test equipment, and training were adequately planned, followed, and controlled. The SW PCA is an examination of the as-coded total system software against its design or deliverable documentation.

For COTS SW this involves verification of correct documentation to support use of the SW versions actually being delivered on the applicable media. Verify the identifications and markings of all deliverable SW media in accordance with contract requirements or best commercial practice is included in the PCA. PCA activities for HW and SW may run concurrently to establish the final product baseline.

The PCA is used as a checkpoint in the integration of COTS/GOTS into systems. All baselines applicable documentation must be updated to accurately reflect the systems configuration, including the COTS/GOTS item and all modifications made to each COTS/GOTS item.

CM activities are key factors in the conduct of a PCA and data management. CM support members will participate and/or conduct the PCA to verify the CIs, related design documentation, BOM, and technical data and drawings match the “as-built” specification. CM http://acqnotes.com/acqNote/commercial-off-the-shelf-cots support members will verify the conformity of the manufacturing development processes, quality control system, and measurement and test equipment. CM support members will ensure that PCA training on PCA conduct is available for service teams conducting PCAs. The PCA shall be conducted after completion of SVR. PCAs can be used to set baselines following installation if the approved baseline artifacts are found to be insufficient, equipment moved to a new facility, or major changes are made to the current environment the system resides.

6.1.3 Configuration Status Accounting (CSA)

CSA as a method to monitor CI updates in an approved baseline and the status of CM controls of all CI data. CSA is used to monitor changes made throughout the systems lifecycle.

CM support members will provide status accounting reports and minutes to support change boards, team meetings and service milestone reviews as required. Miscellaneous CSA reports can be generated in BMC Remedy by the PEO Digital USMC CM service support members as requested.

6.1.4 Asset Audits

Asset Audits capture data affiliated with the USMC equipment procured by PEO Digital. Asset Audits are not used for verification of a systems configured baseline. These audits are typically conducted by logistics or the assigned service’s CfM. The intent is to capture the inventory type information and any amplifying information that is available. For more information pertaining to assets see section 7.8.1.

These audits are to verify product data elements, such as:

• serial numbers

• part Numbers

• manufacturers

• models

• IUIDs

• rack identifiers

• physical locations

• points of contact

• warranties start/end dates

• licenses start/end dates

• documentation…