VuHa Vuokra-asuntojen ja -sopimusten hallintasovellus

Helsingin yliopisto Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti S-01, ryhmä 9 VuHa Vuokra-asuntojen ja -sopimusten hallintasovellus Projektisuunnitelma Projektiryhmän jäsenet: Leena Hyvönen Jussi Iinatti Tuomo Kukkola Pekka Sjöberg Mikko Vitikainen Laura Vuorinen Ohjaaja: Tiiu Ainetdin henkilö: Raine Kauppinen Asiakkaan edustajat: Helena Ahonen-Myka Tylle Väisänen

Versiohistoria Versio Kuvaus Päivämäärä Tekijä 0.1 Ensimmäinen luonnos 9.9.2001 Jussi Iinatti 0.2 Päivitetty luonnos 12.9.2001 Kaikki 0.3 Päivitetty luonnos 13.9.2001 Jussi Iinatti 1.0 Hyväksymiskokouksen jälkeinen päivitetty versio 16.9.2001 Jussi Iinatti 1

Sisältö VERSIOHISTORIA...1 SISÄLTÖ...2 1 JOHDANTO...3 1.1 PROJEKTIN KUVAUS...3 1.2 PROJEKTIORGANISAATIO JA SIDOSRYHMÄT...3 1.3 OIKEUDET...4 1.4 KÄYTETYT TERMIT JA LYHENTEET...5 2 PROJEKTIN TAVOITTEET JA PÄÄTTYMINEN...6 2.1 PROJEKTIRYHMÄN TAVOITTEET...6 2.2 ASIAKKAAN TAVOITTEET...6 2.3 PROJEKTIN PÄÄTTYMINEN...7 3 TYÖSKENTELYPERIAATTEET...8 3.1 LAITTEISTO, TYÖVÄLINEET, TILAT...8 3.2 DOKUMENTOINTI...8 3.3 PROJEKTISSA TUOTETTAVAT DOKUMENTIT...9 3.4 MUU DOKUMENTAATIO...10 3.5 KOODIN DOKUMENTOINTI...10 3.6 OHJELMOINTI...11 3.7 PROJEKTITYÖSKENTELY...11 4 PROJEKTIN VAIHEJAKO...12 4.1 MÄÄRITTELYVAIHE...12 4.2 SUUNNITTELUVAIHE...13 4.3 TOTEUTUSVAIHE...13 4.4 TESTAUSVAIHE...14 4.5 PROJEKTIN PÄÄTTÄMINEN...14 5 OHJELMISTON LAAJUUS JA AIKATAULU...15 5.1 TYÖMÄÄRÄARVIOT...15 5.2 OHJELMISTON KOKO...15 5.3 PROJEKTIN AIKATAULU...15 6 PROJEKTIN SEURANTA JA OHJAUS...17 6.1 RYHMÄN SISÄINEN...17 6.2 RYHMÄN ULKOPUOLINEN...17 6.3 MUUTA...17 7 RISKIENHALLINTA...18 7.1 RISKIEN JAOTTELU...18 7.2 RISKIEN ENNAKOINTI...19 2

1 Johdanto 1.1 Projektin kuvaus Ohjelmistotuotantoprojekti on tietojenkäsittelytieteen pääaineopiskelijoille pakollinen, lukukauden mittainen kurssi, jonka aikana projektiryhmän jäsenet toteuttavat täysimittaisen ohjelmistotuotantoprojektin. Projektin tuotteena saatava sovellus ratkaisee projektin asiakkaan esille tuoman ja määrittelemän ongelman. VuHa-projektin tuloksena saatava sovellus on tarkoitettu opiskelija-asuntoja välittävien yhteisöjen käyttöön, helpottamaan asuntojen vuokraamisesta vastaavan henkilön työtä. Sovellus ohjaa ja opastaa käyttäjää asuntojen vuokraamiseen liittyvissä prosesseissa, sekä tarjoaa välineet eri prosesseihin liittyvien dokumenttien ja tietojen hallitsemiseksi. Sovelluksella pystytään tuottamaan monipuolisia raportteja asuntohaku- ja vuokraustilanteesta. Itse sovelluksen ja lähdekoodin lisäksi projektin tuotteina syntyy erilaisia dokumentteja, sekä projektin verkkosivusto. Luotavat dokumentit on määritelty myöhemmin tässä dokumentissa. Verkkosivuston tarkoituksena on, paitsi tarjota tietoa projektin etenemisestä, myös toimia tietovarastona, jossa projektin dokumentit ovat helposti saatavilla. Sovelluksesta ei ole tarkoitus tehdä markkinoille vietävää tuotetta, vaan se toteutetaan GNU Public License -ehtojen mukaisesti levitettävänä Open source -ohjelmistona. 1.2 Projektiorganisaatio ja sidosryhmät 1.2.1 Projektiryhmä Projektiryhmä koostuu kuudesta tietojenkäsittelytieteen pääaineopiskelijasta. Projektiryhmä suorittaa kaikki projektiin kuuluvat vaiheet, sekä vastaa projektin laadunvalvonnasta koko projektin ajan. Projektin erityisluonteesta yliopiston harjoituskurssina johtuen, projektiryhmä on järjestynyt demokraattiseksi, hajautetuksi organisaatioksi. Projektipäällikkönä toimii jokainen ryhmäläinen vuorollaan. Tehtävä vaihtuu siirryttäessä projektin osavaiheesta toiseen. Kunkin osavaiheen aikana toimiva projektipäällikkö ohjaa ryhmän toimintaa ja on vastuussa vaiheen aikana tuotettavista dokumenteista. Myös muita projektityössä esille tulevia tehtäviä, kuten sihteerin tehtävä, pyritään kierrättämään kaikkien ryhmän jäsenten välillä. 3

