Project Name System Critical Design Review

Transcription

1 Insert project logo Project Name System Critical Design Review Class Number Title Date Location This Critical Design Review assumes that the design team will be following a formalized design process. This design process is assumed to follow the following major steps: 1 Formulation 2 Conceptual Design 3 Configuration Design 4 Detailed Design The Critical Design Review builds on the content found in the Preliminary Design Review, updates the information found in the Design Formulation, Conceptual Design, and Configuration Design phases for information learned since then, and summarizes the design development from the Detailed Design phase. For all of the pages that are repeats of the Preliminary Design Review, ensure that all of the information, diagrams, and requirements track to the current design state. Revise the information as needed. On this slide, you will need to enter the project name, class number (e.g. EE 498 Capstone Design I), date, and location. It is also recommended that the project develop an interesting logo and attach it here as well. The logo can also be carried on the subsequent slides as well. 1

2 Topics Project Overview System Overview System Element 1 System Element 2 System Element 3 Management Overview Supplemental Slides Date Project PDR 2 This is the suggested content and order of presentation for the review. Sponsor may request a different order or additional topics. Modify as required. Be sure to go to the Headers/Footers tool and update the Date and Project name in the footer. The System Element 1, 2, and 3 sections are place holders for the actual number of system elements in the design. The same general format is used in each section description. The actual number of system elements will depend upon the nature of the system design. 2

3 Project Overview Project Mission Statement One paragraph statement of the overall goal (general attributes) of the project. This is a highlevel summary statement (few specific details). Project Technology Demonstration What are the key technologies to be demonstrated in the project Project Objectives List objectives (specific attributes) to define the mission statement. These are lower-level and more specific than the Mission Statement. Date Project PDR 3 The Mission Statement is the problem statement from the Formulation stage of the design. The Technology Demonstration section is an optional listing of interesting technologies that the project may be attempting. Basically this is the first of several marketing sections to highlight interesting features of the design. The Project Objectives section is to expand on the mission statement. Again, this is to better explain the project to others. Note: If needed, expand this page out to multiple pages so that the print does not become too small. 3

4 Project Overview Project Success Criteria What will be the minimum set of testable outcomes to declare the project a success Relevance to Sponsor What are the reasons that the sponsor should support the project (what will it do for the sponsor?) Date Project PDR 4 The Success Criteria should be tied to the system integration and test plan. These criteria are the ones that represent a buy-off on a successful completion of the design. The Relevance to the Sponsor section is marketing back to the sponsor to tell the sponsor why this project fulfills a critical need for that sponsor. 4

5 Project Overview Project-level Requirements Project success and other programmatic criteria turned into a set of specific, testable statements. If programmatic criteria come from a specification document that must be met, reference the document. List these requirements in a table. ID P1 Requirement Testable project-level requirement Source MS Date Project PDR 5 These are the system-level requirements developed in the system design Formulation stage. These requirements should also be in the first section of the Requirements Verification matrix. Generally, the project-level (total system level) requirements will track to the overall mission statement. 5

6 System Overview System Block Diagram/Graphic Itemize the major system elements and a brief statement of their function Date Project PDR 6 This slide begins the Conceptual Design for the entire system. The block diagram is intended to be the Conceptual Design Diagram from the conceptual design phase of the design process. This diagram will show the major system elements that will be refined further via the more detailed design stages. The Conceptual Design should show the major system information flow and power distribution, as necessary. The list of major system elements and functions will be summary statements. We will expand these more later in the presentation. 6

7 System Overview Graphic to illustrate system operational phases Date Project PDR 7 This is intended to be a graphical summary of the system operations concept. It should be more than just On/Off. It should show major operational phases and/or timing. 7

8 Project System Element Risk Assessment System Element 1 System Element 2 System Element N Overall Program Assessment Performance Schedule Cost Safety Testing Manpower Facilities Overall System Element Assessment Y G G R NA G = low risk Y = medium risk R = high risk NA = N/A Date Project PDR 8 Assess the risk status of the overall project based on the assessment made of each of the system elements. Take the system element columns from the last column of the matching chart for the system element summary. Use the Red/Yellow/Green color coding: Green no issues with this portion of the design; all relevant technologies are known, components/software tested; everything works as it should. Yellow there are design issues still to be resolved, parts may not yet be fully tested so there are unknowns, etc. There are issues that can be identified as posing a problem but nothing that is believed to be ready to cause a major setback. Red many unknowns in the design of hardware or software that could prevent proper operation or completion of the project; parts with long lead times or critical operating conditions may be considered to be red until they are in hand or the operations are fully understood. Generally, the project-level risk to completion should be the worst case risk of any of its system elements for a given category. 8

9 System Element 1 RISK R System Element Description For each major system element, give a detailed description of the main function it is to perform. System Element Success Criteria For each major system element, give a detailed listing of success criteria Date Project PDR 9 This is the beginning of the Conceptual Design description for the first major system element. Additional system elements in the overall system design will follow this same format with appropriate modifications. The system description section is really the Problem Statement from the Formulation step of the design process for this system element. Similarly, the system element success criteria should relate back to the system element test plan. Assess the risk to completion for this system element. 9

10 System Element 1 System Element Requirements Testable requirements tied to project-level requirements for the 1 st system element ID S1-j Requirement Testable project-level requirement Source Px Date Project PDR 10 These are the system element requirements developed in the Formulation phase of the design for this system element. These requirements should also appear as the first ones in the System Element section of the Requirements Verification matrix. Most of these requirements should track to project-level requirements. However, they may also track to the missionlevel (project-level) requirements as well. 10

