Attch_0022_ACWS_SEP_RR_Draft_2016_04_04.pdf

ACWS Draft Systems Engineering Plan DRAFT Version 1.0 14 October 2015

Distribution A: Approved for public release; distribution unlimited

ARMY CONTRACT

WRITING SYSTEM

(ACWS) – ACAT IAM

Systems Engineering Plan (SEP) pre-ATP-1 for Risk Reduction Phase Draft

Version 1.0 14 October 2015

Prepared By:

Product Manager Army Contract Writing System (ACWS)

ACWS Systems Engineering Plan DRAFT i

This page intentionally left blank

ACWS Systems Engineering Plan DRAFT ii

SUBMITTED BY:

LTC Robert J. Wolfe Date ACWS Product Manager

DRAFT APPROVED BY:

COL William M. Russell, Date GFEBS Project Manager

APPROVAL PAGE

ACWS Systems Engineering Plan DRAFT iii

Revision History

Version Date Summary of Changes

1.0 14 October 2015 PM-approved draft for Final RFP

ACWS Systems Engineering Plan DRAFT iv

Table of Contents

1.0 Introduction – Purpose and Update Plan

Purpose

Update Plan

2.0 Technical Activities and Products

Results of Previous Phase SE Activities

Market Research

Key SE Activities Performed

Key Definitions

Planned SE Activities for the Next Phase

Technical Reviews

Requirements Development and Change Process

Requirements Management Process

Requirement Management Roles and Responsibilities

Requirements Allocation and Traceability

Controlling Requirements Creep

Configuration and Change Management

2.5.1 CM Roles, Responsibilities, and Authorities

2.5.2 Configuration Baseline Management

Data Management

Operational Data Management

Technical Data Management

Design Considerations

Engineering Tools

3.0 Program Technical Requirements

Architectures and Interface Control

Architectures

ACWS Interface Control and Governance

Technical Certifications

4.0 Engineering Resources and Management

ACWS Systems Engineering Plan DRAFT v

Technical Program Schedule and Schedule Risk Assessment

Technical Program Schedule

Program Risk Assessment

Engineering Resources and Cost / Schedule Reporting

Work Breakdown Structure (WBS)

Integrated Master Plan

Integrated Master Schedule

Integrated Baseline Review

IMP/IMS Linkage

Technical Organization

Integrated Product Team (IPT) Structure

Systems Engineering WIPT

ACWS Systems Integrator

Relationships with External Technical Organizations

Functional Relationship

Test Community Relationship

Cybersecurity Community Relationship

External Interface Partners

ACWS Hosting Environment

Technical Performance Measures and Metrics

Responsiveness

Scalability

Reliability and Availability

Maintainability

Software Quality

System and Software Development Metrics

Technical Performance Measurement (TPM) Monitoring and Review

Appendix A: Acronym List

ACWS Systems Engineering Plan DRAFT vi

List of Tables Table 1: SEP Change Types and Authorities

Table 2: ACWS Risk Reduction Activities

Table 3: ACWS Risk Reduction Entry and Exit Criteria

Table 4: Technical Review Matrix

Table 5: SRR / SFR Details

Table 6: PDR Details

Table 7: CDR Details

Table 8: DTRR Details

Table 9: OTRR Details

Table 10: ORR Details

Table 11: Requirements Management Roles and Responsibilities

Table 12: Systems Engineer Program Documents and References

Table 13: Design Considerations

Table 14: R&M Engineering Activity Planning and Timing

Table 15: Systems Engineering Tools

Table 16: DoD Objectives and Army High Level Objectives

Table 17: Army HLOs and Business Outcomes

Table 18: ACWS Key Performance Parameters (KPP)

Table 19: Architecture Products

Table 20: Interface Partners

Table 21: Technical Certifications

Table 22: ACWS Risk Contributors and Mitigation

Table 23: ACWS SE IPT Working Groups

Table 24: SE WIPT Dependencies and Synchronization

Table 25: Technical Performance Measures

Table 26: Responsiveness Measures

Table 27: Reliability Measures

Table 28: Availability Measures

ACWS Systems Engineering Plan DRAFT vii

Table 29: Notional Defect Aging Metrics

Table 30: Maintainability Measures

Table 31: Software Quality Measures

List of Figures Figure 1: ACWS Systems Engineering Approach/Methodology

Figure 2: ACWS Notional Capabilities Roadmap

Figure 3: Market Research Summary

Figure 4: Requirements Management and Change Process

Figure 5: ACWS Change Management Process – Top-level Flow Diagram

Figure 6: Requirements Traceability

Figure 7: ACWS Operational View (OV)-1

Figure 8: Contracting Systems “As-Is” Interactions

Figure 9: Conceptual “To-Be” System Interface Description (SV-1)

Figure 10: ACWS System Interface Landscape

Figure 11: ACWS Notional Integrated Program Schedule

Figure 12: ACWS PMO Organizational Chart as of 1 October 2015

Figure 13: ACWS IPT Structure

Figure 14: ACWS Program Support Framework

Figure 15: Procurement Systems Functional Governance Structure

ACWS Systems Engineering Plan DRAFT 1

1.0 Introduction – Purpose and Update Plan

Purpose

This version of the Systems Engineering Plan (SEP) is provided as a DRAFT to support the Milestone Decision Authority (MDA) Request For Proposal (RFP) Release decision for the Army Contract Writing System (ACWS). Per DoD Instruction (DoDI) 5000.02 Operation of the Defense Acquisition System, and increasing fidelity on program assumptions, the ACWS estimated program cost exceeds ACAT IAM levels. As a result, the MDA has re-designated the program as an ACAT IAM.

