University of Joensuu Department of Computer Science Remote Controlled Digital tv software Development Project Plan Version: 0




Yüklə 54.76 Kb.
tarix28.04.2016
ölçüsü54.76 Kb.


University of Joensuu

Department of Computer Science

Remote Controlled Digital TV Software Development Project Plan


Version: 1.0

04 November 2005

Created by:

Anahit Pogosova Bablo Rios Barriuso

Project manage r Team member

Table Of Contents:

1. INTRODUCTION 4

1.1 Project Overview 4

2. REFERENCES AND GLOSSARY 4

2.1 Reference Material 4

2.2 Definitions and Acronyms 5

3. PROJECT RESULTS 5

3.1 Project Goals and results 5

3.2 Deliverables 6

4. PROJECT ORGANIZATION 6

4.1 Stakeholders 6

5. PROJECT PHASES 7

5.1 Phases 7

5.2 Created Product 7

6. WORK BREAKDOWN 7

6.1 Organizational Structure 7

6.2 Schedule 9

7. WORK METHODS 10

7.1 Process Model 10

7.2 PP Evaluation 10

8. RESOURSES 10

8.1 Required Hardware 10

8.2 Required Software 10

9. MONITORING PROGRESS 11

9.1 Methods 11

10. RISKS 11

10.1 Main Risks 11

10.2 Risk Table 12



10.3 Keywords & Comments 12

11. ACKNOWLAGEMENTS 13

Appendix 1 – Change History 14

14



Appendix 2 – Meeting Notes 15


1. INTRODUCTION

1.1 Project Overview

Digital technology provides a more efficient way to deliver television than with analogue transmissions. It enables the same services to be delivered in less space with greater clarity.

Digital TV provides the support to Interactive Television (iTV), like applications and programming that allow the viewer to control content delivered with and through the television.

Interactive applications include: iTV-enabled entertainment and informational programming, iTV-enabled personalized advertising, interactive program guides (IPG), video on demand (VOD), personal video recording (PVR), iTV-enabled video games, t-commerce, and iTV-delivered Internet content (web, email, chat, SMS).


Remote control is in charge of receiving orders from the user and send it to the TV digital system infrared interpreter so the orders can be executed.

2. REFERENCES AND GLOSSARY

2.1 Reference Material

Some documentation that is going to be used during the development of the project is listed below:



  • http://cs.joensuu.fi/pages/parkkinen/IMPIT/seminar/Links.htm Useful links for mobile and DigiTV programming

  • http://java.sun.com/products/javatv/index.jsp Java TV API

  • http://java.sun.com/developer/technicalArticles/javatv/apiintro/index.html Introduction to Digital TV Applications Programming

  • http://www.popsci.com/popsci/computerselec/7ef9d4d03cb84010vgnvcm1000004eecbccdrcrd/3.html The PC-Based Tivo Emulator

  • www.lirc.org LIRC - Linux Infrared Remote Control

  • http://www.itvalliance.org Interactive TV Alliance

  • IEEE Standard for Project Management Plans, ANSI/IEEE Standard 1058/1998

  • Software Engineering by Roger S. Pressman


2.2 Definitions and Acronyms

The following is a list of definitions, acronyms and abbreviations used in this document:


DTV Digital TV

RC Remote Control

PP Project Plan

TA Technical Assistant

3. PROJECT RESULTS




3.1 Project Goals and results

The primary goal of the project is to pass the “IMPIT Seminar” course successfully. The aim of the project is to develop remote controlled digital DTV software to the customer. The idea is to develop some tools to use remote control with a DTV.

As a final product it is supposed to get working software, which implements the communication between infrared receiver and DTV emulator. One of the milestones of this software is the user interface that is going to be designed, which must be easy enough to use, in order to be applied by people, who don’t have any notion of computers (the developed software would be tested in elderly audience).

This project does not suppose that students have enough programming skills in Java and in Java TV API therefore the software engineering domain’s ideas will at first prevail ones from application




3.2 Deliverables

It’s supposed to have the following documentation: Project plan; Interface description; Implementation plan; Project binder.

Documents must be delivered to the room 180 by the time mentioned in the schedule chapter of the project plan. The delivery of any additional papers must be adjusted with University of Joensuu teaching personal.

4. PROJECT ORGANIZATION

4.1 Stakeholders

The considered project supposes the participation of two sides: customer and supplier. The customer side is represented by


Markku Tukiainen (Markku.Tukiainen@cs.joensuu.fi)
The supplier is the team, consisting of

Anahit Pogosova (apoghoso@cs.joensuu.fi)

and


Pablo Rios Barriuso (pablorb1984@hotmail.com).
Anahit Pogosova is plenipotentiary of supplier’s side in all questions concerning this project.

Project does not suppose participations of some other persons except (TA)



Jyri Keränen (jyri.keranen@cs.joensuu.fi),
who can substitute Markku in case of emergency. But all other people are always welcome to join.

5. PROJECT PHASES

5.1 Phases

The project consists of following phases:




  • Studying DTV and RC main aspects;

  • Studying Java TV API, Xlets

  • Studying LIRC

  • Exploring the available DTV emulator and relative hardware

  • Interface design

  • Implementation

  • Testing (including testing with a test group)


5.2 Created Product

