INTERIM REPORT 1/8/2013 Compung 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 substanal account of my compung honours project composion which provides details of what has been accomplished in the first twelve weeks. The report provides an indicaon of what progress has been made regarding the project collecvely 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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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.
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
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:
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