The SEP serves as the guiding document for ACWS systems engineering planning and management and will be used by all those implementing ACWS systems engineering activities as described herein.

ACWS PMO is using the Systems Engineering Plan Outline version 2.0 dated January 2015, which puts forth the guidance established in DoDI 5000.02. This version of the SEP documents the systems engineering approach to include the technical requirements, engineering resources management, technical activities, and products as applicable to the characteristics associated with the acquisition of a Commercial-Off-the-Shelf (COTS) solution. This approach will be used throughout the ACWS acquisition life cycle to address and satisfy the statutory and regulatory requirements required to meet key acquisition milestones and deliverables as identified within the tailored ACWS acquisition strategy.

An updated SEP will be provided to the System Integrator (SI) at contract award. The SI will then have ninety (90) days to provide a Systems Engineering Management Plan (SEMP), aligned with the SEP.

Update Plan

The SEP is a living document and will be updated, as needed, to reflect changes in the technical approach stemming from the findings and results of the program and technical reviews, Milestone decisions, and/or other program decision points. Updates to the SEP will be tracked in the revision table. The event triggers that could produce updates to the SEP are shown in Table 1.

Table 1: SEP Change Types and Authorities

Change Type Rationale Updating Authority

Approval Authority

SI SEMP submission Reflect synchronization with the SI

SEMP

ACWS Lead Systems Engineer

Program Executive Office, Enterprise Information Systems (PEO EIS)

ACWS Systems Engineering Plan DRAFT 2

Change Type Rationale Updating Authority

Approval Authority

Updated / Future DoD Directives, Instructions, or Applicable Public Laws

Ensure compliance with any updated / future mandated policies

ACWS Lead Systems Engineer

Deputy Assistant Secretary of Defense (Systems Engineering)

(DASD[SE)]

Decision events Reflect program decisions made at key events, such as technical reviews, where systems engineering processes, activities, and products can be impacted

ACWS Lead Systems Engineer

PEO EIS

ADMs Reflect critical acquisition decisions.

ACWS Lead Systems Engineer

DASD(SE)

Approval Authority Recommendations

Address any changes in program objectives or direction that are initiated by an approval authority above PdM ACWS

ACWS Lead Systems Engineer

Varied based on requestor

Significant Engineering Change

Reflect significant changes in key systems engineering processes and products (e.g., architecture, design, test, integration).

ACWS Lead Systems Engineer

DASD(SE)

2.0 Technical Activities and Products

The ACWS systems engineering approach will leverage DoD Instruction 5000.02 and includes the systems engineering technical processes, roles, responsibilities, and reviews applicable to the characteristics of the COTS solution being acquired. This SEP defines the technical and engineering objectives, assumptions, drivers, dependencies, organization structure, and roles and responsibilities between the ACWS engineering team and external organizations. The processes described in this SEP will be utilized throughout the entire acquisition life cycle and will address the statutory and regulatory requirements required to meet key acquisition milestones and deliverables.

The overarching assumption is that the COTS-based solution will be a mature product that will require minimal customization to integrate into the Army contract-writing environment. This overarching assumption is based on the following tenets:

• The Army will acquire a mature, standards-based COTS system with configurable business processes, open, configurable interfaces, and open systems architecture

• The Army will adopt the COTS solution business processes and workflows

• Business Process Re-engineering will be done jointly with industry to identify

Government process modifications

• Customization will be done only where necessary to meet government regulations, interface requirements, and case-by-case process shortfalls

ACWS Systems Engineering Plan DRAFT 3

• ACWS will utilize DoD Enterprise Services and Data Exchange Standards to the extent applicable, to include Government-designated hosting services as required.

• ACWS will leverage existing Army investments and COTS functionality to the greatest extent possible

The ACWS Program Management Office (PMO) will deploy a single COTS contract writing and management solution through system configuration, integration, and, only if required, limited customization. Following contract award, the government will review the SEMP prepared by the SI. At this time, systems engineering processes, procedures, and technical reviews will be solidified for systems engineering execution across the program life cycle.

The following systems engineering activities, events, and artifacts will be incorporated into the program Integrated Master Schedule (IMS) to ensure the conduct and completion of efforts aligned with overall program milestones, dependencies, and critical path:

• ACWS Risk Reduction (RR) activities, to include Business Process Re-engineering (BPR), Out-of-the-Box (OOTB) Capability and Interface Assessment, System Characterization, Interface Characterization, Technical Standards Characterization, Performance and Scalability Assessment, Human Systems Integration (HSI) Assessment, Sandbox / Development Environment Installation

• Systems engineering development phases: requirements analysis, design (functional/business and technical), build, and test

• Capability builds

• Technical Reviews (e.g., System Requirements Review [SRR] / System

Functional Review [SFR] Preliminary Design Review [PDR], Critical Design Review [CDR]), Test Readiness Reviews [TRR])

• System Integration

• Test Events (e.g., Developmental Test [DT], Initial Operational Test & Evaluation

[IOT&E], Follow-On Operational Test & Evaluation [FOT&E])

• System Certifications

• Training activities

• Deployment activities, such as site surveys and hosting

The process, sequence, and timing for updating the critical path with software-development-related drivers and identifying associated risk mitigation activities to meet schedule objectives will be as directed in the ACWS Risk Management Plan (RMP).

