Attachment_2_Performance_Work_Statement.pdf

PERFORMANCE WORK STATEMENT (PWS)

FOR

THE SYNTHETIC THEATER OPERATIONS RESEARCH MODEL (STORM)

Version 1.0

19 June 2018

1.0 BACKGROUND

1.1 MISSION

1.2 STORM (SYNTHETIC THEATER OPERATIONS RESEARCH MODEL (STORM)

1.3 REFERENCES TO STORM

1.4 AF/A9 SUITE OF TOOLS

2.0 DEFINITIONS AND ACROYNYMS

2.1 DEFINITIONS

2.2 ACRONYMS

3.0 DESCRIPTION OF SERVICES

3.1 KEY PERSONNEL

3.2 TECHNICAL REQUIREMENTS FOR STORM

3.3 CAMPAIGN ANALYSIS SUPPORT

3.4 STORM CAMPAIGN ANALYSIS TOOLKIT

3.5 STORM MAINTENANCE AND MODIFICATIONS

3.6 USER COMMUNITY SUPPORT

3.7 HELP DESK REQUIREMENTS & ADMINISTRATION

3.8 USERS GROUP MANAGEMENT AND ADMINISTRATION

3.9 TRAINING DEVELOPMENT AND INSTRUCTION REQUIREMENTS

3.10 GENERAL SUPPORT

3.12 DELIVERABLES

3.13 CRITERIA FOR ACCEPTANCE

4.0 SERVICE DELIVERY SUMMARY

5.0 GOVERNMENT FURNISHED PROPERTY

5.1 GOVERNMENT FURNISHED UTILITIES.

5.2 CONSERVATION OF UTILITIES.

5.3 GOVERNMENT OWNED.

5.4 EQUIPMENT INVENTORY.

5.5 LOSS OR DAMAGE.

6.0 OTHER DIRECT COSTS

6.1 TRAVEL.

6.1.1 CONTINENTAL UNITED STATES (CONUS)

6.1.2 OUTSIDE CONTINENTAL UNITES STATES (OCONUS)

6.2 MEETINGS AND SYMPOSIA

6.3 ANCILLARY MATERIALS.

6.4 DATA RIGHTS.

file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382068 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382069 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382070 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382071 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382072 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382073 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382074 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382075 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382076 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382077 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382078 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382079 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382080 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382081 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382082 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382083 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382084 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382085 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382086 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382087 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382088 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382089 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382090 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382091 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382092 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382093 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382094 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382095 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382096 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382097 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382098 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382099 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382100 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382101 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382102

7.0 NON-PERSONAL SERVICES

8.0 CONTRACTOR IDENTIFICATION

9.0 SECURITY REQUIREMENTS

9.1 OVERVIEW

9.2 DISCLOSURE OF INFORMATION

9.3 PRIVACY ACT

10.0 HOURS OF OPERATION / PLACE OF PERFORMANCE

10.1 OVERVIEW

10.2 SCHEDULED HOLIDAYS

11.0 CONTRACTOR MANPOWER REPORTING APPLICATIONCMRA).

11.1 LABOR HOURS

11.2 REPORTING INPUTS

11.3 REPORTING PERIOD

11.4 USES AND SAFEGUARDING OF INFORMATION

11.5 USER MANUALS

file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382103 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382104 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382105 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382106 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382107 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382108 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382109 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382110 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382111 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382112 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382113 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382114 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382115 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382116 file:///C:/Users/1457524745A/AppData/Local/Temp/pd05162018130156.docx%23_Toc351382117

1.0 Background

1.1 Mission

The mission of Headquarters Air Force Studies, Analyses and Assessments (AF/A9) is to conduct analyses in support of decisions by the Secretary of the Air Force, the Chief of Staff of the Air Force, Under Secretary of the Air Force and Vice Chief of Staff of the Air Force. To carry out its mission AF/A9 uses modeling and simulation to support force structure decisions, analyze potential force employment options and evaluate the contribution of various weapon systems to the outcome of key objectives in theater-level conflicts. For analyses at this level of war, AF/A9 utilizes various tools to assess the air, space and cyberspace campaign’s impact on the overall joint campaign. These analyses demand accurate and timely representation of the many dimensions of air, space and cyberspace warfare and their relationship to actions by other services or coalition forces. To examine the military potential of proposed doctrinal changes or evolving weapon systems, AF/A9 uses flexible, state-of-the-art theater-level models.

