ePS_RFP_Attach_05_Systems_Engineering_Plan_20170214.pdf

FOR OFFICIAL USE ONLY

Systems Engineering Plan

Filename:

ePS SEP v7p0 lp 20160208.doc

Page:

1/74 Version:

Version 1.0

Date of Creation:

9 February 2016

ACAT I AM

Development RFP Release Decision Milestone

Electronic Procurement System Version: 1.0 Date: 9 February 2016

Page:

2/74

PREPARED BY

Peter J. Kassal Date Chief Engineer Navy Enterprise Business Solutions Program Office

SUBMITTED BY

Bruce C. Urbon Date Program Manager Navy Enterprise Business Solutions Program Office

CONCURRENCE

Victor S. Gavin Date Program Executive Officer Enterprise Information Systems

RDML John W. Ailes, U.S. Navy Date Chief Engineer Space and Naval Warfare Systems Command

Dr. John D. Burrow Date Deputy Assistant Secretary of the Navy Research, Development, Test and Evaluation peter.kassal Typewritten Text

09 FEB 2016

peter.kassal Typewritten Text

09 FEB 2016

peter.kassal Typewritten Text

Page:

3/74

APPROVAL

Stephen P. Welby Date Deputy Assistant Secretary of Defense Systems Engineering

Page:

4/74

Document History

Revision Number DATE

Log of Changes Made and Description of Reason

Changes Approved By

1.0 February 2016 Initial Document Bruce Urbon

Page:

5/74

TABLE OF CONTENTS

1 INTRODUCTION 9

1.1 Purpose 9

1.2 Prime Contractor Alignment with ePS 10

1.3 SEP Review and Approval Process 10

1.3.1 SEP Updates

1.3.2 Timeline Summary

1.3.3 Requirements Review Timeline

2 PROGRAM TECHNICAL REQUIREMENTS 13

2.1 System Overview 13

2.2 EPS Architecture and Interface Control 14

2.2.1 DoDAF Efforts

2.2.2 Physical Architecture

2.2.3 Functional Architecture/Requirements

2.2.4 Relating Architecture Products to Requirements Definition

2.2.5 Linkage between Engineering and Architecture Activities

2.2.6 Internal Interface Control

2.2.7 External Interface Control

2.2.8 Requirements Traceability

2.2.9 Linkage between Engineering and Architecture Activities

2.2.10 Internal Interface Control

2.2.11 External Interface Control

2.3 Technical Certifications 21

3 ENGINEERING RESOURCES & MANAGEMENT 22

3.1 Technical Schedule and Schedule Risk Assessment 22

3.1.1 Technical Schedule

3.1.2 Schedule Risk Assessment

3.2 Engineering Resources and Cost/Schedule Reporting 24

3.2.1 Work Breakdown Structure (WBS)

3.3 Technical Risk and Opportunity Management 24

3.3.1 Risk Management Process

3.4 Technical Organization 26

3.4.1 Government Program Office Organization

3.4.2 User Community Representatives

3.4.3 Program Requirements Manager

3.4.4 Program Requirements Analysts/Subject Matter Expert (SMEs)

3.4.5 User and/or Interface IT Organization

3.4.6 Program Manager (PM)

3.4.7 Program Engineers

Page:

6/74

3.4.8 ePS Prime Contractor

3.4.9 Program Office Technical Staffing Levels

3.4.10 Contractor Program Office Organization

3.4.11 Engineering Team Organization and Staffing

3.5 Relationships with External Technical Organizations 35

3.5.1 Management of Interface Control Agreements (ICA)

3.5.2 Interface Control

3.5.3 External Management

3.6 Technical Performance Measures and Metrics 37

3.6.1 Measurement Planning and Metrics Selection Process

3.6.2 System Performance Measures

3.6.3 System Attributes

3.6.4 Cybersecurity

3.6.5 Technical Waivers and Deviations

3.6.6 Software Maturity

3.6.7 Developmental Evaluation Approach

4 TECHNICAL ACTIVITIES AND PRODUCTS 43

4.1 Results of Previous Phase SE Activities 43

4.2 Planned SE Activities for the Next Phase 44

4.3 Requirements Development and Change Process 44

4.3.1 Identify Requirements

4.3.2 Evaluate Requirements

4.3.3 Validate and Prioritize

4.3.4 Obtain Approval and Baseline

4.3.5 Governance of Capabilities Requirements

4.4 Technical Reviews 50

4.4.1 SETR Events

4.4.2 System Requirements Review (SRR)

4.4.3 Build Technical Review (BTR)

4.4.4 Fielding Technical Review (FTR)

4.4.5 Production Readiness Review

4.4.6 Operational Test Readiness Review

4.5 Configuration and Change Management 59

4.5.1 Configuration and Change Management

4.5.2 Configuration Identification

4.5.3 Configuration Management and Change Control Process Description

4.5.4 Configuration Status Accounting

4.5.5 Configuration Verification & Audit

4.6 Design Considerations 62

4.6.1 Reliability and Maintainability Considerations

Page:

7/74

4.6.2 Audit

4.6.3 Commonality

4.6.4 Facility Planning

4.7 Engineering Tools 66

APPENDIX A: Acronyms

APPENDIX B: ePS Risks

APPENDIX C: Reference Documents

Table of Figures Figure 1: ePS Tailored Acquisition Approach Figure 2: ePS High Level scope Figure 3: SV-1 of ePS Figure 4: DON Financial Management Systems Figure 5: Requirements Type Traceability Figure 6: ePS Program Schedule Figure 7: Risk Impact Ratings Figure 8: ePS Program Office Organization Chart Figure 9: ePS IPT/WG Team Hierarchy Figure 10: ePS Staffing Levels Figure 11: Reliability Maturity (Notional) Figure 12: Requirement Management Process Figure 13: Identify Requirements Phase Figure 14: Requirement Tree Specification Figure 15: SETR Process Figure 16: Configuration Management Process

