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.)"
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 and by Clapp, 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 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), 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.
a. The Grand Design model essentially defines all requirements of the system, designs software to satisfy those requirements, develops the system based on the design, integrates, tests, and finally delivers a totally complete software system to a customer. As shown in Figure 1, DoD Standard 2167A employs the Grand Design approach to software development. Using this process, a prototype could easily be used during the system requirements analysis or software requirements analysis phases to help clarify or define requirements, or it could be used during any of the design phases to examine alternative design approaches. The information gained from using these prototypes would be formally presented to decision makers at the respective system requirements review, system design review, software specification review, preliminary design review, or critical design review prior to proceeding into the next phase.
b. The Incremental model, similar to the Grand Design approach, determines user needs by defining all requirements, but then proceeds to design, develop, test and possibly deliver the software in a scheduled set of builds. Each successive build satisfies a subset of the overall requirements. Figure 2 depicts a modified version of the DoD-Standard 2167A approach that could be used to implement this model. Using this model, a system level prototype could be used prior to the system requirements or system design reviews to help clarify or define requirements, or to assist in tradeoff analyses to determine which sets of requirements should be included within each build. One or more prototypes could also be used during the requirements analysis or design phases for each build. In fact, each build can be looked upon as an evolutionary prototype of the predefined objective system as specified by the requirements. However, unlike a prototype, which is designed primarily to clarify requirements or investigate design options, each build can be delivered as an operational piece of software providing additional capabilities. Accordingly, the Incremental Build approach must allocate the resources for operations and maintenance functions as well as provide for a mechanism to integrate the changes that result from operational use of the software into each succeeding build by implementing a change control process.
c. The Evolutionary Model recognizes up front that all requirements needed to define the system are not fully capable of being implemented, and then proceeds to develop software as a set of builds. However, unlike the Incremental approach, only the requirements needed to support the first build need to be defined as opposed to all the requirements. Figure 3 shows an Evolutionary approach with DoD Standard 2167A types of milestones to monitor the software development process. The entire process can be viewed as an elliptical spiral with expanding requirements and capabilities along the GO-NO-GO major axis. In Quadrant I of the spiral, an appropriate set of requirements for a build are determined. In Quadrant II the requirements are further analyzed, the risks associated with trying to implement the build are evaluated, and a decision is made as to whether or not resources should be allocated to the build development effort. In Quadrant III each build's detailed design and development is completed. The build with the agreed-upon set of requirements is then delivered to the customer for evaluation in Quadrant IV. This model assumes that the evaluation period will allow the customer to define new requirements for the next build, and because each build is providing the customer with at least some operational capability, resources must be allocated to the operations, maintenance, and change control processes that have to accompany each build. In addition, discrepancies uncovered in Quadrant IV through the change control process also provide the feedback needed to modify requirements or design flaws uncovered during operational use. The Evolutionary Model is considered complete once all requirements have been defined and implemented in the final build. Using this process prototypes in Quadrant I or II could be used to clarify a specific build's requirements or to evaluate design options and the risks associated with trying to implement a particular build. According to Pressman [6:379], this evolutionary approach to software engineering enables the developer and customer to understand and react to risks at each evolutionary level. It maintains the systematic stepwise approach suggested by the classic lifecycle, and it also incorporates an iterative framework that more realistically reflects the real world.
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.
Research Analysis & Maintenace, Inc.
1790 Lee Trevino Drive, Suite 600
El Paso, TX 79936-4525
Voice: 915-592-7047 ext. 113