1.2 STORM (Synthetic Theater Operations Research Model (STORM)

The Synthetic Theater Operations Research Model (STORM) is the Air Force’s campaign model solution, integrating air, space, sea, land and cyberspace domains. STORM is a dynamic, complex analytic simulation representing theater-scale military operations in a joint war fighting context. It includes the following components:

A graphical front end for model execution, control and reporting (Study tool)

A graphical front end for management and support of data input and analysis (STORM

Front)

Input tools (Orbit Tool, TBMTool, ATCALPhaseITool, A2SPKTool)

Execution tools (multirun scripts, STORM code and algorithms)

Output tools (MapTool, GraphTool, ReportTool)

Relational database for input, execution and output

Distribution package of select open source software application and tools

Documentation (Analysts, Programmers, Users manuals, Appendices, change notices and training course materials)

1.3 References to STORM

All references to STORM apply to the STORM analytic simulation and components described above. AF/A9 developed, owns and controls access to and licensing of STORM and is responsible for its configuration management. AF/A9 intends to manage and maintain STORM under this Performance Work Statement (PWS). In addition, AF/A9 must maintain and sustain the core capability to run, calibrate, modify, update and integrate data and results amongst the entirety of its modeling and simulation toolkit in order to effectively perform studies and analyses of Air Force capabilities. As a result, maintenance and development of tools or user interfaces to support these models are also supported under this PWS.

1.4 AF/A9 Suite of Tools

AF/A9 also maintains a suite of modeling tools, which are provided by other DoD agencies or other AF/A9 contract vehicles, to support ongoing analysis. The AF/A9 modeling suite includes but is not limited to such models as Brawler, Combat Forces Assessment Model (CFAM), Sensor

Platform Allocation Analysis Tool (SPAAT), Capability Based Logistics Planner (CBLP), Sortie

Generation Rate Model (SGRM), SUPPRESSOR, Extended Air Defense Simulation (EADSIM), Enhanced Surface-to-Air Simulation (ESAMS), Weapons Effects Analysis & Probability

Software (WEAPS), Advanced Framework for Simulation, Intergration and Modeling (AFSIM) and Air Mobility Operations Simulation (AMOS). AF/A9 reserves the right to add or retire models as dictated by the requirements. Tools and/or user interfaces to support these models may be created and/or maintained under this PWS, depending on the Governments needs and the analytical community.

2.0 DEFINITIONS AND ACROYNYMS

2.1 Definitions

“Accreditation” means the model has been authorized for a specific use by the appropriate certifying official.

“Configuration Control Board” means the governing body that is directed to control the model’s code and documentation in such a way as to guarantee the model’s lineage and integrity, allowing the configuration control authority to maintain a database of version release code and documentation.

“Contracting Officer Technical Representative” (COR) means the AF/A9 oversight represenative responsible for this contract.

“Government” means AF/A9 unless otherwise stated.

“Model” means a simplified version of something complex used in analyzing and solving problems or making predictions.

“Model Manager” is the Government individual designated in writing by AF/A9 to act as the program manager for a model. The Model Manager is responsible for all technical aspects of the model and ensuring the PWS encompasses the requirements of AF/A9 and the User community.

“Memorandum of Agreement (MOA)” means the agreement between AF/A9 and the model user on the objectives, rules, and guidelines of the model’s user group.

“Performance Work Statement (PWS)” means a statement of work for performance-based acquisitions that describes the required results in clear, specific, and objective terms with measurable outcomes.

“Performance Plan” aka (Quality Assurance Surveillance Plan) establishes the plan by the

Contractor and the government on acceptable performance that the Contractor must meet and still be considered a satisfactory performer.

“Release Code” means interim STORM releases design to address bug fixes. These releases sometimes include responsive model modifications that do not interfere with basic model functional unless used.

“STORM” means the Synthetic Theater Operations Research Model (STORM). It includes the components listed in paragraph 1.2 above.

“Task Order” A specific requirement for services issued against an existing contract.

“User” means any organization which uses an AF/A9 managed model and is a member of the model’s user group

“Validation” means the model modification provides a valid representation of the real world phenomenon it is attempting to replicate

“Verification” means the model modification has been reviewed to prove that the model executes as designed

“White Paper” means a software design document that includes a rough order of magnitude

(ROM) of the cost to the government. This document is intended to make certain that the government model enhancement requirements fit properly within STORM.

2.2 Acronyms

AF/A9 - Headquarters Air Force Studies, Analyses and Assessments

AMOS – Air Mobility Operations Simulation

CAD – Contract Award Date CASA – Common Analytic Simulation

Architecture

CBLP – Capabilities Based Logistics Planner CCB – Configuration Control Board

CD – Compact Disk CFAM – Combat Forces Assessment Model

CLIN – Contract Line Item Number CMI – Classified Message Incident

CO – Contracting Officer COR – Contracting Officer’s Representative

CONUS – Continental United States DAA – Designated Approval Authority

DFAR – Defense Federal Acquisition

Regulation

DoD – Department of Defense

DRD – Data Release Date DVD – Digital Video Disk

EADSIM - Extended Air Defense Simulation ESAMS - Enhanced Surface-to-Air Simulation

EST – Eastern Standard Time F&FP – Force and Financial Plan

FAQ – Frequently Asked Questions FAR – Federal Acquisition Regulation

G&A – General and Accounting GFE – Government Furnished Equipment

IAW – In Accordance With ISR - Intelligence, Surveillance, and

Reconnaissance

IT – Information Technology ITEM – Integrate Theater Engagement Model

JAFAN – Joint Air Force-Army-Navy MAJCOM – Major Command

NATO – North Atlantic Treaty Organization NCR – National Capital Region

NET – No Earlier Than NISPOM - National Industrial Security

Program Operating Manual

NLT – No Later Than ODC – Other Direct Costs

PWS – Performance Work Statement QCP – Quality Control Plan (Performance

Plan)

SAR – Special Access Required SABSEL – Saber Selector

SCD – Study Completion Date SCI – Special Compartmented Information

SGRM – Sortie Generation Rate Model SPAAT - Sensor Platform Allocation Analysis

Tool

STORM - Synthetic Theater Operations

Research Model

SSD – Study Start Date

TCD – Training Course Date TAD – Task Award Date

VRD – Version Release Date UMD – User Group Meeting Date

WEAPS - Weapons Effects Analysis &

Probability Software

VV&A – Verification, Validation and

Accreditation

3.0 Description of Services

STORM is designed to support in-depth analysis of the campaign-level contributions of air, space, sea, land and cyberspace forces. As a result, STORM is also dependent upon an extensive collection of databases tailored for a combatant’s combat capability as well as force deployment, employment and geographic region characteristics. As STORM undergoes continuous updates in support of analytic studies, all components of STORM (STORM Front, databases, input, output and reporting tools, etc.) require review, modification and updating to ensure its viability as an analysis tool.

3.1 Key Personnel

3.1.1 The key personnel for the Contractor shall be located in the National Capital Region

(NCR). The NCR includes the following areas in the Washington, D.C. metropolitan area: Washington DC, Virginia (Arlington County, Alexandria, Fairfax County, City of

Fairfax, Falls Church, Prince William County, Loudoun County and Stafford County) and Maryland (Montgomery County, and Prince George’s County). The key personnel are required to maintain an off-site facility within approximately an hour response time to the Pentagon, Washington DC to facilitate visits by the COR/Model Manager and AF

Senior Leaders located in the Pentagon.

3.1.2 The Contractor shall develop, integrate, test, document, deliver and support all deliverables to meet the requirements as described in subsections: 3.3, 3.5 and 3.12.

3.1.3 The Government requires that the Contractor commits personnel that will meet the requirements of this contract for a minimum of the base year. The Contractor may prefer personnel that have other campaign model expertise (analytic and/or development) with an explanation of why this campaign modeling experience should be accepted as equivalent experience. Any deviation from the criteria listed below shall solely be determined by the Government.

3.1.3.1 Principle Analyst (paragraph 3.3 and 3.5)

Lead joint campaign analysis with an emphasis on AF operations

Lead developer of STORM data from lower level models such has Brawler, ESAMS, Suppressor and EADSIM

Lead maintainer of the STORM Unified database structure at multiple classification levels

Lead forensic analyst of STORM data and code.

3.1.3.2 Program Manager (paragraph 3.3, 3.4, and 3.5) (Not to exceed 376 hours annually)

Responsible for contractual oversight of STORM development/maintenance, Common Analytic Simulation Architecture (CASA) development/maintenance and oversight of the analytic team

Responsible for coordinating model development and analytic execution

3.1.3.3 Principle Configuration Architect (paragraph 3.4, and 3.5)

Responsible for joint campaign model development and maintenance

Responsible for overseeing the Developmental Test and Evaluation (DT&E) of the

STORM code for each interim/version release

3.1.3.4 Help Desk (Junior Analyst/Developer/Software Engineer (paragraph 3.6, 3.7 and 3.8)

Responsible for assisting the STORM user community debugging STORM code and database errors

3.2 Technical Requirements for STORM

3.2.1 The contractor shall provide all remaining tools, equipment, personnel, and supervision necessary to support the AF/A9 Campaign Analysis Support and Sustainment effort in providing campaign level analysis, software maintenance, software development, configuration management, and user community support to Headquarters Air Force.

3.2.2 The contractor shall receive Government Furnished Equipment GFE to support this contract, as well as funding for Other Direct Costs (ODC) like licenses fees, Maintenance and Warranties for both hardware and software, etc., that are required to support this contract effort. The contractor shall support this effort as a study team’s member, as required, under the study lead’s leadership or as members of software development/enhancement teams under the AF/A9 model manager. The contractor must be capable of providing all of the services specified in the task described below.

3.2.3 The Contractor shall provide internal program management, at an off-site location, to ensure all requirements under this contract are accomplished to the Government’s satisfaction. The Contractor’s program manager shall interface with both the Model

Manager (MM) and the Contracting Officer Representative (COR) regularly, at a frequency determined by the MM and COR, to ensure understanding, and compliance with government’s intent of the active requirements and/or to establish future requirements under this contract. AF/A9 supports a wide range of mission areas-from developing large mathematical models and methodologies to determining aircraft attrition-during a campaign-level effort. These requirements range in scope from short suspense tasking (24 hours – 1 week) to studies dealing with critical force management issues lasting 6-12 months or longer. These tasks require an extensive knowledge of the

Air Force organizational structure, functional responsibilities, mission areas, and joint campaign analysis and data sources and will fall into the task descriptions that follow.

Analysis support may be requested, on an as needed basis, to assist in the conduct of studies. AF/A9 may provide support under this PWS to all users of STORM products.

Contractors who provide analysis support will be required to be proficient in one or more of the AF/A9 modeling tools and its associated application to the analysis task at hand. The contractor shall perform all analysis support and general support tasks at the

Government’s facility, unless otherwise informed by the COR that work shall be conducted at the contractor’s facility.

3.2.4 The Contractor shall enhance and maintain STORM and support the community of

STORM users, based upon the guidance of the AF/A9 Model Manager. This will require a steady-state ongoing effort throughout the period of performance. The level of effort may be increased as unscheduled improvements to STORM are required and funded.

The Contractor personnel who support the model maintenance and user community support tasks shall be experts in the use and algorithms of STORM. Both the model maintenance and user community support tasks shall be accomplished off-site at the

Contractor’s facility.

3.3 Campaign Analysis Support

The Contractor shall provide technical, analytical and subject matter expertise to support A9 study efforts. This expertise may include, but is not limited to, such tasks as applying subject matter expertise and operational experience to concept of operations and mission scenario development in order to add credibility to USAF analyses; assist in developing integrated warfare and air campaign scenarios; assist with functional capability analyses.

3.3.1 Core Campaign Analysis Support

The Contractor will act in concert with A9 study teams to accomplish the tasks outlined in the following subsections. They represent the core tasks required in order to successfully deliver

Campaign Analysis Support. The Model Manager will maintain correspondence with relevant study leads to manage allocation of work and ensure daily task requirements are being met. The

Model Manager will relate any issues to the COR. The Contractor will document activities performed under 3.3.1.1, 3.3.1.2, 3.3.1.3 and 3.3.1.4 in support of AF/A9 analysis in the Monthly

Progress Report.

3.3.1.1 Onsite Study/Analysis Planning

The Contractor, in conjunction with the Model Manager, will investigate and agree to implement appropriate methodologies to support studies and analyses. The Contractor will provide assistance for such tasks as study plan development, methodology and model enhancement and/or development, data configuration control, research and data gathering, as required, to support studies. The Model Manager will maintain correspondence with relevant study leads to manage allocation of work and ensure task requirements are being met.

3.3.1.2 Scenario Database Development Support

The Contractor shall develop, modify, update, debug, and maintain model databases. This database support includes data transfer and calibration of data to/from the AF/A9 suite of models, including but not limited to Brawler, the Weapons Effects Analysis and Probability

Software (WEAPS) and the Enhanced Surface to Air Missile Simulation (ESAMS), and other modeling tools, as required. The Contractor shall provide support to develop and administer the repository of supporting model databases as required by the Government. Additionally, the

Contractor shall work with managers of external models to insure that relevant data from those models are in a format compatible with STORM. When native compatibility from external models is not possible, the Contractor shall adapt the format of the data to insure its usability in

STORM.

3.3.1.3 STORM Support of Analysis

The Contractor shall provide operations systems support to studies by using STORM to produce model runs accurately portraying the given scenario(s) -- provide pre-production, production, post-production model runs and analytic post processing; i.e., run models as required to support studies as required by the Government. The Contractor shall make software modifications to source code, scripts and databases as required to complete studies. This task differs from task

3.3.1.4 in that the scope of these changes shall be limited to elimination of bugs and errors or modifications to existing functionality, required to support on-going studies and analyses. These maintenance and modification actions shall be documented in a format agreed to by the

Government, and shall be placed under configuration control as candidates for inclusion into the baseline.

3.3.1.4 Study and Analysis Reporting Support

The Contractor shall post process model output data utilizing existing model functionality, data reduction programs, scripts, database queries, and analyses tools either developed by the

Contractor or provided by the Government. The Contractor shall support the production of output reports and/or briefings to address study/analyses findings in a format agreed to by the

Government.

3.3.1.5 On-Site Campaign Analysis Support

At the request of the Government, the Contractor shall be prepared to provide additional on-site analytic support similar in scope to the requirements in Sections 3.3.1.1, 3.3.1.2, 3.3.1.3, and

3.3.1.4 above. If executed, the Contractor will document activities performed in support of

3.3.1.5 in the Monthly Progress Report.

3.3.1.6 Off-Site Campaign Analysis Support

At the request and guidance of the COR, the Contractor shall be prepared to provide additional off-site analysis and support. Whereas the STORM support of analysis under requirement and

3.3.1 entails the contribution to Government-led efforts, the analysis under this requirement shall be conducted under Government supervision off-site and reported to the Government in a format and at a periodicity agreed to by the COR. The Contractor shall provide to the Government all databases developed in the course of the analysis. The Contractor shall produce output reports and/or briefings in a format agreed to by the COR to address study/analyses findings. If executed, the Contractor will document activities performed in support of 3.3.1.6 in the Monthly

3.3.1.7 Software and Database Installation Support

As necessary, the Contractor shall support the installation of individualized STORM code updates and databases when they become available to ensure the modeling environment at

AF/A9 is configured with the most relevant model source code and databases. At the request of

AF/A9, the Contractor will provide similar installation support to additional organizations within the NCR. If executed, the Contractor will document activities performed in support of 3.3.1.7 in the Monthly Progress Report.

3.3.1.8 Conflict Simulation Support

At the request of the Government, the Contractor shall support the conflict simulation community through scenario and database development, analytic results briefing, and definition and improvement of processes involved in executing conflict simulation. The Contractor shall perform model setup and operation during rehearsal and actual war games supported by AF/A9.

The Contractor may be required to travel in support of war games. Travel shall include conflict simulation planning meetings, rehearsals, conflict simulation activities, and post-simulation analysis briefings. All travel will be done in accordance with Section 6.1 of the PWS. If executed, the Contractor will document activities performed in support of 3.3.1.8 in the Monthly

3.3.1.9 On-Site STORM Campaign Analysis Toolkit Development Support

At the request of the Government, the Contractor shall be prepared to provide additional on-site analytic support to develop tools to improve data inputs to STORM and utilize and evaluate outputs of STORM in support of AF/A9 Studies and Analysis to include Force Structure. If executed, the Contractor will document activities performed in support of 3.3.1.9 in the Monthly

3.3.1.10 Off-Site STORM Campaign Analysis Toolkit Development Support

At the request and guidance of the Government, the Contractor shall be prepared to provide additional off-site analyses and support. Whereas the STORM support of analysis under requirement 3.3.1.9 entails the contribution to Government-led efforts, the analysis under this requirement shall be conducted under Government supervision off-site and reported to the

Government in a format and at a periodicity agreed to by the Government. The Contractor shall provide to the Government all tools and utilities developed in the course of the development effort. If executed, the Contractor will document activities performed in support of 3.3.1.10 in the Monthly Progress Report.

3.4 STORM Campaign Analysis Toolkit

The contractor will support in accordance with Section 3.0, tools and user interfaces to support the Government use of STORM which may be created and maintained under this PWS. STORM

Campaign Analysis Toolkit development will help members of the STORM analytic community refine and improve inputs to STORM and evaluate outputs from STORM through a suite of tools.

3.5 STORM Maintenance and Modifications

3.5.1 The Government is responsible for the configuration of its models and will chair the model’s Configuration Control Board (CCB). The CCB works directly with users proposing model enhancements to develop design documents that meet requirements while ensuring model integrity. The Contractor shall support the Government’s configuration control and verification and validation processes. The Contractor shall provide a Help Desk representative, Chief Model Architect and Chief Software Engineer as supporting members of the CCB and support the Model Manager in maintaining a registry of all code/software changes (both approved and disapproved) as part of the

CCB.

3.5.2 The Contractor shall accomplish necessary model code/software modifications required to support AF/A9 required analysis or integration with other Agency models. The

Contractor shall be required to coordinate all code/software changes with the appropriate

AF/A9 Model Manager and CCB before any changes are made. Once the CCB approves a concept, the Government will award design and implementation to the Contractor under this task. The Contractor shall provide support to accomplish necessary code/software modification for other Agency models federated or associated with assigned models, including possible integration with other CASA-based models. The

Contractor shall provide software engineering for the development and maintenance of computer applications to support analysis using these models. The Contractor will document code modifications, technical analysis, database development, and administrative activities in support of AF/A9 required analysis, in the Monthly Progress

Report. The Contractor shall turn all code changes over to the configuration management process for incorporation into the next baseline version.

3.5.3 Modification Proposal Development

The Government will continually seek to enhance STORM capabilities by identifying, proposing and evaluating improvements to the methodologies, model algorithms and code, databases and graphical user interfaces. The Contractor and Government shall work in concert to thoroughly define enhancement requirements. The Contractor will provide to the Government recommended courses of action to include draft designs and an estimate of the level of required effort entailed, aka “White Papers”. If the decision is made by the Government to proceed with the suggested course of action, the Contractor will work with the Government to create a modification proposal for submission to the CCB. The Contractor is not required to develop modification proposals for efforts initiated outside of AF/A9 or outside the scope of this PWS as determined by the

Government. However, the Contractor may be asked to review outside agency STORM proposals for viability and feasibility, prior to it being accepted as a required task under the configuration control board.

3.5.4 Software Model Modification Reviews

The Contractor shall support Government reviews of all proposed model modifications to include an assessment of the impact these changes will have on the underlying assumptions, operations, database requirements, source code, and run-time environments of the model. The

Contractor shall recommend approval to implement the proposed design or propose design changes back to the Government. Modification proposals may evolve through the requirements definition and design processes, and thus may be submitted to the CCB multiple times for approval.

3.5.5 Document Requests for Software Modifications

The Contractor shall maintain a software change request database that provides, at a minimum, who required the change, background information on the change and the status of any action taken to implement or discard the change, and provide the database to the Model Manager.

3.5.6 Design Development

It is at the discretion of the Government to endorse and fund under these contract modifications approved by the CCB, however there is no requirement that a resulting design document will be funded upon receipt. Upon authorization from AF/A9, the Contractor shall research such modifications and provide a software specification document to the Government. This document shall contain: a) a detailed design of the methodology, data structures, and algorithms to be implemented; b) a test plan outlining proposed implementation approach, test cases, and test plan; c) an assessment of the impact the software changes will have on the underlying assumptions, operations, database requirements and sources, and run-time environment of

STORM. The Contractor shall submit the completed software specification document to the

Government for approval before Contractor hours are expended on the modification. Subsequent to design review, the Contractor shall modify the design and the software specification document to incorporate recommendations made by the Government. The revised design shall be re-submitted for review and the iterative review process will continue until the design and software specification document are approved for implementation by the Government. Software

Specification Documents containing requirements or design methods diverging from the CCB approved modification proposal shall be submitted to the CCB as an addendum to the original proposal, at no additional costs to the government.

3.5.7 Software Modification Implementation

The Contractor shall, upon approval of the software specification document, code the software, integrate it into the baseline and test the implementation. The Contractor shall incorporate all approved software and data changes, including those developed outside of this contract, into a baseline configuration controlled version of STORM. Responsive bug fixes (described in Section

3.7.3) are not required to undergo the CCB approval process. All other modifications must have been previously approved by the CCB before being incorporated into baseline STORM. STORM updates will be released either as interim updates or as version releases. Interim updates and version releases must follow a versioning schema agreed upon by the Government.

3.5.8 Interim Release Code

Interim updates, previously known as “Release Candidates”, shall be released by the Contractor as necessary to support current analytic efforts of the STORM community. These updates will include code changes that add immediate functionality to the model or resolve bugs found in the current supported baseline versions. Changes may be required directly from the Government or be required to resolve issues identified by the Help Desk (Section 3.7). Responsive fixes are geared toward resolving immediate problems in an expedient manner. As a result, less stringent model documentation and design specifications are acceptable for this type of modification. All documentation shall be provided to the Model Manager upon release of the interim update. In order to minimize disruption to the efforts of the overall community, the Contractor shall ensure all modifications effect STORM functionality only if explicitly employed by the user. Cases where immediate changes cannot be accomplished without impacting baseline STORM functionality require Model Manager approval before being released. The Government may request interim updates to be delivered on specified dates, but will generally not set the schedule for delivery.. The Contractor shall deliver interim code releases to the Government either physically on CDs or DVDs or by other established means of electronic data transfer.

