A new rapid prototyping model
Zhanshan Gao
In this paper, I first introduce the two traditional process models called waterfall model and iterative model respectively plus an object-oriented programming (OOP) model. Then I explain in some details about the rapid prototyping models. In this paper, an example of prototyping model shows us how successfully Microsoft company uses this kind of process model to build software. After analyzing the essentials of classical rapid prototyping models and the essentials of the example, I propose a new software prototyping model called whole-scale evolutionary rapid prototyping model. This paper also analyzes the characteristics of the new approach and its advantages and disadvantages. By the way, the new approach is partially abstracted from my working experience and the knowledge I got from this course.
Keywords: Process model, prototype, rapid prototyping
Index
A lot of papers discuss software process models(Connell1989, Cusumano1997, Evans 1988, Humphrey1989, Kan 1995, Mullin1990,Sommerville 1992). Most of them talk about Waterfall, prototyping, and spiral model. (Kan 1995) generalizes the spiral model and prototype into iterative development model. In addition, (Kan 1995) provides an OOP model which is now getting popular. (Humphrey 1989) provides some extreme models such as atomic model - A model. Actually, A model is a bottom-up model which does not give much guidance in software process development.
1.1 Waterfall model (Cusumano1997, Evans 1988, Humphrey 1989, Humphrey1995, Kan 1995)
In the 1960s and 1970s, software development projects were characterized by massive cost overrun and schedule delays; the focus was on planing and control. The emergence of the waterfall process to help tackle the growing complexity of development projects was a logic event.
The waterfall process model is used to specify what the software is supposed to do (gather and define system requirements) before development begins. After the requirement is defined in specification, it then breaks the complex mission of development into several logic steps (design, code, test, and so forth) to schedule the project and then the development begins, following what is outlined in the specification and design.
The divide and conquer approach of the waterfall process has several advantages like other top-down approaches. It enables organization to track project progress more accurately and discover possible problems at early stages of the product life cycle, especially for large or huge projects. It demands that the process generate a series of documents that can later be used to test and maintain the system. The bottom line of this approach is to make large software projects more manageable and delivered on time without cost overrun.
However, the waterfall models are extremely sensitive to task sequence, since it assumes that the project follows a relatively uniform and orderly sequence of development steps. Consequently, simple change can destroy the entire framework. Like other top-down approaches, the higher-level definition would directly affect those in the lower-levels, therefore, once some aspects of a product is missed, it is very hard or impossible to add those into the complete product.
Back to index...
1.2 Iterative model(Kan 1995)
The iterative enhancement (IE) approach or the iterative development process(IDP) is defined to begin with a subset of the essential requirements and then develop a subset of the product that satisfies the essential needs of the users. Based on the analysis of each intermediate product, the design and the requirements are refined over a series of iterations to produce a system that meets evolving customer needs with improved design based on feedback and learning.
The IDP model combines prototyping with the strength of the classical waterfall model. Other methods such as domain analysis and risk analysis can also be incorporate into the process model.
Actually, spiral model can be regarded as a specific IDP model, while the term IDP is a generic rubric under which varying forms of model can exist.
Fig. 1 illustrates the main procedure of iterative models.
The main purpose of iterative model is to avoid the shortcomings of waterfall models and it address the requirements changes. The changes will be accommodated in the next iterative cycle.
Different from traditional programming, in object-oriented programming, an object is a set of data and operations (methods) that can operate on data. The OOP process can be divided into 8 step:
1. Model the essential system
The essential system describes those aspects of the system required to make it achieve its purpose. It is composed of essential activities and essential data. This step focuses on user requirements. Requirements are analyzed, dissected, refined, combined, and organized into an essential logical model of the system.
2. Derive candidate essential classes
This step uses a technique known as "caving" to identify candidate essential classes and methods from the essential model of the system. A complete set of data-flow diagrams, along with supporting process specifications and data dictionary entries, is the basis for class and method selection.
3. Constrains the essential model
The essential model is modified to work within the constrains of the target implementation environment. Essential activities and essential data are allocated to the various processors and constrains. Additional activities are added to the system as needed.
4. Derive additional classes
Additional candidate classes and methods specific to the implementation environment are selected based on the additional activities added while constraining the essential model.
5. Synthesize classes
The candidate-essential classes and candidate-additional classes are refined and organized into a class hierarchy. Common attributes and operations are extracted to produce superclasses and subclasses. Final classes are selected to maximize reuse through inheritance and importation.
6. Define interfaces
The interface, object-type declaration, or class definition are written based on the documented synthesized classes.
7. Complete design
The design of the implementation module is completed.
8. Implement solution
The implementation of the classes is coded and unit tested.
The analysis phase of the process consists of steps 1 and 2, the design phase consists of steps 3 to 6, and the implementation phase consists of steps 7 and 8. Within the steps of analysis and design, it is expected that several iterations are involved. Prototyping may also used to validate the essential model and to assist in selecting the appropriate classes and methods.
Although OOP model is different from the traditional ones (waterfall and iterative models), the mean features of this OOP is actually a waterfall model. It is also a top-down approach.
From the above introduction, we know that the waterfall model has the shortcoming of lacking flexibility of adjustment of the design. Once the document is done, all the implementation should follow that specification. To avoid this, some authors propose the rapid prototyping models (Humphrey1989, Iivari 1995, Jazayeri 1997, Kan1995). A focus on customer's requirements and unmet needs can be powerful and unifying force(Wheelwright 1992). Right now, almost all the prototyping models focus on customers' requirements.
2.1 Different kinds of prototyping models
Fig. 2 illustrates the main idea of classical prototyping models. The critical difference between Waterfall model and prototyping approach is quick turnaround between designing and prototyping. There are several techniques that can be used to facilitate achieving such an objective. Existing similar modules or specification could make the design and implementation of prototype easier. Designer can quickly modify existing design to outline the new characteristics of the new project. Formal specification languages, such as fourth-generation languages (4GL) can be used to create executable code. Therefore, the end user can figure out the main features of the proposed product. This section discusses mainly about some types of prototyping models.
2.1.1 Rapid Throw away Prototyping
It is used to analyze the most risk items that the developer has not much experience about that problem. In this model, quick and dirty prototypes are built, verified with customers, and thrown away until a satisfactory prototype is reached, at which time, full-scale development begins. The following stages works like the traditional the corresponding part of waterfall model.
2.1.2 Quick and Dirty Prototyping
Quick and dirty is term describing the approach of quickly bring up a version of a system, then modifying it until the customer can grant minimal approval. The programs are modified based on the feedback from the user as they see the output. Unlike rapid throw away prototyping, quick and dirty prototyping might be kept to modify. The software is almost sure to be expensive. This approach is rarely accompanied with documents.
2.1.3 Detail Design-Driven Prototyping
The model is complete and as perfect as it can be made to be. It is then test-driven to uncover any defects which can be corrected before delivery of the final product. The sort of prototyping is problematic because it is so detailed - analysis and design documents being allegedly complete-that it will be expensive to change all the documents and the system when prototype demonstrates uncover unexpected or undesirable results, having the similar shortcomings of waterfall models. Actually, this kind of prototyping is much like a traditional waterfall process model instead of a prototyping model.
2.1.4 Evolutionary Prototyping
In the evolutionary prototyping approach, a prototype is built based on some known requirements and understanding. Contrast to rapid throw away prototyping, this model is then refined and evolved . Whereas throwaway prototypes are usually used because of poorly understanding of the new system, evolutionary prototypes are more likely to be used to evolve based on the best understanding of the system and thus build on the development team's strength.
2.2.1 Small versus large application system
In the early days of rapid prototyping, the tools for prototyping had very poor performance characteristics, making them unsuitable as implementation vehicles for system that featured large numbers of concurrent users or large amounts of stored data. Thus evolutionary prototyping was only applied to small application systems. With the introduction of prototyping tools with much better performance characteristics, and the additional features which make possible combination of prototype modules and modules produced using standard software development techniques within the same system, a prototype of a large system may be evolved into the final deliverable system.
One of the problems with discussing small versus large application systems concerns how one measures system size. As a general rule, systems that have evolved from prototypes will have fewer lines of code and small amounts of stored data than traditionally developed systems. One-line of 4GL may replace 40 or more statements in a third generation procedure language. A visually programmed module may contain no visible lines of code at all. Evolved prototypes will also be easier for maintenance staff to understand and modify throughout the useful life of the system. Prototyped systems tend to be smaller and simpler, even though they often solve large problems.
2.2.2 Real-time versus Data processing systems
The critical issue for real-time system is often response time. The tools available today for prototyping offer a means for improving the response time of prototype modules to a level equal to that of traditional developed software. The modularity of an evolutionary prototype-combined with an integrated environment with the interfaces to other types of development environments-is what provides an evolutionary prototype with the ultimate in flexibility. Example of prototyping User Interface Systems versus Embedded systems
2.3.1 Quality Assurance and control
Rapid prototyping could be considered a quality assurance technique, since its primary benefit and ultimate objective is to greatly meet the requirements of the user by the functionality of delivered software. Quality control is built into a rapid prototyping project since users are involved in early prototype iterations during the analysis phase and some prototyping models can even response user changing requirements at other development stages. Therefore, the final product will ultimately and greatly assurance that it can meet user requirements.
2.3.2 Accommodating new or unexpected user requirements
Users are not always certain what they want requested software systems to do. Users are often accused of unfairly changing their minds about the desired functionality of a system under development during the test phase of a project. Sometimes reality is far different from conceptualizations based on paper specifications.
Rapid prototyping provides an opportunity to accommodate these changes, which basically represent creative thinking on the part of the user, early in the life cycle and at a very low cost. The result is a dramatic decrease in disruptive and costly change activity during testing and a significant reduction of costly postimplementation perfective maintenance. When users are encouraged to take an active role in the development of a system, that system stands a much better change to become a source of pride for them. Needless to say, such a psychological phenomenon is positive for system quality and prototyping is valuable in
2.3.3 Cost saving in development and maintenance
Evolutionary rapid prototyping provides two powerful new ways to help beat down the high costs of software development and software maintenance. The first one is that systems will be easier to modify in place, since the product will be developed based on previous stages which has been proven to meet user's previous requirements. The second one in which prototyping reduces maintenance costs is that need fewer modification after delivery. Since user's requirements can be reflected in the product during development, the maintenance cost after delivery will be greatly reduced.
2.3.4 User satisfaction with software systems
With prototyping, a "what you see is what you get" approach eliminates the bulk of communication problems, allow delivery of systems as least as quickly as ever, and permits the correction of errors due to bad specs in the early, inexpensive phases. When a wrong specification is designed and implemented that does not meet user requirements, even the most modern tools and technology cannot salvage the product. The more functions the system has, the more it will cost to correct the systems structure after delivery, therefore, the worse the user satisfaction is.
When users are allowed into the analysis or even into the development, they can "see" first-hand problems, errors or any misunderstanding at the early stages of product life time. Such is reassuring to a user who can observe the action. This is why "rapid" is such an important part of rapid prototyping.
First, prototyping requires the user to participate into the project as long as possible. That is the key point of prototyping. Ideally, user can follow all the development stages. However, for most projects, users are not always available. The power of the prototyping is to communicate with the customer. It is imperative that a project plan be started as the first phase of activity, and then the plan be continually refined to meet the customer changing requirements. When the number of deliverables or functions of the proposed system increases or becomes more complicated, so does the schedule lengthen, raising the cost.
Second, the iterative process of prototype might continue forever if it is not managed and monitored properly, since management is often not aware of the status of prototyping. Therefore, a successful prototyping needs efficient and effective management.
Third, there are very few prototypers and even fewer trained maintainers of prototyped systems.
In addition, there is little training available to help program get the main idea of this new way of thinking about system development.
(Cusumano 1997) shows a successful example of prototyping model. It tells us the process Microsoft uses to build software. Although the company does not use a pure prototyping process model, the main features of its process are the characteristics of rapid prototyping.
At the requirement stage, Microsoft company does not use waterfall model which would produce a large amount of document. Instead, it begins by creating a "vision statement" defining the goals for a new product and orders the user activities that need to be supported by the product features. The key point of this model is to grasp user requirements as much as possible and as soon as possible. It is easy and cost-saving to modify the "vision statement" instead of a large amount of document. After figuring out the "vision statement", product manager consult the program manager and the program manager consults the programmers to outline the main features of the product. Unlike Waterfall models which try to cover all the details of the product, the specifications in Microsoft leaves much flexibility and freedom to the programmer to accomplish. This is the main characteristic of prototyping model.
In implementation, the project manager then divides the project into parts and divides the project Schedules into several milestone junctures (sequential subprojects), representing for major portions of product, according to the priorities of the features. With regard to each of the subprojects, Microsoft uses a combination of multiple process models to achieve the greatest benefits. It uses Waterfall models to develop the subproduct, integrate the product, test the product and fix errors. In addition, it uses a special technique called "daily synchronization" to synchronize all changes. Actually the idea comes directly from software configuration management (SCM) which is what SEI advocates. Another aspect of the Microsoft model is that it uses an iteration process to evolve from one milestone to another. Each milestone is based on the previous one. The more the product evolves, the more closely the product meets user requirements. Once user changes requirements in a iteration cycle, the next iteration cycle will reflect those changes.
In general, the essentials of Microsoft process model are that it uses rapid prototyping process to outline the main features of the new product, prioritize the activities and divide the project into several parts. Each iteration is built and stabilized and evolve to the next iteration (next milestone) like a spiral model . In addition, Microsoft uses user feedback as an important mechanism to improve development.
As we can see, the waterfall model fails to make adjustment if the user changes requirements; the classical prototyping models just use prototyping at the requirement analysis and design stages; and the traditional iterative models take long time to accomplish a iteration cycle, we can generalize the classical prototyping models to accommodate changing requirements and at the same time, shorten the iteration time and increase the power of prototyping to implementation stage. Considering above, I propose a new model called whole-scale evolutionary rapid prototyping model which inherits the advantages of the classical rapid prototyping while adds new function to accommodate the user requirements. Fig. 3 illustrates the main idea of the new approach.
Whole-scale evolutionary rapid prototyping
The new approach include following 4 steps:
1. Requirement analysis
At this stage, the developers gather and analysis the customer's requirements.
2. Quick design and rapid prototyping
After the main points of the requirements are clear, the development use rapid prototyping approach to develop a quick design of the supposed system. Consult the customer for their opinions about the design. Make any changes to refine it until the customer is satisfied with it. This design should outline the most important features of the new system.
3. Implementation and rapid prototyping
Different from other traditional approaches, this model asks the customer to involve in the implementation stage. The development shows the intermediate result at every implementation stage, ask the customer to confirm that the functions work as they wish them to.
In this period, the development also apply prototyping approach to figure out the priority of the functionality, finishing them stage by stage.
Like what Microsoft does, if the project is very large, we can divide the whole implementation stage into several small parts according to the priorities of the functionality. The most important part is address and implemented first, then the next iteration involve the next most important features and so forth.
If some error or misunderstanding are found during this stage, go back quick design stage and refine the design.
4. Test &release
Because we have asked the customer to participate into the design and implementation stages, there should be much less changes at the test &release stage. However, if the customer change his mind at this stage about the main points of the requirements, go back the design and rapid prototyping stage. If the customer just want make partial changes of the system, go back implementation and prototyping stage, quick and prototype the changed requirements , and implement it. Normally, at this stage, the customer should not have too much changes, and the product can be delivered on time as scheduled.
4.1.1 Its main framework is a combination of several process models.
The main stages are like that of the waterfall model. It starts at requirement analysis, followed by design , implementation, and test &release stages. However, different from waterfall model, the design stage use rapid prototyping approach. It does not require large amount of documentation. Instead, the new approach use rapid prototyping approach. What is produced at this stage is a evolutionary quick design. It is just a vision statement of the system, describing the main features of the system. Beside the waterfall and rapid prototyping approaches, the new approach still has iterative function, from the implementation to design and from test to implementation, and from test to design. Like spiral model, the new approach allows the quick prototype evolves along with time. In general, it combines waterfall, rapid prototyping, spiral, and iterative approaches together into a new one.
4.1.2 It adds new mechanism that other approaches do not have
Classical prototyping is just used at the quick design stage, once the design is finished, customer and prototyping are all kicked out from the development. Other models ask customers to evaluate the quality and functionality of the product at the release/test stage. In this approach, customers accompany product development. They are present at every stage of the product even at the implementation stage.
Another difference is that the new approach uses prototyping is implementation stage. Classical prototyping just use prototyping for quick design.
Different from traditional iterative models which take long time to accomplish the whole cycle, the new approach use iteration just for evolvement. The new change integrate with the last iteration and evolve forward.
The new approach emphasize the important role of customer in the whole process of software development. Therefore, The customers should be available at every stage of the development. And they are willing to be involved into the whole development of the new product. If there are no available customer for a new system, the development can set up a temporary team acting as customers. If the customer and development are not at the same site, the feedback from the customers should continually flow back.
4.2.2. Cooperation between development and customer
To make the new approach most efficient, the development and the customers should cooperate together. Whenever the customers have new requirements, the new design should quick reflect that changes; whenever the customers need some new functions, the implementation should accomplish those as quick as possible. The development should quick understand the customers' requirements. Conversely, the quick design can help customers build up a clear image of their requirements and the incremental implementation can also help customers what they really need. The communication between the customers and development is most important.
To use the new approach, the prototyping personnel are needed. They use the new approach to generate quick design and can quickly figure out the real functionality needed. They can also use prototyping approach to assign priority of the requirements and functionality.
Beside the cooperation between the development, the SCM should also cooperate with the customers. Whenever there are any changes of requirements, the SCM should coordinate the changes among the whole software development process.
This new approach will greatly reduce the costs of development. Because the customers are present at all the stages of the development, they feedback the real opinion toward whatever the new functions in the both the design and implementation. This avoids that situation that the developers think they understand the users requirements, after a long development period, the customers find out the function they need is not there, and the functionality does not work as they wish. This new approach would eliminate the need of re-work from scratch. It also has the flexibility of adding new requirements whenever the user get new ideas. The product will greatly follow the requirements of the users. Otherwise, at the shipping stage, when the user provides several new requirements, they will wait for a long development cycle to receive the new features of the product. This approach save the costs for both the customer and development.
Because the users are present at all the development stages, they would be satisfied with the final shipping product. All the changed requirements are followed and all the needed functions are quickly implemented.
The whole development involves the customer. Therefore, the development can focus whatever the customer needs. This avoids any misunderstanding in the design stage, only the needed and important requirements are picked up in design and only the most important and really needed functions are implemented. The unimportant features are left for future iteration. After the most important features are finished, the next iteration can evolve from this basis to the next iteration.
As the customer are present at any time of the development, the development can best understand the user requirements. They can incorporate the changed requirements into the product whenever the user change ideas. At the design stage, the development's task is to figure out the main point of the requirements and develop a quick design. When the user want add new functionality at the implementation stage, the developer can readily delete function that is not really needed and add new function at the user's requirements. Therefore, at the test and release stage, there should be much and much less changes than other traditional approaches can have. The iteration mechanism in this model is just used to evolve from this iteration to the next iteration. The iteration is based on the previous work with which the user is already satisfied. In general, the function that is not needed is eliminated at the early stage of development, all the time is spent in the necessary work. There is no wasted time. The final product can be shipped on time.
From the procedure of the new approach, we can find out that this approach maximize the flexibility of change requirements. User do not need to wait for the final product which usually takes very long time to develop.
This new approach is a combination of waterfall, spiral, iterative, and prototyping models It has the advantages of all those models. By the way, it avoids the disadvantages of those models.
1.) Like other prototyping models, this new model still needs the developers who can convert the user requirements into prototypes.
2) SCM should greatly be involved into the change control process. It should coordinate all the changes among all the designs and modules.
3) At any time, the developers should be ready to modify or add new functionality.
4) The system structure should be designed so flexible that it should be very easy to add and remove modules without much affection to other modules or functions.
In this new approach, the customers are present at all the stages of the development and they feedback the real opinions toward whatever functions are added in the both the design and implementation. This avoids that situation that the developers misunderstand the requirements. This new approach would eliminate the need of re-work from scratch. It also has the flexibility of adding new requirements whenever the user get new ideas. This approach save the costs for both the customer and development.
The whole development involves the customer. Therefore, the development can focus whatever the customer needs. This avoids any misunderstanding in the design stage, only the needed and important requirements are picked up in design and only the most important and really needed functions are implemented. The unimportant features are left for future iteration. After the most important features are finished, the next iteration can evolve from this basis to the next iteration.
The developers can incorporate any changed requirements into the product whenever the user change ideas. Therefore, at the test and release stage, there should be much and much less changes than other traditional approaches can have. The iteration mechanism in this model is just used to evolve from this iteration to the next iteration. The iteration is based on the previous work with which the user is already satisfied. In general, the function that is not needed is eliminated at the early stage of development, all the time is spent in the necessary work. There is no wasted time. The final product can be shipped on time.
From the procedure of the new approach, we can find out that this approach maximize the flexibility of change requirements. User do not need to wait for the final product which usually takes very long time to develop.
This new approach is a combination of waterfall, spiral, iterative, and prototyping models It has the advantages of all those models. However, it avoids the disadvantages of those models.
Still there are a lots to explore for this new approach.
Connell, John L., etc (1989). Structured Rapid Prototyping, Prentice-Hall
Cusumano, Michael A. and Selby, Richard W (1997) How Microsoft Build Software?, Communication of the ACM, Vol. 40,No. 6 June 1997
Evans, Michael W. (1988). The Software Factory", John Wiley &Sons, New York.
Iivari, Juhani, etc. (1995) Advanced Information System Engineering, Springer-Verlag, Berlin Heidelberg.
Humphrey, Watts S.(1989). Managing the Software Process, Addison-Wesley
Humphrey, Watts S. (1995). A Discipline for Software Engineering" , Addison-Wesley
Jazayeri, Mehdi , etc (1997) Software Engineering ESEC/FSE'97", Springer-Verlag, Berlin Heidelberg.
Kan, Stephen H.(1995). Metrics and Models in Software Quality Engineering, Addison-Wesley.
Mullin, Mark (1990) Rapid prototyping for Object-Oriented Systems, Addison-Wesley
Sommerville, Ian (1992). Software Engineering, Addison-Wesley.
Wheelwright, Steven C.(1992). Evolutionary Product development: quantum leaps in speed, efficiency, and quantity", Free Press, New York
