bannerd

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt
hiddentrue

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

Panel
borderColorgreen
titlePAT-071 - PDR - Preliminary Design Milestone Review Checklist

Image RemovedImage Added

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

Panel
borderColorgreen
titlePAT-071 - PDR - Preliminary Design Milestone Review Checklist

Image Removed

Image Removed

Image Removed

Image Removed

Image Added

Show If
spacePermissionedit
Panel
borderColorgreen
titlePAT detail displays only if you have "edit" permission.

Live Template
templatepat
typetemplate

Updates needed:

Related Pages

Children Display

Show If
spacePermissionedit
Panel
borderColorred
titleVisible to editors only
Expand
titlePDR Raw Content

PAT-071 - PDR - Preliminary Design Milestone Review Checklist

A) Design and Requirements Verification

  1. Software RequirementsVerified Baseline established at the software level.
    Expand
    titleSuccess Criteria Details
    • 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 DescriptionVerified Preliminary detailed design meets software requirements with adequate margins.
    Expand
    titleSuccess Criteria Details
    • 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 TraceabilityVerified  Exists between software requirements and design modules.
  4. Software ArchitectureVerified Exists and interfaces are defined.
  5. Preliminary Software Data DictionaryVerified 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 HazardsVerified Identified and addressed in System Hazard Analyses: include all known software hazards. 

Expand
titleSuccess Criteria Details
  • The software hazards are clearly defined.
  • Traceability between software requirements and hazards is complete.
  • Hazard controls are defined.
  • Hazard verifications are defined.
  • All software requirements that trace to a hazard analysis are to be verified by test.
  • Software hazards address the software Failure Modes and Effects Analysis (FEMAs) and software Fault Tree results.

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

3. Safety and Mission RisksVerified Understood and credibly assessed.

C) Compliance and Standards

  1. NPR 7150.2 and NASA-STD-8739.8 RequirementsVerified Tailoring completed and approved.
  2. Software Classifications and Safety-CriticalityVerified Updated as necessary.

D) Tools and Facilities

  1. Software Development ToolsVerified Identified, including computers programming language, and facilities for implementation, .
    Expand
    titleSuccess Criteria Details
    • 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 FacilitiesVerified Planned and will be in place when needed.
  3. Resource UtilizationVerified 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 ResultsVerified Available.
  2. Software Development Processes and practices by the organizations developing the critical software components exist and are being followed. 
    Expand
    titleSuccess Criteria Details
    • 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 ProcessVerified Acceptable and includes tracking and resolution.
    Expand
    titleSuccess Criteria Details
    • 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 DocumentsVerified Sufficiently mature for Critical Design Review (CDR). Avionics architecture, components, and interfaces are defined and understood at the level needed to move to CDR
    Expand
    titleSuccess Criteria Details
    • The project has identified software quality attributes in the software architecture definition.
  2. Software MetricsVerified In use to track software quality and maturity.
    Expand
    titleSuccess Criteria Details
    • 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 ManagementVerified Processes and tools are in place.
  4. Software Products in electronic formatVerified  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 ConcurrenceVerified Software requirements and design are mature for CDR.
  2. Certifiable PracticesVerified Followed by organizations developing critical software components.
  3. Software Assurance PersonnelVerified Identified for the project and milestone review.

H) Testing and Validation Plans

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

I) Reviews and Approvals

  1. Peer ReviewsVerified Completed for software preliminary design and requirements.
  2. Configuration Control BoardVerified Established and Change Control Process in place.
  3. Lessons LearnedVerified Documented from software areas of the project.

J) Project Management and Cost Estimates

  1. Software Trade StudiesVerified Completed.
  2. Cost EstimateVerified Provided for project’s software support.
  3. Operational ConceptsVerified 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.