Petter Nielsen pnielsenifi'uio'no

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 dont 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

User-interface
Functionality
Data model
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
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