Prototyping. Outline Risk Management Prototyping Kinds of Prototypes Example Activity 1.

Post on 18-Jan-2016

220 views 0 download

Tags:

Transcript of Prototyping. Outline Risk Management Prototyping Kinds of Prototypes Example Activity 1.

Prototyping

2

Outline

• Risk Management• Prototyping• Kinds of Prototypes• Example• Activity

3

Risk Management

• Risk: an unwanted event that has negative consequences

• Risk impact: the loss if risk turns into problem• Measured in time, quality cost

• Risk likelihood: probability that risk will turn into problem• Risk exposure = impact * likelihood

• Risk control: the degree to which you can reduce exposure

4

Risk Management

• Risk assessment• Identification• Analysis• Prioritization

• Risk control• Reduction• Management planning• Resolution

5

Example Risks in E-Commerce Application

• Risk: mobile phones (unexpectedly) need to be supported• Impact: 30% of revenue??• Likelihood: ???

• Risk: credit card validation cannot handle debit cards• Impact: 10% of revenue?• Likelihood: ???

6

Risk Management and Prototyping

• Traditional requirements-gathering• Good for controlling risks regarding what system should do• Don’t know what system should look like

• Prototyping• Good for controlling risks regarding what system should look like• Not good for non-visual aspects of system

7

Top Ten Risks

• Personnel shortfalls• Unrealistic schedule and budgets• Developing the wrong software functions• Developing the wrong user interface• Gold plating• Continuing stream of requirements changes• Shortfalls in externally performed tasks• Shortfalls in externally furnished components• Real-time performance shortfalls• Straining computer science capabilities

8

Outline

• Risk Management• Prototyping• Kinds of Prototypes• Example• Activity

9

General Idea of Prototyping

• Depict• You depict what you think the system should look like

• Test• You test prototypes with customers or users

• Fix• You fix the prototypes • Informs real system implementation

10

Waterfall Process

Requirements analysis

Design

Implementation

Operation

Testing

Prototyping

11

Spiral Process

Draft a menu ofrequirements

EstablishrequirementsPlan

Analyze risk &prototype

Draft a menu ofarchitecture designs

Analyze risk &prototype

Analyze risk &prototype

Draft a menu ofprogram designs

Establisharchitecture

Establishprogram design

Implementation

TestingOperation

Plan

12

Outline

• Risk Management• Prototyping• Kinds of Prototypes• Example• Activity

13

Different Kinds of Prototypes

• Throwaway prototypes• Paper prototypes• Low-fidelity prototypes

• Evolutionary prototypes• High-fidelity prototypes

14

Paper prototypes

• Sketch on paper and/or post-it notes• Don’t worry about colors, fonts, icons, etc.• Doesn’t need to be beautiful

• Does need to show all important UI elements• Does need to be intelligible by users

15

Low-fidelity Prototypes

• Fidelity = closeness to final product• Paper prototypes are ultra low fidelity

• Low-fidelity prototypes can be made with• Photoshop• PowerPoint• HTML• Etc. (anything else that’s cheap / easy to use)

16

High-fidelity Prototypes

• Fidelity = closeness to final product• High-fidelity means closer to final product

• Implemented on target platform• Not fully functional• Destined to be incorporated into final product

17

“Testing” Prototypes

• Customers and Users should be your friends

• They know more about the problem than you do

• They have some ideas about how to solve the problem

• They are best resource for discovering your mistakes before you start coding

• So.. LISTEN!!

18

“Testing” Prototypes

• Pretend to be computer• User tries to perform use case with prototype

• Let the user interface speak for itself!!• See if user can figure it out based on prototype

• If user misunderstands the UI, fix it on the spot• Principle: use is always right (in prototyping)

19

Break Time!!!

20

Outline

• Risk Management• Prototyping• Kinds of Prototypes• Example• Activity

21

Example System: Functional Requirements

• System will have web pages for mobile phones where citizens can report panhandlers

• Certain users (volunteers) will view reports and “claim” panhandlers

• Volunteer offers social services to “claimed” panhandler• Panhandler's report marked “done”

22

Examples System: Panhandler Report State Chart

new(just reported)

claimed(by volunteer)

done(visited by volunteer)

claimunclaim

mark donesucceeds

23

Use Case #1: Report panhandler

• Actor: any user• Preconditions: user views site in mobile browser• Postconditions: system records report• Flow of events:• User selects a city• User enters information about panhandler• System validates inputs• System records report in database

24

1. User selects a city2. User enters

information about the panhandler

3. System validates inputs

4. System records report in database

25

Use Case #2: Process Panhandler

• Actor: volunteer• Preconditions: volunteer logged in via mobile browser• Postconditions: panhandler marked “done” in system• Flow of events:• Volunteer reviews list or map of panhandlers• Volunteer marks report as “claimed”• System records report as claimed• Volunteer visits the panhandler• Volunteer marks report as “done”• System records report as done

1. Volunteer reviews list or map of panhandlers

2. Volunteer marks report as “claimed”3. System records report as claimed4. Volunteer visits the panhandler5. Volunteer marks report as “done”6. System records report as done

1. Volunteer reviews list or map of panhandlers

2. Volunteer marks report as “claimed”3. System records report as claimed4. Volunteer visits the panhandler5. Volunteer marks report as “done”6. System records report as done

28

Examples: Problems Revealed by Prototype

• What happens during “validation” of panhandler report?

• How does the volunteer navigate from “list” to “map” view?

• What happens if there are lots of report?• How does user make sense of it?

• What happens when user marks panhandler as “done”?

29

Non-visual Problems Prototype Might NOT catch

• Duplicate reports• New cities• User authentication• Mapping interface in mobile browser?

Identifying such problems requires techniques beyond prototyping

30

Example Low-Fidelity Prototypes

• Low-fidelity prototypes• “Close to” the real deal• but NOT implemented

• Care about what system will LOOK like• Photoshop, PowerPoint, etc.

http://www.flickr.com/photos/juhansonin/347137175/sizes/o/

Promoting health awareness with a“know your numbers” card & system

http://www.flickr.com/photos/sstorari/3671284171/sizes/o/

Prototype splash-screen for Anaconda, an installer framework for Linux

Prototype of a site for managing and sharing photos

34

Paper vs. Low-fidelity

• Low-fidelity• Let’s you explore colors, fonts, icons, etc.• Paper does not

• But low-fidelity• Is more expensive than paper• Requires somebody with design skills• Is harder to fix on the fly

• And neither can detect certain problems..

35

Outline

• Risk Management• Prototyping• Kinds of Prototypes• Example• Activity

36

Activity

• Get into groups of 3• 1 person will be custom / user• 2 people will be engineers

• Your group’s task is to:• Create use case(s) • Create “paper” prototype(s)

• … for the following functional requirements..• Each team’s customer will decide if prototypes are “good”• (Not me..)

37

Activity: Functional Requirements

• System will have web pages that allow users to upload status reports about mountain bike trails• Status reports MUST include: location, quality, and date• Status reports MAY include: photos, text

• System will allow users to view reports by:• Location, quality, or date

How the paper prototype(s) “look” is up to your team’s customer