Section J Attachment 1 - APS V PWS FINAL - 29 APR 11.docx

UNITED STATES STRATEGIC COMMAND (USSTRATCOM)

Performance Work Statement (PWS) for

Air Vehicle Planning System V

(APS V)

FA4600-11-R-0028

Attachment 1

Table of Contents

Introduction This Performance Work Statement (PWS) addresses the U.S. Air Force Electronic Systems Center (ESC) Air Vehicle Planning System V 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 actions (COA) 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 Global Adaptive Planning Collaborative Information Environment (GAP CIE) that orchestrates enterprise services for integrated joint COA development across diverse mission areas and Combatant Commands; and (2) 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. 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.

This Performance Work Statement (PWS) addresses the Air Vehicle Planning System (APS) Software Sustainment and Modernization portion of MPAS. Throughout this document APS will refer to the Air Vehicle Planning System and associated components.

System Description The Air Vehicle Planning System Verification, Reconnaissance Planning, Data Products and services include:

· Air Vehicle Planning System - Plans fully validated missions down to the individual sortie level. APS is a force-level mission planning system that performs planning functions in support of the nation’s nuclear war plan and Conventional Air Launched Cruise Missile (CALCM). APS is currently used to plan missions involving the following aircraft and weapon systems: B-52, B-2, KC-135, KC-10, RC-135, U-2, EP-3, Air Launched Cruise Missile (ALCM), Advanced Cruise Missile (ACM), and CALCM. APS also contains capability to plan DCA, F15/16/18, but this functionality is not in current use. The APS application is used to perform Air Vehicle planning operations, including maintenance operations, exercise and adaptive planning for the Operational Plan (OPLAN), non-nuclear OPLAN planning, and non-nuclear planning. Tasks include route Generation, Mating and Ranging, Timing, Verification, Data Products and Tape Build. Results and outputs are also used by other applications. The software is also used to perform maintenance operations, as required, for an existing OPLAN. APS program must include support services such as Final Acceptance Processing (FAP) Checker, Air Vehicle Tape Validation Tool (ATVT), TERCOM Placement and evaluation Program (TPEP) and etc. Engineering and software services for maintenance and analysis of Government-owned mission planning software; on-site support for planners; provision of interoperability with other necessary programs; correction of known software deficiencies; incorporation of guidance changes; maintenance of the capability to fix both non-critical and emergency (urgent) Software Change Requests (SCRs); and application training to personnel. The requirement also includes provisions for enhancements and code development.

The Joint Functional Component Command Global Strike (JFCC GS) J54 sponsors Air Vehicle Planning System V components. The ISPAN MPAS Branch (ESC/HSB) is designated as the Program Management Office (PMO) responsible for all management actions associated with this contract. The Procuring Contracting Office is the 55th Contracting Squadron (55 CONS/LGCZ), which is responsible for overall contract management of this effort. The primary users of APS are JFCC Global Strike. The primary operating site is United States Strategic Command (USSTRATCOM), Offutt Air Force Base, Nebraska. Secondary locations and users are located throughout the continental United States and in the future will be on mobile platforms.

Scope Program Objectives The objectives of Air Vehicle Planning System V are to provide engineering and software services for maintenance and analysis of Government-owned mission planning software; on-site support for planners; provision of interoperability with other necessary programs; correction of known software deficiencies; incorporation of guidance changes; maintenance of the capability to fix both non-critical and emergency (urgent) Software Change Requests (SCRs); and application training of personnel for ISPAN at the best value to the Government. The APS components are a subsystem of ISPAN, which supports assigned missions. The Air Vehicle Planning System V contract requires the inclusion of all current air vehicle planning capabilities, maintenance and enhancement of current capabilities, the development of selected new capabilities upon government request, and the integration of APS components into the ISPAN environment, as required.

Contract Technical Objectives The contract objectives are to provide cost-effective engineering support for maintenance and enhancements to sustain air vehicle planning viability and ensure integration with the overall planning environment and potentially to bring new requirements into the APS component. The contract requires the software and database 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 system.

Sustain Current Capabilities First and foremost, the Contractor shall be responsible for preserving all the current mission capabilities of APS. It should be noted that the entirety of the current mission capability is not completely documented in existing requirements documentation. 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 APS shall remain the production, maintenance, and verification of the Operational Plan (OPLAN) 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.

Modernize Applications APS operates within the larger structure ISPAN. The Air Vehicle Planning System V Contractor shall be responsible for integrating with ISPAN activities, present and future, as requested and authorized by Government 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 APS 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 APS and other ISPAN system’s functionality, thus preventing unnecessary duplication of effort.

Support Evolving Missions The contractor shall be responsible for ensuring that APS 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.

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, tactic 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 APS incorporate or model weapon system changes as defined by the Services.

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, air vehicle planning capabilities that were formerly organized under other functional areas.

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 APS Configuration Control Board (CCB), composed of Government PMO, Functional Managers, others, and the Contractor shall convene (as specified in the Para 3.2.4) to review, prioritize, and authorize all activities related to software changes, enhancements, and deficiencies.

Follow Good Software Engineering and Coding Processes The contractor shall keep current on good software engineering and coding processes and practices.

Promote Software Reuse Software products from other systems within ISPAN may be used within APS to minimize the need for independent and potentially redundant developments.

Limit and or attempt eliminate “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.

Description of Services This section describes the overarching APS Program tasks to be performed by the Contractor to appropriately manage the common aspects of the APS Sustainment program within the ESC/HSB Air Vehicle Planning System V Sustainment and Modernization 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.

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 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 for 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 Air Vehicle Integrated Product Team (IPT) and other requested meetings.

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

· Commercial off the shelf (COTS) or Government off the shelf (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) 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.

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 APS 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) 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. The Contractor shall deliver all source code, documents and libraries required for compilation and execution of the system 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'. 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 shall be identified in schedules and work breakdown structures delivered by the Contractor. (CDRL A001) Configuration Control Board and Software Change Proposals The APS 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 APS CCB will manage the configuration of the APS baseline under both development and sustainment. The APS 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 APS CCB for approval or disapproval of the change request. SCRs submitted to the APS CCB will be analyzed by the Contractor. Upon Government request, at a minimum, the Contractor shall review and categorize the SCRs via the Basic CCB process and provide a full analysis (e.g., all acquisition functional areas such as technical, schedule, cost, logistics, etc) for APS 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. Category 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) 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 Key Performance Parameter (KPP)/Key System Attribute (KSA) and supports Technology Refresh and Sustainment recommendations to ensure that APS 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.

Reliability & Maintainability (R&M) Program Plan The Contractor shall provide a Reliability & Maintainability (R&M) Plan at the direction of the Government. (CDRL A016) 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 software failures. This system shall include how such failures can be eliminated or avoided in the future. (CDRL A019) 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, under the processes prescribed by the ISPAN Information Assurance Branch. 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 defenses in depth strategy. IA will be an integral part of the entire software development life cycle (SDLC).

All software developed will be architected, designed and maintained IAW with known industry best practices and standards, USSTRATCOM, USAF, 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 Center (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 shall 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 shall 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 (POA&M) upon delivery of source code to the government when entering Government Developmental Test and Evaluation (GDT&E) for analysis and validation. Open findings and mitigation processes shall be tracked and reported.

Information Assurance (IA) Personnel Certification The Contractor shall ensure that personnel accessing or developing 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.

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 APS 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 APS baselines IAW DISA Gold Disk and all applicable DISA Security Technical Implementation Guides (STIGs).

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

· Support the ISPAN Information Assurance Working Group.

· Support Technical Interchange Meetings.

Certification and Accreditation The APS application 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 free and open source software (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 Plan of Action and Milestones (POAM’s). 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 APS. 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 Information Assurance Vulnerability Managements (IAVMs). All GOTS, COTS, and FOSS installed on Government Furnished Equipment (GFE) hardware shall be approved by the ISPAN Information Assurance Branch prior to use.

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) 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 shall 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 processes 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 shall 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) 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. The contractor shall make at least one delivery per period of performance or according to an agreed upon schedule-le—presently twice a year. (CDRL A013, A022) The Contractor shall provide software deliveries to the Government to include computer software, installation instructions, and release notes describing changes since the previous software delivery. At minimum, deliveries shall 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 shall 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)

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 shall be accomplished before the production of APS. 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 APS programs. 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 remain open until all test procedures can be successfully executed with no Category 1 deficiencies. 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) 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, if it is 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, if it is 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) At a minimum this will include training for major releases, new capabilities brought in during a release and new operator training.

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.

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 to include: (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.

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 to include: (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 reduced total ownership cost 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 APS 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 properly completed (closed).

· The status of the technical effort and design indicates UAT success.

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

· Development risks are known and manageable for Developmental 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.

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 and brief the results of CDT&E and fulfillment of test exit criteria. A Government PMO representative will brief readiness of the software to enter GDT&E. In addition, a Contractor representative shall support any TRR as required by the Government to include: (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 properly completed (closed).

· Adequate test plans have been…