JPSS CGS Verification and Validation

1. JPSS CGS Verification and Validation G. Mineart Noblis / JPSS Program SE 042211

2. Purpose • Response to IDPS PMR Splinter Session Action Item #11 from 040611 • “Clarify the program definition of verification and validation and how it applies to CGS for Algorithms”

3. Principal References • NPR 7123.1A – NASA Systems Engineering Processes and Requirements w/Chg 1 • GPR 7123.1A – GSFC Systems Engineering • NASA/SP-2007-6105 Rev1 – NASA Systems Engineering Handbook • NPR 7150.2 – NASA Software Requirements

4. Verification • Used to determine if the end product was realized correctly (i.e., “the system was done right”) • Shows proof of compliance with requirements • Product can meet each “shall” statement • Proven though performance of a test, analysis, inspection, or demonstration • Software verification is a software engineering activity • Basis • Approved requirements set • Configuration baseline • Product Verification Plan • Timing • Can be performed at any stage in the product life cycle • Pre-launch risk reduction (E2E System Testing) • Can be combined with Validation activities

5. Validation • Used to determine if the correct end product was realized (i.e., “the right system was done”) • Shows the effectiveness and suitability of the product for use in mission operations by typical users • Product meets the expectations of the stakeholders • The product accomplishes the intended purpose in the intended environment • Proven though performance of a test, analysis, inspection, or demonstration (early phases) and certification or acceptance tests using operational processes and personnel (later phases) • Software validation is a software engineering activity • Basis • Concept of Operations • Baselined Stakeholder requirements • Product Validation Plan • Timing • Can be performed at any stage in the product life cycle (ORR prerequisite) • Can be combined with Verification activities

6. What Has Changed from IPO • Clearer verification and validation authority and ownership • Single set of governing acquisition directives (i.e., NASA) • Launch is not viewed as a demarcation between the execution of verification and validation activities • Post-launch operational verification • Formalized pre-launch validation • Single authority for identification and allocation of requirements and verification and validation events • More emphasis on E2E verification testing • Risk required to be assessed for any function not tested in a flight configuration prior to launch • Verification activities include fault protection, fault recovery, and graceful degradation across the entire range of possible inputs • Need for Program validation of supporting models and simulations

7. Thought for JPSS CGS • Software V&V is a software engineering activity • The ground system contribution to science V&V is a JPSS CGS activity (inherited from NGAS and IPO) • Be careful when using the terms “quality” and “performance” as they infer very different things to different team members • IPAC-like criteria generally do not reflect the “goodness” of the underlying science algorithms • NPP science verification is constrained by results from proprietary models and simulations under NPOESS • Cost is too large to justify pre-launch investments in alternative approaches, and the mission system performance risk is low • Consider strengthening robustness testing in ground SI&T plans