% .tex file for typesetting project plan document.

% Document's class. File projdoc is used in this project.
\documentclass[twoside]{projdoc}

% Project name.
\project{Muksis project}

% Confidentiality: Use public or confidential.
\publicity{Public}

% Version number.
\version{0.7}

% Document name.
\title{Project plan}

% Authors: Note alphabethical order by last name.
\author{Richard Domander}{Tuomas M�enp��}{Teemu Nisu}{Tommi Teistel�}
% Phone numbers. Same order as in authors.
\authorphones{050-3482668}{040-7600465}{040-8349310}{045-6528709}
% E-mail. Same order as before.
\authoremails{dimadoma@jyu.fi}{tutamaen@jyu.fi}{tejonisu@jyu.fi}{totateis@jyu.fi}
% Initials. Same order as before.
\authorinitials{RD}{TM}{TN}{TT}

% Abstarct of the document
\docabstract{This is the project plan document of software project Muksis. The document introduces readers to the area of this project by explaining terms and giving background information, as well as describing goals, available resources and management methods. In the later part of the plan information about tasks, schedule and risks are given.} 

% Abstract of the project
\projectabstract{Project Muksis designs and implements new features, like black frame detection, support for DVB, subtitles, and search in MPEG TS, to an open source media player application MPlayer for Matthieu Weber. There is also an option to improve similar existing features to meet the requirements.}

% Keywords: alphabethical order, remember caption at first word and dot to the end.
\keywords{Software project, black frame detecting, DVB, MPEG, search in MPEG TS, Muksis, MPlayer.}

% The actual document starts here
\begin{document}

% This typesets the version history.
\versionhistory

\begin{tabular}{|c|r|p{7cm}|p{3.5cm}|}
\hline
Version & Date & Changes & Authors \\
\hline \hline
0.1    &  19.9.2008  & First version. Introduction and contact information started. & TM\\
\hline
0.2    &  28.9.2008  & Introduction written. Terms, background, project goals and resources started. & TM\\
\hline
0.3    &  29.9.2008  & Resources written. & RD\\
\hline
0.4    &  3.10.2008  & Management methods started. Tasks, workload, division of labour, project goals and risks written. & TM, TT, TN\\
\hline
0.5   &  8.10.2008  & Management methods written. Schedule started. & TM\\
\hline
0.6   &  10.10.2008  & Corrections made for chapters. & TM\\
\hline
0.7   &  15.10.2008  & Corrections for Risks chapter. & TN\\
\hline


\end{tabular}

%Typesetts information about the project.
\projectinfo

\textbf{Customer:}

\begin{tabular}{p{6cm}p{5cm}p{3cm}}
~~~$\bullet$~~Matthieu Weber & \texttt{mweber@mit.jyu.fi} & 014-2603065 \\
\end{tabular}

\vspace{1truecm}
\textbf{Supervisors:}

\begin{tabular}{p{6cm}p{5cm}p{3cm}}
~~~$\bullet$~~Ville Isom�tt�nen & \texttt{vilisom@cc.jyu.fi} & 014-2604976 \\
\end{tabular}

\vspace{1truecm}
\textbf{Contact information:}

\begin{tabular}{p{6cm}p{9cm}}
~~~$\bullet$~~Mailing lists: & \texttt{muksis@korppi.jyu.fi} \\  
		                 
