Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Say your customer is demanding cross-platform functionality. You execute an elegant design that works on all required machines, only to discover that most of your effort was wasted, since cross-platform support was needed for only one of the five major system components. Such communication failures between developers and business users constitute a major stumbling block in the development process, since developers think in technical terms, and business customers speak a different language about costs, benefits and business drivers.

Throughout a project lifecycle, prototypes can serve as a vehicle to facilitate mutual understanding and help keep a project focused on business needs, while providing timely answers to uncertainties about performance and system limitations.

Beyond their most common use to refine system concepts and reduce uncertainty about implementation in the design phase, prototypes can be employed even earlier—during the sales phase—to engage the customer. And, with a little thought and planning, post-project prototyping can provide a "capital investment" in learning, with benefits that reverberate long after the project is over.

Enhancing Understanding
Prototyping typically focuses on a particular feature of an application without considering formal design, documentation, maintainability or other constraints. Traditionally, prototypes are throwaway code created to rapidly answer specific technical questions.

Prototyping can help to:

Elucidate requirements. A prototype can "translate" the domain vocabulary of users into concrete aspects of a system. For example, a prototype can convert a general set of workflow or task descriptions into a sequence of GUI screens and controls displaying well-defined data. This process begins the design of the presentation layer with something that all observers can identify and discuss. It also anticipates the early stages of data layer design.

Detect missing elements. Though customers can't always tell you exactly what they want, when presented with a specific approach to a problem—such as "Is this all the information we need for the customer trouble ticket?" or "Do you like this screen layout or that one?"—they're 100% reliable in telling you when you get it wrong. Thus, a well-designed prototype or a set of prototypes can help rein in the range of possible interpretations and quickly get things steered in the right direction.

Using concrete prototypes early in the project can have the salutary effect of getting everyone on the same page. By showing a prototype to a customer, you're much more likely to expose hidden assumptions, or incompatible or missing requirements. Though the customer may assume that you know exactly what he or she is thinking, it's wise to show the limits of your understanding by developing a prototype that demonstrates exactly what you heard—and what you didn't.

Prototyping thus requires you to be open with your customer, sometimes leading to the rude realization that you had completely misinterpreted the customer's intent. Painful as this is, it's better to learn sooner than later. Even if you end up with egg on your face, you'll be letting your customer know that you want to get it right.

Demonstrate feasibility. A prototype can answer specific questions about high-risk aspects of the system design that impact everything else. For example, performance of a known processing bottleneck in a message queue can be instrumented and tested. Prototype solutions produced with two different design approaches can be empirically compared.

Perhaps a customer wants to use a new vendor reporting tool, but is uncertain if it's compatible with a legacy system on a particular platform. Why speculate and incur risk when the question can be answered definitively with an up-front investment in a focused prototype?

Promote agreement on priorities. As customers and development organizations work together on system requirements, they must also produce realistic

plans for allocating resources within time and budgetary constraints. Often, the customer's wish list exceeds reality, so priorities must be established.

Beyond clarifying feature content and allowing better effort estimates for the work, prototypes can often help customers decide on trade-offs and timing of features in different phases or release plans. To accomplish this, they need to understand the consequences of the priority ordering of features in the same way they'd want to examine different "what if" scenarios when rebalancing an investment portfolio or producing a fiscal year budget.

Prototypes can be used to test the real cost of different strategies for making phased changes to a database by simulating or measuring processing time, documenting difficulties in restoring the database when a failure occurs, or revealing the costs of maintaining interim data models with various approaches. Prototypes can demonstrate how end users are impacted to a greater or lesser extent by phasing in one set of screens before another, or by inserting new off-screen procedures to supplement a changed workflow process. A well-designed prototype can quantify the costs and uncertainties of different approaches, thus facilitating a more rational, cost-justified basis for planning.

Usable Interfaces
So how do you quickly build the better GUI, database or servlet that your customer is clamoring for? Here are some tips.

With a GUI, develop a storyboard approach. Graphical user interfaces provide a sequence of screens requesting user input and displaying data. From the end user's point of view, GUI screens represent tasks to be carried out, and screen transitions constitute the workflow. Bearing this in mind, developers should use prototypes to learn what users need as the new system evolves into a new way of working.

