Lecture 2: Software Life cycle
25
LECTURE 2: SOFTWARE LIFE CYCLE
description
Lecture 2: Software Life cycle. Lazy. Contemplative. Always Using Imagination. Most Important Trait. Why Do Models Matter?. Client has 2 programmers with different styles. Bob. Joe. More about Bob & Joe…. Bob codes like Joe paid attention & like he did in college uses a proper model. - PowerPoint PPT Presentation
Transcript of Lecture 2: Software Life cycle
LECTURE 2:SOFTWARE LIFE CYCLE
Lazy
Contemplative
Always Using Imagination
Most Important Trait
Why Do Models Matter?
Client has 2 programmers with different styles
Bob Joe
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
Bob JoeWork (in
$)Rework (in
$)Work (in
$)Rework (in
$)20% $100,000 $0 $150,000 $0Total $100,00
0$0 $150,00
0$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
Bob JoeWork (in
$)Rework (in
$)Work (in
$)Rework (in
$)20% $100,000 $0 $150,000 $040% $100,000 $20,000 $100,000 $10,000Total $200,00
0$20,000 $250,00
0$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%Comple
teBob Joe
Work (in $)
Rework (in $)
Work (in $)
Rework (in $)
20% $100,000 $0 $150,000 $040% $100,000 $20,000 $100,000 $10,00060% $100,000 $20,000 $100,000 $10,000Total $300,00
0$40,000 $350,00
0$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%Comple
teBob Joe
Work (in $)
Rework (in $)
Work (in $)
Rework (in $)
20% $100,000 $0 $150,000 $040% $100,000 $20,000 $100,000 $10,00060% $100,000 $20,000 $100,000 $10,00080% $100,000 $20,000 $100,000 $10,000Total $400,00
0$60,000 $450,00
0$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
Bob JoeWork (in
$)Rework (in
$)Work (in
$)Rework (in
$)20% $100,000 $0 $150,000 $040% $100,000 $20,000 $100,000 $10,00060% $100,000 $20,000 $100,000 $10,00080% $100,000 $20,000 $100,000 $10,000
100% $150,000 $20,000 $50,000 $10,000Total $550,00
0$80,000 $500,00
0$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 bothNeither 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 IterativeWaterfall Model Is Iterative
Waterfall Model Is IterativeWaterfall 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 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
