PROTOTYPING

© 1997 by Walter Maner (unless otherwise noted)
May be reproduced only for non-commercial educational purposes.

The outline below requires Netscape/Microsoft browsers, version 3.x or later, for correct viewing.

Revised March 15, 1997
  1. Back Top Next
    PICTURE
  2. Back Top Next
    DEFINITION OF PROTOTYPE
    An easily modified and extensible model (representation, simulation
    or demonstration) of a planned software system, likely including its
    interface and input/output functionality
  3. Back Top Next
    CHARACTERISTICS OF A PROTOTYPE
    1. TYPES OF PROTOTYPE
      1. LOW-FIDELITY versus HIGH-FIDELITY
        1. LOW-FIDELITY
          A set of drawings (e.g., storyboard) that provide a static,
          non-computerized, non-working mock-up of user interface for
          the planned system
        2. HIGH-FIDELITY
          A set of screens that provide a dynamic, computerized,
          working model of the planned system
      2. EXPLORATORY versus EXPERIMENTAL versus OPERATIONAL
        1. EXPLORATORY
          A throw-away prototype used to clarify project goals, to
          identify requirements, to examine alternative designs, or to
          investigate a large and complex system
        2. EXPERIMENTAL
          A prototype used to validate system specifications
        3. OPERATIONAL
          An iterative prototype that is progressively refined until
          it becomes the final system
      3. HORIZONTAL versus VERTICAL
        1. HORIZONTAL
          A prototype that models many features but with little detail
          • a horizontal slice of a system's structure chart from the
            top down to a specific depth
          • most useful in the early stages of design
          • purpose is to test the overall interaction metaphor, so
            includes common functions that the user is expected to
            perform frequently
        2. VERTICAL
          A prototype that models few features but with much detail
          • a vertical slice of a system's structure chart from top
            to bottom
          • most useful in the later stages of design
          • purpose is to test details of the design
        3. DIAGONAL
          A prototype that is horizontal down to a particular level,
          then vertical below that point
      4. GLOBAL versus LOCAL
        1. GLOBAL
          A prototype of the entire system
          • an expanded horizontal prototype that models a greater
            number of features and covers multiple levels of the
            system's structure chart
          • useful throughout the design process
        2. LOCAL
          A prototype of a single usability-critical system component
          • a vertical prototype that is focused on one feature
          • useful at some specific stage of the design process
    2. DIMENSIONS OF PROTOTYPING
      1. EXECUTABILITY
        Will the prototype be runnable and, if so, what does that mean?
        1. CHAUFFEURED PROTOTYPE
          "runnable" in the VERY LOOSE SENSE that the prototype allows
          a walkthrough to be performed
        2. ANIMATION PROTOTYPE
          runnable in the LOOSE SENSE that it is executes frame by
          frame in "slide show" mode on a computer
        3. TURING PROTOTYPE
          "runnable" in the sense that it executes in "slide show"
          mode BUT allows a third party, hidden from view, to pick the
          next slide based on user input (also called "Wizard of Oz"
          prototyping)
        4. INTERACTIVE PROTOTYPE
          runnable in the STRICT SENSE that it executes on the
          computer AND responds to user input in real time
        5. FUNCTIONAL PROTOTYPE
          runnable in the VERY STRICT SENSE that it executes on the
          computer, responds to live input, and performs some of the
          expected computations
      2. MATURATION
        Will the prototype be improved by stages and, if so, will it
        eventually grow into the final product?
      3. REPRESENTATION
        What level of fidelity will the prototype achieve?
      4. SCOPE
        Will the prototype be limited to specific areas of
        functionality?
    3. CHARACTERISTICS OF A GOOD NON-DISPOSABLE PROTOTYPE
      1. EXECUTABILITY
        Works sufficiently well with live user input to permit
        usability testing
      2. MATURATION
        Can evolve, given sufficient refinement, into the final product
      3. REPRESENTATION
        Has the "look and feel" and performance characteristics of the
        planned system
      4. SCOPE
        As a minimum, simulates the 20% of the functions that customers
        will use 80% of the time
  4. Back Top Next
    THE PROTOTYPING PROCESS
    Many variations
    1. Perform customer needs analysis in a JAD session but leave
      requirements incomplete.
    2. Build a low-fidelity prototype to clarify initial requirements.
    3. Iterate (re-specify, re-design, re-evaluate) until the team, both
      users and developers, agree that the fidelity and completeness of
      the evolving prototype are sufficiently high.
    4. Freeze these specifications.
    5. Finish building the product exactly as prototyped.
    6. NOTE: The prototyping process experiences a series of birthdays
      while traditional software development experiences a series of
      deadlines.
  5. Back Top Next
    WHEN DO YOU PROTOTYPE?
    1. BEFORE THE BEGINNING
      to show proof of concept to senior management
    2. IN THE BEGINNING
      to gather initial user requirements
    3. AFTER THE BEGINNING
      to validate evolving user requirements
    4. IN THE MIDDLE STAGES
      to validate system specifications
    5. IN MIDDLE AND LATER STAGES
      to pre-train users or to create a marketing demo
    6. IN THE LATER STAGES
      to explore solutions to specific usability or design problems
  6. Back Top Next
    WHAT TO CONSIDER UP-FRONT BEFORE BUILDING A PROTOTYPE
    1. Breadth of functionality needed in the prototype at first, later
      on
    2. Choice of prototyping tool and its limitations
    3. Completion criteria for the iteration cycle
    4. Composition of the team (users, developers, other stakeholders)
    5. Level of fidelity needed in the prototype at first, later on
    6. Maximum length of an iteration cycle
    7. Purpose of the prototype at first, later on
    8. Ways to manage conflict between team members, build consensus
  7. Back Top Next
    PROBLEMS CAUSED AND CURED BY PROTOTYPING
    1. PROTOTYPING MAY ADDRESS THE PROBLEM OF ...
      1. communication between developers and customers
      2. customer acceptance
      3. delivering early proof of concept
      4. fuzziness in early stages of design
      5. gathering valid requirements
      6. increasing constructive user participation
      7. managing change requests
      8. product invisibility
      9. quality assurance
    2. PROTOTYPING MAY INTRODUCE THE PROBLEM OF ...
      1. deciding how much iteration is enough
      2. gauging progress without traditional milestones
      3. managing conflict between developers and customers
      4. managing the schedule for a development cycle that is
        essentially open-ended
      5. processing excess change requests from customers
      6. runaway customer expectations
    3. DEALING WITH PARTICULAR PROBLEMS
      1. HOW DO YOU PREVENT RUNAWAY EXPECTATIONS DURING PROTOTYPING?
        1. Build the expected performance into the prototype, using
          delays (timing loops) if necessary.
        2. Develop realistic specifications.
        3. Distinguish between primary and secondary requirements.
        4. Give customers a crash course in software development.
      2. HOW DO YOU KNOW WHEN YOU ARE DONE PROTOTYPING?
        1. When you run out of time or money (default criterion)
        2. When the prototype meets all the requirements of the final
          system
        3. When the prototype has a limited purpose (e.g., gathering
          initial requirements) and that purpose has been achieved
        4. When, in horizontal prototyping, you reach the target level
          (depth) in the system structure chart
        5. When developers and users jointly agree to move on to the
          next stage
  8. Back Top Next
    PROTOTYPING TOOLS
    1. FEATURES NEEDED IN A RAPID PROTOTYPING TOOL
      1. MOST IMPORTANT FEATURES
        1. Should create a working prototype with which users can
          interact
        2. Should make it easy to create, develop and modify screens
        3. Should simulate the look and feel of the planned interface
      2. OTHER DESIRABLE FEATURES
        1. Should allow calls of external procedures and programs
        2. Should allow playback of user trials
        3. Should allow scientific collection and review of user
          interaction data
        4. Should be able to simulate the expected performance
          characteristics of the planned system (e.g., by using
          timers)
        5. Should exhibit the look and feel of the target operating
          system
        6. Should generate much of the code needed to implement the
          interface design
        7. Should import reusable software components of various kinds
        8. Should import text, graphics, sound and other media
        9. Should leverage industry-standard APIs and standard
          libraries
        10. Should make it easy to change task order
        11. Should make it easy to change window order
        12. Should make it easy to create simple animations
        13. Should make it easy to modify tasks
        14. Should make it easy to sequence and re-sequence windows
        15. Should provide a seamless transition from design to
          implementation
    2. TYPES OF PROTOTYPING TOOLS
      From less formal to more formal
      1. Pencil and paper
      2. Drawing software
      3. Demo makers (e.g., Demo-It)
      4. Animation and slide-show software
      5. Perl + Motif + Tcl/Tk (UNIX)
      6. "Visual" RAD tools such as Visual Basic, Optima++ and Borland
        Delphi
      7. 4GLs
      8. UIMSs (User Interface Management Systems)
      9. Executable specification languages (VDM variants)
  9. Back Top Next
    EVALUATION OF PROTOTYPING
    1. BENEFITS AND RISKS OF PROTOTYPING
      1. ADVANTAGES (BENEFITS)
        1. NUMBER 1 BENEFIT
          Prototypes may be easily changed or even discarded.
        2. NUMBER 2 BENEFIT
          Prototyping may improve communication between and among
          developers and customers
        3. NUMBER 3 BENEFIT
          Users may be more satisfied with systems developed using
          prototyping.
        4. A prototype may provide the proof of concept necessary to
          attract funding.
        5. A prototype may serve as a marketing tool.
        6. A prototype may serve as the basis for operational
          specifications.
        7. Early visibility of the prototype may help management assess
          progress.
        8. Exploratory prototyping allows productive work to proceed
          despite initial uncertainties.
        9. Prototypes may demonstrate progress at an early stage of
          development.
        10. Prototypes may provide early training for future users of
          the system.
        11. Prototyping may prevent unpleasant surprises by calling
          attention to incomplete or inconsistent requirements, or to
          missing functionality.
        12. Prototyping may produce some useful deliverables even if the
          project runs out of time or money.
        13. Prototyping may reduce misunderstandings between and among
          developers and customers.
        14. Prototyping may reduce redesign costs if problems are
          detected early when they are cheap to fix.
        15. Prototyping may reduce the time required for testing if
          problems are detected early when they are cheap to fix.
        16. Prototyping may require less effort (43% less, according to
          Boehm, Gray & Seewaldt, 1984) than conventional development.
        17. Prototyping may result in a 50-50 partnership between users
          and developers where both experience "ownership".
        18. Prototyping may result in a product that is a better fit for
          the customer's requirements.
        19. Prototyping may save on initial maintenance costs because,
          in effect, customers are doing "acceptance testing" all
          along the way.
        20. Prototyping may strengthen requirements specifications.
        21. Systems produced through prototyping may be judged easier to
          learn and easier to use.
        22. The horizontal prototyping method works nicely as a
          complement to structured analysis.
        23. The prototyping environment less vested in a particular
          design, hence more open to change and innovation.
        24. Use of prototypes may flush out change requests earlier,
          when they are cheaper to process.
        25. Users may understand prototypes better than paper
          specifications.
        26. Using prototyping during development may reduce the amount
          of code that is finally written (by 60%, according to Boehm,
          Gray & Seewaldt, 1984).
      2. PITFALLS (RISKS)
        1. NUMBER 1 RISK
          Prototpying may encourage an excess of change requests.
        2. NUMBER 2 RISK
          Working prototypes may lead management and customers to
          believe that the final product is almost ready for delivery.
        3. NUMBER 3 RISK
          The excellent (or disappointing) performance characteristics
          of prototypes may mislead the customer.
        4. Customers may not be prepared to provide the level or
          frequency of feedback required for iterative prototyping.
        5. Customers may not be willing to participate in the iteration
          cycle over the long haul
        6. Developers may have difficulty writing the back-end code
          needed to support the slick front-end interface designed
          with the prototyping tool.
        7. Due to time and market constraints, system specifications
          may be frozen before the prototyping process has reached a
          definitive stage.
        8. During prototyping, the only "design specification" is the
          prototype itself, which may allow uncontrolled change.
        9. Early prototypes may be of low fidelity, dismissed as toys.
        10. Hi-fidelity prototypes may be mistaken for a real product.
        11. Important system characteristics (e.g., performance,
          security, robustness and reliability) may have been ignored
          during prototype development.
        12. It may be impossible to prototype mission- or
          safety-critical system functions.
        13. Iterative prototyping may be difficult for management to
          plan and schedule.
        14. Prototypes may become over-evolved, straining to incorporate
          secondary functionality even though that will take
          disproportionately more development time.
        15. Prototypes may embody simplifications and other
          inaccuracies.
        16. Prototypes may oversell the product.
        17. Prototypes of complex systems may themselves be rather
          complex.
        18. Prototyping is an adaptive process that may not exhibit
          well-defined phases.
        19. Prototyping may continue too long because there may be no
          well-defined completion criterion.
        20. Prototyping may force developers to change design
          philosophies (e.g., switch to a bottom-up or an event-driven
          model).
        21. Prototyping may provide little room for testing
          NON-functional system requirements.
        22. Prototyping may stall if members of the team do not have
          enough decision-making authority.
        23. Prototyping, because it may be less controlled than
          conventional development methods, may lead to a reduction in
          programmer discipline.
        24. Specifications that emerge during later prototyping may
          reduce the structural integrity of the partially designed
          system (e.g., increase coupling between modules).
        25. The context of use for a prototype may be very different
          from the context of use for the final system.
        26. There is no guarantee that the positions of developers and
          customers will converge during the iteration cycle.
    2. WHEN PROTOTYPING WORKS AND WHEN IT DOESN'T
      1. PROTOTYPING IS MORE LIKELY TO SUCCEED WHEN ...
        1. used as a means to achieve early usability testing
        2. used to compare alternative designs (the "dueling
          prototypes" technique)
        3. used to create a "living" specification
        4. used to escape from the rigid serial pattern imposed by the
          traditional software development life cycle
        5. used to evaluate a proposed interface
        6. used to explore the effect of change requests
        7. used to expose new or unexpected requirements
        8. used to identify market requirements
        9. used to involve users in the design process
        10. used to model a system that has a significant user interface
          component
        11. used to model a system that is relatively large and complex
        12. used to provide a common basis for good communication
          between developers and customers
        13. used to stimulate customer input during requirements
          gathering
        14. used within a rapid prototyping tool
      2. PROTOTYPING IS MORE LIKELY TO FAIL WHEN ...
        1. no clear terminating criterion has been established to end
          the iterative development cycle
        2. the expectations of customers are allowed go grow beyond
          reasonable bounds
        3. the functionality of an operational prototype does not scale
          up to the functionality required of the final system
        4. the opinions of developers and customers diverge during the
          iterative phase
        5. the project is too small to justify prototyping
        6. the prototype is mistaken for the promised product
        7. used to model systems that present no external interface
          (e.g., embedded systems)
        8. used to gauge the future performance of the planned system
        9. used to market software that does not exist