T-76.4115
Software Development Project
Group 11 – Game On! Solutions
Project Plan

1.
Introduction
2.
Stakeholders and staffing
3.
Goals
3.1
Project goals
3.2
Personal learning goals
4.
Resources and budget
4.1
Personnel
4.2
Materials
4.3
Budget
5.
Work practices and tools
5.1
Practices
5.1.1
Iterative development
5.1.2
Iteration planning
5.1.3
Documenting
5.1.4
Risk management
5.1.5
Time tracking
5.1.6
Communication
5.1.7
Iteration demo
5.1.8
Defect tracking
5.1.9
Version control
5.1.10
Coding convention
5.1.11
Process improvement
5.1.12
Requirements engineering
5.1.13
Design
5.2
Quality assurance plan
5.3
Tools
5.4
Standards
6.
Phasing
6.1 PP Iteration
7.
Risk log
Change log:
19.10.2006 Initial version of this document / IL
20.10.2006
Additions to most parts of the document / JJä
22.10.2006 Refined few sections / IL
5
5
5
6
6
6
6
6
6
7
Page
3
3
4
4
4
7
7
7
7
7
8
8
8
8
9
9
10
10
10
11
2

Game On! Solutions signed on to a project for G-cluster to develop a GUI for Game on Demand Service with PHP.
The end-users of the system will be able to access the catalogue of games available in the service, to find a game to play, people to play it with and to start the game.
Members of the developing team:
Project manager
Ismo Lehmus
61064V
050 309 6360 ilehmus##cc.hut.fi
QA manager
Juuso Jääskeläinen
63828J
050 346 6646 jpjaaske##cc.hut.fi
Developer
Joni Leiponen
54251H
0408255981 jleipone##cc.hut.fi
Developer
Tapio Auvinen
62994L
040 756 2742
Developer
Antti Pihamaa
48669M
040 717 5359 apihamaa##cc.hut.fi
Architect
Antti Kaunisto
47950R
050 323 3233 kantti##g-cluster.com
Developer
Jukka Merinen
58048D
040 534 3377 jmerinen##iki.fi tsauvine##cc.hut.fi
Architect Antti Kaunisto and developer Joni Leiponen are currently employed by Gcluster so they have good insight of the company and what they are looking for in this project. All members of the development team want this project to succeed and make sure that the result is of the best quality.
Development team’s mentor
Kari Suhonen
050 351 0241 kari.suhonen##hut.fi
G-cluster contacts:
Technical advisor
Samppa Turunen
040 500 2023 samppa.turunen##g-cluster.com
European sales manager
Stephen Ross
040 733 7789
3

4
3.1 Project goals
Client’s goals
Concept
Presentational tool
Description
Something to show to potential clients / new employees
A reference solution
A ready solution if G-cluster’s client doesn’t want to implement their own system
Documentation of the problem
Documentation of possible problems / limitations of set-top boxes. domain
Testing for external components
Consult the User Requirements Documentation for more precise descriptions of the business goals.
The development team’s goal is to efficiently create a system and documentation that fulfils customer’s needs and expectations. The team also tries to learn how to actively communicate without the need to regularly meet face to face.
3.2 Personal learning goals
Ismo Lehmus
Juuso Jääskeläinen
Project managing in general, maintaining active communication between group members and with customer.
Requirements generation and management, regression testing and in general more experience of doing a more thoroughly documented and tested software project.
Experience in using various tools.
Antti Kaunisto Gain more insight into SW process formalities.
Joni Leiponen
Antti Pihamaa
Gaining experience in working in a medium scale software project. Improvement of architectural opinions regarding consumer level software.
Getting experience in project management tools, php-framework and working in a group.

5
Jukka Merinen
Tapio Auvinen
Working and collaborating in a software project and to learn good software development practices.
Learn SQL, working in a large group and to estimate effort. Trying new tools and see if they are worth using.
4.1 Personnel
Member PP I1 I2 Total
Ismo Lehmus
Juuso Jääskeläinen
Antti Kaunisto
Joni Leiponen
Antti Pihamaa
Jukka Merinen
Tapio Auvinen
Total
50
50
30
30
10
10
10
190
60
60
70
70
80
80
80
500
60
60
70
70
80
80
80
500
170
170
170
170
170
170
170
1190
The table above is only a rough estimation of how every member’s time is allocated between the iterations. It will be updated to correct numbers as soon as the correct numbers are delivered to project management.
4.2 Materials
Since the result of this project will be used on a variety of environments, it is necessary to have access to all of those for testing purposes. Most challenging will be the set-top boxes because their browser is of limited capabilities. These set-top boxes are needed in the testing phase and customer has promised them to be ready at that time.
The project management and SCM tools are located on a server that the customer has provided the development team with. All used tools are open source and there are no restrictions on them.

