Based on key factors, such as the problem to be solved or the mandate of the customer, determine the purpose of the prototype.Select the type of prototype that best satisfies the purpose.The possible types of prototypes include:

·concept prototype,

·feasibility prototype,

·horizontal prototype,

·vertical prototype,

·functional storyboard.

A chart illustrates typical purposes for each kind of prototype.

Type of Prototype

Typical Purpose

General Characteristics

When to Use

Concept Prototype

Analyze system approaches

High-level, overall vision

Concept Definition Stage

Feasibility Prototype

Determine feasibility of various solutions

Proof of concept for specific issues

Concept Definition Stage

Horizontal Prototype

Clarify scope and requirements

Demonstrates outer layer of human interface only, such as windows, menus, and screens

Function Definition Stage

Vertical Prototype

Refine database design, test key components early

Demonstrates a working, though incomplete, system for key functions

Later portion of Function Definition Stage

Functional Storyboarding

Determine useable sequences for presenting information

Demonstrates the typical order in which information is presented

Function Definition Stage

Determine What to Prototype

Based on the purpose of the prototype, select a subset of information to prototype (e.g., an approach, issue, human interface, or key function).

A detailed description of the different types of prototypes can help with the process of determining what type of prototype to build:

Description of a Concept Prototype

A Concept Prototype is a high-level application prototype that illustrates the overall vision with respect to functionality, design, structure, and operational characteristics of a system.

It usually describes the required "look and feel" of the human interface, system business scope, system topology, and other factors that contribute to the vision.This prototype may be completed on-line, on paper, or with a combination of both.

A Concept Prototype is usually developed during the early stages of defining the system architecture.

Scope of Concept Prototype

The scope of the Concept Prototype will vary with its intended purpose.The level of detail will vary depending on the specific circumstances of each project and the project terms of reference.In principle, the prototype is conceptual at this point because applications and technologies are considered as types rather than as specific vendor products, and because implementation issues have not yet been addressed.In practice, several aspects of the technology platform will often be dictated by previous investments and/or certain vendor products may be obvious.

One possible objective for completing a Concept Prototype is to assist the project team and the customer in understanding the problem (e.g., the prototype is an application with minimal breadth and minimal depth).

Benefits of a Concept Prototype

Sometimes the concept of an application needs to be tested and refined to determine the desirability of a system before funds are committed.The Concept Prototype can be used to stimulate creative thinking about a system from both customers and analysts or compare the attractiveness of alternative approaches.

Concept Prototypes can be presented to steering committees to help decide which of the proposed systems will be built given the finite development resources.Committee members can appreciate the potential benefits of each competing application.

Systems that cross organizational boundaries require compromise and agreement from a wide range of diverse groups to be implemented successfully.Systems need to address political realities as well as operational ones.A Concept Prototype provides a way to uncover consensus issues early.

Description of a Feasibility Prototype

To establish the feasibility of a solution, all of the pieces must fit together properly.The Feasibility, or Technical, Prototype proves out some technical assertion that is key to the feasibility of the preferred alternative.It verifies that critical components of the technical architecture integrate properly and are capable of meeting the business needs.

Scope of Feasibility Prototype

The kinds of integration problems examined with a Feasibility Prototype are too complex to be addressed with paper analyses and simple reviews of manufacturers' specifications.Physical access to the equipment is required.Proof of concept tests are constructed to validate a conceptual solution.

Description of a Horizontal Prototype

A Horizontal, or User Interface, Prototype is a model of the outer shell of an entire system, i.e., windows, dialogue boxes, menus, screens, reports, and batch processes, with little or no processing behind them.It typically contains all of the system functions on menus, but includes only dummy screens, reports, and database queries (if applicable) for core functions.

Initially, the Horizontal Prototype is unlikely to contain any processing logic behind the external features.In later stages, the Horizontal Prototype may be expanded to eventually evolve into the final system.

A Horizontal Prototype is usually developed during the early stages of analysis.

Purpose of Horizontal Prototype

The Horizontal Prototype is developed to:

·define project scope,

·demonstrate the external features of the system (e.g., windows, menu bars, and reports), as a means of communicating an understanding of the requirement.

Use Automated Tools

Automated CASE tools can significantly reduce the time required to generate a Horizontal Prototype.If automated tools are not available, a paper prototype can be prepared.Although it requires a little more imagination, the analyst can walk through a paper prototype with the customer as if it were an automated prototype.

Horizontal Prototype Versus Interviewing

Horizontal Prototyping is recommended in addition to interviews when the principal objective of the interviews is to define specific requirements related to the external design of a system.

Modelling the external features of a system with a Horizontal Prototype greatly enhances communication between the analyst and the customer.This productive interaction sometimes results in more concrete and useable output than can be gained from interviews.Customers find it easier to respond to a suggested approach demonstrated by a Horizontal Prototype, than to define their requirements or problems with the existing systems in an interview.

Develop a Horizontal Prototype

Reflect proposed functionality in a set of screens in a Horizontal Prototype.

Character-based screen designs may be implemented using menus to decompose the functionality for the Horizontal Prototype.Menus allow analysts and customers to understand the total proposed system in layers, with each layer providing a more detailed view of the functionality.

GUI screen designs offer many graphical objects, such as check boxes, radio buttons, and list boxes that allow users to navigate through the windows.

Description of a Vertical Prototype

A Vertical Prototype contains a stripped down version of the core functions of the system.These functions provide the ability to enter data and store it in a database, as well as the ability to display data on query screens and reports.

