Attachment_01_-_GAP_CIE_Sustainment_SOW_v.2_(Final).pdf

Attachment 01

GLOBAL ADAPTIVE PLANNING COLLABORATIVE INFORMATION

ENVIRONMENT (GAP CIE) SUSTAINMENT

STATEMENT OF WORK (SOW)

Solicitation # FA8707-12-R-0014

Date: 31 May 2013

Solicitation: FA8707-12-R-0014 Attachment 1, Page 2 of 24

Document Change History

Date Change # Change Author Change Summary

Dd mmm

YY

0 Solicitation SOW

Solicitation: FA8707-12-R-0014 Attachment 1, Page 3 of 24

INDEX

1. Contents

1. Scope

1.1. Background

1.2. Overarching Objectives

1.3. System Description

1.4. Operational Functionality

1.4.1. Collaborative Campaign/Contingency Planning (C/CP)

1.4.2. Collaborative Crisis Action Planning (CAP)

1.4.3. Decision Support

1.4.4. System Training

1.4.5. Sustainability

1.4.6. Net-Ready

1.5. Acquisition Approach

1.6. Maintenance

1.7. Enhancements

1.8. Modifications

1.9. Applicable Documents

2. Description of Work

2.1. Software Delivery

2.2. Program Management

2.3. Meeting Support

2.4. Systems Engineering, Architecture and Integration (SEA&I)

2.5. Requirements Management

2.6. Requirements Analysis

2.7. Architecture Analysis

2.8. System Integration

2.9. Contractor Developmental Test & Evaluation (CDT&E)

2.10. GDT&E Integration Support

2.11. Information Assurance

2.12. System Security Engineering (SSE)

2.13. Certification and Accreditation

2.14. Training

2.15. Configuration Management

2.16. Technical Reviews

2.16.1. System Requirements Review (SRR)

2.16.2. Design Reviews

Solicitation: FA8707-12-R-0014 Attachment 1, Page 4 of 24

2.17. Additional Support Requirements

2.17.1. On-site Support

2.17.2. Exercise and Contingency Support

3. Place of Performance

4. Security

4.1. Clearances

4.2. Handling of Classified Material

5. Government Furnished Property

6. Equipment Purchases

7. Development Agreements

8. Contractor Manpower Reporting

9. Other Direct Costs (ODC)

10. Travel

11. End of Contract Transition

12. Studies

12.1. Special Studies and Requirements Analysis

12.2. Demonstration Support

13. Patch Process

Acronyms

Solicitation: FA8707-12-R-0014 Attachment 1, Page 5 of 24

1. Scope

1.1. Background

The Global Adaptive Planning Collaborative Information Environment (GAP CIE) is a web-based, collaborative

Joint Operation Planning (JOP) tool that supports distributed participants in multiple security enclaves (primarily

Secret Internet Protocol Router Network (SIPRNET) and Joint Worldwide Intelligence Communication System

(JWICS) at present). The JOP Process (JOPP) activities that lead to an executable order are accomplished collaboratively among subject matter experts regardless of their physical location. This is done in coordination with the appropriate geographic commanders and is accelerated through a structured, portal-based application that orchestrates data and information to deliver more options, with improved quality, faster. Consequently, GAP CIE provides the Title 10 Combatant Commanders (CCDRs) with global collaborative planning capabilities that are called for in the 2011 Unified Command Plan (UCP), which reads, “Commanders charged with synchronizing planning lead a global collaborative planning process that includes other Combatant Commanders, Combat Support

Agencies (CSAs), and applicable Defense agencies and field activities in support of a designated global mission or campaign plan.”

While GAP CIE was originally designed as a planning capability for United States Strategic Command

(USSTRATCOM), the capability is now applicable to a broader range of organizations and missions due to its doctrinal (Joint Publication 3-0 / 5-0) foundation for JOP. The Joint Requirements Oversight Council (JROC) directed in JROC Memorandum (JROCM) 016-09 that GAP CIE become “the Department of Defense (DOD)

Program of Record for joint Course of Action (COA) development at the CCDR/Strategic level.” GAP CIE’s support for decision making and the situational awareness aspects of JOP have become important partners for the collaborative COA development capability.

1.2. Overarching Objectives

The purpose of the GAP CIE Sustainment Program is to provide sustainment, enhancement, and modification deliveries to fielded GAP CIE capabilities. Software deliveries must be innovative in their openness, flexibility, scalability, and extensibility so they can continue to incorporate tools to support the production of assigned campaign/contingency plans and orders, UCP taskings, and Guidance for the Employment of the Force (GEF) assigned tasks. Joint COA development is crucial to the JOPP, as well as a core capability within the ongoing evolution of the Joint Operation Planning and Execution System (JOPES) to the Adaptive Planning and Execution

(APEX) system via a portfolio of policies, processes, applications, and authoritative data. GAP CIE strives to fulfill the Adaptive Planning (AP) Roadmap II vision of an integrated planning architecture that is able to respond to a dynamic operational environment.

The AP Roadmap II describes a modernized process that will “merge [deliberate] and crisis planning into a single end-to-end planning and execution, ‘living plans’ construct.” The Secretary of Defense directed “the melding of planning and execution into a cohesive system that delivers relevant, comprehensive, and feasible plans that can seamlessly transition to execution.” GAP CIE will support this ongoing evolution, as a core system that exchanges information and services with other existing systems to the greatest extent possible, via compliance with the Joint

