DRAFT PWS Force Structure Support 8Mar2023 DRJ.docx

Force Structure Support PWS CUI Page 1 of 30

FA7014‐22-X-XXXX

PERFORMANCE WORK STATEMENT (PWS)

FORCE STRUCTURE SUPPORT

Controlled by: AFDW/PK CUI Categories: PROCURE Distribution/Dissemination Controls: FEDCON AFTER AWARD POC: CO NAME (240-612-xxx)

Performance Work Statement (PWS) Force Structure Support for Secretary of the Air Force (SecAF), Office of Studies and Analysis (SAF/SA) through AFDW/PK

Table of Contents

ORGANIZATION AND MISSION

The Secretary of the Air Force (SecAF), Office of Studies and Analysis (SAF/SA) serves as the Department of the Air Force (DAF) Operations Research (OR) and systems analysis organization to inform enterprise-level decisions. SAF/SA provides analysis in support of both the Air and Space Forces and the Secretariat. SAF/SA utilizes engagement, mission, and campaign level models to aid in determining the impact of technologies and tactics upon war-fighting outcomes and to make informed recommendations for future Force Structure decisions, influencing the quantity and quality of the Combat Air Force (CAF).

OBJECTIVE AND SCOPE

Objective

The primary purpose of this contract is to provide Software Development Services (SDS), in the form of modification, maintenance, and operation of specified Modeling and Simulation (M&S) tools in support of the Requiring Activity's (RA’s) mission requirements defined herein.

SAF/SA currently manages multiple M&S tools and associated databases to analyze the air, space, cyber, and joint campaigns in support of the yearly Planning, Programming, Budget, and Execution (PPBE) process. These tools range from engagement level, through mission level, to campaign level models. Each model portrays a different aspect of combat. Engagement level models typically support analysis of one or a few friendly systems versus one or a few threat systems, embedded in networks of associated communications and sensor architectures. Mission level models are used to analyze the effectiveness of multiple integrated friendly networks against an integrated enemy threat. Campaign level models attempt to portray the effects multiple integrated systems and networks can have on an entire air or joint campaign.

Models under this effort shall include the Brawler Air-to-Air Combat Model (i.e., Brawler); the Combat Forces Assessment Model (CFAM); the Theater Attrition Modeling System (TAMS); the Logistics Modeling Suite (LMS), which includes the Contingency Basing Selection and Assessment (CBSA) Model, the Time-Phased Force Deployment Data – Planner (TPFDD-P), and the Airfield Damage-Assessment and Resiliency (AD-ARM); and the Advanced Framework for Simulation, Integration, and Modeling (AFSIM), mission and theater level model, as well as other models that SAF/SA may adopt or develop. Hereafter, this suite of models (i.e., Brawler, CFAM, TAMS, LMS (e.g., CBSA, TPFDD-P, and AD-ARM), AFSIM, and future associated models), will be collectively referred to as MODELS, with exceptions noted where applicable. MODELS details include:

Brawler: SAF/SA utilizes engagement- and mission-level models to aid in the determination of the impact of technologies and tactics upon warfighting outcomes. The Brawler assesses air-to-air and limited surface-to-air and air-to-surface engagements and is a key input to this process. Brawler uses a modular representation of air vehicles, with kinematics, propulsion, and sensors modeled separately, as discrete components, with their capabilities specified parametrically.

Combat Forces Assessment Model (CFAM): SAF/SA utilizes campaign-level models to aid in Force Structure optimization. A key input to this process is the CFAM, which is a large-scale linear program designed to provide Air Force (AF) decision-makers with an analytical tool for determining the impacts of budget changes, Force structuring, target allocation, munitions inventories, and combat attrition rates on war-fighting capabilities in a theater scenario and produce an optimized Force Structure assessment. The CFAM model consists of the CFAM model code written in the General Algebraic Modeling System (GAMS) versions 2.x and 3.x, a CFAM Graphical User Interface (GUI) versions 2.x and 3.x, the CFAM dataset development tool (i.e., CFAM Target Module), and data post processing tools (e.g., CFAM Results Parser).

