FA4600-16-R-0007_Amend_1.docx
DOCX document 475 KB Posted
- Attached to
- C2SESIII Award Federal contract opportunity
- Solicitation number
- FA4600-16-R-0007
About this file
C2SESIII RFP Amendment 1
View the file
Other files for this federal contract opportunity
Show all 37
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
FA4600-16-R-0007
FA4600-16-R-0007
SECTION SF 30 BLOCK 14 CONTINUATION PAGE
SUMMARY OF CHANGES
SECTION C - DESCRIPTIONS AND SPECIFICATIONS
The following have been modified:
PERFORMANCE WORK STATEMENT
PERFORMANCE WORK STATEMENT
FOR
USSTRATCOM COMMAND AND CONTROL
SOFTWARE ENGINEERING AND SUPPORT III
(C2SES III)
1 September 2017
USSTRATCOM Command and Control Software Engineering and Support III (C2SES III) Performance Work Statement (PWS)
Name:
Organization:
| Address: |
| [physical mailing address] |
Executive Summary The USSTRATCOM Command and Control Software Engineering and Support (C2SES) program provides Commander (CDR) USSTRATCOM, supported Combatant Commands, Component Commands, and other authorized users with modernized mission critical communications and computer systems utilizing common integrated information and decision toolsets, applications and capabilities in a fully synchronized, net-centric information environment, necessary to maintain deterrence and, if required, dominate in conflict. As the successor to C2SES II, C2SES III will continue to provide total lifecycle program management of these systems, applications, and toolsets.
USSTRATCOM C2SES III PWS.
Table of Contents
| 1 | PURPOSE | 6 |
| 2 | SCOPE | 7 |
| 2.1 | Force Status Readiness (FSR) | 7 |
| 2.2 | Force Survivability, Analysis, and Management (FSAM) | 8 |
| 2.3 | Global Information Grid (GIG)/ Area of Responsibility (AOR) Decision Support System (GADSS) | 8 |
| 2.4 | Nuclear Planning and Execution System (NPES) Capabilities | 9 |
| 2.4.1 | NPES | 9 |
| 2.4.2 | NPES Strategic Data Loader (NSDL) | 9 |
| 2.5 | Low-to-High (L2H) Command and Control Enterprise Database (C2EDB) Data Synchronization (L2HCDS) | 10 |
| 2.6 | Other Considerations | 10 |
| 3 | REQUIREMENTS/DESCRIPTION OF SOFTWARE ENGINEERING SERVICES | 12 |
| 3.1 | Maintenance and Sustainment | 12 |
| 3.2 | Major Enhancements | 12 |
| 3.3 | Integration and Support | 13 |
| 3.4 | Software Lifecycle Management | 13 |
| 3.4.1 | Release Scope | 14 |
| 3.4.2 | Major Release Documentation & Deliverables | 14 |
| 3.4.3 | Minor Release Documentation & Deliverables | 16 |
| 3.4.4 | Patch Releases | 16 |
| 3.5 | Software Engineering Support and Test Environments | 16 |
| 3.5.1 | FSR and GADSS Environments | 17 |
| 3.5.2 | FSAM Environments | 17 |
| 3.5.3 | NPES and NSDL Environments | 18 |
| 4 | REQUIREMENTS FOR SYSTEM ENGINEERING AND SUPPORT SERVICES | 19 |
| 4.1 | System Engineering | 19 |
| 4.1.1 | Application System Engineering | 19 |
| 4.1.2 | Requirements Analysis and Management | 20 |
| 4.1.3 | System Analysis and Integration Support | 20 |
| 4.2 | Communication Engineering | 21 |
| 4.3 | Configuration Management | 22 |
| 4.4 | Quality Assurance | 22 |
| 4.5 | Security Engineering | 23 |
| 4.5.1 | System Security and Information Assurance (IA) | 23 |
| 4.5.2 | Application Security and IA | 23 |
| 4.6 | System and Database Administration | 24 |
| 4.6.1 | NPES Database Support | 24 |
| 4.6.2 | NPES System Administration (SA) | 25 |
| 4.6.3 | GADSS Database Support | 26 |
| 4.6.4 | FSAM System Administration (SA) | 26 |
| 4.6.5 | FSAM Database Support | 27 |
| 4.7 | Testing | 27 |
| 5 | CONTRACTUAL REQUIREMENTS | 29 |
| 5.1 | Place of Performance | 29 |
| 5.2 | Normal Hours of Operation | 29 |
| 5.3 | Key Personnel | 29 |
| 5.4 | Unscheduled Technical Support and Response Times | 30 |
| 5.5 | Period of Performance | 30 |
| 5.6 | Transition Period | 30 |
| 5.7 | Government Furnished Property (GFP) | 30 |
| 5.8 | Billable Hours | 31 |
| 5.9 | Non-Personal Services | 31 |
| 5.10 | Contractor Identification | 31 |
| 5.11 | Program Management / Project Management | 31 |
| 5.11.1 | Services Delivery Summary | 31 |
| 5.11.2 | Task Order Management | 32 |
| 5.11.3 | Management Plans and Processes | 32 |
| 5.11.4 | Project Engineering and Planning | 33 |
| 5.11.5 | Integrated Product Team (IPT) | 33 |
| 5.11.6 | Program Status Reporting | 33 |
| 5.11.7 | Documentation and Data Management | 33 |
| 5.11.8 | Records, Files, and Documents | 33 |
| 5.11.9 | Personnel Security | 34 |
| 5.11.10 | Transmission of Classified Material | 34 |
| 5.11.11 | Protection of System Data | 34 |
| 5.11.12 | System and Network Authorization Access Requests | 35 |
| 5.11.13 | Travel | 35 |
| 5.11.14 | Other Direct Cost (ODC) | 35 |
| 5.12 | Training | 35 |
| 5.12.1 | Mission-Unique Training | 35 |
| 5.12.2 | Other Government-Provided Training | 36 |
| 5.13 | Data Rights and Non-Commercial Computer Software | 36 |
| 5.14 | Software Support and Data Rights | 36 |
| 5.15 | COTS Manuals and Supplemental Data | 36 |
| 5.16 | Enterprise Software Initiative | 36 |
| 5.17 | Software License Management | 37 |
| 5.18 | Report Contract Labor Hours | 37 |
| 5.19 | Transition and Decommissioning Plans | 37 |
| 5.20 | Continuation of Essential Contractor Services during Crisis Declared by the President of the United States, the Secretary of Defense, or Combatant Commander | 37 |
| 5.21 | Ordering Period | 37 |
| 5.22 | COMSEC Notice | 38 |
| 5.23 | Environmental Awareness | 38 |
| 5.24 | Government Insight & Access to Government Records | 38 |
| 5.25 | Organizational Conflicts of Interest Avoidance | 38 |
| 5.26 | Permits and Responsibilities for Work | 39 |
| 5.27 | Unauthorized Representation/Work | 39 |
| 5.28 | Use of Tobacco in DoD Facilities | 40 |
| 5.29 | Utility Service on Government Facility | 40 |
| 5.30 | Motor Vehicle Operation on Base | 40 |
| 5.31 | Associated Contractor Agreements | 41 |
| 5.32 | Anti-Terrorism Information and Considerations | 42 |
| 5.33 | Integrated Team Process (ITP) | 43 |
| 5.34 | Procurement of Material/Equipment | 43 |
| 5.35 | Access to Installations/Buildings/Containers | 44 |
| 5.36 | Post Award/Pre-Performance Conference | 44 |
| 5.37 | Use of Contractor Personnel | 44 |
| 5.38 | Equipment/Software Modifications/Substitution/Additions | 44 |
| 5.39 | Required Insurance | 44 |
| 6 | DATA DELIVERABLES | 46 |
| 7 | TASK ORDER REQUIREMENTS | 47 |
| 8 | Contractor Services Delivery Summary | 49 |
| 8.1 | Quality of Product of Service | 49 |
| 8.2 | Schedule | 49 |
| 8.3 | Management of Key Personnel | 50 |
| 8.4 | Program Management | 50 |
| 8.5 | System Support | 51 |
PURPOSE
The missions of United States Strategic Command (USSTRATCOM) are: to detect, deter, and prevent attacks on United States (US) vital interests, to ensure US freedom of action in space and cyberspace, to deliver integrated kinetic and non-kinetic effects to include nuclear and information operations in support of US Joint Force Commander operations, to synchronize global missile defense plans and operations, to synchronize regional combating weapons of mass destruction plans, to provide integrated surveillance and reconnaissance allocation recommendations to the Secretary of Defense (SECDEF), and to advocate for capabilities as assigned.
The USSTRATCOM C2SES program provides Commander (CDR) USSTRATCOM, supported Combatant Commands, Component Commands, and other authorized users with modernized mission critical communications and computer systems utilizing common integrated information and decision toolsets, applications and capabilities in a fully synchronized, net-centric information environment, necessary to maintain deterrence and, if required, dominate in conflict. As the successor to C2SES II, C2SES III will continue to provide total lifecycle program management of these systems, applications, and toolsets.
SCOPE
The C2SES III contractor shall assemble a cohesive team to effectively implement best practice processes to manage the execution and delivery of USSTRATCOM command and control (C2) software requirements. The contractor shall provide software engineering, system engineering, testing, integration, installation, security engineering, administrative and additional support tasks required to provide reliable, effective, and user-friendly net-centric capabilities contributing to the overall operations and maintenance of USSTRATCOM C2 capabilities. For NPES, development system management and system administrative support shall be provided by the C2SES III contractor. FSAM requires C2SES III support for Integrated Tactical Warning and Attack Assessment (ITW/AA) community testing with FSAM and the Processing and Display Subsystem – Migration (PDS-M), and the Subscriber Terminal Network Terminal (STNT) meeting support, scenario checkout, requirement verification, problem tracking, and initial software and communications problem analysis for FSAM and PDS-M are also required.
The Government seeks disciplined system engineering and software life cycle processes to provide software sustainment, enhancement, optimization, and testing of C2 systems, applications and tools supporting mission requirements and improve operator performance and capability.
The Government expects a contractor and Government partnership to provide the Government clear and constant visibility into all aspects of the program. The contractor shall be responsive to the continuing evolution of USSTRATCOM mission sets, able and willing to adjust as requirements, tasks, and priorities change. Contending contractors shall use this PWS as the basis for preparing proposals, to include a Work Breakdown Structure (WBS), for Government consideration.
The systems/applications included in C2SES III are:
Force Status and Readiness (FSR) Force Survivability, Analysis, and Management (FSAM) Global Information Grid (GIG)/ Area of Responsibility (AOR) Decision Support System (GADSS) Nuclear Planning and Execution System (NPES) and NPES Strategic Data Loader (NSDL) Low to High (L2H) Systems/applications details are provided in the documents available in the bidder’s library, and a summary is provided in the following sections.
Force Status Readiness (FSR) USSTRATCOM Force Status (FS) reporting capabilities are provided by the Force Status Readiness System. The system design is described in the Force Status Readiness (FSR) System/Subsystem Design Description (SSDD) provided in the bidder’s library. In addition, the Force Status Readiness (FSR) Software Design Description (SDD) identifies the software developed and maintained for FSR. The FSR software is deployed in two security domains. The FSR software interfaces with external systems and services including but not limited to databases, mail service, directory service, external web services, cross-domain solution (CDS), and network load balancer. The application environment (e.g., servers, storage, network, and workstations), services, and communication devices used in the software support, test, and production environments are located at Government facilities and are provided and supported by the Government thru other contracted resources.
The database services required by FSR are provided by the C2EDB. The database and data administration support required for the FSR software are provided by Government organizations and other contractors. The C2SES III contractor will recommend updates and coordinate changes to the database requirements with the Government for the FSR application. The scheduling of changes to FSR software must align to and support the applicable C2EDB version release and take into consideration any ITW/AA vertical changes required.
FSR software engineering and support includes addressing changes in the C2EDB schemas, external systems/applications interfacing FSR, functional enhancements, and system maintainability. Corrective changes include eliminating software deficiencies and errors, as well as adapting and updating software tools/technologies to better support user requirements. System and software requirement changes are driven by the user’s operational requirements and plans, the C2EDB and CDS designs and implementations, system utilities, tool set changes, and version upgrades to the commercial software required by FSR. The Government expects the contractor to continually monitor software and system performance, and the supportability and compatibility of all technologies included in the FSR application and environments. The contractor is expected to, based on direction and approval by the Government, address necessary updates and changes to the FSR software.
Force Survivability, Analysis, and Management (FSAM) USSTRATCOM Force Survival (FS) and Force Management (FM) capabilities are provided by the FSAM. The system design is described in the Force Survivability, Analysis, and Management (FSAM) System/Subsystem Design Description (SSDD) available in the bidder’s library. In addition, the Force Survivability, Analysis, and Management (FSAM) Software Design Description (SDD) identifies the software developed and maintained for FSAM.
FSAM software interfaces with external systems and services including but not limited to databases, directory service, cross-domain solution, and network load balancer. The application infrastructure (e.g., servers, storage, network, workstations) and communication devices used in the software support, test, and production environments are located at Government facilities and are provided and supported by the Government thru other contracted activities.
The database services required by FSAM are provided by the C2EDB. The database and data administration support required for the FSAM software are provided by Government organizations and contracted resources. The C2SES III contractor will recommend updates and coordinate changes to the database requirements with the Government for the FSAM application. The scheduling of changes to FSAM software must align to and support the applicable C2EDB version release.
FSAM software engineering and support includes addressing changes driven by C2EDB schema modifications and integration, external interfaced systems/applications, functional enhancements, and system maintainability. Corrective changes include eliminating software deficiencies and errors, as well as adapting and updating software tools/technologies to better support user requirements. System and software requirement changes are driven by the user’s operational requirements and plans, the C2EDB and CDS designs and implementations, algorithm and message changes applicable to Integrated Tactical Warning and Attack Assessment (ITW/AA) programs, system utilities, tool set changes, and version upgrades to commercial software required by FSAM. The Government expects the contractor to continually monitor software and system performance, and the supportability and compatibility of all technologies included in the FSAM application and environments. The contractor is expected to, based on direction and approval by the Government, address necessary updates and changes to the FSAM software. The scheduling of changes to FSAM software must align to and support the applicable ITW/AA version release.
Global Information Grid (GIG)/ Area of Responsibility (AOR) Decision Support System (GADSS) The GADSS software with the companion GADSS database provides capabilities to identify, analyze, track, and report GIG AOR events by the USSTRATCOM Network Operations (NetOps) C2 Watch Officer. The NetOps C2 Watch Officer can then, via GADSS’ collaborative and reporting capabilities pass operational mission impacts to the NetOps operational and maintenances teams. The system design is available in the Global Information Grid (GIG)/ Area of Responsibility (AOR) Decision Support System (GADSS) System/Subsystem Design Description (SSDD) provided in the bidder’s library.
The GADSS database design for GADSS will be provided by the C2SES III Contractor. The GADSS database administration support is provided by Government organizations and other contracted resources. The application infrastructure (e.g., servers, storage, network, workstations) used in the software support, test, and production environments are located at Government facilities and are provided and supported by the Government thru other contracted activities.
Nuclear Planning and Execution System (NPES) Capabilities The Nuclear Planning and Execution System (NPES) is a C2 information system providing data analysis and decision making information during peacetime and crises involving strategic nuclear operations. NPES provides information to the National Command Authorities (NCA) in the critical phases of nuclear conflict. NPES is installed at multiple locations both ground based and airborne. Each NPES installation receives updates and communicates with other NPES installed locations through several communication channels.
The application infrastructure (e.g., servers, storage, network, workstations) used in the software support and test are located at Government facilities and are provided by the Government but will be administered by the C2SES III Contractor. This includes the system administration and database administration services. These services are identified in C2SES III Support Services section of this PWS. The C2SES III Contractor will need to identify and perform system and database administration changes and updates as required by the NPES applications, infrastructure, and as affected by changes from external systems and data sources. The system and database administration will also provide support/assistance to the Government and other contractors in deployment and issue resolution at the NPES production and user testing locations.
NPES
The NPES software provides Force Management, Force Direction, Planning, Situational Awareness, and Execution capabilities. The system and software design documentation is provided in the bidder’s library location.
NPES software engineering and support includes addressing adaptive software changes driven by integrated Government off-the shelf (GOTS) and Commercial-off-the-shelf (COTS) software, external data sources including schema modifications and integration, external interface maintenance, functional enhancements, and system maintainability. Corrective changes include eliminating software deficiencies and errors, as well as adapting and updating software tools/technologies to better support user requirements. System and software requirement changes are driven by the user’s operational requirements and plans, the external data sources, changes to CDS designs and implementations, algorithm and message changes applicable to Integrated Tactical Warning and Attack Assessment (ITW/AA) programs, system utilities, tool set changes, and upgrades to both Government provided software and commercial software required by NPES. The Government expects the contractor to continually monitor software and system performance, and the supportability and compatibility of the entire set of technologies included in the NPES application and environments. The contractor is expected to, based on direction and approval by the Government, address necessary updates and changes to the NPES software. The scheduling of changes to NPES software must align to and support the applicable external data sources.
NPES Strategic Data Loader (NSDL) The NPES Strategic Data Load (NSDL) application is used to extract data from the Integrated Strategic Planning and Analysis Network (ISPAN) Enterprise Database (EDB) for input to NPES. The NSDL software pulls data from an ISPAN EDB and stores the extracted data in files. These files are then distributed for use to NPES locations through two modes. The first mode pulls NPES required data from the current plan, validates, and prepares the data for distribution (via CD, DVD, or electronic transfer). The second mode retrieves selected portion of data and prepares messages for transmission to NPES locations. The NSDL software engineering and support includes addressing application changes driven by the ISPAN EDB and changes to NPES. The EDB changes and cutovers are managed by the USSTRATCOM ISPAN program and are scheduled semiannually with potential interim cutovers as planning circumstances dictate. NSDL releases must align with both the EDB release schedules and NPES release schedules. The details for the NSDL application are provided in the bidder’s library. NSDL software engineering and support includes addressing adaptive software changes driven by external data sources including schema modifications, integration, and system maintainability. Corrective changes include eliminating software deficiencies and errors, as well as adapting and updating software tools/technologies to better support user requirements.
Low-to-High (L2H) Command and Control Enterprise Database (C2EDB) Data Synchronization (L2HCDS) USSTRATCOM Force Status (FS) database synchronization capabilities are provided by the L2HCDS system. The system design is described in the L2HCDS System/Subsystem Design Description (SSDD) provided in the bidder’s library. In addition, the L2HCDS Software Design Description (SDD) identifies the software developed and maintained for L2HCDS.
The L2HCDS software is deployed in two security domains. C2EDB data is replicated to the TS C2EDB via low-to-high cross security domain process using the Secure Message and Routing Terminal Next Generation (SMART.neXt) system. The SMART.neXt provides a two-way file exchange capability that the L2HCDS uses to transfer C2EDB data and process status message between the Secret and TS-C security domains.
The L2HCDS software interfaces with external systems and services including but not limited to databases, mail service, directory service, cross-domain solution (CDS), and network load balancer. The application environment (e.g., servers, storage, network, and workstations), services, and communication devices used in the software support, test, and production environments are located at Government facilities and are provided and supported by the Government thru other contracted resources.
The database services required by L2HCDS are provided by the C2EDB. The database and data administration support required for the L2HCDS software are provided by Government organizations and other contractors. The C2SES III contractor will recommend updates and coordinate changes to the database requirements with the Government for the L2HCDS application. The scheduling of changes to L2HCDS software must align to and support the applicable C2EDB version release and take into consideration any ITW/AA vertical changes required.
L2HCDS software engineering and support includes addressing changes in the C2EDB schemas, external systems/applications interfacing L2HCDS, functional enhancements, and system maintainability. Corrective changes include eliminating software deficiencies and errors, as well as adapting and updating software tools/technologies to better support user requirements. System and software requirement changes are driven by the user’s operational requirements and plans, the C2EDB and CDS designs and implementations, system utilities, tool set changes, and version upgrades to the commercial software required by L2HCDS. The Government expects the contractor to continually monitor software and system performance, and the supportability and compatibility of all technologies included in the L2HCDS application and environments. The contractor is expected to, based on direction and approval by the Government, address necessary updates and changes to the L2HCDS software.
Other Considerations The USSTRATCOM Chief Information Office (CIO) has directed the migration of mission systems to a Common Computing Environment (CCE) (see CCE Policy letter in bidder’s library). This direction affects the C2 systems, and requires a migration from a Solaris operating system on a SPARC-based architecture to a Linux operating system on x86-64 commodity hardware operating within VMWare virtual machines. The C2 portfolio has also made the decision to standardize the mid-tier technology to utilize the JBoss Application Server. The C2 systems described herein are all in the process of migrating to the CCE. All of the systems will be fully transitioned to the new environment prior to the start of this contract.
Early in the C2SES III contract, personnel and operations will transition to the new USSTRATCOM Headquarters (HQ) C2 Complex, currently under construction. The C2SES III contractor will support the transition of hardware and software to the new environment (installation and checkout, system testing, etc.). New building transition plans are still evolving, so it is unknown the extent of the impact on C2SES III activities.
REQUIREMENTS/DESCRIPTION OF SOFTWARE ENGINEERING SERVICES
The bidder’s library contains as-is documentation describing the system and software architectures, coding languages, size, complexity, etc., of the current system/software baselines for the systems identified in Section 2. The Contractor shall use this information to define the scope of effort required and ensure engineering staffing levels, skills, and experience levels are sufficient to successfully deliver the software engineering services describe herein. All software engineering services must comply with applicable documents and standards specified in Section 7 of this PWS.
Maintenance and Sustainment System/software maintenance and sustainment requirements as defined in this PWS will be applied as part of a software delivery specified in Section 3.4, Software Life Cycle Management. Software maintenance addresses corrective, preventive, adaptive, and perfective changes/updates to the applications identified in Section 2 of this PWS. Software sustainment includes documentation, deployment, security, configuration management, integration of GOTS and COTS software, and technology refreshes. As part of the on-going software maintenance and sustainment, the use of the Agile Software methodology is greatly encouraged, subject to Government approval. (CDRL A001, B001, C003) The Contractor shall:
1. Perform corrective, adaptive, perfective, and preventive maintenance, and provide associated documentation, as required.
1. Modify/enhance software to ensure a strong security posture and address government security findings and information assurance vulnerability alert (IAVA), Information Assurance Vulnerability Bulletins (IAVB), technical advisories and Cyber Vulnerability Assessments.
1. Develop schedules and implementation plans, including dependencies and need dates, identification of technical approaches, and a description of anticipated expected results.
1. Design, develop, test and package software for release.
1. Maintain the current baselines of the systems and provide software changes and problem fixes to these baselines as required.
1. Provide to the Government all developed, modified, or converted source modules, processes, programs, scripts, operating instructions, databases, system files, documentation, test files and test conditions, and deficiency reports (DRs) for each software release.
1. Ensure software engineering efforts are compatible with other C2 systems’ hardware, software, and architectures, including Integrated Strategic Planning and Analysis Network (ISPAN) Enterprise Database (EDB) and the C2EDB.
Major Enhancements Major system/software enhancements as defined in this PWS will be applied as part of a software delivery specified in Section 3.3, Software Life Cycle Management. Major system/software enhancements addresses major changes to the mission or communication capabilities to the applications identified in Section 2 of this PWS. Major system/software enhancements includes documentation, deployment, security, configuration management, integration of GOTS and COTS software, and technology refreshes. As part of the on-going system/software enhancement, the use of the Agile Software methodology is greatly encouraged, subject to Government approval. (CDRL A001, B001, C003)
The Contractor shall:
1. Conduct analysis of known and/or future identified enhancement capabilities to determine how the applications identified in Section 2 are impacted.
1. Develop schedules and implementation plans, including dependencies and need dates, identification of technical approaches, and a description of anticipated expected results.
1. Modify/enhance software to ensure a strong security posture is properly maintained.
1. Design, develop, test and package software for release.
1. Maintain the current baselines of the systems and provide software changes and problem fixes to these baselines as required.
1. Provide to the Government all developed, modified, or converted source modules, processes, programs, scripts, operating instructions, databases, system files, documentation, test files and test conditions, and deficiency reports (DRs) for each software release.
1. Ensure software engineering efforts are compatible with other C2 systems’ hardware, software, and architectures, including Integrated Strategic Planning and Analysis Network (ISPAN) Enterprise Database (EDB) and the C2EDB.
Integration and Support Systems/software integration and support will be performed by the Contractor as part of a software delivery specified in Section 3.3 Life Cycle Management. Software designs and baseline include both GOTS and approved COTS software and tools delivered capabilities. (CDRL C004) The Contractor shall:
1. Perform system performance tuning and update software for compatibilities with technology changes (e.g., tech refresh), and integrate services as requested by the Government.
1. Perform the necessary software updates/changes to incorporate where applicable the integration with GOTS and approved COTS software.
Software Lifecycle Management Changes to system/application software may be required to reflect changes in national guidance and/or USSTRATCOM policy; implement Government prioritized, user-defined, functionality requirements; correct software deficiencies identified in the production environment; and incorporate compatibility upgrades resulting from changes in weapon systems, other C2 applications/databases, and supporting infrastructure. Based on user prioritization of requirements and C2 program management guidance, software changes will be delivered to the operational environment via scheduled releases. (CDRL A001, C003) The Contractor shall:
1. Coordinate software change requests, deficiency reports, and projects into scheduled releases in coordination with the Government.
1. Support major releases, minor releases, and security patch support for each application/system as defined in the task orders (TOs).
Major and minor releases are defined as follows:
1. A major release identifies a component or product delivered is incompatible with the previous major release, and indicates enhanced/new functionality is included in the software and/or product structure changes have been included. The duration of a major release is approximately 6-9 months, or longer.
1. A minor release indicates functional enhancements to the product. A minor release must be compatible with previous version of the same major release. A minor release does not necessarily require a re-install of the product, but can be overlaid on top of the existing installation. The duration of a minor release is approximately 3-6 months.
1. A security patch support addresses security issues for the program and may or may not be scheduled separately from directed software releases. A security patch release does not necessarily require a re-install of the product, but can be overlaid on top of the existing installation and easily removed if required. The duration of a security patch is approximately 30-90 days.
Release Scope The Government may reorder priorities and/or add other capabilities as mission requirements dictate. Delivery and implementation of software releases will be made upon completion of each item, following the test processes defined by the IPT and in accordance with (IAW) the requirements of paragraph 4.7 of this PWS. Updated product documentation, regression testing and performance testing will be required, incorporating all software changes for the release.
The Government, in coordination with the Contractor, will prioritize requirements for major and minor releases for each of the systems identified in section 2. The Contractor, in coordination with the Government, will prioritize requirements for security patch releases for each of the systems and make release schedule recommendations to the Government for approval for each of the systems identified in Section 2. The Government may decide to forgo one or both minor releases for a specific system, in which case the Contractor software engineering hours will be reallocated for a specific system. (CDRL A003, C004) The Contractor shall:
1. Analyze and recommend solutions to change requests (CRs) for Government prioritization and approval.
1. Incorporate prioritized user-defined mission requirement capabilities and adaptive, corrective, and perfective CRs into software support efforts for each version release.
1. Identify COTS software products and license requirements to be utilized in both support and operations of C2 applications.
1. Deliver modified software to operational units utilizing Government delivery resources or through remote capabilities.
The Contractor is responsible for determining the optimum skill mix based on software code complexity and current system/application architecture, as described in bidder’s library artifacts.
Major Release Documentation & Deliverables The Contractor shall provide updated documentation and other required deliverables IAW the type of release, CM Policy, C2 SEMP and C2 Test Process documents. Delivery and implementation of these releases will be made upon completion of each item.
The Contractor may use Agile Software methods for each release cycle, but the current set of system life cycle documentation or its equivalent must be maintained. The employment of Agile methods may drive changes to Government defined software lifecycle documentation to align to internal methods (e.g., iterative and incremental). Contractor proposed modifications to the documentation set delivered for each release, as listed below and defined in the C2 SEMP, are subject to Government approval. (CDRL C003, C004, C005) At a minimum, the Contractor shall update and deliver the documentation (or its equivalent) identified in Table 1 for each major release, including incorporation of any outstanding change pages from minor releases/patches.
Table 1 Major Release Documentation
| Release Documentation |
| FSR |
| FSAM |
| GADSS |
| NPES |
| NSDL |
| Software Requirements Specification (SRS) or updated baseline software requirements spreadsheet |
| X |
| X |
| X |
| X |
| X |
| System/Subsystem Design Description (SSDD) |
| X |
X
| Software Design Description (SDD) |
| X |
| X |
| X |
| X |
| X |
Database Design Description (DBDD)
| X1 |
| X1 |
| X |
| Interface Design Description (IDD) |
| X |
| X2 |
| X |
Interface Control Document (ICD)
X
| Software Test Plan (STP) |
| X |
| X |
| X |
| X |
| X |
| Software Test Description (STD) or test case descriptions (spreadsheet) |
| X |
| X |
| X |
| X |
| X |
| Software Test Report (STR) |
| X |
| X |
| X |
| X |
| X |
| Configuration and Installation Guide (CIG) |
| X |
| X3 |
| X |
| X5 |
| X5 |
Software User Manual (SUM)
X4
X6
| Software Version Description (SVD) |
| X |
| X |
| X |
| X |
| X |
| Web Service documentation (as required) |
| X |
X
| Requirements/Design/Readiness Review agendas, presentations, and meeting minutes |
| X |
| X |
| X |
| X |
| X |
Table 1 Notes
1. GADSS and FSAM maintain DDL for the GADSS and FSAM databases, but not a formal DBDD.
1. Description of the FSAM interface design is currently included in the SDD.
1. FSAM refers to this as “Software Installation Guide”.
1. FSAM refers to this as “User Operator Manual”.
1. Delivered as part of the SVD.
1. NPES Software User’s Manual maintained in online help (not a document delivery).
Minor Release Documentation & Deliverables For each minor release, the Contractor will develop and maintain document change pages for all system/software life cycle documentation, for incorporation into the updated/revised documentation at the next major release. (CDRL C003, C004, C005) In addition, and as a minimum, the Contractor shall deliver the documentation identified in Table 2 for each minor release.
Table 2 Minor Release Documentation
| Release Documentation |
| FSR |
| FSAM |
| GADSS |
| NPES |
| NSDL |
| Software Test Description (STD) or test case descriptions (spreadsheet) |
| X |
| X |
| X |
| X |
| X |
| Software Test Report (STR) |
| X |
| X |
| X |
| X |
| X |
| Configuration and Installation Guide (CIG) |
| X |
| X1 |
| X |
| X2 |
| X2 |
| Software Version Description (SVD) |
| X |
| X |
| X |
| X |
| X |
| Requirements/Design/Readiness Review agendas, presentations, and meeting minutes |
| X |
| X |
| X |
| X |
| X |
Table 2 Notes
1. FSAM refers to this as “Software Installation Guide”.
1. Delivered as part of SVD.
Patch Releases In order to comply with IA requirements or emergency changes driven by real-world operational needs, patch releases may be required to ensure delivered software meets warfighter needs.
The Contractor shall prepare and implement software patches IAW Government direction. The only documentation required for a patch release is the Software Test Report (STR) and the Software Version Description (SVD). Guidance for other documentation will be provided by the Government, driven by the nature and complexity of the patch, capability changes to the system, and the mission urgency for deployment. Hours expended in the analysis of software patches are included in the total number of software engineering hours available for a specific system. (CDRL C003, C004, C005) Software Engineering Support and Test Environments The software engineering environments for evaluating, updating, testing, and maintaining software are provided by the Government and located at the Government location. The environments are supported by automated tools, manual procedures, or both. The Contractor may propose changes where they have the greatest impact and improvement on software quality and engineer productivity. The tools for managing system requirements, configurations and changes, acceptance testing, and verification and validation are provided by the Government. (CDRL A002, C004) The Contractor shall:
1. Perform all analyses and responses to stakeholder requests, software discrepancy reports (DRs), and software change request (CRs) on the Government specified network.
1. Track, manage, and provide status of all stakeholder requests, software discrepancies, and change requests in a Government provided repository (e.g., JIRA).
FSR and GADSS Environments The environment for FSR and GADSS software maintenance and acceptance test activities are provided by Government with administration of environment through other Contractors managed by the Government (i.e., not C2SES III). (CRDL C004) The Contractor shall:
1. Perform all FSR and GADSS software evaluations, updates, changes, and maintenance in the Government provided environments.
1. Coordinate all environment administration required for software engineering activities with Government Program Manager (PM).
1. Assist the Government PM in identifying and troubleshooting any issues with the software engineering environments.
1. As required, assist administration personnel in troubleshooting any system performance issues.
FSAM Environments The software engineering activities for FSAM will be accomplished in the Government specified environment. A dedicated environment is provided by the Government for the FSAM software engineering and support activities including all software changes. The environment for FSAM acceptance test activities is provided by the government with administration of the environment through other Contractors managed by the Government (i.e., not C2SES III). (CDRL C004) The Contractor shall:
1. Perform all FSAM software evaluations, updates, changes and maintenance in the dedicated FSAM development environment.
1. Coordinate all test environment administration required for software engineering activities with Government PM.
1. Assist the Government PM in identifying and troubleshooting any issues with the acceptance test environment.
1. As required, assist administration personnel in troubleshooting any system performance issues.
1. Coordinate all FSAM system and database administration required for software engineering activities with support teams provided as part of C2SES III.
1. Migrate the existing FSAM development support environment, where “development support environment” includes developmental tools (e.g. JIRA, Subversion, and Jenkins) and also migrate development application servers, to the USSTRATCOM C2LAN, maintain the existing FSAM development support environment and development applications servers and, where feasible, consolidate the hardware and software of the FSAM and existing C2SES support environments.
NPES and NSDL Environments The software engineering activities for NPES and NSDL will be accomplished in the Government specified environment. A dedicated environment is provided by the Government for the NPES software engineering and support activities including all software changes and software acceptance testing.
The Contractor shall:
1. Perform all NPES and NSDL software evaluations, updates, changes and maintenance in the dedicated NPES environment.
1. As required/requested, support testing activities performed at airborne ground facilities (e.g., integration labs, maintenance facilities).
1. Coordinate all NPES system and database administration required for software engineering activities with support teams provided as part of C2SES III.
REQUIREMENTS FOR SYSTEM ENGINEERING AND SUPPORT SERVICES
The Contractor shall apply high quality, cost-effective system engineering and support processes to meet the functional, operational, and technical requirements identified by the Government, and ensure compatibility with specified hardware, software, and database architectures (e.g., critical interfaces with other C2, war planning, and missile warning systems). This includes, but is not limited to, system engineering analyses and trade studies; integration analysis and design; requirements analysis and management; communications engineering; technical management and control; system/software design and architecture; integrated risk management; configuration management and quality assurance; data management; system security and IA; and test, evaluation, verification and validation. All system engineering and support services must comply with applicable documents and standards specified in Section 7 of this PWS.
System Engineering The Contractor shall apply robust systems engineering processes to align with the USSTRATCOM C2 Systems Engineering Management Plan (SEMP) in support of the Government system engineering team. The SEMP addresses the performance expectations of all USSTRATCOM C2 system-level engineering activities throughout each application’s lifecycle. It describes the key system engineering functions, organizations, processes, and related tasks as they pertain to the modernization and sustainment of the systems. (CDRL A001. C001, C003, C004) The Contractor shall:
1. Implement disciplined system engineering processes IAW the C2 SEMP, unless specifically modified/tailored within this PWS. Any waivers or deviations to the C2 SEMP require approval by the J864 Branch Chief.
1. Prepare and deliver the Contractor’s Software Development Plan (SDP) to the COR and CO within 30 days of contract award.
1. Oversee all engineering activities and ensure the use of common system engineering processes, software tools, techniques, and where practicable, services/languages/libraries/code.
1. As required, leverage full corporate expertise, specialized technical expertise, and reach back resources.
1. Utilize industry best practices to accommodate DOD, Government, commercial, industry, and similar requirements.
Application System Engineering The Contractor shall provide system engineering services to support the sustainment and enhancement of C2 systems/applications. Efforts include strategic technical planning to address planned upgrades or changes to the operational environment, changes/upgrades to interfacing systems, major requirements identified by C2 functional managers, and analyses to drive cost efficiencies and reduce life-cycle costs. (CDRL A001. C001, C003, C004) The Contractor shall:
1. Support the analysis and design of systems and applications and their integration into the overarching enterprise architecture.
1. Provide standard data items and software technical reviews and products IAW the C2 SEMP.
1. Formulate and document descriptions of system architectures and interfaces.
1. Identify activities for Government prioritization and approval to keep the C2 systems/applications sustainable, including required version updates to both GOTS and COTS products integrated within the baseline.
1. Support Technical Refresh activities as directed by the Government.
1. Perform preliminary system concept studies/analysis, conduct technical trade studies, and analyze alternative design approaches to satisfy requirements.
1. Document the results of all analyses/studies and deliver results and recommendations to the Government for approval.
Requirements Analysis and Management The Government is ultimately responsible for the management of all system requirements, but requires support from the Contractor in the management of the software requirements baseline. Stakeholder requests must be analyzed and validated within the scope of the approved baseline requirements, and changes to the requirements baseline will be managed through close coordination/collaboration by the Government and Contractor.
The Contractor shall:
1. Implement standardized processes to conduct detailed requirements analyses.
1. Define software-level requirements.
1. Develop derived requirements and establish traceability to Government system-level requirements.
1. Ensure the Contractor established/managed software-level requirements are traceable to and address all of the Government established/managed requirements for all C2 systems and applications covered under this contract.
1. Review requirements with the Government and obtain approval and permission to proceed prior to initiating software analysis and design.
1. Participate in periodic Government management board meetings (e.g., IPTs and Requirements Review Boards (RRBs)).
1. Maintain a software requirements baseline for all C2 systems and applications covered under this IDIQ.
1. Employ formal management techniques, processes, and tools to effectively manage/control Contractor established requirements for all C2 systems and applications covered under this contract. Tool selection is subject to Government approval (current tools/products are preferred, but Government is open to change).
System Analysis and Integration Support The functionality and performance of the systems and software maintained under this contract are dependent upon many external environments, systems, and enterprise services. Changes to these items often require careful analysis to ensure the delivery of mission services to the warfighter. (CDRL A001. C004) The Contractor shall:
1. Provide the Government with analysis, integration support, and system engineering on upgraded and new C2 systems.
1. Assess the degree to which the physical and functional characteristics of the C2 systems might be corrupted or adversely impacted by new or updated interfaces and capabilities being introduced, and make recommendations to avoid such adverse impacts.
1. Develop technical plans/roadmaps to address planned upgrades to GOTS and COTS hardware and software, as listed in applicable Software Version Descriptions (SVDs) and Software Design Descriptions (SDDs).
1. Ensure system integration addresses eliminating duplicate functionality, including the integration with GOTS and COTS capabilities, and leveraging net-centric and enterprise services where practicable.
1. Develop and deliver technical reports to document the results and recommendations of system and integration analyses/studies
1. Analyze the systems within the scope of this effort and make recommendations to the Government on opportunities for increased integration and enhancement of these systems.
1. Support Government during FSAM and PDS-M activities i.e. Technical Performance Evaluations (TPE), Staff Assistance Visits (SAV), Integrated Mission Area Trainings (IMAT), communications assessments, and exercise/real world events, etc.
0. Exercise support can require extended hours (beyond normal duty hours) of support during exercise days. Therefore, flexible hours are needed to support these exercises.
0. Scenario database preparation and checkout is needed approximately five days (as part of the normal duty schedule) a month.
1. Support Government during FSAM, PDS-M, and STNT requirement validation and verification, problem tracking, scenario checkout, scenario CM, and initial problem analysis
1. Provide analytical support to FSAM software change requests and deficiency reports and research inputs with appropriate staff offices
1. Provide the Government with impact analysis of FSAM system and software engineering proposed changes.
1. Analyze and checkout missile warning scenarios and provide feedback to J7 to ensure accuracy of the data input into FSAM and PDS-M.
1. Provide Government support during FSAM and ITW/AA community meetings as needed or required. Travel may be required to support occasional meetings.
Communication Engineering The systems/applications delivered under this contract are dependent upon a variety of communication systems (i.e.SMART.NeXt) for the receipt and transmission of mission data. Changes to these communication capabilities may have impact on system/application functionality and performance. Communication engineering services include, but are not limited to, maintaining related documentation, communication interface/integration engineering, analysis, and troubleshooting and problem resolution. (CDRL C004) The C2SES III Communication Engineering supports/assists the Government and other contracting resources for the connection and integration of communication devices/systems to C2 systems/applications located at fixed sites and on aircrafts.
The Contractor shall:
1. Assess impacts to C2 systems/applications within the scope of this PWS for communication system/device modernization plans, technical upgrade/refresh, and connectivity changes. Impact assessment includes analysis, determining courses-of-action, and recommend changes or necessary enhancements to sustain the services/capabilities from other communication systems/devices required for C2 systems/applications.
1. Identify and analyze system and software requirements dependent on services/capabilities provided by communication systems/devices and provide the Government with recommended actions for the integration and installation of communication systems/devices. Analysis includes proposing alternative design approaches to satisfy C2 requirements levied on communication systems/devices
1. Maintain and update communication system drawings, interface control documents, data flows, and connectivity diagrams necessary to maintain and troubleshoot C2 systems/application interfaces to communication systems/devices.
1. Assist in communication system/device testing, accreditations, and troubleshooting of communication systems/devices used by C2 systems/applications.
1. Develop and deliver…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .