% .tex-tiedosto projektin dokumenttien latomiseksi.

% Kirjoitelmaluokka, tässä käytetään projektien projdoc-luokkaa.
%\documentclass[twoside]{projdoc}
\documentclass[report,final]{projdoc}

\usepackage{paralist} % siistimmät lista-alkiot
\usepackage{makecell} % taulukkoon monta riviä
\renewcommand\cellalign{ll}
\usepackage{placeins} % floatbarrier
\usepackage{listings} % listaukset

\renewcommand{\lstlistingname}{Listaus}
\renewcommand{\lstlistlistingname}{\lstlistingname Listaukset}
\lstloadlanguages{csh} % C#-ohjelmointikieli
\lstset{literate=
{Ö}{{\"O}}1
{Ä}{{\"A}}1
{ä}{{\"a}}1
{ö}{{\"o}}1
}
\lstset{
captionpos=b,
basicstyle=\ttfamily\footnotesize
}

% Projektin nimi
\project{Groundhog}

% Luottamuksellisuus: käytä termiä 'Luottamuksellinen' tai 'Julkinen'
\publicity{Julkinen}

% Versionumero: numerointikäytäntö on projektikohtainen
\version{1.0.0}

% Päivämäärä: ylikirjoittaa automaattisen päiväyksen
\date{21.10.2021}

% Dokumentin nimi
\title{Projektiraportti}

\def \jobname {projektiraportti} % tämän tiedoston nimi ilman .tex

% Tekijät: huomaa aakkosjärjestys sukunimen mukaan
\author{Iiro Iivanainen}{Harri Linna}{Jere Pakkanen}{Riikka Vilavaara}
% Puhelinnumerot: tekijöitä vastaava järjestys!
\authorphones{}{}{}{}
% Sähköpostiosoitteet: tekijöitä vastaava järestys!
\authoremails{iiro.h.iivanainen@student.jyu.fi}{harri.s.linna@student.jyu.fi}{jere.j.pakkanen@student.jyu.fi}{riikka.k.vilavaara@student.jyu.fi}
% Etu- ja sukunimen alkukirjaimet: tekijöitä vastaava järjestys!
\authorinitials{II}{HL}{JP}{RV}

% Tiivistelmä dokumentista: tämä ei siis ole tiivistelmä projektista,
% vaan tämän ko. dokumentin tarkoituksesta. 
\docabstract{Groundhog-projekti kehitti ohjelmiston Geologian tutkimuskeskukselle tukemaan tomograﬁalaboratorion näytteiden analyysiä. Ohjelmisto helpottaa erityyppisten tutkimusdatojen yhdistämistä, hallintaa ja visualisointia. Dokumentissa kuvataan Groundhog-projektin toteutunutta läpivientiä ja eroja suunnitelmaan verrattuna tavoitteiden ja tulosten, tehtävien ja työmäärien, prosessin ja aikataulun sekä riskiarvioiden ja riskienhallinnan osalta. Lisäksi dokumentissa kuvataan projektiin osallistuneiden opiskelijoiden kokemuksia ja oppimaa. Toteumaa verrataan projektisuunnitelman versioon 1.0.0.}
% Tiivistelmä projektista
\projectabstract{

% Groundhog-projekti suunnitteli ja toteutti Geologian tutkimuskeskukselle multimodaalisen tutkimusdatan hallintaohjelmiston kevätlukukaudella 2021.
}

% Avainsanat: dokumentin sisältöön liittyviä olennaisia asiasanoja: aakkosjärjestys, ensimmäinen sana isolla alkukirjaimella ja piste loppuun.
\keywords{Aikataulu, kokemukset, käytänteet, projektiraportti, prosessi, resurssit, riskit, roolit, sovellusprojekti, tavoitteet, tehtävät, tulokset, työmäärät, työvaiheet.}

% 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{11.5cm}|c|}
\hline
\textbf{Versio} & \textbf{Päivämäärä} & \textbf{Muutokset} & \textbf{Tekijät}\\
\hline
0.0.1 & 31.5.2021 & Kirjoitettiin johdanto. & HL\\
\hline
0.0.2 & 2.6.2021 & Kirjoitettiin sovelluksen tavoitteista ja päivitettiin termilista. & HL\\
\hline
0.0.3 & 4.6.2021 & Kirjoitettiin sovelluksen tavoitteista, tuloksista ja oppimistavoitteista. & HL\\
\hline
0.0.4 & 8.6.2021 & Kirjoitettiin projektiorganisaatiosta. & HL\\
\hline
0.0.5 & 15.6.2021 & Kirjoitettiin tiloista ja laitteista, kehitystyökaluista sekä dokumentointityökaluista. & HL\\
\hline
0.0.6 & 16.6.2021 & Kirjoitettiin luennoista ja perehdytyksistä. & HL\\
\hline
0.0.7 & 29.6.2021 & Kirjoitettiin palavereista ja tiedotuksesta. & HL\\
\hline
0.0.8 & 30.6.2021 & Kirjoitettiin tiedostojen nimeämisestä, hakemistorakenteesta, lähdekoodista, testauksesta, versiohallinnasta ja -numeroinnista sekä katselmoinneista ja tulosten hyväksymisestä. & HL\\
\hline
0.0.9 & 1.7.2021 & Kirjoitettiin tulosten koostamisesta ja toimittamisesta. & HL\\
\hline
0.0.10 & 4.7.2021 & Kirjoitettiin rooleista ja vastuualueista. & HL\\
\hline
0.0.11 & 6.7.2021 & Asemoitiin kansilehti uudelleen. & HL\\
\hline
0.0.12 & 7.7.2021 & Siirrettiin tietoa projektista dokumenttiluokkaan ja päivitettiin termilistaa. & HL\\
\hline
0.0.13 & 8.7.2021 & Muokattiin sovelluksen toteutuneita tavoitteita. & HL\\
\hline
0.0.14 & 9.7.2021 & Muokattiin tavoitteiden toteutumista ja tuloksia. & HL\\
\hline
0.0.15 & 10.7.2021 & Kirjoitettiin tehtäväkokonaisuuksista ja työmääristä. & HL\\
\hline
0.0.16 & 11.7.2021 & Kirjoitettiin projektinhallinnan työmääristä, palaverien työmääristä, esitutkimuksen työmääristä, vaatimusmäärittelyn työmääristä, suunnittelun työmääristä ja toteutuksen työmääristä. & HL\\
\hline
0.0.17 & 13.7.2021 & Muokattiin tehtäväkokonaisuuksia ja työmääriä. & HL\\
\hline
0.0.18 & 14.7.2021 & Kirjoitettiin uudelleen tehtäväkokonaisuudet ja työmäärät sekä resursseista ja työmääristä. & HL\\
\hline
0.0.19 & 19.7.2021 & Kirjoitettiin prosessista ja muokattiin käytänteitä. & HL\\
\hline
0.0.20 & 20.7.2021 & Kirjoitettiin prosessista ja projektin kehitysvaiheista. & HL\\
\hline
0.0.21 & 21.7.2021 & Kirjoitettiin uudelleen projektin kehitysvaiheista ja muokattiin lähdeluetteloa. & HL\\
\hline
0.0.22 & 16.8.2021 & Kirjoitettiin riskeistä ja niiden hallinnasta sekä tiivistelmä. & HL\\
\hline
\end{tabular}

\begin{tabular}{|c|r|p{11.5cm}|c|}
\hline
\textbf{Versio} & \textbf{Päivämäärä} & \textbf{Muutokset} & \textbf{Tekijät}\\
\hline
0.1.0 & 17.8.2021 & Versio 0.0.22 numeroitiin uudelleen julkistamista varten. & HL\\
\hline
0.1.1 & 23.8.2021 & Kirjoitettiin jäsenten kokemuksia ja oppimaa sekä muokattiin palautteen mukaan. & HL\\
\hline
0.1.2 & 25.8.2021 & Kirjoitettiin jäsenten kokemuksia ja oppimaa. & HL\\
\hline
0.1.3 & 10.9.2021 & Korjattiin lukua 7. & HL\\
\hline
0.1.4 & 12.9.2021 & Korjattiin lukua 8. & HL\\
\hline
0.1.5 & 14.10.2021 & Korjattiin lukua 6. & HL, JP\\
\hline
0.1.6 & 17.10.2021 & Korjattiin lukua 5. & HL\\
\hline
0.2.0 & 18.10.2021 & Tehtiin palautteen mukaiset korjaukset. & HL\\
\hline
0.2.1 & 20.10.2021 & Päivitettiin hakemistorakennetta. & HL\\
\hline
1.0.0 & 21.10.2021 & Tehtiin palautteen mukaiset korjaukset. & HL\\
\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

%----------------------------------------------------------------------------
% \mainmatter latoo automaattisesti sisällysluettelon ym. alkusivut, ja 
%% sen jälkeen alkaa dokumentin sisällysluettelossa näkyvät luvut.
\mainmatter

% \chapter{Pääluvun nimi} aloittaa pääluvun, \section{Alaluvun nimi} alaluvun,
% ja \subsection{Ala-alaluvun nimi} ala-alaluvun.
\chapter{Johdanto}

% Groundhog-projekti kehitti Geologian tutkimuskeskukselle multimodaalisen tutkimusdatan hallintaohjelmiston kevätlukukaudella 2021. Projektin jäsenet kehittivät ohjelmiston osana Jyväskylän yliopiston informaatioteknologian tiedekunnan Sovellusprojekti-nimistä projektiopintojaksoa.

Groundhog-projekti kehitti ohjelmiston Geologian tutkimuskeskukselle tukemaan tomograﬁalaboratorion näytteiden analyysiä. Ohjelmisto helpottaa erityyppisten tutkimusdatojen yhdistämistä, hallintaa ja visualisointia. Dokumentissa kuvataan Groundhog-projektin toteutunutta läpivientiä tavoitteiden ja tulosten, tehtävien ja työmäärien, prosessin ja aikataulun sekä riskiarvioiden ja riskienhallinnan osalta. Lisäksi dokumentissa kuvataan projektiin osallistuneiden opiskelijoiden kokemuksia ja oppimaa. Toteumaa verrataan projektisuunnitelman versioon 1.0.0.

Dokumentin laatimisessa on hyödynnetty projektien Liikkuva \cite{liikkuva}, Peltihamsteri \cite{peltihamsteri} ja Potku \cite{potku} raportteja sekä \textit{Tietotekniikan Sovellusprojektien ohjetta} \cite{projektiohje}. Dokumentin lisäksi projektiryhmä laati vaatimusmäärittelyn \cite{vaatimukset}, jossa kuvataan kehitetyn sovelluksen suunnitellut sekä toteutuneet tiedot ja toiminnot. Projektiryhmä suunnitteli vaatimusten pohjalta arkkitehtuurin \cite{arkkitehtuuri}, käyttöliittymän \cite{kayttoliittyma} ja luokkarakenteen \cite{luokkarakenne}. Kehitetyn sovelluksen toteutusratkaisuja ja jatkokehitysideoita kuvataan sovellusraportissa \cite{sovellusraportti}. Sovelluksen laadunvarmistus hoidettiin järjestelmätestauksena, josta laadittiin testaussuunnitelma \cite{testaussuunnitelma} ja testauskertojen raportit \cite{testausraportti}.

Dokumentin luvussa \ref{ch:termit} määritellään projektissa käytettyä käsitteistöä. Luvussa \ref{ch:tavoitteiden-toteutuminen-ja-tulokset} arvioidaan kuinka projektille asetetut tavoitteet toteutuivat. Luvussa \ref{ch:resurssit} esitellään projektiin osallistuneet henkilöt sekä heidän käyttöönsä annetut tilat, laitteet ja ohjelmat. Luvussa \ref{ch:kaytanteet} kuvaillaan projektin käytänteiden toteutumista. Luvussa \ref{ch:roolit-vastuualueet-ja-tehtavat} esitetään henkilöiden vastuualueita sekä tehtävien jakautumista ja työmääriä. Luvussa \ref{ch:prosessi-ja-aikataulu} kuvataan projektin toteutunut prosessi sekä verrataan toteutunutta aikataulua suunniteltuun. Luvussa \ref{ch:riskit-ja-niiden-hallinta} arvioidaan riskienhallinnan toteutumista. Luvussa \ref{ch:jasenten-kokemuksia-ja-oppimaa} pohditaan ryhmän jäsenten oppimaa ja kokemuksia projektista.

\chapter{Termit}
\label{ch:termit}

\termit %komento projdoc-luokassa

\chapter{Tavoitteiden toteutuminen ja tulokset}
\label{ch:tavoitteiden-toteutuminen-ja-tulokset}

Luvussa käsitellään sovellukselle asetettujen tavoitteiden toteutumista, ryhmän oppimiselle ja muille tuloksille asetettuja tavoitteita ja niiden toteutumista. Projektin aikana toteutettiin sovelluksesta prototyyppi, joka sisältää suurimman osan pakollisista toiminnoista. Toteutusvaiheen loppupuolella sovittiin tilaajan kanssa joitakin tärkeitä toimintoja ohjelmiston jatkokehitykseen. Projektiryhmän laatima sovellusraportti \cite{sovellusraportti} ja vaatimusmäärittely \cite{vaatimukset} antavat hyvät lähtökohdat jatkokehitykseen. Dokumentit ja muut materiaalit saatiin laadittua suunnitellusti sekä ryhmän jäsenten oppimistavoitteet toteutuivat.

% Sisältää tilaajalle ja laitokselle luovutettavat tulokset.
% Miten materiaali toimitetaan tilaajalle ja laitokselle.
% Tuloksille asetettujen tavoitteiden toteutuminen tiivistettynä sisältäen rajauksen ja muutokset projektin kuluessa. Viittaus tarkempien kuvausten osalta vaatimusmäärittelyyn ja sovellusraporttiin.

\section{Taustaa ja tarpeita}

Projektin tilaajana toiminut Geologian tutkimuskeskus on työ- ja elinkeinoministeriön alainen kansainvälisesti suuntautunut asiantuntijaorganisaatio, jonka toimipaikkoja on Suomessa kuudella eri paikkakunnalla. Geologian tutkimuskeskus tutkii maaperää ja sen luonnonvaroja tuottaen ratkaisuja elinkeinotoiminnan kestävään kehittämiseen. Tutkimusalueita ovat esimerkiksi ilmastonmuutos, materiaalit ja kiertotalous, liikenteen sähköistyminen sekä hiilineutraali yhteiskunta.

Tomografialaboratoriolla on käytössään röntgensädeskanneri, jonka tuottamaa kolmiulotteista matriisimuotoista harmaasävykuvaa analysoidaan FEI PerGeos -ohjelmistolla. Projektissa kehitettävän sovelluksen päämääränä oli muun tyyppisen tutkimusdatan liittäminen tomografialaitteiston tuottamaan harmaasävykuvaan.

Sovellukselle asetetut vaatimukset olivat suurimmaksi osaksi toiminnallisia vaatimuksia. Sovelluksen suunnittelu suoritettiin tilaajan edustajien kanssa palavereissa. Projektiryhmä esitteli tilaajan edustajille sovellussuunnitelmia ja teki niihin ehdotettuja muutoksia saamansa palautteen perusteella. Toteutusvaihetta edeltäneiden palaverien pöytäkirjat antavat hyvän kuvan ohjelmiston käyttöliittymän, arkkitehtuurin ja luokkarakenteen suunnittelusta.

\section{Sovelluksen toteutuneet tavoitteet}

Pakollisten ja tärkeiden vaatimusten osalta toteutettu sovellus tarjoaa käyttäjälle käyttöliittymän, jonka avulla käyttäjä voi liittää haluamansa tiedoston karttaa esittävään koordinaatistoon. Ohjelma tukee teksti-, kuva-, ja taulukkomuotoisten tiedostojen esitystä, jotka merkitään karttaan pistemäisinä liitoskohtina. Kolmiulotteista tomografiakuvaa esitetään ohjelmassa kolmella pääakselien suuntaisilla leikkauskuvilla. Liitedataa visualisoidaan sovelluksessa graafisesti sekä esitetään listana.

Kehitetty sovellus on teksti-, kuva- tai taulukkomuotoisen tutkimusdatan hallintajärjestelmä. Sitä voidaan käyttää millä tahansa perustietokoneella, johon on asennettuna Windows-käyttö\-järjestelmä. Sovelluksesta toteutettiin toiminnoiltaan suunniteltua rajoittuneempi prototyyppi, joka täyttää tärkeimmät sovellukselle asetetuista tavoitteista. Kehitettävän sovelluksen tärkeimmät kokonaistavoitteet liittyivät liitedatan lukemiseen, näyttämiseen ja yhdistämiseen. Kokonaistavoitteet muodostivat selkeät tehtäväkokonaisuudet, joiden ryhmittely on nähtävissä vaatimusmäärittelyssä \cite{vaatimukset}.

Sovelluksella voidaan käsitellä suuria kolmiulotteisia kuvatiedostoja lukematta niitä kokonaan muistiin. Sovelluksella voidaan selata pääakselien suuntaisia kaksiulotteisia leikkauskuvia, jotka ovat yleisimmät katselukulmat. Kuvapisteisiin pystyy liittämään muun tyyppistä liitedataa ja liitoskohdat visualisoidaan pisteinä. Käyttöliittymä ja luokkarakenne sijoitettiin lähdekoodin tasolla erillisiin projekteihinsa, minkä ansiosta niitä voidaan kehittää toisistaan riippumattomasti.

Tilaajan edustajien laatimassa aihekuvauksessa työmäärien arvioitiin painottuvan edellä kuvattuihin toimintoihin ja käyttöliittymään. Toteutuneet tehtäväkokonaisuudet vastasivat tarkasti suunniteltua, joten kehitetty sovellus vastasi täsmällisesti tilaajan asettamia kokonaistavoitteita, vaikkakin tavoitteet saavutettiin vain osittain. Tilaajan edustajat olivat kertomansa mukaan varautuneet tällaiseen lopputulokseen, joten tämän kaltainen prototyyppi oli tilaajan puolelta odotettavissa. Tästä syystä projektin tavoitteet toteutuivat hyväksyttävästi. Toimintojen rajaus onnistui siinä mielessä hyvin, etteivät prototyyppiin toteutetut ominaisuudet jääneet keskeneräisiksi. Teknisen ohjaajan mukaan sovellus ei ole vielä valmis tuotantokäyttöön, joten sovellukselle laadittiin suunnitelmat jatkokehitystä varten.

% Siirrä tästä eteenpäin sovellusraporttiin

% \textbf{Karttatiedoston lukemista} koskevat vaatimukset muodostivat ensimmäisen tehtäväkokonaisuuden. Karttatiedostojen lukemiseen käytetyn Magick.NET-kirjaston käytössä projektin jäsenet kohtasivat projektissa odottamattoman suuren määrän ongelmia. Kirjaston puutteellinen ja paikoittain jopa virheellinen dokumentaatio vaikeutti karttatiedostojen käsittelyä. Kirjaston valinnalla tavoiteltiin ennen kaikkea yhtenäistä tapaa käsitellä erilaisia kuvaformaatteja. Tästä oli hyötyä kuvapinojen kohdalla, kun käsiteltiin kaksiulotteisia kuvatieodostoja. Toisaalta vaatimukset edellyttivät vain kahta kuvaformaattia tiff ja png, jotka olisivat olleet toteutettavissa projektin aikana ilman Magick.NET-kirjastoakin. Muut karttatiedoston tyyppit 3D-tiff ja raw vaativat erityiskäsittelyä, joten karttatiedostojen lukeminen olisi kannattanut toteuttaa projektin alusta asti käyttäen Miettisen kirjoittamaa pi2-kirjaston valmista ohjelmakoodia. Karttatiedostojen käsittelyssä esiintyy tarpeetonta toistoa, kun tuettavat karttatiedoston tyypit käsitellään erillisissä metodeissa. Jatkokehityksessä tässä kannattaisi harkita Miettisen tapaa, jossa karttatiedoston lukeminen ja käsittely erotetaan toisistaan.

% Jatkokehityksen kannalta kuvankäsittelyyn erikoistuneen kirjaston valinta vaikuttaa edelleen perustellulta ratkaisulta, sillä kirjasto mahdollistaa myös kuvan jatkokäsittelyn esimerkiksi harmaasävyskaalan muuttamisen. Karttatiedostojen lukeminen päädyttiin toteuttamaan niin, että karttatiedostoista muodostetaan pääakselien suuntaiset kaksiulotteiset kuvapinot. Laaja kuvaformaattien tukeminen ja kuvankäsittely puoltavat Magick.NET-kirjaston valintaa MVVM-arkkitehtuurin kanssa, sillä kuvatiedostot on sidottu käyttöliittymän kuva-elementteihin. Käytännössä kuvankäsittely ulkoistettiin siis kokonaan Magick.NET-kirjastolle. Vastaavan toiminnallisuuden olisi tarjonnut esimerkiksi OpenCvSharp-kirjasto, johon ei kuitenkaan perehdytty tarkemmin enää sopivan kirjaston löydyttyä. Toteutusratkaisulla saatiin toteutettua pakolliset vaatimukset karttatiedostojen lukemisen osalta.

% \textbf{Kartan ja liitedatan hallintaa} koskevat vaatimukset muodostivat toisen tehtäväkokonaisuuden. Ohjelma kykenee näyttämään liitedataa, joka voi olla tekstiä, kuvia tai taulukoita. Liitettävän datan käsittelyn ja muokkaamisen vaatimukset siirrettiin kokonaisuudessaan jatkokehitykseen, sillä esimerkiksi taulukoiden muokkaaminen oli käytännöllisempää tehdä siihen erikoistuneella taulukkolaskenta-ohjelmalla. Vastaavasti sovellukseen sisällytettävä AvalonEdit-tekstieditori päätettiin siirtää myös jatkokehitykseen. Tilaajan edustajien tavoitteena oli erityyppisen tutkimusdatan hallintajärjestelmä, mutta sovellus kykenee vain näyttämään erityyppistä liitedataa. Hallintajärjestelmä onkin puutteellinen tutkimusdatan muokkaamisen osalta, joten tilaajan tavoitteet saavutettiin osittain liitedatan hallinnan osalta.

% Sovelluksella pystyy merkitsemään karttaan kuvapisteitä, jotka visualisoivat siihen liitettyä tutkimusdataa. Kartan esittämisessä kuva-elementtinä on omat etunsa, sillä näytettävät kuva-elementit vastaavat tarkasti alkuperäisen kuvan resoluutiota. Tilaajan edustajat toivoivat kartan esittämistä matemaattisessa koordinaatistossa, mutta hallintajärjestelmä käsittelee liitoskohtia kuvapikselien tarkkuudella. Tilaajan edustajat toivoivat liitoskohtien merkitsemiseen pisteiden lisäksi tasoja ja suoria, joten liitedatan yhdistämisen tavoitteet toteutuivat vain osittain. Jatkokehitystä varten ohjelmaan suunniteltiin ja toteutettiin kolmiulotteisen tilakartan prototyyppi, joka tukee tasomaisia liitoskohtia. Tilakartan avulla kartan näyttäminen ja liitoskohtien merkitseminen tehtäisiin SharpGL-kirjaston tarjoamalla käyttöliittymän komponentilla vapaavalintaisesta kuvakulmasta. SharpGL-kirjasto kehitettiin alunperin Windows Forms -teknologialle ja sen dokumentaatio koostuu ainoastaan esimerkkikoodeista, joten jatkokehityksessä kannattaisi valita tietokonegrafiikan OpenGL-rajapinnaksi OpenTK-kirjasto ja käyttöliittymään sovittamista varten GLWpfControl-kirjaston komponentti.

% \textbf{Käyttöliittymää} koskevat vaatimukset muodostivat kolmannen tehtäväkokonaisuuden. Käyttäjä pystyy AvalonDock-kirjaston avulla vaikuttamaan ohjelman ajoaikana käyttöliittymän komponenttien määrään ja sijoitteluun, kuten tilaajan käyttämässä PerGeos-ohjelmassa. Liitedatat avataan erillisiin näkymiin eli käyttöliittymän komponentteihin, jotka käyttäjä pystyy halutessaan irrottamaan ja raahaamaan pääikkunan ulkopuolelle tai toiseen näyttöön, kuten kuten tilaajan edustajien käyttämässä Fiji-ohjelmassa. AvalonDock-kirjasto mahdollistaa sovelluksen käyttämisen em. ohjelmien tavoin, joten sovelluksen voidaan katsoa vastaavan tilaajan asettamia tavoitteita käyttöliittymän osalta. Jatkokehityksen kannalta pääikkunan toiminnallisuus on laajennettavissa toteuttamalla uusi AvalonDock-komponentti, esimerkiksi uudelle liitettävälle datatyypille. Käyttöliittymän komponentit voidaan siten helposti vaihtaa uuteen muuttamatta käyttöliittymän asemointia. Kuvapinon selaamiseen kehitetyllä liukusäätimellä käyttäjä pystyy helposti siirtymään aiemmin merkitsemäänsä liitoskohtaan. Karttanäkymää täydentävä kontrolleri sisältää myös säätimet karttanäkymän harmaasävyskaalan muuttamiseen. Liitedatat esitetään likusäätimen lisäksi hakulistassa, jota voidaan suodattaa ja järjestää esimerkiksi liitedatan nimen perusteella.

% Käyttöliittymän heikkoutena ovat modaalisesti uuteen ikkunaan avautuvat valikot, jotka eivät ole muiden pääikkunan komponenttien tavoin järjesteltävissä. Tällainen toteutusratkaisu rikkoo hieman käyttöliittymän suunniteltua rakennetta, mutta ongelma voidaan ratkaista jatkokehityksessä käyttämällä AvalonDock-kirjastoa modaalisten ikkunoiden asemesta.

\section{Sovelluksen toteutumattomat tavoitteet}
\label{ch:sovelluksen-toteutumattomat-tavoitteet}

Sovelluskehityksen vaatimuksien osalta uusien liitedatojen tyyppien lisääminen tai näyttäminen ei ole tehty kovinkaan helpoksi. Vaikka sovellus tukee uusien käyttöliittymän komponenttien lisäämistä, luokkarakenteen laajentaminen voi tuottaa ongelmia. Liitedatat eivät nimittäin toteuta mitään dokumentoitua rajapintaa, mikä edellyttää jatkokehittäjiltä rajapintojen suunnittelua. Tämä pyrittiin huomioimaan jatkokehittäjille suunnatuissa ohjeissa.

Raportointityökalun vaatimusten osalta raporttien tekeminen siirrettiin kokonaisuudessaan jatkokehitykseen. Raportointityökalut olivat alhaisen prioriteetin toimintoja, joiden toteuttaminen olisi edellyttänyt vaatimusmäärittelyn tarkentamista vähintäänkin raporttien sisällön, muotoilun ja tiedostomuodon osalta. Tämän tyyppisessä näytteiden analyysiä ja tutkimusdataa yhdistelevässä ohjelmistossa raportointityökalun rooli on työnkulun kannalta merkittävä. Raportit mahdollistaisivat tiedon saavutettavuuden myös ohjelman ulkopuolella.

Sovelluksen tallentamisen ja lataamisen vaatimusten osalta käyttäjä pystyy säilyttämään tekemänsä muutokset ohjelmassa, mutta toteutusratkaisu ei ole kuitenkaan taaksepäin yhteensopiva. Tekninen ohjaaja ehdotti keskitettyä tallennustoimintoa, joka päätettiin jättää jatkokehitykseen sovelluksen oltua muilta osin vielä keskeneräinen. Tästä syystä jatkokehityksessä tulee suunnitella ja toteuttaa järjestelmä, joka vastaa kokonaan ohjelman tilan tallentamisesta ja käyttää dokumentoitua tallennusmuotoa varmistamaan versioiden taaksepäin yhteensopivuus.

Suuri osa valinnaisista toiminnoista siirrettiin jatkokehitykseen. Vaikka toiminnot olivat projektin aikana valinnaisia, niiden perusteella kykenee hahmottamaan sovelluksen kehityssuunnan. Erityisesti vapaan kuvakulman toiminnot tulevat vaikuttamaan sekä tiedoston käsittelyyn että käyttöliittymään. Karttakuvia tulisi voida käsitellä vapaasta kuvakulmasta kopioimatta alkuperäistä kuvaa eri kuvakulmista. Vasta tämän jälkeen vapaata kuvakulmaa voidaan esittää käyttöliittymässä. Kolmiulotteisen tilakartan prototyyppikin kykenee esittämään karttakuvaa vain kolmesta eri kuvakulmasta. Niinpä kuvapinojen kopioiminen kovalevylle joudutaan valitettavasti myöhemmin korvaamaan toteutuksella, joka kykenee käsittelemään alkuperäistä karttakuvaa riittävän nopeasti sekä ilman tiedostokoon rajoitteita. Kaikista tärkein ja innovatiivisin ominaisuus jäi siten vielä toteuttamatta.

% Siirrä tämä kaikki sovellusraporttiin

% \textbf{Teknisten vaatimusten} osalta Linux- ja Mac-käyttöjärjestelmät jouduttiin rajaamaan toteutuksen ulkopuolelle toteutusvaiheen alussa, sillä WPF-teknologian käyttöehdot kielsivät ohjelman ajamisen ja kehittämisen muissa kuin Windows-käyttöjärjestelmissä. Linuxin ja Macin rajaaminen kehityksen ulkopuolelle oli tietoinen valinta, jonka tilaajan edustajat hyväksyivät. Geologian tutkimuskeskuksella kaikki todennäköiset käyttäjät ovat Windows-käyttäjiä, joten rajoituksesta ei koitune merkittävää haittaa. Jatkokehitystä ajatellen avoimen lähdekoodin sovellukselle olisi varmaankin kannattanut valita joustavampi ohjelmointikieli Java tai selaimella suoritettava komentokieli JavaScript. Jos ryhmän jäsenillä olisi ollut enemmän kokemusta Python-ohjelmien Qt-käyttöliittymistä, sekin olisi ollut huomionarvoinen vaihtoehto toteutuskieleksi. Pythonin käyttöön ei nimittäin liity myöskään käyttöympäristön rajoitteita. Suunnitteluvaiheessa tehtyjen päätösten rajoitteet paljastuivat vasta toteutusvaiheessa, jolloin suunnitteluun käytettyjen työtuntien jälkeen oli myöhäistä vaihtaa ohjelmointikieltä ja kartoittaa niille kehitettyjä kirjastoja.

% \textbf{Sovelluskehityksen} vaatimuksien osalta uusien liitedatojen tyyppien lisäämistä tai näyttämistä ei ole tehty kovinkaan helpoksi. Vaikka sovellus tukee uusien käyttöliittymän komponenttien lisäämistä, luokkarakenteen laajentaminen voi tuottaa ongelmia. Liitedatat eivät nimittäin toteuta mitään dokumentoitua rajapintaa, mikä edellyttää jatkokehittäjiltä rajapintojen suunnittelua. Tämä pyrittiin huomioimaan jatkokehittäjille suunnatuissa ohjeissa. Luokkarakenteen laajennettavuus onkin yksi tärkeimmistä jatkokehityskohteista, sillä luokkien vastuualueita voidaan selkeyttää rajapintojen avulla. Luokkarakenne suunniteltiin vain kerran toteutusvaiheen alkupuolella ja luokkasuunnitelmasta keskusteltiin teknisen ohjaajan kanssa ryhmän sisäisessä palaverissa. Esimerkiksi toisessa koodikatselmoinnissa tilaajan edustajat neuvoivat erottamaan karttatiedoston käsittelyssä tiedostokohtaiset ja niille yhteiset toiminnot toisistaan. Tilaajan edustajista Miettinen on ohjelmoinut vastaavaa toiminnallisuutta pi2-kirjastoon, josta olisi voinut ottaa enemmän mallia. Tilaajan edustajat ovat luultavasti sovelluksen ensimmäiset jatkokehittäjät, joten samankaltainen toteutusratkaisu olisi saattanut olla yhtenä lisämeriittinä.

% \textbf{Raportointityökalun} vaatimusten osalta raporttien tekeminen sovittiin tilaajan kanssa kokonaisuudessaan jatkokehitykseen. Raportointityökalut olivat alhaisen prioriteetin toimintoja, joiden toteuttaminen olisi edellyttänyt vaatimusmäärittelyn tarkentamista vähintäänkin raporttien sisällön, muotoilun ja tiedostomuodon osalta. Jatkokehityksessä raportointityökalun toteuttamisessa kannattaa aloittaa raporttipohjien määrittelystä, sillä käyttäjät tarvitsevat luultavasti erilaisia raporttipohjia käyttökohteesta riippuen.

% \textbf{Sovelluksen tallentamisen ja lataamisen} vaatimusten osalta käyttäjä pystyy säilyttämään tekemänsä muutokset ohjelmassa. Sovelluksen tilan tallentaminen toteutettiin serialisoimalla koko luokkarakenne JSON-muotoon. Toteutusratkaisu ei ole kuitenkaan taaksepäin yhteensopiva, joten luokkarakenteen muuttamisen jälkeen vanhaa JSON-tiedostoa ei voida avata uudella versiolla. Tällä hetkellä tallennustoiminto on hajautettu koko luokkarakenteeseen, sillä jokainen luokka on vastuussa omasta serialisoinnistaan. Tekninen ohjaaja ehdotti keskitettyä tallennustoimintoa, joka päätettiin jättää jatkokehitykseen sovelluksen oltua muilta osin vielä keskeneräinen. Tästä syystä jatkokehityksessä tulee suunnitella ja toteuttaa järjestelmä, joka vastaa kokonaan ohjelman tilan tallentamisesta ja käyttää dokumentoitua tallennusmuotoa varmistamaan versioiden taaksepäin yhteensopivuus.

\section{Toteutetun sovelluksen rakenne}

Sovellus rakentuu kolmiulotteisen matriisimuotoisen harmaasävykuvan ympärille, johon yhdistetään muuta tutkimusdataa ikään kuin kartaksi. Suuresta karttatiedoston koosta johtuen kuvapinoja vältetään lukemasta kokonaan muistiin. Kuvapinot tallennetaan kovalevylle kolmesta eri katselukulmasta, jolloin kuvien selaaminen on nopeaa. Kaksiulotteiset kuvat näytetään käyttöliittymässä valitusta syvyydestä. Käyttäjä voi myös tarkentaa ja kohdentaa kuvia vierityspalkkien avulla sekä määrittää kuvien harmaasävyskaalan. Kuvankäsittely tapahtuu nopeasti ajoaikana eivätkä muutokset vaikuta alkuperäiseen karttatiedostoon.

Kuvassa \ref{fig:arkkitehtuurisuunnitelma} esitetään sovelluksen arkkitehtuuri käyttäen luvun \ref{ch:termit} vakiintunutta sanastoa. Arkkitehtuuri on jaettu karkeasti käyttöliittymään ja luokkarakenteeseen. Käyttöliittymän osalta noudatettiin MVVM-arkkitehtuuria (\textit{Model-View-ViewModel}), jonka mukaisesti käyttöliittymän elementit sidottiin ohjelman sisältämiin tietorakenteisiin. Käyttöliittymän ja niin kutsutun näkymämallin sitominen erottaa menetelmän perinteisestä tapahtumalähtöisestä MVC-arkkitehtuurista (\textit{Model-View-Controller}). Luokkarakenne on taas käyttöliittymästä erillinen projekti, joka noudattaa kerrosarkkitehtuuria. Kuvassa \ref{fig:arkkitehtuurisuunnitelma} kuvataan luokkarakenteen tasolla sovelluksessa esiintyvien muuttujien suhteita, mikä muodostaa sovelluksen arkkitehtuurisuunnitelman.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/arkkitehtuurisuunnitelma_0.4.1.pdf}
    \caption{Sovelluksen rakenne ja arkkitehtuuri.}
    \label{fig:arkkitehtuurisuunnitelma}
\end{figure}

\FloatBarrier

% Siirretään sovellusraporttiin

Valinnaisten vaatimusten osalta sovellukseen suunniteltiin ja toteutettiin kolmiulotteisen tilakartan prototyyppi. Tilakarttaa suunniteltiin projektin alkuvaiheista lähtien, mutta prototyyppi saatiin toteutettua vasta projektin väliesittelyn jälkeen toukokuun alussa. Muutokset olisivat vaikuttaneet merkittävästi sovelluksen rakenteeseen, joten kolmiulotteinen tilakartta päätettiin siirtää jatkokehitykseen. Tilakartan avulla käyttäjä voisi tarkastella karttaa PerGeos-ohjelman tavoin vapaavalintaisesta kuvakulmasta. Fiji-ohjelman kaltainen vapaavalintainen leikkauskuvan ja näyttäminen edellyttäisi karttatiedoston lataamista kokonaan muistiin, mikä jätettiin toteuttamatta. Ennen tilakartan suunnittelua ja toteuttamista oli vielä epäselvää voisiko sellaista ylipäänsä toteuttaa kohtuullisessa ajassa tai soveltuisiko sellainen suorituskykynsä puolesta käytettäväksi. Vaikka prototyyppi rajattiin toteutuksen ulkopuolelle, sillä saatiin vahvistettua merkittävän jatkokehitysidean toteuttamiskelpoisuus.

\section{Dokumentit ja muut materiaalit}
\label{ch:dokumentit-ja-muut-materiaalit}

Sovelluksen lisäksi projektiryhmä toteutti seuraavat tulokset:

\begin{compactitem}
    \item \textbf{Ajankäyttöraportti} sisältää ryhmän jäsenten työtunnit, sekä niiden jakautumisen eri tehtäväkokonaisuuksille ja tehtäville.
    \item \textbf{Arkkitehtuurisuunnitelma} sisältää korkean tason kuvauksen ohjelmiston rakenteesta käyttäen projektin vakiintunutta termistöä.
    \item \textbf{Esittelymateriaali} sisältää väliesittelyn esitysgrafiikan. Sovellusprojektin aikana järjestettiin yksi esittelytilaisuus.
    \item \textbf{Itsearvioinnit} sisältävät ryhmän jäsenten arviot omasta toiminnastaan, kokemuksistaan ja oppimisestaan projektin aikana. Ryhmän jäsenet päättävät itsenäisesti sijoitetaanko heidän itsearviointinsa julkiseen projektikansioon.
    \item \textbf{Kehitysympäristön pystytysohjeet} sisältävät ohjeet ryhmän käyttämän kehitysympäristön käyttöönottoon jatkokehityksen helpottamiseksi. Jatkokehittäjille suunnatut ohjeet päätettiin sisällyttää sovellusraporttiin.
    \item \textbf{Käyttöliittymäsuunnitelma} sisältää sovelluksen päänäkymän ja sen sisältämien komponenttien näkymät.
    \item \textbf{Käyttöohjeet} sisältävät kuvauksen käyttöliittymästä ja neuvovat, miten sovellusta käytetään. Käyttöohjeessa esitettiin käyttäjien työnkulun vaiheet luonnollisessa järjestyksessä sekä mahdolliset käyttäjiin vaikuttavat rajoitteet.
    \item \textbf{Luokkadokumentaatio} generoidaan automaattisesti lähdekoodin sisältämistä dokumentaatiokommenteista.
    \item \textbf{Luokkasuunnitelma} sisältää ohjelmiston sisäisen rakenteen kuvattuna UML-notaation kaltaisena luokkakaaviona.
    \item \textbf{Lähdekoodi} sisältää sovelluksen lähdekoodin kommentteineen.
    \item \textbf{Palaverien dokumentit} sisältävät palaverien esityslistat, tilakatsaukset ja pöytäkirjat.
    \item \textbf{Projektiraportti} kuvaa projektin toteutunutta läpivientiä, jota verrataan projektisuunnitelmaan kuvaten poikkeamien syitä ja vaikutuksia.
    \item \textbf{Projektisopimus} sisältää projektin sopimusehdot mukaanlukien lähdekoodin ja muiden tulosten lisensointiehdot.
    \item \textbf{Projektisuunnitelma} on projektin läpivientiä kuvaava suunnitelma, jossa kuvataan projektin tavoitteet sekä projektinhallinnan keinot tavoitteiden saavuttamiseksi.
    \item \textbf{Sovellusraportti} kuvaa toteutetun sovelluksen keskeiset toteutusratkaisut ja mahdolliset jatkokehitysideat. Lisäksi sovellusraportti sisältää ohjeet kehitysympäristön pystyttämiseen ja käyttöliittymän kuvauksen.
    \item \textbf{Sähköpostiarkistot} sisältävät projektin yhteisille sähköpostilistoille lähetetyt sähköpostiviestit sekä ryhmän jäsenten ja ohjaajien väliseen viestintään suunnatun sähköpostilistan sähköpostiviestit.
    \item \textbf{Testausraportit} kuvaavat eri testauskerroilla suoritettujen testitapausten havaintojen kuvaukset mukaan lukien perustelut ja jatkotoimenpiteet havaittujen virheiden osalta.
    \item \textbf{Testausraporttipohja} on lomake, johon testauskerran huomiot kirjataan. Täydennetty raporttipohja julkistetaan testausraporttina.
    \item \textbf{Testaussuunnitelma} kuvaa testausympäristön kokoonpanon ja suoritettavat testitapaukset.
    \item \textbf{Vaatimusmäärittely} sisältää sovellukseen kehitettävät tiedot ja toiminnot vaatimuksina sekä niiden prioriteetit ja tilat projektin päättyessä
    \item \textbf{Valmisohjelma} sisältää ajettavan ohjelman
    sekä tarvittavat ohjelmakirjastot yhdessä kansiossa.
    \item \textbf{Verkkoesite} sisältää projektin WWW-esittelyn.
\end{compactitem}

Kääntö-, asennus-, käyttö- ja kehitysympäristön pystytysohjeet suunniteltiin koostettavan yhteen kattavaan käyttäjien manuaaliin. Projektissa ei tarvinnut laatia erillistä asennusohjetta, sillä valmisohjelma sisältää kaiken tarvittavan sovelluksen käyttöönottoon. Valmisohjelmasta tehtiin jakelupaketti, josta ajettava ohjelma voidaan asentaa tietokoneelle. Käännösohjeet sisällytettiin kehitysympäristön pystytysohjeisiin, sillä kehitysympäristön toimivuus oli helpointa todentaa käännettävällä ohjelmalla.

Sovellusta kehitettiin Microsoftin Visual Studiolla, jonka sisältämän nuget-pakettihallinnan kautta ulkoiset kirjastot saatiin liitettyä helposti mukaan valmisohjelmaan. Kehitysympäristön pystytysohjeet sisällytettiin sovellusraporttiin \cite{sovellusraportti} erillisten ohjeiden sijaan. Jatkokehityksessä voisi olla järkevää kääntää kirjastot lähdekoodista ilman nuget-pakettihallintaa, jotta kirjastopäivityksiä voidaan ylläpitää hallitusti.

Käyttöohjeet päädyttiin sijoittamaan versiohallintaan HTML-dokumenttina, joka tulee valmisohjelman mukana ja avautuu lokaalisti sovelluksen \textit{Help}-valikosta käyttäjän oletusselaimeen. Käyttöohje kirjoitettiin kaikista muista dokumenteista poiketen englanniksi. Sovellusraportista löytyvät vastaavat käyttöliittymän kuvaukset suomeksi.

Ryhmän jäsenet sitoutuivat sijoittamaan lähdekoodin kommentteineen avoimen lähdekoodin MIT-lisenssin alle ja muut tulokset avointen dokumenttien CC BY 4.0 -lisenssin alle. Projektipäällikön laatimaa erillistä lisenssisitoumusta ei tarvittu, sillä lisenssisitoumus sisällytettiin projektisopimukseen. Lähdekoodin ja luokkadokumentaation paperitulosteet sovittiin rajattavan pois projektikansiosta, sillä ajantasaiset versiot molemmista sijaitsevat versiohallinnassa. Ryhmän jäsenien tuntimääriä koskeva ajankäyttöraportti sisällytettiin projektikansioon. Tulokset saatiin toteutettua pääosin suunnitellusti, mutta sovelluksen ohjeissa jouduttiin tekemään rajauksia.

\section{Oppimistavoitteet}

Projektiryhmän jäsenten oppimistavoitteet toteutuivat
suunnitellusti. Projekti toteutettiin osana Jyväskylän yliopiston informaatioteknologian tiedekunnan Sovellus\-projekti-nimistä projektiopintojaksoa. Projektin päätyttyä projektiryhmän jäsenet tuntevat sovellusprojektin keskeiset projektinhallinnan menetelmät ja osaavat soveltaa niitä käytännön projektityössä.

Keskeiset projektinhallinnan menetelmät olivat

\begin{compactitem}
    \item projektin suunnittelu, seuranta ja edistymisen raportointi,
    \item projektin ohjaus, ryhmätyöskentely ja viestintä,
    \item projektin virallisten dokumenttien tuottaminen ja niiden hallinta sekä
    \item projektin muutosten ja riskien hallinta.
\end{compactitem}

Kaikilla projektiryhmän jäsenillä oli entuudestaan ohjelmointikokemusta. Projektin loputtua jäsenet osaavat valita tavoitteiden kannalta sopivimmat toteutustyökalut sekä käyttää niitä toteutusprojektin edellyttämässä laajuudessa. Projekti antoi myös selkeyttä siihen, haluavatko projektin jäsenet tulevissa projekteissa toimia asiantuntijan vai projektipäällikön tehtävissä.

\chapter{Resurssit}
\label{ch:resurssit}

Luvussa käsitellään sovellusprojektin jäsenet ja ohjaajat sekä tilaajan edustajat. Luvussa kuvataan myös projektissa käytössä olleita tiloja, laitteita ja kehitystyökaluja. Projektin resurssit toteutuivat projektisuunnitelmaan kirjatulla tavalla.

\section{Projektiorganisaatio}

Projektiorganisaatio toteutui suunnitellusti. Projektiryhmään kuuluivat Iiro Iivanainen,\\ Harri Linna, Jere Pakkanen ja Riikka Vilavaara. Kaikki jäsenet ovat tietotekniikan maisteriopiskelijoita ohjelmisto- ja tietoliikennetekniikan maisteriohjelmassa. Harri Linna toimi projektipäällikkönä ja Jere Pakkanen varapäällikkönä.

Kaikilla projektiryhmän jäsenillä oli entuudestaan ohjelmointikokemusta, mutta projektiryhmän kokemus kyseessä olevan kokoluokan sovellusprojektista sekä siihen liittyvästä projektityöskentelystä oli vähäistä. Sovellusprojektin oheiskursseilla käsiteltiin kuitenkin projektin läpiviennin ja hallinnan taitoja sekä viestintätaitoja, joita projektissa hyödynnettiin ahkerasti.

C\#-ohjelmointikieli oli kaikille ryhmän jäsenille tuttu ennestään. Kehitettävä ohjelmisto koostui kolmesta osasta, joihin kehitystiimin jäsenet erikoistuivat. Kukin jäsen kehitti pääosin yksinään hänen vastuullaan olleita sovellusosioita. Linna keskittyi projektinhallintaan ja dokumenttien laatimiseen. Iivanainen keskittyi liitedatan ja metatietojen hallintaosion kehittämiseen. Pakkanen keskittyi puolestaan kolmiulotteisten karttatiedostojen käsittelyyn ja säikeistämiseen. Vilavaara keskittyi MVVM-arkkitehtuurin mukaisen käyttöliittymän toteuttamiseen.

Tilaajaorganisaatio oli Geologian tutkimuskeskus ja tilaajan edustajat olivat Jukka Kuva ja Arttu Miettinen. Kuva toimii Geologian tutkimuskeskuksella tutkijana. Miettinen toimii Jyväskylän yliopiston fysiikan laitoksella tutkijana.

Projektin vastaavana ohjaajana toimi informaatioteknologian tiedekunnalta Jukka-Pekka\\ Santanen ja teknisenä ohjaajana Juuso Tuononen. IT-palvelut perustivat projektin käyttöön verkkolevyt ja asettivat projektin jäsenille rajattoman tulostuskiintiön.

Sovellusprojekti-kurssin yhteydessä järjestettävän \textit{Projektiviestintä IT-alalla} -kurssin puheviestinnän opettajana toimi Hanna Kivimäki ja kirjoitusviestinnän opettajana Katja Kontturi. \textit{Sovellusprojektin hallintaa, viestintää ja työkaluja} -kurssin opettajana toimi Jukka-Pekka Santanen. Käytettävyyspäivää ei järjestetty ja kolmesta suunnitellusta esittelystä järjestettiin ainoastaan ensimmäinen väliesittely.

% MARGINAALIT KATSOTTU TÄHÄN ASTI

\section{Tilat ja laitteet}
\label{ch:tilat-ja-laitteet}

Projektin käytössä oli WWW-sivusto, verkkolevy, kaksi sähköpostilistaa ja rajaton tulostuskiintiö yliopiston tilojen koronarajoituksista johtuen. Projektiryhmälle varatut työhuoneet AgC417.1 ja AgC418.1 eivät olleet jäsenten käytettävissä, joten ryhmän jäsenet toteuttivat sovelluksen etänä käyttäen henkilökohtaisia tietokoneitaan. Sovellus kehitettiin pääosin Windows-käyttöjärjestelmällä.

Sovellusprojekti-kurssin yhteiset tapaamiset järjestettiin Teams-palvelun kautta videopuheluina. Niin ikään etäpalaverit järjestettiin Teams-videopuheluina Arttu Miettisen kutsusta, sillä opiskelijoilla oli rajoitetut oikeudet kalenteritapahtumien järjestämiseen. Projektiryhmä käytti ryhmän sisäisten dokumenttien jakamiseen kurssin etätyöskentelytilan sisältämää Teams-kanavaa, joka mahdollisti Office356-palvelun käyttämisen. Esimerkiksi työajanseurantalomakkeen päivittäminen tehtiin kätevästi Excelin verkkoversiolla.

Maaliskuussa ensimmäisen \textit{Projektiviestintä IT-alalla} -kurssin kahvilatapaamisen aikaan ryhmän jäsenet siirtyivät käyttämään Discord-palvelua. Ryhmä kokoontui noin kolmesti viikossa keskustelemaan projektin tilanteesta ja seuraavan tapaamisen ajankohdasta ja tavoitteista. Discord-palveluun siirtymisen jälkeen viestittely keskustelualueella lisääntyi merkittävästi Teams-palveluun verrattuna. Aluksi ryhmän jäsenet olivat hieman vastahakoisia ottamaan Discord-palvelua käyttöön henkilökohtaisilla tunnuksillaan, mutta kahvilatapaamisen jälkeen päätettiin ottaa uusi viestintäkanava käyttöön, kun asiasta keskusteltiin uudelleen.

\section{Kehitystyökalut}
\label{ch:kehitystyokalut}

Projektissa kehitetyn sovelluksen ohjelmointikielenä käytettiin C\#:n versiota 8.0 ja ohjelmistokehyksenä .NETin versiota 5.0. Kehitysympäristöinä käytettiin Visual Studio 2019 -ja Visual Studio Code -ohjelmia. Graafinen käyttöliittymä toteutettiin sovelluskehyksellä WPF (Windows Presentation Foundation). Versiohallintaan käytettiin yliopiston GitLab-versio\-hallinta\-järjestelmää. Luokkadokumentaatio suunniteltiin muodostettavan suoraan lähdekoodista käyttäen DocFX- tai Doxygen-työkalua. Luokkadokumentaatiota ei kuitenkaan lopulta muodostettu, mistä sovittiin tilaajan edustajien ja ohjaajien kanssa.

Kehitystyökalut toteutuivat suunnitellusti, mutta työkaluja olisi kannattanut kokeilla käytännössä heti suunnitteluvaiheessa. C\#-ohjelmointikieli valittiin jäsenten aiemman kokemuksen ja WPF-käyttöliittymän perusteella. Tästä seurasi kuitenkin merkittävä rajoite, että sovellusta kehitettäisiin ja ajettaisiin jatkossa vain Windows-ympäristössä. Tilaajan edustajat hyväksyivät kyseisen ratkaisun. Lisäksi Agoran mikroluokkien tietokoneisiin oli asennettuna vanhempi .NET 3.1, joten sovellusta ei voinut myöskään kehittää tai ajaa yliopiston mikroluokissa. Ohjelmointikielen valinnan jälkeen kartoitettiin erilaisia ohjelmakirjastoja, joita hyödyntäen olisi voitu toteuttaa karttatiedostojen lukemisen ja käyttöliittymän ikkunoinnin.

Sopivien kirjastojen Magick.NET ja AvalonDock löydyttyä siirryttiin välittömästi toteutusvaiheeseen 11.3.2021. Koska sovellus tulisi olemaan riippuvainen näistä kriittisen toiminnallisuuden tarjoavista kirjastoista, ohjelmointikieltä ei ollut enää kannattavaa muuttaa jälkeenpäin. Erottamalla WPF-käyttöliittymä ja sovelluksen luokkarakenne erillisiin .NET-projek\-teihin, kirjastojen valinnan aiheuttamien riippuvuuksien vaikutuksia pystyttiin kuitenkin vähentämään. Samaan tapaan luotiin MSTest-projekti kehityksenaikaista yksikkötestaamista varten sekä WPFOpenGL-projekti kolmiulotteista tilakarttaa varten. Erillisillä projekteilla saatiin tehostettua kehitystyökalujen käyttöä. Kehitysympäristön ja -työkalujen rajoituksista huolimatta sovellus toteutui suunnitellusti.

\section{Dokumentointityökalut}
\label{ch:dokumentointityokalut}

Dokumenttien kirjoittamiseen käytettiin toimisto-ohjelmistona LibreOfﬁcea ja Overleaf-pal\-velua. Sovelluksen käyttöliittymäsuunnitelma hahmoteltiin GIMP-kuvankäsittelyohjelmal\-la ja sovelluksen rakennetta kuvaavat kaaviot diagrams.net-palvelussa, joka kuuluu nykyään Office365-verkkopalveluun. Vastaavasti dokumenttien kommentointiin käytetty Kami-palvelu kuuluu Googlen pilvipalveluihin, johon yliopiston tunnukset oikeuttavat rajattoman tallennustilan. Tietokoneen kovalevyn kautta muokattavat tiedostot kannattaakin ilman muuta säilyttää pilvipalvelussa, jonka kautta onnistuu myös dokumenttien muokkaaminen.

Overleaf-palvelu toimii dokumentointityökaluna erinomaisen hyvin, sillä kaikki dokumentit olivat muokattavissa verkossa yhdessä paikassa. Dokumenttien tarkastamisessa käytettiin Kami-palvelua, jolla voidaan tehdä merkintöjä suoraan pdf-dokumenttiin. Kami-palve\-lu tarjoaa siis saman toiminnallisuuden kuin toimisto-ohjelmien versiohistoria, mutta pdf-dokumentteja ei tarvitse muuntaa docx- tai odt-tiedostoiksi, missä saatetaan kadottaa muotoiluja tai jopa tekstiä. Overleaf-palvelun kautta voidaan myös varmuuskopioida dokumentteja yliopiston GitLab-versiohallintaan. Projektin aikana dokumenttien versiohallintaa ei tarvittu, mutta sitä kannattaa ehdottomasti käyttää, jos useampi henkilö tekee muutoksia samaan dokumenttiin. Vanhan tekstin kommentteihin siirtämisen sijaan voidaan tehdä heti muutoksia alkuperäiseen, sillä edelliseen versioon voidaan aina palata muutoshistorian ja versiohallinnan aikaleiman perusteella. Overleaf-, GitLab- ja Kami-palvelut toimivat hyvin yhteen kirjoittamisen teknisenä työympäristönä ilman erillisiä ohjelmistoasennuksia.

Sovellusprojektin alkuperäiset dokumenttipohjat olivat edelleen ajankohtaisia, mutta ne vaatisivat pientä päivitystä vastaamaan viime vuosien aikana hioutuneita hyviä käytänteitä. Overleaf-palvelu soveltuu erinomaisesti teknisten raporttien kirjoittamiseen, kunhan dokumenttipohjat ovat ajan tasalla. Projektiraporttien Liikkuva \cite{liikkuva}, Peltihamsteri \cite{peltihamsteri} ja Potku \cite{potku} rakenteet ja tekstikappaleet olivat nimittäin melkein identtiset, joten Sovellusprojektin alkuperäiset dokumenttipohjat kannattaisi päivittää ainakin rakenteen ja ulkoasun muotoilujen osalta.

Projektin aikataulu laadittiin GanttProject-ohjelmistolla ja työajanseurantaan käytettiin Petri Heinosen kehittämää Excel-työkirjaa. Gantt\-Project-ohjelman sijaan olisi kannattanut hyödyntää valmista Excel-lomakepohjaa samaan tapaan kuin ajankäytönseurannassa. Tällöin suunnitelmien ylläpitäminen projektin aikana olisi vienyt vähemmän aikaa ja taulukkolaskentaohjelmalla olisi voinut koostaa monipuolisia kaavioita tilakatsauksiin. Tilakatsaukset olisi kannattanut latoa Beamer-paketilla.

Ryhmän jäsenet jakoivat toisilleen runsaasti tex-tiedostoista käännettyjä pdf-dokumentteja kommentoitavaksi. Raakatekstin ja ranskalaisten viivojen sijaan korjausehdotusten merkitseminen tarkastettavaan dokumenttiin olisi säästänyt merkittävästi työtunteja sekä kirjoittajalta että tarkistajalta.

\section{Luennot ja perehdytykset}
\label{ch:luennot-ja-perehdytykset}

Luennot ja perehdytykset toteutuivat suunnitellusti. Sovellusprojektin ohella kaikki ryhmän jäsenet suorittivat molemmat oheiskurssit. Näillä kursseilla opittiin projektinhallintaan ja projektiviestintään liittyviä taitoja. Oheiskurssien työtunnit kirjattiin työajanseurantaan erillisenä tehtäväkokonaisuutena.

\textit{Projektiviestintä IT-alalla} -kurssin suoritettuaan opiskelija:
\begin{compactitem}
    \item ymmärtää viestinnän ja vuorovaikutuksen merkityksen projektityöskentelyssä,
    \item tuntee projektiviestintään liittyviä tekstilajeja ja niiden konventioita,
    \item osaa laatia keskeisimmät projektissa tarvittavat dokumentit,
    \item tuntee projektipalavereihin liittyviä käytänteitä,
    \item osaa valita tilanteeseen sopivan tavan viestiä projektin eri vaiheista sekä
    \item tuntee projektityöskentelyyn liittyviä ryhmä- ja vuorovaikutusilmiöitä.
\end{compactitem}

\textit{Sovellusprojektin hallintaa, viestintää ja työkaluja} -kurssi sisälsi seuraavat luennot:
\begin{compactitem}
    \item aloitusluento,
    \item vaatimusmäärittely,
    \item versiohallinta,
    \item projektinhallinta ja johtaminen,
    \item tekijänoikeusluento.
\end{compactitem}

Dokumentointityökaluista aikataulun ja tehtävienhallinnan suunnitteluun olisi kaivattu perehdytystä, sillä projektinhallinnan kannalta ne olivat tärkeimmät projektipäällikön työkalut. Dokumentointityökaluista toimisto-ohjelmien versiohistoriaan ja muokkaustyökaluihin olisi kaivattu perehdytystä.

\chapter{Käytänteet}
\label{ch:kaytanteet}

Luvussa kuvataan projektin käytänteitä, jotka edesauttoivat projektin läpivientiä, asetettujen tavoitteiden saavuttamista ja tulosten toteuttamista. Käytänteissä ei tapahtunut merkittäviä muutoksia suunniteltuun verrattuna. Käytänteissä olisi ollut runsaasti parantamisen varaa ja projektipäällikön olisi kannattanut nähdä enemmän vaivaa niiden suunnitteluun. Käytänteet oli kirjattu projektisuunnitelmaan liian tiivistetysti, mikä saattoi hankaloittaa yhteisten toimintatapojen omaksumista ja noudattamista.

Sovelluksen suunnittelu olisi kannattanut rajata jo projektin alussa ohjelmoijien vastuualueeksi, sillä he toteuttivat sovelluksen. Projektipäällikön olisi kannattanut keskittyä projektin läpiviennin suunnitteluun enemmän. Toisaalta projektipäällikön on vaikea suunnitella tehtävienjakoa, ellei hänellä ole selkeää kokonaiskäsitystä sovelluksen rakenteesta, mikä edellyttää väistämättä suunnitteluun ja toteutukseen osallistumista.

\section{Palaverit}
\label{ch:palaverit}

Palavereja pidettiin aluksi viikon välein projektin määrittely- ja suunnitteluvaiheessa. Kun projekti eteni toteutusvaiheeseen ja tapaamistarve väheni, palavereja pidettiin enää noin kahden viikon välein. Seuraavan palaverin ajankohta päätettiin aina edellisessä palaverissa. Palavereihin osallistuivat kaikki projektiryhmän jäsenet, ohjaajat ja tilaajan edustajat. Palaverit todettiin laillisiksi, jos niiden esityslistat lähetettiin projektiorganisaatiolle vähintään vuorokautta ennen kyseisen palaverin alkua. Palaveri todettiin päätösvaltaiseksi, jos paikalla oli vähintään yksi projektiryhmän edustaja, yksi tilaajan edustaja ja vastaava ohjaaja.

Palavereissa käsiteltiin edellisen palaverin pöytäkirja, projektipäällikön tilakatsaus (ensimmäistä palaveria lukuun ottamatta), seuraavan palaverin ajankohta, läsnäolijoille sovitut toimenpiteet ja mahdolliset muut esille tulleet asiat. Palavereissa keskusteltiin kehitettävän sovelluksen suunnitteludokumenteista ja toteutusratkaisuista sekä esiteltiin kehitettävän sovelluksen toimintaa. Palavereissa keskusteltiin erityisesti tomografiakuvien käsittelyyn liittyvistä asioista. Keskustelun aikana tehdyt päätökset kirjattiin pöytäkirjaan, josta sovellukseen kehitettävien tietojen ja toimintojen kuvaus kopioitiin myöhemmin vaatimusmäärittelyyn.

Ryhmän jäsenten roolit palavereissa muodostuivat niin, että projektipäällikkö Linna ja varaprojektipäällikkö Pakkanen vuorottelivat puheenjohtajan tehtävässä. Puheenjohtaja johti keskustelua ja huolehti esityslistan mukaisesta keskustelun etenemisestä. Iivanainen ja Vilavaara vuorottelivat sihteerin tehtävässä, johon kuului palaverin muistion ja pöytäkirjan laatiminen. Jokainen jäsenistä toimi vähintään kerran sekä sihteerinä että puheenjohtajana. Puheenjohtaja tarkasti ja hyväksyi sihteerin laatiman pöytäkirjan ennen sen julkistamista projektiorganisaatiolle. Esityslistat laadittiin projektiryhmän tapaamisissa, joiden aikana laadittiin viikoittainen tilakatsaus ja tehtävienhallinnan tehtävät.

Palaverien pöytäkirjojen laatimiseen käytettiin Overleaf-palvelua. Muita yhteisiä käytänteitä ei sovittu muistioiden tai pöytäkirjojen laatimisesta. Erillisen dokumenttiluokan puuttuessa mallipohjana käytettiin edellisen palaverin pöytäkirjaa, jonka rakenne ja muotoilut vaihtelivat sihteerinä toimineen henkilön mukaan. Tästä syystä projektiryhmän olisi kannattanut käyttää yhteistä työtilaa Overleaf-palvelussa, joka toimii erinomaisena kirjoittamisen työympäristönä ilman erillisiä ohjelmistoasennuksia. Yhteisten käytänteiden puuttumisesta huolimatta pöytäkirjat olivat korkealaatuisia ja vain yksi muistio kadotettiin projektin aikana.

Etätyöskentelyn vuoksi ryhmän tapaamisia järjestettiin Teams- tai Zoom-palvelussa aluksi kerran viikossa. Näitä palveluja jäsenet olivat tottuneet käyttämään muiden kurssien etätapaamisissa. Toteutusvaiheen alkaessa ryhmän tapaamiset siirtyivät Discord-palveluun, jonka seurauksena tapaamisten määrä kasvoi kolmeen kertaan viikossa. Myöhemmin huomattiin, että kaksi tapaamista viikossa riitti mainiosti. Tekninen ohjaaja kutsuttiin muutaman kerran projektiryhmän suulliseen neuvonpitoon. Muun aikaa hän oli nopeasti tavoitettavissa viestiyhteyden päässä.

\section{Tiedotus}
\label{ch:tiedotus}

Tiedotuksen osalta noudatettiin projektisuunnitelmaan kirjattuja käytänteitä. Projektipäällikkö vastasi ensisijaisesti tiedotuksesta projektiorganisaatiolle. Projektiryhmän ulkoisessa viestinnässä jäsenet vastasivat omien vastuualueidensa viestinnästä. Projektiryhmän sisäisessä viestinnässä jäsenet raportoivat työmäärät, töiden etenemisen ja mahdolliset ongelmat projektipäällikölle. Projektiin liittyvistä valinnoista, muutoksista ja vaihtoehtoisista toteutusratkaisuista keskusteltiin pääasiassa projektipalavereissa. Projektipäällikkö toimitti projektiorganisaatiolle tilakatsauksen sähköpostitse sellaisina viikkoina, jolloin ei pidetty projektipalaveria.

Projektiorganisaation tiedottamista varten perustettiin kaksi sähköpostilistaa, joiden viestit tallentuivat sähköpostiarkistoihin. Sähköpostilistat ja niiden arkistot kuvataan dokumentin metatiedoissa ennen sisällysluetteloa. Ensisijainen sähköpostilista oli tarkoitettu viestintäkanavana koko projektiorganisaatiolle suunnattuun tiedotukseen. Vastaanottajiin kuuluivat ryhmän jäsenet, ohjaajat ja tilaajan edustajat. Toinen sähköpostilista oli tarkoitettu opetuskäyttöön lähinnä ryhmän jäsenten ja ohjaajien väliseen viestintään. Maaliskuun jälkeen kyseistä listaa ei juurikaan käytetty, sillä useimmat sähköposteista koskivat myös tilaajan edustajia.

Tiedotus toteutui ilman suurempia ongelmia, mutta aktiivisempi sähköpostiviestintä olisi tehnyt ryhmän toiminnasta läpinäkyvämpää. Esimerkiksi tilaajan edustajat mainitsivat muutaman kerran, että asioista voi kysyä myös sähköpostitse ennen seuraavaa palaveria. Vastaava ohjaaja joutui muutaman kerran kysymään palauttamattomien tulosten perään. Toteutusvaiheen loppupuolella projektiorganisaatio kutsuttiin seuraamaan projektiryhmän tehtävienhallintaa, minkä seurauksena ryhmän jäsenet alkoivat käyttää tehtävienhallintaa enemmän. Projektiryhmän sisäinen tiedotus tapahtui alkuun Teams-työtilassa. Ensimmäisen \textit{Projektiviestintä IT-alalla} -kurssin kahvilatapaamisen aikoihin, joka järjestettiin etätapaamisena, projektiryhmä siirtyi käyttämään Discord-palvelua. Discord-kanavan perustamisen jälkeen ryhmä kääntyi useammin teknisen ohjaajan puoleen koodauksen aikana.

\section{Tiedostojen nimeäminen}
\label{ch:tiedostojen-nimeäminen}

Lähdekooditiedostojen nimeämisessä käytettiin C\#-ohjelmointikielen yleisiä käytänteitä \cite{nimeamiskaytanteet}. Hakemistot ja tiedostonimet kirjoitettiin englanniksi. Lähdekoodi ja sen kommentit kirjoitettiin englannin kielellä käyttäen UTF-8-merkistöä.

Dokumentit nimettiin sisältöä kuvaavilla nimillä ja dokumentin kielen mukaisesti. Tiedostonimet kirjoitettiin pienillä kirjaimilla ja välilyöntien sijaan käytettiin alaviivoja. Dokumenttien nimiin lisättiin versionumero luvun \ref{ch:versiohallinta-ja--numerointi} käytänteiden mukaisesti.

Esimerkit ovat palaverien dokumenteista:
\begin{compactitem}
    \item \texttt{esityslista\_2021-03-05.txt}
    \item \texttt{groundhog\_palaveri11\_08\_6\_2021.pdf}
    \item \texttt{tilakatsaus26.pdf}
\end{compactitem}

Esimerkit ovat sovellusprojektin dokumenteista:
\begin{compactitem}
    \item \texttt{vaatimusmaarittely\_0.5.0.pdf}
    \item \texttt{TestauskerranSuunnitelma\_0.3.3.pdf}
    \item \texttt{groundhog\_sovellusraportti\_0.1.0.pdf}
\end{compactitem}

Dokumenttien nimeämiskäytänteet vaihtelivat suuresti. Projektin nimi jätettiin monesti merkitsemättä, sillä asiayhteys vaikutti selvältä. Tiedostonimessä saatettiin käyttää välilyöntien tilalla alaviivaa tai suuraakkosia. Versionumeron sijaan saatettiin käyttää päivämäärää, viikkonumeroa tai juoksevaa järjestysnumeroa. Harvemmin nimiä kuitenkaan muokattiin jälkeenpäin siitä syystä, että dokumentit jaettiin projektiorganisaatiolle sähköpostitse hyperlinkkien avulla. Muutokset olisivat tehneet linkeistä lukukelvottomat. Käytännössä sallittiin dokumenttikohtaiset käytänteet, kunhan niissä pysyttiin jatkossakin. Projektikansion koostamisen yhteydessä tarkistettiin ovatko tiedostonimet yhteneviä ja asianmukaisia käyttötarkoituksiinsa.

\section{Hakemistorakenne}
\label{ch:hakemistorakenne}

Projektin tulokset tallennettiin CD-levylle ja sijoitettiin WWW-sivuille päähakemiston alle listauksen \ref{lst:hakemistorakenne} hakemistorakenteen mukaisesti.

\vspace{\baselineskip}
\begin{lstlisting}[caption={Lopputuoteluettelo.},label={lst:hakemistorakenne}]
    ajankaytonseuranta
        ajankaytonseuranta
    dokumentit
        projektiraportti
        projektisuunnitelma
        sovellusraportti
        vaatimusmaarittely
    esittelyt
        lehdistotiedote
        valiesittely
        verkkoesite
    jarjestelmatestaus
        raporttipohja
        testausraportti
        testaussuunnitelma
    palaverit
        esityslistat
        katselmoinnit
        poytakirjat
        tilakatsaukset
    sahkopostiarkistot
        groundhog
        groundhog_opetus
    sopimus
        aihekuvaus
        projektisopimus
        yhteenveto
    sovellus
        geolab_documentation
        geolab_image
        geolab_manual
        geolab_release
        geolab_source
        geolab_testdata
    sovellussuunnitelmat
        arkkitehtuurisuunnitelma
        kayttoliittymasuunnitelma
        luokkasuunnitelma
        taustat-ja-tarpeet
\end{lstlisting}

Hakemistorakenne toteutui pääosin suunniteltuna. Suunnitelmaan verrattuna tulokset ryhmiteltiin useampaan hakemistoon. Kehitysympäristön pystytysohjeet siirrettiin sovellusraporttiin \cite{sovellusraportti}.

\section{Lähdekoodi}
\label{ch:lahdekoodi}

Lähdekoodin käytänteitä ei ollut määritelty projektisuunnitelmassa. Lähdekoodissa käytetyt aliohjelmat, luokat ja muuttujat nimettiin mahdollisimman kuvaavilla englanninkielisillä nimillä luvun \ref{ch:termit} termilistan mukaisesti sekä noudattaen C\#-ohjelmointikielen käytänteitä \cite{nimeamiskaytanteet}. Myös lähdekoodin kommentointi tapahtui englanniksi. Lähdekooditiedostojen alkuun lisättiin listauksessa \ref{lst:ohjelmistolisenssi} kuvattu MIT-lisenssiteksti, jota ei ollut huomioitu suunnitelmassa.

\vspace{\baselineskip}
\begin{lstlisting}[caption={Ohjelmistolisenssi.},label={lst:ohjelmistolisenssi}]
Copyright (c) 2021 Iiro Iivanainen, Harri Linna, Jere Pakkanen, 
Riikka Vilavaara
 
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
 
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
\end{lstlisting}

Lähdekoodin kirjoittamisessa huomioitiin .NETin version 5.0 ja C\#:n version 8.0 versiokohtaiset ominaisuudet ja käytänteet esimerkiksi lokaalien muuttujien tyypityksestä. Rivipituudet rajattiin 80–90 merkkiin, jotta koodin lukeminen olisi miellyttävää jaetulla näytöllä. Listauksen \ref{lst:koodikatkelma} katkelma lähdekoodista edustaa kommentointikäytänteitä.

% \vspace{\baselineskip}
\pagebreak
\begin{lstlisting}[caption={Lähdekoodin kommentointiesimerkki.},label={lst:koodikatkelma},language={[Sharp]C}]
#region 3D-tif
/// <summary>
/// Reads a 2D image from 3D tif file.
/// </summary>
/// <param name="filepath">Filepath of the image.</param>
/// <param name="depth">The depth of the 2D slice.</param>
/// <returns>A MagickImage object from the read file.</returns>
/// <exception cref="ImageReadException">
/// Thrown when failed to read image
/// </exception>
public static MagickImage Read3Dtif(string filepath, int depth)
{
            
    if (!File.Exists(filepath)) 
        throw new ImageReadException("Image does not exist");
    try
    {
        MagickImageCollection images = new();
        MagickImageCollection meta = new();
        meta.Ping(filepath);
        if (depth < meta.Count && depth >= 0)
        {
            MagickReadSettings settings = new();
            settings.FrameIndex = depth;
            settings.FrameCount = 1;

            images.Read(filepath, settings);
            MagickImage image = (MagickImage)images[0];
            image.Density = new Density(96);
            return image;
        }
        else throw new ImageReadException("Image out of bounds");
    }
    catch(MagickException e)
    {
        throw new ImageReadException("Error reading image: " +
            e.Message);
    }
}
#endregion
\end{lstlisting}

\section{Testaus}
\label{ch:testaus}

Sovelluksen käyttöliittymää testattiin kehityksen aikana koko ajan jäsenten toimesta, jotta varmistuttiin sen toiminnasta ja laadusta. Toteutetun sovelluksen laadunvarmistus tapahtui järjestelmätestauksella, joka suoritettiin kaksi kertaa. Järjestelmätestauksella varmistuttiin siitä, että toteutettu sovellus toimi suunnitellusti sekä sovellus täytti sille asetetut toiminnalliset ja laadulliset vaatimukset. Tilaajan edustajat koekäyttivät sovelluksen prototyyppiä sekä antoivat runsaasti hyödyllistä palautetta havaitsemistaan virheistä ja tarvittavista muutoksista. Lisäksi esittivät jatkokehitysideoita kirjattavaksi vaatimusmäärittelyyn \cite{vaatimukset} ja sovellusraporttiin \cite{sovellusraportti}. Suuri osa palautteesta ehdittiin tiukasta aikataulusta huolimatta toteuttaa. Tekninen ohjaaja suoritti lähdekoodin hyväksymistarkistuksen, jonka huomiot liittyivät katselmointien kirjallisten huomioiden tavoin suurelta osin virheenkäsittelyyn. Tekninen ohjaaja koekäytti sovellusta kehityksen aikana ja antoi siitä palautetta kirjallisen muistion muodossa.

Järjestelmätestauksesta vastaava henkilö laati testaussuunnitelman ja taulukkomuotoisen testausraporttipohjan \cite{testausraportti}. Testaussuunnitelma sisälsi testauskerroilla suoritettavat testitapaukset kuvattuina vaihe vaiheelta. Testauskerran suorittaneen jäsenen laatimassa testausraportissa kuvattiin testauskerran havainnot sekä mahdolliset havaitut virhetilanteet ja puutteet. Vastaavan jäsenen lisäksi projektiryhmän muut jäsenet olivat mukana järjestelmätestauksen suorittamisessa. Projektipäällikkö ei osallistunut käyttöliittymän kehittämiseen, joten hänen suoritti ensimmäisen testauskerran ja laati kyseisen testauskerran raportin. Vuorostaan järjestelmätestauksen vastuuhenkilö suoritti toisen testauskerran ja laati vastaavasti testausraportin. Muut jäsenet osallistuivat aktiivisesti havaittujen häiriöiden selvittämiseen ja korjaamiseen.

Projektissa oli tarkoitus, että ohjelmoija suorittaa tarvittavat yksikkötestaukset kirjoittamalleen lähdekoodille. Yksikkötestausta varten luotiin erillinen testausprojekti versiohallintaan vastaavasti kuin käyttöliittymälle ja luokkakirjastolle. Testausprojektilla oli tarkoitus testata CoreLibraryn toiminnallisuus, mutta projektin lopussa yksikään testimetodeista ei testannut käytössä olevaa ohjelmakoodia. Testausprojekti päätettiin siten ylimääräisenä poistaa versiohallinnasta.

Käyttöliittymää ei voinut ajaa Linux-koneella, joten testausprojektia oli tarkoitus käyttää TDD-henkisesti (Test Driven Development) kehitettävän ohjelmaosan toiminnan määrittelyssä. Testitapauksia olikin kertynyt jonkin verran varmistamaan, että ohjelma käyttäytyy edelleen suunnitellusti. Ajattelutavasta seurasi kuitenkin kohtalokas virhe, sillä etukäteen kirjoitettuja apufunktioita (vektorilaskuihin ja tiedostojen käsittelyyn) tai ylipäänsä testausprojektia ei koskaan tarvittu. Tätä periaatetta kutsutaan XP-ohjelmoinnissa (Extreme Programming) lyhenteellä YAGNI (You aren't gonna need it). Toisin sanoen luokkakirjaston kehittäminen erillään käyttöliittymästä ja tiedostonluvusta oli äärimmäisen lyhytkatseista toimintaa, jolla oli kauaskantoiset seuraukset. Toisaalta siinä tilanteessa ei voinut juuri muutakaan, sillä eihän ohjelmaa voinut suorittaa Linux-koneella.

\section{Versiohallinta ja -numerointi}
\label{ch:versiohallinta-ja--numerointi}

Sovelluksen lähdekoodin versiohallintaan käytettiin Git-versiohallintaohjelmistoa. Lähdekoodi sijoitettiin yliopiston GitLab-palveluun, jossa se oli projektin ajan koko projektiorganisaation saatavilla. Dokumenteille ei ollut erillistä versiohallintaa, mutta projektissa laaditut dokumentit aina muokattaessa numeroitiin uudella versionumerolla. Dokumentit sijaitsivat Overleaf-palvelussa projektiryhmän yhteisessä työtilassa, joten dokumentin viimeisin tekstiversio oli aina saatavilla. Projektissa laadittujen dokumenttien uusimpia versioita julkistettiin saataville projektin WWW-sivuilla.

Julkistettavissa dokumenteissa käytettiin kolmiportaista numerointia (i.j.k). Projektiryhmän sisäisiä versioita numeroitiin pienimmällä merkitsevällä numerolla paikassa k. Projektiorganisaatiolle julkistettavat versiot numeroitiin toisella merkitsevällä numerolla paikassa j. Projektiorganisaation hyväksymän dokumentin versio numeroitiin paikassa i. Esimerkiksi projektisopimusta muokattiin ensimmäisen hyväksymisen jälkeen vielä lisenssien osalta, jolloin lopullisen allekirjoitetavan sopimuksen versionumeroksi muodostui 2.0.0.

Tiedostojen nimeämisen kohdalla versionumeroinnin noudattaminen tuotti vaikeuksia, sillä esimerkiksi suunnitteludokumenteista jouduttiin tekemään identtiset kopiot, jos ne haluttiin julkistaa. Toisaalta jos julkistettavat dokumentit olivat kokonaan erillisiä (kuten käyttö\-liittymä- ja arkkitehtuurisuunnitelman muutosehdotuksen yhteydessä) niin järjestysnumero menetti merkityksensä. Esimerkiksi 3D-tilakarttaa suunnitellessa versionumerointi osoittautui osittain riittämättömäksi, sillä lopulta päätettiin olla seuraamatta uutta kehityshaaraa tai se siirrettiin jatkokehitykseen. Tällaisessa tilanteessa olisi suotavaa sallia julkistettavan myös ryhmän sisäisiä versioita, kuten 0.1.1 tai 0.1.2. Projektiorganisaatio voi silloin valita kumman version kehittämistä jatketaan versiona 0.2.0.

Overleaf-palvelua olisi kannattanut hyödyntää myös pöytäkirjojen laatimisessa, sillä todennäköisesti puheenjohtaja ehdotti vähintäänkin pieniä muutoksia pöytäkirjaan. Kirjoitusvirheet olisivat olleet helposti korjattavissa välittömästi oikoluvun yhteydessä ja suuremmat sisällön muutokset olisi voinut kirjata suoraan joko kommentteihin tai erillisellä muokkaustyökalulla. Harvemmin sihteerin kirjaamia projektipalaverien pöytäkirjojen hahmotelmia tarvitsee säilyttää, joten muistiot olisi kannattanut kirjoittaa suoraan tex-tiedostoon, joka käyttäisi projektiryhmän yhteistä cls-dokumenttiluokkaa pöytäkirjoille. Muistioiden rakenne olisi kannattanut vuorostaan kopioida esityslistasta ennen palaveria, jotta dokumenttipohjan muotoilussa olisi säästetty aikaa palaverin jälkeen.

\section{Katselmoinnit ja tulosten hyväksyminen}
\label{ch:katselmoinnit-ja-tulosten-hyvaksyminen}

Projektin aikana sovelluksen lähdekoodi katselmoitiin teknisen ohjaajan toimesta kaksi kertaa. Ensimmäinen katselmointi pidettiin 21.4 ja toinen 3.6. Ennen molempia katselmointeja tekninen ohjaaja laati kirjalliset kommentit, jotka hän välitti sähköpostitse koko projektiorganisaatiolle ennen katselmointitilaisuutta. Katselmointeihin pyrkivät osallistumaan koko projektiorganisaatio, kuten muihinkin projektin yhteisiin tapahtumiin. Katselmoinneissa kiinnitettiin huomiota mm. ammattimaisen lähdekoodin muotoiluun sekä edistyneisiin C\#-ohjelmointikielen ominaisuuksiin, kuten säieturvallisuuteen ja metodien nullable-tyyppisten paluuarvojen merkitsemiseen. Katselmointien palautteet olivat täsmällisen lyhyitä, mutta sitäkin opettavaisempia. Palautteen kuuleminen etukäteen vähensi merkittävästi jäsenten muutosvastarintaa. Edistyneiden C\#-kielen ominaisuuksien ansiosta teknisen ohjaajan palautteet sisällytettiin tilaajan edustajien laatiman aihekuvauksen tavoin projektikansioon. Erinomaisen kirjallisen palautteen ansiosta projektiryhmän ei tarvinnut laatia katselmoinneista erillistä muistiota.

Projektin lopussa laadittavat dokumentit sovittiin hyväksytettävän ensin vastaavalla ohjaajalle ja vasta sitten tilaajan edustajilla. Menettely johtui projektin viivästymisestä, jolloin tilaajan edustajat jäivät lomalle ennen vastaavaa ohjaa ja palasivat lomaltaan ennen vastaavaa ohjaajaa. Vastaava ohjaaja ja tilaajan edustajat hyväksyivät keskeiset dokumentit, joita olivat projektisuunnitelma, vaatimusmäärittely, testaussuunnitelma, sovellusraportti ja projektiraportti. Keskeiset dokumentit hyväksyttiin sähköpostitse vastaavan ohjaajan, tilaajan edustajan ja projektipäällikön toimesta. Tilaajan edustajille riitti lähdekoodin osalta teknisen ohjaajan hyväksyntä sähköpostitse. Projektiryhmän tuloksista ainoastaan projektisopimus allekirjoitettiin yliopiston koronarajoituksista johtuen.

\section{Tulosten koostaminen ja toimittaminen}
\label{ch:tulosten-koostaminen-ja-toimittaminen}

Projektiryhmä kokosi luvussa \ref{ch:dokumentit-ja-muut-materiaalit} kuvatut projektin tulokset luvussa \ref{ch:hakemistorakenne} kuvatun hakemistorakenteen mukaisesti. Informaatioteknologian tiedekunnalle toimitettiin tuloksista koostettu projektikansio ja kaksi CD-levyä, joista toinen oli arkistointia varten. CD-levy koostettiin vasta, kun kaikki projektin tulokset oli hyväksytty ja projektikansio sijoitettiin projektitilan kokoushuoneessa olevaan kirjahyllyyn. Tulokset toimitettiin tilaajalle pakattuna zip-tiedostona projektin WWW-sivuston kautta.

Lähdekoodien osalta sovittiin, ettei niitä tulosteta projektikansioon. Prototyyppien tai järjestelmätestauksen testidataa ei tulostettu projektikansioon. Suurin osa näistä on väliaikaistiedostoja, mutta jotkin dokumentit saattaisivat osoittautua hyödylliseksi jatkokehityksessä. Sen takia tex-tiedostot ja niiden cls-dokumenttiluokat sisällytetään CD:lle ja tulospakettiin.

\chapter{Roolit, vastuualueet ja tehtävät}
\label{ch:roolit-vastuualueet-ja-tehtavat}

Luvussa kuvataan projektiryhmän jäsenten roolit, vastuualueet ja tehtävät. Lisäksi luvussa esitetään ryhmän jäsenten arvioidut ja toteutuneet työtunnit tehtäväkokonaisuuksittain. Tehtäviin tarvittavia työtunteja ei osattu arvioida riittävän tarkasti, joten projektinhallinnan toteutuneet työtunnit olivat suunniteltua suuremmat ja toteutuksen suunniteltua pienemmät. Projektihallinnan tehtäväkokonaisuuteen kirjattiin siihen kuulumattomia tehtäviä, joten toteutuneita työtunteja ei voitu luotettavasti verrata suunnitelmaan.

Roolit vastasivat suunniteltua ja jäsenet omaksuivat projektin aikana selkeät vastuualueet, jotka liittyivät projektin tuloksiin. Ryhmän jäsenet suunnittelivat itsenäisesti tehtäviään ja ajankäyttöään, joten projektipäällikön toimeen kuului nimellisesti vain projektin suunnittelu ja raportointi. Projekti toteutettiin kokonaan etänä, mikä edellytti itsenäistä vastuunottoa tehtävien tuloksista. Tuloksiin liittyvät vastuualueet noudattivat projektiorganisaatiolla hyväksytettävien tulosten osalta melko tarkasti suunniteltua, mutta suunnitelmassa olisi kannattanut esitellä yksi vastuuhenkilö olemaan päävastuussa yksikkötesteistä. Yksikkötestausta suunniteltiin ja toteutettiin projektin alkupuolella, mutta yksikkötestausta ei juurikaan tehty enää toteutusvaiheessa.

\section{Roolit ja vastuualueet}
\label{ch:roolit-ja-vastuualueet}

Projektipäällikkönä toimi Harri Linna ja varapäällikkönä Jere Pakkanen. Projektipäällikön vastuulla oli projektin suunnittelu, hallinta ja raportointi. Lisäksi projektipäällikön vastuulla oli myös tehtävien jakaminen projektiryhmän jäsenille ja säännöllinen projektin edistymisen valvominen. Varapäällikkö hoiti palavereissa puheenjohtajan tehtäviä sekä huolehti palaverien esityslistojen julkistamisesta.

Taulukossa \ref{tab:vastuualueet-dokumentit} kuvataan jäsenten toteutuneet projektin tulosten vastuualueet. Vastuuhenkilö vastasi pääosin kyseisen tuloksen saattamisesta valmiiksi, mutta vastuuhenkilö ei välttämättä toteuttanut kyseistä vastuualuetta yksin. Vastuuhenkilö tiedotti projektiorganisaatiota vastuullaan olevien tulosten valmistumisesta.

\begin{table}[h!]
\centering
\begin{tabular}{ |p{7cm}|p{4cm}| }
\hline
\textbf{Vastuualueen kuvaus} & \textbf{Vastuuhenkilö}\\
\hline
Ajankäyttöraportti & Harri Linna\\
\hline
Arkkitehtuurisuunnitelma & Harri Linna\\
\hline
Esittelymateriaali & Kaikki jäsenet\\
\hline
Esityslistat & Harri Linna, Jere Pakkanen\\
\hline
Itsearvioinnit & Kaikki jäsenet\\
\hline
Kehitysympäristön pystytysohjeet & Riikka Vilavaara\\
\hline
Käyttöliittymäsuunnitelma & Harri Linna\\
\hline
Käyttöohjeet & Iiro Iivanainen\\
\hline
Luokkadokumentaatio & Kaikki jäsenet\\
\hline
Luokkasuunnitelma & Kaikki jäsenet\\
\hline
Lähdekoodi & Kaikki jäsenet\\
\hline
Palaverien dokumentit & Iiro Iivanainen, Riikka Vilavaara\\
\hline
Projektiraportti & Harri Linna\\
\hline
Projektisuunnitelma & Harri Linna\\
\hline
Sovellusraportti & Riikka Vilavaara\\
\hline
Sähköpostiarkistot & Harri Linna\\
\hline
Testausraportti & Iiro Iivanainen, Harri Linna\\
\hline
Testaussuunnitelma & Iiro Iivanainen\\
\hline
Tilakatsaukset & Harri Linna\\
\hline
Vaatimusmäärittely  & Jere Pakkanen\\
\hline
Valmisohjelma & Jere Pakkanen\\
\hline
Verkkoesite & Riikka Vilavaara\\
\hline
\end{tabular}
\caption{Dokumenttien toteutuneet vastuualueet.}
\label{tab:vastuualueet-dokumentit}
\end{table}

Taulukossa \ref{tab:vastuualueet-vaatimusmaarittely} kuvataan jäsenten toteutuneet ominaisuuskokonaisuuksien vastuualueet. Vastuuhenkilö vastasi pääosin kyseisen tehtäväkokonaisuuden saattamisesta valmiiksi, mutta vastuuhenkilö ei välttämättä toteuttanut kyseistä vastuualuetta yksin. Vastuuhenkilö tiedotti projektiorganisaatiota vastuullaan olevien ohjelmaosien valmistumisesta ja niiden esittelystä palavereissa. Projektisuunnitelmassa keskityttiin dokumenttien vastuualueisiin ja sovellusosioiden vastuualueet realisoituivat projektin edetessä vaatimusmäärittelyn tarkentumisen myötä. Taulukko \label{tab:vastuualueet-vaatimusmaarittely} on otettu valmiista vaatimusmäärittelystä \cite{vaatimukset}, mutta teknisten vaatimusten osalta rajoituttiin Windows-ympäristöön ja raportointityökalu siirrettiin kokonaisuudessaan jatkokehitykseen. Tehtäväkokonaisuudet tiivistävät sovellusosioiden vastuualueiden jakoa.

\begin{table}[h!]
\centering
\begin{tabular}{ |p{7cm}|p{4cm}| }
\hline
\textbf{Vastuualueen kuvaus} & \textbf{Vastuuhenkilö}\\
\hline
Karttatiedostojen lukemisen hallinta & Jere Pakkanen\\
\hline
Karttatiedostojen näyttämisen hallinta & Riikka Vilavaara\\
\hline
Liitetyn datan lukemisen hallinta & Iiro Iivanainen\\
\hline
Liitetyn datan näyttämisen hallinta & Iiro Iivanainen\\
\hline
Metatietojen hallinta & Iiro Iivanainen\\
\hline
Karttatiedoston ja liitetyn datan hallinta & Riikka Vilavaara\\
\hline
Sovelluksen tilan tallentamisen ja lataamisen hallinta & Jere Pakkanen\\
\hline
Sovelluksen käyttöliittymän hallinta & Riikka Vilavaara\\
\hline
% Sovelluksen kehityksen hallinta & Iiro Iivanainen\\
% \hline
Ohjeiden hallinta & Iiro Iivanainen\\
\hline
Rajoitteiden hallinta & Jere Pakkanen\\
\hline
% Teknisen toteutuksen hallinta & Iiro Iivanainen, Harri Linna, Jere Pakkanen, Riikka Vilavaara\\
% \hline
\end{tabular}
\caption{Sovellusosioitten toteutuneet vastuualueet.}
\label{tab:vastuualueet-vaatimusmaarittely}
\end{table}

Käyttöliittymän toteutuksen työtunteihin kirjattiin käyttöliittymäsuunnitelman mukaisten näkymien toteuttamisen. Vilavaara oli päävastuussa pääikkunan ikkunoinnista ja MVVM-arkkitehtuurin mukaisesta ohjelmoinnista. Lisäksi pääikkunan karttanäkymä ja karttakontrolleri kuuluivat hänen tehtäviinsä. Iivanainen oli päävastuussa liitoskohtia visualisoivan liukusäätimen ja dataliitosten hallintaan käytettävän listanäkymän toteuttamisesta. Lisäksi hänen tehtäviinsä kuuluivat metatietojen ja käyttäjäasetusten tekeminen. Pakkanen oli päävastuussa erilaisten karttatiedostojen käsittelystä, sovelluksen tilan tallentamisesta, säikeistämisestä ja poikkeuskäsittelystä. Linna suunnitteli sovellusta ja toteutti tilakartan prototyypin. Yksikkötestausta suunniteltiin tehtävän TDD-henkisesti koko toteutusvaiheen ajan, mutta ohjelmistossa ei sinänsä ollut testattavaa. Esimerkiksi tiedoston lukemista oli helpompi arvioida silmämääräisesti kuin yksittäisiä pikseleitä vertaamalla. Muita toteutusvaiheen jäsenten yhteisiä tehtäviä olivat virheenetsintä ja koodikatselmointien palautteen pohjalta tehtävä lähdekoodin refaktorointi.

Vastuualueet tulosten osalta toteutuivat suunnitellusti. Suunniteltu vastuuhenkilö vastasi omasta vastuualueestaan projektin aikana. Ryhmän jäsenet osallistuivat joustavasti toistensa vastuualueisiin sisältyneiden tehtävien suorittamiseen sekä dokumenttien että lähdekooditiedostojen osalta.

\FloatBarrier

\section{Tehtäväkokonaisuudet ja työmäärät}
\label{ch:tehtavakokonaisuudet-ja-tyomaarat}

Ryhmän suunniteltiin käyttävän sovellusprojektiin yhteensä 1600 tuntia, mutta toteutunut tuntimäärä oli oheiskursseja lukuun ottamatta 1635 tuntia. Kokonaisuudessaan työtunteja käytettiin suunniteltua enemmän. Suunnitelmassa palaverit sisältyivät projektinhallinnan tehtäväkokonaisuuteen. Esitutkimus katsottiin kuuluvan projektin suunnitteluvaiheeseen. Suunnitelmassa keskityttiin Sovellusprojektin työtunteihin ja siksi oheiskursseja ei mielletty Sovellusprojektin tehtäväkokonaisuudeksi. Taulukossa \ref{tab:projektin-tehtavakokonaisuuksien-tyotunnit} esitetään eri tehtäväkokonaisuuksien suunnitellut ja toteutuneet tuntimäärät.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c| }
\hline
\textbf{Tehtäväkokonaisuus} & \textbf{Suunniteltu} & \textbf{Toteutunut} & \textbf{Erotus}\\
\hline
Vaatimusmäärittely & 48 & 18 & -30\\
\hline
% Esitutkimus & 0 & 160 & -160\\
% Suunnittelu & 400 & 148 & -252\\
Suunnittelu & 400 & 310 & -90\\
\hline
Toteutus & 816 & 566 & -250\\
\hline
Testaus & 96 & 63 & -33\\
\hline
% Palaverit & 0 & 372 & 372\\
% Projektinhallinta & 240 & 302 & 62\\
% Tulosten luovutus & 0 & 4 & 4\\
Projektinhallinta & 240 & 678 & 438\\
\hline
%Oheiskurssi & 426 & 212 & -214\\
%\hline
\textbf{Sovellusprojekti} & \textbf{1600} & \textbf{1635} & \textbf{35}\\
\hline
%\textbf{Yhteensä} & \textbf{2026} & \textbf{1764} & \textbf{262}\\
%\hline
\end{tabular}
\caption{Projektin tehtäväkokonaisuuksien työtunnit.}
\label{tab:projektin-tehtavakokonaisuuksien-tyotunnit}
\end{table}

Tehtävien työmäärät suunniteltiin aikaisempien sovellusprojektien toteutuneiden tuntien pohjalta. Jäsenten työnjako oli tasapuolinen ja vaiheiden vaatimaa työmäärää kyettiin ennakoimaan edellisten ryhmien ajankäyttöraporttien perusteella. Näistä ajankäyttöraporteista saatiin suuntaa antavat prosentuaaliset osuudet kokonaistyömäärän jakautumisesta vaiheittain, mitkä sitten suhteutettiin tämän projektin arvioituun kokonaistyömäärään. Työmääräarviot määräytyivät kokonaistyömäärästä kuvan 6.1 mukaisesti, kun kokonaistyömäärän arvio laskettiin kaavalla
\[ 26,67\,\frac{T}{OH} \cdot 15\,O \cdot 4\,H = 400,05\,\frac{T}{H} \cdot 4\,H = 1600,2\,T \textrm{, missä} \]
\begin{compactitem}
    \item T = Työtunnit,
    \item O = Opintopisteet ja
    \item H = Henkilömäärä.
\end{compactitem}

\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{kuvat/projektisuunnitelma/vaiheet.png}
    \caption{Suunnitellut työmäärät tehtäväkokonaisuuksittain.}
    \label{fig:suunnitellut-tyomaarat-vaiheittain}
\end{figure}

Arviointimenetelmä erosi merkittävästi projektisuunnitelmaan kirjatusta kolmen pisteen työmääräarvioinnista, jossa projektiryhmän jäsenet olisivat antaneet tehtäville kolme eri työmääräarviota: optimistinen, pessimistinen ja todennäköinen. Lopullinen työmääräarvio olisi saatu näiden kolmen painotetusta keskiarvosta. Nykyinen arviointi perustuu valistuneiden arvausten sijaan aiempien sovellusprojektien dokumentoituun tietoon.

Dokumenttien laatimiseen käytetyt työtunnit kirjattiin virheellisesti projektinhallinnan tehtäväkokonaisuuteen, vaikka dokumentit olivat eri tehtäväkokonaisuuksien tuloksia. Ainoastaan projektisuunnitelman ja -raportin työmäärät olisi kannattanut merkitä projektinhallintaan ja muut dokumentit kyseisten tehtäväkokonaisuuksien alle.

Kaikki tapaamiset mukaan lukien ryhmän sisäiset tapaamiset kirjattiin virheellisesti palaverien tehtäväkokonaisuuteen. Tämä aiheutti vääristymää projektinhallinnan työmäärissä, koska suunnitelmassa palaverit sisältyivät projektinhallinnan tehtäväkokonaisuuteen. Ainoastaan projektipalaverit olisi kannattanut merkitä projektinhallintaan ja muut suunnittelupalaverit kyseisen tehtäväkokonaisuuden alle.

Suunniteltujen ja toteutuneiden työtuntien välinen erotus selittyy suurimmaksi osaksi näillä työtuntien kirjaamisen käytänteillä. Projektinhallinnan suuri erotus selittyy edelleen dokumenttien laatimiseen käytetyillä työtunneilla. Kuvassa \ref{fig:toteutuneet-tyomaarat-vaiheittain} esitetään projektin toteutuneet työmäärät vaiheittain, jotka erosivat suunnitelmasta.

% Kuvassa \ref{fig:toteutuneet-tyomaarat-vaiheittain} esitetään toteutuneet työmäärät vaiheittain, kun palaverien työtunnit jätetään huomiotta.

\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{kuvat/projektiraportti/vaiheet/VaiheetLyhytK_Kaikki.png}
    \caption{Ryhmän toteutuneet työmäärät tehtäväkokonaisuuksittain.}
    \label{fig:toteutuneet-tyomaarat-vaiheittain}
\end{figure}

Esimerkiksi jos vaatimusmäärittelyn (määrittely), testaussuunnitelman (testaus) ja sovellusraportin (toteutus) työtunnit siirrettäisiin niitä vastaaviin tehtäväkokonaisuuksiin, niin projektinhallinnan osuuden voisi kuvitella laskevan. Vastaavasti muiden tehtäväkokonaisuuksien osuudet kasvaisivat, jolloin työmäärien toteuma lähestyisi suunniteltua. Luotettavia johtopäätöksiä toteuman ja suunnitelman työtuntien eroista ei kuitenkaan voi tehdä.

Ryhmän jäsenet merkitsivät tunnollisesti projektiin käyttämiään työtunteja. Ryhmän olisi kuitenkin kannattanut heti projektin alussa sopia työtuntien kirjauskäytännöistä huomattavasti tarkemmin. Kirjauskäytänteisiin olisi voinut vielä vaikuttaa, jos projektisuunnitelma olisi valmistunut maaliskuussa. Joka tapauksessa tuntien kirjaaminen suunnitelman mukaisille tehtäväkokonaisuuksille, olisi tehnyt työtuntien vertailusta projektipäällikölle helpompaa.

\FloatBarrier

\section{Projektinhallinnan työmäärät}
\label{ch:projektinhallinnan-tyomaarat}

Projektinhallintaan oli suunniteltu 240 tuntia ja siihen käytettiin 678 tuntia. Kaikkia tulosten viimeistelyyn ja kokoamiseen käytettyjä tunteja ei voitu kirjata taulukkoon \ref{tab:projektinhallinnan-tyomaarat}, sillä kokoamista tehtiin vielä projektiraportin kirjoittamisen jälkeen. Projektinhallinnan työtunteihin kirjattiin pääasiassa dokumenttien laatimiseen käytettyjä työtunteja.

Projektipäällikkö otti tehtävän vastaan vastahakoisesti ja suunnitteli tekevänsä projektinhallintaa muiden tehtäviensä ohella. Projektin jäsenet kokoontuivat kaksi tai kolme kertaa viikossa keskustelemaan projektin läpiviennistä, mikä selittää arvioitua suuremmat palaverien työtunnit. Poikkeavista järjestelyistä johtuen ryhmän jäsenet tapasivat vain kerran projektisopimuksia allekirjoittaessaan. Tiedottaminen tapahtui suurimmaksi osaksi projektiryhmän yhteisissä tapaamisissa.

Projektinhallinta on yleensä 15--20 prosenttia kokonaistyömäärästä, joten projektipäällikön olisi kannattanut keskittyä ensisijaisesti projektinhallinnan tehtäviin. Muut ryhmän jäsenet eivät tästä huomauttaneet, joten ehkäpä yhteisvastuu koettiin toimivaksi. Taulukossa \ref{tab:projektinhallinnan-tyomaarat} kuvataan projektinhallinnan työmäärät.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
kirjoitus -ja ulkoasu & 5 & 0 & 29 & 0 & 34\\
\hline
muut tehtävät & 11 & 3 & 9 & 9 & 32\\
\hline
raportointi & 66 & 27 & 2 & 52 & 147\\
\hline
seuranta ja hallinta & 0 & 4 & 3 & 6 & 13\\
\hline
sopimukset & 0 & 1 & 0 & 22 & 23\\
\hline
suunnittelu & 0 & 0 & 0 & 8 & 8\\
\hline
tiedotus & 6 & 1 & 0 & 2 & 9\\
\hline
toteutus & 0 & 0 & 4 & 0 & 4\\
\hline
tukitehtävät & 0 & 0 & 3 & 10 & 13\\
\hline
tutustuminen & 2 & 3 & 7 & 0 & 12\\
\hline
valmisteltu ja tutustuminen & 1 & 0 & 0 & 0 & 1\\
\hline
\textbf{Projektinhallinta} & \textbf{91} & \textbf{39} & \textbf{57} & \textbf{109} & \textbf{296}\\
\hline
\end{tabular}
\caption{Projektinhallinnan toteutuneet työtunnit.}
\label{tab:projektinhallinnan-tyomaarat}
\end{table}

Suunnitelmassa palaverit sisältyivät projektinhallintaan, mutta niihin käytettiin 372 tuntia. Palaverien suuret työtunnit johtuvat siitä, että ryhmän jäsenet kirjasivat projektipalavereiksi myös ryhmän tapaamiset, joita tehtiin ajoittain jopa kolmesti viikossa. Ryhmän sisäisiä tapaamisia merkittiin nimikkeellä muut tehtävät. Toteutuneet työtunnit olivat siis suunnilleen kolminkertaiset edellisvuosien projekteihin verrattuna, koska Groundhog-projekti toteutettiin kokonaan etänä.

Palaverien työtunteja olisi kannattanut arvioida edellisvuosien pöytäkirjojen lukumäärän ja palaverien keskimääräisen keston perusteella. Koko ryhmä käytti palavereihin kahdeksan tuntia helmikuussa joka viikko ja maaliskuusta kesäkuulle joka toinen viikko. Lisäksi niihin liittyi esityslistojen, tilakatsausten ja pöytäkirjojen valmistelua. Ryhmän tapaamisia pidettiin kaksi tai kolme kertaa viikossa, mikä vastaa 16--24 henkilötyötuntia viikoittain. Lisäksi projektin viivästyessä valmiiksi korkeat tuntimäärät kasvoivat entisestään.

Palaverit vaikuttivat rutiinitehtäviltä, mutta niihin käytettävien työtuntien aliarviointi varmaankin johti aikaresurssien loppumiseen projektin toteutusvaiheessa, jolloin toteutukseen varatut työtunnit jäivät merkittävästi alle suunnitellun. Palaverien vaatiman työmäärän väheksyminen oli siten merkittävä virhearvio projektin läpiviennin kannalta. Esimerkiksi palavereihin käytettiin enemmän aikaa kuin projektinhallintaan. Taulukossa \ref{tab:palaverien-tyomaarat} esitetään palaverien toteutuneet työtunnit tehtävittäin.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
katselmoinnit & 1 & 1 & 1 & 2 & 5\\
\hline
muut tehtävät & 55 & 66 & 52 & 48 & 221\\
\hline
raportointi & 2 & 8 & 6 & 10 & 26\\
\hline
seuranta ja hallinta & 0 & 0 & 0 & 3 & 3\\
\hline
sopimukset & 0 & 0 & 0 & 1 & 1\\
\hline
suunnittelu & 9 & 11 & 7 & 4 & 31\\
\hline
tiedotus & 0 & 0 & 0 & 2 & 2\\
\hline
tukitehtävät & 18 & 7 & 9 & 15 & 49\\
\hline
tutustuminen & 2 & 2 & 0 & 2 & 6\\
\hline
valmistelu ja tutustuminen & 4 & 7 & 4 & 8 & 23\\
\hline
\textbf{Palaverit} & \textbf{91} & \textbf{102} & \textbf{79} & \textbf{95} & \textbf{367}\\
\hline
\end{tabular}
\caption{Palaverien toteutuneet työtunnit.}
\label{tab:palaverien-tyomaarat}
\end{table}

\FloatBarrier

\section{Vaatimusmäärittelyn työmäärät}
\label{ch:vaatimusmaarittelyn-tyomaarat}

Vaatimusmäärittelyyn arvioitiin 48 tuntia, mutta käytettiin 18 tuntia. Vaatimusmäärittelyn suunnittelu ja raportointi kirjattiin projektinhallinnan tehtäväkokonaisuuteen. Muutoshistorian perusteella dokumenttia päivitettiin säännöllisesti lähes viikoittain.

Vaatimusmäärittelyn vastuuhenkilö toimi puheenjohtajana useimmissa palavereissa vastaten useimpien pöytäkirjojen tarkastamisesta. Pöytäkirjojen tarkastamisen yhteydessä havaitut sovellukseen kehitettävät tiedot ja toiminnot kirjattiin vaatimusmäärittelyyn, jolloin vaatimusmärittelyn työtunnit kirjattiin samaan tehtäväkokonaisuuteen kuin pöytäkirjojen tarkastaminen. Taulukossa \ref{tab:vaatimusmaarittelyn-tyomaarat} on määrittelyvaiheen toteutuneet työtunnit tehtävittäin. 

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
kirjoitus- ja ulkoasu & 0 & 0 & 0 & 4 & 4\\
\hline
raportointi & 0 & 7 & 0 & 0 & 7\\
\hline
seuranta ja hallinta & 0 & 0 & 0 & 7 & 7\\
\hline
\textbf{Määrittely} & \textbf{0} & \textbf{7} & \textbf{0} & \textbf{11} & \textbf{18}\\
\hline
\end{tabular}
\caption{Vaatimusmäärittelyn toteutuneet työtunnit.}
\label{tab:vaatimusmaarittelyn-tyomaarat}
\end{table}

\FloatBarrier

\section{Suunnittelun työmäärät}
\label{ch:suunnittelun-tyomaarat}

Sovelluksen suunnitteluun arvioitiin 400 tuntia, mutta käytettiin 148 tuntia. Suunnitelmassa esitutkimus miellettiin yhdeksi suunnitteluvaiheen tehtäväksi. Toteutusteknologioihin ja ohjelmakirjastoihin tutustuminen liittyy nimittäin erottamattomasti sovelluksen suunnitteluun. Suunnitteluun käytettiin 310 työtuntia esitutkimus mukaan lukien. Suunnitteluun kuulumattomia tehtäviä kirjattiin projektinhallinnan ja vaatimusmäärittelyn dokumenttien osalta.

Suunnittelun työtunnit kohdistuivat karttatiedostojen lukemisen ja käyttöliittymän karttanäkymän toteutusratkaisuihin. Sovellussuunnitelmien laatimiseen käytettiin arvioitua vähemmän aikaa, sillä suunnitelmat olivat toteutuskelpoisia jo viikolla 10. Toteutusvaiheeseen voitiin siirtyä viikolla 11. Sovellussuunnitelmia päivitettiin seuraavan kerran vasta viimeistelyvaiheessa jatkokehitysideoiden dokumentoimista varten. Taulukossa \ref{tab:suunnittelun-tyomaarat} esitetään suunnitteluvaiheen työtunnit tehtävittäin.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
kirjoitus- ja ulkoasu & 0 & 0 & 0 & 2 & 2\\
\hline
käyttöliittymä & 7 & 4 & 3 & 22 & 36\\
\hline
muut tehtävät & 4 & 0 & 0 & 12 & 16\\
\hline
rajapinnat & 0 & 0 & 0 & 15 & 15\\
\hline
raportointi & 0 & 19 & 0 & 0 & 19\\
\hline
seuranta ja hallinta & 0 & 0 & 0 & 4 & 4\\
\hline
suunnittelu & 0 & 10 & 0 & 31 & 41\\
\hline
toteutus & 0 & 3 & 0 & 0 & 3\\
\hline
tukitehtävät & 0 & 0 & 0 & 9 & 9\\
\hline
\textbf{Suunnittelu} & \textbf{11} & \textbf{36} & \textbf{3} & \textbf{95} & \textbf{145}\\
\hline
\end{tabular}
\caption{Suunnittelun toteutuneet työtunnit.}
\label{tab:suunnittelun-tyomaarat}
\end{table}

Esitutkimus suunniteltiin kuuluvan suunnitteluun, mutta siihen käytettiin 160 tuntia. Monet työkalut olivat tuttuja ryhmän jäsenille jo entuudestaan. Työkaluihin ja laitteisiin tutustumista tehtiin myös sovelluskehityksen aikana, joten niitä lienee kirjattu toteutukseen. Aihealueeseen tutustuttiin myös paljon palavereissa tilaajan edustajien kanssa keskustellessa ja osin myös ryhmätapaamisissa. Työtunteja oli hankala arvioida, koska ei ollut selkeää käsitystä siitä, kuinka paljon uusia työkaluja projektin jäsenet joutuvat opettelemaan. Taulukossa \ref{fig:esitutkimuksen-tyomaarat} esitetään esitutkimuksen toteutuneet työtunnit tehtävittäin.

Esitutkimukseen sisältyi aihealueen tuntemuksen hankkimista tutustumalla Fiji- ja ImageJ-ohjelmiin sekä pi2-kirjaston dokumentaatioon. Lisäksi esitutkimukseen sisältyi kehitysympäristön Visual Studio asentaminen ja WPF-projektin käytänteiden kertaaminen. Merkittävin osa työtunneista liittyi kuitenkin MVVM-arkkitehtuurin ja WPF-projektin tutkimiseen sekä ulkoisten kirjastojen kartoittamiseen. Esitutkimuksen aikana harkittiin eri ohjelmointikieliä sekä kymmenittäin erilaisia ohjelmakirjastoja, joiden lisenssiehtojen yhteensovittaminen lisäsi työmäärää. Monet vapaan ohjelmistolisenssin kirjastot kielsivät kaupallisen käytön tai olivat muuten tarttuvia GPL-lisenssejä.

Jälkeenpäin ajatellen esitutkimuksen tuntimäärät olisi kannattanut sisällyttää suunnitelmaan omana tehtäväkokonaisuutenaan. Projektin käynnistämiseen liittyi paljon sellaisia käytännön asioita, jotka eivät varsinaisesti liittyneet vaatimusmäärittelyyn eivätkä projektin tai sovelluksen suunnitteluun, vaan enemmänkin tietopohjan ja aihealueen ymmärryksen hankkimiseen. Projektin alussa sovellettiin ketterää ohjelmistokehitystä Scrumin muodossa. Projektissa siirryttiin vasta myöhemmin takaisinkytkettyyn vesiputousmalliin. Esitutkimuksen työtunnit olisi kannattanut kirjata suunnitteluvaiheen tehtäväksi.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
esitutkimus & 0 & 0 & 1 & 0 & 1\\
\hline
kirjoitus- ja ulkoasu & 0 & 0 & 1 & 0 & 1\\
\hline
käyttöliittymä & 17 & 1 & 17 & 1 & 36\\
\hline
muut tehtävät & 4 & 0 & 5 & 0 & 9\\
\hline
suunnittelu & 0 & 15 & 2 & 1 & 18\\
\hline
toteutus & 0 & 2 & 13 & 2 & 17\\
\hline
tukitehtävät & 1 & 0 & 8 & 8 & 17\\
\hline
tutustuminen & 13 & 4 & 13 & 9 & 39\\
\hline
valmistelu ja tutustuminen & 1 & 5 & 0 & 12 & 18\\
\hline
\textbf{Esitutkimus} & \textbf{36} & \textbf{27} & \textbf{60} & \textbf{33} & \textbf{156}\\
\hline
\end{tabular}
\caption{Esitutkimuksen toteutuneet työtunnit.}
\label{fig:esitutkimuksen-tyomaarat}
\end{table}

\FloatBarrier

\section{Toteutuksen työmäärät}
\label{ch:toteutuksen-tyomaarat}

Toteutukseen suunniteltiin 816 tuntia, mutta käytettiin 566 tuntia. Huomattavasti suunniteltua vähempi työmäärä selittyy viikoittaisten palaverien ja ryhmän sisäisten tapaamisten suurella määrällä. Kaksi tapaamista viikossa osoittautui etäaikana toimivaksi järjestelyksi. Sovellukseen verrattuna muutaman tunnin tapaamiset saattoivat vaikuttaa rutiininomaisilta tehtäviltä, mutta ryhmän jäsenet joutuivat sovittamaan ajankäyttöään puolenpäivän aikaan järjestettäviin tapaamisiin. Jäsenten kertoman mukaan saatiin enemmän aikaan sellaisina päivinä, jolloin palavereja ei järjestetty. Ryhmän jäsenet tunnistivatkin tarpeen pitää välillä taukoa ryhmän sisäisistä tapaamisista, jotta voisivat keskittyä paremmin vastuualueittensa itsenäisiin ohjelmointitehtäviin. Yksi tapaaminen viikossa koettiin riittämättömäksi ja kolmas tapaaminen viikossa koettiin ylimääräisenä. Sopivat ajankohdat olivatkin alkuviikosta maanantaina tai tiistaina sekä toisen kerran keskiviikkona tai torstaina. Viikonloppuisin ei edellytetty ohjelmointia, mutta monet varmasti käyttivät yhtäjaksoisen työrauhan hyväkseen. Taulukossa \ref{fig:toteutuksen-tyomaarat} esitetään toteutuksen toteutuneet työtunnit tehtävittäin.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
kirjoitus- ja ulkoasu & 0 & 0 & 1 & 0 & 1\\
\hline
käyttöliittymä & 122 & 0 & 47 & 0 & 169\\
\hline
muut tehtävät & 1 & 0 & 0 & 0 & 1\\
\hline
rajapinnat & 0 & 0 & 0 & 6 & 6\\
\hline
suunnittelu & 0 & 3 & 0 & 1 & 4\\
\hline
toteutus & 19 & 186 & 79 & 88 & 372\\
\hline
tukitehtävät & 3 & 0 & 0 & 4 & 7\\
\hline
valmistelu ja tutustuminen & 0 & 0 & 0 & 2 & 2\\
\hline
\textbf{Toteutus} & \textbf{145} & \textbf{189} & \textbf{127} & \textbf{101} & \textbf{562}\\
\hline
\end{tabular}
\caption{Toteutuksen toteutuneet työtunnit.}
\label{fig:toteutuksen-tyomaarat}
\end{table}

\FloatBarrier

\section{Testauksen työmäärät}
\label{ch:testauksen työmäärät}

Järjestelmätestaukseen suunniteltiin 96 tuntia, mutta käytettiin 63 tuntia. Ero johtuu siitä, että kolmatta testauskertaa ei ollut tarpeen suorittaa. Testauskerroilla havaitut häiriöt liittyivät suurimmaksi osaksi poikkeuskäsittelyyn, jolloin virheiden korjaaminen oli suoraviivaista. Taulukossa \ref{fig:testauksen-tyomaarat} esitetään järjestelmätestauksen toteutuneet työtunnit tehtävittäin.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c|c|c| }
\hline
\textbf{Tehtävä} & \textbf{RV} & \textbf{JP} & \textbf{II} & \textbf{HL} & \textbf{Yhteensä}\\
\hline
kirjoitus- ja ulkoasu & 0 & 0 & 34 & 0 & 34\\
\hline
käyttöliittymä & 0 & 0 & 1 & 13 & 14\\
\hline
muut tehtävät & 2 & 0 & 0 & 0 & 2\\
\hline
raportointi & 0 & 0 & 0 & 9 & 9\\
\hline
toteutus & 0 & 0 & 3 & 0 & 3\\
\hline
\textbf{Testaus} & \textbf{2} & \textbf{0} & \textbf{38} & \textbf{22} & \textbf{62}\\
\hline
\end{tabular}
\caption{Testauksen toteutuneet työtunnit.}
\label{fig:testauksen-tyomaarat}
\end{table}

Pakkanen ja Vilavaara merkitsivät testauskerralla havaittujen häiriöiden tai puutteiden korjaamiseen käyttämänsä työtunnit muihin tehtäväkokonaisuuksiin, mikä selittää osaltaan testauksen vähäiset kokonaistyötunnit. Testausvaihe kesti noin kaksi viikkoa, joten työtunnit olivat todellisuudessa suuremmat.

\FloatBarrier

\section{Resurssit ja työmäärät}
\label{ch:resurssien-tehtavat-ja-tyomaarat}

Tehtävät pyrittiin jakamaan tasaisesti ryhmän jäsenten kesken. Ryhmän jäsenten toteutuneet työtunnit noudattavat yhteistä tavoitetta hyvin. Projektisuunnitelmassa arvioitiin, että kaikki tekevät vähintään 400 tuntia. Ryhmän jäsenet kirjasivat työtunteja ajankäytönseurantaan vielä projektiraportin laatimisen jälkeen, joten taulukon projektiraportin sisältämät tuntimäärät ovat vain suuntaa antavia. Ajankäytönseurannan \cite{ajankaytonseuranta} mukaan kaikki ryhmäläiset saavuttivat 400 tunnin tavoitteen, kun oheiskurssien työtunnit poistetaan laskuista. Taulukko \ref{tab:projektin-resurssien-tyotunnit} sisältää jäsenten toteutuneet työtunnit oheiskursseja lukuun ottamatta.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|c|c|c| }
\hline
\textbf{Resurssi} & \textbf{Suunniteltu} & \textbf{Toteutunut} & \textbf{Erotus}\\
\hline
Iiro Iivanainen & 400 & 368 & -32\\
\hline
Harri Linna & 400 & 477 & 77\\
\hline
Jere Pakkanen & 400 & 406 & 6\\
\hline
Riikka Vilavaara & 400 & 384 & -16\\
\hline
\textbf{Yhteensä} & \textbf{1600} & \textbf{1635} & \textbf{35}\\
\hline
\end{tabular}
\caption{Projektin resurssien työtunnit.}
\label{tab:projektin-resurssien-tyotunnit}
\end{table}

Ryhmän jäsenet tekivät yhteistyötä tehtävien jakamisessa osallistumalla sekä projektinhallintaan että sovelluksen kehittämiseen. Tehtävät olivat nimellisiä ja niiden hajauttaminen paransi ryhmän yhteishenkeä. Jäsenet vastasivat vastuualueensa tuloksista, mutta muut jäsenet osin kehittivät niihin kuuluvia tuloksia.

Projektin kestosta huolimatta yli 100 työtunnin ero jäsenten kesken on suuri etenkin, kun se vastaa noin neljäsosaa yksittäisen jäsenen kokonaistyötunneissa. Toisaalta onko syytä mennä projektin jäsenten tasolle, jos kokonaisuus pysyy budjetissa. Taulukon \ref{tab:projektin-resurssien-tyotunnit} mukaan jäsenten työtuntien keskimääräinen erotus vastasi koko projektin erotuksen suuruusluokkaa. Projektinhallintaan liittyi kaikissa projektin vaiheissa viikoittain toistuvia velvoitteita ja johtotehtäviä, mikä näkyi suurempina tuntimäärinä.

\section{Iivanaisen työtunnit tehtäväkokonaisuuksittain}

Iivanainen oli päävastuussa järjestelmätestauksesta ja toteutti liitedatoihin ja metatietoihin liittyvät ohjelmaosiot. Iivanainen toimi palavereissa useamman kerran sihteerinä osallistuen sitä kautta projektinhallintaan. Hän osallistui kaikkiin projektin tehtäväkokonaisuuksiin vaatimusmäärittelyä lukuun ottamatta. Iivanainen aloitti toteutuksen kustomoidun liukusäätimen vastuualueensa parissa, jonka valmistuttua muita sovellusosioita oli ehditty suunnitella yhdessä palavereissa valmiiksi. Liukusäädintä ennen Iivanainen perehtyi useamman viikon ajan SharpGL-kirjastoon, jonka tunnit kirjattiin esitutkimusvaiheeseen. Kuva \ref{fig:iivanaisen-tyomaarat-vaiheittain} esittää Iivanaisen työtuntien jakautumista tehtäväkokonaisuuksiin.

\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{kuvat/projektiraportti/vaiheet/VaiheetLyhytK_Iivanainen.png}
    \caption{Iivanaisen työmäärät tehtäväkokonaisuuksittain.}
    \label{fig:iivanaisen-tyomaarat-vaiheittain}
\end{figure}

\FloatBarrier

\section{Linnan työtunnit tehtäväkokonaisuuksittain}

Linna oli projektipäällikkönä päävastuussa projektinhallinnasta, sovellussuunnitelmista ja toteutti tilakartan prototyypin. Linna toimi palavereissa puheenjohtajana ja neuvotteli asioista ryhmän puolesta. Projektisuunnitelman ja -raportin ulko- ja kirjoitusasun muokkaamiseen käytetyt työtunnit kirjattiin oheiskurssille, mikä selittää verraten suuret tuntimäärät. Kuva \ref{fig:linnan-tyomaarat-vaiheittain} esittää Linnan työtuntien jakautumista tehtäväkokonaisuuksiin.

\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{kuvat/projektiraportti/vaiheet/VaiheetLyhytK_Linna.png}
    \caption{Linnan työmäärät tehtäväkokonaisuuksittain.}
    \label{fig:linnan-tyomaarat-vaiheittain}
\end{figure}

\FloatBarrier

\section{Pakkasen työtunnit tehtäväkokonaisuuksittain}

Pakkanen oli päävastuussa vaatimusmäärittelystä ja toteutti luokkarakenteen karttatiedostoihin liittyvät ohjelmaosiot. Pakkanen oli varapäällikkö ja toimi palavereissa toistuvasti puheenjohtajana. Vaativa ohjelmointitehtävä vei suurimman osan työtunneista. Kuva \ref{fig:pakkasen-tyomaarat-vaiheittain} esittää Pakkasen työtuntien jakautumista tehtäväkokonaisuuksiin.

\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{kuvat/projektiraportti/vaiheet/VaiheetLyhytK_Pakkanen.png}
    \caption{Pakkasen työmäärät tehtäväkokonaisuuksittain.}
    \label{fig:pakkasen-tyomaarat-vaiheittain}
\end{figure}

\FloatBarrier

\section{Vilavaaran työtunnit tehtäväkokonaisuuksittain}

Vilavaara oli päävastuussa sovellusraportista sekä toteutti käyttöliittymään mukaan lukien sen arkkitehtuuriin liittyvät ohjelmaosiot. Vilavaara toimi palavereissa useamman kerran sihteerinä ja osallistui aktiivisesti projektinhallintaan. Sihteerinä toimiessaan hän kirjasi ylös palaverien päätöksiä ja valvoi näiden päätösten toteutumista. Kuva \ref{fig:vilavaaran-tyomaarat-vaiheittain} esittää Vilavaaran työtuntien jakautumista tehtäväkokonaisuuksiin.

\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{kuvat/projektiraportti/vaiheet/VaiheetLyhytK_Vilavaara.png}
    \caption{Vilavaaran työmäärät tehtäväkokonaisuuksittain.}
    \label{fig:vilavaaran-tyomaarat-vaiheittain}
\end{figure}

\FloatBarrier

\chapter{Prosessi ja aikataulu}
\label{ch:prosessi-ja-aikataulu}

Luvussa kuvataan projektissa noudatettua prosessia ja toteutunutta aikataulua. Projektiin suunniteltua alkuperäistä vaihejakoa ei tarkalleen ottaen noudatettu, koska valittu prosessi vaihdettiin toteutusvaiheen aikana. Lisäksi kaikkia ajankäyttöraportin määrittämiä vaiheita ei sisällytetty suunnitelmaan.

Prosessi epäilemättä vaikutti projektin tuloksiin, sillä projektin päättyminen viivästyi suunnitellusta kolmella kuukaudella. Tilaajan edustajat eivät olleet asettaneet projektille takarajaa ja tulokset luovutettiin projektisopimuksen päättymisen jälkeen. Projektin alkuperäinen aikataulu osoittautui optimistiseksi, sillä 1600 työtunnin tavoite olisi edellyttänyt suunnitellulla aikataululla projektiryhmältä noin 85 tunnin viikoittaista työmäärää.

\section{Prosessi}
\label{ch:prosessi}

Sovellusprojektin läpiviennissä sovellettiin takaisinkytkettyä vesiputousmallia, johon liittyvät päävaiheet ovat määrittely, suunnittelu, toteutus, testaaminen ja viimeistely. Prosessin vaiheita kuvataan tarkemmin projektisuunnitelmassa \cite{projektisuunnitelma}. Projektissa noudatettu prosessimalli ei ollut ensimmäinen prosessi, jota projektissa sovellettiin, sillä alkuvaiheessa suunniteltiin käytettävän Scrumia, mutta jo suunnitteluvaiheessa havaittiin, ettei siihen mennessä noudatettu prosessi ollut riittävän ketterä ja projektin läpiviennissä oli nähtävissä selkeät vesiputousmallin kehitysvaiheet.

Scrumin jäänteet ovat nähtävissä tehtävienhallinnassa, jossa ryhmän viikkopalavereissa laadittiin vaiheen työlista, johon nostettiin korkean prioriteetin viikoittaisia tehtäviä ominai\-suus-listasta. Scrumin soveltamisessa epäonnistuttiin siinä, että viikoittaisten syklien (listojen) tehtävät (kortit) liittyivät samaan tehtäväkokonaisuuteen (vaiheeseen). Toteutusvaiheessa sovelluksen hahmotelmia ja toimintaa olisi kannattanut laajentaa inkrementaalisesti pienissä erissä, mutta toteumassa tähdättiin valmiiseen sovellukseen ennen ensimmäisten prototyyppien julkistamista.

Tehtävien jakaminen kunkin jäsenen vastuualueen mukaisesti aiheutti sen, että ominaisuuksia kehitettiin toisistaan erillään, jolloin ohjelmasta saatiin ajettava prototyyppi vasta toteutusvaiheen loppupuolella. Havainto otettiin puheeksi ryhmän jäsenten kanssa viikkopalaverissa, jossa projektipäällikkö ehdotti, että sovellusta kehitettäisiin sykleissä lisäten toimintoja pienissä erissä. Selkeät vastuualueet koettiin toimivana järjestelynä, joten ryhmän yhteiseksi kannaksi muodostui prosessin vaihtaminen vesiputousmalliin. Päätöksestä tiedotettiin projektiorganisaatiota keskustelua seuranneessa projektipalaverissa ja ryhmä siirtyi noudattamaan takaisinkytkettyä vesiputousmallia vastaavan ohjaajan ehdotuksesta. Tämä tarjosi vaiheisiin kaivattua joustavuutta, jolloin tuloksia ei tarvinnut kiinnittää kuin vasta projektikansiota koostettaessa. Prosessimallin vaihtamiseen ajauduttiin siksi, että projektin alkuvaiheessa suunnitellun scrum-mallin käyttöönotossa epäonnistuttiin. Scrum-malli edellyttää yleensä kokenutta tiimiä ja scrum masteria, jolla on menetelmästä vankka kokemus. Kun näin ei ollut, oli prosessin vaihtaminen oikea ratkaisu. Etätyöskentely lisää haasteita scrum-mallilla toimittaessa.

Takaisinkytkeytyvän vesiputousmallin eräs suurimmista hyödyistä liittyi kuitenkin aikataulujen suunnittelun suoraviivaisuuteen, sillä kehitysvaiheet asettuivat järjestyksessä Gantt-kaavion aikajanalle. Aikataulusta tarvitsi määrittää vain tehtäväkokonaisuuksien sisältämien tehtävien tulokset ja niiden työmääräarviot. Keskeisten tulosten valmistuttua siirryttiin seuraavaan vesiputousmallin vaiheeseen, joka sisälsi hyvin samanlaisen tehtäväkokonaisuuden kuin edellisessä vaiheessa, mikä on nähtävissä Gantt-kaaviossa. Scrumin aikana kokonaistyömäärää oli vaikeampi suunnitella tai arvioida etukäteen. Projektipäällikön projektinhallinnan tiedot olivat kenties riittämättömät ketterien prosessimallien suunnitteluun.

\section{Projektin kehitysvaiheet}
\label{ch:projektin-kehitysvaiheet}

Esitutkimusvaiheen aikana tutustuttiin projektin toimintaympäristöön ja tilaajan esittämiin tarpeisiin. Lisäksi kartoitettiin projektin tavoitteet, keskeiset reunaehdot ja ongelma-alueet. Näiden perusteella hahmoteltiin projektille alustava aikataulu- ja työmääräarvio.

Määrittelyvaiheessa kartoitettiin sovellusvaatimukset. Vaiheen tuloksena tilaajalle toimitettiin vaatimusmäärittely.

Suunnitteluvaiheessa laadittiin tilaajan edustajien kanssa keskustellen dokumentit, jotka kuvaavat tarkasti sovellukselle asetetut tavoitteet ja tarpeet. Vaiheen aikana kuvattiin käyttöliittymä, arkkitehtuuri ja luokkarakenne. Suunnitteluvaiheen katsotaan käynnistyneen, kun aloitettiin sovellussuunnitelmien laatiminen. Sovellussuunnitelmien tarkennuttua toteutuskelpoisiksi, siirryttiin toteutusvaiheeseen. Projektin aikana kehitettävä sovellus oli uusi, joten toteutusvaiheeseen siirtyminen edellytti kehitysympäristön ja työkalujen valintaa.

Toteutusvaiheessa projektiryhmän kesken sovittiin kullekin ryhmän jäsenelle selkeät vastuualueet, jotka määrittivät luonnollisesti tehtävänjakoa. Sovellussuunnitelmia noudatettiin tarkasti. Joitain merkittäviä vaatimuksia jouduttiin rajaamaan jatkokehitykseen ennen testausvaiheeseen siirtymistä.

Sovelluksen testaaminen suunniteltiin toteutettavan testauksen V-mallin periaatteita noudattaen. Vaatimusten toteutuminen todennettiin hyväksymistestauksen sijaan tilaajan edustajien suorittamalla sovelluksen koekäytöllä. Sovelluksen toimivuuden projektiryhmä varmisti järjestelmätestauksella, mutta yksittäisiä aliohjelmia ei yksikkötestattu. Yksikkötestit olisi kannattanut lisätä projektin tuloksiin ja niiden toteutus vastuuttaa.

Viimeistelyvaiheessa laadittiin sovelluksen käyttöohjeet, sovellus- ja projektiraportti. Tulokset viimeisteltiin ja kerättiin projektikansioon arkistoitavaksi. Tilaajalle luovutettiin sähköinen versio projektikansiosta.

\section{Aikataulu}
\label{ch:aikataulu}

Projekti alkoi 2.2.2021 ja sen suunniteltiin päättyvän 11.6.2021. Projektin toteutuneita tarkistuspisteitä olivat väliesittely, kaksi koodikatselmointia ja lähdekoodin hyväksymistarkistus.
% Projekti päätettiin tulosten luovuttamiseen, joka tapahtui 27.8.2021.
Projekti päätettiin ennen tulosten luovuttamista 31.8.2021. Aikataulullisesti projekti myöhästyi yksitoista viikkoa suunnitellusta. Keskeiset syyt myöhästymiseen olivat viivästymät toteutuksessa ja testauksessa, jotka johtivat siihen, että viimeistelyvaiheen tehtävät sijoittuivat keskelle loma-aikaa.

Esitutkimus-, määrittely- ja suunnitteluvaihe alkoivat ja päättyivät suunnitelman mukaisesti.

Toteutusvaihe aloitettiin suunnitelman mukaisesti, mutta toteuttaminen viivästyi suunnitellusta runsaat kaksi viikkoa valmistuen 15.6.2021. Viivästyminen olisi ollut tätäkin suurempi ilman toiminnallisuuteen tehtyjä rajauksia, jotka on kuvattu luvussa \ref{ch:sovelluksen-toteutumattomat-tavoitteet}. Toteutusvaiheen viivästymisessä suurin yksittäinen syy oli projektiryhmän kokemuksessa, joka johti tiettyyn tehottomuuteen toteutusratkaisuja valittaessa sekä projektinhallinnan ja viestinnän vaatiman ajan aliarviointi.

Viivästymä toteutusvaiheessa vaikutti suoraan testausvaiheeseen, joka käynnistettiin neljä viikkoa suunniteltua myöhemmin. Testaus itsessään onnistuttiin toteuttamaan suunniteltua nopeammin ja se valmistui vain kolme viikkoa suunniteltua myöhemmin 5.7.2021.

Viimeistelyvaihe käynnistettiin viisi viikkoa suunniteltua myöhemmin ja pääosa työskentelystä ajoittui kesäaikaan, jonka vuoksi valmistuminen kesti suunniteltua pidempään. Viimeistelyvaiheeseen sisältyi neljän viikon ajanjakso, jolloin ei pidetty projekti- tai ryhmäpalavereja ja jäsenet keskittyivät itsenäiseen raporttien viimeistelyyn. Viimeistelyvaihe ja koko projekti valmistui 20 viikkoa suunniteltua myöhemmin 29.10.2021. Viimeistelyvaiheen viivästymässä konkretisoitui projektiryhmän kokemattomuus dokumentoinnissa. Projektidokumentaation kokoaminen ja viimeistely veivät kommenttikierroksineen suunniteltua enemmän kalenteriaikaa.

% Viimeistelyvaihe ja koko projekti valmistui yksitoista viikkoa suunniteltua myöhemmin 31.8.2021.

Projektin suunniteltu ja toteutunut aikataulu esitellään kuvassa \ref{fig:projektin-aikataulu}, jossa otettiin pohjaksi projektisuunnitelman versio 1.0.0.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/GanttAikataulu.pdf}
    \caption{Projektin aikataulu.}
    \label{fig:projektin-aikataulu}
\end{figure}

\FloatBarrier

\section{Ryhmän työtunnit viikoittain}
\label{ch:ryhman-tyotunnit-viikoittain}

Projektin alussa asetettua koko ryhmän viikoittaista tuntitavoitetta laskettiin 100 tunnista 70 tuntiin viikolla 14, mikä tarkoitti yhdeltä jäseneltä alle 20 tunnin työmäärää viikoittain. Projektiohjeen mukaan toteutusaikaa olisi noin 13–16 viikkoa, minkä perusteella jäsenten olisi tullut varata viikoittain vähintään 20–30 tuntia projektityöhön. Projektin työmäärätavoite 17,5 tuntia viikossa oli huomattavasti vähemmän kuin suositeltu vähimmäistyömäärä, mutta se oli saavutettavissa. Ryhmän käyttämien työtuntien jakaantuminen eri viikoille esitetään kuvassa \ref{fig:ryhman-tyotunnit-viikoittain}.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/viikot/ViikotTekijatK_Kaikki.png}
    \caption{Ryhmän työtunnit viikoittain.}
    \label{fig:ryhman-tyotunnit-viikoittain}
\end{figure}

Projektissa päästiin tuntitavoitteeseen suurimpana osana viikoista. Ryhmän jäsenten työtunnit eivät jakautuneet tasaisesti projektin aikana, mutta yhteenlasketut tuntimäärät vastasivat ryhmän yhteistä tavoitetta. Projekti käynnistyi kunnolla huhtikuussa, kun sovelluksen tekninen puoli alkoi vähitellen hahmottua ja voitiin siirtyä toteutusvaiheeseen.

\FloatBarrier

\pagebreak

\section{Iivanaisen työtunnit viikoittain}
\label{ch:iivanaisen-tyotunnit-viikoittain}

Suunnitteluvaiheessa Iivanainen jäi tuntitavoitteesta projektin alkupuolella useampana viikkona johtuen grafiikkakirjaston toiminnan haastavuudesta. Viikosta 14 lähtien hän pääsi joka viikko tavoitteeseen ja useampana viikkona yli tavoitteen, lukuun ottamatta kahta viimeistä viimeistelyvaiheen viikkoa. Projektin loppupuolella tunteja kertyi erityisesti testausvaiheen dokumenttien laatimisesta.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/viikot/ViikotTekijatK_Iivanainen.png}
    \caption{Iivanaisen työtunnit viikoittain.}
    \label{fig:iivanaisen-tyotunnit-viikoittain}
\end{figure}

\pagebreak

\section{Linnan työtunnit viikoittain}
\label{ch:linnan-tyotunnit-viikoittain}

Linna ei osallistunut sovelluksen ohjelmointiin toteutusvaiheessa, joka sijoittui viikoille 11--24. Väliesittelyn jälkeen Linna toteutti tilakartan prototyypin ja ensimmäisen järjestelmätestauskerran, muuten hän keskittyi projektinhallintaan ja suunnitteludokumenttien laatimiseen. Testauksen jälkeinen kuukausi pyhitettiin projektiraportin tavoitteelliseen kirjoittamiseen.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/viikot/ViikotTekijatK_Linna.png}
    \caption{Linnan työtunnit viikoittain.}
    \label{fig:linnan-tyotunnit-viikoittain}