3.5.9 Version Releases

Version releases often include, but are not limited to, modifications impacting core functionality of the model.. Dates for which baseline versions of STORM are completed and released to the community will be coordinated with the Model Manager. No later than 60 days prior to the determined release date, the Contractor shall deliver an alpha version to the Model Manager.

Testing shall be done in the alpha version, discrepancies shall be resolved, and corrections shall be implemented into a beta version to be delivered to the Model Manager no less than 30 days prior to the determined version release date. A final phase of testing shall be performed on the beta version to identify remaining bugs. Corrections shall be implemented and tested prior to final version release. For each software version release, the Contractor shall revise documentation to account for changes; and place all final code and documentation changes under configuration control. Documentation may include but is not limited to an Analyst’s Manual, Programmer’s Manual, and User’s Guide. The Contractor shall deliver integrated software version releases with an automated installation process and updated documentation on CDs or

DVDs on the schedule agreed upon by the Government.

3.5.10 Maintain Software Version Repository

The Contractor shall maintain a configuration controlled version of software and documentation for all version releases. This repository shall include a configuration control log that details all changes made in either interim or version releases and be presented to the Government upon request.

3.5.11 Code Development Testing

At the request of the government, prior to the release of interim STORM code, the Contractor shall perform off-site testing of interim code on A9 collateral databases. These tests will examine the STORM code against robust databases that stress different areas of the model in an effort to isolate hard breaks in the code and identify possible errors in the database. Upon testing completion, the Contractor shall provide a final report describing all discovered breaks and responsive fixes to be included with the Alpha, Beta or Final code release, as applicable.

