An Agile Software Engineering Process
Bruce R. Maxim, Raspinder Kaur, Christopher Apzynski, David Edwards, Ethan Evans
Department of Computer and Information Science
Dearborn, Michigan, USA
bmaxim, raspinde, capczyns, dkedward, ewevans @umich.edu
Experiential learning has proven to be an effective means of teaching engineering topics. Serious games can provide an effective and enjoyable way to improve student learning in engineering courses . Serious games are gaining popularity as a means of instruction in higher education . Serious games make use of the artistic medium of games to deliver a message, teach a lesson, or provide an experience. Serious games may be entertaining, but that is not their primary purpose.
Computer games can teach
Computer games can provide opportunities for students to experience success in new areas. This often encourages them to try more things and attempt more difficult tasks. Trying to achieve the visible evidence of accomplishment or “leveling up” that appears on a player’s
In one study, Taran used a computer game to teach the principles of risk analysis in project management course. Taran argues that practicing concepts in a game makes them less likely to be forgotten. Games provide a means for students to try out and experiment with strategies in safe environments. . This type of game play can help teach players the kind of critical thinking that is important to STEM coursework .
A few drill and practice computer games have been created to help reinforce student knowledge of various parts of the software development process . In general, these drill and practice programs focus on lower level skills (e.g. recall and recognition) and use entertainment to motivate game replay.
Most of the existing software engineering process games run on laptops or are implemented as web applications, rather than as mobile apps. There are also some
This project was partially funded by the Association of Computing Machinery Special Interest Group on Computer Science Education .
There are several
A critical analysis of several software engineering games appears in von Wangenheim and Shull . According to von Wangenheim and Shull, software engineering games may be better at reinforcing knowledge learned previously than teaching new knowledge. They also found that software engineering process simulation games had more impact on student learning than other types of software engineering games. This was especially true when games allowed students to develop competence through discovery learning and learning by failure. It is important for games to provide instruction and guidance inside the game itself. It is important to provide students with sufficient feedback or explanation of their game scores and results, including instructor debriefing sessions. Subjective feedback from the students using these games indicates that they prefer
Gamification is the use of game elements and
Experience points, scoreboards, and awards are the most frequently used game elements in course gamification. It is important to provide students with a goal and set of rules or game mechanisms that they may use to attain this goal. The infrastructure set up for the gamified activity can support elements of both competition and collaboration among the participants . Creating a
We decided to create a serious computer game that allows students to manage virtual software projects using agile software engineering practices. Students will be able to experiment with various agile process improvement practices while managing a virtual development team. As a result of participating in the learning activities embodied in the game, we expect that students will discover the importance of using software process improvement activities while managing these virtual projects. We are working on a means of providing players with opportunities to create dynamic software process models in the game environment. We are making use of entertainment elements to encourage game replayability.
II. SYSTEM DESIGN
The team examined the relevant literature on games for educational purposes, gamification strategies, and agile software process improvement practices. The literature findings, along with our previous experiences in building serious games, influenced the design of our game and the player interactions. The team decided to create a
The reason we choose to create a card game rather than a 3D simulation with animated characters was to reduce the system requirements for players’ mobile devices. We wanted to emphasize player decision making and focus on the quality of the game AI instead of using high resolution graphics. Multi- player gaming was rejected to allow students practice opportunities that were dependent only on individual player’s available time.
The card game Mille Bornes  was selected by the design team as a model for game play. Mille Bornes is a multi- player game with the goal of completing a trip by playing distance cards until the trip is complete. Opponents can delay your progress by playing cards that halt progress (e.g. flat tire). When progress is interrupted the player needs to either find a remedy (e.g. deploy a spare tire) or have taken previous measures to anticipate that problem (e.g. own a puncture proof tire). This seemed like a good model for proactive risk management as we began to develop our software project management game.
The object of the Process Improvement Game (PIG) is to complete software artifact construction tasks
Fig. 1 contains a state transition diagram that summarizes the gameplay in the Process Improvement Game. The game states are connected by the activities typically included in a variation of the SCRUM framework used for project management . The game will contain some random event behavior so that players will be encouraged to look for ways to vary their daily management decisions to maintain project velocity.
The final process improvement game prototype will contain a virtual tutorial software construction challenge (project) and two additional virtual software construction challenges. Players start a new game by selecting one of the three virtual projects to complete. The tutorial project must be completed to unlock access to the other two projects. All three project levels may be repeated as players seek to improve their scores.
The three construction challenges will be similar to one another to allow players to work on improving their software process management decisions. There will also be an element
of chance to encourage students to replay the game more than once.
Each software construction challenge will have its own backstory. This backstory provides the players with motivation for building artifacts. The backstory may also provide players with insight into selection of the tasks to be included in each new sprint. In agile software development, a sprint is a set period of time during which specific work has to be completed and made ready for customer review. The project story line may provide opportunities to inspire the player to perform process experiments in the virtual environment.
Each virtual project will require the completion of one or more sprints. The player selects the tasks to be completed in the current sprint from the product backlog list. At the beginning of each sprint, the player allocates his group of virtual developers into one of three roles (coder, tester, or debugger). Roles may be reassigned during one of the daily SCRUM meetings, if the player has the right card in hand.
At the daily SCRUM meeting, the player allocates the activities assigned to the team, based on the cards in his or her hand. The game AI analyzes dynamic playing behavior and watches for opportunities to exploit a weakness in the player’s strategy. For example, the player writing code over several days without testing will trigger a defect card being played by the AI. Failing to communicate with the Product Owner may trigger a change request card played by the AI.
When the sprint is complete, the player receives a summary of the effectiveness of team during the time allocated for the sprint. Uncompleted tasks or rejected products are returned to the product backlog. If the project is completed the player statistics are updated and displayed on the
As players become more experienced in playing the game, defects, accidents, schedule slippage, and change requests are introduced into the game. These events are intended to help players to become attuned to watching for problems and planning for them. This also adds to the challenge and enjoyment of the game, as long as the interruptions are not seen as too frequent or too arbitrary.
Players work for experience points as part of the reward system. The experience points will be based on completing the project on time and
This game is being implemented using the Unity 3D game engine. The reason for using this game engine is the ease with which games can be exported to multiple platforms (the web, PC, Mac, and mobile – both IOS and Android). Our game
scripting is being done using the MonoDevelop language. This makes it easy to interface with external software libraries as needed.
The planned evaluation of the game consists of a technical assessment of the game’s usability, as well as an assessment of the student learning resulting from game play. Both assessments will be accomplished by having game players complete
As part of the usability assessment, each member of the development team will review the game by completing a usability checklist prior to allowing the release of the PIG prototype for external play. In addition, game players will be asked to complete an
Our plan is to evaluate this game with junior level software engineering students. We will introduce the game following their participation in classroom activities which expose them to the nature of prescriptive software process models and the project management elements of SCRUM. The game will be assigned as homework while students are studying software project management activities along with risk monitoring, mitigation and management practices in class.
Student learning of agile process improvement strategies will be assessed by having the students take a short online quiz after completing each of the three game projects (levels) for the first time. The quiz questions will check student understanding of the optimal strategy for managing their project resources and will be based on the rules used to develop the game AI. We may ask students to take each quiz a second time after replaying each game project to see if their understanding improves.
We made a conscious decision to not include the quiz as part of the game, since we want use the entertainment value of the game to inspire players to replay the game and not simply study for the quiz. We plan to ask the students to share their lessons learned from playing the game in a class discussion.
IV. CURRENT STATUS
The design team has created a paper prototype of the game and the user stories for the computer game. The development team created the game infrastructure and exported WebGL, Windows, and Android versions of the initial game. The first playable game prototype containing one level was completed during June 2016. This prototype was deployed on the web and will be play tested by software engineering students during July 2016. Player feedback regarding the game is being used to refine gameplay and create the two additional virtual software projects (including the tutorial level). A revised prototype containing all three projects will be available for public review in August 2016.
V. FUTURE PLANS
It is our hope that the project activities will result in the creation of a prototype for an extensible game that provides a virtual learning environment for teaching software engineering process improvement in agile development environments. We plan to add elements of other agile process models to allow students to experiment with broader process improvement strategies. We also plan to create additional software project challenges.
We plan to make this game and its sequels available as free to play web games hosted on the University of Michigan- Dearborn GAME Lab website. We also plan to make the app version of the games freely available as a download for Android devices.
Thanks to the students in the University Michigan- Dearborn GAME Lab for taking the time to play and critique our game.
Rajab, P.; Raju, P; and Sankar, C. (2003) “Serious Games to Improve Student Learning in Engineering Classes”, Computers in Education Journal, Vol. 5 No. 2,
Orszzullok, L. and Knautz, K. (2014)
Michael, D. and Chen, S. (2006) Serious Games: Games that Educate, Train, and Inform, Thomson Course Technology, Indianapolis, IN.
Taran, G.. (2007) "Using Games in Software Engineering Education to Teach Risk Management," Proceedings of 20th Conference on Software Engineering Education & Training, (CSEET’07) July 2007, IEEE Press,
Tang, Y.; Shetty, S.; and Chen, X. (2010) "Empowering students with
engineering literacy and
Navarro, E. and v. d. Hoek, A. (2004) “SimSE: An Interactive Simulation Game for Software Engineering Education’, Proceeding of the Seventh IASTED International Conference on Computers and Advanced Technology in Education, pp.
Rusu, A. Et.al. (2010) “Learning Software Engineering Basic Concepts Using a
Baker, A.; Navarro, E.; and v. d. Hoek, A. (2005) “An Experimental Card Game for Teaching Software Engineering Processes”, the Journal of Systems and Software, vol. 75, pp.
Ramingwong, S. (2012) “CutIT: A Game for Teaching Process Improvement in Software Engineering”, Proceeding of the Third International Conference on Information, Communication and Education Application (ICEA 2012),
Agile Games and Exercises List < http://www.agilesparks.com/agile-
von Wangenheim, C. and Shull, F. (2009) “To Game or Not to Game?”, IEEE Software, Vol. 28 No. 2,
Dicheva, D., Dichev, C., Age, G.m and Angelova, G. (2015) “Gamification in Education: A Systematic Mapping Study”, Proceedings of
Sillaots, M. (2015) “Gamification of Higher Education by the Example of Course of Computer Games”, Proceedings of eLmL 2015 Seventh International Conference on Mobile, Hybrid, and Online Learning, pp.
Mille Bornes <https://en.wikipedia.org/wiki/Mille_Bornes> (accessed 04.20.16).
Pressman, R. S. and Maxim, B. R. (2014) Software Engineering: A Practitioner’s Approach, 8th Ed.,
Fig. 1 State Transition Diagram Showing Game Flow