1. Prototyping Strategies

2. Overview
Prototyping is a well understood and used technique in engineering where novel products are tested by testing a model prototype
prototypes can be “throw away” (e.g., scale models) or go into commercial use (Concorde!)
In software development prototypes can be
paper-based
software-based

3. Aims of Prototyping in Software
The aim of prototyping is to resolve uncertainty about
functional requirements
operation sequences
user support needs
required representations
“Look and Feel” of the interface

4. Prototyping Techniques
The three major kinds of prototyping are
“Throw away” prototyping (a.k.a. “rapid prototyping”)
used exclusively in requirements gathering
Incremental prototyping
not actually prototyping at all, but the delivery of prioritised functions incrementally to a single, overall design
Evolutionary prototyping (a.k.a “Rapid Application Development, RAD)
as for incremental prototyping but with evolving design

5. Other (Lesser) Kinds of Prototyping
Full prototype
full functionality, lower performance than production software
Horizontal prototype
displays “breadth” of functionality, no “back end” support
Vertical prototype
full functionality and performance of a “slice” of a system
High Fidelity prototyping
prototyping through alternative media, e.g. video

6. Other (Lesser) Kinds of Prototyping (continued)
Low fidelity prototyping
lesser, cheaper materials
Chauffeured prototyping
user observed “driving” the system
Wizard of Oz prototyping
as chauffeured, but with the observer unobserved!
Requirements Animation

7. Paper-based Prototyping
Paper-based prototyping is useful only for “throw away” schemes (obviously!). Can include
Holistic Design
role-playing; e,g., CRC cards in OO development
Sketching and Metaphor
visual brainstorming, screen design, icons etc.,

8. Paper-based Prototyping (continued)
Scenarios
e.g. Use Cases in OO development
Storyboards and Snapshots
using “film-scripting” techniques to visualise interactions between users and the system

9. Software Prototypes A software prototype is “executable”
will not have a generalised lifetime
can be thrown away, or evolve
may serve many different purposes
should be “quick and dirty” (and cheap!)
is an integral part of user-centred design approaches based on evaluation/modification

10. Software prototyping tools
Facades and Requirements Animators
e.g., Demo II
interfaces demonstrated through “slide shows”
useful only for throw away prototyping
Screen generators
e.g., Protogen
GUIs built rapidly by “screen-painting” then hooked into application code
RAD tools
e.g., Visual Basic, Delphi
can be used for building full apps.

11. RAD tools
Rapid Application Development (RAD) tools are being used generically for prototyping
i.e., even when only facading is required
Can lead to confusion about what kind of prototype is being built
heightened, unrealistic user expectations
lower Quality Assurance
It is therefore important to be able to evaluate tools, and establish a proper prototyping process

12. Visual Basic and Delphi
VB (Microsoft) and Delphi (Borland) are both RAD tools for MS-Windows applications
Both enable user to “paint” screens by drag-and-drop operations on predefined GUI elements (widgets)
scrollbars, menus, buttons, list boxes, dialo boxes etc.
Both allow user-customisation of widget properties
colour, size, text, formatting etc.

13. Event-driven Programming
VB and Delphi give close support to event-driven programming
where app. is idle until its behaviour is triggered by a user-initiated “event”
Each predefined widget has a skeleton body of methods (procedures) to support events
e.g., LeftMouseButtonDown( )
user supplies implementation code
Screens can be animated prior to coding specific application behaviour

14. Event-Driven Programming (contin.)
Development procedure is essentially
1. Paint the screen with widgets (actually called Controls)
2. Customise their attributes via a Properties Form
3. Supply implementations of their event procedures
write code “on back” of Controls
4. Write “back-end” code in separate modules

15. Visual Basic versus Delphi
Both support “reusable” Controls
VB is “object-based”
reuse of “back-end” code is difficult
VB code is a form of BASIC - a pre-”structured” language
encourages hardwiring of Controls to event code
VB is an interpreted environment
25x slower than a fully compiled environment

16. Visual Basic versus Delphi
Delphi is object-oriented
“back-end” objects can be resused and customised via inheritance (an OO feature)
Delphi code is Object Pascal
fully-fledged OO language also used in the Macintosh Apple’s operating system
Delphi code is compiled
faster

17. Implications VB is good for Delphi is good for
“throw away” prototyping, facading, requirements animation
screen generation
can be hooked into C++ or J++ code
Delphi is good for
incremental prototyping
RAD