PAT-071 - PDR - Preliminary Design Milestone Review Checklist

A) Design and Requirements Verification

1. Software Requirements: Verified Baseline established at the software level.
   

   Adequate documentation exists to allow proceeding with software implementation and software testing. All software requirements are verifiable. All Safety mission-critical software designs/requirements have been through a peer review. Peer reviews have required participation. TBD and TBR items are identified with acceptable plans and schedules for their disposition, and the software volatility metric is less than 20%. The % of TBD/TBC/TBRs in the software requirements document does not exceed 1% High software requirements quality risk score (software requirements quality score of 3 or higher).  Less than 3 is a risk, and fewer than 20% of the requirements have a high-risk or very high-risk score. Software requirements volatility is less than 20%. A sufficient number of detailed software requirements exist. The software requirement volatility metric is less than 30%. The detailed software requirements are agreed upon, finalized, stated clearly, and consistent with the preliminary design. The software requirements reflect and include the Software Fault Tree Analysis (FTA), or Software Failure Modes and Effects Analysis results

2. Software Design Description: Verified Preliminary detailed design meets software requirements with adequate margins.
   

   The software's preliminary design features and architecture are represented by software requirements. Adequate technical and programmatic margins (e.g., data throughput, memory) and resources exist to complete the software development within budget, schedule, and known risks. Relevant software operational modes and states are defined (e.g., nominal, critical, contingency). Software common cause addressed (if applicable). Software design addresses the software safety-critical requirements. Software design addresses unauthorized use of software applications, command issuing, memory changes, and data changes to the software configuration. Software design provides automatic detection and safing for critical and catastrophic hazards. Software fault management requirements, architecture, and design have been defined. The software design logically isolates the safety-critical design elements and data from non-safety-critical data. The Software command and telemetry design have been defined. Software error detections have been defined. Software design, architecture, components, and interfaces are defined and understood at the level needed for code development. Software design addresses the Software Fault Tree Analysis (FTA) or Software Failure Modes and Effects Analysis results. Cybersecurity has been addressed in the software design.

3. Bidirectional Traceability: Verified  Exists between software requirements and design modules.
4. Software Architecture: Verified Exists and interfaces are defined.
5. Preliminary Software Data Dictionary: Verified Exists and data is defined.  
6. Verified Completed IV&V Software Design Analysis 
7. Verified Completed the IV&V Software Requirements Analysis
8. Verified Completed Software Assurance Software Requirements Analysis
9. Verified Completed Software Assurance Software Design Analysis
10. IV&V concurs that the project’s software requirements and design are sufficiently mature to proceed to CDR. (If IV&V is required)

B) Risk and Hazard Analysis

1. Software Hazards: Verified Identified and addressed in System Hazard Analyses: include all known software hazards. 

2. Software Fault Tree Analysis (FTA): Verified Preliminary results available.

3. Safety and Mission Risks: Verified Understood and credibly assessed.

C) Compliance and Standards

1. NPR 7150.2 and NASA-STD-8739.8 Requirements: Verified Tailoring completed and approved.
2. Software Classifications and Safety-Criticality: Verified Updated as necessary.

D) Tools and Facilities

1. Software Development Tools: Verified Identified, including computers programming language, and facilities for implementation, .
   

   sufficient software analysis and development tools exist. the software development organization is trained in the use of the software language. Validated and accredited software tool(s) required to develop or maintain software exist. A defined approach to the automatic generation of software source code exists.

2. Software Development Facilities: Verified Planned and will be in place when needed.
3. Resource Utilization: Verified Estimates and margins provided.
4. Hardware resources Verified develop and test the software. The required Engineering test units, modeling, and simulations have been identified and planned

E) Quality Assurance and Process Audit

1. Software Process Audit Results: Verified Available.
2. Software Development Processes and practices by the organizations developing the critical software components exist and are being followed. 
   

   Evidence exists with Software process audit results. Evidence that the software development organization followed the required processes for this point in the software lifecycle.

3. Problem Reporting Process: Verified Acceptable and includes tracking and resolution.
   

   Change control is established (e.g., change tracking, review, approval, disapproval, change impact analysis, resolution, re-validation, and re-verification.)

F) Documentation and Metrics

1.  Interface Control Documents: Verified Sufficiently mature for Critical Design Review (CDR). Avionics architecture, components, and interfaces are defined and understood at the level needed to move to CDR
   

   The project has identified software quality attributes in the software architecture definition.

2. Software Metrics: Verified In use to track software quality and maturity.
   

   Software risks, issues, and findings are documented. The project has addressed all software assurance and Severity 1 or 2 findings. Verify that the project does not have a risk associated with developing software at the same time as the hardware is being designed, the risk of misunderstanding the software-hardware interfaces, and not having the hardware available to use in the software development. Software supply chain risks. Sufficient software workforce or software skillsets exist.

3. Software Configuration Management: Verified Processes and tools are in place.
4. Software Products in electronic format. Verified  that NASA has access to the software products in electronic format, including software development and management metrics.

G) Stakeholder and Organizational Readiness

1.  IV&V Concurrence: Verified Software requirements and design are mature for CDR.
2. Certifiable Practices: Verified Followed by organizations developing critical software components.
3. Software Assurance Personnel: Verified Identified for the project and milestone review.

H) Testing and Validation Plans

1. High-Level Test Plan: Verified Identifies testing needed at each level of implementation/integration.
2. Software Test Plans: Verified Developed and documented.
3. Prototype Software: Verified If applicable, developed and evaluated.

I) Reviews and Approvals

1. Peer Reviews: Verified Completed for software preliminary design and requirements.
2. Configuration Control Board: Verified Established and Change Control Process in place.
3. Lessons Learned: Verified Documented from software areas of the project.

J) Project Management and Cost Estimates

1. Software Trade Studies: Verified Completed.
2. Cost Estimate: Verified Provided for project’s software support.
3. Operational Concepts: Verified Defined and documented.

K) Old Business - Items from earlier reviews

1. RFAs and RIDs from the previous review have been Verified resolved, and any resulting actions are complete.