PP-v17.doc - globaldancefloor

needmoreneedmoreData Management

Nov 28, 2012 (4 years and 25 days ago)

252 views

1


10/18
/2009


Global Dance Floor

T
-
76.4115

S
OFTWARE
D
EVELOPMENT
P
ROJECT

T
EAM
14

-

P
ROJECT
P
LAN


T
-
76.4115 Project Plan


Team 14

Version Control

Rev


Date


Author


Reviewer

Notes


1.0

27.09.2009

Mika Järvi

N/A

Initial draft

1.1

07.10.2009

Mika Järvi

N/A

Exported from Google docs

1.2

07.10.2009

Joni Rannila

N/A

Added QA parts

1.3

11.10.2009

Mika Järvi

N/A

New version

1.4

15.10.2009

Mika Järvi

N/A

Revisions based on mentor & customer
meeting

1.5

16.10.2009

Renne Nissinen

N/A

Added Design parts

1.6

18.10.2009

Mika Järvi

N/A

Revisions based on customer feedback

1.7

18.10.2009

Mika Järvi


Co
mpleted risk log & made other changes.


T
-
76.4115 Project Plan


Team 14

Contents

1. Introduction

................................
................................
................................
................................

1

2. Stakeholders and staffing

................................
................................
................................
...........

2

3. Goals

................................
................................
................................
................................
............

3

3.1 Project goals

................................
................................
................................
..........................

3

3.2 Personal learning goals

................................
................................
................................
.........

4

4. Resources and budget

................................
................................
................................
.................

5

4.1 Personnel

................................
................................
................................
..............................

5

4.2 Materials

................................
................................
................................
...............................

5

4.3 Budget

................................
................................
................................
................................
...

6

5. Work practices and tools

................................
................................
................................
............

7

5.1 Practices

................................
................................
................................
................................

7

5.1.1 Iterative development

................................
................................
................................
...

7

5.1.2 Iteration planning

................................
................................
................................
..........

8

5.1.3 Documenting

................................
................................
................................
..................

8

5.1.4 Risk management
................................
................................
................................
...........

9

5.1.5 Time tracking

................................
................................
................................
.................

9

5.1.6 Communication

................................
................................
................................
..............

9

5.1.7 Iteration demo

................................
................................
................................
.............

10

5.1.8 Defect and issue tracking

................................
................................
.............................

10

5.1.9 Version control

................................
................................
................................
.............

12

5.1.10 Coding convention

................................
................................
................................
.....

12

5.1.11 Process improvement

................................
................................
................................

13

5.1.12 Requiremen
ts engineering

................................
................................
........................

13

5.1.13 Design

................................
................................
................................
.........................

13

5.2
Quality

assurance plan

................................
................................
................................
........

14

5.3 Tools

................................
................................
................................
................................
....

14

5.4 Standards

................................
................................
................................
............................

15

T
-
76.4115 Project Plan


Team 14

6. Phasing

................................
................................
................................
................................
......

15

6.1 Schedule

................................
................................
................................
..............................

15

6.2 Project Planning

................................
................................
................................
..................

16

6.3 Implementation 1

................................
................................
................................
...............

17

6.4 Implementation
2

................................
................................
................................
...............

17

7. Risk log

................................
................................
................................
................................
......

17

References

................................
................................
................................
................................
....

20


T
-
76.4115 Project Plan


Team 14

List of tables

Table 1: Group roles and contact details

................................
................................
........................

2

Table 2: Areas of responsibility

................................
................................
................................
.......

3

Table 3: Goals of the customer in prio
ritized order

................................
................................
.......

3

Table 4: Personal learning goals

................................
................................
................................
.....

4

Table 5: Allocated effort (hours)

................................
................................
................................
.....

5

Table 6: Project budget

................................
................................
................................
...................

7

Table 7: Documenting responsibilities
................................
................................
............................

8

Table 8: Possible status values for ope
n issues

................................
................................
............

10

Table 9: Possible status values for closed issues

................................
................................
..........

10

Table 10: List of task types for issue tracking

................................
................................
...............

11

Table 11: List of milestones for issue tracking

................................
................................
..............

11

Table 12: List of different priorities for issue tracking

................................
................................
..

11

Table 13: Coding standards used

................................
................................
................................
..

13

Table 14: Project schedule

................................
................................
................................
............

15

Table 15: Project risks

................................
................................
................................
...................

17


List of figures

Figure 1: Project stakeholders

................................
................................
................................
........

2

Figure 2
: Development room layout with the sensor ma
t and guiding lights installed

.................

6

