Verification Matrix Process 1 Agenda Review of Verification

  • Slides: 19
Download presentation
Verification Matrix Process 1

Verification Matrix Process 1

Agenda • • • Review of Verification Process Verification Planning Matrix (VM-P) Examples Verification

Agenda • • • Review of Verification Process Verification Planning Matrix (VM-P) Examples Verification Planning Matrix Context in the larger Verification & Commissioning Process Key Dates 2

Verification & Validation on LSST • • • LSE-160 Verification and Validation Process is

Verification & Validation on LSST • • • LSE-160 Verification and Validation Process is the governing document for V&V on LSST Establishes a consistent, project-wide process for the development of V&V plans, compliance assessments, V&V reporting, and deliverables It is the process that ensures every requirement gets planned and traced to an activity to verify it. Defines steps in the verification process Defines requirements for developing verification plans for each project-controlled requirement

 • • LSE-160 Applicability • • • Applies to all Project-Controlled requirements: Specifications

• • LSE-160 Applicability • • • Applies to all Project-Controlled requirements: Specifications Requirements Documents Interface Control Documents (ICDs) Each “shall” statement in each of these documents must be formally verified Project-Controlled Specifications Project-Controlled ICDs

LSST Verification & Validation Process

LSST Verification & Validation Process

Heuristics/Guidance for Verification • Ranking of desirability of Verification Methods: • • • 1.

Heuristics/Guidance for Verification • Ranking of desirability of Verification Methods: • • • 1. Test (performance) / Demonstration (functional) 2. Analysis (performance) / Inspection (functional, features) Requirements should be verified at the lowest level of integration possible There will be exceptions where lower level requirements can only be verified at higher levels. We need to understand those exceptions now so that they can be incorporated into the Commissioning plan Interface Requirements should be verified first by the subsystems using analysis or emulators/simulators for the other side of the interface prior to subsystem acceptance into Commissioning. Final verification of project-level interface requirements will occur in Commissioning with actual hardware/software on both sides of the interface. Both levels of interface verification activities will be captured in the ICD verification matrices

Verification Planning Requirements • • For each requirement (“shall statement”) a Verification Plan will

Verification Planning Requirements • • For each requirement (“shall statement”) a Verification Plan will be created that includes the following: Verification Owner – the subsystem team that is responsible for verification Responsible Technical Authority (RTA) – the point-of-contact assigned responsibility for the verification of the requirement from the responsible subsystem. The RTA has responsibility for overseeing all associated verification activities. Verification Method(s) – Test, Analysis, Inspection, Demonstration Verification Level – Same Level, Higher Level, Lower Level Verification Requirement – A statement that defines precisely what will be done to verify the requirement. If there is any vagueness in the requirement, the Verification Requirement should clearly address the noted issues and define what precisely will be verified any limitations. The statement should define what will be done, where it will be done, what special test equipment (STE) is needed, and what project hardware/software is needed. Success Criteria - A statement that defines the explicit pass/fail criteria. This statement should be clear enough that an independent third party observer should be able to determine if the verification event was successful or not. Needed by Fall 2016 to support Com. PDR

Examples • • Verification Planning Matrix for the OSS (LSE-30) Verification Planning Matrix Template

Examples • • Verification Planning Matrix for the OSS (LSE-30) Verification Planning Matrix Template for the T&S Spec (LSE-60) 8

OSS Verification Planning Matrix

OSS Verification Planning Matrix

VM-P Template for LSE-60

VM-P Template for LSE-60

End-to-End Verification Implementation Process • Different Tools Utilized for Various Strengths • Enterprise Architect

End-to-End Verification Implementation Process • Different Tools Utilized for Various Strengths • Enterprise Architect Sys. ML • Manage Requirements • Traceability • Self Consistent Plan • Documentation from Model • PMCS (Primavera) • Integrated Master Schedule • EVMS • JIRA • Agile / Ability to Adapt quickly • Connectivity back to EA for Verification Closeout

End-to-End Verification Implementation Process • The rest of the process is notional and will

End-to-End Verification Implementation Process • The rest of the process is notional and will continue to be developed as part of the Commissioning re-plan and detailing of the Verification Plan

Key Dates • Definition of Verification Owner, RTA, Method(s) and Level: Specs/ICDs Completion Date

Key Dates • Definition of Verification Owner, RTA, Method(s) and Level: Specs/ICDs Completion Date LSR (LSE-29), OSS (LSE-30), Camera (LSE-59) 09/09/16 T&S (LSE-60), DM (LSE-61), OCS (LSE-62), EPO (LSE-89) 09/23/16 Project-Controlled ICDs 10/07/16