Simse Rapid Prototyping Model Course Module

SimSE Rapid Prototyping Model Course Module

1.Introduction/Background

Although the rapid prototyping model depicts an entire software life cycle, we made it much more focused and did not include some of the effects that are included in the other models. For instance, this model ignores budget, considers all employees to be equally skillful at every task, and omits explicit review, inspection, testing, and correction activities (the starting narrative states that these activities are implied in the development of each artifact). These simplifications were made in order to put the focus strongly on the prototyping process and create a model that depicts an entire software life cycle but focuses on one particular aspect of that life cycle.

This model depicts a “throw-away” prototyping process in which a rapid prototype is iteratively developed with customer input, and then thrown away, after which a final version of the software is built. (This is in contrast to an evolutionary prototyping process in which the rapid prototype is evolved to become the final version of the software.) The rapid prototype is basically used as a requirements analysis tool in this model, as the process of developing the prototype and subsequently discussing the prototype with the customer is the primary means of discovering the requirements for the system.

2.How to Use This Module

This module is designed to be used as part of a course in which relevant software engineering concepts (namely, software processes and the rapid prototypingprocess model in particular) are being taught. SimSE is intended to be used as a complementary component to a course, not as a standalone instructional tool. Therefore, software engineering in general and the rapid prototyping life cycle modelin particular should be introduced to students either before, or in parallel with the students’ exposure to the rapid prototyping game (either through lectures (see Section 6), readings (see Section 7), or some other method). SimSE’s main strength lies in its ability to allow students to put concepts into practice that they otherwise would not have the opportunity to experience through other instructional methods.

Before students are given the assignment to play SimSE, it is imperative that they watch at least the SimSE Gameplay video tutorial, and strongly recommended that they also watch the Explanatory Tool and Game Branching video tutorials as well. All video tutorials are available at Our experience with SimSE has shown again and again how crucial the instruction a student receives in learning to play the game is to their success in learning from it. These video tutorials have been designed to specifically highlight and address aspects of SimSE that are critical for students to understand for a maximally effective educational experience. Therefore, we suggest that you not only assign the students to watch these videos on their own time, but, if time and resources allow, show them in class as well, emphasize how important they are to watch, and also point them to the SimSE player’s manual, available at If time and resources further warrant, students should be required to attend a TA-lead training session, in which they are shown the videos, given a printed player’s manual and, and then allowed to try playing the game for a while with the TA (who should have already studied the manual and played SimSE themselves) available to answer any questions they may have.

Students should be given the questions to answer for this module (see Section 8) at the time they are asked to play the rapid prototyping model.Having the questions to refer to while they play helps point them to some of the more subtle lessons encoded in the model, as well as provides you, as an instructor, with a way to assess whether or not they have completed the assignment and learned the concepts.

One could use this module as a mandatory part of a course, or else make it an extra-credit assignment. Especially when multiple models are assigned, the exercise is actually quite involved, so somewhere in the order of 5-10% extra credit is recommended.

3.Learning Objectives

The basic process that the model enforces and rewards is the following: (1) Outline the requirements for the system with the customer, (2) develop a prototype, (3) have the customer evaluate the prototype, (4) continue re-developing the prototype and having the customer re-evaluate the prototype until the player decides that it is time to move on, and (5) follow the waterfall model for development of the final system. (Although we could have built any one of a number of different life cycle models to follow after the rapid prototyping cycle, we chose the waterfall model because its simplicity allows us to keep this simulation model focused on the rapid prototyping process, in which the model’s central challenges lie.) Aside from this overall process, our rapid prototyping simulation model also teaches the following lessons (all taken from [1]):

