Exhibit_5B_TFITS_Configuration_Management_Plan.pdf

FOR OFFICIAL USE ONLY

CONFIGURATION MANAGEMENT PLAN (CMP)

TOTAL FORCE INFORMATION TECHNOLOGY

SYSTEMS (TFITS)

Version 3.0 November 2015

Prepared by:

Prepared by:

MARINE CORPS SYSTEMS COMMAND (MCSC)

TFITS

Information Systems & Infrastructure (IS&I)

Quantico, Virginia 22134

TFITSDC0001 TFITS CMP November 2015 ii

SIGNATURE PAGE

CMP

TECHNICAL REVIEW:

Mr. Robert Lovejoy Assistant Product Manager – Engineer (APdM – E)

PMM 110 IS&I, TFITS

MCSC

CONCURRENCE:

Mr. Tony Brill Deputy Product Manager (DPdM)

PMM110 IS&I, TFITS

APPROVED BY:

Mr. Lou Peradotto Product Manager (PdM)

PMM 110 IS&I, TFITS

iii

FOR OFFICIAL USE ONLY

Executive Summary

Configuration Management (CM) is an umbrella activity developed to identify changes, manage changes, ensure changes are being properly implemented, report changes to others who may have an interest, and record changes for historical reference. CM activities include the technical and administrative actions required to identify and document the functional and physical characteristics of a Configuration Item (CI). In addition, CM activities control changes to a CI and its characteristics, as well as verify, record, and report change processing and implementation status. As a result, CM can provide a complete audit trail of decisions and design modifications.

Department of Defense Instruction (DoDI) 5000.02, Enclosure 12, paragraph 5, directs the use of CM across the total system life cycle per the following extract:

The PM shall use a configuration management approach to establish and control product attributes and the technical baseline across the total system life cycle. This approach shall identify, document, audit, and control the functional and physical characteristics of the system design;

track any changes; provide an audit trail of program design decisions and design modifications; and be integrated with the Systems Engineering Plan (SEP) and technical planning. At completion of the system level Critical Design Review (CDR), the PM shall assume control of the initial product baseline for all Class 1 configuration changes.

This CMP provides methods to define, document, control, implement, account for, and audit changes to the various CIs of TFITS Projects. Using the American National Standards Institute/ Electronic Industries Alliance standard 649 as the standards, the Military Handbook (MIL- HDBK) 61A and the Government Electronics Information Technology Association Handbook (GEIA-HB) 649, as guides, CM for TFITS has been tailored to manage the functional and physical attributes of the system. Configuration planning includes the identification of functional and physical level documents, such as specifications, drawings, diagram, or other documents that identify the end item. This plan documents the change control structure and provides details relative to Configuration Change Board (CCB) operations, Configuration Status Accounting (CSA), and Configuration Verification and Audit (CV&A).

https://acc.dau.mil/dag_5000.02p30#5 iv

FOR OFFICIAL USE ONLY

RECORD OF CHANGE HISTORY

Version Number

Date

Figure, Table or

Paragraph Number

A, M, D Title of Brief Description

Change Reques t Numbe r

1.0 Mar 14 All N/A Initial Document N/A

2.0 Sep14 All All Annual update to the TFITS CMP CR_48

3.0 Sep 15 All All Aunnal update to the TFITS CMP CR_81

& 82

3.0 Sep 15 iv M Removed individual V2.0 changes from change history.

Details remain in V2.0.

3.0 Sep 15 P 8 M

Update to the Configuration Management System (CMS) diagram to remove Systems Engineering

Technical Review (SETR) Event Tracker

3.0 Sep 15 P 9 M

Modified the Roles diagram to include the Advocate in each the Functional Review Board (FRB), Engineer Review Board (ERB) & CCB

3.0 Sep 15 Table 2.2 D Removed ‘Urgency’ from FRB Description. The Urgency attribute was removed from the ECP Tracker

3.0 Sep 15 Table 2.2 D

Removed ‘Justification of Change’ from ERB

Description. The Justification of Change’ attribute was removed from the ECP Tracker

3.0 Sep 15 Table 2.2 A Added Information Assurance (IA) requirement for CCBs to the CCB Description.

3.0 Sep 15 Table 3.2 M

Modified environment descriptions in the Configuration Item Technical Database (CITDB) Table from Dev, Test & Prod; to: ‘that fall within the accreditation boundary’

3.0 Sep 15 Table 3.2 M

Changed Tracelink CI Type to Hostname CI type. This reflects a change in how the CITDB will track tracelinked CIs

3.0 Sep 15 Table 3.2 A

Added, ‘Source code may be delivered by the SI in physical assets such as, DVD or CD. These media will be stored in the TFITS approved safe.’ To SWCI row.

3.0 Sep 15 P18 Section

4.1.2 A

Added, ‘Virtual ERB and CCB are acceptable means for reviewing and approving 4th octet changes’ to first paragraph

3.0 Sep 15 P18 Section

5.1 A

Added, ‘Releases may be tracked by unique name or System Version Number (SVN). Once a release package has been approved at Production Readiness Review (PRR) the SVN must be used to track the release in production.’ To first paragraph

3.0 Sep 15 P20 Section

7.0 A

Modified first paragraph to read more cleanly and better incorporate the usage of Physical Configuration Audit

(PCA), Post Implementation Review (PIR) and Production Verification Test (PVTs).

*A-Added, M-Modified, D-Deleted v

FOR OFFICIAL USE ONLY

TABLE OF CONTENTS

1. INTRODUCTION

1.1 Scope

1.2 Objectives

1.3 TFITS Systems and Applications