Technical risks will be managed as part of the ACWS risk management process. The ACWS PMO will manage program risks and mitigation, ensure significant risks are being captured and addressed in order to meet cost, schedule, and capability delivery objectives in accordance with the ACWS RMP.

ACWS Systems Engineering Plan DRAFT 4

The ACWS Systems Engineering life cycle process is depicted in Figure 1 below.

ACWS will use IEEE Standard for Application and Management of the Systems Engineering Process (IEEE STD 1220-2005), as a guide. Figure 1 below illustrates the systems engineering activities for the ACWS program life cycle. There are Roman numerals for each section located at the top center of each section. The center (Section I) represents the core, where processes (e.g., Requirements Management, Configuration Management, Risk Management, Decision Analysis, Technical Planning, Test and Evaluation, Architecture and Design Development, Data Management), key decision activities (e.g., risk, economic analyses, change control, collaboration) and governance (e.g., doctrine, standards, requirements) set the pace for the program. The yellow ring (Section II) represents the key engineering phases. The aqua ring (Section III) represents the milestones, technical reviews, and checkpoints to be conducted. The light blue ring (Section IV.) represents the engineering activities to be performed for within each phase. The green arrow indicates an iterative or incremental process that will be repeated throughout the program life cycle. Phases, milestones, and activities will be conducted as applicable.

Figure 1: ACWS Systems Engineering Approach/Methodology

ACWS will follow a modular and open systems approach. ACWS will deliver capability in a series of software builds. Figure 2 depicts the notional build plan and serves as the basis for all acquisition planning. Each build will follow a process starting with requirements analysis and concluding with an operational evaluation. Technical

ACWS Systems Engineering Plan DRAFT 5 reviews will be conducted as applicable. Entry and exit criteria for each technical review are defined in this SEP. ACWS will apply the applicable systems engineering processes contained in the following plans:

• ACWS Acquisition Strategy

• ACWS Transition Strategy

• ACWS Configuration Management Plan (CMP)

• ACWS Risk Management Plan (RMP)

• ACWS Requirements Management Plan (RqtMP)

• ACWS Test and Evaluation Master Plan (TEMP)

Figure 2: ACWS Notional Capabilities Roadmap

Results of Previous Phase SE Activities

ACWS entered the Material Solution Analysis phase with the approval of the Milestone Development Decision Acquisition Decision Memorandum (MDD ADM) dated 29 October 2014. The most significant outcome of pre-MDD activities is the results of the Market Research and the Analysis of Alternate (AoA) that drove the determination of the program competitive approach and the high confidence in availability of the COTS-based solution.

Market Research

Figure 3 summarizes the market research activity that has occurred to date. The ACWS SE WIPT has been a key participant in analyzing the functional requirements, reviewing data from industry responses to multiple Request for Information (RFI) self-certifications aligned to the functional requirements, and participating in numerous vendor demonstrations through multiple forums to assess product maturity and ability to meet ACWS requirements OOTB.

ACWS Systems Engineering Plan DRAFT 6

Figure 3: Market Research Summary

Key SE Activities Performed

In addition to the market research, key systems engineering activities have included the following:

• Reviewing the High Level Objectives (HLOs) and collaborating with the functional community on the identified measurements and associated threshold and objective values, to include identifying key performance parameters

• Analyzing the functional requirements in order to:

‒ Assess testability ‒ Derive non-functional requirements, to include refining standards compliance requirements ‒ Identify data hosting requirements ‒ Develop an interface strategy and define interface requirements, to include conducting Technical Interchange Meetings (TIMs) with interface partners for data gathering in order to capture the current state and assess complexity and risk associated with each

‒ Determine the percentage of requirements that could be met OOTB, how many could be met with configuration, and how many would require customization. This resulted in a Report, Interface, Conversion, ACWS Systems Engineering Plan DRAFT 7

Enhancement, Form, Workflow (RICEFW) objects count that was provided to the Cost WIPT as input to the life cycle cost estimate

• Reviewing operational views and preparing system views to support acquisition planning and documentation development

• Defining technical implementation strategies for systems engineering, data hosting, information assurance / cyber security, and testing

• Collaborating with the functional community and finalizing the definitions for configuration, modification, customization, Initial Operational Capability (IOC) and Full Deployment (FD)

• Preparing systems engineering inputs for the Acquisition Requirements Package

• Developing the Program Protection Plan (PPP) and Cybersecurity Strategy

• Preparing inputs for, and reviewing, the Acquisition Strategy and Capabilities

Requirements Traceability Matrix (RTM)

• Reviewing the Concept of Operations (CONOPS)/Operational Mode

Summary/Mission Profile (OMS/MP) and RqtMP

• Defining the key tasks and outcomes for the ACWS RR in compliance to the

DODI 5000.2 RR Phase

Key Definitions

The following key terms that contribute to systems engineering planning and execution have been defined as follows:

Out of the Box (OOTB) The released version of a COTS solution that includes those functions, capabilities, tasks, business processes, forms, or other operations that are available to any authorized user upon installation and initial setup of the hardware and software.

Configuration Any change within the defined set of COTS product parameters, which the user can set and does not result in customization of the COTS product.

Software configuration typically:

• Enables or disables functionality that is readily available in the COTS product

• Includes the initial setup of a large system (e.g., install parameters, data-element names, functional security model, User Interface (UI) modification, settings, processes)

• Includes the use of available menus and/or wizards to set the parameters that determine the workflow; and

• Is not lost with a version upgrade of the COT product

ACWS Systems Engineering Plan DRAFT 8

