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

Fall 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

Fall 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

Fall 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

Fall 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

Fall 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)

Fall 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

Fall 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

Fall 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

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

Fall 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, …)

Fall 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

Fall 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

Fall 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

Fall 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)

Fall 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

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

Fall 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

Fall 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

Fall 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