~~~$\bullet$~~Archives: & \texttt{https://korppi.jyu.fi/kotka/servlet/} \\
																	& \texttt{list-archive/muksis/} \\ 
                                     
~~~$\bullet$~~Room: & AgC 225.3 / 014-2604971
\end{tabular}

% \mainmatter typesetts automatically contents and first chapter.
\mainmatter

\chapter{Introduction} \label{chap:introduction}

Muksis is a student software project in the Department of Mathematical Information Technology at the University of Jyv�skyl�. During the fall 2008 and the beginning of the year 2009 the project designs and implements new features to an open source media player application MPlayer. The main new features are black frame detection, support for DVB subtitles, and seek function to skip commercials based on black frame locations. The project team has an option to improve similar existing features possibly found in original MPlayer code or patches written by project client. The software is made for Matthieu Weber who is a senior assistant in the Department of Mathematical Information Technology at the University of Jyv�skyl�.

MPlayer is a free open source media player distributed under the GNU General Public License. It is a command line application with different optional graphical user interfaces. The program supports all major operating systems, including Linux and other Unix-like systems, Microsoft Windows, and Mac OS X. MPlayer has support for a variety of media formats. In addition to its generous range of supported formats MPlayer can also save all streamed content to a file. 

The project will be performed in a team of four students: Richard Domander, Tuomas M�enp��, Teemu Nisu and Tommi Teistel�. All members except Tuomas M�enp�� have a good knowledge of programming language C. Tommi Teistel� is also familiar with the MPlayer source code. Tuomas M�enp�� has mostly done web based software development before the project.

This document is an introduction to the work flow of the project Muksis. In Chapter \ref{chap:terms} the main terms used in the document are explained. Chapter \ref{chap:background} expounds background information and chapter \ref{chap:goals} outlines the main goals. Chapter \ref{chap:resources} analyzes available resources, chapter \ref{chap:schedule and process} explains the process model, and schedule and  chapter \ref{chap:management} describes project management methods,introduces tasks, workload, division of labour, etc. The risks involved in the project are finally described in chapter \ref{chap:risks}.


\chapter{Terms} \label{chap:terms}
Following terms appear in this document:

\begin{Ventry}{Agile software development}
\item[Agile software development] a software development process. Agile methods emphasize real-time communication and working software as the primary measure of progress using iterative development.
\item[Software project] course on The Department of Mathematical Information Technology.
\item[C] a general-purpose, high-level programming language. 
\item[DVB] Digital Video Broadcasting, a set of open standards for digital television. Defines various details about the physical and data link layer-level transmission of data, refers to existing MPEG standards for the actual format specifications where possible. The data stream itself is an MPEG-2 Transport Stream with some DVB-specific constraints and may contain multiple channels. 
\item[Iterative development] technique of developing and delivering incremental components of business functionality. A single iteration results in one or more bite-sized but complete packages of project work that can perform some tangible business function. Multiple iterations recurse to create a fully integrated product. 
\item[MPEG] The Motion Picture Experts Group, a working group of ISO/IEC. Also a common name for certain standards created by them. 
\item[MPEG-2] The MPEG standard specifying video, audio and related format specifications, primarily used for DVDs and digital television broadcasting. 
\item[MPEG TS] is a MPEG transport stream. It is a communication protocol for audio, video and data. It's goal is to allow multiplexing of digital video and audio and to synchronize the output.
\item[patch] is a small piece of software designed to fix problems with or update a computer program. This includes fixing bugs, replacing or adding features and improving the usability or performance.
\item[OSS] open source software, a computer software, which source code is made available under a copyright license or arrangement. This permits users to use, change, and improve the software, and to redistribute it in modified or unmodified form.
\item[SVN] Subversion is a free version control system. It is used to maintain current and historical versions of files such as source code. 
\end{Ventry}


\chapter{Background} \label{chap:background}

The MPlayer project was started in 2000 by a group of programmers from Hungary who were unsatisfied with the video players available for Linux at the time. They were soon joined by others and the open source project has been (slowly) advancing towards a 1.0 release since then. The player is written in the C language and is noted for its command line interface and support for a large number of different media formats and video output methods. A media encoding application called MEncoder is built on the same codebase and can encode video and audio into many different formats.[1] 

Finnish television broadcasting migrated to the DVB - Digital Video Broadcasting standard in 2007. The current MPlayer code does not have support for its "soft" subtitling (subtitles which are separate from the video images) feature, which is used by some Finnish broadcasters, notably the national broadcasting company YLE.

Patches that add the primary features was previously created by Matthieu Weber, but the continued development of MPlayer has left these incompatible with the MPlayer source code. The features can thus be implemented either from scratch or by adapting the previous patches' code to work in the current MPlayer source.

It is a known fact that MPlayer's documentation and coding is not done in the best way. This adds more challange for the team to understand the structure and functions of the application. Research in general is one major ensemble that will take most of time at the first iterations of the project.

There are several versions of the MPlayer code available. The team decided to use the stable v1.0rc2 version of the source code instead of the SVN version, since the code might change too much during the project causing severe impacts to the project schedule.

\chapter{Project goals} \label{chap:goals}
\section{Software}
The project's primary goal is to produce a patch for the latest stable version of MPlayer (MPlayer-1.0rc2) that adds various features:
\begin{itemize}
\item Support for DVB subtitling, at least for the type used by YLE. Other similar formats may be considered additional goals if time can be spared to implement them.
\item A black frame detection filter that can be used to identify potential commercial breaks in a TV broadcast by counting the number of frames considered black (actual zero luminance is uncommon in MPEG video due to the ITU-R Recommendation BT.601, which effectively limits 8-bit luminance values to a range of [16,235] for compatibility with legacy equipment). The MPEG timestamps of the detected commercial breaks will be written to a file.
\item Improved accuracy for seeking in a stored MPEG Transport Stream, the media container format used for digital television broadcasting. This will require changes to the MPlayer MPEG TS demuxing code. With some additional code and the output of the black frame detection filter, this can be used to make MPlayer automatically (and accurately) skip commercial breaks in a TV recording.
\end{itemize}


Some of the features may be of interest to the MPlayer community; creating and submitting a patch that adds these to the current SVN version of MPlayer could be considered an additional goal.

\section{Documentation}
Besides the software itself, the project will produce a number of documents related to its development. All documents will be written in English, except the ones created for the related course, which will be in Finnish. After the  project these will be collected in a folder for reference in the university's future software projects. These include (in chronological order):
\begin{itemize}
\item \textbf{GPL agreement} contract on licensing the source code and the software under General Public License.
\item \textbf{Project plan}, which introduces the project, its background and goals, and describes its overall management; the schedule, the tasks, how they are divided and what risks the project may face.
\item \textbf{Architecture plan}, which explains the overall structure of the MPlayer software, or at least the parts related to the project's goals.
\item \textbf{Test plan \& report} shortly outlines the testing strategy, the test cases, and report on the test results. 
\item \textbf{The application report}, which describes how the new features work.
\item \textbf{Project report} will be written at the end of the project to analyze and summarize the project progress.
\item \textbf{Project presentation reports} (esittelyraportit) for the related course.
\item \textbf{Meeting agendas, minutes} and related materials.
\item \textbf{Project's e-mail list archive} in printed form.
\item \textbf{Source code} a print out of the code written by project team.
\end{itemize}

The software patches and the documentation are also written in a CD, which is delivered to the university and to the client. One additional CD is filed in the department's archive.

\section{Learning goals}
The project's participants will gain useful experience in teamwork and working with an open source project and its codebase and (hopefully) some communication skills.  There are various aspects in managing a software project and every team members should have a chance to learn about them.

Richard wants to refresh his knowledge of C, and learn to understand and work with a large existing (and in this case, challenging) code base. He is also interested to see a process in action in a real project. Richard believes that he will learn to understands why processes and the tasks
related to them are so useful. 

Teemu is interested in open source software, and wants to learn more about participating in an OSS project. He is also looking forward trying out agile software development methods in practice and getting experience of software projects in general. He is quite familiar with object oriented programming, and is excited about confronting older programming paradigms involved in the project. 

Tommi is interested in open source development and wants to learn more about working with code originally written by others. 

Tuomas has interests in project managing and wants to learn about the management methods. He is also looking forward trying out agile software development methods and to understand programming language C better.


\chapter{Resources} \label{chap:resources}

This chapter describes the available resources for project Muksis.

\section{Recource constraints}
One ECTS credit (op, opintopiste) equals about 27 hours of work [2], so a student can expect to work between 270 and 400 hours for the project (10-15 op for the course). The team members don't have many other courses simultaneously, so it won't be challenge for anyone to allocate the required time. If the allocated time is not enough the features will be at least partially implemented, because of the iterative process used in this project. 

\section{The team}
The team consists of four mathematical information technology majors. The supervisors tried to form as heterogeneous team as possible from the course applicants. Still, all members meet the requirements set for the course, and this fall all selected were quite advanced in their studies.  

\section{Physical resources}
The project team has been given the room AgC225.3 inside the project space AgC223.1. In the room there are four computers (1/member), office supplies and white boards. The team can also use the project space, but a reservation has to be made beforehand. The printer in project space and MIT department's copier can be used for project documents. Also a small "library" of technical books is available, but most of the technical documents needed is provided by the client, Matthieu Weber. 

The team can request further software installations and resources (for example, Trac) from MIT's PC support. Team members are not allowed to install programs. The team chose Linux and CodeBlocks IDE, but kept one Windows machine just in case. The team can also get a projector and a digital audio recorder for the meetings. 

\section{Supervisors}

The supervisor in charge is Ville Isom�tt�nen from MIT. He supervises all aspects of the project and especially its planning, process, management, and general state. He also acts as a sort of mediator between the client and the team. There currently is no technical supervisor for the project, but everyone in the team has some experience with C. Linux OS and CodeBlocks IDE are familiar too for most of the members, so they can instruct those less versed. Weber has specific technical knowledge about the 
subject, so the team will cope even if no technical supervisor is found, although lack of one presents unique risks.


\chapter{Process and schedule}\label{chap:schedule and process}

This chapter explains the process and schedule of project Muksis.

\section{Process model}
The project is carried out using an agile process model. This model uses multiple sequential iterations that have duration of two weeks. The beginning phase is called 0-iteration, in which the topic of the project, workspace and personnel are introduced. 0-iteration acts as a start-up and orientation phase with no software implementation. After this, iterations are performed in two-week cycles.

Each iteration aims to build further the product made in previous iteration. This ensures that the project is progressing steadily, and participants get to monitor the results as soon as possible. Short iteration intervals also help reacting faster to the changes and preditct better the output.

\section{Schedule}

Well planned schedule is essential for a software project. Because of the agile process model, a timetable is planned for every iteration. At first only an overview for each iteration is written in the start-up phase. The final schedule for the next iteration is planned at the end of each two-week cycle.

\subsection{Iteration schedules}

The release plan in presented in the Figure \ref{tab: release plan} and explains the major goals for each iteration. The first day of new iteration is the next day after the official meeting between iterations. The project encompasses a 2-week 0-iteration and five iterations, which is 12 weeks in total.

\subsection{Iteration steps}
All implementations are decided iteration-by-itreation. In the meeting at the end of the iteration project team reviews the priorities of the tasks and requirements with the customer and decides which tasks the team does next. After the meeting, in the internal meeting of project team, the persons in charge are nominated for the tasks and time usage estimated. Previous schedules can be used to more precisely evaluate this. During the iteration the software is produced with a typical design-implement-test sequence.

\begin{table}[ht]
\begin{center}
\begin{tabular}[t]{|r|l|p{9,5cm}|}
    \hline
    \textbf{Iteration}  & \textbf{Duration} & \textbf{Most important tasks} \\
    \hline
    \hline
    \textbf{0} & 2 weeks & Introduction to the subject, research and beginning of the project plan. \\
    \hline
    \textbf{1} & 2 weeks & Black frame detection's implementation, completing project plan, research of seek function and dividing it's implementation to tasks.  \\
    \hline
    \textbf{2} & 2 weeks & Seek function's implementation and starting to implement DVB subtitles, writing architecture plan. DVB subtitle implementation, writing application report and testing.\\
    \hline
    \textbf{3} & 2 weeks & More testing and writing test report. \\
    \hline
    \textbf{4} & 2 weeks & Writing project report. \\
    \hline
    \textbf{5} & 2 weeks & Ending project. \\
    \hline


\end{tabular}
\end{center}
\caption{Release plan of the iterations.}\label{tab: release plan}
\end{table}


\chapter{Management methods} \label{chap:management}

This chapter describes management methods of project Muksis.

\section{Meetings}
An official meeting is held between every iteration with all participants of project Muksis. Before the meeting project team plans and prepares the material, which includes a proposal on the next iteration's requirements and explains how working time was distributed in the previous iteration. In the beginning of a meeting the previous iteration is reviewed, then goals for the future iteration are decided. The goals mean the parts of software to be implemented and the documents to be written during next two weeks. The chairman of the meeting brings and sets up needed equipment to the meeting room and opens the session. The secretary prepares agenda to the meeting and takes notes during session. After the meeting he writes a report called minutes, which reviews the main items discussed and any decisions that were made. All material is to be delivered two work days before the meeting, agenda one day before and the minutes at maximum three days after the meeting.

\section{Communication}\label{communication}
Communication is held up with e-mail list \texttt{muksis@korppi.jyu.fi}. Unofficial meetings are held at least once per week if there are no official meetings. Project supervisors have also delivered the contact informations to every participants. Most of the team's internal communication is maintained with informing meetings at the team's office. An e-mail list \texttt{muksismafia.group@korppi.jyu.fi} is also established and used in internal communication. The project manager has the responsibility to act as a mediator between the team and the rest of the participants and to monitor communication's sufficiency. 

\section{Task management}
The example of the task proposal the team presents for the meeting is given in table \ref{tab: 1 tasks}. After meetings, the team plans together how the selected part of the software will be implement by dividing work to tasks using office room's white boards. These tasks might already be presented in the meeting, when there is only a need to write them down to the white board. The description of the task is written to the one column in the white board and to another the estimated time for accomplishing the task. The names of team members who will participate the task are also written to the board. The presentage estimation of task progress is written to the last column during the iteration.

\section{Time logging}
Time usage of every iteration is written on excel document. All work hours of the team members are written to the excel table by sorting them using task abstraction. The time used in the peripheral course is also written down to the same excel table. In the beginning of iteration project team evaluates the estimated time needed to accomplish each task. This means that team must have internal meetings during this phase to divide tasks and to estimate the time requirement. In the end of iteration the table show how well the plan held during the iteration, and this helps to compose even more realistic approximations during the project.

\begin{table}[ht]
\begin{center}
\begin{tabular}{|l|c|c|c|c|c|}
    \hline
    Task  & Richard & Teemu & Tommi & Tuomas & Summary (h)\\
    \hline
    \hline
    \textbf{Project management} & \textbf{9} & \textbf{9} & \textbf{9} & \textbf{17} & \textbf{44} \\
    \hline
    \hspace{0.1cm} Informing & 2 & 2 & 2 & 2 & 8 \\
    \hline
    \hspace{0.1cm} Project plan & 2 & 2 & 2 & 6 & 12 \\
    \hline
    \hspace{0.1cm} Project planning & 1 & 1 & 1 & 4 & 7 \\
    \hline
    \hspace{0.1cm} Schedule managing & 1 &1 & 1 & 2 & 5 \\
    \hline
    \hspace{0.1cm} SVN & 2 & 2 & 2 & 2 & 2 \\
    \hline
    \hspace{0.1cm} Trac \& WWW & 1 & 1 & 1 & 1 & 4 \\
    \hline
    \textbf{Meetings} & \textbf{4} & \textbf{4} & \textbf{4} & \textbf{7} & \textbf{19} \\
    \hline
    \hspace{0.1cm} Agenda \& preparation & 1 & 1 & 1 & 1 & 4 \\
    \hline
    \hspace{0.1cm} Meetings & 3 & 3 & 3 & 3 & 12 \\
    \hline
    \hspace{0.1cm} Minutes & 0 & 0 & 0 & 0 & 3 \\
    \hline
    \textbf{Research} & \textbf{9} & \textbf{9} & \textbf{9} & \textbf{14} & \textbf{41} \\
    \hline
    \hspace{0.1cm} Functions of old MPlayer & 2 & 2 & 2 & 2 & 8 \\
    \hline
    \hspace{0.1cm} MPlayer code \& specs & 5 & 5 & 5 & 5 & 20 \\
    \hline
    \hspace{0.1cm} Running TV records with MPlayer & 0 & 0 & 0 & 0 & 5 \\
    \hline
    \hspace{0.1cm} Research patch & 2 & 2 & 2 & 2 & 8 \\
    \hline
    \textbf{Peripheral course} & \textbf{6} & \textbf{6} & \textbf{6} & \textbf{6} & \textbf{24} \\
    \hline
    \hspace{0.1cm} Lectures & 5 & 5 & 5 & 5 & 20 \\
    \hline
    \hspace{0.1cm} Group work & 1 & 1 & 1 & 1 & 4 \\
    \hline
    \textbf{Implementation} & \textbf{17} & \textbf{17} & \textbf{17} & \textbf{4} & \textbf{55} \\
    \hline
    \hspace{0.1cm} Changing existing bf code  & 2 & 2 & 15 & 2 & 21 \\
    \hline
    \hspace{0.1cm} Trying Matthieu's bf code & 15 & 15 & 2 & 2 & 34 \\
    \hline
    \textbf{Total hours} & \textbf{45} & \textbf{45} & \textbf{45} & \textbf{48} & \textbf{183} \\
    \hline
\end{tabular}
\end{center}
\caption{Task division and time estimation for iteration 1.}\label{tab: 1 tasks}
\end{table}

\section{Responsibilities}
To make project easier to accomplish all work is managed with a set of responsibilities. A team member is named for each responsibility. This is presented in the Table \ref{tab: responsibilities}. Peripheral course's lectures, group works and presentations are handled as a separate responsibility belonging to all team members.

A responsibility means that a team member is selected to be a person in charge for the area of responsibility. The person in charge monitors the progression of the area but doesn't necessarily complete the selected tasks by himself. The responsibilities will be taken into account when the tasks are assigned to the team members.

\begin{table}[ht]
\begin{center}
\begin{tabular}[t]{|l|l|}
    \hline
    Area of responsibility  & Person in charge \\
    \hline
    \textbf{Project management} & Tuomas \\
    \hline
     \textbf{Research} & Tommi \\
    \hline
    \textbf{WWW} & Richard \\
    \hline
    \textbf{DVB} & Richard \\
    \hline
    \textbf{BFD} & Teemu \\
    \hline
    \textbf{MPEG TS} & Tommi \\
    \hline
    \textbf{documenting code} & Teemu \\
    \hline
    \textbf{uniforming code} & Richard \\
    \hline
    \textbf{finalising code} & Tommi \\
    \hline
    \textbf{testing} & Tuomas \\
    \hline
    \textbf{Trac} & Tuomas \\
    \hline
    \textbf{Project folder} & Teemu \\
    \hline
    \textbf{SVN} & Tuomas \\
    \hline

\end{tabular}
\end{center}
\caption{Areas of responsibilities.}\label{tab: responsibilities}
\end{table}

\section{Documentation}
Documents are typesetted with \LaTeXe typesetting software using department's document templates and named with format \texttt{document\_name-version.pdf}. All documents are published in a PDF format and  stored in the public project space created to the network of the university of Jyv�skyl�, and are available for all. At the end of project these files will be burned on CD-r media and placed to the project folder. In addition, meeting agendas and minutes are stored to the project management application named Trac, where they are easily editable and accessible for all participants. All complete plans and reports are signed by the customer, the project manager and the supervisor.

\section{Version management}
The team uses Subversion for version management. A branch is created for every main feature to be sure code tweaking doesn't affect other members implementing different features. Every document with a version number is named as \texttt{document\_name-a.b}, where a is the first number of version with only values of 0 or 1. b is the second number of version and is an integer starting from 1. In example after version number 0.9 comes 0.10 not 1.0. The number 1.0 indicates that the document is complete.

\chapter{Risks} \label{chap:risks}
Many things can prevent a software project from succeeding. This section is about evaluating risks related to this project and considering how to avoid them. Risks are defined in Table \ref{tab: Risks of the project}. Probabilities and effects of each risk are evaluated on a scale of low-intermediate-high.
\begin{table}[ht]
\begin{center}
\begin{tabular}[t]{|l|l|l|}
    \hline
    \textbf{Risk}  & \textbf{Probability} & \textbf{Effect} \\
    \hline
    \hline
    Client's availability & Low & High \\
    \hline
    Supervision & Intermediate & Intermediate \\
    \hline
    Inability to participate & Low & High \\
    \hline
    Human relationships & Low & High \\
    \hline
    Inexperience & High & Intermediate \\
    \hline
    Programming skills & Low & High \\
    \hline
    Scheduling & Intermediate & Intermediate \\
    \hline
    Communication & Intermediate & High \\
    \hline
    Language & Intermediate & Low \\
    \hline
    MPlayer development & Low & Intermediate \\
    \hline
    Applications & High & Intermediate \\
    \hline
\end{tabular}
\end{center}
\caption{Risks of the project.}\label{tab: Risks of the project}
\end{table}

\section{Client's availability}
The resulting software will be mostly for personal use, so the client has a great importance for the project. In this case, the client is also the participant with the most knowledge about technical details of the subject. For these reasons the progress of the project may slow down if the team is not able to contact the client at some point.

\textbf{Anticipating:} Meeting times should be settled early enough.

\textbf{Tracking:} The team should be in contact with the client frequently. Tracking the response times helps the team to keep up with the situation.

\textbf{Reacting:} If the client is prevented from participating to the supervision of the project, the team should try to proceed on their own on the basis of what has been agreed previously.

\section{Supervision}
The supervisor might not always be able to give instructions in short-term. Also the subject is very technical, and a technical supervisor has not been found.

\textbf{Anticipating:} Meeting times should be settled early enough.

\textbf{Tracking:} Keep contact with the supervisor by e-mail or telephone.

\textbf{Reacting:} Ask the project supervisor to find someone to brief the team if technical difficulties arise.

\section{Inability to participate}
Obstacles such as vacations, social matters or illness may turn up to prevent some team members from participating in the project.

\textbf{Anticipating:} Inform the other team members in advance about vacations. Share tasks equally within team members.

\textbf{Tracking:} Communication within team members is essential for everyone to know the current situation. If someone doesn't show up in an appointment, the others should contact him.

\textbf{Reacting:} The other members try to complete the tasks of the missing participant. Unexpected absence shall be reported immediately.

\section{Human relationships}
Effective teamwork is not possible if the group members don't get along with each other for some reason.

\textbf{Anticipating:} The group members should get to know each other in the beginning of the project.

\textbf{Tracking:} Follow the situation and bring out the subject in a group meeting if it looks like there is an issue.

\textbf{Reacting:} Try to resolve conflicts by talking.

\section{Inexperience}
The team members don't have much experience of software projects of this magnitude. Most of the team members are also unfamiliar with the subject.

\textbf{Anticipating:} Survey the factors causing uncertainty when sharing tasks. One should inform the others if he cannot carry out an assignment by himself.

\textbf{Tracking:} Have situation reviews frequently.

\textbf{Reacting:} Ask for help from other team members, the supervisor(s), and the client.

\section{Programming skills}
There may be insufficiencies in the team's programming skills. Dealing with MPlayer's source code may be challenging because the team is unfamiliar with the programming paradigms it uses. 

\textbf{Anticipating:} Survey the team's programming skills in the beginning of the project.

\textbf{Tracking:} Keep watch on the progress of programming by having inspections and situation reviews.

\textbf{Reacting:} Ask for briefing from other team members or supervisors if problems arise. Use pair programming to share knowledge.

\section{Scheduling}
The project has only a few main requirements. Estimating the amount of time required to implement them might still be quite difficult. Underestimation is likely to lead to too strict schedule.

\textbf{Anticipating:} Estimate time requirements for each task individually. Use iterative process to make it easier to adopt changes in the schedule. Inform the client within an iteration if delays are likely to occur.

\textbf{Tracking:} Time consumption is monitored with the time management application and on the whiteboard. The amount of time actually used should be compared with the estimates at the end of an iteration.

\textbf{Reacting:} Negotiate with the client about rearranging the schedule and leaving objectives out if necessary.

\section{Communication}
Communication between the participants of the project may be insufficient. This can be a serious problem because the project involves a great amount of background research.

\textbf{Anticipating:} The participants should get to know each other so they would feel more comfortable while communicating. Adopt minimum practices for communication (see \ref{communication}).

\textbf{Tracking:} The project manager follows the situation and makes sure that the group communicates sufficiently.

\textbf{Reacting:} In serious lack of communication, contact the supervisors for solution.

\section{Language}
The native language of the team members is Finnish. The language used for documentation and communicating with the client is English. This may cause some misunderstandings and make writing the documents more challenging for the team.

\textbf{Anticipating:} Survey the team's skills in English language in the beginning of the project. The students should get familiar with the subjects that are about to be discussed and study the most common terms in advance.

\textbf{Tracking:} Constantly track if the foreign language causes issues such as misunderstandings or delays that might compromise the progression of the project.

\textbf{Reacting:} If misunderstandings occur, correct them as soon as possible. Take up the question with the supervisor and the client if the language seriously holds back the progress.

\section{MPlayer development}
Radical changes in MPlayer source code could make applying the patches to latest SVN version of MPlayer more complicated. This would make delivering the patch to MPlayer community significantly harder, since they only accept patches compatible with the latest version. There is also a chance that other developers implement similar functionalities to MPlayer, which would make this project obsolete. 

\textbf{Anticipating:} Research the existing code to see what has been done already.

\textbf{Tracking:} Keep watch on the situation with MPlayer development by tracking changes in the SVN version and new releases.

\textbf{Reacting:} Negotiate with the client about project requirements if it looks like something has already been implemented by other developers.

\section{Applications}
A lot of software applications are needed during the project. Some of them may not be already installed on the computers in the project room. The team members may also be unfamiliar with some of the applications. When it comes to a computer software, there is always a risk of malfunction too.

\textbf{Anticipating:} Determine in the beginning what kind of software is required to complete the project.

\textbf{Tracking:} Make sure that all the required applications are installed and working properly.

\textbf{Reacting:} Request the technical support to install missing software and to resolve other software related problems. Also inform the others via project mailing list to keep them up with the situation. Ask for help with unfamiliar applications from other team members and the supervisor.


%bibliograohy
\begin{thebibliography}{1}

\bibitem[1]{credit}
MPlayer documentation; Appendix D. History, refrenced 10.10.2008 \\
\texttt{http://www.mplayerhq.hu/DOCS/HTML/en/history.html}

\bibitem[2]{history}
University of Jyv�skyl�; KIEPO termipankki, refrenced 29.9.2008 \\
\texttt{http://www.jyu.fi/hum/laitokset/solki/tutkimus/}
\texttt{projektit/kiepo/termipankki/opintopiste/}
\texttt{?searchterm=opintopiste}
\end{thebibliography}

%APPENDIX
%\begin{appendix}

%\chapter{First appendix}

%\end{appendix}

% The end of document.
\end{document}