1.4 Reference Documents

2. PLANNING AND MANAGEMENT

2.1 CM Organization, Roles, and Responsibilities

2.2 Configuration Management System

2.3 Configuration Management Boards

2.4 Configuration Management Integrated Product Team (IPT)

3. CONFIGURATION IDENTIFICATION

3.1 Configuration Item Naming Methods

3.2 Configuration Item Technical Database

3.3 Configuration Baselines

4. CHANGE MANAGEMENT

4.1 Engineering Change Proposal ......................................... Error! Bookmark not defined.

4.2 Action Item

5. VERSION MANAGEMENT

5.1 System Versioning

5.2 Document Versioning

6. CONFIGURATION STATUS ACCOUNTING

6.1 Configuration Status Documents and Reports

7. CONFIGURATION AUDIT

7.1 Technical Documentation

7.2 Physical Configuration Audits

7.3 Configuration Management Quality Assurance

Appendix A Acronym List ................................................................................................... A-1 Appendix B TFITS CITDB Data Dictionary ......................................................................B-1 Appendix C TFITS System Versioning Schema ................................................................ C-1 Appendix D TFITS ECP Workflow Process (Class I & Class II ECPs) .......................... D-1 vi

FOR OFFICIAL USE ONLY

Table of Figures

Figure 2-1: TFITS CM Delegation of Authority Figure 2-2: TFITS CMS Functionality Figure 2-3: Review Board Members Figure 4-1: Simplified TFITS ECP Process Figure C-1: Software Versioning Schema……………………………………………………..C-1 Figure D-1: TFITS ECP Workflow Process…………………………………………………...D-1

List of Tables

Table 1-1: TFITS Managed Projects Governed by this CMP Table 2-1: CM Roles and Responsibilities Table 2-2: Review Board Member Responsibilities Table 2-3: CM IPT Members Table 3-1: Configuration Item Designators Table 3-2: Configuration Item Technical Database Description Table 3-3: Configuration Baselines Table 5-1: Document Versioning Example Table 7-1: Required Technical Documentation

1. INTRODUCTION

This CMP has been developed to set out the processes that the IS&I TFITS Product Management Office (PdMO) will follow to define, document, implement, account for and audit changes to requirements and baselines, supporting processes and documents for each of the projects in its portfolio.

The purpose of this document is to define the practices and procedures required to accomplish configuration management throughout the lifecycle of each TFITS project. The intended audience for this document is the TFITS PdMO, its supporting agencies, and TFITS Development Contractors (hereafter referred to as Systems Integrators (SIs)). It also applies to TFITS IPTs, Working Groups (WGs) and other Government personnel who have oversight responsibilities for TFITS projects.

The SI shall develop a SI CMP and execute a configuration management process that addresses and coordinates with the processes, products, functions, and objectives described in this plan.

This CMP is considered a living document and will be updated as necessary to support evolving program requirements and maturing products and processes.

1.1 Scope

CM is a systems engineering discipline that formalizes the management and control of configuration changes to a system throughout its lifecycle. The key principles of CM are to ensure that all components of a system be uniquely identified, managed and controlled. The TFITS PdM is responsible for CM across the entire PdMO. The TFITS Project Managers (PjM) are responsible for executing the requirements of this plan for each of their respective projects.

The TFITS Systems Engineers (SE) are responsible for executing CM for their competency.

1.2 Objectives

The CM objectives for the TFITS program are to:

• Execute an effective CM process that includes:

o Identifying, establishing, managing, and verifying functional, allocated, and product baselines o Assuring an organized, traceable, and verifiable process by which configuration items (CIs) may be implemented o Ensuring all changes are controlled, processed, recorded, implemented, reported, and archived for historical reference o Capturing, evaluating, and documenting existing process, and performing process improvement o Supporting, facilitating, implementing, and coordinating the CCB, process as required

• Coordinate the Government and SI CM processes

• Provide a complete audit trail of decisions and design modifications

• Provide the information required to ensure delivered end products conform and perform to their specifications; any requested deviations will be documented and approved through the TFITS change management process

• Perform PCAs with sustained CSA in conjunction with the release of ECP and updates to the CITDB

• CV&A in accordance with the TFITS Change Management Process

• Apply configuration control to approved baseline documents, such as requirements, specifications, designs, drawings and diagrams

• Manage TFITS CIs

• Address IA CM related requirements (version releases and controls)

1.3 TFITS Systems and Applications

Systems and applications that are included in the TFITS portfolio are categorized into three groups: Managed, Supported, and Monitored. The PdMO is responsible for configuration management of all Managed systems listed in Table 1-1.

Table 1-1: TFITS Managed Projects Governed by this CMP

No. Project Name Acronym 1 Paperless Acquisition Purchase Request Builder PA PRB 2 Paperless Acquisition Standard Procurement System PA SPS 3 Radio Frequency Identification RFID 4 Defense Readiness Reporting System- Marine Corps DRRS-MC 5 Theater Medical Information Program-MC TMIP 6 Marine Corps Recruiting Information Support System MCRISS 7 Marine Corps Training Information Management System MCTIMS 8 Automated Performance Evaluation System APES 9 Requirements Transition and Manpower Management System RTAMMS

10 Manpower Mobilization Assignment System / Marine Corps Force Augmentation Processing System

MMAS/

MCFAPS

