Tik-76.115 Projektisuunnitelma

Tiivistelmä

Projektin organisaatio koostuu projektiryhmästä, asiakkaasta ja kurssista. Projektin toteuttava projektiryhmä koostuu seitsemästä TKK:n opiskelijasta. NetSeal Technologies toimii projektin asiakkaana ja kurssin henkilökunta toimii työprosessin valvojana ja arvostelijana.

Projektin tavoitteet voidaan jakaa erikseen projektiryhmän ja asiakkaan tavoitteisiin. Projektiryhmän tavoitteena on saada kurssi suoritettua kunnialla läpi välttäen ylimääräiset työtunnit ja hyötyen prosessista vielä taloudellisesti. Asiakkaan tavoitteena taas on saada mahdollisimman toimiva ohjelmistotuote ilman, että kustannukset nousevat omakustannehintaa korkeammiksi.

Toteutuksessa tullaan noudattamaan tiettyjä projektisuunnitelmassa kuvattuja menetelmiä. Näillä menetelmillä pyritään määrittelemään asianmukaiset muutoksen- ja versionhallintaproseduurit. Projektiryhmän sisäinen ja ulkoinen tiedonkulku sekä projektin aikana toimitettavat dokumentit tullaan myös määrittelemään tarkasti. Ohjelmakoodin kirjoittamisessa ja dokumentoinnissa noudatetaan tiettyjä ennalta sovittuja periaatteita, joiden avulla pyritään selkeyteen ja ymmärrettävyyteen. Projektin kulkua valvotaan tasaisin väliajoin pidetyin palaverein ja katselmuksin.

Projekti on jaettu 6 eri vaiheeseen. Nämä vaiheet ovat projektin suunnittelu, neljä toteutusvaihetta ja projektin luovuttaminen. Jokaisella vaiheella on kurssin puolelta määritelty deadline, jonka ylittäminen johtaa pistemenetyksiin kurssin arvostelussa. Projekti päättyy 24.4.2001 tai jos päättämiskriteerit täyttyvät jo ennen tätä.

Sisällysluettelo

1. Johdanto

1.1 Projektin tarkoitus ja kattavuus

1.2 Asiakas

1.3 Tuote ja ympäristö

1.4 Oikeudet työn tuloksiin

1.5 Yleiskatsaus dokumenttiin

Mikäli katsotaan tarpeelliseksi, voidaan myös laatia muita tämän ohjelmistoprosessin kannalta tarvittavia dokumentteja (esim. ohjeistus dokumenttien ulkoasun määrittelystä). Tällaisten dokumenttien mahdollisesta laatimisesta päätetään Synapsi-ryhmän palavereissa projektin aikana. Tätä projektisuunnitelmaa tullaan käyttämään projektin osallistuvien henkilöiden ohjeistuksena käytännön toimissa välittömästi sen jälkeen, kun suunnitelma on hyväksytty projektisuunnitelmakatselmoinnissa.

2. Termit ja määritelmät

3. Asiakkaan nykyinen ratkaisu

4. Projektin toteutusperusteet

Asiakasyritys kokee myös hyödylliseksi tuoda itsensä opiskelijoiden eli potentiaalisten työntekijöiden tietoisuuteen.

Ohjelmiston oikeudet myydään asiakkaalle. Oikeuksien hinta pyritään määrittämään siten, että omalla työvoimalla tuotettuna hinta olisi sama, jonka projekti nyt kaikkine kustannuksineen tulee maksamaan. Yrityksen ei tarvitse ostaa mitään ylimääräisiä laitteita eikä ohjelmia. Testauksen aikana testikoneita ei luonnollisesti voi käyttää muuhun, joten tämä voidaan ajatella jonkinlaiseksi haitaksi, vaikka välittömiä kuluja siitä ei olekaan.

Asiakkaan henkilöstö joutuu uhraamaan projektille jonkin verran omaa aikaansa, mutta näin tapahtuisi joka tapauksessa, joten se ei tuo mitään lisäkuluja. Koska projekti tehdään lisäominaisuutena jo olemassa olevaan tuotteeseen, siihen ei millään lailla siirrytä. Saavutetut taloudelliset edut ovat vaikeita mitata, mutta kuitenkin erittäin ilmeisiä johtuen manuaalisen työn vähenemisestä.

