[EXAMPLE Design & Readiness Review Outlines]{.underline}

[Donna McNamara & SPIWG -- December 19, 2008]{.underline}

Preliminary Design Review (PDR)

PDR Participants: IPT (Users, Developers, PAL, Programmers, IT
(OSDPD/IPD), OSD Satellite Product Management, OP Co-Chairs)

1.  Project Overview

    a.  \"Requests for Actions (RFAs)\" will be solicited from the
        meeting participants and results of actions collected during the
        design review will be shared with the IPT in a report.

    b.  Introduce IPT Members

2.  Project Requirements and Goals

    a.  Project requirements (especially from the users)

    b.  Ingest requirements

    c.  Processing requirements (e.g., performance, validation, etc.)

    d.  Dissemination requirements (outputs, formats, timeliness, return
        to service)

    e.  User requirements

3.  System Requirements

    a.  Where is code being developed?

    b.  Where will system be run operationally?

    c.  Space, memory, processing and bandwidth requirements

4.  Algorithm Overview and Sample Products

    a.  Science description

    b.  Science maturity documentation

    c.  Science test data preparation plan

    d.  Preliminary validation plan

5.  System Design

    a.  Languages & Tools (compilers, versions, etc)

    b.  Source of Code (originating organization, amount of
        recoding/customization)

    c.  Directory Structure

    d.  Input Data and Formats

    e.  Ancillary data and Auxiliary Files

    f.  Output Files and Formats

    g.  Run Schedules

    h.  System Architecture, Data Flow, and Security

6.  Quality Assurance

    a.  Error Tracking

    b.  Near-real-time monitoring procedures

    c.  Science monitoring techniques and tools

7.  Documentation (what will be written and by whom?)

    a.  Users Manual

    b.  Interface Control Document

    c.  Maintenance Manual

    d.  Metadata Description

    e.  Operations Manual

    f.  Systems Description Manual

    g.  Archive Data Submission Agreement

    h.  ESPC Monitoring Procedures

    i.  ESPC Monitoring Checklist or GUI Check Template

    j.  Operational Events Log

8.  Users List and Contact Information

9.  Archive Plan -- Discuss Needs and Approach

10. Risk Assessment and Mitigation Actions. Are there factors that might
    impact the execution of your project and what actions can you take
    to mitigate the impact (e.g., building move, personnel changes,
    contractor support/resources, uncertainty about IT refresh meeting
    your needs, algorithm maturity, launch delay, etc.)

11. Project Timeline

Critical Design Review (CDR)

CDR Participants: IPT (Users, Developers, PAL, Programmers, IT
(OSDPD/IPD), OSD Satellite Product Management, OP Co-Chairs)

1.  Project Overview

    a.  \"Requests for Actions (RFAs)\" will be solicited from the
        meeting participants and results of actions collected during the
        design review will be shared with the IPT in a report.

    b.  Introduce IPT Members

2.  Project Requirements and Goals

    a.  Project requirements (especially from the users)

    b.  Ingest requirements

    c.  Processing requirements (e.g., performance, validation, etc.)

    d.  Dissemination requirements (outputs, formats, timeliness, return
        to service)

    e.  User requirements

3.  System construction specifics (software modules ready to code)
    (content differs from PDR)

    a.  Specify coding timelines

    b.  Specify quality control approach

    c.  Specify unit testing and time lines

    d.  Where will system be run operationally?

    e.  Space, memory, processing and bandwidth requirements

4.  Algorithm Overview and Sample Products (content differs from PDR)

    a.  Science description

    b.  Science test data sets

    c.  Present science tests and accuracy

    d.  Completed science validation design

    e.  Detailed validation plan

    f.  Proposed anomaly correction procedures

5.  System Design

    a.  Languages & Tools (compilers, versions, etc)

    b.  Source of Code (originating organization, amount of
        recoding/customization)

    c.  Directory Structure

    d.  Input Data and Formats

    e.  Ancillary data and Auxiliary Files

    f.  Output Files and Formats

    g.  Run Schedules

    h.  System Architecture, Data Flow, and Security

6.  Quality Assurance

    a.  Error Tracking

    b.  Near-real-time monitoring procedures

    c.  Science monitoring techniques and tools

7.  Documentation (what will be written and by whom?)

    a.  Users Manual

    b.  Interface Control Document

    c.  Maintenance Manual

    d.  Metadata Description

    e.  Operations Manual

    f.  Systems Description Manual

    g.  Archive Data Submission Agreement

    h.  ESPC Monitoring Procedures

    i.  ESPC Monitoring Checklist or GUI Check Template

    j.  Operational Events Log

8.  Users List and Contact Information

9.  Archive Plan -- Present the archive plan including all the items
    needed in the submission agreement. Identify who will complete the
    formal document - usually the PAL (content differs from PDR)

10. Risk Assessment and Mitigation Actions. Are there factors that might
    impact the execution of your project and what actions can you take
    to mitigate the impact (e.g., building move, personnel changes,
    contractor support/resources, uncertainty about IT refresh meeting
    your needs, algorithm maturity, launch delay, etc.)

11. Project Timeline

Software Code Review (SCR)

SCR Participants: An individual or small team with expertise in software
and systems standards, software security, and code optimization.

The SCR is assigned to individuals or a team and the review is performed
on their own, not in a meeting format. The SCR results are presented at
the Test Readiness Review (TRR).

Test Readiness Review (TRR)

TRR Participants: IPT (Users, Developers, PAL, Programmers, IT
(OSDPD/IPD), OSD Satellite Product Management, OP Co-Chairs)

The TRR is a Development Phase interim review. Its purpose is to
determine whether code and test data development are sufficient to allow
definitive testing of the pre-operational algorithm. Upon successful
completion of the TRR, code testing and refinement commences.

The TRR should also determine if software concurs with standards and
security.

\- Unit \# 1 thru Unit \# X Readiness

\- Unit Validation results (Do inputs and outputs provide expected
results)

System Readiness Review (SRR)

SRR Participants: IPT (Users, Developers, PAL, Programmers, IT
(OSDPD/IPD), OSD Satellite Product Management, OP Co-Chairs)

The SSR is a review of the project operational readiness performed prior
to preparing an operational decision briefing for the SPSRB. Its purpose
is to determine whether the system and algorithm performance meets all
project requirements and to confirm completion of all required
documentation and archive plans for operations and maintenance. Users
should provide a statement of readiness to ingest and detail the
specific utilization of the product. Final validation results should be
presented. Monetary support should be identified for on-going
maintenance of systems by OSDPD and science by STAR.