Labels on screens and the range of valid values for input fields define a system vocabulary. Do you understand what each item means? Here, the prototype serves as a vehicle to ask the questions. The flow of screens defines how the work flows. What happens when the system fails? Listen carefully to the user's description of failure conditions—it's likely to differ significantly from that of managers and system operations personnel, and this difference may reveal missing requirements, interactions with external systems or performance constraints—all of which are important to discover as soon as possible.

The Data Layer
With a database, provide a stub implementation. Almost any prototype will require access to data to simulate realistic interactions and to address meaningful questions about the proposed system.

Even in a prototype, strive for a clean architectural separation between the data tier and the presentation and processing tiers. If the prototype involves a GUI, design and implement a simple object model of the data by focusing on the data items on each GUI screen. But you should also learn how the various task/screen data items map to the underlying data model. You may uncover issues that will significantly affect database design (if this is an option), or that may require a more robust processing-layer design for joining data to meet presentation-layer display needs or system performance criteria.

Taking care of the database layer in prototyping is a double win: Customers can get answers to questions about performance, feasibility, maintainability and so on, and developers can think ahead toward design and implementation.

Keep It Simple
Make it flexible and extensible. Since one question often leads to another, a prototype should be able to evolve. With a little forethought and judicious choice of tools and technologies, a prototype aimed at one question can become a framework for answering others. Customers may well extend the inception or elaboration phase of the project if they feel that your prototype is able to answer a range of questions.

Table-driven configuration and simple screen-navigation frameworks can help make GUI-oriented prototypes flexible. XML encapsulation of data sources can make parsing and translation activities more easily extensible. Use of the façade design pattern can facilitate integration with diverse legacy systems, thus allowing extension of a prototype to good benefit.

Choose a familiar and productive technology environment. As in any development project, it's best to prototype in the target deployment environment. However, fast is better than slow, and that often means going with what you know. If a performance bottleneck is known to lurk within a DBMS, you need a simple client test program to focus a prototype on a different stored procedure, indexing approach or table schema. It doesn't matter if you build it on Unix or NT—even though the application will eventually reside on NT—just use what's convenient. As another example, if the solution space involves Java, don't spend any time worrying about the specific application server, Web server or operating system you use in prototyping, since the work will exhibit a high degree of portability in any case.

Reduce, Reuse, Recycle!
Though prototypes may be considered "throw-away" tools, why not be green? At a project's end, prototypes should be evaluated like other project artifacts to identify lessons learned and opportunities for reuse. The cost of a properly designed prototype—that anticipates reuse opportunities—can be amortized, and its value extended, across multiple projects.

The following "best practices" will encourage reuse of prototypes:

Don't build prototypes in private environments. Instead, create "sandboxes" for prototype development that provide maximum administrative support with minimum constraints. The sandbox should be a mixture of operating systems, tools and middleware from market-leading vendors in the technologies you use. For example, if you're doing J2EE-based development, choose two or three cross-platform application servers and deploy them on Unix, Linux and/or NT, as appropriate. If you're focusing on Microsoft .NET, allocate system administration resources to keep up with beta programs for that platform. Deploy a lightweight source-control tool and use naming conventions for simple project directories that allow maximum flexibility. If you can afford it, also deploy memory profiling, round-trip engineering and design tools.

Insist on a design review process, or at least in-house demonstration and discussion of the prototypes used. By definition, prototypes evolve on-the-fly, but with a little bit of peer review, developers can benefit from the experience and concrete suggestions of others in both strategy and implementation.

Building a prototype is often a great learning experience for the immediate developer, but it can also provide meaningful hands-on learning tasks for others. Prototypes focus on real-world problems, but are sized "just right" to provide developers with ample education. In contrast with traditional training materials and test programs, prototypes are well beyond the J2EE version of "Hello World," yet they're much more focused than those unreadable encyclopedias of APIs that fill the walls of a bookstore's computing section. Prototypes in a sandbox lab are also cheaper than a stand-up training vendor, and the original developer can often be corralled to answer questions.

With a little effort and foresight, your prototypes can be flexible and lasting tools that bridge the communication gap with your customers and extend your skills across multiple projects.

RELATED ARTICLES What Zope Did Wrong (and How It's Being Fixed) Ubuntu and the Software Around It Simply Rails 2 WSO2's Open Source Enterprise Service Bus The Eclipse Ganymede Release		TOP 5 ARTICLES No Top Articles.