Section J Attachment 1 - Final PWS

MASS PWS

UNITED STATES

STRATEGIC COMMAND

(USSTRATCOM)

Performance Work Statement for

Missile Applications Software Support II

(MASS II)

Table of Contents Introduction

41.1 System Description

SCOPE

52.1 Program Objectives

52.2 Contract Technical Objectives

52.2.1 Sustain Current Capabilities

52.2.2 Modernize Applications

62.2.3 Support Evolving Missions

62.2.4 Respond to Software Change Requests

62.2.5 Follow Good Software Engineering and Coding Processes

DESCRIPTION OF SERVICES

73.1 Program Management

83.2 Systems Engineering (SE)

93.2.1 System Environments

93.2.2 Requirements Documentation

93.2.3 Configuration Management

113.2.4 Reliability, Availability, Maintainability (RAM) Engineering

123.2.5 Information Assurance (IA)

143.3 Software Sustainment/Development

153.3.1 Software Development Lifecycle

153.3.2 Software Delivery

163.4 Developmental Test and Evaluation (DT&E)

173.5 Training

173.6 Technical Reviews

173.6.1 System Requirements Review (SRR)

183.6.2 Design Reviews

193.6.3 Test Readiness Review (TRR)

203.7 Onsite Support

213.8 Special Studies and Requirements Analysis

213.9 Additional Support Requirements

213.9.1 Exercise and Contingency Support

213.9.2 Experimental Support

PLACE OF PERFORMANCE

SECURITY

215.1 Clearances

215.2 Handling

GOVERNMENT-FURNISHED PROPERTY AND SERVICES

SCIENTIFIC AND TECHNICAL INFORMATION (STINFO)

DEVELOP AGREEMENTS

MISSION ESSENTIAL SERVICES

SERVICES SUMMARY

TRANSITION…………………………………………………………………………………...23

1 Introduction This Performance Work Statement (PWS) addresses the U.S. Air Force Electronic Systems Center (ESC) Missile Applications Software Support (MASS) II Software Sustainment and Modernization Program for the Integrated Strategic Planning and Analysis Network (ISPAN) at United States Strategic Command (USSTRATCOM). The fielded Block 1 ISPAN is an operational Information Technology (IT) system of systems that provides a collaborative framework for the development of nuclear and conventional kinetic/non-kinetic strike options and course of action (COA) development in support of joint operation planning and senior leader decision-making for the Department of Defense (DoD). The system is composed of two elements: (1) a Mission Planning and Analysis System (MPAS) that facilitates the development of Joint Staff full spectrum Level 1-4 nuclear and conventional (kinetic and non-kinetic) strike options supporting theater and strategic requirements, and (2) a Global Adaptive Planning Collaborative Information Environment (GAP CIE) that orchestrates enterprise services for integrated joint COA development across diverse mission areas and Combatant Commands. Both elements of the ISPAN program form a framework that supports the Joint Operation Planning and Execution System (JOPES), Joint Operation Planning Process (JOPP), and the transition of JOPES to the Adaptive Planning and Execution (APEX) system that makes use of web-based collaboration, enterprise applications, and net-centric data to create living plans that are more responsive to the dynamic nature of current world events.

1.1 System Description

The applications presently maintained under MASS include the Dynamic Application and Rapid Targeting System (DARTS) and Missile Applications Reusable Services (MARS). The DARTS software rapidly and accurately allocates, and then assigns, Intercontinental Ballistic Missiles (ICBM) and Submarine Launched Ballistic Missiles (SLBM) to targets. This software produces the ballistic missile portion of Operations Plan (OPLAN) 8010. DARTS is a comprehensive system that also considers the allocation and application of aircraft weapon systems to ensure the ballistic missile portion of OPLAN 8010 is fully integrated with aircraft weapon systems. This process, called “timing and deconfliction”, includes analyses of missile and aircraft weapons effects, and subsequent adjustments of mission plans to meet the requirements of OPLAN 8010. The software is also used to perform maintenance operations, as required, for an existing OPLAN. The system has inherent reusability features that allow other systems with similar planning or analysis needs to re-use one or more of its components, via MARS. MARS provides ballistic missile mission planning capabilities very similar to those available in DARTS. Indeed, it is built on the same core set of planning software components used within DARTS. MARS differs from DARTS primarily in that it possesses no user interface; all of its capabilities are accessed via “head-less” web services that are integrated into client applications other than DARTS. The present users of MARS are the Automated Windowed Planning System (AWPS) and Nuclear Planning and Execution System (NPES).