11 Optical Digital Imaging-Records Management System ODI-RMS 12 Performance Evaluation System PES 13 Secure Personnel Accountability SPA 14 Total Force Retention System TFRS 15 Web Based Manpower Assignment Support System WebMASS 16 Manpower Models MODELS 17 Total Force Data Warehouse TFDW 18 Total Force Structure Management System TFSMS 19 Joint Force Requirements Generator II & JFRG II Modernization (M) JFRG II (M) 20 MAGTF Deployment Support System II MDSS II 21 Automated Manifest System-Tactical AMS TAC 22 Defense Messaging System/Organization Management Systems DMS/OMS

1.4 Reference Documents

The references provided are CM sources that contain the CM standards, instructions and directives, guidelines and processes from which this CMP is formulated.

1.4.1 Standards

Department of Defense:

• MIL-STD-881C: Work Breakdown Structures for Defense Materiel Items Government and Industry:

• GEIA-HB 649B: Implementation Guide for Configuration Management

• TechAmerica Electronics Industries Alliance-649-B: Configuration Management

Standard

1.4.2 Instructions and Directives

Department of Defense:

• Department of Defense Directive 5000.1, The Defense Acquisition System

• DoDI 5000.02, Operation of the Defense Acquisition System

• Defense Acquisition Guidebook

1.4.3 Handbook/Guidelines

Department of Defense:

• MIL-HDBK-61A: Configuration Management Guidance

MCSC:

• MCSCO 4130.1A - MCSC Configuration Management Policy

• MCSCO 5400.5 – Naval SYSCOM Systems Engineering Policy

• SIAT-HDBK-003 – CM Implementation Handbook

• MCSC Systems Engineering Technical Review Handbook

• TFITS Systems Engineering Plan

• TFITS Performance Measurement Plan

• TFITS Requirements Management Plan

• TFITS System Test & Evaluation Strategy

• TFITS Risk Management Plan

2. PLANNING AND MANAGEMENT

The TFITS CM program is initiated through this CMP by the TFITS PdM to fulfill the requirements of MCSCO 4130.1, Configuration Management Policy. The Integrated Process and Product Development process consisting of three major components (tools, teams, and processes) will be used to develop the structure, and create the business practices necessary to accomplish the TFITS program objectives and CMP goals.

The TFITS CMP provides guidelines and policies that will ensure requirement and product CI baselines are established, controlled, and maintained. Also, this plan identifies the procedures, responsibilities, and activities that all personnel must follow in order to maintain a valid CI baseline. The activities are facilitated by the degree of management support provided, the working relationships established with other interfacing activities such as PdMO, IPTs, WGs, Engineering, Logistics, IA, and SI Configuration Management.

TFITS CM processes and procedures adhere to MIL-HDBK-61A. Any modification to or deviation from of the approved CMP processes or procedures must be reviewed by the CM IPT and approved by Tier I leadership.

2.1 CM Organization, Roles, and Responsibilities

The CM structure features an integrated organization with well–defined functions that interface with all program functional elements. Within the TFITS PdMO, the PdM has the overall responsibility for implementing the requirements of MCSCO 4130.1, Configuration Management Policy and may delegate as necessary. The TFITS APdM-E, serves as the Configuration Manager (CfM), responsible to the PdM for the execution of this plan. Figure 2-1 shows the delegation of TFITS CM authority.

APM-E

PdM APdM-E

SE

PM

PjM (Tier II, III)

CCB Chair ERB Chair

CCB ERB

Delegated CCB Chair

Delegated CCB Chair

Delegated ERB Chair

Delegated ERB Chair

Figure 2-1: TFITS CM Delegation of Authority

Table 2-1: CM Roles and Responsibilities

CM Roles Responsibilities

Product Manager (PdM)

• Chairman of the CCB responsible for fulfilling the requirements of MCSCO 4130.1, Configuration Management Policy. The PdM may delegate his/her authority to the PjM o Establish the CM approach o Controls product attributes o Manage the technical baseline across the total system life cycle o Responsible for the review and approval of Class I & Class II ECPs

• Assume control of the initial product baseline

Tier II PjM

• Responsible for the oversight and management of the TFITS’ projects production baseline

• Responsible for execution and adherence to the TFITS CMP

• Coordinate TFITS CM process improvement activities through the Tier 1 IPT

APdM-E

• Perform the TFITS Change Management (ChM) function but may delegate this authority to the SE

• Oversee the planning, development and execution of the TFITS CM and engineering efforts

• Chair the TFITS ERB (may be delegated to SEs)

• Develop and maintain CM related documentation, such as the CMP, standard operating procedures (SOP) and CSA

• Accountable for the overall TFITS CM process development and execution

• Establish and maintain TFITS configuration baseline documentation

• Chair technical reviews and audits (first and second octet changes)

• Develop and implement new technical approaches to existing processes, products, and operational concepts

• Ensure product baselines are maintained and version controlled as specified in appendix C of this plan

• Provide technical and managerial support for the CM processes

• Provide technical and managerial support for TFITS IPTs

• Participate in meetings where proposed baseline changes are discussed

• Conduct and/or support TFITS PCAs

• Coordinate and concur on all CM process development and delivery

• Responsible for execution of the CMP

PjM

• Execute rigorous processes for CM activities o Configuration identification o Configuration control o Status accounting o Configuration verification o Configuration audit of Project CIs

• Establish and maintains Lifecycle Management Plan (LCMP)

• Operational efficiency and control over Hardware (HW) / Software (SW) CIs

• System performance and readiness

• Lifecycle Cost

• Responsible for ensuring his/her project conforms to CM related processes and procedures

• Additionally, PjM is responsible for the following tasks:

o Plan, execute, and facilitate project CCB meetings o Participate in meetings where proposed baseline changes are discussed o Coordinate and schedule events related to baseline changes o Manage the execution of CCB approved ECP o Initial Capabilities Documents, Service Level Agreements and Memorandum of Agreements o Track, Approve and Post Contract Data Requirements Lists (CDRLs) to the TFITS CDRL Tracker in SharePoint

