SimSE Rational Unified Process (RUP) Model Course Module
1. Introduction/Background
The SimSE RUP model is roughly based on a non-computerized RUP simulation game that IBM uses to
train their employees in the RUP process, with some elements added and removed to make it more
appropriate and fitting for SimSE. For instance, in the IBM game the player could “progress” through
development by answering a series of questions about RUP correctly. In SimSE, development progresses
by having employees work on artifacts.
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 RUP 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 RUP life cycle model in particular should be
introduced to students either before, or in parallel with the students’ exposure to the RUP 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
(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 RUP 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.
Studies have shown that it is important to make a SimSE assignment worth a non-trivial portion of a
students’ final grade (at least 10%), as making it worth too little provides inadequate motivation for
1
students to put the effort in, learn the concepts, and have a positive experience. These studies used three
SimSE modules/models together and made them collectively worth 10% of a student’s final grade, as an
extra-credit assignment.
3. Learning Objectives
A significant portion of what the SimSE RUP model teaches is communicated through the allowable
actions a player can take at each point in the process. This is partly by necessity: RUP is a highly dense
process with numerous prescribed steps. If we were to make them all available at every point throughout
the game, the player would undoubtedly be lost and overwhelmed by all the choices. Instead we limit the
choices available at each step, depending on what part of the process the player is in. For example, a
player can only develop the architecture when in the Elaboration phase and can only develop code when
in the Construction phase. As another example, a player may only plan for one phase after they have
completed all of the work required in the preceding phase. This is even taken so far so that, at several
points throughout the game, only one choice appears on each employee’s menu. Thus the player is steered
much more than in other models and given significantly less freedom. While it may seem that a model
like this would be too easy, the RUP model actually has quite a few challenges—challenges that lie
mainly in other aspects of the game aside from deciding which steps to take next. These challenges will
be brought forth as the learning objectives of the model are described in the remainder of this section.
There are two major lessons encoded in the RUP model, based on [1]. The first of these concerns the
steps and overall flow of RUP which, as already mentioned, are taught through the allowable next steps a
player can take at any point in the game. Figure 1 shows a state chart diagram depicting the SimSE RUP
model’s general flow. (A link to an online version of this diagram is given to the player in the starting
narrative of the RUP game.) As the player progresses through the four RUP phases of Inception,
Elaboration, Construction, and Transition, their course through the game is as follows: The player starts a
phase, assigns employees to that phase, starts an iteration, does some development work, and then either
starts another iteration or assesses the phase. If the assessment is negative, they must go back, start
another iteration, and do more development work. Otherwise, they may plan for the next phase and then
end the phase. Going through the prescribed parts of these steps multiple times is designed to ingrain the
RUP model in the player’s mind. The variability in this aspect lies in the number of iterations done per
phase, a decision the player must make for themselves. If too few are done, time is wasted in performing
phase assessments multiple times (a phase assessment will result in negative results if the work for the
phase is incomplete, requiring that another phase assessment be performed after more work is done). If
the player chooses to do too many iterations, their employees will find themselves assigned to work that
is already done. The employees will then have to come back to the player and announce to them that the
work is already done. By this time, precious clock ticks will have been wasted in unnecessary
communication. Thus, after multiple runs of the game the player will likely be able to come to some
conclusions about how many iterations are appropriate in each phase.
2
Figure 1: State Chart Depiction of the SimSE RUP Model’s Overall Flow.
The second major lesson taught by the RUP model (and the central challenge of both our model and the
IBM game that our model is based on) is efficient allocation of personnel. The player has 10 employees
available, each with a skill set and a pay rate. There are five categories of skills: project management,
architecture, requirements, design and development, and testing. Each employee has either “low” or
“high” skill in each area. In order to enhance realism and add challenge to the model, an employee can
only have, at most, three “high” skills, and their pay rate depends on how many “high” skills they have—
those with one skill are paid $300 per clock tick, those with two skills $400, and those with three skills
$500. Thus, the player must make careful choices about who to assign to which phase, ensuring that the
necessary skills are present to complete the work, but also taking care that they do not assign so many
employees that they exceed their budget. Although efficient allocation of manpower is not a lesson unique
to RUP, in this game it nevertheless serves as a tool with which to teach about what occurs in the different
phases of RUP. Namely, the player must know which activities are performed in each phase so that they
can accordingly assign the employees with the appropriate skills to the appropriate phase(s).
In addition to these two major lessons, the RUP model also teaches a secondary lesson about prototyping.
At the beginning of the Construction phase, the player is notified that the customer would like to see two
intermediate prototypes during the phase. It is up to the player to decide when to submit each prototype—
namely, which use cases should be completed and incorporated into each intermediate version. The
3
customer will be “happy” with a first prototype that contains the five to eight most critical use cases (out
of 20 use cases for the entire system), and “happy” with a second prototype that contains the eleven to
fifteen most critical use cases. For each of these “happy” results, the player will also be rewarded with 5
bonus points (which will be added to their final score). The customer will also be “somewhat happy” with
a prototype that contains more than the desired use cases, but will inform the player that they would liked
to have seen it sooner with less functionality. These situations will penalize the player by 2 points. If a
prototype does not meet any of these conditions, the customer will be “unhappy”, and the player will lose
5 points.
4. Prerequisites
A student should have a basic understanding of software engineering and the RUP life cycle model. (See
Sections 6 and 7 for ways to achieve this.)
5. Time Commitment
The average time to play a single RUP game is 30-45 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 Chapter 4 cover RUP.
7. Optional Supplementary Readings
1. Chapter 4 of: Sommerville, I., Software Engineering. 8th ed. 2008: Addison-Wesley.
2. Kruchten, Pl, The Rational Unified Process: An Introduction (2nd Edition). 2000: AddisonWesley.
8. Assignment
Instructions
First, watch the SimSE video tutorials 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 RUP 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
4
version of Java installed on your machine, you will have the opportunity to install it when you try to run a
game.
Questions
1. What approach to prototyping is rewarded in this game? (Which/how many (approximately) use
cases were incorporated into each when you submitted them and the customer was happy with
them?)
2. What were the major tradeoffs involved in assigning staffing in this game?
3. What are the major outputs of the Inception phase?
4. What are the two major activities in the Elaboration phase?
5. Which phase required the most time and effort?
Answers
1. First prototype: Customer is satisfied when it contains the 5-8 most critical use cases (use
cases 1 through 5, 1 through 6, 1 through 7 or 1 through 8); Second prototype: Customer is
satisfied when it contains the 11-15 most critical use cases (use cases 1 through 11, 1 through
12, 1 through 13, 1 through 14, or 1 through 15). Any answer that falls into these ranges
should be accepted, including, “the first prototype was acceptable when it had
approximately 1/3 of the most critical use cases in it, and the second prototype was
acceptable when it had approximately 2/3 of the most critical use cases in it”, or something
to that effect.
2. The major tradeoffs concern having enough people with the right skills to get the job done
in the scheduled time, but not so many people (or too many expensive people) that the
budget was exceeded.
3. The project plan is developed and the most important use cases are constructed. An
additional possible answer is the Elaboration phase plan, although this is a less major one.
4. Meet with the customer to determine detailed requirements and develop the architectural
prototype.
5. Construction.
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:
5






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.
Kruchten, P., The Rational Unified Process: An Introduction (2nd Edition). 2000: Addison-Wesley.
6