Learning Software Engineering Basic

Concepts using a Five-Phase Game


Learning Software Engineering Basic Concepts
using a Five-Phase Game
Abstract - Unfortunately, the stereotype of a software
engineer or computer scientist is one who spends his
whole day in a cubicle programming. Other aspects of
software engineering, such as holding meetings with the
customer and users to gather requirements, documenting
requirements, design, and testing are not talked about.
Many middle and high school students believe this
stereotype and become disinterested in a prospective
career in software engineering. As a result, we developed
a game prototype to teach software engineering basic
concepts to middle and high school students. Our game
allows a student to explore the various phases of the
software life cycle, which are requirements, design,
implementation, testing, and maintenance. The waterfall
software life cycle was practiced while developing this
game, and every student in the Information Visualization
course participated equally in the development of the
game. In addition, visualization techniques were used to
develop this game.
Index Terms – K-12 Education, Software Engineering
Education, Information Visualization, Educational Games
INTRODUCTION
The role of a software engineer can mean many different
responsibilities. A software engineer can communicate with
the customer, design the software system, implement the
design, test the software, deliver it to the customer, perform
maintenance, or handle project management. Unfortunately,
students in adolescence do not fully understand the
profession. This leads to youth not pursuing a profession in
software engineering or computer science. Due to faulty
stereotypes, teenagers view this job as one where one would
sit in a cubicle all day and never communicate with other
people. Another common belief is that the whole job is
centered on programming [1]. In a study performed at
University of Colorado at Boulder, almost half of students in
CS1 believed that computer scientists spend a lot of time
working alone, and three quarters believed that computer
scientists’ work is mostly programming [2]. People do not
realize that other fields with educational backing need to be
used, in addition to general skill sets.
Gaming emphasizes entertainment, which can have its
benefits, but could be far more powerful if it were used as an
educational tool. Very few companies have successfully
developed games that actually teach something to our youth.
Session S2D
Teenagers learn from playing computer games, but many
games do not educate or provide false information [3].
The goal of our project was to develop a game that can
be used to effectively teach middle and high school students,
with limited or no computer science background, what the
daily life is like for a software engineer. Teaching software
engineering concepts is not an easy task, due to constant
change and its broad nature, and creative ideas such as
virtual laboratories and PDA’s have been proposed [4]. The
goal of our game is similar, which is to provide a unique, but
effective tool to teach young students basic concepts of
software engineering.
DEVELOPMENT METHODOLOGY
Our game was developed during the Fall 2009 semester at
Rowan University, in a course titled Information
Visualization. One of the course’s learning outcomes is for
students to explore graphics programming and theory and
application of visualization principles. Separation of
concerns was practiced, as the class was divided into five
teams. The class was comprised of twenty five
undergraduate students and five graduate students, which
were divided into five teams comprised of five
undergraduate students and one graduate student each.
The outcome of our overall game is to develop a
website for a hypothetical company and it is comprised of
five individual mini-games, each with the goal of
introducing basic concepts for each of the five software
engineering phases of the waterfall lifecycle model:
requirements, design, implementation, testing, and
maintenance. Each team developed a mini-game
concurrently, independently, based on their phase selection.
Despite the development efforts being independent, the
graduate team leaders had to meet on a regular basis to
ensure that the overall game would function properly. Each
mini-game was responsible with providing output to
following phase and relied on input from the preceding
phase. Graduate team leaders had to clearly communicate
their requirements to their preceding and succeeding phases
so the final product would function. By setting up the class
into several teams, each student was exposed to the entire
development process of their mini-game, which leads them
to be better software engineers [5].
Our development methodology was carefully selected to
allow every student to be involved in each phase of the
software lifecycle [6]. Each team had to produce
requirements for their mini-game, which the preceding phase
 S