Page:

8/74

List of Tables

Table 1: ePS Requirement Types Table 2: Technical Certifications Table 3: ePS IPTs Table 4: ePS Functional and Technical Positions Table 5: Interface Control Agreements Table 6: SV-7 SPMs List Table 7: System Attributes Table 8: Technical Baseline Planning and Status Table 9: SRR Technical Details Table 10: BTR Technical Review Details Table 11: FTR Technical Review Details Table 12: PRR Technical Review Details Table 13: OTRR Technical Review Details Table 14: Design Considerations for Technical Requirements Table 15: R&M Engineering Activity Table 16: Engineering Tools

Page:

9/74

1 INTRODUCTION

This document supports the Systems Engineering planning aspects of the Electronic Procurement System (ePS) Program. The ePS Program is an Acquisition Category 1 Major Automated Information System (MAIS) Defense Business System (DBS). The ePS is a modernization effort to replace the Navy’s Standard Procurement System (SPS). The current SPS is inadequate to perform required Department of the Navy (DON) contracting functions without extensive cost and is reliant upon the use of multiple aging systems. The ePS Program execution goal is to meet the Under Secretary of Defense for Acquisition, Technology, and Logistics (USD (AT&L)) mandate to sunset the SPS by September 30, 2020.

The ePS provides the DON contracting workforce with secure agile contract writing and management capabilities in an effort to better support the Warfighter. The ePS supports Department initiatives, providing an end-to-end process perspective and better buying power (BBP). The system facilitates audit readiness, reduces infrastructure and sustainment costs, and meets 100% of the End-to-End (E2E) contract writing and procurement requirements for the Department of the Navy (DON) Integrated Contracting Environment (DICE). The ePS is compliant with Congressional and Office of the Secretary of Defense (OSD) directives.

1.1 Purpose

The purpose of the ePS Systems Engineering Plan (SEP) is to define and document the Systems Engineering (SE) approach, associated processes, roles, and responsibilities. SE processes support the assessment of technical health, conduct technical baseline management, support program decisions, and integrate with program activities. The SEP formulates the appropriate Milestone decisions, including Program and Risk assessments.

In addition to the SEP, the ePS Program relies heavily on the prime contractor’s Systems Engineering Management Plan (SEMP) to describe program execution details. The SEMP is a key tool to assess multiple aspects of the contractor’s applied approach.

This SEP will update throughout the acquisition lifecycle and is intended to:

• Support the development RFP release decision

• Obtain approval by the Milestone Decision Authority (MDA) at Milestone B

• Present a comprehensive SE planning document for the ePS Program

• Provide the “blueprints” for the conduct, management, and control of the technical aspects of the ePS Program

• Guide the technical efforts of the ePS Program throughout its lifecycle

• Define the methods for implementing system requirements; including technical content, technical staffing, and technical management

Page:

10/74

• Provide authority and empower the PMW 220 Chief Engineer (CHENG), assisted by a Systems Engineering Group (SEG), to execute the technical planning for ePS

• Maintain consistency with other ePS documentation

1.2 Prime Contractor Alignment with ePS

As part of the ePS procurement, the Program Office will require a Systems Engineering Management Plan (SEMP) from the Prime Contractor to communicate how the vendor will achieve Systems Engineering outcomes outlined in the SEP.

The SEMP will:

• Explain application of the contractor’s standards, capability models, and toolsets to deliver the contracted ePS services and products

• Give insight as to how the contractor’s systems engineering technical management and technical processes will be accomplished in support of ePS Integrated Product Teams (IPTS) (section 3.4.9; Table 3)

• Describe how the contractor’s systems engineering efforts will be conducted

• Outline how to support the preparation, management, and successful closeout of the technical reviews

• Include the planning and controls of the technical program tasks, and management of integrated design, configuration, test, and implementation

The relationship of SEMP to SEP is a key construct, particularly in allowing the Government to communicate critical information to the contractor.

1.3 SEP Review and Approval Process

The SEP is an authoritative, yet “living” document, to be used by all personnel associated with ePS engineering lifecycle processes. SEP reviews are conducted by designated approval authorities:

• The ePS Program is monitored by Program Management Office (PMO), Navy Enterprise Business Solutions (NAVEBS) PMW 220, and led by the ePS Assistant Program Manager (APM).

• The Assistant Program Manager for Engineering (APM-E) adjudicates changes and maintains configuration control of this document.

• Space and Naval Warfare Systems Command (SPAWAR), in conjunction with the PMW 220 SEG, and ePS SE Working-Level Integrated Product Team (WIPT) will review updates and provide necessary comments.

• The PMW 220 PM signs the SEP updates once it is assured the impact of any changes with respect to cost, schedule, and performance are understood, agreed upon, and valid.

Page:

11/74

• The ePS Assistant Program Manager reviews all Environmental, Safety and Occupational Health (ESOH) requirements and develops recommendations for PM approval. ESOH requirements for hosting are the responsibility of the ePS hosting center.

1.3.1 SEP Updates

The ePS Assistant Program Manager (APM) assumes responsibility for this document and ensures SEP updates occur as needed to meet the direction and requirements of the Deputy Assistant Secretary of the Navy for Acquisition and Procurement (DASN (AP)) and the Program Executive Office for Enterprise Information Systems (PEO-EIS). SEP updates include technical progress and changes in technical approaches resulting from technical reviews, program reviews, acquisition milestones, and/or other program decision points. The ePS SE team updates the SEP throughout the acquisition lifecycle.

