Attach_3_AMP_TO_1_PWS_2_Jun_17.pdf
PDF 18 MB Posted
- Attached to
- Analysis of Mobility Platform (AMP) Federal contract opportunity
- Solicitation number
- HTC71117RD001
About this file
Attachment 3 - Task Order 1 PWS 2 Jun 17
View the file
Other files for this federal contract opportunity
Show all 24
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
HTC71117RD001
Attachment 3
PERFORMANCE WORK STATEMENT
FOR
TASK ORDER (TO) 0001
ANALYSIS OF MOBILITY PLATFORM (AMP)
2 June 2017
1.0 DESCRIPTION OF SERVICES
1.1 Background.
The Analysis of Mobility Platform (AMP) is a comprehensive transportation modeling, simulation, and optimization environment used to analyze and assess the movement of military-related cargo and personnel within the Defense Transportation System (DTS). Primary AMP users include analysts at the United States Transportation
Command (USTRANSCOM) Joint Distribution Process Analysis Center (JDPAC), Military Surface Deployment and Distribution Command Transportation Engineering Agency (SDDCTEA), Air Mobility Command (AMC) A9, Joint Staff J4 and J8, Office of the Secretary of Defense (OSD) Cost Assessment and Program Evaluation (CAPE), Headquarters, Air Force (HAF) A9, and the Center for Army Analysis (CAA). JDPAC is the functional manager for AMP.
AMP provides a comprehensive representation of end-to-end deployment and distribution, to include movement by all transportation modes within the continental United States (CONUS), inter-theater (strategic), within theater, and combinations thereof.
AMP includes quick-look tools for assessing air- and seaport enabler requirements and port throughput, as well as highly detailed simulation tools for airport, seaport, and distribution nodal modeling:
- Airport Rapid Analysis Tool (ARAT)
- Airport Throughput Tool (ATT)
- Airport Simulation Tool (AST)
- Seaport Rapid Analysis Tool (SRAT)
- Seaport Throughput Tool (STT)
- Seaport Simulation Tool (SST)
- Distribution Performance Nodal Model (DPNM)
The AMP suite also includes the Rapid Course of Action (COA) Analysis Tool (RCAT) for rapidly developing and assessing transportation COAs, as well as the Joint Mobility Closure Estimator (JMCE), a formula-based, rough order of magnitude (ROM) deployment estimator application.
AMP supports answering force closure, infrastructure, lift asset, process, and policy analysis questions. Analysts use AMP to support a variety of use cases, to include programmatic analysis, deliberate planning, crisis action planning, operational planning, exercises, and war games. AMP has served as DOD’s model of record for OSD-level major mobility programmatic studies since 1995. AMP Theater modeling capability is the long-standing program of record for theater Reception, Staging, Onward Movement, and Integration (RSO&I) analysis. JDPAC has conducted multiple Research, Development, Test, and Evaluation (RDT&E) projects within the AMP program to infuse mathematical optimization technology within the core AMP discrete event simulation environment, resulting in capabilities to enable AMP to optimally allocate and schedule air assets to movement requirements and to optimally make mode and node determination decisions. Analysts can yield solutions which drive effectiveness
(velocity), efficiency (least cost), or best value combinations while also accommodating asset readiness constraints.
AMP provides aerial refueling modeling capabilities and JDPAC has leveraged RDT&E to significantly enhance these capabilities to address such modeling and analysis requirements as track switching, tanker-to-tanker refueling, disruptive events, tanker CONOPS / schedule repair, large-scale campaign scenarios, and AR receiver demand modeling.
AMP has numerous features, all of which have been incorporated to address user requirements. Following is a short subset of these features:
- End-to-end deployment and distribution modeling environment, accommodating deployment/re-deployment and sustainment/retrograde operations of military cargo and personnel over the DTS
- Joint Operation Planning and Execution System (JOPES) time-phased force deployment data (TPFDD) movement requirements
- Extensive, detailed, geospatial representation of multi-modal transportation networks and nodes
- Extensive, detailed representation of organic and commercial lift assets
- Integrated strategic and theater airlift and sealift; channel/SAAM missions, VISA
- Integrated origin-to-destination planners and schedulers
- End-to-end and nodal discrete event simulation (DES)
- Heuristics-based mode and node determination/optimization
- Virtual Requirement Line Number (RLN) unit integrity modeling
- Schedule Optimization (i.e., Mixed Integer Programming (MIP) and Linear Programming (LP) mathematical optimization integrated within DES) and Stochastic Simulation in support of operational airlift, providing effectiveness/efficiency objective trade-offs and plan robustness
- Network Optimization (i.e., Mixed Integer Programming (MIP) and Linear Programming (LP) mathematical optimization integrated within DES) in support of strategic mode/node/transshipment determination to provide effectiveness/efficiency objective trade-offs
- Air/Sea trade-offs, multi-modal operations
- Dynamic, multi-echelon organization-based sustainment generation with inventory management and dynamic source selection
- Ashore and afloat prepositioning
- Joint Logistics Over-the-Shore (JLOTS) modeling
- Large (e.g., over 100,000 movement requirements) multi-theater, multi-OPLAN, multi-year scenario modeling, within two-hour run-time
- Simulation start-stop and exogenous event handling
- Extensive theater Reception, Staging, Onward movement, and Integration (RSOI) modeling
- Costing
- Detailed tabular, graphical, and animation output
- Aerial refueling modeling
1.2 Scope.
This Performance Work Statement (PWS) contains requirements in support of AMP development for FY18 in the following areas: Optimization, Programmatic Analysis, Operational Applications, and Seaport and Airport
Analysis. In addition, this PWS contains requirements for sustainment of AMP and Rapid Course of Action
(COA) Development and Assessment throughout FY18.
1.3 General Tasks.
Task areas with associated subtasks to be performed are Contract Management, Technical Support for Studies and Analyses, Requirements Management, Support for Design and Development, Software Maintenance, Application Administration, Security Engineering and Cyber Security Requirements, Support for Contingency
Plan Review, Configuration Management, and Increment V Capability. An additional task area included in the
Indefinite Delivery / Indefinite Quantity PWS, Sustainment Enhancements, has no requirements identified for this PWS.
1.3.1 Task Area 1 – Contract Management.
This task area shall encompass overall contract management that tracks the performance of the work and consists of the functional activities relating to the administration and management of this effort. These activities shall include administrative, clerical, documentation, and related duties that provide general support for the program.
The contractor shall provide program management for all contractor tasks, personnel resources, and costs, and shall ensure all deliverables meet schedule and budget constraints under this PWS. The contractor shall provide support by preparing documents such as required briefings, point papers and meeting minutes related to status of the performance of this PWS. The contractor shall work with the AMP Program Office, process owners/stakeholders, Federal and Department of Defense (DOD) Government representatives, and other contractors to accomplish required tasks. All decisions regarding Government requirements or Government actions will be made by Government personnel. The contractor’s representative will submit required evaluations and recommendations to the Contracting Officer’s Representative (COR) and/or Contracting Officer (CO) for further action.
1.3.1.1 Task Area 1 Subtask 1 – Plan, Organize, Control. The contractor shall provide a contract management function that tracks the performance of the work. Point of Contact (POC) information for the person(s) performing the contract management function shall be designated in writing to the Contracting Officer (CO) with a copy to the
Contracting Officer’s Representative (COR) no later than the date of the Post-Award Conference. POC information shall include name, title, phone number, and e-mail address. The contractor shall ensure all personnel assigned to this contract meet the minimum requirements specified in the contractor’s proposal, in accordance with (IAW) the generic resumes provided as part of the contractor’s staffing approach. The contractor shall notify the CO in writing of changes to key personnel within three (3) business days after information is known.
The contractor shall report ALL contractor labor hours (including subcontractor labor hours) required for performance of services provided under this contract for the Air Force via a secure data collection site, Enterprise-wide Contractor Manpower Reporting Application (eCMRA). The contractor is required to completely fill in all required data fields using the following web address: http://www.ecmra.mil/. Reporting inputs will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through
September 30. While inputs may be reported any time during the FY, all data shall be reported no later than http://www.ecmra.mil/
October 31 of each calendar year, beginning with 2018. Contractors may direct questions to the help desk at:
http://www.ecmra.mil.
The eCMRA site associated with this contract is AIR FORCE.
The Command of the Requiring Activity is AFELM USTRANSCOM.
The Unit Identification Code (UIC) for this requirement is FF0WLO.
The Federal Service Code for this contract is D308.
1.3.1.2 Task Area 1 Subtask 2 - Task Order Management Plan (TOMP). The contractor shall prepare a
TOMP that encompasses all task orders, describing tasks, dependencies, management and technical approach, organizational resources, and management controls to be employed to meet cost, performance, and schedule requirements throughout contract execution. The TOMP shall include the contractor’s approach to plan for, identify, monitor, and control risk in all phases of this effort. The contractor shall update the TOMP after receipt of each task order.
Deliverable: TOMP
1.3.1.3 Task Area 1 Subtask 3 - Monthly Status Reports (MSR). The contractor shall submit a MSR summarizing overall status, progress, and recommendations and shall include details and results of the work performed during the reporting period, identifying any issues, problem areas, and items that require Government action; work planned for the next month; change request and problem report evaluations, as necessary; dates and locations of in-process reviews (IPR) conducted; hours performed on each Contract Line Item Number (CLIN) by labor category; actual and projected expenditures; meetings attended, with a summary of relevant items discussed; cost, schedule and/or performance variance that includes a description of how the variances were determined; risk assessment and mitigation recommendations; open issues; a list of deliverables provided; and key personnel (e.g., project manager, lead developer, lead engineer) changes. Estimated and actual travel costs shall be reported, together with contractor name, trip location and purpose, and dates of travel. The MSR shall include copies of invoices for all travel performed during the reporting period.
Deliverable: MSR
1.3.1.4 Task Area 1 Subtask 4 - In-Process Reviews (IPR). The contractor shall conduct and/or host IPRs on a twice-yearly basis. The Program Manager (PM) will determine dates and whether IPRs will be held at the contractor’s site, at USTRANSCOM, via video teleconference, web-cast, or conference call. IPRs shall summarize status, progress, new capability requirements and program schedule to include new requirements, risk identification, and proposed remediation plan in any task area. The contractor shall provide a draft agenda to the PM in accordance with the schedule in the deliverable table in Paragraph 1.4. The contractor shall prepare presentation materials and provide them to the PM in accordance with the schedule in the deliverable table in Paragraph 1.4.
Following the IPR, and in accordance with the schedule in the deliverable table in Paragraph 1.4, the contractor shall submit minutes of the IPR to include date, IPR location, a list of attendees, a record of activity; decisions made during the IPR; and an action items list that includes a description of the action item (AI), the primary person or organization responsible for accomplishing the AI, and an estimated completion date.
Deliverables: Agenda, Presentation Materials, IPR Meeting Minutes
1.3.1.5 Task Area 1 Subtask 5 - Integrated Master Schedule (IMS). The contractor shall deliver to the PM an
IMS in either MS Project or Excel preferred format that provides a schedule for all major milestones as currently tasked to the contractor. The IMS shall include a Master Schedule that lists the major milestones with start and completion dates associated with each. The IMS also shall include sub-tasks necessary to achieve the milestone and scheduled and actual start and completion dates for each sub-task. The IMS delivered to the government shall address development, test, and deployment for software releases containing approved new capability, enhancements, or problem reports, and shall show the critical path. The contractor shall keep this schedule current, and provide an updated schedule weekly as necessary after coordinating these changes with the PM. Percent complete on tasks within the schedule shall be updated on a weekly basis. The IMS also shall be delivered with the MSR.
Deliverable: IMS
1.3.1.6 Task Area 1 Subtask 6 - Demonstration Support. The contractor shall conduct up to five demonstrations of software releases of any type at Scott AFB IL during AMP IPRs or AMP user group meetings, or at the developer or subcontractor locations. The contractor shall conduct technical presentations or demonstrations to USTRANSCOM, other DOD commands, or other AMP users. The contractor shall support presentations or demonstrations at other venues when required by the PM.
1.3.1.7 Task Area 1 Subtask 7 – Teleconferences. The contractor shall participate in weekly telephone conferences lasting 30 to 60 minutes to provide current status of all tasks.
1.3.1.8 Task Area 1 Subtask 8 – Data Protection.
The contractor shall indemnify the Government from any liability to data owners or licensors resulting from, or as a consequence of, a release or disclosure of technical data and computer software made by this contractor or its officers, employees, agents, or representatives.
1.3.2 Task Area 2 - Technical Support for Studies and Analyses.
The contractor shall support planning and execution of one major analytical study such as the Defense Program
Guidance’s Mobility Capabilities and Requirements Studies and Quadrennial Defense Review, and up to four smaller studies that may spin off from the major study. This may require software modifications, analysis of study requirements and products, and on-site support. As appropriate to the specific study, the contractor shall work with other model development contractors to define upgrades and enhancements to AMP software and other models, and to coordinate release and testing schedules. In support of studies and analyses, the contractor shall modify AMP software and shall enhance the graphical user interfaces (GUI) and/or charts as directed by the Configuration
Control Board (CCB). The contractor shall conduct integration and testing, and perform trouble-shooting to repair or modify software problems identified during model execution.
1.3.3 Task Area 3 - Requirements Management.
The contractor shall support the administration of the AMP requirements management process. The contractor shall manage the activities necessary to receive, verify, analyze, refine, and confirm requirements provided by the
AMP PM or Functional Manager (FM).
1.3.3.1. Requirements Management Plan (RPM). The contractor shall document its internal requirements management process in a Requirements Management Plan (RMP). The content of the RMP shall be delivered in adobe pdf format.
Deliverable: RMP
1.3.3.2. Requirements Traceability. Using an automated requirements tracking tool, the contractor shall maintain the traceability of all requirements from capability needs through design and test; document all changes to those requirements and record the rationale for those changes throughout the system lifecycle. The contractor shall provide the Government Program Management Office (PMO) and FM personnel remote access to this tool.
The contractor shall employ this tool as a repository and to input, track, trace, and manage requirements, including software problem reports. Requirements traceability shall be confirmed at each technical review (e.g., IPRs, test readiness reviews (TRR), operational readiness reviews (ORR), production readiness reviews (PRR), Requirements Definition Document (RDD) reviews).
As requirements are entered into the automated tracking tool, the contractor shall assess each requirement and provide the level of effort and impacts to program costs and program schedule. The contractor shall record these assessments in its requirements management tool.
1.3.3.2.1 Software Requirements Specification (SRS). The contractor shall provide an SRS that describes the user’s functional requirements in detail and in a form that will support design and development of software to satisfy the PM-approved functional and technical requirements of each software release. The SRS shall conform to the requirements of Contract Data Requirements List (CDRL) A001 (Data Item (DI)-IPSC-81433A, Software
Requirements Specification). The USTRANSCOM Program Executive Office – USTRANSCOM (PEO-T) will review and approve the SRS prior to contractor implementation.
Deliverables: Software Requirements Specification
1.3.4 Task Area 4 – Support for Design and Development. (T-CAP)
The contractor shall design and develop software as designated in the subtasks below. Design and development of new capability within AMP also encompasses software integration and at least three tests considered a part of the development process: unit, regression, and integration testing.
The contractor shall define a software development approach appropriate for the computer software effort to be performed under this PWS. This approach shall be documented in a Software Development Plan (SDP) and followed for all computer software to be developed and/or maintained under this effort. The SDP shall define the contractor's proposed life cycle model and the processes used as a part of that model. In this context, the term “life cycle model” is as defined in ISO/IEC/IEEE Std. 15289-2015. The SDP shall describe the overall life cycle and shall include primary supporting, and organizational processes based on the work content of this PWS.
The SDP shall contain the information defined by ISO/IEC/IEEE Std. 15289-2015 and the Plans or Procedures in the Table of ISO/IEEE Std. 15289-2015. In all cases, the level of detail shall be sufficient to define all software development processes, activities, and tasks to be conducted. At a minimum, information provided must include specific standards, methods, tools, actions, strategies, and responsibilities associated with development and qualification.
The contractor shall deliver an updated program-level SDD annually which conforms to the requirements of CDRL
A003 (DI-IPSC-81435A, Software Design Description).
The contractor shall consider use of third-party products that may be innovative or new to AMP and could improve system performance. The contractor shall provide its recommendations concerning use of third-party products to the Government. In particular, the Government’s goal is to encourage reuse of software and components, especially in cases where the Government has unlimited data rights.
Deliverable: Software Development Plan, Software Design Description
1.3.4.1 Task Area 4 Subtask 1 – General Development Support. The contractor shall:
(a) Propose release content and schedules based upon Government requirements and priorities
(b) Provide necessary models and simulations to support the verification, validation, and authentication
(VV&A) process
(c) Provide software size (executable lines of code and function points), cost, and schedule estimates, and include justification and methodology used to derive the estimates
The contractor shall ensure that the AMP software is developed to be compatible with the current and any projected USTRANSCOM software configuration standards (e.g., United States Air Force (USAF) Standard
Desktop Configuration (SDC), network, security, Internet browser). The contractor can download the USAF SDCs from https://ceds.gunter.af.mil/Default.aspx for use within its development environment.
1.3.4.2 Task Area 4 Subtask 2 – Software Testing.
To ensure all Government specifications for each requirement at each release are met, the contractor shall employ a contractor submitted and Government approved testing program to verify Government-approved requirements, software patches, fixes or maintenance releases, replacement of commercial off- the-shelf (COTS) software, and replacement of hardware.
https://ceds.gunter.af.mil/Default.aspx
1.3.4.2.1 The contractor’s test and evaluation (T&E) processes shall conform to the Government T&E processes to include the Government T&E Master Plan (TEMP). Activities shall include developing a master T&E strategy as a part of the SDP; determining testability of change requests; producing test plans; tracing requirements through multiple documents to test procedures; supporting application certification efforts; performing test and operational readiness reviews and supporting production readiness reviews; supporting Government T&E observation of the contractor’s T&E (e.g., Government Witness Testing (GWT)); documenting test results;
objectively analyzing data; conducting risk analyses; capturing T&E metrics; testing performance; supporting operational test events; and recommending T&E process improvements.
1.3.4.2.2 The contractor shall support Government participation in test events. These events include GWT and
User Acceptance Testing (UAT) of the software to ensure it is validated and verified against the provided requirements or problem reports. The purpose of GWT is to observe contractor system integration testing (SIT) of the software planned for use during UAT. The functional user will record and track deficiencies discovered during UAT. The contractor shall not issue a new version of software for continuation of UAT without PM approval. In accordance with PM and FM prioritization and PM direction, the contractor shall resolve these deficiencies and present another software version for UAT. The contractor shall conduct a TRR before contractor software integration testing commences and an ORR before UAT commences. The goals of these reviews are to confirm the readiness of the application and test infrastructure (e.g., test environment and documentation) to start each test event, to identify the proper exit criteria necessary to complete each test event, and obtain Government approval to proceed toward the next milestone leading ultimately to software fielding.
1.3.4.2.3 The contractor shall prepare briefing slides for each TRR and ORR and provide them for Government review before either TRR or ORR occurs. Timing of delivery of the TRR and ORR slides for Government review is as noted in the Deliverable Table in Paragraph 1.4. For each release, the contractor shall prepare a Software Test
Description (STD) that describes the developer’s test methodology and traces requirements from contractual and/or requirements documentation through to test cases. This requirements trace shall be documented as a Requirements
Traceability Matrix (RTM) and included in the STD. The STD shall conform to the requirements of CDRL A002
(DI-IPSC-81439A/T (tailored), Software Test Description.) The contractor shall create test cases for each requirement that shall provide detailed test instructions, any pre-conditions or inputs, and expected results for each required functional capability or defect. Test cases also shall include expected results for comparison with the actual test results. These test cases shall be included in the STD. The STD also shall describe the contractor’s approach to conduct regression testing on changes made to commercial off-the-shelf components and application software components. In addition, the contractor shall provide documentation that records the status and results of the contractor’s test efforts. The STD and test reports shall be delivered in accordance with the deliverable table in
Paragraph 1.4. The contractor shall deliver a Software Test Report (STR) that details test results following completion of SIT. This report shall conform to the requirements of CDRL A003 (DI-IPSC-81440A/T STR, Software Test Report).
1.3.4.2.4 The TRR shall at a minimum, address the following topics, issues, and events:
(a) Test methodology to verify contents of the release
(b) Software Problem Reports (SPR) and Change Requests (CR) contained in the release
(c) Review of all formal test documentation (Software Version Description (SVD), STD, test plans)
(d) Verification of the availability of all necessary personnel, forms, equipment, software, and support material, and/or data for the test to be performed
(e) Review that all new requirements are mapped to test cases
(f) Confirm that each SPR and CR has a test case developed against it, or provision of reason why one has not been developed
(g) Verification that test procedures have been reviewed and recommendations incorporated into the appropriate documentation
(h) Results of regression testing
(i) Description of security concerns
1.3.4.2.5 To support the ORR, the developer shall produce the test artifacts along with a description of any open
SPRs for review by the PMO and functional representatives. During ORR, the contractor shall brief the results of
SIT and GWT. The developer shall deliver all artifacts, including a draft SVD, to the PMO and place them under Configuration Management (CM) control. The successful outcome of this review will result in
Government PM approval to proceed to UAT.
1.3.4.2.6 Once the software is delivered to the Government for UAT, the contractor shall not change the software baseline under test until the Government has completed testing, prioritized software or test problem reports, and has accepted the change(s) proposed to resolve the problem(s). In accordance with PM and FM prioritization and PM direction, the contractor shall resolve these deficiencies and present another software version for UAT. After completion of UAT, the Government will conduct a PRR, with developer participation, that demonstrates readiness of the application and infrastructure to support fielding to the production environment, and to issue a fielding decision.
1.3.4.2.7 If the contractor has used automated test scripts to verify software problem fixes for a software version entering a scheduled test event involving Government participation, the contractor shall provide a user-readable version of the automated test script(s) and expected test result(s) for each test case; these shall be included in the
STD. The contractor shall provide the results of automated testing of the software build to be used at the start of scheduled test events, and any builds occurring during scheduled test events. The contractor shall include these automated test result(s) as an addendum to the STR.
1.3.4.2.8 Deficiencies will be documented, prioritized, tracked, and may result in non-acceptance of the software release by the Government. The software shall be resubmitted for testing and only accepted by the Government once it passes Government testing. The PM will make the final decision concerning software acceptance. In this contract, deficiencies are defined as the difference between the functional specifications stated by the Government and the capability provided in the software being delivered to the Government. This definition includes capability previously delivered to the Government that was not a part of the new functional specifications or code changed due to fixing problems with the software that the Government CCB authorized.
1.3.4.3 Task Area 4 Subtask 3 –Software Releases. The contractor shall provide up to two (2) minor releases, up to six (6) scheduled maintenance releases, and up to six (6) emergency releases annually; emergency releases will occur between regularly scheduled releases. Software releases are categorized into major, minor, maintenance, or emergency releases. Releases are classified as “minor” if they include new functionality, but no changes to the system architecture or security posture. Minor releases also may contain fixes to software problem reports. Releases are classified as “major” if they include change(s) in the system architecture (e.g., introduction or elimination of a database, transition from client-based application to web-based access) or security posture.
Major releases also include new functionality, and also may contain fixes to software problem reports.
Maintenance releases may contain fixes to software problem reports and needed enhancements. For maintenance releases, the contractor shall conduct a regression test of the revised software to ensure the software changes do not degrade system operation. The contractor shall brief results of the regression test during TRR. Emergency releases normally contain only fixes to software problem reports, but may include new capability rushed to the field to support a high-priority requirement. The following pertains:
Each release must undergo cyber security review to determine the degree to which the changes incorporated into the software impact the security or hardware architectures of the system, or include the implementation of a new operating system, database, or interface. This review is accomplished once the contractor submits software security scans (current scan tool is Fortify) for analysis. The frequency of contractor delivery of Fortify scans for analysis will be as described in the Paragraph 1.4 Deliverables Table. Once all Category 1 faults are corrected and the USTRANSCOM Cyber-Security Branch (TCJ6-OI) accepts risks identified as Category 2 and / or 3 faults, the
AMP Government engineer, supported by Program Executive Office-USTRANSCOM (PEO-T) security engineer, will submit the necessary documentation (normally a minor modification checklist) for Government approval.
Other forms of review include requests for interim authority to test or completion of the reaccreditation process.
The contractor shall support the Government in achieving software acceptance by accomplishing tasks described in Paragraph 1.3.7. AMP currently is accredited under the DOD Information Assurance Certification and
Accreditation Process (DIACAP), and is scheduled to complete its transition to Risk Management Framework
(RMF) during FY18.
Version numbering shall be consistent with the description contained in the Government Configuration
Management Plan (CMP).
The contractor shall provide the following items:
Code scans
Source code
Executable programs
Source code shall be delivered in conformance with the requirements of CDRL A004 (DI-IPSC-81488/T, Computer Software Product (CSP)).
The contractor shall update the Software User Manual (SUM) to provide USTRANSCOM functional personnel appropriate guidance for system operation. The SUM shall conform to the requirements of CDRL A005 (DI-IPSC-
81443A/T, Software User Manual).
The contractor shall follow the software release process addressed in the Government AMP CMP. The contractor also shall deliver software source code with each release. Using the processes described in the CMP, the Government CCB will determine the contents of each software release after consideration of the developer’s recommended release contents and the functional user’s priorities.
The contractor shall deliver an SVD in accordance with the deliverable table in Paragraph 1.4. The SVD shall conform to the requirements of CDRL A006 (DI-IPSC-81442A, Software Version Description). The contractor shall submit an updated SVD whenever the Government CCB approves changes to the software baseline. The contractor shall not undertake work on requirements (new capability (functionality) or software maintenance) that have not been approved by the Government until the Government CCB has approved the requirements.
Deliverables: STDs, STRs, TRR slides, ORR slides, SVDs, SDD, Software releases, Updates to Software User
Manual, code scans, source code on Blu-ray disc.
1.3.5 Task Area 5– Software Maintenance.
1.3.5.1. AMP Software Maintenance (includes AMP-PAT, Joint Mobility Closure Estimator
(JMCE), Rapid Course of Action Analysis Tool (RCAT), and Distribution Performance Nodal Model
(DPNM)). (T-Ops)
1.3.5.1.1. AMP Software Maintenance. The contractor shall correct problems that AMP users encounter with the software, and shall conduct unit, integration, and regression testing of these fixes. The contractor shall maintain the data objects, run-time infrastructure, and adapt to changes in the AMP component models to ensure federated runs are operational. As software problems are corrected, the contractor shall adhere to the test and release requirements contained in Paragraphs 1.3.4.3 and 1.3.4.4 above. The SPRs and CRs under this task will be allocated to releases by the AMP CCB.
The contractor shall:
(a) Facilitate and support the administration of the AMP problem reports management process
(b) Propose release content and schedules based upon software maintenance priorities directed by the
AMP CCB
(c) Provide software level of effort, cost, and schedule estimates, and include justification and methodology used to derive the estimates
(d) Code, test, document, and support full integration of software and software releases in accordance with
AMP CCB direction and Paragraph 1.3.4
(e) Include a list and brief description of software defects that will be fixed in a given release in the SVD associated with that release
(f) Provide CM, quality assurance (QA), and documentation for all AMP software to include any necessary updates to the SUM
1.3.5.1.2. Data Dictionary. (Optional Task) (T-OPS) The contractor shall update and distribute the AMP data dictionary with each major and minor AMP software release. The contractor shall ensure that the data dictionary provides sufficient detail needed to accurately trace data item changes to every affected AMP data file along with location and format details within each affected file.
Deliverable: Data Dictionary
1.3.5.1.3 EEP Support. (Optional Task) (T-Ops – AT21) The contractor shall provide expertise to the AT-
21 team to support the Enterprise Executable Plan (EEP) and sustain AMP-related optimization capabilities to be leveraged by the EEP solution set. This support shall not exceed 20 hours per week. Duties include support/sustainment of or provision of expertise concerning the following:
(a) Assist the Government in resolving issues during technical integration and functional user testing
(b) Assist the Government in developing help desk procedures to triage EEP problem resolution
(c) Maintain and make minor updates to business rules for filtering requirements from the DEX file to the CSV files
(d) Maintain and make minor modifications to the integration of AMP optimization capability with AT-21 software and processes
1.3.6 Task Area 6 – Application Administration. (T-Ops)
1.3.6.1 Task Area 6, Subtask 1 - Application Administration Support. The contractor shall provide on-site application administration and support to USTRANSCOM system administrators and functional users.
This includes the following activities:
(a) Plan, schedule and support installation of AMP software, to include application patches and updates. Troubleshoot AMP installation problems. Support Functional Area Communications
Computer System Manager installation of AMP application software on Secure Internet Protocol
Router Network (SIPRNET) clients, as necessary
(b) Support optimization, backup, recovery, modification, and upgrade of software. Debug AMP software and support testing of the application (e.g., JDPAC research and development laboratory, support of GWT and UAT)
(c) Provide technical support for hardware refresh efforts
(d) Provide Help Desk support to assist functional users troubleshoot and correct AMP problems
(e) Keep information located on the AMP webshare site current, including keeping the web pages updated with the latest downloadable AMP software releases, sample data, and AMP User
Group materials
(f) Assist Government security and networking personnel to resolve application-related issues
The contractor shall keep the AMP Application Administration Manual updated. The contents of the manual shall include account administration; software installation; obtaining, generating, and updating reference files, shared drives, and web pages; troubleshooting and resolving operating system conflicts; maintaining logs; and creating reports.
Deliverable: Updated Application Administration Manual
1.3.6.2 Task Area 6, Subtask 2 – AMP Model User Training. The contractor shall provide up to ten sessions of AMP training. Training shall be on the use of the AMP modeling tools. USTRANSCOM will coordinate and provide the training classroom (including hardware) if such training is required. Training shall be consistent with industry standards and result in the trainees’ full understanding of the capabilities and the designed use of the associated software applications and GUIs.
1.3.6.3 Task Area 6, Subtask 3 – Update AMP Training Materials. The contractor shall update training materials for classroom, self-paced, or computer-based training. As new AMP capability is delivered to the
Government. The purpose of the training materials is to provide a new analyst an overview of the AMP software with the objective of enabling this analyst to perform the following functions using the software following completion of this training. The training materials shall include, but not be limited to, at least one training scenario and practical exercises.
a. Understand major concepts of airlift, sealift, Continental United States (CONUS), theater, and sustainment and how they work within the model
b. Understand how to open, import, export, and run an AMP scenario
c. Understand basic navigation of the tool; i.e., where editors are located, how the basic GUI functions work (i.e., copy, paste, filter, etc.), and what data is located within each editor
d. Understand what reports are available and where they are located
e. Be able to complete practical exercises provided
Deliverable: Updated training materials
1.3.7 Task 7 – Security Engineering and Cyber Security Requirements. (T-Ops)
1.3.7.1 Task 7 Subtask 1 – Security Engineering Requirements.
Using the Defense Information Systems Agency (DISA) Application Security and Development Checklist and
Security Technical Implementation Guide (STIG), the contractor shall evaluate all AMP releases to ensure security issues are identified and addressed. The contractor shall conduct code reviews and apply the DISA
Application Security and Development Checklist and STIG to all AMP software releases.
1.3.7.1.1. IA Vulnerability Management. (T‐Ops) The contractor shall monitor and analyze IA Vulnerability
Management (IAVM) Notices, USTRANSCOM Security Notifications, United States Cyber Command
(USCYBERCOM) and vendor security advisories and make recommendation to the Government for applicability to AMP.
1.3.7.1.1.1. (T‐Ops) The contractor shall submit an initial analysis and assessment for high impact (risk) advisories (based on the STIG Finding Severity Category listed in the IA Vulnerability Advisories [IAVA], IA Vulnerability Bulletins [IAVB], and Technical Advisories [TA]) to the Government AMP PM, engineer, and security engineer. All STIG Finding Severity Category I and II IAVAs and IAVBs are considered high impact.
Deliverable: High Impact Risk Advisory
1.3.7.1.1.2. (T‐Ops) The contractor shall prepare an analysis for other than high impact advisories and provide it to the USTRANSCOM AMP Engineer.
Deliverable: Other Risk Advisory
1.3.7.1.1.3. (T‐Ops) The contractor shall provide a summary of security analysis and assessment results during weekly teleconferences and in an update in the MSR.
Deliverable: Security Summary
1.3.7.1.2. (T-Ops) IA Security Bulletins. The contractor shall analyze applicable security bulletins to determine impact, identify mitigating factors, and develop recommendations to the Government regarding potential courses of action. Contractor recommendations shall be compliant with AMP, USTRANSCOM, and DoD security requirements and industry best practices. The contractor shall ensure that patch deployments and other significant security activities are documented in the IMS.
The contractor shall develop and update mission criticality analyses, vulnerability assessments, risk assessments, and identification and counter measure implementations for Mission-Critical Functions.
The contractor shall protect unclassified DoD data from unauthorized access or disclosure in accordance with DoDI
8582.01, “Security of Unclassified Information on Non-DoD Information Systems,” DoDM 5200.01, Volume 4, and classified information under DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM), and the program’s Security Classification Guide.
1.3.7.1.3 Security Testing. The contractor shall conduct an automated code scan of the application using an approved code scan tool (currently Fortify) with the current rule packs, signatures, engines, etc. installed. A qualified developer security engineer and programmer shall review the results of the automated code scan, determine and mark false positives, and provide rationale for recommendations. The contractor shall analyze and comment on respective analysis options (Not an Issue, Reliability Issue, Bad Practice, Suspicious, Exploitable, or custom). The contractor shall provide the results and a detailed analysis 15 business days prior to software delivery.
For all software releases, the contractor shall conduct software security testing in accordance with the DISA
Application Security and Development Checklist and STIG, and shall submit the completed checklist to the
Government in accordance with Paragraph 1.4, Deliverables. As validation of continued compliance with the STIG, the developer shall submit application code scan reports for each software release as indicated in the deliverables table. Delivery should coincide with the other programmatic documentation deliveries: 120 business days prior to program need-by date (required accreditation/authorization date) to support the DoD certification and accreditation methodology.
Deliverables:
Pre-Software Delivery Automated Code Scan
DISA Application Security and Development Checklist and STIG
1.3.7.1.4 Use of Automated Code Scanning Tool. The contractor shall use an automated tool, currently Fortify to scan the application source code to identify, document, and remediate vulnerabilities or weaknesses in the application design/coding, such as those described in Common Weakness Enumeration / System Administration, Networking, and Security Institute (CWE/SANS) TOP 25 Most Dangerous Programming Errors
(http://www.sans.org/top25-programming-errors) and Open Web Application Security Project (OWASP) Top Ten
(http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), that could be exploited by unauthorized sources. The contractor shall ensure the operator of this tool is trained in its operation. This training shall be at no cost to the Government. The contractor shall submit the file (*.fpr file) containing the results of the application code scans. This file shall include thorough developer analysis, suppressions, and remediation’s taken. The results file shall be submitted to the USTRANSCOM AMP security engineer. If remediation’s or mitigations are planned for future action, the contractor shall submit this information as milestones in a plan of action and milestones
(POA&M) and within the comments section of the *.fpr file.
Deliverables: Application code scan results file (*.fpr file)
1.3.7.1.5 Source Code Configuration Control (Versioning). The contractor shall use a strict version control process for software development.
1.3.7.2 Task 7, Subtask 2 – AMP Risk Management Framework
The contractor shall support security assessment and authorization activities for the AMP application. The contractor shall develop and / or update existing system security documentation developed to facilitate AMP security authorization IAW RMF procedures. The contractor shall perform Security Control Assessment activities as required to maintain current authorization and support follow-on authorizations. The contractor shall support
USTRANSCOM's use of selected tools, currently eMASS for automated accomplishment of the RMF process. The contractor shall update cyber security documentation a minimum of once per year or as needed when software weaknesses are discovered.
The government will be responsible for providing policy requirements associated with the program, while the developer shall ensure the required artifacts adhere to and incorporate these policy requirements.
http://www.sans.org/top25-programming-errors) http://www.sans.org/top25-programming-errors) http://www.sans.org/top25-programming-errors)
The Contractor shall develop and maintain the following documentation required to support the RMF authorization decisions.
RMF deliverables identified below can be grouped or combined as necessary as long as the resultant document or documents address the RMF requirements and support the implementation and validation of the controls.
Deliverables:
System Security Plan (SSP). The contractor shall develop a SSP IAW DoDI 8510.01, DoDI 8500.01. Ref:
NIST SP 800-18 (Guide for Developing Security Plans for Federal Information Systems).
Incident Response Plan. The contractor will develop a plan that describes the procedures for responding to incidents affecting the system. Ref: NIST SP 800-61 (Computer Security Incident Handling Guide)
Ports, Protocols, and Services (PPS) information. Include ports for internal and external traffic and source and the list of destination Internet Protocol (IP) addresses. DoD approved PPS worksheet will be used;
available on the Ports, Protocols, and Services Management (PPSM) website at https://pnppki.cert.smil.mil.
Security Test Plan. The contractor will develop a security test plan that describes its Software
Development Lifecycle (SDLC) and procedures used by the developer to test the application code for security vulnerabilities prior to delivery to the government.
Risk Analysis and Assessment Report. Relating to the system applicable Information Assurance
Vulnerability Assessments
Static Source Code Scan Report. The contractor shall conduct analysis and provide comments on respective analysis options (Not an Issue, Reliability Issue, Bad Practice, Suspicious, Exploitable, or custom). Results will be provided in accordance with the deliverables table
Completed DISA Application Security and Development Checklist and STIG. Each STIG rule shall include comments supporting respective status for Open/Not a Finding/Not Applicable. Open STIG rules shall include proposed fix actions. The contractor shall submit completed STIG IAW the deliverables table.
AC – Access Control Policy & Procedures
AU 0 Audit and Accountability Policy & Procedures
CM – Configuration Management Policy & Procedures
CP – Contingency Plan and Procedures, IA – Identification and Authentication Policy & Procedures
IR – Incident Response Plan
MA – system Maintenance Policy & Procedures
PE – Physical and Environmental Protection Policy & Procedures
PL – Security Planning Policy (IAW DoDI 8510.01) & Procedures
AT – Security Awareness Training Procedures
MP – Media Protection Procedures
PS – Personnel Security Procedures
PM – Information Security Program Procedures
RA – Risk Assessment Procedures
CA – Security Assessment and Authorization Procedures
SC – System and Communications Protection Procedures
SI – System and Information Integrity Procedures
SA – System and Services Acquisition Procedures
Security Test Plan
1.3.7.3 Task 7 Subtask 3 – Cyber Security Requirements.
1.3.7.3.1 Requirements for Contractor Provision of Security Plan and Cyber Security Controls. The contractor shall establish a cyber security program to implement and sustain appropriate cyber security management, operational, and technical controls and processes required to safeguard DoD non-public information resident on or transiting the contractor's unclassified information systems from unauthorized access and disclosure. Protection https://pnppki.cert.smil.mil/ measures applied must be commensurate with the risks (i.e., consequences and their probability) of loss, misuse, unauthorized access, or modification of information. The contractor shall submit for Government approval an overarching security plan that describes its strategy for implementation of cyber security and Industrial Security requirements throughout the life of the contract. The security plan shall address the security controls described in
National Institute of Standards and Technology (NIST) Special Publication 800-53 (current version), Recommended
Security Controls for Federal Information Systems and Organizations
(http://csrc.nist.gov/publications/PubsSPs.html), and shall be tailored in scope and depth appropriate to the effort, the specific unclassified DoD information.
1.3.7.3.2 Information Assurance Workforce Improvement Program (IAWIP). The contractor shall:
(a) Ensure that personnel accessing information systems and who perform cyber security functions have the proper and current information assurance certification (IAT Level II) and (IAM-Level I) to perform information assurance functions in accordance with DoD 8570.01-M, IAWIP.
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 .