\end{figure}

\pagebreak

\section{Pakkasen työtunnit viikoittain}
\label{ch:pakkasen-tyotunnit-viikoittain}

Pakkasen viikoittaiset työtuntimäärät vaihtelivat suuresti. Suurempien viikkojen ansiosta Pakkanen pystyi ottamaan hieman rennommin muilla viikoilla työtuntien suhteen. Vaatimusmäärittelyä päivitettiin usein samalla viikoilla kuin palavereja pidettiin, mikä näkyy poikkeuksellisen korkeina tuntimäärinä. Pakkanen osallistui muita enemmän sovelluksen vaativan tiedoston- ja virheenkäsittelyn toteuttamiseen, mutta jäi alle tuntitavoitteen projektin muissa vaiheissa.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/viikot/ViikotTekijatK_Pakkanen.png}
    \caption{Pakkasen työtunnit viikoittain.}
    \label{fig:pakkasen-tyotunnit-viikoittain}
\end{figure}

\pagebreak

\section{Vilavaaran työtunnit viikoittain}
\label{ch:vilavaaran-tyotunnit-viikoittain}

Vilavaaran viikoittaiset työtuntimäärät vaihtelivat myös suuresti. Suurin osa työtunneista sijoittui toteutusvaiheeseen, jossa hän toteutti suurelta osin käyttöliittymäpuolen ohjelmaosion. Testausvaiheen jälkeen Vilavaara kertoi sairastuneensa, mistä johtuen sovellusraportin kirjoittaminen siirtyi viimeistelyvaiheen alusta myöhempään ajankohtaan.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.9\textwidth]{kuvat/projektiraportti/viikot/ViikotTekijatK_Vilavaara.png}
    \caption{Vilavaaran työtunnit viikoittain.}
    \label{fig:vilavaaran-tyotunnit-viikoittain}