C2 Objective Architecture and other community standards. The need to interoperate with technical initiatives such as the Joint C2 Common User Interface (based on the Ozone Widget Framework) also shapes sustainment requirements.

The effects analysis capabilities of the system will be operated and sustained by integrating or incorporating tools that not only address best-estimate performance and effects (Integrated Crisis Early Warning System (ICEWS), et.

al.), but also plausible uncertainties in planning parameters (effects-based). The system will be capable of conducting analyses at varying levels of detail, integrating data at varying stages of completion.

GAP CIE will reuse and refine valuable parts of the existing planning functions to support new mission areas, with reengineering to increase speed and efficiency at the user interface. One recent implementation of this approach is the Dashboard capability, which allows users to construct flexible situational awareness views through the addition of customizable gadgets to a canvas. These gadgets provide connections to authoritative data sources and the GAP

CIE planning environment, with visualization in multiple forms. Enhancing the Dashboard capability to provide more gadget types, more data sources, and better performance is expected to be a major focus of this sustainment effort.

Solicitation: FA8707-12-R-0014 Attachment 1, Page 6 of 24

The system will incorporate decision support tools that provide better insight into the increasing array of military and non-military options being proposed and organized by the system. This insight will include the confidence or uncertainty bounds of the plans, and is to be understandable by commanders, planners, and systems and intelligence experts who support the planning process. The decision support capability will also feed display capabilities provided by other programs.

The GAP CIE architecture must remain flexible, extensible and scalable to meet evolving CCDR and national decision requirements, and shall support the CCDRs within a common Command and Control (C2) framework.

Affordability and its interaction with these capabilities is also a consideration.

1.3. System Description

GAP CIE is comprised of two functional components supported by commercial off-the-shelf (COTS) software products: the GAP CIE planning environment, and the Global Situational Awareness Tool (GSAT). GSAT provides situational awareness of global events in a sharable, user-defined operational picture for viewing geospatial, temporal, relational, and tabular COA planning data. GSAT allows a look at a battlespace and permits the visualization of real data from authoritative systems of record and other approved sources. The GAP CIE portion provides Deliberate Planning, Crisis Action Planning, and Decision Support tools. Both allow subject matter experts to share situational awareness and collaboratively build integrated, macro COAs. The system automates the construction of orders, messages, and status and decision briefs, freeing planners from format management and focusing their efforts on plan and information quality.

GAP CIE has transformed the way CCDRs plan and assess global and theater operations. The system has advanced global adaptive and collaborative planning capabilities to support Strategic Deterrence (nuclear, conventional, and non-kinetic); Global Strike; Information Operations (IO); integrated missile defense (IMD); Space Operations;

global Intelligence, Surveillance, and Reconnaissance (ISR); and other advanced missions.

Integration of third-party tools, such as Joint Capability Technology Demonstrations (JCTDs), existing operational systems, or other pilots, is a major source of specialized capabilities in GAP CIE. Two significant examples of such integration are the Theater Operational Planning and Assessment Service (TOPAS) and the Integrated Crisis Early

Warning System (ICEWS). GAP CIE leveraged TOPAS as a reference implementation (since its code was not suitable for direct reuse) to create its Plan Design and Assessment (PD&A) capability, which includes functions previously referred to as effects planning.

ICEWS is a Defense Advanced Research Project Agency (DARPA) Science and Technology (S&T) project (2007-

2011) for analyzing Human, Social, Cultural, and Behavioral (HSCB) interactions on a global scale. When the integration is complete, GAP CIE users will access ICEWS functionality, in addition to other data sources, to establish CDR Situational Awareness (SA); to analyze events and forecast alternate futures; to monitor HSCB trends in a country or area of responsibility (AOR) that would justify increased Combatant Commander (CCDR) focus, trigger an update to existing campaign/contingency plans and/or the beginning of Crisis Action Planning (CAP); and aid in plan assessment to include monitoring real-time sentiment analysis.

1.4. Operational Functionality

This section describes GAP CIE’s operational functionality as a set of capability areas. Each capability area has Key

Performance Parameters (KPPs), with associated thresholds and objectives, as defined in the ISPAN Modernization

Capability Development Document (CDD) and validated in JROCM 092-10. There are a number of other attributes

(OA) and Key System Attributes (KSA) as well. In the Technical Requirements Document (TRD), the capabilities were detailed and designated to a development increment. During transition to Operations and Sustainment (O&S) of the system all KPP, KSA, and OA capabilities were assessed and degree of completeness determined. Fielded capabilities shall be maintained, at a minimum. The following is a summary of the Increment 2 KPPs:

Solicitation: FA8707-12-R-0014 Attachment 1, Page 7 of 24

1.4.1. Collaborative Campaign/Contingency Planning (C/CP)

Support a plans library with intelligent search capabilities; support early phases of deliberate planning , including

In-Process Review (IPR) A.

1.4.2. Collaborative Crisis Action Planning (CAP)

