Prototypes: Tools That Can Be Used and Misused

Kevin Dolan, Research Analysis and Maintenance, Inc.

Over the last several years, the software engineering community has placed greater emphasis on using prototypes to help the process of producing reliable software products that meet customer requirements. Prototypes are excellent tools for improving the communications between software developers and end- users as well as for providing managers with information needed to conduct cost, schedule, and functionality tradeoff analyses. However, if prototypes are misused and not developed as part of a well-defined software development process, they can be the root cause of long-term project management and software lifecycle maintenance problems. This paper discusses some legitimate ways for using software prototypes as part of a planned software development process and some of their detrimental side effects when not used properly.

Thayer defines a prototype in engineering to be:

"A full-scale model and functional form of a new system or subsystem. (A prototype does not have to be the complete system--only the part of interest.)"[1]

Thayer further defines prototyping as a strategy for giving the designer and customer early visibility into the actual functioning and operational behavior of a system. As described by Boehm[2] and by Clapp[3], these definitions conform to some of the ways to use prototypes during the requirements definition phase to minimize development risks due to incomplete requirements, and to assess whether a user interface can be developed that will allow the designated system to operate effectively. These papers reinforce the use of prototypes during the requirements definition phase in order to understand the required functionality of a system. In a separate article, Rombach[4] describes how prototyping is intended to help in the process of developing an acceptable requirements product or to explore the technical feasibility requirements and risks associated with implementing all or a limited set of the overall requirements. "Prototyping is a way of learning 'fast' about crucial project issues." The expectation is that this upfront investment pays off by detecting early on that it is infeasible to continue the project or by creating an acceptable requirements product that allows predictable and controllable software evolution. The goal is only to reuse the experience gained during the prototyping process and to feed that experience back into the creation of better requirements, and not necessarily to reuse any products created as part of the prototyping process. Rombach further states that after acceptable requirements have been created, the regular software process can follow any other lifecycle model. Prototyping is therefore a tool that can be used as an integral part of an overall software development process in order to gain a better understanding of some objective system.

In developing a draft version of the Military Standard for Software Development and Documentation (SDD)[5], B. Boehm provided the government with information on the many possible software development lifecycle models currently employed by software engineers. The SDD grouped these models into three major categories. The following is a synopsis of these categories along with the phases most applicable to using prototypes.

Figure 3. Evolutionary model

Each of these generically categorized lifecycle models provide software engineers and managers with a framework for developing software within an organized, controlled, and well-disciplined environment. As discussed, prototypes can be used as an integral part of each model. But, a distinction must be made between a prototype and a planned operational build resulting from either the Incremental or Evolutionary models. The prototype's primary purpose is to assist in the development of either a finished product meeting all of a customer's needs, or a preliminary product meeting a subset of those needs. The prototype software, in and of itself, is not usually designed with attributes such as efficiency, functionality, and maintainability as major quality factors. The prototype will usually employ a quick design that focuses on a representation of those aspects of the software that will be visible to the user, and this is where the risks to misusing the prototype seem to be the greatest.

For example, a software development process could specify using the Grand Design approach and a prototype to help clarify some of the more "fuzzy" types of requirements. After clarifying these requirements the plan would be to proceed with the preliminary design, detailed design, coding, integration, and acceptance testing phases. But if, as documented by Pressman [6:377], the customer sees the prototype as an operational version of the software, unaware that the prototype is held together "with chewing gum and baling wire," unaware that in the rush to get it working, overall software quality or long-term maintainability issues were not considered; then, when informed that the product must be rebuilt, the customer becomes impatient, crying foul and demanding that a "few fixes" be applied to make the prototype a working product. Too often, software development management relents. When this happens, the original Grand Design process is essentially abandoned, an ad hoc plan is accepted, and discipline breaks down. Software developers, who were originally planning on an orderly development, begin to sense a lack of leadership. On the other hand, management, who had initially staffed itself to develop software using the Grand Design process, is now forced to develop the plans and allocate the resources to try to switch to an incremental or evolutionary approach to complete the remaining requirements. In the meantime, the customer, who is now using the prototype in an operational environment, has identified some previously undetected "minor" problems that need "tweaking." In effect, the prototype has jumped into the lifecycle maintenance phase; and management, who had not prepared to enter the maintenance phase this early in the development schedule, is now torn between allocating resources to support the prototype's operations, maintenance, and change control processes and supporting the remaining build(s) needed to complete the system. What happens next is probably based more on the personalities involved in the process than on any software engineering principles; but in all likelihood, the software developers will begin to take matters into their own hands. Outside of a prototype with spiraling costs and schedules, management will have yet another lesson taught but not necessarily learned.

Another misuse of the prototyping concept is to confuse it with operational build type of software. For example, even though it may be understood at the beginning of a project that requirements will be defined and operational capabilities will be provided to the customer in an evolutionary fashion, the term prototype is used to describe the first and possibly even follow on builds. Just the use of the word prototype lulls management into thinking that a "formal" software development process with explicit phase points using an evolutionary type of process for each build is not really required because it's "just a prototype." Accordingly, management does not recognize the requirement to allocate the resources needed to ensure that the quality attributes normally required in delivered software are included in each delivered prototype. They fail to monitor the prototype's operations, maintenance, and change control processes while the remaining prototypes are being defined and developed. This failure to recognize the need to maintain the prototype as an operational piece of software can then have the same negative effects as in the first example. Maintenance of the initial prototype (really build) and the follow on prototypes begin to vie for the same scarce resources and discipline breaks down. The primary difference in this example is that the failure to maintain a well-disciplined software development environment is due to a misunderstanding of the true objectives of each prototype among management, software developers, and the customer, as opposed to a breakdown in discipline to follow a predefined process. These types of misunderstandings consistently lead to cost and schedule overruns and dissatisfied customers.


Prototyping is an invaluable tool that can be used as part of a well- defined process to improve communications with customers during requirements and design tradeoff analyses. However, if there is not a clear understanding among all interested parties as to the true objectives of the prototype and how it fits into a well-defined software development process, the quality of the final software product delivered to a customer becomes more dependent upon the people working on the effort than on the quality of the processes employed by management to produce reliable and consistent products.

Kevin Dolan
Research Analysis & Maintenace, Inc.
1790 Lee Trevino Drive, Suite 600
El Paso, TX 79936-4525
Voice: 915-592-7047 ext. 113
Fax: 915-595-0559


  1. Thayer, R.H., and M. Dorfman, Standards, Guidelines, and Examples on System and Software Requirements Engineering, IEEE Computer Society Press, p. 541, 1990.
  2. Boehm, B.W., "A Spiral Model of Software Development and Enhancement," ACM Software Engineering Notes 11,4, pp. 14-24, August 1986.
  3. Clapp, J., "Rapid Prototyping for Risk Management," Proceedings COMPSAC 87, Washington, D.C., IEEE Computer Society Press, pp. 17-22, 1987.
  4. Rombach, H.D., "Software Specifications: A Framework," SEI Curriculum Module SEI-CM-11-2.1, Carnegie Mellon University, p. 7, January 1990.
  5. Military Standard, Software Development and Documentation, Working Draft 4, Software Development Standards and Ada Working Group, p. 66, October 1992.
  6. Pressman, R.S., A Manager's Guide to Software Engineering, McGraw-Hill, Inc., pp. 377-379, 1993.