Extension Software code that provides additional functionality in the ACWS solution without disturbing the core software code. It may include additional interfaces, automation of additional contract writing/administration processes, and new data fields. Does not require a secondary license.

Plug-In / 3rd Party A software component that provides capability that cannot be inherently accomplished by the core COTS solution, and which requires a secondary license. This component will be installed or integrated with the existing COTS product(s) and should not require changes to the core code of the existing COTS product(s). It may include additional interfaces, automation of additional contract writing/administration processes, and new data fields. Once installed/integrated, the operations should seamlessly execute and be unnoticeable to the user.

Customization Any software development work to change or extend the functionality of a COTS product, resulting in changes to the core code of the COTS product that may or may not be incorporated as enduring functionality within the COTS baseline.

Software customization may be used to create reports, interfaces, conversion objects, extensions, forms, or other capability to satisfy requirements specific to the Army that could not otherwise be implemented by the configuration process. Customization of the COTS product requires a detailed understanding of the COTS implementation and data schemas in order to develop new or change existing functionality of the product.

Customization includes Enhancement: Capability that results from changes to the core code of a COTS product in order to improve existing functionality that cannot otherwise be accomplished through configuration or modification. Enhancements are expected to be included in future releases of the COTS product. Enhancements are anticipated to be system upgrades necessary to ensure continued alignment, improvement, and standardization of end-to-end contracting processes and maturation of infrastructure to handle the large transaction volume and data demands. This may include application version upgrades, automation of manual business process steps, automated access to additional data required for report completeness, major updates to meet changes in compliance requirements, and infrastructure modernization to address additional users, system scalability, technology refresh, prevailing industry standards, and emerging technologies.

Initial Operational Capability IOC is achieved when ACWS:

1. Has been deployed and trained to at least one (1) Army Procurement command or sub-command

ACWS Systems Engineering Plan DRAFT 9

2. Can be used to execute basic procurement functions (as defined above)

3. Can successfully exchange data with all identified Federal and DoD systems

4. Can successfully exchange data with a minimum of one (1) Army Financial system (e.g., GFEBS, LMP, or CEFMS) listed in Figure 10 Note:

Army Procurement Commands = ACC, USACE, MEDCOM, INSCOM, NGB Sub-Commands = ECC, MICC, APG, NJ, RI, RSA, WRN, USACE Atlanta, USACE Dallas, USACE Winchester, USAMRAA

Full Deployment FD is achieved when ACWS:

1. Has been deployed and trained across the Army Contracting Enterprise

2. Can be used to execute all identified capabilities (as defined above)

3. Can successfully exchange data with all identified Federal, DoD, Financial and

Mission Specific systems

Planned SE Activities for the Next Phase

Following a successful RFP release, a source selection, and an Authority to Proceed-1 (ATP-1) decision, a contract will be awarded to initiate the RR phase. Per DoDI 5000.02, the purpose of the RR phase is to “reduce technology, engineering, integration, and life cycle risk cost to the point that a decision to award a contract for EMD can be made with confidence in successful program execution for development, production, and sustainment.”

The ACWS RR phase will focus on enabling the PMO to successfully award the Task Order (TO) 0001 and understanding, in a comprehensive way, the development efforts for all builds.

Key ACWS RR focus areas will include:

• Establishing a project team, project structure, and project plans to initiate a business blueprint

• Conducting a business blueprint to optimize the Army “To-Be” end-to-end Procure-to-Pay processes and business scenarios in the context of the ACWS solution, including integration with all required partner systems

• Defining applicable Business Process Designs and Fit-Gap Assessments, including recommendations on how to address gaps through analyses of alternatives

• Developing a plan for solution development spanning all ACWS builds, including:

− Expected configuration requirements

ACWS Systems Engineering Plan DRAFT 10

− RICEFW inventory by build − Resources and schedules across all builds and phases − Applicable program management activities.

The ACWS RR phase will provide necessary breadth and depth of knowledge regarding the selected software solution that will allow the program to mature the “To-Be” business process workflow to be adopted by the Government. The ACWS RR phase will also focus on system characterization, along with insight into any underlying programmatic and technical risks surrounding the delivery of a contracting writing solution to the Army on time and within budget.

ACWS RR will allow for integrated and dedicated collaboration and execution between with Government functional Subject Matter Experts (SMEs), PdM ACWS representatives across all disciplines, and the SI. The ACWS RR phase inherently:

• Increases user involvement and ownership of the capability from the onset

• Provides an opportunity to conduct BPR and significant organizational change management activities early in the program life cycle

• Allows for full analysis of the selected solution to assess OOTB capability against requirements, and determine development / customization efforts up front

• Provides an “off-ramp” prior to the issuance of the development Task Order if those efforts exceed expected costs and schedules

• Minimizes design and implementation incompatibilities across subsequent builds

• Maximizes adoption of the COTS product business processes, thereby minimizing unnecessary customization

• Allows for the assessment of the technical characteristics of the selected solution

• Provides ample lead time to configure the Government hosting services to optimize performance, as well as solidify interface details, thereby reducing the uncertainty regarding business process and data integration with interface partners

• Provides knowledge of interface complexity from the onset to determine means to exchange data with other systems

ACWS RR activities descriptions follow:

• Global Analysis:

As a Commercial-Off-The-Shelf (COTS) Defense Business System (DBS), the focus of the Risk Reduction (RR) phase will be to gain sufficient understanding of potential development efforts through series of blueprinting workshops. The goal of blueprinting is to:

− Gain an understanding of the overarching or "global" requirements (i.e., from across all releases/builds).

ACWS Systems Engineering Plan DRAFT 11

− Gain an understanding of the “out of the box” solution and configurable functionality of the COTS-based solution mapped to the ACWS capabilities and requirements (i.e., the Fit/Gap analysis).

− Insight into development efforts required to address any gaps between the OOTB / configurable functionality of the solution and ACWS capabilities / requirements.

− Determine how requirements will be executed in the To-Be environment.

The outputs of the workshops will support Business Process Re-engineering efforts that primarily will focus on changing business processes before deciding to undertake any development efforts that were identified during blueprinting.

Once the blueprinting, fit/gap, and business process re-engineering efforts are complete the final task will be to develop a comprehensive schedule that maps any approved development efforts to a specific builds that achieves IOC and FD within acceptable timeframes. The Requirements-Traceability-Matrix (RTM) will be revised concurrent with this activity.

The SI and the ACWS PMO will jointly undertake the Global Analysis effort to gain an understanding of the overarching or global requirements (e.g., from across all builds) and organizational structures of the ACWS objectives. The SI, in collaboration with Government functional and technical representatives, will perform detailed solution blueprinting activities to map out how the system capabilities will be delivered based on the COTS OOTB solution. The SI will provide a Fit/Gap Analysis to compare the proposed solution to the ACWS requirements, and then conduct BPR to evaluate potential business process changes to align with the COTS product and identify system configuration and/or customization requirements. It is anticipated that these tasks will require a series of workshops with functional SMEs (provided by the ACWS PMO) utilizing a Government lab. If the Government lab environment is not available, it may be necessary to utilize a SI-provided environment to support blueprinting workshops. The solution blueprinting workshops noted in Table 2 will support and drive all other tasks and deliverables in this area.

• Blueprinting Methodology: Blueprinting will be a collaborative effort led by the SI and will include the ACWS functional community, key process/system partner SMEs, and the program management office. The current plan calls for a series of focused workshops that will decompose the ACWS solution into functional process areas. The plan calls for an iterative series of workshops based on the logical progression of the contracting and related business processes. This will segment the analysis into focused, manageable workshops. Vendors are being asked to provide their concepts as part of proposals so the current plan is notional pending source selection and contract award.

ACWS Systems Engineering Plan DRAFT 12

• Blueprinting Workshop Participants: It is anticipated that the ACWS System Integrator will provide SMEs knowledgeable with the functionality of the COTS-based business system. ACWS will provide functional process SMEs from across the Army contracting enterprise and related process stakeholders from partner Army and DoD organizations when applicable to provide expertise on Army business processes and the ACWS requirements.

The list of organizations that will be included in blueprinting workshops includes:

Army Contracting Enterprise − Office of the Deputy Assistant Secretary of the Army – Procurement

(ODASA(P))

Functional proponent to provide senior-level contracting, contracting system SMEs, and functional governance leadership − Army Medical Command (MEDCOM) − National Guard Bureau (NGB) − United States Army Corps of Engineers (USACE) − Army Contracting Command (ACC) to include:

Mission & Installation Contracting Command (MICC) Expeditionary Contracting Command (ECC) ACC Centers (Warren, Rock Island, Redstone, Aberdeen Proving Ground, New Jersey, and Orlando) − Army Intelligence and Security Command (INSCOM)

Partner/Stakeholder Participants − Assistant Secretary of the Army – Financial Management & Comptroller

(ASA-FM&C)

General Fund Enterprise Business System (GFEBS) DASA(FIM) – Financial Information Management DASA(FO) – Financial Operations

− Army Material Command Logistics Modernization Program (LMP)

− Corps of Engineers Financial Management System (CEFMS) − Air Force Financial Management Defense Enterprise and Accounting Management System (DEAMS)

− Defense Finance and Accounting Service (DFAS) − Defense Contract Management Agency (DCMA)

ACWS Systems Engineering Plan DRAFT 13

T&E Community SMEs − Army Test & Evaluation Command (ATEC) Observation / Familiarization Survivability Post Milestone A, Paper Study Cyber Baseline Assessment Human System Integration (HSI) Assessment Design of Experiments (DOE) Training Effectiveness (optional)

− Deputy Assistant Secretary of the Army – Developmental T&E

(DASD(DT&E))

Observation / Familiarization

− Joint Interoperability Test Command (JITC) Observation / Familiarization

• Interface Definition: The SI and the ACWS PMO will work together to identify the specific characteristics of each ACWS interface, to include inbound and outbound data exchanges and the data formats associated with each as aligned to the business process workflow. Compliance with all required standards will be addressed. The ACWS PMO will ensure that the necessary collaboration and information exchange with each interface partner is aligned with the ACWS IMS.

• System Characterization: System Characterization will address both programmatic and technical aspects of the system as follows:

‒ Programmatic: The SI and the ACWS PMO will work together during the

ACWS RR phase to develop a comprehensive program plan to achieve a Full Deployment Decision (FDD) within the mandatory time frame. Additionally, many of the activities will generate inputs to acquisition documentation required for ACWS to proceed to subsequent Milestone (MS) decisions. The SI will be expected to provide resources with detailed knowledge of the solution as inputs to various documents as requested by the ACWS PMO.