The Joint Functional Component Command Global Strike (JFCC GS) J54 sponsors Missile Applications components. The ISPAN MPAS Branch (ESC/HSBB) is designated as the Program Management Office and is responsible for all management actions associated with this contract. The Procuring Contracting Office is 55th Contracting Squadron (55 CONS/LGCZ), which is responsible for overall contract management of this effort.

The primary users of DARTS and MARS are Joint Functional Component Command Global Strike (JFCC GS), Plans and Integration Directorate. The primary operating site is United States Strategic Command (USSTRATCOM), Offutt Air Force Base, Nebraska.

2 SCOPE

2.1 Program Objectives

The objectives of MASS II are to provide ballistic missile planning and analysis support for ISPAN at the best value to the Government. The contract requires the inclusion of all current DARTS and MARS planning capabilities, maintenance and enhancement of current capabilities, the development of selected new capabilities upon government request, and the integration of DARTS or MARS into the ISPAN environment, as required.

2.2 Contract Technical Objectives

The contract objectives are to provide cost-effective ballistic missile planning software engineering support for maintenance and enhancements to sustain DARTS/MARS viability and ensure integration with the overall planning environment and potentially to bring in new requirements into the DARTS/MARS software. The contract requires the software support to be responsive to changes in the following areas: military planning guidance, service weapons and weapon systems, ISPAN computing architectures, and upgrades based on technology advances. It is a Government objective to select a contractor that has the organizational capability and technical ability to accomplish the following activities relative to the present ballistic missile planning system:

2.2.1 Sustain Current Capabilities

First and foremost, the contractor shall be responsible for preserving all current mission capability of DARTS and MARS. Although not expected to create documentation, the Contractor shall perform source code inspections and at the discretion of the Government, conduct user interviews as required to ensure that their knowledge of current requirements is complete. The primary, overriding goal of MASS II shall remain the production, maintenance, and verification of the Operational Plan (OPLAN) 8010 data for a full fidelity, force-level, timed and de-conflicted plan. Finally, the requirement to maintain current capabilities does not necessary imply maintaining the current system and software architecture should a suitable low risk alternative be proposed.

2.2.2 Modernize Applications

DARTS and MARS operate within the larger structure of ISPAN. The MASS Contractor shall be responsible for integrating with ISPAN activities, present and future, as requested and authorized by Government Program Management Office (PMO), and in accordance with the ISPAN System Engineering Plan (SEP). The contractor will participate in the System Engineering and Architecture IPT (SEA IPT) as needed or as requested by the Government. At government direction, the Contractor shall be responsible for redesigning portions of DARTS/MARS in accordance with new requirements levied by the MPAS Modernization Way-Ahead Plan and ISPAN technical direction, to ensure that relevant functionality is accessible to other ISPAN software as required. The intent of this requirement is to provide net-centric interoperability between selected DARTS and ISPAN systems’ functionality, thus preventing unnecessary duplication of effort.

2.2.3 Support Evolving Missions

The contractor shall be responsible for ensuring that DARTS continues to use an architecture that is scalable, flexible, extensible and provides for the efficient implementation of changing requirements. This includes future missions, weapons, system functions and guidance changes.

2.2.3.1 Respond to Weapon System Changes

This contract includes the requirements to accommodate and implement changes resulting from weapons system evolution. The planning process can be impacted by changes in deployed weapon systems, new weapon systems or weapons carried by these systems, tactics changes, changes in Service-furnished planning support products, and the national military policy that defines the use of weapons planned by USSTRATCOM. The nature of war planning requires that DARTS/MARS incorporate or model weapon system changes as defined by the Services.

2.2.3.2 Respond to Organizational Changes

This contract includes responding to changes in the strategic planning and the organizational environment. This aspect may result in deletion of, or additions to, DARTS capabilities that were formerly organized under other functional areas.

2.2.4 Respond to Software Change Requests

The Contract shall be responsible for tracking and correcting software deficiencies in a manner compatible with and approved by the Government, updating software to reflect national guidance, implementing new planning requirements, modifying or re-hosting software to meet requirements (to include hardware changes), and constructing software adapters for interface into the ISPAN environment. The Missile Applications Configuration Control Board (CCB), composed of Government PMO, Functional Managers, others, and the Contractor shall convene (as specified in Para 3.2.4) to review, prioritize, and authorize all activities related to software changes, enhancements, and deficiencies.

