INSE - Lecture 6a

Prototyping

Or: “Not building a Leaning Tower…”

Validation is needed

Having written a specification...

- irrespective of whether it is in English or some formal notation -

how do we ensure the specification matches the user requirements?

One method is prototyping

Differences between a prototype and “the real thing”

The prototype must be available very early so that lessons learnt from it can be fed back into the Requirements, Specification and Design documents.

This means we take whatever short-cuts are needed: e.g. – incomplete having only key facilities;– on the wrong machine;– too slow;– too big– ...

Typically We build an approximation to the doubtful

parts of the desired system; if needed we simulate any special hardware

or peripherals; we have users try it to see what they mis-

understand, mis-use, say is wrong, like/dislike, …

Often it changes the user’ perception of what they need.

Variations

a mock-up; a hand-built cut-down of “the real

thing”; using some sort of “prototype-maker”

– maybe from a formal spec, or– maybe in logic programming or other

special language.

Postscript on Prototyping No matter how a prototype is made prototypes are thought to save far more

than they cost. And if you don’t prototype intentionally,

your chances of fundamental error are so high that a good motto is

“build one to throw away (because you will, anyhow)”

INSE - Lecture 6b

Estimating

Estimates...

… are almost always needed - usually in 2 forms

-- £££

-- man-years

“Man-years” often helps to

-- estimate the £££;

-- decide realistic deadlines;

-- decide what resources are likely to be needed.

Issues that arise... Milestones for keeping track of “whether the project is on schedule”;

Brookes Law; estimates

– often are wildly wrong; and– usually are under-estimates.

[But they are now usually much better than in the early days.]

Milestones Estimate the whole cost as the sum of

(pessimistic) estimates of the costs of parts; then decide the final deadline and total

number of people; then derive a target deadline for each part of

the project. Each deadline-for-a-part is then a milestone; project progress can be checked by seeing

whether milestones are reached by the expected deadlines.

Brookes Law

“Adding manpower to a late software project will make it even later.”

New people joining mid-project– need to do a lot of learning before they can

achieve anything;– waste the established people’s time by asking

questions on everything not yet documented;– will make mistakes when they do start achieving;– will never be fully committed to the project.

Avoiding Brookes’ Law

GET THE ESTIMATES RIGHT!

When Brookes’ Law comes into action

limit later damage by having the new people write the missing documentation

Why do estmates go wrong?

Reasons include we tend to estimate for the bits we like,

omitting the bits we don’t like; getting the program out before the

competition get theirs out– therefore hurry– therefore haste– therefore less speed.

Why estimates go wrong… continued

Middle management do the estimates– not done technical work for years;– therefore out of touch.

Middle management will want to please higher management– therefore err on the low side.

The producers won’t be emotionally committed to the deadlines, so won’t try as hard.

Why estimates go wrong… continued

Ultimately, it will be guessing, supported by experience.

Most of these are reasons for the estimates to be low.

After this lecture

from here out, consider prototyping for any non-trivial or non-obvious programs or parts of programs you build;

keep records of how much time you spend on building programs, web-pages, writing up notes; after a while start using that information to begin predicting...