Theater Attrition Modeling System (TAMS): SAF/SA's TAMS is being developed to produce Integrated Air Defense Systems (IADS) level combat attrition of aircraft and long-range weapons. Attrition data is a key data element, along with kills per sortie, for the CFAM. TAMS initial development and fielding has been largely completed and is now entering a follow-on fielding and more gradual development phase. TAMS utilizes AFSIM as the IADS driver.

Logistics Modeling Suite (LMS): SAF/SA’s LMS is an interactive analytic framework designed to explore the impact of various logistics Concept of Operations (CONOPS) and levels of support measured in terms of the operational effect to generate forces in warfare. The three core models being developed and modified are CBSA, TPFDD-P, and AD-ARM, which are each briefly discussed below. The model suite is most often used to perform mission-level modeling to inform campaign warfare analysis. Typical logistics areas addressed are infrastructure capacity and capability, movement of assets, sortie generation and production, and resilience to and after attack. Each model is designed and developed to work independently for specific analysis, but also to work in conjunction with each other and related models and tools to address larger questions. In most cases there are component tools within the models that cause the model to function as a system-of-systems (see Figure 1 below).

Figure 1: Logistics Modeling Suite Interactions

Contingency Basing Selection and Assessment (CBSA): CBSA assesses the feasibility of Force laydown locations to support the desired type and number of aircraft for the operational mission requirements. CBSA uses high-accuracy Geospatial Information and Services (GI&S) data focusing on runways, ramps, fuel operations, and munitions for single or mixed aircraft types (e.g., Mission Design Series (MDS)). The CBSA output is typically used to support analysis efforts in the other LMS models and to directly inform campaign-level models needing location selection and assessment. The summary question CBSA addresses is: “Where can we operate?”

Time-Phased Force Deployment Data – Planner (TPFDD-P): TPFDD-P examines the movement and maneuver requirements of operational locations based on the desired Forces mission capability requirements. It organizes them into sets of Unit Type Codes (UTCs) to determine the movement and maneuver requirements for the personnel, equipment, and related supplies. This in turn is used to quantify the Logistically Feasible Force Flow (LF3), including points of origin for them. TPFDD-P output is typically used as an input for campaign mobility models, which then identify Force closure sufficiency to meet campaign timing, deployment limitations, and delays. The summary question TPFDD-P addresses is: “How much, where, and how fast do we have to move?”

Airfield Damage-Assessment and Resiliency (AD-ARM): AD-ARM examines the baseline capability of operating locations to generate sorties before attack and then the capability to recover after attack. It expresses this analysis as both a damage assessment and of resiliency of recovery measured in terms of the change in feasible sortie generation of the aircraft. It includes the infrastructure to evaluate overall sortie production. AD-ARM typically uses the other LMS models and several external models as a system-of-systems to provide an output of high-fidelity, GI&S-informed evaluation of the location, sets of locations, or the theater to inform operational and logistics CONOPS for future warfare and scenario development. The summary question AD-ARM addresses is: “How well can we operate after the enemy attacks?”

Advanced Framework for Simulation, Integration, and Modeling (AFSIM): SAF/SA utilizes mission-level models to assess the relative merits of different technologies; weapon systems; space systems; Tactics, Techniques, and Procedures (TTP); and other Force Structure decisions, to inform AF and wider Department of Defense (DoD) decision-makers. A key input to this process, the AFSIM, is the assessment of new system concepts and designs with advanced capabilities not easily assessed within traditional engagement and mission level simulations. Development activities include modeling weapon kinematics; space, air, and ground sensor systems; electronic warfare systems; communication networks; advanced tracking, correlation, and fusion algorithms; and automated tactics and battle management software. While SAF/SA is not the model manager for AFSIM, SAF/SA is one of the early implementers of AFSIM and is a developmental user expanding the capabilities of the model. As such, SAF/SA often has need of larger changes to the software and related databases to improve existing capabilities (e.g., develop new quantum taskers); enable new capabilities (e.g., development of new theater-level scenario laydowns); address current limitations (e.g., expand air-to-air decision-making algorithms); or to federate AFSIM to other Modeling and Simulation (M&S) tools (e.g., create a shared Brawler and AFSIM interface to external missile data files). Additionally, SAF/SA may require usability modifications (e.g., GUI changes and updates); improvement of reporting from “observers” to ease post-processing functionality; or changes to the space modules to mimic Satellite Tool Kit (STK) capabilities within AFSIM (e.g., orbital mechanics, satellite maneuver, and adaptive data networks).

Scope -- Requiring Activity and Partners. The work under this contract is being done principally for SAF/SA, at the locations set forth in Section 9.0. Strategic partners shall include other Secretariat/Headquarters AF agencies (e.g., directorates AQ, A3, A5, and A8) and Combatant Command analytic agencies (e.g., U.S. Air Forces in Europe (USAFE)/A9 and Pacific Air Forces (PACAF)/A9).

Mission Essential. The maintenance and development of the software tools managed under this contract are essential to maintaining the credibility of the analytic insights produced by SAF/SA and other associated agencies, but this Force Structure Support is being acquired as a service, so that government personnel can be freed up to perform higher priority taskings, and taskings that are barred from contracted support (acquisitions, source selection, and decision-support analyses). As such the contracted Force Structure Support is not inherently governmental in nature.

TASKS

The Contracting Officer (CO) is the only person authorized to direct the contractor or take any actions that would change the contract or commit the Government in any way. The CO will appoint a Contracting Officer’s Representative (COR) who will be the RA’s contact. The COR will work with the contractor pursuant to the scope of the PWS to meet mission requirements. Unless otherwise specified, deliverables shall be delivered in commercial standard format (e.g., Microsoft Word or Adobe PDF).

Any and all source code, models, prototypes, programming, language, licensure, enterprise-wide rights, software, Contract Data Requirements Lists (CDRLs), manuals, training documents, and other similar products and related data developed, modified, or created under the contract shall be exclusively at the United States (U.S.) Government's expense. Per Defense Federal Acquisition Regulation Supplement (DFARS) 252.227-7014(b)(1), all of these items must be delivered to the U.S. Government with unlimited rights. As such, the Government may use, modify, reproduce, release, perform, display, or disclose the source code in whole or in part, in any manner and for any purpose whatsoever, and it may authorize others to do so. No proprietary software shall be designed or incorporated into any of the MODELS managed under this contract.

(Task 1) – Program Management

Post-Award Brief (PAB). The PAB shall be held within seven calendar days of the start of performance. Schedule and conduct this meeting in coordination with the COR and CO.

The purpose of the PAB is to: 1) discuss any unique characteristics of the requirement(s); 2) identify stakeholders' roles and responsibilities; 3) review the 60-day transition-in to full performance; and 4) establish a common understanding of cost, schedule, and performance expectations (Deliverable 3.1-1: contract PAB Slides).

Program Management Plan (PMP). The PMP is a resource-loaded baseline that outlines the steps that will be taken, provides the timeline to completion (estimated project start and stop dates), provides an expenditure plan aligned to key milestones within the project (to include any anticipated Other Direct Costs (ODCs)), identifies and quantifies the deliverables associated with each project, and identifies any associated risks and appropriate mitigation needed for execution of the contract. The completion timeline(s) of any given project shall not extend beyond the overall Period of Performance (PoP) of the contract. The contractor shall provide the initial PMP within 15 days after contract award and provide an updated PMP quarterly and within 15 days after each new project tasking. Upon acceptance and approval by the Government, the contractor shall meet the cost, schedule, and forecasted delivery date of all deliverables by taking all reasonable measures to fulfill the requirement and report the project status in the Monthly Status Report (MSR). The deliverable quantities listed in each table from Task 4 through Task 6 are estimates provided for reference. The actual deliverable quantities will be reflected within the PMP upon assignment of the project(s) and the Final Technical Report (FTR) (Deliverable 3.1-2: PMP).

Monthly Status Report (MSR). The MSR shall provide a detailed status for each project within the PMP as well as capture an overall status of the contract. The contractor shall deliver the MSR on a date mutually agreed upon by the contractor and the COR. Specific MSR format, and any additional content not specified in this section, shall be mutually agreed upon by the contractor and COR; this format shall be established No Later Than (NLT) the PAB. The MSR reports cost, schedule, and performance against the PMP baseline and identifies planned versus actual expenditures per project; total monthly and cumulative ODC expenditures; status of known risks and risk mitigation efforts; deliverable(s) funded, technical progress made, and schedule status per deliverable(s); title, date, and number of deliverable(s) completed; and deliverable(s) scheduled to be delivered during the upcoming month. The MSR shall report all funding received and shall detail the projects supported by such funding, the date received, and the funding source (if known). If the MSR shows that a project is not meeting the performance standards set forth in the Service Summary found in Section 6.0, the contractor shall provide the rationale and circumstances preventing the standards from being met (Deliverable 3.1-3: MSR).

Quarterly Project Management Reviews. Conduct quarterly project management reviews with the COR to include detailed project information on cost, schedule, performance, risk assessment, and risk mitigation plans (Deliverable 3.1-4: Quarterly Project Management Review).

Final Technical Reports (FTRs). The FTRs shall include contract-specific background information, objectives, assumptions, specific data collected, analyses conducted, recommendations, and conclusions. An initial technical report shall be submitted halfway through the PoP. A draft FTR shall be submitted NLT 45 days prior to the last date of the contract’s PoP, and the completed FTR shall be submitted NLT 10 days prior to the last date of the contract’s PoP. Each report shall be delivered to the COR and COR (Deliverable 3.1-5: FTR).

Redacted contract. Within 30 days after contract award, provide a redacted copy of the awarded contract that is appropriate for public release. The redacted contract shall be posted by the Government to a public website (Deliverable 3.1-6: Redacted contract).

Contractor Acquired Property (CAP) Report. Provide a monthly report for all CAP acquired via ODC charging to be included in the MSR, if applicable (Deliverable 3.1-3: MSR).

Task 1 Deliverables Table

Performance Deliverables

Due Date or Frequency Description

(Task 2) – Conferences. A “conference” is defined in the Joint Travel Regulations (JTR) as, “[a] meeting, retreat, seminar, symposium, or event that involves attendee travel. The term ‘conference’ also applies to training activities that are considered to be conferences under 5 Code of Federal Regulations (CFR) 410.404.” Contractor responsibilities for hosting conferences may include coordinating the location for a conference and providing the venue by reserving and incurring the cost of meeting rooms and required technical equipment ODCs under this contract. Additionally, contractors may manage attendee invites and acceptances, badging, and security, and may provide printouts of briefs to attendees. The contractor shall not expend any resources associated with hosting a conference until the RA has obtained the requisite approval to conduct a conference from the appropriate approval authority In Accordance With (IAW) the current DoD Conference Guidance. The contractor shall be aware of and not incur any prohibited conference expenses per the DoD Conference Guidance. The contractor shall not expend any funds under this contract for providing food or nutrition for technical symposiums or conferences or for blocking off or reserving lodging for attendees.

The contractor shall draft the Conference Planning and Approval Information Request. Approval is required for each individual conference, unless one-time approval is provided for a recurring DoD-sponsored or -hosted conference. Conference support for this contract is estimated to be approximately two conferences per year. Each conference duration is estimated at two days up to four days, with attendance up to approximately four people (Deliverable 3.2-1: Conference Planning and Draft Approval Information Request; Deliverable 3.2-2: Conference Report).

Task 2 Deliverable Table

Performance Deliverables

Due Date or Frequency Description

(Task 3) – Contract Transition Support Transition-In. Facilitate the accomplishment of a seamless transition of requirements. Transition-in services shall begin on the effective date of the award and shall be complete on the date which is 60 days after the effective date when the contractor shall assume full responsibility for Tasks 4 and beyond. Comment by JOHNSON, DALE R GS-14 USAF HQ USAF DIR SPT EL HS/A9FM: This is what was specified, and should be sufficient if they have the experience gates required in section 8. Not sure if we can specifty a requirement for resumes at the time they propose. If we can require them and evaluate them when scoring proposals, then 60 days to transition in should be sufficient.

Identify Points of Contact (POCs) for liaison between the Government, the prime contractor, and other contracted industry partners for a proper and orderly transition and transfer of services and assets between the parties cited.

Prevent disruption to vital Government business, including service degradation during or after transition.

Establish an overview of the transition efforts and describe the activities to transition, which shall include a schedule with milestones by activity.

Coordinate the transition of Government property, if applicable.

Transition knowledge and information regarding risk or problem areas from contractor personnel or Government personnel.

Transition-Out Plan. Develop and execute a Transition-Out Plan that shall facilitate the accomplishment of a seamless transition from the incumbent to incoming contractor or Government personnel at the expiration of the contract. Provide a Transition-Out Plan NLT 60 days prior to expiration of the contract. Identify how the incumbent will coordinate with the incoming contractor and Government personnel to provide a seamless transition and transfer knowledge regarding the following:

1. Program and project management processes POCs Location of technical, program, and project management documentation Status of ongoing technical initiatives Transition of personnel Schedules and milestones Actions required of the Government Communication with the incoming contractor or Government personnel for the period of the transition via weekly status meetings Transition-Out Plan, to include:

1. Coordination with Government representatives

1. Review, evaluation, and transition of current support services

1. Transition of historic data to new contractor systems

1. Identification of Government-approved training and certification process

1. Transfer of hardware warranties and software licenses

1. Transfer of business and technical documentation

1. Development of an orientation phase and program to introduce Government personnel, programs, and users to the contractor's team, tools, methodologies, and business processes

1. Disposition of contractor-purchased Government owned assets, including facilities, equipment, furniture, phone lines, and computer equipment

1. Transfer of Government Furnished Equipment (GFE) and Government Furnished Information (GFI), and GFE inventory management assistance

1. Personnel out-processing procedures including turn-in of all Government keys, IDs, and access cards (Deliverable 3.3-1: Transition-Out Plan).

Task 3 Deliverables Table

Performance Deliverables

Due Date or Frequency Description

(Task 4) – MODELS Modification Comment by JOHNSON, DALE R GS-14 USAF HQ USAF DIR SPT EL HS/A9FM: This is the most dynamic of our tasks. I may have several different modification projects going on simultaneously. Some may be incrementally funded over 18 months-3 years, others may be a quick 4-6 month modification. It would be good for tracking purposes if we could have a separate CLIN (101, 102, 103 . . .) for each subsequent project.

MODELS Modification Design Approval. Research and develop proposed MODELS designs as Software Specification Documents (SSDs) to include analyzing Government requirements for code upgrades or modifications to MODELS and present to the Government for review, prior to implementation. Upon Government review and approval, incorporate the Government’s recommendations into the SSD until the design is approved for implementation by the Government (Deliverable 3.4-1: SSD).

MODELS Modification Implementation. Upon Government approval of the SSD, commence the modifications and develop progress reports at least monthly or as specified in the SSD development process, and include those reports as well as software modification processes and practices in a Software Integration Plan (SIP) (Deliverable 3.4-2: SIP).

MODELS Modification Configuration Control. Assess and update a working software version, which is defined as a configuration-controlled version of the original, Government supplied software and associated documentation, to include incorporating the modifications approved and implemented in Task 4 of this PWS. The contractor shall act as the Configuration Manager (CM) for the assigned MODELS in close coordination with the Government Model Manager (MM). This evolving code baseline shall be frozen upon Government request and an interim software version shall be made and delivered to the COR and MM. The Government will provide GFI such as existing and updated source codes, documentation, utilities, scripts, and scenario databases to include the initial copy of any MODELS managed under this effort (Deliverable 3.4-3: Interim Software Version).

MODELS Modification Integration, Testing, and Release. Conduct and document code change integration and testing processes as changes are made to the code baseline. Document all code changes in a common software change log, which shall be included in any release documentation developed under this contract (Deliverable 3.4-4: Task 4 Software Change Log Alterations).

MODELS Modification User Documentation. Update associated MODELS’ user documentation (e.g., user guides, programmer’s manuals, and analyst’s manuals) to include verifying all software changes, in addition to being internally documented within the respective code, are reflected in user documentation for users to take advantage of new functionality developed under this contract. User documentation shall be frozen in conjunction with any software release version and packaged for distribution in the same release. The Government will provide the current versions of all documentation associated with the MODELS under management in this contract (e.g., user guides, programmer’s manuals, and analyst’s manuals) (Deliverable 3.4-5: Task 4 User Documentation Changes).

MODELS Modification Verification, Validation, and Accreditation (VV&A). When the scale of the modifications undertaken in Task 4 of this PWS is expected to require a Verification, Validation, and Accreditation (VV&A) effort before it can be used, details for the VV&A effort will be specified by the Government as part of the request for the modification and shall be documented in the SIP. Conduct research and analysis for V&VA model processes to include conducting code reviews, verifying model inputs and outputs, and validating and documenting model results in the VV&A Package as specified in the SIP (Deliverable 3.4-2: SIP; Deliverable 3.4-6: VV&A Package).

Task 4 Deliverables Table

Performance Deliverables

Due Date or Frequency Description

(Task 5) – MODELS Maintenance and Configuration Management Comment by JOHNSON, DALE R GS-14 USAF HQ USAF DIR SPT EL HS/A9FM: This is the least dynamic of our tasks. This one is set at 3 FTE/year and is unlikely to change over the life of the contract.

While major modifications and enhancements to the codes for various MODELS will be undertaken in Task 4, Task 5 shall include research for and analysis of user requirements necessitating the growth of the MODELS to include conducting analysis of bugs, repairs, and requested enhancements to identify maintenance and reliability trends and recommend solutions and software best practices for systems to improve overall MODELS performance.

3.5.1 Software Change Request (SCR) Directed Development. Review and assess user-generated Software Change Requests (SCRs) to include analyzing and identifying recommended solutions to address SCRs. Assess all SCRs upon receipt to include analyzing and sorting them as either: A) bug fixes and software errors (i.e., identified in currently fielded software); or B) modification requests (i.e., enhancements to current software). Research and assess the Level-Of-Effort (LOE) required to address the SCRs, to include identifying the LOE as “LOW” (i.e., up to eight hours to resolve the issue within the SCR); “MEDIUM” (i.e., between eight and 40 hours to resolve the issue); and “HIGH” (i.e., requiring more than 40 hours to resolve) categories. Capture all of this information in an SCR database (or an adjunct to an SCR database managed by a Government agency) documenting, at a minimum, the source of the change, background information on the change, the sort and LOE assessment, and the status of any action taken to implement or discard the change. Brawler’s SCRs are currently submitted to a Government-provided and updated website and database that the contractor shall only be required to access. For CFAM, a Government SCR database will be provided to the contractor, who shall maintain that database during the contract or replace it with a similar tool with the assent of the Government. If a central SCR database is maintained by a third-party, the contractor shall maintain their own standalone adjunct database. The other MODELS under management are not currently mature enough to require an SCR database but may require development in the later years of this contract (Deliverable 3.5-1: SCR Database or Adjunct).

Task 5 Deliverables Table

Performance Deliverables

Due Date or Frequency Description

3.6 (Task 6) – MODELS Operation and Optimization Comment by JOHNSON, DALE R GS-14 USAF HQ USAF DIR SPT EL HS/A9FM: This is a mixed task. Right now the steady state portion of the task represents 8.4 FTE on-site at SAF/SA, 2 FTE on-site A5, and 3 FTE at the contractor site supporting USAFE, and this may grow over time, but not with wide fluctuations.

However there is a requirement to flex to meet SecAF/CSAF tasking for short-term studies, or to hire specialized experience for limited periods. Having an incremental CLIN structure (302, 303, 304 . . .) to accommodate these analytic surges would be helpful. This task could also be split if that would facilitate.

This task shall include conducting analytical studies to include operating the given MODELS on-site or running stand-alone studies off-site, especially where outside expertise is required to identify and develop recommended improvement methodologies for operation and optimization of the MODELS. All such operation and optimization efforts shall be done using the M&S tools detailed under Tasks 4 and 5 of this PWS or involve supporting efforts, such as intelligence analysis, that feeds those models. In addition, modification to the MODELS software packages shall generally be carried out within Tasks 4 and 5 of this PWS, and as such software modifications to source code, scripts, and databases required to complete studies under Task 6 shall be limited to minimal modifications to existing functionality (e.g., enhancements or elimination of bugs and errors) required for on-going studies and analyses.

3.6.1 Analytic Research Operations and Planning. Develop a study plan for each stand-alone analytic effort utilizing MODELS operations on excursion to existing studies, or for separate analytic endeavors. All study plans shall be submitted to the Government for approval before commencing any work. When assisting Government studies, the Government study plan shall be followed, and a separate study plan shall not be created. Conduct MODELS operations R&D analysis in the form of standard model runs to produce data accurately portraying the given scenario(s). Model runs shall include pre-production input files, production runs, and post-production data reduction to support analytic post processing and aggregate findings. All MODELS operations analysis shall adhere to the guidelines set forth in the Government approved study plan (Deliverable 3.6-1: Study Plan; Deliverable 3.6-2: Model Runs).

3.6.2 Study-Related Software Modification. Develop software modification recommendations related to the analysis conducted in Task 6 and implement Government approved modifications to include documenting all modifications in a model-specific change log. Communicate change log updates to the appropriate CM in Sections 3.4.3 and 3.5.2 of this PWS, so they can be placed under configuration control as candidates for inclusion into the code baseline (Deliverable 3.6-3: Task 6 Software Change Log Alterations).

3.6.3 Research Output Reporting. Document post process MODELS output data utilizing existing model functionality, data reduction programs, scripts, database queries, and analyses tools either provided by the Government, as part of the MODELS software suites, through modifications to those Government provided tools, or through the use of industry-standard data-analysis tools. Develop study output reports summarizing findings (Deliverable 3.6-4: Study Output Reports).

3.6.4 Optimization of MODELS Interactions and Job Scheduling. Due to the varied nature of the constituent MODELS such as nature of input files, the number entities played, the time-steps used, and computational approaches, and because all those MODELS must coexist on the same supercomputing infrastructure, SAF/SA needs the ability to research and develop job scheduling techniques to optimize throughput and document those procedures in a job scheduling playbook. Develop and update a job scheduling playbook that lays out in layman’s terms the current rules for scheduling jobs, so that all SAF/SA analysts can fully utilize the computing cluster, without jeopardizing operations for other users. Conduct ongoing life-cycle analysis of the job scheduling playbook to include analyzing bugs and repairs to identify maintenance and reliability trends for systems to improve RMQSI for the overall systems. Verify computational resources are apportioned equitably across all users accounting for user and data production priorities. The network control job schedule schema shall employ software such as MOAB, TORQUE, Altair Grid Engine, PBS Professional, SAMBA, and Galaxy (Deliverable 3.6-5: Job Scheduling Playbook).

3.6.5 Develop Operating Documentation and Research Communications Bridges. Develop and maintain Approval to Operate/Authorization to Connect (ATO/ATC) for Sensitive Compartmented Information Facility (SCIF) and Special Access Program Facility (SAPF) networks using the Risk Management Framework (RMF), for SAF/SA’s Peer-to-Peer (P2P) and standalone networks IAW the DoD Information Assurance (IA) process through the DoD Enterprise Mission Assurance Support Services (eMASS) web interface. The Government may require additions to the list of ATO/ATCs during the course of this contract as new networks are added. Review each ATO/ATC request to verify currency with the Security Control Assessor (SCA) - Authorizing Official (AO) or their Technical Representative (TR), IAW all 33 series Air Force Instructions (AFIs) and the Joint Special Access Program Implementation Guide (JSIG) for SAPF. Participate in monthly SAF/SA Information Technology Requirements Working Group (ITRWG) and Configuration Control Board (CCB) meetings and technical interchanges to include documenting lessons learned and processing Communication-Computer Systems Requirement Documents (CSRDs). Register SAF/SA Ports, Protocols, and Services (PPS) in the DoD Ports, Protocols, and Services Management (PPSM) Registry.