Computing honours project
-
Upload
bert-verninsk -
Category
Documents
-
view
214 -
download
1
description
Transcript of Computing honours project
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