Pages

Thursday, May 21, 2009

Prototyping

Software prototyping, refers to the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that occurs during certain software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.
The conventional purpose of a prototype is to allow users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. Prototyping can also be used by end users to describe and prove requirements that developers have not considered, so "controlling the prototype" can be a key factor in the commercial relationship between developers and their clients. Interaction design in particular makes heavy use of prototyping with that goal.
Prototyping has several benefits: The software designer and implementer can obtain feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.
This process is in contrast with the 1960s and 1970s monolithic development cycle of building the entire program first and then working out any inconsistencies between design and implementation, which led to higher software costs and poor estimates of time and cost.[citation needed] The monolithic approach has been dubbed the "Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can also avoid the great expense and difficulty of changing a finished software product.
The practice of prototyping is one of the points Fred Brooks makes in his 1975 book The Mythical Man-Month and his 10-year anniversary article No Silver Bullet.

Overview
The process of prototyping involves the following steps

  1. Identify basic requirements, determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
  2. Develop Initial Prototype, the initial prototype is developed that includes only user interfaces.
  3. Review, the customers, including end-users, examine the prototype and provide feedback on additions or changes.
  4. Revise and Enhance the Prototype, using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed.


Dimensions of prototypes
Nielsen summarizes the various dimension of prototypes in his book Usability Engineering

Horizontal Prototype
A common term for a user interface prototype is the horizontal prototype. It provides a broad view of an entire system or subsystem, focusing on user interaction more than low-level system functionality, such as database access. Horizontal prototypes are useful for:

  • Confirmation of user interface requirements and system scope
  • Demonstration version of the system to obtain buy-in from the business
  • Develop preliminary estimates of development time, cost and effort.


Vertical Prototype
A vertical prototype is a more complete elaboration of a single subsystem or function. It is useful for obtaining detailed requirements for a given function, with the following benefits:

  • Refinement database design
  • Obtain information on data volumes and system interface needs, for network sizing and performance engineering
  • Clarifies complex requirements by drilling down to actual system functionality