1.2.2 Ryhmän jäsenet Leena Hyvönen leena.hyvonen@helsinki.fi 040 5634622 Jussi Iinatti jussi.iinatti@helsinki.fi 040 5614445 Tuomo Kukkola tuomo.kukkola@helsinki.fi 040 7077704 Pekka Sjöberg pekka.sjoberg@helsinki.fi 050 5319410 Mikko Vitikainen mikko.vitikainen@helsinki.fi 040 5739766 Laura Vuorinen laura.vuorinen@helsinki.fi 050 5428833 1.2.3 Projektin ohjaaja Tiiu Ainetdin tiiu@oks.cc 1.2.4 Projektin vastuuhenkilö Raine Kauppinen rkkauppi@cs.helsinki.fi 1.2.5 Asiakkaan edustajat Asiakkaan edustajina projektissa toimivat Tylle Väisänen, Pohjalaisen Valtuuskunnan asuntosihteeri, sekä Helena Ahonen-Myka tietojenkäsittelytieteen laitokselta. Projektin päättyessä asiakas arvioi vastaako ohjelma sovittuja määrityksiä. Tylle Väisänen valvoo, että ohjelman toiminnallinen toteutus vastaa loppukäyttäjän tarpeita ja vaatimuksia. Helena Ahonen-Myka valvoo, että ohjelman teknisen toteutuksen laatu noudattaa ohjelmistotuotantoprojektissa vaadittua tasoa ja toimii projektin teknisenä asiantuntijana. Tylle Väisänen Tylle.Vaisanen@helsinki.fi Helena Ahonen-Myka Helena.Ahonen-Myka@cs.helsinki.fi 1.3 Oikeudet Projektiin osallistuvat henkilöt (projektiryhmä) luovuttavat tuotettavan ohjelmiston oikeudet Helsingin yliopistolle. Helsingin yliopisto puolestaan antaa ohjelmistoon vapaan käyttöoikeuden GNU General Public Licence -ehtojen mukaisesti. Lisätietoja GNU -lisensseistä läytyy GNU:n verkkosivuilta www.gnu.org 4

1.4 Käytetyt termit ja lyhenteet DTD Document Type Declaration, W3C:n kehittämä rakenteisten dokumenttien rakenteen määrittelykieli. Lisätietoja: http://www.w3.org/xml/ HTML Hypertext Markup Language, WWW-sivujen sisällön kuvauksessa käytetty kieli. Lisätietoja: http://www.w3.org/pub/www/markup/ Java Sunin kehittämä ohjelmointikieli ja järjestelmäriippumaton ajoympäristö. Lisätietoja: http://java.sun.com Javadoc Sunin kehittämä Java-koodin dokumentointimenetelmä. Lisätietoja: http://java.sun.com TKTL Helsingin yliopiston tietojenkäsittelytieteen laitos. Lisätietoja: http://www.cs.helsinki.fi W3C World Wide Web Consortium, kansainvälinen yhteistyöelin, joka koordinoi WWW-tekniikan ja -standardien kehitystä. Lisätietoja: http://www.w3.org/pub/www/consortium/ XML Extensible Markup Language, W3C:n kehittämä rakenteisten dokumenttien määrittelykieli. Lisätietoja: http://www.w3.org/xml/ XSL Extensible Stylesheet Language, W3C:n kehittämä XML-dokumenttien ulkoasun määritykseen tarkoitettu kieli. Lisätietoja: http://www.w3.org/style/xsl/ 5

2 Projektin tavoitteet ja päättyminen 2.1 Projektiryhmän tavoitteet Ryhmän päätavoitteena on - aikataulun puitteissa - tuottaa korkealaatuista materiaalia, joka vastaa asiakkaan tavoitteita. Asiakkaan tavoitteiden pohjalta luodaan lista toteutettavista ominaisuuksista, joiden puuttuminen lopullisesta tuotteesta merkitsee projektin epäonnistumista. Osa alkuperäisistä tavoitteista kirjataan lisäominaisuuksina, jotka toteutetaan aikataulun niin salliessa, mutta joiden puuttuminen ei suoraan merkitse projektin epäonnistumista. Projekti on tietojenkäsittelytieteen harjoituskurssi, joten ryhmän yhtenä tavoitteena on oppia ohjelmistotuotantotekniikkaa, ryhmässä työskentelyä, dokumentointia sekä uusia sovellustekniikoita ja tuotantovälineiden käyttöä. 2.2 Asiakkaan tavoitteet Tällä hetkellä asiakas tekee kaiken vuokra-asuntojen hallintaan ja asukkaiden valitsemiseen liittyvät toimenpiteet manuaalisesti. Asiakkaan tavoitteena on saada aikataulun mukaisesti käyttöönsä sovellus, joka täyttää mahdollisimman täydellisesti hänen määrittelemänsä vaatimukset. Sovelluksen on myös tarkoitus suorittaa osa asiakkaan tällä hetkellä manuaalisesti tekemistä tehtävistä. Tarkoituksena on helpottaa asiakkaan työtä, ettei kaikkea tarvitse enää tehdä käsin. Asiakas odottaa tuotteelta korkeaa laatua, joka ilmenee mm. helppokäyttöisyytenä ja toimintavarmuutena. Asiakas haluaisi sovelluksen toteuttavan seuraavat ominaisuudet ja toiminnot: - Asunnon hakijoiden tietojen tallentaminen - Asuntojonon muodostaminen asunnon hakijoista - Vuokrasopimusten tietojen tallentaminen - Asuntojen tietojen tallentaminen - Asuntojen varaaminen osakunnille - Asunnon haku - Henkilön haku nimen puhelinnumeron asunnon haettavan asunnon loppuvan asumisajan loppuvan vuokrasopimuksen mukaan - Raporttien tulostaminen henkilöistä joiden asumisoikeus tai vuokrasopimus loppumassa vapaista ja vapautuvista asunnoista asuntojen täyttöasteesta 6

