What is difference between the Draft Design Document and the Software Description Document required after the CDR is approved?
The Software Description Document would characterize “what” the software is intended to perform while the Draft Design Document would specify ”how” it will actually be fulfilled. It’s important to remember the purpose of both the PDR and CDR, especially the traceability between both major reviews.
Open full Question Details
The Preliminary Design Review (PDR) is a technical assessment that establishes the Allocated Baseline of a system to ensure a system is operationally effective. As you probably know, it’s conducted before the start of detailed design work and is the first opportunity for the Government to closely observe the Contractor’s hardware and software design. This review assesses the allocated design documented in subsystem product specifications for each configuration item in the system and ensures that each function, in the Functional Baseline, has been allocated to one or more system configuration items. The PDR establishes the allocated baseline (hardware, software, human/support systems) and underlying architectures to ensure that the system under review has a reasonable expectation of satisfying the requirements within the currently allocated budget and schedule.
For software Critical Design Reviews (CDR), the primary purpose of the software CSCI CDR is to determine if the completed detailed design meets the specified requirements established in the pertinent developmental baseline (functional/performance) specification, and that the design is complete and ready to be implemented (i.e., coded and unit tested). The Software Requirements Specifications (SRSs) should be reviewed for changes and traceability to the completed detailed design. Impact of changes in requirements should be analyzed for impact to the detailed software design. Where necessary, software requirements should be reallocated and designs adjusted to be consistent and complete. Analysis should include internal and external interfaces. The verification requirements and procedures should be analyzed for consistency and completeness. Software CSCI designs should be analyzed for consistency with the CS&S design architecture and interfaces with other elements of the system design. Where incremental development is being used, the CSCI design should be reviewed for completeness and consistency for each increment scheduled to be completed. Design allocations between and among the planned increments should be analyzed and reviewed, closely.
The main exit criteria of the software CDR confirms that:
· Detail level software CSCI designs are established and reviewed, and are determined to be complete and ready
· The software CSCI requirements, as specified in the contractor developmental baseline specifications, are satisfied by the detailed design description.
· Software CSCI test descriptions are complete.
· Draft software CSCI test procedures are complete.
· Detailed software CSCI design and interface descriptions are complete.
· Software CSCI development progress metrics are updated to reflect current development and design status.
· Software CSCI development files are established and maintained current.
· Software CSCI development estimates are updated as part of the balance and control process, and CS&S risks (including those related to cost, schedule, and performance) have been identified and mitigation plans have been developed