ATT J14 GCSS-MC CM Plan FY24.pdf

GLOBAL COMBAT SUPPORT SYSTEM-MARINE CORPS

CONFIGURATION MANAGEMENT PLAN

GCSS-MC-CMP-01

22 April 2024

Revision 3.5

GCSS-MC CMP-01 22 April 2024

RECORD OF CHANGES

Date Revision Description of Change Author

Initial Release

23 Feb 17 1.0 Updates to support End-to-End Process, adoption of Hosting and Network CM, and other changes

Tracy Marino

31 Aug 17 2.0 Updates to support R12 Technical Upgrade and Kansas City Information Technology Center (KCITC) configuration

Tracy Marino

25 Feb 22 3.0 Annual updates Shannon Wright

24 Mar 22 3.1 Audit updates Shannon Wright

24 May 22 3.2 Audit update - Added Appendix H Change Migration Audit Process

John McGraw

11 Nov 22 3.3 Audit update – Chapter 13 updated to capture policy in reference to access provisioning for the SDE and Gitlab Code access. Added Appendix I and J.

John McGraw

24 Feb 23 3.4 Audit update – Added chapter 14 related to monitoring of all changes and Appendix K.

John McGraw

22 Apr 24 3.5 Audit Update – Section 14 updated with improvements to the Backlog audit process.

Updated Appendix K with CR Reconciliation Process. Added Appendix L. Updated Table of Contents. Removed DRAFT Watermarks.

Updated signature block.

Shannon Wright

TABLE OF CONTENTS

1 INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 References

2 CM PLANNING

2.1 CM Roles and Responsibilities

3 CONFIGURATION IDENTIFICATION

3.1 Baseline Management

3.1.1 Baseline Audit Process

3.2 Requirements Management

3.3 Baseline Nomenclature

3.3.1 GCSS-MC Software Identification and Versioning

3.3.2 GCSS-MC Infrastructure Identification and Versioning

3.3.3 GCSS-MC Release Management

3.4 GCSS-MC Product Structure and Top-Level Configuration Items

3.4.1 GCSS-MC Production Environment

3.4.2 GCSS-MC Software Application Configuration Items

3.4.3 GCSS-MC Hardware Configuration Items

3.4.4 GCSS-MC Laptops and Laptop Images

3.4.5 Reports, Interfaces, Conversions, Extensions, Customizations, Personalization’s, and

Workflows (RICECPWs) Configuration Items

3.4.6 Technical Documentation Describing Configuration Items

4 CONFIGURATION CONTROL AND CHANGE MANAGEMENT

4.1 GCSS-MC Change Types

4.1.1 GCSS-MC Issue Change Sub-Types

4.1.2 Change Request (CR)

4.2 Engineering Change Proposal (ECP)

4.3 Specification Change Notice (SCN)

4.4 Requests for Variance (RFV)

4.5 Configuration Control Process

4.5.1 Classification of Changes

4.5.2 Prioritization of Changes

4.5.3 Severity Level of Changes

4.6 Change Approval Processing

4.6.1 Configuration Control Board (CCB)

4.6.2 Change Assessment Board (CAB)

4.6.3 Installations and Logistics Enterprise CCB (ECCB)

4.7 Technical Data Package (TDP)

4.8 Change Control during Government Acceptance Testing (GAT)

TABLE OF CONTENTS (Cont)

5 INTERFACE MANAGEMENT

6 ENVIRONMENT AND INSTANCE MANAGEMENT

7 VIRTUAL MACHINE AND VIRTUAL LOCAL AREA NETWORK

MANAGEMENT

7.1 Virtual Machine Management

7.2 VM Capacity Management

7.3 Virtual Local Area Network (VLAN) Management

8 CONFIGURATION MANAGEMENT METRICS

9 CONFIGURATION STATUS ACCOUNTING

9.1 Configuration Status Accounting Tools and Reporting

10 CONFIGURATION VERIFICATION AND AUDIT

10.1 Physical Configuration Audit (PCA)

10.2 Functional Configuration Audit (FCA)

10.3 CM Process Audit

11 TECHNICAL DOCUMENTATION MANAGEMENT

11.1 Technical Documentation Management Process

11.2 Development and Storage Tools

11.3 Control of Technical Documentation

11.3.1 Library Control

11.3.2 Document Version Control

11.4 Document Identifier

11.4.1 Document Originator

11.4.2 Document Type

11.4.3 Document Series

11.4.4 AIM/OUM Identification

11.4.5 Creating New Revisions

12 GCSS-MC SOFTWARE AND TECHNICAL DOCUMENTATION ARCHIVES,

STORAGE, DISASTER RECOVERY AND DISPOSAL

12.1 Technical Documentation Receipt, Retention and Storage

12.1.1 Retention and Archiving

12.1.2 CM Data Repository

12.1.3 Backups

13 ENVIRONMENT ACCESS CONTROLS

14 MONITORING OF ALL CHANGES TO THE PRODUCTION ENVIRONMENT

15 GLOSSARY

TABLES

Table 1-1. CM Plan Guidance Documents Table 2-1. CM Roles and Responsibilities Table 3-1. GCSS-MC System Baseline Definition Table 3-2. Software Versioning Schema Table 3-3. Infrastructure Versioning Schema Table 3-4. GCSS-MC Production Environment Table 4-1. GCSS-MC Change Sub-Types Table 4-2. Change Prioritization Table 4-3. Change Severity Table 6-1. GCSS-MC Environments and Instances (1 of 3) Table 6-1. GCSS-MC Environments and Instances (2 of 3) Table 6-1. GCSS-MC Environment and Instances (3 of 3) Table 7-1. GCSS-MC Virtual Machine Resource Capacity Approval Authorities Table 11-1. Types of GCSS-MC Program Documents Table 11-2. Documentation Development and Storage Tools Table 11-3. Levels of Version Control Table 12-1. Document Retention Guidelines