Systems Engineer

(SE)

• Support the APdM-E in all CM and engineering activities in accordance with the TFITS SEP and TFITS CMP

• Perform the Project Change Management function as delegated by APdM-E

• Oversee the planning, development and execution of their Projects engineering CM efforts

• Chair the Project ERB

• Execute CM related documentation, such as the CMP, SOP and CSA

• Execution of baseline development and documentation

• Execution of baseline delivery

• Responsible for project:

o Manage Engineering CIs in the CITDB o Provide formal approval of the release (authority delegated from APdM-E) of ECPs into the production environment o Establish and maintain project configuration baselines o Chair technical reviews and configuration audits o Manage requirements and interfaces

Logistician

• Executes Logistical functions of CM o Participating in ERB and CCB o Review logistics CIs in the CITDB o Support the PCA process

CfM

• The APdM-E is designated to be the CfM but may delegate this authority for TFITS’ project level baselines.

• The CfM will enforce the rigorous processes for CM activities to include:

o Configuration identification o Configuration control o Status accounting o Configuration verification o Configuration audit of Project CIs

Configuration Management Analyst

The CM Analyst is a member of the PdMO CM staff and is assigned to support the daily management and accounting of Government data and CIs. The CM Analyst will work with PjMs, SE, SI and supporting competencies to ensure integrity of program documentation and system configuration. CM activities are reported directly to CfM. Additionally, CM Analyst is responsible for the following tasks:

• Control, maintain, and manage the Configuration Item Technical Database (CITDB) and associated CIs

• Manage and maintain approved project documentation in the Published Library

• Document and maintain all CM processes and procedures

• Control system configurations

• Validate ECPs are documented and maintained

• Provide ECP status reports in support of Change Management and SETR events

• Establish relationship of ECPs to effected CIs

• Provide status of CIs relationship to ECP in support of Change Management and SETR events

• Provide SEs status of CI completeness

• Conduct CSA and develop reports

• Conduct PCA

2.2 Configuration Management System

The TFITS PdMO will use the Government owned TFITS SharePoint Portal as its CMS. The CM functionality included in the TFITS CMS is displayed in Figure 2-2.

Configuration Management

System

TFITS SharePoint Portal

CITDB Tracker Provides the managed baseline version of HWCIs, SWCIs, Tracelinks, Interfaces & Documentation

ECP Tracker Provides management, accounting and control of project ECPs

Document Libraries Project Working Libraries, Product Library & Published Library

CDRL Tracker Provides management control of contract deliverables

RISK Tracker Provides management, accounting and control of project risks

Figure 2-2: TFITS CMS Functionality

Access to TFITS SharePoint is granted to individuals based upon their role in the TFITS program. TFITS SharePoint will also be used to provide CSA.

2.3 Configuration Management Boards

The configuration review boards consist of FRB, ERB and CCB as depicted in Figure 2-3. Each Review Board has a chairperson and other personnel to support change management. The Chair of each board will make decisions with recommendations from the respective board members. A quorum is not specified as the Chair has ultimate approval authority; however, dissenting recommendations from board members must be documented in the minutes and entered as risks for mitigation. Board members not in ERB/CCB attendance must provide written recommendations for each ECP. All ECPs will be submitted and managed in the TFITS CMS, ECP Tracker.

FRB ERB CCB

Chairperson

FAM

Chairperson

TFITS SE

Chairperson TFITS PdM/PjM

Members PjM

IAM

Logistician FAM, Advocate

HSI,

CM, T&E

SMEs, SI

Members PjM

Logistician, IAM Financial Mgr

FAM, Advocate, HSI Contracts

CM, T&E

SMEs, SI

Members Advocate

PjM

SE

Logistician SMEs

SI

Figure 2-3: Review Board Members

Table 2-2: Review Board Member Responsibilities

Review Board Description

FRB

Advocates will establish a Project level FRB. The FRB is chaired by the Advocate with members consisting of, PjM, SE, Log, SI and Subject Matter Experts (SMEs) as required.

FRB is responsible to:

• Assess changes to software program for o Advocate priority o Requirements

• Link potential changes to the appropriate system requirement

• Ensure ECPs are generated against valid functional requirements

ERB

The Systems Engineer will establish a Project level ERB. The ERB is chaired by the APdM-E or his designee (SE) with participation from the PjM, Information Assurance Manager (IAM), Logistician, Advocate, Functional Advocate Manager (FAM), CM, Test & Evaluation (T&E), Human System Integration (HSI), SI & SMEs as required. The ERB performs the initial analysis and review of all ECPs supporting documentation.

The ERB ensures:

• The ECP is managed in TFITS CMS ECP Tracker

• Determination of Classification (e.g. Class I or Class II)

• Categorization of Technical/Performance versus Functional requirement

• Level of Effort

• ECP octet level determination

• Proposed System Version Number

• Level SETR required

• Identification of CIs impacted by the ECP

• ECPs impact to the Baseline

• Required operational and procedural changes

CCB