Projektin toteuttaminen esim. alihankintana tulisi maksamaan noin 120 000 mk. Seuraava laskema on saatu arvioimalla projektin toteuttamiseen kuluva aika joltain alihankinta yritykseltä. Aikaa alihankkijalta kuluisi luultavasti noin 450 tuntia eli noin kolme kuukautta. Alihankinnan tuntihintaa ei missään varsinaisesti mainostetta, mutta valistunut arvaus voisi olla esim. 266mk/h. Tämä perustuu löyhästi siihen, että täysipäiväisen ohjelmoijan palkka on n. 100mk/h, tähän päälle lasketaan kuitenkin vielä sosiaalikuluja 33mk/h niin saadaan pelkän työnhinnaksi 133mk/h. Lisäkuluja aiheuttavat kuitenkin seuraavat tilanteet: ohjelmoijan palkka projektin ulkopuolella, alihankkijan muut kulut (tilat, laitteet, ei-koodaava henkilöstö), alihankkijan tavoittelema voitto projektista n. 20%.

5. Projektin organisaatio

5.1 Projektiryhmä

Ryhmän kotisivu

http://www.hut.fi/~jmanttil/Synapsi/home/

Sähköposti

mika.mantyla@hut.fi, antti.vainio@hut.fi, mvarso@cc.hut.fi,cemo.timucin@hut.fi, Juho.Anttila@proha.fi, mrantee@cc.hut.fi, mac@cc.hut.fi

Jäsenten esittely ja yhteystiedot

Rooli(t):	Projektipäälikkö
Nimi:	Mika Mäntylä
Puhelin:	(050) 3529949
E-mail:	mika.mantyla@hut.fi
WWW-kotisivu:	http://www.hut.fi/~mmantyla/
Kiinnostus- ja osaamisalueet:	Ohjelmistotuotanto, Mobile IP, internet-tekniikat.
Opiskelu- ja työkokemus:	Syksy 1997 Teknillinen Korkeakoulu, Tietotekniikan koulutusohjelma.
	NetSeal Tech.:	Software Engineer    3.1.2000 -
	TietoEnator:	ATK-suunnittelija:    31.5.1999 - 31.12.1999
Rooli(t):	Käyttöliittymävastaava
Nimi:	Antti Vainio
Puhelin:	(040) 7685 127
E-mail:	Antti.Vainio@hut.fi
WWW-kotisivu:	http://www.hut.fi/~avainio
Kiinnostus- ja osaamisalueet:	Tietoturvallisuus, internet-tekniikat, olio-ohjelmointi, käyttöliittymät, tietokonegrafiikka.
Opiskelu- ja työkokemus:	Syksy 1997 Teknillinen Korkeakoulu, Tietotekniikan koulutusohjelma.
	Nokia Research Center:	Trainee 1.6.2000 -
	Nokia Networks:	Trainee 24.5.1999 - 31.5.2000
Rooli(t):	Koodipäällikkö
Nimi:	Mikko Varso
Puhelin:	(041) 517 4674
E-mail:	mvarso@cc.hut.fi
WWW-kotisivu:
Kiinnostus- ja osaamisalueet:	C/C++ -ohjelmointi, käyttöliittymät.
Opiskelu- ja työkokemus:	Syksy 1995 Teknillinen Korkeakoulu, Tuotantotalouden koulutusohjelma.
	NetSeal Tech.:	Software Engineer 6.3.2000 -
Rooli(t):	WWW- ja dokumentointivastaava
Nimi:	Juho Anttila
Puhelin:	(040) 7675 130
E-mail:	Juho.Anttila@Proha.fi
WWW-kotisivu:
Kiinnostus- ja osaamisalueet:	Tietokannat, C++ -ohjelmointi, JAVA -ohjelmointi, WWW-teknologiat.
Opiskelu- ja työkokemus:	Syksy 1996 Teknillinen Korkeakoulu, Tietotekniikan koulutusohjelma.
	Proha Oyj:	Ohjelmistokonsultti 15.3.1999 -
Rooli(t):	Systeemisuunnittelija
Nimi:	Ville Rannikko
Puhelin:	(050) 549 0317
E-mail:	mac@cc.hut.fi
WWW-kotisivu:	http://www.hut.fi/~mac
Kiinnostus- ja osaamisalueet:	Visual C++, Java, käyttöliittymät.
Opiskelu- ja työkokemus:	Syksy 1990 Teknillinen korkeakoulu, Tietotekniikan koulutusohjelma.
	ICL Invia Oyj:	Systeemisuunnittelija 3.3.1997-
Rooli(t):	Menetelmävastaava
Nimi:	Cemo Timucin
Puhelin:	(040) 7675 122
E-mail:	ctimucin@cc.hut.fi
WWW-kotisivu:	http://www.hut.fi/~ctimucin
Kiinnostus- ja osaamisalueet:	Projektitoiminta, olio-ohjelmointi, ohjelmistojen testaus.
Opiskelu- ja työkokemus:	Syksy 1996 Teknillinen korkeakoulu, Tietotekniikan koulutusohjelma.
	Proha Oyj:	Ohjelmistokonsultti 28.10.1998-
Rooli(t):	Asiakasvastaava
Nimi:	Marko Rantee
Puhelin:	(050) 569 4964
E-mail:	mrantee@cc.hut.fi
WWW-kotisivu:
Kiinnostus- ja osaamisalueet:	Windows-verkkorajapinta, Java, C.
Opiskelu- ja työkokemus:	Syksy 1996 Teknillinen korkeakoulu, Sähkö ja tietoliikennetekniikan koulutusohjelma.
	NetSeal Tech.:	Software engineer 1.3.1999-
	Espoon Evl. seurakuntayhtymä:	Kausityöntekijä kesä 1997 ja kesä 1998

5.2 Sidosryhmät

5.3 Projektin organisaatiokaavio

Kuva 1. Organisaatio

6. Projektin tavoitteet ja päättäminen

6.1 Projektiryhmän tavoitteet

1. Kurssin Tik-76.115 Software Project suoritusmerkinnän saaminen
2. Kurssiarvosana => 3
3. Tyytyväinen asiakas
4. Hyvän tuotteen tekeminen
5. Laaditun aikataulun noudattaminen
6. Työmäärän tasainen jakautuminen
7. Ylityötuntien välttäminen
8. Henkilökohtaisen taloudellisen tilanteen parantaminen

6.2 Asiakkaan tavoitteet

Välttämättömät ominaisuudet

• Asiakasryhmien muodostus: voidaan määrittää, mitkä asiakkaat saavat mitkäkin päivitykset.
• Päivityspaketit ovat ajettavia setup tiedostoja, jotka purkavat itsensä. Päivityksen tulee olla atominen 
• Asiakaskone pitää käynnistää uudelleen, kun päivitykset on tehty.
• Force-päivitys eli voidaan myös päivittää takaisin pienempään versioon.
• Kysytään haluaako käyttäjä päivittää ohjelmiston moduuleita.

Toivottavat ominaisuudet

• Non-force -päivitys: palvelin saa asiakkaalta tiedon moduuliversioista.
• Vipu jolla estetetään softapäivitykset.

Kiva olla

• Jonkin muun kuin ohjelmistomoduulin päivitys: esimerkiksi tekstimuotoisten dokumenttien yms automaattinen etäpäivitys.
• Rajapinta, jolla nähdään onko asiakas linjalla.
• Mahdollisuus päivittää palvelimessa olevia moduuleita, jotta se voisi päivittää ne muihin asiakkaisiin.

Asiakkaan Top 10

1. Yrityksen pitää saada lopulta kaikki oikeudet projektiin (itse projekti)
2. Asiakasta ei pidä alkaa päivittämään kysymättä. (softa)
3. Ainoastaan administrator-oikeuksilla voidaan päivittää moduuleita palvelimelle (softa)
4. Päivitettävien moduuliryhmien muodostus (softa)
5. Päivityksen tulee olla atominen (softa)
6. Päivitettävien asiakkaiden ryhmien muodostus (softa)
7. Dokumentointi pitää olla sitä tasoa, että siitä on seuraavan helppo jatkaa eteenpäin. (itse projekti)
8. Projektin pitää valmistua keväällä 2001 (itse projekti)
9. Käyttöliittymän tulee olla nopeasti omaksuttavissa. (softa)
10. Palvelinpää tehdään Javalla ja asiakaspää tehdään Microsoftin työkaluilla

6.3 Projektin tavoitteet

6.4 Projektin keskeyttämiskriteerit

• Projektiryhmän jäsenten terveydentila heikkenee vakavasti (Mahahaava, Vatsakatari)
• Työmäärä ylittyy 50 % arvioidusta.

6.5 Projektin päättämiskriteerit

Projekti päätetään loppupalaverilla, jossa läsnä ovat ainakin neljä projektiryhmän jäsentä sekä asiakas ja ohjaaja.

7. Projektin resurssit

Projekti lomailee ja lukee tentteihin

• 15.12.2000 - 11.1.2000
• 12.4.2000 - 18.4.2000

8. Projektissa käytettävät menetelmät ja työkalut

8.1 Muutosten hallinta (koodi/dokumentit)

Tarpeen vaatiessa muutospyyntöjen käsittely toimii seuraavasti.

1) Muutostarpeen havainnointi.
Muutospyynnön tekijä syöttää muutos pyynnön järjestelmään ja raportoi seuraavat asiat: 1. Kuka löytänyt, 2. Mistä modulista/versiosta (esim. Server-0.1), 3. Ongelman kuvaus.