FIGURES

Figure 3-1. GCSS-MC High Level Specification Tree Figure 7-1. GCSS-MC Server and Virtual Machine Naming Scheme Figure 11-1. GCSS-MC Document Identifier Figure 11-2. AIM/OUM Document Identifier

APPENDICES

Appendix A—List of Acronyms and Descriptions ......................................................................... A-1 Appendix B – SETR Documentation .............................................................................................. B-1 Appendix C—Engineering Change Proposal.................................................................................. C-1 Appendix D—Specification Change Notice ................................................................................... D-1 Appendix E—RFV Template and Instructions ............................................................................... E-1 Appendix F – Baseline Audit Process............................................................................................. F-1 Appendix G – CM Baseline Reconciliation Report ........................................................................ G-1 Appendix H – Change Migration Audit Process............................................................................. H-1 Appendix I – Access Provisioning Reconciliation Report.............................................................. I-1 Appendix J – Code Access Reconciliation Report.......................................................................... J-1 Appendix K – All Changes Reconciliation Report ......................................................................... K-1 Appendix L – All Changes Reconciliation Report Addendum............................................................................ L-1

1 INTRODUCTION

Key aspects of systems engineering include planning, assessing, analyzing, and controlling various technical activities to help ensure that an integrated and total life cycle-balanced set of systems, people, and process solutions is created that satisfies customer needs. Configuration Management (CM) is a technical process within systems engineering which enables technical control of program activities, system design, work products, requirements, interfaces, data and configurations; and changes to these that would affect cost, performance, and schedule. For large enterprise information systems, the Department of Defense (DoD) has adopted the Information Technology Service Management (ITSM) model. ITSM employs Information Technology Infrastructure Library (ITIL documented best practices). ITIL includes CM as part of Service Transition. Service Transition is the ITIL process that targets build and deploy IT services. The Service Transition process also makes sure that changes to services and Service Management processes are carried out in a coordinated way. The Service Transition processes include Change Management, Change Evaluation, Transition Planning and Support, Application Development, Service Asset and CM, Release and Deployment Management, Service Validation and Testing, and Knowledge Management.

1.1 Purpose

This purpose of this document is to provide guidelines, objectives, responsibilities, definitions, references, and processes for Global Combat Support System–Marine Corps (GCSS-MC) Enterprise NIPERNET V2.x CM activities. Data and document management processes are also included as well as interface management. This document, along with the GCSS-MC Sustaining Engineering Plan that describes the Information Technology Infrastructure Library processes implemented within the GCSS-MC Post Deployment System Support effort (including change management), provide CM technical, administrative and surveillance processes. This plan addresses the following CM activities:

• CM Planning: Budgeting for resources and tools; documenting plans, processes and procedures; and determining metrics, schedules, and milestones for the GCSS-MC CM effort.

• Configuration Identification: Selecting Configuration Items (CIs) for a product, assigning identifiers to them, and recording their functional and physical characteristics in technical documentation. This includes the interfaces for GCSS-MC. CIs comprise the functional, allocated, and product baselines.

• Configuration Control, Change Management, and Release Management:

Configuration Control is the process of maintaining definition and traceability of approved changes to the GCSS-MC baselines. Change and Release includes the identification, tracking, and evaluation of changes; coordination of change reviews for proposed baselines changes; and management of the disposition and implementation of these changes. Change Management is the process responsible for controlling the life cycle of all changes. The primary objective of change management is to enable beneficial changes to be made, with minimum disruption to Information Technology (IT) services.

• Configuration Status Accounting: Recording and reporting information needed to manage CIs, baselines, and CM-controlled environments associated with GCSS-MC.

This information includes approved and pending CIs, the status of proposed changes to

CIs and CM-controlled environments, and the implementation status of approved changes.

• Configuration Verification and Audits: Validation of the integrity of and consistency between a product and its configuration documentation. It provides confidence in establishing a product baseline. It ensures a known configuration as the basis for operation and maintenance instructions, training, spare and repair parts, drawings and technical documentation. It determines that adequate CM processes are in place to provide continuing control of established configurations at all phases of the system’s life cycle.

• Data and Documentation Management: Identification and management of recorded administrative, managerial, financial, and technical configuration information. It includes ownership and approval of the Technical Data Package (TDP) which represents changes to the production system (hardware and software), supporting documentation, configuration management data, versioning of software and documentation, and data repository control and access.

• Interface Management: GCSS-MC identifies external and internal interfaces, establishes interface standards, and maintains interface stability. It includes the activities of defining, controlling, and communicating the information needed to enable unrelated objects (including systems, services, equipment, software, and data) to co-function. New systems or services will be managed by Interface Management and will require formal agreements with the external interfaces or services.

This CM Plan integrates methods and practices documented in Military Handbook 61, Configuration Management Guidance, and industry standards such as Electronics Industry Alliance (EIA) 649, “Consensus for Configuration Management,” Institute of Electrical and Electronics Engineers (IEEE) 12207, “Software Life Cycle Processes, and Information Technology Infrastructure Library (ITIL) Service Transition Practices,” and GEIA-HB-649, Configuration Management Standard Implementation Guide. A list of acronyms and definitions is provided in Appendix A.

1.2 Scope

This CM Plan applies to current and future designs, capabilities, and implementations of GCSS-MC, as well as all activities, integrated product teams, and working groups supporting the program.

1.3 References

Table 1-1 provides guidance documents applicable to this CM Plan:

Table 1-1. CM Plan Guidance Documents

Document Identifier Title Department of Defense Instructions

DODI 5000.02 Department of Defense Instruction, Operation of the Defense Acquisition System

DODI 5000.75 Business Systems Requirements and Acquisition

DON Memo 11 June 2010 Information Technology Service Management (ITSM) Framework in the Department of the Navy (DON)

DOD 5200.01, Vol 4 DoD Information Security Program: Controlled Unclassified Information (CUI)

Military Standards and Handbooks MIL-STD-31000 Technical Data Packages MIL-HDBK-61 Configuration Management Guidance MCSCO 4130.1 Marine Corps Systems Command Order

(MCSCO) 4130.1: Configuration Management Policy

MCSCO 5400.3 Technical Authority Industry Standards

EIA 649 Electronics Industries Alliance (EIA)-649-B, National Consensus Standard for Configuration Management

GEIA-HB-649 Configuration Management Standard Implementation Guide

EIA 836 CM Data Exchange and Interoperability IEEE 828-2005 Institute of Electrical and Electronics Engineers

(IEEE) Standard (STD) 828-2005: IEEE Standard for Software Configuration Management Plans

IEEE 12207 Software Life Cycle Processes 5981-879 4EN Hewlett Packard (HP) Information Technology

Service Management (ITSM) Model ITIL v3 The Information Technology Infrastructure

Library; Service Transition Practices GCSS-MC Program Documents

GCSS-MC-SEP Global Combat Support System – Marine Corps GCSS-MC Sustaining Engineering Plan

TA.105 PROD02 United States Marine Corps GCSS-MC, TA.105 Operations and Support Process PROD02: Tier II Service Desk Standard Operating Procedures – Enterprise NIPRNET

CM-010 CACI GCSS-MC CM Plan CM-070 GCSS-MC Product Baseline Report GCSS-MC-CM-002 Global Combat Support System – Marine Corps

(GCSS-MC) Configuration Control Board (CCB) Charter

Document Identifier Title GCSS-MC-CM-007 Global Combat Support System – Marine Corps

(GCSS-MC) Change Assessment Board (CAB) Charter

GCSS-MC CM Standard Operating Procedures Document Identifier Title

GCSS-MC-CM-001 Change Management Procedures

• GCSS-MC CCB Operations

• Resolving Issues Found During

Government Acceptance Testing

(GAT)

• Creating A SharePoint Production Readiness Review (PRR) View In SharePoint

• How to Generate the Change Assessment Board (CAB) Meeting Agenda

• Technical Documentation Review, Approval and Release

Websites

ODASD(SE)

https://www.acq.osd.mil/se/acronym.html

Office of the Deputy Assistant Secretary of Defense for Systems Engineering Acronyms and Abbreviations

Configuration Management Data Repository (CMDR)

Configuration Management Database

(CMDB)

Change Request Database (CRDB) http://www.acq.osd.mil/se/acronym.html

2 CM PLANNING

The CM Manager reports to the Product Manager (PdM) and will identify the resources and tools required to effectively execute CM and to ensure proper control for the product baseline.

This CM Plan, supporting documentation, and support tools are the foundation of GCSS-MC CM activities; however, significant progress has been achieved to integrate systems engineering, testing, training, subject matter experts, and interface management activities within the CM process. The CM Planning activities will continue to evolve and will be applied to future capability development efforts.

2.1 CM Roles and Responsibilities

Table 2-1, CM Roles and Responsibilities, describes key roles, responsibilities, and activities associated with GCSS-MC CM processes.

Table 2-1. CM Roles and Responsibilities

Role Responsibilities Activities

Product Manager Responsible for

GCSS-MC

CM

• Approves the CMP and the CAB and CCB Charters

• Submits and recommends approval to the Program

Manager (PM) of Engineering Change Proposals (ECPs), Specification Change Notices (SCNs) and Request for Variances (RFVs)

Assistant Product Manager – Engineering (APdM-E)

Responsible for the implementation of

• Chairs the CAB

• Approves the CMP and CAB Charter hardware configuration items and computer software configuration items (CSCIs)

CM Manager Directs, organizes, and coordinates the planning and execution of all CM activities.

• Develops and maintains the CM Plan and associated CM policies. Establishes, approves and maintains CM standards and procedures needed to implement the CM Plan

• Establishes and maintains the Configuration Management Data Repository (CMDR)

• Establishes and maintains the Change Request (CR) Workflow and CR database (CRDB)

• Establishes and maintains the Configuration Management Database (CMDB)

• Implements the CM program as defined in this CM Plan

• Maintains the TDP

• Maintains CM End-to-End Processes

• Participates in program and external IPTs, technical reviews and test events which impact the GCSS-MC current and future baselines

• Maintains an accurate status of artifacts in the

CMDR

• Provides CM metrics

• Educates other functional areas to be able to work effectively and efficiently with the CM tools

• Provides Enterprise-level configuration control and status accounting

• Establishes and documents current and evolving hardware and software level baselines

• Generates and distributes standard and custom reports

• Administers CCB and CAB activities

• Provides guidance and direction in the version control procedures of all configuration baselines

• Conducts CM audits and follow-on activities

Technical Documentation Management (performed by the CM Team)

Manages the inventory in the

GCSS-MC CM

Data Repository

(CMDR)

• Develops standards for maintenance of GCSS-MC technical documentation which includes the TDP

• Controls and processes all requests for artifacts to and from the GCSS-MC CRDB