2.2.5 Follow Good Software Engineering and Coding Processes

The contractor shall keep current on good software engineering and coding processes and practices.

2.2.5.1 Promote Software Reuse

Software products from other systems within ISPAN may be used within DARTS/MARS to minimize the need for independent and potentially redundant developments.

2.2.5.2 Limit “Hard Coding”

The contractor shall be responsible for ensuring that the system remains as data-driven as possible, with any 'hard-coding' of values held to an absolute minimum. The contractor shall notify the government of existing/delivered hard coding with each delivery.

3 DESCRIPTION OF SERVICES

This section describes the overarching Missile Applications Program tasks to be performed by the Contractor to appropriately manage the MASS II contract. The contractor shall be responsible to ensure they have a staff capable of complying with the tasks below – to include all required technical training/knowledge/certifications.

These core efforts will include, but not be limited to, the following areas: program management, systems engineering; requirements, design and test activities; and on-site support.

3.1 Program Management

The Contractor shall plan, implement, apply, and maintain required program management expertise to fully address all program management tasks, events, processes, and products associated with all increments, activities, and phases under this PWS. The Contractor shall use proven and mature Program Management processes that are integrated via the Program Management Plan (PMP) and Integrated Master Schedule (IMS) with outcomes reported via an approved and validated Cost/Financials Report (ANSI standards for EVMS for over $20M contract value). The Contractor shall provide monthly and cumulative spending reports against a pre-established budget baseline (Contract Performance Report Format 1). 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 study and analyze alternative management approaches and present them to the Program Management Office (PMO) for how best to satisfy customer requirements. The Government will evaluate those alternative approaches for possible implementation. The Contractor shall develop, implement, and maintain a contract performance management information system for program management as well as system design, development, integration, test, certification, fielding, sustainment, and maintenance activities and events.

The Contractor shall prepare and submit a monthly status report to the Government describing current period activities and accomplishments, near-term events, and current programmatic issues. (CDRL A001; A002, A012, A013) 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.

· Measurement and analysis including establishing management indicators for early problem detection.

· Configuration management.

· Milestone and progress reviews.

· Budget control, reporting, and management.

· Schedule control, reporting, and management.

· Continuous Risk and Opportunity Management.

· Earned Value Management The Contractor shall participate in the meetings of the Missile Applications Integrated Product Team (IPT) and other requested meetings.

3.2 Systems Engineering (SE)

The Contractor shall perform robust systems and software engineering using disciplined, established Contractor and tailored industry processes, as well as best practices specifically tailored and adapted for all requirements, design, development, integration, engineering, and support activities included under this PWS. The Contractor shall execute all systems engineering and related program management processes defined “Level 3” Process Areas (PAs) by the Capability Maturity Model Integration (CMMI) as tailored by the Contractor specifically for this contract. The Contractor shall be Capability Maturity Model Integration (CMMI) Level 3 certified, or equivalent, and execute all systems engineering and related program management processes according to the guidelines of that certification as tailored by the Contractor specifically for this contract.

The Contractor’s SE methodology shall manage, implement and consider all aspects of architecture development (specifically including Information Assurance (IA) and security aspects of the architecture) and life cycle processes including:

· Assurance of an open, service oriented, flexible, expandable/scalable, and loosely coupled architecture.

· Internal and external interface requirements development and management maximizing the use of open, industry established external and internal interface standards.

· Requirements development, analysis, decomposition, allocation, trade-off analysis, documentation, and management.

· Functional analysis, decomposition, and allocation.

· Risk reduction analyses.

· Software engineering.

· Hardware engineering.

· Network engineering and integration.

· Integration of new, modified, and legacy mission/infrastructure systems.

· Systems Security Engineering (SSE).

· COTS or GOTS product analyses and recommendation.

· System design and analysis.

· Decision analysis and resolution.

· Modeling and Simulation (MODSIM).

· Deficiency/Defect detection, prevention, containment, tracking, and resolution.

· Technical resource planning and allocation.

· Configuration management.

· Data management.

· Technical risk management.

· Installation engineering.

· User training support.

· Supportability engineering and planning.

· Human Systems Integration (HSI) engineering.

The Contractor shall develop and execute dynamic processes for managing changes in technical solutions as a result of requirements reprioritization, budget adjustments, new technologies, or changes in operational business processes. (CDRL: A001, A003, A005, A009, A015)

3.2.1 System Environments

The Contractor shall be responsible for designing and developing software systems that must operate efficiently in the ISPAN system environments. The ISPAN system environments include the computer hardware, software, and associated configurations that together provide the basic IT infrastructure for ISPAN systems. The ISPAN CCB will keep documentation of the current ISPAN system environments. (CDRL A003, A009) The ISPAN system environments may be provided as virtual machines to the Contractor by the Government to simplify testing against the system environments. If provided, the Contractor shall use these environments for development and testing in lieu of recreating the environments. The Government may request a copy of the virtual machines used in Contractor testing to verify findings in Government testing.

3.2.2 Requirements Documentation

The Contractor shall document system requirements, including traceability from derived requirements to Government provided requirements and from requirements to an approved software baseline. The Contractor shall develop testable criteria for each requirement incorporated into the system/sub-system specifications to enable verification of the requirement during test. Each software delivery, including informal patch deliveries, shall include traceability to specific Missile Applications functions and requirements.

The Contractor shall provide the Government access to any requirements and specification management tools, and related information repositories. The Contractor shall coordinate with the PMO and other Government stakeholders on the data management standards that support information exchange between USSTRATCOM requirements management tool(s) and Contractor design specification management tool(s). (CDRL A003, A005, A009, A015)

3.2.3 Configuration Management

The Contractor shall be responsible for having, or being able to establish prior to contract start, 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 should maintain a version control system for all software artifacts. No part of any delivered CDRLs may be marked 'proprietary'. The Contractor shall be responsible for supporting functional configuration audits as required. The Government may exercise the option of having the Contractor perform or assist in CM at USSTRATCOM with Government oversight. Government CM processes should be identified in schedules and work breakdown structures delivered by the Contractor. (CDRL: A001)

3.2.3.1 Configuration Control Board and Software Change Proposals The DARTS baseline will be managed by a minimum of two Government configuration control boards (CCBs):

· The ISPAN CCB provides an integrated, disciplined, structured, and streamlined configuration control process to manage the ISPAN environments throughout ISPAN’s entire life cycle. The ISPAN CCB serves under the authority of the ISPAN Program Manager. The ISPAN Chief Engineer serves as the technical advisor to the ISPAN CCB. A representative from each ISPAN functional area is included in the ISPAN CCB. The ISPAN CCB ensures adequate information cross-flow and proper coordination.

· The Missile Applications CCB will manage the configuration of the DARTS baseline under both development and sustainment. The Missile Applications CCB is chaired by the PMO.

A Software Change Request (SCR) is the document by which a proposed software change is described, justified, and submitted to the Missile Applications CCB for approval or disapproval of the change request. SCRs submitted to the Missile Applications CCB will be analyzed by the Contractor. Upon Government request, the Contractor shall be required to review and categorize the SCRs via, at minimum, the basic CCB process and provide a full analysis (e.g., all acquisition functional areas such as technical, schedule, cost, logistics, etc) for Missile Applications CCB review.

The Contractor may submit issues that the Contractor feels justifies an SCR. Further, the Contractor shall notify the Government immediately when the need for an emergency or urgent priority SCR is determined. However, the Contractor shall not begin work on an SCR until directed to by the Government.

The Contractor shall categorize SCRs using the Deficiency Report definitions as defined in AF T.O. 00-35D-54 (i.e. Class I or II). The contractor shall further categorize SCRs by corrective maintenance (fixing errors in a system after release), adaptive maintenance (making the system useable in a changed or changing environment (technical or operational)) or enhancement (improving the performance/usability of the existing system or new minor functionality, capability or behavior).

The Contractor shall propose specific qualitative and quantitative criteria for categorizing changes into SCR categories for Government approval. In addition, the Contractor shall propose what activities can be accomplished prior to SCR approval. (CDRL A009) Basic CCB Process:

· Minimum Membership

· PM

· FM

· Contractor Lead

· Minimum Tasks/Functions

· Track changes with min information

· Tracking #

· Requester

· Date of Request

· Version Discovered

· Title

· Description

· Category (Adaptive, Corrective, Enhancement)

· Severity (CAT I)

· Estimated Effort in Hours

· Final Effort in Hours

· Estimated Version/Date

· Priority (set by Gov’t)

· Workaround/Impact to User

· Review for validity, benefit, impact, risk