2) Muutospyynnön käsittely (Projektipäällikkö käsittelee ja lähettää eteenpäin )
Käsittelijä päättää, mitä toimia pyyntö aiheuttaa. Jos pyynnön perusteella ryhdytään toimiin raportoi käsittelijä seuraavat asiat: 1. Kuka löytänyt, 2. Mistä modulista/versiosta (esim. Server-0.1), 3. Ongelman kuvaus, 4. Työmääräarvio, 5. Pyynnön toteuttaja.

3) Muutospyynnön toteutus.
Kun toteuttaja on tehnyt tarpeelliset muutokset, raportoi hän seuraavat asiat: 1. Minne muutoksia tehtiin, 2. Miten muutokset vaikuttavat ohjelmaan, 3. Paljonko kului aikaa.

4) Muutospyynnön testaus
Lopuksi testaaja testaa muutoksen. Raportoidaan asiat: 1. Testauspäivämäärä, 2. Millaisia testitapauksia käytettiin testaukseen. 3. Miten muutoksia havaittiin ohjelman toiminnassa muutoksen seurauksena.
 

8.2 Tuotteenhallinta

8.3 Versionhallinta

Koodin hallintaa tullaan käyttämään perinteistä checkout/chekin mallia. Muut mallit (composition malli, long trasaction malli, change set malli) jäävät käyttämättä, koska ryhmällä ei ole niiden käyttöön tarvittavaa välineistöä eikä osaamista.
 

8.4 Tiedonkulku (sisäinen/ulkoinen)

Sähköpostin avulla projektiryhmän jäsenet voivat tehokkaasti saavuttaa koko ryhmän. Todella pikaisissa asioissa voidaan turvautua myös puhelimen käyttöön. Mikäli joku ryhmän jäsenistä kokee puhelimenkäytön tiettyinä aikoina hankalaksi (esim. töissä olon vuoksi), voidaan tähän liittyvistä käytännöistä sopia erikseen. WWW:n kautta julkaistaan ryhmän kotisivuilla kaikki projektiin liittyvä dokumentaatio. Dokumentointivastaava vastaa viime kädessä siitä, että dokumentit tulevat ensi tilassa WWW:hen.

Ulkoinen tiedotus ja yhteydenpito tapahtuu asiakkaan suuntaan asiakasvastaavan kautta ja projektiin liittyvän kurssin suuntaan projektipäällikön kautta. Em. henkilöt ovat vastuullisia tiedottamaan muita ryhmän jäseniä mahdollisesti saamastaan uudesta tiedosta/muutoksista. Edellisestä poikkeavista käytännöistä voidaan tarvittaessa sopia projektipalavereissa ryhmän kesken.

8.5 Dokumentointi

Projektin aikana on tarkoituksena luoda ainakin seuraavat dokumentit (lista sisältää myös projektin vaiheen, jossa ko. dokumentti luodaan):

• Projektin suunnittelu:
• Projektisuunnitelma
• Vaatimusmäärittely
• Edistymisraportti
• Toteutusosa 1-4
• Toiminnallinen määrittely
• Tekninen määrittely
• Testaussuunnitelma
• Testausraportti
• Käyttöohje
• Edistymisraportti
• Luovutus
• Opponenttiryhmän testausraportti
• Loppuraportti

8.6 Ohjelmakoodista

Ohjelmoitikieli

Ohjelmakoodin kirjoitus

(defun tik-76.115-c-mode ()







  "C mode with adjusted defaults for use with Tik-76.115 project."







  (interactive)







  (c-mode)







  (c-set-style "K&R")







  (setq c-basic-offset 8))







(defun tik-76.115-c++-mode ()







  "C++ mode with adjusted defaults for use with Tik-76.115 project."







  (interactive)







  (c++-mode)







  (c-set-style "K&R")







  (setq c-basic-offset 8))

Koodin ulkomuoto ja rakenne

Ympäristö ja kääntäjät

• Java-koodi
• Windows NT 4.0, Visual Cafe/JDK 1.2.2
• C++-koodi (asiakasohjelmiston Windows NT käyttöliittymä)
• Microsoft Visual Studio 6.0
• lisättynä mahdollisesti: CygWin b15-b20, GNU Make 3.75
• ANSI-C-koodi
• CygWin b15-b20, GNU Make 3.75, Microsoft Visual Studio 6.0
• RedHat Linux 6.2, GNU Make, gcc

Koodin kommentointi

C/C++ tarjoaa vastaavan työkalun, Doc++, dokumentoinnin generointiin, joten C++ -koodissa tullaan käyttämään Doc++:n mukaista /** ... */ -merkkien sisään laitettua kommentointia kaikissa kommenteissa, joista on tarkoitus generoida dokumentit. //-merkinnän avulla toteutettua kommentointia ei tulla projektissa käyttämään.

Koodissa tulee kommentoida

• globaalit muuttujat
• luokkien attribuutit
• funktiot/metodit (sis. funktion kuvauksen ja parametrien kuvauksen)

Pohja lähdekooditiedoston alkuun sisällytettävästä kommenttiosiosta:

C++ -tiedostot:

/*







 * tiedoston nimi







 *







 * Author: tiedoston vastuuhenkilön nimi







 * Date  : tiedoston muutospäivä formaatissa dd.mm.yy







 *







 * 







 *







 *







 * Copyright Netseal Technologies 







 */

Java-tiedostot

8.7 Laadunvarmistus

Koska ryhmä on ymmärtänyt, että vaatimukset ovat projektin tärkein yksittäinen komponentti, käyttää ryhmä suuren panoksen niiden yksityiskohtaiseen määrittelyyn sekä eritoten niiden hallitsemiseen koko projektin elinkaaren ajan. Mikäli vaatimuksiin tulee muutoksia projektin edetessä on ryhmällä käytössä hyväksyntäprosessi, jossa täytyy hankkia ensin hyväksyntä muutokselle sekä projektipäälliköltä, koodipäälliköltä/kälipäälliköltä (riippuen kumman vastuualueeseen muutos liittyy) että myös asiakkaalta. Vasta hyväksyntäprosessin läpikäytyään ryhmä realisoi muutoksen ja korjaa vaatimukset oleellisilta osiltaan.

Laadunvarmistuksen kannalta oleellinen asia on myöskin ohjelmiston testaus. Ryhmä on tiedostanutt myös tämän seikan ja käyttääkin toteutuksen ja testauksen välisen suhteen kuvaavaa V-mallia. Tämä tarkoittaa sitä, että ei edetä "perinteisellä" tavalla, eli ensin kerätään vaatimukset, suunnitellaan ja lähdetään toteuttamaan järjestelmää, jonka jälkeen tehdään testisuunnitelmat moduuli-, yksikkö- sekä järjestelmätestausta varten. Uusi lähestymistapa on tehdä asioita rinnakkain. Samalla hetkellä kun ryhmä saa asiakkaalta korkean tason businessvaatimukset pystyy tekemään myös hyväksyntätestaussuunnitelman. Toiminnallista määrittelyä tehdessä ryhmä pystyy generoimaan myös järjestelmätestaussuunnitelman. Ketju jatkuu, kunnes ryhmä pääsee matalalle tasolle, jossa se suunnittelee hyvin teknisiä yksityiskohtia, jolloin ryhmä pystyy samalla suunnittelemaan myös moduulitestauksen. Suunnitelmien jälkeenhän vuorossa on toteutus, jonka jälkeen ryhmä toteaakin että kaikki testisuunnitelmat ovatkin jo valmiina eikä aikaa tarvitse kuluttaa enää suunnitteluun, vaan testaustoiminta voidaan käynnistää onnistuneen projektin lopputuloksen takaamiseksi.

8.8 Tarkastukset ja katselmointi

Kurssi on asettanut tiettyjä ajankohtia, joihin mennessä vaiheen katselmoitavat (väli)tuotteet on oltava valmiina. Ajankohdat ovat seuraavat:

• 16.10.2000 Projektisuunnitelmavaihe
• 7.11.2000 Toteutuksen 1. vaihe
• 12.12.2000 Toteutuksen 2. vaihe
• 13.02.2001 Toteutuksen 3. vaihe
• 20.03.2001 Toteutuksen 4. vaihe
• 24.04.2001 Luovutus

8.9 Palaverikäytännöt

Katselmoinneissa noudatetaan kurssin käytäntöä eikä asiaa oteta tässä erikseen esille.

8.10 Ryhmätyökäytännöt

8.11 Vaatimusten hallinta

Työkalussa pystytään helposti mm. määrittelemään vaatimusten (ja myös testauksen) väliset riippuvuussuhteet, jolloin muutosten analysointi on vaivatonta. Näemme yhdellä silmäyksellä mihin kaikkiin asioihin meidän pitää kiinnittää huomiota, jos eteemme tulee tilanne, jossa meidän täytyy muuttaa olemassaolevia vaatimuksia. Työkalu on käytössämme kurssilaisen työnantajan puolesta, joten lisenssiasiatkin on kunnossa.

9. Projektin ositus, vaiheistus ja resurssointi

Projekti jakaantuu kuuten vaiheeseen joiden aikana se on tarkoitus viedä läpi. Ensimmäinen vaihe on Projektin suunnittelu, jonka aikana on tarkoitus saada käsitys projektissa toteutettavasta työstä ja pohtia menetelmiä projektin menestyksekkääseen läpivientiin. Suunnittelua seuraa neljä toteutusvaihetta  nimeltään Toteutus 1-4. Näiden vaiheiden aikana on USDP:n hengessä tarkoitus, joka kerta suunnitella toteuttaa ja testata ohjelmisto. Jokaisen vaiheen siis pitäisi päättyä toimivaan ohjelmistoon.

Vaihe toteutus 1 on kuitenkin sen verran lyhyt, että kyseisessä vaiheessa tulemme ainoastaan keskittymään suunnitteluun. Vasta vaiheiden toteutus 2-4 aikana tulemme noudattamaan tarkemmin USDP:tä eli siis pyrimme päättämään jokaisen vaiheen hyvin suunniteltuun, toimivaan ja testattuun ohjelmistoon.

Projekti päättyy luovutus vaiheeseen, jossa asiakkaalle luovutetaan toimiva ja hyvin dokumentoitu ohjelmisto.

9.1 Projektin suunnittelu (DL 16.10.2000)

Tuotokset:

1. Projektisuunnitelma, jossa mukana seuraavan vaiheen tarkempi suunnitelma ja MS Project -tiedosto. (Resursit kaikki)
2. Vaatimusmäärittely (Resursit: Marko, Mika, Cemo, Mikko)
3. Edistymisraportti (Resursit: Antti)

Muut tehtävät

1. Työtilan ja www-sivun järjestäminen (Resursit: Juho)

9.2 Toteutus 1 (DL 7.11)

Tehtävät ja resursit

1. Projektisuunnitelman päivittäminen. (Resurssit: Mika, Antti.)
2. Vaatimusmäärittelyn päivittäminen.(Resurssit:  Marko, Cemo)
3. Toiminnallinen määrittely. (Resurssit: Mikko, Marko, Ville)
4. Tekninen määrittly. (Resurssit. Mikko, Antti, Ville)
5. Testaussuunnitelma. (Resurssit. Mika, Antti, Cemo)
6. Työkalujen käyttöönotto ja asennus. (Resurssit Juho, Mikko)
7. Edistyraportin kirjoittaminen. (Resurssit: Antti)

Tuotokset

1. Päivitetty projektisuunnitelma
2. Päivitetty vaatimusmäärittely
3. Toiminnallinen määrittely (karkealla tasolla mahdollisimman suuri osa järjestelmästä)
4. Tekninen määrittely (jos ehditään niin pitkälle)
5. Testaussuunnitelma (ei-toiminnallisten ominaisuuksien osalta ja jos tekninen määrittely on tehty myös siltä osin)
6. Testausraportti (jos testausta on tehty)
7. Edistymisraportti

9.3 Toteutus 2 (DL 12.12)

Tämän vaiheen kannalta on kriittistä, että tekninen määrittely saadaan tehtyä vaiheen alussa. Teknisenmäärittelyn aikainen valmistuminen varmistaa sen, että ohjelmointi ja testaussuunnittelu pääsevät alkamaan hyvissä ajoin ennen DL:ää.  Vaiheen lopussa pitäisi siis olla valmiina määrittelyjen ja  testaussuunnitelman lisäksi demon verran toimivaa koodia ja muutama onnistuneesti läpiviety testitapaus.

Tehtävät ja resursit

1. Opiskellaan Javan GUI komponentien käyttöä (Antti) ja serveri-client ohjemointia (Mikko, Ville)
2. Päivitetään ja täydennetään toiminnallista määrittelyä asiakkaan palautteen perusteella (Mika, Mikko, Marko, Antti)
3. Tehdään tekninenmäärittely (Mikko, Antti, Ville, Mika) ( DL 23.11)
4. Päivitetään ja täydennetään testaussuunnitelmaa teknisen määrittely pohjalta (Cemo + joku teknisempi guru)
5. Ohjelmoidaan: GUI:ta, clientin ja serverin välistä kommunikointia(Antti, Mikko, Ville)
6. Tehdään Burana-raportit (Juho, Marko).

1. Päivitetty projektisuunnitelma
2. Päivitetty vaatimusmäärittely
3. Päivitetty toiminnallinen määrittely
4. Päivitetty tekninen määrittely
5. Päivitetty testaussuunnitelma
6. Päivitetty testausraportti
7. Käyttöohje
8. Edistymisraportti

 

9.4 Toteutus 3 (DL 13.2)

9.4.1 Yleiskuvaus

9.4.2 Eteneminen