The Project Manager will establish a Project level CCB. The CCB is chaired by the PdM or his designee (PjM) with participation from the SI, PjM, SE, FAM, Logistician, Advocate, IAM, CM, HSI, Finance Manager, Contracts, and SMEs (as needed). The CCB approves all ECPs to the Product baseline configuration. The CCB is to be conducted on an as needed basis but no less than quarterly (as required by the NIST CM-3 DIACAP IA control Security Design and Configuration Control Board (DCCB). Product CCB membership is shown in Table 2-2.

The CCB is composed of technical and administrative representatives who:

• Are identified by function in the CCB Charter and assign alternate representation in their absence

• Review CCB agenda items prior to meeting ECPs and miscellaneous changes

• Advise the CCB Chair for their respective competency

• Provide recommendations for proposed ECPs

• Identify risks associated with proposed ECPs

• When necessary, propose deviations from proposed ECPs

• Modify the currently approved CI’s configuration documentation

2.4 Configuration Management IPT

The CM IPT Charter establishes the CM IPT, which provides administrative and technical support for the CM process and is responsible for supporting the execution of CM activities. The CM IPT will assist the PdM in enforcing rigorous processes for CM activities. The goal is to attain the maximum operational efficiency, performance, and readiness of all CIs for the lowest total life cycle cost. CM IPT responsibilities are delegated by the PdM and APdM-E and include the key activities listed below.

• Configuration Planning and Management

• Configuration Identification

• Configuration Control

• Change Management

• Configuration Status Accounting

(A detailed list of CM activities is documented in the CM IPT Charter.)

CM IPT membership consists of representatives from the competencies and functional areas to ensure cross-functional input into CM related matters. Table 2-3 lists the core TFITS CM IPT members. Refer to TFITS CM IPT Charter for additional information.

Table 2-3: CM IPT Members

CM IPT Members Competency Responsibility Engineering IPT Lead / Chair CM Manager WG Chair/Member CM Analyst Member SE Arch IPT Lead Member SP IPT Lead Member T&E IPT Lead Member Logistics Member IA Manager Member Project Management Member

3. CONFIGURATION IDENTIFICATION

The purpose of identifying CIs is to incrementally establish and maintain a definitive basis for system/application control and status accounting. The software and hardware used to support the development of TFITS or its project applications are the responsibility of the SI and will be under CM control. Identification of CIs includes the selection and determination of configuration documentation required for each CI. New CIs must be identified before applying CM oversight. The decision to apply CM to a CI will be made by the TFITS CfM. In the case of system/application documentation, it will come under CM control after it has been placed on record as a fully reviewed version.

The Configuration Identification process includes:

• Selecting CIs in accordance with the guidance of MIL-HDBK-61A and Section 3.1 Configuration Item Naming Methods

• Determining the types of configuration documentation needed

• Determining the appropriate configuration control activity

• Issuing identifiers for the CIs and the configuration documentation

• Maintaining CIs in the TFITS SharePoint CMS

• Maintaining the configuration of CIs

• Releasing the configuration documentation

• Establishing the configuration baselines for the control of CIs

3.1 Configuration Item Naming Methods

The Configuration Item Identification method employed in TFITS includes a standard naming convention and the SharePoint versioning functionality. The numbering convention is used to uniquely identify CIs, baselines and technical documents. It is created using the Marine Corps Program Code (MCPC), Table of Authorized Material Control Number (TAMCN), CI type and a unique numbering convention. If a TAMCN is not available, the Project identifier may be used.

TFITS documentation shall conform to the document naming conventions established in the TFITS CMP. Document naming conventions may be applied at the Tier I, II & III levels. TFITS Document naming conventions will adhere to the following principals:

• Tier I generated documents: “TFITS_” will precede the document Title

TFITS_SEP

• Tier II generated documents: “TFITS_<MCPC>” will precede the document Title

TFITS_LAIS_PMR

• Tier III generated documents: “TFITS_<MCPC>_<TAMCN/Project name>” will precede the document Title

TFITS_PA_SPS_PMR

TFITS_JFRG_JFRG_PMR

Additionally, to ensure data integrity in the current document tracking tools, documents must contain underscores in place of spaces, and dates must not be used in Document titles. The Document tracking tool (SharePoint) uses Version Management and dates in Document titles, that negates this functionality. When a Configuration Item number is assigned to a CI, it shall not be changed or used to identify another CI.

Table 3-1: Configuration Item Designators

Configuration Item Type Designator

Hardware HW Software SW Document DC Interface IN

3.2 Configuration Item Technical Database

The CITDB is a list consisting of hardware, software, tracelinks, interfaces, and documentation used to identify the system configuration and establish the Product Baseline (PBL). The CITDB captures data integral to HW and SW lifecycle management. The CITDB is a list in SharePoint organized by SVN. CITDB change control is managed through the ECP change management process. The CITDB contains information from Logistics, System Engineering, IA, Finance, Contracting, System Integrator, CM and Project Management. Changes to the CITDB will be submitted by the SI via ECP and accepted into the PBL by the CM Analyst under the supervision of the CfM.

Table 3-2: Configuration Item Technical Database Description

CM Asset Asset Description

Hardware CIs

All operational HW devices that fall within the accreditation boundary) are to be identified, documented and managed at all times during the HW lifecycle. Such as, installation, project transfers (in/out), HW reconfiguration, end of life, refresh and disposal. Hardware within TFITS is Commercial off the Shelf (COTS) products, which are identified by manufacturer, model number and serial/service tag number(s). The hardware CI within a TFITS program may consist of but are not limited to:

• Servers (File, Network, Web, and Database)

• Laptops and handheld devices

• Storage Area Network and/or Blades

• Network Attached Storage, Disk Array and/or Direct Attach Storage

• Load Balancers

• Backup Tape Libraries

• Network Interface Cards and/or Host Bus Adapters (HBA)

• Printers and/or Scanners

• Routers (Network, Proxy and/or Cable, etc.)

• Firewalls and/or Modems

• Switches and/or Ports.