Figure 3: Timeline for project iterations and sprints

................................
................................
......

7

Figure 4
:

Preliminary architectural design

................................
................................
....................

14


T
-
76.4115 Project Plan


Team 14

1

/
20

1. Introduction

Global Dance Floor is an interactive music playback and visualization platform. It allows the
users (i.e. the dancers) to vote on how they feel about the song currently
being played by
moving to a specific part of the dance floor indicated by visual aids. The hardware system
installed in the floor registers people's positions, and calculates the votes given. The voting
results are then visualized on screen, after which ei
ther a similar or a different type of song is
selected and played next
,

depending on whether
people liked the previous song.


The system will be developed specifically keeping in mind World EXPO 2010 Shanghai China
[1]
,
a global event held from May 1 to Oc
tober 31, 2010 and lasting 184 days. The event is expected
to gather some 70 million visitors, with over 200 countries including Finland represented. As a
member of the Greater Helsinki Expo wo
rking group preparing concept pro
posals for the Expo,
TKK/Sober
IT is pushing towards getting Global Dance Floor presented as a part of Finland's
contribution to the exhibit. In this context, the music catalogue for the system would consist of
Finnish music.

T
-
76.4115 Project Plan


Team 14

2

/
20

2. Stakeholders and staffing

The project
’s main stakeholder
s are presented below:


Customer
Software Expert Trio
TKK/SoberIT
Project Manager
QA
Architect
Mika Järvi
Joni Rannila
Renne Nissinen
Main contact:
Kimmo Karhu
Developer team
Olavi Goussev
Mikael Matveinen
Technical contact:
Mia Kallio
Kati Saarikangas
Tingan Tang
Iiris Laihanen
Tianshi Xiang
Group mentor
Juhana Antero Yrjölä

Figure
1
: Project
stakeholders


Other stakeholders not illustrated on the picture include hardware component suppliers,
the
system’s end
-
users and course personnel
.

Contact details for our team can be foun
d from table
1.

Table
1
: Group roles and contact details

Role

Name

Email

Telephone

Project Manager

Mika Järvi

mika jarv
i tkk fi

+358
-
50
-
3470190

QA

Joni Rannila

joni rannila gmail com


+358
-
44
-
2698016

Architect

Renne Nissinen

rnissine at cc hut fi

+358
-
50
-
3386322

Developer

Olavi Goussev

ogoussev at cc hut fi

+358
-
50
-
5670579

Developer

Mia Kallio

mia kallio at
tkk fi

+358
-
40
-
5574856

Developer

Iiris Laihanen

ilaihane at cc hut fi

+358
-
50
-
3648103

Developer

Mikael Matveinen

mmatvein at cc hut fi

+358
-
40
-
7487019

Developer

Kati Saarikangas

kati saarikangas at tkk fi

+358
-
40
-
7574527

Developer

Tianshi Xiang

txiang
at cc hut fi

+358
-
46
-
6446879


Besides their title role in the team, each member has also been assigned one or more
preliminary
areas of responsibility listed in table 2.

Coding work is not mentioned in the table,
but it will be distributed evenly amongst
the group, taking into account the preferences and
skills of each individual.

T
-
76.4115 Project Plan


Team 14

3

/
20

Table
2
: Areas of responsibility

Name

Areas of responsibility

Mika Järvi

Project management, documentation
, risk management

Joni Rannila

Quality Assuran
ce, Infrastructure

(servers)

Renne Nissinen

Design & Architecture

Olavi Goussev

Infrastructure

(servers)

Mia Kallio

Testing

Iiris Laihanen

Documentation review

Mikael Matveinen

Design & Architecture

Kati Saarikangas

Assistant project manager

Tianshi

Xiang

Design & Architecture, Web site administration


All deliverables and other updated information can be found from the group’s
project
website
at:
http://code.google.com/p/globaldancefloor/

3.
Goals

3.1 Project goals

The project goals have been
discussed with the customer
and are stated as follows:

Table
3
: Goals of the customer in prioritized order

Goal

Verification criteria

1.
Working prototype of the system for dem
o
purposes

The system must be able to realize the core
use cases
(UC1 & UC2)

for demo purposes
, see
Requirements document for details.

There
should be n
o open blocker level issues, but
there can be a few critical issues open for
which a workaround exists s
o that the system
can be still demonstrated.

2.
Presentation quality implementation of the
system

covering base use cases


A polished implementation of the system that
covers the core uses cases, and can

be
with
confidence
presented to the public

at Shang
hai
Expo 2010.

No blocker

or

critical issues should
be open.

3.
A bells and whistles version of the system