Updates to this document will occur:

• In support of Milestone B and the Full Deployment Decision (FDD)

• Upon a significant change in scope or requirements

• Upon significant change in technical or acquisition strategy

• In compliance with the ePS Configuration Management Plan (CMP)

• When additional reviews are planned or from captured results of completed reviews

1.3.2 Timeline Summary

Transition to ePS will occur in one Limited Deployment (LD) and two releases. Figure 1 captures the tailored acquisition approach intended for the ePS Program:

Page:

12/74

Figure 1: ePS Tailored Acquisition Approach

The Materiel Solution Analysis (MSA) phase is complete, including an Analysis of Alternatives (AoA) and Problem Statement approved by the Navy Resources Requirements Review Board (R3B). A tailored Capability Development Document (CDD) in the form of a Capabilities Requirement Document (CRD) has been created. The ePS CRD establishes the DON’s operational requirement in the form of an E2E Contracting Writing System (CWS) capability to be met by ePS. The CRD includes System Performance Measures (SPMs), which establish thresholds and objectives, and Key System Attributes (KSAs), which must be met for the ePS system to meet its operational goals.

1.3.3 Requirements Review Timeline

User requirements gathered during the AoA study, led by DASN (AP), were validated after clarification with the Head of Contracting Activities (HCAs) and decomposed requirements are baselined via a formal Systems Requirements Review (SRR).

The level of definition and understanding of system requirements is complete as demonstrated through multiple years of requirement definition and refinement, market research (including four Request for Information (RFI) solicitations to industry), and business process re-engineering activities. Efforts also leverage the near twenty year history of the SPS and Federal CWS procurements over the past decade.

Page:

13/74

2 PROGRAM TECHNICAL REQUIREMENTS

2.1 System Overview

The ePS provides the DON with a standardized, seamless, and secure procurement capability to support its operational needs. The Program also supports BBP initiatives, facilitates Financial Improvement and Audit Readiness (FIAR), and reduces infrastructure and sustainment costs.

The ePS will provide:

• Functional capabilities to support the end-to-end (E2E) Procure-to-Pay (P2P) process

• An electronic Contracting Writing System (CWS) capability, compliant with Federal

Acquisition Regulations (FAR) and the DoD and Navy/Marine Corps Supplements to the FAR (DFARS and NMCARS)

• Capture of data at the source to avoid redundant data entry via touch labor

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

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

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

• Comply with DON-specific architecture and environmental constraints (e.g., compatibility with Navy Marine Corps Intranet (NMCI) and Public Key Infrastructure

(PKI))

The ePS provides automated processing of contracts requirements capability from inception to closeout, while incorporating flexibility to interface with other electronic systems as needed.

Figure 2 depicts the high-level functional, technical, and management requirements which outline the scope of ePS:

Figure 2: ePS High Level scope

The ePS will consist of a COTS technology CWS component and COTS Enterprise Service Bus (ESB) component to deliver the defined integrated capability. The ePS Program will minimize custom development in compliance with the Clinger Cohen Act (CCA), in order to realize the

Page:

14/74 benefits of a “true” COTS solution. Any customization is intended to be a configuration of the software to address specific DON requirements.

Further details pertaining to the software will be documented after a solution is chosen in source selection and software sub-elements are known. However, it has been identified that ePS will have the following elements:

• COTS CWS

a. Purchase Request Package Generation

b. End-to-End Contract Writing Capability

c. Grants Management Capability

d. High Volume Inventory Purchases

e. Process and Data Validation

f. Data Reporting and Analytical Capability

g. Post-Award Contract Management Functions

h. Vendor Procurement Gateway Portal (with Self-Registration)

i. CWS Interfaces

• COTS ESB (transparent to users)

a. CWS Integration

b. Translation and Transport Services

c. Data Exchanges

d. Developmental Framework

2.2 EPS Architecture and Interface Control

The ePS architecture will provide a robust compilation of Department of Defense Architecture Framework (DoDAF) defined viewpoints and associated models that represent a COTS software solution, along with the operational and technical environment in which it will reside. This environment is hereafter referred to as the “To-Be” DON Integrated Contracting Environment (DICE). Aligned with governing Enterprise Architecture (EA), the ePS architecture will portray data standardization, interoperability, secure electronic data transfer, data visibility and the DON financial exchange of data. Its structure will comply with (and maintain alignment with) the following architectural frameworks and guidance:

• DoD Business Enterprise Architecture (BEA). Deputy Chief Management Officer (DCMO). Version 10.0, 14 Feb 2013

• Department of Defense Architecture Framework (DoDAF). DoD Deputy Chief Information Officer (CIO). Version 2.02, 22 Mar 2010

• DON Enterprise Architecture (EA). DON CIO. Version 4.0, 26 Sep 2012

• Architecture Development Guide (ADG). DON CIO. Version 2.0, 29 Jul 2011

Page:

15/74

A centralized infrastructure ensures all commands use the most current release of ePS. As updated versions to these frameworks are released, compliance will be re-evaluated and subsequently adjudicated. As it pertains to ePS, the Operational Viewpoints (OV2/3/4/5a/5b/6c) will provide clarification of requirements and associated functional flows between operational nodes. The System Viewpoints and Services Viewpoints (SV/SvcV 1/2/4/5/6) and Standards Viewpoints (StdV 1/2) will represent the framework for the ePS Systems Specification including system functionality, system interfaces, system data exchanges, and technical standards.

Similarly, additional views include the Capability Views in particular (CV2/4/6) the Overview and Summary Information (AV-1/2) and the Data and Information View (DIV2/3).

