Software Life Cycle
Management of what to do in
what order
Software Life Cycle (Definition)
The sequence of activities that take place during software development.
Examples:
code development
quality assurance (QA)
changing client requirements
management intervention
redevelopment
QA again
etc.
Typical Life Cycle
(at the worst short-lived companies)
Software Development Management
Quality Assurance (QA)
Sales
Customer
(1. Imagines printer software.)
(2. Sells copy machine software.)
(3. Develops really cool walking/talking AI that will operate fax machines.)
(4. Unsure what code does, but tests for bugs and agrees product will properly toast bread.)
(5. Sues.)
Need Communication and Control
Model from one company where I worked.
(And the basis of many early “.coms”.)Developers
Management
QA
Sales Customer
requirements match code developed brainstorm
idea
developers tell
management about product
pass buck to sales
convince customers we have a good product
Problems?
Mostly works, but
1.
QA has no real feedback. By definition the code does what the developers say it will. Just minor bug control.
2.
Development does whatever they want (fun).
3.
Management only manages sales, not developers or QA.
4.
What if Development didn’t do a good job of
anticipating market needs? Are they business
majors?
Can You Suggest a Better Model?
Developers
Management
QA
Sales Customer
Try it…
Classic “Waterfall” Model
An idealized linear model in roughly 5 steps.
Analyze
Specify
Design
Build
Test
Waterfall Picture
Analyze
Specify
Design
Build
Test
Also called “throw-it-over-the-wall” model.
Waterfall Details
1. Analyze
(management, marketing, sometimes development)consult with client, or brainstorm use case diagrams
ensure useful
2. Specify
(development management, QA)set requirements document
communication between management and developers
break up into modules for each developer (sometimes
part of the Design stage)
Waterfall Details (cont.)
3. Design
(development, dev management, QA)functional specification document class diagram
sequence diagram (if necessary)
4. Build
(development)write code
ensure modularity, flexibility
ensure high cohesion, low connectivity
implementation document (when done)
use case scenarios for QA (for your detailed piece)
5. Test
(QA, development)ensure reliable
Design Stage Has Many Review Steps
Reviews facilitate communication between developers and developers’ boss (nail down expectations).
Functional Spec Review
This is the functionality I will code.
Parrot use case diagram in code-like terms.
Design Document Review
Here’s how I’ll really do this in detail.
Includes class diagram.
Implementation Document Review
Despite what I said, this is the way it really worked.
Includes class diagram.
Post-Mortem Review
This is what worked well or did not work well.
Lessons for next time.
Reviews go by many different names…
Other Stages Have Many Steps
But as software developers we are
primarily concerned with Design steps.
Take business courses for other stages.
Advantages of Waterfall Model
Easy to understand.
Easy to implement.
Commonly used.
Easy to modify.
Many government and big business contracts require you to use and document this
approach.
Problems With Waterfall Model
Many criticisms of the standard waterfall model, including
1.
Problems are not discovered until Test stage.
2.
Requirements must be completely specified before the software is designed - requirement changes make the model unstable.
3.
Design and coding often turn up requirements
inconsistencies, missing components, and unexpected development needs.
4.
System performance cannot be tested until the system is almost coded.
Linear and uni-directional. Can’t go backwards.
Alternative: Prototyping Model
A big failure of waterfall is that changes in requirements muck up everything.
Solution: build a prototype.
Or a quick mock up, or partial implementation…
Show it to the customer.
Revise requirements.
Repeat.
Prototyping Model Picture
Specify (Requirements)
Quick Design
Revise Requirements Build Prototype
Full Design Show Customer
satisfied not satisfied
the rest is the same…
1. Throw away prototype.
2. Re-usable prototype. Modularity a must!
Advantages, disadvantages?
Speed for prototype vs. speed for final product.
Time is money
Two Types of Prototypes
Problems With Prototype Model
When do you stop iterating?
picky customers are never satisfied.
Solution: Can set arbitrary time limits on each iteration.
1 week.
Difficult for big products.
The prototype can be too big a job.
Solution: Rapid throwaway. Quick and dirty
prototypes. Not re-useable.
Iterative Model
Standard operating system software approach.
1. Develop software and release to public.
2. Using customer’s experiences, improve, redesign, re-implement, re-release.
3. Iterate, and keep releasing with new and better functionality.
Modularity is essential! Why?
Iterative Model Picture
Analyze
Specify
Design
Build
Test Deliver
Sometimes also includes
the prototype model.
Iterative
Advantages/Disadvantages
Advantages
1.
incorporates the customer’s feedback naturally.
2.
changing requirements are incorporated at two levels.
1. prototyping
2. new releases
3.
generate excitement/buzz with limited beta release.
Disadvantages
annoy customer with poor releases.
Spiral Model
Developed by Boehm, 1988.
Iterative.
Rarely used exactly.
Frequently used to some extent.
Spiral Model Picture
increasing cost
1. Analyze risks
2. Specify requirements 3. Engineer:
Design Implement QA
4. Evaluate
commitment partition
Spiral Advantages
1. Works with any of the previous models.
2. Naturally incorporates changes in requirements.
3. Good model for handling risk.
Can do high risk in first loop (so bail early if necessary).
Lower risk items later.
Spiral Model Is Vague!
(Disadvantage)
Doesn’t indicate what the result of each loop should be.
A final product? (uncommon)
An increasingly refined product? (common)
Partial products, slowly integrated? (common)
Doesn’t indicate when to end.
Probably should happen in risk assessment.
So with inexperienced hands, costs can
blossom.
Object-Oriented Process
Just the above models with OO practices.
Heavier use of UML to guide the above models.
Attempt to reuse components.
OO Process and Reusability
VERY DIFFICULT. (true reusability hard to achieve)
Still maturing.
One idea:
1.
Identify potentially reusable classes/packages.
2.
Set these aside into a “possibly reusable library”
3.
When a new customer’s project is started, identify those classes in the library that might be reused.
4.
If they can be, then generalize/improve these classes so that they really are modular and reusable.
5.
Pass on the cost of generalization to the new customer
(who will see it as a cost savings because you don’t
have to develop from scratch!)
Many Other Life Cycle Models
Clean Room Process
Emphasis on defect prevention rather than correction.
Use mathematical proofs to show each part of the code is correct.
Invented by IBM.
Defect Prevention Process
whenever something doesn’t work, find the root cause and suggest an improvement to the life cycle process
