project plan - aalto university · t-76.115 software project - p2pdigitv project plan – ml-pp...

Helsinki University of Technology

T-76.115 Software Project

Project PlanHelsinki Institute for Information Technology

P2PDigiTV

Document ID: ML-PP

Team Medialiima

30 Nov 2004

Revision: 250

T-76.115 Software Project - P2PDigiTV Project Plan – ML-PP

Revision History

Revision Date Author Description250 30 Nov 2004 Hartikainen Updated table 6184 27 Nov 2004 Hartikainen Fixed some typing errors182 27 Nov 2004 Hartikainen Updated Table 6180 27 Nov 2004 Hartikainen Updated Introduction, customer goals and

I1 deliverables and tasks173 25 Nov 2004 Suhonen Updated chapter 5142 17 Nov 2004 Hartikainen Updated chapter 6 to contain detailed I1

plan, updated realized hours for PP137 11 Nov 2004 Hartikainen Revised estimated working hours in sec-

tion 4.1127 07 Nov 2004 Hartikainen Added operating environment figure, re-

vised introduction chapter112 02 Nov 2004 Hartikainen Minor issues pointed out by the customer,

fixed citation references111 02 Nov 2004 Suhonen Minor changes to chapter 5105 01 Nov 2004 Niinimäki Added chapter 5.1.3102 01 Nov 2004 Suhonen Small fixes to chapter 5, added references

to other delivery documents98 01 Nov 2004 Hartikainen Lots of small fixes according to review

comments88 30 Oct 2004 Suhonen Minor changes to chapter 585 29 Oct 2004 Suhonen Added sections to chapter 579 29 Oct 2004 Hartikainen Updated customer goals, added document

ID, other minor fixes77 28 Oct 2004 Suhonen Moved some sections from chapter 5 to

Quality Handbook70 28 Oct 2004 Hartikainen Added chapter 6, revised other chapters69 28 Oct 2004 Suhonen Minor changes65 27 Oct 2004 Suhonen Added sections to chapter 525 20 Oct 2004 Hartikainen Fixed paths to style file and pictures20 20 Oct 2004 Hartikainen Revised chapters 1, 2 and 3. Added text to

chapter 417 20 Oct 2004 Hartikainen Added chapter 3 and parts of chapter 4, re-

vised other chapters16 17 Oct 2004 Hartikainen Added chapter 1 and parts of chapter 210 09 Oct 2004 Hartikainen Added revision column to revision history

table5 09 Oct 2004 Hartikainen Removed unnecessary comments4 09 Oct 2004 Hartikainen Added automatic revisioning3 08 Oct 2004 Hartikainen Improved layout

Team Medialiima 30 Nov 2004 (rev 250)


Contents

1 Introduction 1

1.1 Purpose and Scope of the Project . . . . . . . . . . . . . . . . . . 1

1.2 The System and Environment . . . . . . . . . . . . . . . . . . . . 1

1.3 Terminology and Definitions . . . . . . . . . . . . . . . . . . . . 2

2 Stakeholders and Staffing 2

2.1 Project Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Other Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Goals and End Criteria 7

3.1 Goals of the Customer . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Goals of the Project Group . . . . . . . . . . . . . . . . . . . . . 7

3.3 Personal Learning Goals . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Project Abort Criteria . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Project End Criteria . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Resources and Budget 10

4.1 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Work Practices and Tools 12

5.1 Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1.1 Iterative Development . . . . . . . . . . . . . . . . . . . 12

5.1.2 Iteration Planning . . . . . . . . . . . . . . . . . . . . . . 13

5.1.3 Requirements Management . . . . . . . . . . . . . . . . 13

5.1.4 Risk Management . . . . . . . . . . . . . . . . . . . . . 14

5.1.5 Documenting . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.3 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15



6 Phasing 15

6.1 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2.2 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.3 Implementation 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.3.2 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 18

6.3.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.4 Implementation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.5 Finalization and Delivery . . . . . . . . . . . . . . . . . . . . . . 21

7 Risk Log 21

References 21



1 Introduction

1.1 Purpose and Scope of the Project

The project Medialiima is executed as the practical part of T-76.115 SoftwareProject course in Helsinki University of Technology during the autumn term 2004and the spring term 2005. The main project group consist of seven computer sci-ence students from Helsinki University of Technology. Because of the nature ofthe project as a part of a university course many aspects of the project must followguidelines and frameworks defined by the course organization. Especially usedsoftware development framework and schedule are completely set by the coursestaff.

The main goal of the project is to create a fully functional set-top-box prototype forterrestrial digital television (DVB-T). The developed prototype will have most ofthe functionalities provided by current products, but in addition to that it will offermore advanced features in the area of content creation and sharing. A good exam-ple of such functionality would be a seamless integration to existing informationnetworks to enable content downloading and sharing between other users.

The customer of the project is Helsinki Institute for Information Technology (HIIT).HIIT is a joint research institute of Helsinki University and Helsinki Universityof Technology, which conducts internationally high-level strategic research in in-formation technology. The main goal of the customer in the project is to get aworking prototype, which could be demonstrated to attract potential investors inthe industry to join further development of the technologies used in the prototypein co-operation with HIIT’s research projects. Because of the prototype nature ofthe project, features provided by the prototype are considered more important thanthe high level of quality.

All software and other material produced during the project will be released underMIT open source license [1].

1.2 The System and Environment

The basic idea behind the system to be developed is to provide end users an en-hanced set-top-box compared to existing solutions. The created product shouldprovide most of the functionality found in the current high-end set-top-boxes andin addition give some extra functions that are not found in the current products atall. The most important of such functions are high integration to other digital net-works than the digital television network as well as integration to multiple wirelessterminals such as mobile phones and personal digital assistants (PDA). Good inte-gration to content management system DiMaS is also an important feature that willenable end users to consume and redistribute material provided by various contentproviders using for example the peer-to-peer network created by set-top-boxes or

Team Medialiima 30 Nov 2004 (rev 250) 1 (22)


wireless connections to handheld devices such as mobile phones. The used hard-ware platform is based on the standard and open PC hardware architecture.

The operating environment of the product would ultimately be the same as that ofthe current set-top-boxes, most commonly the living room of households. How-ever, because of the prototype nature of the project, the environment used duringthis project will be more controlled by the project group and could be almost com-pared to ”laboratory conditions”. An overview of the environment surroundingP2PDigiTV set-top-box is illustrated in Figure 1. In the picture are also presentedentities, which are out of the scope for this project (mainly mDiMaS and its relatedsystems). However, these systems will indirectly affect also P2PDigiTV projectand were included for completeness.

Since P2PDigiTV project relates very closely to HIIT projects done by other groupson the T-76.115 course (DiMaS and m3Festival), there will also be some co-operation between all these groups. The co-operation is led by the common cus-tomer together with all project managers of participating teams. Rough division ofresponsibilities between projects is presented in Table 2.

Table 2: Responsibilities between P2PDigiTV, DiMaS and m3Festival projectsProject Main ResponsibilitiesP2PDigiTV Normal digi-TV set-top-box functionality, ability to create a

P2P network and share distribution packages (DP) in that,ability to download DPs from the DVB-T stream

DiMaS Ability to create and publish new DPs, user management &authentication, encryption key management

m3Festival Creates a gateway between mobile phones and fixed P2P net-work, offers content from P2P network to mobile terminals,routes messages realtime between mobile terminals

1.3 Terminology and Definitions

All used terms and abbreviations of this document are presented in Table 3.

2 Stakeholders and Staffing

As a project developing a prototype product there are very few different stakehold-ers that need to be taken into consideration from the project group’s viewpoint.Most of the external and more distant stakeholders (e.g. digi-TV industry) are ”be-hind” the project’s customer and won’t interact directly with the project group. Theorganisational diagram of the stakeholders and staffing of the project is presentedin Figure 2.



Figure 1: Environment of the system.



Table 3: Terms and abbreviations used in this document.Term ExplanationHIIT Helsinki Institute for Information Technology. The customer of

the project.HUT Helsinki University of Technology. Organizer of the T-76.115

Software Project course.DVB-T Digital Video Broadcasting - Terrestrial. European standard for

sending digital television broadcast [2].PDA Personal Digital Assistant. A small mobile terminal which nor-

mally contains electronic calendar, memos, addressbooks etc.Ethernet Datalink layer data transfer protocol commonly used in local area

networks. Most of the home and corporate networks use Ethernetprotocol.

WiFi Wireless Fidelity. A set of standards for wireless local area net-works (WLAN) based on the IEEE 802.11 specifications.

Bluetooth Wireless low-power and short range data transfer technique com-monly used in PDAs, mobile phones, laptops and other mobileterminals.

IrDA Infrared Data Association. IrDA creates specifications for wire-less data transfer using infrared signal.

DP Distribution Package. Media content package that wraps the ac-tual content and all of its metadata. Package may also containsome software that can be used to view or edit the content. Di-MaS creates and publishes all DPs as Java JAR archives.

DiMaS Digital Content Distribution Management System. The contentmanagement system used to create distribution packages and dis-tribute them.

mDiMaS Mobile Digital Content Distribution Management System. Sys-tem that enables mobile terminals to create, edit and view DPsand participate in fixed P2P network of DiMaS.



Course Staff (HUT)

Jaakko Nyrölä Project group's

mentor

m3Festival Project Team DiMaS Project Team

Co-operates

Delivers the product

Gives requirements, evaluates

Supports, evaluates

Asks for help

P2PDigiTV Project Team (Medialiima)

Tuomas Niinmäki System Architect

Antti Halla Coding & Testing

Ilkka Lyytinen SW Specification & coding

Ilpo Stenberg HW Specification & coding

Anna-Kaisa Pietiläinen Risk Management &

coding

Kari Suhonen Quality Assurance

Jouni Hartikainen Project Manager

Perttu Marttila Project Manager

Markus Mannevaara Project Manager

Customer (HIIT)

Olli Pitkänen Customer

Representative

Tommo Reti Customer's

Technical Advisor

Figure 2: Organization of the project.



2.1 Project Group

The project group consists of seven computer science students from Helsinki Uni-versity of Technology. Following list contains their contact details and informationabout their responsibilities in the project group. (Please note scrambled email ad-dresses.)

• Antti Halla

– Email: ahalla#cc.hut.fi.removethis

– Responsibilities:Coding & testing

• Jouni Hartikainen

– Email: jouni.hartikainen#hut.fi.removethis

– Responsibilities:Project Manager

• Ilkka Lyytinen

– Email: ilyytine#cc.hut.fi.removethis

– Responsibilities:Software specifications & coding

• Tuomas Niinimäki

– Email: taniinim#cc.hut.fi.removethis

– Responsibilities:System architect

• Anna-Kaisa Pietiläinen

– Email: apietila#cc.hut.fi.removethis

– Responsibilities:Risk management & coding

• Ilpo Stenberg

– Email: istenber#cc.hut.fi.removethis

– Responsibilities:Hardware specifications & coding

• Kari Suhonen

– Email: kari.suhonen#hut.fi.removethis

– Responsibilities:Quality assurance



2.2 Other Stakeholders

In addition to project group there are two customer representatives and group’smentor actively involved in the project. Communication with the other HIIT projects(namely DiMaS and m3Festival) is done via respective project managers. Contactinformation of all these stakeholders is presented in the following list.

• Olli Pitkänen

– Email: olli.pitkanen#hiit.fi.removethis

– Responsibilities:Main customer representative

• Tommo Reti

– Email: tommo.reti#hiit.fi.removethis

– Responsibilities:Customer’s technical advisor

• Jaakko Nyrölä

– Email: jnyrola#cc.hut.fi.removethis

– Responsibilities:Project group’s mentor

• Perttu Marttila

– Email: perttu.marttila#iki.fi.removethis

– Responsibilities:DiMaS project manager

• Markus Mannevaara

– Email: markus.mannevaara#hut.fi.removethis

– Responsibilities:m3Festival project manager

3 Goals and End Criteria

3.1 Goals of the Customer

The goals of the customer and their verification criteria are presented in prioritizedorder in Table 4. Most of the goals are tightly bound to the functionalities of thesystem and are verified by the customer’s technical advisor in the acceptance testmeeting, which takes place during the last iteration of the project.

3.2 Goals of the Project Group

The goals of the project group are presented in Table 5.



Table 4: The main goals of the customer and verification criteria for them.Pri. Goal Verification criteria1 Working final demon-

strationSystem will not fail during the demonstra-tion when used by the demonstration manu-script, demonstration manuscript will be writ-ten so that it is executable in predefined cus-tomer environment, verified in the demonstra-tion session by the customer

2 Easy to use for endusers

Installation is fully automatic (possibly net-work settings are asked from the user), op-erating system is completely hidden from theuser, system can be controlled using the re-mote control

3 System is maintain-able and extendable

System design is modular, all code is welldocumented, technical documentation is ex-tensive

4 Easy to use for an ad-ministrator

Building the installation CD is automated andeasy, system is built on package based distri-bution, system uses centralized configurationfile, system has an extensive documentationon how to build and customize the installationCD

5 All transferred contentis secure

DPs are encoded and proper decryption key isneeded to decrypt them, only DPs signed byDiMaS can be distributed and shown

6 The looks of the UIcan be easily modifiedto make it more ap-pealing

UI uses easily editable templates, presenta-tion is well separated from logic

7 Digi-TV compatibility End user can watch normal DVB broadcast,end user can download DPs from DVB stream

8 Content and metadataintegrates to the P2Pnetwork

DPs are physically distributed in the P2P net-work, metadata of the new DP is propagatedto all peers, DPs can be searched accordingto their metadata, DPs can be transferred be-tween peers

9 User doesn’t see dif-ference between localand remote content

In the content browser it is transparent for theend user to see whether the DP is on local harddrive or in the P2P network

10 Only DiMaS can up-date the metadata ofthe DP

When updated DP is transferred to one peerthe update propagates to all other peers andnew metadata can be found using search



Table 5: The main goals of the project groupPriority Goal

1 To learn to better understand and implement iterative and incremen-tal software development process

2 To deliver a satisfactory product to the customer as well as meet allother customer expectations

3 To learn more controlled and disciplined working practices4 To pass the T-76.115 course with good grades (at least 4)

3.3 Personal Learning Goals

In the following list are presented all personal learning goals of the project group’smembers.

• Antti Halla

– To get an overview of the software project

– To see which working and communication methods work and whichdon’t

– To learn about new technologies

• Jouni Hartikainen

– To learn systematical methods on tracking the ongoing project

– To learn to adjust the process according measured data from it

– To deliver a good product to the customer

• Ilkka Lyytinen

– To learn how a complex SW-project can be handled using more formalengineering methods

• Tuomas Niinimäki

– To learn detection and solving of problems related to communicationand organization of distributed projects and to the customer interface

• Anna-Kaisa Pietiläinen

– To learn good software project practises and to see their possible chal-lenges

– To get familiar with new tools

– To get to know new technologies



• Ilpo Stenberg

– To learn new and interesting technologies

– To see a software process as a whole and to find tools to succeed in it

• Kari Suhonen

– To identify and adopt good QA practises

– To observe how the chosen process and communication & task delega-tion practises suit for the project

– To learn new exciting technologies

3.4 Project Abort Criteria

Project group has an option to abort the project if an event, which makes continu-ing the project radically more demanding and time consuming than originally wasassumed, occurs. The project group must always discuss with the mentor of thegroup and the customer before an abort decision can be made. However, the groupmembers will do the decision. The project can be aborted in following conditions:

• More than one group member leaves the project

• Client doesn’t provide some vital information for the group (e.g. functionalrequirements)

• Client doesn’t provide needed resources to purchase all needed hardware

3.5 Project End Criteria

The project will end when the project group has used all of its budgeted workinghours (total 1330 hours) and group has agreed with the customer to end the project,or on the last course delivery date (15.03.2005), whichever comes first. The projectcan also be ended earlier if the customer considers the project ready.

After the end of the project the members of the project group don’t have any oblig-ations for the project.

4 Resources and Budget

4.1 Personnel

The working budget of the project consists of 190 working hours for each projectgroup member. This gives the project total working hour budget of 1330 hours.



Table 6: Planned working hours per person per iteration.PP * I1 * I2 FD Total

Antti Halla 22 33 90 45 190Jouni Hartikainen 92 44 30 24 190Ilkka Lyytinen 33 51 65 41 190Tuomas Niinimäki 54 37 65 34 190Anna-Kaisa Pietiläinen 45 59 60 26 190Ilpo Stenberg 66 25 65 34 190Kari Suhonen 72 42 40 36 190

Total: 384 291 415 240 1330

Planned hours per person in each iteration are presented in Table 6. Hours areplanned so that persons having more managerial roles (Project Manager & QualityAssurance responsible) have more hours to use in the beginning of the project toassure smooth start for efficient development work in later iterations. On the otherhand persons responsible for development and testing have more time reserved forlater iterations. Hours are also divided unevenly between iterations as can be seenfrom Table 6. The second implementation iteration has much more hours than theother iterations as it is the longest one in calendar time. In addition the Christmasholiday is also located during that iteration and hence there is even more calendartime to spend all the planned working hours. Columns marked with ’*’ representactual realized values.

In addition to the project group, the customer representatives have committed touse as much working hours as needed for the successful project completion. Theproject has also some resources available for demanding graphical work fromHelsinki Polytechnic (Stadia) in the form of a student group. The size and needfor this resource is not yet accurately determined.

Project group’s mentor has also committed to provide support as is required by theT-76.115 course.

4.2 Materials

As the project will be using mostly open source or otherwise freely distributablesoftware there are no special software needs planned for the project. However thisis not the case with hardware used during the project. Because the built prototypewill be constructed from scratch, used hardware needs to be specified and pur-chased in the beginning of the project. Customer (HIIT) has budgeted resourcesto purchase required hardware to construct one prototype unit. Since there will beonly one prototype unit, most of the development work will be done using projectgroup member’s own computers and other hardware. Also version management



repository as well as tools for communication and issue tracking will be runningon computers of the project group members.

In addition to the software and hardware resources, the customer will provide re-sources to broadcast digital TV stream customized for the project using researchtransmitter.

4.3 Budget

In Table 7 is presented a budget calculation of the project. As the project is exe-cuted as a university course the customer is not actually paying for the work doneby the project group and thus the calculations must be considered only indicativeof real costs. However, some costs (namely hardware and customer’s own workinghours) are real costs. These costs are marked with ’*’ in the calculation.

Table 7: Budget calculation for the project.Cost Unit price Amount SumDevelopment team work 80 EUR/hour 1330 hours 106400 EURCustomer’s own work (*) 30 EUR/hour 350 hours 10500 EURHardware (*) 1300 EUR/unit 1 unit 1300 EUR

TOTAL: 118200 EUR

5 Work Practices and Tools

5.1 Practices

Most of the working practises such as quality assurance practises, software engi-neering practises, project reviews, coding conventions, version control and commu-nication and time reporting practises are described in a separate Quality Handbook[3]document.

5.1.1 Iterative Development

The implementation of the product will be done iteratively and incrementally. Inthe beginning of each iteration, the iteration goals and requirements are definedand frozen (see Chapter 5.1.2). This gives stability and space for the developers.The end product of all iterations will be a fully functioning and tested product thatwill have certain predefined functions.

The project consists of four consecutive iterations:



1. Project Planning

2. Implementation 1

3. Implementation 2

4. Finalization and Delivery

A project review will be held in the end of all iterations. The customer, customer’stechnical advisor, mentor and the group will be present in the review. In the reviewthe group will demonstrate the end product of the iteration and get feedback.

5.1.2 Iteration Planning

In the beginning of all iterations an iteration plan is made by the project manager.At least one customer meeting must be held. The group will plan the goals and thedeliverables of the iteration with the customer. The customer must prioritise thefunctionalities that are going to be implemented. The iteration plan will contain adetailed schedule, goals, deliverables and tasks for the iteration. When the plan iscomplete the customer and the mentor will review and accept it. It is estimated thatpreparing of an iteration plan takes two working days (16 hours).

5.1.3 Requirements Management

The requirements are derived from customer needs using an interactive and iter-ative process. The categorization of functional requirements is mainly based onthe ten goals defined by the customer with some additional requirements definedas a by-process of the requirements elicitation. The requirements are linked to usecases, which provide a way to track the progress of functional requirement imple-mentation.

Some of the non-functional requirements address all the defined use cases whileother non-functional requirements are specific only to some of them. There arealso few non-functional requirements with such global effect but which are stillexplicitly included in some use cases to further emphasize their importance on theimplementation of that particular use case.

The customer will formally approve all requirements and use cases to be imple-mented. The approval procedure of requirements and use cases also include theirinitial prioritisation; the actual prioritisation can be changed during the project andwill be one of the aspects addressed in iteration planning process. The statuses andpriorities defined for requirements and use cases are defined in the requirementsspecification document [5].



5.1.4 Risk Management

Risk management practises are defined in the Risk Management Plan[4].

5.1.5 Documenting

Delivery documents are written using LATEXand then converted into PDF format. Adocument template has been prepared and it should always be followed. A deliv-ery document must contain following sections: Cover page, revision history page,TOC, main contents and references page.

Delivery documents should only contain relevant information in clear and com-pact form. Overlappings between documents should be avoided, because it makesmaintenance of the documents harder. Some minor overlappings should be leavedif it helps understandability of a certain document. All delivery documents arewritten in English.

Table 8 presents documents to be delivered. All of them except Risk ManagementPlan, Quality Handbook and Test Plans are required by the course.

Table 8: Documents to be deliveredDeliverable Responsible PersonFinal Report Jouni HartikainenIteration Plans Jouni HartikainenProgress Reports Jouni HartikainenProject Plan Jouni HartikainenQuality Handbook Kari SuhonenRequirements Specification Tuomas NiinimäkiRisk Management Plan Anna-Kaisa PietiläinenSEPA Diaries AllTechnical Specification Tuomas NiinimäkiTest Cases Kari SuhonenTest Plans Kari SuhonenTest Reports Kari SuhonenUser’s Manual Kari Suhonen

In addition a lot of internal documentation is created. Medialiima TWiki will bethe main medium for these documents.

5.2 Tools

Tools used are presented in Table 9. Tool version information can be found fromMedialiima TWiki.



Table 9: ToolsTool Purpose More informationAnt Build manage-

menthttp://ant.apache.org/

Bugzilla Bug-tracking http://www.bugzilla.org/Doxygen API documents

generationhttp://www.doxygen.org/

Eclipse Main develop-ment IDE

http://www.eclipse.org/

LATEX For document-ing

http://www.tug.org/

Subversion Version control http://subversion.tigris.org/TestLink Test manage-

ment toolhttp://sourceforge.net/projects/testlink/

TortoiseSVN Subversionclient

http://tortoisesvn.tigris.org/

Trapoli Time reporting http://valinor.soberit.hut.fi:4288/trapoli_oht/TWiki Web-based col-

laboration plat-form

http://twiki.org/

5.3 Standards

Group has adopted following practises, which are described in ML-QHB [3]:

• Communication practises

• Meeting practises

• Coding conventions

6 Phasing

The HUT T-76.115 course forces all attending project teams to use the softwareproject framework described by the course staff. This framework contains foursucceeding iterations from which two are executed during the autumn term 2004and other two during the spring term 2005. The preliminary plan and schedulefor each iteration is presented in this chapter. Like the main principle of iterativeand incremental development also this schedule will be updated and will get moreprecise as the time goes by.



6.1 Schedule

The conceptual schedule of all iterations in the project is presented in Table 10.The iterations beyond the first two are not yet planned completely and thus thereare no internal deadlines defined yet.

6.2 Project Planning

6.2.1 Goals

Main goals for the Project Planning iteration are concentrated around requirementsspecification and infrastructural activities. Also one important task during the plan-ning iteration is to specify all needed hardware, since the lack of production hard-ware will seriously slow down the first implementation iteration. Here are all goalsfor the project planning iteration:

• Decide roles of the team members

• Plan the whole project at higher level with the customer

• Find out functional requirements for the system to be built

• Get the project infrastructure working

– Communication

– Version management

– Tools

– Meeting practices

– Worktime reporting practices

6.2.2 Deliverables

The most important deliverables of the first iteration are the project plan and therequirements specification documents. These documents are essential for the nextiteration and thus they need to be well finalized. Other planned documents containRisk Management Plan, Quality Handbook and Progress Report. From these threedocuments only the Progress Report is a mandatory document, while the other twodocuments will help the team to improve and manage the project more efficiently.All deliverables and corresponding responsible persons are listed in Table 11.



Table 10: Full iteration schedule for the project.Iteration Date Related events

Project Planning

Tue 12.10. Delivery of iteration plan for PP iterationThu 28.10. All documents ready for reviewMon 01.11. All documents reviewedTue 02.11. Delivery of documents and reportingTue 02.11. Simple and minimal bootable LiveCD readyTue 02.11. Technology prototype of P2P techniques

readyWed 03.11. Project reviewWed 03.11. Customer meeting to plan next iteration

Implementation 1

Tue 09.11. Delivery of iteration plan for I1 iterationTue 09.11. Group meetingSun 21.11. Internal milestone I: Reqs 0101, 0201,

0302, 0504 and 0505 readyTue 23.11. Group meetingThu 25.11. All delivered documents (except progress

report and test log) ready for the internalreview

Fri 26.11. Internal milestone II: Reqs 0107, 0202,0402, 0403, 0404 and 1001 ready

Tue 30.11. Internal milestone III: System tests done. Atleast all found critical and major defectsfixed.

Tue 30.11. Delivery of documents and reportingWed 01.12. Project review

Implementation 2Tue 11.01. Delivery of iteration plan for I2 iterationTue 08.02. Delivery of documents and reportingWed 09.02. Project review

Finalization &Delivery

Tue 15.02. Delivery of iteration plan for FD iterationTue 01.03. Delivery of the final system & documents to

the peer groupTue 08.03. Report the results of the peer testing to the

peer groupTue 15.03. Delivery of documents and reportingWed 16.03. Final demo



Table 11: Deliverables of the Project Planning iteration.Deliverable Responsible PersonProject Plan Jouni HartikainenRequirements SpecificationTuomas NiinimäkiRisk Management Plan Anna-Kaisa PietiläinenQuality Handbook Kari SuhonenProgress Report Jouni Hartikainen

6.2.3 Tasks

All needed tasks to accomplish the goals during the iteration, as well as their re-sponsible persons, are presented in Table 12. The table also contains the informa-tion about the realized hours for the iteration.

6.3 Implementation 1

6.3.1 Goals

Goals for the Implementation 1 iteration are presented in the following list. Thebiggest change to the Project Planning iteration is the strive to decrease the amountof hours spent on project management and instead use these resources to developsomething that is useful for the customer.

• Decrease time spent on project management and concentrate on development

• Design the core software architecture

• Implement most of the digiTV functionality

• Get the framework for customizing the LiveCD working

• Implement the basic P2P networking functionality

• Refine customer requirements

• Order the final hardware

6.3.2 Deliverables

Since the Implementation 1 iteration is the first iteration that contains actual im-plementation effort, the deliverables of the iteration are divided in software com-ponents delivered to the customer and documentation.



Table 12: Tasks of the Project Planning iteration

.

Task Resp. person Est. hours Real. hoursDesign system archi-tecture

Tuomas Niinmäki 20 h 12.5 h

Document reviews All 12 h 16.1 hLecture All 20 h 21.95 hMeetings (customer) All 30 h 29.1 hMeetings (group) All 20 h 23.55 hMeetings (mentor) All 14 h 12.7 hOrganize and preparefor meeting

All 6 h 2.15 h

Personal SEPA All 15 h 14.3 hPlan current iteration Jouni Hartikainen 15 h 15.8 hPlan working methodsand tools

Kari Suhonen 8 h 8.9 h

Prepare for project re-view

All 10 h 3.3 h

Quality assurance Kari Suhonen 20 h 36.6 hRead deliverablesfrom previous courses

Jouni Hartikainen 6 h 4.8 h

Read Wiki All 10 h 10.35 hRequirements analysisTuomas Niinimäksi 30 h 31.6 hRisk management Anna-Kaisa Pietiläinen 20 h 17.5 hSet up working meth-ods and tools

All 15 h 21.30 h

Specify hardware Ilpo Stenberg 25 h 26.6 hSpecify used Linuxdistro

Ilkka Lyytinen 10 h 13 h

Study course material All 6 h 3.1 hStudy digi-TV Ilkka Lyytinen 6 h 2.5 hStudy P2P networks Antti Halla 15 h 8 hStudy working meth-ods and tools

All 25 h 17.2 h

Write meeting minutes Jouni Hartikainen 5 h 2.6 hWrite project plan Jouni Hartikainen 15 h 17 hWrite progress report Jouni Hartikainen 4 h 2.7 hTotal 385 h 383.2 h



During the planning it was estimated that the team would spend 115 hours to directimplementation tasks and additional 18 hours to study technologies directly relatedto implementation work. These estimates were used to define implemented func-tionality for the iteration with the customer. Table 13 presents the functionalitiesto be implemented in prioritised order as well as hour estimates for the implemen-tation work. Working estimates don’t include those 18 hours that are budgeted forstudying used technologies. Numbers in Requirement column refer to functionalrequirements. These are defined and presented in detail in ML-REQ [5].

