Projektisuunnitelma

Metaxa

Helsinki 12.12.2005

Ohjelmistotuotantoprojekti

HELSINGIN YLIOPISTO

Tietojenkäsittelytieteen laitos

Kurssi

581260 Ohjelmistotuotantoprojekti (6 ov)

Projektiryhmä

Väinö Ala-Härkönen

Reima Halmetoja

Antti Laitinen

Kalle Pyykkönen

Oskari Saarekas

Tuomas Tanner

Juuso Vanonen

Asiakas

Olli Niinivaara

Johtoryhmä

Juha Taina

Joni Salmi

Kotisivu

http://www.cs.helsinki.fi/group/metadata/

Versiohistoria

12.09.2005 Versio 1

14.09.2005 Versio 2 (aikataulu lisätty)

20.09.2005 Versio 3 (riskianalyysi)

23.09.2005 Versio 4 (laadunvalvonta ja päivitetty aikataulu)

01.10.2005 Versio 5 (ohjaajan esittämät puutteet korjattu)

12.12.2005 Versio 6 (päivitetty vastaamaan toteutunutta)

12.12.2005 Versio 7 (kirjoitettu puhtaaksi ja jäädytetty)

Sisältö

1. Johdanto	1

2. Organisaatio	1

3. Kokoarvio	3

4. Työn ositus ja aikataulu	3

5. Työskentelytavat	5

6. Riskianalyysi	6

6.1. Organisaatio- ja projektityöriskit	7

6.2. Aikatauluriskit	9

6.3. Tekniikka ja teknologiariskit	10

6.4. Tuotettavaan ohjelmistoon liittyvät riskit	12

6.5. Riskien toteutuminen	12

7. Laadunvalvonta	13

1. Johdanto

Tämä projektisuunnitelma sisältää syksyn 2005 Metadata-projektin projektin yleiskuvauksen, osallistujien vastuualueet, projektiaikataulun, sekä riskit. Projekti kuuluu Helsingin Yliopiston tietojenkäsittelytieteen laitoksen 10 opintopisteen (6ov) laajuiseen Ohjelmistotuotantoprojekti -kurssiin.

Projektin tarkoitus on toteuttaa metadatan hallintatyökalu, jonka avulla metadataa voidaan luoda ja koota ominaisuuksien tarkastelua varten. Työkalu mahdollistaa metadatan harvestoinnin (noutamisen) tällaista palvelua tarjoavalta palvelimelta tai paikallisesta tietovarastosta (cd-rom, kiintolevy), metadatan tallentamisen paikallisesti jatkokäsittelyä varten, sekä paikallisesti tallennetun metadatan poimimisen ja poimintatulosten edelleen tallentamisen tiedostoiksi jatkoanalyysia varten.

2. Organisaatio

Projektiryhmä (sulkeissa varavastuualue)

Kalle Pyykkönen, Projektipäällikkö

Väinö Ala-Härkönen, Dokumenttivastaava

Juuso Vanonen, Vaatimusmäärittelyvastaava

Tuomas Tanner, Suunnitteluvastaava (koodivastaava)

Antti Laitinen, Koodivastaava (suunnitteluvastaava)

Reima Halmetoja, Testausvastaava (projektipäällikkö, määrittelyvastaava)

Oskari Saarekas, Yleismies

Sidosryhmät

Olli Niinivaara, asiakas

Joni Salmi, ohjaaja

Juha Taina, Ohjelmistotuotantoprojekti-kurssin vastuuhenkilö

Vastuualueet

Projektipäällikkö vastaa projektisuunnitelman laatimisesta ja ylläpidosta. Hän vastaa projektin seurannasta ja raportoinnista reagoiden ongelmatilanteisiin. Projektipäällikkö jakaa työtehtäviä ryhmän jäsenille hyödyntäen näiden vahvuuksia ja osaamisalueita.

Määrittelyvastaava vastaa vaatimusanalyysin työn johtamisesta sekä vaatimusdokumentin tuottamisesta ja ylläpidosta. Määrittelyvastaava osallistuu tehtävien jakamiseen vaatimusanalyysin osalta.

Suunnitteluvastaava vastaa suunnitteluvaiheen aikaisesta työn johtamisesta sekä suunnitteludokumentin tuottamisesta ja ylläpidosta. Suunnitteluvastaava osallistuu tehtävien jakamiseen suunnitteluvaiheen osalta.

