Scribd
Upload
189 views3 pages

Preliminary Design Review (PDR)

The Preliminary Design Review (PDR) establishes the system baseline and architecture to ensure the design can meet requirements. It assesses the allocated design and subsystem specifications to allow detailed design. A successful PDR provides the baseline, updated risk assessment, cost analysis, schedule, and sustainment plan. It also resolves design conflicts and determines if requirements and preliminary design support proceeding to detailed design.

Uploaded by

Ngọc Nguyễn Vũ Bích
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
189 views3 pages

Preliminary Design Review (PDR)

The Preliminary Design Review (PDR) establishes the system baseline and architecture to ensure the design can meet requirements. It assesses the allocated design and subsystem specifications to allow detailed design. A successful PDR provides the baseline, updated risk assessment, cost analysis, schedule, and sustainment plan. It also resolves design conflicts and determines if requirements and preliminary design support proceeding to detailed design.

Uploaded by

Ngọc Nguyễn Vũ Bích
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Preliminary Design Review (PDR)

The Preliminary Design Review (PDR) is a multi-disciplined technical review


for the candidate design(s) to establish 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 of the CDD within the currently allocated budget and schedule.

This review assesses the allocated design captured in subsystem product


specifications for each configuration item (hardware and software) in the
system and ensures that each function in the functional baseline has been
allocated to one or more system configuration items.

Subsystem specifications for hardware and software, along with associated


ICDs, enable detailed design or procurement of subsystems. Configuration
items may consist of hardware and software elements, and include items
such as structures, avionics/electronics, weapons, crew systems, engines,
trainers/training, etc.

Completion of the PDR should provide the following:

An established system allocated baseline,


An updated risk assessment for Engineering and Manufacturing
Development (EMD),
An updated Cost Analysis Requirements Description (CARD) or
CARD‐like document based on the system allocated baseline,
An updated program schedule including system and software critical
path drivers, and
An approved Life Cycle Sustainment Plan updating program
sustainment development efforts and schedules.

It is important to clarify and resolve design conflicts before completing the


Systems level PDR and entering detailed design. For complex systems, a
PDR may be conducted incrementally for each configuration item. These
incremental or subsystem reviews ultimately lead to an overall system level
PDR. They should be substantially completed before the systems-level PDR
is held.

The PDR evaluates the set of subsystem requirements to determine whether


they correctly and completely implement all system requirements allocated
to the subsystem. The PDR also determines whether subsystem
requirements trace with the system design. At this review, the IPT should
review the results of peer reviews of requirements and preliminary design
documentation.
A successful PDR is predicated on determination that the subsystem
requirements, subsystem preliminary design, results of peer reviews, and
plans for development, testing and evaluation form a satisfactory basis for
proceeding into detailed design and test procedure development.

Typical PDR success criteria include affirmative answers to the following exit
questions:

Does the status of the technical effort and design indicate operational
test and evaluation success (operationally effective and suitable)?
Can the preliminary design, as disclosed, satisfy the draft Capability
Development Document?
Has the system allocated baseline been established and documented
to enable detailed design to proceed with proper configuration
management?
Are adequate processes and metrics in place for the program to
succeed?
Have sustainment and human systems integration design factors been
reviewed and included, where needed, in the overall system design?
Are the risks known and manageable for integrated testing and
developmental and operational evaluation?
Is the program schedule executable (technical/cost risks)?
Is the program properly staffed?
Have the program„s cost estimate been updated?
Is the program executable within the existing budget and with the
approved system allocated baseline?
Is the preliminary system level design producible within the production
budget?
Is the updated CARD consistent with the approved allocated baseline?

With the additional emphasis on software development and the critical role it
plays in providing system functionality, the following exit questions should
also be addressed for the system‟s software component:

Has the Computer system and software architecture design been


established, and have all Computer Software Configuration Items
(CSCIs), Computer Software Components (CSCs), and Computer
Software Units (CSUs) been defined?
Are Software Requirements Specifications (SRSs) and Interface
Requirement Specifications (IRSs), including verification plans,
complete and baselines for all CSCs and do they satisfy the
system/subsystem functional requirements?
Do the Interface Control Documents (ICDs) trace all software interface
requirements to the CSCIs and CSUs?
Has the computer system and software design/development approach
been confirmed through analyses, demonstrations, and prototyping in
a relevant environment?
Has the preliminary software design been defined and documented?
Have software increments been defined and have capabilities been
allocated to specific increments?
Have software trade studies addressing COTS, reuse, and other
software‐related issues been completed?
Has the software development process been defined in a baselined
Software Development Plan (SDP) and is if reflected in the Integrated
Master Plan (IMP) and Integrated Master Schedule (IMS)?
Do the software development schedules reflect contractor software
processes and IMP/IMS software events for current and future
development phases?
Have the software development environment and test/integration labs
been established with sufficient fidelity and capacity?
Have unique software risks have been identified and assessed and
have mitigation plans been developed and implemented?
Have software metrics been defined and reporting process
implemented, and are they being actively tracked and assessed?
Does the Test and Evaluation Master Plan (TEMP) address all CSCI
plans, test facilities, and test plans, including testing required to
support incremental approaches (e.g. regression tests)?
Is there a life‐cycle sustainment plan and does it include software
support requirements?
Have the software development estimates (i.e. size, effort (cost), and
schedule) been updated?
Have all required software‐related documents been baselined and
delivered?

The PDR should be conducted when the allocated baseline has been
achieved, allowing detailed design of hardware and software CIs to proceed.
A rule of thumb is that 10 percent to 25 percent of product drawings and
associated instructions should be complete, and that 100 percent of all
safety‐critical component (Critical Safety Items and Critical Application
Items) drawings are complete.

The PDR should be conducted when all major design issues have been
resolved and work can begin on detailed design. The PDR should address
and resolve critical, system‐wide issues before detailed design begins.

The PDR risk assessment checklist is designed as a technical review


preparation tool, and should be used as the primary guide for assessing risk
during the review. This checklist is available via the “Checklist for Technical
Reviews” in the Reference Tab of this course

You might also like