3.6 User Community Support

3.6.1 AF/A9 shall be the sole authority responsible for defining the User Group membership roster, and subsequently determining each user’s specific eligibility for STORM support.

AF/A9 shall provide the approved User Group roster to the Contractor when changes occur and provide an updated roster annually, even if no changes have occurred. Upon receipt, the Contractor shall use the roster to validate support requests, ensuring that only authorized members are supported. Each individual request for support received from non-approved sources shall be reported to the government Model Manager as soon as possible.

3.6.2 STORM Campaign Analysis Toolkit Modification Proposal Development

The Government will continually seek to enhance STORM capabilities Campaign Analysis

Toolkit by identifying, proposing and evaluating improvements to the methodologies, model algorithms and code, databases and graphical user interfaces. The Contractor and Government shall work in concert to thoroughly define enhancement requirements. The Contractor will provide to the Government recommended courses of action to include draft designs and an estimate of the level of required effort entailed, aka “White Papers”. If the decision is made by the Government to proceed with the suggested course of action, the Contractor will work with the Government to create a modification proposal for submission to the CCB. The Contractor is not required to develop modification proposals for efforts initiated outside of AF/A9 or outside the scope of this PWS as determined by the Government. However, the Contractor shall review outside agency proposals for viability and feasibility as a required task under configuration control.