Koodivastaava vastaa koodin yhtenäisestä ulkoasusta ja rajapintojen yhtenäisyydestä. Koodausvastaava osallistuu tehtävien jakamiseen toteutusvaiheen osalta ja toimii puheenjohtajana koodiin liittyvissä kokouksissa ja katselmuksissa.

Testausvastaava on vastuussa testauksen kattavuudesta. Hän vastaa testauksen suunnittelusta ja johtamisesta toteutuksen ja varsinaisen testausvaiheen aikana. Testausvastaava vastaa testaussuunnitelman ja testausraporttien tuottamisesta ja ylläpidosta.

Dokumenttivastaava kokoaa ja muotoilee dokumenttien lopulliset versiot. Dokumenttivastaava vastaa projektin www-sivuista ja toimii Wikin tukihenkilönä. Dokumenttivastaava hoitaa kokouksissa sihteerin tehtäviä.

Projektiryhmä vastaa omalta osaltaan kollektiivisesti laadunvalvonnasta projektin aikana.

Ryhmän ohjaajan rooli on toimia ulkopuolisena laaduntarkkailijana. Ryhmän ohjaaja puuttuu ryhmän toimiin havaitessaan projektin olevan menossa väärään suuntaan. Tarvittaessa ohjaaja osallistuu konfliktin ratkaisuun.

Projektin vastuuhenkilö on vastuussa kaikista kurssin projekteista. Tarvittaessa hän on käytettävissä ylimpänä asiantuntijana ja auktoriteettina prosessiin liittyvissä asioissa.

Varamiesjärjestelyt

Keskeisille vastuuhenkilöille on nimetty varahenkilöt, jotka ottavat vastuun varsinaisen vastuuhenkilön ollessa estynyt hoitamaan tehtäviään.

3. Kokoarvio

SLOCCOUNT ohjelman tuottama kokoarvio lopullisesta ohjelmasta:

Total Physical Source Lines of Code (SLOC) = 13,806

Development Effort Estimate, Person-Years (Person-Months) = 3.15 (37.78)

(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))

Schedule Estimate, Years (Months) = 0.83 (9.94)

(Basic COCOMO model, Months = 2.5 * (person-months**0.38))

Estimated Average Number of Developers (Effort/Schedule) = 3.80

Total Estimated Cost to Develop = $ 425,317

(average salary = $56,286/year, overhead = 2.40).

Alkuperäinen LOC -arvio oli 14700, joten lopputulos oli yllättävän lähellä alkuperäistä arviota.

4. Työn ositus ja aikataulu

Projektin työtehtävät jakautuvat seuraaviin kategorioihin:

Aiheeseen tutustuminen. Tehtävänannon yhteydessä saatuun työn aiheeseen liittyvään materiaaliin tutustumista.

Projektisuunnitelma. Projektisuunnitelma kuvaa ryhmän työskentelytavat, aikataulun, työnjaon ja riskit. Projektipäällikkö kirjoittaa projektisuunnitelman alustavan version, jonka pohjalta ryhmä osallistuu suunnitelman työstämiseen. Projektisuunnitelmaa päivitetään projektin edetessä.

Vaatimusmäärittely. Vaatimusmäärittelyssä selvitetään asiakkaan järjestelmälle asettamat vaatimukset, joiden pohjalta kirjoitetaan vaatimusdokumentti. Vaatimusmäärittelyn yhteydessä tutkitaan mahdollisuutta käyttää valmiita komponentteja vaatimusten toteuttamiseen.

Suunnittelu. Toteutuksen suunnittelu alkaa vaatimusmäärittelyn loppuvaiheessa, kun määrittely on oleellisilta osiltaan valmiina. Suunnittelun tuloksena syntyy suunnitteludokumentti. Alustava testaussuunnitelma laaditaan suunnitteluvaiheessa.

Toteutus. Toteutusvaiheen tuotos on asiakkaan tilaama ohjelmisto. Toteutus Integraatio-osajärjestelmän osalta toteutetaan kahdessa kierroksessa niin, että ensimmäisen vaiheen tuotos käy asiakkaalla kommentoitavana ja toisessa vaiheessa toteutetaan asiakkaan toivomat muutokset. Yksikkötestausta suoritetaan toteutuksen edetessä.

