Attch_0001_ACWS_Statement_Of_Objectives_2016_05_06.pdf

Unclassified

ACWS SOO

Version 1.02 6 May 2016

Distribution A: Approved for public release; distribution unlimited

ARMY CONTRACT

WRITING SYSTEM

(ACWS)

Statement Of Objectives (SOO) Version 1.02 6 May 2016

Solicitation Number: W52P1J-16-R-0058

Prepared By:

Product Manager Army Contract Writing System (ACWS)

ACWS SOO i

This page intentionally left blank

ACWS SOO i

Revision History

Version Date Summary of Changes

Version 1.0 4 April 2016 Final for publication

Version 1.01 14 April 2016 Minor edits to correct period of performance

Version 1.02 6 May 2016 Updated the version to 1.02 and version date to 6 May 2016 throughout. Separated “Enhancement” from the “Customization” definition and created “Enhancement” as a separate Term of Reference in Section 2.2.;

CDRL numbers were corrected in Section 8.0; made corrections where Attachment 0005 was misrepresented as Attachment 0004 (1 location) and where Attachment 0011 was misrepresented as Attachment 0010 (4 locations); corrected a Table 2 entry where a SIPRNet requirement was misrepresented as a NIPRNet requirement; deleted requirement for EVM in Section 6.1.i; updated Figure

4. Other changes in this SOO also highlighted in green.

ACWS SOO ii

Table of Contents

1.0 Purpose

2.0 Background & Terms of Reference

2.1 Background

2.2 Terms of Reference

3.0 Scope

4.0 Program Objectives

5.0 Business Outcomes

6.0 Contract Objectives

6.1 Program Management

6.2 Systems Engineering Management and Planning

6.3 Solution Design and Development

6.3.1 Solution Design Support

6.3.2 Solution Development Support

6.3.3 Cybersecurity and Program Protection Support

6.3.4 Data Support

6.4 Test and Evaluation

6.5 Training

6.6 Solution Deployment

6.7 Organizational Change Management

6.8 Operations and Support

6.9 Licenses for Commercial Software

6.10 Transition Out

6.11 Studies, Analyses, Assessments and Improvements

6.12 Travel

6.13 Other Direct Charges

6.14 Manpower Reporting

6.15 Contract Data Requirements List (CDRL)

7.0 Period and Place of Performance

8.0 Operating Constraints and Conditions

ACWS SOO iii

9.0 Compliance References

Appendix A: Acronym List

List of Tables Table 1: ACWS High Level Objectives

Table 2: ACWS Business Outcomes

Table 3: ACWS Key Performance Parameters (KPPs)

List of Figures Figure 1: ACWS Notional Program Schedule

Figure 2: ACWS Notional Software Build Plan with IOC and FD Definitions

Figure 3: ACWS Notional Software Build with IOC and FD Interfaces

Figure 4: Contract CLINs and Notional Task Orders

ACWS SOO 1

1.0 Purpose

The Statement of Objectives (SOO) identifies the broad, basic, top-level objectives of a mature Commercially Available Off-the-Shelf (COTS) Contract Writing System (CWS)1 and management solution for an Indefinite Delivery/Indefinite Quantity (IDIQ) contract with an initial twelve (12) month Base Ordering Period, one (1) forty-eight (48) month Option Ordering Period, and one (1) sixty (60) month Option Ordering Period.

2.0 Background & Terms of Reference

2.1 Background

Over the last fifteen years, the Army has relied on the Standard Procurement System (SPS), the Procurement Automated Data and Document System (PADDS) and Virtual Contracting Enterprise (VCE) as its primary contract writing capabilities. The Army is pursuing an alternative as these systems are reaching the end of service life.

In October 2011, Defense Procurement and Acquisition Policy (DPAP) announced SPS termination plans, directing that no new contracts would be input into SPS after 30 September 2015, and that all use of SPS would cease on 30 September 2017. The services were further directed to plan, budget for and execute plans to support future contracting capabilities to replace SPS.

Also, in January 2012 through the FY13 National Defense Authorization Act Section 862, “Uniform Contract Writing Requirements”, Congress gave DoD direction to establish electronic contract writing systems that comply with uniform standards, requirements, rules, and controls.

In response to higher headquarters and congressional direction, the Army conducted an Analysis of Alternatives (AoA) and Cost Benefit Analysis (CBA). Those studies determined the strategy for the identification of a single enterprise-wide contract writing and management system that would replace SPS, PADDS, and the VCE suite of tools in order to meet the Army's current critical functional requirements and extend to meet future functional requirements.

On 25 September 2014, the Under Secretary of Defense (Acquisition, Technology and Logistics) (USD (AT&L)) signed a memorandum that updated the sunset (termination) date for use of the SPS. The USD (AT&L) directed all components to cease awarding

1 "DoD defines a COTS-CWS as a commercially available software application, or product, whose core competency (out of the box) is to generate and issue FAR-based contracting actions (awards, orders, or modifications)." DoD Strategic Plan for Defense Wide Procurement Capabilities (A Functional Strategy), Version 2.1, February 12, 2016, Page 7.

ACWS SOO 2