\end{figure}

\FloatBarrier

\chapter{Riskit ja niiden hallinta}
\label{ch:riskit-ja-niiden-hallinta}

Luvussa kuvataan projektin ennakoitujen riskien toteutumista sekä niiden vaikutusta projektin läpivientiin ja tuloksiin. Lisäksi esitellään toimenpiteet riskin ennaltaehkäisyyn ja toipumissuunnitelmat riskien toteutumisen varalta. Riskien haittavaikutuksiin varauduttiin varaamalla työvaiheisiin arvioitua enemmän aikaa, mutta aikaresurssien ehtyessä sovelluksesta jouduttiin rajaamaan tärkeitä toimintoja jatkokehitykseen.

\section{Riskien todennäköisyydet ja vakavuudet}
\label{ch:riskien-todennäköisyydet-ja-vakavuudet}

Groundhog-projektin läpivientiin liittyviä riskejä arvioitiin nelikenttämallilla, jossa riskin toteutumisen todennäköisyys ja seurausten vakavuus luokiteltiin suureksi, kohtalaiseksi tai pieneksi. Riskit järjestettiin ensisijaisesti vakavuuden tai toissijaisesti todennäköisyyden perusteella. Jos joko riskin vaikutus tai todennäköisyys oli pieniä, kokonaisriski oli myös pieni eikä se vaatinut välittömiä toimenpiteitä. Jos sekä riskin vaikutus että todennäköisyys olivat suuria, myös kokonaisriski oli suuri ja toimenpiteet riskin ehkäisemiseksi ja toipumissuunnitelman laatimiseksi käynnistettiin välittömästi. Kaikissa muissa tapauksissa riski oli keskinkertainen ja edellytti suunnitelman laatimista riskin ehkäisyksi. Oheinen riskimatriisi kuvaa projektin alussa tunnistetut riskit ja toteutuneiden riskien osalta toteutuneen vakavuuden. Projektin aikana uusia riskejä ei tunnistettu.