‒ Technical: These tasks will focus on system characterization, security planning, and knowledge transfer between the SI and the ACWS PMO. The installation and operation of the initial lab environment, and capturing detailed insight into technical issues, are key elements across these activities. The lab environment will be utilized for other tasks but from a technical standpoint, the value of the lab environment will be to assist the Government in achieving a successful installation in the Government-owned and operated hosting environment, and to identify and address technical risks/issues early in the program life cycle. There will not be any development in this environment and it is not expected that all of the ACWS planned interfaces will be

ACWS Systems Engineering Plan DRAFT 14 demonstrated; only those, to the practical extent possible with respect to what is provided as OOTB for the selected product.

It is not expected that any Army unique interfaces (for example, financial systems) will be demonstrated in this phase. Additionally, any OOTB interfaces that are assessed during this phase will require full implementation in the ACWS production environment during Build 1.1. It is not the intention of this phase to require that the SI conduct activities that will not add value to the long-term success of the program. The lab environment will be hosted in a Government provided facility. The SI will be required to provide personnel to assist in the installation and operation of the environment. Prior to entering the development “build” phases, the SI and ACWS PMO will work together to ensure that ACWS deployment and sustainment plans are sufficiently detailed to minimize unnecessary re-training and sustainment costs. Table 2 below provides a summary view of the ACWS RR activities by category, the deliverable products, and the projected timeframe (some tasks conducted in parallel):

Table 2: ACWS Risk Reduction Activities

Category Activity Products(s) Timeframe Global Analysis Blueprinting / BPR • Initial Business Process Designs (high level solution blueprint)

• Architecture Viewpoints & Development Plan

• Critical Functionality Analysis

• Studies, Analysis, Assessments, and

Improvements

• Use Cases/Test Scenarios

TBD

Fit Gap Analysis • Fit/Gap Analysis Report (including out of the box/configurable functionality mapped to requirements)

• Development objects to meet gaps and level of effort

OOTB Capability Requirements Assessment and Prioritization

• Updated RTM

Deployment Requirements

• Life Cycle Sustainment Plan (LCSP)

• Deployment Plan

Business Intelligence Data Migration Strategy Analysis

• Database Design (DBDD)

Disconnected State Characterization

• Disconnected State Plan / CONOPS

Interface Definition

Interface Characterization • Business Process and Business Rules Definition

• Interface Exchange Requirements ICDs update

• CONOPS for Financial Integration

• Interface Requirements Specification (IRS)

• Interface Design Description

TBD

ACWS Systems Engineering Plan DRAFT 15

Category Activity Products(s) Timeframe Programmatic

System Characterization

Resource-loaded integrated program schedule that identifies activities to be executed and associated dependencies aligned to program MSs

• Integrated Master Schedule

• Critical Path

• Risk Management Status Report

TBD

Program Management Planning

• RMP

• RqtMP

• Communications Plan

• CMP

• OCM Plan

• Detailed Development / Build Release Plan

• Interface Partner MOAs/MOUs

• Training Plan

• Deployment Plan

• Onboarding Plan

• SEMP

• Product Support Plan

• Program Protection Information Plan

• Build Plan

Technical System

Characterization

Lab Environment Installation

• COTS product Provisioning, Installation, and Configuration Procedures Plan

TBD

Security Hardening • Vulnerability Assessment Report Performance and Scalability Assessment

• System Performance Report

HSI Assessment • HSI Assessment Report OOTB Interface Assessment

• Interface Assessment Log and Report

Stand-up of Development, Test, and Production Environments at Government-owned and operated data center.

• SLAs

• Provisioning, Installation, and Configuration

Plan for COTS product within Government-owned and operated environments

• Technical Landscape Architecture Plan

• Hosting Analysis Report

Secure Environment Technical Characterization

• Program Protection Plan (PPP)

• Cybersecurity Strategy

Technical Standards Characterization

• ISP Inputs

• Technical Review Package

• System Provisioning Document

• Operating Environment Requirements and

Design

• Software Requirements Specification

• Computer Software Baseline

• Software Version Description

• Quality Assurance Program Plan (QAPP)

• Phase-Out Transition Plan

Test Management • Reliability, Availability and Maintainability (RAM) Report

• Coordinated Test Plan

• Software Test Plan

• RAM Plan

• Requirements Testability Analysis Report

TBD

ACWS Systems Engineering Plan DRAFT 16

Category Activity Products(s) Timeframe Training Plan Development

• Training Plan

In order to ensure completeness and sufficiency of the results of all ACWS RR activities, a combined SRR/SFR will be conducted to ensure that a mutual understanding between the government and contractors exists; and to establish the functional baseline. A Preliminary Design Review (PDR) will be conducted to ensure functionality is represented in a realistic and executable design given potential requirements trades and the result of system characterization.

There will not be any formal test events conducted during the ACWS RR phase.

However, early engagement with external agencies and test tools will provide insight into expectations and anticipated level of effort for each planned test event.

ACWS RR entrance and exit criteria are identified in Table 3 below. At the conclusion of ACWS RR, a Go/No Go decision will be made to proceed to Milestone B.

Table 3: ACWS Risk Reduction Entry and Exit Criteria

Entry Criteria Exit Criteria

• Baselined (Validated and Approved) Requirements with Performance Parameters ( Fully characterized through FDD)

• Level 3 “To-Be” Process Descriptions

• “To-Be” Business Process Model Use Case in sufficient detail to support blueprinting, fit/gap, and functional scenario development

• Interface Plan

• Program Management tools to support ACWS

RR

• Resources available to execute ACWS RR

• Products noted in Table 2 are complete, validated, and approved

• Final Build Schedule

• Hosting environment