kuukauden sisään ja ulos muuttajista kaikista vuoden aikana sisään muuttaneista kuukauden sisällä päättyvistä vuokrasopimuksista asuntojonoista osakuntien asuntokiintiöistä tehdyistä vuokrasopimuksista asunnoista, joissa on ollut lemmikkejä - Ohjelmiston käytön kontrollointi salasanalla 2.3 Projektin päättyminen Projekti päättyy kun kaikki määritelty materiaali on valmistunut ja se on hyväksytty päätöskatselmuksessa kaikkien sidosryhmien kanssa. Muuten projekti voi päättyä vain, jos siitä sidosryhmien kanssa kokouksessa erikseen sovitaan. Poikkeavaan projektin päättämiseen voidaan päätyä vain jos sen epäonnistuminen näyttää erittäin epätodennäköiseltä. Projektin arvioitu päättymispäivä on 13.12.2001, joka on samalla myös alustava päivämäärä päätöskatselmukselle. Projektin on päätyttävä viimeistään 31.12.2001, jonka jälkeen se arvostellaan. 7

3 Työskentelyperiaatteet 3.1 Laitteisto, työvälineet, tilat Toteutusta varten projektiryhmälle on varattuna kaksi tietokonetta TKTL:n huoneessa D325. Nämä koneet ovat myös julkisessa käytössä, mutta ryhmäläisillä on oikeus ottaa ne omaan käyttöönsä viiden minuutin varoitusajalla. Versionhallintaan käytetään tarvittaessa TKTL:n CVS-palvelinta, jonne luodaan projektia varten oma moduuli, sekä henkilökohtaiset tunnukset jokaiselle ryhmän jäsenelle. Sovelluskehitystä ei ole sidottu mihinkään tiettyyn ohjelmointiympäristöön tai alustaan, kunhan tuotettava lähdekoodi on Java 1.2.2 yhteensopivaa. Mahdollisista ulkoisista kirjastoista sovitaan erikseen suunnitteluvaiheessa. Kirjastojen käytössä on huomioitava, että lopputuotteen on täytettävä GNU Public License -levitysehdot. Ryhmän käytössä on säilytyslokero numero 19 TKTL:n huoneessa D328, jossa säilytetään projektikansiota, kopiokorttia, kopiokalvoja, sekä muuta projektin materiaalia. Jokaisella projektiryhmän jäsenellä on avain kaappiin. 3.2 Dokumentointi Projektiin kuuluvat dokumentit tuotetaan ja säilytetään MS Word 97/2000 -muodossa. Verkkosivuille dokumentit kopioidaan myös PostScript tai PDF-muotoisina. Erilaisten kaavioiden ja kuvien täytyy olla osana dokumenttia, jossain yleisesti tunnetussa muodossa, kuten GIF, JPG tai TIFF. Alkuperäiset kuva- ja kaaviotiedostot on syytä säilyttää projektin päättymiseen saakka, vaikka niitä ei välttämättä liitettäisikään palautettavaan materiaaliin. Jokaisen dokumentin alussa on oltava versiohistoria, jota päivitetään aina dokumenttia muokattaessa. Versiohistoriassa tulee mainita kuvaus dokumentin tilasta, tai tehdyistä muutoksista, sekä muokkaaja ja muokkauspäivämäärä. Projektin vaiheesta toiseen siirryttäessä dokumenteista talletetaan sen hetkiset versiot pysyvästi, sekä projektikansioon, että projektin verkkosivuille. 3.2.1 Dokumenttien jäädyttäminen Osa dokumenteista hyväksytään hyväksymiskokouksessa ja hyväksytty versio jäädytetään. Jäädytetyt versiot talletetaan pysyvästi. Jokainen jäädytettyyn dokumenttiin tehtävä muutos vaatii erityisen versionhallintakokouksen, jossa muutokset hyväksytään. Muutokset sisältävä dokumentti erotetaan alkuperäisestä versionumeroinnilla. Alkuperäisen dokumentin liitteeksi lisätään muutosdokumentti, jossa tehdyt muutokset on lueteltu. 8

3.3 Projektissa tuotettavat dokumentit Projektisuunnitelma - Yleiskuvaus tehtävästä ohjelmistosta - ohjelmiston kokoarvio LOC-menetelmällä - projektin vaihejako - aikatauluarvio - projektin etappipisteet (esim. dokumentin jäädytys) - projektiryhmän työnjako - riskienhallintasuunnitelma Projektisuunnitelmaa pidetään ajan tasalla koko projektin ajan. Vaatimusdokumentti - Vaatimusten kartoitus: o Ohjelmiston yleiskuvaus sidosryhmien kannalta o Ohjelmiston tarjoamien palveluiden yksityiskohtainen kuvaus o Järjestelmän ulkoiset laitteistotason liittymät o Käyttöliittymä o Käytettävyysvaatimukset o Rajoitteet suunnittelulle ja toteutukselle - Vaatimusten analysointi ja mallinnus: o Tietomallinnus: ER-kaaviot tai olio-yhteys -kaaviot o Funktiomallinnus: Käyttötapaukset Käyttöohje - sisältää loppukäyttäjälle tarkoitetun kuvauksen järjestelmän toiminnoista. Suunnitteludokumentti - Yleistä o Ohjelmiston kuvaus o Tärkeimmät vaatimukset o Suunnittelurajoitukset - Osajärjestelmien yleiskuvaus o Kaaviokuva osajärjestelmistä ja sen selitys o Osajärjestelmien välinen kommunikointi ja protokollat o Rinnakkaisuusasiat - Osajärjestelmäkuvaus, kustakin osajärjestelmästä: o Kaaviokuva ulkoisista ja sisäisistä olioista ja sen selitys o Rajapinnan kuvaus toisiin osajärjestelmiin o Rajapinnan kuvaus ulkoisiin elementteihin (tiedostot, tietokanta ym.) o Käyttöliittymäkuvaus, jos se kuuluu osajärjestelmän tehtäviin o Luokkakuvaus, kustakin luokasta: o Tietosuunnitelma o Arkkitehtuurisuunnitelma o Liittymäsuunnitelma (sisäiset liittymät ja luokan rajapinta) o Toimintosuunnitelma - Toteutusympäristön kuvaus 9