team had to agrree to. Every sttudent had an equal
e opportunnity player rrelates to thiss dilemma, as they know thhey cannot
too contribute id
deas to their teaam’s game and d how to designn it. leave annd complete thhis level until their task is ccompleted.
EEach mini-gam me had relativ vely high imp plementation and
a Some oof the employeees won’t resppond to inquirries or will
testing complexity (taking in considerration the tiime not be hhelpful. A midddle and high school studentt can relate
aallocated for th
his assignment)), which requirred every stud dent to this and realizess that a largge portion off software
inn a respective team to contriibute to the deevelopment of the engineeering is comm munication annd working w with other
ggame and to ensure
e that it functioned co orrectly. Workking people, which is a lesson taughtt daily at thiss age. An
wwith others encourages
e communication, leadership, and a individuual will learnn much moree from a gam me that is
sseparation of concerns
c [7]. In n only did eaach
I our case, not immers ive and one tthat uses effecctive visualizaations [11].
team members need to coopeerate with one another, but eaach The reqquirements m mini-game accoomplishes thiss by using
team needed to work in harmo o be successful.
ony in order to office im
magery and us er dialog.
Other meth hodologies inv volving large class
c projects try
too simulate the industry wo orking environnment by having
ggroups of stu udents assigneed different tasks
t within the
""organization" [8], [9]. Whille this approacch resembles the
inndustry practtice in reseaarch labs an nd medium-ssize
ccompanies, thee fact that each h group of studdents focuses and
a
ppractices only on a specific set m impact cou
s of skills may urse
learning outcom mes and restriict students' op pportunities affter
ggraduation.
The gamee was developeed in Java SE 6 using the JOG GL
AAPI, which adh heres to the Op penGL 2.0 speccification.
GAME DESCRIPTION
E

EEach mini-gam me was develloped by a different

