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, 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