Testaussuunnitelma, sisältäen testitulokset - sisältää kuvauksen suoritettavista moduuli- ja luokkatason, integrointitason ja validointitason testeistä, sekä käytettävän testiaineiston. Testauksen edetessä testitulokset liitetään osaksi tätä dokumenttia. Asennusohje - kertoo kuinka ohjelmisto asennetaan käyttöympäristöönsä valmiiksi loppukäyttäjää varten. Voi olla osana ylläpitodokumenttia. Toteutusdokumentti - Toteutuksen onnistuminen verrattuna suunnitteludokumenttiin: o ominaisuuksien muutokset o ominaisuuksien karsiminen o ominaisuuksien lisäykset o suunnitelmassa havaittujen virheiden korjaukset 3.4 Muu dokumentaatio Työtuntilistat - jokainen projektiryhmän jäsen pitää kirjaa tekemistään työtunneista päivän tarkkuudella. Kokouspöytäkirjat - jokaiseen kokoukseen valitaan sihteeri, joka kirjaa ylös käsiteltävien asioiden pääkohdat ja päätökset, ja kirjoittaa niistä kokouspöytäkirjan. Sisäiset muistiot - niiden tapaamisten, jotka eivät ole virallisia kokouksia, muistiinpanot kirjataan muistioihin, jotka säilytetään. Ylläpitodokumentti - sisältää sellaisen kuvauksen järjestelmän toiminnallisuudesta, että mahdollinen ohjelmiston ylläpitohenkilö pystyy suoriutumaan tehtävästään. Loppuraportti - on lyhyt yhteenveto projektista, johon otetaan liitteiksi sellaiset jatkuvasti päivitetyt dokumentit, jotka eivät ansaitse omaa raporttia. Esimerkiksi työtuntilistat, pöytäkirjat ja sisäiset muistiot ovat tällaisia raportteja. 3.5 Koodin dokumentointi Java-koodi dokumentoidaan javadoc-standardin mukaisesti, seuraavaa ohjetta noudattaen: - Kaikki luokat kommentoidaan - Kaikki metodit kommentoidaan - Kaikki static -muuttujat kommentoidaan - Kaikki public -muuttujat kommentoidaan - private muuttujat kommentoidaan koodin kirjoittajan oman harkinnan mukaisesti Javadoc-kommentteihin tulee liittää seuraavat tiedot, mikäli ne ko. kommenttiin on mahdollista liittää: author, version, param, return, exception / throws 10

Koodin osia voi ja kannattaa kommentoida myös normaaleilla kommenteilla, joista siis ei generoida javadoc-dokumentaatiota. Lisää: http://java.sun.com/j2se/javadoc/ 3.6 Ohjelmointi Java-koodi kirjoitetaan Sunin Java-tyylioppaan, http://java.sun.com/docs/codeconv mukaisesti. HTML-koodi noudattaa World Wide Web Consortiumin määrittelemää HTML Specification v4.0 Transitional standardia, http://www.w3.org. Arkkitehtuurin mallinnuksessa noudatetaan UML-standardia ja tietokannan mallinnuksessa ER-mallia. Projektin aikana tuotettu materiaali kerätään ryhmän kotihakemistoon /home/group/vuha/, jonne luodaan tarkoitusta varten sopiva hakemistorakenne. 3.7 Projektityöskentely Projektiryhmä kokoontuu TKTL:n huoneessa C476 säännöllisesti kahdesti viikossa, ellei poikkeuksesta erikseen ryhmän kesken sovita. Säännölliset kokousajat ovat: - maanantaisin 17.00 19.00 - torstaisin 08.30 10.30 Kokousten ulkopuolella ryhmän pääkommunikointiväline on sähköposti. Mikäli joku ryhmän jäsenistä ei pääse saapumaan kokoukseen tai myöhästyy merkittävästi, tulisi asiasta ilmoittaa joko aikaisemmassa kokouksessa, sähköpostilla tai äkillisissä tapauksissa tekstiviestillä jollekin ryhmän jäsenelle, joka on tulossa kokoukseen. Dokumentit, aikataulu ja yhteystiedot ovat saatavilla ryhmän kotisivulta osoitteesta http://www.cs.helsinki.fi/group/vuha/ 11

4 Projektin vaihejako Projekti toteutetaan vesiputousmallin mukaisesti, jolloin seuraavaan vaiheeseen siirrytään edellisen päätyttyä.edellisen vaiheen dokumentit ja muu tuotanto toimii seuraavan vaiheen syötteenä. Vaihejaon lisäksi projekti pyritään jakamaan erillisiin moduuleihin siten, että tuotannossa päästään mahdollisimman laajaan rinnakkaisuuteen. 4.1 Määrittelyvaihe Määrittelyvaiheen aikana analysoidaan asiakkaan vaatimuksia ja niistä johdetaan ohjelmiston vaatimukset, jotka taas määrittelevät toteutettavan järjestelmän sisällön. Määrittelyvaiheen aikana projektin määrittelyn ja vaatimusanalyysin lisäksi aloitetaan ohjelmiston käyttöohjeen laatiminen. 4.1.1 Projektin määrittely Asiakkaan vaatimukset ja projektin ongelmakenttä kartoitetaan pääpiirteittäin, jotta kaikilla on selkeä kuva toteutettavan ohjelmiston luonteesta. Kartoituksen pohjalta määritellään projektin tuleva sisältö ja kulku, päätetään projektiorganisaatio, vaihejako ja alustava aikataulu. Tulokset kirjataan projektisuunnitelmaan. 4.1.2 Vaatimusanalyysi Vaatimusanalyysin tarkoituksena on selvittää asiakkaan tuotteelle asettamat vaatimukset.vaatimukset luokitellaan välttämättömiin ominaisuuksiin ja lisäominaisuuksiin. Välttämättömät ominaisuudet ovat oleellinen osa tuotetta, jotka toteutetaan. Lisäominaisuudet toteutetaan vain, jos projektilla riittää siihen ylimääräisiä resursseja. Vaatimukset dokumentoidaan asiakkaalle vaatimusdokumentiksi. 4.1.3 Päivitettävät dokumentit - 12

