Date post: | 29-Mar-2018 |
Category: |
Documents |
Upload: | nguyentuong |
View: | 214 times |
Download: | 1 times |
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
T-76.4115 SOFTWARE PROJECT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
PROJECT PLAN
3
6.4. Implementation 2................................................................................................. 28
7. Risk log .........................................................................29
8. Acronyms and abbreviations ......................................32
9. References.....................................................................33
10. Appendix.......................................................................34
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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/
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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.
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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.
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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.
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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.
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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/
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
- Meeting with the customer
- 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
- Meeting with the customer
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
- Meeting with the customer
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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.
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
Negative effect: the
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
Negative effect: the
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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.
T-76.4115 SOFTWARE PROJECT
FUTURE MOBILE GROUP MEDIA FORMAT
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