% .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.4}

% 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}

% Tiivistelmä dokumentista: tämä ei siis ole tiivistelmä projektista,
% vaan tämän ko. dokumentin tarkoituksesta. 
\docabstract{This is the project plan document of application project Muksis. The document introduces readers to the area of this project explaning terms and giving background information and describing goals, available resources and management methods. In the later part of the plan the document hadles information about tasks, schedule and risks.} 

% Tiivistelmä projektista
\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 and/or improves similar existing features for Matthieu Weber.}

% Avainsanat: dokumentin sisältöön liittyviä olennaisia asiasanoja: aakkosjärjestys, ensimmäinen sana isolla alkukirjaimella ja piste loppuun.
\keywords{Application project, black frame detecting, DVB, MPEG, search in MPEG TS, Muksis, MPlayer.}

% Varsinainen tulosteessa näkyvä ladonta alkaa
\begin{document}

% Tämä latoo versiohistorialle ympäristön, sen alapuolelle ladotaan
% versiohistoriataulukko. Esimerkin vuoksi tehty. 
\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  & Recources written. & RD\\
\hline
0.4    &  3.10.2008  & Management methods, tasks, workload, division of labour, project goals, risks and schedule written. & TM, TT, TN\\
\hline
\end{tabular}


% \projectinfo latoo ympäristön projektin tiivistelmälle, joka on 
% projektikohtainen.
% Projektin tiivistelmä ja tekijöiden tiedot ladotaan automaattisesti sivun
% alkuun. Eli lisättävä projektiorganisaation tiedot muiden kuin tekijäiden
% osalta sekä tarvittavat yhteystiedot. Alla tämä on tehty esimerkin vuoksi.
\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 latoo automaattisesti sisällysluettelon ym. alkusivut, ja 
%% sen jälkeen alkaa dokumentin sisällysluettelossa näkyvät luvut.
\mainmatter

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

Muksis is a student application project in the Department of Mathematical Information Technology at the University of Jyväskylä. During fall 2008 and the beginning of year 2009 the project 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 and/or improves similar existing features possibly found in original MPlayer code if found meaningful. The application 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 very wide 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 group 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 developing 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 this document are explained. Chapter \ref{chap:background} expounds background information and chapter \ref{chap:goals} construes and reasons the main goals. Chapter \ref{chap:resources} analyzes available resources, chapter \ref{chap:management} describes project management methods and chapter \ref{chap:tasks} explains about tasks, workload and division of labour. Project schedule is introduced in chapter \ref{chap:schedule} and finally chapter \ref{chap:risks} describes possible risks involved in this application project.


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

\begin{Ventry}{Agile software development}
\item[Agile software development] a software development process. Agile methods emphasize realtime communication and working software as the primary measure of progress using iterative development.
\item[Application 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 datastream 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[User story] a software system requirement formulated as one or two sentences in the everyday language of the user.
\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.

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.


\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}
A patch that adds the primary features was previously created by Matthieu Weber,
but the continued development of MPlayer has left the patch incompatible with 
the MPlayer source code. The features can thus be implemented either from
scratch or by adapting the previous patch's code to work in the current MPlayer
source.

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.


