31
ISDE Prototyping JTB Oc t 2000 1 ISDE ISDE Prototyping Preece Chapter 27

ISDE Prototyping JTB Oct 20001 ISDE Prototyping Preece Chapter 27

  • View
    231

  • Download
    0

Embed Size (px)

Citation preview

ISDE Prototyping JTB Oct 2000 1

ISDEISDE

Prototyping

Preece Chapter 27

ISDE Prototyping JTB Oct 2000 2

Objectives of LectureObjectives of Lecture

Overview of PrototypingWhat is prototypingAims of prototypingPrototyping techniquesPrototyping tools

ISDE Prototyping JTB Oct 2000 3

OverviewOverview

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

ISDE Prototyping JTB Oct 2000 4

What is Prototyping?What is Prototyping?

Essential element in user centred design Is an experimental and partial design Involves users in testing design ideas Typically done very early in the design process Can be used throughout the SDLC Different types of prototyping are appropriate for different

stages of design– Product conceptualization – requirements – task match

user acceptance

ISDE Prototyping JTB Oct 2000 5

Aims of Prototyping in Aims of Prototyping in SoftwareSoftware

The aim of prototyping is to resolve uncertainty about

functional and user requirements operation sequences user support needs required representations “Look and Feel” of the interface appropriateness of the design

ISDE Prototyping JTB Oct 2000 6

General Features of PrototypingGeneral Features of Prototyping

Enables the designer to quickly build or create examples of :-

The data entry form The menu structure and order The dialogue styles Error messages

Should be inexpensive to develop – intention is to discard/modify it

Should not require programming skills

ISDE Prototyping JTB Oct 2000 7

Prototyping (cont)Prototyping (cont)

Traditionally users lack the ability to envisage designs conceptually

Alternatively their may be a conceptual mismatch between the designer and the user

This may not manifest itself until very late Users often lack the ability to imagine the ramifications of

design decisions Users are often unable to comment on technical design

documents A prototype provides users with a concrete representation

of the proposed design

ISDE Prototyping JTB Oct 2000 8

Prototyping Prototyping

Users are therefore more able to :- Confirm change or elaborate upon the specification

Software prototyping is a dynamic simulation It should reflect the users real task with

appropriate task scenarios Input a customer order given on the telephone

This will provide information on task sequence operations and any difficulties which the user may experience

ISDE Prototyping JTB Oct 2000 9

Paper Based PrototypingPaper Based Prototyping

Paper based prototypes These have no functionality but can still be useful for:-

– Generating ideas– Gaining insights into what the user might want or is thinking Eg a

paper based design of a data entry screen

Storyboards and Snapshots– using “film-scripting” techniques to visualise

interactions between users and the system This is very quick and cheap

ISDE Prototyping JTB Oct 2000 10

Software PrototypingSoftware Prototyping

A software prototype will be a version of the proposed system with limited functionality

Will differ from the final system in terms of Size, reliability robustness & completeness

A software prototype is “executable” 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

ISDE Prototyping JTB Oct 2000 11

Prototyping TechniquesPrototyping 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

ISDE Prototyping JTB Oct 2000 12

Rapid PrototypingRapid Prototyping

Aims to collect information on requirements and the adequacy of possible designs

Recognises that requirements are likely to be inaccurate when first specified

The emphasis is on evaluating the design before discarding it

ISDE Prototyping JTB Oct 2000 13

Rapid Prototyping -AdvantagesRapid Prototyping -Advantages

Helps the designer to evaluate the design very early in the the design cycle

It is good for addressing the problem of users not knowing or being unable to state their requirements

Provides the opportunity for continued evaluation and refinement of the design

Increases the chance of getting a well designed system acceptable to the users with the required functionality and ease of use

ISDE Prototyping JTB Oct 2000 14

Rapid Prototyping – DisadvantagesRapid Prototyping – Disadvantages

Can consume a lot of resources – users analysts programmers. Therefore can be costly as well as time consuming

The continued process of design evaluate redesign may mean that the design phase of the cycle is considerably increased

May be a long time before get a working system Reluctance to ‘throw away’ or discard the prototype Users expectations/wishes may be unrealistic

– May not be technically or economically feasible

ISDE Prototyping JTB Oct 2000 15

Incremental PrototypingIncremental Prototyping

Final product is built as separate components one at a time There is one overall design for the system It is partitioned into independent and smaller components Final product is released as a series of products

– Eg General student details data module – the students assessment profile module

ISDE Prototyping JTB Oct 2000 16

Incremental Prototyping - AdvantagesIncremental Prototyping - Advantages

Allows large systems to be installed in phases Helps to avoid the delays between specification

and implementation Core system features are provided early Users are not overwhelmed with a complex level

of functionality in one go Suitability and appropriateness of key

requirements can be checked Less essential features can be added later

ISDE Prototyping JTB Oct 2000 17

Incremental Prototyping – DisadvantagesIncremental Prototyping – Disadvantages

Need to have an overall view of requirements Suitable development software must be used – not just

high level prototyping software Long development timescale before full functionality is

obtained This may be incompatible with management business

goals– Eg Need to get to market before a competitor– Urgent requirements for a complete solution

ISDE Prototyping JTB Oct 2000 18

Evolutionary prototyping – RADEvolutionary prototyping – RAD

As for incremental prototyping Additions and amendments are made following evaluation

and the system is regenerated in its amended form In this case the prototype evolves into the final system

ISDE Prototyping JTB Oct 2000 19

Evolutionary prototyping – AdvantagesEvolutionary prototyping – Advantages

The system can cope with change during and after implementation

Again helps to overcome the gap between specification and implementation

Users get some functionality quickly

ISDE Prototyping JTB Oct 2000 20

Evolutionary prototyping -DisadvantagesEvolutionary prototyping -Disadvantages

Can lead to a long development timescale May have limited functionality which may not be

apparent to the user May believe that they have the final complete

system and may therefore be unimpressed!

ISDE Prototyping JTB Oct 2000 21

Other Prototyping TechniquesOther Prototyping Techniques

Full prototype– full functionality, lower performance than production

software Horizontal prototype

– displays “breadth” of functionality, no lower level detail “back end” support Eg. Database link

Vertical prototype– full functionality and performance of a “slice” or small part

of the system High Fidelity prototyping

– prototyping through alternative media, e.g. video

ISDE Prototyping JTB Oct 2000 22

Other Kinds of Prototyping Other Kinds of Prototyping (continued)(continued)

Low fidelity prototyping– lesser, cheaper materials

Chauffeured prototyping– user observed “driving” the system

Wizard of Oz prototyping Requirements Animation

ISDE Prototyping JTB Oct 2000 23

Software prototyping toolsSoftware prototyping toolsFacades 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.

ISDE Prototyping JTB Oct 2000 24

Further ReadingFurther Reading

Preece Chpt 8

ISDE Prototyping JTB Oct 2000 25

RAD toolsRAD 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

ISDE Prototyping JTB Oct 2000 26

Visual Basic and DelphiVisual 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.

ISDE Prototyping JTB Oct 2000 27

Event-driven ProgrammingEvent-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

ISDE Prototyping JTB Oct 2000 28

Event-Driven Programming Event-Driven Programming (contin.)(contin.)

Development procedure is essentially1. 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

ISDE Prototyping JTB Oct 2000 29

Visual Basic versus DelphiVisual 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

ISDE Prototyping JTB Oct 2000 30

Visual Basic versus DelphiVisual 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

ISDE Prototyping JTB Oct 2000 31

ImplicationsImplications

VB 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