Chapter 6: Software Prototyping

1
Chapter 6 Software Prototyping

• Remark this presentation is based on Ian
  Sommerville slides provided with his Software
  Engineering 6th Edition book (Addison Wesley)
• 6.1 Introduction
• Prototyping is the rapid development of a system
  or parts of a system for a variety of purposes
• We have already mentioned prototyping as a
  technique for clarifying requirements, reducing
  risk or as a base for software development
  processes (phased development as in iterative or
  incremental software development).
• The objectives of this chapter are
• To describe the use of prototypes in software
  development projects
• To discuss evolutionary and throw-away
  prototyping
• To introduce three rapid prototyping techniques -
  high-level language development, database
  programming and component reuse
• To explain the need for user interface prototyping

2

• Prototyping is increasingly used during today's
  software projects development indeed many
  projects are developed as a succession of
  prototypes (see phased development).
• But prototyping can also be misused and lead to
  huge problems.
• 6.2. Uses of Software Prototyping
• The principal use is to help customers and
  developers understand the requirements for the
  software
• Customers and users usually find it hard to
  express their real requirements
• Very hard to predict everything in an entirely
  new software (even using traditional modelling
  techniques)
• Useful because all parties involved can discover
  requirement errors or omissions early in the
  software process
• This is a risk reduction activity
• Technical issues can be clarified using a
  prototype
• The produced prototype may be used for user
  training before the final system is delivered.

3

• The prototype may be used during verification of
  the final system (see back to back testing
  later) i.e. as an oracle
• As mentioned prototyping can be an entire way of
  developing software (phased development)
• 6.3 Prototyping Benefits
• Misunderstandings between software
  users/customers and developers are exposed
• Missing functionalities may be detected and
  confusing functionalities may be identified
• A working system is available early in the
  process
• The prototype may serve as a basis for deriving a
  software specification
• The prototype can support user training and
  software testing

4

• 6.4 Problems with Prototyping in General
• Misuse of prototyping
• linking prototypes together to build the entire
  software chaos, buggy, slow, impossible to
  maintain
• Absence of evaluation/review of the prototype
• Technical difficulties (induced by very short
  deadlines)
• Managerial difficulties
• planning, costing
• tracking changes in prototypes
• not leaving enough time for evaluation/review
• Perceived initial costs
• 6.5 Prototyping in the Software Process
• We have seen in chapter two how the benefits of
  prototyping can be harnessed within a controlled
  software process
• Phased/evolutionary development iterative or
  incremental
• We grow the software rather than build it.
• Realistic feedback is possible throughout the
  project since executables are available after
  each iteration.

5

• Refer back to chapter 2 for details of
  evolutionary processes which can also be part of
  the spiral model.

6

• 6.5.1 Throwaway Prototyping
• Only a technique not a software development
  process.
• The prototype is developed from an initial
  specification, delivered for experiments and
  feedback then discarded.
• Clarify the least well understood requirements.
• Used to validate or even derive the software
  requirements.
• Can be used to reduce requirements or
  technological risks.
• clarify requirements
• evaluation of technical solutions
• Can be very effective e.g. Graphical User
  Interface prototyping
• The prototype should not be considered as a final
  system
• some system characteristics may have been left
  out.
• the system will be poorly structured and
  difficult to maintain
• the objectives was rapid implementation for quick
  feedback not reliability or clarity

7

• non-functional requirements will not be addressed
  in a prototype (e.g. security, safety,
  reliability)
• unlikely to be as efficient as a well planned
  system
• no specification available, hence cannot be
  formally validated and will be hard to maintain
• Keeping/modifying a prototype which was intended
  to be throwaway as a final system is always a
  very bad temptation which must be resisted
  (quality goes out of the window!)
• 6.7 Prototyping Techniques
• Rapid development is the objective (to reduce
  costs, quick feedback)
• Various techniques available depending on problem
  domain
• Dynamic high-level language development
• Database programming
• Visual environments
• Applications assembly
• Composition of reusable components
• These techniques are often combined in a given
  software development process.

8

• 6.7.1 Dynamic high-level language development
• A variety of programming languages fall under
  this category
• scripting languages (e.g. Perl, Python), good
  networking capabilities.
• logic languages (e.g. Prolog), good for
  combinatorial problems.
• functional languages (e.g. Lisp, ML), good for
  manipulation of symbols.
• Languages which include powerful data management
  facilities
• Need a large run-time support system (because the
  programs are usually interpreted not compiled).
  Not normally used for large system development.
• Can lead to slow prototypes
• 6.7.2 Database programming
• Very common.
• Use of external database capabilities rather than
  implementation from scratch.
• Includes a query language (usually SQL)

9

• e.g. Microsoft Access Engine, Borland Database
  Engine
• 6.7.3 Visual environments
• Very useful for Graphical User Interface part of
  a system.
• Allow rapid prototyping of user interface
• e.g. VC, Delphi, VB, CBuilder

10

• Problems
• absence of standards, compatibility issues, quick
  versions turnaround and heavy dependence on the
  version of the visual environment (Visual Basic
  version 1 anyone?) create maintenance problems.
• good for GUI but be careful of the rest complex
  dependencies between parts of the program can
  cause maintainability problems ideally the
  interfaces should be as independent of the rest
  of the application as possible.
• 6.7.4 Applications assembly
• The combination of various stand alone
  applications to create the new system.
• For example one can combine a spreadsheet, a
  database and an email reader with a specially
  designed graphical user interface to develop a
  customer care system.
• Requires a range of applications that can be
  glued together e.g. Microsoft Office with VB for
  Applications
• Good for small projects

11

• Problems
• poor reliability
• heavy dependence on other applications
• slower systems
• poorly structured systems
• 6.7.5 Composition of reusable components
• Prototypes can be constructed quickly if a
  library of reusable components and some mechanism
  to compose these components into systems are
  available
• the system is prototyped by 'gluing' together
  existing components
• Examples
• Unix utilities and Shell language
• Visual Basic for Application
• Object Oriented languages with large libraries
  Smalltalk, Java.
• Disparate applications combined with CORBA
  (Common Object Request Broker Architecture)
• Becoming increasingly common with more and more
  libraries, of notably OO, components available.

12

• 6.7.6 User Interface Prototyping
• It is impossible to pre-specify the look and feel
  of a user interface in an effective way
  prototyping is essential
• 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
• The final user interface may be implemented in a
  different language than the prototype e.g. from
  VB to VC (for professional products) or from
  VC to hand coded GUI (e.g. air traffic control
  screen)
• A sound software engineering principle is that
  the interface layer of a system should be as
  independent from the rest of the application as
  possible (see notion of low coupling)
• allows for easy maintenance of the UI
• allows for distributed UIs
• allows easier portability e.g. same application
  but with different interface on Linux, Windows
  the Web
• easier localisation of products (a German, a
  French an English version of the same product)

13

• 6.7.7 Summary
• Prototyping can be a very effective technique for
  clarifying requirements (throw away prototyping)
  or as a principle for software development
  (phased development iterative and incremental
  software process)
• Rapid development is essential for throw away
  prototypes. This may require leaving out
  functionality or relaxing non-functional
  constraints
• Do not be tempted to keep a prototype that was
  intended to be thrown away.
• In throw away prototyping start with least well
  understood requirements
• In an iterative approach start with most well
  understood requirements
• An incremental approach requires a specification
  and an initial software architecture
• Using prototyping techniques is not without risk
  for the software project.

14

• Prototyping is essential for parts of the system
  such as the user interface which cannot be
  effectively pre-specified.
• Users/Customers must be involved in prototype
  evaluation.