Using Games in Software Engineering Education to Teach
Risk Management
Gil Taran, 20th Conference on Software Engineering Education &
Training (CSEET’07), pages 211-220, 2007
Background
Computer science has, in recent times, become one of the most popular and intensive
courses to be taken up at university. Indeed, it is without a doubt that it is also of great
importance as technology plays a major role in solving problems and shaping the future.
Like any other field, computer science in the corporate world means risks and rewards
and this naturally leads to a need for management.
Management is taught at institutions in the familiar tradition of classroom lectures, case
studies, exercises/projects and examination. However, a seemingly persistent challenge
that educators face is keeping students interested in the material being taught, as the
current situation can only be described as dreary and boring.
This is where the author had the idea of using Game-Based Learning (GBL), that is, as
stated in the article, “the integration of games into the learning process” with the
expected result of raising student involvement, enjoyment and maximising learning that
can be further applied to projects, exercises and/or work (p.1). The activity was then
compared to the traditional methods of learning to assess its effectiveness.
The author has, for several years, taught risk management for software intensive projects
at Carnegie Mellon University and even though it had a diverse method of teaching –
lectures, case studies, discussions, assignments, and projects – the effectiveness of the
course was seen to be in doubt. There were several observations made that highlighted
some issues; taught concepts being easily forgotten if not practised, difficulty to provide
students with opportunities to experiment the material taught; time-constraints leading to
shortening or modification or complete scrapping of assignments; and difficulty in
providing an experience of unforeseen, “what-if” scenarios that are common in
management.
The author thus set out to address these dynamic issues with the help of GBL.
Results
Main part of the summary. Here you should explain the research methods used
(experimental research, case studies, questionnaires, etc.) and results/findings of the
research. If you cite/refer to the article, include page number (p. 34 or pp. 23-24) so that
reader can easily find right page from the article
As aforementioned, the idea was to introduce game-based learning into the learning
process. The author, along with some colleagues, developed a board game for 3 to 4
players in April 2006. The basic goal of the game were simple – to create a simulation of
what managers in software development face. Students playing the game would be put in
situations where they would experience real decision-making that would amount to real
results, experiencing risks and dealing with them with either ignorance or mitigation, or a
method that they develop on their own. Further, the game was meant to allow students to
experience these real world scenarios with fun and enjoyment that would help in further
understanding and applying concepts learned through lectures.
In the game, each player is a project manager and they all compete against each other.
The player needs to develop a software product and sell it to the market. The one with the
most amount of money at the end is declared the winner. Within this process are 5 phases
that are familiar in software development – planning, requirements, design and
architecture, implementation and testing. What is important to note is that the game
differs from all other board games in that players are free to move to any phase,
whenever they want, without any need of throwing a die. However, they must all begin
from the planning phase.
Players in the beginning also have a set of resources, namely, resources, money and risk
cards. There are 5 cards – Project Cards, Surprise Cards, Oops Cards, Risk Cards and
Mitigation Cards. At each turn, a player has 2 options – Perform a Project Step or
Mitigate a Risk. Whatever they may choose, each has a cost (money/personnel)
associated. In order to simulate unforeseen circumstances, where resources are used up in
unplanned activities, a 6-sided die must be thrown that determines whether the planned
activity takes place or not. These interruptions are presented to the player 1/6th of the time
in the form of Surprise Cards and 1/6th of the time in the form of Oops Cards.
Players also gain “Project Capabilities” whenever they perform a project step (e.g.
becoming more proficient in design) and each project step has 3 levels of capabilities.
While each player has level 1 capabilities by default, “Level 2 and level 3 capabilities are
gained through a combination of bonus points for each level 1 capability you have,
planning steps you performed for that phase and a die throw. Capabilities are used later
on in the game for calculating revenues from selling the product. Each phase also allows
you to talk to management (one time per phase) and ask for more project resources
(money or personnel), the cost of which needs to be paid back to management at the end
of the game.” (pp. 3-4).
It is up to the players when to go into production and the game ends when each player is
selling or has run out of money. During the game they make various operational and
strategic decisions, such as deciding how much to invest in capabilities or reduction of
risks. The number of risks carried with them into production simulates potential future
problems, capabilities simulate the importance of doing things the right way and the
throw of a die simulates the variance in sales. Revenues towards the end are formulated
using a combination of these factors.
Conclusions
The game was tried out for a few semesters in universities and at the end of the courses
(the game was applied to other courses in management as well), students were asked to
answer a short questionnaire that asked 5 open-ended questions:
- Compared to a software development project, how real was the game?
- How would you rate the fun factor of the game (in your own words)?
- How simple was this game to play?
- What are the three most important things the game has taught you?
- What is the game learning objective in your opinion?
The responses from students were highly positive, with students commending on how the
game was real, very close to real situation (especially to those who had experience), easy,
simple and fun to play.
There was also another questionnaire handed out to students to rate how the activities
helped meet certain objectives (such as helping to learn concepts, increasing analytical
thinking, improving synthesis skills; the connection between ideas, etc.). Interestingly,
students rated evaluation skills to be highest in case studies even though the game offered
several opportunities for them to evaluate their decisions and progress. Also, it should be
noted that lectures were not rated high in any category. In a further study, students
supported the teaching of risk management using multiple teaching techniques.
Since its inception and first use, the game has continuously been improving based on
feedback from students. The creators plan on increasing the realism of the game by
including more components to the game, such as project estimation and quality assurance.
However, the game also should not become too complex to play and this introduces a
paradox – how to make the game have more complexity yet not be more difficult to play?
The creators are looking to a solution of a computer-based version of the game that will
allow for automating many of the complexities aforementioned and that is expected to
maintain the easiness of playing the game with the additional components.
Overall the game showcases how GBL is extremely effective in its purpose and, when
combined with traditional and current teaching and learning practices, it offers an easy
way to boost learning, in addition to increasing the effectiveness of the established
teaching and learning practices such as lectures and case studies. The author also further
developed a project risk index questionnaire to truly test if students really do learn how to
make better decisions in real software project scenarios. The students are intended to use
this to measure their project risk level before playing the game and after. This helps to
identify if students are applying what they learn to lower risk levels in real.
Ammaar Amin Mufti