The Prototyping Approach

Techniques for prototype application

Types of Information Systems Sprague & Watson, DSS for Management, Prentice Hall, 1996

Type I (Procedure)• High volume• Low transaction cost• Well structured• Measurable• Process & efficiency• Data• Clerical

Type II (Goal)• Low volume• High trans. value• Poorly structured• Hard to measure• Goal & effectiveness• Concepts• Mgrs, professionals

IS Development Approaches

• Systems Development Life Cycle• Information Center (DSS)• Object and Component

Type ILarge Systems

• Intercommunications among applications

• Formal methodologies• CASE technologies• Purchased products• Outsourcing

Type ISDLC

• Type I systems• Large and Costly• Cost justified• Formal stages of evaluation• Stages carefully reviewed and

formally approved• Data, Process, Communications

Type IIInformation Center (DSS)

• Type II systems• Relatively small and inexpensive• Value justified• Prototyping and evolutionary design• Data, Dialog, Model

Prototyping

“It is easier to tell what you don’t like about an existing system than to

describe what you would like in an imaginary one”

A.M. Jenkins, 1983

Choice

Life Cycle Prespecification

possible Changes expensive Good project

communication Static model OK Rigorous approach

useful Iteration

unacceptable

Prototype Prespecification

difficult Quick tools work Communications gap Animated model

needed Rigor after

requirements Iteration accepted

The Prototyping Process

IdentifyInitial

Requirements

DevelopSystem

Use andEvaluate

Document and Install

Iterate

Prototyping Life Cycle

Determine suitability for prototypingIdentify basic needsDevelop working modelDemonstrate and solicit refinementsRevise and redemonstrateClean up and document

Assumptions

All requirements cannot be specifiedQuick build tools are availableCommunications gap between

builders and usersActive models are requiredRigorous approaches are appropriate

once requirements are knownIteration is valuable

Use Prototyping If

Life cycle too slowScope of project manageable

30 screensSmall team: 1-2 users/designers50 attributes

User not sure of specificationsUser satisfaction very importantReporting or DSS Irregular or infrequent use

Do Not Use Prototyping If

Don’t understand toolsData not well managedSoftware not well managedProfessional staff not availableTechnology response not adequateUser not willing to invest time

Factors Favoring Prototyping

Structure: interactive, on-line (OLAP)Logic: structured but not algorithmic

DSS applications are often data-report types

User: competent and active participantTime Constraint: not a crash projectManagement: willing to work with methodSize: not overly large or complex

Factors Favoring Prototyping

Problem: imprecise specifications, poorly defined communications, interactive model needed

Why not use prototyping

Roles

User Responsible for business solutions

Intermediary Run system for userBuilder Write code for applicationTechnical Supports the development

Support toolsToolsmith Build basic tool modules (often

work for software houses)

Requirements for Successful Prototyping: User

Initiate the processSeeks IS assistanceCompetent in business areaWilling to spend time with system

Requirements for Successful Prototyping: Builder

Assigned to PrototypingCompetent with toolsKnows organizational data resources

Requirements for Successful Prototyping: Technology

Roles identified4GL Tools establishedData is managedTechnology response adequate

Builders Added Value(Professional Design)

Date and time stampsControl totalsAudit trailsCommon interface feelAdditional functionsTesting

Prototyping Principles

1. Most applications arise from a small set of basic systems

1. Batch edit/update 7. On-line application2. Batch reporting interface3. Batch data update 8. On-line report4. Batch interface5. On-line update/query6. On-line ad hoc query

Prototyping Principles

AddModifyDisplayDeleteLocate

BrowseActivateCopyConnectStop

2. Most systems use a common set of data processing functions

Prototyping Principles

3. Most editing derives from a small set of models.

Tunnel editsCross field editsCross record edits

Prototyping Principles

4. Most reports are based on a four step process.

Select data from the databaseSort by specificationFormat and edit for printingPrint

Prototyping Principles

Audit trailsControl totalsMenu and

command modesHelp facility

Standard screen formats

Date/time stamping

Ergonomics

5. There are a standard set of value added design structures that should be added

Prototyping Tactics

Normalize data to 3NFUse component engineering

Use existing componentsAssemble from existing partsReuse piecesCreate pieces so that they can be reused

Cut and pasteKeep a set of examples

Prototyping Tactics

Use active data dictionariesAutomate documentationKeep teams small Integrated software workbench toolsSpecify objectives not proceduresProvide end-user report writing toolsUse professional prototypersHave systems developers work with

prototypers

Project Management

Initial Model: 2-6 weeksMust be fast enough to maintain interest

Revisions: immediate - 2 weeksChargeback: use charges to avoid

frivolous changes Approval: determine the group who

approves iterationsSign off: formal acceptance

AdditionalImplementation RequirementsOperational documentation and

proceduresData size and operational impact

analysisTest planTraining procedures

Tactic

EvolutionThrowawayLife Cycle component

References

Bernard H. Boar, Application Prototyping, Wiley, 1984. Ralph Sprague & Eric Carlson, Building Effective Decision Support

Systems, Prentice Hall, 1984.