% Voisi katsoa jossain vaiheessa, mitkä näistä ovat projektin kannalta
% olennaisia ja mitkä eivät. 
% -T
\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
for 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:
\begin{itemize}
\item \textbf{The architecture report}, which explains the overall structure of 
the MPlayer software, or at least the parts related to the project's goals.
\item \textbf{The application report}, which describes how the new features 
work.
\item \textbf{GPL agreement} contract on licensing the source code and the software under GPL.
\item \textbf{The 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{The project's e-mail list archive} in printed form.
\item \textbf{Showcase reports} (esittelyraportit) for the related course.
\item \textbf{The project report} will be written at the end of the project to 
summarize its development.
\item \textbf{Meeting agendas, minutes} and related materials.

% jätin tähän jutut, joista en keksinyt mitään kirjoitettavaa..
%\item \textbf{Installing introduction(?)} 
%\item \textbf{Requirement analysis(?)} 
%\item \textbf{Resource management report}
%\item \textbf{Test report}
\end{itemize}

\section{Learning goals}
The project's participants will gain useful experience in teamwork, the various
aspects of managing a software project, working with an open source project and
its codebase and (hopefully) some people skills.


\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 [1], 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 heterogenous 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) and office supplies. 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, altough lack of one presents unique risks.


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

\section{Project process model}
The project is carried out using an agile method process model. This model uses multiple sequental iterations that have duration of two weeks. The beginning phase is called as 0-iteration and topic of the project, workspace and personel are introduced. 0-iteration acts as a startup and orientation phase with no software implementation. After this iterations are performed in two-week cycles from iteration 1. The first day of new iteration is the next day after the official meeting between iterations.

\section{Meetings and communication}
An official meeting is held between every iteration with all participants of project Muksis. Before the meeting project team plans the material, which shows the upcoming iteration's requirements and explains how working time was distributed in the last one. At meeting the previous iteration is reviewed and goals for the future iteration decided. Which means the parts of software to be implemented and the documents to be written in the next two weeks.

The communication is held up with e-mail list at muksis@korppi.jyu.fi and face-to-face meetings. The documents are stored in the Muksis project space created to the network of the university of Jyväskylä, which participate in the project will 
monitor the progress of the project. In addition, meeting agendas and minutes are stored in the group created a Trac project management application, where they are easily editable.

\section{Task managemen}
After meetings, the team plans together how they are going to implement the software. This is done before the division of tasks. Office room's white board is used in this phase and recorded implemented the requirements and were provided for group discussion of those responsible. In addition, the requirement calls make up the work progresses, the percentage estimate of how much the requirements have been carried out. When Member of the group has received a pre-requirement, he can look directly valkotaululta; what tasks have not yet been allocated and take it over. Furthermore, agreed with the brief moments from the assembly, which runs through the implementation of the performance These reviews
is considered necessary, but at least two weeks.

\section{Schedule management}
Every time iteraation recorded in a separate excel-bottom. This table is recorded
Members of the Group of the hours, broken down by vaatimuksittain. Meanwhile, the table is recorded
oheiskurssiin also spent hours iteraation of that period. The table is filled each week on Friday. Iteraation at the beginning of a project team to make an assessment of hours worked vaatimuskohtaisesti. The intra-group meetings held thus iteraation, at least in the beginning of the distribution of tasks and their exports of resource assessment. Iteraation the end of the table sees the estimate and outturn ratio. This information is useful in a more realistic evaluation of the project.

\chapter{Tasks, workload and division of labour} \label{chap:tasks}

The project's smooth passthrough to promote the project has been divided into different work packages, and areas of responsibility. For each task and responsibility of the area is designated on the corresponding member of the group or members. The project is in addition to a project team to carry out oheiskurssin. oheiskurssi secret deals tehtäväkokonaisuutenaan and will include the corridors course lectures and mid-demonstrations.

\section{demarcation of responsibilities}
The project's various sub-regions designated as group leaders, whose task is to monitor their own responsibilities under the mission progression and accurate. Division of responsibility is shown in table XX This task allocation takes account of the group members' responsibilities. But aim is that all enjoy the experience of each task a whole.

The project includes management of the project plan preparation, information and reporting. Management is also calculated in palaverit, preparation and palaverin protocol. Pilot covers the subject area and exploring the tools Requirements management belongs to the requirements of kertoitus together with the customer and their management through the project. The application covers the planning application to the various elements of the design, such as an application architecture and structure. Application Planning ensures that each iteraation at the beginning of getting through the group carried out the design a common vision of creation. Implementation of the various sub-programming. Components are divided into vastuualueikseen own, which are shown in Table 6.1. Studies seeks to share for members of the group table to appear in accordance with the division. With the source code, documentation and the match finishes its own people. Web site development, maintenance and updating also has its own responsibilities. Testing is part of the so singular as the integration testing and storyjen
acceptance tests. Testing is responsible for ensuring that these all are carried out as planned, and controlled through a project.

\section{Iteraation segregation of duties}
Iterative process of the model taken for reasons of the requirements to be decided case by case basis iteraatioiden in the arts at the powwow. Then iteraation during the requirements of responsible persons and time iteraation planned to be held at the beginning of a group powwow. For example, a 1-iteraation task-sharing is presented in table XX of the time the plan completed after Studies carried out have been closed. The other iteraatioiden taken in the arts is drawn up in the responsibilities assigned only way.

\chapter{Schedule} \label{chap:schedule}
The project is carried out agile methods in accordance with a process model The project will apply a short, two-week iteraatioväliä. Each of iteraatiossa aims to build the previous iteraatiossa generated profits ahead. This ensures that the project is progressing steadily, and subscribers get, as soon as possible to monitor the results of the project development. Short iteraatioväli allow for the rapid reagoinninmahdollisiinmuutoksiin and predictive outstanding claims. It will also facilitate the evaluation of time because the episode is always the same. In previous iteraatioiden the basis of accrued knowledge to help assess how much the two-week period there will be time to implement. Estimates of work tarkentuvat as a project progresses.

In Figure 7.2 is presented in the project glands above-described process model. Start-up Phase (Set Up) is 0-iteraatio, and the other begins iteraatiot always getting through. Iteraatioiden periodicity of between two weeks and during, may also agree to hold informal meetings if they felt necessary.

\section{Iteraation Steps}

The tasks to the requirements of deciding always iteraatiokohtaisesti. Iteraatioiden in the arts at the powwow a project team with the customer re-evaluate the requirements of the priorities and decide to take requirements. Palaverin ago after meeting a group powwow group decides iteraation during the requirements of responsible persons and the time planned. The estimate demand the implementation of the current period will allow reflektoinnin during the project, namely the resources to be studied the mirror to previous demands and those already elapsed time.

Requirements deals käyttäjätarinoina the user storyina. Storytmuistuttavat use cases (Use Case), but are standard descriptions of customer requirements. Storylle be given a descriptive name, and those approval defining the criteria. Studies then be distributed programming tasks to be assigned to team members. The group planning powwow responsible for the records of the white board during the iteraation Studies carried out and their promoters. During the implementation of the outputs run the unit for testing and user storyhin charged in the approval tests to go through, so that developers can say storyn to be fully implemented. Thereafter, the output is carried out immediate integration of the program. If the story is ready to discharge its author to check directly to the next valkotaululta the Stör and to record it himself. Iteraation at the end of all iteraation storyjen approval of the tests will take place through the first group of the action and then the customer and the powwow. Iteraation photographed structure diagram, 7.1.

\section{Iteraatioiden schedules}

Scoreboard 7.1 is to be presented iteraatioiden designed for the arts sections and the main targets (the release plan). Iteraatioiden between the time period reviewed with the customer previous iteraation yields and refined in the next iteraation plan. This transitional phase lasts from zero days to a week, depending on the parties' resources and whether we need yet palaverin run after the approval or planning. Application Project was launched 1.2.2007 and the table of 7.1 according to plan the project lasts 17 weeks, ie ending on 31.5.2007.


\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}. Propabilities 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
    The client & Low & High \\
    \hline
    Supervision & Intermediate & Intermediate \\
    \hline
    Group members & Low & High \\
    \hline
    Inexperience & High & Intermediate \\
    \hline
    Programming skills & Intermediate & 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{The client}
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 group is not able to contact the client at some point.