any contracts, agreements, or orders through SPS after 30 September 2018. Use of SPS, for all contracts issued prior to the 30 September 2018, is allowed to continue until 30 September 2020. USD (AT&L) confirmed the original direction from October 2011, for each Service to budget for and execute plans to deploy future contracting capabilities. On 24 March 2016, USD (AT&L) approved the ACWS Acquisition Strategy and signed an Acquisition Decision Memorandum approving ACWS as an unbaselined Acquisition Category I (ACAT I) Major Automated Information System (MAIS), ACAT IAM and retained Milestone Decision approval.

2.2 Terms of Reference

The following terms are defined to ensure consistency in context. The definitions here shall take precedence over the content in the Requirements Traceability Matrix (Attachment 0005) or any other Request for Proposal (RFP) attachment. The RTM was approved 4 November 2015, and the definitions below were refined after that date.

• Commercially Available Off-the-Shelf Contract Writing System (COTS-CWS)2 – A commercially available software application, or product, whose core competency (out of the box) is to generate and issue FAR-based contracting actions (awards, orders, or modifications).

• 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 COTS product.

• 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

2 ACWS herein incorporates the DoD definition for COT-CWS.

ACWS SOO 3

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.

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

3.0 Scope

This ACWS IDIQ contract will procure a COTS-CWS and management solution over 1-year, 4-year, and 5-year ordering periods. Task Order 0001 will initiate the Risk Reduction Phase and additional Task Orders will continue through Development & Deployment Phase, to Operations & Support Phase (Reference DoDI 5000.02, Model 3).

The Army Contract Writing System (ACWS) will be the Army's single, next-generation, enterprise-wide contract writing, management, execution, and close-out software system. ACWS will facilitate the standardization of Army Procurement business processes and improve data exchange and business process workflow with selected

ACWS SOO 4

Army Enterprise Resource Planning (ERP) systems. As a financial feeder system, ACWS will meet the compliance requirements of the Federal Financial Management Improvement Act (FFMIA) of 1996.

The ACWS solution will meet the full scope of Army Contracting requirements and processes, including unique requirements in secure and non-secure locations, unique requirements supporting combat or non-combat contingencies, those within or outside the borders of the Continental United States, those supporting grants and assistance agreements, and those performing weapons systems, construction, installation, and other specialized contracting activities. See Attachment 0007 Concept of Operations/Operational Mode Summary/Mission Profile, Attachment 0005 ACWS Requirements Trace Matrix, Attachment 0008 Architecture Views). These documents aid in describing the context of the scope of the requirements for the ACWS solution.

The contracting solution must support the full breadth of contracting processes with the strategic goal of implementing a single software solution that will meet the Army's current and future end-to-end contracting operational requirements in any environment, including secure and disconnected environments. When deployed, ACWS will be used by approximately 10,000 end users in Government entities at approximately 300 different locations in support of installation, construction, medical services, expeditionary, transportation, and research and development contracting requirements.

The ACWS solution is expected to streamline end-to-end business processes; eliminate capability gaps of legacy systems; minimize customization that inhibits upgrades to the COTS solution; adapt to continuously emerging laws, regulations, and policies;

minimize cost of operations, maintenance, and support; support financial auditability compliance requirements; promote and improve efficiencies when integrating with existing automated solutions; and where practical, minimize the number of existing and future interfaces.

4.0 Program Objectives

The ACWS program objectives are to execute a strategy for the identification, procurement and deployment of the Army's single, next-generation, enterprise-wide contract writing, management, execution, and close-out software system that will meet the Army's current critical functional requirements and extend to meet future functional requirements.

The ACWS Defense Business System Problem Statement was approved in September 2013:

“The Army must move to a single enterprise-wide contract writing and management system to obtain business process efficiencies, support compliance with the FFMIA of 1996, integrate with existing Enterprise Resource Planning (ERP) solutions, and decrease the number of complex interfaces while fostering auditability. Due to the rapidly approaching SPS Sunset dates, the Army has an

ACWS SOO 5

urgent need to analyze available strategies, re-engineer business processes, select and implement a solution to replace current contracting capabilities.”

The new capability is required to replace SPS, PADDS, and VCE. The end state is to streamline contracting end-to-end business processes; minimize operating, maintenance and support costs; where applicable minimize the number of existing and future interfaces; support financial auditability; and promote and improve efficiencies when integrating with existing ERP systems.

Attached as references are Attachment 0007, ACWS Concept of Operations/Operational Mode Summary-Mission Profile, and other applicable requirements documents which provide additional details for preparing the Contractor PWS and CDRLs. Table 1 provides the ACWS program objectives as High Level Objectives (HLO):

Table 1: ACWS High Level Objectives

Short Title High-Level Objective Description

HLO – 1

Adaptability

Apply Better Buying Power initiatives to achieve efficiencies; Implement and maintain an open and scalable architecture that allows for capability enhancements, system adaptability, and technology insertion.

HLO – 2

Contract Management and Administration

Optimize standard business processes, procedures, templates and formats to enable contract administration and leverage Business Information (BI) to provide increased visibility and oversight over the management and administration of contracts.

HLO – 3

Process & Data Integration Successful automated data exchanges and workflow across functional domains (procurement, finance, and logistics) and the DoD.

HLO – 4

Integrated System

Implement an integrated contract writing and management system that performs the full spectrum of procurement business processes to support the awarding and administration of legally binding procurement instruments in accordance with the FAR and its supplements while reducing overall system and process complexity, fostering usability, and eliminating redundant data entry within a single solution.

HLO – 5

Net Ready Supports military operations, is entered and managed on the network, and effectively exchanges information

HLO – 6

Operational Availability Capable of performing its assigned mission for the environment in which it is deployed.

Along with the information provided in Attachment 0005, ACWS Requirements Traceability Matrix, and Attachment 0007, Concept of Operations (CONOPS) Operational Mode Summary/Mission Profile document, these HLOs provide the

ACWS SOO 6

program level context in which the ACWS capability requirements are expected to be satisfied.

5.0 Business Outcomes

As a result of the ACWS contract performance, the Government expects to achieve the Business Outcomes defined in Table 2 and the Key Performance Parameters defined in Table 3.

Table 2: ACWS Business Outcomes

HLO #

Business Outcome

Title Business Outcome

Description Measurement Threshold Value (T) Objective Value (O)

HLO – 1

BO – 1

Emerging Requirements

System will provide baseline capabilities and is adaptable to implement emerging requirements based on policy changes and/or user needs.

Amount of time required for the system to implement changes based upon user needs and policy updates that have been approved by the Configuration Control Board (CCB)/Procurement Systems Governance Board (PSGB) Process.

T: Implement system change < 8 months after CCB/PSGB approval

O: Implement system change < 6 months after CCB/PSGB approval

HLO – 2

BO – 2

Data

Accuracy and Integrity

Enforce standard business rules and workflows to ensure data accuracy and integrity.

Percentage of data reported that matches the data within ACWS.

T: 95% of data reported to Federal Procurement Data System – Next Generation (FPDS- NG) and Defense Assistance Awards Data System (DAADS) matches data within

ACWS

O: 98% of data reported to FPDS-NG and DAADS matches data within ACWS

HLO – 3

BO – 3-1

Procure-to-

Pay Handshake 2;

Pre-Award Funds Check

System performs integrity checks that ensures validation and re-verification of data (at the line item level) to account for changes since receipt of a Purchase Request (PR). (Handshake 2)

Percentage of instruments for which funds-check validations are executed prior to award.

T: 98% of instruments within ACWS have funds-check executed prior to award

O: 99.5% of instruments within ACWS have funds-check executed prior to award

ACWS SOO 7

HLO #

Business Outcome

Title Business Outcome

Description Measurement Threshold Value (T) Objective Value (O)

HLO – 3

BO – 3-2

Procure-to-

Pay Handshake 3;

Integration with accounting systems

Obligations are posted accurately in the appropriate accounting system.

(Handshake 3)

Percentage of instruments that are accurately recorded within the appropriate accounting systems IAW established business rules.

T: 95% of obligation data is accurately and electronically recorded in the appropriate accounting system

O: 98% of obligation data is accurately and electronically recorded in the appropriate accounting system

HLO – 3

BO – 3-3

Accurate data exchange with external systems

Information shared and/or posted accurately in the appropriate system.

Percentage of instruments that successfully pass the Procurement Data Standard (PDS) validation.

T: 95% PDS

validation success rate

O: 98% PDS

validation success rate

HLO – 3

BO – 3-4

Prompt data exchange with external systems

Information shared and/or posted promptly in the appropriate system.

Average time to electronically distribute data to Electronic Document Access (EDA).

Transactions originating from 'disconnected state' should be measured from point of data-synchronization.

T: EDA Load Date < 24 hours (monthly average)

O: EDA Load Date < 1 hour (monthly average)

HLO – 4

BO – 4

Optimized and standard Business

Processes

A Contract Writing System that uses modern technologies to allow for configurable workflow and real-time collaboration using centralized services, standardized business rules, and standard data formats.

The percentage of business process models and templates that have been reduced, simplified or standardized as compared to the As-Is state.

T: 15% reduction, simplification or standardization

O: 25% reduction, simplification or standardization

ACWS SOO 8

HLO #

Business Outcome

Title Business Outcome

Description Measurement Threshold Value (T) Objective Value (O)

HLO – 5

BO – 5-1

Net Ready on

Nonsecure Internet Protocol Router

Network (NIPRNet)

A Contract Writing System that is maintained and sustained on the NIPRnet in both Continental United States (CONUS) and Outside

CONUS

environments.

Authority to Operate (ATO) granted for operations for NIPRNet

Joint Interoperability Certification granted for NIPRNet

T & O: ATO granted for operations on NIPRnet Joint Interoperability Certification granted for NIPRNet

HLO – 5

BO – 5-2

Net Ready on

Secret Internet Protocol Router

Network (SIPRNet)

ACWS that is maintained and sustained on the SIPRnet in both CONUS and

OCONUS

environments.

ATO on SIPRnet

Joint Interoperability Certification for SIPRNet