3.6.3 Campaign Analysis Toolkit Review of Modification Proposals

The Contractor shall support Government reviews of all proposed model modifications to include an assessment of the impact these changes will have on the underlying assumptions, operations, database requirements, source code, and run-time environments of the model. The

Contractor shall either recommend approval to implement the proposed design or propose design changes back to the Government. Modification proposals may evolve through the requirements definition and design processes, and thus may be submitted to the CCB multiple times for approval.

3.6.4 Document Requests for STORM Campaign Analysis Toolkit Software Modifications

The Contractor shall maintain a software change request database that provides, at a minimum, who required the change, background information on the change and the status of any action taken to implement or discard the change, and provide the database to the Model Manager who will maintain it.

3.6.5 STORM Campaign Analysis Toolkit Design Development

It is at the discretion of the Government to endorse and fund under this contract modifications approved by the CCB, however there is no requirement that a resulting design document will be funded upon receipt. Upon authorization from AF/A9, the Contractor shall research such modifications and provide a software specification document to the Government. This document shall contain: a) a detailed design of the methodology, data structures, and algorithms to be implemented; b) a test plan outlining proposed implementation approach, test cases, and test plan; c) an assessment of the impact the software changes will have on the underlying assumptions, operations, database requirements and sources, and run-time environment of the