A Vertical Prototype includes some user functionality but, more importantly, access to data.This can demonstrate to the user a "working" system, although not one that is fully functional or tuned.

Vertical Prototypes do not normally include:

·edits and controls,

·security features,

·audit trails,

·exception handling,

·record locking.

The Vertical Prototype is normally developed during the later stages of analysis.

Vertical Prototype Requires a Corresponding Data Model

Do not develop a Vertical Prototype without reference to a corresponding data model or database.Without a corresponding data model, unrealistic expectations for system externals may be created that prove difficult to implement.

How to Build a Vertical Prototype

The steps to follow to build a Vertical Prototype are:

·Determine the core functions of the system; i.e., the functions that should be part of the prototype.

·Determine any temporary structures required to replace non‑core functions.For example, in an accounting system, vendor files are not critical to the functionality but you need vendor data in a file to be able to demonstrate payables.In this case, table maintenance routines are developed to build vendor files.

·Design and build a preliminary database or make a copy of an existing database.

·Build temporary structures.

·Identify and develop key modules and functions.

·Design and develop core functions.

Benefits of a Vertical Prototype

A Vertical Prototype provides the opportunity to test and refine the core application features and physical database design at an early stage.

By providing the customer with a Vertical Prototype, considerable development effort can be saved.Key components of a system can be tested before design is fully underway.The stripped down versions of the programs can be modified to accommodate the requests for changes that inevitably surface once the customer has a working model.However, beware of the "give them everything they ask for" trap that increases complexity and the risk of failure.Accommodating customer change requests must be compared against the added value of the change and the additional prototyping costs.

Description of Functional Storyboarding

Functional Storyboarding is a method of modelling a business function to define the user interface and the application flow.A storyboard contains frames that represent screens or Web pages that you intend to build for the application that is being prototyped.The frames are arranged in the order that they are intended to be viewed, to demonstrate the functionality of the proposed application.

Storyboards display only important functionality, along with any output the functions will generate.The input requirements naturally evolve during the evaluation of the storyboard.

Recommended Use

Use Functional Storyboarding to help the user see how the customer business functions map to system functions.For example, assume a business function of a manufacturing company is to mail out new product information to distributors.The process involves checking off each distributor name from a master list, as a package is prepared for mailing. When the business function is automated, the system requires the user to:

·generate a list of distributors by selecting a geographic area,

·double click on a distributor name in the list to display the details of the distributor,

·fill in the appropriate field on the screen to indicate that a package has been sent,

·save the changes and exit the screen,

·bring up the next distributor, and repeat the process.

Storyboard frames help the user appreciate how different a business function can become when it is automated.

Size of a Functional Storyboard

Depending on the business function, one storyboard could contain 20 to 400 frames.Effective storyboards do not need to display every possible feature.They are meant to demonstrate the important functions.

How to Build a Functional Storyboard

To build a Functional Storyboard:

·Decide on the important aspects of the business function that you are prototyping.

·Identify the major steps involved in conducting the functionality.

·Design the screens required to complete each step following the guidelines in Human Interface Design.The screens (i.e., frames) may be hand drawn, but an automated tool is recommended to ease their creation and modification.

·Create a template to represent common elements that are shared among the frames (e.g., headers, footers, or tool bars).Create the individual elements that form the templates for each type of frame.

·Build the required frames using the templates.

·Assemble the frames to display in a sequence that matches the application flow of the proposed system.Re-use and redisplay frames, if necessary, to demonstrate the business function.

·Use a storyboard tool to playback the frames.Many storyboard tools allow you to create and playback frames that represent the screen displays in the prototype.

The functional storyboard displays depict the user interface of the system.The sequence of the displays simulates the functionality of the system.There is no code behind the storyboards, unlike the Vertical Prototype which allows the user to interact with the computer.The frames are arranged in the order they would be invoked in a working system.This arrangement of screens distinguishes it from a Horizontal Prototype which shows the screens but does not show how the screens interact.

References

The reference below provides additional information on storyboarding and identifies several storyboarding tools.The appendices contain several case studies that used storyboarding to model business functions:

Prototypes can be paper or software.Paper prototypes are frequently used in the earliest stages of a project to help the customer visualize requirements.Paper prototypes also help to enhance the usability of a system.

On-line prototypes are necessary for a feasibility prototype that verifies the plausibility of a technical solution, and for a vertical prototype that requires reference to data.On-line prototypes help the customer visualize the system more realistically, but are more expensive than paper prototypes.

Consider Longevity

Consider whether the prototype is to be a throw away version or is to be retained and developed into the final system.There are advantages and disadvantages to both methods.

If a vertical prototype is to be retained, programming standards definition and some detailed logic definition must occur before the prototype is built.Defining standards and guidelines before developing a prototype reduces the risk that a prototype will be discarded.It is advantageous to continue to develop the prototype into the final system to benefit from the cost and development effort of the prototype.However, caution must be taken to keep the process of developing the prototype under control.An unchecked number of iterations could result in higher cost or a convoluted product.

There is some risk in deciding to stay with a prototyping approach simply to recover the investment in the prototype.Sometimes the lessons learned from the prototype are its value, not the prototype itself.It may be best to start over rather than inherit known flaws in the prototype.Automated CASE tools make flaws less of a risk but an analyst must be willing to throw away a prototype when a fresh start will improve the end product.

Whether it is cost effective to develop a throw away prototype depends on:

·The complexity of the system functions, database, and architecture.The more complex the application, the more likely the throw away prototype can be cost justified.

·The environment (e.g., languages) being used.For example, Visual Basic may be used to develop a prototype that will eventually be developed in C.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.