Table 13: Planned software functionality of the Implementation 1 iteration.Pri Functionality Requirement Estimate1. Implement Main Menu 0201 10 h2. Remove UI from Firefox 0201 7 h3. Integrate DVB-T player 0101, 1001 13 h4. Finish customizable installation CD0302 20 h5. P2P: Join peer group 0504, 0505 7 h6. P2P: Transfer files between peers 0401, 0403 23 h7. Create simplified DP viewer 0202 7 h8. Integrate video player 0107 8 h9. Execute hard-coded search 0402 10 h10. Execute search based on XML DB 0402 10 h

Total 115 h

In addition to the software components presented in Table 13 the documentary pre-sented in Table 14 will be delivered. The process framework of the T-76.115 courserequires all these documents and hence they will be considered as mandatory de-liverables and will override software functionality in priority.

Table 14: Documentary deliverables of the Implementation 1 iteration.Deliverable Responsible PersonTechnical specifiaction Tuomas NiinimäkiTest plan, test cases and test log Kari SuhonenProgress report Jouni HartikainenRevised project plan Jouni HartikainenRevised requirements specificationTuomas NiinimäkiRevised quality handbook Kari SuhonenRevised SEPA diaries AllRevised risk scenarios Anna-Kaisa Pietiläinen



6.3.3 Tasks

Table 15 presents all tasks that are needed to accomplish all goals presented insection 6.3.1. Tasks with prefixes APP, MENU and P2P are pure software imple-mentation tasks. Combined with the integration task ”Finish installation CD” theyform the 115 budgeted implementation hours for the iteration.

6.4 Implementation 2

In the Implementation 2 iteration the main focus is on further developing the basicfunctionality built during the first implementation iteration. Goals are to providemore extended and advanced features such as distributing distribution packages viavarious networks, synchronizing metadata databases between P2P peers and betterdata security. This iteration is planned more carefully during the Implementation 1iteration.

6.5 Finalization and Delivery

During the Finalization and Delivery iteration the main goals are to stabilize thedevelopment and add only some features. Most important goal during the iterationis to succeed in the demo session arranged by HIIT. This iteration is planned indetail during the Implementation 2 iteration.

7 Risk Log

All risk management related issues are covered by the separate Risk ManagementPlan[4].

References

[1] The MIT License, Open Source Initiativehttp://www.opensource.org/licenses/mit-license.php

[2] Website of DVB consortiumhttp://www.dvb.org/

[3] Quality Handbook (ML-QHB)

[4] Risk Management Plan (ML-RISK)

[5] Requirements Specification (ML-REQ)



Table 15: Tasks for the Implementation 1 iterationTask Responsible person Est. hoursAPP: Create simplified DP viewer Ilpo Stenberg 7 hAPP: Integrate DVB-T player Tuomas Niinimäki 13 hAPP: Integrate video player Tuomas Niinimäki 8 hDesign system architecture Tuomas Niinimäki 4 hExecute and report tests Kari Suhonen 10 hFinish installation CD Ilkka Lyytinen 20 hMeeting (customer) All 8 hMeeting (group) All 17 hMeeting (mentor) All 7 hMENU: Main menu servlet Ilpo Stenberg 10 hMENU: Remove UI from Firefox Ilpo Stenberg 7 hOrganize and prepare for meeting Jouni Hartikainen 2 hP2P: Hard-coded content search Anna-Kaisa Pietiläinen 10 hP2P: Join peer group Antti Halla 7 hP2P: Transfer files between peers Antti Halla 23 hP2P: XML DB based content search Anna-Kaisa Pietiläinen 10 hPersonal SEPA All 6 hPlan current iteration Jouni Hartikainen 4 hPlan working methods and tools Jouni Hartikainen 5 hPrepare for project review All 8 hPrepare testing Kari Suhonen 10 hProject review All 7 hQuality assurance Kari Suhonen 8 hReading Wiki All 4 hRequirements analysis Tuomas Niinimäki 4 hReview documents All 3 hRisk management Anna-Kaisa Pietiläinen 2 hSet up working methods and tools All 5 hSpecify hardware Ilpo Stenberg 3 hStudy digi-TV Tuomas Niinimäki 2 hStudy P2P networks Anna-Kaisa Pietiläinen 8 hStudy working methods and tools Jouni Hartikainen 5 hUpdate project plan Jouni Hartikainen 3 hWrite meeting minutes Jouni Hartikainen 3 hWrite technical specification Tuomas Niinimäki 8 hWrite test cases Kari Suhonen 5 hWrite test plan Kari Suhonen 10 hTotal 276 h
