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 PDAs 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 courses 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
nity tudent had an equal opportun e team had to agr to. Every st ree o n ams game and how to design it. to contribute id deas to their tea d E Each mini-gam had relativ vely high imp me plementation and a testing complexity (taking in consider ime ration the ti a allocated for th assignment) which requir every stud dent ), his red in a respective team to contri n ibute to the de evelopment of the king g game and to ensure that it functioned co e orrectly. Work w with others encourages communication, leadership, and e a ach s separation of concerns [7]. In our case, not only did ea c n I ach team members need to coope erate with one another, but ea team needed to work in harmo in order to be successful. ony o Other meth volving large class projects try c hodologies inv o to simulate the industry wo orking environ nment by having groups of stu g ed t udents assigne different tasks within the "organization" [8], [9]. Whil this approac resembles the " le ch size ndustry pract in arch labs an medium-s tice in resea nd companies, the fact that each group of stud c h e dents focuses and a urse m practices only on a specific set of skills may impact cou p s fter ict learning outcom and restri students' op mes pportunities af graduation. g ed GL The game was develope in Java SE 6 using the JOG e API, penGL 2.0 spec A which adh heres to the Op cification.
E GAME DESCRIPTION

hey player r relates to this dilemma, as they know th cannot s completed. leave an complete th level until their task is c nd his ees ries or will pond to inquir Some o the employe wont resp of ddle and high school student can relate t not be h helpful. A mid s f ge to this and realizes that a larg portion of software munication an working w with other nd enginee ering is comm people, which is a lesson taught daily at this age. An s t individu will learn much more from a gam that is n me e ual immers ive and one t that uses effec ations [11]. ctive visualiza The req mini-game acco s omplishes this by using quirements m office im magery and us er dialog.

