Honours Dissertation

s) Co mpu ter games deve me nt BSc (Hon Hons) Com puter evellop opme men

ues of Agil e soft ware develop me nt when crea ML5 Iss ssu gile ftw opme men eatting a HT HTM yTab2 game for Ga Gallax axy

Jam Jamiie Cater

2013 25/04/ 25/04/2

Sup ervisor: Dr. Joh n N. Sutherland upe ohn

Decla Declarration This dissertation is submitted in partial fulfilment of the requirements for the degree of Computer games development (Honours) in the University of the West of Scotland.

I declare that this dissertation embodies the results of my own work and that it has been composed by myself. Following normal academic conventions, I have made due acknowledgment to the work of others.

Name: JAMIE CATER Signature: Date:

P a g e |i

Library Re Refference Sheet

ame Cater Surn urna

st Name Jamie Fir Firs Ini Inittials J.C

wer ID Numb er B00186941 Borro Borrow Numbe

se Code COMPSCI Cour Cours

se Des crip Cour Cours esc ripttion Computer Games Development recognises that the fastest growing sector of the computer games industry is for game-playing on smartphones, tablets, internet sites and social networking spaces and this degree prepares graduates for employment in this rapidly changing environment.

ervisor Dr. John N. Sutherland Pro rojjec ectt Sup upe

ssertation Title Issues of Agile software development when creating a Di Dis HTML5 game for GalaxyTab2

ssion 2012/2013 Se Ses

P a g e | ii

Honours project specification document Pro rojjec ectt Title: Issues of Agile software development when creating a HTML5 game for GalaxyTab2 ent: Jamie Cater Stud ude

er ID: B00186941 Bann nne

ervisor: Dr. John N. Sutherland Sup upe erator: Dr. Mark Stansfield Mod ode Ou Outtline of Pro rojjec ectt: 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. ssa ble Pro A Pa Pas sable rojjec ectt will: -Investigate Literature -Design Project -Do the work -Gather in results & analyse them st Cl as s Pro A Fir Firs Clas ass rojjec ectt will: -Investigate Literature with more convincing representation -Design Project which contains a convincingly structured insight to the development -Do the work -Gather in results & analyse them -Propose a model/guide for later people doing work in this area

P a g e | iii

Rea ding Li st: eading Lis 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 mode ling: Effective practices 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. Hoda, Rasina Et al ;( 2008) “Victoria University of Welington; Available: 7. http://nzcsrsc08.canterbury.ac.nz/site/proceedings/Individual_Papers/pg2 18_ 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”, AddisonWesley 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 1. projects with DSDM TM Atern TM”, The Stationary Office 14. Jutta Eckstein (2004) “Agile software development in the large”, Dorset house publishing Res our ces Requir ed: (hardware/software/other) esour ourc quire 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 Literature review Methodology Research Implementation Conclusion

5 25 35 25 10

P a g e | iv

Table of Contents Declaration............................................................................................................................................... i Library Reference Sheet...........................................................................................................................ii Honours project specification document............................................................................................... iii Table of Contents.................................................................................................................................... v Acknowledgments................................................................................................................................. vii Abstract.................................................................................................................................................viii 1 Introduction..........................................................................................................................................1 1.1 Dissertation research overview..................................................................................................... 1 1.2 Aims of the project........................................................................................................................ 1 1.3 Agile software development's core values....................................................................................2 2 HTML 5................................................................................................................................................. 4 3 Pulse game engine............................................................................................................................... 6 4 Tablets.................................................................................................................................................. 9 4.1 Ipad2.............................................................................................................................................. 9 4.2 Galaxy tab 2 7.0........................................................................................................................... 10 5 Software development.......................................................................................................................12 5.1 Software process models.............................................................................................................12 5.2 Examination of software development....................................................................................... 15 6 Agile software development.............................................................................................................. 17 6.1 Agility in software development................................................................................................. 17 6.2 The values of ASD culture............................................................................................................18 6.3 Agile benefits and shortcomings................................................................................................. 21 6.4 Methodologies.............................................................................................................................22 6.4.1 Scrum...................................................................................................................................22

P a g e |v

6.4.2 Xp........................................................................................................................................23 6.4.3 DSDM Atern........................................................................................................................24 6.4.4 Adaptive systems development......................................................................................... 24 6.4.5 Feature driven development..............................................................................................25 6.4.6 Crystal methodologies........................................................................................................25 6.4.7 Agile Modelling...................................................................................................................26 6.5 The Growth and future of ASD.................................................................................................... 26 7 Prototype development..................................................................................................................... 27 7.1 Integrating an agile framework in a single person team..............................................................27 8 Qualitative and quantitative research............................................................................................... 32 8.1 The questionnaire........................................................................................................................32 8.2 Prototype evaluation................................................................................................................... 33 9 Model and attributes recommendations........................................................................................... 34 10 Conclusion........................................................................................................................................ 37 References.............................................................................................................................................40 Glossary................................................................................................................................................. 43 Appendix A - Implementing Physics using pulse engine........................................................................ 44 Appendix B - Design document............................................................................................................. 45 Appendix C - Technical documentation.................................................................................................48 Appendix D – Project management.......................................................................................................49 Appendix E- Preliminary game development........................................................................................ 50 Appendix E - Screen tests on ipad2....................................................................................................... 52 Appendix F - Programming code............................................................................................................52 Appendix G - Assets creation of the prototype..................................................................................... 53 Appendix H - Final game play screen.....................................................................................................54

P a g e | vi

Acknowledgments A big thanks to: ervisor – Dr John Sutherland. A legend of a guy and now a great friend!

Sup upe Thank you for all your morale support and help during the project. If it wasn't for your help I would not have gotten far with the development of my dissertation.

Thank you!

Mod erator – Dr Mark Stansfield is a great guy! Thanks for all the help you gave ode throughout the project.

Game engine developers – The Modulus team: Brandon Cannaday and Charlie Key! - Thank you for the help you provided during the development of the game. Most importantly thanks for making the game engine! It is awesome. assmates – Alan Wong, Gordon McCleod, Jonathan “Jof” Traynor, Adam Cl Cla Kale, Shona Logan, Sean Winston, Andrew McNamara, Andrew Cunningham.

Made some great friends during university! They certainly helped the morale at times er – Dr Daniel Livingstone for offering use of his Ipad2. Thankfully, I Lec ecttur ure didn't require the use of it but thanks again as it helped a lot during the project knowing I had that as a backup reducing the risks of developing software!

Thanks for your help!

Fami milly – Collette Maclachlan, Lyndsay Issac, Michelle Burns thanks for your support Testers – Gong Wei Lee, Gong Ying Lee, Chris Henderson, Andrew Tsim, Sheryl McAllister, Colin Li, Alan Wong, Gordon McCleod, Jof Traynor, Adam Kale, Shona Logan, Sean Winston, Andrew McNamara, Andrew Cunningham.

Thank you for taking the time to try the game and complete the survey!

Agile Alliance - I now appreciate what you created the manifesto for.

Pa Parrents – Mum & Dad - Thanks you for all your support throughout the project

yright and trademarks acknowledged. © 2012/13 All cop opy

P a g e | vii

Abstract This dissertation examines Agile software development (ASD) which provides the syllogism to the question, “what are the issues of Agile software development when creating a HTML5 game for the galaxy tab 2 7.0?� Traditional software development incurred high financial costs, duplicated resources and failed to recognise the significance of communication or each individual involved in the project. Furthermore, processes did not develop software in short incremental and iterative cycles involving the input from the customer and a development team every day. ASD has contributed a flexible approach to the development process of creating software.

ASD is scalable to the size of an organisation. Until now, there has been no academic recognition of whether Agile principles and values being applied by an individual, adding agility in software development by themselves, is favorable. In order to analyse this thesis, a prototype was created following Agile values and principles by myself. The prototype was evaluated by tablet gamers. The majority of them enjoyed it and highlighted that they would purchase a commercially released version of the prototype.

They also found it fun to play. The prototype was completed on time, due to the inherent values of Agile methodologies.

The crucial aspect, revealed by this study was that if the Agile manifesto is strictly followed by an intrepid, enthusiastic worker who is highly motivated, the project is likely to be successful. The study concludes, ASD is advantageous to a sole developer, because changes during the project can be avoided/fixed using ASD.

P a g e | viii

1 Introduction 1.1 Dissertation research overview 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.

1.2 Aims of the project • • •

• •

To identify the strengths and weaknesses of Agile software development and how it can be used to create quality working software Examine the potential of the HTML5 platform for creating games using the Pulse game engine Highlight how Agile would be used by a single person in development of a piece of software - One person keeps management of the project under control and communicates to influential people involved in the development.

Create a prototype game, which can be evaluated via play tests, as to how successful the project was using ASD to complete a project by one person Recommend 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.

P a g e |1

1.3 Agile software development's core values 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 Agile they referred to as “Agile 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 when 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.

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

P a g e |2

All of these values should be applied within the development of software according to Agile Agile. In order to abide in the values stipulated, Agile consists of lightweight methodologies such like Xtreme programming (XP), Crystal(clear), Scrum, Agile modelling (AM), Dynamic systems development method (DSDM), Feature driven development (FDD) and a range of others. Agile software development may not require all of these methodologies in order to achieve agility. However, all of the methodologies have their usefulness which enable development teams to create software according to the Agile manifesto ultimately to create quality working software for the end user.

Agile software development has changed the perspective of how people should view software development; which is not only an approach to creating working software, but as a community of enthused workers aiming to achieve the best for the end user by collaborating together efficiently.

P a g e |3

2 HTML 5 Hypertext 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. “Mark-up” refers to the syntax he opted to use which contained “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, and HTML4 and recently in 2012, HTML5.

All these versions introduced different web standards for the language which included: new approaches to syntax and efficient code, improved semantics and application programmer interfaces (API). Figure 2 below demonstrates how custom div ids 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 sufficient now.

Fig 1: 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

P a g e |4

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 web's 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 few browsers which presently support features of HTML5: Opera, Safari, Chrome and Firefox.

The new features introduced in HTML5 include: •

• • • • • • •

New Element tags – for instance the <canvas> tag: used for rendering drawings to the screen, or the <meter> tag: used for creating a graphical bar for representation of stats, or moreover, the <video> tag: used for embedding a video. Various other new tags exist.

New Attribute tags – height and width, autocomplete (forms), no-validate and more Full CSS3 Support – The new css3 platform for cascading style sheets Video and Audio 2D/3D Graphics Local Storage Local SQL Database Web Applications

HTML5 can be used to create many webpages containing multimedia content and also for creating browser games and native applications.

P a g e |5

3 Pulse game engine The pulse game engine is an open source Javascript graphics engine which was made by Modulus, a team of 3 developers based 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>

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.

P a g e |6

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. The engine may have as many scenes within the one engine. Each scene can have as many layers as the programmer desires. In turn, these layers can contain as many Nodes, i.e. Sprites, labels, objects, as is required.

Fig 2: 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

P a g e |7

The pulse game engine also contains a Javascript class within the engine which utilities the Box2D physics engine by Erin Catto. Box2D is an open source physics engine written in C++ for simulating rigid bodies in 2D. The pulse game engine has had 5 updates since it was released in January 21 2012. The developers, have issued a statement that the engine was going to have some important updates in the next six months (December 2012 â&#x20AC;&#x201C; May 2013).

However at the time, no such updates were made available on the website for other to download to date. (The end of March 2013)

P a g e |8

4 Tablets 4.1 Ipad2 The Ipad2 was released in March 25th 2011. It has a 9.7-inch LED-backlit glossy widescreen Multi-Touch display. The tablet has the apple mac operating system installed on it. It can be used in 2 orientation modes (horizontal/vertical) to provide a different perspective display to the user. Game designers must consider the operating system if they intend to release an application for people to purchase. Screen size is also something they must consider in order to display the content correctly and in the correct orientation mode for the tablet. Apple demand that developers must purchase a license from them in order to release applications for their devices. This costs $99 every year the developer wishes to pursue application development for an Apple product. Developing web applications for the device, do not require the purchase of the Apple license.

Fig 3: The Ipad2, www.prepaymania.co.uk, Last accessed: 02/04/2013

P a g e |9

4.2 Galaxy tab 2 7.0 The Samsung Galaxy Tablet 2 7.0 was released in April 2012. It is a 7â&#x20AC;&#x2122;â&#x20AC;&#x2122; tablet which has a 1GHz Dual Core processor with 1GB of RAM. The tablet has the android 4.0 operating system installed on it. Similar to the Ipad2, the tablet can be used in 2 orientation modes (horizontal/vertical). The galaxy tablet 2 7.0 has the Android operating system installed on it. This operating system unlike Apple, does not require that developers purchase a license in order to release applications for Android devices. Developing web applications rather than native applications means that game developers should ensure that the screen is sized correctly, that multi-touch is disabled and that the mouse scroll function is also disabled in order to display the content correctly and in the correct orientation mode for the tablet.

CSS (cascading style sheet) has to be used in order to ensure that the game screen is positioned correctly to fill the tablet screen and to disable multi-touch.

.page body. { :fixed; position position:fixed; :-8px; top top:-8px; :-8px; left left:-8px; background-color :white; background-color:white; }

#IfWinActive ahk_class Chrome_WidgetWin_1 { ::return ^WheelDown::return ^WheelUp::return #MaxHotkeysPerInterval 1000 } P a g e | 10

The positioning of the window can be adjusted via the body tag of the page. The margins can then be set accordingly. Using the IfWinActive tag will check if the current window is in use. If it is, then the WheelDown'and WheelUp variable would be set to false as their default values during the time that the windows is actively in use. Similarly, the hot keys that are are to be found on a standard keyboard, are set so that the user does not mistakenly interrupt their experience while using the touch screen device.

Fig 4: The galaxy tab 2 7.0, www.googlereader.com, Last accessed: 02/04/2013

P a g e | 11

5 Sof ofttware development 5.1 Software process models Software engineering practices - such as project management and programming testing - were defined in the 1960’s in the creation of software. The approach to creating software previously were linear and basic due to the quality of computers that programmers were using to create the software and their lack of awareness of more suitable approaches 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 customer's requirements were not sufficiently defined to enable the creation of acceptable software for the customer as many aspects of the development changed during the project. Moreover, the maintenance of the programming code with the code and fix model could not be reused in other projects which was a problem. The hard work that the teams invested during the development of the customer’s software, would be useless and would have to start from the beginning with new projects which was inefficient to the company/team's time and money.

Specific stages were implemented in order to resolve these difficulties during development yet they 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 heavyweight 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 the outcomes of a project 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.

Barry Boehm attempted to rectify these issues when he introduced the spiral model in 1988. The model also has a heavyweight, 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.

P a g e | 12

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; â&#x20AC;&#x153;matching to contract software, relying on risk-assessment expertise, and the need for further elaboration of spiral model steps.â&#x20AC;&#x153; 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 â&#x20AC;&#x201C; 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 heavyweight 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.

Additionally, 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 organises development processes cost effectively. The process models at that time in software development history still were not perfect but were becoming more efficient than they ever were. The heavyweight 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.

P a g e | 13

Fig 5: The “waterfall model” An iterative software development lifecycle. http://www.Blogspot.com Web. 07 Jan 2013

P a g e | 14

5.2 Examination of software development Improvements have been made to SD and it has been redefined since its inception in 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 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 to 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.

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 customer's specification. The spiral model by Barry Boehm aimed to change the negatives of the waterfall model but was still not too 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/organisations.

P a g e | 15

On the contrary, the methods are flexible enough for almost any SD team to implement if the team have focus. Large or small development teams have potential with ASD to become successful, yet not all projects achieve a positive end result. Different approaches to software development vary depending on the type of way a company/team chooses to operate. Kortmann et al (2009) below in figure 5 show a variety of approaches to software development.

Fig 6: Process cycle approaches to SD which contribute to Agile software development (with the exception of Linear which would be traditional software development) Kortmann, R. et al; 40th conference of the international simulation and gaming association 2009 P a g e | 16

6 Agile sof ofttware development 6.1 Agility in software development 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.” 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 “capitalising 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 be valuable to producing quality working software. An advantage of Agile is that team meetings are encouraged to occur daily, with the involvement of the clients and management in the project, in order to keep everyone informed of any changes or problems which can be resolved together. If the workforce knows exactly what to do and is getting on well with each other, the work is more likely to be of high quality. The development team themselves must ensure that they can work together and create the software conjointly; sharing their skills and working towards a quality end product.

Awad (2005) found that having a workforce that is 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 Agile's 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 team’s 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.

P a g e | 17

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

6.2 The values of ASD culture The four points below in figure 7 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 7: “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

Agile software development advocates the principles 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) Alistair Cockburn’s Crystal (clear) methodology, Amblers(2002) Scot Ambler’s Agile modelling (AM), Jeff De Luca's Feature driven development (FDD) Jim Highsmith's Adaptive software development (ASD) and DSDM consortium’s Dynamic system development Atern 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.

P a g e | 18

However, the heavyweight processes have been condensed into lightweight methods that can be used due to ASD. The important aspects of Agile methods are that they have enhanced the processes and interpretation of traditional software development: in terms of effectiveness of producing the final output and what software development means to each individual project. Traditional approaches make use of all available tools to create the end product which may not be 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 â&#x20AC;&#x153;XP and other Agile approaches are forcing organizations to reexamine whether their processes are adding any value to their organizations.â&#x20AC;? 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. The organisation may be too large to incorporate the changes Agile software development would bring to their development teams and management involvement in projects which, in the long term would be financially difficult to implement successfully for the entire organisation. Furthermore, Turk et al (2002) identified that Agile does not offer the quality control over software which is required to be safety critical. Pair programming for instance does not have the potential scope to highlight problems during a flexible project such as Agile would advocate the best method to develop software which in turn puts human beings at risk.

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 principles it attempts to instil. 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.

Moreover, the self-management workforce forges positive behaviour 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.

P a g e | 19

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 principles 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 table in Figure 8 below which shows a comparative view of approaches of software development.

Category

Traditional

Agile

Development Model

Traditional

Iterative

Focus

Process

People

Management

Controlling

Facilitating

Customer Involvement

Requirements gathering and delivery phases

On-site and constantly involved

Developers

Work individually within teams

Collaborative or in pairs

Technology

Any

Mostly Object orientated

Product features

All included

Most important first

Testing

End of Development

Iterative and/or drives code

Documentation

Thorough

Only when needed

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

P a g e | 20

6.3 Agile benefits and shortcomings The difference in an Agile development compared to traditional software development is the flexibility of each project which Agile offers to companies/teams.

Project management can keep all the aspects of 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 they must complete it. 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 via flexible framework which can highlight risks, compared to awaiting a particular time to identify if anything is troubling the project. 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.

In Agile the end user is involved in the projects development throughout. They benefit from the early releases of working software which can be shown to them and further discussion about features or issues can be resolved. The flexibility of Agile ensures that the end user is always happy with what is happening to their software and, in turn, the development team stay motivated to create the software knowing that what they are creating is suitable. Therefore, Agile offers a bond between all those involved in the project enabling them to collaborate together confidently and produce quality software.

However, one major 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 dissertation - 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 alongside XP. P a g e | 21

6.4 Methodologies 6.4.1 Scrum Scrum is a methodology devised 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 resolve.

This can be done during the meeting.

Each day, the Scrum master collaborates with the customer (product owner) - along with the development team - and keeps the project on task in relation to the product ownerâ&#x20AC;&#x2122;s product backlog (specifications). The development team then get to work in sprints (iterations) of 2 â&#x20AC;&#x201C; 4 weeks depending on the scope of the project. When processes/tasks have been completed, they are recorded so that the team can view diagrams, graphs and/or charts in the work environment: usually on a wall but may be presented on computer screens. The development team can then determine what remains to be done or how long they have to complete a particular task.

The team meetings help to commix the team with the project, and discussions about remaining work can be 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. The use of SCRUM makes the workforce feel in charge of their work. The principle behind the Agile manifesto state that the best architectures, requirements and designs emerge from selforganising teams. Teams managing themselves empowers them to work and to produce high quality software while collaborating together on coding and sharing knowledge. The customer then receives the section of work to demonstrate the latest features. The relationship between the product owner and the Scrum team improves on their trust for each other 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 a new project.

P a g e | 22

Fig 9: An example of a â&#x20AC;&#x153;SCRUMâ&#x20AC;? development cycle. http://www.scrumalliance.org Web. 07 Jan 2013

6.4.2 Xp 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 for 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 modelling which respects the Agile principals of communication, courage, simplicity and feedback, XP also values these attributes.

Motivating and consideration of the welfare of the team is paramount during development.

XP aims to make teams program "in the extreme" in contrast to traditional programming practises which did not encourage making the team or the code resource efficient. Teams operate in weekly or quarterly cycles (as in a business calendar year) within an XP framework. This 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 a wall which allows team members to discuss points and refine P a g e | 23

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 frequent re-factoring is important when using XP as this refines code which creates better usable 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.

6.4.3 DSDM Atern The earliest methodology to be accepted as an Agile method is Jenifer Sanders Dynamic Systems Development Model Atern (DSDM Atern) which is an improvement to the predictive project management method PRINCE2. DSDM eliminated the need for the BDUF (big design up front) approach, which required many details from the customer from the outset to structure the project. DSDM adapts to the customer's needs via accommodating alterations compared to Prince 2s method of processes to complete the development. Communication is done rarely via documentation but by social interaction. Similarly, Jim Highsmithâ&#x20AC;&#x2122;s book on Agile project management highlights that when choosing a model it is better to adapt to a current model rather than inventing a completely new one.

6.4.4 Adaptive systems development Adaptive systems development (ASD) by Jim Highsmith, begins by setting out to find the problem that the team are attempting to 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 to understand the system via research and preparing the data collected, in readiness to create/fix problems that may be encountered when building 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 modelling of the system is created and iterations take place to make the product. Adaptions are made during this phase if the requirements change or problems exist. The model is then evaluated to eliminate errors and a high quality product is delivered to the customer.

P a g e | 24

6.4.5 Feature driven development 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 agreed features to develop for the customer. Chief programmers set the task for members of the team to undertake. Those responsible for each class are assigned. 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 that has been made. Concurrently, the process of building the product by the defined features takes place during the development phase. The phases in FDD, of building and designing by features continue until the project is completed.

6.4.6 Crystal methodologies Crystal methodologies created by Alistair Cockburn are lightweight processes 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 of the 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 principles.

The main roles in the crystal clear method are the customer, 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.

P a g e | 25

Reviewing the projects status take place with workshops occurring every 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.

6.4.7 Agile Modelling Another method is Scott Amblerâ&#x20AC;&#x2122;s Agile modelling, which offers Agile developers a method for creating effective documentation during a project. It creates a discipline for creating documentation â&#x20AC;&#x153;when it hurtsâ&#x20AC;?. 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 difficult to communicate socially in a team may follow Agile modelling principles to resolve issues. Modelling 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 principles to adhere to which reflect Agile as a whole are; "simplicity, feedback, communication and courage."

6.5 The Growth and future of ASD Since the Agile manifesto document was created, there have been regular conferences held in various locations to enable people to get together and discuss areas of interest that agilists have noted in their own projects and can offer ways to improve/re-think their strategies. It also provides an opportunity to view exactly where software development is heading: making software development efficiencies and cost effectiveness within an Agile frame work. The conferences aim to raise awareness of Agile among software developers. The conferences and workshops have been successful and in 2012, Agile conferences reached the southern hemisphere in Brazil. Since software development is becoming a worldwide phenomenon as technologies become available, more companies e. could be benefiting by becoming Agil ile The Agile alliance who organised these workshops and conferences, are to broadcast the benefits of ASD to India in 2013. They aim to empower people of the community to discuss, with relevant people, what they do in a business environment. They have also confirmed on their website that the next conference in Nashville, USA is to be held in August 2013. Companies such as Amazon, Motorola and IBM are using Agile methods to release their products. If companies continue to have the desire for agility in their product/software development then Agile has the potential to grow further still.

P a g e | 26

ot otype development 7 Pr Prot oto 7.1 Int egrating an agile framework in a si ngle person nte sin team The central roles in the project such as, the programmer, sound engineer, project manager, designer and alpha tester were all completed by myself, at all times adhering to the principles of Agile software development. There were other external people involved in the project such as stakeholders - my computing honours module supervisor and moderator - game play testers and the creators of the game engine. At the start of the academic honours year, I agreed and defined my research. After some investigation into software development kits that would allow me to program an HTML5 game, I had to develop my skills to create a prototype which would be fun, playable, incorporate new technologies and be developed purely with Agile practices. I also researched the internet for suitable game engines to develop the programming code in. e's philosophy was to involve all those in the The first aspect of maintaining Agil ile project from the beginning, and indeed throughout the project. Meetings were arranged weekly with my supervisor. I also informed my moderator and he agreed to be a major stakeholder in the project. According to Coplien et al (2005) â&#x20AC;&#x153;Each organization has its own pattern of effective communication and development. â&#x20AC;&#x153; We agreed that when face-to-face discussion would be considered impractical in the hours outside of the University, so we would remain in contact through the university email system. I also informed them that I would be keeping a blog space online where my progress during the week would be visible to them - although Agile promotes communicating face-to-face daily, this was not feasible but weekly Agile software meetings and emails enabled regular contact. In the book "A development with Scrum"(Ken Swabber et al 2002): "Scrum meetings do much more for a team than just capturing information.

They don't only make everyone capture what they did, but it makes everyone say it in front of everybody else...It also makes everyone promise in front of everyone else what you will be working on next, so it puts everyone's credibility and trust to the test. Scrum is about deep social interactions that build trust among team members."

My supervisor, one of the stakeholders in the project, suggested that I should aim to produce a game for the tablet market. I decided that the Ipad2 would be a good tablet for which to develop the game. The first week was used to research the game engine. I started learning basic programming techniques such as rendering images to the screen and manipulating the image via key presses. The learning process did not take long and eventually, I created a working game menu. I looked into the engines facility to support HTML5's touch function for touch screen devices.

I had used the central storage site dropbox in previous modules for storing files and decided that it would serve its purpose well as a space for source control and keeping all my files in the one place. During the second week when I told some fellow students of my project, one of them said he had an Ipad2 and P a g e | 27

offered to test some of my code on it for me. I sent him the files I had create for the menu and he tested it on his Ipad2.

The touch function worked but the screen would not scale well on the Ipad2. He sent me the screen caps of the failed screen. I decided at this point in the week that I would make a gantt chart which would provide a mock time scale for completing the initial analysis and design work. Later in the week, after some researching and learning about how devices handle scaling, I resolved the issue of the scaling on the ipad2. When I sent my tester the code he sent me the screen capture of it working. I decided to start some of the coding for the physics element of the game. When I had set up the physics module of the engine in the code, it failed to work despite it being coded correctly. I decided to send the creators of the engine an email as none of their help pages stated any issues with the physics engine.

The creators of the pulse engine are based in Ohio, USA which meant I would have to wait to hear back from them because of the five hour time difference. Until then I decided to design some characters for the game. I had an idea of the genre of game in mind as my supervisor suggested an Egyptian theme. I named the prototype game "Tale of Kareem". Not being able to have daily meetings and working alone had its effects on me. I found that I was in a rather complex position with lots of work started, none of which could be completed at present with the certainty of being able to use them in the project. There were many things to document on the blog space in order to record and communicate my progress to date. I also decided to keep a daily log of progress in a text file. The design of the prototype game was done using FDD, DSDM Atern during the first twelve weeks.

The mix of these methodologies enabled the project to develop incrementally.

Unlike any other of the methodologies, the flexibility of FDD allowed for the unconfirmable features - due to problems - to be developed when they could be and other tasks could therefore take precedence. I began designing the characters and sprites adding features weekly to the game. Audio creation took place alongside the artwork development which was manageable due to the flexible working hours available within the Agile framework.

I ended the week with a progress review of my work so far. It was during this review that I realised that if some or all of the issues I was waiting to be resolved were not answered or just would not be resolved, there were risks for which I would have to develop fall back positions. I carried out a risk management assessment. I found that I would have to make a decision about an alternative game engine - which would have been "construct 2". I would also have needed to inform my supervisor and moderator of this decision. I realised that it would be best to continue to learn new skills with pulse in order to produce different game types and get familiar with construct 2 in the hope that the Modulous team would respond to my physics engine query. Further thought made me aware of what would be involved in changing everything.

I would have to create a scrolling physics game instead of real time physics. I also found that the statement: Simplicity-the art of maximizing the amount of work not P a g e | 28

done-is essential was profoundly important to this project - not least because I was attempting to use Agile software development, but because I was on my own doing a teamâ&#x20AC;&#x2122;s job every day. After each meeting with my supervisor when I had a discussion of what happened during the week or a discussion of an email I sent him regarding the project, I would go back home and write up an account of the week referring to my log and blog what happened that day.

In week three, Brandon, one of the three developers of the game engine, replied to me saying that I was correct there was a bug with the engine and the physics module. He also supplied code to try and sort my problem.

What was happening was that the physics global variable was being overridden by the physics engine, taking precedence over the pulse game engine when it was checking for physics interaction. The solution worked. I continued to work on researching the pulse engine and designing elements of the game with my graphics tablet. I identified elements of the design which I could work on in the following weeks such as power ups, music and story. In week 6 my tester told me he had to sell his Ipad2 which meant I had no way of testing the code I had done.

The most appropriate response to this news was by sending contact details on a University collaboration site. In a few hours I had a reply from a lecturer who kindly offered use of his Ipad2 but access to it would be restricted to the university. I responded to him that I would contact him if I could not find an alternative as I required use in my development environment: my home. When I met with my supervisor he said that I should develop for the Galaxy tab 2 7.0 as it was a similar technology but for the Android operating system.

He could authorise access for me to use one. While this was good news it meant I had to re-design all of the images for the screen size. In week 9, while awaiting the tablets availability to take home, I took a moment to tidy up some documentation that I had created. The documents actually came in useful in the later weeks. I created a design and technical document. I also produced a feedback form document which could be used to get information on how well the game would be received by a game play audience. During this week I also thought a lot about what types of classes I would require to get the game running efficiently. I created Class, responsibilities and collaborator cards which helped me think about what was going to be on the programming agenda in the next week.

In the following week I decided to have another project review and identify exactly where I was in relation to the entire honours project - prototype, learning new skills and the honours module deliverable documentation. After reading about Jim Highsmiths advice to teams reviewing their progress, I decided to make an assessment card of my own and put it on the blog space. This allowed me to organise my time better and also conveyed the position I was in to the stakeholders without waiting for the formal meetings which happened each week.

In week 10 I received the galaxy tablet 2 7.0 When I got it home and set it up, I soon realised that the physics did not work well on the tablet. It was running intermittently in the chrome browser. I then tried all the available browsers. None of them was able to sustain the speed of the engine processing the physics mathematics in real time.

P a g e | 29

At this point in the development of the prototype I was pleased that I had already considered creating a scrolling game on which I carried out unit tests and it worked fine on the galaxy tab 2. I had to review what features I could implement in the smaller screen with the potential of creating a fun and immersive runner game. In week 11 and 12 I was unwell. This is the only inflexible aspect of developing software adhering to Agile practices by yourself. I could not do as much work as I was usually capable of and was no-where near as enthusiastic as I normally would be. I carried on with planning and coding some elements of the introduction user interface for the Galaxy tab 2 7.0 screen.

At the start of week 13 I had the new menu and scrolling mechanics implemented.

It was then that the Titanium SDK reported an error with its internal files which caused the environment not to load. I searched Google for a solution but all I found was a help page saying that the effects of the error could not to be resolved and that the software required the user to re-program some files in the SDK directory. I made an informed decision to use the eclipse SDK, which I had already used in previous university projects as this would be an easier option. It also contained nothing better or worse than Titanium and was still free to use. The first semester was now over The main game mechanic coding of the game could take place now and into February, hopefully in time to carry out some research and play tests before my presentation in March. This would mean I could present a fully argumentative case that Agile software development can be utilised in a single person team.

By now I realised that Scrum with XP would be the way ahead for me to develop the remainder of the features of the game. I started with some re-factoring and revised the title screen layout for the smaller screen. I decided to make a feature list which I could track on my blog space - the space acting as the Scrum story board in a real Agile team environment. I decided to put a time scale on the final development so I could enhance my efforts to get the games 3 levels debugged and playable for the middle of February. 2 week Sprints were defined and many features in the feature list. For instance, the run animation for the main character, obstacles and more game play elements required programming. Over the two weeks I got to work and documented, as before, daily progress on the blog space and in my log text file.

I was making steady progress. I allowed my moderator to try the game and he said he was satisfied and to carry on with the development. Old features were getting ticked off, new ones could be put on or scored out which fleshed out the game more. At the end of the two weeks in January I reviewed my progress entirely. Similar to last time using the team assessment chart, I made one of the sprint in order to reflect and document what happened and what went well. What I found was that I had boosted my creativity using Scrum and Xp. Time was always an important aspect of the project to consider but making sure the work is being done and quality is maintained at a high level is considerably more important. Ensuring the standard is always high during the development, even if the worker(s) is enthusiastic and organised, can only be achieved by good short term thinking.

P a g e | 30

In his Agile project management book, Jim Highsmith states: That adapting to change is of greater worth to developing software than it is to following a plan. He states 3 points to consider in order to react positively to change: “·Envision – explore versus plan-Do ·Exploration versus production ·Adapting versus anticipating” Envisioning, exploring and adapting were values which contributed to the development of the prototype: learning new skills and communicating problems and receiving feedback.

I found that my efforts at this stage in the development were aiming to achieve the XP aims to inspire developers to achieve when creating software: Risk taking to achieve a goal while knowing what can be done due to the flexibility and short term thinking of the entire project. The developer must be courageous during the development of the project and must always be aware of his or her role and responsibilities in the project. I prepared myself for the final sprint of the project to get the final features working and playable. I made a back-up plan to account for some risks that may occur in order to produce quality working software to test before the date of my presentation. I made an energised work diagram to reinforce the aspects I had identified.

This highlighted the need to rest more and take breaks during the sprint rather than putting so much human effort into the work. The diagram reminded and empowered me that I was the controller of the flexible working times. The balance of work would still be achieved if I considered personal health and other work that needed attention. A single person doing all of the work meant it was quite an effort to produce your very best every day for two weeks for 9 hours a day. I did get a lot of features done in this time however which made it worthwhile. If Agile is to be truly integrated the development team/person should be enthusiastic, conscientious, ambitious and amicable. The statement of simplicity of the development is crucial.

Simple organisation, simple communication and simple design elements - refining processes that work, and expanding on failed processes - ensuring technical debt does not disrupt the development of software. A burn down chart was made to predict if there was enough time to finish the project in time to get organised to gather feedback on the game. The burn down chart showed that in the last 13 days I could potentially complete the prototype in 5 days before it would be too late to organise gathering feedback. I managed to finish the game.

P a g e | 31

8 Qualitative and quantitative research esti onn a ir e 8.1 The qu que stio nna I created a questionnaire document to obtain information from potential end users with reference to their view of the tablet runner game. The results of the game play test questionnaire documented the gamers experience. The testers were prompted with questions which provided research data for the game including both quantitative data as well as qualitative data. Maxwell et al (1986) attests that combining both of these research methods "deepens the perspective" which allows the results to be tested in context with the investigation in a bigger scale than reducing questions which cover one data range - be it purely quantitative or qualitative . 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) This view was certainly supported by the end results of the honours project research. I provided the potential gamers with access to the Galaxy tablet 2 7.0 to test the game. I did not interfere during the gamers experience in order to maintain complete impartiality. I then directed them to the website for the survey and they completed it. I gathered research data from 13 males and 6 females who participated in the survey. There were 12 people who were in the 18-25 years old category, 5 were 26 - 38 and 2 were above the age of 39. Compiling and analysing the results from all the gamers, I found that (14 / 19) “Enjoy Runner games”. (18 / 19) “Liked the Aesthetics”. (12 / 19) “Liked the Controls”. (14 / 19) “Liked the Game play”. (13 / 19) said it was a “respectable runner game”.

Finally, and most crucially, (16 / 19) Said playing the game was fun. In the survey I also included a field to assess how much people would be willing to pay for the game if it was put onto the Android market store for applications. The majority of people would pay £0.69 for the final version of the game. One person said between 59p and £1. Another person said between 60p and £1. This was particularly pleasing result as the majority of the 19 people who took the survey said that they would pay for the final version of the game. The reasons given by those who disagreed was that they expected the game to be free either at first or they already played better games which were free to play.

Only one person said that the game was not up to modern standards which prompted their disapproval of the games fun factor. They also expected the game to be free to play. The majority of people did not like the player jump game mechanic which proved to be annoying. Nonetheless, the challenge of the timing for jumping - which was noted to be completely different from any other runner game on the market - was also a positive aspect of the game as a whole.

P a g e | 32

Positive comments from the majority of respondents state that the game was frustrating and addictive but it needed work if the game was to become commercially available to the public market. One problem linked with this is the criticism of the tutorial screen which was not clear enough or attractive.

More visuals were recommended in order to provide the gamer with more information on what is happening on the screen. Another criticism was aimed at the controls of the game. While some agreed that they liked the controls and they were straight forward to use - "not many to remember" - the controls proved bothersome to a minority of the gamers as the "dexterity required to play the game was a challenge". One gamer said that the controls were hard to get to grips with but overall the experience was fun. One person stated in the comments section that the controls were simple. The feedback also included responses regarding some extra features which people would have liked to be in the game if the intention was to market it. Various suggestions to include in a production version were: a level points system, more levels, more fast pace, check points.

oto 8.2 Pr Proto otottype evaluation To consider the prototype as a success would be true. However, there were a few failures highlighted by testers during the play test. However, analysis of the data collected supports the view that incorporating the values suggested by the Agile manifesto is during the prototype's development is a success for Agile software development and of the project as a whole. The prototype received positive feedback in parallel to being fun and challenging. Furthermore, people stated they would purchase a copy of the game for a/their tablet device. The prototype followed the principles of the Agile manifesto throughout the project. It delivered the software on time, was able to adapt to change during the project smoothly, the people involved in the project were able to communicate and provide feedback on various aspects during each week of development. The prototype was also available to demonstrate when new features were ready. The positivity of the data collected supports the success that was achieved entirely. Agile values can be implemented in a single person team; and they can get positive results.

P a g e | 33

el and att ommendations 9 Mod ode ttrributes rec eco In a single person team project, adhering to the principles of the Agile manifesto while using Agile methods of developing software is a challenge. The difficulties that occur during the project emphasise the absence of a development team to support the project. The entire challenge of development with Agile is therefore, a personal one. The individual must accept the responsibility of dealing with all the occurrences during the development. In order to achieve success, the person must be prepared to learn and be determined and courageous to develop the skills required to compete the project well and on time. Identified by Ambler(2002, p. 25) he states that; “The best developers have the humility to recognize that they don’t know everything."

Fundamentally, the person should adopt a routine which encompasses the principles of agility. This routine should consider the best method of working within an Agile framework: the most appropriate development methods to use within the environment they are working in. Similarly in Agile software development IID is used and the best method of developing working software is chosen depending on the type of organisation. Project management must be in place within the Agile framework if the project is to go well. Barry Bohem et al,(1989) said that "win-win situations exist, and often they can be created by careful attention to people’s interests and expectations." The individual should therefore show leadership and most importantly, courage to organise their project and communicate changes frequently.

It is important to communicate well with all those involved in the project, daily in accord with the Agile principles. In the creation of the prototype I found that weekly meetings were a reliable and realistic approach to discussion regarding various problems during development. Although face-to-face is the best form of communicating, the email system worked well for the project outwith the normal hours of attendance at the University, to communicate any changes to those involved in the project - supervisor, moderator and for a brief period, my fellow student Jonathan. Beck (2005, p. 4) notes that using XP in Agile means that "you don’t prepare for failure. Keeping a little distance in relationships, holding back effort either through underwork or overwork, putting off feedback for another round of responsibility diffusion: none of these behaviours have a place on an XP team.”

In order to keep the development transparent during these times, I set up a blog space which was accessible by all. Despite the fact that in order to truly claim to e, you must be communicating with the development team and implement Agil ile sharing ideas, in a single person development team this is virtually impractical. In order to keep track of progress or ideas I had, I kept daily logs in a text file which I documented each day - like a daily meeting. They offer the ability to reflect on what has occurred previously quickly and any issues that are observed can be resolved.

Responding to changes in development can be done well in a single person team.

P a g e | 34

The flexibility of the individual aiming to complete tasks daily, allows for adaption to any changes to take place almost instantaneously. If problems do not arise, there is always something else that the person can use their initiative on, to reduce the amount of work they may have. When beginning to program, it is important to ensure understanding of how to use the development environment. It is also vital to set standards that will be used in the programming code files at the start to ensure consistency of readability of them. Xp is recommended to ensure the correct disincline is being invoked within the Agile framework. The programming code should be designed properly.

The code should contain the most appropriate data types ensuring that processes are running as efficiently as possible. The variable names should be meaningful to the programmer and others who may look at it - use of metaphors in the code will aid maintenance later in the development. Debugging and re-factoring regularly eliminates doing more work later to enhance the code and also induces an understanding of the overall code which has been created. Testing code should be done daily. Unit testing should be done for new features. Ultimately, doing this frequently will save investing time later in the development fixing errors or holding up other features that need to be completed. Martain(2008, p. 11Ch 1) makes a good point about ensuring the code written is designed well - 'clean' and is fit for the purpose it was built for â&#x20AC;&#x153;You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.â&#x20AC;?

This is an important aspect of Agile while developing software. Even in a single person development team, ensuring the code is readable and designed to its full potential for the application is important. Using Scrum along with XP while in the implementation phase of the project, will keep the project manageable. User stories written and documented ensure that continuous integration is re-enforced on paper - as no Scrum meetings can be had daily with one person doing the development themselves; effectively taking the role of the Scrum master and development team. Producing a sprint backlog is also a good idea to remind yourself of the time scale of the project. Reflection, just like in a team using Scrum, should occur at the end of the sprint to highlight the inefficiencies and allow the person to act on them for the next sprint. Beck (2005, p. 18) sums up this point aptly of the correct attitude when you reflect upon the practices used while programming: â&#x20AC;&#x153;When you encounter a problem, ask yourself if the problem was caused by a lack of communication. What communication do you need now to address the problem? What communication do you need to keep yourself out of this trouble in the future?"