2.2.1 DoDAF Efforts

The ePS architecture description will be developed and updated in accordance with the SPAWAR Architecture Review Guide (Appendix C, Reference j.). Following initial architecture development, models will be presented with continued architecture development, during the Risk Reduction phase. The viewpoints and models developed during this effort will support a Milestone B decision. All existing models will be updated as necessary. The PMO is currently using System Architect V11.4.2 to develop architectural views.

2.2.2 Physical Architecture

The Systems View (SV)-1 depicts both the internal and external boundaries of ePS. It portrays system flows as a simplified representation of a pathway or network pattern within the proposed network. These interfaces are depicted graphically as a conveyor between systems and are bounded by their associated operational nodes. In conceptual design, ePS will leverage common industry standards and best practices through the use of commercially available products.

An Enterprise Service Bus (ESB) will provide middleware services for distributed heterogeneous back end functions and applications to provide information to distributed heterogeneous front-end users. The ESB will hide complexity, simplify access, provide canonical forms of query, and allow interaction, while handling the complex details in the background. In general, the purpose of an ESB is to:

• Run seamless data exchanges across an enterprise quickly and easily

• Transform data packages from one format to another, including robust conversion capabilities (e.g., mathematical computations, substitutions, and concatenations) and common system adapters

• Ensure information delivery (even when some systems or networks may go off-line from time to time)

• Broker data packages, including message routing, queueing, and resubmissions

• Deliver an agile, graphical user interface (GUI)-based development for data exchanges and services

• Provide incremental solution implementations to prevent the need for immediate change of enterprise services and applications at one time.

Page:

16/74

Figure 3 represents boundaries of ePS:

Figure 3: SV-1 of ePS

The ePS will integrate with the DON Financial Systems shown in Figure 4, brokering financial data exchanges to ensure integrity and control in the areas of budget, program management and delivery, external reporting, and data integrity. Figure 4 illustrates the DON Financial Systems ePS integration:

Page:

17/74

Figure 4: DON Financial Management Systems

2.2.3 Functional Architecture/Requirements

Requirements types are categorized based on common characteristics and attributes. Some requirement types are based on the requirement source or area of effect. Table 1 identifies the different ePS requirement types.

REQUIREMENT TYPE DESCRIPTION

Business Rule (BR) A rule that defines or constrains some aspect of business and normally resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business.

Business rules can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals.

Data Requirement (DR) Prescribed directives or consensual agreements that define the content and/or structure that constitute high quality data instances and values.

Data requirements can be stated by several different individuals or groups of individuals. Moreover, data requirements may also be based on laws, standards, or other directives. They may be agreed upon or contrary to each other.

Page:

18/74

REQUIREMENT TYPE DESCRIPTION

Internal Control (IC) All methods by which an organization governs its activities to provide reasonable assurance that the following objectives are being achieved:

• Effectiveness and efficiency of operations

• Reliability of financial reporting

• Compliance with applicable laws and regulations

Interface Requirement (IR) Interface requirements imposed on one or more system, subsystems, to identify data passed between these entities.

Glossary Item (Term) A term used in the Program’s common vocabulary.

System Requirement (SR) Functional and non-functional requirements of the system.

Functional Requirement (FR) Detailed statements of the effects that a system is required to achieve, without making any commitment as to how the system is to do it. They constrain only the externally observable behavior and omit any design or implementation bias. Functional requirements may be calculations, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Functional requirements are often used to measure the “fitness for purpose” of the design system which equates to the quality to fulfill a specification or stated outcomes.

Non-Functional Requirement (FR) Elaborates a performance characteristic of the system. Non-functional requirements are sometimes defined in terms of metrics (something that can be measured about the system) to make them more tangible.

Nonfunctional requirements (or system qualities) describe system attributes such as security, reliability, maintainability, scalability, and usability (often referred to as the “ilities”). They can also be constraints or restrictions on the design of the system (in which they may be called design constraints).

Table 1: ePS Requirement Types

2.2.4 Relating Architecture Products to Requirements Definition

The foundation of the Architecture products begin with a final set of approved requirements in the ePS SRS and CRD that allow the creation of products that depict interoperability and connectivity within the network. These products will be the basis for creating test parameters and recording results when performing developmental and operational testing.

2.2.5 Linkage between Engineering and Architecture Activities

Planned engineering activities will be reflected in the ePS architecture implementation and operation including the appropriate data formats to ensure accuracy. Any component of the ePS delivered will be Joint Information Environment (JIE) compliant. Furthermore, any information

Page:

19/74 provided to other systems by way of transaction or data interchange will be compliant with the governing protocols and procedures that ensure interoperability.

2.2.6 Internal Interface Control

Internal interface control will be managed via an ePS Interface Control Document (ICD). When the ICD is completed and approved it will be controlled in accordance with the ePS Configuration Management Plan.

2.2.7 External Interface Control

External interface control will be managed via signed Interface Control Agreements (ICA) with external system owners. The ICAs will establish data interface relationships and requirements to ensure accurate and timely exchanges. ICAs provide detailed information on the data and formats that are used in the exchange and processing of information between ePS and another system.

2.2.8 Requirements Traceability

The Program will maintain and control the relationship between each unique requirement and the rest of the program elements in the Requirements Traceability Matrix (RTM) for use by the design, build, test, and deployment teams. A unique specification identifier provides a linkage from business rules/interface requirements to the system requirements and from the system requirements to the architectural/design elements and finally to test cases. Requirements traceability will allow the Program to understand how a change (or change request) to a requirement will impact other requirements; upstream and downstream. Requirements traceability will be implemented so that, whenever any requirement is changed, all business rules, interface and system requirements, configuration element, and test cases impacted by the change are identified. Figure 5 depicts the Requirements Traceability Matrix:

Page:

20/74

Figure 5: Requirements Type Traceability

2.2.9 Linkage between Engineering and Architecture Activities

Planned engineering activities will be reflected in the ePS architecture implementation and operation including the appropriate data formats to ensure accuracy. Any component of the ePS delivered will be Joint Information Environment (JIE) compliant. Furthermore, any information provided to other systems by way of transaction or data interchange will be compliant with the governing protocols and procedures that ensure interoperability.

2.2.10 Internal Interface Control

Internal interface control will be managed via an ePS Interface Control Document (ICD). When the ICD is completed and approved it will be controlled in accordance with ePS Configuration Management Plan.

2.2.11 External Interface Control

External interface control will be managed via signed Interface Control Agreements (ICA) with external system owners. The ICAs will establish data interface relationships and requirements to ensure accurate and timely exchanges. ICAs provide detailed information on the data and formats that are used in the exchange and processing of information between ePS and another system and vice versa.

Page:

21/74

2.3 Technical Certifications

Table 2 portrays the ePS system-level technical certifications required during the DBS lifecycle process:

CERTIFICATION PMO

TEAM/POC

ACTIVITIES TO

OBTAIN

CERTIFICATION

CERTIFICATION

AUTHORITY

EXPECTED

DATE

Clinger Cohen Act (CCA) Acquisition Management with SE and

IT

Submit CCA package to

DON CIO

PM/DON CIO

(MDAP/MAIS also by DoD CIO)

Q4 FY16

DoD Information Assurance Risk Management Framework (DIARMF)/ Authority to Operate

(ATO)

SE, CS and

IT

Submit DIARMF package

NAO (A&A)

-DON Senior Information Assurance Officer

(SIAO)/DON CIO

-Authorizing Official

(AO)

Q4 FY18

Certification for Initial Operational Test and Evaluation

(IOT&E)

SE and QA/Test

Operational Test Readiness Review

(OTRR)

OPTEVFOR/COTF Q1 FY19

Certification of system’s compliance with applicable DoD and Federal CWS requirements and regulations, to include:

• Compliance with the prescribed use of data and the interface requirements of Federal, DoD, and Navy enterprise systems

• Compliance with data standards

SE and QA/Test

SRR/BTR & FTR DFAS/DASN (AP)/

FMO/DPAP

Q4 FY18

Page:

22/74

CERTIFICATION PMO

TEAM/POC

ACTIVITIES TO

OBTAIN

CERTIFICATION

CERTIFICATION

AUTHORITY

EXPECTED

DATE

Certification under § 2222 “Defense business systems:

architecture, accountability, and modernization”

• System is in “compliance with the enterprise architecture”

• “Business process supported by the DBS program is or will be as streamlined and efficient as practicable”

• “Need to tailor COTS systems to meet unique requirements or incorporate unique interfaces has been eliminated or reduced to the maximum extent practicable”

SE/business process SME

“Defense Business Systems Investment Management Process Guidance,” June 2012

Navy DCMO/Navy

CIO/IRB/DBSMC

Q4 Annually

Interoperability Certification T&E WIPT Lead

Obtain Certification:

OPTEVFOR

interoperability testing/JTIC concurrence

JITC Q4 FY18

Spectrum Supportability Determination -- Generally spectrum analysis of COTS software products does not apply to DBS software, since there are neither any transmitters nor receivers or antennae.

N/A DD Form 1494 DON CIO/ National Telecommunications and Information Administration

(NTIA)

N/A

Table 2: Technical Certifications

3 ENGINEERING RESOURCES & MANAGEMENT

3.1 Technical Schedule and Schedule Risk Assessment

3.1.1 Technical Schedule

The ePS is employing an evolutionary acquisition approach utilizing a multiple release approach for fielding of the ePS solution. The ePS Program will enter the acquisition lifecycle at the Development RFP Release Decision point (Q4 FY16). Release 1 will deliver full end-to-end CWS capability. Release 2 will introduce any additional functionality needed to close remaining

Page:

23/74 functionality gaps, and will deploy to the remaining HCA user commands. Figure 6 reflects the ePS Program schedule:

Figure 6: ePS Program Schedule

3.1.2 Schedule Risk Assessment

Inherent impacts of schedule dependencies are critical, and assessing these risks will be a significant factor in the success of the ePS Program. To help mitigate the schedule risks, the PM and the Systems Engineering Team, including vendors and integrators, will use a critical path analysis technique to identify major schedule drivers. At the ePS Program Management Review, the leadership team will address the critical path schedule risk assessment. The scheduling team will meet more frequently if the risks become critical. Additionally, the engineering team will address schedule risk at Systems Engineering Technical Review (SETR) events.

Page:

24/74

3.2 Engineering Resources and Cost/Schedule Reporting

3.2.1 Work Breakdown Structure (WBS)

The ePS prime contractor will be required to create a detailed technical WBS, which will be used as an input to the Program’s Integrated Master Schedule (IMS). The government will review the WBS and IMS during an Integrated Baseline Review (IBR). For further information, refer to the ePS CARD which includes the approved ePS Program WBS.

3.3 Technical Risk and Opportunity Management

3.3.1 Risk Management Process

The PMW 220 Risk Management Plan (RMP) (see Appendix C Reference g.) outlines the approved ePS Risk Management strategy, and it details the process for implementing proactive Risk Management as part of the overall management of the ePS Program Office. As the Program matures through its lifecycle, the type and character of risks will change.

Risk Management is a program management tool used to assess and handle events that may adversely impact the Program; this includes budget, schedule, cost and technical considerations.