\begin{table}[h!]
\centering
\begin{tabular}{ |l|p{2.5cm}|p{2.5cm}|p{2.5cm}| }
\hline
\textbf{Riskin kuvaus} & \textbf{Arvioitu todennäköisyys} & \textbf{Arvioitu vakavuus} & \textbf{Toteutunut vakavuus}\\
\hline
Aikaresurssien rajallisuus & Suuri & Suuri & Kohtalainen\\
\hline
Tilojen ja laitteiden puute & Suuri & Kohtalainen & Kohtalainen\\
\hline
Ryhmän tietotaitojen puute & Kohtalainen & Kohtalainen & Kohtalainen\\
\hline
Ryhmän jäsenten muut sitoumukset & Kohtalainen & Kohtalainen & -\\
\hline
Ominaisuuksien toteuttamisen vaikeus & Pieni & Kohtalainen & -\\
\hline
\end{tabular}
\caption{Riskien arviointi.}
\label{tab:riskien-arviointi}
\end{table}

Riskienhallintaa voidaan projektissa pitää onnistuneena. Riskit tunnistettiin jo projektin alussa ja toimenpiteet riskien todennäköisyyksien ja vaikutusten pienentämiseksi olivat pääsääntöisesti onnistuneita. Sovellus valmistui sovellukseen toteutettavien ominaisuuksien rajausten ja tilaajan esittämien muutosten jälkeen ajallaan. Voidaan kuitenkin arvioida, että joidenkin riskien kohdalla toimenpiteiden käynnistäminen vieläkin aikaisemmassa vaiheessa projektia olisi pienentänyt riskin vaikutusta entisestään. Yhden riskin (ryhmän tietotaitojen puute) osalta arvioitua todennäköisyyttä ei seurattu riittävästi ja riski toteutui ilman, että siihen olisi varauduttu laatimalla toipumissuunnitelma. Suuremmassa projektissa riskienhallinnan systemaattisuuteen tulee kiinnittää enemmän huomiota kuten myös käytettäviin hallintavälineisiin.

\FloatBarrier

%\section{Riskien hallinta}
%\label{ch:riskien-hallinta}

\section{Aikaresurssien rajallisuus}
\label{ch:aikaresurssien-rajallisuus}

\textbf{Toteuma:} Riski toteutui osittain. Kaikkia suunniteltuja toimenpiteitä ei pystytty toteuttamaan ja osa toteutettiin ajallisesti liian myöhään, mutta vaikutus onnistuttiin rajaamaan hyväksyttävälle tasolle.

\textbf{Kuvaus:} Aikaresurssien rajallisuus liittyy ohjelmiston laatutavoitteisiin. Hyvä ohjelmisto vaatii perusteellista suunnittelua, järjestelmällistä testaamista sekä runsaasti iteraatioita ohjelmakoodin refaktoroinnissa. Projekti toteutetaan annettujen aikaresurssien puitteissa.

\textbf{Vaikutus:} Projektia toteutettiin takaisinkytketyn vesiputousmallin mukaisesti. Riski konkretisoitui toteutusvaiheessa, jolloin osa suunnitellusta toteutuksesta siirrettiin jatkokehityksessä toteutettavaksi.

\textbf{Toimenpiteet riskin ennaltaehkäisyyn:}
\begin{compactitem}
    \item Vaatimusmäärittelyssä priorisoitiin kriittisimmät toiminnallisuudet toteutettavaksi ensimmäisinä (toteutettu).
    \item Sovellusta kehitettiin inkrementaalisesti lisäämällä uusia ominaisuuksia muokaten iteratiivisesti olemassa olevaa takaisinkytketyn vesiputousmallin mukaisesti. Toimiva sovellus saatiin kuitenkin koottua yhteen varsin myöhäisessä vaiheessa toteutusta, tässä Scrum-prosessi oli saattanut toimia paremmin (toteutui osittain).
    \item Arkkitehtuuria ja luokkarakennetta suunniteltaessa hyödynnettiin C\#-kielen standardikirjastoja sekä geneerisiä tyyppejä rajapinnoissa. Tämä mahdollisti sovelluksen joustavan muokkaamisen (toteutettu, osoittautui kuitenkin joissain tilanteissa vääräksi valinnaksi).
    \item Käyttöliittymä suunniteltiin käyttävän ikkunointia, joka helpotti moduulien lisäämisen ja korvaamisen (toteutettu).
    \item Suunnittelu- ja toteutusvaihe aloitettiin mahdollisimman varhaisessa vaiheessa ja laadukas prototyyppi ennätettiin toteuttaa (toteutettu).
    \item Tavoitteena oli, että yksikkötestaus aloitetaan samaan aikaan kuin toteutus, jotta niitä voisi suorittaa samanaikaisesti. Tähän ei kuitenkaan päästy ja sovellusta ei yksikkötestattu kehityksen aikana (ei toteutettu).