A rapid prototyping approach is appropriate for situations in which the requirements are unclear or not well-known to begin with. In the starting narrative of this model, after describing what the project is, the player is told, “Your customer is not entirely sure what they want the system to do or to look like, so unearthing their requirements might take a little bit of work and creativity.” This piece of text was included specifically to hint to the player that a rapid prototyping approach should be considered in situations such as this one. When the customer is unsure of their requirements, a rapid prototype can serve as a tangible tool with which to transform vague requirements into concrete ones.
A rapid prototype can be an effective means of eliciting requirements from the customer. As mentioned previously, discussing a prototype with the customer is the primary means of discovering requirements in this model. Each time the developers bring a revised prototype to the customer for evaluation and they spend time engaging with the customer in a discussion about it, new requirements are discovered as the ability to look at and play with an executable prototype of the system gives the customer more ideas about what they want. However, there does come a point when all of the requirements that are going to be discovered are discovered, and in this model that occurs after three rounds of prototype development and customer evaluation.
Rapid prototyping can make the rest of development go more smoothly. The more complete the prototype, the faster requirements specification, design, and implementation will go. This signifies that having a prototype: (1) helps make the requirements clear and (2) gives the developers a head start on design and implementation, as they have already at least experimented with some of the design and implementation issues they will likely encounter in the development of the final system.
Rapid prototyping can have a positive impact on the quality of the resulting system. The completeness of the prototype also has a positive effect on the correctness of the subsequent artifacts (requirements document, design, and code), representing that prototyping can help to ensure that what the developers are specifying, designing, and implementing matches what the customer wants.
Too much or too little prototyping can be detrimental to the project. Despite a lengthy literature search to determine what the “right amount” of prototyping is, we found no real-world data suggesting a value—only the general consensus that too little prototyping can result in a product that does not fully meet the customer’s needs, and too much prototyping can be an unnecessary waste of time, as the return on the investment into prototyping starts to dwindle at a certain point. As a result, we set this “right amount” around 60%, meaning that the player is rewarded for developing the prototype to include about 60% of the total discovered requirements at any given point. We experimented with different numbers and found that this value did well at communicating to the player that there is a balance that must be achieved between too much and too little prototyping, and this balance falls somewhere in the middle region of the spectrum from prototyping no requirements to prototyping all of the requirements. This is enforced in the model in three ways. First, as development of the prototype begins to go past the 60% mark (indicating that they are probably spending too much time on it), the developers will announce to the player, “The customer called – he’s anxious for the prototype and wants to know what the hold up is!” This is designed to give the player a hint about what the right stopping point for prototype development is in the game. Second, the factor by which the completeness of the prototype speeds up development of subsequent artifacts (requirements, design, code) is maximized at a prototype completeness level of about 60% (meaning more than 60% of the total discovered requirements are incorporated into the prototype), and significantly levels off shortly thereafter. This is designed to illustrate that the most important requirements should be prototyped so that they can become well-understood, but if less important requirements that the customer is not too particular about begin to be included, precious time that could be spent implementing those requirements into the final system is being wasted. Third, this effect of diminishing return on investment is also present in the prototype’s effect on the correctness of subsequent artifacts. The difference between the correctness of, say, a design for which a prototype is 100% complete and the correctness of one for which a prototype is 60% complete is miniscule—about 1%.
Certain programming languages are more appropriate for prototyping than for implementation, some more appropriate for implementation than prototyping, and some are appropriate for both. The player must choose both a prototyping language and an implementation language from three choices: Visual Basic, Java, and C++. In our model, we have made the generalization that Visual Basic is the one most appropriate for prototyping, C++ is the one most appropriate for implementation, and Java falls somewhere in the middle and can be used for either one. Choosing C++ for prototyping will make development of the prototype go awfully slow. Choosing Visual Basic for implementation will make implementation go fast, but will result in decreased correctness, illustrating that a prototyping language generally does not have the capacity to implement all of the requirements for the system. Choosing Java for either activity influences the speed and correctness by an amount that is somewhere in between the two other languages.

4.Prerequisites

A student should have a basic understanding of software engineering and the rapid prototyping life cycle model.(See Sections 6 and 7 for ways to achieve this.)

5.Time Commitment

The average time to play a single rapid prototyping game is about 15 minutes, but, of course, it is likely to take several times playing the game for the student to learn the concepts and be able to answer the questions. Students should be given at least one week of out-of-class time to play the game and answer the questions (see Section 8).

6.Suggested Supporting Lectures

The slides that accompany Ian Sommerville’s Software Engineering textbook are a good resource. The latest version of these slides are available at The slides forChapters 4 and 17 include some about the rapid prototyping / throw-away prototyping model.

7.Optional Supplementary Readings

Sommerville, I., Software Engineering. 8th ed. 2008: Addison-Wesley.

8.Assignment

Instructions