A
n enhanced
version of the system that
contains additional features not specified in
T
-
76.4115 Project Plan


Team 14

4

/
20

the core use cases.

No block
er or
critical

issues
should
be ope
n.


According to the customer, c
ompleting the first goal is critical, the second goal is desirable and
the third goal is extra.

3.2 Personal learning goals

The personal learning goals for each t
eam member are listed in table 4
.

Table
4
: Personal learning goals

Member

Personal learning goal

Mika Järvi

To gain experience in
managing a large
distributed

software project

done inside an ad hoc development team
.

Joni Rannila

To get experience from the quality point of view in softwa
re
development. I'm also trying to learn some new QA
-
methods and
see how th
ey are executed in the project.

Renne Nissinen

To gain experience in defining a software architecture for others
to base their work on, and in overseeing the developers
implementi
ng it.

Olavi Goussev

To gain experience in software development from developers point
of view an
d learn some new technologies.


Mia Kallio

To get some work experience in my field of study and find out how
the software development process works in a rea
l world

environment.

Iiris Laihanen

Learn to work in a group in
a software developement project

Mikael Matveinen

To get experience developing software in a group and possibly learn
some new technologies

Kati Saarikangas

To gain experience in softwar
e dev
elopment project

Tianshi Xiang

To gain experience i
n software project development.




T
-
76.4115 Project Plan


Team 14

5

/
20

4. Resources and budget

4.1 Personnel

The initial effort estimates in hours for each t
eam member are listed in table 5
. The table will be
updated after
iterations

to reflect the
prevailing

situation.

Table
5
: Allocated effort (hours)

Member

Project Planning

Iteration 1

Iteration 2

Total

Mika Järvi

60

30

30

120

Renne Nissinen

40

80

27

147

Joni Rannila

49

49

49

147

Olav
i Goussev

2
9

5
9

5
9

147

Mia Kallio

2
0

5
0

5
0

120

Iiris Laihanen

2
0

5
0

5
0

120

Mikael
Matveinen

2
0

5
0

5
0

120

Kati Saarikangas

2
0

5
0

5
0

120

Tianshi Xiang

2
7

8
7

8
7

201

Total

285

505

452

1242


4.2 Materials

The most essential
material requirement for the project is the hardware sensor mat,

provided
by a company called
MariMils Oy
[1].
Initially designed to aid in the care of elderly people, the
system
can be used to detect the position of people standing on a floor.
The sensor sy
stem can
be controlled via HTTP GET and HTTP POST requests, and the data from the sensors is received
in XML format.

The second key hardware component in the system is the guiding lights that c
an be us
ed to
instruct people to move about
the dance floor.
Th
e light system will also be provided by
MariMils Oy. In contrast to the hardware mat, the lights are controlled with ASCII command
sequences sent through a TCP/IP connection. The protocol is designed to be human readable
and usable even manually with a sim
ple telnet client.

T
-
76.4115 Project Plan


Team 14

6

/
20

Our customer has dedicated a room at SoberIT premises (Innopoli 2) where the sensor mat
and
guiding lights
will be installed.
Layout for the room and the proposed mat location is illustrated
in figure 2.

The guiding lights are wall
-
mount
ed, and similar to what can be found on airports.


Figure
2
: Development room layout with
the
sensor mat

and guiding lights

installed

The

room will also contain
a Linux server to which the sensor mat
and lights will be connected
to
.

The server will run all the necessary
software to control the system, and it can be remotely
accessed and operated via the network.

All software components used in t
he project will be
open source.

In addition to the more atypical hardware components, t
he system will also require some
standard equipment for audio and video output. The music will be played through a speaker
system and the voting results and visualization will be done on a display device, most likely an
LCD
-
type television screen. Only a s
ingle display device will be utilized in this project, but the
architecture will be designed keeping in mind possible multi
-
display functionality.

4.3 Budget

The estimated cost of the project in a real world
environment

is presented in table 6.

T
-
76.4115 Project Plan


Team 14

7

/
20

Table
6
: Project budget

Item

Units

Unit cost

Total

Team
effort

1
242

hours

50

62100

Customer

effort

30 hours

100

3000

Hardware

1

5000

5000

Server costs

6 months

50

300

Premises

6 months

300

1800

Total



72200

euros


5. Work practices and

tools

5.1 Practices

5.1.1 Iterative development

After the initial project planning phase, the project will be divided into two iterations. Both
iterations will contain 3 sprints, with one sprint la
sting two
weeks.
The result of each sprint will
either
be a development release or a milestone release (see table 11 in chapter 5.1.8).
Figure 3