· Disposition Request

· Maintain List of SCRs (past, present, future)

· Electronic access to SCR list by the Gov’t via common desktop tools (aka – Excel)

· Maintain minutes, action items

· SCR List for Delivery (patch, version, etc) must be signed by PM, FM, Contractor Lead and submitted to contracting

· Any change must be resigned with impacts (if any noted) and resubmitted

· Must be able to track/maintain multiple baselines at the same time (i.e. – development, test and prod)

3.2.4 Reliability, Availability, Maintainability (RAM) Engineering

At the direction of the Government, the Contractor shall perform RAM engineering and analysis to include a reliability block diagram and analysis in order to demonstrate the availability requirements are satisfied by analysis and design improved system maintainability and supportability into the fielded baseline. The Contractor shall provide a system solution that addresses system obsolescence and meets or exceeds the Materiel Availability/ Reliability KPP/KSA and supports Technology Refresh and Sustainment recommendations to ensure that DARTS remains supportable and maintainable. The Contractor shall conduct Failure Modes, Effects, and Criticality Analysis (FMECA) and provide corresponding reports as part of system design documentation. The Contractor shall provide initial RAM engineering recommendations to the Government prior to or at the design review and at government established intervals thereafter. Additionally, the Contractor shall implement and field Government-approved RAM changes in an efficient strategy synchronized with other system updates to minimize operational impact. The Contractor shall measure the effectiveness of those changes for a period of at least one (1) year before assessing the success of the updates.

3.2.4.1 Reliability & Maintainability (R&M) Program Plan

The Contractor shall provide a Reliability & Maintainability (R&M) Plan at the direction of the Government. (CDRL A016)

3.2.4.2 Maintenance Data Collection (MDC)

The Contractor shall develop a MDC Plan that proposes methods, sources, storage, retrieval and business practices that enable collection of failure data from diverse sources to assess the software health. The MDC shall be accomplished only at the direction of the Government. The data shall include all pertinent life cycle data from development testing to current state for the software. When directed by the Government the Contractor shall develop and implement a failure reporting and corrective action process in order to provide analysis of application failures including symptoms, root causes, and corrective actions for all SW failures. This system shall include how such failures can be eliminated or avoided in the future. (CDRL A019)

3.2.5 Information Assurance (IA)

The contractor shall comply with all current DoD and USSTRATCOM cyber security and information assurance (IA) directives, instructions and policies to include best practices and countermeasures. The contractor shall also engage in efforts to better understand 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. IA will be an integral part of the entire software development life cycle (SDLC) and maintenance activities.

All software developed will be architected, designed and maintained IAW with known industry best practices and standards, USSTRATCOM, U.S. Air Force, DoD, and NIST policy and guidance (including any updates) to include but not limited to:

· MITRE CWE/SANS Top 25 Most Dangerous Programming Errors, Open Web Application Security Project (OWASP) Top ten web vulnerabilities

· USSTRATCOM SI 301-6, Information Assurance

· U.S. Air Force Electronic Systems Command (ESC) Secure Software Development Guide

· Defense Information Systems Agency (DISA) Application Security and Development Checklist and all other applicable Secure Technical Implementation Guides (STIGs) and checklists

· DoD Net-Centricity vision, policy and initiatives

· DoD Instruction 8500.2, Information Assurance (IA) Implementation

· NIST FIPS 140-2, Security Requirements for Cryptographic Modules, FIPS 180-3, Secure Hash Standard and FIPS 186-3, Digital Signature Standard

The contractor shall comply with the current and future DoD Directive 8570.1 Information Assurance Training, Certification and Workforce Management and DoD 8570.01-M Information Assurance Workforce Improvement Program.

The contractor shall perform automated static source code analysis scans using the tools provided by the PM or another ISPAN IA approved tool. Scans will be conducted throughout the development cycle 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 will provide source code scan results (CDRL A017) and in conjunction with the PM and ISPAN IA Branch create the DISA Application Security and Development Checklist Plan Of Actions and Milestones (POAM) 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.

3.2.5.1 Information Assurance (IA) Personnel Certification

The Contractor shall ensure that personnel accessing information systems have the proper and current information assurance certification to perform information assurance functions in accordance with DoD 8570.01-M, Information Assurance Workforce Improvement Program. The Contractor shall meet the applicable information assurance certification requirements, including:

· DoD-approved information assurance workforce certifications appropriate for each category and level as listed in the current version of DoD 8570.01-M; and