Support a collaborative environment that facilitates joint operation planning and meets COA development timelines specified in Operation Plan (OPLAN) 8010, Global Strike Joint Capabilities Document (17 April 2006), and the

Joint Strategic Capabilities Plan. End state-objective-effect-action/task (Effects Planning) plans are displayed geospatially, temporally, and/or as task relationships in a manner that supports the joint operation planning process.

1.4.3. Decision Support

Support a customized, user-defined geospatial and temporal visualization tool to perform continuous analysis of the operational environment with the capability to access, generate, and display combat support to land, maritime, air, space, and cyberspace components. Web service development and enhancements shall conform to Net-Centric

Enterprise Services (NCES) Enterprise Service Management (ESM) and other relevant standards. Support GAP

CIE’s expanding consumption of other programs’ web services in various forms, with a responsive process for dealing with web service changes or problems.

1.4.4. System Training

Support GAP CIE end user, super-user, trainer, and administrator training and training materials. Maintain existing training and help materials with updates that account for each software change.

1.4.5. Sustainability

Support a growing, global community of users, interact rapidly with users, and provide a high degree of availability, including in a Continuity of Operations (COOP) situation on both SIPRNET and JWICS. Maintain or improve system performance (as experienced by end users) with each software change. Future sustainability enhancement goals will include robust COOP support and cross-domain security solutions.

1.4.6. Net-Ready

Support systems engineering and architecture improvements in compliance with Joint Command and Control, Adaptive Planning and Execution community, and DoD net-centric initiatives.

1.5. Acquisition Approach

GAP CIE employs an incremental acquisition strategy, as well as an incremental enhancement and test approach because of the changing CCDR planning and analysis environment. The baseline capability was delivered in a series of spiral deliveries; maintenance drops and enhancement/modification deliveries shall follow a similar pattern of iterative software improvements.

1.6. Maintenance

The primary goals of maintenance work are to resolve Deficiency Reports (DRs) and improve system performance.

The software lifecycles for maintenance drops intentionally overlap, with up to four drops in different phases of the lifecycle at any given time. Depending on funding levels, maintenance drops may be delivered as frequently as every four months.

1.7. Enhancements

Joint Publication 5-0, as updated in August 2011, resurrected the term “deliberate planning” for the activity of creating and maintaining campaign and contingency plans. However, for consistency with previous program documents, GAP CIE has opted not to rename the KPP or its associated capability area.

Solicitation: FA8707-12-R-0014 Attachment 1, Page 8 of 24

Drops may also include capability enhancements requested by users or using organizations. Enhancements are considered part of system sustainment because they keep the existing applications in step with evolving operational needs. Integration of third-party applications or tools may be considered either enhancements or modifications (see below), depending upon scope.

1.8. Modifications

Significant customer-requested modifications could add development work. Development deliveries would be in addition to the drop schedule, but aligned with it such that a development package and its nearest drop could be tested and integrated at the same time.

The capabilities associated with each KPP in the CDD, and their associated identified requirements, are further detailed in the TRD (classified SECRET/REL). The Increment 2 portion of the TRD will define the intended context for maintenance updates.

1.9. Applicable Documents

The Contractor shall ensure requirements are accomplished in accordance with (IAW) the following applicable documents, in addition to documents listed elsewhere in this SOW:

Current ISPAN Systems Engineering Plan (SEP)

IA Docs/Regs—See paragraph 2.12

DoD Open Technology Development Roadmap

Net-Centric Enterprise Solutions for Interoperability (NESI) http://nesipublic.spawar.navy.mil/

Configuration Management Plan

Joint C2 Objective Architecture 2.1 (or current version)

GAP CIE Requirements-Development Process

Joint Pubs 3-0 and 5-0

2. Description of Work

2.1. Software Delivery

The contractor shall provide maintenance and enhancement software deliveries in accordance with the processes outlined in the GAP CIE SOW and the GAP CIE Joint Requirements/Development Process. The Contractor shall deliver to the Government any developed source code, computer software and/or technical data to include scripts, configuration files, Software Version Description (SVD), build instructions, and identification of development tools used. Build instructions shall include identification of all dependencies (libraries, Dynamic Link Library (DLLs), compilers, etc.) and tool configuration instructions to include tool data files and database files as applicable.

Deliveries shall be according to an agreed-upon schedule for each delivery order, ranging from small, monthly deliveries to large, less frequent deliveries in the event the program receives additional funding.

The Contractor shall be responsible for establishing a process to ensure the Government approves the use of any proprietary or Free and Open Source Software (FOSS) to include commercial products (including, but not limited to, operating systems (OS), graphical user interfaces, patches, and compilers). The Contractor shall be responsible for maintaining any FOSS used within their baseline.

The Contractor shall deliver incrementally tested and approved updates to software as required. The Contractor shall also provide initial and follow-on recommended software changes founded upon engineering analysis. The

Contractor shall make every effort and maximize use of commercial off the shelf (COTS) and Government off the shelf (GOTS) solutions that meet GAP CIE requirements. This will include reuse of software components/services developed by other DoD programs if applicable.

The contractor shall maintain a staff with the appropriate qualifications, certifications, skills, and experience to successfully complete GAP CIE software deliveries.

CDRL