The ePS RMP also addresses the management of those risks that have been realized, and are adversely impacting the Program; also known as “issues.” The relationship between Risk Management and Issues Management is addressed. The RMP outlines the organization and management approach in planning, identifying, characterizing, assessing, analyzing, handling, tracking, and reporting risks associated with the successful execution, deployment, and sustainment of Navy EBS systems.

The purpose of the RMP is to provide standard procedures for identification and mitigation of risks. Effective Risk Management increases the likelihood/probability of program success.

Risk Management is applicable to all acquisition functional areas in order to identify critical risks and take mitigating action to manage these risks before they can become issues, causing cost, schedule, or performance impacts.

The Risk Management Board will report new risks or significant changes in status of previously identified risks to the Program Manager. Refer to the PMW 220 Risk Management Plan (RMP) for more information. Program risks will be handled by the Risk Management Board (RMB) as described in the RMP. Figure 7 is the Impact Ratings matrix:

Page:

25/74

LEVEL TECHNICAL PERFORMANCE SCHEDULE COST

1 Minimal or no consequences to technical performance

Minimal or no impact Minimal or no impact

2 Minor reduction in technical performance or supportability

Able to meet key dates

Slip < * month(s)

Budget increase or unit production cost increases

< ** (1% of Budget)

3 Moderate reduction in technical performance or supportability with limited impact on program objectives

Minor schedule slip; Able to meet key milestones with no schedule float

Slip < * month(s)

Sub-system slip > * month(s) plus available float

Budget increase or unit production cost increase

< ** (5% of Budget)

4 Significant degradation in technical performance or major shortfall in supportability; may jeopardize program success

Program critical path affected

Slip < * month(s)

Budget increase or unit production cost increase

< ** (10% of Budget)

5 Severe degradation in technical performance; cannot meet KPP or key technical/supportability threshold; will jeopardize program success

Cannot meet key program milestones

Slip < * month(s)

Exceeds APB threshold

> ** (10% of Budget)

Please see Appendix B for a summary of current ePS Program risks.

Page:

26/74

= Original Risk Analysis = Current Assessment = Predicted Final

HighModerateLow oo

• Risk ID #82: Risk Statement…

• Consequences if Realized:

- Cost -

- Performance -

- Schedule -

• Handling Method: (Accept, Avoid, Transfer or Mitigate) Summarize activities:

1. Summarize Key Activity 1

2. Summarize Key Activity 2

3. Etc.

• Planned Closure Date:

• Risk ID #23: Risk Statement…

• Consequences if Realized:

- Cost -

- Performance -

- Schedule -

• Handling Method: (Accept, Avoid, Transfer or Mitigate) Summarize activities:

1. Summarize Key Activity 1

2. Summarize Key Activity 2

3. Etc.

• Planned Closure Date:

• Risk ID #45: Risk Statement…

• Consequences if Realized:

- Cost -

- Performance -

- Schedule -

• Handling Method: (Accept, Avoid, Transfer or Mitigate) Summarize activities:

1. Summarize Key Activity 1

2. Summarize Key Activity 2

3. Etc.

• Planned Closure Date:

• Risk ID #97: Risk Statement…

• Consequences if Realized:

- Cost -

- Performance -

- Schedule -

• Handling Method: (Accept, Avoid, Transfer or Mitigate) Summarize activities:

1. Summarize Key Activity 1

2. Summarize Key Activity 2

3. Etc.

• Planned Closure Date:

• Risk ID #85: Risk Statement…

• Consequences if Realized:

- Cost -

- Performance -

- Schedule -

• Handling Method: (Accept, Avoid, Transfer or Mitigate) Summarize activities:

1. Summarize Key Activity 1

2. Summarize Key Activity 2

3. Etc.

• Planned Closure Date:

Li ke lih oo d

Oonsequence

1 2 3 4 5

Figure 7: Risk Impact Ratings

3.4 Technical Organization

The Program PMO staff has estimated the ePS Programmatic manpower requirements for the lifecycle of the ePS. Refer to Section 3.0 of the ePS CARD that details the ePS operational components and provides a delineation of programmatic manpower requirements by fiscal year, title, labor type, sponsoring activity, and number of Full-Time Equivalents (FTEs). Personnel supporting ePS are divided into three labor types: Government, Contractor Support Services (CSS), and Military Labor. The CSS personnel listed only include PMO assigned support and do not include contractor resources provided by the awarded COTS solution provider required to design, develop, integrate, and transition the ePS solution to the government as those personnel are contingent on the awarded contract and solution.

As part of the Navy EBS portfolio, ePS will leverage services from shared competencies within the portfolio to reduce cost and take advantage of experienced Business IT skill sets and knowledge. The ePS Government staff contains resources from the PEO-EIS, SPAWAR Systems Center - Atlantic (SSC LANT) and SPAWAR Competencies.

Page:

27/74

CSS personnel levels will fluctuate throughout the Program with the majority of resources being on-boarded during the Risk Reduction and Development/Deployment Phases of the acquisition lifecycle. The ePS PMO will leverage the use of PMW 220 resources in an effort to minimize CSS total personnel. When available, the PMO will also leverage Government Subject Matter Experts (SMEs) from the HCA commands to accomplish project tasking. This will enable the PMO to manage and optimize total resource numbers.

The ePS PMO staff estimated labor by task via the WBS and the notional Limited Deployment and two release deployment schedule. Resource estimates were developed by analyzing the WBS work packages, scope of the work (e.g., HCA sites by number of users and ePS functionality), and SME input on historical data. The elements of the WBS were then allocated to the appropriate Cost Element Structure (CES) according to DoD 5000.4-M, Cost Analysis Guidance and Procedures.

