SS Draft - Attachment 7 - Draft Statement of Objectives QUALITY ASSURANCE SURVEILLANCE PLAN

DRAFT DOCUMENT

QUALITY ASSURANCE SURVEILLANCE PLAN

STATEMENT OF OBJECTIVES

1.0 Purpose

T

Software Development and Technical Support

AF

This section details the Government's specific surveillance methods and processes used to evaluate Contractor compliance. To ensure execution aligns with modern agile and high-performance computing best practices, traditional milestone-based document reviews are replaced with continuous integration validations, live demonstrations, and automated static code quality analysis.
This Quality Assurance Surveillance Plan (QASP) provides a systematic surveillance method to evaluate Contractor performance under the Software Development and Technical Services (SDTS) contract. The Contractor is responsible for management and quality control actions to meet the terms of the agreement; the Government is responsible for monitoring Contractor performance to ensure the mission to develop and maintain science enabling software infrastructure and HPC environments is achieved.

2.0 Performance Standards and Evaluation Framework

R

The Contractor's performance will be evaluated against the highly complex demands of the Modeling Systems Division (MSD), focusing on the Flexible Modeling System (FMS), the FMS Runtime Environment, data services, and the Model Diagnostics Taskforce Framework.

2.1 Agile Software Development and Model Integration Surveillance

D

●​ Standard: TStandard: The Contractor must facilitate the collaborative, modular development of FMS and component models (e.g., MOM6, FV3) using a capacity-based, agile sprint model. To ensure delivery is incremental and does not stall development, traditional document-heavy design reviews (e.g., Preliminary and Critical Design Reviews) are replaced by recurring agile ceremonies.
●​ Surveillance Method: The Government Contracting Officer's Representative (COR) and MSD Lead will evaluate performance through the following mechanisms: a.​ Interactive Sprint Reviews: Direct observation of live, working software demonstrations at the end of every sprint cycle to verify that delivered features meet scientific requirements and end-user needs.
b.​ CI/CD Pipeline Validation: Objective verification that 100% of code integrated into the main repository passes the automated hierarchical testing pipeline (HSD) with zero regression failures.

DRAFT DOCUMENT

c.​ Definition of Done Verification: Prior to accepting a completed iteration, the Government Product Owner will audit the sprint backlog to confirm that every