\textbf{Anticipating:} Meetings should be arranged early enough.

\textbf{Tracking:} The group should be in contact with the client frequently.

\textbf{Reacting:} If the client is prevented from participating to the supervision of the project, the group 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:} Meetings should be arranged 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 group if technical difficulties arise.

\section{Group members}
Obstacles such as vacations, social matters or illness may turn up to prevent some group members from participating in the project. Relational problems between group members may also be harmful for the project.

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

\textbf{Tracking:} Communication within group members is essential for everyone to know the current situation and to keep the relations intact.

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

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

\textbf{Anticipating:} Asking for advice in difficult situations is important. 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 group members, the supervisor(s), and the client.

\section{Programming skills}
There may be insuffiencies in the group's programming skills. Dealing with MPlayer's source code may be challenging because the group 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.

\textbf{Reacting:} Ask for briefing from other group 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:} Use iterative process to make it easier to adopt changes in the schedule.

\textbf{Tracking:} Time consumption is monitored with the time management application and on the whiteboard.

\textbf{Reacting:} Rearrange schedule if delays occur. Negotiate with the client about 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.

\textbf{Tracking:} Have unofficial meetings to invoke communication.

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

\section{Language}
The native language of the group 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 group.

\textbf{Anticipating:} The students should get familiar with the subjects that are about to be discussed and study the most common terms in advance.

\textbf{Tracking:} Ask if something is unclear.

\textbf{Reacting:} If misunderstandings occur, correct them as soon as possible.

\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 pathces compatible with the latest version. There also is 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.

\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 group 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. Ask for help with unfamiliar applications from other group members and the supervisor.


\chapter{Summary} \label{chap:summary}

%LÄHTEET
\begin{thebibliography}{1}
%Katso kirjoitusohjeen luku 2.3 ja 2.4.
%\bibitem[1]{Jok05} Jokinen, R., ''Ohjelmistoprosessit'', Helsinki: Otava, 2005.
\bibitem[1]{credit}
University of Jyväskylä; KIEPO termipankki, refrenced 29.9.2008 \\
\texttt{http://www.jyu.fi/hum/laitokset/solki/tutkimus/projektit/kiepo/termipankki/opintopiste/?searchterm=opintopiste}
\end{thebibliography}

%LIITTEET
%\begin{appendix}

%\chapter{First appendix}

%\end{appendix}

% Dokumentin  lopetus
\end{document}
