6.111 Fall 2004 Lecture 15, Slide 1Project Managementand ControlSlides by:John GuttagMichael ErnstMIT EECS©Michael Ernst/John Guttag6.111 Fall 2004 Lecture 15, Slide 2Documentation• Goal: reduce opportunity for misunderstandings• Do not rely on oral communication– Record decisions in writing• Not a waste to document things that may change– Provide target for criticism– Good way to find mistakes early• When a teammate finds a flaw in your design– Triumph for both of you– He/she found flaw– You explained things well6.111 Fall 2004 Lecture 15, Slide 3Documentation, cont.• Use version control system– For documentation as well as code• Keep change log– Date– Person– Reason– Summary• Verilog/circuit diagrams are most important documentation– Property of project• Not property of designer– Shared coding standard and design patterns help• Must be enforced by management6.111 Fall 2004 Lecture 15, Slide 4Team Organization• Most importantly, you need one• Two distinct considerations– How decisions get made (management structure)– How information flows (communication structure)• Have a plan for this• Two poles– Centralized• Needed for large projects– Decentralized• What I recommend for your project6.111 Fall 2004 Lecture 15, Slide 5Decentralized Organization• Key decisions made jointly– Requirements– High level design– Schedule– Who will work on what– Response to slippage• Lower level design exchanged for examination– Everyone responsible for everything– Design reviews tremendously helpful• Try it, you’ll like it• Do need a leader at all times– Chair meetings, provide agenda, make decisions– Leadership changes based on relevant expertise6.111 Fall 2004 Lecture 15, Slide 6• Keep in mind cost to fix defects110100100010000100000DesignProgrammingQAPost-deploymentSome Process Models, But First6.111 Fall 2004 Lecture 15, Slide 7• Keep in mind cost to fix defects0500010000150002000025000DesignProgrammingQAPost-deploymentSome Process Models, But First6.111 Fall 2004 Lecture 15, Slide 8The Waterfall Modelrequirements analysisdesignimplementationunit testingintegration testingacceptance testingproductioncomplaintslawsuits0500010000150002000025000DesignProgrammingQAPost-deployment6.111 Fall 2004 Lecture 15, Slide 9Waterfall Model• Works well when– The requirements are high quality and stable– The developers have previously built similar systems– The project is not very complex• When used in other situations– Lots of rework– High late stage costs– Because everyone gets it wrong the first time• Rarely right for most companies• Might be right for late stage development– E.g., customization6.111 Fall 2004 Lecture 15, Slide 10Modify until client is satisfiedBuild firstversionOperateHacking Model6.111 Fall 2004 Lecture 15, Slide 11Hacking Model Has Problems• No specification– Figure out specification as you design• Useful for– Small designs– Easily accessible client• If applied to something too complex– Lots of rework– High costs at a late stage6.111 Fall 2004 Lecture 15, Slide 12Characteristics of a Better Model• Reduces cost of late-stage problems– Adequacy of specification– Performance limitations• Rapidly builds necessary competencies– Use new knowledge to improve design• Focuses on reducing risk– Make (and discover) mistakes early• Look at one better model– Not the only reasonable model– Different situations call for different models6.111 Fall 2004 Lecture 15, Slide 13Prototyping/Incremental ModelAnalyzerequirementsDesignBuild realsystemincrementallyBuildprototypeCritiqueprototype6.111 Fall 2004 Lecture 15, Slide 14Prototype Phase• Not hacking– Carefully design prototypes– Discard prototypes rather than change-until-done• Quick and dirty?– Dirty is easy• Lots of wasted work?– Plan to throw one away, you will anyway– Much cheaper if mistakes discovered early6.111 Fall 2004 Lecture 15, Slide 15Some Uses of Prototypes• Sell project to management– Be careful what you wish for– “Managing up” is important• Understand requirements– Build a mock up, get feedback from users– Learn the customers needs– More than just the I/O pins• Understand design– Find “gotchas” early on• Understand building blocks– Hardware– Programming environment– Tool kits and libraries6.111 Fall 2004 Lecture 15, Slide 16Understand Building Blocks• May have specifications that are– Ambiguous– Incomplete or inaccurate– Unclear about preconditions– Unclear about performance• Trying building blocks out early in appropriate context– Informs design– Modularizes debugging process• Example– Analog checkoff in Lab 36.111 Fall 2004 Lecture 15, Slide 17Effective Prototyping• A prototype is built to answer questions– Know what questions you wish to answer– Write them down at the start• Use list to decide– What functionality to implement– What tests to run– When discard prototype• Keep a lab notebook– Record decisions and rationale– Treat as log• Don’t revise or throw out6.111 Fall 2004 Lecture 15, Slide 18Prototyping Pitfalls• Worthless prototype– Doesn’t answer right (or any) questions• Failure to discard prototype– Longer you wait, the harder it gets– Must have drop dead date for prototyping phase• Second system effect– Prototype makes problem seem easier than it is• Much of the work goes to last 10% of getting it right– Features get added or schedule compressed6.111 Fall 2004 Lecture 15, Slide 19Prototyping/Incremental ModelAnalyzerequirementsDesignBuild realsystemincrementallyBuildprototypeCritiqueprototype6.111 Fall 2004 Lecture 15, Slide 20Incremental Development Phase• Short cycles, weeks not years– Design Redesign– Implement Reimplement– Validate Revalidate– Assess risk Reassess risk– Consolidate & Optimize• Smallest steps representing visible progress– New behavior– Better performance– Reduced amount of code– Better platform for future development• Not same as prototyping phase– Not throw away code6.111 Fall 2004 Lecture 15, Slide 21Advantages of Incremental Model• Feedback– Easier to measure progress– Better documentation– Reality check• Leads to more modular designs– Piecewise validation easier– Changes easier• Better customer-vendor relationship– Less adversarial– Shared problem solving• Difficulty– Executives/customers must
View Full Document
Unlocking...