First, watch the SimSE video tutorial at Then download the SimSE player’s manual at Be sure to watch the video and read the manual carefully, as they will highlight several important things that will significantly help you in successfully playing SimSE and correctly answering the questions. Then download the rapid prototyping game at (Be sure to download the game and not the model, as the model is not executable.) The download consists of a “readme” text file and an executable game, which you can run by simply double-clicking on it. If you do not have the current version of Java installed on your machine, you will have the opportunity to install it when you try to run a game.

Questions

We recommend choosing approximately five of the following questions to use with this module.

What did you find was the most successful way to approach prototyping in the game (how much prototyping is best, at what point in the process should it be done, etc.)?
What is one of the most significant benefits of having the customer evaluate the prototype?
Can you ever do too much prototyping? What is the result?
From playing the game, what can you conclude are satisfactory choices for prototyping and implementation languages?
What kinds of software projects is a rapid prototyping approach best for and why?
What are the effects of skipping prototyping altogether on the resulting requirements document? In other words, what is the difference between a requirements document for a system that has been prototyped and one that has not?
What is the effect of doing too little prototyping on the subsequent design and code that are developed?

Answers

This approach that this game most highly rewards is: (1) outline requirements with customer; (2) do approximately 3-4 rounds of prototyping (1 round = develop prototype, followed by having the customer evaluate the prototype) until about 60% of the requirements are included in the prototype; (3) do waterfall process (requirements, design, implementation). An alternative, yet equally rewarding approach that should also be accepted as a correct answer is including some requirements specification in each round of prototyping (after customer evaluation).
Customer evaluation of the prototype results in the discovery of new requirements (as the customer sees some of their preliminary requirements implemented in a prototype, it helps them solidify further requirements, and sparks ideas for new ones). Another possible answer is that it also results in higher correctness of later artifacts (i.e., requirements specification, design, and implementation), as they end up more in line with what the customer wants.
Yes. When you have a project with limited time, doing too much prototyping will cause the project to be late, and have only minimal positive effects on correctness of later artifacts.
Prototyping: Visual Basic is fastest, Java slightly slower, and C++ is the slowest, and all have equal effect on the correctness of later artifacts. Implementation: Visual Basic is fastest, Java slightly slower, and C++ is the slowest. Visual Basic results in the most errors, Java less errors, and C++ the least errors. Choosing the same language for prototyping and implementation causes implementation to be faster, due to the fact that there should be at least some reusable code from the prototype that can be used in the system implementation. Any answer that does not deviate from these rules should be accepted.
Those in which the customer is unsure of their requirements, because prototyping helps to unearth and solidify those requirements in a tangible way, early on in the process.
If no prototyping is involved, a number of requirements will go undiscovered and the requirements document will reflect this, specifying fewer requirements than if there had been prototyping involved. The requirements document will also have more errors if no prototyping is involved.
The design and code will have more errors.

Suggested Explanatory Tool Exercises

Students should be encouraged to work through the following exercises, which will both help them get a better score and answer the questions associated with this model.

Graph the actions “SuggestedRequirementsOutliningPhase”, “SuggestedPrototypingPhase”, “SuggestedRequirementsPhase”, and “SuggestedDesignPhase”, and “SuggestedImplementationPhase”, along with your requirements, design, implementation, integration, and testing activities, to see if you spent too much or too little time on any activity, as compared to that suggested by the model. (If this creates too busy or too large of an action graph, you can also do them one at a time, e.g., one graph with “SuggestedRequirementsPhaseDuration” and all of your requirements activities, one graph with “SuggestedDesignPhaseDuration” and all of your design activities, etc.) If you find one or more phases in which your efforts are significantly off from the ideal, study the action and rule info associated with the particular phase. For instance, if you find that you spent way too long on requirements activities, study the rules associated with the “CreateRequirements”, “ReviewRequirements”, and “CorrectRequirements” actions.
Generate object graphs of your artifacts with their hidden attributes (numUnknownErrors especially) to see if there were errors you didn’t know about. If so, generate composite graphs of these attributes along with the related development activities to see which actions might have caused them to be introduced, and then study the rules associated with these actions of interest to see what error introduction in these actions is dependent on.
Try to discover what the effects of pay raises and bonuses are (questions 2 and 3) by generating a composite graph of these two actions and an employee’s attributes.

9.How to Use This Module with Other Modules