Lazy

Contemplative

Always Using Imagination

Most Important Trait

Why Do Models Matter?  Client has 2 programmers with different styles BobJoe

More about Bob & Joe… Bob codes like Joe paid attention & like he did in college uses a proper model

Starting the Project  Both look at notes from project executive  Bob then writes test cases & starts coding  Joe determines client’s needs in meetings %Complete BobJoe Work (in $)Rework (in $)Work (in $)Rework (in $) 20%$100,000$0$150,000$0 Total$100,000$0$150,000$0

Project Getting Going  Bob duplicates code, but with minor tweaks  Slows progress & requires expensive reworking  Design minimizing code created by Joe  Client’s requirements examined; bugs found & fixed %Complete BobJoe Work (in $)Rework (in $)Work (in $)Rework (in $) 20%$100,000$0$150,000$0 40%$100,000$20,000$100,000$10,000 Total$200,000$20,000$250,000$10,000

Passing the Halfway Point  Bob works from scratch & does not reuse code  Lacks plan to incorporate existing code  Joe uses design to write comments & outlines  Finds majority of errors during this process  When possible, merges classes & simplifies design %Complete BobJoe Work (in $)Rework (in $)Work (in $)Rework (in $) 20%$100,000$0$150,000$0 40%$100,000$20,000$100,000$10,000 60%$100,000$20,000$100,000$10,000 Total$300,000$40,000$350,000$20,000

Project Nearing Completion  Bob’s code is project-specific & cannot be reused  Getting concerned as project starts falling behind  Joe writes test cases from his system design %Complete BobJoe Work (in $)Rework (in $)Work (in $)Rework (in $) 20%$100,000$0$150,000$0 40%$100,000$20,000$100,000$10,000 60%$100,000$20,000$100,000$10,000 80%$100,000$20,000$100,000$10,000 Total$400,000$60,000$450,000$30,000

Final Rush to the Deadline  Bob cannot describe system to get extra help  Completing system takes lots of all-nighters  Joe’s coding is easy with well-defined tests  Code could be written by (cheap) trained monkeys Bob Joe

Final Rush to the Deadline  Bob cannot describe system to get extra help  Completing system takes lots of all-nighters  Joe’s coding is easy with well-defined tests  Code could be written by (cheap) trained monkeys Bob Joe Joe’s Team

Final Accounting %Complete BobJoe Work (in $)Rework (in $)Work (in $)Rework (in $) 20%$100,000$0$150,000$0 40%$100,000$20,000$100,000$10,000 60%$100,000$20,000$100,000$10,000 80%$100,000$20,000$100,000$10, %$150,000$20,000$50,000$10,000 Total$550,000$80,000$500,000$40,000

What’s The End Result?  Bob barely finishes  Most goals are met  Occasionally crashes  Close to original goal  Joe is tanned & rested  Met stated goals  Reliable & robust  Follows design perfectly

What’s The End Result?  Bob barely finishes  Most goals are met  Occasionally crashes  Close to original goal  Joe is tanned & rested  Meets all needs  Reliable & robust  Exactly follows design Client fires them both Neither met requirements

Models Matter  Client valued original concept above all else  Joe and Bob both forgot about this main point  Joe gets better chair in unemployment line  To survive, life cycle models must succeed  Nobody records failures or the merely adequate  But common saying is “There is no silver bullet”  One shared weakness no matter your choices  Need to keep your focus on requirements  Keep in mind when being lazy

Classroom Development  Always start from scratch  Know all requirements from the start  And requirements will not change  Coding begins immediately at start  Projects are trivial jokes in real-world  If lasts 3 weeks, projects “very large”  Code cannot be reused  Never look at again, anyway

Why These Phases Matter

Waterfall Model  Shows steps project goes through  Can compress, but steps never skipped  Assumes steps not revisited once done  Each step ends with some result  Evidence process followed correctly  Begin by testing results of previous

Moving Target Problem  During development, requirements may change  Changes may be important, but…  …disrupts flow & introduces dependencies  Regression faults occur without good testing  Error (“fault”) usually in unrelated portion of project  Major pain to fix  As changes continue, faults will build up  Redesign & reimplementation ultimately needed  Change is inevitable  Your plans must handle gracefully

Waterfall Model Is Iterative

Heck of a job, Brownie.

Incremental Development  Waterfall improved by working incrementally  Focus on most important piece at the moment  Follow waterfall model to develop that piece  Focus on new most important piece once complete stepwise refinement  Method also called stepwise refinement  Best of both worlds is incremental methods goal  Amount of duplicative work minimized  Improved reaction to change using smaller chunks  But handling changes requires good design & plans

For Next Lecture  Reading for Monday available on Angel  Will be discussing software requirements  What are they?  How do we figure them out?  Can they be discussed in our teams?  Weekly activity problem #2 due at start of class  Discussed at start of lecture, just like today  Available on weekly assignment page