Page 1


Computing Honours Project Interim Report

By: Jamie Cater, B00186941 Degree of Computer Games Development

For: Dr Mark Standsfield & Dr John Sutherland

Abstract: This document contains a substantial account of my computing honours project composition which provides details of what has been accomplished in the first twelve weeks. The report provides an indication of what progress has been made regarding the project collectively and outlines how the project should end. Intent for the project, research undertaken, the planning processes and thoughts about the prototypes development shall be discussed. The report will conclude with what deliverables are to be completed at the end of the twenty-four weeks and how an overall successful project shall be evaluated.


CONTENTS 1 INTRODUCTION ............................................................................................... 2 1.0.1 DISSERTATION TITLE ..................................................................................................2 1.0.2 DISSERTATION RESEARCH..........................................................................................2 1.0.3 AIMS OF THE PROJECT ...............................................................................................2 2 OVERVIEW ......................................................................................................... 3 2.0.1 RESEARCH AND WHAT IS BEING ADDRESSED .............................................................3 2.0.2 PROJECT INTENT AND INVESTIGATION ......................................................................3 2.0.3 AGILE SOFTWARE DEVELOPMENT ............................................................................ 4 2.0.4 HTML5 ......................................................................................................................5 2.0.5 GALAXY TAB 2 7.0......................................................................................................7 2.0.6 PULSE GAME ENGINE ................................................................................................7 3

LITERATURE SEARCH ...................................................................................... 11

4 LITERATURE REVIEW ..................................................................................... 12 4.0.1 ABSTRACT ................................................................................................................... 12 4.0.2 INTRODUCTION........................................................................................................... 12 4.0.3 SOFTWARE DEVELOPMENT AND THE INTRODUCTION OF AGILE .............................. 13 4.0.4 AGILE: BENEFITS AND SHORTCOMINGS ..................................................................... 18 4.0.5 INTEGRATING AGILE SOFTWARE DEVELOPMENT ...................................................... 20 4.0.6 MY INVESTIGATION USING AN AGILE FRAMEWORK .................................................. 23 4.0.8 REFERNCES .................................................................................................................. 25 4.0.9 GLOSSARY ................................................................................................................... 27 5

PROGRESS ....................................................................................................... 28


METHODOLOGY ............................................................................................. 31


CONCLUSION – THE PROGRESS TO DATE.................................................... 33

APPENDIX A REFERNCE LIST................................................................................ 34 APPENDIX B PROJECT SPECIFICATION FORM ................................................... 35 APPENDIX C DESIGN DOCUMENT ....................................................................... 37 APPENDIX D TECHNICAL DOCUMENT............................................................... 40 APPENDIX E EVALUATION FORM DOCUMENT .................................................. 42

Page 1 of 42


1 INTRODUCTION 1.0.1 DISSERTATION TITLE “The issues of agile software development when creating a HTML5 game for Galaxy Tab 2 7.0.”

1.0.2 DISSERTATION RESEARCH The project was conceptualized to provide a medium of examining agile software development. In particular, the intent of the analysis was to gain understanding of how a computer game software developer who develops games themselves – a ‘bedroom developer’ – would integrate agile software development and if it would be of any benefit compared to how agile is currently used in industry in small/large organisations. The nature of software development has changed since it was first used in the computing industry in the 1960’s until 2012. I intend to examine if agile has any benefit to bed room developers.


 

Identify the strengths and weaknesses of agile software development since its creation to how it is being used today Examine potential of the HTML5 platform for creating games Highlight how agile would be used in single person development (bedroom developer) while keeping management of the project under control and communicated to influential people involved in the development Create a prototype game which can be accessed via play tests as to how successful the project as a whole has been Create a software development model for future developers who may adopt this mode of creating software using Agile software development – identify strengths, weaknesses, opportunities and costs of the development in relation to other models/software teams

Page 2 of 42


2 OVERVIEW 2.0.1 RESEARCH AND WHAT IS BEING ADDRESSED Since agile software development (ASD) began in 2001, development teams have improved their effectiveness of producing quality software to the end user compared to their previous approaches to development. What has yet to be understood is how capable is it of making a single teamed project agile enough to produce a successful computer game. Using ASD for such a project may or may not be suitable regarding the advantages and disadvantages it has within industry – for small and large teams. Furthermore, the introduction of the HTML5 platform in 2012 has created many new opportunities to create new types of games. The innovative technological advancement of touch screen devices such as the Ipad’s and galaxy tablets has allowed gaming to take place ‘on the move’. It is arguable then that ASD could be the future of software development where developers are aiming to create a successful HTML5 game for a tablet device. The new market of gamers and new essential skills to develop such a game could be the future of small companies/independent games developers. I want to examine exactly how this could be implemented.

2.0.2 PROJECT INTENT AND INVESTIGATION I will implement a software development process which shall adhere to the agile manifesto’s principals to develop an HTML5 game using the Pulse game engine in the Titanium IDE. The game shall be developed to show that the agile development process can be used to create a game when the single role in the project – the general specialist - has to maintain the projects growth until completion. It is important to be aware that agile software development is generally not used by single membered teams but with small teams comprising of core roles (see figure 1 below of core and extended team roles) or large teams who need agility in their project to increase efficiency and quality of their output. I plan to analyze whether it can be used successfully while taking the role as the generalizing specialist of the project. This entails impersonating a variety of roles such as: the project manager, programmer, human resources and artist. My supervisor takes the role of an executive and my moderator taking the role of stakeholder/sponsor in the project while. My colleague Jonathan, takes the role of the independent tester. The students who are part of the two computer games courses at the University of the West of Scotland: Paisley will be the beta testers who will complete a playtest and evaluate the games performance on an evaluation document. The game shall be hosted online on – an online storage space - which shall be accessible to the Samsung Galaxy Tab 2 to play in a browser.

Page 3 of 42


Fig 1: An example of some roles in an agile team. Not all are essential for this project. Web. 07 Jan 2013

2.0.3 AGILE SOFTWARE DEVELOPMENT The Agile Manifesto was first formed at a meeting at the Snowbird cabin, Utah on February (11th – 13th) 2001 by 16 software enthusiasts; and experts in their own software methodology domains who wanted to make software development what they referred to as “Agile” These experts formed what they refer to as the agile alliance. The manifesto was formed with the following eidolon: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The document lists principals which the agile alliance regards as vital values to adhere to using agile software development: “1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 3. Business people and developers must work together daily throughout the project.

Page 4 of 42


4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 5. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 6. Working software is the primary measure of progress. 7. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 8. Continuous attention to technical excellence and good design enhances agility. 9. Simplicity--the art of maximizing the amount of work not done--is essential. 10. The best architectures, requirements, and designs emerge from self-organizing teams. 11. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.� All of these values should be applied within the development of software. Agile software development consists of methods from a range of software creation techniques such like Xtreme programming, Crystal, Scrum, Agile modeling, Dynamic systems development method, Evo, feature driven development and a range of others. Agile development may not require all of these methodologies for various reasons but, all have their usefulness in making software development more agile. They have changed the perspective of how people should view software development: not only as an approach which entails many processes and operations but as a culture and community of enthused works aiming to achieve the best for the end user by collaborating together.

2.0.4 HTML5 Hyper text mark up language (HTML) is a programming language which enables web developers to format a webpage document to be viewed online. Tim Berners Lee created HTML (and consequently the World Wide Web) in 1989 when he was having problems of accessing information on other computers and decided to invent the method of Hyper-text: navigable text which allows the user to choose where to go in the document. “Markup� refers to the syntax he opted to use which contained

Page 5 of 42


“tags” which defined properties of the document; for example textual italics. He has changed the way we obtain information, interaction with different content and explore the World Wide Web. It has advanced since the release of HTML with versions: HTML+, HTML2, HTML3.2, HTML4 and most recently in 2012, HTML5. All these version introduced different web standards for the language which included: new approaches to syntax and efficient code, improved semantics and application programmer interfaces (API). In figure 2 below, it demonstrates how custom div id’s are no longer required in HTML5 as the elements now exist as HTML5 element tags. (no need for div id=”header” to reference an element; just <header> is suffice now.

Fig 2: Example of how new elements have been assigned. The id tags shown have now been added into the elements in HTML5. Web. 07 Jan 2013 Although HTML5 has improved the standard of processing information, it is yet to be approved by the World Wide Web consortium (W3C). The W3C group was created in 1994. Their aim was to make standards for the entire webs usage of HTML so that everyone would follow the same protocols which would make the language more robust and less likely to cause unexpected errors. HTML5 is to be a fully formed language by 2022, which means that it will be standardised across all browsers when it has been analysed and adapted to newer technologies/browser capabilities. On the contrary, there are a few browsers which presently support HTML5: Opera, Safari, Chrome and Firefox. The features of HTML5 include: 

    

New Elements – <canvas> for drawing and manipulating via code (javascript), <meter> for creating a graphical bar for representation of stats, <video>for embedding a video and various others New Attributes – height and width, autocomplete (forms), no-validate and various others Full CSS3 Support – The new css3 platform for cascading style sheets Video and Audio 2D/3D Graphics Local Storage

Page 6 of 42


Local SQL Database Web Applications

2.0.5 GALAXY TAB 2 7.0 The Samsung Galaxy Tablet 2 7.0 was released in April 2012. It is a 7’’ tablet which has a 1GHz Dual Core processor. The tablet has the android 4.0 operating system installed on it. The tablet can be used in 2 orientation modes (horizontal/vertical). Design of a game must consider the operating system and the screen size in order to display the content correctly and in the correct orientation mode for the tablet.

2.0.6 PULSE GAME ENGINE The pulse game engine is an open source Javascript graphics engine which was made by the Modulus team in Ohio, USA. The engine was designed so that people who knew how to develop programs using an object orientated approach could use the engine coding in Javascript to develop HTML5 games. The engine makes use of the canvas element of HTML5 to render graphics to the screen. The engine has the following qualities:      

Object typing (sprites, scenes, layers, nodes, labels) A sprite sheet Support for sprite sheets and animations Asset Management by use of scenes and layering of objects Plugin support Event handling for touch devices A Debug module for evaluating the games performance

Setting up a game in Pulse is done by first creating a document operated model (DOM) which sets up the webpage and game engine. This is achieved by creating an HTML page:

<html> <head> <script type="text/javascript" src="engine/pulse.js"></script> </head> </html>

Page 7 of 42


The pulse engine setup defines that only one engine object should be applied to each game file. The ready method should call the DOM to setup the canvas with the game engine â&#x20AC;&#x201C; via custom game window element id. The engine.go should be called to start the engine at the correct frame rate.

pulse.ready(function() { // The game is ready to be setup now //game coding goes here var engine = new pulse.Engine( { gameWindow: "myDivElementId" } ); ...

engine.go(33); // frame rate set at 33fps });

Components of the Pulse engine include, Game scene manipulation, Sprites, Layers, Animations, Events handlers, Assets manager and an easy to use plugin architecture. Figure 3 shows the framework of a game and what is permitted by the engine.

Fig 3: The framework of setting up a game/app in pulse (one engine, many scenes, many layers in each scene, many nodes(sprites, labels,..) within the layers) Web. 07 Jan 2013

Page 8 of 42


The pulse game engine contains a javascript which utalises the Box2D physics engine by Erin Catto. Box2D is an open source physics engine written in C++ for simulating rigid bodies in 2D Find it here â&#x20AC;&#x153;

In pulse, the physics module is accessed by sourcing it in the html file. <html> <head> <script type="text/javascript" src="pulse.physics.min.js"></script> </head> </html>

Next, in the Javascript game file, the ready function is used to set the pulse to Box2D physics ratio parameter. The area of which to have physics can then be set along with gravity for the world space. The world can then be defined as World = (AWorldObject){theworld,thegravity,are phsyics active}

pulse.ready(function() { // Ratio of Box2D physics to pulse mm.Box2DFactor = 0.01; // Define area of physics bounding box var worldAABB = new b2AABB(); worldAABB.lowerBound.Set(-10000.0, -10000.0); worldAABB.upperBound.Set(10000.0, 10000.0); // Setup gravity vector and world for Box2D var gravity = new b2Vec2(0.0, 7); // was 0.0 , 7 var world = new b2World(worldAABB, gravity, true);

When sprites are defined, they can be manipulated via calls to the physics module. For instance, to get a sprite(S) to move up on the y axis.

S.b2body.SetLinearVelocity(new b2Vec2(2,S.b2body.GetLinearVelocity().y));

Page 9 of 42


One final aspect of setting up physics is ensuring that the physics module runs at a rate which accompanies the frame rate of the game and of the engines update loop. The update function loop parameters consider the scenes that are being used in the game and the frame rate (elapsed). For each iteration of the physics loop (Step), the game update loop works synchronously with the physics and the other game processes on the screen. When the game is rendered, the game should run smoothly with no asynchronous hang ups.

function update(sceneManager, elapsed) { // update the Box2D physics world world.Step(elapsed/1000, 10); . . . }

The pulse game engine has had 5 updates since it was released in January 21 2012. The developers, have issued a statement that the engine was going to have some important updates in the next six months (December 2012 â&#x20AC;&#x201C; May 2013).

Page 10 of 42


3 LITERATURE SEARCH I decided to study agile software development after a series of meetings with my project supervisor - Dr John Sutherland - in September 2012. In week 1 I had a vague I idea that I wanted to develop a welldesigned HTML5 game but Dr John advised me to research about the subject and think about exactly what I was aiming to analyse/discover. On October 10th in week 3 I had defined my topic of investigating agile software development and the issues I may have developing an HTML5 game for a tablet device in a single person team. A PhD Student who remained in the meeting contributed to the discussion and provided me with direction to take the research by creating my own pattern for doing the project when I have done all of the necessary research, implemented and evaluated my performance. The literature research started during week 4, October 17th when I got 5 books out of Paisley campus library. I also began searching on google scholar about agile software development and bookmarking what I had found. There was many academic papers addressing concerns and positive about agile software development. In week 5, Dr John discussed with me his knowledge of software development and where to take my research next. He told me to look continue to look on scholar and search for books in the library. The academic papers I had found gave a clear indication of where agile took software development since 2001 when the manifesto for agile was written. Dr John highlighted the need to search for Barry Boehmâ&#x20AC;&#x2122;s input to software development as a revered software engineer. Further research demonstrated that the software development processes began with a basic linear procedure: some processes which were established through software engineering and refining the current software development procedures. In order to understand the need for agile, previous methods had to be understood. This lead me to researching models used in 1970/80 software development such as the code-and-fix model, waterfall model and spiral model to name a few. The attributes which each model supported within the development framework indicated what was functioning well within the development environment and areas which were failing to create a quality end product for the user. When I searched the library for the authors of the agile manifesto, I found interesting books relevant to software development and software engineering. During week 6 of the semester (October 30 th) I went to Glasgow University library to see if they had any more books on agile than they did in Paisley. I spend a few hours reading books and making notes. I added to my collection of books until I had 14 which I could study - each book provided a unique insight into a method/aspect of agile development which fortified my awareness of agile processes and what agility meant in software development. On the 13th November; week 8, my friend from the Hamilton campus got me a book that wasnâ&#x20AC;&#x2122;t available at Paisley: Extreme programming explained. This book has been important in my research as it is the foundation of my investigation in terms of ensuring the implementation of my programming is efficient and organised. During week 8 I started to type up all of the quotes I had identified with potential to support my explanations of the research. I have reserved 2 books which I will collect when they are available in January, The art of agile development and The pragmatic programmer: from journeyman to master. Next, all that remained was to write the final literature review.

Page 11 of 42


4 LITERATURE REVIEW 4.0.1 ABSTRACT This literature review shall investigate what agile software development entails for software development teams to create a successful project. The paper intends to prove that single person teams could use agile software development successfully. It will discuss ideas which formed the agile manifesto and generated a new, flexible method of developing software. Agile software development will be examined to identify the benefits and short comings of implementing an agile framework. The methodologies which comprise of practices which are used in agile software development will be discussed to highlight the features of developing software with agile. Finally, the paper will conclude with a description of my investigation and how I intend to utilize these methods in my research project. All of these factors shall form the conclusion to my research of how useful agile software development could be for a single person team.

4.0.2 INTRODUCTION The intent of this literature review is to assess how Agile software development (ASD) has enhanced software development (SD). Various aspects of SD will be explored to establish a firm stance on the topic of ASD. Improvements have been made to SD and it has been redefined since its inception the 1960â&#x20AC;&#x2122;s. At that time creating working software was the only consideration within the development process. From the 1970â&#x20AC;&#x2122;s onwards, SD advanced with regard to team / resource efficiency and also the competence and attitude of the workforce to deliver what the customer requires. More customer involvement in this process has also resulted in further improvements in the way that software is developed. It has become not only a process in a workplace, due to agile software development, but also a way of working in a social environment to the best of the SD teams abilities. Throughout the decades since 1970 this has been achieved because many of the traditional development processes were identified as being inefficient or a hindrance to the project.

Software engineering practices helped form particular ways of carrying out tasks, for example the need for comprehensive documentation was reduced and risk management was introduced within the development framework. In 2001, The Agile manifesto, written by 16 software developers revolutionised the way SD is approached: for small and large teams. These expert methodologists in their own domains of software development / engineering collaborated together to form a method of SD they named Agile. It is now widely used in software creation companies as a standard SD approach due to the advocation of agility in development teams. Agility promotes values and principles which create successful projects if the team abide with them. It has been proven that it enhances the software produced, the satisfaction of the end user and the intrepidity of employees within a crafted SD environment.

Page 12 of 42


The values in the manifesto such as “Individuals and interaction over processes and tools” and “Responding to change over following a plan” were never considered positive within the traditional linear context of SD; it was a strictly planned and regimented process. Problems with the tayloristic approaches, for instance using the waterfall model required many iterative processes during the development, due to the structure of the model, in order to meet the customers specification. The spiral model by Barry Boehm aimed to change the negatives of the waterfall model but was still not to efficient as it incurred high costs and high risk taking as the development changed due circumstances. Agile methods aimed to address these concerns and promote SD processes which were people orientated. Despite the positives, there are some negative aspects of agile such as the social and psychological effects of team working, the concern for safety critical software due to the unpredictability of ASD and working effectively in large teams/oragnisations.

On the contrary, the methods are flexible enough for almost any SD team to implement if the team has focus. Large or small development teams have potential with ASD to become successful, yet not all projects achieve a positive end result. The literature review will assess how ASD can be used in a project and what benefits or costs to SD it embodies. Collectively, these results will form the conclusion to my paper.

4.0.3 SOFTWARE DEVELOPMENT AND THE INTRODUCTION OF AGILE Software development began in the 1960’s. The processes involved in creating software were basic due to the quality of computers that programmers were using to create the software and their procedural and basic approach to development. The development would consist of making the programming code and then fixing errors if they were present then moving onto the next piece of software. This approach was named the “code and fix model”. This caused many problems, such as high costs of fixing the errors or if the design had to be changed when the customer received the software. The customers’ requirements were not sufficiently well defined to create acceptable software. Moreover, the maintenance of the programing code with the model was inefficient and could not be reused in other projects. Specific stages were implemented in order to resolve these difficulties which incurred high financial risk to software development companies.

The transformation of software development therefore began in the 1970’s, when the waterfall model was introduced. This model was a heavy weight approach to software development: the structure of the development was focused on rigorous processes - Analysis, Design, Implementation, Testing, Documentation, Evaluation, Maintenance -which eliminated the issues with the code and fix it model. The waterfall model presented linear procedures for creating software. According to Boehm (1988) the waterfall proved useful in maintaining a projects deliverables as each stage was done in iterative stages which standardised software development. Yet the model was unable to be flexible enough to adapt to changes during development and cost companies money to fix.

Page 13 of 42


Barry Boehm attempted to rectify these issues when he introduced the spiral model in 1988. The model also has a heavy weight, iterative development approach to the project in stages similar to the waterfall. Risk assessment/reviewing and planning objectives are the focus of every step around the spiral. It involves a top down and bottom up approach that offers a more flexible development compared to the waterfall. This means that refinements occur after each cycle of iterations which attempt to reduce risks and financial costs. In contrast to the waterfall model, tasks are not to iterative down a bureaucratic structure in order to refine any problems which is a positive aspect of the spiral approach. Attention to identify risks, bugs or other aspects which may influence the development are highlighted during the spiral development cycle. However, there were factors of the spiral model which hindered software developments overall efficiency.

Boehm (1988) identified the difficulties with the spiral model which are; “matching to contract software, relying on risk-assessment expertise, and the need for further elaboration of spiral model steps.“ The difficulty of developing a project with such a low cost tolerance puts pressure on the workforce and incurs costs which may be damaging to a company’s finance – especially with small businesses who need to at least break-even to sustain their company. Furthermore, because the project is amended after each software development cycle, the opportunity to re-use the processes of other projects are rare. Weaknesses associated with heavy weight methods have been highlighted by Chau et al., (2004) who denotes that the traditional approaches rely on documentation as the main facilitator of communication of changes during development.

These measures hinder the development process as documentation can be extremely volatile during a project. When design changes or mistakes are made, documentation then needs to be updated which takes time and proves costly. Furthermore, documentation becomes obsolete as it reaches different sections of the workforce after each iterative cycle and must be done repeatedly. While this is not a disadvantage of the spiral model there could be a better way of communicating instead of by way of documentation and oraganisng development processes cost effectively. The process models at this time in software development history still were not perfect but were becoming more efficient than they ever were.

The heavy weight process models such as the waterfall were important however, because they created an operational approach to software development which identified tasks required to be completed during phases in the development. Cohen et al., (2004) attests that processes change as failings of a particular aspect of one method are identified and another is created to resolve the problems. It is important to recognise that the traditional approach to software development, despite the time consuming inefficiency, is still important in relation to the phases Analysis, Design, Implementation, Testing, Documentation, Evaluation and Maintenance. Shortfalls were highlighted by Highsmith(2001) when he agrees that although there had been improvements in software development, he argues that a more flexible approach was required.

Page 14 of 42


Fig. 1 The “waterfall model” An iterative software development lifecycle. Web. 07 Jan 2013

In 2001, a team of 16 software developers who were experienced using their own developed methodologies for software development– the agile alliance - created the Agile manifesto. The document brought with it a new outlook on software development. The manifesto promoted the values of a successful software development project through 13 statements. The four points below in figure 2 provide an underpinning of what each of the statements entails in the manifesto:

Individuals and interactions


Processes and tools

Working software


Comprehensive documentation

Customer collaboration


Contract negotiation

Responding to change


Following a plan

Fig. 2 “Agile manifesto”; While there is value in the items on the right, we value the items on the left more. Larman, C. Agile & Iterative development: A managers guide. 2004

Page 15 of 42


Agile software development advocates the principals in the manifesto through the various agile methodologies. The agile methods include: Beck(1999) Kent Beck’s Extreme programming (XP), Sutherland et al(1999) Jeff Sutherland, Ken Swabber and Mike Beedle’s Scrum method, Cockburn(2004) Alistar Cockburn’s Crystal (clear), Amblers(2002) Scot Ambler’s Agile modeling (AM), Jeff De Lucas Feature driven development (FDD) Jim Highsmiths Adaptive software development (ASD) and DSDM consortium’s Dynamic system development model (DSDM). Each of these methods all have their advantages and disadvantages which contributes to the agility of a project and the final product. Cohen et al., (2004) and Larman (2004) suggest that although agile methods are useful in making software development more efficient, the processes are derivative of the traditional processes which are still needed. However, the heavy weight processes have been condensed into light weight methods that can be used due to ASD.

The important aspects agile methods are that they have enhanced the processes and interpretation of traditional software development methods: in terms of effectiveness of producing the final output and what software development means to each individuals project. Traditional approaches make use of all available tools to create the end product which may not well structured or designed, whereas agile supports an object orientated approach to design. The more structured object orientated approach offers a reliable and flexible method of creating software. Nonetheless, the traditional processes are not to be neglected when using agile methods. Highsmith (2001) states that agile has improved the organisation of software companies “XP and other agile approaches are forcing organizations to reexamine whether their processes are adding any value to their organizations.” This is important to consider when choosing to use ASD because some organisations may not be able to be flexible enough to use agile methods.

Agile software development has become the latest revolution in software development. While the traditional values are still present within the process, the structure and approach to software development has changed and will benefit from agile in respect to the principals it attempts to instill. Additionally, Vinekar et al., (2006) highlight that the dynamic nature of agile teams means that it proves difficult to implement the traditional linear approach and being agile together during development. Agile software development has helped improve teams to produce quality working software for the customer. Constantine (2002) concurs when he describes that agile methods create a finely tuned way of doing something within the development framework, for instance in relation to well-written code. He explains that it is easier to build on existing code or refactored code than it is to create the entire product collectively.

Page 16 of 42


Moreover, the self-management workforce forges positive behavior in teams to share knowledge and produce quality work. Maurer et al., (2003) found that compared to traditional approaches, agile development allows for adapting to change and getting tasks done to the best they can be done in stages which suit the development environment. It is a people orientated process of software development where the people involved are the central focus while the values of the team encapsulate the principals of the manifesto. Furthermore, each project can be different and each agile software development approach is too, which means each project gets its own effective method of collaborating and producing success.

Hoda et al., (2008) found that agile methods are flexible enough to cope with change in projects and thus reduce risks. They accommodate frequent changes, work efficiently and productively while producing high quality working software for the customer compared to the traditional approaches. Hoda et al., (2008) provide a chart in Figure 3 below which shows a comparative view of approaches of software development.




Development Model









Customer Involvement

Requirements gathering and delivery phases

On-site and constantly involved


Work individiually within teams

Collaborative or in pairs



Mostly Object orientated

Product features

All included

Most important forst


End of Development

Iterative and/or drives code



Only when needed

Fig. 3 Traditional software development vs. Agile Software development Hoda, R et al; Computer science research conference

Page 17 of 42


4.0.4 AGILE: BENEFITS AND SHORTCOMINGS One of the agile alliance members Cockburn (2002) views agile as: “a cooperative game of invention and communication, with a primary goal of delivering useful, working software and a secondary goal of setting up for the next game.” Similarly, Qumer et al.(2008) extends this view of agility. He explains that agile software development “exhibits flexibility to accommodate changes in the shortest time span.” Agile software development can offer the following benefits to software development teams. Agility within a development environment creates a team who work flexibly. Their roles in the team are dynamic which allows them to share knowledge to improve the quality of their work. Furthermore, Highsmith (2001) makes the point that the agile methods are constructed to allow teams to integrate their knowledge while “capatalising on each individual’s and each team’s unique strengths”.

In accordance with this view, Whitworth et al., (2007) found in their research that agile projects encourage team collaboration which was helpful in motivating the team. This is a distinctively positive aspect of agile because having a motivated workforce can is valuable to success. An advantage of agile is that team meetings are encouraged daily particularly with the clients and management involved in the project in order to keep everyone informed of any changes or problems which can be resolved. If the workforce know exactly what to do and are getting on well with each other, the work is more likely to be of high quality.

Awad (2005) found that having a workforce that are capable of getting work completed - a “team of good people” - can make use of agile methodologies better than a team that is disinterested in the development. Whitworth et al., (2007) also found in their investigation due to agiles advocation of collaborating with people rather than working with tools/processes all day, the workforce felt exhausted after a whole day being socially active. Moreover personality disagreements hindered progress and certain styles of individuals hindered the team getting along at times. Another negative aspect was that some individuals wanted to apply agile practices “ill suited to agile interactions”. This would have affected the teams motivation for their project and the confidence in the team ability would have been compromised. People work in different ways and the team must work together to work to their best. Agile offers the medium for discussion during daily/weekly team meetings but if the individuals in the environment are not cooperating to form positive working relationships, the project is at risk of failure.

Page 18 of 42


Another advantage of agile is that the customer’s needs are always met. Agile development teams keep a close relationship with their customers. This means that if any changes or misunderstandings occur, the team can alter what they have developed. The flexibility of the Iterations and increments within the development mean that changes are easily made and the customer can see the results. A further advantage of ASD is that the flexibility can improve time management. Project management is a vital part of software development and it is no different in an agile framework. The difference in an agile development is again the flexibility of each project. Project management keeps everything in the development secure but transparent to the workforce which allows them to get on with their work.

The development can be organised and each individual knows what tasks they have to complete and by when. While this is helped with the development iterations and meetings, project management in ASD is more than merely being organised. It is about ensuring that development is running smoothly and can identify how to carry out tasks differently to achieve better quality or be more time efficient. It can adapt to the flexible framework which can highlight risks. Costs can be saved due to the constant need to plan for change or improve quality of working together as a team. Boehm et al. (1989) states that “A good software project management theory should be simultaneously simple, general and specific.” This is true of agile software development also; which means that having robust project management is advantageous to software development.

However, the only disadvantage of the flexibility of agile is when it is implemented in a development team which is considered large. Boehm (2002) notes that Cockburn and Highsmith came to the conclusion that agile software development is more difficult for larger teams because of the bureaucracy within a large team complicating aspects of development for the team. It has been suggested by Cockburn that even more communication is required in large agile teams in order to succeed. Comparatively, Lindvall et al., (2004) found however that as long as the large team finds the correct methodology to follow they can benefit such as Motorola did. Motorola highlighted that XP – an agile methodology which will be explained in the next section of the literature review - can be implemented in large teams and the problems they discovered were not because of the method but because of the linear approaches they kept within the environment along with XP: “Team members encountered fewer unpleasant surprises at the development cycle’s end, and they shared a common view of the project”.

Page 19 of 42


4.0.5 INTEGRATING AGILE SOFTWARE DEVELOPMENT In order to experience the benefits from ASD, developers must use the agile methodologies. There are many methodologies which can be used in agile. It is best to select the most appropriate ones to get the most out of ASD: this is true regardless of the size of the development team as every project has different needs. Considerations include: team size, how flexible the project needs to be and what skills the team has. Firstly, how development is oragniased starts with project management.

The earliest methodology to be accepted as an agile method is Jenifer Sanders Dynamic systems development model (DSDM) which is an improvement of the predictive project management method PRINCE2. DSDM eliminated the need for the BDUF (big design up front) approach, which required many details at the beginning to structure the project which is what PRINCE2 requested of teams. DSDM makes the change to adapt to needs via accommodating alterations. Communication is done rarely via documentation but by social interaction. Similarly, Jim Highsmith’s book on agile project management which highlights that when choosing a model it is better to adapt to a current model rather than inventing a completely new one.

Another method is Scott Ambler’s Agile modeling which offers agile developers a method for creating effective documentation during a project. It creates a discipline for creating documentation “when it hurts”. In order to refine problems it may be sensible to provide documentation on a specific area. While agile presents the value of social communication over processes and tools, important changes or problems which are hard to communicate socially in a team may follow agile modeling’s principals to resolve issues. Modeling encourages teams to work in specific areas in the work environment and organise themselves around story boarding, UML diagrams or flow charts which add to the positive atmosphere in the workforce. Four principals to adhere to which reflect agile as a whole are; simplicity, feedback, communication and courage.

Feature driven development (FDD) by Jeff De Luca. It involves the initial processes of developing an overall model for the system (project). A feature list is then created to document the processes which will be required to create the software product. These features create the development framework. A plan is then put in place for the development to follow: for instance to produce a new feature every 2 weeks and review how the tasks were completed. The plans are driven by the features agreed to develop – producing documentation or releasing a new version of code. Chief programmers set the task

Page 20 of 42


for members on the team to undertake and those responsible for each class are formulated. Milestones are formed and defined during the start-up phases in FDD in order to reduce risk using the short development time allocated. Next, the iterative and incremental flow of the development takes place when the team design the product by the features to meet the milestone and inform managers of progress which has been made. Concurrently, the process of building the product by the defined features takes place during the development phase. This phase of building and designing continues until the project is completed.

Adaptive systems development (ASD) by Jim Highsmith, begins by setting out to find the problem that the team are attempting solve. This means that the problem can be observed if any alterations are required during the projects development and how they may affect the end product. The next stage in development is understanding the system via research and preparing the data collected to be ready to create/fix it when you begin to build the product for the customer. Adapting to change is the focus of the entire model, which makes research of potential concerns imperative to the success of the model being implemented in the development environment. Next, the modeling of the system is created and iterations take place to make the product. Adaptions are made during this phase if the requirements change or the problems exist. The model is then evaluated to eliminate errors and is delivered to the customer.

Another method is SCRUM by Jeff Sutherland, Ken Schwaber and Mike Beedle. This lightweight model has a team orientated approach to software development. Teams are structured with a SCRUM master, the product owner and the development team. The SCRUM master leads a 15 minute daily meeting to ensure everyone knows what has to be done or if there are any problems to be resolve this can be done during the meeting. The master collaborates with the customer (product owner) and keeps the project on task in relation to the product ownerâ&#x20AC;&#x2122;s product backlog (specification). The development team then gets to work in sprints (iterations) of 2 â&#x20AC;&#x201C; 4 weeks depending on the scope of the project. When processes/tasks have been complete they are recorded so that the team can view them on a wall chart and can see what remains to be done.

The team meetings help to forge the team with the project and discussions about remaining work can communicated to everyone involved to improve team cohesion. Eventually, the sprint is over and the work can be evaluated. If any problems occurred, the team and master can work together to see if there could be any potential to make their procedures more efficient. Using SCRUM makes the workforce feel in charge of their work and empowers them to work to produce high quality software

Page 21 of 42


and collaborate together on coding and knowledge sharing. The customer then receives the section of work to demonstrate the latest features which should improve the product owner’s relationship with the development team as they prove they are capable of producing the software. A next sprint is then planned for the development team to begin another part of the software or new project.

Fig. 4 An example of a “SCRUM” development cycle. Web. 07 Jan 2013

Crystal methodologies created by Alistair Cockburn are light weight process which detail effective practices in development teams considering communication, working in different types of environments and project management attributes. He created the methods which are colour coded to represent the size of the team which may use them most effectively. Agile software development comes under the crystal clear category which has the least number of team members in the crystal methodology family. The number of team members and heaviness of each methods increase as the colours get darker: for example Clear, yellow, orange, red, maroon. The clear method is used in ASD and defines that all the team members will be capable of collaborating together to get the work done following agile principals.

The main roles in the crystal clear method are sponsor – who is the customer and then the designer(s) and programmer(s). The deadlines are formed through the self-disciplined team approach. Documentation need only take place if there is a need to keep the information, for instance risk management procedures. The team work together to meet the deadlines and regular output is produced in short iterations. Reviewing the projects status take place with workshops occurring every

Page 22 of 42


2/3 weeks to allow the team to reflect on the development. Individuals are encouraged to talk about what went well or not so well and suggest processes which could improve their position. Crystal clear follows these processes until the working software is delivered to the customer.

Extreme programming (XP) by Kent Beck attempts to create a programming environment by which individuals can have positive relationships with each other and strive to increase quality and productivity as a team. XP is a lightweight method which places responsibility on the team of their work. It advocates short development cycles which should be properly programmed, tested and evaluated. The flexibility of the method allows the team to react to changes late in the development. Similar to agile modeling which respects the agile principals of communication, courage, simplicity and feedback, XP also values these attributes. The motivation and welfare of the team is what XP attempts to make paramount during development. Additionally, XP helps programming extreme: old practices are enhanced and fine-tuned to make code more resource efficient.

Teams operate in weekly or quarterly cycles (such like a business calendar year) within an XP framework which reduces the risks involved in linear projects and planning during each phase of development can resolve problems. Communication is done socially and by using stories. Stories are written on cards and are posted on walls which allow team members to discuss points and refine problems easily. The agreed final problems on the story cards can then be delegated to members of the team to work on. Fixing errors and refactoring frequently is important when using XP as this refines code. Various techniques such as pair programming and testing are crucial to the success of XP. Testing may take the form of unit tests and/or test-driven development and continuous integration.

4.0.6 MY INVESTIGATION USING AN AGILE FRAMEWORK The results of my investigation intend to prove that ASD can be used for a single person team – not just for small and large teams. ASD makes clear that identifying a suitable approach to development is one main factor of successful software developments. This investigation project has requirements which change frequently due to external influences. The central roles of the project rely on one person – myself – keeping orgarniastion of the project in order to deliver the product. There are other individuals involved: the executive, the sponsor, domain expert of the game engine – who lives in America - and independent testers. All of these factors had to be considered when choosing methods to implement in the development. Due to the flexibility of FDD and DSDM these where used to organise the framework of the project. Milestones could be set while reclaiming the flexibility of the project to adapt to internal/external elements which not be refrained. Aspects of SCRUM such as the

Page 23 of 42


regular review value of the method influenced how to reflect on progress. Agile modeling helped create the environment which I could document processes yet still remain on task. Crystal(clear) helped to identify how the projects focus would integrate with people involved. XPâ&#x20AC;&#x2122;s high standards encouraged effective and efficient coding and testing as thoroughly as possible during development. The processes are effective in completing the work to a high quality standard and development flows incrementally and iteratively. Kortmann et al (2009) below in figure 5 show a variety of approaches to software development.

Fig. 5 Process cycle approaches to SD which contribute to agile software development (with the exception of Linear/incremental which would be traditional software development) Kortmann, R. et al; 40th conference of the international simulation and gaming association 2009

Page 24 of 42


4.0.7 REFERNCES [1] Boehm, B. (1988) “A spiral model of software development and enhancement”, Journal about the spiral software development model and software development, Vol 21, Issue 5 [2] Chau, T. and Maurer, F. (1988) “Knowledge Sharing in Agile Software Teams”, Journal assessing how teams collaborate in an agile software development environment, 2004, ISSU 3075, pp. 173-183 [3] Cohen, D, Lindvall, M, Costa, P. (2004) “An introduction to agile methods”, Journal about the spiral software development model and software development, Vol 62, pp. 1 – 66 2004 [4] Highsmith, J. (2001) “What is agile software development”, Journal about agile software development, Vol 15, Issue 10 [5] Beck, K. (1999) “Embracing Change with Extreme Programming”, Journal detailing all the aspects of extreme programming by Kent Beck, Vol 32, Issue 10 [6] Sutherland, J, Devos, M, Beedle, Sharon, Y and Schwaber, K. (1999) “SCRUM: An extension pattern language for hyperproductive software development”, Journal about the Scrum methodology, Vol 4, 1999 [7] Cockburn, A. (2004) “Crystal Clear A Human-Powered Methodology For Small Teams, including The Seven Properties of Effective Software Projects”, Journal The crystal clear methodology, 2004 [8] Amblers, S. (2002) “Agile Modeling: Effective Practices for eXtreme Programming and the unified Process”. New York: John Wiley & Sons, Inc. New York, 2002. [9] Larman, C and Basili, V.R. (2004) “Iterative and Incremental Development: A Brief History”, Journal of the development approach of IID in software development, Vol 36, Issue 6 [10] Vinekar, V, Slinkman, C. W. and Nerur, S. (2006) “Can Agile and Traditional Systems Development Approaches Coexist? An Ambidextrous View”, Journal about agile and traditional approaches to software development and how they can be integrated together, Vol 23, Issue 3 [11] Constantine L. L. (2002) “Process Agility and software usability toward lightweight usage-centered design”, Journal of the development approach of IID in software development, August 2002. [12] Chau, T., F. Maurer, and G. Melnik, (2003). “Knowledge Sharing: Agile Methods vs. Tayloristic Methods”. In 12 th IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2003). IEEE Computer Society. 302–307. [13] Hoda, R. J, Noble, S, and Marshall, S. (2008) “Agile Project Management”; Computer Science Research Student Conference, Christchurch, New Zealand, pp. 218-221. April 2008 [14] Cockburn, A. (2002) “Agile software development”. Addison-Wesley

Page 25 of 42


[15] Qumer, A, and Henderson-Sellers, B. (2008) “An Evaluation of the Degree of Agility in Six Agile Methods and its Applicability for Method Engineering, Information and Software Technology”, Journal regarding six agile methodologies, Vol 50, Issue 4 [16] Whitworth, E. and Biddle, R. “The Social Nature of Agile Teams”, Proceedings of the AGILE Conference 2007, Journal of how teamwork is implemented in agile teams, p.26-36, August 13-17, 2007 [17] M. Awad. “A Comparison between Agile and Traditional Software Development Methodologies” , Thesis paper denoting agile and traditional software development practices, Honours program thesis, University of Western Australia, 2005. [18] Boehm, B and R, Ross. (1989) “Theory-W Software Project Management: Principles and Examples”, Journal about management principals, Vol 15, Issue 7 [19] Boehm. (2002) “Get Ready For The Agile Methods, With Care, Journal about agile methodologies”, Part 1 of a Journal about agile software development methods and approaches, Vol 35, Issue 1 pp. 6469, 2002. [20] Lindvall M, Muthig D, Dagnino A, Walling C, Stupperich M, Kiefer D. (2004) “Agile software development in large organizations”, Journal about how large organisations manage agile software development, Vol 37, Issue 12 [21] Mary Poppendieck. (03/04/2000). “A Rational Design Process – It’s Time to Stop Faking It”. Available: 00/Architecture+Figure+1.JPG. Last accessed 01/01/2013. [22] Scrum Alliance. “Scrum Is an Innovative Approach to Getting Work Done”. Available: k_Flow.png. Last accessed 01/01/2013. [23] Larman, C (2004). “Agile & Iterative Development: A manager's guide”. 5th ed. USA: AddisonWesley . [24] Kortmann, R., Harteveld, C. “Agile game development: lessons learned from software engineering. In: Learn to game, game to learn”, Agile game development: lessons learned from software Proceedings of the 40th conference of the international simulation and gaming association. (2009)

Page 26 of 42





Software Development


Iterative and incremental development


Feature driven development


Dynamic systems development method


Agile Software Development


Extreme Programming


Adaptive software development

Code and Fix

A software development model which entailed programming the software for a set amount of time then fixing the errors after this process has been complete


Agile Modeling


PRojects IN Controlled Environments 2


Big Design Up Front


Unified modeling language

Page 27 of 42


5 PROGRESS First 12 weeks: A. B. C. D. E. F. G.

Define specification for project – The customers initial requirements Gather resources – Books, Papers, game development tools Learn programming in HTML5 and pulse game engine and start coding prototype Research into agile software development Inform and get feedback on development from supervisor – The project executive Inform my moderator of what I am doing in the project – The project sponsor Generate important documentation – Game documents/project management reports

During the first twelve weeks of the projects development, I defined the topic of study and what I wanted to investigate: if agile software development could be successfully implemented in a single person development team framework – one person does all the work but the main roles in a project team are present (sponsor, executive, independent testers, play-testers). The customer’s requirements for the game changed frequently starting as: a platform game to be made with HTML5 for the Ipad2. This changed to a running platformer HTML5 game for the Samsung galaxy 2 Tab. I was able to gather development tools, research the html5 platform and game engine, books and academic papers on the subject of agile and software development and read through them. An Agile approach to development of small increments and iterations approach allowed me to plan each part of my project in stages similar to the traditional software development cycle but remaining flexible enough to be able to react to changing requirements. This was influenced by various aspects of SCRUM and DSDM. Every two weeks I would review my progress regarding what tasks required my attention using modeling techniques – gantt charts and assessment cards - to evaluate my performance during the iterations. Risk analysis was done frequently when important aspects of development changed. For example, when I had to consider how to code the game for the ipad2, I had to research alternatives for making the game window fit the screen as many of the versions I made did not fit the screen. I had to make the decision to implement css to get the game code to work within the devices screen.

Communication was vital aspect of the development during the first twelve weeks. When I was developing for the Ipad2, I had to find someone who had an ipad2 to test my game. One of my colleges offered to be my Alpha tester for the project. However, in later weeks he wanted to sell his Ipad2 which meant I had to communicate interest in Alpha testers. One of my lecturers offered to assist me with his which was great. Later on in the project, I was offered to develop for the Samsung galaxy 2.

Page 28 of 42


I was able to think how to adapt my design for the screen sizing and research methods of coding the changes so that user zoom was disabled. I found errors in the physics module of the game engine when I was initially making a platform game for the Ipad2 â&#x20AC;&#x201C; within the game engine, the game loop was being overridden by the physics engine, thus any changes I made within the game loop, were disregarded by the game engine. I tried to disable the physics globally but the game loop was still setting the game assets based on the physics engine.

I had to contact the game engine designer to make him aware of this issue. The designers name was Brandon who lives in USA, Ohio which meant I had converse with him via email. This took a few days but the issues were resolved and I was able to fully implement the physics. He told me to set the physics off on each function within the game loop manually which worked.

When I was prepared enough to begin creating the game after I had done my research, I was able to create small unit tests of the game and produce usable segments of the game every two weeks following the XP method for creating efficient and working code: this approach also improved the design of the game: the user interface assets were more easily positioned on the screen when the designed changed to make them clear to the player. Adapting to changes in the requirements was simpler than following regimented processes. For instance, I had to change the genre of the game when I tested the game on the Samsung galaxy 2, as the browsers were not fast enough to implement the physics at run time.

I confirmed details with my supervisor of the project and kept him informed every week. I had my initial meeting with my moderator who agreed to act as the project sponsor and I sent both my supervisor and moderator the webpage where I documented progress with the game and updated it weekly. (because it is a single person team, it was difficult to work and inform daily so, each iteration was on a weekly basis.) Documentation created early on in the project in order to outline the potential outcome of the projects deliverables. Thus far, agile software development has been implemented sufficiently and benefits which it aims to offer to development teams is occurring within the single teamed framework: it is allowing for effective communication of the project and any changes that are made, it has allowed the programming of the game to be organised and progress can be seen, documentation has only been recorded when it is needed and it has allowed the developer to work flexibility enough while focusing on short term planning and delivering working software which is robust and efficient as possible.

Page 29 of 42


Final 12 weeks: A. B. C. D. E. F. G.

Review the specification for the project and make amendments if necessary Create a presentation about my investigation into Agile Finish the prototype Present my research (with galaxy tab and power-point slides) Test the game using my game evaluation forms Write the dissertation methodology and conclusion Print off the dissertation and submit it along with the prototype

I will be creating the final version of the game and testing. I will be implementing my design during January and February and will be recording what happens during the development daily. When I have finished the game â&#x20AC;&#x201C; near the end of February â&#x20AC;&#x201C; I will organise a play test day and gamers who are on the computer game development/technical degree courses can come and test my game and fill in evaluation forms to provide me with qualitative and quantitative feedback. When I have collated the results of the play test, I will create a powerpoint presentation about the research I have done on agile software development. This will be confirmed with my supervisor to assess if it is suffice to communicate all that I have learned during the project. I will then be able to use the results of the playtest in the presentation and communicate to lecturers how successful my project was using agile software development to create a successful game overall.

When I have written the results in the final dissertation, I will be able to write a conclusion and put the results in a model/pattern which may offer guidance for developers who may attempt a similar development with agile. I will be able to print it off and submit the final project deliverables.

Page 30 of 42


6 METHODOLOGY The game which shall be made adhering to the principals of the agile manifesto is called “Tale of Kareem”. The game will make full use of the touch screen technology to develop the gamer’s interest in the mystical Egyptian tale. It will expand on the popular touch screen genre of platform games as an innovative platform runner game.

I have structured my development in two week iterations like the SCRUM method. I plan to get features working during these sprints as it suits the environment which I am confined in: daily meetings (review) can be made while productivity takes place with the game. Refactoring the programming code will be done frequently and incremental design will take place. I will be unable to adhere entirely to the XP method of programming effectively as I am the only programmer however, I aim to follow the principals of XP – to code confidently and review regularly. The development will be conceived through the creation of regular unit tests for difficult aspects of the programing before implementing, conducive internal commentary and working at a pace which increases productivity. I have noticed already that within a single person team that all these processes seem overburdening for one person to manage at one time. This has prompted daily/weekly reviews of my thoughts and actions which are stored in a text file to allow me to revisit parts if I need to improve features or think of a solution of creating a new aspect of the project.

Agile project management highlights the need to be organised and prepared for change. I will use a version control system on a free file sharing website called dropbox. It enables control of each asset in order to edit or restore a working copy. The game shall be created in short incremental and iterative week(s) using FDD and aspects of scrum to record and review progress. The XP principal of using incremental design will have a vital role in developing the game in short iterations. Agile project management risk analysis will be used regularly during the iterations.

In order to evaluate the success of the game itself, I intend to collect qualitative and quantitative information from the potential end users of the game: computer game students who enjoy playing games. I created evaluation forms which will be used during a play test day (Week beginning February 25th) students on the computer game development/technical course will have the opportunity to evaluate the game and write down their thoughts.

Page 31 of 42


Fig 3: Game design screen captures

Page 32 of 42


7 CONCLUSION â&#x20AC;&#x201C; THE PROGRESS TO DATE I believe that I am making stable progress with the project. My research has led to discover many aspects of agile software development and inspired me to implement them in my own project. For instance, frequent communication, reviewing progress/planning for short term and using incremental design, have helped make the project a success thus far. The importance of being organised has been evident in my research of the agile methodologies. I will be able to produce quality output due to agile methods which offer a detailed yet flexible development environment. The progress which I have made to date using agile software development has provided me with sufficient confidence that I will be able to produce a successful, working piece of computer game software which will be delivered on time and according to the requirements specification.

Page 33 of 42


APPENDIX A REFERNCE LIST [1] Agile academy. “Roles in an agile team”. Available: df. Last accessed 07th Jan 2013.

[2] Lachlan. H. (2007). A Preview of HTML 5”. Available: Last accessed 07th Jan 2013. [3] Modulus team. (2012). Pulse game engine. Available: Last accessed 07th Jan 2013. [4] Cater, J., 2012. Tale of Kareem Title Screen and Game play. [photograph]. Unpublished Jan 2013 [5] Cater, J., 2012. Design documentation pages. [photograph]. Unpublished Jan 2013 [6] Cater, J., 2012. Technical documentation pages. [photograph]. Unpublished Jan 2013 [7] Cater, J., 2012. Game play test evaluation form pages. [photograph]. Unpublished Jan 2013 [8] Maxwell, J.A, Bashook, P.G. and Sandlow, L.J, "Combining Ethnographic and Experimental Methods in Educational Research: A Case Study," in Educational Evaluation: Ethnography in Theory, Practice, and Politics, D,M, Fetterman and M,A, Pitman (eds.). Sage Publications, Beverly Hills, CA, 1986, pp, 121-143. [9] Bonoma, T.V, "Case Research in Marketing: Opportunities, Problems, and a Process," Journal of Marketing Research (22:2), May 1985, pp, 199-208 [10] Modulus team. (2012). Pulse game engine. Available: Last accessed 07th Jan 2013. [11] Cunningham, W. (2001). “Principles behind the Agile Manifesto” .Available: Last accessed 07th Jan 2013.

Page 34 of 42


APPENDIX B PROJECT SPECIFICATION FORM Project Title: Issues of Agile software development when creating a HTML5 game for GalaxyTab2 Student: Jamie Cater

Banner ID: B00186941

Supervisor: Dr John Sutherland Moderator: Dr Mark Stansfield

Outline of Project: This project aims to follow the Agile manifesto which expands on the

fundamentals of the principles. The dissertation will analyse the best method of creating a game using the Agile manifesto. In order to achieve this, each aspect of the Agile manifesto must be examined in turn during the games development. The rise of the HTML5 platform has created a new way of making & playing games. I shall create a working model of the results using the Pulse game engine (Javascript engine) developed in the Titanium SDK using HTML5/ Javascript for the Galaxy Tab 2 which shall adhere to research carried out and demonstrate the processes involved in creating a successful project when adhering to Agile principles. Analysis of the projectâ&#x20AC;&#x2122;s results will allow me to create design pattern(s) for particular aspects of the projectâ&#x20AC;&#x2122;s development. This will refine the processes for academics/game developers interested in creating such a project in the future.

A Passable Project will:

i. ii. iii. iv.

Investigate Literature Design Project Do work Gather in results & analyse them

A First Class Project will:

v. vi. vii. viii. ix.

Investigate Literature with more convincing representation Design Project which contains a convincingly structured insight to the development Do work Gather in results & analyse them Propose a model/guide for later people doing work in this area

Page 35 of 42


Reading List: 1. 2. 3. 4. 5. 6. 7.

8. 9. 10. 11. 12. 13. 14.

Cockburn, Alistair; (2002) “Agile software development”, Addison-Wesley Larman, Craig; (2004) “Agile & Iterative development: A manager’s guide”, Addison-Wesley Highsmith, Jim; (2004) “Agile project management”; Addison-Wesley Ambler, Scott W.; (2002) “Agile modelling: Effective practises for extreme programming and the unified process; John Wiley & Sons, Inc., New York Coplien O. James Et al; (2005) “Organizational Patterns of agile software development”; Pearson Prentice Hall Crawford, Chris; (2011) “The art of game design” McGraw-Hill Osborne Media Hoda, Rasina Et al; (2008) “Victoria University of Wellington; Available: nt.pdf Boehm, Barry; (1989) “Tutorial: Software risk management”, IEEE Computer society press Boehm, Barry Et al; (2004) “Balancing Agility and Discipline”, Addison-Wesley Beck, Kent; (2005) “Extreme Programming Explained embrace change”, Addison-Wesley Martin, Robert C; (2009) “Clean code : a handbook of agile software craftsmanship / The object mentors”, Prentice Hall Mike, Beedle Et al (2002) “Agile Software Development with Scrum”, Prentice Hall Richards, Keith (2007) “Agile Project Management: Running PRINCE2TM projects with DSDM TM Atern TM ”,The Stationary Office Jutta Eckstein (2004) “Agile software development in the large”, Dorset house publishing

Resources Required: (hardware/software/other)

Titanium Studio IDE, Paint.NET, Audacity, Pulse game engine, Graphics tablet, Word processor (Microsoft word), Zoe (animation program), PNGQuant (image compression program), Lucid chart diagram (online chart creation program), Gantter (online gantt chart creation program), Dropbox (online storage space) Galaxy Tab 2 7.0

Marking Scheme: Introduction Literature review Methodology Research Implementation Conclusion

Marks 5 25 35 25 10

Page 36 of 42


APPENDIX C DESIGN DOCUMENT The design documentation made the game ideas more focused and purposeful during the projects initial development. The document was particularly important during the beginning of the project when new ideas and problems arose. The ideas contained in the document could be elaborated on when aspects of the development changed, for instance the conversion of assets from ipad2 to galaxy tab 2 screen dimensions or the physics being unable to implement fast enough on the tablet meaning that I had to create my own, thus changing the game mechanics and the objectives, influences, characters of the game.

Page 37 of 42


Page 38 of 42


Fig 4: Game design document pages: Screen design, game influences and character design

Page 39 of 42


APPENDIX D TECHNICAL DOCUMENT The technical documentation aided the thoughts about the requirements for the project to be a success. Particular attention to the document at the beginning of the project â&#x20AC;&#x201C; despite the many changes made since itâ&#x20AC;&#x2122;s creation, made planning easier to manage when changes were made to the requirements. It allowed ideas/concepts to be communicated easily to stakeholders during the initial start up phase of the project.

Page 40 of 42


Fig 5: Technical document pages

Page 41 of 42


APPENDIX E EVALUATION FORM DOCUMENT The evaluation form will enable the students at the play test to record their thoughts on the game. The results of the playtest will record quantitative data as well as qualitatively. Maxwell et al (1986) attests that combining both methods of research allows for the results to be tested in context with the investigation. Moreover, â&#x20AC;&#x153;Collecting different kinds of data by different methods from different sources provides a wider range of coverage that may result in a fuller picture of the unit under study than would have been achieved otherwiseâ&#x20AC;? (Bonoma, 1985)

Fig 6: Evaluation form pages

Page 42 of 42

Computing honours project  

Issues of Agile software development when developing an HTML5 game for the galaxy tgab 2 7.0

Computing honours project  

Issues of Agile software development when developing an HTML5 game for the galaxy tgab 2 7.0