The TFITS HW CITDB and the required data elements will be used to establish and manage hardware configuration baselines and assigned

Configuration Item Numbering. The SI will support and use the PBL in the HW CITDB under the supervision and guidance of the CfM and

Program Management Office CM Analyst.

Software CIs

All operating systems, database and applications installed within the accreditation boundary will be managed to the fourth octet for all major, minor, maintenance, and patch versions. Software used to support TFITS Projects is to be identified, documented and managed through the

CITDB. Key configuration data to capture and maintain is defined in the software CITDB. Software CI (CSCI) upgrades will require an ECP submitted for review and approval by the ERB and CCB prior to implementation. The Software Versioning Schema can be found in

Appendix C.

CSCIs are the programs and other operating information used by a computer such as Oracle, Microsoft, Red Hat, and project system applications.

Source code may be delivered by the SI in physical assets such as, DVD or CD. These media will be stored in the TFITS approved safe. Each project should define the souce code safe handling and retention procedure in the Project Level CMP.

Hostname Configuration

Host Configuration provides the cross reference of the Hardware Configuration Items (HWCIs) and CSCIs such as a server running Red

Hat Interface CIs identify inbound and outbound relationships with external systems such as a database sending or receiving information to another database.

Interfaces

Interfaces are composed of system elements, and may operate as part of larger systems of systems. The design, definition and management of the physical and logical interfaces, both internal (communications between system elements) and external (communications between the system and other systems), are critical to program success.

Documentation CIs

Documentation CIs are the documented description of the system and its supporting activities such as SEP, CMP, System Design Description, User Manual, etc.

The documentation used to support the system/application must be identified and controlled when establishing each of the baselines identified in Table 3-3.

TFITS, in concert with the SI, is responsible for identifying and managing all document CIs.

Table 7-1 Identifies the TFITS Required Technical Documents

Note: Appendix B contains the CITDB data dictionary. The CITDB continues to evolve, and therefore, changes to the data dictionary may occur. The TFITS PdMO will maintain the CITDB data dictionary as a stand-alone document and maintain configuration control over this document.

3.3 Configuration Baselines

A baseline is a logical grouping of CIs that constitute a system. Baselines provide a fixed reference to specify the CIs at a particular milestone event or point in time. A baseline establishes an approved standard upon which subsequent work can be accomplished. Refer to Table 3-3 for specific types of baselines. After the Product baseline is established, changes to the baseline can only be made through a formal change request. All change requests will be submitted as ECPs via the ChM process.

Details on the relationships between the system requirements baseline and the product baseline, including the logical elements that comprise those baselines, are included in the Requirements Management Plan.

Table 3-3: Configuration Baselines

Baseline Description

FBL

The Functional Baseline (FBL) is the initially approved baseline describing the functional and performance requirements for a capability. The following elements are required:

• Validation and verification that functional and performance requirements are met

• Government approval of the Software Requirements Specification

(SRS)/Software Requirements Description (SRD) constitutes the establishment of the FBL

• SI manages the established FBL until creation of the PBL

• Prior to each SETR the SI shall provide the SRS/SRD and update the

Requirements Traceability Matrix (RTM)

ABL

The Allocated Baseline (ABL) describes the allocation of the functional and performance requirements within the design constraints of the system and subsystems.

ABL is approved and controlled by the Government at PDR. The prime supplier maintains the ABL, as applicable. Each ABL consists of:

• Approved performance and design documentation defining the development of a

CI

• SI provides and updates the following documentation 30 days prior to PDR o SRS/SRD, Software Design Description o System/Subsystem Design Document o CI level performance specifications o Interface Design Description o Software Architecture Description o RTM o Work Breakdown Structure

• SI manages the established ABL until creation of the PBL For COTS/NDI systems, an Allocated baseline is not required; however, it is recommended that the requirements traceability matrix trace the CI to the requirements in the system level specification.

PBL

The PBL is the approved configuration of a system established at the CDR and verified at the PCA. The PBL is managed by the PjM. The PBL is documented by the following CIs recorded in the Project’s CITDB:

• Hardware

• Software

• Tracelinks

• Interfaces

• Documentation

• ECPs

4. CHANGE MANAGEMENT

Change Management is the formal process used to track changes to any approved baseline configuration throughout the lifecycle of a program. Change Management includes the systematic evaluation of changes through the Change Management process. Proposal, justification, evaluation, coordination, disposition of proposed changes and the implementation of all approved and released changes. TFITS manages change to project configuration baselines through the FRB, ERB and the CCB. These boards prepare, justify, evaluate, coordinate, adjudicate, and implement Class I and Class II ECPs and baselined configuration documentation.

All changes shall be evaluated for correctness and related impacts, and if approved, prioritized and scheduled for implementation.

4.1 ECP

An ECP is the method of tracking change to a product baseline. An ECP is generated when a change is required to fix a deficiency or to change functionality of a system requirement. ECPs are classified as Class I or Class II according to the criteria outlined in sections 4.1.1 and 4.1.2.

The TFITS PjM and SE ensure the TFITS ECP tracker is used and up-to-date. However, the SI may be tasked to create and maintain the ECP through its lifecycle.

INPUTS

FRB, Help Desk, FAM, etc.

Create ERB CCB SETR Release Closed

Inputs

Figure 4-1: Simplified TFITS ECP Process

4.1.1 Class I ECP

A classification (Class) I ECP represents an engineering change that impacts system form, fit and function. Class I changes must be reviewed and approved by the ERB and CCB. Class I ECP criteria, as outlined in MIL-HDBK-61A Military Handbook, Configuration Management Guidance, are as follows:

Examples of Class I ECPs include:

• A system change driven by changes in capabilities with formal requirements documents from the capabilities sponsor. (Statement of Need, Capability Development Document, Capability Production Document, Urgent Need Statement)

• A significant change to form, fit or function driven by enhancement or multiple hardware and/or software upgrades

• Change driven by limited enhancements or a hardware/ software refresh or a fix driven by defect/bug or underlying security vulnerability. (E.g. Information Assurance Vulnerability Alerts (IAVA))

4.1.2 Class II ECP

Class II ECPs are changes that do not affect form, fit, function, interoperability, or interchangeability and provide minimal to no impact on any controlled documentation under configuration control. Class II changes must be reviewed and approved by the ERB and CCB (Virtual ERB and CCB are acceptable means for reviewing and approving 4th octet changes).

Class II ECP criteria, as outlined in MIL-HDBK-61A Military Handbook, Configuration Management Guidance, are as follows:

Examples of Class II ECPs include:

• Corrections to code which do not affect form, fit, or function

• A defect, or bug, but does not constitute a measurable change or enhancement

• IAVA, Operational Directives, Marine Corps Directives

• Proposed changes to the approved configuration documentation, which has been included in the contract or statement of work by the tasking activity, and is not a Class I.

IAVA messages (security/maintenance patches) are generated when a vulnerability to an application or system exists that poses an immediate and significant threat to Department of Defense information systems. The TFITS PjM will respond to all IAVA notifications in accordance with the timeline specified in the IAVA. IAVAs must be created as ECPs and implemented in accordance with the change management process. This requires ECPs to be sent to the ERB and CCB prior to implementation. To accommodate rapid deployment of time sensitive IAVA ECPs, ERBs, and CCBs may be held virtually/via email and the output captured and recorded as CIs in the TFITS CMS tool.

4.2 Action Item

An Action Item (AI) is a method for tracking taskings assigned to an individual. AIs are generated as a result of ERBs, CCBs, audits as well as other Project Activities. Open AIs related to CM activities are required to be completed prior to approval of the respective activity.

5. VERSION MANAGEMENT

5.1 System Versioning

TFITS has implemented an octet based System Versioning Schema that identifies incremental changes in the approved configuration of a system. The SVN is applied to a Configuration Item that represents a system and is used to identify the Product baseline. Changes to the baselined configuration are accomplished through the ECPs process. At ERB, the SE identifies the octet level (e.g. Octet level 1, 2, 3, or 4) of each ECP based on the complexity of change (To identify the criteria for determining octet levels refer to Appendix C – System Versioning Schema). The CCB groups ECPs into release packages identified by the SVN. The SVN increments based on the octet level of ECPs included in a release. If ECPs of varying octets are included in the same release, the SVN will reflect the highest octet ECP within the release package. (Example: SVN

1.0.0.0 is being modified by 3 ECPs: two 3rd octets and one 2nd octet ECP, hence the SVN will change to 1.1.0.0). Releases may be tracked by unique name or SVN. Once a release package has been approved at PRR the SVN must be used to track the release in production.

5.2 Document Versioning

All digital (electronic) TFITS project and program documentation used to support the system, application or managerial functions should be identified, managed and controlled with the establishment of baseline identifiers to ensure effective data management. Digital data is defined as any information prepared by electronic means and made available to TFITS staff by electronic data access, interchange, transfer, or on electronic/magnetic media. Handwritten notes do not apply and shall not be accepted as product data.

Document versioning is a function of the document libraries as defined in the TFITS SharePoint portal libraries. All unapproved (unsigned) working document revisions are tracked in the Project working document libraries by incrementing the second (2nd) integer changes (minor version: e.g. 1.1, 1.2, 1.3, etc.). Approved and Signed document versions are identified by incrementing the First integer (Major version: e.g. 1.0, 2.0, etc.) during document check-in to the TFITS CMS. Approved and Signed documents are controlled in the TFITS Published Library.

To transfer approved and signed working documents to the TFITS Published library, the document metadata tag named “Published?” must be selected. The CMS auto-copies the approved version into the TFITS Published Library. The published document librarian is notified to review the metadata associated with the document. Once approved by the librarian, the document becomes available in the TFITS Published Library.

Table 5-1: Document Versioning Example

Document Name Version Version Status Location

TFITS_Configuration_Management_Plan 1.0 Published Document

TFITS

Published Library

TFITS_Configuration_Management_Plan 1.1 Working Document Project Working

Library

TFITS_Configuration_Management_Plan 1.2 Working Document Project Working

Library

TFITS_Configuration_Management_Plan 1.3 Working Document Project Working

Library

TFITS_Configuration_Management_Plan 2.0 Published Document

TFITS

Published Library

Additional information on document versioning and related metadata tracking can be found in the “TFITS Site Collection Knowledge Management Plan” located on the TFITS CMS.

6. CONFIGURATION STATUS ACCOUNTING

CSA is the mechanism used to capture the evolution of baselines and maintain written agreements and approvals. CSA is the administrative tracking and reporting of all formally identified and controlled CIs. It includes the maintenance of records required to support configuration auditing. Status accounting encompasses recording and reporting the following:

• The versions of the products that exist in each baseline

• The justifications, descriptions of changes and approvals by the appropriate parties for any baseline changes

• The status of the technical and administrative documentation associated with the program and each baseline

• Any discrepancies discovered during a configuration audits

• Closure and archive status

• CITDB status and revision

• Reports identifying the trends of reported issues

Required configuration status accounting data will be recorded, maintained and reported via the TFITS SharePoint CMS. All of this information will be available to provide users with a complete description of the status of every CI throughout a system’s/application’s lifecycle.

