Software Prototyping
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
1
Software prototyping
•
•
•
•
Intention/aim of prototyping
In relation with general prototyping
Approaches to and types of prototyping
Strengths and weaknesses of prototyping
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
2
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
3
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
4
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
5
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
6
Approaches to prototyping
• Approaches to prototyping, according to
the goals we want to achieve:
– Exploratory
– Experimental
– Evolutionary
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
7
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
8
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
9
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
10
Horizontal and vertical prototyping
• Horizontal
– Only specific layers of system is implemented
• Vertical
– Selected parts down through all layers
User-interface
Functionality
Data model
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
11
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
12
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
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
13
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
17.03.2003
• 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
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
14