CS 540A-04 Prototyping

8/22/2019 CS 540A-04 Prototyping

1/40

Lecture 4 Prototyping

CS 540Quantitative Software Engineering


2/40

Software Requirements Process

Requirements Elicitation

Requirements Analysis

Use Cases

Requirements Specification

Prototype/Modeling

Requirements Management


3/40

Software Prototyping Process

Software prototyping is the process of creating an

incomplete model of the future full-featured

software

Process: Identify basic requirements

Develop Initial prototype

Review with customers users

Revise and enhance


4/40

Types of Software Prototypes

Throwaway prototype: process of creating a

rapid model (demonstration or marketing)

Evolutionary prototype: build a system then

refine

Incremental: final product built as separate

prototypes


5/40

Serial development is costly

Cost ofChange

Time

The Longer You Wait

for Feedback, the

more costs are sunk.


6/40

Applications

Feasibility (must use)

Human Interface testing

Increases user involvement

Reduce time and cost

DSDM (Dynamic systems development method) Business prototypes (automation/mechanization)

Usability prototypes Performance and Capacity

Proof of concept


7/40

Technicians

Cost of WorkToday

Technician

New Costof Work

SystemAdministrator

Cost of System

Operation

Cost of System

Hardware

Software

Training

Standards ReuseProcesses

Tools Technology

$1b/yr

Developer

Benefits of Automation


8/40

Project A: Order Reading and Analysis Software

Size of Prototyping Effort:

12K lines of C Code (10% of final system module)

Purpose:

Find a method for order reading and analysis, applicable to

variable formats.

Duration and Staff of Prototype:

Four people for eight months.


9/40

Prototyping Results

1. Final requirements based on prototype results.

2. Alerted developers' to the possibility of a

having a tunable system.

3. Early evaluation of functional decompositionand performance showed bottlenecks in the

dispatcher.

4. Eliminated the possibility of reusing code from

another project.5. Prototype was thrown away due to

decomposition and performance problems.


10/40

Project B: Outside Plant Data Base System

Size of Effort: 5% of 500K line of source code.

Purpose:

To evaluate database structures for an outside plant data and toexperiment with approaches to handling multiple future states of

equipment usage.

Duration:

Three people for 15 months.


11/40

Experience:

1. A data base structure using hyper graph theory was

invented.

2. An algorithm for handling both time-driven and event-

driven assignments was invented

3. The prototype became the basis for the production code.

4. UNIX flat files were used to model loop plant by way of

a directed graph.

5. The prototype showed database portability from Unix to

the Mainframe.


12/40

TRADITIONAL PROTOTYPE BASED

40% REDUCTION

20%

80%

40%

30%

45%

25%

Systems

Engineering

Design,

Develop,

Test,

Install

Final

Development,

Deployment

Systems

Engineering &

Prototype

FinalDevelopment

Deployment

Comparison


13/40

Prototypes

Plan to build a prototype

Document feedback from customer for the

prototype.

Manage the feedback into the software product


14/40

Prototyping with Reuse

Application level development Entire application systems are integrated with the prototype so

that their functionality can be shared

For example, if text preparation is required, a standard word

processor can be used

Component level development Components are mutually independent

Individual components are integrated within a standard

framework to implement the system

Framework can be a scripting language or an integration

platform.


15/40

Prototyping Benefits

Misunderstandings between software users and

developers are exposed

Missing services may be detected and confusing

services may be identified

A working system is available early in the process

The prototype may serve as a basis for deriving a

system specification The system can support user training and system

testing


16/40

Prototyping Approaches

Prospectus

Ev o lu ti on ar y

p r o to ty pi ng

Th r ow- a wa y

P r o to ty pi ng

De l i ve r e d

s ys te m

Exec ut a ble P r ot ot yp e +S y st e m S pe c i f ic a t io n


17/40

Prototyping Objectives

The objective ofevolutionary prototypingis to

deliver a working system to end-users

The development starts with those requirements

which are best understood.

The objective ofthrow-away prototypingis to

validate or derive the system requirements

The prototyping process starts with those

requirements which are poorly understood


18/40

Evolutionary Prototyping

Must be used for systems where the requirements

specification cannot be developed in advance

Based on techniques which allow rapid system

iterations

Verification is impossible as there is no

specification

Validation means demonstrating the adequacy ofthe system


19/40

Evolutionary Prototyping Flow

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliver

system

System

adequate?

YES

N


20/40

Evolutionary Prototyping Advantages

Accelerated delivery of the system Rapid delivery and deployment are sometimes more important

than functionality or long-term software maintainability

User engagement with the system Not only is the system more likely to meet user requirements,

they are more likely to commit to the use of the system


21/40

Evolutionary Prototyping Technologies

Specification, design and implementation are

inter-twined

The system is developed as a series of increments

