SE Concept - 5 Phase Game
-
Upload
ysharavana -
Category
Documents
-
view
49 -
download
0
Transcript of SE Concept - 5 Phase Game
Learning Software Engineering Basic Concepts using a Five-Phase Game
Session S2D
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.
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
9
ttoEtaingwstt
tog"incplg
A
Esgedmpithwgeth
I
Tcrpwmtipthwtpc
rimrs
978-1-4244-62
eam had to agro contribute id
Each mini-gamesting compl
allocated for thn a respective
game and to ewith others eseparation of ceam members eam needed to
Other metho simulate th
groups of stu"organization" ndustry pract
companies, thepractices only earning outcom
graduation. The game
API, which adh
Each mini-gamstudents, so thgame that was educate middledifferent visuametaphors to phase. The bess to simulate his strategy i
website for a games with reaeffective as a lehey are experie
I. Requirements
The player starcustomer (see requirements epurpose of the website. The plmay not help hime it is played
player’s questiohe website is f
website, and well the player
player to findcomplete the le
This mighrealistic. Derivmportant phas
rigorous duringsystem at a late
62-9/10/$26.00
ree to. Every stdeas to their teame had relativexity (taking
his assignment)team to contri
ensure that it encourages coconcerns [7]. Ineed to coope work in harmohodologies inve industry wo
udents assigne[8], [9]. Whil
tice in reseae fact that eachon a specific smes and restri
e was developeheres to the Op
GAME DE
me was develhe objective of
user-friendly, e and high schoalization techn
convey infort technique fora real-world n our game, theoretical coralism in mind earning tool, aencing while p
s Phase
rts the game byFigure 1). T
engineer whowebsite and wlayer spawns nhim. The gamed, the employeons. The emplfor, what the cowhat pages areto talk to som
d the needed evel. ht be frustratinving requiremse of any sofg this phase oer time or losi
0 ©2010 IEEE40th ASE
tudent had an eam’s game andvely high imp in consider), which requiribute to the defunctioned communication, In our case, nerate with one ony in order tovolving large corking environed different tle this approacarch labs an
h group of studset of skills mict students' op
ed in Java SE 6penGL 2.0 spec
ESCRIPTION
loped by a df each team wintuitive, that
ool students. Eniques and emrmation about r teaching softenvironment [as the player
rporation. Desmakes the ov
as the student cplaying the gam
y appearing inThe player haose task is towhat pages are nnext to an emple is random, mees give differeoyee might telolor scheme is,e needed. The
meone else. It iinformation
ng to the playeents is the hftware lifecycloften leads to ing the contrac
E EE/IEEE Fron
equal opportund how to designplementation aration the tired every stud
evelopment oforrectly. Work
leadership, anot only did eaanother, but ea
o be successfulclass projects nment by havtasks within ch resembles nd medium-sdents focuses a
may impact coupportunities af
6 using the JOGcification.
different teamwas to develop
could be usedEach team utilizmployed differ
their particutware engineer[10]. We empr must designsigning the miverall game mcan relate to wme.
n the office of as the role ofo determine necessary for tloyee that may
meaning that eaent answers to ll the player w, the layout of employee mi
is the goal of or they cann
er, but it is quhardest and mle. Failure to redeveloping
ct altogether. T
ntiers in EducS2D-2
nity n it. and ime dent
the king and ach ach . try ing the the
size and urse fter
GL
of p a d to zed rent ular ing loy n a ini-ore
what
the f a the this y or ach the
what the ght the not
uite most
be the
The
player rleave anSome onot be hto this engineepeople, individuimmersThe reqoffice im
THE PLAY
II. Desig
The nexfrom theprovideThe gamfrom theplace th
Themoduleblocks stock ticphase, twhat pawants, tThe laycustome
Eacnavigateon the pnot wanbottom The plarequires
Stuteaches
Occation Confere
relates to thisnd complete th
of the employehelpful. A mid
and realizesering is comm
which is a ual will learnive and one tquirements mmagery and us
YER MUST NAVIGAID
ign Phase
xt level, which e requirements
ed, the player mme employed he top of the scr
hem appropriate blocks in ths, or subsectiare shopping cker, and missthe player deteages are necesthe player muyout of the per defined durich page has e a block to onpage they are nt a particular mof the screen
ayer must placs before advanudents in adole
the player to bctober 27 - 30ence
s dilemma, as his level untilees won’t respddle and high s that a largmunication anlesson taught
n much morethat uses effec
mini-game accoer dialog.
FIGURE 1 ATE THROUGH THE DENTIFY REQUIREM
is the design ps phase. Based must design thehere is similar treen sequentialtely (see Figurehe design minions of a webcart, latest ne
sion statement. ermined the lasary. Based on
ust design eachpage reflects ting the requiremfour block rene of these regcurrently desigmodule, they cand a new on
ce modules on cing to implemescence can rbe organized a
S
, 2010, Washi
they know th their task is cpond to inquirschool studentge portion ofnd working wt daily at thise from a gamctive visualizaomplishes this
CUSTOMER’S CORMENTS.
phase, is quite on the require
e layout of the to Tetris, as blolly and the playe 2). i-game represebsite. Exampleews, contact in
During the reqayout of the wn the pages theh page during the design strments phase.
egions. The plgions if they wgning. If the pcan just let it fane will appear each page the
mentation. elate to this g
and think
ngton, DC
hey cannot completed. ries or will t can relate f software with other s age. An me that is ations [11]. s by using
RPORATION TO
different ements website. ocks fall yer must
ent website es of these nformation, quirements
website and e customer this phase.
ructure the
layer must ant it to be
player does fall past the
at the top. e customer
game, as it t the actual
9
wbthmswe[dLwthoIl
II
TgndsmtrgT
978-1-4244-62
work before dbefore coding the proper ab
middle and higstatement, but twhich this geducational ga12]. A student
decisions havLimitations of which impact this, as these d
our mini-gameIgnoring the dead to consequ
THE PLAYER MUSTO PL
III. Implementa
The implementgame, as the pnavigating throdesign templatesymbols in themust navigate emplate befor
represented in gain energy byThe player mu
62-9/10/$26.00
doing it. Layithe website wistractions andgh school studthey do undersgame demonaming that is t is more likelyve a long-terf Europe 2045the state of theecisions might
e, the player mdesign phase ouences later on
FIGT DECIDE WHICH M
LACE THEM ON EAC
ation Phase
tation phase levplayer is portrough the mazee the customere maze will b
through the re their energythe lower left
y walking oveust find each p
0 ©2010 IEEE40th ASE
ing out the dill allow the ded reduce codedent might nottand organizatstrates. One important is
y to learn to frorm impact. 5, the player e game. The pt lead to a nega
must design thr not taking iin the overall
URE 2 MODULES ARE NECCH PAGE OF THE W
vel resembles trayed in the ge (see Figure r picked, one
be golden in cmaze and co
y runs out. Tht of the screener coffee symbpage in the m
E EE/IEEE Fron
different modueveloper to mae duplication. t understand ttion and planni
component decision mak
om a game if thIn their gammakes decisiolayer learns frative outcome.
he page carefult seriously cougame.
CESSARY AND WHEWEBSITE.
the classic arcagame as a pers3). Based on of three templ
color. The plaollect the corrhe energy bar
n. The player cbols in the mamaze and solve
ntiers in EducS2D-3
ules ake
A that ing,
of ing
heir me, ons om . In lly. uld
ERE
ade son the late yer rect r is can aze. e a
simple unlimite
Onis the programonly brichallengimplemlong nigcoffee achallengstructurwhat arstudent understaand thatexit it sis extrelevel [1as disculinear, endless level anstudent the stuimplemand ope
THE PL
IV. Test
The teswhich wplayer mto fix thpossiblecolor. B
The“compu
Occation Confere
coding challed amount of t
ne of the difficueducate stude
mming withoutiefly touches uges, but it d
mentation phasghts to meet dand the energyged an implere to use, whatre the required
certainly wouand that a mazt the maze has safely. The gamemely importan13]. This level ussed in this rbut it is fairways to trave
nd the placemeplays the leve
udent not to mentation phaseen-ended create
LAYER MUST NAVIGC
ting Phase
sting phase levwas developedmust click, or he bugs (see Fe bugs, such as
By clicking on e game is intui
uter bugs”. A tctober 27 - 30ence
lenge, which times. ulties of an iments in adolet any prior expupon coding th
does emphasize. An implem
deadlines, whicy. The maze is ementer facest methods nee
d parameters. Auld not under
ze is complex, a multitude of
ming environmnt, as it is the
might not be eference, wherrly open to inerse the maze ent of challenl. Constrainingfully understae. The fact thates the parallel t
FIGURE 3 GATE THROUGH THCODING CHALLEN
vel employs thd during the kill, all the bu
Figure 4). The s a wrong backall the bugs, thitive, as it usesteenager will m
Sessi
, 2010, Washi
can be atte
mplementationescence about perience. This hrough its HTMze other aspecmenter will bech is representa metaphor fo
s, such as wed to be implemA middle or hrstand that, bumuch like pro
f possible pathment, the maze
backdrop for a sandbox en
re the game plnterpretation. in order to coges varies eac
g the student wand the purpot the level is rto implementa
HE MAZE AND COMGES.
he design for design phase
ugs on the screeplayer is prom
kground or imphe issue is restos a cliché phasmost certainly h
ion S2D
ngton, DC
empted an
mini-game computer
mini-game ML coding cts of the e spending ting by the r the many
which data mented, or
high school ut they do gramming, s to take to
e metaphor, this whole
nvironment, lay is non-There are
omplete the ch time the
would cause ose of the randomized ation.
MPLETE ALL
each page, level. The en in order mpted with proper text ored. e, which is have heard
9
ontMaTfdbth
V
TpTitthtorTcthth
rmbrmSa
tacud978-1-4244-62
of this phrase anon-technical echnology if th
Middle and higas situations arThe player is nfixed, but the defects and thabe pleased. Thihe most effecti
THE PLAYER M
V. Maintenance
The final level player about diThe maintenantself is very ohe player abouo the maintena
read and then tThe player is choices. The plhe correct anshe ground.
This technreading compremore interestinbomb with a tareading materiamake a quick, Shooting the wacquiring more
From a soaught about v
coupling. The useful statisticdevelopment ef
62-9/10/$26.00
and will be ablepeople can ohere is a defectgh school studere given to theot explained holesson learne
at they must beis metaphor isive forms of ed
FIGMUST ERADICATE A
BECOMES I
e Phase
is the maintenifferent forms
nce team had apen ended. Thut different forance itself. Ththey are prompthen prompted
layer must shoswer with their
nique of learnehension from ng and engaginank. It forces thal they are presinstinctive dec
wrong bomb me points, so theroftware engineevarious forms
text the playcs about mainffort could be s
0 ©2010 IEEE40th ASE
e to relate to itonly relate tot in the softwaents are taught player in a seow the problemd is to check
e fixed or the c easy to relate
ducation-base g
URE 4 ALL THE BUGS BEFOINOPERABLE.
nance phase, wof maintenanc
a difficult taskhe approach tarms of maintenhe player is gipted to go ontod with a quesot the bomb thr tank before t
ning uses mulstandardize te
ng, as the playhe player to pasented with, ascision on whic
means losing thre is an incentiering perspectof maintenanc
yer has to readntenance, suchspent on maint
E EE/IEEE Fron
t. In society, mo computers aare they are usit about test casequential mannm would reallyk for all possiconsumer will ne to and is onegaming [11].
ORE THE WEBSITE
which teaches ce (see Figure k, as maintenanaken was to teanance as opposven some texto the next screstion and sevehat correspondsthe bomb falls
ltiple choice aests, but makeyer must shooay attention to they will haveh bomb to sho
hat round and nve to succeed. ive, the playerce, cohesion, ad provides soh as 67% oftenance. The w
ntiers in EducS2D-4
most and ing. ses, ner. y be ible not
e of
the 5).
nce ach sed t to een. eral s to s to
and s it
ot a the
e to oot. not
r is and
ome f a way
the infofor maentertain[14]. Thinterestigame. Ba partiaccompcorrect learning
THE
A grouparticipgame. TOf the black aThe gamSoutherby the results o
I. Requi
The pacommunthe succit was remainithe custproject.answereimportaneeds w
II. Desig
The paorganiz
Occation Confere
ormation is praking the teenining to them.he Moodle-moing in learningBy having fun,icular topic. plishes this, as
bomb. This g the material.
PLAYER MUST IDE
EV
up of nine hpate in an evaThe group con
nine participaand they rangeme play took prn New Jersey.students conc
of each phase a
irements Phase
articipants weunication with cess of a projecimportant for
ing three studetomer was imp After playinged that commuant. They indicwas crucial to th
ign Phase
articipants wezation and plan
ctober 27 - 30ence
resented is effenager remembThis game sup
odel claims thatg if they are as, the student abThe maintenthe student is ileads to the
FIGURE 5 ENTIFY DIFFERENT
VALUATION ST
high school saluation study sisted of sevenants, seven weed in age fromplace at Willia. Pre and post cerning each pare outlined be
e
ere asked abother developct. Six of the nthe developer
ents thought tportant to succg the game allunication withcated that undehe success of a
ere asked abnning in the su
Sessi
, 2010, Washi
fective and theber it is uniqpports the Moot students are msked questionsbsorbs informa
nance phase interested in sh
e student, unk
T FORMS OF MAINTE
TUDY
students were by actually p
n males and twere white and m fourteen to amstown Highquestions werephase of the gelow.
out the impopers and the cunine students thrs to commun
that communiccessfully implel nine of the p
h the customer erstanding the a project.
out the impouccess of a pro
ion S2D
ngton, DC
e technique que and is odle-model much more s through a ation about mini-game hooting the knowingly,
ENANCE.
asked to playing our wo females. d two were
seventeen. h School in e answered game. The
ortance of ustomer in hought that nicate. The cation with ementing a participants
was more customer’s
ortance of oject. Eight
Session S2D
978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference S2D-5
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
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.
Session S2D
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
[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.
[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, [email protected] Robert Russell, Graduate student, Department of Computer Science, Rowan University, [email protected] John Robinson, Instructor, Department of Computer Science, Rowan University, [email protected] Amalia Rusu, Assistant Professor, Department of Software Engineering, Fairfield University, [email protected]