d team of
sstudents, so thhe objective off each team wasw to develop p a
ggame that was user-friendly, intuitive, that could be used d to
eeducate middlee and high scho ool students. Each
E team utilizzed
ddifferent visuaalization techn niques and em mployed differrent FIGURE 1
mmetaphors to convey inforrmation about their particu ular THE PLAY
YER MUST NAVIGAATE THROUGH THE CUSTOMER’S COR
RPORATION TO
ID MENTS.
DENTIFY REQUIREM
pphase. The best technique forr teaching softtware engineering
is to simulate a real-world environment [10]. [ We employ
thhis strategy in our game, as the playerr must design n a II. Desig
ign Phase
wwebsite for a theoretical corrporation. Dessigning the miini-
The nexxt level, which is the design pphase, is quite different
ggames with reaalism in mind makes the ov verall game more
from thee requirementss phase. Based on the requireements
eeffective as a leearning tool, as c relate to what
a the student can w
provideed, the player m
must design thee layout of the website.
thhey are experieencing while playing
p the gam
me.
The gam me employed hhere is similar tto Tetris, as bloocks fall
II. Requirementss Phase from thee top of the scrreen sequentiallly and the playyer must
place thhem appropriattely (see Figuree 2).
TThe player starrts the game by n the office of the
y appearing in
Thee blocks in thhe design minii-game represeent website
ccustomer (see Figure 1). The T player haas the role off a
module s, or subsections of a webbsite. Examplees of these
rrequirements engineer
e whoose task is to o determine the
blocks are shopping cart, latest neews, contact innformation,
ppurpose of the website and what
w pages are necessary
n for this
t
stock ticcker, and misssion statement. During the reqquirements
wwebsite. The pllayer spawns next
n to an emplloyee that may y or
phase, tthe player deteermined the laayout of the w website and
mmay not help him.
h The gamee is random, meaning
m that eaach
what paages are necessary. Based onn the pages thee customer
tiime it is playedd, the employeees give differeent answers to the
wants, tthe player muust design eachh page during this phase.
pplayer’s questioons. The employee might telll the player whatw
The layyout of the ppage reflects tthe design strructure the
thhe website is for,
f what the co olor scheme is,, the layout of the
customeer defined duriing the requirem ments phase.
wwebsite, and what
w pages aree needed. The employee might
Eacch page has four block reegions. The pllayer must
tell the player to talk to sommeone else. It is i the goal of the
navigatee a block to onne of these reggions if they want it to be
pplayer to find d the needed information or they cann not
on the ppage they are currently desiggning. If the pplayer does
ccomplete the leevel.
not wannt a particular m fall past the
module, they ccan just let it fa
This migh ng to the playeer, but it is qu
ht be frustratin uite
bottom of the screen and a new onne will appear at the top.
rrealistic. Derivving requirements is the hardest
h and most
m
The plaayer must placce modules on each page thee customer
immportant phasse of any sofftware lifecyclle. Failure to be
requiress before advancing to implem mentation.
rrigorous during g this phase often
o leads to redeveloping the
Stuudents in adoleescence can relate to this ggame, as it
ssystem at a lateer time or losiing the contracct altogether. The
T
teaches the player to bbe organized aand think t the actual
9978-1-4244-6262-9/10/$26.00 0 ©2010 IEEE E Occtober 27 - 30, 2010, Washington, DC
40th ASEEE/IEEE Fron ntiers in Educcation Confereence
S2D-2
 Sessiion S2D
wwork before doing
d it. Layiing out the different
d modu ules simple coding challlenge, which can be atteempted an
bbefore coding the
t website wiill allow the deeveloper to maake unlimiteed amount of ttimes.
thhe proper abstractions and d reduce codee duplication. A mplementation mini-game
Onne of the difficuulties of an im
mmiddle and hig gh school studdent might nott understand that
t is the educate studeents in adoleescence about computer
sstatement, but they
t do understand organizattion and planniing, program mming withoutt any prior expperience. This mini-game
wwhich this game g demonstrates. One component of only briiefly touches uupon coding thhrough its HTM ML coding
eeducational gaaming that is important is decision making challengges, but it ddoes emphasizze other aspeccts of the
[12]. A studentt is more likelyy to learn to fro
om a game if th
heir implem mentation phase. An implem menter will bee spending
ddecisions hav ve a long-terrm impact. In their gam me, long nigghts to meet ddeadlines, whicch is representting by the
LLimitations off Europe 2045 5, the player makes decisio ons coffee aand the energyy. The maze is a metaphor for the many
wwhich impact thet state of thee game. The player learns from challengged an impleementer facess, such as w which data
thhis, as these decisions mightt lead to a negaative outcome.. In structurre to use, whatt methods neeed to be implem mented, or
oour mini-gamee, the player must
m design thhe page carefullly. what arre the requiredd parameters. A middle or hhigh school
IIgnoring the design
d phase or not taking it seriously cou uld student certainly wouuld not underrstand that, buut they do
lead to consequ uences later on in the overall game. understaand that a mazze is complex, much like programming,
and thatt the maze has a multitude off possible paths to take to
exit it ssafely. The gam
ming environm ment, the mazee metaphor,
is extreemely importannt, as it is the backdrop for this whole
level [113]. This level might not be a sandbox ennvironment,
as discuussed in this reference, wherre the game pllay is non-
linear, but it is fairrly open to innterpretation. There are
endless ways to traveerse the maze in order to coomplete the
level annd the placemeent of challenges varies eacch time the
student plays the level. Constrainingg the student wwould cause
the stuudent not to fully understaand the purpoose of the
implem mentation phasee. The fact thatt the level is rrandomized
and opeen-ended createes the parallel tto implementaation.

FIGURE 2
THE PLAYER MUST DECIDE WHICH MODULES
M ARE NECCESSARY AND WHE
ERE
LACE THEM ON EAC
TO PL CH PAGE OF THE WEBSITE
W .
FIGURE 3
THE PLLAYER MUST NAVIG
GATE THROUGH TH
HE MAZE AND COM
MPLETE ALL
II
III. Implementa
ation Phase
CODING CHALLENGES.
C
TThe implementtation phase lev vel resembles the
t classic arcaade
ggame, as the player
p is portrrayed in the game
g as a persson IV. Testting Phase
nnavigating thro
ough the mazee (see Figure 3). Based on the
ddesign templatee the customerr picked, one of three templlate The tessting phase levvel employs thhe design for each page,
ssymbols in thee maze will beb golden in color.
c The player which w was developedd during the design phase level. The
mmust navigate through the maze and co ollect the corrrect player mmust click, or kill, all the buugs on the screeen in order
template beforre their energy y runs out. Th he energy barr is to fix thhe bugs (see F
Figure 4). The player is prom mpted with
rrepresented in the lower leftt of the screenn. The player can
c possiblee bugs, such ass a wrong backkground or impproper text
ggain energy byy walking oveer coffee symb bols in the maaze. color. B
By clicking on all the bugs, thhe issue is restoored.
TThe player mu ust find each page
p in the maze
m and solvee a Thee game is intuiitive, as it usess a cliché phase, which is
“compuuter bugs”. A tteenager will m most certainly hhave heard
9978-1-4244-6262-9/10/$26.00
0 ©2010 IEEEE Occtober 27 - 30, 2010, Washington, DC
40th ASE
EE/IEEE Fron
ntiers in Educcation Confereence
S2D-3
 Sessiion S2D
oof this phrase and
a will be ablee to relate to itt. In society, most
m the infoormation is prresented is effefective and thee technique
nnon-technical people can only o relate to
o computers and a for maaking the teennager remembber it is uniqque and is
technology if th here is a defectt in the softwaare they are usiing. ining to them. This game suppports the Mooodle-model
entertain
MMiddle and hig gh school studeents are taughtt about test casses, [14]. Thhe Moodle-moodel claims thatt students are m much more
aas situations arre given to the player in a seequential mann ner. interestiing in learningg if they are assked questionss through a
TThe player is not explained ho ow the problem m would really y be game. BBy having fun,, the student abbsorbs informaation about
ffixed, but the lesson learned is to check k for all possiible a partiicular topic. The maintennance phase mini-game
ddefects and thaat they must bee fixed or the consumer
c will not
n accompplishes this, as the student is iinterested in shhooting the
bbe pleased. Thiis metaphor is easy to relatee to and is onee of correct bomb. This leads to thee student, unkknowingly,
thhe most effectiive forms of edducation-base gaming
g [11]. learningg the material.

FIGURE 5
THE PLAYER MUST IDEENTIFY DIFFERENTT FORMS OF MAINTEENANCE.
FIGURE 4
THE PLAYER MUST
M ERADICATE ALL
A THE BUGS BEFO
ORE THE WEBSITE
BECOMES INOPERABLE
I . EV
VALUATION ST
TUDY

V
V. Maintenancee Phase A grouup of nine hhigh school sstudents were asked to
particippate in an evaaluation study by actually pplaying our
TThe final level is the mainten nance phase, which
w teaches the game. T The group consisted of sevenn males and tw wo females.
pplayer about diifferent forms of maintenancce (see Figure 5). Of the nine participaants, seven weere white andd two were
TThe maintenan nce team had a difficult task k, as maintenan nce black aand they rangeed in age from m fourteen to seventeen.
ittself is very open ended. Th he approach taaken was to teaach The gam me play took pplace at Williaamstown Highh School in
thhe player abou ut different forrms of maintennance as oppossed Southerrn New Jersey.. Pre and post questions weree answered
too the maintenaance itself. Th he player is given some textt to by the students conccerning each pphase of the ggame. The
rread and then they
t are promp pted to go ontoo the next screeen. results oof each phase aare outlined beelow.
TThe player is then prompted d with a quesstion and seveeral
cchoices. The pllayer must shoot the bomb th hat correspondss to I. Requiirements Phasee
thhe correct ansswer with theirr tank before thet bomb fallss to The paarticipants weere asked about the impoortance of
thhe ground. commununication with other developpers and the cuustomer in
This techn nique of learn ning uses mulltiple choice and a the succcess of a projecct. Six of the nnine students thhought that
rreading compreehension from standardize teests, but makes it it was important for the developerrs to communnicate. The
mmore interestinng and engagin ng, as the playyer must shoo ot a remainiing three studeents thought tthat communiccation with
bbomb with a taank. It forces thhe player to paay attention to the the custtomer was impportant to succcessfully impleementing a
rreading materiaal they are pressented with, as they will havee to project. After playingg the game alll nine of the pparticipants
mmake a quick, instinctive deccision on which bomb to sho oot. answereed that commuunication withh the customer was more
SShooting the wrong
w bomb means
m losing th
hat round and not
n importaant. They indiccated that undeerstanding the customer’s
aacquiring moree points, so therre is an incentive to succeed. needs w
was crucial to thhe success of a project.
From a so oftware engineeering perspective, the playerr is
taaught about various
v forms of maintenancce, cohesion, and a II. Desig
ign Phase
ccoupling. The text the play yer has to read d provides so ome The paarticipants weere asked about the impoortance of
uuseful statisticcs about main ntenance, such h as 67% off a organizzation and plannning in the suuccess of a prooject. Eight
ddevelopment efffort could be spent
s on mainttenance. The way
w
9978-1-4244-6262-9/10/$26.00
0 ©2010 IEEEE Occtober 27 - 30, 2010, Washington, DC
40th ASE
EE/IEEE Fron
ntiers in Educcation Confereence
S2D-4

of the nine students thought that it was important to have a
plan and indicated that the overall success of a project would
be in jeopardy without some planning and organization.
After playing the game all nine of the participants answered
that planning and organization was more important. They
indicated planning and organization would help the
workflow and contribute to the overall success of a project.
III. Implementation Phase
The participants were asked if software can be developed in
different ways. All participants answered that it was
important to look at different methodologies and
programming languages before implementing a solution.
After playing the game the answers provided by the
participants indicated that programming is complex, the time
constraints of the project must be taken into consideration,
there are many different ways to approach a problem, and
that organization is key in the overall success of a project.
IV. Testing Phase
The participants were asked about the importance of
thoroughly testing software. The participant’s answers prior
to playing the game indicated some understanding of the role
of testing in the software lifecycle. One of the nine
participants did answer that testing was important to ensure
the customer’s specifications were met. After playing the
game eight of the participants answered that thorough testing
was important to catch bugs in the code and one still
answered that testing ensured the customer is satisfied.
V. Maintenance Phase
The participants were asked what they learned about
software maintenance. Prior to playing the game four of the
participants answered that software maintenance meant
debugging the code, two answered maintenance meant
getting rid of bugs, one answered maintenance meant taking
care of the software and modifying if necessary and the
remaining two participants answered that software is
unpredictable and always changing and that using different
programs helps bring out more effective results. After
playing the game three of the participants answered
maintenance is difficult, one answered that sixty seven
percent of the project budget could be allocated for
maintenance, and one answered everything in software is
connected. Two participants provided no answer to the post
game question.
VI. Conclusions
The results of the pre and post questions indicated overall
that the participants gained some better understanding of the
software lifecycle, but that the maintenance phase seemed to
be the most confusing to the participants. This would tend to
indicate a need for enhancements in that phase of the game.
FUTURE ENHANCEMENTS
Although our game covers all phases of the software
engineering waterfall lifecycle, it has a compartmentalized
978-1-4244-6262-9/10/$26.00 ©2010 IEEE
40th ASEE/IEEE Frontiers in Education Conference
S2D-5
Session S2D
feel to it. This is expected, as different teams developed each
phase, but it would be ideal to have one game that teaches all
aspects of software engineering.
A persistent, three-dimensional world where the player
has a character in a sandbox experience is the optimal way to
teach challenging concepts. The player is not constrained to
a linear, repetitive game in a realm like this. The player is
able to interact with other characters and to work on
projects. The success and failure a character experiences
when dealing with others would simulate real life software
booms and busts that occur yearly.
Software engineering deals with methodology and
practicalities of delivering usable software. Communication,
teamwork, documentation, version control, and
implementing large projects are all parts of this field. Small
games can teach basic concepts from each of these
experiences, but ideal is a game that combines all of these
lessons into one experience where consequences matter to
the player, so they will learn from it.
CONCLUSION
In this paper we have presented an effective game for
educating middle and high school students about software
engineering. Students who played our game were able to
appreciate the software engineering profession. Each mini-
game provides valuable lessons about a particular phase of
the software engineering lifecycle. The game does not have
a learning curve, which means any individual will be able to
play our game and learn about software engineering.
The university students became better software
engineers through this experience. By employing a
methodology where the class was divided into teams, each
university student was responsible for deriving requirements,
designing the game, providing implementation, and running
test cases. Each team had to derive requirements from other
teams, since each mini-game related to another mini-game in
the overall application. Each student was provided with the
opportunity to contribute equally to each phase of their
respective game. By having each phase developed
independently and concurrently, university students were
exposed to real-world-like environment, where each team
had to communicate requirements, design, and test cases to
one another.
ACKNOWLEDGMENT
We thank all students in the Fall 2009 Information
Visualization course at Rowan University who helped
developed this game, and to students at Williamstown High
School, lead by their instructor, Mary Peacock, for their
participation in our evaluation study.
REFERENCES
[1] Lewis, C., Jackson, M. H., Waite, W. M. "Student and faculty
attitudes and beliefs about computer science", Commun. ACM 53, 5,
May 2010, pp. 78-85.
[2] Wing, J., "Computational thinking", Commun. ACM 43, 3, March
2006, pp. 33-35.
October 27 - 30, 2010, Washington, DC

[3] Riezeman, M. J., "Play to Learn", IEEE The Institute, March 2009, pp.
6.
[4] Zagar, M., Bosnic, I, Orlic, M., "Enhancing software engineering
education: a creative approach", International Conference on Software
Engineering: Proceedings of the 2008 international workshop on
Software Engineering in east and south Europe, 2008, pp. 51-58.
[5] Ford, G., "The progress of undergraduate software engineering
education", ACM SIGCSE Bulletin, Vol, No#. 26, 1994, pp. 51-55.
[6] Rusu, A., Webb, R., Shanline, D., Santiago, C., Luna, C., Kulak, M.,
“A Multiple-Projects-Multiple-Winners Approach for Teaching
Software Engineering”, Proceedings 9th IASTED International
Conference on Software Engineering and Applications, ACTA Press,
2005.
[7] Ali, M., R., "Imparting effective software engineering education",
ACM/SIGSOFT, Vol, No#. 31, July 2006, pp. 1-3.
[8] Blake, J., "A Student-Enacted Simulation Approach to Software
Engineering Education", IEEE Transactions on Education, Vol. 46,
No. 1, 2003.
[9] Way, T., "A Company-Based Framework for a Software Engineering
Course", Proceedings 36th Technical Symposium on Computer
Science Education, ACM SIGCSE Bulletin, Vol. 37, Issue 1, pp. 132-
136, 2005.
[10] Jaccheri, L., Morasca, S., "On the Importance of Dialogue with
Industry about Software Engineering Education", International
Conference on Software Engineering: Proceedings of the 2006
international workshop on Summit on software engineering education,
2006, pp 5-8.
978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC
40th ASEE/IEEE Frontiers in Education Conference
S2D-6
Session S2D
[11] Yue, W., S., Zin, N., A., "Usability evaluation for history
educational games", ACM International Conference Proceeding
Series: Proceedings of the 2nd International Conference on
Interaction Sciences: Information Technology, Culture and Human,
Vol, No#. 403, 2009, pp. 1019-1025.
[12] Sisler, V., Brom, C., Slavik, R., " Towards a novel paradigm for
educational games: the augmented learning environment of 'Europe
2045", MindTrek: Proceedings of the 12th international conference
on Entertainment and media in the ubiquitous era, 2008, pp. 34-38.
[13] Bellotti, F., Berta, R., De Gloria, A., Primavera, L., "Enhancing the
educational value of video games", Computers in Entertainment, Vol,
No#. 7, June 2009.
[14] Daloukas, V., Dai, V., Alikanioti, E., Sirmakessis, S., "The design of
open source educational games for secondary schools", PETRA, Vol,
No#. 282, 2008.
AUTHOR INFORMATION
Adrian Rusu, Associate Professor, Department of
Computer Science, Rowan University, rusu@rowan.edu
Robert Russell, Graduate student, Department of Computer
Science, Rowan University, russel42@students.rowan.edu
John Robinson, Instructor, Department of Computer
Science, Rowan University, robinsonj@rowan.edu
Amalia Rusu, Assistant Professor, Department of Software
Engineering, Fairfield University, rusu@mail.fairfield.edu