that are delivered to the customer

Techniques for rapid system development are

used such as CASE tools and 4GLs

User interfaces are usually developed using a GUIdevelopment toolkit


22/40

Evolutionary Prototyping Challenges

Management problems

Existing management processes assume a waterfall

model of development

Specialist skills are required which may not beavailable in all development teams

Maintenance problems

Continual change tends to corrupt system structure so

long-term maintenance is expensive

Contractual problems


23/40

Prototypes as Specifications

Some parts of the requirements may be

impossible to prototype

E.g., safety-critical functions

An implementation has no legal standing as acontract

Non-functional requirements cannot be

adequately tested in a system prototype


24/40

Incremental Development

System is developed and delivered in increments after

establishing an overall architecture

Requirements and specifications for each increment may

be developed

Users may experiment with delivered increments while

others are being developed

These serve as a form of prototype system

Intended to combine some of the advantages ofprototyping

More manageable process

Better system structure


25/40

Incremental Development Flow

Validateincrement

Build systemincrement

Specify systemincrement

Design system

architecture

Define system

deliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO


26/40

Throw-away Prototypes

Used to reduce requirements risk

The prototype is developed from an initial

specification, delivered for experiment then

discarded

The throw-away prototype must NOT be considered

as a final system Some system characteristics may have been left out

There is no specification for long-term maintenance

The system will be poorly structured and difficult to maintain


27/40

Throw-away Prototyping

Outline

requirements

Develop

prototype

Evaluate

prototype

Specify

system

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusable

components


28/40

Rapid Prototyping Techniques

Various techniques may be used for rapid

development

Dynamic high-level language development

Database programming Component and application assembly

These techniques are often used together

Visual programming is an inherent part of mostprototype development systems


29/40

Dynamic High-level Languages

Languages which include powerful data

management facilities

Need a large run-time support system. Not

normally used for large system development

Some languages offer excellent UI development

facilities

Some languages have an integrated supportenvironment whose facilities may be used in the

prototype


30/40

Choice of Prototyping Language

What is the application domain of the problem?

What user interaction is required?

What support environment comes with the

language?

Different parts of the system may be programmed

in different languages

Example languages Java, Smalltalk, Lisp, Prolog, Perl, Tcl/TK


31/40

Database Programming Languages

Domain specific languages for business systems based around adatabase management system

Normally include a database query language, a screen generator, a

report generator and a spreadsheet

May be integrated with a CASE toolset

The language + environment is sometimes known as a 4GL

Cost-effective for small to medium sized business systems

DB

programminglanguage

Interfacegenerator Spreadsheet

Reportgenerator

Database management system

Fourth-generation language


32/40

Prototyping with Reuse

Application level development Entire application systems are integrated with the prototype so

that their functionality can be shared

For example, if text preparation is required, a standard word

processor can be used

Component level development Components are mutually independent

Individual components are integrated within a standard

framework to implement the system Framework can be a scripting language or an integration

platform.

.


33/40

Key points

A prototype can be used to give end-users a concrete

impression of the systems capabilities

Prototyping is becoming increasingly used where

rapid development is essential

Throw-away prototyping is used to understand the

system requirements

In evolutionary prototyping, the system is developedby evolving an initial version to the final version


34/40

Visual programming

Scripting languages such as Visual Basic support

visual programming

the prototype is developed by creating a user

interface from standard items and associatingcomponents with these items

A large library of components exists to support

this type of development

These may be tailored to suit the specific

application requirements


35/40

Visual programming with reuse

File Edit Views Layout Opt ions Help

General

Index

Hypertextdisplay componentDate component

Range checkingscript

Tree displaycomponent

12th January 2000

3.876

Draw canvascomponent

User promptcomponent +

script


36/40

Problems with visual development

Difficult to coordinate team-based development

No explicit system architecture

Complex dependencies between parts of the

program can cause maintainability problems


37/40

User interface prototyping

It is impossible to pre-specify the look and feel of

a user interface in an effective way

UI development consumes an increasing part of

overall system development costs

User interface generators may be used to draw

the interface and simulate its functionality with

components associated with interface entities

Web interfaces may be prototyped using a web

site editor


38/40

Mindset

Prototyping is critical system parts that cannot be

effectively pre-specified

Rapid prototyping focus on partial functionality

Prototyping techniques include the use of tools,

very high-level languages and database

programming

Users must be involved in prototype evaluation


39/40

Growing from Prototype to Model


40/40

Software Prototyping: Review

Types: Throwaway, Evolutionary, Incremental

Advantages and Disadvantages

When to Use

Methods: DSDM, Evolutionary, Operational,

SCRUM

Tools: Screen Generators, design, tangible

architect, Visual Basic, REE, LYMB Simulation technologies

Documents

CS 540A-04 Prototyping