STORM Campaign Analysis Toolkit. The Contractor will submit the completed software specification document to the Government for approval before Contractor hours are expended on the modification. Subsequent to design review, the Contractor shall modify the design and the software specification document to incorporate recommendations made by the Government. The revised design shall be re-submitted for review and the iterative review process will continue until the design and software specification document are approved for implementation by the

Government. Software Specification Documents containing requirements or design methods diverging from the CCB approved modification proposal shall be submitted to the CCB as an addendum to the original proposal.

3.6.6 STORM Campaign Analysis Toolkit Software Modification Implementation

The Contractor shall, upon approval of the software specification document, code the software, integrate it into the baseline and test the implementation. The Contractor shall incorporate all approved software and data changes, including those developed outside of this contract, into a baseline configuration controlled version of STORM. Responsive bug fixes (described in Section

3.7.3) are not required to undergo the CCB approval process. All other modifications must have been previously approved by the CCB before being incorporated into baseline STORM. STORM updates will be released either as interim updates or as version releases. Interim updates and version releases must follow a versioning schema agreed upon by the Government.

3.6.7 STORM Campaign Analysis Toolkit Interim Release Code

Interim updates, previously known as “Release Candidates”, shall be released by the Contractor as necessary to support current analytic efforts of the STORM community. These updates will include code changes that add immediate functionality to the model or resolve bugs found in the current supported baseline versions. Changes may be required directly from the Government or be required to resolve issues identified by the Help Desk, Section 3.7.4. Responsive fixes are geared toward resolving immediate problems in an expedient manner. As a result, less stringent model documentation and design specifications are acceptable for this type of modification. All documentation shall be provided to the Model Manager upon release of the interim update. In order to minimize disruption to the efforts of the overall community, the Contractor shall ensure all modifications effect STORM functionality only if explicitly employed by the user. Cases where immediate changes cannot be accomplished without impacting baseline STORM functionality require Model Manager approval before being released. The Government may request interim updates to be delivered on specified dates, but will generally not set the schedule for delivery to the Government. The Contractor shall deliver interim code releases to the

Government either physically on CDs or DVDs or by other established means of electronic data transfer.

3.6.8 STORM Campaign Analysis Toolkit Version Releases

Version releases often include, but are not limited to, modifications impacting core functionality of the model. Dates for which baseline versions of STORM are completed and released to the community will be coordinated with the Model Manager. No later than 60 days prior to the determined release date, the Contractor shall deliver an alpha version to the Model Manager.

Testing shall be done in the alpha version, discrepancies shall be resolved, and corrections shall be implemented into a beta version to be delivered to the Model Manager no less than 30 days prior to the determined version release date. A final phase of testing shall be performed on the beta version to identify remaining bugs. Corrections shall be implemented and tested prior to final version release. For each software version release, the Contractor shall revise documentation to account for changes; and place all final code and documentation changes under configuration control. Documentation may include but is not limited to an Analyst’s Manual, Programmer’s Manual, and User’s Guide. The Contractor shall deliver integrated software version releases with an automated installation process and updated documentation on CDs or

DVDs with the agreed upon schedule. (Deliverables: Contract Data Requirement List (CDRL) 1

Deliverable 001 STORM Campaign Alpha Developmental Release, CDRL 2 Deliverable 002

STORM Campaign Analysis Toolkit Beta Developmental Release, and CDRL 3 Deliverable 003

STORM Analysis Toolkit Final Version Release.)

3.6.9 Maintain STORM Campaign Analysis Toolkit Software Version Repository

The Contractor shall maintain a configuration controlled version of software and documentation for all version releases. This repository shall include a configuration control log that details all changes made in either interim or version releases and be presented to the Government upon request.

3.6.10 STORM Campaign Analysis Toolkit Code Development Testing

At the request of the government, prior to the release of interim STORM Campaign Analysis

Toolkit code, the Contractor shall perform off-site testing of interim code on A9 collateral databases. These tests will examine the STORM Campaign Analysis Toolkit code against robust databases that stress different areas of the model in an effort to isolate hard breaks in the code and identify possible errors in the database. Upon testing completion, the Contractor shall provide a final report describing all discovered breaks and responsive fixes to be included with the Toolkit Alpha, Beta or Final code release, as applicable.

3.6.11 STORM Campaign Analysis Toolkit User Community Support

AF/A9 shall be the sole authority responsible for defining the STORM Campaign Analysis

Toolkit User Group membership roster, and subsequently determining each user’s specific eligibility for STORM support. AF/A9 shall provide the approved STORM Campaign Analysis

Toolkit User Group roster to the Contractor when changes occur and provide an updated roster annually, even if no changes have occurred. Upon receipt, the Contractor shall use the roster to validate support requests, ensuring that only authorized members are supported. Each individual request for support received from non-approved sources shall be reported to the Government

COR immediately. (Deliverables: Contract Data Requirement List (CDRL) 4 Deliverable 004

STORM Campaign Analyst Toolkit Alpha Developmental Release, CDRL 5 Deliverable 005

STORM Campaign Analyst Toolkit Beta Developmental Release, and CDRL 6 Deliverable 006

STORM Campaign Analyst Toolkit Final Version Release.)

3.7 Help Desk Requirements & Administration

3.7.1 The Contractor’s STORM Help Desk shall serve as the first point of contact for members of the User Group with technical issues involving the model. The Contractor shall provide technical support functions to the Government’s approved users of

STORM. The Government’s maximum expected level of effort for this task is less than a full man year. The manning of the Help Desk is as required and shall not be a full time effort.

3.7.2 The Contractor shall provide an off-site Help Desk for the STORM user community, to identify, isolate, and correct problems with the model. The user experiencing a problem will be expected to identify the problem, characterize the domain of the problem (e.g., model version, data used, operating system, etc.) and to provide this information to the

Contractor-staffed Help Desk. The Contractor is not required to maintain a full time answering service, however, the Help Desk shall be reachable by telephone or email during normal duty hours (0830 – 1630 EST hrs). The Contractor shall maintain a log documenting trouble calls (tickets) received in consecutive order to include the following: tracking number, the date trouble ticket was opened, originator and their contact information, the nature of the problem, the solution provided if any, the current status of any open trouble calls, date closed and follow-up summary of any/all actions taken to close. Open tickets over 30 days old will be highlighted in the Monthly Progress

Report and will include all appropriate information as to why no resolution has been made and the expected resolution date. The Contractor shall include a list of all monthly trouble call logs and the status of each call log in the Monthly Progress Report, due on the 5th business day of the month, to the Contracting Officer Technical Representative

(COR).

3.7.3 Additional Help Desk Administration.

At the request of the Government, the Contractor shall be prepared to provide additional Help

Desk support similar in scope to the requirements in Section 3.7 above.

3.7.4 STORM Campaign…