4.1.4 Luotavat dokumentit Projektisuunnitelma Vaatimusdokumentti Käyttöohje 4.2 Suunnitteluvaihe Suunnitteluvaiheen aikana ohjelmistosta rakennetaan malli, jonka avulla ohjelmisto voidaan tuottaa suoraviivaisesti. Vaiheen tehtävänä on muokata vaatimusanalyysissa esille tuodut tuotteen ominaisuudet sellaiseen muotoon, että ne voidaan helposti toteuttaa valituilla ohjelmointikielillä. Suunnitellaan ohjelmiston tietorakenteet, arkkitehtuuri, käyttöliittymä, ja algoritmiset yksityiskohdat. Testaussuunnitelman ja asennusohjeen luominen aloitetaan suunnittelun yhteydessä. Suunnittelun tulokset dokumentoidaan suunnitteludokumentiksi. 4.2.1 Päivitettävät dokumentit Projektisuunnitelma Käyttöohje 4.2.2 Luotavat dokumentit Suunnitteludokumentti Testaussuunnitelma Asennusohje 4.3 Toteutusvaihe Suunnitelmat toteutetaan, eli suunnitelma käännetään tietokoneen ymmärtämälle kielelle. Jos edeltävät vaiheet on viety huolella läpi, tämä vaihe on mekaaninen. Tulos dokumentoidaan toteutusdokumentiksi. 4.3.1 Päivitettävät dokumentit Projektisuunnitelma Käyttöohje Testaussuunnitelma Asennusohje 4.3.2 Luotavat dokumentit Toteutusdokumentti 13

4.4 Testausvaihe Testausta suoritetaan mm. algoritmi- ja moduulitasolla koko ohjelmiston tuotannon ajan. Testausvaiheessa suoritettava testaus on integraatiotestaus ohjelmistoa testataan kokonaisuutena. Yhdessä asiakkaan kanssa suoritetaan toiminnallisuuden testaus. Vaiheen aikana löydetyt virheet korjataan ja tulokset kirjataan osaksi testaussuunnitelmaa. 4.4.1 Päivitettävät dokumentit Testaussuunnitelma 4.4.2 Luotavat dokumentit - 4.5 Projektin päättäminen Projekti tarkastetaan, ja mahdollisesti hyväksytään ja päätetään päätöskatselmuksessa, jossa läsnä ovat kaikki projektin sidosryhmät. Projektin päättymisen jälkeen voidaan vielä viimeistellä dokumenttien uusimpia versioita, lähinnä kirjoitusvirheiden ja ulkoasun osalta. Projektiryhmä tarkistaa että kaikista dokumenteista on lähetetty kopiot niitä tarvitseville, sekä projektin verkkosivuille ja projektikansioon. Valmistellaan ja pidetään projektin loppudemo. 4.5.1 Viimeisteltävät dokumentit Uusimmat versiot 4.5.2 Luotavat dokumentit Loppuraportti 14

5 Ohjelmiston laajuus ja aikataulu 5.1 Työmääräarviot Jokainen ryhmän jäsen tekee viikossa keskimäärin 20 tuntia työtä. Tähän työmäärään on laskettu mukaan kaikki ryhmän tapaamiset ja palaverit. 5.2 Ohjelmiston koko 5.2.1 LOC arvio ohjelmiston koosta LOC arviointi suoritetaan määrittelyvaiheen myöhemmässä vaiheessa. 5.2.2 Ennakkoarvio ohjelmiston koosta Projektin kiinteästä aikataulusta ja resursseista voi laskea että ohjelmakoodia tullaan tuottamaan arviolta 3500 riviä. 5.3 Projektin aikataulu 5.3.1 Projektin eri vaiheiden aikataulu Käytettävissä ~1200 henkilötyötuntia (6 hlö * 200h/hlö) Vaihe Aikataulu Työmääräarvio Projektisuunnitelma vk. 36-37 80 h (7%) Vaatimusanalyysi vk. 38-40 150 h (13%) Suunnittelu vk. 41-44 400 h (33%) Toteutus vk. 45-47 300 h (25%) Testaus & korjaus vk. 48-49 150 h (12%) Lopputoimenpiteet vk. 49-50 120 h (10%) = 1200 h (100%) Lopputoimenpiteet sisältävät: Käyttöohjeen viimeistely Loppudemon valmistelu Loppudemo Loppuraportin teko 5.3.2 Viikkoaikataulu Vk. Pvm. Tapahtuma 35 Pe 31.8. Projektin aloitustapaaminen 36 Ti 4.9. Tapaaminen yhdessä ohjaajan kanssa To 6.9. Tavattu asiakas Projektisuunnitelman teko alkaa 37 Ma 10.9. Tapaaminen yhdessä ohjaajan kanssa, projektisuunnitelman valmistelua To 13.9. Tapaaminen yhdessä ohjaajan kanssa, projektisuunnitelman tarkastaminen 15