• Receives all artifacts into the CMDR

• Maintains Controlled Unclassified Information

(CUI) library

• Maintains and controls access to the document libraries as well as all repositories

• Works with document owners, reviewers and approvers to ensure submitted documentation is accepted, reviewed, updated if necessary and approved

• Maintains status accounting of all documentation

• Supports CM activities such as CCB and CAB meetings, configuration reviews, and audits

• Develops and executes workflows for the review and acceptance of documentation

• Archives documentation IAW the CMP

• Creates reports for the Government on selected

CI/CMDR data

• Provides CMDR metrics to the CM Manager

• Conducts Document Management Working Group

Meetings to address technical documentation management issues

• Conducts quality reviews to ensure accuracy of CMDR data

Configuration Identification Coordination (performed by the CM Team)

Maintains the product structure and baseline

• Maintains the configuration of Reports, Interfaces, Conversions, Extensions, Customizations, Personalization’s, and Workflows (RICECPW)

• Ensures changes and documentation are associated within the CMDB

• Participates in new capability IPTs

• Identifies requirements for additional baselines and procedures to maintain

• Supports CM activities such as CCB meetings, configuration reviews, and audits

• Manages the generation, quality and issuance of the

CM-070 document

• Creates and decommissions CIs in the Asset

Management Databases as changes are approved.

Change Manager Coordinates all change-related activities including tracking action items and updating status of Request for Changes

• Ensures each change is recorded and classified in the CRDB

• Coordinates preapproved changes, when applicable

• Notifies all affected parties of the disposition of changes

• Advises and supports the Configuration Manager

• Controls and processes all requests for artifacts to and from the GCSS-MC CRDB

• Ensures the effective use of the Change

Management tracking tool

• Evaluates all CRs for completeness and enforces standards and procedures

• Escalates emergency CRs to the CM Manager

• Assesses risk, confers with relevant experts, and provides the CAB and CCB with recommendations concerning approval of the change

• Reviews the initial change priority and identifying High Level CIs impacted by the change

• Participates in change assessment and review activities

• Ensures the closure of change requests with status information

• Generates and distributes standard and custom reports

• Facilitates the dissemination and disposition CIs

Code Management (performed by the CM Team)

Manages access to and organization of the software code libraries

• Ensures user groups in the CR Workflow and software code management tools are managed properly, reflect correct access levels and personnel are current

• Manages access to code objects and files

• Manages workflows for changes in the CRDB

• Creates builds for Government testing and release

• Conducts training for CR Workflow and software code management tool users

• Generates reports and metrics from CRDB to facilitate CM processes and ensure quality and integrity of CM data

• Participates in CM and release management meetings and test events

• Updates CRDB with notes and status based upon CCB, CAB and other change approval and authorization meetings

• Reviews version description documentation and release installation/upgrade instructions and all other relevant documentation

• Prepares release notes for each build

CCB Coordination (performed by the CM Team)

Manages and controls the production baseline and configuration information and ensures all changes to production are adequately assessed for risk avoidance, impact, and funding

• Maintains the SOP for CCB Operations

• Manages the schedule for CCB meetings

• Ensures CCB meeting material and teleconference requirements are met for each meeting and the meeting begins on time

• Develops CCB meeting agendas and minutes; and statuses action items

• Maintains the CCB entrance and exit checklist

• Maintains the CCB attendees and distribution list

• Coordinates CCB preparation activities with each change sponsor

• Resolves change status accounting discrepancies in the CMDB. CMDR and CRDB

• Reviews CR quad charts for all changes for accuracy and completeness within the CCB approval authority, and coordinates updates with the Product Owners

• Ensures readiness of required documentation to release prior to CCB disposition

• Reviews and monitors the progress of changes within the scope of the CCB

• Reviews all proposed changes and documentation on the agenda prior to the CCB meeting

• Requests and obtains any additional information needed to assess the effects of proposed changes

• Updates CMDR as the result of CCB decisions

CAB Coordination (performed by the CM Team)

Manages and controls the production baseline and configuration information and ensures all changes to production are adequately assessed for risk avoidance, impact, and funding

• Maintains the SOP for CAB Operations

• Manages the schedule for CAB meetings

• Ensures CAB meeting material and teleconference requirements are met for each meeting and the meeting begins on time. Develops CAB meeting agendas and minutes; and statuses action items

• Maintains the CAB entrance and exit checklist

• Maintains the CAB attendees and distribution list

• Coordinates CAB preparation activities with each change sponsor

• Resolves change status accounting discrepancies in the CMDB, CMDR and CRDB

• Reviews CR quad charts for all changes within the

CAB approval authority for accuracy and completeness, and coordinates updates with the change sponsors

• Ensures readiness of required documentation to release prior to CAB disposition

• Reviews and monitors the progress of changes within the scope of the CAB

• Reviews all proposed changes and documentation on the agenda prior to the CAB meeting

• Requests and obtains any additional information needed to assess the effects of proposed changes Reviews CR quad charts for all changes within the CCB approval authority, and coordinates updates with the Product Owners

• Update CMDR as the result of CAB decisions

Status Accounting Coordination (performed by the CM Team)

Responsible for the formatting, data quality and communication of

GCSS-MC

configuration status accounting data and CM related metrics

• Defines format and frequency of reporting

• Perform quality assurance for data integrity, timeliness and consistency

• Produces reports and metrics

Release Manager Responsible for the planning of system updates

• Schedules all changes to the Production Support System (PSS) and production environments and publishes the change schedule

• Coordinates release schedules with Release Planning and Scrum Masters