T & O: ATO granted for operations on NIPRNet Joint Interoperability Certification granted for SIPRNet

HLO – 6

BO – 6-1

Availability

System is operationally capable of performing assigned mission

Percentage of time that ACWS is operationally available (Uptime / (Uptime + Scheduled Downtime + Unscheduled Downtime)

T: 93.3% availability (monthly average) O: 96.7% availability (monthly average)

BO – 6-2

Restorability (Reliability)

System: Average amount of time it takes for the system to be restored from a catastrophic loss of data and system operation

Software: Average amount of time it takes for an ACWS process to be restored from a failure

System : Recovery Time Objective (RTO) & Recovery Point Objective

(RPO)

Software: Mean Time To Restore: Time starts after incident is logged;

diagnostic analysis is completed in parallel to ensure the problem is not derived from a network or hardware issue

T: RTO = 24 Hours RPO = 12 Hours

O: RTO = 8 hours RPO = 6 hours

T: 4 Hours

O: 2 Hours

BO – 6-3

Maintainability

Average amount of time it takes to efficiently correct defects and/or failures

Mean Time To Repair

(MTTR)

T: MTTR < 8 hours

O: MTTR < 4 hours

ACWS SOO 9

Table 3: ACWS Key Performance Parameters (KPPs)

Key Performance

Parameter Subfactors Threshold Objective

Operational Availability

HLO-6

Restorability (Reliability)

Recovery Time Objective (RTO) = 24 hours

Recovery Point Objective

(RPO) = 12 hours

RTO = 8 hours

RPO = 6 hours

Availability 93.3% availability (monthly average)

96.7% availability (monthly average)

Maintainability < 8 hours < 4 hours

Net Ready

(NR KPP)

HLO-5

Support to Military

Operations

95% Procurement Data Standard (PDS)

Validation Success Rate 98% PDS Validation Success Rate

Enter and be managed on the network

TBD (will be updated with the completion of the SV- 7 architecture document with initial Information Support Plan)

TBD (will be updated with the completion of the SV-7 architecture document with initial Information Support Plan)

Exchange Information 95% 98%

6.0 Contract Objectives

The ACWS Contract Objectives are to provide products and services to the Government based on a suite of COTS products, commercial standards practices, innovation, and risk management to meet the requirements in Attachment 0005, ACWS Requirements Trace Matrix. The Government seeks a COTS-CWS product currently in service with other Federal users, but will allow the use of limited, COTS software (e.g., third party) that is not currently in use within the federal Government, in order to provide a complete solution, with the greatest level of flexibility at the lowest level of risk that will allow end users to respond to emerging requirements without developing additional software.

This SOO is supplemented with other documents as attachments (e.g., Attachment 0007 Concept of Operations/Operational Mode Summary/Mission Profile, Attachment 0005 ACWS Requirements Trace Matrix, and Attachment 0008 Architecture Views).

These documents aid in describing the context of the requirements to satisfy the desired objectives/outcomes/results specified in this SOO along with performance metrics, measurements, and a Quality Assurance Surveillance Plan (QASP).

ACWS SOO 10

The Government is seeking the Contractor’s most creative and cost effective approach, timeline, and overall solution. The Government is providing preliminary and Notional information, as well as planning imperatives, to help the Contractor develop an effective solution that addresses the ACWS requirements. Therefore, a prescribed approach is not provided, nor is the Contractor expected to conform to the Government’s Notional planning baselines as long as the Contractor delivers the required solution while meeting or improving upon those baselines within the imperatives and constraints listed.

The Government has provided a preliminary list of Contract Data Requirements List (CDRLs) that the Contractor shall use, in whole or in part, to support its solution. The Contractor, in response to the SOO, shall provide a Performance Work Statement which includes comprehensive and cost effective CDRLs. The Government CDRLs may be tailored to the Contractor’s solution. The Contractor may recommend additional CDRL items, replacement CDRL items, or deletions of CDRL items. The Contractor shall provide a clear rationale for any combination of changes, additions, or deletions from the Government-provided CDRLs that the Contractor believes are prudent to support its unique solution.

The Government has provided within this SOO the following three Notional planning products: 1) Notional Program Schedule, 2) Notional Software Build Plan, and 3) CLIN structure and Notional Task Order Plan. These Notional products serve as the Government Planning Baseline and represent a minimal acceptable approach, upon which the Contractor should strive to improve. The ACWS program must meet all statutory requirements per DoDI 5000.02 as well as those in listed paragraph 9.0 Compliance References.

ACWS SOO 11

Figure 1: ACWS Notional Program Schedule

The ACWS Notional Program Schedule (Figure 1) provides an overarching view of the activities and events within the Government Product Management Office (PMO) oversight. The Contractor shall develop a unique program plan and schedule.

Flexibility and tailoring of the timelines for events, phases, milestones and the number of software builds depicted is expected within the confines of the schedule imperatives and constraints listed below and those in paragraph 8.0 of this SOO.

The following schedule imperatives and constraints have been defined for the ACWS Program Schedule:

• The Notional Program Schedule above identifies Milestone A as Authorization to Proceed – 1 (ATP-1). Unless waived by the Milestone Decision Authority, the time between ATP-1/Milestone A and Full Deployment Decision (FDD) must not exceed five (5) years (Ref. DoDI 5000.02, Table 4)

• System Builds/Capabilities and required interfaces can be delivered/provided earlier

• Initial Operational Capability (IOC) is achieved when ACWS (See Figures 2 and 3):

ACWS SOO 12

‒ Has been deployed and trained to at least one (1) Army Procurement command or sub-command (See Attachment 0011 Contracting Geographic Locations and Authorized Users)

‒ Can be used to execute basic procurement functions (as defined in Figure) ‒ Can successfully exchange data with all identified Federal and DoD systems (as defined in Figure 3) ‒ Can successfully exchange data with a minimum of one (1) Army Financial system (e.g., General Fund Enterprise Business System (GFEBS), Logistics Modernization Program (LMP), or Corps of Engineers Financial Management System (CEFMS))

• Each software build must include a developmental test and an operational test specific to the capabilities of that build

• System deployment activities, including user training, cannot take place during the fourth quarter of any fiscal year due to the contracting community workload at the end of the fiscal year

• Concurrency of similar activities across builds may limit Government resource availability to adequately support development, testing, training, or fielding

• A specific number of software builds is not mandated

• Post IOC, the combination of capability sets is not mandated

• Secure environment baseline will not be deployed until after IOC

All program planning follows the requirements for an Acquisition Category IA, Major Automated Information System (MAIS) (ACAT IAM). Milestone Decisions (MS) are redesignated as Authorization to Proceed (ATP) decision points and the required documentation will be tailored at each point.

ACWS SOO 13

The Notional Software Build Plan (Figure 2) provides the IOC and Full Deployment (FD) definitions along with Notional Builds for a phased approach for development and delivery of the ACWS capability and interfaces:

Figure 2: ACWS Notional Software Build Plan with IOC and FD Definitions

ACWS SOO 14

The IOC and FD with Interfaces are graphically depicted below (Figure 3):

Figure 3: ACWS Notional Software Build with IOC and FD Interfaces

ACWS SOO 15

The Contract Line Item Number (CLIN) structure is defined in Figure 4 with a Notional Task Order Plan approach as the baseline. While the CLIN Structure is set, the Contractor may provide a different set of Task Orders after TO 0001. When Figure 4 is combined with the Figures 2 and 3, Notional Software Builds, early achievement of interfaces and delivery of capability may adjust the number of builds and therefore adjust the number of Task Orders.

Figure 4: Contract CLINs and Notional Task Orders

* Figure 4 Notes:

a) CLINS for Program Management (PGM Mgt.) and Systems Engineering Management & Planning (SE Mgt & Planning) are projected to be included in each TO.

b) Support Task Orders may start in Option 1: 48 Month Ordering Period.

ACWS SOO 16

6.1 Program Management

The Program Management objective is to execute planned activities within cost, schedule, and performance parameters. Additional details are included in Attachment 0007 ACWS Concept of Operations/Operations Mode Summary Profile; Attachment 0008 Architecture Views; and any other applicable requirements documents as a basis for preparing a Contractor PWS, and CDRLs.

Program Management support includes:

a) Program Management – Establish and perform a comprehensive Program Management Plan (PMP) [CDRL A001] that describes the processes and procedures associated with how the program will be managed and executed, and ensures accurate and timely cost, schedule and performance information throughout the life cycle of the program.

b) Contractor Work Breakdown Structure (CWBS) – Define and implement a comprehensive Contractor Work Breakdown Structure [CDRL A002] and associated dictionary, compliant with MIL-STD-881C, which identifies all the Contractor activities to the lowest level of detail necessary to deliver the ACWS solution. See Attachment 0025 ACWS Cost and Software Data Reporting (CSDR) Plan to align the proposed CWBS elements with reporting requirements.

Identify any CSDR Plan modifications necessary to ensure alignment with the proposed ACWS solution.

c) Schedule Management – Prepare and implement a resource-loaded Integrated Master Schedule (IMS) [CDRL A003] that provides a comprehensive enterprise solution roadmap to include major milestones, program reviews, incremental software builds, test events, training, deployment to designated locations and sustainment activities, legacy system retirement and any other roadmap topics/items. The IMS shall be aligned with the CWBS.

d) Personnel Management – Resumes are neither required nor desired. In the Staff Levels Skill Mix Schedule (Attch. 15), Offerors are responsible for identifying Key Personnel / Key Positions (no names, no resumes) and the qualifications that they propose for those positions. Provide qualified staff with the requisite knowledge, skills, experience and certifications necessary to perform in the position to which they have been assigned to support the activities of the ACWS program to meet the cost, schedule and performance over the entire ordering period. The qualifications for those Offeror-identified positions are what Government expects to be committed to the program, and fulfilled if the individual serving in that position needs to be replaced. Notify the Government if one or more of the Key Personnel / Key Positions (Contractor identified), for any reason, become or is expected to become unavailable for work for a continuous period exceeding 30 calendar days, or is expected to devote substantially less effort to the work than indicated in the approved IMS or as initially planned. Submit to the Procuring Contracting Officer (PCO)/Contracting Officer Representative (COR), ACWS SOO 17 for approval, the résumé and any other required data of the qualified replacement Key Personnel / Key Positions.

