project plan - SoberIT-Software Business and Engineering · PDF file ·...

T-76.4115 SOFTWARE PROJECT

CoMedia Supporting Collective and Collocated Use of Contextual Media

(HIIT)

PROJECT PLAN

Group CoMedia

Fang, Liang Project Manager lfang(at)cc.hut.fi

Helles, Teppo Usability Engineer/ User Interface Designer

thelles(at)cc.hut.fi

Jing, Jing Requirements Manager/ Quality Assurance

jingj(at)cc.hut.fi

Kjällman, Jimmy Developer jimmy.kjällman(at)cc.hut.fi

Martelin, Tomas Lead Developer tmarteli(at)cc.hut.fi

Sandberg, Magnus Developer/Tester magnus.sandberg(at)hut.fi

Vikström, Lucas Developer lvikstro(at)cc.hut.fi

Zhu, Di Developer/Tester dzhu2(at)cc.hut.fi


FUTURE MOBILE GROUP MEDIA FORMAT

PROJECT PLAN

1

Document History

Version Date Author Note

0.0.1 13.10.2005 Fang Liang First draft

0.0.2 13.10.2005 Fang Liang Adding Jimmy Kjällman to the plan and

modifying related parts

0.0.3 13.10.2005 Fang Liang Taking Jimmy Kjällman from the plan and

modifying according to instructions from

mentor Lauri Svan

0.0.4 15.10.2005 Teppo Helles Proof reading, adding & defining technical

details

0.0.5 16.10.2005 Jing Jing General formatting, rephrasing project

overview, adding Section 5.1.7 Project

Monitoring & Control

0.0.6 16.10.2005 Teppo Helles &

Jing Jing

Restructuring and rephrasing sections 3.1 and

5.1

0.0.7 17.10.2005 Fang Liang Proof reading, modifying section 6.1

scheduling to more details available and

adding customer goals and criteria

0.1.0 17.10.2005 Fang Liang Plan ready for delivery

0.1.1 24.10.2005 Fang Liang Updating the plan with new member and

some other related changes

Updating section 8 acronyms and

abbreviations

0.1.2 31.10.2005 Jing Jing Adding QA plan reference

0.1.3 13.11.2005 Fang Liang Updating section 6.1, 6.3 and 7



PROJECT PLAN

2

Table of Contents

1. Introduction................................................................... 4 1.1. Overview of the project......................................................................................... 4

1.2. Terminology .......................................................................................................... 5

2. Stakeholders and staffing ............................................. 7 2.1. Project group ......................................................................................................... 7

2.2. Other stakeholders................................................................................................. 8

3. Goals and end criteria .................................................. 9 3.1. Goals of the customer............................................................................................ 9

3.2. Goals of the project group................................................................................... 10

3.3. Personal learning goals........................................................................................ 11

3.4. Project abort and end criteria .............................................................................. 12

4. Resources and budget ..................................................14 4.1. Personnel ............................................................................................................. 14

4.2. Materials.............................................................................................................. 15

4.3. Budget ................................................................................................................. 15

5. Work practices and tools.............................................15 5.1. Practices .............................................................................................................. 15

5.1.1. Iterative development ................................................................................... 16

5.1.2. Iteration planning ......................................................................................... 17

5.1.3. Documenting ................................................................................................ 17

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

5.1.5. Time reporting.............................................................................................. 17

5.1.6. Software size reporting................................................................................. 18

5.1.7. Communication ............................................................................................ 18

5.1.8. Iteration demo .............................................................................................. 18

5.1.9. Version control ............................................................................................. 18

5.1.10. Coding convention ....................................................................................... 18

5.1.11. Defect tracking ............................................................................................. 19

5.1.12. Peer testing ................................................................................................... 19

5.1.13. Requirements management .......................................................................... 19

5.1.14. Progress Monitoring and Control ................................................................. 19

5.2. Quality assurance plan ........................................................................................ 20

5.3. Tools.................................................................................................................... 20

5.4. Standards ............................................................................................................. 20

6. Phasing..........................................................................21 6.1. Schedule .............................................................................................................. 21

6.2. Project Planning .................................................................................................. 22

6.2.1. Goals............................................................................................................. 22

6.2.2. Deliverables.................................................................................................. 23

6.2.3. Tasks............................................................................................................. 23

6.3. Implementation 1................................................................................................. 24

6.3.1. Goals............................................................................................................. 25

6.3.2. Deliverables.................................................................................................. 25

6.3.3. Tasks............................................................................................................. 26



PROJECT PLAN

3

6.4. Implementation 2................................................................................................. 28

7. Risk log .........................................................................29

8. Acronyms and abbreviations ......................................32

9. References.....................................................................33

10. Appendix.......................................................................34



PROJECT PLAN

4

1. Introduction

1.1. Overview of the project

Nowadays mobile phones play an important role in people’s everyday life. The enormous user

volume and amazing functionalities of the mobile phone have opened up new research

opportunities for innovative mobile communication and media applications. This project aims

to explore new means of mobile communication for mobile phone users to produce and share

multimedia content and information. The outcome of this project will be:

• A new generation multimedia format to enrich group communication

• An optimized communication mechanism utilizing both Telecom and Bluetooth network

• A prototype application which allows researchers to experiment and investigate group

communication behavior on mobile terminals

The User Experience Research Group of Helsinki Institute for Information Technology (HIIT)

initiated this project. They’ve been recently researching mobile media in large-scale events1

by organizing trials at the Neste Rally and at the Hultsfred Rock Festival in the year of 2004

and 2005. The research addresses active spectatorship, where people are not seen as passive

consumers of mobile information services, but as active participants co-experiencing the

event. A successful trial was organized in summer 2005 at Neste Rally and Hultsfred where

the mobile application developed by the previous year’s software project student group was

utilized. This year HIIT would like to increase the possibilities of interaction among users

based on the infrastructure developed last year. Therefore, based upon the existing platform

for basic text and image sharing in a group, this project is to build an application named

CoMedia, whose functionality is to support group spectators in large-scale events with

collective and collocated use of contextual media in mobile communication.

The innovative technology concepts incorporated to CoMedia application are:

1. Context awareness: the CoMedia application should provide context awareness

information to the mobile users.

2. Multimedia content: the CoMedia application should include media formats such as

sound and video into the multimedia messages.

3. Bluetooth P2P network: Bluetooth P2P communication must be supported by the

application to exchange messages between members without the need of telecom

networks, and to synchronize updates from other members when connection

congestion occurs.

4. Permanent media content storage: the media content must be stored / cached locally

so that only new messages should be downloaded.

5. Visual code: The CoMedia application should support the visual code attachment to a

story, and should allow the story to be viewed by scanning the visual code and

download the story.

The project team contains currently eight students who come from different academic and

technical background. The majority of the students are computer science majors and most of

1 Homepage of the related research, Wireless Festival, at http://www.hiit.fi/wf/



PROJECT PLAN

5

them have work experience relating to this project’s topic, especially the lead developer and

the requirements managers. The project manager is from the department of industrial

engineering and management who has her minor in software engineering and business. All of

them are motivated to complete this course by delivering a quality software product to the

customer.

With the current scope and requirements of the project a rough estimate on total man-hours to

be spent is 1360 hours.

1.2. Terminology

Below is a list of all the terminologies used in this plan.

Table 1 Terminology

Terminology Description

Bluetooth Bluetooth is a wireless personal area networking technology

“initiated by Ericsson, IBM, Intel, Nokia and Toshiba to set a

standard for cable-free connectivity between mobile phones,

mobile PCs, handheld computers and other

peripherals”2(Definition)

Context awareness It refers to the device, which can offer “information about the

circumstances under which they operate and can react

accordingly.” 3 (Definition)

The context information helps the users identify other members’

current location and status. The users can use the available

context information to conduct detailed communications with

other members within the application.

Crossmedia Crossmedia communication is “communication where the

storyline will invite the receiver to cross-over from one medium

to the next. Making it possible to transform from one-

dimensional communication (sender -> receiver(s)) to multi-

dimensional communication (sender(s) <->

receiver(s)).”4(Definition)

Context phone It is a mobile device providing the context information to its

user.

Festival An occasion for feasting or celebration.

People attend a festival have usually common interest and would

like to share it with others.

Group communication People who participate in the festival enjoy communicating with

each other and sharing their findings and collected information

during and after the event. The members can create media stories

2 Definition of Bluetooth from www.3gnewsroom.com/html/glossary/b.shtml

3 Definition of context awareness from Wikipedia, available at

http://en.wikipedia.org/wiki/Context_awareness 4 Definition of Crossmedia from Wikipedia at http://en.wikipedia.org/wiki/Crossmedia



PROJECT PLAN

6

and invite friends to join and share information.

MMS Short for Multimedia Message Service, “it is a method of

transmitting graphics, video clips, sound files text messages over

wireless networks using the WAP protocol.”5(Definition)

P2P “A peer-to-peer (or P2P) computer network is a network that

relies on the computing power and bandwidth of the participants

in the network rather than concentrating it in a relatively few

servers.” 6 (Definition)

If encountering connection congestion in the festival, members

can communicate via P2P connection for sharing information.

Visual code The visual code is used as a unique identifier to each individual

object. It will be used by the users as an identifier and key to

each media story.

5 Definition of MMS from www.internetworld365.com/Content/Pages/Glossary.aspx

6 Definition of P2P from Wikipedia, available at http://en.wikipedia.org/wiki/P2P



PROJECT PLAN

7

2. Stakeholders and staffing

There are three major parties involved in the whole project, namely the project group of eight

students, the customer from HIIT who proposed the project and who will evaluate the project

outcome, and the project course staff who will evaluate the performance of the student group

as well as the final project result. Below is a sketch of the relationship among all the

stakeholders.

Figure 1 Organizational chart of CoMedia project

2.1. Project group

Inside the project group of eight students everybody has been assigned clear roles for this

project. The table below presents the project group members, their roles and contact

information.

Table 2 Information about group members and other stakeholders

Name Role Email

Fang, Liang Project Manager

Main contact person 0415059921

lfang(at)cc.hut.fi

Helles, Teppo Usability Engineer/

User Interface Designer

thelles(at)cc.hut.fi



PROJECT PLAN

8

Jing, Jing Requirements/

Quality Assurance Manager

jingj(at)cc.hut.fi

Kjällman, Jimmy Developer jimmy.kjällman(at)cc.hut.fi

Martelin, Tomas Lead Developer

System Architect

tmarteli(at)cc.hut.fi

Sandberg, Magnus Developer/Tester magnus.sandberg(at) ADD

hut.fi

Vikström Lucas Developer lvikstro(at)cc.hut.fi

Zhu, Di Developer/Tester dzhu2(at)cc.hut.fi

2.2. Other stakeholders

The roles of other stakeholders in this project and their contact information are presented in

the table below.

Table 3 Information about other stakeholder

Name Role Email

Jacucci, Giulio Customer giulio.jacucci(at)hiit.fi

Kanerva, Pekka Technical Advisor Pekka.kanerva(at)hiit.fi

Svan, Lauri Mentor lauri.svan(at)hut.fi



PROJECT PLAN

9

3. Goals and end criteria

This chapter will state the goals of this project from the perspectives of different stakeholders,

including the customer, the project group and the individual members in the group. The goals

of the customer will include business, functionality and quality goals for the system.

3.1. Goals of the customer

The CoMedia project will be developed based on a last year’s project - Festival7. The

CoMedia project will be incorporated with innovative and advanced business and technology

concepts and achieve the following goals: The verification criteria are specified by the

customer.

Table 4 Goals of the customer in the priority order

Business Goals Verification criteria

1. Create a system that enhances mobile

media sharing with context awareness and

features for collocated interaction

1. the system supports new practices of

mobile media sharing through context

awareness and features for collocated

interaction

2. Create a system that is unique with no

commercial or academic substitutes

2. There are no academic or commercial

systems that can be considered substitutes

3. Create a robust system that can be

trialled in the field with at least 8 users

3. The system can be used for a whole

weekend in mobile conditions with 8

simultaneous users without breakdowns

Functionality Goals Verification criteria

1. To integrate context awareness

capability into the application, so that

people communicating in a group can see

each other’s current information, such as

current activity status and location.

1. The system integrates in mobile group

media, context awareness cues of three

types (activity in system, in the phone, the

environment) successfully in a way to

support new practices of mobile media

sharing

2. To integrate sound and video media into

the CoMedia application in order to enrich

the media types besides text and pictures.

These media will be used in constructing

media stories shared within a group of

people.

2. The system supports the creation and

viewing of sound and video

3. To implement an advanced and

optimized communication mechanism in

sharing information utilizing both

Bluetooth and telecom networks. This will

not only increase the communication

immediacy and efficiency, but also will be

3. The collocated clients can exchange

messages using Bluetooth maintaining

consistency of stories

7 Festival project delivery page: http://www.soberit.hut.fi/T-76.115/04-

05/palautukset/groups/Festival/pp/delivery.html



PROJECT PLAN

10

cost saving for users. A communication

agent will be designed to detect the

optimal mean for communication within a

group.

4. To associate visual codes with media

stories. Visual codes are like bar codes

indentifying an individual media story.

Visual codes provide a simple and

convenient approach for other users to find

out about and join other media stories

inside the system. This enables users to

advertise their media stories to the open

public.

4. Users can assign a visual code to a story,

other users can access the story with the

visual code

Quality Goals Verification criteria

1. To Implement immediacy in sharing

information as it happens, with the least

amount of delay.

1. The system implements immediacy and

instant messaging

2. Usability and interaction design that

requires minimal input and responsiveness

from the users. Yet achieving all of the

defined functionalities.

2. The user is required to carry out a

minimal number of interactions in each

feature and the system response time are

minimal

3. To implement crossmedia so that

information can be: accessed from both

mobile terminals and personal computers

through the internet.

3. Stories are accessible through a web

browser through a nicely designed webpage

that integrates all the implemented features

(sound, video, context cues)

4. To gather thorough and detailed logs of

every action by the clients and server for

research purposes.

4. Every interaction of the user with the

system is logged in a text file in the client

3.2. Goals of the project group

Table 5 Goals of the project group in the priority order

Goal Verification criteria

1.Deliver the final product successfully The most important criteria is that the

system will be accepted by the customer.

The course grade can also be a good

criterion.

2.Get grade 4 or 5 for the course Following points that have been earned in

each iteration and monitor the progress and

adding them up to see if this goal can be

achieved at the end of the project.

3.To learn new software engineering

techniques and practices as well as some

advanced technologies and concepts in

mobile communication

During the internal meetings, especially at

each iteration review session, group

members can sum up what they have

learned, technically and managerially.

Since SEPAs are required for every

member, SEPAs diary can also be a good



PROJECT PLAN

11

way to see if people have already learnt

some thing new in the practices they are

interested in.

4.For the group members get to know each

other better and maybe build up some future

co-operation network.

This goal is rather personal, so no strict

criteria are needed.

5.To get some business opportunity after

developing the system, since the technology

is new.

The criteria for this goal are rather trivial, if

the opportunity comes, then this is achieved.

3.3. Personal learning goals

Table 6 Personal learning goals

Member Personal learning goals

Fang, Liang � To learn how to manage a real project as a project manager

� To learn how to manage a technical project without a

technical background

� To understand better the communications among people

from different background and culture

� To improve capability in technical documentation writing

Helles, Teppo � To learn more about human communication and interaction

behavior

� To develop usability design in Human-Computer

Interaction

� To get familiar with mobile application development

process

� To get a more detailed understanding of the requirement

engineering process

� To improve communication and negotiation skills while

working with the customer

� To improve project scheduling and estimation skills

� To apply learned project management theory in practice

and gain valuable risk management experience as a member

of the management team

� To improve team work skills and coordination skills

� To improve team work skills

Jing, Jing � To apply project management theory into practice

� To improve team work skills and coordination skills

� To improve communication and negotiation skills while

working with the customer and the team

� To get better understanding of requirement engineering

process

� To apply the quality assurance process into the project and

learn hand on experience

� To improve project scheduling and estimation skills

� Get deeper experience on risk management as a member in



PROJECT PLAN

12

the management team

Kjällman, Jimmy � To learn more about programming group communication

applications for mobile devices

� To get experience of software development as a team for a

customer

� To learn how to use development tools and practices to

achieve higher efficiency

Martelin, Tomas � To experience managing parallel projects and get some

experience in designing mobile application software.

� To learn to use different mobile development tools better

and teach this to others.

Sandberg, Magnus � To experience how a project works in a larger group with

different roles and a real customer with a different

background.

� To learn how to make the best use of limited time and strict

deadlines, changing the requirements if necessary.

� To learning more about the capabilities of modern mobile

phones and their possible use.

Vikström Lucas � To learn how to cooperate and work together with a big

software programming group.

� To learn new interesting things that can be done with Java

and mobile phones, especially the Bluetooth

communication.

Zhu, Di � To get more experiences and knowledge with software

development process.

� To study the mobile application development and learn to

use different tools like Wiki & Bugzilla.

� To improve programming and quality assurance practice.

� To get better grade and credits unit.

3.4. Project abort and end criteria

Project abortion will be considered if following things happen:

� More than two persons quit from the management team during the first phase or more

than two developers quit from the development team in the two iterations, before the

final product is delivered to the customer.

� The customer terminates the project for some unexpected reasons, such as no funding

for the project any more.

� At the end of each iteration, no valid or acceptable deliveries are accomplished

because the group cannot realize the implementations based on customer’s

requirements.



PROJECT PLAN

13

Naturally we expect the project to run smoothly enough so that the above mentioned project

abort situations will not materialize. However, if in the worse case the project seems to be

forced to be aborted, the project manager has to contact the customer and the course staff and

try to find out alternatives or take some corrective actions. The act of formally aborting the

project would still require the majority of the group in an internal vote.

The project will be concluded when the following criteria are met:

� The final system is accepted by the customer with the agreed functionalities and

quality goals realized with customer satisfaction.

� All the source codes and system documentation are delivered to the customer.

� All the required tasks are completed and passed for the course T-76.4115 together

with SEPA diaries approved.

� The course is over and teams are dismissed.



PROJECT PLAN

14

4. Resources and budget

This chapter will present the resource and budget estimation for this project. All the figures

are rough estimates and thus subject to future updates, once more detailed information is

available, as the project proceeds.

4.1. Personnel

The project group consists of eight students. The course T-76.4115 requires that every student

spend at least 150 hours to fulfill the course criteria. Therefore totally 150*8=1200 hours

should be spent on this CoMedia project. Surely the actual hours spent can vary a little from

1200 hours depending on the demand of the project and the members skills in completing the

system requirements as well as some risk factors.

Since the roles and responsibilities of each member are different, ranging from pure

management work to pure development work, it will be understandable that members spend

their time differently in every phase during the project process. Generally speaking, the

management group members will spend more time during the first phase when more planning

work needs to be done to get the project started, except that the lead developer will also spend

much time working with the development team during the implementation phases for

architectural design and task division. The project management team will also spend more

time when the project is reaching an end of an iteration, when documentation work will need

to be finalized. Development team members will spend some time during the planning phase

to study the knowledge and tools needed for this project, because the concepts and ideas

behind this project are new. The majority of time for the developers will be spent in the two

implementation iterations. Internal meetings and meetings with mentor and customer will take

place regularly and the time spent on the meetings will spread evenly throughout the project.

Table 7 Planned effort - hours to be spent on project

Fang

Liang

Helles

Teppo

Jing

Jing

Kjällman,

Jimmy

Martelin

Tomas

Sandberg

Magnus

Vikström

Lucas

Zhu

Di

Total

PP 56 52 52 10 51 38 32 32 313