38 Ma 17.9. Tapaaminen yhdessä ohjaajan kanssa, projektisuunnitelma jäädytetään, aloitetaan vaatimusanalyysi, projektipäällikkö vaihtuu To 20.9. Tapaaminen yhdessä ohjaajan kanssa 39 Ma 24.9. Tapaaminen yhdessä ohjaajan kanssa, seurantakokous To 27.9. Tapaaminen yhdessä ohjaajan kanssa 40 Ma 1.10. Tapaaminen yhdessä ohjaajan kanssa, vaatimusanalyysi valmistuu To 4.10. Tapaaminen yhdessä ohjaajan kanssa, vaatimusdokumentin tarkistaminen 41 Ma 8.10. Vaatimusanalyysin katselmuspalaveri. Tapaaminen yhdessä asiakkaan kanssa, jäädytetään vaatimusdokumentti, aloitetaan suunnittelu, pp vaihtuu To 11.10. Tapaaminen yhdessä ohjaajan kanssa, seurantakokous 42 Ma 15.10. Tapaaminen yhdessä ohjaajan kanssa, suunnittelu etenee To 18.10. Tapaaminen yhdessä ohjaajan kanssa 43 Ma 22.10. Tapaaminen yhdessä ohjaajan kanssa, seurantakokous To 25.10. Tapaaminen yhdessä ohjaajan kanssa 44 Ma 29.10 Tapaaminen yhdessä ohjaajan kanssa To 1.11. suunnitteludokumentti valmistuu 45 Ma 5.11. Suunnitteludokumentin katselmuspalaveri Tapaaminen yhdessä asiakkaan kanssa, jäädytetään suunnitteludokumentti, aloitetaan toteutustyö, pp vaihtuu. To 8.11. Tapaaminen yhdessä ohjaajan kanssa, seurantakokous 46 Ma 12.11. Tapaaminen yhdessä ohjaajan kanssa To 15.11. Tapaaminen yhdessä ohjaajan kanssa, seurantakokous 47 Ma 19.11. Toteutusdokumentti valmistuu, tehdään testaussuunnitelma? To 22.11. Tapaaminen yhdessä ohjaajan kanssa 48 Ma 26.11. Jäädytetään toteutusdokumentti, Aloitetaan testaus & bugikorjaus, pp vaihtuu To 29.11. Tapaaminen yhdessä ohjaajan kanssa, seurantakokous 49 Ma 3.12. Tapaaminen yhdessä ohjaajan kanssa, Testausdokumentti valmistuu To 6.12. Tapaaminen yhdessä ohjaajan kanssa, Jäädytetään testausdokumentti, loppudemon valmistelu, loppuraportin kirjoittaminen 50 Ma 10.12. Loppuraportti valmistuu, demo, To 13.12 Projekti päätöskatselmus? 16

6 Projektin seuranta ja ohjaus 6.1 Ryhmän sisäinen Ryhmä pitää tapaamisaikojensa yhteydessä seurantakokouksia tarpeen mukaan. Kokousten ajankohta sovitaan aina tapauskohtaisesti. Tapaamisissa on ryhmän jäsenten lisäksi paikalla ryhmän ohjaaja ja mahdollisesti myös ohjelmistotuotantoprojektin vastuuhenkilö. 6.2 Ryhmän ulkopuolinen Erillistä laadunvalvontaryhmää ei projektille perusteta. Ryhmän jäsenet tekevät projektin aikana jatkuvaa ohjelmistoarviointia. Tuotteen lisäksi arvioidaan dokumentteja ja muuta aineistoa. Formaalia teknistä arviointia (FTR) tehdään harkinnan mukaan. Valmisteltuja FTR-kokouksia voidaan pitää viikkotapaamisten yhteydessä. Asiakas seuraa projektia osallistumalla haluamillaan kerroilla ja pyydettäessä ryhmän tapaamisiin ja seurantakokouksiin. Asiakasta informoidaan myös sähköpostitse projektin etenemisestä. Lisäksi ohjelmistosta järjestetään asiakkaalle erillinen demotilaisuus testausvaiheen aikana. 6.3 Muuta Projekti pyritään rajaamaan siten että tarvittava työmäärä on realistinen. Kaikkia ohjelmistoon liittyviä piirteitä ja toimintoja ei ole kurssin puitteissa mahdollista toteuttaa. 17

7 Riskienhallinta Riskit tarkistetaan jokaisen vaiheen jälkeen ennen siirtymistä uuteen vaiheeseen. Tarkistus tehdään projektiryhmän yhteisessä tapaamisessa. Riskien todennäköisyyksien arviointiin on käytetty asteikkoa epätodennäköinen, mahdollinen, todennäköinen. Riskeistä on tarkemmin käsitelty todennäköisimmät riskit sekä sellaiset mahdolliset ja epätodennäköiset riskit jotka toteutuessaan aiheuttaisivat huomattavia ongelmia. Tarkemmin käsitellyt riskit on riskien jaottelussa merkitty tähdellä. 7.1 Riskien jaottelu 7.1.1 Tekniset riskit työkalut valitaan huonosti (tehtävään sopimattomat työkalut) ryhmän jäsenet eivät hallitse käytettäviä työkaluja toteutustekniikka valitaan huonosti (tehtävään sopimaton tekniikka) ryhmän jäsenet eivät hallitse käytettäviä toteutustekniikoita versionhallinta ei suju, hukataan jo tehtyä työtä tai ei olla selvillä kokonaistilanteesta varmuuskopioinnin puute aiheuttaa tehdyn työn häviämisen (*) tarvittavia laitteistoresursseja ja työkaluja ei ole riittävästi saatavissa (etenkin kiivaan työskentelyn aikoina) tietoliikenneyhteydet takkuavat 7.1.2 Aikataulun riskit tehtävää ei rajata riittävästi (*) kaikkia työvaiheita ei huomata ottaa mukaan aikataulun suunnittelussa työmäärät arvioidaan liian pieniksi (*) aikataulu on liian optimistinen aikaa tuhrataan epäoleellisiin tehtäviin (*) opetteluun ei voida varata tarpeeksi aikaa, lopputuloksen laatu on huono ja aikataulu mättää ryhmäläisten osaamisen ja ammattitaidon erilaisuutta ei osata riittävästi ottaa huomioon (*) asiakkaalla ei ole aikaa palavereihin ja kokouksiin tai yhteistä sopivaa aikaa ei löydy 7.1.3 Organisaatioon, henkilöihin ja tiedonkulkuun liittyvät riskit ryhmän jäsen sairastuu (*) ryhmän jäsen on matkoilla (*) ryhmän jäsen on kiireinen (työ, tentti ) (*) ryhmän jäsen keskeyttää kurssin (*) ryhmän jäsenillä keskenään ristiriitaiset tavoitteet (kurssista ykkösellä läpi <> hyvä toimiva käyttökelpoinen ohjelmisto) osakuntalaiset menettävät kasvonsa jos ohjelmisto ei toimi odotetusti tai valmistu (kuten edellinenkin kohta, tämäkin saattaa aiheuttaa hankausta ryhmän sisällä) vastuualueet eivät ole riittävän selkeät 18