COTS/FOSS/GOTS Baseline, CDRL A017 http://nesipublic.spawar.navy.mil/

Solicitation: FA8707-12-R-0014 Attachment 1, Page 9 of 24

2.2. Program Management

The Contractor shall plan, implement, apply, and maintain program management expertise to fully address all program management tasks, events, processes, and products associated with all activities and phases under this

SOW. The Contractor shall provide monthly and cumulative spending reports against a pre-established budget baseline (Contract Performance Report Format 1) in both dollars and hours. The Contractor shall not deviate from the Program Office Work Breakdown Structure (WBS) without approval . The Contractor shall provide timely, accurate, and relevant technical, cost, schedule and risk assessments to the Government. The Contractor shall provide in-depth Government visibility into the program’s management and status/issue tracking. The Contractor shall support management processes that will allow the PMO to evaluate impacts to cost, schedule and performance in both the baseline and enhancement environment resulting from evolving requirements with the goal of maximizing content delivery at minimum, repeatable cost. The Contractor’s management processes shall link together cost, schedule and requirements in order to examine changes to priorities and to allow the PMO to analyze impacts of these changes with minimal Contractor involvement, prior to directing formal change processes.

Program Management will be instrumental to the success of each software delivery, and subsequently the overall success of the program. At a minimum, Program Management processes and activities shall encompass the following areas:

Program planning and communication.

Program monitoring, control, and issue resolution.

Resource planning and allocation including budgets.

Quality Assurance

Measurement and analysis including establishing management indicators for early problem detection. These indicators should be consistent with the metrics identified in the Program Office

Systems Engineering Plan (SEP).

Configuration management.

Minimize the risk of software obsolescence.

Milestone and progress reviews.

Budget control, reporting, and management.

Schedule and technical control, critical path management, reporting, and management.

Continuous Risk and Opportunity Management.

CDRLs

Contract Performance Report, CDRL A009

Program Management Review Package, CDRL A010

Data Accession List, CDRL A013

2.3. Meeting Support

The Contractor shall participate in meetings as requested by the Government, including but not limited to GAP CIE

Integrated Product Team (IPT) meetings; program management reviews (PMRs); technical interchange meetings

(TIMs); configuration control boards (CCBs); Deficiency Review Boards (DRBs) and software lifecycle related reviews and meetings.

The Contractor shall support a participative requirements-development process that closely involves the

Government during all phases of the software lifecycle. Development In-Process Review (IPR) sessions shall be held on an as-required basis to allow for the Government and Contractor to clarify and collaborate on requirements and the implementation of technical solutions. The Development IPR process is important as it allows for continuous Government involvement and guidance during the execution of a delivery in order to minimize software errors found during testing. Functional Manager (FM) involvement is vital to successful Development IPR meetings and hands-on demonstrations, and face to face interaction is also critical.

CDRL

Progress Demonstrations, CDRL A011

Solicitation: FA8707-12-R-0014 Attachment 1, Page 10 of 24

2.4. Systems Engineering, Architecture and Integration (SEA&I)

The Contractor shall follow the ISPAN Program Office SEP. The rest of this section describes areas of particular emphasis or customization for GAP CIE.

The Contractor’s product team shall utilize systems and software engineering processes equivalent to Software

Engineering Institute (SEI) Capability Maturity Model Integration (CMMI) Level 3 certification rating.

The contractor shall create an approach that encourages adaptive software improvement, and that improves the product overall.

The development approach shall support the rapid delivery of enhancements and modifications, with regular functional design reviews (such as Development IPRs) with the functional managers.

Architecture updates are expected to continually improve performance from the previous update, or at minimum not degrade existing performance. Architecture product and configuration changes must support the existing functionality and user base, while not limiting future product or user base expansion.

No delivery will degrade GAP CIE’s user-facing functional capabilities. Any functional improvement delivered via this contract shall become the new user-facing functional standard for all future deliveries. All changes that decrease functionality, to include system performance, shall be documented changes prior to delivery order award. Changes to existing capabilities or performance expectations not documented prior to delivery order award shall be considered new deficiencies as a result of the Contractor’s effort.

The Contractor’s proposed solutions shall require a migration strategy that deals with existing software and data.

The proposed strategies must take into consideration CCDR directed integration efforts for subsystems and third-party capabilities.

The Contractor shall maintain the software code as unclassified to greatest extent possible, with any classified sections built and delivered as optional stand-alone additions to the GAP CIE deployment.

The Contractor shall value warfighter end-user system performance, under operational load, as its performance priority. The Contractor shall apply best practices with regard to web page development and implementation, targeting maximum user-facing page generation and rendering speed, as the environment and information assurance

(IA) regulations allow. For any performance requirements that cannot be met based on external constraints, the contractor shall demonstrate and document that their code has, to the greatest extent possible, reduced the impact of the external system performance, and no affordable amount of contractor effort would improve the performance.

The contractor shall consider other performance guidance in addition to the above to improve overall performance.

CDRL

Software Development Plan, CDRL A001

2.5. Requirements Management

The Contractor shall consider requirements to be additive in nature toward the GAP CIE capabilities. New fixes, refinements, and enhancements shall not remove, limit, or degrade user-facing capabilities (including system performance) present in the existing baseline. Exceptions shall be permitted only prior to task award and shall be as agreed to during negotiation and clarification with the Government.

