1. INSE - Lecture 6a Prototyping

2. Or: “ Not building a Leaning Tower …”

3. 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

4. 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 –...

5. 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.

6. 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.

7. 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) ”

8. INSE - Lecture 6b Estimating

9. 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.

10. 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.]

11. 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.

12. 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.

16. Avoiding Brookes ’ Law GET THE ESTIMATES RIGHT!

17. When Brookes ’ Law comes into action  limit later damage by having the new people write the missing documentation

18. 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.

19. 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.

20. Why estimates go wrong … continued  Ultimately, it will be guessing, supported by experience.  Most of these are reasons for the estimates to be low.

21. 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...