vastuu jakaantuu liian epätasaisesti ryhmäläisten kesken työmäärät jakaantuvat liian epätasaisesti ryhmäläisten kesken tiedonkulku ryhmän jäsenten välillä ei toimi (*) 7.1.4 Asiakkaaseen liittyvät riskit asiakas ei osaa ilmaista toiveitaan selkeästi (*) asiakas muuttaa mieltään projektin vaatimusanalyysin tekemisen jälkeen asiakkaan toiveet ymmärretään väärin asiakas ei ymmärrä että kaikkea ei voida toteuttaa (*) lopputuote ei vastaa asiakkaan toiveita 7.2 RISKIEN ENNAKOINTI 7.2.1 Tekniset riskit Riski Varmuuskopioinnin puute aiheuttaa tehdyn työn häviämisen. Todennäköisyys Mahdollinen. Vaikutus Ainakin osa työstä joudutaan tekemään uudelleen. Aikataulu viivästyy. Ennaltaehkäisy Jäsenet huolehtivat omilla koneillaan olevien tiedostojen varmuuskopioinnista. Yhteisessä hakemistossa olevat tiedostot varmistetaan kaksi kertaa viikossa. Toipuminen Etsitään tiedostojen viimeisimmät olemassa olevat versiot. Tehdään välttämättömät osat uudelleen. Jäsenet kantavat itse vastuun omien tiedostojensa riittävästä varmuuskopioinnista. Projektipäällikkö valvoo yhteisen hakemiston kopiointia. 7.2.2 Aikataulun riskit Riski Tehtävää ei rajata riittävästi. Todennäköisyys Mahdollinen. Vaikutus Projekti tursuaa yli varatun ajan tai ei valmistu. Ennaltaehkäisy Huolellinen määrittely. Pitäytyminen välttämättömimmissä ominaisuuksissa. Toipuminen Ryhmä palaa määrittelyvaiheeseen. Toteutettavaa osaa supistetaan. Projektipäällikkö seuraa tehdyn aikataulun toteutumista. Riski Todennäköisyys Vaikutus Ennaltaehkäisy Toipuminen Työmäärät arvioidaan liian pieniksi. Mahdollinen. Projekti ei etene suunnitellulla tavalla. Työ viivästyy tai ei valmistu. Suunniteltua aikataulua tarkkaillaan jatkuvasti. Aikataulua muutetaan ja päivitetään tarvittaessa. Jäsenten osaamisen tasot otetaan huomioon tehtäviä jaettaessa. Rajataan projektia pienemmäksi. Projektipäällikkö seuraa tehdyn aikataulun toteutumista. 19

Riski Todennäköisyys Vaikutus Ennaltaehkäisy Toipuminen Riski Todennäköisyys Vaikutus Ennaltaehkäisy Toipuminen Aikaa tuhrataan epäoleellisiin tehtäviin. Todennäköinen. Projekti ei etene suunnitellulla tavalla. Työ viivästyy. Kunkin vaiheen tavoitteet ja vaatimukset ovat kaikille ryhmän jäsenille selvät. Ei tavoitella täydellistä lopputulosta vaan hyväksytään kelvollinen tuotos. Tietoisesti vältetään ylidokumentointia ja ylimäärittelyä. Vältetään painottamasta niitä osa-alueita jotka ryhmäläiset hallitsevat hyvin ja kohdennetaan resursseja niihin osa-alueisiin joissa jäsenet eivät ole kokeneita. Tehtävien tärkeysjärjestys arvioidaan uudelleen. Tarvittaessa rimaa lasketaan tai toteutettavaa osaa supistetaan. Projektipäällikkö seuraa tehdyn aikataulun toteutumista. Ryhmäläisten osaamisen ja ammattitaidon erilaisuutta ei osata riittävästi ottaa huomioon. Mahdollinen. Projekti ei etene suunnitellulla tavalla. Työ viivästyy. Työ kasaantuu muutamille jäsenille. Jäsenten osaamista ei hyödynnetä, joten projektin tuotosten laatu kärsii. Ryhmän jäsenet kertovat avoimesti omista vahvuuksistaan ja heikkouksistaan. Tehtävät jaetaan siten että jäsenelle annetaan pieniä tehtäviä siltä alueelta jota hän haluaa kehittää, ja suuria tehtäviä siltä alueelta millä hän on hyvä. Tehtävät jaetaan uudella tavalla ryhmän jäsenten kesken. Projektipäällikkö seuraa tehdyn aikataulun toteutumista ja työnjaon tasapuolisuutta ja oikeudenmukaisuutta. 7.2.3 Organisaatioon, henkilöihin ja tiedonkulkuun liittyvät riskit Riski Ryhmän jäsen sairastuu. Todennäköisyys Todennäköinen. Vaikutus Työ viivästyy tai tulee joltain osin hutaisten hätäisesti tehdyksi. Ennaltaehkäisy Ryhmän jäsenet huolehtivat levon ja yöunen riittävyydestä. Työnjako on selkeästi tehty ja projektipäällikkö tietää mitä kenenkin pitäisi tehdä. Jäsenten tekemät tuotokset ovat koko ajan kaikkien saatavilla. Toipuminen Jaetaan sairastuneen jäsenen kriittiset työt muille. Vähennetään tuotteelle asetettuja vaatimuksia. Jäsen ilmoittaa sairastumisestaan projektipäällikölle ja ryhmälle. Projektipäällikkö huolehtii tehtävien uudesta jaosta. Riski Todennäköisyys Vaikutus Ennaltaehkäisy Ryhmän jäsen on matkoilla. Todennäköinen. Työt kasaantuvat ajallisesti epätasaisesti. Työ saattaa viivästyä. Ryhmän jäsen tiedottaa tulevasta matkastaan heti kun tietää 20