After last 3 phases there supposed to be a corresponding “product”. After finishing the interface design phase the Interface Description document must be finalized. In the scope of the implementatiopn phase an Implementation Plan should be created. After finishing the phase there must be an intermedeiate version of the software, that complies with the customer’s demand. After compleating the last phase (testing), a final version ot the software should be created, and also the Project Binder should be accomplished.

All created documents must be delivered as it is stated in the Deliverables chapter of the project plan.

6. WORK BREAKDOWN

6.1 Organizational Structure

In the table below the roles of each team member are specified and described.





Role

Individual(s)

Description

Project Manager


Anahit Pogosova

1. Performs overall supervision of the project

2. Is responsible for the project as a whole

3. Maintains project plan

4. Delegates requirements gathering to the requirements engineer(s).

5. Performs implementation

6. Arbitrates problems as they occur

7. Member of the Software Development Group


Technical Writer

Pablo Rios Barriuso

1. Oversees and maintains documentation

2. Takes meeting minutes and meeting documentation

3. Acts as the configuration management expert

4. Member of the Software Development Group




Requirements Engineers

Anahit Pogosova
Pablo Rios Barriuso

1. Leads requirements gathering efforts

2. Communicates with stakeholders, clients, end-users

3. Conducts interviews with stakeholders

4. Acts as interface to the customer

5. Documents requirements as well as policies elicited

6. Member of the Software Development Group




Software Development Group


Anahit Pogosova
Pablo Rios Barriuso

1. Performs the implementation of the specific part of the system

2. Write the documentation for designed software



Tester

Pablo Rios Barriuso

1. Performs the application testing

2. Insurances program expected behavior



6.2 Schedule

Project started on September 23. The last date is May 16, 2006. The project has to be done up to this date.

The preliminary time schedule for the project (deliverable deadlines and project phases’ deadlines) is given below. All the changes in the schedule will be fixed in the project plan as it’s stated in the PP Evaluation chapter.
Deliverables:

November 4, 14-00 .. .…… .…….……………………………….. Project Plan

December 16, 14-00 . .……… .…… .………………… .. Interface Description

February 20, 14-00 ...…………………… .…… .……… Implementation Plan

April 28, 14-00 …………………………………….…….……. Project Binder

Phases:
November 4 ……….…………………… Studying DTV and RC main aspects

November 20 ……….… .……… .…… ………………………Studying LIRC

December 16 ………… . . .……… .…… .………………… .. Interface design

January 20 …… ....… .…… .………………… .. Exploring the DTV emulator

February 20…………… ……………… .… …… Studying Java TV API, Xlets

April 10 ………… …… …………… ……………… .… …… Implementation

April 28 …………………………………………………….…….……. Testing

7. WORK METHODS



7.1 Process Model

The software development model we plan to follow for the development process is the waterfall model. This model is one of the most suitable for small software projects.



7.2 PP Evaluation

The PP will be revised once a week or each time after new data about the time spent on the project will be available. The change history would be reflected in the Appendix 1 of the project plan. All changes would be made only with the agreement of whole team. Changes concerning the deadlines must be also adjusted with the customers.



8. RESOURSES



8.1 Required Hardware

Minimal requirements are as follows:




  • IBM PC compatible 1,3GHz

  • 500 MB RAM

  • 40 GB HDD

  • Video Card with TV output

  • TV monitor


8.2 Required Software





  • Digital TV emulator

  • MS-Windows 2000/NT/XP

  • Eclipse

  • Java Virtual Machine


9. MONITORING PROGRESS



9.1 Methods




All the weekly activities will be published in the special Diary. In the end of each week it’s going to be examined by the appropriate team member and compared with the project plan to see, what results actually have been achieved. The summary will be multicasted be e-mail to all team members.


Also there would be meetings of the team members. Exact date and time of that meetings will be announced 2 business days prior the selected date. Information about the meeting would also be multicasted by the e-mail or via mobile phone to all members of the team.

Meetings can be arrange ether in real, or in virtual, using the Skype messenger.

After each meeting a record will be made by an appropriate team member in the Appendix 2 of the PP.

10. RISKS



10.1 Main Risks

Main risks we have determined for this project are as follows:




  • Equipment failure

  • Late delivery of software

  • Changes in requirements

  • Staff diseases

  • Staff incompetence

  • Resource risk

  • Elks factor1


10.2 Risk Table





Risks

Probability

Impact

Equipment failure

30%

Very High

Late delivery of software

45%

Low

Changes in requirements

10%

High

Staff diseases

50%

High

Staff incompetence

20%

High

Resource risk

30%

High

Elks factor

5%

Very High

10.3 Keywords & Comments

Keywords for risks:



Very High – risk entails irreversible consequences.

High – risk entails serious consequences, which will take lots of time to overcome.

Low – risk entails consequences which can be overcome in 1 day.


11. ACKNOWLAGEMENTS



Appendix 1 – Change History


04.11.2005 – Initial version created

Appendix 2 – Meeting Notes



02.11.05: Team meeting; discussion about the project plan;

03.11.05: Team meeting; discussion about the project plan;

03.11.05 : meeting with customers; the task was strictly defined and explained.

Some hints for the solution where given.



1 By the Elks factor we mean that huge quantity of elks will go on the roads and completely stop the traffic



Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azrefs.org 2016
rəhbərliyinə müraciət

    Ana səhifə