Software lifecycle models

Today, I read chapter 7 of "Rapid development" by Steve McConnell. I found out it was really a good survey of this topic. Before my memory fades, record some points here.

1. Water fall model
Documents driven, need stable product definition, and well-understood technical methodologies.
Pro:

• Tackling complexity in an orderly way;
• Extremely good for non-experiened staff for minimizing wasted effort;
• Works well when quality requirements dominate cost and schedule requirements;
• Minimize planning overhead

Con:

• Difficulty of fully specifing requirements at the beginning of the project;
• Not flexible;
• The result isn't visible until the end.

2. Code and fix

Pro:

• No overhead;
• Require little expertise

Con:

• Dangerous;
• Only can be applied for small internal tools.

3. Spiral

It starts from a small scale project with low risk,

1. determine the objectives and alternatives,
2. explore the risks, make a plan to handle the risk,
3. develop the deliverables for this iteration, verify they are correct,
4. plan and commit to an approach for the next iteration.

Pro:

• Rish driven method;
• More invest, less risk;
• Provide as at least much management control as waterfall model.

Con:

• Complicated;
• Need knowledgeable management;
• Difficult to define the objectives and the milestones indicating ready for the next iteration.

4. Modified Waterfalls

Allow the phases of waterfall model to overlap so as to reduce the overhead of waterfall model.

2 types:

1. Sashimi model: allow overlapping
2. Subproject model: do the easy part first, and difficult part later by dividing the system into several small subjects.

Cons:

• Miletones for each phase become ambiguous since the overlapping;
• Miscommunication and inefficiency;
• Unforeseen interdependencies

5. Waterfall with risk reduction

Put a risk reduction spiral in a section of waterfall lifecycle, for eample requirement and architecture design.

6. Evolutionary Prototyping

Develop system concept as you move through the project. Start from implement the most visible aspects of the system, show it to the user, continue to develp the prototype based on the feedback.

con:

• You don't know when the project can be finished in order to create an acceptable product;
• An easy execuse to do code-and-fix development.

7. Staged delivery

Know exactly what you want to achieve at the beginning of each stage, and deliver the product for each. For each stage, we can follow whatever model fits it the best(waterfall, modified waterfall, etc).

Pro:

• Put the useful functions to user as early as possible;
• Provide tangible progress at each stage;

Con:

• Need careful planning;
• Need to handle interdependencies.

8. Design to schedule

similar with stage delivery. The difference is that you don't necessarily know at the outset that you'll ever make it to the last release. It is useful for products to release by a particular date.

Set the priorites for each subproject, for each stage, implement and test the high priority ones first, then the lower priority. Release the ready product and add on new functions later.

• Need skills for planning;
• Waste time for planning on those features won't be shipped in the end.

9. Evolutionary delivery

A model straddles the ground between evolutionary prototyping and staged delivery. Under staged delivery, after system architect design, use prototyping method instead of staging.

10. Design to Tools

Only implement the functions supported by the available libraries and components, leave out the ones without.

• May lose some functions;
• Dependent on 3rd party lib;
• Vendor stability.

11. Commercial off-the-shelf software

How to select the best lifecycle model?

Ask questions:

1. How well do you understand the problem and requirement?
2. How well do you understand the system architecture?
3. How much reliability do you need?
4. How risky the product may entail?
5. Large growth envelope(volatile demands)?
6. Do you have a defined schedule?
7. Overhead?
8. Allow for midcourse corrections?
9. Provide users with progress visibility?
10. Provide management with progress visibility?
11. Require little management/developer sophistication?