Audio creation and art work can be created incrementally as the development of the project goes on. When there is room to define a feature and create, time must be assigned to get the assets created. This can be done at the same time as the programming is taking place because there is one person managing the development and making the decisions. The only weakness of creating the content is the skills required to make them. Time and effort must be made in your P a g e | 35

own time to develop these skills such as sketching. Creating animations also takes time which means that the person must be prepared to exert a lot of energy into the project. They must be enthusiastic throughout the project and have a keen interest it what they are doing. I recommend the following principles as a requirement for a single person adhering to the Agile manifesto and Agile software development to create software. In relation to my research, people should be aware of these attributes to give their project the best opportunity to become an overall success.

The single person tea m with Agile 10 att ribu sf ul pro eam ttribu ributtes for succes essf sful projjec ectts: 1. The art of simplicity - reducing the amount of work not done - is a pivotal aspect to get right at an individual level: it affixes flexibility and focus to the individual, meanwhile affecting the quality of the project and its outcome.

2. A highly motivated and amicable individual(s) is required: They must understand and adhere to all aims of the project and their role. They should be aware that such a project is a burden on their time and should always be giving 100% 3. Short releases of working software and communicating regularly is important because it can resolve issues or create new problems.

4. Similar to the self-organising teams, the best architectures, requirements and designs emerge from an organised individual who is intrinsically motivated to perfect everything about the development with amount of time available.

5. Planning in the short should be an aspect of an individualâ&#x20AC;&#x2122;s technical ability in the project: Envisioning, exploring and adapting are key stages they must do well 6. As with XP, individuals should be considered as human beings - not mere workers. Respect should be instilled during the project for their own time, health and wellbeing.

7. Regular meetings with key people involved in the project are a must: Unless changes or problems are being communicated, nothing can be done about them.

8. Always be aware of time constrains but it is not wasteful to document/model when the entire project is being carried out by a single person: It can aid design in the short term but it does not not need to be updated as too many aspects change.

9. Keeping logs of progress is a good idea so that they can be referred to for information about previous direction in the project if required - team meetings usually have meeting minutes, treat each day like a personal meeting.

10. Deliverable features should be considered regularly in a single person team.

Unlike a team who can delegate specific features to add - at a particular time in the project - the time and importance of the feature must be agreed by all people involved, and then developed in order to be delivered on time.

P a g e | 36

cl usi on 10 Con oncl clu sio In conclusion, creating HTML5 games for the Galaxy tab 2 7.0 can be achieved through single person development when the individual is following the principles of the Agile manifesto using Agile practices. The project successfully demonstrated the strengths and weaknesses of Agile software development and how it is used to create quality working software. Research has proven that Agile software development can be scaled up and downwards for different team sizes.

However, the individual(s) must be organised, reliable and determined to work to the best of their abilities. Agile also improves the trust between the customer and the development team through the short releases of the software and the daily involvement in the project.

Weekly meetings in person and email during the week strengthened the trust with those involved and also productivity as feedback could be given and points e. I didn't discussed in detail. Furthermore, I was able to do the project with Agil ile need to resort to traditional methods which contributes to the success of the research. I achieved it myself with no-one's help. The only team member I had was at the beginning where I kept in contact with my tester - but after this, testing was done by myself using TDD. It could be done quicker also - Jonathan worked during the days. Crucially, the values that Agile advocates were true. All of these traits of Agile software development in small and large teams were found to benefit software development with a single person development team. Examination of the Pulse game engine showed that HTML5 games could be made by learning how to program in Javascript, CSS and HTML5.

Development of the prototype was achieved during the first twelve weeks using FDD and DSDM Atern by designing potential features first and organising the project resources and tasks: with particular attention to the people involved. During the remaining twelve weeks of development I used Agile modelling, Scrum and XP. The practices contained in these methods ensured that the project went well and adhered to the principles Agile teaches. The development was centred on technical excellence, communication and simplicity. My research proved a success firstly that the combination of methods used to follow Agile principles enabled the game to be completed by the agreed time and was proven to be of a high quality.

Personal reflection occurred daily and a more in depth review taking place at the end of each sprint. Changes occurred frequently during the twenty-four weeks and the framework for development of the prototype was flexible enough to accommodate the changes and implement them on time and to a high quality. Agile software development is all about getting what the customer wants and the prototype was exactly what the customer wanted. To ensure that this was the case, communication and showing progress regularly was key to success. When the game was ready to be tested, academic research also supported that it worked well in accordance with Agile software development.

P a g e | 37

It was received well by those who provided their view of the game. The questionnaires were deigned to record quantitative and quantitative feedback on the game when they tested it to make certain that the feedback received gave a clear indication of the games success or failure. When developing the prototype I identified that the flexibility of Scrum and XP allowed the development of the game to increase when all the skills which were required to create the game were learned.

Another factor determining the dissertation's success is that when the software was completed, there was still time left over (2 weeks) which would have been enough time to make the changes people suggested for the commercial release of the prototype. Each point in the manifesto was being controlled within the Agile framework effectively but this was only because of ten vital attributes which my research identified regarding the environment and the people involved in the projects development.

Simplicity must be the main factor in single person development. The person must do everything possible to ensure that each part of the development is simplified to give them more time to perfect. It also means less work will need to be done which in turn means fewer problems to communicate and less feedback to receive. A highly motivated individual is a must. They must understand and accept their responsibilities from the outset and be involved right away. They should be enthusiastic about completing the project and aim to perfect every task they need to complete. Short releases of the software being developed allows for the customer and the developer to communicate better. It enables them to agree on certain aspects of the game and receive better feedback on what the customer wants. It also benefits the developer gaining a sense of reward for their hard work. The individual must be comfortable in their environment.

They must show courage, skill and initiative to complete the work. They must be the leader in the development of the project which requires them to learn from mistakes and perfect everything in the development. Short term planning is a must.

Reviews must occur daily to ensure all that is happening in the development will go smoothly and nothing will be forgotten either to communicate, or a task that may build up in the feature list. Value must be placed on the human needs of the individual. They must be able to recognise that their health is also important when developing software. In order to merge rest and developing a balance must be found which enables them to do the work to perfection while not fatiguing them.

Regular face-to-face communication is a must with all those involved.

Good time management must be in place. Modelling when there is time available is not a bad thing. Keeping logs/blogs and tracking progress aids understanding of the time scale and progress that has been made (and what remains to complete the project). All instances during the development require use of good judgment. It is important to develop the game to be delivered on time and at good quality.

Neglecting to be more efficient, or not communicate problems is not an option in Agile software development. Collectively, the project and research were a success.

The research demonstrated that new skills can be learned to support HTML5 and touch screen technology using Agile software development within a single person team.

P a g e | 38