• Coordinates release plans with the GCSS-MC Operations Center and change sponsors

• Reviews changes ready for build assignment and prioritizes builds

• Publishes 30/60/90-day schedule depicting changes in development, PSS and production as well as environment refreshes, system backups/clones, and type of system outage required

• Reviews the GCSS-MC program integrated master schedule for potential conflicts with the release management schedule

• Participates in CAB and CCB meetings and review activities

• Monitors incident management tickets that have become releases to ensure application to PSS and Production are record in the CRDB.

• Resolves conflicts in change implementation schedules

• Ensures approval has been obtained for the Release schedule

• Secures the authorization from the Program Manager to release builds to the Production system

• Assigns and maintains software release versioning and generates a Software Baseline report for each release

• Reviews builds and recommends a refresh schedule in accordance to the CMP

• Generates DD-1149 for deliveries of system backups and/or clones and maintains a distribution report.

• Generates release metrics.

3 CONFIGURATION IDENTIFICATION

Configuration Identification is one of the cornerstones of CM. The objective of Configuration Identification is to define and maintain the underlying structure of a system. This includes specifying CI types and their sub-components while capturing the attributes and metadata for each CI and identifying and understanding the interrelationships to other CIs, internal and external, to the GCSS-MC system. The Product Manager (PdM) and Assistant PdM, Engineer are responsible for the hardware configuration items and computer software configuration items (CSCIs) which comprise the GCSS-MC system. Technical documentation is associated with the CIs to provide sufficient detail to design and test each CI. CIs are grouped into baselines, which is also an activity associated with configuration identification. As the requirements for the system are decomposed, the baselines progress into increasing detail and accountability for approved changes.

3.1 Baseline Management

A baseline is a configuration identification document or set of such documents formally designated at a specific time also known as a “snapshot in time” during a CI’s life cycle.

Baselines, plus approved changes from those baselines, constitute the current configuration and a point in time from which to define changes. Typically, there are three baselines: Refer to Figure 3-1.

• Functional (FBL): Initial set of approved documentation describing GCSS-MC functional and interface characteristics. The functional baseline (FBL) is established by the Government prior to contract award for system development.

• Allocated (ABL): A document or set of documents which describes all of the approved functions, system characteristics, interface capabilities, and other functional requirements for any configuration item belonging a system or product. The allocated baseline (ABL) not only establishes performance specifications but details the testing, documentation, verification, and service requirements for the system.

• Product (PBL): Describes all functional and physical characteristics of the system necessary to procure, produce, test, inspect, evaluate, accept; and initially establish successfully completion of a physical configuration audit. The product baseline (PBL) for GCSS-MC is the Enterprise production system.

3.1.1 Baseline Audit Process

An audit will be conducted per instance as required following the process in Appendix F (Baseline Audit Process) and G (CM Baseline Reconciliation Report).

3.2 Requirements Management

GCSS-MC is designated as PMW230.1 under the Logistics Integrated Information Solutions- Marine Corps (LI2S-MC) Logistics Portfolio, PMW230. The GCSS-MC Capability

Development Document (CDD) provides the key performance parameters for the system. The GCSS-MC Capability Production Document (CPD) provides the requirements for the system.

Figure 3-1. GCSS-MC High Level Specification Tree

The GCSS-MC CPD requirements are maintained in Dynamic Object-Oriented Requirements System (DOORS) and decomposed in the approved Requirements Traceability Matrix (RTM).

A system verification matrix shall be generated from the CPD requirements for each major system upgrade and results recorded in DOORS. The RTM is under CM control; changes will be managed and consistent with the processes described within this CM plan.

3.3 Baseline Nomenclature

Increments and releases define the system level baseline for GCSS-MC within the PMW230 portfolio. Future additions to the GCSS-MC are identified as increments and releases.

Increments are defined as new functionality, technical refreshes, or additions to the PMW230 portfolio. Table 3-1 provides an explanation of the baseline identification methodology and the current baseline.

Table 3-1. GCSS-MC System Baseline Definition

GCSS-MC System Baseline Identifier as of 11 April 2024

Increment

Acquisition Lifecycle Phase

Release Patch

Set

Version

Description

1 Production 1.1 69 8.123.0.0 Initial Operational Capability, plus code fixes, performance and security updates

1 Engineering Development

1.1.1 37 4.0.0.0 Release 1.1 functionality plus EATO, MFS, RSA, and WAN Optimization

1 Sustainment 1.1.1 41 6.3.1.0 Post Full Deployment Decision, Release 1.1.1

1 R12 Tech Refresh

2.X 56 8.47.0.0 Oracle EBS Release 12 Upgrade and Oracle Engineer Hardware (OEHW)

2 Materiel Solution/ Technology Development

3.X 9.0.0.0 Future system in the GCSS- MC/LCM sub-portfolio

2 Sustainment 4.X 10.0.0.0 Technology refresh, approved code and performance fixes

3.3.1 GCSS-MC Software Identification and Versioning

All GCSS-MC code is stored in Gitlab which provides file level version control and build management through tagging, branches, and merging. All GCSS-MC approved changes are assigned to builds, versioned by incremented build number, which are tested and released to the production system. For ease of managing the significant number of builds, Build Sets are created quarterly which group together all builds deployed to production during that calendar year quarter. The builds are assigned numerically and migrated through the test environment and into production without repackaging. The builds are stored at the Naval Systems Engineering Research Center (NSERC) Gitlab repository maintained in NSERC’s Azure Secure Cloud Computing Architecture (SCCA), and access is managed by the GCSS-MC CM Manager.

GCSS-MC Production has a daily incremental backup performed Monday through Friday with a full system backup completed on Saturdays. When Build Sets are cut, the Code Management team deliveries the Build Set Release Notes to the Program Office along with the Production tape backups, which are stored in the GCSS-MC Physical Media Library.

In order to capture GCSS-MC builds in a context of scope of the change included in the build, the software identification and versioning shall be accomplished in accordance with the software versioning schema shown in Table 3-2. The major software release number reflects the increments and releases defined in the system level baseline definition above.

Table 3-2. Software Versioning Schema

Digit Assignment:

A B C D

Description:

Major

Minor Maintenance

Release

Engineering Candidate/Developer

Release

Definition: • System release

• Changes to an underlying database engine

• Functional addition(s) that did not previously exist as documented in the applicable system specification

• One-digit baseline identifier assigned to the CSCI or collection of CSCIs that represents a system, reflects an approved performance/ product baseline, advances in number as additional program/system level baselines emerge, and is usually accompanied by a system or system/ subsystem specification

• System update

• New features

• Design changes which do not affect functionality or code changes to address bug fixes.

• Two-digit sequential numbers assigned to each release that improves functionality/capability as described in the applicable specification

• Updates without functional additions proposed to resolve known bug fixes (issues, plug-in packages, vulnerability patches (e.g., IAVA/B) or establish or modify system configurations

• Improvements to stability and usability

• Two-digit identifier that indicates addition of minor updates or patches

• Identifies developer internal build

• Two-digit Identifier that indicates the incorporation of site or application-specific file or data

Change Mechanism

• Approved Class I

ECP

• Approved Class I change and/or ECP

• Approved Class II Change

• Approved Class II Change

Digit

Assignment:

A B C D

Description:

Major

Minor Maintenance

Release

Engineering Candidate/Developer

Release

Defense IA Manager

Accreditation

• As determined by Information Systems Security Manager and new Authority to Operate (ATO).

Level of effort dependent upon severity of change

• Requires Addendum to Risk Management Frame (RMF) work

3.3.2 GCSS-MC Infrastructure Identification and Versioning

All GCSS-MC approved infrastructure changes are assigned to builds which may be tested and released to the production system depending on the type of change and their impact to the GCSS- MC application. The builds are assigned numerically and migrated through the test environment and into production without repackaging. To capture GCSS-MC incremental builds in a context of scope of the change included in the build, the infrastructure identification and versioning shall be accomplished in accordance with the versioning schema shown in Table 3-3.

Table 3-3. Infrastructure Versioning Schema

Digit Assignment: A B C Description: Major Minor Maintenance Release

Definition: • Infrastructure design change including network switches or the Exadata configuration

• One-digit baseline identifier assigned to the Infrastructure CIs or collection of CIs that represents the GCSS-MC infrastructure baseline, advances in number as changes are made to the infrastructure that result in, and is usually accompanied by a system or system/subsystem specification

• Operating System updates

• Configuration or IP address changes

• Two-digit sequential number assigned to each release that addresses configuration updates

• Updates or patches without functional additions proposed to resolve known bugs, issues, and vulnerability to software critical to the operational effectiveness of any hardware component

• Two-digit identifier that indicates addition of minor updates or patches

Change Mechanism • Approved Class I ECP • Approved Class II Change

• Approved Class II Change

Defense IA Manager

Accreditation

• As determined by Information Systems Security Manager and new Authority to Operate (ATO). Level of effort dependent upon severity of change

3.3.3 GCSS-MC Release Management

The GCSS-MC Release Management process manages, plans, schedules, and controls a software build through development, testing, and deployment to environments. In addition, the Release Manager plans environment refreshes to ensure that the configuration of the development to production environments are in sync and works with the Software Development Environment operating system and application patches are applied to development instances. The Release Management process is documented in the GCSS-MC Sustaining Engineering Plan and the associated Release Management Process Analysis & Narrative document.

3.4 GCSS-MC Product Structure and Top-Level Configuration Items

The GCSS-MC product structure refers to the CIs, documentation defining the CIs, and the relationship of the CIs. Along with the hardware supporting the system and the Oracle EBS COTS software product, GCSS-MC utilizes a combination of System Engineering Technical Review (SETR) documents and Oracle Applications Implementation Methodology (AIM) and Oracle Unified Methodology (OUM) which comprise much of technical documentation for the system. These methodologies break out the product structure to the lowest level necessary to conduct baseline management.

Changes to the product structure, including the SETR, AIM and/or OUM inventory, must be approved by the GCSS-MC CAB or CCB, depending upon the type of change.

3.4.1 GCSS-MC Production Environment

The production system is located at the Kansas City Information Technology Center (KCITC) in Kansas City, Mo. Table 3-4 provides the name of each environment and description.

Table 3-4. GCSS-MC Production Environment

System Environment Instance ID Application

KCITC PROD GANEPA IDM

KCITC PROD GCNEPA OEM

KCITC PROD GENEPA EBS-Forms

KCITC PROD GONEPA OBIEE

KCITC PROD GBNEPA SOA/BPEL

3.4.2 GCSS-MC Software Application Configuration Items

GCSS-MC is comprised of many software applications. In addition to the software name, version and vendor the software licenses associated with the software are tracked in the CMDB which also includes the type of license, the cores and core ratio, type of users, and servers are tracked and managed through the change control process.

3.4.3 GCSS-MC Hardware Configuration Items

The GCSS-MC hardware supports servers across production and PSS environments. The servers are named, owned, and managed by GCSS-MC Program Management Office (PMO). In accordance with a Memorandum of Agreement (MOA) between KCITC, HQMC C4 and GCSS- MC, KCITC provides hosting services (power, pipe, and ping) for the PSS and PROD environments as well as pulling and mailing backup tapes to the PMO. System configuration is controlled and tracked by GCSS-MC CM.

Specific version information regarding each HWCI can be found in the GCSS-MC Configuration Status Accounting (CSA) Report.

3.4.4 GCSS-MC Laptops and Laptop Images

In addition to the HW and SW CIs for the PSS and production environments, GCSS-MC also maintains configuration control over the laptops and the associated approved image used to support the Government Operations Center (GOC), Infrastructure, Test and Evaluation (T&E), and Mobile Training Suite (MTS). After testing the image, each is placed under CM control when the image has been approved by the CAB. The images are then entered into the CMDB and associated with the laptops. The laptops with the approved images are also placed under CM control once the association is made in the CMDB. Changes to the laptop images and laptops with the approved image require a CR to change the image or decommission a laptop or add a new laptop with the approved image.

3.4.5 Reports, Interfaces, Conversions, Extensions, Customizations, Personalization’s, and Workflows (RICECPWs) Configuration Items

Customization of the GCSS-MC solution is accomplished using RICECPW objects with Oracle and other third-party COTS software; all RICECPWs are software CIs. The software and associated design documentation is tracked by CM. New RICECPW must be introduced using a CR and approved by the CCB prior to development and implementation. Additionally, an approved CR by the CCB is needed to inactivate or retire any RICECPW CI prior to removal from the baseline.

Each RICECPW CI is tracked as it moves through the development life cycle and placed in production or decommissioned.

3.4.6 Technical Documentation Describing Configuration Items

The GCSS-MC system architecture, design, interfaces, customizations, test scripts, operations procedures, and knowledge management tools have been developed using AIM/OUM. AIM and OUM was the project management methodology and still is the program’s implementation strategy until the technical documentation is transferred to acquisition or lifecycle management documents as identified in the System Engineering Technical Review (SETR) process, see Appendix C. AIM provides documentation templates that support the tasks needing to be performed to assist the implementation participants in running and managing projects successfully. The templates used by GCSS-MC are a subset of the complete list of available templates. GCSS-MC also adopted the OUM, which is a standards-based method with roots in the Unified Process. OUM is business-process and use-case driven and includes support for the Unified Modeling Language (UML). GCSS-MC Release 1.1 uses AIM and Release 1.1.1 introduces OUM. Customizations, Personalization’s and Workflows were added to support the R12 Technical Upgrade.

4 CONFIGURATION CONTROL AND CHANGE MANAGEMENT

Change Management is the process of tracking changes to any approved baseline configuration throughout the entire program life cycle. The objective is to control the lifecycle of all changes, ensuring that all approved changes are properly documented, and that CIs are not added or modified without the required authorization. Each modification is evaluated for priority and impact to cybersecurity, training, cost, schedule, design, operations; and are approved prior to implementation.

GCSS-MC CM will manage all changes to program configuration baselines using established Systems Engineering Technical Review (SETR) processes and IPTs, and the CABs and CCBs to prepare, justify, evaluate, dispose, and implement change solutions, ECPs, Specification Change Notices (SCNs), and Requests for Variances (RFVs) to affected CIs and baselined configuration documentation. Documentation that will be baselined and approved by the CAB and CCB will include, but not be limited to, Oracle AIM and OUM documentation, Statements of Work (SOW), and associated Contract Data Requirements Lists (CDRL) deliverables, Interface Control Documents (ICDs), Drawings and Diagrams, Engineering Change Proposals (ECPs), Change Requests (CRs), SCNs, and RFVs. See for the GCSS-MC Change Management Process.

4.1 GCSS-MC Change Types

Proposed changes to the GCSS-MC system are categorized by components of the system and are aligned with the Program’s organization:

• Infrastructure including network updates, hardware, OS, and databases

• Functional business processes

• Information Assurance/System Security

• Data Quality/Interfaces

4.1.1 GCSS-MC Issue Change Sub-Types

Issues can be identified by a sub-type which identifies the GCSS-MC change authority and the associated CIs impacted by the change. Table 4-1 provides a description of each.

Table 4-1. GCSS-MC Change Sub-Types

Change Sub Types

Description Potential Affected Work Products/Configuration Items

Change Authority

Code Fix A correction to the GCSS-MC RICE code, SQL, or form customization which corrects a bug or provides code tuning.

DS.145 (CV.010 or 020 would be rare if conversion item); TE.050 or 070, TE.025, TE.054 (Test Scripts)

GCSS-MC

Change Assessment Board (CAB)

Configuration Fix

A parameter change, software COTS version update, Information Assurance Vulnerability Advisory (IAVA) or manufacture's OEM patch to a GCSS- MC software product/configuration item. Also includes content changes of training Materials/programs.

Note: If code is associated with a configuration fix the CR will be labeled as a Code Fix.

MC.055; DS.145 (CV.010 or 020 would be rare if conversion item);

TA.090s (Security Documents), TE.050 or 070, TE.025, TE.054 (Test Scripts), TE.50 Episode 101 Tests; IM.090 (Application and Database Installation/Setups); Oracle Checklists

CAB

COTS Upgrade COTS upgrade for GCSS-MC business applications, hosting management services or network changes this includes major version upgrades does not affect form, fit, or function.

Physical and Logical Drawings, TA.095 (Application and Database Installation/Setups), TA.105;

Checklists;

CAB

Hardware Fix A parameter setting change or COTS version update to a GCSS- MC hardware product/configuration item, including technology refresh.

Building or re-provisioning of servers.

TA.xxx,TE.050, TE.040, TE.054 (Test Scripts), TA.105

CAB

Data Script A script developed to effect a direct backend database / bulk change of data residing in GCSS- MC that is either incorrect or in need of specific updating in order to support operations or to change data to comply with standards.

DS.145; MC.055; MC.060 (CV.010

or 020 would be rare if conversion item); TA.090s (Security Documents), TE.050, TE.040, TE.054 (Test Scripts);

Help Desk Troubleshooting Guides; AP.150s.

CAB

New Software A change to software form, fit or function, including changes directed by higher authority, or required for compatibility with higher echelon systems. Ensure a requirement is selected for the Requirement ID field.

I&L requests review and concurrence of all design changes.

BP.90, DS.145;TA.XXX; TE.010

(CV.010 or 020 would be rare if Conversion item); TA.090s (Security Documents), TE.050, TE.040, TE.054

(Test Scripts)

GCSS-MC

Configuration Control Board

(CCB)

Change Sub Types

Description Potential Affected Work Products/Configuration Items

Change Authority

New Hardware A change to hardware form, fit or function of the GCSS-MC system, including changes directed by higher authority Ensure a requirement is selected for the Requirement ID field.

I&L requests review and concurrence of all design changes.

BP.90, TA.XXX, TA.090s (Security Documents), TE.050, TE.040, TE.054

(Test Scripts)

CCB

New Requirement

A change to the form, fit or function of the GCSS-MC system which is a new requirement not documented in the CPD and does not exist in the system. New requirement changes must be approved by I&L and Capabilities Development and Integration (CD&I) and require additional funds to implement.

Documentation variable: DS.145 and others (CV.010 or 020 would be rare if NEW Requirement is for new data conversion item); TA.090s (Security

CCB

4.1.2 Change Request (CR)

A CR is a proposed change to GCSS-MC. CRs are entered into the CRDB and fixed according to priority. Service Requests elevated from Incident and Problem Management from the Tier 1, 2, and 3 Help Desks are associated with a respective CR. CRs that are generated as a result of testing are associated to the original CR. Program capabilities and initiatives are defined in the CR Workflows and are grouped together whenever possible.

4.2 Engineering Change Proposal (ECP)

ECPs are proposed changes or enhancements to the CIs design, operation, functionality, or requirements of the GCSS-MC system. ECPs may reference and include one or more CRs.

Additionally, changes to drawings, associated lists or other documentation will be described in a revised ECP in lieu a Notice of Revision (NOR). Form DD-1692, Engineering Change Proposals, has been modified for the GCSS-MC program, and is included in Appendix C. The instructions to complete the tailored Form DD-1692 can be found on the GCSS-MC CM Repository under Change Management, Forms and Templates.

4.3 Specification Change Notice (SCN)

SCNs are used to record, manage, and transmit approved changes to an existing contracted GCSS-MC specification. Once approved by the CCB, the SCN is placed on contract as the official notice of changes to the specification. SCNs are documented using form DD-1969, see Appendix D. The SCN form and instructions can be found on the GCSS-MC CM Repository under Change Management, Forms and Templates.

4.4 Requests for Variance (RFV)

An RFV is prepared to allow acceptance of a nonconforming item. When it is determined that a product cannot be developed as specified in baseline documents, an RFV is prepared to gain approval for temporary departure from the documented configuration. An RFV is processed to record the departure from baseline documents, include action plans to correct the departure at a future IMS scheduled date; and does not represent a permanent change to the baseline documentation. All variances shall be documented and approved by the CCB. The RFV form, DD-1694 with the continuation page and instructions for completing the form are found in Appendix E. The RFV form and instructions can be found on the GCSS-MC CM Repository under Change Management, Forms and Templates.

4.5 Configuration Control Process

The GCSS-MC configuration control processes enables a systematic review by program and technical teams, of proposed changes, and validation of system changes prior to Government testing and release. The process is managed by the CM Manager and owned by the CHENG.

CCB and CAB milestones align with typical software development life cycles and the systems engineering technical reviews. Refer to Change Authorization Board (CAB) Charter.

4.5.1 Classification of Changes

Changes can be grouped into two classifications (Class I and Class II).

Class I changes are changes that fall into the following change sub-type categories:

• New Software

• New Hardware

• New Requirement

Class II changes are changes that fall into the following change sub-type categories:

• Configuration Change

• Code Fix

• COTS Upgrade

• Hardware Fix

• Data Script

• Test Configuration

• Test Script

4.5.2 Prioritization of Changes

A priority is assigned to all changes. GCSS-MC uses a prioritization of changes consistent with the IEEE 12207 guidance as well as user impact to a Business Process (BP) as defined in TA.105 Operations and Support Process, PROD02: Tier II Service Desk Standard Operating Procedures

– Enterprise NIPRNET as a reference. The CR originator is responsible for recommending a priority upon submission of a change, based upon the respective impact to the Enterprise. The current Increment 1 Mission essential BP are:

a. Request Management: Create or Update Service Request; Request for Supply; Request for Service; Request for Technical Assistance; Mass Transfer of Install Base Ownership; Create and Maintain Accountable and Responsible Officers; Retire Install Base Items; Flagging Install Base Items for Readiness; Maintenance-Related Returns.

b. Supply: Order Management Execution; Requisition to Receipt; Inquiries and Reports; Return of Spares; Secondary Reparable or T/E Items; Demand Planning; Forecasting; Supply Costing;

Advanced Supply Chain Planning; Spares Management Minimum/Maximum Planning;

Inventory Minimum/Maximum Planning; Quality; Inventory Accuracy; Item…