lecture 4 prototyping cs 540 – quantitative software engineering

47
Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Post on 20-Dec-2015

224 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Lecture 4 Prototyping

CS 540 – Quantitative Software Engineering

Page 2: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Software Requirements Process

Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype/Modeling Requirements Management

Page 3: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Serial development is costly

Cost ofChange

Time

The Longer You Wait for Feedback, the more costs are sunk.

Page 4: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Business Analyst

Requirements Specifications

Questions Questions

A sometime facilitator between customers and developers.

Page 5: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Technicians

Cost of Work Today Technician

New Costof Work

SystemAdministrator

Cost of SystemOperation

Cost of System

Hardware

Software

Training

Standards ReuseProcesses

ToolsTechnology

$1b/yr

Developer

Benefits of Automation

Page 6: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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.  

Page 7: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 decomposition and 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.

 

Page 8: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 to experiment with approaches to handling multiple future states of equipment usage. Duration:  Three people for 15 months.

Page 9: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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.

 

Page 10: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

TRADITIONAL PROTOTYPE BASED

40% REDUCTION

20%

80%

40%

30%

45%

25%

SystemsEngineering

Design,Develop,

Test,Install

FinalDevelopment,Deployment

SystemsEngineering &

Prototype

FinalDevelopment

Deployment

Comparison

Page 11: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Prototypes

Plan to build a prototype Document feedback from customer for the

prototype. Manage the feedback into the software product

Page 12: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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.

Page 13: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 14: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Prototyping Approaches

Prospectus

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

Page 15: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Prototyping Objectives

The objective of evolutionary prototyping is to deliver a working system to end-users• The development starts with those requirements

which are best understood. The objective of throw-away prototyping is to

validate or derive the system requirements• The prototyping process starts with those

requirements which are poorly understood

Page 16: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 of the system

Page 17: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Evolutionary Prototyping Flow

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

Page 18: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 19: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 GUI development toolkit

Page 20: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Evolutionary Prototyping Challenges

Management problems• Existing management processes assume a waterfall

model of development

• Specialist skills are required which may not be available in all development teams

Maintenance problems• Continual change tends to corrupt system structure so

long-term maintenance is expensive Contractual problems

Page 21: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 a contract

Non-functional requirements cannot be adequately tested in a system prototype

Page 22: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 of prototyping • More manageable process• Better system structure

Page 23: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Incremental Development Flow

Validateincrement

Build systemincrement

Specify systemincrement

Design systemarchitecture

Define systemdeliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO

Page 24: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 25: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Throw-away Prototyping

Outlinerequirements

Developprototype

Evaluateprototype

Specifysystem

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Page 26: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 most

prototype development systems

Page 27: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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 support environment whose facilities may be used in the prototype

Page 28: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 29: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Database Programming Languages

Domain specific languages for business systems based around a database 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

DBprogramming

language

Interfacegenerator Spreadsheet

Reportgenerator

Database management system

Fourth-generation language

Page 30: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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.

.

Page 31: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Key points

A prototype can be used to give end-users a concrete impression of the system’s 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 developed by evolving an initial version to the final version

Page 32: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Visual programming

Scripting languages such as Visual Basic support visual programming• the prototype is developed by creating a user

interface from standard items and associating components 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

Page 33: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Visual programming with reuse

File Edit Views Layout Options Help

GeneralIndex

Hypertextdisplay componentDate component

Range checkingscript

Tree displaycomponent

12th January 2000

3.876

Draw canvascomponent

User promptcomponent +

script

Page 34: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 35: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 36: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

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

Page 37: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Growing from Prototype to Model

Page 38: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Case History

Harbor Radar

Senior Design Project

Page 39: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Project Overview

To primarily serve boaters in the Hudson River area with a 40 mile radius and inexpensive TV to display weather info, buoy data, and plotted locations

Interactive website• Accessible to everyone• Secure section where admin can control information

displayed with ability to plot coordinates and alter broadcast information

Difficult time writing requirements and setting scope

Page 40: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Requirements

Website Design-Easy to use, clean, intuitive and clearly display

maps Reliability

• High reliability requested by customer• Availability

» Ultimate goal of 24/7, however probably not doable. 20/7 has been suggested

Page 41: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Requirements (cont.)

Performance• Website will support 50 simultaneous users

» Reach for goal of 100• Television broadcast(s) place little load on the system• Response Time

» Average of .5s Constraints

• Television resolution will be an issue» Aim to be readable on a 9” screen

• Support both IE and Netscape, versions TBD

Page 42: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Map Module Screenshots

Page 43: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Larger View

Grid

Icons

Page 44: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Wrapper Module for TV Screens

Page 45: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

Case Study Space Data System

Source: A. Hooke, NASA/JPL

A GroundTrackin

gNetwork

One or MoreSpacecraft

An Instrument

ControlCenterA Spacecraft

ControlCenter

A ScienceFacility

A SpaceTrackingNetwork

Commodity Space

Communications Systems

Commodity Space

Navigation Systems

One or MoreInstruments

Page 46: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

CS 540A Fall 06 46

Host

- Host/Terminal- Host Dependent- Centralized Database

S

- Client/Server- Host Cooperative- Shared Database

Case Study: Networked Computing

Page 47: Lecture 4 Prototyping CS 540 – Quantitative Software Engineering

CS 540A Fall 06 47

Host

S

- Local processing continues- Database updates stored- In business

DisasterAvoidance

CLOSED

- Processing stops- Out-of-business

Networked Computing in Action