Life-cycle Models

Look at stages
- e.g. design... maintenance

'Model' in the sense of 'to be imitated' ... 'exemplary'...

We will look at:

Build and Fix


code it
while client not satisfied
    fix it
wend

Only suitable for small systems.

Widely-known/used.


Analogy

    stage 1

        stage 2

            stage 3


                etc ...

Output of one stage flows down to next stage.

Note: common misconception - the model does acknowledge the need for an upwards flow, where stages need re-doing.

(e.g between design and implementation, where implementation might show the need for a modified design.)

Fig 3.2 in notes:


req's
verify

    spec
    verify

        design ... implem ..  test  ...  operation

At each stage, there is some form of verification/ test.

To repeat: problems found in coding are allowed to influence design (resulting in amended documentation.)

Benefits:

Drawbacks:

We create a subset, a scaled-down model.

When we create it, we need to be clear about what we are doing:

starting to code the final product?
learning how a language or system works?
mocking-up a cut-down version to show the client? - getting comments? - which stage of the cycle? Specification!

There are several approaches to using prototyping in the life of a product.

or 'throwaway' prototyping. Sole purpose of proto is to help determine the spec. e.g by showing proto to client.


fig 3.3
prototype
verify

    spec
    verify

        ...etc

less modification of spec will be needed.

The throwaway prototype:

Refine the prototype until it becomes the final product.

Danger: build and fix?



start...     risk...stage        risk...stage...         ... product

precede each stage with risk analysis, which may involve prototyping.

E.g. Prior to coding: