INTERIM REPORT

1/8/2013 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.

INTERIM REPORT

Page 1 of 42

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

6 METHODOLOGY ............................................................................................. 31

7 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

INTERIM REPORT

Page 2 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.

1.0.3 AIMS OF THE PROJECT

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

INTERIM REPORT

Page 3 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 dropbox.com – an

online storage space - which shall be accessible to the Samsung Galaxy Tab 2 to play in a browser.

INTERIM REPORT

Page 4 of 42

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

http://www.agileacademy.com.au 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.

INTERIM REPORT

Page 5 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

INTERIM REPORT

Page 6 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. http://www.alistapart.com 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

INTERIM REPORT

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

INTERIM REPORT

Page 8 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 – 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) http://www.withpulse.com Web. 07 Jan 2013

INTERIM REPORT

Page 9 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

“http://box2d.org/about/

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));

INTERIM REPORT

Page 10 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 – May 2013).

INTERIM REPORT

Page 11 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 well-

designed 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’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 30th) 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’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.

INTERIM REPORT

Page 12 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’s. At that time creating working software was the only consideration within the development process. From the 1970’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.

INTERIM REPORT

Page 13 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.

INTERIM REPORT

Page 14 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.

INTERIM REPORT

Page 15 of 42

Fig. 1 The “waterfall model” An iterative software development lifecycle. http://www.Blogspot.com

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 Over Processes and tools

Working software Over Comprehensive documentation

Customer collaboration Over Contract negotiation

Responding to change Over 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

INTERIM REPORT

Page 16 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 re-

examine 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.

INTERIM REPORT

Page 17 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.

Category Traditional Agile

Development Model Traditional Iterative

Focus Process People

Management Controlling Facliltiating

Customer Involvement Requirements gathering and

delivery phases

On-site and constantly

involved

Developers Work individiually within

teams

Collaborative or in pairs

Technology Any Mostly Object orientated

Product features All included Most important forst

Testing End of Development Iterative and/or drives code

Documentation Thorough Only when needed

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

science research conference

INTERIM REPORT

Page 18 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.

INTERIM REPORT

Page 19 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”.

INTERIM REPORT

Page 20 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

INTERIM REPORT

Page 21 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’s product backlog (specification). The development

team then gets to work in sprints (iterations) of 2 – 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

INTERIM REPORT

Page 22 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. http://www.scrumalliance.org 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

INTERIM REPORT

Page 23 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

INTERIM REPORT

Page 24 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’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

INTERIM REPORT

Page 25 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

INTERIM REPORT

Page 26 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. 64-

69, 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:http://2.bp.blogspot.com/_Kl7849hBl_c/TNx3OSOj_LI/AAAAAAAAAEo/Z2iKtQxvyTU/s4

00/Architecture+Figure+1.JPG. Last accessed 01/01/2013.

[22] Scrum Alliance. “Scrum Is an Innovative Approach to Getting Work

Done”. Available:http://www.scrumalliance.org/system/resource_files/0000/3905/Scrum_Framewor

k_Flow.png. Last accessed 01/01/2013.

[23] Larman, C (2004). “Agile & Iterative Development: A manager's guide”. 5th ed. USA: Addison-

Wesley .

[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)

INTERIM REPORT

Page 27 of 42

4.0.9 GLOSSARY

TERM MEANING

SD Software Development

IID Iterative and incremental development

FDD Feature driven development

DSDM Dynamic systems development method

ASD Agile Software Development

XP Extreme Programming

ASD 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

AM Agile Modeling

PRINCE2 PRojects IN Controlled Environments 2

BDUF Big Design Up Front

UML Unified modeling language

INTERIM REPORT

Page 28 of 42

5 PROGRESS

First 12 weeks:

A. Define specification for project – The customers initial requirements

B. Gather resources – Books, Papers, game development tools

C. Learn programming in HTML5 and pulse game engine and start coding prototype

D. Research into agile software development

E. Inform and get feedback on development from supervisor – The project executive

F. Inform my moderator of what I am doing in the project – The project sponsor

G. 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.

INTERIM REPORT

Page 29 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 – 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.

INTERIM REPORT

Page 30 of 42

Final 12 weeks:

A. Review the specification for the project and make amendments if necessary

B. Create a presentation about my investigation into Agile

C. Finish the prototype

D. Present my research (with galaxy tab and power-point slides)

E. Test the game using my game evaluation forms

F. Write the dissertation methodology and conclusion

G. 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 – near the end of February – 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 play-

test 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.

INTERIM REPORT

Page 31 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.

INTERIM REPORT

Page 32 of 42

Fig 3: Game design screen captures

INTERIM REPORT

Page 33 of 42

7 CONCLUSION – 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.

INTERIM REPORT

Page 34 of 42

APPENDIX A REFERNCE LIST

[1] Agile academy. “Roles in an agile team”. Available: http://www.agileacademy.com.au/agile/sites/default/files/Agile%20Team%20Roles.p

df. Last accessed 07th Jan 2013.

[2] Lachlan. H. (2007). A Preview of HTML

5”. Available:http://www.alistapart.com/d/previewofhtml5/structure-div.gif. Last accessed

07th Jan 2013.

[3] Modulus team. (2012). Pulse game engine. Available: http://withpulse.com/img/visual_tree.png.

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: http://withpulse.com/about. Last accessed

07th Jan 2013.

[11] Cunningham, W. (2001). “Principles behind the Agile

Manifesto” .Available: http://agilemanifesto.org/principles.html. Last accessed 07th Jan 2013.

INTERIM REPORT

Page 35 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’s results will allow me to create design pattern(s) for particular aspects of the project’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. Investigate Literature ii. Design Project

iii. Do work iv. Gather in results & analyse them

A First Class Project will:

v. Investigate Literature with more convincing representation vi. Design Project which contains a convincingly structured insight to the development

vii. Do work viii. Gather in results & analyse them

ix. Propose a model/guide for later people doing work in this area

INTERIM REPORT

Page 36 of 42

Reading List: 1. Cockburn, Alistair; (2002) “Agile software development”, Addison-Wesley 2. Larman, Craig; (2004) “Agile & Iterative development: A manager’s guide”, Addison-Wesley 3. Highsmith, Jim; (2004) “Agile project management”; Addison-Wesley 4. Ambler, Scott W.; (2002) “Agile modelling: Effective practises for extreme programming and the unified

process; John Wiley & Sons, Inc., New York 5. Coplien O. James Et al; (2005) “Organizational Patterns of agile software development”; Pearson

Prentice Hall 6. Crawford, Chris; (2011) “The art of game design” McGraw-Hill Osborne Media 7. Hoda, Rasina Et al; (2008) “Victoria University of Wellington; Available:

http://nzcsrsc08.canterbury.ac.nz/site/proceedings/Individual_Papers/pg218_Agile_Project_Management.pdf

8. Boehm, Barry; (1989) “Tutorial: Software risk management”, IEEE Computer society press 9. Boehm, Barry Et al; (2004) “Balancing Agility and Discipline”, Addison-Wesley 10. Beck, Kent; (2005) “Extreme Programming Explained embrace change”, Addison-Wesley 11. Martin, Robert C; (2009) “Clean code : a handbook of agile software craftsmanship / The object

mentors”, Prentice Hall 12. Mike, Beedle Et al (2002) “Agile Software Development with Scrum”, Prentice Hall 13. Richards, Keith (2007) “Agile Project Management: Running PRINCE2TM projects with DSDM TM Atern

TM”,The Stationary Office 14. 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: Marks

Introduction 5 Literature review 25 Methodology 35 Research Implementation 25 Conclusion 10

INTERIM REPORT

Page 37 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.

INTERIM REPORT

Page 38 of 42

INTERIM REPORT

Page 39 of 42

Fig 4: Game design document pages: Screen design, game

influences and character design

INTERIM REPORT

Page 40 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 – despite the many

changes made since it’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.

INTERIM REPORT

Page 41 of 42

Fig 5: Technical document pages

INTERIM REPORT

Page 42 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, “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” (Bonoma, 1985)

Fig 6: Evaluation form pages