Possible incorporation of Prototyping in the Conventional Approach to Systems Development

1. Possible incorporation of Prototyping in the Conventional Approach to Systems Development economic social operational technical FEASIBILITY STUDY interviewing observations questionnaires record sampling REQUIREMENTS ANALYSIS working methods user requirements current system problems SYSTEMS ANALYSIS SYSTEMS SPECIFICATION inputs outputs processes files security prototype design prototype development prototype testing prototype amendment writing progs testing training installation changeover IMPLEMENTATION system meets requirements? new requirements? continue to function? MAINTENANCE REVIEW

2. PROTOTYPING Prototyping is a technique for building a quick and rough version of a desired system or parts of that system An approximation of a type that exhibits the essential features of the final version of that type Rapid Application Development by James Martin Avison & Fitzgerald p 76 PROTOTYPE An original or model, after which anything is formed The first thing, or being, of its kind A pattern, exemplar, or archetype Websters 20th Century Dictionary The main objectives of using prototypes is: • Get an idea of what the system will offer • Provide feedback on whether the system is what is required

3. PROTOTYPING Prototyping helps to identify misunderstandings between users & software developers this may help detection of missing (not yet specified) user requirements James Martin suggests a prototype is most useful when: where the functions and detailed design of a system are not yet fully understood and can be used to explore and solidify the functions and design For this purpose, it is far more effective that reviewing paper specifications “a prototype is worth ten thousand words”

4. PROTOTYPING For this purpose, it is far more effective that reviewing paper specifications It is also fundamentally different from a paper description: a prototype is: • real • manipulatable • can be adjusted • can be modified users get a feel for what their system will be like. Its flaws are visible and tangible rather than buried in boring text In the RAD lifecycle the expressed intention is: that the prototype must be part of the evolving system i.e. NOT disposed of, but worked on throughout

5. PROTOTYPING Martin suggests, that in particular: prototyping ought to be used in the development of all interactive systems It is worth noting that: when a prototype is reviewed seriously by end users, they almost always change something Prototyping does much to solve the problem of inadequate communication between the designers and users

6. PROTOTYPING prototype suggests an analogy with engineering, where prototyping is used extensively There are, however, fundamental differences between the prototyping of software and the prototyping of machines In engineering, a machine prototype usually takes longer to build and is more expensive than the ultimate product a mass-production line may be used the prototype is needed for pre-testing the product IN SOFTWARE THERE IS NO MANUFACTURING PRODUCTION LINE

7. PROTOTYPING Prototyping is practical only if the prototype can be built quickly and cheaply Therefore, a software prototype is usually an incomplete or simplified version that has the essential functions of the working system but not the scale or performance James Martin asserts that: there are many pitfalls in prototyping to avoid these, it is essential to incorporate prototyping in the development lifecycle where the procedural structures will aid avoidance of those pitfalls

8. PROTOTYPING JAD sessions can make very good use of prototypes. The discussions become more tangible between developers and users when their interaction is bridged by use of a prototype It can also be used in the Requirements Planning Phase partial prototypes can help in checking the desirability of a system before committing funds

9. PROTOTYPING Prototyping is particularly valuable in the following situations: • There is scope for user creativity to improve the system • Users are unsure of exactly what they want • The system changes a basic business operation • An end-user dialogue should be tried out with the users to see if it can be improved • The users do not understand all the impacts of the new system • The functions are subtle, and the users understand them better than the analysts • Screens and reports should be checked with management to see if they can be made more useful or easy to use • The users have difficulty expressing all the system requirements • The prototype may act as a catalyst to elicit alternative ideas • The relative merits of alternative solutions need to be explored • Experimentation may be done to achieve better business practice

10. PROTOTYPING Prototyping should never be an excuse for casual work in which structured design is abandoned always first build something simple This starts a debate early in the evolution that may flush out misconceptions The initial prototype is successively enhanced With complex systems it is desirable to build the functionality first then polish the human factoring

11. PROTOTYPING When the prototype is regarded as complete, there may still be much work to do in building the operational system A list of missing features should be made: • Features for recovery from failures • Features for fallback • Security features • Features of auditability • Features for ease of maintenance • Machine efficiency • Facilities for having multiple users • Facilities for high-volume usage with adequate response times

12. PROTOTYPING A list of missing features should be made: • Larger database facilities • Networking facilities • Operation on a different machine • Documentation A danger of prototyping is that the users, motivated to be excited about the prototype, acquire unfulfillable expectations The advantage is that the prototype can be used to train users so they will be ready when the real system arrives

13. PROTOTYPING Benefits of Prototyping: • Users understand and react to prototypes far better than to paper specifications. Often, they fail to understand or miss important points in paper specs • Often it is quicker to build a prototype than to build paper specifications • Prototyping introduces early reality testing into a project. The users can see what is being built for them and critique it • Without, there is a substantial risk of building an inadequate system, wrong features or, at worst, a system the users will reject • It encourages users to contribute creative input into design process • When using or reviewing a prototype, users tend to be unbiased by existing systems

14. PROTOTYPING Benefits Prototyping: • Prototyping enables errors and weaknesses to be caught before expensive design and programming are done • Prototypes, or partial prototypes, are of great help in JAD sessions • Prototypes can generate excitement and improve morale of the users and developers • Prototypes are valuable for communicating what is required to programmers • Prototypes provide users with early experience with the system and may be used as training tools • Prototyping can give fast development by having the prototype evolve into the final system

15. PROTOTYPING Dangers of Prototyping: • Quick, casual design may replace well-structured design • The prototype encourages the users to change their minds about requirements. They many continually invent requirements so that the prototype constantly changes and does not converge quickly to an implementable form • The users’ expectations may become too high. The may think they can have the system immediately • There is a temptation to make the prototype the production system, without adequate consideration of security, auditability, fallback, recovery, maintainability, performance, networking or documentation • The user may take the prototype too literally, when the implemented system will be different • The user may be too casual about the prototype and not take the time to identify its flaws