Proto Typing

  • View
    215

  • Download
    0

Embed Size (px)

DESCRIPTION

Explanation

Transcript

Prototyping: Guidelines for Professionals

Prototyping

Puneet Ralhan

CIS 732

Fall 2000

12/18/2000

Table of Contents3Introduction

3Prototype Development

4Methodology

4Types

6Paperboard Prototypes

6Contextual Prototyping

7Prototype Evaluation

7Protocol Analysis

8Cognitive Walkthrough (Normans Model)

9Communicability Evaluation

9Expert Reviews

10User Participation

11Rapid Ethnography

12Experience Prototyping

12Tools

13Hypermedia Management Tools

14Interface builders Tools

144th Generation Systems

15Object-Oriented Application Frameworks

15Shortcomings of current tools

16Web Applications Prototyping

17Benefits

19Final Thoughts

20References:

20Articles

21Books

Introduction

Software customers / users usually find it very hard to express their real requirements and it is almost impossible to predict how a system will actually be used and how it will interact with other systems in the users workspace. Careful requirements analysis along with systematic review of the requirements helps reduce the uncertainty of what a system should do but there is no real substitute for trying out a requirement before committing to it. This is possible if a prototype of the system to be developed is available.

Prototyping is a development approach used to improve planning and execution of software projects by developing executable software systems (prototypes) for experimental purposes. It is very suitable for gaining experience in new application areas and for supporting incremental or evolutionary software development.

Prototyping has many objectives including evaluation of the design, functionality and user interface. This report will be focusing on the user interface aspect with some linkage to the functionality. A function defined in the specification may seem useful and well defined but when the users finally try to use the application they find that their view was incorrect. Prototypes thus let user validate and evaluate their requirements and thus users can discover requirements omissions early in the process. Rapid Application Development Methodology uses development of the prototypes by the software team, working closely with the users in the requirements identification phase. Then these prototypes are either discarded (throw away prototypes) or enhanced (evolutionary prototypes) into production systems.

In the last decade the biggest development has been the advent of the Web based applications where development times are short, large amount of functionality a must and the user interface critical. Prototyping techniques have been adapted to serve this purpose and there is a portion of this report that will be focusing on the Web Applications.

Prototype Development

Thompson, Wishbow [1992] state that rapid prototyping allows members of the development team to confirm whether the product interface (this can include its online documentation) can be easily learned and used. Goals for rapid prototyping include:

Conducting iterative testing and revision early in the product development cycle. This approach allows user testing to be an integral part of product design.

Using measurable objectives (benchmarks) for user performance and attitude. Empirical measures prevent the endless debate that can sometimes follow user testing. If subject behavior falls below the benchmark there is little doubt among team members that something must be done.

Using simple, proven testing techniques. The think-aloud protocol method advocated by Newell and Simon, and discussed frequently in the technical communication literature allows for efficient data collection. If the coding scheme is kept simple, reviewing data and reporting results can be accomplished in a matter of a few days. Protocol analysis also has the virtue of requiring only a small subject sample.

Methodology

A methodology [Purtilo, Larson, Clark. 1991] that can be used for development of prototypes is:

Identify Objectives: First, a definition of the problem to be solved must be expressed, along with the criteria by which its success is to be judged.

Identify Risk: No realistic software effort can expect a clear and complete statement as the result of a step labeled define the problem, as the above item might suggest. In the gray and uncertain areas of the problem definition lurk great risks. These gray areas of risk must be identified and made explicit.

Formulate Prototyping Hypotheses: Once the risk areas have been expressed, the developer is in a position to design experiments to specifically address those risks. Each experiment addresses a hypothesis concerning the nature and potential remedy of the risk to a products success. The hypothesis should include explicit linkage to the parts of the project that may be affected.

Construct Prototype System: A system that implements the hypothesized solution must be developed. Traditional programming practices are too expensive to make this practical in many situations. Thus there is a need to use specialized tools that facilitate inexpensive prototyping.

Instrument Prototype: Since the primary purpose of constructing a prototype is to answer one or more questions concerning its functional or other characteristics, it will usually be necessary to gather dynamic information regarding the operation of the software. In a large prototype, the complexity and volume of information is likely to exceed the limit of a single persons ability to comprehend it. It would be desirable to use automated tools for this purpose.

Experiment: The prototype system must be exercised to determine its behavior and gather the output from the system instrumentation.

Evaluate Results: The results of the experiments must be evaluated to assess the efficacy of the hypothesized solution.

Repeat. This entire process is repeated until one of three outcomes is reached:

sufficient information has been derived from the prototyping activities to begin the development of a product

no solution to the problem can be found or, equivalently, that the solution would be too complex or costly to be of benefit

the prototype system itself is of sufficient quality to serve as the production-quality system or, that it can be modified to serve as the production-quality system at less cost than a full-scale production-quality development effort.

Often the prototyping phase is considered as a part of the requirements gathering phase and are outsourced to a vendor (external / internal) and then bids are gathered for the development of the production system.

Types

There are three types of prototypes [Sommerville, 1995]

Throwaway Prototypes

Evolutionary Prototypes

Incremental Development

Throwaway prototypes essentially use prototypes to clarify functional / user interface requirements and also help the managers identify any potential risks. Once the prototype is evaluated and the requirements updated the prototype is discarded and the development starts afresh. The main problem faced in this approach is when the management is tempted to take the prototype and enhance it into the real application. I actually have seen this in my professional life and this can lead to problems like uncontrolled changes during the prototyping stage, design compromises while adding new features and missing features like security, performance & reliability at base levels. Since the prototype is not the final product the cost of iterations should be kept well in control because of the tendency of the development team to go into too many details of the application and then tempting to reuse some of that application in the final product.

Evolutionary prototyping is based on developing an initial application and then iterating through multiple user evaluations and improvements. The important aspect of this is that the application has to be written in an environment that allows such development. A good language for such application development would be Visual Basic or Powerbuilder. The important aspects are that the design should be updated thoroughly at every iteration to avoid any possibility of compromises being introduced in the application.

Incremental development is the methodology where each delivered production software is taken as a prototype and after the evaluation by the users the changes and suggested and incorporated in the next release. This is a useful in the environment where the development cycles are small and the user group is anxious to get some functionality for being able to work. The main drawback in this methodology is that the system architecture needs to be determined initially and any changes to the architecture could lead to compromises in the application robustness/reliability.

Baumer, Bischofberger, Lichter, Ziillighoven [1996] concluded that:

The reuse of prototypes for the development of a target system can only be recommended if the development tools produce prototypes with clean system architecture. Many presentation prototypes are planned as throw always for this reason.

There is a strong trend for one team to carry out the entire development cycle. Due to lack of know-how many organizations are still dealing with different teams for prototyping and the development of target systems.

A newly emerging trend is to use prototypes as a vehicle for developing and demonstrating visions of innovative systems. This source for innovation can be tapped not only for individual software projects but also for various kinds of marketin