I1 34 40 40 70 50 56 59 59 338

I2 60 58 58 70 49 56 59 59 399

Total 150 150 150 150 150 150 150 150 1050

Since all of the group members are doing this course for a replacement of the previous course

T-76.115, every member is required to spend an extra 20 hours for this project in addition to

the 150 hours calculated in the above table. The group members can choose to spread the 20

hours extra effort evenly throughout the project phases or to spend the hours in a short time

frame when there is an urgent call for before the delivery deadlines. Therefore in the above

table the planning of these additional 20 hours is not included but rather will be left to

individual members to decide when and how they are going to use it.



PROJECT PLAN

15

4.2. Materials

The hardware for this project compose of

� HUT’s and students’ personal computers

� A server, running Debian GNU/Linux Sarge operating system provided by the

customer with some tools installed.

� Four Nokia 6630 (Series 60) 3G phones with SIM cards, provided by the

customer for test purposes.

The software for this project will be:

� Subversion. Subversion is an open-source version control tool that is used to

check files in and out of the system.

(svn version 1.1.4 (r13838) compiled May 13 2005, 06:29:47).

� MySQL: the server application uses a MySQL database.

(mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu(i386))

� J2ME SDK, J2SE SDK & J2EE

� Wireless tools from SUN

� Nokia series 60 emulator

� Bugzilla by Mozilla is going to be tested as a bug tracking tool.

� MS Office application for reporting and documentation

� Eclipse IDE

� Wiki

� Poseidon UML (Community Edition)

4.3. Budget

For the budget part, all the estimates will just be theoretical since no real budget will be

provided for this student project and there will be no need for strict financial monitor and

controlling procedures over the budget spending. Therefore only some simple figures based

on average salary level in Finland for software developers will be presented to get an idea as

how much a project of such size will cost at the normal industrial level. The only expense in

this project will be the project fee of 2000 € the customer will have to pay for the course. The

budget could also include the hours the customer, the technical advisor and the mentor will

spend for this project.

Some more detailed calculation and tables of theoretical budget estimation will be attached in

the Appendix.

5. Work practices and tools

5.1. Practices

The work process in this project will be based on the following practices, out of which some

are mandatory by the course and others selected by ourselves.

In addition, project group members will select an additional practice as couple to fill our

requirement of the Software Engineering Practice Assignment (SEPA). Up till now the SEPA



PROJECT PLAN

16

topics are not yet specified by the group members. Selected SEPA practices and related

information will be updated in this practice section once the topics are confirmed.

5.1.1. Iterative development

Our project is divided into three parts. The first iteration focuses on project planning, and

requirement specification. The second and the third iterations will be mainly the development

work of the CoMedia system.

Our project is a research project in developing a prototype system. Therefore, the iterative

development process would fit well this research project. Currently we have collected all the

customer requirements and some solutions have been proposed internally. This gives us an

overview of the amount of work for the whole system. We will plan the work amount for each

iteration according to the duration of the period and the availability of each developer.

Our main principle in each iteration is to develop functionality from basic to advance, from

simple to complex. Each iteration will be divided into milestones depending on the amount of

functionality and development complexity. We decide to make an internal release every two

weeks, which is followed by a presentation of the development result to the customer. At the

beginning of each two weeks, new development tasks based on designed functionalities will

be given to the developers. Developers will work on the tasks during the two weeks. There

will be around 2 hours internal testing at the end of this period. All the documents produced

must be reviewed. A simple code review should be held to control the production quality. At

the end of each period (2 weeks) implemented functionalities are collected and compared with

the initial planning of the period and against the over all functionality development schedule.

In addition, there will be weekly reporting practices.

We have designed a very strict project monitoring and control process, detailed information

see Section 5.1.3 Progress Monitoring and Control.

Our aim for the second iteration period is to develop functionalities related to Context

Awareness, Permanent Content Storage, and Multimedia Content. If time allows, some

optional features will be implemented. The third period is planned to develop Bluetooth P2P

communication and Visual Code.

The customer and the technical advisor from HIIT will keep in close contact with the whole

group, where the technical advisor will surely provide more help when the developers have

some problems during implementation. Close contact will make sure that feedback can flow

via both ways and produce a good atmosphere for the project team, especially when some

concrete functionality is delivered to the customer, the management group will seek rapid

feedback from the customer.

At the end of each iteration the team will have a review meeting so that it has time to discuss

all the feedbacks from the previous iteration and get ready for improvements if there is

something missing or shorted or even mistaken. Practices, which have been proved not

working well in one iteration, should be discarded or adjusted in the next iteration to avoid

further disturbances to the project progress. Causes for practices failures shall be analyzed and

discussed in group’s internal meetings so that members can learn from each other. Unsolved

problems or problems that are unable to be solved by the group members will be discusses

with the mentor to see if there is some hidden reasons.



PROJECT PLAN

17

5.1.2. Iteration planning

Iteration planning is mainly done by the management team, together with the customer. The

aim is to keep a customer meeting always right after each iteration demo, so that the planning

of the next iteration can start right after the review of the previous iteration. After this an

internal meeting will be organized to communicate in more detail to the whole group, the

things that need to be accomplished during the coming iteration. The group morale and

synergy need to be aroused at the beginning of each iteration. The project manager will

collect all the information required for the meeting and distribute it to all of the group

members. Additional small meetings can also be organized via MSN, if the management

group needs to communication some management issues.

5.1.3. Documenting

This project work will require a huge amount of documentation work. The following table

will preliminarily specify the responsible persons for all the required documents.

Table 9. List of documents and responsible persons

Documents Responsible person(s)

Project plan Project manager

Iteration plans Project manager

Meeting minutes Project manager

Requirements document Requirements manager

Use cases documents Usability specialist

Quality assurance plan Quality assurance manager

Test plan Tester

Test reports Tester

System specification Lead developer

User manual Usability specialist

Progress reports Project manager

Final report Project manager

5.1.4. Risk management

We do not like risks and do not wish them to jeopardize our project. Our main objective is to

avoid risks. We will list top five risks sorted with priority, impact severity and duration in our

weekly meeting memo. These risks shall be collected, analyzed and concluded every week.

Every member shall give opinion on the project and how it is progressed. We welcome

comments and complaints from the group members, since it reflects existing problems in the

group. According to the collected risks, we will analyze them and find out how to avoid them.

If they are not avoidable, we will find out and execute corresponding actions to keep the risk

under our control. These risks shall be reanalyzed in the next meeting.

5.1.5. Time reporting

Time reporting is done by filling up an Excel sheet on a weekly basis. At the start of each

iteration the management team designs the required time reporting spreadsheet and sends it to



PROJECT PLAN

18

the group members. The spreadsheet keeps track of each individual task designed for that

iteration on an hourly basis. Any time spending on additional (not defined) tasks should be

specified and justified.

These spreadsheets are to be delivered to the project manager at the end of each week, so that

she can properly monitor and control time consumption and development progress in the

project.

5.1.6. Software size reporting

The software size will be checked every week for analyzing the progress and production

efficiency. The major criteria will be the physical size of the software developed; the length of

the code by lines, and how many new files has been produced.

Together with the time reporting, we can find out the production rate of developers and

understand their capability in production. It would help us in further planning and scheduling

the development work.

5.1.7. Communication

E-mail is the primary communication channel within the project team itself and with the

other stakeholders, the customer and course mentor. The project manager will be the interface

who will take care of the messages from and to the customer as well the mentor. She then will

forward all the messages to the other group members.

Course WIKI will also be a communication channel for all the parties involved. Project

manager will upload all the meeting minutes to the WIKI on time. MSN messenger will be

used as a supplement when minor issues need to be handled instantly.

5.1.8. Iteration demo

For each iteration demo, the project manager will collect all the required information and

make the PowerPoint presentation for the demo. Other group members, the customer and

mentor will also get a chance to comment on it and suggest changes before the final

demonstration. All the group members are required to participate in the demonstration and

present their parts in each iteration. Except in the first project planning iteration demo, where

only the management group is required to be present to demonstrate the project planning

phase. Other members are also welcome to the demo, but are not necessary.

5.1.9. Version control

As our customer recommendation suggests, the version control tool will be Subversion8. It is

an improved implementation of CVS. Subversion was already adopted by the previous

mGroup project, on which the CoMedia application is built on.

5.1.10. Coding convention

8 See specification at Tigris.org http://subversion.tigris.org/



PROJECT PLAN

19

The coding convention will be traditional Java conventions9. The coding style should also

follow that of the mGroup application, as required by the customer.

5.1.11. Defect tracking

For the defect tracking, Bugzilla will be used for bug reporting, tracking, resolving and

closing. The team will follow the Bugzilla configuration in the bug reporting process.

5.1.12. Peer testing

The developed CoMedia application will be peer tested by the BitPlayers group at the end of

the third iteration.

5.1.13. Requirements management

Most of the requirements will be collected by meetings with the customer and technical

advisor. The requirements managers and the lead developer will also study all the

documentation provided by the customer to further understand the needs of the customer. The

CoMedia system will be built on the previous year project mGroup, therefore the

requirements managers and the lead developer also need to understand the system

specification of mGroup. More interaction with the customer will take place whenever the

group feels that there is a need for requirements clarification. The requirement team will be

responsible for eliciting, recording, analyzing, documenting all the requirements and then

explain to the whole group.

5.1.14. Progress Monitoring and Control

The progress monitoring and control is the most important measures to ensure the success of

the entire project. The project group will meet internally once a week to report individual

development status, problems, needs and work plan for the next week.

When the technical design is finished, detailed implementation tasks will be distributed to the

group members with schedules. Each week during the internal meeting, the development tasks

for each group member will be announced and set as the development goal of the week. In the

following week meeting, the development status will be checked against the goal. If slippage

exists, a discussion must be held on for the slippage reason and action how to catch up the

schedule. The project management group must help the developer to solve encountered

problem if necessary.

Action point is an activity that must be complete within a certain time interval. To improve

the project management practice, action points (technical / non-technical) for each member

can be set. Project manager must constantly compare the actual development schedule against

the project plan. Deviation from the original plan must be detected, planned and resolved

using action points and other necessary measures.

A bi-weekly meeting is set up with the customer to present the project status and demonstrate

the project implementation. It is a tool for the customer to track the project status, resolve

problems and ease the project team for the development.

9 See specification at SUN web-site http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html



PROJECT PLAN

20

5.2. Quality assurance plan

This section is written in a separate document; see document delivery homepage – CoMedia

Quality Assurance Plan.

5.3. Tools

To Sum up, the tools that will be used in this project will be as follows:

� The customer will provide to the project a concept design of the new media

formats and of context aware features together with a basic java platform on

which to start, so that the group can concentrate on the advanced features

� Version control: Subversion. Subversion is an open-source version control tool

that is used to check files in and out of the system.

(svn version 1.1.4 (r13838) compiled May 13 2005, 06:29:47)

� Nokia 6630 3G phones and SIM cards as test phones. HIIT has provided four

Nokia mobile phones to test the application. The phones have a Series60

interface and run the Symbian operating system. The phones are MIDP 2.0

compatible and support 3G networking and Bluetooth.

� Server PC: HIIT has provided a PC on which to run the server application. It is

an AMD CPU with 1.3 gigaByte processor, 1 gigaByte RAM running Debian

GNU/Linux Sarge and is equipped with Subversion with the base application,

Ant and MySQL, along the current versions of standard GNU applications.

� MySQL: the server application uses a MySQL database.

(mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu(i386))

� J2ME SDK

� Wireless tools from SUN

� Nokia series 60 emulator

� Excel compatible applications will be used for time reporting and other reports.

� Bugzilla by Mozilla is going to be tested as a bug tracking tool.

5.4. Standards

The customer does not dictate any process standards for the project but has provided four

features that are targeted for requirement specification and implementation



PROJECT PLAN

21

6. Phasing

6.1. Schedule

The table below includes all the important dates or time periods throughout the whole project

life cycle. Some of the dates are rough estimates, thus are subject to change once more

detailed information is available. We will have at least one internal group meeting every week

to follow the progress and more internal meetings will be arranged whenever necessary. For

the mentor meetings, one mandatory mentor meeting will be held in each iteration but more

will be scheduled if needed. For the customer meetings, bi-weekly meetings will be held to

maintain the necessary face-to-face communication.

Table 10: Project schedule

Date Project related events

PROJECT PLANNING (27.9.- 20.10.2005)

Tu 27.9 Group forming: first informal group meeting in CS building

We 28.9

(9.30-11.30am)

Official kick-off meeting with the customer in HIIT building

- Presentation by the customer

Mo 3.10 DL 13:00 E-mail iteration plan (proj. plan ch. 6.1 & 6.2) to the mentor and

customer

We 5.10

4.00pm

- First meeting with project mentor Lauri Svan

- Internal meeting after the meeting with the mentor if necessary

Th 6.10 Lead developer meets customer to get the server and software installation

Th 13.10 Meeting with the customer to discuss the scenarios

Fr 14.10 5pm - Internal meeting for document review and revising and demo rehearsal

Mo 17.10 DL 13:00 Delivery of documents

We 19.10 3pm Iteration demos

We 19.10 4pm Meeting with customer to discuss detailed requirements specification and

task division

IMPLEMENTATION 1 (21.10.- 8.12.2005)

Th 27.10

8am

Internal meeting

-review of the tasks done in week 42-43

Mo 31.10. DL 13:00 Group sign up. E-mail names + IDs to the teacher.

Mo 31.10. DL 13:00 E-mail iteration plan + QA plan (proj. plan ch. 5.2. & 6.1 & 6.3) to

the mentor and customer

Th 3.11

3.30pm

Customer meeting to demo the first milestones

-sound recording

-message content storing

Th 3.11 8am Internal meeting

Th 10.11 8am Internal meeting

We 16.11 3pm Internal meeting



PROJECT PLAN

22

We 16.11 4pm Mentor meeting

Th 17.11 3pm Customer meeting

Week 47

(21.11-27.11) Internal meeting

Week 48

(28.11-4.12)

- Internal meeting

- Meeting with customer

Mo 5.12. DL 13:00 Delivery of documents

We 7.12

3pm Iteration demo

Week 50

(12.12-18.12)

- Internal meeting to review the second demo

- Meeting with the customer

9.12.-15.1. Christmas vacation (shorter vacation is allowed)

IMPLEMENTATION 2 (16.1. - 2.3.2006)

Mo 16.1 Internal meeting for ‘re-kick-off’ after the vacation and to review the iteration

plan and QA plan

We 18.1. DL 13:00 E-mail iteration plan + QA plan (proj. plan ch. 5.2.2 & 6.1 & 6.4) to

the mentor and customer

Week 4

(23.1-29.1)

- Internal meeting for demo rehearsal


- Mentor Meeting

1.-3.2. Demo to the customer and mentor (show visible progress)

Week 6

(6.2-12.2)

- Internal meeting for demo review


Fr 17.2. DL 13:00 Deliver the final system and testing guidelines to the peer group.

18.2-20.2 Peer testing

Tu 21.2. DL 13:00 Report the peer testing results to the peer group

Week 8

(20.2-26.2)

- Internal meeting to discuss about the peer testing results

- Internal meeting for demo rehearsal


Mo 27.2. DL 13:00 Delivery of documents

We 1.-2.3. 8-19 Iteration demos

Fi 3.3 Internal wrap-up meeting

6.2. Project Planning 6.2.1. Goals

• project plan

• technical & usability requirement specification



PROJECT PLAN

23

• project & product name

• project scoping

• understanding the domain and context of the project (including concepts of visual

code and context phone)

• study related topics (mobile usability, HCI10), technologies (Bluetooth, MIDP 2.0),

research and theories (Human communication)

• understanding the previous implementation related to this project

• set up project work and communication methods and environment

• set up a work process for project monitoring, controlling and reporting

• task distribution and understanding roles and responsibilities in the project

• build a project homepage for management and control purposes (documentation, status

report, meeting memo etc.)

• finish all the deliveries for phase 1 with high quality work and communicate the

contents to all the group members

6.2.2. Deliverables

• project plan (except ch. 5.3 QA Plan)

• requirements document (ch. 1-5, ch. 6-9 at least most important requirements, ch. 11-

12)

• progress report

• SEPA diaries (ch.1, for management group members also ch. 2-3)

6.2.3. Tasks

Planned tasks listed below conclude our understanding from the meeting with the customer as

well as the requirements from the course. The effort estimation is preliminary since this is the

beginning of the project and the group is still adapting to a more synchronized working

rhythm.

Table 11: Task estimation for Phase 1

TASKS

EFFORT

(hours/person)

RESPONSIBLE

PERSON(S)

Starting

Date

Ending

Date

Scenario and use case

studies for requirement

specification

2 Jing, Helles

(RM) & Martelin

(LD)

07.10 08.10

Functional requirement

drafting

8 Jing (RM) 09.10 13.10

GUI requirement drafting 8 Teppo (RM) 09.10 13.10

Requirement review

session

2 Jing, Helles

(RM), Martelin

(LD) & the

customer

14.10 14.10

Requirement finalization 2 Jing, Helles 15.10 17.10

Domain study and

documentation reading

2 All 03.10 13.10

10 HCI: Hunan Computer Interaction



PROJECT PLAN

24

(Scenario

Meeting)

Technology, theory &

topic study

2 All 03.10 20.10

Lectures 8 All 27.9 20.10

Meetings with the

customer and mentor

6 All 27.9 20.10

Internal meetings 6 All 27.9 20.10

Adopting tools 3 Developers 03.10 20.10

Building a project

homepage

6 Martelin (LD) &

1 developer

07.10 20.10

Define project goals

17.10

3 Jing/Helles (RM)

& Martelin (LD)

28.9

(DL for

PPlan)

Other project management

duties

5 Fang (PM) 27.9 20.10

Personal SE practice 17.10

2 All 27.9

(DL for

PPlan)

Plan the next iteration 1 All 18.10 20.10

Plan work methods and

tools

2 All 13.10 16.10

Risk management 17.10

1 Fang (PM) 27.9

(DL for

PPlan)

Project preparation/Start

and organize project

3 Management

Group

27.9 20.10

Writing and publishing

meeting minutes

4 Fang (PM) 27.9 20.10

Write progress report 17.10

6 Fang (PM) 13.10

(DL for

PPlan)

Finalize the project plan

for phase one

17.10

8 Fang (PM) 28.9

(DL for

PPlan)

Supporting PM for project

plan phase one

17.10

3 Jing/Helles (RM)

& Martelin (LD)

28.9

(DL for

PPlan)

TOTAL TIME (hours) 313

6.3. Implementation 1



PROJECT PLAN

25

This first implementation phase will focus on three out of the five requirements of the whole

project: Context awareness, Multimedia content and Permanent media content storage, out of

which the first two must be completed during this phase while the Permanent media content

storage functionality can overlap into the beginning of the next implementation phase as well.

During this iteration also the user interface design, technical system specification, test cases

and test plan, quality assurance plan and progress report should be finished and delivered.

Naturally, the project plan and requirement specification will be modified and updated if

necessary.

6.3.1. Goals

• Finish technical design

• Form two developer teams and divide implementation tasks in the two teams

• Focus on organized implementation works in order to realize all the milestones for this

iteration

• Deliver two required system functionalities to the customer with good quality: Context

messaging and Multimedia messaging

• Finish or partially finish Permanent media content storage

• Decide SEPAs topics and finish half of SEPAs at the end of this iteration

• Integrate SEPAs practices into the software development process with an attempt to

improve the process

• Finish all the other deliveries for this phase with high quality work and communicate

the contents to all the group members

6.3.2. Deliverables

• Course required deliverables