11 System Element 1 Subsystem Listing For each major system element, list the subsystems to comprise that system element. Use WBS numbering to identify them. Include a block diagram showing the relative relationship between the subsystems and any signals that can be defined Graphic capturing the Conceptual Design Diagram for the system element Date Project PDR 11 This is to capture the functional decomposition for the system element that was developed during the Conceptual Design for the system element. The graphic should be the Conceptual Design Diagram from the Conceptual Design phase for this system element. For clarity, this diagram can be move to a full page. 11

12 System Element 1 RISK R Subsystem block diagram/graphic Subsystem Definition Describe the function(s) to be performed by the i th subsystem of system element 1 Describe any operational phases or timings relevant to the subsystem Subsystem I/O (power and/or signals) Date Project PDR 12 This is the description for each of the subsystems identified in the Functional Decomposition in this system element. For each subsystem, indicate it s current risk status. Repeat this slide for each of the subsystems in this system element. 12

13 System Element 1 Subsystem Requirements Testable requirements tied to system element requirements for the i th subsystem of system element 1 ID S1.i-j Requirement Testable project-level requirement Source S.1-x Date Project PDR 13 These are the subsystem element requirements developed in the Formulation phase of the design for this subsystem belonging to the system element. These requirements should also appear as the second level ones in the System Element section of the Requirements Verification matrix. Most of these requirements should track to system element-level requirements. However, they may also track to the mission-level (project-level) requirements as well. 13

14 System Element 1 Insert a graphic showing the Part Configuration for this subsystem. Date Project PDR 14 This is the Part Configuration diagram from the Configuration Design phase. Be sure to include interfaces, information, power, and control signal flow in some manner. This should be updated from the PDR slides. 14

15 System Element 1 Insert the data from the Parametric Design. Date Project PDR 15 These are the design variables from the Parametric Design in the Configuration Design phase. This is probably best entered as a spreadsheet. This should be updated from the PDR slides. 15

16 System Element 1 Detailed schematics/drawings/flow charts, etc. Date Project PDR 16 This shows the actual configuration drawing to move to subsystem build. 16

17 System Element 1 Support Analysis/Data Power needs (nominal, worst case) Mass budget, form factor restrictions Thermal considerations/mitigation Safety factors (vibration, mass, wire gauge, fasteners, etc.) Regulatory issues (code specifications, regulatory specifications, etc.) that must be met; status of any relevant applications, licenses, or reviews Date Project PDR 17 This is all of the major analysis to back up selections made in the parametric design table. This may extend to several pages, depending upon the state and complexity of the design. This should be updated from the PDR slides. 17

18 System Element 1 Hardware/software status If any hardware/software has been developed to test design concepts, show results here Indicate any potential design delays (long lead items, etc.) here. Date Project PDR 18 Optional slide to cover actual hardware/software status if known at this time. If there is a specific reason why a design element is still high risk, this would be the place to explain the status. 18

19 System Element Subsystem Risk Assessment Subsystem 1 Subsystem 2 Subsystem N Overall System Element Assessment Performance Schedule Cost Safety Y G G R Testing Manpower Facilities Overall Subsystem Assessment NA G = low risk Y = medium risk R = high risk NA = N/A Date Project PDR 19 Assess the risk status for this system element. Use the same red/yellow/green criteria as before. Copy the last column results to the appropriate column in the program-level table. 19

20 Management Overview Organizational Chart WBS Schedule I&T Summary Budget Detailed Risk Assessment and Mitigation Date Project PDR 20 These are the main management issues at this point in the design process. If the sponsor requires others, add them as needed. 20

21 Organizational Chart Show an organizational chart with lines of reporting for team members. Also indicate advisors/helpers Date Project PDR 21 Enter an organizational chart for the whole project. 21

22 WBS WBS Project Work breakdown Structure Date Project PDR 22 Develop a system Work Breakdown Structure (WBS) for the system. 22

23 Schedule Schedule Show expected time line for the project (can be done as a Gantt chart) Use the WBS from the preceding slide Date Project PDR 23 This is the high-level project schedule as best can be determined at this point. Typically a Gantt chart is used. A similar chart in a spreadsheet can also be used. It should be organized via WBS. 23

24 I & T Summary I&T Overview Describe the approach to how I&T will be accomplished I&T Flow Describe the flow of the I&T from unit level to final acceptance testing Date Project PDR 24 At this point, the integration and test concepts should be being developed. How will all of the system elements be integrated and tested? 24

25 Budget Budget Personnel and resources budget for developing the project Date Project PDR 25 There are several budgets important in the design: 1 financial 2 personnel 3 required resources. These can be done as a series of spreadsheets with one per page. 25

26 Detailed Risk Assessment and Mitigation Risk Element Element or subsystem that has major risk potential Description Describe the risk and other systems/subsystems that could be impacted Proposed Mitigation How will the risk be minimized and/or contained by the design Date Project PDR 26 For the big risk items, how will that risk be mitigated? 26

27 Documentation The following documents are suggested to be ready at the time of the Critical Design Review: Finalized Parts List and Materials List. Finalized Operations Concept Document Finalized Interface Control Document Finalized Integration and Test Plan Finalized budgets: power, mass, size, communications links, etc. Finalized Requirements Matrix and Requirements Document Date Project PDR 27 27