The Contractor shall consider and account for the deployment environment of GAP CIE, and identify any implementation issues that affect or limit any enhancements. All new performance requirements shall assume a software-first improvement approach, as opposed to a hardware-first solution, to satisfy contract performance requirements.

2.6. Requirements Analysis

The Contractor shall, in the course of their requirements development, produce screen mockups for any functional enhancements to GAP CIE. The screen mockups shall be revised for any clarified or removed functionality as a result of requirement analysis so that a traceable development baseline is established. The Contractor shall not create mockups for work that does not change the functional flow of a task, unless the task was blocking functionality from what would be normally expected by the user interaction.

Solicitation: FA8707-12-R-0014 Attachment 1, Page 11 of 24

The Contractor shall maintain the overarching system requirements outlined here as general design principles. While not development tasks, these principles are expected to be implemented in all proposed solutions. These principles include, but are not limited to:

The contractor shall not degrade the functional system capabilities established in any previous delivery, except where agreed to prior to task award.

The contractor shall not degrade the user-facing page load and render times measured in any previous delivery, except as agreed to prior to task award.

The contractor shall not decrease the system user capacity measured in any previous delivery, except as agreed to prior to task award.

The contractor shall not decrease the system stability as measured in any performance test in a previous delivery.

If a data record is created, the ability to modify, delete, sort, and search for the record is also required.

If an existing data record is tasked to be modified in any way, all system usage of that modified record is expected in the task, including but not limited to impacts to online briefings and briefing export capabilities.

Latitude and Longitude are always N/S/E/W, never negative and positive.

If a data record must be entered in a particular format, a sample of the format must be presented next to the data record entry field.

For data entry windows, open a pop-up to display the content to the greatest extent possible. These windows should be as consistent as possible throughout the system, both in layout and functionality (such as spell-check).

Provide an hourglass or some other feature for all potentially long-running operations to let the user know the system is executing the task and not locked up.

All functions shall work on the first try, every try.

The Contractor shall include bounds and validity checking for all data entry fields created or edited in the course of task execution, including null input, excessive character input, invalid character input, excessive file upload, and insecure character string input.

All JavaScript errors are considered to leave the system in an unstable and unpredictable state resulting in a local stop test and browser restart. This leads to a CAT 1 DR.

The Contractor shall approach and fulfill all requirements from an operator’s perspective with usability in mind, save for obvious back-end enhancements. This shall include the operational suitability of the specified requirements.

2.7. Architecture Analysis

The Contractor shall be responsible for the GAP CIE product architecture, while the government will be responsible for the product deployment infrastructure. The Contractor may prescribe the system architecture down to the server

COTS and product configuration. The Government is responsible for the physical deployment of the infrastructure, including hardware product selection and specification, networking, and number of servers deployed. The contractor may be asked to support government analysis of any items in the government’s area of responsibility.

The Contractor shall make part of all design reviews, a system scalability check for requirements and proposed solutions that may cause dramatic storage growth or performance impact. The Contractor shall make part of all design reviews, mock-ups in order to communicate/demonstrate capability implementation and gain FM input/feedback on products the GAP CIE system may ingest or produce (e.g. Keyhole Markup Language (KML) imports or Portable Document Format (PDF) generation, etc.). The Contractor shall make part of all design reviews, any implementation changes that increase internal system network calls or GAP CIE system to user interface client calls, with a focus on minimizing and reducing traffic. The Contractor shall consider as an overarching objective the need to always maintain or reduce the usage of any networks, virtual or physical, in the GAP CIE system.

Sustainability in terms of effort and cost shall be determined as part of any architecture changes, especially with regard to COTS changes.

2.8. System Integration

The Contractor shall include code baseline merges and data cutover transition scripts and build configuration instructions to be part of contracted efforts. Each effort shall stand alone and not depend on other contract efforts or

Solicitation: FA8707-12-R-0014 Attachment 1, Page 12 of 24 funding lines to complete the full delivery of the contracted capabilities. The database cutover scripts provided shall be considered valid Government Developmental Test and Evaluation (GDT&E) testable deliveries and thus capable of drawing a CAT-1 DR in the event of a cutover script failure so long as the Contractor receives a copy of the finalized classified Government database from the previous delivery. The configuration and installation instructions shall be considered GDT&E testable deliveries in all cases and thus capable of drawing a CAT-1 DR if the instructions as delivered omit or misstate a step that prohibits system installation and configuration.

Deliverable End Item, CDRL A012

2.9. Contractor Developmental Test & Evaluation (CDT&E)

The contractor shall plan, prepare, and conduct tests to demonstrate that it has met all technical requirements, with no adverse effects on existing capability, including IA software coding practices IAW Government policies and procedures. Regression testing is required to validate there is no loss of existing capability. Automated testing is encouraged but not required. Testing is expected to be biased toward the most positive user experience, especially including ease of use. Workarounds proposed during software testing and defect rating shall be judged in this manner.

For each delivery, the contractor shall conduct CDT&E in accordance with the SEP and Test and Evaluation Master

Plan (TEMP). Test-related tasks include the following:

Test Planning. The contractor shall prepare a delivery Software Test Plan (STP) defining test cases and other planning information. The STP shall include a Requirements Traceability Matrix (RTM) which defines test requirements based on any requirements documents provided by the Government, and the specific release requirements specification, technology refreshment, and user defined thresholds. Test cases shall be defined to verify detailed software requirements. The contractor shall coordinate the draft STP with stakeholders through the Government Integrated Test Team (ITT).

Test Procedures. The contractor shall prepare test procedures that implement the test cases defined in the test plan. These test procedures will be approved by the Government ITT.

Test Preparation. The contractor shall perform preparatory activities to define test databases, emulate components and interfaces, train test personnel, configure facilities, and conduct dry runs of procedures, as defined in the test plan.

Test Readiness. The Contractor shall conduct a system level Test Readiness Review (TRR) in coordination with the ITT that demonstrates readiness to enter system level contractor testing. The TRR will allow the

Government to assess Contractor readiness to proceed to CDT&E. A Contractor representative shall brief the results of development and CDT&E dry-runs and fulfillment of test entrance criteria:

- All applicable previous technical review exit criteria and key issues have been satisfied in accordance with an accepted plan.

- All functional, unit level, subsystem, system integration, and qualification testing with the final versions of the software configuration items required to support system Developmental Testing have been satisfactorily completed.

- All applicable test plans, test cases (to include abuse cases and IA Application Penetration testing), and test procedures have been made available for participants to review.

- All previously identified and documented IA risks and documented design non-compliance have corresponding approved corrections and/or mitigations.

- All known discrepancies have been identified, provided to the participants to make a maturity determination, and dispositioned in accordance with the test plan.

- All required resources (people, facilities, test articles, test instrumentation) have been identified and coordinated to support the planned tests.

- Roles and responsibilities of all test participants have been defined and accepted.

- An agenda has been developed and sent to all participants prior to the review.

- The software metrics provided to the PMO to manage the software program were also provided to the software subject matter experts.

Solicitation: FA8707-12-R-0014 Attachment 1, Page 13 of 24

Test Conduct. The contractor shall conduct CDT&E in the contractor test facility in accordance with the STP and test procedures. The contractor shall validate that CDT&E exit criteria have been met on Government test resources for each delivery within the USSTRATCOM building. System testing shall be repeated until all test procedures can be successfully executed with no Category 1 deficiencies. The Government will ensure required test resources are available in the USSTRATCOM building for contractor access at the beginning of CDT&E.

Test Exit. The Contractor shall conduct a system level test exit review in conjunction with a Government-led

TRR that demonstrates readiness both to exit system level contractor testing and to enter GDT&E. A

Contractor representative shall brief the results of CDT&E and fulfillment of test exit criteria. The contractor shall consider CDT&E complete when the following conditions are met:

- All Category I DRs, defined in accordance with Air Force T.O. 00-35D-54, have been verified closed.

- All Category II Urgent DRs have been reviewed by the Government.

- All CDT&E test procedures have been satisfactorily accomplished.

- System performance (speed and capacity) has been measured and validated against the pre-determined expectations

- No Security CAT I problems exist, as defined by DoD Instruction (DoDI) 8510.01 which adversely affect system security and mission accomplishment, and all Category II, Urgent and below Problem Reports (PRs) have documented workarounds.

- All updates to Defense Information Systems Agency (DISA) application security and development Security

Technical Information Guide (STIG) have been delivered to Government.

- Hewlett Packard (HP) Fortify Source Code Analyzer source code scan files have been delivered for complete code base.

Test Analysis and Reporting. The contractor shall analyze test results, record defects, schedule retest, and document final results in the Software Test Report (STR). The contractor shall provide a test exit brief to the

Government, demonstrating that it has successfully tested all test objectives. Final test reports require approval by the Government. The Contractor shall provide STRs with each new/modified software upgrade and revision during field testing and the O&S phase.

Test Data. The contractor shall provide the Government access to all Test & Evaluation data as required.

CDRLs

Software Test Plan (STP), CDRL A005

Software Test Description (STD), CDRL A006

Software Test Report (STR), CDRL A007

IA Test Product/Report, CDRL A016

2.10. GDT&E Integration Support

Support to Government:

The contractor shall provide integration support to the Government during GDT&E. Support shall include technical consultation to resolve integration problems associated with the deployment of the software. This support shall include technical support during normal work hours. GDT&E support also includes DR workoff for DRs identified during GDT&E.

Schedule:

The length of GDT&E support will vary depending on the size and complexity of the delivery but will normally not exceed 90 days. The Government will specify the length of GDT&E in the RFP for the delivery. GDT&E will end when all CAT I DRs (as defined in T.O. 00-35D-54) found within the specified GDT&E period, regardless of when they were introduced into the system, have been closed. GDT&E may be condensed if/when the Government finds no CAT I DRs and/or the Contractor fixes all, and introduces no additional, CAT I DRs in subsequent patches. In the event the Government determines to field a delivery prior to all identified CAT I DRs being closed, the contractor shall still be responsible for resolving all CAT I DRs for that delivery.