o QA Plan

o Technical specification

o Test plan

o Test report

o Progress report

o SEPA diaries

• Additional deliverables

o Updated project plan



PROJECT PLAN

26

o Updated requirements specification

o Meeting minutes/memo

o Bi-weekly demo for milestones to the customer

6.3.3. Tasks

Planned tasks listed below are divided into managerial tasks and technical tasks. The effort

estimation were made in the first internal meeting of this iteration.

Table 2: Task estimation for implementation 1

Planned tasks Responsible

Estimate

Managerial and documentation tasks

QA plan writing and reviewing Jing(RM) 10 *1=10

Test plan writing and reviewing Jing(RM) 12 *1=12

Support RM for QA plan and Test plan Tomas(LD) 5 *1=5

Iteration plan preparation, writing and reviewing Liang(PM) 6 *1=6

Update Project plan Liang(PM) 4 *1 =4

Write Progress report Liang(PM) 10 *1=10

Support/help PM in iteration plan, project plan updating

/progress report writing

Teppo(RM) 10 *1=10

Update Requirement Specification

Jing/Teppo

(RM)

2 *2=4

Mentor meeting All 2 *8=16

Customer meetings To be confirmed

Internal meetings All 6 *8=48

Writing meeting minutes Liang(PM) 6 *1=6

Personal SE practice All 2 *8=16

Writing SEPA All 2 *8=16

Other project management(Project manager) Liang(PM) 15 *1=15

Other project management(group members, if applicable)

Plan the next iteration All 1 *8=8

Subtotal 186

Technical tasks

GUI design Teppo(RM) 8 *1=8

UI specification writing Teppo(RM) 8 *1=8

Technical design/specification writing Tomas(LD) 15 *1=15

Support tech. design/writing Teppo(RM) 2*1=2

Studying the last year implementation 4h/week*4 weeks)

Developers except

Jimmy

16*3=48

Study the requirements of the whole project and pervious

year implementation

Jimmy* 26

Technical implementation Tomas(LD)** 20



PROJECT PLAN

27

Technical implementation(including some preliminary

testing) (8h/week *4 weeks )

(subtasks are presented as bellows: )

Developers 32*4=128

Context Awareness: Lucas/Jimmy 50

Implement parser for ContextPhone log 12

Implement ContextCue database structure 12

Implement ContextCue delivery format from server to

the clients

12

Integrate context cues into GUI components 12

Multimedia content: Magnus/ Di 50

Implement control mechanism for recording &

playing media

12

Implement sound recorder & player 12

Implement video recorder & player 12

Implement methods for attaching media content to

messages

12

Permanent media content storage: Tomas

All developers

48

Implement data storage structure for MMC cards 8

Implement media content download mechanism 8

Implement media story, message & user database

structure (server)

8

Implement new content advertiser on server 8

Implement client-server handshake model 8

Implement data-management tools 8

Test case design/documenting Tomas / Jing 10 *2=20

Test execution/fixing and report bugs (last week before

demo)

Tomas/

Developers

10 *5=50

Testing Usability Teppo(RM) 4*1=4

Quality assurance Jing(RM) 4 *1=4

Preparing for customer demo All 1 *8=8

Subtotal 341

TOTAL(preliminary) 527

* Jimmy came to this project later than the other developers; therefore he needs to spend more

time get familiar with the previous year implementation

**Tomas will not spend as much time as the developers but he needs to do some technical

implementation work to help the developers.

Table 3 planned hours for each group member in this phase

Name Hours

Fang, Liang 55

Helles, Teppo 48

Jing, Jing 52



PROJECT PLAN

28

Martelin, Tomas 74

Sandberg, Magnus 72

Vikström Lucas 72

Zhu, Di 72

Kjällman，Jimmy 82

Total 527

6.4. Implementation 2

This phase will deliver the rest two functionalities, Bluetooth P2P network and Visual code,

and conclude the project as a whole. All required documents fro the course and project need

to be finalized and delivered during this phase. The system will be thoroughly tested by the

group, handed over for peer testing and finally to acceptance testing. More detailed plan for

this iteration will be made during the third iteration planning stage and be added into this

project plan.



PROJECT PLAN

29

7. Risk log

This chapter will list all the risks that have been identified so far for this project. However this

risk log needs to be updated frequently when new risks are identified during the project

development. All the risks need to be taken into consideration when making project decisions.

The project management group, especially the project manager shall be responsible for risk

management. But risk management shall also become everybody’s business due to the elusive

nature of risks.

The risk log below will be presented separately according to each phase. Therefore there will

be three rig log tables.

Table 12: Risk log-project planning phase

ID Risk Effects Controlling actions Responsible

1. Customer does not want to do

this project any more and quit

the course

Very strong negative

effects: the project will be

aborted and group cannot

finish their course

Trying to communicate

with the customer in a

frank way to see if

there is any room for

discussion

Project manager

2. Requirements eliciting is not

enough Strong negative effect: lack of requirements will

make system architecture

difficult and will cause big

requirements changes later

Communicating with

the customers more to

understand their needs

Requirements

managers

3. Wrong requirements are

elicited Strong negative effect: system change in later

phases will be more costly

and time-consuming which

will delay the delivery

This problem can only

be solved via active and

frequent interaction

with the customer

Requirements

managers

4. Tools are too difficult to be

learnt by the developers and it

will take longer time than

expected

Negative effect: the

learning will take longer

time and that will affect

the project schedule

Seeking help from the

technical advisor, using

group learning synergy

Lead developer

5. Last year’s system is not

working properly


CoMedia cannot be

implemented on top of it

Seeking help from the

technical advisor

Lead developer

6. Requirements are hard to be

prioritized because there are

too many features to be

implemented and the

customer wants them all or

don’t know how to select

Negative effect: without

prioritizing the project can

suffer from tight schedule

and maybe lead to late

delivery

Communicating with

the customer more

frequently to help them

clarify the requirements

Requirements

managers

7. Difficult to start working as a

group, some communication

problems

Negative effect: group

trust cannot be built and it

will make later iteration

works more difficult

Group members shall

try their best to build

trust through more

active communication

All

8. Too tight schedule and the

required deliveries cannot be

finished before deadlines or

can only be finished with poor

quality


group’s grade will be

affected and the next

iteration cannot start on

time

Monitor and control the

progress actively,

group members shall

help each other

All

9. Recruited developers are not Negative effect: learning Seeking help from Project manager



PROJECT PLAN

30

qualified to do the

implementations for the next

iterations

the skills will take time

and that will delay the

schedule

course staff & Lead

Developer

10. Misunderstandings in

communications with the

mentor, the customer and also

within the group

Negative effect: highly

possible to occur and it