e) Communications - Establish and perform formal and informal forums (e.g., program reviews, status updates, recurring reports, and metrics) to achieve program goals and reduce the overall level of required Government oversight for cost, schedule, and performance (to include: program management, financial management, technical management, contract management, data management, and subcontract management). [CDRL A004 Program Status Reports]

f) Risk Management - Establish and conduct a risk management process, in accordance with the Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, dated June 2015, which identifies and mitigates program and technical risks and provides for metrics to monitor program status and provide reports. [CDRL A005 Risk Management Plan (RMP)], [CDRL A006 Risk Management Status Report]

g) Quality Management - Perform quality assurance as a process that monitors the overall plan, procedures, and controls that the Contractor will use to provide and maintain a satisfactory quality system for the duration of the IDIQ. (Attachment 0016, Quality Assurance Surveillance Plan) [CDRL A007 Quality Assurance Program Plan (QAPP)]

h) Configuration Management - Conduct a comprehensive configuration management approach that ensures system integrity while changes are made to the system throughout the program lifecycle. [CDRL A008 Configuration Management Plan (CMP)]

i) Contract Funds Management - Establish a baseline, monitor, and report contract funds status. [CDRL A011 Contract Funds Status Report]. IAW DoDI 5000.02 and DFARS 252.234-7003, Notice of Cost and Software Reporting System, systematically collect and report actual contract costs to provide DoD cost analysts with needed data to estimate future costs. See Attachment 0025 ACWS Cost and Software Data Reporting Plan. [A013 Cost Data Summary Report (CDSR)]; [A014 Software Resource Data Report (SRDR)]; [A015 Functional Cost Hour Report (DD1921-1)]; and [A0016 Contract Business Data Report (DD1921- 2)].

j) Program Documentation Management – Develop and manage documentation in a consistent and appropriate form and format. This process shall be described in the PMP [CDRL A001]

k) Audit Readiness - Provide support to the Government to demonstrate audit readiness, respond to agency audits, inspections, and product assessments, and to achieve all necessary certifications

ACWS SOO 18

6.2 Systems Engineering Management and Planning

The Systems Engineering Management and Planning objective is to plan and manage all engineering tasks required to achieve a balanced set of activities, which include analysis, design, development, test and support functions, to satisfy ACWS requirements throughout the program life cycle. Additional details are included in the Attachment 0022 ACWS Systems Engineering Plan; Attachment 0023 ACWS Test and Evaluation Master Plan; Attachment 0005 ACWS Requirements Trace Matrix;

Attachment 0007 ACWS Concept of Operations/Operations Mode Summary Profile;

Attachment 0008 Architecture Views; and any other applicable requirements documents as a basis for preparing a Contractor PWS, and CDRLs.

Systems Engineering Management and Planning support includes:

a) Engineering Management - Perform management activities to oversee and support the analysis, design, development and test of the ACWS solution, including facilitating workshops, conducting meetings and technical reviews, providing the appropriate documentation, and ensuring compliance with DoDI

5000.02. [CDRL B001 Systems Engineering Management Plan (SEMP)]

b) Enterprise Architecture Management and Maintenance - Manage the development of solution-specific architecture viewpoints; maintain DoDAF architecture viewpoints to ensure the architecture remains consistent with current solution configurations and designs across all releases and sustainment; ensure compliance with the prevailing release of the DoD Business Enterprise Architecture (BEA).

c) System Performance Analysis and Reporting – Define performance metrics, (e.g., Technical Performance Measures in accordance with the ACWS SEP), collect performance data, perform analysis, and prepare reports. [B002 System Performance Reports]

d) Hosting Analysis – Monitor and analyze hosting environment infrastructure performance for classified and unclassified as well as disconnected operations to ensure continued operational availability; assess impact associated with additional capability; make recommendations, to include schedule and performance impacts, for all operating environments, when changes are required (e.g., for compute, network and memory storage capacity). [B003 Hosting Analysis Reports]

e) Operating Environments – The operating environment during the Risk Reduction phase may be hosted at a Government facility other than DISA and will not be continued beyond MS B as ATP-2. After ATP-2 the Government anticipates four

(4) operating environments on the NIPRNet: Development, Test, Production and Continuity of Operations (COOP). The Government anticipates three (3) environments to support the secure capability (i.e., Test, Production, and COOP).

All of these operating environments will be hosted at a Government facility. The Contractor will be responsible for configuration and deployment of the application

ACWS SOO 19

server software (e.g., Web, database), while the Government provided hosting facility will provide management and configuration of the operating system, tools and monitoring, system administration, and storage capacity. [CDRL B004 Operating Environment Requirements and Design]

f) Human Systems Integration – Ensure that the solution complies with Human Systems Integration in the System Acquisition, Army Regulation 602-2, January 27, 2015 or later, AR 73-1 Test and Evaluation Policy, Section 2-15.