\end{compactitem}

\textbf{Toipumissuunnitelma riskin toteutumisen varalta:}
\begin{compactitem}
    \item Projektin aikana tilaajan kanssa sovittiin tietyt toiminnallisuudet siirrettäväksi jatkokehitykseen. Projektin päättyessä voitiin toimittaa toimiva prototyyppi vaikkakin toiminnallisuudeltaan suunniteltua suppeampana (toteutettu).
    \item Projektiryhmä laati vaatimusmäärittelyn, sovellusraportin, käyttöohjeen ja testausdokumentit. Tavoitteena oli, että projektiryhmä olisi dokumentoinut myös jatkokehitykseen siirretyn toiminnallisuuden sillä tasolla, että toteutusta olisi näiltä osin voitu aikanaan suoraan jatkaa. Tähän ei kuitenkaan päästy (ei toteutettu).
\end{compactitem}

\section{Tilojen ja laitteiden puute}
\label{ch:tilojen-ja-laitteiden-puute}

\textbf{Toteuma:} Riski toteutui jo ennen projektin käynnistymistä.

\textbf{Kuvaus:} Projektin käynnistysvaiheessa tavoitteena oli tehdä töitä yhteisissä tiloissa ja projektin tarjoamilla laitteilla. Covid19-pandemien aiheuttamien yliopiston tilojen käyttörajoitusten takia, ryhmä ei saanut huonetta käyttöönsä ja projektin jäsenten tuli työskennellä henkilökohtaisilla laitteilla.