6
4.3 Budget
1190 hours times 15 to 20 euros per hour equals roughly 17800 to 23800 euros.
The real costs to the customer are only the time spent in meetings / reviewing the documentation and the 3000 euros that goes to SoberIT.
5.1 Practices
5.1.1 Iterative development
Feedback from the customer comes through weekly meetings.
Every development team member is responsible for their own scheduling within the given deadlines. Internal deadlines are decided by the SE experts when creating iteration plan and the project manager follows up on them.
5.1.2 Iteration planning
Iteration planning is done by the SE experts after consulting the customer. The consulting is carried out at the same weekly meetings as the feedback comes from.
Effort estimation is carried out with the developer who the task is assigned to.
5.1.3 Documenting
Project plan is created maintained mainly by the project manager with assistance from other SE experts who give opinions, provide information and review the document.
The developers provide a part of the information.
PP Iteration plan is created by the SE experts using the information the customer provided. Maintaining the document was done by the project manager.
Architecture documentation is created by the architect. A draft of system architecture is already created for internal use of the development team but will not be delivered at the end of PP iteration.
User requirements document is created and finalized by the QA manager. The requirements were discussed at the weekly meetings between the SE experts and the customer. Maintaining of the document is QA manager’s responsibility.
The customer is responsible for checking all the published documentation that they conform the NDAs.

7
5.1.4 Risk management
The risks are initially identified by the SE experts. After that the risk log is updated whenever a new risk is introduced or a risk’s status or impact changes. The updating is done by project manager.
5.1.5 Time tracking
Time tracking is taken care of with Eventum. This will be clarified as soon as the project management is more familiar with the tool.
5.1.6 Communication
TikiWiki is used to facilitate document sharing with the project team. An IRC channel and Skype conferences provide alternative means to communicate in addition to faceto-face meetings.
Google docs might be utilized in addition to the TikiWiki to allow for collaborative development of some documents.
5.1.7 Iteration demo
The SE experts will create a progress report for the demo presentation.
5.1.8 Defect tracking
Defect tracking is done with Eventum in the same manner as the tracking of general features. All development team members have the rights to create new defect-issues in Eventum when ever a bug is found and an obligation to do so.
5.1.9 Version control
SVN is utilized for version control. The commits are linked to issues managed in
Eventum.
Every developer will check in regularly before starting the development work and everyone will commit the changes when he has finished the development work.

8
5.1.10 Coding convention
A separate document is created and maintained by the architect regarding the coding convention. This document will cover basic syntax; class, variable and method naming; preferred structures; commit convention; documentation guidelines and all other necessary subjects.
A code review will be done after the very first code writings are done to check that all developers have understood the coding convention correctly.
Strict MVC (Model-View-Controller) layering is followed in all code generated.
PHPCodeSniffer may be used to automatically test code syntax compliance, either daily, per commit or at other chosen intervals.
5.1.11 Process improvement
Process improvement ideas and proposals are collected throughout the whole development project by the project manager. Proposals are then reviewed by the SE experts and it will be decided if they are implemented.
In addition to the proposals, a reflection workshop is kept after every iteration to discuss what could be done better.
5.1.12 Requirements engineering
A separate document is created and maintained by the QA manager.
5.1.13 Design
A more thorough separate document is created and maintained by the architect.
Architecture, development tools and constraints are mostly mandated by the customer needs. The customer has required the use of PHP language, MySQL and Apache fore the implementation phase. The customer also provides an initial implementation which will probably not be used in the project for anything but requirements elicitation and as a basis for some minor components.
The lightweight CodeIgniter MVC framework is used as the basis of the system’s architecture. The choice was made after exploratively narrowing down and the more thoroughly evaluating four commonly used PHP frameworks. The MVC layering will provide for the ability to change parts of the business logic with stubs, to provide different views for different clients and so on. Domain model pattern (PoEAA 116) will be mainly used for modelling business logic. Other major architectural patterns utilized are listed below:
- Model View Controller (PoEAA 330)
- Template View (PoEAA 350)