g) Technical Review(s) – Conduct the necessary design reviews (e.g., Preliminary Design Review, Critical Design Review) to assess and validate the system and software design. [CDRL B005 Technical Review Package]

6.3 Solution Design and Development

The overall Solution Design and Development objective is to perform all analysis, design, development, test, and integration activities necessary for the successful delivery of the ACWS solution.

Solution Design and Development support includes:

a) Performing risk reduction efforts associated with maturing the “to be” business process workflow to be adopted by the Government, characterizing system performance, defining interface requirements at the data level, and developing a build schedule to deliver the ACWS solution.

b) Applying industry proven standards throughout the development life cycle to deliver a well-documented and validated solution resulting in user acceptance.

c) Developing the ACWS solution and associated system documentation.

d) Providing a secure operational environment based on the Risk Management

Framework (RMF) for DoD Information Technology (IT) and DoD Cybersecurity requirements in order to maintain and improve the confidentiality, availability, and integrity of the ACWS solution through detection, reaction and protection from both internal and external threats and vulnerabilities.

e) Implementing tools and procedures to facilitate access to data.

f) Conducting the necessary reviews to ensure validation of requirements, design, implementation and test products.

Additional details are included in Attachment 0005 ACWS Requirements Traceability Matrix; Attachment 0007 ACWS Concept of Operations/Operations Mode Summary Profile; Attachment 0008 Architecture Views; Attachment 0010 ACWS Interface Development Strategy and other applicable requirements documents as a basis for preparing a Contractor PWS, and CDRLs.

ACWS SOO 20

6.3.1 Solution Design Support

Solution Design support includes:

a) Global Analysis – Support the Government analysis to compare the COTS solution to the ACWS requirements; conduct Business Process Reengineering to evaluate potential business process changes to align with the COTS product;

identify system configuration and/or customization requirements. [CDRL B006 Fit/Gap Report] [CDRL B007 Business Process Design] [CDRL B008 Requirements Traceability Matrix]

b) System Characterization – Support the Government in conducting the following:

i. Technical risk and standards assessment to identify risks and provide mitigation strategies associated with end-to-end system performance, software limitation, security, legacy data access, interface development and integration [CDRL A006 Risk Management Status Report]

ii. Performance and scalability assessment to determine user capacity, data capacity, and computing resource requirements for hosting and provisioning at the Government designated hosting facility in preparation for Build 1. [CDRL B009 System Provisioning Document]

c) Interface Definition – Assess the Out-Of-The-Box (OOTB) ACWS solution against interface requirements; determine required interfaces or integration points to external and internal systems and partner systems; define data exchanges at the data format level; and document interface specifications.

[CDRL B010 Interface Control Document] [B011 Interface Requirements Specification]

d) Architecture Development – Develop business, system, and technical architecture artifacts (i.e., applicable DoDAF architectural viewpoints) and associated descriptions to support acquisition milestone documentation, Fit-Gap, Global Analysis and Blueprinting efforts solution design and test design. [CDRL B012 Architecture Viewpoints and Plan] [CDRL B007 Business Process Design]

e) Requirements Analysis – Analyze the ACWS requirements and decompose/derive requirements to the software level; allocate the requirements to the component level; update requirements document(s); determine optimal hosting infrastructure requirements for classified, unclassified, and disconnected operations and supporting system operations, and sustainment at the Government hosting sites. [CDRL B008 Requirements Traceability Matrix] [CDRL B011 Interface Requirements Specification (IRS)] [CDRL B013 Software Requirements Specification (SRS)]

f) Build Planning – Develop a comprehensive build plan that specifically references system functionality and system interface design. [CDRL B014 Build Plan]

g) System/Software Design – Conduct analysis of the global blueprint to identify and conduct build-specific design activities; develop specific functional, non-

ACWS SOO 21

functional (e.g. software restorability, responsiveness, usability) , and integration design artifacts required to enable efficient and effective software development activities; identify system constraints, limitations, and implementation dependencies [CDRL B015 Software Design Description (SDD)] [CDRL B016 Interface Design Description (IDD)] [CDRL B017 Database Design Document] [CDRL B018 Human Engineering Design Approach Document]

6.3.2 Solution Development Support

Solution Development support includes:

a) Capability Development/Integration – Develop/integrate the software services/modules/products identified during the analysis and design phases to complete the ACWS solution due to COTS product gaps.

b) Interface Development – Develop/configure interfaces with other systems to allow the ACWS solution to send and receive data electronically over the Government network; maintain data integrity; ensure compliance with financial auditability standards.

c) Software/System Integration – Integrate all the software solution components and deploy on the Government network.

d) Capability Configuration – Configure all system parameters to implement the defined business processes and capability design, to include infrastructure level parameters to meet performance requirements.

e) Development Test – Perform development testing at the component level and integration level to ensure all requirements have been met and that the system is ready for independent Government developmental and operational test.

f) Solution Delivery – Deliver and install the ACWS solution at the designated Government facility. [CDRL B019 Computer Software Baseline] [CDRL B020 Configuration Status Accounting Information] [CDRL B021 Software Version Description (SVD)]

