1 Project Name System Final Review Class Number – Title Date Location Insert project logo This Final 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 Final Review builds on the content found in the Critical Design Review , updates the information found in the Design Formulation, Conceptual Design, Configuration Design, and Detailed Design phases for information learned since then, and summarizes any final design development from the final I&T phase. For all of the pages that are repeats of the Critical 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.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Project NameSystem Final Review
Class Number – TitleDate
Location
Insert project logo
This Final 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 – Formulation2 – Conceptual Design3 – Configuration Design4 – Detailed DesignThe Final Review builds on the content found in the Critical Design Review , updates the information found in the Design Formulation, Conceptual Design, Configuration Design, and Detailed Design phases for information learned since then, and summarizes any final design development from the final I&T phase. For all of the pages that are repeats of the Critical 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.
2
Date Project Final Review 2
Topics
• Project Overview• System Overview • System Element 1• System Element 2• System Element 3• Management Overview• Supplemental Slides
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.
3
Date Project Final Review 3
Project Overview
• Project Mission Statement– One paragraph statement of the overall goal
(general attributes) of the project. This is a high-level 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.
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.
4
Date Project Final Review 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?)
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.
5
Date Project Final Review 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.
MSTestable project-level requirement
P1
SourceRequirementID
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.
6
Date Project Final Review 6
System Overview
• Itemize the major system elements and a brief statement of their function
System Block Diagram/Graphic
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.
7
Date Project Final Review 7
System Overview
Graphic to illustrate system operational phases
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.
8
Date Project Final Review 8
G = low risk Y = medium risk R = high risk NA = N/A
Facilities
NAOverall System Element Assessment
Manpower
Testing
RSafety
GCost
GSchedule
YPerformanceO
verall Program
Assessm
ent
System
Elem
ent N
………………
System
Elem
ent 2S
ystem
Element 1
Project System Element Risk Assessment
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.
9
Date Project Final Review 9
System Element 1
• 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
RISK
R
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.
10
Date Project Final Review 10
System Element 1
• System Element Requirements– Testable requirements tied to project-level
requirements for the 1st system element
PxTestable project-level requirementS1-j
SourceRequirementID
These are the system element requirements developed in the Formulationphase 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 mission-level (project-level) requirements as well.
11
Date Project Final Review 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
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.
12
Date Project Final Review 12
System Element 1
• Subsystem Definition– Describe the function(s)
to be performed by the ithsubsystem of system element 1
– Describe any operational phases or timings relevant to the subsystem
– Subsystem I/O (power and/or signals)
Subsystem block diagram/graphic
RISK
R
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.
13
Date Project Final Review 13
System Element 1
• Subsystem Requirements– Testable requirements tied to system element
requirements for the ith subsystem of system element 1
S.1-xTestable project-level requirement
S1.i-j
SourceRequirementID
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.
14
Date Project Final Review 14
System Element 1
Insert a graphic showing the Part Configuration for this subsystem.
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.
15
Date Project Final Review 15
System Element 1
Insert the data from the Parametric Design.
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.
16
Date Project Final Review 16
System Element 1Detailed schematics/drawings/flow charts, etc.
This shows the actual configuration drawing to move to subsystem “build.”
17
Date Project Final Review 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
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.
18
Date Project Final Review 18
System Element 1
• Hardware/software Test & Integration 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.
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.
19
Date Project Final Review 19
G = low risk Y = medium risk R = high risk NA = N/A
Facilities
NAOverall Subsystem Assessment
Manpower
Testing
RSafety
GCost
GSchedule
YPerformance
Overall
System
Elem
ent Assessm
ent
Subsystem N
………………
Subsystem 2
Subsystem 1
System Element Subsystem Risk Assessment
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.
20
Date Project Final Review 20
Management Overview
• Organizational Chart• WBS• Schedule• Budget
These are the main management issues at this point in the design process. If the sponsor requires others, add them as needed.
21
Date Project Final Review 21
Organizational Chart
Show an organizational chart with lines of reporting for team members. Also indicate advisors/helpers
Enter an organizational chart for the whole project.
22
Date Project Final Review 22
WBS
• WBS– Project Work breakdown Structure
Develop a system Work Breakdown Structure (WBS) for the system.
23
Date Project Final Review 23
Schedule
• Schedule– Show expected time line for the project
(can be done as a Gantt chart)– Use the WBS from the preceding slide
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.
24
Date Project Final Review 24
Budget
• Budget– Personnel and resources budget for
developing the project
There are several budgets important in the design:1 – financial2 – personnel3 – required resources.These can be done as a series of spreadsheets with one per page.
25
Date Project Final Review 25
Documentation
• The following documents are suggested to be ready at the time of the Critical Design Review:– Final test results to show that all
requirements have been successfully met– Any final changes to previous documents– Final design notebook showing all
supporting analysis and alternatives considered.
Related Documents