Testaus. Testaus suoritetaan testaussuunnitelman mukaan. Yksikkötestaus tapahtuu toteutuksen yhteydessä. Integrointitestausta suoritetaan osajärjestelmien valmistuessa ja järjestelmätestaus koko toteutuksen päätteksi. Testausvaiheesta laaditaan testausdokumentti, joka kuvaa suoritetut testit ja testitulokset.

Muut tuotokset. Valmiille ohjelmalle laaditaan käyttöohje, ylläpitodokumentti ja projektista laaditaan loppuraportti.

Projektin tarkistuspisteet:

Vaatimusmäärittelyn hyväksyminen (TR1)	12.10.2005

Vaatimusmäärittelyn hyväksyminen (TR2)	17.10.2005

Vaatimusmäärittelyn hyväksyminen (TR3 - hyväksyttiin)	20.10.2005

Suunnitteludokumentin hyväksyminen I (TR)	4.11.2005

Vaatimusmäärittelyn muutokset (TR4)	21.11.2005

Vaatimusmäärittelyn muutokset	29.11.2005

Demotilaisuus	8.12.2005

Työn luovutus	16.12.2005

Muita päivämääriä

Loma	23.10.2005 - 29.10.2005

Määrittelyvastaava lomalla	14.10.2005 – 29.10.2005

Projektin aikataulu kaaviona löytyy liitteestä 1.

5. Työskentelytavat

Työvälineet

Projektin jäsenet kommunikoivat projektitapaamisten lisäksi pääasiassa sähköpostia käyttäen. Ryhmällä on keskinäistä yhteydenpitoa varten käytössä sähköpostilista. Tarpeen vaatiessa voidaan käyttää myös puhelinta ja pikaviestintäohjelmistoja.