Vaihe alkaa ryhmällä joululoman jälkeen 11.1. Tästä eteenpäin käytettään kolme viikkoa ohjelmointiin ja testaussuunnitelman viimeistelyyn. Kolme ohjelmointi viikkoa jakaantuvat seuraavasti. Ohjelmointiviikolla 1 tekee jokaisen moduulin vastuuhenkilö omaan moduuliinsa sieltä vielä puuttuvan toiminnallisuuden ja viimeistelee ohjelmansa käyttämät rajapinnat. Ohjelmointiviikolla 1. pyritään myös käyttöliittymästä hankimaan palautetta esim. Netsealin kautta tulevilla testihenkilöillä. Ohjelmointiviikolla 2 pyritään integroimaan moduulit yhtenäisesti toimivaksi yksiköksi. Ohjelmointiviikolla 3 haetaan moduulien välisestä kommunikaatiosta "helppoja" bugeja ja testataan alustavasti järjestelmää. Viimeisellä viikolla toteutetun alpha testauksen ansiosta pystymme paremmin viemään läpi ominaisuuksien testausta.

Kolmen viikon ohjelmoinnin jälkeen testataan ohjelmaa testaussuunnitelman mukaisesti ja raportoidaan bugeja ja epätoivottuja ominaisuuksia. Tässä vaiheessa myös kirjoitetaan järjestelmälle käyttöohje.

Vaiheen lopussa katselmoidaan palautettavat dokumentit ja valmistellaan järjestelmä Demo kuntoon.

9.4.3 Lopuksi

9.4.4 Riskit

Vaiheen toinen riski liittyy selkeästi testaamisen suorittamiseen. Ryhmällä ei ole paljoakaan kokemusta näin tarkasti määritellyn testauksen suorittamisesta ja halukkuus testauksen läpivientiin saattaakin olla varsin matala. Varmimmat keino riskin välttämiseksi on selkeästi nimetä vastuuhenkilöt ja varmistaa, että testisuunnitelma on siten toteutettu, että sen läpivienti ei aiheuta ylimääräistä päänvaivaa. Joskaan tässäkään vaiheessa ei kannata aliarvioida kaljasakkojärjestelmän vaikutusta motivoijana.

9.4.5 Tuotokset

1. Päivitetty projektisuunnitelma
2. Päivitetty vaatimusmäärittely
3. Päivitetty toiminnallinen määrittely
4. Päivitetty tekninen määrittely
5. Päivitetty testaussuunnitelma
6. Päivitetty testausraportti
7. Käyttöohje
8. Edistymisraportti

9.4.6 Tuntiarvio

Kuva 2. Vaihe T3 arvio työmääristä ja aikataulusta.

9.5 Toteutus 4 (DL 20.3)

9.5.1 Vaiheen yleiskuvaus

Vaiheen aikana ohjelmistoon tullaan lisäämään/korjaamaan vielä seuraavia ominaisuuksia:

9.5.2 Aikataulu

Vaihe alkaa T3-vaiheen viikolla 7 palaverin merkeissä (15.2.). Vaihe käynnistetään 15.2. korjaamalla edellisen vaiheessa auki jääneitä bugeja. Tämän jälkeen siirrytään toteuttamaan puuttuvia ominaisuuksia (kts. edellinen kappale) 22.2. alkaen ja varmistetaan testaamalla, että vanhat bugit saatiin korjattua. Tämän jälkeen (1.3.) on vuorossa n. viikon kestoinen ohjelmiston integroiminen RoamMate:iin. Loppu aika (9.2. alkaen) vaiheesta jää järjestelmän testaamiseen, dokumenttien päivittämiseen (mm. luodaan käyttöohjeesta lopullinen versio) ja seuraavan vaiheen suunnitteluun. Rinnakkain muiden aktiviteettien kanssa suoritetaan jatkuvaa bugikorjausta aina virheiden ilmetessä.

Viimeisenä toimintana vaiheessa katselmoidaan aikaansaadut dokumentit ja valmistaudutaan katselmointiin suunnitellen samalla demo.

9.5.3  Riskit

Pienempänä riskinä voidaan nimetä ohjelmiston integroimisessa RoamMate:iin  mahdollisesti esiintyvät ongelmat. Riskiä ei koeta kovin suureksi, koska ryhmän sisällä on jonkin verran osaamista integroinnissa tarvittavasta tieto-taidosta. On kuitenkin mahdollista, että vaiheen aikana tulee ilmi jokin seikka jota ei ole aiemmin osattu ottaa huomioon. Riski pyritään välttämään perusteellisella paneutumisella ja huolellisella työskentelyllä. Myös asiakkaalta saatava opastus on olennaisessa asemassa - asiakasvastaava huolehtii, että riittävää opastusta saadaan.

9.5.4 Tuotokset

1. Päivitetty projektisuunnitelma
2. Päivitetty vaatimusmäärittely
3. Päivitetty toiminnallinen määrittely
4. Päivitetty tekninen määrittely
5. Päivitetty testaussuunnitelma
6. Päivitetty testausraportti
7. Käyttöohje
8. Edistymisraportti