· Appropriate operating system and or environment certification for information assurance technical, IA engineer, IA software engineer, and software engineer positions as required by DoD 8570.01-M.

The Contractor shall provide documentation supporting the information assurance certification status of personnel performing these identified information assurance functions.

Contractor personnel who do not have proper and current certifications shall be denied access to DoD information systems for the purpose of performing information assurance functions.

3.2.5.2 System Security Engineering (SSE)

The Contractor shall ensure that information system security engineering is employed to implement or modify the system architecture and design, including all developed and reuse 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 ensure that all Missile Applications baselines undergo a consistent security engineering review and analysis process. This process shall be rolled up under SE but is described here in detail. The Contractor shall:

· Develop and implement security configurations for all Missile Applications baselines IAW DISA Gold Disk and all applicable DISA Security Technical Implementation Guides (STIGs).

· Support the Missile Applications CCB processes by identifying IA requirements, design, and implementation strategy.

· Support the ISPAN Information Assurance Working Group.

· Support Technical Interchange Meetings.

3.2.5.3 Certification and Accreditation

The Missile Applications Certification and Accreditation (C&A) process is accomplished by the ISPAN Information Assurance Branch IAW USSTRATCOM policy and procedures, SI 301-6, and DoDI 8510.01, DoD Information Assurance Certification and Accreditation Process. The assigned Information Assurance Manager (IAM) or Information Assurance Officer (IAO) will maintain the C&A package for all ISPAN 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) Change Requests (SCR). This will include but is not limited to:

· A baseline of the integrated COTS, GOTS and FOSS by version for each delivery (CDRL A009)

· Application/system data flow diagrams (CDRL A015)

· A systems architecture diagram (CDRL A015)

· Internal/external port/service usage (CDRL A015)

· Internal/external connections (CDRL A015)

· Web services provided/consumed (CDRL A015)

· Authentication procedures/ flow diagram (CDRL A015)

· Assist the IAM/IAO in the development of mitigations for known vulnerabilities/findings documented in POAMs. Develop and provide version and description documents and identify all changes to the baseline per delivery. (CDRL A009)

· Produce source code scan results (CDRL A017) and the assist 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 Information Assurance Working Group

· Support the ISPAN SEA IPT

· Support TIMs

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

In addition to the above activities, the Contractor shall develop and maintain a process for assessing and incorporating all security patches into the baselines, in accordance with processes/timelines provided by the ISPAN Information Assurance Branch.

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 DARTS. The Contractor will work with 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 Information Assurance Vulnerability Managements (IAVMs). All GOTS, COTS, and FOSS installed on GFE hardware shall be approved by the ISPAN Information Assurance Branch prior to use.

3.3 Software Sustainment/Development

Software sustainment/development includes the contractor effort to assure that the baseline remains operational, supportable, and accredited. The primary focus is to optimize life cycle customer support and achieve optimum system availability at the lowest total ownership cost. The Contractor shall sustain the baseline and stay abreast of technology changes and mission application changes that impact interoperability, operations and system accreditation.

Contractor shall deliver incremental tested and approved updates as required to software and hardware. 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 PMO requirements. This will include reuse of software components/services developed by other DoD programs if applicable. (CDRL A018) 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 to include commercial products (including operating systems, graphical user interfaces, patches, and compilers). The Contractor shall be responsible for maintaining any FOSS software used within their baseline, in accordance with maintenance of contractor developed code.

The contractor shall verify at software design reviews, peer reviews, unit code and test phases, and upon request by the Government that the requirements included in this PWS for robust, assured, secure software development have been met especially as relates to the items such as the SANS CWE Top 25 Most Dangerous Programming Errors and the DISA Application Security and Development Checklist. (CDRL A003)

3.3.1 Software Development Lifecycle

The Contractor shall develop, implement, and maintain processes to manage the software development lifecycle. Lifecycle processes shall include:

· Requirements development: The Contractor shall have specific, tailored processes for requirements development, analysis, and management to include a description and methodology for requirement tracking, with bidirectional traceability to the functional requirements.

· Software Code and Unit test: The Contractor shall have software coding standards that will be implemented on this program. Contractor should include processes for automated unit testing and code peer reviews to ensure software correctness and security.

· Software configuration management: The Contractor shall place all source code including legacy, and free and open source software (FOSS) in a version control system, and maintain version baselines tracking requirements met with each release.