g) Configuration Audits – Assist the Government in preparing, conducting, and documenting the results of Functional and Physical Configuration Audits.

(FCAs/PCAs) [CDRL B022 Configuration Audit Summary Report]

6.3.3 Cybersecurity and Program Protection Support

The Cybersecurity and Program Protection Support objectives are to conform to the DoD cybersecurity/RMF requirements, to plan and implement the protection of the system components, technologies, and critical program information from foreign collection, and cyber exploitation/insertion/attacks throughout the acquisition lifecycle.

The ACWS Government-developed Program Protection Plan (PPP) will be published after the contract award with the input from the Contractor. To ensure Contractors understand the program protection requirements, Attachment 0006 DASD Systems

ACWS SOO 22

Engineering, Program Protection Plan Outline & Guidance, v.1.0, Tailored for Defense Business Systems (DBS), June 13, 2013 is included to guide the preparation of a Program Protection Implementation Plan (PPIP) required to support the ACWS PMO’s Program Protection effort.

Cybersecurity and Program Protection support includes:

a) Cybersecurity Workforce - Identify, manage and integrate Cybersecurity workforce functions into the ACWS Risk Reduction Phase. Ensure all personnel performing cybersecurity functions or security controls are trained and certified in compliance with DoDD 8140.01 and DoD 8570.01-M.

b) Assessment and Authentication (A&A)/Cybersecurity Compliance – Support the RMF process and activities (e.g., Security Risk Assessment, Plan of Action and Milestones (POA&M)) to facilitate the security A&A of the system according to all relevant cybersecurity standards/directives/policies (e.g., DoDI 8510.01, NIST SP 800-30 Rev 1) and the associated security controls as defined in DoDI 8500.1 to ensure ACWS is fully accredited throughout the program lifecycle. This includes providing updates to the DoD Enterprise Mission Assurance Support Service (eMASS) system as required and providing supporting cyber security documentation for upload as artifacts in eMASS, mitigating all security risks and vulnerabilities found during A&A and during continuous monitoring and scanning activities. All vulnerabilities must be mitigated IAW DoDI 8510.01 based on the Category Level. Support the implementation of DoD/Army-directed Cybersecurity mandates such as Information Operations Conditions (INFOCONs), Information Assurance Vulnerability Alerts and Bulletins (IAVA/Bs) and all applicable vendor released security updates, fixes, patches and bundles for the COTS solution throughout the program lifecycle. Develop system documentation required for the Security Authorization Package. [CDRL B023 Risk Management Framework (RMF) Package]

c) Program Protection – Develop and update the mission Critical Functional Analysis (CFA), vulnerabilities assessments, risk assessments, identification and counter measurement implementations, demonstration of visibility into supply chain and Software Assurance for critical components, and update of CFA results and Program Protection risks and mitigations at each Technical Review (assuming the system contains no CPI). Develop and implement a Program Protection Implementation Plan (PPIP) that describes the Contractor's implementation of the Government-PPP. [CDRL B024 Program Protection Implementation Plan (PPIP)]

d) Software Assurance – Provide a plan to achieve and demonstrate the level of confidence that the software is reliable and functions as intended and that the software is free from security vulnerabilities and malicious code, either intentionally or unintentionally designed or inserted as part of the software, throughout the lifecycle. At a minimum, the plan includes countermeasures to prevent, detect, respond, and report to Government vulnerabilities in software;

ACWS SOO 23

continuous monitoring; and adheres to secure coding standards. Develop, document, and update Software Assurance Countermeasures Table 5.3.3-1 from Attachment 0006 DASD Systems Engineering, Program Protection Plan Outline & Guidance, v.1.0, which summarizes the planned and current state of a program's software assurance activities in accordance with the table description provided in the Defense Acquisition Guidebook section 13.7.3. Verify all software code against the Common Weakness Enumerations (CWE), Common Vulnerabilities and Exposures (CVE), and Common Attack Pattern Enumeration and Classification (CAPEC). Support the Government to identify and remediate vulnerabilities or weaknesses in the COTS solution and software design/coding.

Provide visibility into software versioning down to the lowest feasible software component level. Mitigate new, critical vulnerabilities detected no later than 30 days after detection, depending upon the criticality of the vulnerability and whether the system is in Production or not. Additionally, ensure vulnerabilities are successfully mitigated during the build development period of the affected software and no later than the established release/deployment date of that same software.

e) Software Compliance – Ensure software complies with all DoD Instructions/Federal Standards (e.g., DoDI 8500.1, DoDI 8551.1, and Federal Information Security Modernization Act of 2014 (FISMA)). Design, develop and implement secure software and configurations through applying applicable DoD Secure Technical Implementation Guides (STIGs), checklists, security guidance for vendors, and industry best practices as provided in the CAC-enabled DISA Information Assurance Support Environment (IASE) web site. [CDRL B024 Program Protection Implementation Plan (PPIP)] [CDRL B025 Critical Functional Analysis]

f) Incident Management – Provide Incident Management and Escalation services to detect and record incidents, send security alerts, prevent onset of threat and vulnerability that results in catastrophic or critical failure, and restore the system to a normal operational state.