Toipuminen asiasta. Työnjaosta sovittaessa otetaan huomioon matkan aiheuttama poissaolo. Jäsenelle ei matkan ajaksi anneta sellaista tehtävää jota hän ei pysty tekemään, eikä sellaista tehtävää jonka tuloksista riippuu muiden jäsenten työn eteneminen. Jaetaan jäsenen tehtävät matkan ajaksi uudelleen. Jäsen ilmoittaa matkastaan projektipäällikölle ja ryhmälle. Projektipäällikkö huolehtii tehtävien uudesta jaosta. Riski Todennäköisyys Vaikutus Ennaltaehkäisy Toipuminen Ryhmän jäsen on kiireinen (työ, tentti ). Todennäköinen. Työt kasaantuvat ajallisesti epätasaisesti. Työ viivästyy tai tulee joltain osin hutaisten hätäisesti tehdyksi. Ryhmän jäsenten kiireet otetaan huomioon jo aikataulua suunnitellessa. Jäsen kertoo ryhmälle tulevista kiireistään kun tietää asiasta. Jäsen kertoo ryhmälle heti kun huomaa oman aikataulunsa mättävän. Jaetaan osa kiireisen jäsenen kriittisistä töistä muille. Vähennetään tuotteelle asetettuja vaatimuksia. Jäsen ilmoittaa aikataulunsa mättämisestä projektipäällikölle ja ryhmälle. Projektipäällikkö huolehtii tehtävien uudesta jaosta. Riski Todennäköisyys Vaikutus Ennaltaehkäisy Toipuminen Ryhmän jäsen keskeyttää kurssin. Epätodennäköinen. Projekti saattaa jäädä kokonaan toteutumatta. Työn jotkin osat jäävät tekemättä tai tulevat hutaisten tehdyiksi. Aikataulu pettää. Ryhmän jäsenet kannustavat toisiaan ja keskustelevat kiireestä, uupumuksesta ja kyllästymisestä avoimesti. Työ ja vastuu jaetaan mahdollisimman tasaisesti ryhmän jäsenten kesken. Jäsenten erilaiset osaamiset ja vahvuudet otetaan huomioon työnjakoa tehtäessä. Työnjako on selkeästi tehty ja projektipäällikkö tietää mitä kenenkin pitäisi tehdä Ryhmä arvioi projektin toteutumismahdollisuudet uudelleen. Projektia supistetaan ja aikataulu laaditaan uudelleen. Työnjako tehdään uudelleen uutta suunnitelmaa vastaavaksi. Jäsen ilmoittaa keskeyttämisestään ryhmälle ja projektipäällikölle. Jos jäsen ei saavu palaveriin tai ei tee sovittuja tehtäviä, projektipäällikkö ottaa yhteyttä jäseneen. Projektipäällikkö huolehtii että ryhmä arvioi projektin uudelleen. Riski Todennäköisyys Vaikutus Tiedonkulku ryhmän jäsenten välillä ei toimi. Mahdollinen / todennäköinen.. Kaikki mättää. 21

Ennaltaehkäisy Toipuminen Projektipäällikkö pitää huolen siitä että palavereissa kaikki jäsenet saavat suunvuoron. Kaikkien jäsenten mielipiteitä kysytään ja kuunnellaan. Asioista tiedotetaan sähköpostilla. Ryhmän www-sivuja pidetään ajantasalla. Rakentava keskustelu. Projektipäällikkö tarkkailee ryhmän kommunikointia. Jäsenet ottavat viestintäongelman esille heti kun huomaavat sellaisen. 7.2.4 Asiakkaaseen liittyvät riskit Riski Asiakas ei osaa ilmaista toiveitaan selkeästi. Todennäköisyys Mahdollinen. Vaikutus Määrittelyjä joudutaan muuttamaan kesken projektin, työ viivästyy. Ennaltaehkäisy Ryhmä perehtyy huolellisesti asuntosihteerin nykyiseen työhön. Asiakkaalle esitetään käli-hahmotelmia projektin määrittelyvaiheessa. Toipuminen Ryhmä palaa määrittelyvaiheeseen. Toteutettavaa osaa supistetaan vastaamaan uutta aikataulua. Riski Todennäköisyys Vaikutus Ennaltaehkäisy Toipuminen Asiakas ei ymmärrä että kaikkea ei voida toteuttaa. Mahdollinen. Projekti paisuu liikaa eikä valmistu varatussa ajassa. Asiakkaan kanssa pyritään sopimaan täsmällisesti toteutettavista osista. Asiakkaan keskenään ristiriitaisia toiveita selvitetään yhdessä asiakkaan kanssa. Määrittelyyn ei hyväksytä ristiriitaisia vaatimuksia. Ryhmä palaa määrittelyvaiheeseen, jos yhteisymmärrystä ei muuten löydy. Toteutettavaa osaa supistetaan vastaamaan uutta aikataulua. 22