9.5.5. Tuntiarvio

Kuva 3. Vaiheen T4 arvio työmääristä ja aikataulusta.

9.6 Luovutus (DL 24.4)

9.5.1 Vaiheen yleiskuvaus

9.5.2 Aikataulu

Vaihe aloitetaan viikolla 12 (22.3.) palaverilla. Ensimmäinen jakso (22.3. - 28.3.) on varattu vaiheessa T4 havaittujen bugien (mikäli sellaisia vielä on) korjaamiseen sekä kommunikointiin opponenttiryhmän kanssa. Pyrkimyksenä on saada sovittua opponenttiryhmän kanssa sellainen aikataulu, että molemminpuolinen opponenttiryhmien järjestelmätestaus voidaan suorittaa seuraavan jakson aikana. Toinen jakso (29.3. - 4.4.) suoritetaan oman järjestelmän testaus ja testin tulosten tultua jatketaan havaittujen bugien korjaamista (jos sellaisia tulee ilmi). Tällä jaksolla aletaan suorittaa myös koodin ja dokumenttien siistimistä siihen muotoon, että ne ovat luovutuskunnossa. Tällä viikolla suoritetaan myös opponenttiryhmän järjestelmätestaus sekä vastavuoroisesti tarjotaan opponenttiryhmälle tarvittavat välineet (ohjelmisto, dokumentaatio, opastus) oman järjestelmämme testaukseen. Kolmannella jaksolla (5.4. - 11.4.) aloitetaan loppuraportin kirjoittaminen sekä suoritetaan lopullista järjestelmätestausta ohjelmistollemme. Mikäli edellisellä viikolla suoritetusta opponentin suorittamasta testauksesta saadaan jotakin olennaista palautetta (esim. havaittu selkeä virhe järjestelmässä), tähän pyritään reagoimaan mahdollisuuksien mukaan. Tosin tässä vaiheessa ei enää ryhdytä tekemään suuria muutoksia ohjelmistoon. Kuten aiemmin mainittiin, 12.4. - 18.4. välinen aika on varattu pääsiäislomalle. 19.4. - 24.4. välinen aika varataan lopulliseen katselmointiin (19.4.), jossa tarkistetaan/verifioidaan kunkin dokumentin tila, ohjelmiston tila sekä täydennetään ja hyväksytään projektin loppuraportti. 24.4. - 27.4. välisenä aikaa valmistellaan loppudemonstraatio ja 27.4. suoritetaan itse demonstraatio loppukatselmoinnin yhteydessä.

9.5.3  Riskit

Toinen vaiheeseen liittyvä riski on opponenttiryhmän kanssa suoritettavassa yhteistyössä mahdollisesti ilmi tulevat ongelmat. Opponenttiryhmä on saattanut aikatauluttaa LU-vaiheen täysin eri tavalla, jolloin suunnittelemaamme testausaikataulua voidaan joutua muuttamaan. Tämän riskin välttämiseksi päätimmekin sijoittaa opponenttiryhmän kanssa kommunikoinnin ja testauksesta sopimisen heti vaiheen alkuun, joten mahdolliset ongelmat tulevat heti ilmi ja niihin voidaan tehokkaasti reagoida.

9.5.4 Tuotokset

9.5.5. Tuntiarvio

10. Seuranta ja ohjaus

Asiakaskasvastaava huolehtii tiedottamisesta asiakasrajapinnalle viikottaisessa palaverissä. Samassa palaverissä asiakasvastaava saa projektin ohjaajalta tarvittavaa ohjausta.

Varsinaisen projektin seuraamisen mittareina käytämme tehtyjä työtunteja, ohjelmiston kokoa sekä ohjelmistosta löytyneitä virheitä. Tuntiraportoinnin hoidamme kurssin tarjoaman Tirana-palvelun kautta. Ohjelmiston koon määrittelemiseen ja raportointiin käytämme kurssin tarjoamaa Burana-raportointijärjestelmää. Ohjelmistosta löytyneet virheet raportoimme myös Burana-järjestelmän kautta.

Kerätyn tiedon analysoinnin voimme hoitaa mm. ViCA-visualisointiohjelmistolla. Kurssi tarjoaa muutamia vakiokuvaajia, mutta suunnitelmissamme on luoda myös muutamia omia.
 

11. Standardit, direktiivit ja määräykset

12. Riskien hallinta

13. Koulutussuunnitelma

13.1 Projektiryhmän sisäinen koulutussuunnitelma

13.2 Asiakkaalle tarjottava koulutussuunnitelma

14. Asennussuunnitelma

15. Käyttöönottosuunnitelma

Lähdeluettelo

Liiteluettelo