Dokumentteja valmistellaan Wiki -järjestelmässä (http://db.cs.helsinki.fi/~tkt_meta/wiki/). Wikiin kirjataan myös kunkin jäsenen vapaat ajat, sekä muuta mahdollista projektiin liittyvää ohjeistusta. Valmiit dokumentit julkaistaan OpenOffice- ja PDF-muodoissa projektin www-sivuilla (http://www.cs.helsinki.fi/group/metadata/).

Koodin hallintaan ja varmuuskopiointiin käytetään CVS-versionhallintajärjestelmää ja kehitysympäristöksi suositellaan Eclipseä.

Projektin aikataulut tehdään MS Excelillä. Kaavioiden työtiedostot löytyvät projektin kotihakemistosta.

Seuranta- ja raportointikäytännöt

Ryhmä kokoontuu projektin aikana 1-2 kertaa viikossa:

I-periodissa: ma klo 8.00 ja to klo 16.00

II-periodissa: ti klo 10.00 ja pe klo 14.00

Viikon ensimmäinen tapaaminen on seurantakokous, jossa tarkastellaan projektin tilaa. Kokouksissa puheenjohtajana toimii projektipäällikkö ja sihteerinä dokumenttivastaava. Kokouksen asialista toimitetaan osallistujille mahdollisuuksien mukaan edellisenä päivänä, kuitenkin viimeistään samana päivänä tuntia ennen kokousta. Lisäksi ryhmä voi tarpeen mukaan kokoontua myös muina aikoina. Pääasiallisesti näitä viikonpäiviä käytetään minietappeina tehtävien aikataulutuksessa ja jaossa.

Projektiryhmän jäsenet kirjaavat omat työtuntinsa OhTu projektin seurantajärjestelmään (http://db.cs.helsinki.fi/~tkt_ohtu/metrics/v0/index.php) vähintään kahdesti viikossa ennen ryhmätapaamisia. Lisäksi jäsenet pitävät ajantasaista kopiota tuntikirjanpidostaan ryhmähakemistossa.

6. Riskianalyysi

Riskianalyysissa kuvataan projektiin liittyvät tunnistetut riskit, eli tapahtumat jotka toteutuessaan vahingoittavat projektia. Kustakin riskistä on kirjattu kuvaus, josta riskin mahdollinen toteutuminen voidaan tunnistaa, toiminta riskin toteutuessa, arvio riskin todennäköisyydestä, sekä seurausten vakavuudesta. Riskitilanteita seurataan aktiivisesti erityisesti seurantakokouksissa, sekä muutenkin erityisesti projektipäällikön ja projektin menossa olevan vaiheen vastuuhenkilön toimesta.

Riskitilanteet luokitellaan seuraavasti:

Todennäköisyys:

Suuri: on erittäin todennäköistä, että riski toteutuu projektin aikana

Mahdollinen: jotain ääripäiden väliltä

Pieni: on epätodennäköistä muttei mitenkään mahdotonta että riski toteutuu

Vakavuus:

Vähäpätöinen: ei vaikuta vakavasti projektin onnistumiseen mutta voi sekoittaa aikataulua

Siedettävä: aiheuttaa näkyviä ongelmia projektin onnistumiselle ja aikataululle

Vakava: uhkaa vakavasti projektin onnistumista

Tuhoisa: projektin jatkaminen on vaikeaa tai lähes mahdotonta

6.1. Organisaatio- ja projektityöriskit

Ryhmän jäsen keskeyttää kurssin.

Todennäköisyys: Pieni

Vakavuus: Siedettävä, mikäli yksi keskeyttää, vakava tai tuhoisa mikäli keskeyttäjiä on useita

Minimointi: Oikeudenmukainen ja järkevä työnjako, hyvä ryhmähenki.

Tunnistaminen: Keskeyttäjän ilmoitus tai saapumatta jättäminen tapaamisiin.

Toteutuessa: Muunnetaan työjakoa siten, että muut hoitavat myös keskeyttäneen henkilön tehtävät.

Projektiryhmäläisen pitempiaikainen sairastuminen

Todennäköisyys: Pieni

Vakavuus: Vakava. Lyhytaikaiseen sairastumiseen on varauduttu varamiesjärjestelyllä. Pitkäaikainen sairastelu kriittisessä vaiheessa johtaa suuriin aikataulujen ja vastuiden uudelleenjärjestelyihin.

Minimointi: Varamiesjärjestelyt. Lisäksi pyritään siihen, että kaikilla jäsenillä on tieto "missä mennään"

Tunnistaminen: Ryhmäläisen ilmoitus.

Toteutuessa: Muunnetaan työjakoa siten, että muut hoitavat myös sairastuneen henkilön tehtävät. Lisäksi voidaan joutua tinkimään joistakin toteutettavista osista, mikäli niiden toteuttaminen edellyttää sairastuneen henkilön osaamista.

Projektiryhmän jäsenen riittämätön osaaminen

Todennäköisyys: Mahdollinen

Vakavuus: Siedettävä

Minimointi: Työnjako osaamisen mukaan. Parityöskentely ja ryhmätyö. Avoin kommunikaatio. Kykyjen yliarvioinnin välttäminen.

Tunnistaminen: Jäsenen esiintuoma epävarmuus, aikataulujen venyminen.

Toteutuessa: Muu projektiryhmä antaa tukea. Työ jaetaan pienempiin osiin. Vastuualueen varahenkilölle annetaan isompi rooli.

Ryhmän sisäinen kommunikaatio ei ole riittävää

Todennäköisyys: Mahdollinen

Vakavuus: Vakava

Minimointi: Käytetään kaikkia sovittuja kommunikaation muotoja. Puututaan ongelmatilanteisiin välittömästi.

Tunnistaminen: Ryhmän jäsenet eivät ole tietoisia toistensa tekemisistä. Yksittäisten jäsenten tekemän työn kasaaminen yhteen aiheuttaa ylimääräistä työtä.

Toteutuessa: Lisätään kasvokkain tapahtuvan kommunikoinnin määrää. Tarvittaessa lisätään raportoinnin määrää.

Kommunikaatio-ongelmat asiakkaan kanssa

Todennäköisyys: Mahdollinen

Vakavuus: Siedettävä - vakava

Minimointi: Pidetään asiakkaan kanssa yhteyttä tiiviisti, dokumentoidaan vaatimukset tarkasti ja hyväksytetään välivaiheita asiakkaalla järjestelmällisesti. Sovitaan aikataulut ajoissa ja tarkasti.

Tunnistaminen: Projekti ei etene hyväksyttyjen vaatimusten puutteen takia.

Toteutuessa: Lisätään yhteydenpitoa ja vuorovaikutusta asiakkaan kanssa.

Projektityön osien laatu ei riittävä

Todennäköisyys: Mahdollinen

Vakavuus: Vakava

Minimointi: Tarkistutetaan osien tuotokset ryhmän tarkastustilaisuuksissa. Pidetään laadun näkökulma mielessä kaikissa toimissa.

Tunnistaminen: Myöhemmät vaiheet kärsivät edellisten epämääräisyydestä, lopullisen tuotteen laatu on huono.

Toteutuessa: Avataan jäädytetty osa muutoksille. Korjataan pahimmat puutteet epäonnistuneissa vaiheissa jälkeenpäin - palataan projektin vaiheessa takaisinpäin.

6.2. Aikatauluriskit

Aikataulu ei pidä

Todennäköisyys: Mahdollinen

Vakavuus: Siedettävä

Minimointi: Projektipäällikkö seuraa projektin etenemistä ja puuttuu myöhästymiseen. Projektin jäsenet ilmoittavat ajoissa, mikäli heille annetut tehtävät vaativat suunniteltua enemmän resursseja.

Tunnistaminen: Tarkastuspisteisiin päästään myöhässä

Toteutuessa: Tehdään kohtuuden rajoissa ylitöitä ja otetaan aikataulu kiinni. Sovitaan asiakkaan kanssa joidenkin vähemmän oleellisten vaatimusten pudottamisesta toteutuksesta.

Asiakas ei toimita lupaamiaan asioita ajoissa

Todennäköisyys: Mahdollinen

Vakavuus: Vakava

Minimointi: Pyritään sopimaan asiakkaan kanssa tarkasti toiminnasta ja aikatauluista. Viestitään selkeästi.

Tunnistaminen: Asiakkaan tuotokset eivät ole valmiit sovittuun aikaan mennessä.

Toteutuessa: Muutetaan aikatauluja. Otetaan suunnittelussa huomioon, että arkkitehtuuri mahdollistaa ominaisuuksien lisäämisen jälkeenpäin. Jätetään osa vaatimuksista toteuttamatta. Yritetään selvittää missä vika piilee ja mahdollisesti siirretään osa asiakkaan vastuulla olevista osista ryhmän harteille.

Vaatimuksia liikaa

Todennäköisyys: Suuri

Vakavuus: Siedettävä

Minimointi: Priorisoidaan vaatimukset tarkkaan alusta alkaen, suunnitellaan asiakkaan kanssa toteutettavat vaatimukset.

Tunnistaminen: Projekti ei pysy aikataulussa.

Toteutuessa: Jätetään vähemmän tärkeitä ominaisuuksia toteuttamatta.

Työmäärien virhearviointi

Todennäköisyys: Mahdollinen

Vakavuus: Siedettävä

Minimointi: Otetaan huomioon aikataulutuksessa. Analysoidaan vaatimukset huolellisesti ja aikataulutetaan projektin kulku alkuun mielummin pessimistisesti kuin optimistisesti. Projektiryhmä arvioi etukäteen onko hänelle osoitetun työtehtävän arvioitu työmäärä oikea.

Tunnistaminen: Projekti on jatkuvasti myöhässä aikataulusta.

Toteutuessa: Muutetaan työnjakoa. Jätetään osa vaatimuksista toteuttamatta.

6.3. Tekniikka ja teknologiariskit

Uuden tekniikan haltuunoton vaikeus

Todennäköisyys: Mahdollinen

Vakavuus: Siedettävä

Minimointi: Käytetään ensisijaisesti sellaista tekniikkaa, josta ryhmällä on osaamista. Huomataan ongelma ajoissa. Varataan aikatauluun aikaa tekniikan haltuunottoon. Jaetaan osaamista ryhmän kesken.

Tunnistaminen: Projektin eteneminen takkuilee tai ryhmän jäsenet viestittävät.

Toteutuessa: Vaihdetaan tekniikka tutumpaan tai yksinkertaisempaan. Muokataan aikataulua ja työnjakoa niin, että tekniikan sisäistämiseen jää aikaa.

Työkalujen (kehitysympäristö, dokumentointityökalut, versionhallinta käyttövaikeudet

Todennäköisyys: Mahdollinen

Vakavuus: Siedettävä

Minimointi: Valitaan työkalut jotka ovat tuttuja mahdollisimman monelle.

Tunnistaminen: Työkalujen käyttö tuntuu vaivalloiselta ja hitaalta, projektituotosten aikaansaannissa on ongelmia.

Toteutuessa: Harkitaan työkalujen vaihtamista, kysytään apua projektiryhmän sisällä tai ulkopuolisilta.

Tärkeä komponentti liian vaikea ryhmän toteutettavaksi

Todennäköisyys: Mahdollinen

Vakavuus: Vakava

Minimointi: Analysoidaan valmiita komponentteja käytettäväksi tarvittaessa.

Tunnistaminen: Yksittäisen komponentin toteutus takkuilee ja myöhästelee.

Toteutuessa: Pyritään etsimään sopiva valmis komponentti, yksinkertaistetaan komponentin toimintaa.

Ohjelmaversion tai sen osien tuhoutuminen

Todennäköisyys: Pieni

Vakavuus: Vähäpätöinen

Minimointi: Käytetään tunnollisesti CVS:ää ryhmähakemistossa ja luotetaan laitoksen varmuuskopioihin.

Tunnistaminen: Ohjelmaversion lähdekoodit ovat hävinneet.

Toteutuessa: Palataan ohjelmiston edelliseen versioon tai yritetään kaivaa uusin varmuuskopioista.

Projektidokumentin tuhoutuminen tai katoaminen

Todennäköisyys: Pieni

Vakavuus: Vähäpätöinen

Minimointi: Työstetään dokumentteja Wikissä. Projektin jäsenet huolehtivat kukin henkilökohtaisten työtuntitiedostojen varmuuskopioinnista..

Tunnistaminen: Dokumentti on kadonnut.

Toteutuessa: Kaivetaan esiin uusin varmuuskopio.

Valmiin komponentin laatu osoittautuu riittämättömäksi.

Todennäköisyys: Pieni

Vakavuus: Vakava

Minimointi: Käytetään riittävästi aikaa valmiiden komponenttien testaamiseen ja analysointiin.

Tunnistaminen: Integrointitestaus paljastaa vian jota ei olla huomattu analyysissa.

Toteutuessa: Pyritään löytämään parempi valmis komponentti tai koodataan sen toiminnallisuus itse.

6.4. Tuotettavaan ohjelmistoon liittyvät riskit

Asiakkaan vaatimukset muuttuvat

Todennäköisyys: Suuri

Vakavuus: Siedettävä

Minimointi: Jäädytetään olennaiset ja tärkeimmät pysyvät vaatimukset mahdollisimman pian, varataan aikaa elävien vaatimusten uudelleen toteuttamiseen.

Tunnistaminen: Asiakas haluaa ohjelmiston osia muutettavan.

Toteutuessa: Muutetaan ohjelmistoa, priorisoidaan tarvittaessa vaatimuksia uudestaan.

Asiakas tyytymätön ohjelmistoon

Todennäköisyys: Pieni

Vakavuus: Vakava

Minimointi: Määritellään asiakkaan kanssa vaatimukset huolellisesti. Annetaan asiakkaalle tutkittavaksi ja hyväksyttäväksi prototyyppejä ja muita välituotoksia.

Tunnistaminen: Asiakas ei pysty tekemään ohjelmalla haluamiaan asioita.

Toteutuessa: Neuvotellaan asiakkaan kanssa mahdollisista muutoksista aikatauluun ja ohjelmistoon.

6.5. Riskien toteutuminen

Projektin aikana useita etukäteen tunnistettuja riskejä pääsi toteutumaan. Riskien tarkkailu toimi, mutta yleisesti ottaen reagointi olisi saanut olla nopeampaa ja tapahtua kovemmalla kädellä.

Lähestulkoon kaikki aikatauluriskit toteutuivat. Sen lisäksi että vaatimusmäärittelyvaihe oli hankala ja kesti kovin kauan asiakkaan vaatimusten muuttuessa ja lisääntyessä koko ajan, arvioitiin myös lopulta työmäärät alakanttiin ja toteutettavia vaatimuksia oli tämän ansiosta liikaa. Aikataulut pääsivätkin venymään pahasti ja toteutettavia vaatimuksia jouduttiin karsimaan yhteensä kolme kertaa.

Aikataulujen venymiseen vaikuttivat pieneltä osalta myös viestintäongelmat. Ryhmän sisäinen kommunikaatio ei toiminut tarpeeksi tehokkaasti ja välillä palautteen ja neuvojen saaminen, ryhmätyö sekä työnjaosta sopiminen olikin vaikeaa ja hidasta. Viestintäongelmia ei kyetty kunnolla ratkaisemaan, eli kasvokkain tapahtuvaa kommunikointia lisäämään, koska ryhmän jäsenten aikatauluja ei kyetty riittävässä määrin sovittamaan yhteen.

Riski johon ei oltu varauduttu lainkaan oli asiakkaan katoaminen kuvasta. Viimeisessä vaiheessa vaatimusten karsimista jouduttiin tekemään ryhmän kesken ilman asiakkaan palautetta ja integraation ylimääräinen iteraatiokierros jättämään väliin asiakkaan vetäydyttyä ilmeisesti isyyslomalle varoittamatta.

7. Laadunvalvonta

Laadunvalvonnan tarkoituksena on varmistaa, että järjestelmä toteuttaa sille asetetut vaatimukset ja toimii virheettömästi. Järjestelmän korkeaan laatuun pyritään huolellisella suunnittelulla ja riittävällä testaamisella. Järjestelmän ja dokumenttien laatua valvotaan TR-katselmuksilla.

Projektin aikana ryhmän ohjaajalla on ulkopuolisen laaduntarkkailijan rooli. Kuitenkin vastuu laadusta kuuluu projektiryhmälle.

Dokumenttien laatu

Määrittely- ja suunnitteludokumenttien laatu varmistetaan katselmoinneilla aikataulun mukaan. Ennen katselmusta dokumentti käy läpi luku- ja korjauskierroksia ja dokumentin edistymistä seurataan erityisesti seurantakokouksissa. Katselmoinnin tuloksena dokumentti voidaan hyväksyä sellaisenaan, hyväksyä muutoksin tai hylätä, jolloin joudutaan järjestämään uusi katselmus myöhemmin.

Määrittelydokumentin osalta järjestetään TR-katselmointi, johon myös asiakas osallistuu. Suunnittelu dokumentit tarkistetaan siten, että ensin katselmoidaan osajärjestelmien väliset rajapinnat, tietorakenteet ja käyttöliittymän rajapinnat. Osajärjestelmien sisäiset suunnitelmat hyväksytään erikseen.

Dokumentin hyväksymisen jälkeen ne jäädytetään. Jäädytyksen jälkeen dokumentteihin voidaan tehdä muutoksia vain erillisen muutoksenhallintakokouksen toimesta. Dokumentti siirretään jäädytyksen jälkeen nähtäväksi projektin kotisivulle.

Ohjelmiston laatu

Ohjelmiston suunnittelussa ja toteutuksessa tulee pitäytyä määrittelyn asettamissa rajoissa niin, että lopputuotteen toiminnallisuus pystytään johtamaan määrittelydokumentista. Näin ollen onnistunut yhteistyö asiakkaan kanssa on laadun kannalta yksi tärkeimmistä tekijöistä.

Ohjelmistolle laaditaan kattava testaussuunnitelma, jonka pohjalta suoritetaan yksikkö-, integrointi- ja järjestelmätestaus. Testien tulokset kirjataan ylös ohjelmakoodiin (yksikkötestit) ja testausdokumenttiin.

TR-kokoukset

TR-kokouksessa tarkistetaan projektissa tuotettu dokumentti tai ohjelmiston osa mahdollisimman tarkasti etsien siitä virheitä systemaattisella tavalla. Kokouksessa ovat läsnä asiakas, projektiryhmä, sekä ryhmän ohjaaja. Kaikki kokouksen osanottajat perehtyvät mahdollisimman tarkasti tarkastettavaan tuotokseen.

Ryhmä käy alustajan ohjaamana läpi tarkastettavat tuotoksen ja etsii siitä virheitä. Asiantuntija selittää ryhmälle kohdat, joista heillä on kysyttävää. Sihteeri kirjaa löydetyt virheet tai puutteet pöytäkirjaan. Tuotos voidaan hyväksyä sellaisenaan, korjauksin tai se voidaan hylätä, jolloin varataan aika uudelle kokoukselle. Kokous keskittyy siis virheiden löytämiseen, ei niiden korjaamiseen.

15

2005-12-11T18:49:59