2.009 Product engineering processes!"iteration is the autobahn to improvementSafety!your product, yourself, your team"inherent part of a product’s design. Not an add on !(like product architecture, usability, product form)""stop if you are too tired, stressed, distracted, feeling unwell, or have skipped meals""ask if you are unsure…""if you see something you are uneasy about…""winners of the contest: safety at work...5th place4th place3rd place2nd placeand the winner…A look ahead!upcoming items"user feedback tutorial 4-5 PM today, 1-150"costing tutorial 7 PM tonight, Pappalardo south conference, 2 people per team!"evening lab hours for this week are posted on website"35-307 available for off hours work, signup starting tonight"notebooks are submitted this week""ID consultations Thursday 6-10 PM. Team area. 30 minute sessions—see schedule on website""consulting class on Wednesday"Success factors!not a homework exercise"capacity"time"100%"sketch"mockup"technical"public"Homework"For real"2.009 Product engineering processes!today!"technical review pointers"debugging a systematic approach to the art"Alpha prototype!definition"the ‘first’ design model that:"functions like the manufactured product"looks and feels like the manufactured product"made of materials similar to manufactured product"is manufactured differently than product"Alpha prototype!the “first” complete prototype: looks right, works right"your first version of the alpha prototype will not work well!"technical review is November 17""typically, teams redesign and rebuild before final !(you must get close enough to know what the issues are)""""Technical review!how to think about it?!"all show, no tell"be prepared to let reviewers use the prototype!Technical review in 14 days…!examples"work in parallel"keep meetings short"communicate"design, don’t hack"ask"enjoy product eng."Technical review!intent"demonstrate/test functional alpha prototype and discuss remaining areas for improvement "!assess operation of the product in relation to the product contract""assess the prototype from many viewpoints and prioritize areas for improvement"Technical review!focus"operation""meets contract""ease of use""robustness""quality of experience (sounds good, feels good)""safety"details""mechanical design""interface/human factors""form and aesthetics""electronics design""system integration""assembly and manufacturability""prototype execution"Design for manual assembly!mini quiz from last Monday"list 4 design-for-manual-assembly guidelines""enjoy the process, lose some sleep, order some pizza”: Brendan Chin"Design for manual assembly!mini quiz from last Monday"list 4 design-for-manual-assembly guidelines"and now…!a design-for-assembly quiz"analyze the platen lift assembly and answer the questions on the handout""no talking or sharing answers""read the instructions, but don’t look at assembly !(on back) until instructed""get as much done as you can in 7 minutes""Debugging!a systematic approach"if it is not tested!it does not work"Debugging"testing plan:"have one, and document it"design testing plan as you design the system/subsystem specs."test incrementally"work with a buddy"ask if you have concerns"""Debugging"seeing:!expect the unexpected"Debugging process!(fault diagnostics)"wishing will not make a fault go away ""symptoms that mysteriously disappear are not problems solved""debugging requires careful systematic thinking, tackling probable causes in a strategic order""goal: a 5 step process to follow when trying to diagnose and fix a problem"Debugging!step 1"when something goes wrong …"stop, observe, and think"document the circumstances"how was the device being used leading to the failure?"who observed the problem?"had something been changed?"describe the environmental circumstances"describe the faulty behavior !What, When, Where, How big?"form a clear symptom statement (object—defect form)""Debugging!example symptom statement"object—defect"Good"the product made a popping sound, emitted a flash of light and smoke"Bad"the product shorted out""Debugging!step 2"identify and recruit the people needed to solve the problem"who are the best people to tackle the problem? Are you the right person? System integrators should be able to help in this process""provide your detailed notes and symptom statement to the individual or task force that will address the problem (team site)""don’t be afraid to think about it"Debugging!step 3"carefully review data and develop an interim plan"are the initial data sufficient to localize the problem? !If no, gather more information (often through careful exploration and observation) "is a new drawing/diagram needed? "is their too much clutter to observe the problem?""can the problem be isolated or provisions be made so that other team members can continue to work?!"what else needs to happen? ""Debugging!step 4"define and verify possible causes"develop hypotheses about what is causing the problem""carefully evaluate each hypothesis against the existing data. Eliminate improbable causes""prioritize remaining probable cause hypotheses, trading off ease of verification with confidence in hypothesis""systematically test each hypothesis by isolating its probable cause and performing appropriate experiments or measurements"Debugging!step 4"remember""there may be more than one cause behind the defect!"Debugging!step 5"once the cause has been identified…"generate ideas for permanent correction of the problem""select most promising solution and, if appropriate, perform simple sketch model or mockup level tests to verify that it will work""implement the solution""carefully verify that the solution has eliminated the fault. !Be sure that tests emulate the initial failure conditions"Debugging!step 6"inform team members that the fault has been corrected, summarizing the fault (object—defect), the cause(s), and the