loped by a different team of d me Each mini-gam was devel E f w he p students, so th objective of each team was to develop a s d game that was user-friendly, intuitive, that could be used to g ool E e zed educate middle and high scho students. Each team utiliz e niques and em alization techn rent different visua d mployed differ rmation about their particu ular metaphors to convey infor m r phase. The best technique for teaching soft p tware engineering [ is to simulate a real-world environment [10]. We employ his n th strategy in our game, as the player must design a r website for a theoretical cor inirporation. Des w signing the mi alism in mind makes the ov games with rea g verall game more earning tool, as the student can relate to what a effective as a le c e w encing while playing the gam p hey th are experie me.

FIGURE 1 THE PLAY MUST NAVIGA THROUGH THE CUSTOMERS COR YER ATE RPORATION TO ID DENTIFY REQUIREM MENTS.

II. Desig Phase ign

phase, is quite different The nex level, which is the design p xt s ements from the requirements phase. Based on the require e ed, must e provide the player m design the layout of the website. ocks fall me here to The gam employed h is similar t Tetris, as blo yer e reen sequential and the play must lly from the top of the scr s I. I Requirements Phase hem appropriat (see Figure 2). tely e place th rts The y T player star the game by appearing in the office of the n ent e he i-game represe website The blocks in th design mini f T customer (see Figure 1). The player ha the role of a c as es bsite. Example of these module s, or subsections of a web requirements engineer who e ose task is to determine the r o nformation, ews, contact in blocks are shopping cart, latest ne w purpose of the website and what pages are necessary for this n p t quirements cker, and miss sion statement. During the req stock tic y layer spawns next to an empl n website. The pl w loyee that may or the phase, t player dete website and ermined the la ayout of the w ach may h e m m not help him. The game is random, meaning that ea ages are necessary. Based on the pages the customer what pa e n d, ime ees ti it is played the employe give differe answers to the ent the wants, t player mu design each page during this phase. ust h ons. players questio The employee might tel the player what p ll w ructure the yout of the p The lay page reflects t the design str he f olor th website is for, what the co scheme is, the layout of the , er custome defined duri the requirem ing ments phase. website, and what pages are needed. The employee might w e w layer must ch Eac page has four block re egions. The pl meone else. It is the goal of the i tell the player to talk to som e navigate a block to on of these reg ne gions if they want it to be not d player to find the needed information or they cann p player does page they are currently desig on the p gning. If the p evel. complete the le c fall nt not wan a particular m module, they c just let it fa past the can er, uite ht This migh be frustratin to the playe but it is qu ng bottom of the screen and a new on will appear at the top. ne m ving requirements is the hardest and most realistic. Deriv h r e ayer must plac modules on each page the customer The pla ce le. se mportant phas of any sof ftware lifecycl Failure to be im mentation. s requires before advancing to implem g o rigorous during this phase often leads to redeveloping the r game, as it escence can relate to this g udents in adole Stu ct T er system at a late time or losi the contrac altogether. The ing s t the actual and be teaches the player to b organized a think 9 Oc ctober 27 - 30, 2010, Washington, DC 0 E 978-1-4244-6262-9/10/$26.00 2010 IEEE ntiers in Educ cation Confere ence 40th ASE EE/IEEE Fron S2D-2

Sessi S2D ion

w work before doing it. Layi d ing out the different modu d ules b before coding the website wi allow the de t ill eveloper to ma ake th proper abstractions and reduce code duplication. A he d e m middle and hig school stud gh dent might not understand that t t s statement, but they do understand organizat t tion and planni ing, w which this game demonstrates. One component of g e educational ga aming that is important is decision making [12]. A student is more likely to learn to fro a game if th t y om heir d decisions hav a long-ter ve rm impact. In their gam me, L Limitations of Europe 2045 the player makes decisio f 5, ons w which impact the state of the game. The player learns from t e th as these decisions might lead to a nega his, t ative outcome. In . o mini-game the player must design th page careful our e, m he lly. I Ignoring the design phase or not taking it seriously cou d uld uences later on in the overall game. lead to consequ simple coding chall lenge, which can be atte empted an ed times. unlimite amount of t On of the difficu ne ulties of an im mplementation mini-game is the educate stude ents in adole escence about computer program mming without any prior exp t perience. This mini-game only bri iefly touches u upon coding th hrough its HTM coding ML challeng ges, but it d does emphasiz other aspec of the ze cts implem mentation phase. An implem menter will be spending e long nig ghts to meet d deadlines, whic is represent ch ting by the coffee a the energy The maze is a metaphor for the many and y. challeng ged an imple ementer faces such as w s, which data structur to use, what methods nee to be implem re t ed mented, or what ar the required parameters. A middle or h re d high school student certainly wou not under uld rstand that, bu they do ut and ze understa that a maz is complex, much like programming, and that the maze has a multitude of possible paths to take to t f exit it s safely. The gam ming environm ment, the maze metaphor, e is extre emely importan as it is the backdrop for this whole nt, 13]. nvironment, level [1 This level might not be a sandbox en as discu ussed in this reference, wher the game pl is nonre lay linear, but it is fair open to in rly nterpretation. There are erse the maze in order to co omplete the endless ways to trave nd ch ent level an the placeme of challenges varies eac time the student plays the level. Constraining the student w g would cause udent not to fully understa and the purpo of the ose the stu implem mentation phase The fact that the level is r e. t randomized and ope en-ended create the parallel t implementa es to ation.

FIGURE 2 THE PLAYER MUST DECIDE WHICH MODULES ARE NEC M CESSARY AND WHE ERE LACE THEM ON EAC PAGE OF THE WEBSITE. CH W TO PL

II Implementa III. ation Phase T implement The tation phase lev resembles the classic arca vel t ade g game, as the player is portr p rayed in the game as a pers g son n navigating thro ough the maze (see Figure 3). Based on the e d design template the customer picked, one of three templ e r late s symbols in the maze will be golden in color. The player e b c m must navigate through the maze and co ollect the corr rect template befor their energy runs out. Th energy bar is re y he r r represented in the lower left of the screen The player can t n. c g gain energy by walking ove coffee symb y er bols in the ma aze. T player mu find each page in the maze and solve a The ust p m e

FIGURE 3 THE PL LAYER MUST NAVIG GATE THROUGH TH MAZE AND COM HE MPLETE ALL C CODING CHALLENGES.

IV. Test ting Phase The tes sting phase lev employs th design for each page, vel he which w developed during the design phase level. The was d player m click, or kill, all the bu on the scree in order must ugs en to fix th bugs (see F he Figure 4). The player is prom mpted with possible bugs, such as a wrong back e s kground or imp proper text color. B clicking on all the bugs, th issue is resto By he ored. The game is intui e itive, as it uses a clich phase, which is s compu bugs. A t uter teenager will m certainly h most have heard

9 978-1-4244-6262-9/10/$26.00 2010 IEEE 0 E Oc ctober 27 - 30, 2010, Washington, DC 40th ASE EE/IEEE Fron ntiers in Educ cation Confere ence S2D-3

Sessi S2D ion

o this phrase and will be able to relate to it In society, most of a e t. m n non-technical people can only relate to computers and o o a technology if th is a defect in the softwa they are usi here t are ing. M Middle and hig school stude are taught about test cas gh ents t ses, a situations ar given to the player in a se as re equential mann ner. T player is not explained ho the problem would really be The ow m y f fixed, but the lesson learned is to check for all possi k ible d defects and tha they must be fixed or the consumer will not at e c n b pleased. Thi metaphor is easy to relate to and is one of be is e e th most effecti forms of ed he ive ducation-base gaming [11]. g the info ormation is pr resented is effe fective and the technique e for ma aking the teen nager rememb it is uniq ber que and is ining to them. This game sup pports the Moo odle-model entertain [14]. Th Moodle-mo he odel claims that students are m t much more interesti in learning if they are as ing g sked questions through a s game. B having fun, the student ab By , bsorbs informa ation about a parti icular topic. The mainten nance phase mini-game accomp plishes this, as the student is i interested in sh hooting the correct bomb. This leads to the student, unk e knowingly, g learning the material.

FIGURE 4 THE PLAYER MUST ERADICATE ALL THE BUGS BEFO THE WEBSITE M A ORE BECOMES INOPERABLE. I

FIGURE 5 THE PLAYER MUST IDE ENTIFY DIFFERENT FORMS OF MAINTE T ENANCE.

EV VALUATION ST TUDY A grou of nine h up high school s students were asked to particip pate in an eva aluation study by actually p playing our game. T group consisted of seven males and tw females. The n wo Of the nine participa ants, seven we white and two were ere d black a they range in age from fourteen to seventeen. and ed m The gam play took p me place at Willia amstown High School in h Souther New Jersey. Pre and post questions were answered rn . e by the students conc cerning each p phase of the g game. The of are elow. results o each phase a outlined be I. Requi irements Phase e The pa articipants we ere asked about the impo ortance of commun unication with other develop pers and the cu ustomer in the succ cess of a projec Six of the n ct. nine students th hought that it was important for the developer to commun rs nicate. The ing ents thought t that communic cation with remaini three stude the cust tomer was imp portant to succ cessfully imple ementing a project. After playing the game all nine of the p g l participants ed unication with the customer was more h answere that commu importa They indic ant. cated that unde erstanding the customers needs w crucial to th success of a project. was he II. Desig Phase ign The pa articipants we ere asked about the impo ortance of organiz zation and plan nning in the su uccess of a pro oject. Eight

V Maintenance Phase V. e T final level is the mainten The nance phase, which teaches the w p player about di ifferent forms of maintenanc (see Figure 5). ce T maintenan team had a difficult task as maintenan The nce k, nce it tself is very open ended. Th approach ta he aken was to tea ach th player abou different for of mainten he ut rms nance as oppos sed to the maintena o ance itself. Th player is given some text to he t r read and then they are promp t pted to go onto the next scre o een. T player is then prompted with a ques The d stion and seve eral c choices. The pl layer must shoot the bomb th corresponds to hat s th correct ans he swer with their tank before the bomb falls to r t s th ground. he nique of learn ning uses mul ltiple choice and a This techn r reading compre ehension from standardize te ests, but makes it m more interestin and engagin as the play must shoo a ng ng, yer ot b bomb with a ta ank. It forces th player to pa attention to the he ay r reading materia they are pres al sented with, as they will have to e m make a quick, instinctive dec cision on which bomb to sho oot. S Shooting the wrong bomb means losing th round and not w m hat n a acquiring more points, so ther is an incentive to succeed. e re From a so oftware enginee ering perspective, the player is r ta aught about various forms of maintenanc cohesion, and v ce, a c coupling. The text the play has to read provides so yer d ome u useful statistic about main cs ntenance, such as 67% of a h f d development ef ffort could be spent on maint s tenance. The way w

9 978-1-4244-6262-9/10/$26.00 2010 IEEE 0 E Oc ctober 27 - 30, 2010, Washington, DC 40th ASE EE/IEEE Fron ntiers in Educ cation Confere ence S2D-4

Session S2D
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 participants 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 customers 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 minigame 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.

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

Session S2D
[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. [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.

[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. 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. 132136, 2005.

AUTHOR INFORMATION Adrian Rusu, Associate Professor, Department Computer Science, Rowan University, rusu@rowan.edu of

[9]

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

[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