Dzball Development With Extreme Programming
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Dzball Development With Extreme Programming as PDF for free.
More details
- Words: 450
- Pages: 3
Universidad del Valle de Guatemala
DZBall Development WITH EXTREME PROGRAMMING AGILE PROCESS METHODOLOGY
Team Members: Luis Carlos Aldana 08261 David Hsieh 08225 Eduardo Mejicano 08058 17/03/2009
DZBALL DEVELOPMENT WITH EXTREME PROGRAMMING (XP) AGILE PROCESS METHODOLOGY The project DZBall a mobile phone java based game, is being developed with the Agile Process methodology eXtreme Programming (XP), since it covers all our needs, our limited resources and small team meets the requirements, and it’s the most efficient methodology we reviewed for game development.
Whole Team Since our team is made up of three people, the whole team factor of the XP methodology fits best, because every member works in a whole team, every single member has the same picture or idea about the project, which satisfies the communication aspect. There will also be a member who plays the customer role; in most cases it’s a business representative who will define the features, priorities, tests and requirements of the product. This “customer” will communicate with the developers and the rest of the team, so that they can all develop and work in base of a customer needs.
Test-Driven Development Every software has at least a bug and more when it’s still on development, and these bugs are more noticeable on games, which is our case. Test-Driven Development means that during our development, our developers must make a test just after writing a feature’s code, so that the developers have a feedback on their and whole project’s progress.
Small Releases & Customer Tests Because DZBall will be a videogame, it’s exposed to not visible bugs by the team coders and testers, but also we don’t know if people will like the game. To take care of these problems, there methodology suggests making not few releases, but a small release in each single feature or set of small features developed and implemented on the application, in this case would be the game. Since there will be a release in each implemented feature, the customer will be able to try each new feature of the application, so the not seen by the team bugs would be reported, and also we will know what the customer thinks about the new feature.
PROJECT PLANNING Task
Start
End
Duration
Project Modeling
16/March 2009
01/April 2009
13 days
Code development *
02/April 2009
05/May 2009
24 days
Unit tests
06/May 2009
18/May 2009
9 days
Installation and testing on mobile device
19/May 2009
26/May 2009
6 days
Application testing and bug corrections
27/May 2009
08/June 2009
8 days
Final project presentation
08/June 2009
08/June 2009
1 day
*There will be a code test during the code development after making each feature.
This planning may be modified according to development changes.
DZBall Development WITH EXTREME PROGRAMMING AGILE PROCESS METHODOLOGY
Team Members: Luis Carlos Aldana 08261 David Hsieh 08225 Eduardo Mejicano 08058 17/03/2009
DZBALL DEVELOPMENT WITH EXTREME PROGRAMMING (XP) AGILE PROCESS METHODOLOGY The project DZBall a mobile phone java based game, is being developed with the Agile Process methodology eXtreme Programming (XP), since it covers all our needs, our limited resources and small team meets the requirements, and it’s the most efficient methodology we reviewed for game development.
Whole Team Since our team is made up of three people, the whole team factor of the XP methodology fits best, because every member works in a whole team, every single member has the same picture or idea about the project, which satisfies the communication aspect. There will also be a member who plays the customer role; in most cases it’s a business representative who will define the features, priorities, tests and requirements of the product. This “customer” will communicate with the developers and the rest of the team, so that they can all develop and work in base of a customer needs.
Test-Driven Development Every software has at least a bug and more when it’s still on development, and these bugs are more noticeable on games, which is our case. Test-Driven Development means that during our development, our developers must make a test just after writing a feature’s code, so that the developers have a feedback on their and whole project’s progress.
Small Releases & Customer Tests Because DZBall will be a videogame, it’s exposed to not visible bugs by the team coders and testers, but also we don’t know if people will like the game. To take care of these problems, there methodology suggests making not few releases, but a small release in each single feature or set of small features developed and implemented on the application, in this case would be the game. Since there will be a release in each implemented feature, the customer will be able to try each new feature of the application, so the not seen by the team bugs would be reported, and also we will know what the customer thinks about the new feature.
PROJECT PLANNING Task
Start
End
Duration
Project Modeling
16/March 2009
01/April 2009
13 days
Code development *
02/April 2009
05/May 2009
24 days
Unit tests
06/May 2009
18/May 2009
9 days
Installation and testing on mobile device
19/May 2009
26/May 2009
6 days
Application testing and bug corrections
27/May 2009
08/June 2009
8 days
Final project presentation
08/June 2009
08/June 2009
1 day
*There will be a code test during the code development after making each feature.
This planning may be modified according to development changes.
Related Documents
Dzball Development With Extreme Programming
April 2020 6
Extreme Programming
July 2020 9
Extreme Programming
April 2020 4
Sdlc - Extreme Programming
November 2019 27
Extreme
October 2019 41