· Integration Testing: The Contractor shall include automated regression testing

· Build: The Contractor shall include processes to build software artifacts, preferably automated to improve efficiency.

· Testing: The Contractor shall apply security principles that include least privilege, quality assurance with emphasis on the use of independent code reviews and code coverage, exception handling, patch management including software entering test, and the use of code evaluation tools.

· Quality Assurance: The Contractor shall conduct software information assurance and vulnerability analyses, defect detection and containment (including categorization, prioritization, resolution, and retest), and dead code detection. The Contractor processes should ensure application of security principles that include least privilege, quality assurance with emphasis on the use of independent code reviews and code coverage, exception handling, patch management including software entering test, and the use of code evaluation tools. Also, the Contractor processes should include removing all dead code unless a detailed analysis is provided to the Government addressing all risks associated with this dead code and the Government approves retaining the dead code in the product. (CDRL A003)

3.3.2 Software Delivery

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 will be according to an agreed upon schedule—presently twice a year. (CDRL A013, A022)

The Contractor shall provide informal software deliveries to the Government to include computer software, installation instructions, and release notes describing changes since the previous software delivery. At minimum, informal deliveries will be made to support Government Development Test and Evaluation (GDT&E).

The Contractor shall identify all code with proprietary and free and open source (FOSS) software (including code) included with each delivery. The Contractor should provide a description of the software, its origin, how it is controlled, how it has been tested to verify performance requirements, and how it has been analyzed for vulnerabilities. (CDRL A007, A009, A018)

3.4 Developmental Test and Evaluation (DT&E)

Developmental T&E includes a Contractor Developmental Test and Evaluation (CDT&E) phase (part of which shall be accomplished in the government facility), Government Developmental Test and Evaluation (GDT&E) phase and User Acceptance Test (UAT) phase. These phases will be accomplished before the production cutover of DARTS. The Contractor shall participate in directed Government Integrated Test Team (ITT) meetings. The ITT meets to assist in the coordination and administration and approval of both Contractor and Government test planning activities to include test plan/procedures development, test anomalies, test conduct and reporting issues. The Contractor shall involve the Government in all Contractor test processes for the Missile Applications program. Government test personnel shall have the opportunity to participate in Contractor test events to collect data to support SRR, design reviews, and Government tests and other milestones and decision points.

The Contractor shall provide the Software Test Plan (STP) which shall include all the test events referenced in this document. Tests shall be conducted IAW Government approved test plans and procedures. 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, as defined by the integrated requirements team. Final test reports require approval by the Government. The Contractor shall provide Software Test Reports with each new/modified software upgrade and revision during field testing and the Operations and Sustainment (O&S) phase.

The Contractor shall conduct testing in a system environment compatible with the ISPAN operational environment to the greatest extent practicable. By matching the operational environment, the Contractor can reduce the risk of integration errors during government testing

The Contractor shall conduct testing to include functional, Validation & Verification (V&V), performance, security, and interoperability testing as directed by the government. System testing shall be repeated until all test procedures can be successfully executed with no Category 1 deficiencies, or the Government deems the risk to proceed to formal Government testing is acceptable. At the conclusion of system testing, the Contractor shall update the STP and corresponding test procedures as required incorporating any changes, and shall document and apply lessons learned to the overall test processes. Government testing will document deficiencies IAW the deficiency reporting process. Deficiencies will be traced back to the appropriate requirement, software version, and test case. (CDRL A006, A008)

3.5 Training

For applications, systems, or capabilities that the Contractor develops under this contract, the Contractor shall:

· Provide analysis of training requirements to determine: (a) if training is required; (b) if training is required, is it needed for Operations and/or System Administration; and (c) the level of training needed. The Government will use this analysis to help determine the training requirements and method.

For applications, systems, or capabilities that the Contractor provides modification from the third party product, additional training may be required to complement or supplement available pre-existing training provided by third parties. In these cases, the Contractor shall provide:

· Analysis of training requirements to determine: (a) if complementary or supplemental training is required; (b) if complementary or supplemental training is required, is it needed for Operations and/or System Administration; and (c) the level of complementary or supplemental training needed. The Government will use this analysis to help determine the training requirements and method.

When training is needed per Government direction, the Contractor shall provide training materials and conduct classes. The materials and class will be reviewed and approved by the Government. (CDRL A010)

3.6 Technical Reviews

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

