17.03.2003 Petter Nielsen ([email protected]) Information Systems/IFI/UiO 1 Software Prototyping.

17.03.2003 Petter Nielsen ([email protected])Information Systems/IFI/UiO

1

Software Prototyping


2

Software prototyping

• Intention/aim of prototyping

• In relation with general prototyping

• Approaches to and types of prototyping

• Strengths and weaknesses of prototyping


3

Software prototyping

• Suggestion for definition: “An early demonstration of relevant parts of a desired IS, which are to be combined with other processes in system development to improve the final system“

• Early feedback about meeting users needs, as well as technical feasibility and efficiency

• Demonstrations provides “tangible” models to evaluate

• Communication and learning: Internal and external


4

Motivation

• You only know to build the system when you have built it

• While working with prototypes, developers learns about the system

• Preferred to postpone completion of specifications until system construction

• An executable specification


5

Conditions for prototyping

• Have to be a learning process– A dialog– Possible to criticize– Possible to implement the knowledge

• Early availability for users and developers

• Easy to change as needed


6

Terminology of prototyping

• Not prototyping in a strict sense: – Engineering:

• A well defined phase were a model is produced in advance,• exhibiting all the essential features of the final product, • for use as a test specimen and outside the further production

• Software prototyping: – In the context of the development process– No clear relation between the prototype and final

system– Interest in the process and not the prototype as a

product: Learning– Reproduction is not a challenge


7

Approaches to prototyping

• Approaches to prototyping, according to the goals we want to achieve: – Exploratory– Experimental– Evolutionary


8

Exploratory prototyping

• To handle the communication challenge between users and developers:– User don’t know which help IS can give them, and

developers does not know users needs

• To be used in the early phases of development clarifying requirements

• Alternatives must be available for discussion• Only recommended if tools is available to

develop with a minimum of effort – cost and time• Normally thrown away


9

Experimental prototyping

• Proposed solution evaluated by experimental use, also handling communication challenge

• Appropriate in any phase after initial specification

• The prototype can serve as: – Complementary to the specification– Refinement of parts of the specification– Step between specification and implementation

• Can be a throw-away or become a part of or the system


10

Evolutionary prototyping

• Far away from the original term: An approach with fixed requirements does not suffice

• Continuous process of adaptation to changing requirements

• Two forms: – Incremental

• Basis in existing practice and substitution over time

– Evolutionary• Not a focus on capturing all requirements in advance but in

cycles


11

Horizontal and vertical prototyping

• Horizontal – Only specific layers of system is implemented

• Vertical– Selected parts down through all layers

Functionality

Data model

User-interface


12

Relation to the final system

– Prototype proper• In parallel with the real system• Illustrates specific parts of the system: User interface or functionality• Several small to address different problems• Throw-away

– Breadboard• Clarifying construction related questions• Based on specifications• Not related to users• Throw-away

– Pilot system• Not only for testing but also employed in the system• No clear distinction between the prototype and the system• Requires more elaborated design than proper and breadboard


13

Summary

Type of prototype Exploratory Experimental Evolutionary

Main aim Learning Evaluation Accommodate change

Relation to final system

Proper/breadboard

Throw-away

Proper/breadboard

Throw-away or components

Pilot system

The final system


14

Strengths and weaknesses of prototyping

• Introducing communication and feedback into software development methodology

• Can lead to more adequate systems if used appropriate

• Early demonstration of operational version

• Easy way of involving the users: The feel of participation, ownership and commitment

• After successful evaluation, the prototype can be used as a teaching environment

• Prepares the organization by giving a foretaste

• No guaranty for real user participation

• Requires a willingness to accept criticism and changes

• Problems with multiple prototypes

• Prototypes creates expectations: Differences in final system and prototype without user consent will lead to acceptance problems

17.03.2003 Petter Nielsen ([email protected]) Information Systems/IFI/UiO 1 Software Prototyping.

Documents

Transcript of 17.03.2003 Petter Nielsen ([email protected]) Information Systems/IFI/UiO 1 Software Prototyping.