1. Fall 2006 1 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Senior Design Lecture 4 Definition phase Design phase

2. Fall 2006 2 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Product development cycle Define Design Prototype Evaluation Production Milestones/ Approvals Product Approval Design Release Prototype Release Beta Release Product Release Documents Functional Specifications Project Plan Debug & Evaluation Plan Theory of Operations Qualification Report Not in class Manufacturing Report EOL Final Report

3. Fall 2006 3 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering PDC diagram Illustrates process vs. time Funnel shape: team’s understanding (focus) increases over time Five distinct phases –Transitions actually iterative –Each phase Documented Specific entry/exit milestones & criteria

4. Fall 2006 4 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Why do we have … Milestones –Keep on track –Show progress –Illustrate accomplishments Documents –Future reference –Refine your thoughts –CYA

5. Fall 2006 5 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Definition phase Define Design Prototype Evaluation Production Milestones/ Approvals Product Approval Documents Functional Specifications

6. Fall 2006 6 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Definition phase overview Purpose –Starts product development –Estimate return on investment (ROI) Document –Functional Specifications –Describes what the product is Milestone –Product Approval (corporate OK)

7. Fall 2006 7 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering How are specifications used? BOD/Officers: track progress, bottom line Engineering: design Manufacturing: what to build Marketing: features to sell Support: foresee errors Sales: selling to customers Finance: budget

8. Fall 2006 8 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Functional specifications Typical issues –Feature creep: adding capabilities once design started, avoid “like the plague” –Poorly defined, incomplete, or incompatible features Recommendation: be as specific as possible (often very difficult), as soon as possible

9. Fall 2006 9 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Product approval Purpose –Freeze (change control) product features –Resources (staffing, funds) applied to product Process –Hold an approval meeting: team, advisor, industry rep –Review (page-by-page) the Functional Specifications

10. Fall 2006 10 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Document revision Rev. 0.9 Rev. 0.95 Rev. 1.0 Rev. 1.x Team submits to advisor for review Team modifies document per advisor, sends Rev. 0.95 to industry rep Team modifies document per approval meeting, change control in effect Team modifies document per CCB approval

11. Fall 2006 11 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Change control Once a document is at Rev. 1.0 it is subject to change control Motivation: avoid feature creep, communicate changes Process –Request submitted to Change Control Board –Approvals require document changes and new revision number (1.1, 1.2, …)

12. Fall 2006 12 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Design phase Define Design Prototype Evaluation Production Milestones/ Approvals Design Release Documents Project Plan

13. Fall 2006 13 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Design phase overview Purpose: develop a technical solution that meets the requirements Document –Project Plan –Describes your methodology (schedule) Milestone –Design Release –Freezes design concept

14. Fall 2006 14 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Why have a project plan? Team knows what's going on Budget your time Detect/correct a problem Supervisor knows what you’re doing

15. Fall 2006 15 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Project plan Typical issues –Poorly defined, incomplete, or incompatible schedule or dependencies –Incorrect assumptions, under estimating risks –Not understanding the technology Recommendation: be as specific about the schedule as possible, develop contingencies (as you will need them)

16. Fall 2006 16 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Design release Purpose –Finalize design concept and/or data base –Start detailed implementation Process –Hold an approval meeting: team, advisor, industry rep –Demonstrate that your solution is feasible and solves the problem

17. Fall 2006 17 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering

18. Fall 2006 18 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Why do we have … Milestones To monitor progress, adjust the schedule as necessary Documents To facilitate communications

19. Fall 2006 19 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering How are specifications used? BOD/Officers: profit Engineers: know what to design Mfg: special equipment, processes tuning, data Marketing: advanced sales, long cycles Service: spares, contracts, training Finance: forecast revenue/profit Sales: collateral, trade shows

20. Fall 2006 20 CS-EE 480 Lillevik 480f06-l4 University of Portland School of Engineering Why a project plan? Determine what has to be done, by when, and by who (schedule) State assumptions, identify dependencies Set the budget Evaluate risks, develop contingency plans