In addition, research that was gathered regarding the testing of the game was positive. Conjointly, the research in the dissertation proves that one person can achieve the goal of creating an HTML5 game for the Galaxy tab 2 7.0. The issues of changes affecting development can be avoided/fixed using Agile software development. If Agile principles are understood and followed by the individual developing software, the project is likely to be a success.

P a g e | 39

Re Refferences [1] Amblers, S. (2002) “Agile Modelling: Effective Practices for eXtreme Programming and the unified Process”. New York: John Wiley & Sons, Inc. New York, 2002.

[2] Beck, K. (1999) “Embracing Change with Extreme Programming”, Journal detailing all the aspects of extreme programming by Kent Beck, Vol 32, Issue 10 [3] Kent Beck (2005). Extreme Programming explained: Embrace change.

Boston: Addison-Wesley.

[4] 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 [5] Boehm, B and R, Ross. (1989) “Theory-W Software Project Management: Principles and Examples”, Journal about management principles, Vol 15, Issue 7 [6] Boehm, B (2002) “Get Ready For The Agile Methods, With Care, Journal about agile methodologies”, Part1 of a Journal about agile software development methods and approaches, Vol 35, Issue 1 pp. 64-69, 2002.

[7] Bonoma, T.V, "Case Research in Marketing: Opportunities, Problems, and a Process," Journal of Marketing Research (22:2), May 1985, pp, 199-208 [8] Chau, T., F. Maurer, and G. Melnik, (2003). “Knowledge Sharing: Agile Methods vs. Tayloristic Methods”. In12th IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE2003). IEEE Computer Society. 302–307.

[9] Chau, T. and Maurer, F. (2004) “Knowledge Sharing in Agile Software Teams”, Journal assessing how teams collaborate in an agile software development environment, 2004, ISSU 3075, pp. 173-183 [10] 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 [11] Cockburn, A. (2002) “Agile software development”. Addison-Wesley [12] Cohen, D, Lindvall, M and Costa, P. (2004) “An introduction to agile methods”, Journal about the spiral software development model and software development , Vol 62, pp. 1 – 66 2004

P a g e | 40

[13] 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.

[14] Turk, D., France, R., Rumpe, B., 2002. “Limitations of agile software processes”. In: Proceedings of the 3rd International Conference on Extreme Programming and Agile Processes in Software Engineering. Sardinia, Italy.

[15] Dybå, T., and Dingsøyr, T. 2008. “Empirical Studies of Agile Software Development: A Systematic Review,” Journal: Information and Software Technology (50:9-10), pp. 833-859.

[16] Highsmith, J. (2001) “What is agile software development”, Journal about agile software development, Vol 15, Issue 10 [17] Hoda, R. J, Noble, S, and Marshall, S. (2008) “Agile Project Management”; Computer Science Research Student Conference, Christchurch, New Zealand, pp.

18-221. April 2008 [18] James O. Coplien & Neil B. Harrison (2004). Organizational Patterns of Agile Software Development: Prentice Hall.

[19] Kortmann, R., Harteveld, C. (2009) “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 [20] Lachlan. H. (2007). "A Preview of HTML5". Available: http://www.alistapart.com/d/previewofhtml5/structure-div.gif.

Last accessed 07th Jan 2013.

[21] Larman, C and Basili, V.R. (2004) “Iterative and Incremental Development: A Brief History”, Journal of the development approach in IID, Vol 36, Issue 6 [22] Larman, C . (2004) “Agile & Iterative Development: A manager's guide”. 5th ed.

USA: Addison-Wesley.

[23] 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 [24] M. Awad. (2005) “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.

P a g e | 41

[25] 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.

[26] Modulus team. (2012). Pulse game engine. Available: http://withpulse.com/about.

Last accessed 07th Jan 2013.

[27] 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 [28] Robert C. Martin. (2008). Chapter 1. In: Clean Code: A handbook of agile software craftsmanship: Prentice Hall. P11.

[29] 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 [30] Ken Schwaber, Mike Beedle. (2002). "Why does Scrum work ?. In: Agile software development with Scrum". Upper Saddle River, NJ: Prentice hall. 105.

[31] 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 approach to software development and how they can be integrated together, Vol 23, Issue 3 [32] Whitworth, E. and Biddle, R. (2007) “The Social Nature of Agile Teams”, Proceedings of the AGILE Conference 2007,Journal of how team work is implemented in agile teams, p.26-36, August 13-17, 2007

P a g e | 42

Glossa sarry TERM SD IID FDD DSDM Atern ASD RAM XP ASD Code and Fix

AM PRINCE2 BDUF UML Lightweight methodology LED CSS HTML Agilists

Agile/Agility

Sprint

Javascript

Plugin

MEANING Software Development Iterative and incremental development Feature driven development Dynamic systems development Atern method Agile Software Development Random access Memory Extreme Programming Adaptive software development A software development model which entailed programming the software for a set amount of time then fixing the errors after this process has been complete Agile Modelling PRojects IN Controlled Environments 2 Big Design Up Front Unified modelling language A methodology which is not as process intensive as traditional heavyweight methodologies Light emitting diode Cascading style sheets Hypertext mark-up language Someone who advocates the principals of the Agile manifesto document and who appreciates Agile software development. They may themselves be practicing Agile.

The ability to react to changes to the requirements efficiently and flexibly at any time during development. Also the ability to collaborate assertively in the attempt to resolve issues/get feedback to produce quality working software.

A period of time (typically 2 - 4 weeks) which is assigned to the development of software in the Scrum methodology A programming language which is used on web pages. It is used to allow the user to program interactive content for the browser.

Components of a piece of software which has the ability to interact with a bigger application (program) which enables use of it's features. For instance a javascript plugin for checkboxes can be used in the Pulse game engine

P a g e | 43

ne Append ndiix A - Implementing physics using pulse engi engine 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 for the world var worldAABB = new b2 AABB(); 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 = new b2World(worldAABB, gravity, true);

, 7 var

world

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

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

P a g e | 44

gn do cument Append ndiix B - Desi Desig doc 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.

P a g e | 45

P a g e | 46

P a g e | 47

hnical do cumentation Append ndiix C - Tec ech doc The technical documentation aided the thoughts about the requirements for the project to be a success. Particular attention to the document at the beginning of the project â&#x20AC;&#x201C; despite the many changes made since itâ&#x20AC;&#x2122;s creation, made planning easier to manage when changes were made to the requirements. It allowed ideas/concepts to be communicated easily to stakeholders during the initial start up phase of the project.

P a g e | 48

Append ndiix D â&#x20AC;&#x201C; Project management Dropbox enabled the storage of all the files and documents for the project in the one space. The website is accessible anywhere with a simple login and was free to use. I could keep track of multiple versions and any changes made could be recovered if a previous version was required. I kept versions of code, documents, daily progress records and documents of my dissertation work.

P a g e | 49

eli minary game development Append ndiix E- Pr Preli elim

P a g e | 50

Append ndiix E - Screen tes estts on ipad2

P a g e | 51

og e Append ndiix F - Pr Prog ogrramming cod ode

P a g e | 52

e protot yp e Append ndiix G - Asse setts crea eattion of th the oty

P a g e | 53

Append ndiix H - Final game play sc scrreen

P a g e | 54