i
llustrates the timeline of the iterations, sprints and releases.
Some work will probably be done
during the Christmas vacation also to allow for more flexibility in
allocating the total course
hours on an individual level.

Milestone release (Bonus)
Milestone release (Prototype)
Milestone release (Shanghai)
2009
2010
Week
44
45
46
47
48
49
50
51
52
53
1
2
3
4
5
6
7
8
Phase
Iteration 1
Christmas vacation
Iteration 2
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Sprint 6
Iteration demo
Iteration demo
Development releases
Development release

Figure
3
: Timeline for project iterations and sprints

In the beginning of the iteration, tasks will be divided for each sprint. After the sprint has been
completed, the re
sults are analyzed and targets readjusted if necessary.

Feedback is requested
from the customer
by releasing
the

development build by Sunday 23:59 on the week the sprint
ends. The customer will then test the system and report any new issues encountered to
the
T
-
76.4115 Project Plan


Team 14

8

/
20

issue tracking system by Tuesday 23:59.
Testing will be done throughout the project as features
complete, with special emphasis placed at the end of iterations.

We will try to arrange common developer days, i.e.
a specific day or days in the week when
all
developers g
ather in a single room to code. Experience from previous years has shown this to
be a very beneficial practice.
The exact day(s) and times will be chosen at the beginning of
teaching periods.

5.1.2 Iteration planning

Iteration planning is d
one in the beginning of the iteration phase. Planning will be done by the
SE expert trio while collaborating with other group members and the customer.

Goals for the
iteration will be dependent on the results of the last iteration, i.e. whether the goals s
et
previously were successfully met.

The tentative goals for the iterations are already known, and correspond to the goals set in
chapter 3.1. The goal for the first iteration is to produce a working prototype of the system,
which incorporates all the feat
ures described in use cases 1 and 2. After this has been done, the
aim of the
first two sprints of the
second iteration phase is to create a presentation quality
version of the system, which co
uld be presented to the public.
Depending on how well the set
g
oals are met, the last sprint is used either to develop additional bonus features or polish
existing functionality.

5.1.3 Documenting

All documents will be distributed via the project website at Google Code, either via direct
download documents or wiki pag
es. Each required document will have a person responsible for
the
final
authoring and delivering

of that document

(unless multiple documents need to be
delivered at the same time, in which case the project manager gathers all the documents and
takes care o
f the delivery)
.

Google Docs can be used as a collaboration tool in creating the
document if deemed necessary.
The most important documents

and the persons responsible
for them are listed in table
7
.

Table
7
: Documenting responsibil
ities

Document

Responsible

De
livery

Project Plan

& Iteration plans

PM

End of PP phase

/ Each iteration

Requirements Document

+ QA
plans

QA

End of PP phase / Each iteration

Weekly progress report

PM

Every week

Architectural Design

SA

Beginning of 1
st

It
eration, Refined
during 2
nd

iteration

T
-
76.4115 Project Plan


Team 14

9

/
20

User’s manual

PM

End of project


5.1.4 Risk management

A four
-
step risk management process is used to assess, control and minimize risks present in
the project.
First, the r
isks have been identified

via internal gro
up
discussions

based on initial
meetings

with the customer
. Second, the significance and implications of each risk have been
analyzed and documented in the risk log at the end of this document. Third, precautionary
actions have been taken to minimize the a
ctualization of each risk. Fourth, the status of each
risk is monitored and
updated on regular basis after each sprint
.

Some general project management related risks have also been identified by looking at project
plans from previous years’ courses.
The p
e
rson responsible for updating the risk log

is the
project manager, and g
roup members are instructed to inform the project manager
immediately if they recognize a new risk or a notable increase in the probability of an existing
risk.

5.1.5 Time tracking

A
dedicated spreadsheet has been set up in Google Docs for time tracking purposes. Team
members report the hours they’ve used on a daily basis, along with a short description and a
category classification of the time spent. The project manager then uses the
information to
produce a weekly time report. Different categories



such as
documentation
,
meetings
and
coding


are created and
maintained

by the project manager
.

A

practice encouraged to everyone is
to write down
the time when work began, and then
calcul
ate the actual elapsed hours after finishing working

for the day.

5.1.6 Communication

All important issues, decisions and meetings will be communicated via email to all group
members
,

and
depending on the situation, to
other stakeholders. For
more informal

