Project Plan Name of the group (edit)
Version Date Author Description 1.0 18.6.2007 Vanhanen 1.1 28.9.2009 Rainio Project plan first version (Ch 6.1 and 6.2).
More detailed pp-tasks with time estimates. Important dates 1.2 9.10.2009 Rainio listed. Reflection workshop information added. Responsibilities for deliverables added. 1.3 16.10.2009 Rainio Chapters 1-7 initial version.
Contents
1. Introduction 5. Work practices and tools 2. Stakeholders and staffing 6. Phasing 3. Goals 7. Risk log 4. Resources and budget
1. Introduction
1.1 Overview of the system
In the Happyoffice-project for Rocky Advertizing shall be created a browser-used solution for time tracking and scheduling. In essence it is a calendar view where you can paint events for yourself or multiple participants. Ease of usage is the most important criteria for the product. Rocky advertizing has evaluated the existing time tracking solutions out there and they haven’t been able to find an existing product that would be sufficiently easy to use. They have applied for financing from Keksintösäätiö for developing this solution.
In the first phase the product shall replace Rocky’s old time tracking system, but later on it may be sold to other interested parties or distributed as freeware software. 2. Stakeholders and staffing
The following picture depicts the stakeholders in the project. Their roles are described below the figure.
Figure 1. Organizational chart (no template given).
2.1 Rocky Advertizing
Rocky Advertizing is the most important stakeholder in the project. The original idea for the solution is owned by Rocky and they shall also be the primary user of the resulting product.
Heikki Kärkkäinen is the project owner at Rocky. He makes the final decisions considering solutions and end results.
Antti Vaahtersalo is the technical expert at Rocky. Questions related to the technical implementation choices shall be discussed with him.
Users of Happyoffice can be any employee at Rocky. They shall use the end product and should thus be asked for opinions about the usability etc.
Emails at Rocky are in format [email protected]
2.2 T-76.4115-course The project shall be done for the course T-76.4115/5115 and thus the requirements of the course have to be considered. Mentor is assigned to the group by the course. Our mentor is Atso Koskinen ([email protected]).
2.3 Hosting service provider
We have rented a virtual host from Futuron (www.webhotelli.fi).
2.4 Possible client for the system
Rocky may be selling the solution to other companies.
2.4 Balboa team
The Balboa team consists of three Software engineering experts and six developers. The team gathers understanding of the solution to be build, created requirements, splits them into tasks and implements the system. Our team consists of the following members
Role Name Email Phone PM Ohto Rainio o
Contact information can be found from https://wiki.tkk.fi/display/t7641152009TeamBalboa/Contact+information
Teams web page can be found at https://wiki.tkk.fi/display/t7641152009TeamBalboa/
E-mail to the whole team is balboa at teemukoskinen dot com. 3. Goals
3.1 Project goals
These goals have been derived from the discussions with the customer.
Table 1: Goals of the customer in the priority order
Goal Verification criteria 1. Working By the end of the project Rocky will be able to fake the HappyOffice time functionality of tracking and scheduling solution into usage at their every day work replacing scheduling and time the old time tracking solution. tracking The usability of the system must be good. Users must be able to use the 2. Ease of usage system without reading a manual. The final validation is done by the customer who decides whether the usability is there. The system has to be such that it can be sold or given to use to other 3. Can be sold to companies than Rocky as well. It will work with the SaaS (Software as a other companies Service) model meaning that the system is hosted in one place and can be used by a myriad of users and companies over the net. The system must support mobile extendability. The system must be designed so that it can be later extended to be used in mobile phones without 4. Mobile significant changes to underlying business logic. The architecture of the extendibility system has to be such, that all the calls made between business layer and UI can be replaced easily with another technique than the currently implemented one. 5. Multi language The system must support multiple languages (Finnish, English, Swedish). support The primary language is English. Security. The clients can't access other client’s information in any way (including user interface and raw communication between user interface and 6. Security the server). Passwords must be encrypted. Users can’t see events they are not meant to see. Documentation. The system must be well documented so that it can be later 7. Documenting extended by other developers. The documentation is validated by the customer. The system must at least support a later adding of a reporting functionality if 8.Reporting not implemented within this project. This means most importantly that the functionality Database structure must support generating reports out of the event data per user, per project, per client, per time period.
3.2 Personal learning goals
Table 2: Personal learning goals
Member Personal learning goal I'm eager to apply in practice the project management tools and techniques that I've learned at TKK courses. I'm waiting to work with a big team and hope that we are able to build a successful end product for Ohto Rainio our client. It is also interesting to work with a client who hasn't that much experience in IT-projects and trying to figure out the best ways to communicate and ensure the end result will be useful. I want to learn about QA-practices and how a QA-manager works in a team. I'm especially looking forward to see how TDD and unit testing Mikko Vestola helps to produce quality software in practice. I'm also interested in how to produce software with good usability. I have implemented many www- projects with php from a scratch without using any php frameworks. So I'm interested to learn what kind of Ville Harvala solutions do the frameworks offer. I'm also interested to learn what kind of challenges does the project offer in the perspective of an architect. My goal for this project is to widen my perspective about software development projects. I'm excited about working with our customer who Teemu Koskinen seems genuinely interested in the project. Personally I look forward to learning both technical and social skills in an environment that is similar to real-life IT projects. I'm interested in learning new technologies and getting to apply them in practice. This is an excellent opportunity to gain some coding experience and to work with different kinds of development tools in a real project Marja Käpyaho setting. This particular project is also very usability oriented and I'm interested in being a part of the design of a real user interface. And, of course, I look foward to working with our great team-mates! I'm interested in learning about practical software development in a more Risto Laurikainen or less realistic setting. I'm also going to take this course as an opportunity to learn about new technologies and how they all fit together. Im interested getting from simple hobby and school projects to this "real- life simulation". Im eager to see, how can I apply my knowledge from other projects and past experience to this project. This is a huge project Nick Eriksson compared with my previous projects, so I see this a chance to learn about real-life projects and working at this level. Also interested in learning new practises and frameworks. As I have no experience working in a software company, I am excited to be able to work in big team environment. I hope that this will allow me to understand what it is like to work in software company and bring Osmo Salonen understanding to the dynamics of a larger team. In addition I'm looking forward to learning new technologies and building quality software for our client. The last but not the least goal is to make new friends and contacts. I look forward to getting to know web development with PHP and the related frameworks. So far I have developed web applications with Java and its frameworks only, so real PHP development — as opposed to some Ville Saalo simple hobby projects — should prove interesting. I would also like to participate in the high-level architecture planning, but I also feel that I have got some strong views on what works from the end user's point of view, so I would like to stick my nose into the user interface design, too.
4. Resources and budget
4.1 Personnel
Work is scheduled per week per person. The vacation is held between week 50 and week 3. Developers are planned to use 80% of their time on iteration 1 and 2 and 20% for project planning iteration. The weekly cumulative planned and realized hours per person can be seen in the following table. Iteration Project plan Iteration 1 Iteration 2 Week 39 40 41 42 43 44 45 46 47 48 49 50 3 4 5 6 7
Planned and realized cumulative hours per person Ohto 20 40 60 80 90 99 108 118 127 136 145 155 164 173 182 192 201 Ohto 39 56 72 Difference 19 16 11 -80 -90 -99 -108 -118 -127 -136 -145 -155 -164 -173 -182 -192 -201 Mikko 12 24 36 49 56 63 71 78 86 93 101 108 116 123 131 138 146 Mikko 8 24 Difference -12 -17 -13 -49 -56 -63 -71 -78 -86 -93 -101 -108 -116 -123 -131 -138 -146 VilleH 7 15 22 29 38 47 57 66 75 84 93 102 111 120 129 138 147 VilleH 15 24 Difference -7 0 2 -29 -38 -47 -57 -66 -75 -84 -93 -102 -111 -120 -129 -138 -147 Nick 7 15 22 29 38 47 57 66 75 84 93 102 111 120 129 138 147 Nick 2 9 Difference -7 -13 -13 -29 -38 -47 -57 -66 -75 -84 -93 -102 -111 -120 -129 -138 -147 Teemu 10 20 30 40 53 65 77 90 102 114 127 139 152 164 176 189 201 Teemu 14 27 Difference -10 -6 -4 -40 -53 -65 -77 -90 -102 -114 -127 -139 -152 -164 -176 -189 -201 Marja 10 20 30 40 53 65 77 90 102 114 127 139 152 164 176 189 201 Marja 11 24 Difference -10 -10 -7 -40 -53 -65 -77 -90 -102 -114 -127 -139 -152 -164 -176 -189 -201 Risto 6 12 18 24 31 39 46 54 61 68 76 83 90 98 105 113 120 Risto 9 19 Difference -6 -4 1 -24 -31 -39 -46 -54 -61 -68 -76 -83 -90 -98 -105 -113 -120 VilleS 6 12 18 24 31 39 46 54 61 68 76 83 90 98 105 113 120 VilleS 13 16 Difference -6 1 -3 -24 -31 -39 -46 -54 -61 -68 -76 -83 -90 -98 -105 -113 -120 Osmo 10 20 30 40 53 65 77 90 102 114 127 139 152 164 176 189 201 Osmo 13 23 Difference -10 -8 -8 -40 -53 -65 -77 -90 -102 -114 -127 -139 -152 -164 -176 -189 -201 SUM (plan) 89 178 267 356 443 530 616 703 790 877 963 1050 1137 1223 1310 1397 1484 SUM (act) 39 139 235 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Difference -50 -40 -32 -356 -443 -530 -616 -703 -790 -877 -963 -1050 -1137 -1223 -1310 -1397 -1484
4.2 Materials
Hardware
We are using computers accessible to Students at the Helsinki University of Technology. In addition to the computers, we have a virtual server has been rented by Rocky for our development use.
Software
We shall do the developing using Aptana Studio with Eclipse. We are developing with PHP over Debian Linux. We are using SVN for version control, AceProject for project managing and time tracking and GoogleDocs for easily sharing documents.
4.3 Budget
We have calculated the budget as follows:
Budget item Cost (€) Total Team work hours (h) 1484 70 103880 Rockys hours (h) 100 200 20000 Computers, 6 months 9 50 450 Server 1 30 30 124360
5. Work practices and tools 5.1 Practices
5.1.1 Iterative development
Iterations are divided into weeks. We have working time scheduled every monday from 10-16 and every friday from 10-16. Every monday we also have a compulsory meeting from 13.00-14.00 when the passed weeks developments, problems and further development is discussed. The team will be mostly working in the planned working hours together in the room we have booked.
Sprints
The two iterations are each divided into three sprints: Sprints 1 - 6. In the beginning of the two iterations, we will (re)prioritize the requirements with the client and choose the requirements to be implemented. The list will be refined after each sprint. In each spring we choose the tasks that will be implemented. After each sprint we can analyze how well we have reached the goals and show the working version to the client who can give feedback based on the result. We have set meetings with the client at the end of each sprint. The requirements analysis is done at the end of each sprint. In the end of the requirements analysis, the requirements prioritizations are updated. The acceptance testing for features is done by Rocky and by the team whenever a new increment is made to the system. The working version of the product will be available on line.
5.1.2 Iteration planning
Iteration planning is done at the end of the previous iteration and the beginning of the new one. This always includes the iteration demo, after which the next iteration is planned with the client. This includes selecting the requirements in order of importance to be implemented in the iteration. Scheduling and task planning is done after the requirements have been selected, so the iteration document will always be planned and documented for the course deadline. The tasks, time estimates and deadlines are typed to AceProject.
5.1.3 Documenting
The project manager is responsible for document deadlines. He is also responsible for the documentation of technologies for the client. One review is required for each document, and usually performed by the architect or the QA manager. QA manager is responsible for the QA-plan, requirements and task documenting.
5.1.4 Risk management
Risks are discussed with the team and client and elaborated within the team in the planning phase of each iteration and the reflection workshops. The risks are documented in a risk log and monitored by the QA manager. For all the risks with negative impact on the project, the way to minimize the risk is documented and implemented. In addition, a contingency plan for each risk is crafted. Risk status is communicated to the customer in the weekly mail if relevant.
5.1.5 Time tracking
The time tracking is done in the project management environment. There is a ready support for time tracking in AceProject. After each working session, each team-member will update their time log. Once per week the time log is also uploaded to the wiki. In the wiki, the time logs are analyzed according to work realized compared to work scheduled for each team member and the whole team. In this way it is easy for the team and all stakeholders to monitor how much effort has been made. A Work scheduled per work performed chart is made on task level for each iteration. Tasks are created by the developers under the supervision of the QA-manager.
5.1.6 Communication
The team has two set working times per week, and the team will mostly be working at these times as agreed. Communication is planned by the project manager so that all known issues can be addressed at the meetings. In addition, each Monday we have a meeting where current issues are addressed, and the most important decisions are made. We will go through what has been done, what will be done, and what problems have occurred. Each Friday the status is reported to the mentor and the client. Other communication channels used by the team are:
o Email o For information that needs response for everyone on the team. Response is requested in the mail and if it is not received the person will be approached by phone or in person. o IRC o Mainly for communication during development, when someone wants feedback on something. o Telephone o For specific questions to specific persons
The communication with the mentor is done through weekly mails and other mails on important issues. The mentor is also always invited to the weekly coding sessions on Fridays or Mondays. In addition, other feedback meetings with the mentor will be arranged. The communication with the client is done mainly through email (weekly mails), the wiki and by telephone on issues that require feedback. After each spring we have a scheduled meeting with the client.
5.1.7 Iteration demo
The demos are prepared by the project manager in collaboration with the project management team. The project management team takes care of ensuring the software demo.
5.1.8 Defect tracking
AceProject system is used to track defects. The status of a defect can be seen from the system. At least a list of the existing bugs is provided for the peer group. Only one defect is described in each defect report. The defects are used in improving our processes and tools so that defects of the same type could be avoided.
Defect report includes following information:
o defect type (bug, …) o description o status o priority o steps to produce (and repeat) o date o founder o estimated time for fixing expected result
5.1.9 Version control
SVN on our development server is used for version control. All code checked-in should be working and coded according to the agreed coding conventions. Code should be checked in at least daily. Check-outs can be done always before the developer starts coding. In addition SVN is used for version controlling important design documents (ER-charts etc.)
5.1.10 Coding convention
Language Coding Convention Natural language in code and comments English PHP http:// www.yiiframework.com/ Javascript http://dojotoolkit.org/developer/StyleGuide
5.1.11 Process improvement
Process improvement is arranged by two meetings in each sprint: the feedback meeting with Rocky and a reflection workshop within the team. The project manager is responsible for process improvement. Reflection workshops are arranged at the beginning of each sprint. The reflection workshops are organized on the Monday when new sprint starts. Everyone from the team should be present. The process is improved according to the feedback got in the meeting. In addition the customer is asked for feedback of the process at the meetings which are then discussed at the reflection workshop. In addition to the workshops, everyone is actively encouraged to give feedback. The defects from AceProject are reviewed at the end of each sprint and the developing practices are updated so that the same type of bugs could be avoided in the future.
5.1.12 Requirements engineering
Requirements elicitation is done in a meeting with the customer where the whole team is present and customer demonstrates their ideas about the system. The team analyses the results of the meeting and creates the initial requirements document based on the analysis. These requirements are prioritized by the team and validated with the customer who also reprioritizes them where necessary. These results are documented in the requirements document and based on that, requirements are split into tasks linked to the appropriate requirement. The requirement status is monitored as the tasks for the requirement proceed. Requirements are reprioritized and new requirements introduced after each sprint in meeting with the customer.
5.1.13 Design
The project architect is responsible for the architectural design. He uses developers as assistants where possible and relevant. The high-level architecture is documented and communicated with the architecture document. The code level design is done by the developers during implementation.
The architectural design is based on the requirements document and the technologies agreed with the customer. All the concerns of the stakeholders must be considered. Based on the most important concerns, the architectural requirements are chosen. 5.1.14 TDD
We use Test Driven Development in the business layer to ensure high quality. This means that first we write the tests and then we code the feature. The feature is complete when all the tests pass. Later we can run the tests to ensure that nothing has broken.
5.2 Quality assurance plan
You may extract this chapter as a separate document, if it grows too large. Read the QA guidelines!
What are the most important quality goals? o goals may be found e.g. among non-functional requirements, implicit customer expectations, project goals and project risks o all quality goals are not relevant to all parts of the system o a good goal includes a clear verification criteria What QA practices are performed in order to achieve the quality goals
?
o testing levels, e.g., unit / module, integration, system, acceptance testing o test types, e.g.,
functional, performance, load, stress, security, reliability, usability, compatibility
o other QA practices, e.g., document/code reviews, coding standard, collecting continuous feedback from the customer (see ch 7) o a quality palette is a good way to summarize the plan (see QA report Table 1) When QA practices are performed? o e.g. code reviews may be executed regularly, usability testing once or twice during the project etc. o functional testing may be done immediately when a fucntion is ready or/and in the end of an iteration o regression testing is usually needed after changes What hardware, software and test environments are needed? What QA materials are produced
?
o guidelines for using the selected QA practices, e.g. coding standard template, code review checklist o test cases, test data, test logs o tools for running tests or checking coding style etc. How the information gained from using the QA practices is utilized? o evaluating the quality status during the project, e.g., in the iteration demos, using some defined QA metrics o steering the project based on some defined QA metrics o convincing the customer on achieving the required level of quality
Tasks, personnel resources and schedule should be documented as part of the iteration plan in sections 6.1-6.4. 5.3 Tools
The following tools are used in the project.
o Google Docs o AceProject o Wiki (tkk) o MediaWiki o SVN o Microsoft office (excel, word, power point) 2003 o Windows Vista o Eclipse o Aptana Studio o MySQL o PHP 5 o Virtual server with Debian 5.0 o Apache http server 2.2.3 o PHPMyAdmin o PHPUnit
We have a development environment on Windows running Eclipse and Aptana Studio. The application will run on a Virtual server rented from Futoron running Debian 5.0 and Apache http server with PHP.
5.4 Standards
Coding convetions, communication standards as described and project management standards from AceProject are followed. 6. Phasing
6.1 Schedule
The schedule will be followed according to the following scheduling plan. All meetings for iteration 1 and 2 have been set. The important deadlines and work processes related to requirements and testing can be followed according to this plan.
Reflection workshops are held at the beginning of each sprint to improve in our working.
6.2 Dates on schedule Project plan iteration i. 2.10.09 Iteration plan DL ii. 7.10.09 Customer meeting for requirements iii. 19.10.09 Project plan, requirements DL iv. 21-22.10.09 Iteration demo and I1 meeting with customer Iteration 1 i. 22.10.09 Iteration begins ii. 11.11.09 First sprint customer meeting iii. 25.11.09 Second sprint customer meeting iv. 8-9.12.09 Iteration demo and third sprint customer meeting Iteration 2 i. 18.1.10 Iteration begins + customer meeting ii. 3.2.10 First sprint customer meeting iii. 17.2.10 Second sprint customer meeting iv. 23.-24.2.10 Iteration demo + system delivery to customer
6.2 Project Planning Goals:
Creating the project plan Understanding the system to be built Requirements specification including most important functional requirements Deciding and studying implementation technologies Deciding the process model to be followed Agreeing on important dates with customer and the team Agreeing on communication and reporting practices with the customer and team Building a successful team (Setting up development infrastructure)
Deliverables:
Project plan (except ch. 5.2 QA Plan) (Responsible: Ohto) Requirements document without detailed functional and non-functional descriptions (Responsible: Mikko) progress report (Responsible: Ohto)
Tasks:
See the table below.
Resp Time Predec onsib Start Finish estima essor Task le date date te tasks 1. Understanding the system to be built Ohto 22.9.2009 7.10.2009 30 - a. Discussion about the problem in general 5 b. Trying out the prototype system built by customer 5 c. Kick off meeting with the customer 10 d. Discussing the meeting with the team 10
2. Defining the requirements to an adequate level as a basis for the requirements document and the project planning Mikko 23.9.2009 9.10.2009 50 1 a. Kick-off meeting with the customer 30 b. Refining the and listing the requirements with the team 10 c. Prioritizing and completing the requirements list with the customer 5 d. Freezing the first requirements so the team can define the infrastructure needed to start the development 5
3. Creating the project plan Ohto 30.9.2009 19.10.2009 50 1,2 a. Finding out everything the customer needs to give input on for the creation of the project plan 20 b. Getting the input from the customer for the project plan 5 c. Writing the document 25
4. Creating the requirements document except the detailed descriptions Mikko 9.10.2009 19.10.2009 25 2 a. Freezing the starting point requirements for the project 5 b. Creating the prototype descriptions 20
5. Preparing the iteration demo Ohto 18.10.2009 20.10.2009 10 All Creating the iteration demo based on the results of the iteration
6. Deciding and studying implementation technologies Ville 23.9.2009 7.10.2009 100 1 a. Based on customer requirements discuss the possible technologies with the customer and the team 5 b. Make decisions of the used technologies 10 c. Study the technologies where there are unknowns before hand 85
7. Deciding the process model to be followed Mikko 7.10.2009 7.10.2009 10 1 a. Based on the system to be built, customer interests and team members working possibilities decide a process model to be used. 10
8. Agreeing on important dates with customer and the team Ohto 7.10.2009 7.10.2009 5 7 a. Deciding the deliveries and deadlines and agreeing the dates for meetings with the customer 5
9. Building a successful team Ohto 22.9.2009 - 20 - a. Agreeing on days for working together 1 b. Kick off meeting 18 c. Assigning responsibilities based on interest 1
10. Setting up development infrastructure Ville 23.9.2009 7.10.2009 51 1,2 a. Setting up virtual server 10 b. Setting up CVS, Wiki, PHP 10 c. Configuring development environment for every1 (Eclipse, Aptana studio, FTP-plugin) 31
Total hours: 356
6.3 Implementation 1
Goals:
design core architecture (refine what this means in your project) add any other major goals here ...
Deliverables:
Software Documents List items here ... (use cases/core architectural -updated project plan parts) -updated requirements document -technical specification (at least the general architecture) -test cases -QA report and test log -progress report -add any other deliverables here ...
Tasks:
planned tasks on a reasonable level of detail
6.4 Implementation 2
See above. 7. Risk log
Describe here the major risks.
Table 4: Risk log (Propability 1=lowest, 3=highest, Severity 1= lowers, 3=highest).
Prop. Current ID Risk at prop. Sev. Effects Controlling actions Responsible beg. Development Developers use their work is delayed. own laptops (4/6 TKK’s Vista developers). 1 workstations fail 3 3 2 Developers’ to cooperate motivation Vista network Project decreases. stations are used as manager little as possible. Developers can’t Development Try to choose work Project 2 work on the same 3 3 2 work becomes days that fit everyone manager days and in the inefficient when and courage same space. developers’ everyone to attend on questions get those days. answered with a delay. Build a good team spirit that everyone is Quality of the final eager to work system is poor together rather than when developers alone. haven’t made decisions together. Taking care of good team spirit. (avoiding) Crucial knowledge
A developer quits is lost. 2 The development Project 3 in the middle of 2 3 work of critical parts manager the project. Project scope must is done using pair be decreased. programming and reviews. (minimizing effect) Taking backups of All our code and the code and wiki- documentation documentation on may be lost if the virtual server. QA manager Virtual server is stored only on the 4 2 2 3 and Ville lost server. Maintaining local Saalo
versions of the code Development on developers’ work is delayed. workstations. Trying to learn the framework as early Yii framework as possible. and
dhtmlXScheduler Development 5 2 2 2 Arranging trainings Architect learning takes work is delayed. and experience more time than exchange sessions calculated. with the whole development team. Development can’t Communicate continue. questions and Customer can’t be Project 6 1 1 3 problems to reached manager End result isn’t customer as soon as optimal they raise. We may have to Demonstrate the Usability choose another library to the requirement can’t 1 technology. customer with a 7 be met with 1 3 QA manager demo. dhtmlXScheduler End result is of library poor quality Developers use much time in the beginning for learning the features of the library.
Refrences
A list of references.