As DRBs are held, the Government will identify a list of opened DRs to the contractor. The contractor shall minimize patches during baseline testing which disrupt the Government’s test schedule. Fixes to the Contractor’s baseline are expected during GDT&E, but the delivery of any patch to the Government’s GDT&E baseline shall be at Government PMO direction only, which should consider Contractor recommendations for patches that improve

Solicitation: FA8707-12-R-0014 Attachment 1, Page 14 of 24 the testability of the system during GDT&E. The Government’s ideal test schedule consists of a single software delivery at GDT&E TRR and a final patch delivery to close out GDT&E.

2.11. Information Assurance

The Contractor shall comply with all current DoD and USSTRATCOM cyber security and ISPAN IA Branch IA directives, instructions and policies to include best practices and countermeasures. Under the processes, the

Contractor shall also engage in efforts to enhance all aspects of cyber security. Threats and vulnerabilities, IA initiatives, requirements, priorities, and investments that aid in designing IA from the beginning and building in a defense-in-depth strategy for IA shall be an integral part of the entire software life cycle.

The Contractor shall take into consideration the following USSTRATCOM, United States Air Force (USAF), DoD, and National Institute of Standards and Technology (NIST) policy directives and guidance (including any updates) when architecting, designing, maintaining, and renewing GAP CIE’s DoD accreditation.

SI 301-6, Information Assurance

DODD 8500.2 Mission Assurance Category (MAC) 1 Checklist

Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic

Modules

DISA Application Security and Development STIG

DISA Application Services STIG(s)

DISA Database STIG(s)

DISA Webserver STIG(s)

DISA OS STIG(s)

CJCSM 6510.01, Defense-in-Depth: IA and Computer Network Defense (CND)

CJCSI 6211.02C, Defense Information System Network (DISN): Policy, Responsibilities and

Processes

CJCSI 6510.01E, Information Assurance and Computer Network Defense

DOD 5200.1-R, Information Security Program

DODD 5000.1, The Defense Acquisition System

DODD 8500.01E, Information Assurance

DODD 8570.01, Information Assurance Training, Certification, and Workforce Management

DODI 5000.2, Operation of the Defense Acquisition System

DODI 8500.2, Information Assurance Implementation

DODI 8510.01, DOD Information Assurance Certification and Accreditation Process (DIACAP)

DODI 8520.2, Public Key Infrastructure (PKI) and Public Key (PK) Enabling

DODI 8551.1, Ports, Protocols, and Services Management

DODI 8580.1, Information Assurance in the Defense Acquisition System

Executive Order 12958, Marking Classified National Security Information

FIPS PUB 190, Guideline for the Use of Advanced Authentication Technology Alternatives

(www.itl.nist.gov/fipspubs/fip190.htm)

NIST SP 800-34, Contingency Planning Guide for Information Technology Systems

NSTISSP #11, National Policy Governing the Acquisition of Information Assurance and IA-Enabled