communications, e.g. development practicalities requiring more real
-
time communications, the
project’s IRC channel (#team14 @ IRCNet) will be used.

The room where the hardware platform
and development server will be installed is located in the customer’s
premises, which also
makes spontaneous face
-
to
-
face communications with the customer easy.

The project site at Google Code also includes a Wiki section
(
http://code.google.com/p/globaldancefloor
/w/list
), which will be used to distribute
information about development practices, architectural decisions and other issues. The system
T
-
76.4115 Project Plan


Team 14

10

/
20

will be used in close collaboration with the issue tracking tool in Google Code (see chapter
5.1.8).

For situations re
quiring instant feedback on an important issue, telephone will be used.

5.1.7 Iteration demo

The p
roject manager is responsible for
coordinating the iteration demos, so that the required
materials and/or presentations are prepared on time.

5.1.8
Defect an
d issue

tracking

To track bugs, feature requests and other tasks, we will use the issue tracking tool incorporated
into Google code (
http://code.google.com/p/globaldancefloor/issues/list
)
. An open issue can
have one of four status values:

Table
8
: Possible status values for open issues

Status

Description

New

A new task that hasn’t been
appr潶oT

祥y
.

却慲a敤

䄠W慳a WU慴 U慳 be敮 牥癩敷敤 ☠
app牯癥T

anT WU攠
T敶敬epm
敮W on iW U慳ab敧en.

剥慤y

周攠T敶敬ep敲 U慳af楮楳i敤
a c潤ing

W慳aⰠanT 楴 楳 w慩a楮朠Wo
b攠牥癩敷敤.


-
U潬T

周攠W慳a U慳 be敮 sW潰o敤 anT 楳in潴 b敩n朠T敶敬潰敤.


䅮 楳獵e c慮 be 獵b浩mWeT b礠慮祯ye

⡤(v敬ep敲Ⱐ卅SW物漠浥mb敲, cu獴om敲)
ⰠbuW iW n敥Ts

W漠b攠
慰p牯癥T b礠yn攠潦 WU攠S䔠W物漠浥mb敲猠bef潲e w潲k c慮 b攠獴慲aeT 潮 iW⸠佮c攠WU攠T敶敬ep敲
U慳afin楳ieT w潲k楮g 潮⁴U攠W慳aⰠWU攠sW慴u猠楳i獥W W漠
剥RTy
⸠.fW敲 WU攠慲捨iW散e 潲 允QU慳a
reviewed the results of the task, the task is classified as ‘clos
ed’. A
n issue
marked

as ‘closed’

can
have one of the following status values:

Table
9
: Possible status values for closed issues

Status

Description

Done

A non
-
coding task that has been finished.

Verified

A completed coding task tha
t has been verified to work by the
QA.

Invalid

This was not a valid issue report.

Duplicate

The report duplicated an existing issue.

WontFix

We decided not to take action on this issue.

T
-
76.4115 Project Plan


Team 14

11

/
20


Any changes done to an issue’s status mode must always be suffic
iently commented on the
task’s page. Developers are also expected to make regular comments on the progress of the
task during the “Started” period of the task, at least at the end of each day. This enables the SE
trio to better follow the progress of each
task, and identify potential problems that the
developer might run into.

In addition to the status code of each task, they will be classified according to the type of t
he
task:

Table
10
: List of task types for issue tracking

Type

D
escription

Type
-
Defect

A software defect/bug that needs attention.

Type
-
Enhancement

An additional feature.

Type
-
Task

A
work item that doesn’t require code changes.

呹Te
-
佴U敲

卯浥moWU敲 W慳a noW b敬潮杩g朠Wo 慮礠潦 WU攠abo癥v


呯 U敬e p污n WUe 楴敲慴
楯n猬⁥慣a 楳獵e w楬氠be 慳獩杮敤 Wo 潮攠of WU牥攠浩m敳e潮敳o

呡b汥l

: 䱩獴

潦o汥lW潮敳⁦潲 楳獵e W牡捫楮g

Milestone

Description

Milestone
-
Prototype

Issues included in the working

prototype of core use cases (1
st

goal
)

Mileston
e
-
Shanghai

Issues included in the polished impl
ementation of core use
cases (2
nd

goal
)

Milestone
-
Bonus

Issues categorized as b
onus features (3
rd

goal
)


To measure the priority (of a task) or severity (of a bug), each task will be assigned a priority
tag,

which can have one of the following values:

Table
12
: List of different priorities for issue tracking

Priority

Description

Priority
-
Blocker

Worst kind of issue.
Blocks development and/or testing work.
Must be resolved before anyth
ing else.


Priority
-
Critical

Crashes, loss of data, severe memory leaks.
Must
be
resolve
d

in the specified milestone.

Priority
-
High

Major loss of function.
Strongly want to resolve in the
T
-
76.4115 Project Plan


Team 14

12

/
20

specified milestone.

Priority
-
Medium

Minor loss of function or ot
her problem which doesn’t
interfere with the use of the system, and a workaround might
exist.
Normal priority.

Priority
-
Low

Cosmetic and other trivial issues.
Might slip to a later
milestone.


The issue tracking system also allows practically an unlimite
d number of ways to categorize and
classify different tasks
, so that they can then be easily
found or filtered out
. We aim to take
advantage of these po
ssibilities in any ways we can.

5.1.9 Version control

For version tracking we will use Subversion (SVN),

which is

incorporated in Google code.
Developers should make an update from the repository every time they start working with the
project. Only tested code should be checked in to the repository to ensure that the repository
always contains a working copy

of the project.

Each commit should include a brief description
of what the developer has changed or added to the code.

Because of the distributed nature of this software development project, we’re using post
-
commit review as a quality assurance method.
Ev
ery task coded and checked in the version
control will be
checked into a branch, created by the developer at the beginning of the task,
and a review request is sent to reviewers. When the r
eviewed
code is accepted
by the architect
or the QA

manager, the co
de will be merged to trunk
.

Google Code has a built in support for
this kind of code review method.

5.1.10 Coding convention

Every team member is free to use whichever IDE they prefer, but we strongly encourage
everyone to employ Eclipse where applicable.

This way, if a developer runs into problems with
the editor, help is more easily available from other group members. Eclipse is also known as a
proficient editor, which includes built
-
in SVN support and can be used for nearly all parts of the
project.

The
re
is

also lots of helpful plug
-
ins available for Eclipse, such as PMD for finding
potential problems

in the code

and
Metrics for
displaying

statistics like LOC
.


Generally accepted coding standards will be used for producing and formatting the actual code
.
The languages and used coding standards used in the project are listed in table 13.


T
-
76.4115 Project Plan


Team 14

13

/
20

Table
13
: Coding standards used

Language

Coding standard

Java

http://java.sun.com/docs/codeconv
/

PHP

http://framework.zend.com/manual/en/coding
-
standard.htm


The code must be properly documented during coding. For Java this means creating Javadoc
[3]
comments. For PHP we will pr
obably use a similar tool called phpDocumentor
[4].

5.1.11 Process improvement

The general process improvement activities are arranged at the end of each iteration in two
phases: first the SE
-
trio meets with the customer to discuss improvements with projec
t team

customer interaction and after that the project team will
have its

own reflection workshop

regarding internal processes.

We’re

also using root cause analysis to improve the development process. The trigger for root
cause analysis is 10 fixed defects. The defect analysis and improvement suggestions are made in
the same meeting and the accepted improvements are taken into action im
mediately to get the
maximum gain out of the analysis process.

5.1.12 Requirements engineering

Requirements are gathered at customer meetings at the beginning of the PP
-
iteration by using
use case
-
diagrams as a tool. The SE
-
trio analyzes the requirements
and
the
QA
-
manager turns
the diagrams in to a textual form in the requirements document. The requirements are
represented to the customer for prioritization and validation.

All the change requests to the requirements have to go
through

SE
-
trio, who analyze

and
document the request for customer acceptance. The requirements document will be kept
updated and the latest version will be available at project’s web page. All major changes will
also be communicated to all stakeholders via email.

5.1.13 Design

The p
rogramming language chosen for the main parts of the project is Java, being the best
choice among the developers in the group.

For music and video decoding and playback, the
open source multimedia framework
gstreamer
[5]

will be utilized.

T
he

structure
of t
he system
will be divided into several key components, ari
sing naturally from
the various

functionalities required of it. This will allow parallel development of different
components by subgroups of the development team. The design focuses on specifying
T
-
76.4115 Project Plan


Team 14

14

/
20

in
terfaces between components, while the low
-
level class design is
largely up to the developers
in q
uestion.

A preliminary vision of the architecture can be seen below.



5.2
Quality

assurance plan

Due to

the

large size of the s
ection, the quality assurance plan will be made available as a
separate document on the project web site.

5.3 Tools

The following tools
have been or will most probably be used

in the project:

Use

Tool

Notes

Project
management

Google Code

SaaS tool

tha
t features a downloads section, wiki,
issue tracking and version control

Documentation

Google Docs

Document collaboration tool

Documentation

Microsoft Office

2007

For authoring documents

Communications

Email, IRC, MSN
Messenger

Several

Coding

Eclipse

I
DE

Version control

SVN

As a plugin for Eclipse

Database

PostgreSQL

A free database application.

Application Server

JBoss

An open source Java EE application server.

Drawing

MagicDraw UML

For use case diagrams

Testing

PMD

Tool for analyzing Java code to

find possible
floor API

lights API

main application

web interface

gr
aphics overlay

gstreamer

playlist functions

Figure
4
: Preliminary architectural design

T
-
76.4115 Project Plan


Team 14

15

/
20

problems

Testing

EMMA

Code coverage tool for assessing automated tests

5.4 Standards

Currently no standards have been identified that we should

strictly

adhere to.

6. Phasing

6.1 Schedule

The most important events and deadlines for t
he pro
ject are listed in table 14
.

Table
14
: Project schedule

Project planning phase (22.09.2009


21.10.2009)


Wed 23.9.

First customer meeting

Fri 2.10.

First team meeting

Fri 2.10.


DL: Delivery of iteration plan

Sun 11.10.

Interna
l DL: Project plan ready for team review

Mon 12.10. 12:00


Mentor meeting

Mon 12.10. 13:00

Reviewing project plan with customer

Thu 15.10.

Installation of the hardware sensor mat

Tue 6.10. 16:15
-

18:30

EES (Innopoli 2): Project Managers

Tue 13.10. 16
:15
-

18:30

EES (Innopoli 2):

QA Managers

Mon 19.10.
13:00

DL: Delivery of all documents

Wed 21.10.
11:00

Iteration demo at Saarikoski (Innopoli 2)

Implementation 1 (22.10.2009


9.12.2009)


Wed 28.10.
13:00

DL: Delivery of iteration plan + QA plan

Tu

3.11. 16:15
-

18

EES (Innopoli 2): QA managers (QA)

Tu 10.11. 16:15
-

18

EES (Innopoli 2): Architects

Tu 17.11. 16:15
-

18

EES (Innopoli 2): Project managers

Tu 24.11. 16:15
-

18

EES (Innopoli 2): Usability engineers

Mon 7.12.
13:00

DL: Delivery of al
l documents

Tue 8.
-
9.12.

Iteration demos

(Innopoli 2)

Christmas vacation (10.12.2009


17.1.2009)

Implementation 2 (18.1.2009


24.2.2009)


Wed 20.1.
13:00

DL: Delivery of iteration plan + QA plan

Mon 15.2.
13:00

DL: Delivery of final system and test
ing guidelines to peer group

Tu 16.2. 16:15
-

18

EES (Innopoli 2): Project managers

T
-
76.4115 Project Plan


Team 14

16

/
20

We 17.2. 16:15
-

18

EES (Innopoli 2): Architects

Th 18.2. 13:00

DL: Deliver the peer testing results to the peer group

Th 18.2. 16:15
-

18

EES (Innopoli 2): QA managers

Mon 22.2.
13:00

DL: Delivery of all documents

Tue 23.
-
24.2.

Iteration demos

(Innopoli 2)

Post project

Tu 2.3. 16:15
-

20

Lecture (T1): Quality award ceremony

Fr 19.3. 23:59 ?

DL Course feedback form (fin, eng).


6.2 Project Planning

Goals

Descripti
on

Have e
verything planned to ensure an efficient start for the first implementation round


Understanding the domain
:
Getting to know the hardware and its capabilities (i.e. suitability
for the project.

Requirements specification on a general level: Cr
eating the most important or “core” use
case
s.

Initial architectural design and configuring the development environment



Deliverables


Description

Responsible

Project Plan (except chapter 5.2. QA plan)

Mika Järvi

Requirements document


Joni Rannila

P
rogress report


Mika Järvi


Tasks


Description

Responsible

Status

Installing the development server

Joni Rannila

Done

Setting up project management and
development environment

Mika Järvi

Done

Eliciting and validat
ing requirements with the
customer

All

Done

Initial proof
-
of
-
concept testing to ensure
hardware compliance

Renne Nissinen

Not done, hardware
not yet supplied.

Writing project plan

Mika Järvi

Done

T
-
76.4115 Project Plan


Team 14

17

/
20

Writing the requirements document

Joni Rannila

Done

Init
ial architectural design

Renne Nissinen

Almost done

6.3 Implementation 1

To be written in the iteration planning phase.

6.4 Implementation 2

To be written in the iteration planning phase.

7. Risk log

Table 1
5

lists the risks identified in the implement
ation of this project. The probability
(=P)
and
severity
(=S)
of

the risks will be updated during iterations
.

The scale for probability and severity
is from 1 being the lowest to 3 being the highest.

Obsolete risks that did not realize will have a
probabil
ity rating of zero.

Table
15
: Project risks

ID

Risk

P


S


Effects

Controlling actions

Respo
nsible

1

A developer quit
s
in the middle of
the project.

2

2

Knowledge is lost.


Project scope can't be
expanded,

or
possibly
needs to

be decreased.


Taking care of good team
spirit. (avoiding)


The development work of
critical parts is done using pair
progr
amming. (minimizing
effect)

PM


2


Delivery of
hardware
components get
delayed

2


2


Project gets
delayed;

no
early proof
-
of
-
concep
t
testing can be done.


Start developing features that
are independent of the hw
platform (minimizing effect)


PM


3

Hardware
platform turns out
t
o be unsuitable
for the project

1

3

Project goals must be
redefined.

Early proof
-
of
-
concept testing
(
avoidi
ng
)

Redefining the whole project
(minimizing effect)


SA


4

Hardware
platform turns out
0

1

Op
erating system must be
switched.

Test the platform early on
QA


T
-
76.4115 Project Plan


Team 14

18

/
20

to be unsuitable

to be used with
Linux

Linux (avoiding)

Switch to Windows if Linux is
not applicable

(minimizing
effect)


5

Main customer
contact

too busy
to partake in the
project

1

2

Not enough support
received from the
customer side.

Switch communications to
technical contact

(
minimizing
effect).

PM

6

Workload is not
distributed evenly

2

2

Team
members become
frustrated because of
either too much or too
little work.

Focus on scheduling and take
advantage of developer days
to evenly distribute work
(avoiding)

Re
-
assign tasks and
responsibilities (minimizing
effect)

SA

7

Not enough
communication
b
etween the
group and the
customer

1

3

We fail to properly
understand customer

s
needs and requirements.

Hold regular meetings with the
customer, and keep the
communications open
(avoiding)

Increase meetings

and email
correspondence

(minimizing
effect)

PM

8

Not enough
communication
between group
members.

1

2

Team members do not
have a common
understanding of the
project goals, and thus fail
to implement them.

Ensure sufficient
communications with regular
meetings, email
correspondence and IRC
(avoiding)

Inc
rease meetings and email
correspondence (minimizing
effect)

PM

9

The API needed to
control the mat
1

3

The project gets delayed
and goals are not met.

Early studying of the
QA

T
-
76.4115 Project Plan


Team 14

19

/
20

and the lights is
not mastered in
time.

documentation (avoiding)

Re
-
assign API rel
ated tasks to
the person most capable of
performing them (minimizing
effect).

10

The team doesn’t

have sufficient
skills to
develop a
feature

2

2

Features are not
completed
at all
or too
much

time

is taken to
complete them.

Make realistic assessments o
f
the developers’ skills when
assigning tasks within the
group (avoiding)

Assigning a more experienced
developer to a difficult task or
removing the feature
altogether (minimizing effect).

SA

1
1

The hardware
documentation
turns out to be
incomplete.

2

2

C
oding cannot proceed as
fast as planned.

Early proof
-
of
-
concept coding
(avoiding)

Employ trial
-
and
-
error
methods to see how the
platform functions (minimizing
effect)

SA

1
2

Inadequate
testing

1

3

The project does not meet
quality requirements.

Develop goo
d QA practices to
ensure good enough quality
(avoiding)

QA

1
3

Developer unable
to complete
assigned tasks
due to sickness or
other reason.

1

2

Task(s) will not be
completed in the allotted
time slot
, delaying the
project
.

Make sure the deadlines are
to kn
own to everyone. Use
early personal deadlines to
allow for greater flexibility in
problem situations (avoiding)

Re
-
schedule tasks and adjust
targets (minimizing effect)

PM

14

Architecture
chosen turns out
to be unsuitable
for the project.

1

3

Time is lost

re
-
designing
the architecture.

Use general and flexible
architectural decisions, that do
not create too many
constraints (avoiding)

SA

T
-
76.4115 Project Plan


Team 14

20

/
20

15

Important project
data is lost.

1

3

Time is lost redoing tasks
already done.

Make sure backups are taken
of key proj
ect data files
(avoiding)

QA,
PM,
SA

References

[1]: World Expo 2010 China Website,

http://en.expo2010.cn/

[2]: MariMils Oy,
http://www.marimils.fi

[3]: Javadoc tool,
http://java.sun.com/j2se/javadoc/

[4]: phpDocument website,
http://www.phpdoc.org/
.

[5]: gStreamer: Open source multimedia framework,
http://gstreamer.freedesktop.org/