Exhibit_3b_TFITS_CMP.pdf

FOR OFFICIAL USE ONLY

CONFIGURATION MANAGEMENT PLAN (CMP)

TOTAL FORCE INFORMATION TECHNOLOGY

SYSTEMS (TFITS)

Version 1.0

Prepared by:

Prepared by:

MARINE CORPS SYSTEMS COMMAND

Total Force Information Technology Systems (TFITS) Information Systems & Infrastructure

Quantico, Virginia 22134

TFITSDC0001 TFITS CMP March 08, 2013 ii

SIGNATURE PAGE

CONFIGURATION MANAGEMENT PLAN (CMP)

TECHNICAL REVIEW:

Mr. Andrew Mittura Assistant Product Manager – Engineer PM10 IS&I, APdM-E TFITS Marine Corps Systems Command

CONCURRENCE:

Mr. Tony Brill Deputy Product Manager PM10 IS&I, DPdM TFITS

APPROVED BY:

Mr. William Sandlin Product Manager (PdM) PM10 IS&I, APdM TFITS iii

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 Configuration Management Plan (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 (ANSI/EIA) 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 Control Board (CCB) operations, Configuration Status Accounting (CSA), and Configuration Verification and Audit (CV&A).

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

RECORD OF CHANGE HISTORY

Version Number

Date Figure, Table or Paragraph

Number *A, M, D Title of Brief Description Change Request

Number

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

Questions concerning this Configuration Management Plan should be referred to:

• Andrew Mittura, TFITS APdM-E, 703-784-4740, Andrew.Mittura@usmc.mil

• Tony Brill, TFITS Deputy PdM, 703-784-4865, Tony.Brill@usmc.mil

• William (Pete) Sandlin, TFITS PdM, Chairman, 571-247-4482, william.sandlin@usmc.mil mailto:Andrew.Mittura@usmc.mil mailto:Tony.Brill@usmc.mil v

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 Control Board (CCB)

2.3 Engineering Review Board

2.4 Functional Review Board

2.5 Relationship of TFITS IPTs to CM

3. TOOLS AND RESOURCES

4. CONFIGURATION IDENTIFICATION

4.1 Configuration Baselines

4.2 Identification Methods

4.3 Software Configuration Identification

4.4 Documentation Management

5. CHANGE MANAGEMENT

5.1 Engineering Change Proposal (ECP)

5.2 Configuration Change management Process

5.3 System Release Versioning and IA Considerations

6. CONFIGURATION STATUS ACCOUNTING (CSA)

6.1 Configuration Status Documents and Reports

6.2 Hardware Control Accounting

6.3 Requirements Traceability Matrix (RTM) and Specifications Database

7. CONFIGURATION AUDIT

7.1 System Verification Review combined with Production Readiness Review

7.2 Physical Configuration Audits (PCAs)

7.3 Configuration Management Quality Assurance (QA)

8. DATA MANAGEMENT

8.1 Data Management Process

8.2 Document Revision Status Levels

8.3 Data Identification

8.4 Data Management Library Administration

Appendix A Acronym List ................................................................................................... A-1 Appendix B TFITS CITDB Data Dictionary ......................................................................B-1 Appendix C IA Implications of Software Version Changes ............................................. C-1 Appendix D ECP Workflow Process ................................................................................... D-1 Appendix E CCB Charter .....................................................................................................E-1 vi

Table of Figures

Figure 4-1: CI Data Model Figure 5-1: System Versioning Scheme for IA Figure 8-1: Data Management Process

Figure D-1: TFITS Change Process ........................................................................................... D-1

List of Tables

Table 1-1: TFITS Managed Projects Governed by this CMP Table 2-1: TFITS Product CCB Membership Table 2-2: Relation of TFITS Working Groups to CM Table 2-3: CM IPT Members Table 3-1: CMS Functions Table 4-1: Configuration Item Designators

Table C- 1: IA Implications of Software Version Changes ....................................................... C-1

1. Introduction This Configuration Management Plan (CMP) has been developed to set out the processes that the Total Force Information Technology Systems (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 of the TFITS projects. The intended audience for this document is the TFITS Product Management Office (PdMO), its supporting agencies, and TFITS Development Contractors (hereafter referred to as Systems Integrators (SIs). It also applies to TFITS Integrated Product Teams (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 CM 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

Configuration Management (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 to a system can be uniquely identified and managed. The TFITS Product Manager (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.

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 Configuration Item (CI) baselines o Assuring an organized, traceable, and verifiable process by which Configuration

CIs may be implemented o Ensuring all changes are properly 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 Change Control

Board, process as required

• To coordinate the Government and System Integrator CM processes

• To 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

• To provide a complete audit trail of decisions and design modifications

• To provide accurate Configuration Status Accounting (CSA) and Configuration

Verification & Audit reports (CV&A)

• To perform Functional and Physical Configuration Audits

• To archive approved baseline documents, such as requirements, specifications, designs, drawings and diagrams

• To manage TFITS logistics CIs

• To address Information Assurance (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 the Managed systems listed in Table 1-1.

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

Project Name Acronym Automated Manifest System-Tactical AMS TAC Active Radio Frequency Identification aRFID Automated Tool Inventory Control and Tracking System ATICTS Joint Force Requirements Generator II JFRG II MAGTF Deployment Support System II MDSS II Passive Radio Frequency Identification pRFID Defense Readiness Reporting System- Marine Corps DRRS-MC Marine Corps Recruiting Information Support System MCRISS

Manpower Mobilization Assignment System MMAS Web Based Manpower Assignment Support System Web MASS Manpower Models MODELS Paperless Acquisition PA Systems Purchase Request Builder PR Builder Standard Procurement System SPS Total Force Data Warehouse TFDW Automated Performance Evaluation System APES Total Force Retention System TFRS Performance Evaluation System PES Optical Digital Imaging-Records Management System ODI-RMS Defense Messaging System DMS Drill Management Module DMM Marine Corps Training Information Management System MCTIMS Theater Medical Information Program-Maritime TMIP Joint Engineering Data Management Information and Control Systems JEDMICS Joint Configuration Management Information System JCMIS Secure Personnel Accountability SPA

1.4 REFERENCE DOCUMENTS

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

1.4.1 Standards

Department of Defense:

• MIL-STD-881: Work Breakdown Structures for Defense Material Items

Government and Industry:

• Government Electronics Information & Technology Association Handbook (GEIA-HB)

649B: Implementation Guide for Configuration Management

• Tech America Electronics Industries Alliance (EIA)-649-B: National Consensus Standard for

Configuration Management

• ANSI/TIA/EIA-606 Administration Standard for the Telecommunications Infrastructure of

Commercial Buildings

1.4.2 Instructions and Directives

Department of Defense:

• Department of Defense Directive 5000.1

• Department of Defense Instruction (DoDI) 5000.02, Operation of the Defense Acquisition

System

1.4.3 Handbook/Guidelines

Department of Defense:

• Military Handbook (MIL-HDBK)-61A: Configuration Management Guidance

Marine Corps Systems Command:

• MCO 4130.1 - Marine Corps Systems Command Configuration Management Policy

• TFITS Systems Engineering Plan

• TFITS Versioning Policy Letter 3-11

• TFITS Interim Policy Letter 1-11

2. PLANNING AND MANAGEMENT

The TFITS CM program is initiated through this CMP by the Product Manager (PdM) for TFITS to fulfill the requirements of MCSCO 4130.1, Configuration Management Policy. The Integrated Process and Product Development (IPPD) 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 mandatory 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.

MIL-HDBK-61A guidance was used to establish the TFITS CM processes and procedures documented in this CMP. Any modification to or deviation from any of these approved CMP processes or procedures must be approved by the TFITS CCB.

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. The APDM-E and the DPdM coordinate and concur on all CM process development and delivery, as well as the execution of the CMP.

2.1.1 Product Manager (PdM)

The PdM TFITS is the chairman of the CCB and is responsible for fulfilling the requirements of MCSCO 4130.1, Configuration Management Policy to establish the CM approach, control product attributes, and manage the technical baseline across the total system life cycle. PdM TFITS is responsible for the review and approval of Class I change requests. However, the PdM may delegate his/her authority to the PjM as appropriate. At the completion of the system level Critical Design Review (CDR), the PdM assumes control of the initial product baseline for all Class 1 configuration changes.

2.1.2 Deputy Product Manager (DPdM)

The DPdM is responsible for the oversight and management of the TFITS’ projects production baseline and execution. To facilitate the performance of those duties, the DPdM participates as a member of the CCB and Tier 1 IPT. The DPdM coordinates all requests for TFITS CM process improvement activities through the T1 IPT. The DPdM is responsible for adherence to the TFITS CMP. The DPdM provides formal approval of the release (authority delegated from PdM) of Engineering Change Proposals (ECPs) into the production environment.

2.1.3 Assistant Product Manager – Engineer (APdM-E)

The TFITS APdM-E performs the TFITS Change Management (ChM) function charged with overseeing the planning, development and execution of the TFITS CM and engineering efforts.

The APdM-E is accountable for the overall TFITS development and implementation of all CM processes, focusing on the execution of baseline development and delivery. The APdM-E Chairs the TFITS Engineering Review Board (ERB) which is established by the System Engineering Plan (SEP). The purpose of the ERB is to ensure proper review, analysis and classification, and quality control of all engineering change requests.

The APdM-E is responsible for the following tasks:

• Development and maintenance of CM related documentation, such as the CMP and change reports

• Establishment and revision of TFITS level configuration baseline documentation

• Participating in technical reviews and audits

• The development and implementation of new technical approaches to existing processes, products, and operational concepts

• Defining the version of the change to be made and ensuring that product baselines are maintained. The version determination shall be in accordance with the PdM TFITS versioning policy established in the SEP.

• Adherence to CM activities to include the administrative and technical support for the CM processes.

• Planning, executing, and chairing TFITS CM IPTs and meetings

• Participating in any meetings where proposed baseline changes are discussed

• Supporting configuration audits and conducting configuration self-audits and SI audits

2.1.4 Project Manager (PjM)

With input from the CfM, the PjM executes rigorous processes for CM activities, such as configuration identification as well as control, accounting, verification, and audit of their individual Project CIs. The PjM’s goal is to attain the maximum operational efficiency, performance, and readiness of all individual Project CIs for the lowest total life cycle cost. The PjM ensures their project has a clear understanding of CM related products and standard procedures.

In addition to the execution of the CM efforts outlined in this CMP, the PjM is responsible for the following tasks:

• Planning, executing, and facilitating project CCB meetings

• Participating in any meetings where proposed baseline changes are discussed

• Coordinating and scheduling events related to baseline changes

• Managing the execution of CCB approved ECPs

2.1.5 Systems Engineer (SE)

Within individual projects, the SE is accountable for the development and implementation of all CM processes, focusing on the execution of baseline development and delivery.

The SE is responsible for:

• CM of requirements, specifications, drawings, diagrams, standard operating procedures (SOPs), and lists of required technical standards and documentation

• Establishment and revision of project level configuration baseline documentation

• Participating in technical reviews and audits

• Supporting the APdM-E in all CM and engineering activities in accordance with the

TFITS SEP and TFITS CMP

2.1.6 Configuration Manager (CfM)

The APDM-E will be the Configuration Manager (CfM) for TFITS’ project level baselines. The CfM will enforce the rigorous processes for the basic CM activities of configuration identification, configuration control, status accounting and auditing to attain maximum operational efficiency and performance, lowest total lifecycle cost, and readiness of TFITS Managed project CIs.

In addition to managing the CM efforts outlined in this CMP, the CfM is responsible for the following tasks:

• Participating in the TFITS Configuration Management IPT meetings

• Participating in all CCB meetings

2.1.7 Requirements Manager (REQM)

The TFITS Requirements Manager (REQM) is responsible for managing requirements for the TFITS program. The REQM provides the configuration control focus for requirements and interfaces with the project advocate representatives. In addition, the REQM works with the CfM, the PjM and the SI throughout the TFITS life cycle. The REQM participates in the ERB, the CCB and CM IPT. The REQMP provides additional details of the REQM responsibilities.

2.1.8 Configuration Management Analyst

The CfM Analyst is a member of the PdMO CM staff and supports the daily management and accounting of Government data and CIs for individual projects under TFITS. The CfM Analyst reports directly to the CfM in the execution of the CfM activities and provides support to the PjMs.

In addition, the CfM Analyst is responsible for the following tasks:

• Controlling, maintaining, and managing the Configuration Item Technical Database (CITDB) and its CIs

• Controlling and maintaining all CM products and procedures, including all baseline software source and object code databases along with configuration documentation

• Managing and maintaining project documentation with a focus on configuration control

• Coordinating technical writing for CM products and procedures

• Defining product configuration for testing, readiness reviews, formal reviews, shipment readiness, installation readiness, and final baseline acceptance

• Documenting the dispositions of and maintaining records for all ECPs

• Disseminating reports for the purposes of CSA and CV&A

• Coordinate with the logistics lead to capture and maintain logistics information

2.1.9 CCB Members

CCB members will review all changes and agenda items presented. CCB members will act as voting members (unless otherwise noted), sources of information, and advisors to the CCB Chair. CCB members will identify alternate members, identified by name or function in the Project CCB Charter, who will attend CCB meetings in their absence. CCB members may vote by proxy through their alternate members.

2.2 Configuration Control Board (CCB)

The CCB has been established as the highest configuration control authority for the TFITS program and controls all critical changes to the baseline configuration that require additional funding. The TFITS PdM will establish and chair the CCB. However, the PdM may designate his/her authority to the DPdM to chair the CCB as appropriate. The CCB is a group of people composed of technical and administrative representatives who determine approval or disapproval of proposed engineering changes to, and proposed deviations from, a CI’s current approved configuration documentation. The CCB will review ECPs and Requests for Deviation/Waiver (RFD/RFW) on no less than a quarterly basis. All CCB voting members (denoted with “*” in Table 2-1) will formally provide recommendation for concurrence, rejection, or deferment of proposed changes to the CCB Chair who has final approval authority for all Class I ECPs.

The CCB shall be planned, organized and conducted in accordance with the TFITS CCB Charter (Appendix F). An example of the Product CCB membership is shown in Table 2-1.

Table 2-1: TFITS Product CCB Membership

Function Member CCB Chair PdM TFITS *Configuration Manager (CfM) APdM-E

*CCB Member Information Assurance Manager

(IAM)

*CCB Member Logistician *CCB Member Financial Manager *CCB Member PjM

*CCB Member Combat Development & Integration

(CD&I)

CCB Member (non-voting) Selected SMEs as needed CCB Member (non-voting) Vendor

CCB Member Functional Area Manager/User community

2.3 Engineering Review Board

The ERB is chaired by the APdM-E/ChM or his designee with participation from the SI. The ERB performs an initial technical analysis and reviews the ECPs and its supporting documentation for the following:

• Completeness of the requirement/request

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

• Categorization of Technical/Performance versus Functional requirement

• Level of Effort

• Justification for the change

• Impact, relationship to other CI

• Operational and procedural changes that will be required

• Impact to the baseline

• Level SETR required

The result of the ERB activity will result in the ECPs workflow for escalation into the CCB (Class I ECPs) or Forward Schedule of Change (FSC) on Class II ECPs.

2.4 Functional Review Board

Advocates will establish and chair Project level FRBs. The FRB is a group of people composed of the Advocate, project office, the SI and other SME representatives who determine Priority and Urgency of proposed engineering changes. The FRB is established, pre ERB and is responsible for reviewing all changes to software or hardware baselines to assess the desirability of implementing changes based on current priority, urgency, funding and requirements. The FRB is responsible for linking potential changes to the appropriate system requirement to ensure ECPs are generated against legitimate functional requirements. FRBs will assign the ECP Priority and Urgency required for promotion to the next release cycle.

2.5 Relationship of TFITS IPTs to CM

Each TFITS IPT provides assistance to the PdM and PjM and ensures a clear understanding of CM related products and standard procedures. Also, the IPTs are responsible for evaluating, identifying, and tracking relevant CM related issues according to Table 2. All IPTs coordinate with the CM IPT on their CM related issues. IPT membership consists of representatives from the PdMO and SI as well as SMEs.

The TFITS SEP provides additional information and a description of each IPT identified in Table 2-2.

Table 2-2: Relation of TFITS IPTs to CM

IPT Name CM Responsibilities

Tier 1 IPT Responsible for oversight and execution of

CM activities at the Product Manager level Tier 2 IPT Responsible for oversight and execution of

CM activities Project Manager level Configuration Management IPT

(CM IPT)

Responsible for CM execution activities

Systems Engineering IPT

(SE IPT)

Identification and coordination of development efforts and engineering baselines

Logistics IPT

Identification and coordination of CM related logistics, asset status tracking and accounting, maintenance planning, resource and training

Test & Evaluation (T&E) IPT

(T&E IPT)

Identification of CI and T&E change status accounting coordination

Information Assurance (IA) IPT

(IA IPT

Assessment of IA related changes with their impact to the baseline configuration

Sustainment and Modernization IPT Identification of Production changes and coordination of those changes

Architecture and Interface IPT Identification and management of TFITS architecture and interfaces changes

2.5.1 Configuration Management IPT

The CM IPT 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, such as configuration identification and control as well as CSA and CV&A. The goal is to attain the maximum operational efficiency, performance, and readiness of all CIs for the lowest total life cycle cost.

The CM IPT responsibilities include, but are not limited to:

• Providing support to the CCB, including subject matter expertise on CM

• Documenting reviews of the proposed change within the TFITS CMP

• Establishing and implementing the configuration identification process

• Ensuring that CI baselines are established, controlled, and maintained using technical and administrative techniques, which include the development of documents that formally identify and establish those baselines

• Ensuring that configuration deliverables and test software, hardware, firmware, data, and databases are established, controlled, and maintained

• Managing and implementing the software, hardware, database, and documentation change process

• Recording the baseline configuration as used in the development, training, and production environments

• Performing configuration audits and reviews on items such as the SI library and historical archives

• Providing an optimum degree of uniformity in policy, procedures, documentation, and reports for TFITS CM

• Collecting and analyzing CM metrics

• Maintaining as designed, as built, and as maintained baselines

CM IPT membership consists of representatives from the various functional areas to ensure cross-functional input into CM related matters. Table 2-3 lists the core TFITS CM IPT members.

Table 2-3: CM IPT Members

Members from TFITS TFITS APdM - E System Engineers Project Managers TFITS Logistician TFITS IA Officer TFITS/Project CM SMEs

3. TOOLS AND RESOURCES

The TFITS program will use the SharePoint Portal for its Configuration Management System (CMS) to control and manage the CIs.

The CMS functionality includes management and control of the following:

Table 3-1: CMS Functions

Function Description

CCB calendar Provides an aggregate view of project level CCB schedule

CITDB Provides the management, and control of projects CSCIs, HWCIs, Documentation and Interfaces

Documentation Repository for project and product documentation CIs

ECP Provide the management, accounting, and control of project ECPs

Requirements Provides management and control projects Requirements Traceability

Matrices SETR Provides an aggregate view of projects

Systems Engineering Technical Reviews

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.

Appendix B describes 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.

4. 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 the TFITS’ or its project applications are the responsibility of the SI and will be under the control of the CfM. 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 using the guidance of MIL-HDBK-61A, Section 5.3.2 and Activity Guide:

Table 5-2

• 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 SharePoint CMS

• Maintaining the identification of CIs

• Releasing the configuration documentation

• Establishing the configuration baselines for the control of CIs

4.1 Configuration Baselines

A baseline is a logical grouping of configuration items that constitute the system. Baselines provide a fixed reference to specify the configuration items at a particular milestone event or point in time. A baseline establishes an approved standard upon which subsequent work can be made. After the Product baseline is established, changes to the baseline can only be performed through a formal request for change process. All change requests will be submitted as Engineering Change Proposals (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 REQMP. Figure 4-1 provides the TFITS CI Logical Data Model as an example.

Product BL

Baseline (Functional/Allocated)

Software CI

PK Config ID

Software Name Version Description

Hardware CI

PK Config ID

Manufac Processor Memory (RAM)

CDD/CPD/CONOPS

PK Config ID

Description Treshold Objective

SDS

PK Config ID

Description Threshold Objective

Use/Test Cases

PK Config ID

Description Method Results

Interfaces

PK Config ID

System Name Protocols Inbound/Outbound

SRS/SRD

PK Config ID

Description Treshold Objective

SDD ID

ECP

PK Config ID

Description Class Status

TEMP/STES

PK Config ID

COI

MOP

MOE

MSur

Documentation

PK Config ID

File Name Name Version Date

Version Release

Version Number Description Date Source Codes

Reports

ID

Name Description

Forms

ID

Name Description

Workflow

ID

Name Description

Schemas

Name Description Module

Objects

ID

Name Description

RTM

PK Config ID

Description Treshold Objective

STP

PK Config ID

File Name Version Date

Figure 4-1: CI Data Model

4.1.1 The Functional Baseline (FBL)

The FBL is the initially approved baseline document describing the functional and performance requirements for a capability (or top-level configuration). Validation and verification are required to demonstrate that the functional and performance requirements are met. This baseline plus approved changes constitute the functional baseline and serve as the description of a projects required functional characteristics throughout the system life cycle. Government approval of the Software Requirements Specification (SRS)/Software Requirements Description (SRD) constitutes the establishment of the FBL for each increment of capability. The SI shall manage the FBL for TFITS projects at the conclusion of the System Requirements Review/System Functional Review (SRR/SFR). The SI shall provide the SRS/SRD and the update to the Requirements Traceability Matrix (RTM) prior to each Systems Engineering

Technical Review (SETR). The execution and management process for the FBL is addressed in the REQMP.

4.1.2 Allocated Baseline

The ABL describes the allocation of the functional and performance requirements within the design constraints of the system and subsystems that will implement a capability. Each ABL consists of the allocated configuration documentation, which will be comprised of the current approved performance and design documentation governing the development of a CI. This level of documentation describes the system and subsystem requirements and characteristics and the verification required to demonstrate achievement of those specified characteristics. The SI shall manage the ABL for TFITS projects at the conclusion of the Preliminary Design Review (PDR)/Design Review (DR). The SI shall provide and update the SRS/SRD, Software Design Description, Interface Design Description, Software Architecture Description, RTM, Work Breakdown Structure (WBS), and other related documentation thirty days prior to the PDR. The TFITS SEP provides the notional entry and exit criteria for the PDR/DR. Government control of the ABL is deferred until the Functional Configuration Audit (FCA)/System Verification Review (SVR)/Production Readiness Review (PRR).

4.1.3 Product Baseline

The Product Baseline (PBL) is the approved documentation including the complete set of released and approved engineering design documents including detailed software and hardware CI information, engineering models, interfaces and database design documents for software. The PBL is managed by the PjM. The PBL will be established after contract award at the conclusion of the Critical Design Review (CDR)/DR and verified at the Physical Configuration Audit (PCA) and during the Production Readiness Review (PRR). The Project CITDBs is the CM tool used to manage the PBL. The Government provides the most current System PBLs to the SI as Government Furnished Information (GFI).

4.1.3.1 HWCIs and CSCIs

The hardware and software used to support the system are identified and documented in the CITDB to establish the product configuration baselines and nomenclature for CIs that are primarily Commercial-Off-The-Shelf (COTS) products vendor specifications, such as model or release numbers. The CITDB provides a list of required data elements for hardware and software CIs. The SI shall support and manage the PBL using the CITDB under the supervision and guidance of the CfM and CM Analyst.

4.1.3.2 Document CIs

The SI CMP will include processes and procedures that address documentation control. In support of the PCA, the PBL design and engineering related documentation will include system, network, and wiring diagrams that depict the hardware and software used. In addition, these diagrams will illustrate any connectivity devices, such as hubs, routers, and firewalls. Also, these diagrams should indicate all connections to other systems and/or networks that either flow internally within a project or externally to other organizations through functional and technical interfaces. In order to support the creation of these diagrams, TFITS programs will ensure that every cable termination point is clearly labeled and that the start and end locations of the cable run are documented. The ANSI/TIA/EIA-606 standard, “Administration Standard for the Telecommunications Infrastructure of Commercial Buildings,” will be followed for this effort.

4.1.3.3 Architecture Models and System Interfaces

Architecture models and system interfaces will be documented and controlled through the TFITS CCB process and managed by the Architecture and Interface IPT. Software design documents shall include system interface design and configuration information. System interfaces will be recorded in the CITDB

4.2 Identification Methods

Two considerations are taken into account for CI identification: (1) ensuring unique names, and

(2) a distinguishable version number scheme.

The naming convention used to uniquely identify the CIs, baselines and technical documents that will be placed under CM control is based on the TAMCN and unique sequence number (e.g., A9000HW0001). If a TAMCN is not available, then another uniquely defined number that is formally tracked and sequenced can be used, such as the project acronym (e.g., MDSS, RFID, etc), preceding a uniquely identified number (e.g., RFIDHW0001). When a number is assigned to an item, it shall not be changed, used to identify another item, or used for a different version of that item. This procedure is applied to the following:

• System Architecture. A diagram will be needed to depict the system hardware used and any connectivity devices, (hubs, routers, firewalls). The diagram should indicate all connection to other systems and/or networks that are either internal to TFITS or external to other organizations.

• Hardware. The hardware used to support the system should be identified, documented and controlled when establishing the system/application configuration baselines and nomenclature. At a minimum, the following hardware configuration data shall be collected and maintained: vendor name, model and version number, serial number, date placed in service, warranty status, duration of warranty and build sheets.

• Software. The software used to support the system should be identified, documented and controlled when establishing each of the baselines. At a minimum, the following software configuration data shall be collected and maintained: vendor, software type, software version, date placed in service, number of licenses, duration of licenses and planned end of life/support. For specific software versioning schema, see section 4.3 Software Configuration Identification to this Plan.

• Documentation. The documentation used to support the system/application should be identified and controlled when establishing each of the baselines identified in paragraph

4.1 above.

Table 4-1: Configuration Item Designators

Configuration Item Type Designator Hardware HW Computer Software CS Capabilities Production Document CPD Capabilities Development Document CDD Concept of Operation CON

Ancillary Devices AN Document DC Interface IN System Design Specification SDS

4.3 Software Configuration Identification

Computer Software Configuration Items (CSCI) includes operating systems/application, application software; firmware, databases, source codes, software code objects, hardware drivers, Internetwork Operating Systems (IOS), and any other software components required for operation of TFITS products.

TFITS, in concert with the manufacturer and/or SI, is responsible for identifying and managing CSCI. TFITS will identify CSCI using a unique numbering schema that follows best practices.

For CSCIs, the preferred method is to use the Software Engineering Institute adopted 4 digit schema: major release, minor release, maintenance release and patches (e.g., x.x.x.x). CSCI upgrades to products within TFITS shall be reviewed and approved by the CCB prior to implementation. This versioning schema reflects the TFITS Versioning Policy Letter 3-11.

4.4 Documentation Management

The SI is required to maintain all system lifecycle documentation to keep it current.

While not a comprehensive list, system/application lifecycle documentation includes documents such as:

• Test Scripts & Use Cases

• Software Requirements Description (SRD)

• Software Design Description (SDD)

• User Manuals

• Release Notes

• Source Codes

• System/Network Diagrams

• System Administration Manuals

• Helpdesk Guides

• RTM

• Test Plans

• Others (e.g. Contract Deliverables)

• CITDB

5. CHANGE MANAGEMENT

Change Management is the formal process to track changes to any approved baseline configuration throughout the entire program lifecycle. Change Management includes the systematic proposal, justification, evaluation, coordination, disposition of proposed changes and the implementation of all approved and released changes into (a) the applicable configurations of a product, (b) associated product information, and (c) supporting and interfacing products and their associated product information. The objective of Configuration Change Management is to:

• Ensure effective control of all CIs and their documentation

• Provide effective means for proposing changes, requesting deviations, preparing notices of revisions and preparing change notices

• Ensure engineering changes to CIs are fully coordinated and documented prior to implementation

• Provide accurate configuration identification and interoperability with hardware, and software

5.1 Engineering Change Proposal (ECP)

An Engineering Change Proposal (ECP) is the vehicle that requests a change to a CI within a baseline. An ECP is generated when a change is required to fix a deficiency, add or remove functionality related to a system requirement. ECPs are classified as Class I or Class II according to the criteria outlined in this document.

As part of ECP generation, the SI will conduct the following activities via the ERB to present to the CCB:

• Justification for the change

• CI’s that require modification

• Related CI’s that may be affected

• Operational and procedural changes that will be required

• Level of Effort for the proposed change

5.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 by the 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:

• Affects any physical or functional requirement in approved functional or allocated configuration documentation, and configuration baseline

• Affects any approved functional, allocated, or product configuration baseline and documentation, cost, warranties, or contract milestones

• Add or modify interface or interoperability requirements

• Make a significant and measurable effectiveness change or enhancement in the operational capabilities or logistics supportability of the system or item

• Effect substantial lifecycle cost

• Prevent slippage in an approved production schedule

• Affects approved product configuration documentation and one or more of the following:

o Government furnished equipment, o compatibility, interoperability, or logistic support, o delivered manuals for which changes are not funded

5.1.2 Class II ECP

Class II ECPs are authorized for administrative and documentation changes that do not meet Class I ECP criteria. These changes provide minimal to no impact to any documentation under configuration control, and do not affect form, fit, function, interoperability, or interchangeability (e.g. bug fixes, which result from erroneous operation of the software based on the customer's documented requirements or functional test scripts). 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 (not a measurable change or enhancement) in the operational capabilities

• Information Assurance Vulnerability Alert (IAVA)

• 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 Class I.

5.1.2.1 Implementation Timeline

The implementation timeline for ECP approval by the Government will be determined based on a combination of criticality, severity and priority of the ECP

5.1.2.1.1 ECP Criticality

• Emergency: Assigned when the change is necessary to protect national security; to prevent death, serious injury or extensive damage/destruction of equipment; or to accomplish missions with a system currently experiencing abnormal halts. Emergency ECPs will be presented to the CCB within 48 hours of ECP initiation.

• Urgent: Assigned when the change is required to prevent serious compromises to mission accomplishment; to correct potentially hazardous conditions which may result in serious personal injury or equipment damage; or to meet new regulatory requirements.

Urgent ECPs will be presented to the CCB within 30 days of ECP initiation.

• Routine: Assigned when an “Emergency” or “Urgent” priority is not justified. Routine ECPs will be presented to the CCB within 90 days of ECP initiation

5.1.2.1.2 ECP Priority

Class I ECPs will be prioritized using the following:

• Priority 1: (Critical) System no longer meets mission because business process has changed. Capability change.

• Priority 2: (High) Functional change needed no work around

• Priority 3: (Medium) Functional change with work around

• Priority 4: (Low) Minor change enhancement

5.1.2.1.3 Defect Severity

Class II ECPs will be categorized using the following severity levels.

• Severity 1: (Showstopper) Prevents the accomplishment of an operational or mission essential capability. Jeopardizes safety, security, or other requirement designated “critical”.

• Severity 2: (High) Adversely affects the accomplishment of an operational or mission essential capability and no work-around solution is known. Adversely affects the technical, cost, or schedule risks of the project or the life cycle support of the system.

• Severity 3: (Medium) Adversely affects the accomplishment of an operational or mission essential capability but a work-around solution is known. Adversely affects the technical, cost, or schedule risks of the project or the life cycle support of the system.

• Severity 4: (Low) Results in user/operator inconvenience or annoyance but does not affect a required operational or mission essential capability. Results in inconvenience or annoyance for development or support personnel, but does not prevent the accomplishment of those responsibilities.

• Severity 5: (Other) So minor in its affect that corrective action would cost more than it would be worth. An enhancement not linked to a requirement that has been validated.

5.1.3 Information Assurance Vulnerability Alerts Process

IAVA messages are generated when a vulnerability to an application or system exists that poses an immediate and significant threat to Department of Defense (DoD) information systems. The TFITS PjM will respond to all IAVA notifications in accordance with the timeline specified in the IAVA.

5.1.4 Requests for Deviation (RFD)

A Request for Deviation (RFD) is a specifically written authorization to depart from a particular requirement(s) of a CI’s currently approved configuration documentation for a specific ECP or requirement for a specified period of time. It differs from an engineering change since a deviation does not affect a change to a configuration document. Deviations will be requested by the SI prior to a software release (e.g., software build). However, the deviant CI must be suitable for use. A RFD is submitted if, during the design and development, the contractor determines that, for a valid reason (such as long lead time), a Government required performance attribute will not be met or verified before scheduled delivery.

5.2 Configuration Change management Process

TFITS will manage all changes to project configuration baselines using the FRB, ERB and CCB to prepare, justify, evaluate, coordinate, adjudicate, and implement Class I and Class II ECPs as well as RFDs of effected CIs and baselined configuration documentation. Likewise, supporting documentation requiring PdM signature may be submitted for review to the CCB. All changes shall be evaluated for correctness and related impacts, and if approved, prioritized and scheduled for implementation (See Appendix D for details).

5.3 System Release Versioning and IA Considerations

The incremental system versioning schema will adhere to the guidelines shown in Figure 5-1.

This approach defines the types of changes that affect the various version elements and the IA implications of those changes.

Figure 5-1: System Versioning Scheme for IA

The table in Appendix C describes specific IA actions and level of approval that result from software version changes. Depending upon the type and magnitude of the change, as denoted by the position of the incremented version element, different IA actions are required. These actions range from full re-accreditation for major changes to a program CM review for minor enhancements and bug fixes.

6. CONFIGURATION STATUS ACCOUNTING (CSA)

Status accounting is the mechanism that records how baselines evolve and maintains all written agreements and approvals. It is the administrative tracking and reporting of all configuration items formally identified and controlled. 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

• Drawing and CITDB CI status and revision

• Reports identifying the trends of reported issues

Required configuration status accounting data will be recorded, maintained and reported via the 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.

Major Release Patch ReleaseMaintenance ReleaseMinor Release

Triggers Reaccreditation

Triggers Security Relevant Risk

Reduction Event

Internal Program CM Process

• Increment

Class I ECPs

Class I ECPs

Class II ECPs

CSC Syste e s o g

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.

6.2 Hardware Control Accounting

Individual Projects under the TFITS PdMO are responsible for hardware control and accountability of all Project CIs.