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 prototyping process 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 model in 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
http://www.ics.uci.edu/~emilyo/SimSE/downloads.html#Videos. 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
http://www.ics.uci.edu/~emilyo/SimSE/downloads.html#Docs. 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
1
(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
2
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
3
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
http://www.cs.standrews.ac.uk/~ifs/Books/SE8/Presentations/index.html. The slides for Chapters 4 and 17 include some
about the rapid prototyping / throw-away prototyping model.
7. Optional Supplementary Readings
1. Sommerville, I., Software Engineering. 8th ed. 2008: Addison-Wesley.
8. Assignment
Instructions
First, watch the SimSE video tutorial at http://www.ics.uci.edu/~emilyo/SimSE/downloads.html#Videos.
Then
download
the
SimSE
player’s
manual
at
http://www.ics.uci.edu/~emilyo/SimSE/downloads.html#Docs. 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 http://www.ics.uci.edu/~emilyo/SimSE/downloads.html#Games. (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.
4
1. 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.)?
2. What is one of the most significant benefits of having the customer evaluate the prototype?
3. Can you ever do too much prototyping? What is the result?
4. From playing the game, what can you conclude are satisfactory choices for prototyping and
implementation languages?
5. What kinds of software projects is a rapid prototyping approach best for and why?
6. 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?
7. What is the effect of doing too little prototyping on the subsequent design and code that are
developed?
Answers
1. 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).
2. 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.
3. 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.
4. 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.
5
5. 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.
6. 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.
7. 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.
1. 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.
2. 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.
3. 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
In the past, this module has been successfully used in conjunction with two other SimSE modules,
making an assignment that consists collectively of three models/modules and associated questions, and is
worth 10% of a student’s final grade. However, this module is also large enough to be used on its own as
a smaller assignment, if desired.
10. Other Notes
There are several other potentially effective uses for SimSE, most of which have yet to be fully explored:
6






Have more advanced students modify an existing model (or build one from scratch, which should
only be used with extremely advanced students) using SimSE’s Model Builder tool and one of the
existing models (available at http://www.ics.uci.edu/~emilyo/SimSE/downloads.html). This has
been tried, and results published in T. Birkhoelzer, E. Oh Navarro, and A. van der Hoek.
Teaching by Modeling instead of by Models. Sixth International Workshop on Software Process
Simulation
and
Modeling,
May
2005
(available
at
http://www.ics.uci.edu/~emilyo/papers/ProSim2005.pdf).
Our experience has suggested that an observer presence can have a positive effect on learning in
SimSE. Although we have not tried this ourselves in classroom settings (only in controlled
experiment settings), some suggested ways to try this are having students play SimSE in pairs, or
having them play SimSE in a lab setting while observed by an instructor or TA.
Have students play in teams, especially teams that have also done, or are doing a class project
together. This can add both a collaborative aspect to learning, and, if set up to be a competition
between teams, can add a competitive aspect.
Make the assignment mandatory, rather than optional or extra-credit, to increase motivation.
Have students play in a lab setting, both to add a competitive aspect and to allow them to
collaborate. Keep in mind, however, that a lab setting generally does not provide enough time to
play a game enough to be able to answer all the questions. An appropriate approach might be to
allow students to play the game first in a lab session (this would also allow them to ask any
questions that may arise), and then let them complete the rest of their playing and questionanswering out of class.
If a project is also being done as part of the course, have students pick one or more of the SimSE
models and write an essay reflecting on comparisons between the SimSE process model(s) and
the one followed in their project.
11. Feedback?
If you have any comments, suggestions, feedback, or experience regarding this course module or SimSE
in general, please send an email to Emily Navarro (emilyo@ics.uci.edu).
References
1.
Sommerville, I., Software Engineering. 8th ed. 2008: Addison-Wesley.
7