3.4.1 Government Program Office Organization

The Sponsor/Functional Owners participated in the SRS development, were involved in early reviews of draft requirements and participated in stakeholder requirements sessions. The Resource Sponsor is OPNAV N41. The Functional Sponsors are DASN (AP) and PDASN (FM&C). As members of the ePS Governance Board, they may be called upon to resolve escalated issues such as required capabilities, deployment sequencing, or data governance policies. The Sponsors review/approve the SRS and govern any significant scope changes of the Program during system development.

A combination of Government and contractor personnel fulfills the ePS Program staffing requirements. Lessons learned from past industry and Government ERP implementations indicate that Government involvement throughout the process requires a strong, collaborative working relationship between Government and contractor personnel as a critical success factor for large programs like ePS. Integrated government and contractor team(s) are essential for efficient and effective decision making and program execution. While the Program’s acquisition approach seeks to promote a strong partnership between Government and contractor personnel to achieve ePS objectives, it maintains integrity, separation and protection of inherently governmental functions.

The PM will provide governance and oversight to the mid-level tiers and competencies. Mid-level tiers and competencies include, but are not limited to, an Implementation team, a Cybersecurity team, an Acquisition Manager, SE Team, Logistics team, Cost-Estimating team, and a Procuring Contracting Officer (PCO). Figure 8 represents the organizational structure associated with the ePS Program, including the Technical Division, where the SE resides:

Page:

28/74

Figure 8: ePS Program Office Organization Chart

3.4.2 User Community Representatives

User community representatives (from the HCA commands) are identified in the stakeholder analysis and recruited to become part of the requirements team. They will provide input and review the draft requirements from the perspectives of user operations, business flow, accuracy of policy interpretation, development and modification to training and implementation planning in addition to leveraging users for test and test feedback. They will participate in elicitation meetings, specification walkthroughs and stakeholder meetings. User community representatives will be asked to review and validate system requirements.

3.4.3 Program Requirements Manager

The assigned Program Requirements Manager is responsible for managing the requirements process to include:

• Documenting, analyzing, tracing, prioritizing and managing the system process

Page:

29/74

• Manage changes to the controls the requirements throughout a program

• Outline well-organized requirements specification(s) for a shared understanding

• Ensure verification of system requirements satisfy the user needs

3.4.4 Program Requirements Analysts/Subject Matter Expert (SMEs)

The Program Requirements Analysts and SMEs provide expertise in the domain of the system with extensive background in the problem arena.

The Analyst:

• Participates in stakeholder meetings to help define requirements

• Identifies and communicates outstanding issues and initiates resolution activities

• Obtains and documents all policy clarifications in writing

• Participates in writing the requirements specifications

• Works with the requirements manager to plan schedule and prepare for internal walkthroughs and stakeholder requirements sessions

• Incorporates feedback and comments into requirements specifications and facilitates stakeholder review and approval

Functional and policy SMEs will review the requirements to validate compliance with entrance/exit criteria as well as the project baseline.

3.4.5 User and/or Interface IT Organization

The ePS Interface Control Working Group (ICWG) will identify external system interface requirements, identify changes to interfaces within systems under the authority and control of external entities, and manage Interface Control Agreements (ICAs) with representatives of those organizations. These representatives will be asked to provide input and review requirements with a focus on the accuracy and completeness of the interface requirements. These users and/or interfacing IT organizations will be identified during stakeholder analysis and when interfaces of the system are identified.

3.4.6 Program Manager (PM)

The Program Manager is among the reviewers and approvers of the requirement management process.

The PM:

• Should receive an executive briefing of the requirements at a minimum to understand the capabilities of the system

• Understand the requirements well enough to discuss them, at a high level, with external executive stakeholders

• Approve and sign the final requirements specifications

Page:

30/74

• Is accountable for ensuring requirements plans and supporting methodologies (e.g.

processes, procedures, standards, and templates) are in compliance with organizational best practices and policies

• Monitor the progress of the requirement processes, provides regular status updates and makes approval recommendations to stakeholders, program steering committee members and other senior leaders

3.4.7 Program Engineers

The PMW 220 Chief Engineer:

• Provides overall guidance and supervision of ePS Program engineering staff

• Identifies the engineering resources required to support the Program’s acquisition and the assignment and management of all the engineers within the ePS systems engineering

• Is responsible for the SE working-level IPT (WIPT), cybersecurity working group, and

Test and Evaluation WIPT

• Coordinates with all ePS Program WIPTs, providing SE direction and support as required to facilitate SE processes throughout the Program

• Develops and maintains the metrics that assess the effectiveness of systems engineering

The ePS Assistant Program Manager - Engineering (APM-E) provides technical expertise and support throughout the Program’s lifecycle, in a multi-stakeholder environment. The APM-E:

• Manages the overall system engineering efforts within the Program, including engineering cost, schedule and performance throughout the lifecycle of the system

• Provides technical leadership toward the development and tracking of the functional/technical requirements and interfaces, assisting with technical analyses, and ensuring the final system meets all stated requirements

• Is responsible for planning and conducting all ePS Program Systems Engineering Technical Reviews (SETR)

• Leads the technical assessment and review of all requirements specifications including their alignment with the system architecture.

The ePS Lead Engineer is responsible for implementing the systems engineering processes within the Program, and ensuring they support the technical evaluation of system performance throughout the lifecycle of the system.

Test engineers review requirements to ensure all are testable, prepare test plans, oversee testing, ensure defects are resolved prior to product deployment, and clarify the gray area requirements that are frequently unnoticed, such as error messages and usability issues.

3.4.8 ePS Prime Contractor