(test/development/staging/production) requirements are clearly defined, and hosting agreements with Government-owned and operated data center are in place

• Risks defined with Mitigation Plans

• Requirements baselined for Build 1.1

• All personnel, tools, training, other resources available to begin Build 1.1 activities

• Interface Control Document (ICD)

• Successful PDR

Technical Reviews

As depicted in Figure 1, technical reviews will be conducted throughout each phase of the ACWS system life cycle, and will serve as checkpoints regarding successful completion of key activities. At a minimum, the following technical reviews will be conducted as planned within the ACWS program schedule / IMS:

• System Requirement Review (SRR) / System Functional Review (SFR)

• Preliminary Design Review (PDR)

• Critical Design Review (CDR)

ACWS Systems Engineering Plan DRAFT 17

• Developmental Test Readiness Review (DTRR)

• Operational Test Readiness Review (OTRR)

• Operational Readiness Review (ORR)

• Functional Configuration Audit (FCA)

• Physical Configuration Audit (PCA)

Guidelines for these reviews are provided in Tables 4-10 below. Technical reviews will be tailored based on the scope of the review and complexity of the capability under review. For design reviews, Independent Evaluators will be used to ensure that emerging designs are aligned with system of systems objectives and are achievable within the timeframe identified. They will make a determination / recommendation as to readiness to proceed.

ACWS Systems Engineering Plan DRAFT 18

Table 4: Technical Review Matrix

REFERENCES SRR / SFR PDR CDR DTRR OTRR ORR

Purpose

• Define functional / system requirements

• Determine resource allocation

• Identify risks

• Approve RTM

• Approve

Architecture

• Approve

Preliminary Design

• Establish Allocated Baseline

• Approve RTM

• Approve

Architecture

• Approve Detailed

Design

• Establish Product

Baseline

• Ensure system can proceed into developmental test within project budget, schedule, risk

• Assess whether the system meets the functional requirements documented in the allocated and product baselines

• Establish and verify final product performance

• Verify test procedures and results are consistent with requirements

• Ensure system can proceed into operational test within project budget, schedule, risk

• Assess whether the system meets the functional requirements documented in the allocated and product baselines

• Establish and verify final product performance

• Verify test procedures and results are consistent with requirements

• Perform formal examination of functional characteristics and test data

• Verify system has achieved the performance specified in the requirements specifications

• Verify that system performance is demonstrated in the designated configuration

• Verify all associated technical documentation is complete and accurate

• Confirm that production processes, quality control, measurement and test equipment, and training are adequately planned, followed, and controlled

• Verify that any items that were impacted/redesigned after completing OTRR are performing as required

ACWS Systems Engineering Plan DRAFT 19

REFERENCES SRR / SFR PDR CDR DTRR OTRR ORR

Projected Schedule

To be determined post contract award

To be determined post contract award

To be determined post contract award

To be determined post contract award

To be determined post contract award

To be determined post contract award

Chair & Co-Chair

ACWS Chief Systems Engineer & Office of the Deputy Assistant Secretary of the Army – Procurement

(ODASA(P))

Functional Sponsor

ACWS Chief Systems Engineer & Office of the Deputy Assistant Secretary of the Army – Procurement

(ODASA(P))

Functional Sponsor

ACWS Chief Systems Engineer & Office of the Deputy Assistant Secretary of the Army – Procurement

(ODASA(P))

Functional Sponsor

ACWS Test Lead ACWS Chief Systems Engineer

ACWS Test Lead

ACWS Test Lead

Additional Objectives

See Table 5 See Table 6 See Table 7 See Table 8 See Table 9 See Table 10

ACWS Systems Engineering Plan DRAFT 20

Upon completion of each technical review, all conflicts, contradictions, errors, impacts and omissions identified as part of the exit criteria will be documented for action and meeting notes will be provided to all reviewers and formally recorded as part of the technical review report. The ACWS SE WIPT will resolve all identified issues / action identified as required. The following tables provide detail for each required review.

Table 5: SRR / SFR Details

Area Details Co-Chairpersons ODASA(P) Functional Sponsor PMO Participants ACWS WIPT Leads, SI representatives Stakeholder Participant Organizations

• Procurement Systems Governance Board (PSGB) representatives

• ODASA(P)

• PEO EIS representatives

• DASD(SE)

Peer and Program independent SME participant organizations

• PEO EIS SMEs

• ODASA(P) SMEs

Purpose • Define functional / system requirements

• Determine resource allocation

• Identify risks

Entrance Criteria • Preliminary System Specification has been provided for review

• Technical Plans, to include SEMP, CMP, and TEMP, are available

• Preliminary Work Breakdown Structure (WBS) has been developed

• Preliminary IMS has been developed

• Preliminary Cost Plan has been developed

• Preliminary Supportability documentation has been developed

ACWS Systems Engineering Plan DRAFT 21

Area Details Exit Criteria • Requirements have been adequately decomposed into functions and mapped accordingly

• System requirements are traceable back to/and within the RTM

• System scope and bounds have been clearly stated

• System interfaces with external entities and between major internal elements have been defined

• Requirements have been adequately allocated hardware, human, and software subsystems

• Tradeoff analyses have been performed to address options for meeting operational needs and to determine system constraints

• Operational views have been reviewed and refined

• Initial system architecture views have been defined

• Technical Performance Measures been bee identified

• Initial software sizing and resource loading parameters have been defined

• Critical technology elements have been identified

• Network security requirements have been defined

• Host security requirements have been defined