6.1 Configuration Status Documents and Reports

Configuration status documents and reports are continually maintained to provide up–to–date information relative to each baseline and the trends of CIs within the baseline. The engineering definition data is accumulated as soon as the drawings, specifications, interface documents, etc.

are issued for a given CI and entered into the CITDB. Configuration definition lists are updated from issued documents and approved ECPs.

7. CONFIGURATION AUDIT

Initial Configuration audits, conducted via PCAs, determine to what extent the as-designed/as-tested/as-built product reflects the required physical and functional characteristics specified in the requirements. Continuous reviews are performed to ensure that CIs have been correctly identified and updated for each release. System Verification Review and PRR are combined events and conducted prior to a new version release or system enhancement. PVT is performed upon the release in support of PIR.

Self-audits may be directed at any time deemed necessary to maintain configuration identification integrity or to determine that the actual as-built configuration complies with the documented baseline. Criteria that may necessitate a self-audit is when a Project is found to be out of compliance with a particular CM activity (e.g. ECP Tracker is out of date, ERB/CCBs not conducted quarterly, etc.)

7.1 Technical Documentation

There are many documents produced during the lifecycle of a system/application. As documentation applies to TFITS-Managed Projects, the documents listed in Table 7-1 are required to fulfil the Product baseline. Required project documentation developed by a contractor/vendor will be formally delivered via the CDRL process. Required program documents developed by the Government will be internally approved. All required documents will be published in the TFITS Published Library and baselined through the CITDB Tracker.

Program documents are documents produced at the TFITS PdMO level. These documents provide projects with guidance from the Tier I level. Examples of Program documents can be found in Table 7-1 Required Technical Documentation.

Project documents are documents produced at the individual project level. These documents provide information about the specific project or system the project manages. Examples of project documents can be found in Table 7-1 Required Technical Documentation.

Table 7-1: Required Technical Documentation

Program Level Documents Project Level Documents G Performance Measurement Plan SI System Maintenance Manual G Risk Management Plan SI System Admin Manual G Configuration Management Plan SI User Manual G Requirements Management Plan SI Training G System Engineering Plan SI System/Subsystem Design Description G System Test & Evaluation Strategy SI Version Description Document G Integrated Master Schedule SI Software Architecture

SI Software Acquisition Management Plan G/SI Requirements Traceability Matrix G/SI HW/SW Checklist (CITDB) SI System Design Specification SI Software Requirements Description SI Software Development Plan SI Software Build Plan

G/SI Government Acceptance Test Plan SI Software Test Plan SI Software Test Scripts & Cases

G/SI Test Report and Defects G/SI Lifecycle Sustainment Plan

G Engineering Infrastructure Overview

(MCEITS)

G Service Level Agreement (MCEITS) G = Government Produced SI = SI/Vendor Produced

7.2 Physical Configuration Audits

The Physical Configuration Audit (PCA) is tailored for TFITS and will verify that the product to be delivered is identical to the product that has been tested and verified. PCAs will ensure that the CIs submitted for audit accurately represent the “as-built” product.

Items to be reviewed may include, but are not limited to:

• Final documentation supporting the current system configuration (SEP, LCMPs etc.)

• CSA amplifying information for each CI

• CITDB (HW,SW, Interfaces, Tracelinks, Documentation)

• Final versions of drawings/diagrams

• ECP Tracker

• Final training documentation and packages

• Final test results

• Software code validation (Retina Scans etc.)

• Final Version Description Documentation

• Virtualized Hardware

Audits of the physical hardware will start with baseline configurations. A snapshot of this information with all applications, hardware drivers and operating system updates when the machine was built will be the starting point. The TFITS SharePoint CMS will be the source of record for this information. Likewise, the TFITS SharePoint CMS will control documentation about the upgrades, operating system patches, antivirus and software code updates; hardware changes, such as hard drive replacement, partition changes, additional memory installed, and motherboard replacement and real-time inventory.

7.3 Configuration Management Quality Assurance

CM self-audits assist in the implementation of TFITS CM Quality Assurance (QA). Self-audits involve periodic reviews of the structure and facilities of the CM information system and libraries to verify that the contents are correct and complete. These informal audits are conducted to assess whether CM processes are being followed as prescribed. The purpose is to verify that the current baseline is consistent with the perceived status of the baseline. The CfM and CM Analyst will conduct the audit by comparing the documentation, hardware, and software with the established baseline. The internal CM process audit will be planned and agreed to in advance. The CfM and CM Analyst will document the results of the audit in a Health Assessment report submitted to the APdM-E. A copy will be retained in the TFITS CMS.

Government ‘Walkthroughs’ provide another mechanism to implement CM QA. These events are intended to be “spot-checks” on deliverables resulting from CM related activities, such as configuration audits and inventory actions. For example, the TFITS SE or CfM may walk through an environment where CIs are located and check for any obvious inconsistencies with the documented baseline.

A-1

FOR OFFICIAL USE ONLY

Appendix A Acronym List 1

ACRONYM DEFINITION

ABL Allocated Baseline AI Action Item APdM-E Assistant Product Manager - Engineer CCB Configuration Change Board CDR Critical Design Review CDRL Contract Data Requirements List ChM Change Management CI Configuration Item CITDB Configuration Item Technical Database CM Configuration Management CfM Configuration Manager CMP Configuration Management Plan CMS Configuration Management System COTS Commercial off-the-Shelf CSA Configuration Status Accounting CSCI Computer Software Configuration Item CV&A Configuration Verification and Audit DCCB Security Design and…