Project Plan

Team Testarossa

Version	Date	Author	Description
1.0	14.10.2008	Jaakko	Document template
1.1	17.10.2008	Alexey	3.2 ,4.1, 4.3 Budjet, 3- Introduction,5.1.1,5.1.2,5.1.13
1.2	18.10.2008	Ville	3.2&4.1.1&4.1.2 (own information), 5.1.5, 5.1.6, 5.3
1.3	18.10.2008	Jaakko	4.2, 5.4, 5.1.9, 5.1.10, 3.2, 4.1
1.4	19.10.2008	Kalle S.	2, 3.2, 4.1, 5.1.7, 5.1.8
1.4	19.10.2008	Alexey	References, Icluding 6.1, 6.2 from other document
1.5	19.10.2008	Alexey	6.1 Schedule update, 6.3 Implementation 1 plan, 5.1.14 Irc sessions,5.1.15 Google - calendar,5.1.16 Testing starts 1 week before release delivery
1.6	31.10.2008	Ville	Added "5.2 QA plan"
1.6	27.11.2008	Alexey	Updated "6.3 Implementation" Sprints 3 BLIs added to tasks and deliverable, added actual work hours for sprint 2 (for all)

1. Introduction

Agilefant is open-source web-based tool for managing software development projects. Agilefant system has been developed particulary for needs of agile software projects by Helsinki University of Technology's SoberIt lab and previous software development project-courses.
Agilefant's main purpose is to manage software development backlog. Backlog is a prioritized work- and featurelist. Elements in bakclog are called backlogitems which have priority, time effort estimate and list of tasks related to item.

2. Stakeholders and staffing

2.1 Team Testarossa

Project web page is at http://www.agilefant.org. All the course related documentation and other material cam be found at the team wiki at http://www.agilefant.org/wiki/display/TSR. Team also has an E-mail address which is testarossa(ä)agilefant.org.

Name	Role	E-mail	Phone
Alexey Murtola	Project Manager	amurtola(ä)gmail.com	050-4994505
Jaakko Ruutiainen	Architect	jruutiai(ä)niksula.hut.fi	050-5904065
Kalle Ranki	QA Manager	kranki(ä)cc.hut.fi	041-5185858
Kalle Säilä	Developer	ksaila(ä)cc.hut.fi	050-3002524
Jouni Ojala	Developer	jaojala(ä)cc.hut.fi	040-8336787
Ville Pulkkinen	Developer	hpulkkin(ä)cc.hut.fi	0400-593490

2.2 Customer and mentor

Name	Role	E-mail	Phone
Ilkka Lehto	Product Owner	ilkka.lehto(ä)iki.fi	041-5016167
Jarno Vähäniitty	Business Owner	jvahanii(ä)gmail.com	050-3862777
Reko Jokelainen	Technical Advisor	reko.jokelainen(ä)soberit.hut.fi	040-5643797
Pasi Pekkanen	Technical Advisor	pasi.pekkanen(ä)hut.fi	?
Seppo Sahi	Mentor	seppo.sahi(ä)gmail.com	050-5370356

2.3 Organizational Chart

Figure 1. Organizational chart.

As shown in the Organizational chart, there are also some other stakeholders in the project like the open source community and other organizations.

3. Goals

3.1 Project goals

Our goals in general level are divided on 2 main parts: course completing and giving our customer best value of new features for "Agilefant"- software. This in union includes delivering of documents, iterations demos, project management, software process improvement, implementing new features for "Agilefant". Of course we have also learning goals in this project (see. 3.2 "Personal learning goals")

Table 1: Goals of the customer in the priority order

Goal	Verification criteria
1. Producing business value to the customer in every sprint	Sprint backlog is empty after the sprint
2. Maximizing time spent in software development and minimizing overhead	Teams logged working hours consist mostly from SW development activities

3.2 Personal learning goals

Table 2: Personal learning goals

Member	Personal learning goal
Murtola Alexey	Get experience in systematic software engineering using "Agile"- methods. Study of requirements engineering, effort estimation and basics of testing. Basics study of JAVA technologies.
Pulkkinen Ville	Be familiar with a software development project which applies Java and an Agile -method. How to produce good quality sw fast.
Jaakko Ruutiainen	Get experience in software engineering using Agile methods
Kalle Ranki	Working in a agile software development team. Learning to work with a large codebase.
Jouni Ojala	To learn new technologies and work with agile software development team.
Kalle Säilä	To learn how to use agile methods and how to run an agile software development team. Also to learn some new technologies.

4. Resources and budget

4.1 Personnel

4.1.1 Planned work hours.

	PP	I1			I2
Member	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5	Sprint 6	Sprint 7	Total
Alexey Murtola	30	20	20	10	20	25	25	150
Ville Pulkkinen	20	20	20	20	20	20	30	150
Jaakko Ruutiainen	20	20	20	20	20	20	30	150
Kalle Ranki	20	30	25	30	0	25	20	150
Jouni Ojala	20	20	20	20	20	20	30	150
Kalle Säilä	20	30	20	20	10	20	30	150

Total								900

4.1.2 Actual work hours.

	PP	I1			I2
Member	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5	Sprint 6	Sprint 7	Total
Alexey Murtola	23	41.5						64.5
Ville Pulkkinen	20	37						57
Jaakko Ruutiainen	20	35,5						55.5
Jouni Ojala	19	37						56
Kalle Säilä	25	47.5						72.5
Kalle Ranki	20	48						68
Total	127	246,5						373

4.2 Materials

Team has one room in Innopoli 2 where work can be done. In that room we have three computers of which two can be used for development. We might install development enviroment to the third machine if needed, otherwise it will be used for testing and documenting. Some team members have personal computers that can be used to develop Agilefant.

Development environment is fully free and open sourced software. Two development machines are equipped with Windows XP operating system which is only commercial software team needs.

Team has access to various tools used by SoberIT. Wiki is used for documentation, Agilefant for development management and SVN for source code repository.

4.3 Budget

Here the costs that may imposed by the project. Team members don't get any charge for work. In our project budget is time. For each team member is about 150 hours for whole project. Mentor meetings about 4 during project. In case of our project software and hardware not reguire a lot of resources. We are using old customers computers and own hardware (1000 is for internet- services and software licenses).

	Amount	Price	Total price
Team members work	150 * 6 =900 h	15	13500
Mentor consulting	8 h	15 / h	120
Office renting	6 months	800 / m	4800
Software and hardware		1000	1000
Customers consulting	150h	15	2250
		Yhteensä:	21670€

5. Work practices and tools

5.1 Practices

5.1.1 Iterative development with course and customers reguirements.

Our schedule depends of 2 schedules with fixed dates (endpoints). First is "course"- schedule with 3 iteration demos and deadlines for delivery of documents. Responsibilities in documentation and demos are divided between groups in weekly group meetings. Second is "customers"-schedule with endpoints of 7 sprints (see schedule). In each sprint (except 4 - holiday) we need to deliver a set of new features or editions for "Agilefant" software.

5.1.2 Iteration planning and implementation.

Customer and group discuss this set of features with customer before sprints starts. (At the end of current sprint). Whole team estimate time effort for each feature using "card" - voting. (Each member show card with number that represent effort estimation and explain his decision.) Group use pair programming. Feature items divided between pairs depends of assigned effort estimation and pair's time budget (see 4.1). Each pair is responsible for planning, implementation, testing and demonstration of own set of features. Each pair demonstrates own work result to customer and mentor and gets feedback. We need at least 2 meeting (planning, demo) with our customer in each sprint. Architect will deliver ".zip" package of new release with implemented functionality from all pairs.

5.1.3 Documenting

Project manager is responsible for document deadlines, but the whole team participates in writing them. Project manager splits documents writing in equal parts and deals them to team members. All documents are written in this wiki and are publicly accessible.

5.1.4 Risk management

Risks are identified and reviewed after every sprint in our spring planning meeting. The team discusses risk priorities and actions for controlling risks.

5.1.5 Time tracking

Our project, Agilefant, is a time tracking tool itself. Thanks for Agilefant; Testarossa can apply real-time time reporting.

Of course, we have a manual time tracking in this page; see chapters "4.1 Personnel", "4.1.1 Planned work hours" and "4.2.2 Actual workhours".
Chapters 4.1.1 and 4.1.2 will be updated after each sprint.

Tasks for Testarossa creates our project manager, Alexey Murtola.

5.1.6 Communication

Testarossa has a mailing list which consists of all stakeholders (team members, customers, mentor). An IRC channel is applied as well.

The following 2 IRC channels are applied:

!fantti-grp14
!agilefant

Face-to-face discussions and meetings between all stakeholders are the most important way to handle communication.

All stakeholders must follow Testarossa e-mails, the IRC channel and a Testarossa section in Agilefant.

5.1.7 Iteration demo

There are there iteration demos which are mandatory parts of the course. However, our project has more than 3 sprints and we are also planning to keep a short demo for the customer after every sprint.

We have a small group so our roles in the project vary. Basic structure is that the Project Manager or Scrum Master presents the documentation and used practices. After that each developer or developer pair presents the made changes and the new features. All the other issues like Quality Assurance plan is presented by the team member who has had the most time to do that.

5.1.8 Defect tracking

5.1.8.1 Process

If the team finds a bug, it should be fixed immediately if possible. If the the bug can't be fixed immediately, a bug report should be made and saved in the sprint backlog. If the bug remains unfixed when the sprint is over, it should be moved to the product backlog and the customer decides wether or not to fix it and when.

5.1.8.2 Bug reports

The bug report should include the following information:

Id
Type of the bug (e.g. null pointer)
Location (e.g. file or url)
How to reproduce the bug
Date
Who found it
An estimation of how long it will take to fix it

What system is used, is an Excel sheet enough, giving access to the customer/peer group, ...

5.1.9 Version control

Team uses customer's existing SVN repository for code version control. Code commits to the repository are made after customer's product owner has reviewed the change and the change has passed unit tests. After commit automatic build tool Bamboo builds the new version and runs all unit tests, if anything fails all project stakeholders are notified by email. Commits that break the build must be fixed immediatelly. Changes are briefly described in the commit comments and possible documentation is saved in the wiki.

5.1.10 Coding convention

As fully functioning product Agilefant already has great amounts of code and team tries to make code which conforms to previous conventions. Code Conventions for the Java Programming Languageby Sun Microsystems is used as it has been in use before. Agilefant uses many external frameworks and libraries (Spring, Hibernate, Webwork, jUnit). When working with those coding convetions used in them are adapted and used.

5.1.11 Process improvement

After each sprint team arranges retrospective meeting. Customer is welcome to these meetings as well. Team figures out what methods did work and what didn't and what can be done to improve the process.

5.1.12 Requirements engineering

Gathering of requirements is done before each sprint. Customer and team arranges meeting. Team listens customer and tries to understand customer requirements and goals. Results are written down to Agilefant.

Analyzing requirements is done by team (lead by scrum master). Team makes time effort estimates (poker-method) for backlogitems and divide them to tasks. Customer evaluates and validates results.

Sprint planning is done with customer and team. Customer has prioritized backlogitems to Agilefant and team makes decisions about sprint's scope (how many backlogitems are transferred to sprint backlog) and goals. Team contacts straight to customer if there are any problems with requirements.

Agilefant provides realtime statustracking.

5.1.13 Design

Low level design is already implemented. In our projects scope is implementing new features using "Agilefants" base architecture.

5.1.14 Irc sessions

Team has IRC - sessions every MA,KE,PE at 10.00 for reporting about problems, planning and knowledge transfer

5.1.15 Google - calendar

Team use Google- calendar for tracking all project endpoints

5.1.16 Testing starts 1 week before release delivery.

For executing testing activities team decided that backlog items coding need to be done 1 WEEK before release delivery (see "Schedule")

5.2 Quality assurance plan

5.2.1 What are the most important quality goals?

Testarossa collected the most important quality goals with the customer.

Here is a short list about the most important quality goals in a priority order (the most important first):

Quality goal
There are regular releases in every sprint
There are no problems which block usage in releases
The User Interface has common view and behavior
SW Development for future SW groups is easier
Agilefant SW maintains current performance
Agilefant SW does not loose users's data
Agilefant SW maintains current portability

5.2.2 What QA practices are performed in order to achieve the quality goals?

The idea of this chapter is to connect quality goals into QA practices. A chapter "5.2.2.14 Quality palette" summarizes this QA plan.

Chapters 5.2.2.1 - 5.2.2.14 announce QA practises, when those are performed and what material are produced.

5.2.2.1 Scrum

Perhaps the most important QA practice is the applying of Scrum. Scrum is a one of agile SW development methods.
Why Scrum is applied? The aim is that SW development team produces SW which has good quality; produced SW meets customer's requirements and expectations.

Testarossa applies the following activities in Scrum:

Activity in scrum	Description
IRC Sessions	Testarossa keeps regular IRC sessions (at !fantti-grp14) at 10.00 am (Monday, Wednesday and Friday). Of course, it's allowed to discuss in other times at IRC. The customer may join into these sessions. Testarossa can meet the customer at !agilefant.
Weekly meetings	A regular face-to-face team meeting is at 16.00 (Tuesday). The customer may join into these sessions.
Task planning (one task less than 5 hours)	A backlog item consists of tasks. An individual task must be planned so that length is less than 5 hours.
Agilefant and - burndown	Testarossa can follow the progress of the project in Agilefant; what are the current backlogs, which backlogs need work, which are done. Agilefant burndown how much effort left and how much used.
Google -calendar	There is a Google calendar (in http://www.agilefant.org/wiki/display/TSR/Home) in wiki and there is a possible to follow what happens in a given week, - day etc.
5 % percent workshop	5 % of every sprint time must be use for the planning of the next sprint.

Scrum is applied as a QA practice all the time within the project.

Scrum and its activities produce the following material:

Activity in scrum	Produced material	When?
IRC Sessions	An IRC session itself does not produce any material. Material may be produced if needed.	IRC sessions are kept at 10.00 am (Monday, Wednesday and Friday).
Weekly meetings	A regular face-to-face team itself does not produce any material. Material may be produced if needed.	A regular face-to-face team meeting is at 16.00 (Tuesday).
Task planning (one task less than 5 hours)	Notations in Agilefant. There is a "Progress" tab for a backlog item in Agilefant. There are task list (TODO) in a progress tab and notations will be there.	In the beginning of a sprint or within a sprint.
Agilefant and - burndown	Notations in Agilefant. Agilefant burndown shows spent effort versus planned effort in graphical mode.	When Testarossa marks spent efforts or changes the state of a task in Agilefant.
Google -calendar	Notations (meeting, demo etc.) in Google -calendar	When it's needed
5 % percent workshop	Notations in Agilefant; Testarossa and the customer create new backlog items and todo -lists for those.	In the end of the previous sprint.

Scrum helps to achieve a quality goal "There are regular releases in every sprint".

5.2.2.2 Feature freeze week before release

Testarossa has aim to finish needed backlog items one week before releasing. That way Testarossa has time enough for testing, corrections, documenting etc.

"Feature freeze week before release" itself does not produce any material.

Feature freeze week before release helps to achieve a quality goal "There are no problems which block usage in releases".

5.2.2.3 Definition of done

That is a checklist for backlog items when those are in a "Implemented" state in Agilefant.

The following list must be checked

is an unit test designed
is a test charter designed
is a test charter/case tested successfully
has the customer checked a backlog item

If the customer accepts a backlog item and its functionality, tests, documents etc. -> Testarossa changes its state to "Done" in Agilefant.

That is performed when a backlog item has been implemented. A summary sheet in Wiki will be produced material. There are own pages for an each sprint http://www.agilefant.org/wiki/display/TSR/ET+Chart.
The summary sheet announces a "Definition of done" checklist and its results (ok/nok).

Definition of done helps to achieve quality goals "There are regular releases in every sprint" and "There are no problems which block usage in releases".

5.2.2.4 Testing

5.2.2.4.1 Testing levels

The following testing levels are applied: unit/module, integration and system testing.

Testing level	Description	When?	How?
Unit/module tests	Will be driven for individual components.	When Testarossa has finished a backlog item programmers must test that a given backlog item fulfils its specification and it does not produce negative side effects.	Testarossa makes JUnit tests for classes and methods
Integration tests	Will be driven for component groups. The idea is to ensure that components (backlog items) work together as planned and no negative side effects occur. The customer offers Bamboo which is continuous integration server. The customer and Testarossa receives an e-mail if Bamboo can not build SW or tests fail.	Testarossa will run these when unit/module tests has been ran successfull and all backlog items (for a certain sprint) are collected together.	Testarossa makes JUnit tests for bigger set of classes and methods
System tests	Will be driven system as a whole. The scope of unit/module and integration tests was in implemented backlog items.	These will be ran when integration tests has been ran successfully.	Due to small size of Agilefant SW Testarossa makes system tests by unit/module tests.
Acceptance tests	Acceptance tests will be driven system as a whole - customer requirements.	When Testarossa has verified the quality of Agilefant SW by other tests (unit/module -, integration - and system tests) and when Testarossa decides that Agilefant SW is ready for releasing. Testarossa has to find out when the customer is going to drive acceptance tests! That way the customer gets what he/she wants. Read a chapter "5.2.2.4.5 Testarossa does not test everything".	The customer announces testing tools, - types, - methods for an every acceptance test.

5.2.2.4.2 Testing types

Testing type	Description	When?	How?
Functional tests	Functional tests are used to ensure that the behavior of the system adheres to the requirements specification. All functional requirements for the system must be achievable by the system. Functional tests belong into under system tests.	When all backlog items are collected together.	By explorative testing and ad-hoc testing. Read chapters "5.2.2.4.3 Explorative testing" and "5.2.2.4.4 Ad-hoc testing".
Performance tests	The goal of system performance tests is to see if the software meets the performance requirements. The priority of performance tests (in this project) is lower than functional tests. Testarossa has to monitor somehow the performance of the SW within the project. Performance tests belong into under system tests.	When all backlog items are collected together.	The customer ships a database which is used in Agilefant and Testarossa tests performance within the project with that.
Regression testing	Regression testing is needed after changes. E.g. there is a bug and Testarossa fixes that. After that Testarossa drives release tests or other pre-defined tests.	After changes.	E.g. by JUnit tests, by acceptance tests, by tests which revealed a bug etc.

5.2.2.4.3 Explorative testing

Exploratory testing is test design and execution at the same time. Exploratory tests, unlike scripted tests (predefined test procedures, whether manual or automated), are not defined in advance and carried out precisely according to a plan. ET is optimized to find bugs fast. A tester continually adjusts plans to re-focus on the most promising risk areas, follows hunches and minimizes the time spent on documenting. ET may be useful to complement a more formal testing approach.

Explorative testing is applied when Testarossa has finished a backlog item.

Testarossa will use a graphical sw tool "Freemind". Testarossa designs e.g. exploratory test charts by Freemind.
A test chart shows steps in a test case and a tester has to mark result passed or failed.

Testarossa measures the coverage of test cases from test charts; how many paths has been driven versus total sum of paths,
how many test cases has been driven versus total sum of test cases, how many test cases has been driven versus time etc.

Testers should apply traffic lights in tests; green (e.g. quality is good), yellow (e.g. not sure) and red (e.g. quality is bad).

An exploratory test chart is designed by a programmer(s). An ET chart must be finished before a test; what to test and how to test?

5.2.2.4.4 Ad-hoc testing

That will be ran randomly within the project and that is targeted for a certain purpose. An ad-hoc test will not be designed.

5.2.2.4.5 Testarossa does not test everything

There are a lot to do and lot to test in the project. This means that there are no necessary resourcies (e.g. skills,people,time,system) to test everything.

The following test level will not be tested:

The final acceptance tests will be driven by the customer. Anyway Testarossa has to follow the results of acceptance tests and react fast if there are bugs in SW produced by Testarossa (="Testarossa can not close eyes"). The customer is not a testing service

The following test types will not be tested:

Stress testing (a system test). That must be tested with high load. That needs time, people and a system.
Security testing (a system test). E.g. does Agilefant loose data. That needs time, people and a system.
Selenium tests. Automatic testing for user interfaces. In practice Selenium is a plug-in for a web browser which saves
the following transaction e.g. an user goes through web pages and Selenium checks that needed texts appear etc. It's possible that Testarossa may apply that sometimes. Because Testarossa can not promise the usage of Selenium tests exactly, Testarossa doesn't apply that. That test type is proposed by the customer.

5.2.2.4.6 Testing and its material

Produced material	When?
Exploratory testing charts	When a backlog item has been implemented
Test logs	When test case has been driven

Testing helps to achieve quality goals "There are no problems which block usage in releases", "Agilefant SW maintains current performance" and "Agilefant SW does not loose users's data".

5.2.2.5 Creating of automatic unit tests

Automatic unit tests (JUnit) must be created before tests. Produced material is JUnit code itself.

Creating of automatic unit tests helps to achieve quality goals "There are no problems which block usage in releases" and "SW Development for future SW groups is easier".

5.2.2.6 Test-Driven Development

Test-Driven Development (TDD) is an extreme approach to unit testing where tests are written before implementation.

Testarossa applies a "Test - Code - Refactor" rule in TDD:

Test. Write a test case for a given feature.
Code. Code a given feature.
Refactor. Improve the quality of test cases.

In practise test, code, refactor, test, code, refactor etc. as long as a given feature fulfils its specification. Produced material is code&its comments.

Test-Driven development helps to achieve quality goals "There are no problems which block usage in releases" and "SW Development for future SW groups is easier".

5.2.2.7 QA Practise Prioritization

Prioritization is very important. The lack of resourcies (staff, time, etc.) means that there is no necessary time to run all QA activities in the project.

Priorities will be given (e.g. to backlog items) in the beginning of a sprint. Backlog items, tasks etc., which have higher priorities, will be done first.
Testarossa must follow priorities within the project. Testarossa is allowed to change priotities if needed.

Priority notations in Agilefant are produced material.

QA practise priorization helps to achieve a quality goal "There are regular releases in every sprint".

5.2.2.8 Pair programming

The following is loaned from T-76.4115 pages:

"Pair programming is a practice where two developers sit in front of one computer programming together. They may continuously change the role between code writer and observer. The pairs also change frequently, e.g., daily. The proposed advantages of this practice are lower number of bugs, better transfer of knowledge among the team, higher enjoyment of work, and faster development without considerably higher total effort spent on the project."

How does pair programming work in practise? The answer: Programmers (3 persons) meet regularly and on schedule at Motorhome.

That is performed all the time within the project. That does not produce any special material.

Pair Programming helps to achieve a quality goal "There are no problems which block usage in releases".

5.2.2.9 Reporting

Testarossa does QA reporting in the end of each implementation. A QA report tells that how many defects/bugs found, how many defects/bugs corrected etc.

Code review checklist, test cases, -data, -logs and -charters will be reported. Test cases must be finished before test. Test logs will be appeared after tests.

Reporting occurs in wiki.

Reporting helps to achieve a quality goal "SW Development for future SW groups is easier".

5.2.2.10 Code/document/test case reviews

Testarossa runs reviews for

code
documents
test cases, -charters

Reviews will be driven against a checklist.

Code reviews will be driven when it is necessary; e.g when developer has made bigger/remarkable addings, removings, etc. or situations where code behaviour can be disaster.

For that purpose Testarossa can use a program called "FishEye" which code review tool. A developer can add own code to FishEye and propose to the customer and/or other team members that please review my code.

Code reviews can be held e.g. at Motorhome (the workroom at Innopoli) where e.g. team members and/or the customer can review code manually. In manual code reviews is the same policy; those will be driven when it is necessary.

Produced material will be the results of a checklist (ok/nok).

Code/document/test case reviews helps to achieve quality goals "There are regular releases in every sprint" and "There are no problems which block usage in releases".

5.2.2.11 Coding standard

Sun coding conventions will be applied. That is performed all the time within the project. That does not produce any special material.

Coding standard helps to achieve a quality goal "SW Development for future SW groups is easier".

5.2.2.12 Retrospective

Actions for quality improvements after every sprint. That is performed in the beginning of the next sprint. That produces material to a QA plan (if needed) and/or to wiki (if needed). It's allowed to produce other material (if needed).

Retrospective helps to achieve quality goals "There are regular releases in every sprint", "There are no problems which block usage in releases", "The User Interface has common view and behavior", "SW Development for future SW groups is easier", "Agilefant SW maintains current performance", "Agilefant SW does not loose users's data" and "Agilefant SW maintains current portability".

5.2.2.13 Collecting continuous feedback from the customer

The customer follows regularly Testarossa and its working. The customer may give feedback to Testarossa; e.g test this way, avoid that kind of coding etc.

There are face-to-face meetings with the customer in the beginning/ending of each sprint. In the beginning of each sprint requirements (which backlog items will be done within a sprint) will be set with the customer and Testarossa may receive technical support (e.g. how difficult a given backlog item is). The ending of each sprint the customer evaluates each backlog item (does it meet the requirements or not) and the customer gives feedback to Testarossa and vice versa. Testarossa can meet the customer at !agilefant.

Testarossa makes own backlog items for the customer; when the customer has acceptance tested successfully a backlog item -> the customer marks that backlog item "Done".

Produced material can be the customer's comments in Wiki, notations in Agilefant etc.

Collecting continuous feedback from the customer helps to achieve a quality goal "The User Interface has common view and behavior".

5.2.2.14 Other QA practices

The following table announces other QA practices:

Other QA practice	Description	When?
The tagging of the repository	Every released Agilefant SW must be tagged in the repository. That action improves traceability.	When the customer launches a release.
Common practices and terms	Everybody (in Testarossa) understands the meaning of terms; what is a sprint, who is a scrum master, sprint is finished when the demo has been kept, what is my role and my resonsibilities etc.	All the time within the project.
Bug/defect follow up	All bugs and defects must be documented. If Testarossa finds a new bug/defect -> that must be added to the the bug/defect list. If bug/defect is fixed&tested&verified -> that bug/defect must be removed from the bug/defect list. An every bug/defect has priority how serious it is.	All the time within the project.

The following table announces produced material and when it's produced for other QA practices:

Other QA practice	Produced material	When?
The tagging of the repository	A release note.	When the customer launches a release.
Common practices and terms	None	None
Bug/defect follow up	Bug/defect (plus priorities) lists	When changes&updates are needed in bug/defect lists

Other QA practices help to achieve quality goals "There are no problems which block usage in releases", "SW Development for future SW groups is easier" and " Agilefant SW maintains current portability".

5.2.2.15 Quality palette

The following quality palette summarizes this QA plan:

	Quality goals
QA practice	There are regular releases in every sprint	There are no problems which block usage in releases	The User Interface has common view and behavior	SW Development for future SW groups is easier	Agilefant SW maintains current performance	Agilefant SW does not loose users's data	Agilefant SW maintains current portability
Scrum	x
Feature freeze week before release		x
Definition of done	x	x
Testing		x			x	x
Creating of automatic unit tests		x		x
Test-Driven Development		x		x
QA Practice Prioritization	x
Pair programming		x
Reporting				x
Code/document/test case reviews	x	x
Coding standard				x
Retrospective	x	x	x	x	x	x	x
Collecting continuous feedback from the customer			x
Other QA practices		x		x			x

5.2.3 What hardware, software and test environments are needed?

Hardware, software and test environments must be equal in the customer and Testarossa. That way the behavior of the SW can be
ensured; if Testarossa does not detect any defects/bugs with a certain test set -> the customer does not detect any defects/bugs as well.

The following is copied from Project Plan (5.3 Tools) http://www.agilefant.org/wiki/display/TSR/Project+Plan

Summary of all tools used. Mention version numbers and availability information, if relevant to the project. Description of all development and test environments that are needed; both software and hardware environments.

Eclipse (Java development tool), version ?.
Tomcat (web server), version ?.
MySQL (SQL server), version ?.
Hibernate (object/relational persistence and query service), version ?.
ANT (scripting language), version ?.
Mantis (Bug Tracking)
FishEye (Used for subversion repository viewing and code reviews)
SVN (Version management)
Bamboo (Continuous Integration server, runs all unit tests when committing in the subversion repository)

The main operating system is Windows XP but some test cases must be run in Linux environment.

5.2.4 How the information gained from using the QA practices is utilized?

5.2.4.1 Iteration demos

Testarossa has to convince the customer that Agilefant SW meets the customer's requirements. Testarossa has to show test cases
and prove that Testarossa has tested Agilefant SW enough and test cases are adequate.

5.2.4.2 The usage of QA metrics

Testarossa has to use QA metrics; how many defects/bugs found, how many defects/bugs found after regression tests, what is the coverage of testing,
how many test charters have been driven against the total number of test charters, how many testing rounds have been driven, how many defects/bugs after each testing round etc.
Testarossa has to show this way that there is progress in the project.

5.2.4.3 Education

If either the customer or Testarossa feels there is no information enough for quality purposes then education must be kept.

5.3 Tools

Summary of all tools used. Mention version numbers and availability information, if relevant to the project. Description of all development and test environments that are needed; both software and hardware environments.

Eclipse (Java development tool), version ?.
Tomcat (web server), version ?.
MySQL (SQL server), version ?.
Hibernate (object/relational persistence and query service), version ?.
ANT (scripting language), version ?.
Mantis (Bug Tracking)
FishEye (Used for subversion repository viewing and code reviews)
SVN (Version management)
Bamboo (Continuous Integration server, runs all unit tests when committing in the subversion repository)

Testarossa develops Agilefant in a Windows XP machine.

5.4 Standards

No notable standards are used.

6. Phasing

Because our project is agile development project (scrum) we don't simply divide it to planning/implementation phases. Each iteration is divided into multiple development sprints. Each sprint contains planning, development and customer demo. In the following we have described project schedule, goals and deliverables.

6.1 Schedule

In this schedule are approximated dates (date and time of team meeting can be changed) for major events in project. Dates of deadlines and durations of main phases in project (iterations divided into "sprints").

Pre-project (5.9-19.9)

Fr 5.9 Topic proposals published (don't contact customers before 16.9.)
We 10.9 DL 13:00SE experts are published
Fr 12.9DL 13:00Forming of SE expert trio
Tu 16.9 Presentation of the topics (Customers)
Fr 19.9 DL 13:00Recruitments of developers

Project - planning (23.9. - 22.10.2008)

Tu 23.9 Lecture - "Development process framework"
Th 24.9 Meeting with customer. Project started.
Tu 30 Team meeting.
Fr 3.10 DL 11:00Iteration
Tu 7.10 EES 17:00-18:45 Project managers

13.10.2008 - 23.10.2008 Sprint 1: Warm-up

Tu 7.10 Team meeting 19.00
9.10 Mentor meeting 17.30-19.00
Tu 14.10. EES 17:00-18:45 QA managers (requirements engineering) , Team meeting 19.00
Mo 20.10. DL 11:00 Delivery of documents
Tu 21.10 Team meeting 18.00
Tu 21.-22.10 Iteration demos

Implementation 1 (23.10. - 10.12.2008)

24.10.2008 - 29.10.2008 Sprint 1.5 : Dev

Fr 24.10 Team meeting with customer, Sprints 1.5 and 3 planning
Tu 28.10 Team meeting, sprints 3 planning 16.00
We 29.10 1.5 releases delivery to customer DL 12.00

27.10.2008 - 14.11.2008 Sprint 2: Dev

Tu 28.10 Team meeting 16.00
Fr 31.10 DL 11:00 Iteration plan + QA
Fr 7.11 Sprints 2 items are coded testing begins
Tu 11.11 Team meeting 16.00
Th 13.11 Delivery "Release 2" to customer

17.11.2008 - 10.12.2008 Sprint 3: Dev

Tu 18.11Team sprints 3, planning 16.00
Tu 25.11 Team meeting 16.00
Mo 1.12 Sprints 3 items are ready testing begins
Tu 2.12 Team meeting 16.00
Fr 8.12 Delivery of new release to customer, DL 11:00 Delivery of documents, Team meeting 16.00 planning and reviewing demo
Tu 9.-10.12 Iteration demos
Tu 16.12 Team meeting, 4,5 iteration planning 16.00

16.12.2008 - 9.1.2009 Sprint 4: Holidays

Implementation 2 (9.1. - 4.3.2009)

9.1.2009 - 30.1.2009 Sprint 5: Dev

Tu 9.1 Team meeting 16.00
Tu 20.1 DL 11:00 Iteration plan + QA plan
Tu 23.1 Team meeting 16.00
Tu 30.1 Team meeting 16.00

2.2.2009 - 20.2.2009 Sprint 6: Dev

Tu 2.2 Team meeting 16.00
8.2 Demo to the customer and mentor (show visible progress)
Tu 9.2 Team meeting 16.00
Tu 16.2 Team meeting 16.00
Fr 20.2 DL 11:00 Deliver the final system and testing guidelines
23.2.2009 - 4.3.2009 Sprint 7: Finalize

Mo 23.2 EES 16:15-18 Project managers 9.00 Team meeting
Tu 24.2 DL 11:00 Report the peer testing results to the peer group, EES 16:15-18 QA managers
We 25.2 EES 16:15-18 Architects
Tu 30.2 Team meeting 18.00
Mo 2.3 DL 11:00 Delivery of documents
Tu 3.-4.3 Iteration demos

Post project

Tu 10.3 16:15 - 20:00 Quality award ceremony + dinner

6.2 Project Planning

Our goals for this project plan phase are little bit different than most of the groups because our software is already "ready" and our job is to make it better. This means little less planning and little more developing and testing the software in this first phase
Another thing is that we are encouraged to use agile software development methods so we don't have any specific planning phase or developing phase. Both the plannig/documenting and developing goes hand in hand through out the entire project and because of the agile methods our goals will be modified depending on our success in each iteration.
Here the list of main goals that need to achieve.

Goals:

- Understand domain of the project.

- Divide responsibilities/tasks between group members

- Every group member should understand domain of own task

- High visibility of progress for team members and customer.

- Using "Agilefant"- software as tool for project management

- Weekly team meetings

- Setting up the development environment

- Learning the technologies

- Learning the agile methods, especially Scrum

- Getting familiar with the "Agilefant"- software

- Study the old code and structure of the software

- Setting up the communication channels and practices

- Get to know the project stakeholders

- Do the warm up tasks and start developing

Deliverables.

- project plan (except ch. 5.2 QA Plan)
- requirements document
- progress report

Information on related to tasks

1. Setting up working facilities

. Development machines and servers (15h)

. Software (25h)

2. Planning of methods and processes to be used and communicating those to all stakeholders (20h)

. Development process: Scrum

. Tools and methods of communication

. Inside team

. Between customer and team

3. Architecture planning (10h)

4. Documenting and reviewing customer needs and requirements (30h)

5. Teaching sessions on: (20h)

. Technologies and tools to be used

. Scrum

. Testing and quality assurance methods and tools

6. Project plan (15h)

7. Testing processes and tools with warm up tasks (63h)

. Select all backlog items -button

. Multi-attaching themes to BLIs

. Unactivated and not-selected themes not shown in BLI's Themes-tab

. Created date to BLI

. Creator info to BLI

. Save & Close -buttons to BLIs

. Theme Delete button to edit theme tab

. Theme - Backlog Item tab - sorting

. Text fix to iteration metrics completed => done

. Spent effort -tab for Project list (in product page)

. Roadmap default timescale to 1 year

. Total load text drawn with the same color as load meter

. Not-in-project BLI Responsibles in red

. Empty backlog causes weird burndown

. User details in Daily Work

. Last modified date to BLI

. Spent effort logging for iterations

Task priorities

1. Critical

2. High

3. Medium

4. Medium

5. High

6. Medium

7. Medium

6.3 Implementation 1

Goals

-Improve communication and software engineering process with respect of first iteration results
-Items are ready for testing 1 week before release delivery (for executing testing activities).
-Deliver documents required documents (see "Deliverables")
-Deliver 1.5, 2, 3 releases (do backlog items of sprints 1.5, 2, 3)

Deliverables

Software	Documents
Release 1.5 (24.10.2008 - 29.10.2008) 1) Multi-attaching themes to BLIs 2) Unactivated and not-selected themes should not be shown in BLI's Themes-tab	-updated project plan (6.1,6.3,5.2)
Release 2 (29.10.2008 - 14.11.2008) 1) Text fix to iteration metrics completed => done 2) Save & Close -buttons to BLIs 3) Tag themes while creating a backlog item 4) Created date to BLI 5) Creator info to BLI 6) Roadmap default timescale to 1 year 7) Delete button to edit theme tab	-updated requirements document -test cases
Release 3 (17.11.2008 - 10.12.2008) 1) All items that are not were not successful in releases 1.5 and 2 2) Set of new backlog items: -Devision BLI to child BLIs: structure tree HTML prototype -BLIs Priorization HTML prototype	-QA report and test log -progress report

Tasks

Improve process

-         IRC - sessions mo, we, fr at 10.00
-         Weekly meetings Tu at 16.00
-         Wiki, Google calendar for all end points
-         Customers involvement to process (panning, technical support, IRC - sessions)
-       Improve teamspirit

Write and deliver documents

-         Update project plan (6.1,6.3,5.2, actual effort)
-         Update requirements document
-         Write test cases
-         Do QA- and progress- report slides

Do all chosen backlog items and deliver 3 releases with next new features

-      Multi-attaching themes to BLIs
-      Unactivated and not-selected themes should not be shown in BLI's Themes-tab
-     Text fix to iteration metrics completed => done
-     Save & Close -buttons to BLIs
-    Tag themes while creating a backlog item
-     Created date to BLI
-     Creator info to BLI
-     Roadmap default timescale to 1 year
-     Delete button to edit theme tab
-     Devision BLI to child BLIs: structure tree HTML prototype

- BLIs Priorization HTML prototype

- Define libraries and possabilities to implement prototypes

Demonstrate our progress in project
- Progress demo (process report, backlog items demo)
- QA report

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

ID	Risk	Prop.	Sev.	Effects	Controlling actions	Responsible
1	A developer quits in the middle of the project.	3	2	Crucial knowledge is lost.Project scope must be decreased.	Taking care of good team spirit. (avoiding)The development work of critical parts is done using pair programming. (minimizing effect)	Project manager
2	Communication between team fails	1	3	Team spirit go down and knowledge transfer fails	Working together as much as possible	All team members
3	Communication between team and customer fails	1	3	Team might produce code not valuable to the customer	Working at our office near the customer as much as possible	Project manager, all team members
4	Team makes bad architectural choices	2	3	Developing the system will become extremely difficult	Discussing critical architectural choices with the customers technical adviser	Architect

References

Last years projects plan with the same scope : http://www.soberit.hut.fi/T-76.4115/08-09/projects/index.html

Plan template: ttp://www.soberit.hut.fi/T-76.4115/08-09/instructions/template/project_plan.html