3.6.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. The SRR shall identify any outstanding requirements issues or areas where there is a lack of consistent understanding of requirements, operations, performance characteristics, or functionality of the modernization program. The Contractor shall review the requirements and Release Specification and provide analysis and recommendations for updates. (CDRL A005)

Entrance Criteria

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

· All applicable requirements documentation, including a requirement traceability report/matrix from requirements documents through allocation to design specifications and systems/sub-systems have been made available for participants to review.

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

Exit Criteria

· SRR meeting held and all action items properly completed (closed).

· The system requirements, as disclosed, satisfy the functional requirements.

· The system requirements are sufficiently detailed and understood to enable system functional definition and functional decomposition.

· There is an approved system requirements specification.

· The risks are known and manageable for design and development.

· The schedule for the delivery cycle is executable within the anticipated cost and technical risks.

· The software functionality in the system specification is consistent with the software sizing estimates and resource loaded schedule.

· There are no significant issues outside the scope of the contract.

3.6.2 Design Reviews

The Contractor shall conduct design reviews at the direction of the Government. The Government shall determine what design reviews are necessary prior to the beginning of an individual development or maintenance effort. The Contractor shall clearly describe any departures or updates to the preliminary design solution provided in the SRR or earlier design reviews. (CDRL A015)

Entrance Criteria

· SRR and/or previous design reviews are completed, technical baseline established, and all previous actions closed to the satisfaction of the Government.

· Updates to the systems requirements specification, if any, have been completed.

· All applicable software design documentation has been made available for participants to review. SRR and/or previous design reviews are completed, technical baseline established, and all previous actions closed to the satisfaction of the Government.

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

· Design package at the allocated baseline level established with explicit identification of potential reductions in schedule and life cycle ownership cost resulting from re-use (e.g. hardware, software, licenses, services, applicable design materials)

· If applicable, all design trade studies and analyses are complete as required to support product selections or design decisions. Trade studies shall include a detailed description of the study to include process used, assumptions made, and the analytical results as appropriate. Contractor shall include economic considerations where possible to assist with RTOC determinations.

· An updated requirements traceability report/matrix is provided showing traceability from requirements documents through allocation to design specifications and systems/sub-systems.

· An updated program development schedule is provided including test and evaluation, software integration elements and identification of critical path drivers.

· A risk assessment for missile applications is provided that includes plans/mitigation strategies for all risks that has been fully coordinated with and agreed to by the Government.

Exit Criteria

· Design review meeting held and all action items completed (closed).

· The status of the technical effort and design indicates Operational Test success (operationally suitable and effective).

· Adequate processes and metrics are in place for the associated development effort to succeed.

· Development risks are known and manageable for Developmental Testing and Operational Testing.

· The design, as presented, addresses the identified threat assessment and complies with current DoD Information Assurance policy and guidance.

· The information assurance risks associated with the proposed designs have been documented with appropriate and approved mitigations.

· Any threats identified as not being addressed or any design not in accordance with DoD Information Assurance policy and guidance are documented and a mitigation plan has been developed and accepted by the ISPAN Program Manager.

· Key project schedule milestones are identified and supporting schedules reflect a logical flow to accomplish the work.

· The development schedule is executable within the anticipated cost and technical risks.

· The system requirements are understood to the level appropriate for this review.

· The detailed design satisfies human systems engineering requirements.

3.6.3 Test Readiness Review (TRR)

The Contractor shall conduct a system level TRR in coordination with the ITT that demonstrates readiness to enter system level testing. The TRR will allow the Government to assess Contractor readiness to promote software to the government test environment prior to the start of formal GDT&E. A Contractor representative shall attend the TRR. In addition, a Contractor representative shall support any TRR as required by the Government. (CDRL A006, A008, A011)

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, Operational Testing, and System of Systems/Family of Systems tests have been satisfactorily completed.

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

· The Information Assurance threat model has been updated to match current Information Assurance threats.

· All previously identified and documented Information Assurance 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.

Exit Criteria

· TRR meeting held and all action items successfully completed (closed).

· Adequate test plans have been completed and approved.

· All required test resources have been identified and coordinated.

· The test program is properly staffed.

· All previous applicable component, subsystem, system level, and qualification test results required to support system Developmental Testing, Operational Testing, and Family of Systems/System of Systems tests have been satisfactorily completed.

· All of the test program risks have been identified; applicable mitigation plans have been approved or risks accepted as is by…