\textbf{Vaikutus:} Sovelluksen tuli vaatimusmäärittelyn mukaan toimia millä tahansa perustason tietokoneella, joten laitteiden vaikutus projektiin ei ollut suuri. Kaikilla projektilaisilla ei kuitenkaan ollut samanlaista laitekokoonpanoa, mikä aiheutti pieniä viiveitä kehityksessä ja vaikeutti työnjakoa. Yhteisten tilojen puuttuminen vaikutti ryhmätyöskentelyyn, jolle löydettiin korvaavia muotoja.

\textbf{Toimenpiteet riskin ennaltaehkäisyyn:}
\begin{compactitem}
    \item Riski toteutui jo ennen töiden käynnistymistä, joten ennaltaehkäisyä ei kyetty suunnittelemaan.
\end{compactitem}

\textbf{Toipumissuunnitelman riskin toteutumisen varalta:}
\begin{compactitem}
    \item Projektiryhmä työskenteli kokonaan etänä henkilökohtaisilla tietokoneillaan. Tietotekniikan opiskelijoilla oli riittävät työvälineet työpöytäsovelluksen kehittämiseen (toteutettu).
    \item Otettiin käyttöön etätyöskentelyä tehostava Discord-kanava, johon kuului ryhmän jäsenten lisäksi tekninen ohjaaja. Ryhmä kokoontui puheyhteyden ylitse neuvottelemaan kolmesti viikossa (maanantaisin, keskiviikkoisin ja perjantaisin) ajankohtaisista toimenpiteistä (toteutettu).