The prime contractor will participate with the requirements team to lend specialized COTS solution expertise to review functional and technical components of the requirements. The

Page:

31/74 contractor will review the requirements to determine if the requirement can be configured by the system, determine the level of customization required vs. out-of-the-box (OOTB), and ensure derived requirements are minimalized.

The ePS contractor will have an Earned Value Management System (EVMS) to tie cost, schedule, and technical performance together. The contractor will provide monthly EVM reports, which will be incorporated into recurring performance metric reviews with ePS Program management staff.

3.4.9 Program Office Technical Staffing Levels

The PMW 220 Program Office has established a Systems Engineering Group (SEG) which will support the portfolio’s technical strategy and engineering management approach from concept to disposal. The SEG is designed to promote effective ePS SE by conducting analysis of data affecting product development and design. Additionally, the PMW 220 SEG monitors SE activities throughout the lifecycle of the ePS Program, including assessing performance, cost, and schedule impacts from a technical perspective. The SEG also supports the Risk Management process, while providing technical expertise and supporting the formal review process in a multi-stakeholder environment. The PMW SEG Charter is listed in ePS references.

The SE WIPT approves the purpose, scope, strategy, and objectives to transform required operational capabilities into an integrated system design that optimizes total system performance and minimizes total ownership costs. The SE WIPT is responsible for guiding the development of a comprehensive systems engineering support strategy that provides all systems engineering documentation to support Milestone decisions and other Program events.

The Program Office utilizes IPT structures to facilitate decision-making by considering recommendations based on concurrent, timely input from the entire team. The IPT approach takes advantage of all members’ expertise to create an integrated solution. The IPT organizations are not aligned to vendor teams. Instead, the vendors have participation and representation in the IPT(s) relevant to their scope of work. Table 3 describes the ePS IPTs established:

Page:

32/74

NAME CHAIRPERSON TEAM

MEMBERSHIP

TEAM ROLES AND

RESPONSIBILITY

PRODUCTS OR

METRICS

*METRICS WILL

BE TRACKED BY

IPT

Acquisition

WIPT

Mary Kay Caffrey

Program Office Manage, coordinate and development of program documentation

-Acquisition Documentation

-Milestone Reviews Systems Engineering

WIPT

Gail Hoffman Program Office Platform lead R&M Lead Key subcontractors

ESOH

Coordinate development of the SEP, tailored Information Support Plan

(ISP)

- SEP

- Tailored

Information Support Plan (ISP)

- Architecture Framework

Cybersecurity (CS) Working Group

Steven Kougoures

Program Office System Security Service Representative

- CS Requirements

- ID vulnerabilities

- Mitigation strategies

- Cybersecurity Strategy

- PPP

- Threat analysis

- ATO accreditation

Interface Control Working Group

Mary Klausner Program Office Interoperability Rep.

External Programs

- Interface management

- External System liaison

- Interface Testing

- Interface Architectural Views

- ICAs

- ICD

Implementation Team

Joseph Gryder Program Office Service Representative External Programs

- Initial Training

- User access

- Deployment preparations

- Deployment Plans

- Training Products

- User Command

Systems Engineering Group

Peter Kassal Program Office External Programs key contractors

- SE Strategies

- Resolve tech issues

- SW engineering

- Technical expertise

- SETR Events

- Requirements Docs

- System Architecture

- Hosting Solution

- Integration

Testing & Evaluation WIPT

David Rodenberger

Program Office Test Manager Service Rep.

key subcontractors

- ID test requirements

- Developmental

Evaluation Framework

- Design of Experiment

- Manage T&E throughout lifecycle

- TEMP

- Test Plans

Table 3: ePS IPTs

3.4.10 Contractor Program Office Organization

The prime contractor has not been selected at this time. Following selection, this SEP will be updated to include the contractor’s program office description.

Page:

33/74

3.4.11 Engineering Team Organization and Staffing

Figure 9 represents the current ePS IPT/Working Group hierarchy:

Figure 9: ePS IPT/WG Team Hierarchy

Table 4 represents the staffing for ePS technical and functional areas determined by the activities occurring in ePS. Contractor staffing for PMO services is relatively constant. Other ePS contract support services include Systems Engineering, Cybersecurity, Test & Evaluation, training/help desk and data management.

FOUO: ePS MANPOWER WORK SHEET

WBS Team Position/Title Labor Type

PMO

PMO ePS Assistant Program Manager (APM): Senior Government/PMO PMO ePS Deputy APM: Senior Government/PMO PMO Chief Systems Engineer (CHENG) 5.0: Senior –

Key Leadership Position (KLP) Government/PMO

PMO PM/DPM Support: Senior Contract Support Services (CSS) PMO Business Finance Management 1.0: Senior Government/PMO PMO Cost Estimating 1.6 Government/PMO PMO Cost Estimating Team CSS PMO Program Contracting Officer 2.0 Government/PMO PMO PCO Team Government/PMO PMO Product Support Manager

(PSM) 4.0

Government/PMO

PMO Acquisition (Acq) Analyst Government/PMO PMO Acq Support CSS

Page:

34/74

PMO Requirements/Configuration Manager Government/PMO ePS Systems Engineering

Sys Eng Assistant Program Manager-Engineering (APM-E) 5.0: Senior

Government/PMO

Sys Eng Lead Engineer: Senior Government/SSC-L Sys Eng SE Support: Senior CSS Requirements Requirements Engineer: Senior Government/SSC-L SW Eng Software (SW) Engineer 5.0: Senior Government/PMO SW Eng SW Eng Support: Senior CSS SW Eng Network Eng Support: Senior CSS SW Eng Middleware Eng.