Fred Brooks's classic, The Mythical Man-Month, is as fresh today as it was in 1975. Technology has changed the world in drastic ways, but many foibles of software project management remain the same. Decades ago, Brooks said:
In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved
When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers...
It is this concept of building a pilot, or prototype system that led to the "structured," "evolutionary" rapid prototyping model, the RAD model, and the spiral model. In his later, equally wise work, "No Silver Bullet, the Essence and Accidents of Programming," Brooks believes that most software development errors still have to do with getting the system concept wrong, not the syntax or the logic. Software development will always be difficult, and there will never be a magic panacea or silver bullet. He offers a positive note in the application of rapid prototyping techniques:
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants.
One of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements.'-^
Watts Humphrey, best known as the inspiration for the SEI CMM, supports Brooks in the importance of requirements and evolution:
There is a basic principle of most systems that involve more than minor evolutionary change: The system will change the operational environment. Since the users can only think in terms of the environment they know, the requirements for such systems are always stated in the current environment's terms. These requirements are thus necessarily incomplete, inaccurate, and misleading. The challenge for the system developer is to devise a development process that will discover, define, and develop to real requirements. This can only be done with intimate user involvement, and often with periodic prototype or early version field tests. Such processes always appear to take longer but invariably
end up with a better system much sooner than with any other strategy.J—1
Definitions of Prototyping
According to Connell and Shafer, an evolutionary rapid prototype is:
An easily modifiable and extensible working model of a proposed system, not necessarily representative of a complete system, which provides users of the application with a physical representation of key parts of the system before implementation. An easily built, readily modifiable, ultimately extensible, partially specified, working model of the primary aspects of a proposed system
And Bernard Boar defined a prototype as "a strategy for performing requirements determination wherein user needs are extracted,
presented, and developed by building a working model of the ultimate system—quickly and in context.'"J—1
Description of the Structured Evolutionary Prototyping Model
Prototyping is the process of building a working replica of a system. The prototype is the equivalent of a mock-up, or "breadboard," in the hardware world.
Evolutionary programs are conducted within the context of a plan for progression toward an ultimate capability. This strategy also requires the development of increments of software demonstrable to the user, who is involved throughout the entire development process.
A "quick" partial implementation of the system is created before or during the requirements definition phase. The end users of the system use the rapid prototype and then supply feedback to the project team for further refinement of the requirements of the system. This refinement process continues until the user is satisfied. When the requirements definition process has been completed, through the development of rapid prototypes, the detailed design is derived and the rapid prototype is fine-tuned using code or external utilities to create a final working product. Ideally, the prototyping model is evolvable—nothing wasted—and of high quality—no skimping on documentation, analysis, design, testing, and so on. Hence, the name is "structured rapid prototyping model," as shown in Figure 4-11.
Figure 4-11. The Structured Evolutionary Rapid Prototyping Model
Figure 4-11. The Structured Evolutionary Rapid Prototyping Model
The life cycle begins in the center of the ellipse. User and designer develop a preliminary project plan from preliminary requirements. Using rapid analysis techniques, user and designer work together to define the requirements and specifications for the critical parts of the envisioned system. Project planning is the first activity of the rapid analysis phase, producing a document outlining rough schedules and deliverables.
The project plan is created, and then a rapid analysis is performed, followed by database, user interface, and function creation. The second activity is rapid analysis, during which preliminary user interviews are used to develop an intentionally incomplete high-level paper model of the system. A document containing the partial requirements specification is output from this task and used to build the initial prototype that is created in the next three phases. The designer constructs a model (using tools), a partial representation of the system that includes only those basic attributes necessary for meeting the customer's requirements. Next the rapid prototype iteration loop begins. The designer demonstrates the prototype; the user evaluates its performance. Problems are identified then, and the user and designer work together to eliminate them. The process continues until the user is satisfied that the system represents the requirements. The project team will remain in this loop until the user has agreed that the rapid prototype accurately reflects the system requirements. Creation of the database is the first of these phases. After the initial database is set up, menu development may begin, followed by function development—a working model. The model is then demonstrated to the user for suggestions for improvements, which are incorporated into successive iterations until the working model proves satisfactory. Then formal user approval of the prototype's functionality is obtained. Next, a preliminary system design document is produced. The prototype iteration phase is the heart—through scenarios provided by the working model, the user may role-play and request successive refinements to the model until all functional requirements are met. When the user approval has been obtained, the detail design is derived from the rapid prototype and the system is tuned for production use. It is within this tuning phase that the rapid prototype becomes a fully operational system instead of a partial system during the prototyping iteration loop.
A detailed design may be derived from the prototypes. The prototype then is tuned using code or external utilities, as required. The designer uses validated requirements as a basis for designing the production software.
Additional work may be needed to construct the production version: more functionality, different system resources to meet full workload, or timing constraints. Stress testing, benchmarking, and tuning follow, and then comes operation maintenance as usual.
The final phase is operation and maintenance, which reflects the activities to move the system into a production state.
There is no "right" way to use the prototype approach. The result may be thrown away, used as a foundation for enhancement, or repackaged as a product, depending on the original objectives, the process used, and the desired quality. Clearly, cost and schedules benefit from evolutionary prototyping because no components are "thrown away."
Strengths of the Structured Evolutionary Rapid Prototyping Model
When ap-plied to a suitable project, the strengths of the structured evolutionary rapid prototyping model can be seen in the following ways:
® The end user can "see" the system requirements as they are being gathered by the project team—customers get early interaction with system.
® Developers learn from customers' reactions to demonstrations of one or more facets of system behavior, thereby reducing requirements uncertainties.
® There is less room for confusion, miscommunication, or misunderstanding in the definition of the system requirements, leading to a more accurate end product—customer and developer have a baseline to work against.
® New or unexpected user requirements can be accommodated, which is necessary because reality can be different from conceptualization.
® It provides a formal specification embodied in an operating replica.
® The model allows for flexible design and development, including multiple iterations through life cycle phases.
® Steady, visible signs of progress are produced, making customers secure.
® Communications issues between customers and developers are minimized.
® Quality is built in with early user involvement.
® The opportunity to view a function in operation stimulates a perceived need for additional functionality.
® Development costs are saved through less rework.
® Costs are limited by understanding the problem before committing more resources.
® Risk control is provided.
® Documentation focuses on the end product, not the evolution of the product.
® Users tend to be more satisfied when involved throughout the life cycle.
Weaknesses of the Structured Evolutionary Rapid Prototyping Model
When applied to a project for which it is not suited, the weaknesses of this model can be seen in the following ways:
• The model may not be accepted due to a reputation among conservatives as a "quick-and-dirty" method.
• Quick-and-dirty prototypes, in contrast to evolutionary rapid prototypes, suffer from inadequate or missing documentation.
• If the prototype objectives are not agreed upon in advance, the process can turn into an exercise in hacking code.
• In the rush to create a working prototype, overall software quality or long-term maintainability may be overlooked.
• Sometimes a system with poor performance is produced, especially if the tuning stage is skipped.
• There may be a tendency for difficult problems to be pushed to the future, causing the initial promise of the prototype to not be met by subsequent products.
• If the users cannot be involved during the rapid prototype iteration phase of the life cycle, the final product may suffer adverse effects, including quality issues.
® The rapid prototype is a partial system during the prototype iteration phase. If the project is cancelled, the end user will be left with only a partial system.
® The customer may expect the exact "look and feel" of the prototype. In fact, it may have to be ported to a different platform, with different tools to accommodate size or performance issues, resulting in a different user interface.
® The customer may want to have the prototype delivered rather than waiting for full, well-engineered version.
® If the prototyping language or environment is not consistent with the production language or environment, there can be delays in full implementation of the production system.
® Prototyping is habit-forming and may go on too long. Undisciplined developers may fall into a code-and-fix cycle, leading to expensive, unplanned prototype iterations.
® Developers and users don't always understand that when a prototype is evolved into a final product, traditional documentation is still necessary. If it is not present, a later retrofit can be more expensive than throwing away the prototype.
® When customers, satisfied with a prototype, demand immediate delivery, it is tempting for the software development project manager to relent.
® Customers may have a difficult time knowing the difference between a prototype and a fully developed system that is ready for implementation.
® Customers may become frustrated without the knowledge of the exact number of iterations that will be necessary.
® A system may become overevolved; the iterative process of prototype demonstration and revision can continue forever without proper management. As users see success in requirements being met, they may have a tendency to add to the list of items to be prototyped until the scope of the project far exceeds the feasibility study.
® Developers may make less-than-ideal choices in prototyping tools (operating systems, languages, and inefficient algorithms) just to demonstrate capability.
® Structured techniques are abandoned in the name of analysis paralysis avoidance. The same "real" requirements analysis, design, and attention to quality for maintainable code is necessary with prototyping, as with any other life cycle model (although they may be produced in smaller increments).
When to Use the Structured Evolutionary Rapid Prototyping Model
A pro-ject manager may feel confident that the structured evolutionary rapid prototyping model is appropriate when several of the following conditions are met:
® When requirements are not known up-front;
® When requirements are unstable or may be misunderstood or poorly communicated;
® For requirements clarification;
® When developing user interfaces;
® For proof-of-concept;
® For short-lived demonstrations;
® When structured, evolutionary rapid prototyping may be used successfully on large systems where some modules are prototyped and some are developed in a more traditional fashion;
® On new, original development (as opposed to maintenance on an existing system);
® When there is a need to reduce requirements uncertainty—reduces risk of producing a system that has no value to the customer;
® When requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when application not well understood;
® When developers are unsure of the optimal architecture or algorithms to use;
® When algorithms or system interfaces are complex;
® To demonstrate technical feasibility when the technical risk is high;
® On high-technology software-intensive systems where requirements beyond the core capability can be generally but not specifically identified;
® During software acquisition, especially on medium- to high-risk programs;
® In combination with the waterfall model—the front end of the project uses prototyping, and the back end uses waterfall phases for system operational efficiency and quality;
® Prototyping should always be used with the analysis and design portions of object-oriented development.
Rapid prototyping is well suited for user-interface intensive systems, such as display panels for control devices, interactive online systems, first-of-a-kind products, and decision support systems such as command and control or medical diagnosis, among others.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.