Information Technology Products (http://niap.nist.gov/cc-scheme/nstissp-11.faqs.pdf)

Title 5 United States Code Section 552a (Privacy Act)

CJCSM 3213.02C The Joint Staff FOCAL POINT Program http://www.itl.nist.gov/fipspubs/fip190.htm http://niap.nist.gov/cc-scheme/nstissp-11.faqs.pdf

Solicitation: FA8707-12-R-0014 Attachment 1, Page 15 of 24

Best practices include the following:

MITRE CWE/SANS Top 25 Most Dangerous Programming Errors

Open Web Application Security Project (OWASP) Top 10 coding practices

DISA Application Security and Development Checklist

The Contractor shall perform automated static source code analysis scans using the tools provided by the PM or another ISPAN IA approved tool. Scans shall be conducted throughout software development to ensure flaws and vulnerabilities are identified and corrected early in the lifecycle to prevent code being delivered to the Government with vulnerabilities. The Contractor shall provide source code scan results and in conjunction with the PM and

ISPAN IA Branch, upon delivery of source code to the Government when entering GDT&E for analysis and validation. Open findings and mitigation processes shall be tracked and reported.

The contractor shall deliver the results of their Fortify Source Code Analyzer (SCA) results and any updates to their DISA Application Security Development STIG Plan of Action and Milestones

(POA&M) with each major delivery.

Adherence to DISA Application Secure Development STIG & Checklist; avoidance of OWASP Top

10 Web Application Security Vulnerabilities and SANS Top 25 Programming Errors; and integration of IA into the System Development Life Cycle (SDLC).

The developer shall consider the security implications and needs of the system targeting maintenance and improvement of the system’s compliance with the IA strategies of the DOD.

The Contractor shall ensure that all personnel developing software code have been trained in secure code development for the language in which they will be coding. The Contractor shall provide documentation of the IA training status of these personnel.

Information Assurance Test Products/Reports, CDRL A016

2.12. System Security Engineering (SSE)

The Contractor shall employ information system security engineering to implement or modify the system architecture and design, including all developed and reused software code, in compliance with DoD Directive

8100.1, “Global Information Grid (GIG) Overarching Policy,” to make maximum use of enterprise IA capabilities and services. The Contractor shall:

Develop and implement security configurations for the GAP CIE baseline IAW DISA Gold Disk and all applicable DISA STIGs.

Support PMO processes by identifying IA requirements, design, and implementation strategy.

Support the ISPAN IA Working Group.

Support TIMs.

2.13. Certification and Accreditation

The GAP CIE Certification and Accreditation (C&A) process is accomplished by the ISPAN IA Branch in accordance with Strategic Command Instruction (SI) 301-6, Information Assurance; and DoDI 8510.01, DIACAP.

The assigned IA Manager (IAM) or IA Officer (IAO) will maintain the C&A package for all GAP CIE applications and systems. The Contractor shall assist the IAM in the C&A process by accomplishing and providing the corresponding results to the ISPAN IAM from the following activities:

Develop and provide documents and assistance associated with obtaining Interim Authority to Test (IATT), Interim Authority to Operate (IATO), Authority to Operate (ATO), System Information Profile (SIP) and

System Change Requests (SCR). This will include but is not limited to:

o A baseline of the integrated COTS, GOTS and FOSS by version for each delivery o Application/system data flow diagrams

Solicitation: FA8707-12-R-0014 Attachment 1, Page 16 of 24 o A systems architecture diagram o Internal/external port/service usage o Internal/external connections o Web services provided/consumed o Authentication procedures/ flow diagram o Role based/fine grain access control capabilities o Assist the IAM/IAO in the development of mitigations for known vulnerabilities/findings documented in POAMs o Develop and provide version and description documents and identify all changes to the baseline per delivery.

o Produce source code scan results and the DISA Application Security and Development Checklist

POAM upon delivery of source code to the government when entering GDT&E for analysis and validation.

Support the ISPAN IA Working Group.

Support TIMs.

Support the ISPAN Systems Engineering and Architecture (SEA) IPT

Coordinate with outside agencies such as Defense Intelligence Agency (DIA) and DISA, as necessary.

The contractor shall develop, maintain and execute a process for accessing and incorporating all security related patches provided by the vendor/distributor and identified by U.S. Cyber Command

(USCYBERCOM) IA Vulnerability Alerts (IAVAs), U.S. Computer Emergency Readiness Team (US-

CERT) Common Vulnerabilities and Exposures (CVEs) into the baseline as soon as the vulnerability has been identified. The contractor shall adhere to the USCYBERCOM-issued IAVA implementation schedule for category (CAT) I, II and III vulnerabilities. All baselines subject to Developmental Test and Evaluation

(DT&E), Operational Test and Evaluation (OT&E) or fielding shall include all the latest security patches

(IAVAs and CVEs). As part of the analysis and implementation process, the contractor shall:

o Immediately notify the government through secure channels if a security patch cannot be installed or will cause a production failure.

o Notify the government of any performance or functionality issues caused by directed security patches or configurations.

The Contractor process shall also ensure that risks associated with patching the baselines (e.g., a patch causing loss of functionality) are identified and minimized. In addition, the Contractor shall notify the Government immediately of any security-oriented patches that may adversely impact the operation, performance, or functionality of GAP CIE.

The Contractor shall assist the ISPAN IA Branch to create any needed POA&Ms.

All Government furnished hardware and software shall be maintained in compliance with cyber requirements, to include the timely application of IAVAs. All GOTS, COTS, and FOSS installed on GFE hardware shall be approved by the ISPAN IA Branch prior to use.

CDRLs

Information Assurance System Security Plan, CDRL A015

Information Assurance Test Products/Reports, CDRL A016

2.14. Training

The GAP CIE Functional Manager’s staff creates training products and conducts formal and informal user training

(introductory, continuing, refresher, and difference training). The Contractor shall design and build all software changes with human-system integration in mind, to minimize the “learning curve” for existing users when capability development or enhancements are fielded.

At the direction of the Government, the Contractor shall produce occasional GAP CIE introduction/welcome videos.

For every software change, the Contractor shall update the appropriate portions of the comprehensive user/administrator manual and the context-sensitive help files within GAP CIE. All such updates to the manual and

Solicitation: FA8707-12-R-0014 Attachment 1, Page 17 of 24 help files shall be GDT&E-testable items.

Deliverable End Item, CDRL A012

2.15. Configuration Management

The Contractor shall be responsible for having a configuration management process that provides thorough, efficient, and timely implementation of all software and database product changes and includes Government PMO approval before product changes are initiated. All source code, documents and libraries required for compilation and execution of the system shall be delivered to the Government for configuration management (CM) purposes.

Additionally, the Contractor shall maintain a version control system for all software artifacts. No part of any delivered CDRLs may be marked 'proprietary' without prior notification to the Procurement Contracting Officer.

The Contractor shall be responsible for supporting functional configuration audits as required. The Government may require the Contractor to perform or assist in CM at USSTRATCOM with Government oversight. To the degree determined by the Government, the Contractor shall configure its development and testing environment to match the primary operational GAP CIE instance.

CDRL

Deliverable End Item, CDRL A012

2.16. Technical Reviews

The Contractor shall conduct and/or participate in technical reviews at the direction of the Government. Reviews include Systems Requirements Reviews, Design Reviews, and Test Readiness Reviews.

2.16.1. System Requirements Review (SRR)

At the direction of the Government, the Contractor shall conduct an SRR to ensure complete and consistent understanding of all requirements by the Contractor and the Government. The SRR shall address any requirements changes since the design technical baseline was established.