takes extra effort to solve

the problems that was

caused by the

misunderstanding

Talk more in the

meetings instead of the

emails. Arrange more

meetings if necessary

All

11. Customer feedback too slow Negative effect: this will

delay the progress of the

project

More active

communication with

the customer and make

him understand the

tight schedule of the

course

Project manager

Table 12: Risk log-implementation 1

ID Risk Effects Controlling actions Responsible

1 Vague work division among

the developer teams

Negative effect: people

spend time doing duplicate

work or some jobs are

neglected

More internal

communication

More planning

All

2 Design work is not well

done Strong negative effect:

inadequate design will make

things hard for the

developers to get started

Talk openly on the

meetings

Lead developer has to

take the responsibility

All

3 Technical design cannot be

completed on time

Negative effect: the late

design will affect the

schedule

Management group

and the whole team

will have to push the

designer

All

4 Little time for SEPA,

people cannot decide on the

topic

Negative effect: members

who do T-76.115 course

might not pass

Increase members’

incentive to practice

what they choose to

write during the

project process

All

5 Members do not have the

required skills to finish what

has been assigned to them

Negative effect: time slips

will happen easily in such

cases. Less value adding

time means less efficiency

Allocating the jobs

according to skill level.

Check frequently if

members have

difficulties

Seek help from the

technical advisor if

necessary

All

6 Too many requirements to

be implemented and time is

not enough

Negative effect: customer

might not be satisfied if what

he wants cannot be

delivered; meanwhile

developers feel frustrated

because they are always

behind their schedule

Negotiate and

communicate with the

customers, trying to

see if there is room for

concession.

Management

group

7 Requirements change from

the customer

Negative effect: changes can

cause serious time shortage

and rework. Developers will

be disappointed if they have

to change their work

Negotiate with the

customer

Management

group



PROJECT PLAN

31

constantly.

8 New requirements added

during implementation

Negative effect: New

requirements will demand

extra time and even affect

the architectural work

Negotiate with the

customer

Management

group

9 Key member(s) are not

available

Negative effect: design or

some critical path

development cannot be

realized on time; project will

be delayed

Roll rotation or

replacement when the

person is not available

Management

group

10 Customer feedback is too

slow

Negative effect: project

progress might not be on the

right track as what the

customer wants

More effective

communication,

making full use of

every meeting

All

11 Some members burn out

their time in the first two

iterations

Negative effect: others will

have to take up their jobs

later which will affect the

progress of the project

More tight monitoring

and control on time

Project manager

12 Insufficient communication

among the developers and

Lead developer

Negative effect: Developers

need clear instructions

otherwise their work cannot

be orchestrated.

Lead Developer should

take a more managerial

role

Lead developer

and developers

13 The previous application

has bugs which affect our

development

Negative effect: It will slow

down our development.

Developers will have to fix

the bugs or they have to find

ways to bypass the bugs.

Developers have to try

their best to find such

bugs as early as

possible.

Seeking help from

technical advisor

Lead developer

and developers

14 Team work spirit is low and

morale is low

Negative effect: morale is

the key to success.

Try to have more

effective

communication and

build more open

atmosphere

All



PROJECT PLAN

32

8. Acronyms and abbreviations

A glossary explaining the acronyms and abbreviations used in this document are explained

here.

Table 13 Acronyms and Abbreviations

Acronym /

Abbreviation Description

3G 3rd generation wireless

ad-hoc Spontaneous

API Application Programmin Interface

BT Bluetooth

CPU Central Processing Unit

CVS Concurrent Versions System

DB Database

DL Deadline

GNU

Gnu's Not Unix, name for the complete UNIX-compatible

software system

GPRS General Packet Radio Services

GUI Graphical User Interface

HCI Human-Computer Interaction

HIIT Helsinki Institute for Information Technology

HUT Helsinki University of Technology

IDE Integrated Development Environment

J2EE Java 2 Platform, Enterprise Edition

J2ME Java 2 Platform, Micro Edition

J2SE Java 2 Platform, Standard Edition

LD Lead Developer

MIDP Mobile Information Device Profile

MMS Multimedia Messaging System

P2P Peer to Peer

PDA Personal Digital Assistant

PM Project Manager

QA Quality Assurance

RAM Random Access Memory

RM Requirement Manager

SDK Software Development Kit

SE Software Engineering

SEPA Software Engineering Practice Assignment

SIM GSM subscriber identify module

SMS Short Messaging System

SQL Structured Query Language

SUN Sun Microsystems, Inc

UI User Interface

UML Unified Modelling Language



PROJECT PLAN

33

9. References

1. Vanhanen, Jari: http://www.soberit.hut.fi/T-76.115 Project Planning Guidelines

2. http://www.soberit.hut.fi/T-76.115 Projects' Deliveries 2004 - 2005

3. http://www.soberit.hut.fi/T-76.115 Topic Proposals 2005-2006

4. Jacucci, Giulio. CoMedia project scenarios

5. Jacucci, Giulio and Salovaara, Antti. Mobile media sharing in large-scale events-

beyong MMS

6. Jacucci, Giulio. Supporting the shared experience of spectators through mobile group

media.



PROJECT PLAN

34

10. Appendix

1. Calculation of the theoretical budget for this project

For the customer side, if the planned bi-weekly meetings will be held through out the whole

project, starting from week 39 in 2005 to week 9 in 2006, when the project will be over,

except the Christmas holiday (09/12/05-15/01/06) there will be about 9 meetings, every one

of which will take around 2 hours.

For the mentor side, there will be at least 3 meetings with him, each lasting about 1.5 hours.

For the project group side, there will be 8 students. If everyone will spend 170 hours for the

project, there will be a total of 1360 working hours spent on this project.

Lets assume that the customer will pay 50 euros to buy each hour the project group will spend

for this project, including the mentor. This will give us the customers budget for this project.

If we assume the project group members to be paid 20 euros per hour for their work inside the

group we will get a budget for the project group. The development tools in this project will be

students’ own computers and a server provided by the customer, so the material costs

(hardware & software) will not be calculated here.

Table 1 Customer budget

Expenses Hours Price/hour

(euros)

Total

(euros)

Customer and

technical advisor

working hours

100

(meetings + other work related to the project)

50 5000

Project fee 2000

Mentor 20 (meetings + other jobs related to project) 50 1000

Customer pays

group members

1360 50 68000

Total 76000

Table 2 Group budget

Expenses Hours Price/hour (euros) Total (euros)

Group member

working hours

1360 20 27200

Total 27200

project plan - SoberIT-Software Business and Engineering · PDF file ·...

Documents

Transcript of project plan - SoberIT-Software Business and Engineering · PDF file ·...