• Security accreditation strategy has been defined

• System requirements are testable

• Preliminary approaches for how requirements will be assessed down to the subsystem level have been identified

• Test issues and constraints have been identified

• Training requirements have been adequately defined

• System safety release requirements have been adequately defined

• Reliability, availability, and maintainability requirements have been defined

• Supportability / Logistics issues and constraints have been identified

• Technical Documentation requirements (TMs, training) have been identified

• Risks have been identified and prioritized and are mitigation plans / actions defined, to include cost and schedule impact

• Program schedule is executable

• Program is executable within the existing budget and known technical risks

• Unresolved issues or deficiencies have been identified and recorded

• Action items have been recorded and monitored

Products/Artifacts being reviewed

• Work Breakdown Structure

• Integrated Master Schedule

• RqtMP

• RTM

• SEMP

• CMP

• Business Process Models / Workflows

• System/Subsystem Specifications (SSS)

• Test Plans

• Risks Assessments and mitigation plans

• Engineering Metrics

• Trade-off Analyses

Table 6: PDR Details

Co-Chairpersons ODASA(P) Functional Sponsor PMO Participants ACWS WIPT Leads, SI representatives

ACWS Systems Engineering Plan DRAFT 22

Stakeholder Participant Organizations

• PSGB representatives

• ODASA(P)

• PEO EIS representatives

• DASD(SE)

Peer and Program independent SME participant organizations

• PEO EIS SMEs

• ODASA(P) SMEs

Purpose • Approve RTM

• Approve Architecture

• Approve Preliminary Design

• Establish Allocated Baseline

• Review results of the any site visits conducted

• Ensure requirements have been allocated to system components

• Ensure requirements are testable and traceable to top-level requirements

• Ensure sufficiency to proceed to CDR

• Ensure resource sufficiency to execute plan

Entrance Criteria • Requirements scope has been bounded and assessed (e.g., operational capabilities and requirements are defined, measurable, and documented) to include:

‒ Requirements have been decomposed, allocated to capabilities / system functions, and mapped to hardware, software, and infrastructure components ‒ Uncertainties have been documented with known impact ‒ Performance parameters / requirements have been defined and documented ‒ Interface requirements between systems have been defined and documented ‒ Hosting requirements have been defined and documented ‒ Security requirements, to include ATO documentation, have been defined and documented ‒ Tradeoff analyses have been performed to address options for meeting operational needs and to determine system constraints ‒ Functional end-to-end Use Cases are defined

• SEMP is made available prior to the review

• Development methodology is defined

• Engineering tools are in place

• Updated cost and schedule data made available prior to the review

• Operational and System Views developed (should include interfaces and data exchanges)

• Overall test approach defined and test schedule provided, to include test resource requirements (e.g., facility, support equipment, and support tools)

• Risk areas (technical, cost, and schedule) identified

• Configuration Management approach defined

• Schedule for all program milestones identified

• Design alternatives identified

• Key design assumptions, constraints, limitations, and issues identified

• System interdependencies and implementation interdependencies identified

• Integration strategy defined

• Development environment established

• Testing environments established

• RTM complete and ready to be placed under CM

• Software requirements and interface requirements to be implemented in each incremental software build and/or release identified

• Required IA activities underway

• Service-level agreements in place

• Resource Plan has been provided for review

ACWS Systems Engineering Plan DRAFT 23

Exit Criteria • Allocated Baseline is established and documented to enable design to proceed with proper CM

• Architecture views have been assessed against the requirements

• System requirements traceable back to/and within the RTM

• System design satisfies the requirements as translated into the SSS/configuration specifications

• Interfaces and interface requirements have been defined, to include interactions among system components and data flows between systems

• IA and Security strategies are defined for the network and host environment(s), and the accreditation process is known

• Test plans and assumptions have been defined, to include use cases / test scripts to test, and the test environment description is known

• Training strategy is defined, to include Configuration and Change Management

• System Support Strategy is defined

• System Integration Strategy is defined

• Adequate government and SI processes/metrics are in place

• Project schedule is executable within the existing budget (technical/cost risks)

• Cost Plan is in place and has been assessed

• Contracts, associated SOWs, and licenses, are finalized / in place execute

• Sufficient resources with correct skill sets are assigned to execute activities

• Required Program Documentation is in place and approved

• Cost, schedule, and performance risks have been identified and prioritized, and risk mitigation plans are defined and assessed as actionable

• Unresolved issues or deficiencies have been identified and recorded

• Action items have been recorded and monitored

Products/Artifacts being reviewed

• Work Breakdown Structure

• Integrated Master Schedule

• RqtMP

• RTM

• SEMP

• CMP

• Business Process Models / Workflows

• SSS

• SSDD

• IDDs / ICDs

• Test Plans

• Risks Assessments and mitigation plans

• Engineering Metrics

• Trade-off Analyses

• Use Cases

Table 7: CDR Details

Co-Chairpersons ODASA(P) Functional Sponsor PMO Participants ACWS WIPT Leads, SI representatives Stakeholder Participant Organizations

• PSGB representatives

• ODASA(P)

• PEO EIS representatives

• DASD(SE)

ACWS Systems Engineering Plan DRAFT 24

Peer and Program independent SME participant organizations

• PEO EIS SMEs

• ODASA(P) SMEs

Purpose • Approve RTM

• Approve Architecture

• Approve Detailed Design

• Finalize Allocated Baseline

• Review results of the any site visits conducted

• Ensure requirements have been allocated to system components

• Ensure…