Design Reviews

1
Design Reviews

• J. Burge
• OPTI 422/522

2
Types of reviews

• Peer reviews
• Informal and frequent
• Usually only attended by teammates
• with engineering databooks, not view graphs
• These cover particular details
• Products action items, technical memos
• Internal reviews, e.g. Internal Preliminary
  Design Review
• Semi-formal
• without the customer
• Coordinate different parts of the program
• Prepare for formal reviews
• Formal reviews, e.g. Preliminary Design Review
• More formal part of program plan
• with the customer
• Also frequently has outside reviewers smart
  people who may know nothing about the project.
• Products RFA, successful pass allows the project
  to continue.

3
Typical reviews
SRR System Requirements Review SCR System
Concept Review PDR Preliminary Design
Review CDR Critical Design Review PRR
Production Readiness Review TRR Test Readiness
Review
4
Purposes of Reviews

• Obvious purpose
• External review can find problems A little
  humility now can save you from untold pain later
• Contractual reasons
• Provides clean milestone for incremental funding
• Less obvious values of reviews
• Formal reviews impose discipline on a project
• Reviews define milestones holds schedule
  together
• Reviews force good systems engineering
  presentations will clearly define for subsystems
  
• requirements, functional design, analysis,
  verification, risks
• Forces you to chase down loose ends
• Preparing for reviews high energy and
  productivity
• Reviews provides opportunity for all involved to
  see the complete system

5
Products of reviews

• Review package publication (overheads support
  stuff) distributed before the review
• Discussion must be captured in minutes, action
  items, or RFA forms (Request for Action)
• Also, these reviews usually build relationships-
• Between technical people from customer and
  contractor
• Within teams (you work like crazy closely with
  others)
• Establish confidence from high level people in
  customers organization
• A Pass score is often needed for more money,
  next phase of the project

6
PDR

• Examines
• system requirements
• preliminary design
• function allocation
• verification tools
• Work Breakdown Structure
• Full-scale engineering design begins after this
  review.

(Prof. T. Bahill UA)
7
Results from PDR

• confirm that
• the design implements all the system functions
• the system requirements are completely defined
  with
• balance across cost, schedule, performance and
  risk
• consistency to Test Evaluation results
• allocated baselines for subsystems
• sufficient design has been accomplished to verify
  the completeness and achievability of the defined
  requirements
• the risk handling approach is reasonable
• critical accomplishments, success criteria, and
  metrics encourage continued technical effort

(Prof. T. Bahill UA)
8
CDR

• Examines
• system design in full detail
• resolution of technical problems
• technical performance measures
• manufacturing plan
• interface control documents
• Ensures that the design maturity justifies the
  decision to commence manufacturing and coding.

(Prof. T. Bahill UA)
9
Results from CDR

• confirm that
• the design is balanced across cost, schedule,
  performance and risk for the life cycle
• the system physical architecture is an integrated
  detailed design that will satisfy requirements,
  including interoperability and interfaces
• allocated baselines for subsystems are refined
• detailed plans are ready to be built
• test plan will verify all aspects of system
  performance

(from Prof. T. Bahill UA)
10
Design Reviews for 422

• Somewhere between a CDR and a PDR
• Plan 30 min presentation, 20 min discussion
• Post Design Review material on the web
• Invite faculty sponsor anybody else
• Make reference to other documents. Have them
  available at your design review
• Technical memos
• Test Plan
• Bill of Materials
• Drawings
• Collect and track RFA forms
• Follow this up with Technical Data Package
• Same basic info as design review, but in report
  format. Plan to update this at the end of the
  term as your final report.

11
Suggestion for 422 Design Reviews

• Introduction
• - top level description of system
• - introduce team
• - include top level schedule
• Requirements
• key requirements
• functional decomposition
• Design Overview
• Identify subsystems and how everything fits
  together
• Show how subsystems map onto functions
• drawings/flow diagrams are very helpful here
• use this to establish terminology
• Subsystems - design
• Hardware
• show/describe
• include trade studies performed for each
  subsystem (summary of results or open trades)
• show analysis performed and results (prove that
  it will meet requirements)

12
422 Design reviews, cont

• Subsystems (cont.)
• Software
• define modules
• brief description of algorithms (perhaps
  visually)
• estimate of lines of code for each module
• Interfaces physical, logical data structures,
  data flow diagram
• Risk Analysis summary of risk plan, identify
  important risk items
• Fabrication plan
• Overview of plans to build the system
• Make reference to Bill of Materials, drawings,
• Alignment plan
• Test plan
• - How will you prove that it meets requirements

13
Considerations,

• Before the review
• Prepare a clear statement of purpose
• Invite tough reviewers and challenge them to find
  faults
• Prepare a good review package
• Deliver it early
• Tell a clear story
• Educate your customer
• During the review
• Defend your design
• Expose your weaknesses
• Be willing to see the value in a different
  approach
• After the review
• Follow up on action items
• Respond quickly
• Document the results

(from D. Beshore, Raytheon)
14
Successful reviews,

• A good review produces criticism
• Get the chaos out early
• A good metric is how many valid items are
  identified
• There is value to having the customer as an
  active participant in the review. It gives the
  customer confidence that you
• understand the requirements
• have the design well under way
• understand customer expectations for the product
• To do this, you must have a meaningful set of
  internal reviews first, and they must produce
  honest criticism

(from D. Beshore, Raytheon)