\end{compactitem}

\section{Ryhmän tietotaitojen puute}
\label{ch:ryhman-tietotaitojen-puute}

\textbf{Toteuma:} Riski toteutui. Toimenpiteiden ansiosta vaikutus onnistuttiin rajaamaan hyväksyttävälle tasolle siirtämällä tilaajan kanssa sovitusti osa toiminnallisuuksista jatkokehitykseen.

\textbf{Kuvaus:} Projektiryhmän kokemus kyseessä olevan kokoluokan sovellusprojektista sekä siihen liittyvästä projektityöskentelystä oli vähäistä.

\textbf{Vaikutus:} Resurssien käytön tehottomuuden seurauksena osa sovelluksen ominaisuuksista jouduttiin rajaamaan toteutuksen ulkopuolelle.

\textbf{Toimenpiteet riskin ennaltaehkäisyyn:}
\begin{compactitem}
    \item Tilaajan edustajilla oli runsaasti tietotaitoa aihealueesta, joten projektiryhmä sai on saanut erinomaista ohjeistusta toteutusratkaisuihin (toteutettu).
    \item Projektiryhmä valitsi ohjelmointikielen ja kehitysympäristön sekä sovittujen lisenssien puitteissa myös ulkoiset kirjastot, mutta kokemuksen puute näkyi erityisesti tehdyissä valinnoissa (toteutettu).
    \item Teknisellä ohjaajalla oli runsaasti kokemusta ohjelmistokehitysprojekteista, ohjelmoinnista ja kuvankäsittelyn ohjelman kehittämisestä ja tätä hyödynnettiin (toteutettu).
\end{compactitem}

\textbf{Toipumissuunnitelma riskin toteutumisen varalta:}
\begin{compactitem}
    \item Riski toteutui ilman toipumissuunnitelmaa. Toipumisessa hyödynnettiin toimintojen siirtämistä jatkokehitykseen, joka sovittiin tilaajan kanssa.
\end{compactitem}

\section{Ryhmän jäsenten muut sitoumukset}
\label{ch:ryhman-jasenten-muut-sitoumukset}

\textbf{Toteuma:} Riski onnistuttiin suunnitelluilla toimenpiteillä välttämään. Jäsenille ei tullut ennakoimattomia sitoumuksia.

\textbf{Kuvaus:} Projektiryhmän jäsenten muut sitoumukset olisivat saattaneet viivästyttää projektin läpivientiä. Kaksi ryhmän jäsenistä kirjoitti pro gradu -tutkielmaa samaan aikaan, mikä esti täysipäiväisen työskentelyn. Tilaajan edustajat eivät vaatineet projektin valmistuvan tietyssä aikataulussa, mutta projektisopimuksessa määritettiin ehdoton takaraja projektin valmistumiselle.

\textbf{Vaikutus:} Projekti viivästyi, mutta ei tämän riskin vuoksi.

\textbf{Toimenpiteet riskin ennaltaehkäisyyn:}
\begin{compactitem}
    \item Ryhmä asetti itselleen viikoittaisen 100 tunnin tavoitteen, johon sovelluksen edistymistä peilattiin viikoittaisessa tilakatsauksessa. Viikkotavoite pienennettiin projektin aikana 70 tuntiin (toteutettu).
    \item Poissaoloista aiheutuneet vaikutukset ehkäistiin siten, että muista sitoumuksista ilmoitettiin ryhmälle etukäteen. Tällöin ryhmän muut jäsenet sopivat, ketkä suorittavat poissaolevan tehtävät (toteutettu).
\end{compactitem}

\textbf{Toipumissuunnitelma riskin toteutumisen varalta:}
\begin{compactitem}
    \item Kokonaisriski ei noussut eikä toipumissuunnitelmaa laadittu.
\end{compactitem}

\section{Ominaisuuksien toteuttamisen vaikeus}

\textbf{Toteuma:} Riski onnistuttiin suunnitelluilla toimenpiteillä välttämään.

\textbf{Kuvaus:} Toteutettavat ominaisuudet oli määritetty selkeästi. Tästä huolimatta toteutus on osoittautunut haastavaksi versiohallinnan lukuisista \textit{fix}-alkuisista komennoista päätellen. Käsiteltävät tiedostot olivat suuria, joten niitä ei välttämättä voinut lukea muistiin kerralla. Myös käsiteltäviä tiedostotyyppejä oli erilaisia, mikä lisäsi toteutuksen vaikeutta.

\textbf{Vaikutus:} Projekti viivästyi ja osa toiminnallisuuksista siirrettiin jatkokehitykseen. Syynä tähän ei kuitenkaan ollut ominaisuuksien toteuttamisen vaikeus.

\textbf{Toimenpiteet riskin ennaltaehkäisyyn:}
\begin{compactitem}
    \item Haastavien toimintojen osalta toteuttajat ottivat yhteyttä tekniseen ohjaajaan tai tilaajan edustajiin (toteutettu).
    \item Ryhmäpalavereissa tarkennettiin toteutusratkaisuja (toteutettu).
    \item Selvitettiin mahdollisuudet valmiskomponenttien käyttöön esimerkiksi datan lukemisen osalta (toteutettu).
\end{compactitem}

\textbf{Toipumissuunnitelma riskin toteutumisen varalta:}
\begin{compactitem}
    \item Kokonaisriski ei noussut eikä toipumissuunnitelmaa laadittu.
\end{compactitem}

\chapter{Jäsenten kokemuksia ja oppimaa}
\label{ch:jasenten-kokemuksia-ja-oppimaa}

Luvussa kuvataan projektiryhmän jäsenten kokemuksia ja oppimaa sovellusprojektista. Projekti oli kaikille ryhmän jäsenille ensimmäinen oikea ohjelmistokehitysprojekti, joka sisälsi projektin kaikki kehitysvaiheet aina vaatimusmäärittelystä projektin tulosten luovutukseen asti. Ryhmän jäsenet kokevat oppimistavoitteidensa toteutuneen hyvin ja ovat olleet tyytyväisiä päästyään mukaan projektiin. Ryhmän jäsenet saivat kattavan kuvan projektinhallinnasta ja tilaajien kanssa toimimisesta, vaikka projektin tulokset toimitettiin vasta sopimuksen määräajan päättymisen jälkeen. Luvuissa \ref{ch:iivanaisen-kokemuksia-ja-oppimaa}--\ref{ch:vilavaaran-kokemuksia-ja-oppimaa} ryhmän jäsenet kuvaavat kokemuksiaan ja oppimiaan asioita.

\section{Iivanaisen kokemuksia ja oppimaa}
\label{ch:iivanaisen-kokemuksia-ja-oppimaa}

Iivanainen käsitti projektin tilaisuutena haastaa omia ohjelmointitaitojaan projektin laajuisessa ohjelmointityössä. Hänellä oli päällimmäisenä ajatuksena riittävätkö taidot tämän laajuiseen ohjelmistokehitykseen. Iivanainen arveli, että etäaikana voisi ottaa palaverien osalta hieman rennommin, mutta päinvastoin yllättyikin erilaisten ohjeiden määrästä.

Kirjoittamisesta ja ohjelmoinnista opittiin suhteellisen paljon sekä projektin hallinnasta tarvittavista niin sanotuista pehmeistä taidoista. Iivanainen kertoo näiden taitojen parantuneen käytännön kokemuksen kautta enemmän kuin niihin tarkoitetuilla kursseilla aikaisemmin. Toisten ohjelmakoodiin ei tarvinnut juurikaan puuttua, koska ryhmällä oli selkeät vastuualueet. Ryhmätyöskentelyssä taas enempi kommunikoinnin määrä oli vähempää parempi. Projekti koettiin rentona suorittamisena, vaikka vastuuta ja painetta oli viedä sitä eteenpäin.

Palaverien pöytäkirjat ovat suurelta osin Iivanaisen käsialaa. Virallisempana vastuualueena olivat järjestelmätestauksen dokumentit, joiden laatimisessa otettiin mallia aiempien ryhmien valmiista dokumenteista. Hän huomaa hyödyntävänsä nykyisin enemmän hahmolakeja sekä muita tekstin luettavuutta parantavia asioita. Myös tekstin muotoiluun kiinnitetään enemmän huomiota. Sovelluksen liitedatojen käsittelyyn ja käyttöjärjestelmään liittyvien ohjelmaosien toteuttamisen myötä Iivanainen hahmottaa paremmin ohjelmaosien ja vastuualueiden rajoja. Hänen mukaansa ohjelmakoodin parantaminen tehostuu ja tarvittaessa voi kohdistaa kysymyksiä vastuuhenkilölle, kun kehittäjillä on selkeät vastuualueet.

\section{Linnan kokemuksia ja oppimaa}
\label{ch:linnan-kokemuksia-ja-oppimaa}

Odotin kurssilta tilaisuutta osallistua projektiin, joka olisi sisältänyt enemmän käytännön ryhmätyötä ja vähemmän itsenäisiä kirjoitustehtäviä. Aihekuvausta lukiessani saatoin olla tyytyväinen ryhmävalintaan, vaikka en tuntenut muita ryhmän jäseniä entuudestaan. Ensisijaisesti valmistauduin ohjelmoijan rooliin, mutta ryhdyin sitten oma-aloitteisesti projektipäälliköksi.

Projektia sitoivat yliopiston mallit ja odotukset, joita noudattamalla olisi varmaankin päässyt vähemmällä. Palavereja lukuun ottamatta projekti koostui omalla kohdallani itsenäisesti suoritettavista kirjoitustehtävistä. Ryhmätyöt menevät monesti etänä sellaiseksi, että sovitaan yhdessä tehtävienjaosta, mutta varsinainen työnteko tehdään itsenäisesti.

Projektipäällikön vastuualue koostui projektinhallinnan tehtäväkokonaisuudesta. Kokemukseni mukaan hyvällä projektihallinnalla voidaan tunnistaa muutoksia vaativia toimenpiteitä, mutta projektipäälliköltä puuttuu todellinen vaikutusvalta opiskelijaprojekteissa. Projekti alkaa olla sen verran myöhässä, ettei projektinhallinta ole enää kovin mieluisaa.

\section{Pakkasen kokemuksia ja oppimaa}
\label{ch:pakkasen-kokemuksia-ja-oppimaa}

Ennen projektin alkamista Pakkanen tiesi odottaa suurta työmäärää, sillä hän oli tutustunut aiempien vuosien projekteihin ja projektiohjeeseen. Muita odotuksia liittyi palaverien virallisuuteen ja pöytäkirjojen laatimiseen. Aluksi työmäärä arvelutti, mutta projektin edetessä ennakkoluulot hälvenivät havainnon myötä, että uuden opettelua ei ollut kauheasti. Suuresta työmäärästä huolimatta projektissa ei ollut yhtä paljoa uuden opettelua kuin luentokursseilla mihin oltiin tottuneita.

Etätyöskentely on ollut Pakkasesta toimivaa, vaikka etänä tekeminen vaikuttikin projektin taustalla. Työskentely olisi varmasti ollut erilaista, nopeampaa työtahtia kenties, jos oltaisiin oltu samaan aikaan kaikki paikalla. Ryhmätyöskentely on toiminut paremmin kuin muilla kursseilla satunnaisesti muodostetuissa ryhmissä, joiden ongelmia ei ilmennyt niinkään paljon. Toteutettavia asioita oli paljon, mutta jokainen teki oman osuutensa. Palaveritkin olivat sopivan muodollisia, ettei niiden virallisuutta tarvinnut jännittää.

Varaprojektipäällikön tittelistä ei tullut ylimääräistä työtä, sillä projektipäällikkö ei pitänyt lomaa. Kerran tapahtui läheltä piti -tilanne. Palaverien puheenjohtajana Pakkanen onnistui mielestään paremmin projektin alkuvaiheissa. Hänestä pieni esiintymisjännitys edesauttaa kommunikaatiotaitojen kehittymisessä. Pakkanen aloitti vaatimusmäärittelyn laatimisen heti projektin alussa, joten kerralla tehtävä kirjoitusmäärä pidettiin kohtuullisena. Jos Pakkanen tekisi kuvankäsittelyn alusta, niin hän tekisi muutamia asioita eri tavalla. Kuvankäsittely saatiin kuitenkin pääosin toimivaksi.

\section{Vilavaaran kokemuksia ja oppimaa}
\label{ch:vilavaaran-kokemuksia-ja-oppimaa}

Projektin suuri työmäärä oli Vilavaaran tiedossa hyvissä ajoin ennen projektin alkamista, mutta häntä mietitytti tuleeko työmäärä lopulta vastaamaan ennakko-odotuksia. Rajoitusten takia kurssin suorittaminen ylipäänsä ei ollut itsestäänselvyys, esimerkiksi siinä miten viralliset palaverit tulisivat vaikuttamaan tilaajan ja ohjaajien kanssa toimimiseen. Poikkeusjärjestelyt vaatisivat varmasti muutakin kuin luentojen siirtäminen etäopetukseen. Vilavaara tiedosti, ettei projekti tulisi olemaan pelkkää koodausta, vaan siihen sisältyisi myös runsaasti kirjoittamista.

Vilavaara kertoi yliarvioineensa raportoinnin vaativuuden, sillä dokumenttien laatiminen ei vastannut muiden opiskelijoiden puheista saatua mielikuvaa. Palavereista ei ollut aiempaa kokemusta eivätkä ennakko-odotukset vastanneet siten juurikaan hänen projektikokemuksiaan. Vilavaara korostaa vuorovaikutuksen merkitystä tilaajan edustajien ja ohjaajien kanssa toimimisessa, missä on ensiarvoisen tärkeää pitää usein yhteyttä kuin jättää yhteydenpito vähemmälle. Sovelluksen osalta tekemisen määrä ei yllättänyt vaan ohjelmointia jopa odotettiin.

Dokumenttien kirjoittaminen on harjaannuttanut virallisen tekstin tuottamisessa. Palautteen perusteella on saanut huomioita siitä, missä on voinut vielä parannettavaa. Käyttöliittymän toteuttamisessa Vilavaara tunnistaa vielä parantamisen varaa. Ensimmäinen idea ei välttämättä ole se paras, sillä vasta kokeillessa saattaa huomata siitä heikkouksia. Projektissa opittiin paljon niissä tilanteissa, joissa aikaisemman osaamisen puolesta ei ollut apua. Vilavaara huomaa kirjoittavansa nykyään valmiimpaa koodia, joka tarvitsee jälkeenpäin vähemmän refaktorointia.

\chapter{Yhteenveto}
\label{ch:yhteenveto}

Groundhog-projekti kehitti kevään 2021 Sovellusprojekti-kurssilla Geologian tutkimuskeskukselle multimodaalisen tutkimusdatan hallintaohjelmiston tukemaan tomograﬁalaboratorion näytteiden analyysiä. Prototyyppi helpottaa erityyppisten tutkimusdatojen yhdistämistä, hallintaa ja visualisointia, mutta sovelluksessa riittää vielä runsaasti kehitettävää ennen sen käyttöönottoa.

Projektissa tärkeimmät sovellukselle asetetut tavoitteet toteutuivat suurelta osalta. Kaikkia vaatimusmäärittelyssä suunniteltuja toimintoja ei ehditty toteuttaa, mutta sovellukseen kehitettävistä toiminnoista sovittiin tilaajan kanssa. Sovelluksen kehittäminen jatkuu projektin jälkeen avoimen lähdekoodin ohjelmistona tilaajan toimesta.

Projektissa saavutettiin tavoitteen mukainen enimmäistyömäärä ja ryhmän jäsenet sitoutuivat projektiin aikataulun pidentämisestä huolimatta. Tulokset luovutettiin sopimuksen vastaisesti myöhässä. Projektin päättyessä projektiryhmän jäsenet tuntevat sovellusprojektin keskeiset projektinhallinnan menetelmät ja osaavat soveltaa niitä käytännön projektityössä.

Vastaavan ohjaajan mukaan toteutunutta työmäärää ei pystytty luotettavasti vertaamaan suunniteltuun projektisuunnitelman työmäärien arvioinnin puutteista ja työtuntien kirjausten virheistä johtuen. Projektisuunnitelma hyväksyttiin vasta kesäkuun puolessa välissä ja sen viivästyessä projektin jäsenillä ei todennäköisesti ollut tiedossa projektin läpiviennin käytänteet, mikä osin saattoi johtaa epäyhtenäiseen toimintaan -- ainakin kirjauskäytänteiden osalta.

%LÄHTEET
\begin{thebibliography}{1}
\makeatletter
\addtocounter{\@listctr}{0}
\makeatother

\bibitem{potku} Jarkko Aalto, Timo Konu, Samuli Kärkkäinen, Samuli Rahkonen ja Miika Raunio. 2013. ''Potku-sovellusprojekti, Projektiraportti''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{arkkitehtuuri} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Arkkitehtuurisuunnitelma''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{ajankaytonseuranta} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Ajankäytönseurantatyökaluja''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{kayttoliittyma} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Käyttöliittymäsuunnitelma''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{luokkarakenne} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Luokkasuunnitelma''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{projektisuunnitelma} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Projektisuunnitelma''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{sovellusraportti} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Sovellusraportti''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{testausraportti} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Testausraportti 1--2''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{testaussuunnitelma} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Testaussuunnitelma''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{vaatimukset} Iiro Iivanainen, Harri Linna, Jere Pakkanen ja Riikka Vilavaara. 2021. ''Groundhog-sovellusprojekti, Vaatimusmäärittely''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{peltihamsteri} Mari Kasanen, Leevi Liimatainen, Marina Mustonen, Juhani Sundell ja Arttu Ylä-Sahra. 2019. ''Peltihamsteri-sovellusprojekti, Projektiraportti''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{liikkuva} Joel Kivelä, Erkki Koskenkorva, Mika Lehtinen, Oskari Leppäaho ja Petri Partanen. 2014. ''Liikkuva-sovellusprojekti, Projektiraportti''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\bibitem{nimeamiskaytanteet} Microsoft Corporation. 2008. ''Capitalization Conventions''. Saatavilla WWW-muodossa, \url{http://msdn.microsoft.com/en-us/library/ms229043.aspx}, viitattu 21.7.2021.

\bibitem{projektiohje} Santanen, Jukka-Pekka. 2017. ''Tietotekniikan Sovellusprojektien ohje''. Jyväskylän yliopisto, informaatioteknologian tiedekunta.

\end{thebibliography}

%LIITTEET
%\begin{appendix}
%\chapter{Ensimmäinen liite}
%Tänne tarvittaessa liitteitä.
%\end{appendix}

% Dokumentin  lopetus
\end{document}