9
The structure of the persistency interface will most likely be either Active Record
(PoEAA 160), Row Data Gateway (PoeAA 152) or Table Data Gateway (PoEAA
144) or a mix of these. Object-relational mapping will not be used.
Concurrency is not a major problem due to the majority of selects among the database accesses in the system. PHP sessions, i.e. Server Session State (PoEAA 458), and user accounts will be utilized to provide for statefulness in a stateless HTTP environment.
5.2 Quality assurance plan
Quality assurance plan will be created and maintained as a separate document by QA manager.
5.3 Tools
PHPEclipse is used as the preferred IDE for development. Developers are free to choose other similar IDEs due to personal preferences.
PHPUnit3 unit testing framework is utilized for unit testing, and coupled with
PHPEclipse through a plug-in. CruiseControl and Phing may be used for continuous building / build process automation, respectively, if deemed helpful.
Zend CodeAnalyzer will be used for static analysis of generated code.
Selenium is utilized for front-end testing with the tests primarily generated with the
Selenium IDE plug-in to Mozilla Firefox.
TortoiseSVN is used as the SVN client for Windows.
Apache is the HTTP-server which the system runs on.
MySQL is the database management system that is used to implement parts of the
GUI. Version?
Eventum is PHP/MySQL based issue tracking system that the development team uses for general project management. It will also be used for time tracking and reporting.
Recent versions of the major browsers (IE, FF, Opera, possibly Safari) will be used for browser compatibility and visual testing. Set-top box setups provided by the customer will be used to ensure compatibility with those client environments.
OpenSTA or similar suites will be utilized in the later stages for stress testing.

10
5.4 Standards
There are no “must follow” standards defined for the development team.
The iteration plans are created and maintained as separate documents by the project management. Mostly this is done by the project manager and the other SE experts provide him advice and consultation.
In the first iteration we will implement the core features of the system. After the first iteration we should at the least have a replacement for the currently used simplistic front-end system.
In later stages and in the second iteration the work will focus on adding optional functionalities and to perfecting usability and visuals.
6.1 PP Iteration
Deliverable
Project plan
PP Iteration plan
Requirements document
Progress report
Architectural design
Task
Assignee Time used
Ismo Lehmus & Juuso Jääskeläinen
5h / person
Ismo Lehmus 6h
Juuso Jääskeläinen
Ismo Lehmus
Antti Kaunisto & Joni Leiponen
5h
Assignee Allocated time
1h
3h
Implement web pages
Contact graphic designer candidates
Decide on used framework
Decide on coding convention
Design architecture
Review old code
Tapio Auvinen
Ismo Lehmus
Antti Kaunisto & Joni Leiponen
Antti Kaunisto & Joni Leiponen
Antti Kaunisto & Joni Leiponen
Antti Kaunisto & Joni Leiponen
Write architectural design documentation
Decide on what version control software to use
Antti Kaunisto & Joni Leiponen
Ismo Lehmus & Juuso
Jääskeläinen
Juuso Jääskeläinen
Define requirements for the product
Decide on issue tracking software Ismo Lehmus & Juuso
Jääskeläinen
Decide on time tracking software Ismo Lehmus & Juuso
Jääskeläinen
2h
2h
2h
2h
3h
1h
Included in meetings
3h
2h
2h
2h
2h
1h
2h
Used time
1h not done
1h
4h
2h

11
Decide on risk management practices
Ismo Lehmus & Juuso
Jääskeläinen
Install all necessary tools Antti Kaunisto
Decide on communication practices Ismo Lehmus
Decide on documentation practices Ismo Lehmus
Meetings with the client Ismo Lehmus & Juuso
Jääskeläinen & Antti Kaunisto &
Internal meetings
Joni Leiponen
All members
1h 1h
6h
1h
8h
1h
1h 1h
10h / person 10h / person
9h / person 9h / person
Risk
Hardware problems
Server-client architecture
Description
Server breaking down, tools and code base lost
Shortage of human resources
People getting sick, other activities that take time
Customer unavailable
Customer’s contact person unavailable, for instance a business trip
Multiplayer and other player-toplayer functionalities can not be implemented in the client operating environments due to the strict serverclient architecture and limited support for techniques to circumvent that.
Avoidance
Keeping most important issues somewhere else also, keeping backup of the code base.
Constant development, information sharing
Active communication between the team and customer and planning the schedule of meetings.
The multiplayer functionalities will be simplified. Available techniques for circumventing the problem (auto-refreshing) will be used. Separate versions for environments supporting asynchronous scripting might be created.
Probability Impact
1
3
2
5
References:
PoEAA: Martin Fowler, Patterns of Enterprise Application Architecture 2002. Pattern catalogue available from: www.martinfowler.com
4
2
3
5