T-76.115 Projektisuunnitelma ETL-työkalu ExtraTerrestriaLs Versio Päivämäärä Tekijä Kuvaus 0.1 20.10.2004 Timo Sallinen Ensimmäinen versio 1.0 22.10.2004 Timo Sallinen Korjauksia, lisätty 1.4 ja 5.3 1.1 26.10.2004 Mikko Ruokojoki Korjauksia 1.2 26.10.2004 Teemu Nousiainen 5.1, kommunikointi 1.3 27.10.2004 Mikko Ruokojokoi 5.1.3 & 5.3.1.4 Katselmointien muokkaus 1.4 27.10.2004 Teemu Nousiainen 5.3 täydennystä 1.5 27.10.2004 Teemu Nousiainen Katselmoinnissa löydetyt virheet 1.6 27.10.2004 Timo Sallinen 5.1.5 muutoksia. 1.7 28.10.2004 Teemu Nousiainen Kappaleasettelu oikeaksi 1.8 28.10.2004 Mikko Ruokojoki Asiakkaan topten päivitetty 2.0 28.10.2004 Teemu Nousiainen Dokumenttien yhdistely 2.1 1.11.2004 Mikko Ruokojoki 3. kappaletta päivitetty Sivu 1 / 24
Sisällysluettelo 1 Johdanto... 3 1.1 Projektin tarkoitus ja laajuus... 3 1.2 Järjestelmät ja ympäristö... 3 1.3 Oikeudet tuotteeseen... 3 1.4 Terminologia... 4 2 Projektin organisaatio... 5 2.1 Projektiryhmä... 5 2.2 Muut sidosryhmät...8 3 Tavoitteet... 8 3.1 Asiakkaan tavoitteet... 8 3.2 Ryhmän tavoitteet...9 3.3 Projektin keskeyttämisen kriteerit... 10 3.4 Projektin lopettamisen kriteerit... 10 4 Resurssit ja budjetti...11 4.1 Henkilöstö- ja aikaresurssit... 11 4.2 Laite- ja ohjelmistoresurssit...11 4.3 Budjetti... 12 5 Työskentelytavat ja työkalut... 13 5.1 Käytännöt...13 5.2 Ryhmän SEPA-aiheet...17 5.3 Laadunvarmistuksen suunnitelma... 18 5.4 Työvälineet... 20 5.5 Standardit...20 6 Vaiheistus...21 6.1 Aikataulu... 24 7 Riskiloki...24 8 Liitteet... 24 Sivu 2 / 24
1 Johdanto 1.1 Projektin tarkoitus ja laajuus Projektin tarkoitus on suunnitella ja toteuttaa ETL-työkalu Aureolis Oy:lle osana Teknillisen korkeakoulun Tietojenkäsittelyopin ohjelmatyö (T-76.115) kurssia. Projekti kestää koko lukuvuoden 2004-2005 ja sisältää neljä eri vaihetta, suunnittelun (PP), kaksi toteutuskierrosta (I1 ja I2) ja viimeistely/toimitusvaiheen (DE). Jokaisen vaiheen sisällä työt pilkotaan pienemmiksi, iteratiivisiksi prosesseiksi. Projektin aihe, ETL-työkalu, tulee sanoista Extract-Transform-Load. Kyseessä on tiedon poiminta, sen käsittely eri tavoin ja tiedon lataaminen tietovarastoon. Tietovarastoinnissa tarvitaan työkalua, jonka avulla tietoa voidaan muokata mahdollisimman automaattisesti erilaisin toimenpitein. Yleinen esimerkki on tiedon denormalisointi, jonka avulla helpotetaan tiedon jalostamisen ja raportoinnin tarpeita. Projekti vaatii laajaa tietämystä tietokannoista ja tietovarastoinnista. Työ toteutetaan seitsemän hengen opiskelijaryhmässä. Työmäärä on kiinnitetty 1400 työtuntiin. Projektiryhmän työtä ohjaa ja vetää ryhmän keskuudestaan valitsema projektipäällikkö. Hän on pääasiallinen vastuuhenkilö myös asiakkaan suuntaan projektin onnistumisesta. Teknillisen korkeakoulun puolelta työtä ohjaa mentor. Opiskelijoiden tarkoituksena on oppia laajan ohjelmistoprojektin läpikäymistä ja asiakasta kiinnostaa lopputuloksena syntyvä, omassa liiketoiminnassaan hyödyllinen ohjelmisto. Asiakkaan eli Aureoliksen puolelta työssä avustavat tekninen asiantuntija ja tekninen johtaja. 1.2 Järjestelmät ja ympäristö Ohjelmisto toteutetaan käyttöjärjestelmästä ja laitealustasta riippumattomaksi pääosin Java- ohjelmointikielellä. Taustalla olevia järjestelmiä ovat erilaiset tietovarastot ja operatiiviset tietokannat. Ohjelmisto on tarkoitettu lähinnä asiakkaan asiantuntijoiden käyttöön. Tulevaisuudessa on mahdollista, että käyttäjiä ovat myös Aureoliksen asiakkaat. Olennainen osa ohjelmistoa on kuvauskieli, jonka avulla voidaan kuvata ETL-työkalun sisältämiä prosesseja ja niiden suhteita toisiinsa. Prosesseista voidaan luoda verkkomainen kuvaus, jolloin eri aliprosessit voivat toimia rinnakkaisesti. Ohjelmistoon suunnitellaan useita rajapintoja, joiden tarkoituksena on käsitellä erimuotoista tietoa ja mahdollistaa prosesseihin liitettävien toimenpiteiden luonti: Erilaisten syötteiden käsittelyrajapinnat (eri tietokantatyypit, eri tiedostotyypit) Prosesseihin liitettävien toimenpiteiden rajapinta 1.3 Oikeudet tuotteeseen Tekijänoikeuksista on sovittu erillisellä sopimuksella, joka tulee olemaan lopullisen Sivu 3 / 24
projektisuunnitelman liitteenä. 1.4 Terminologia Suomeksi Englanniksi Selitys DW, tietovarasto DW, data warehouse Kohdetietokanta, johon tallennetaan kunkin ETLprosessin suorituksesta saatu lopputulos. Tietovarastoa ei juuri muokata (paitsi silloin kun suoritetaan ETL-prosessi), vaan siihen tehdään ainoastaan kyselyjä. ETL-prosessi (myös ETT tai ETM) ETL process Datan lukeminen lähdeaineistosta (extract), muokkaaminen (transformation) ja tallentaminen tietovarastoon (load / transportation / move) Osaprosessi, tehtävä Subprocess, task ETL-prosessiin kuuluva yksittäinen datan muokkaus-, kopiointi- tai muu toimenpide. Mentor Mentor Projektiryhmän tukihenkilö ja ohjaaja PP-vaihe Project Planning Projektin suunnitteluvaihe. Muita vaiheita esim. toteutusvaihe I ja toteutusvaihe II Iteraatio Iteration Tietyn pituinen aikajakso, jonka kuluessa ohjelmaa kehitetään eteenpäin suunnitelman mukaisesti. Syöte Tulos Toimenpide Operaatio Osaprosessin saama syöte, josta tulos muodostetaan. Osaprosessin syötteestä muodostama tulos. Ks. osaprosessi Toimenpide. Ks. osaprosessi Sivu 4 / 24
Kaavio 1- Projektin osapuolet ja organisaatio 2 Projektin organisaatio 2.1 Projektiryhmä Sivu 5 / 24
Nimi: Rooli / vastuu: Kiinnostuksen aiheet: Mikko Ruokojoki Projektipäällikkö, riskienhallinta - Oppia projektijohtamista ohjelmistoprojekteissa - Oppia toimimaan hyvänä asiakasrajapintana projektissa - Oppia projektin ajanseurantaa, toteutumisseurantaa - Tulla tutuksi projektihallinnan työkaluihin Puhelin: 0400 709 319 Sähköposti: mikko.ruokojoki(at)nomenal.fi Nimi: Rooli / vastuu: Kiinnostuksen aiheet: Risto Kunnas Testaus, dokumentointi - Tavoitteena tulla paremmaksi Javaohjelmoijaksi - Tavoitteena syventää tietämystä testauksesta Puhelin: 050 5893560 Sähköposti: Nimi: Rooli / vastuu: Kiinnostuksen aiheet: rkunnas(at)cc.hut.fi Mika Suvanto Riskienhallinta Tavoitteinani on ensisijaisesti saada kokemusta ohjelmistokehityksestä vähän suuremmassa ryhmässä, sillä aiemmin olen työskennellyt lähinnä 2-4 hengen ryhmissä. Tarkoitus olisi myöskin kerätä kokemusta hieman hallitummasta projektin läpiviennistä ja tässä hyödyllisistä käytännöistä ja työkaluista. Toki tavoitteisiin kuuluu kurssin läpäiseminen siihen varatuilla resursseilla ja lopputulos, joka tyydyttää koko ryhmää sekä asiakasta. Puhelin: 050 338 5345 Sähköposti: mika.suvanto(at)hut.fi Sivu 6 / 24
Nimi: Rooli / vastuut: Kiinnostuksen aiheet: Teemu Nousiainen Pääohjelmoija, testaus Tärkeimpänä oppimispäämääränä kurssilla on selkeän kokonaiskuvan saaminen ohjelmistoprojektista. Aikaisempi kokemukseni ohjelmistoprojektin läpiviemisestä on vähäistä, joten yritän saada mahdollisimman paljon käytännön kokemusta. Keskityn testaamisen suunnitteluun ja testauksen toteuttamiseen. Puhelin: 040 743 8174 Sähköposti: Nimi: Rooli / vastuut: Kiinnostuksen aiheet: tnousiai(at)cc.hut.fi Timo Sallinen Dokumentointi -Kokemuksen saaminen laajemmassa projektiryhmässä toimimisesta -Henkilökohtaisten ohjelmistokehitysmetodien kehittäminen ja kokonaiskuvan saaminen ohjelmistotuotannon formaaleista menetelmistä Puhelin: 040 701 8179 Sähköposti: timo.sallinen(at)hut.fi Nimi: Rooli / vastuut: Kiinnostuksen aiheet: Jani Malmi Vaatimusmäärittely, muutosten hallinta Tavoitteenani on oppia uusia asioita tiimityöskentelystä vähän isommassa ryhmässä. Harvinainen tilanne, että näin monta työskentelee saman ohjelmiston parissa. Haluna oppia myös uusia asioita ohjelmistotuotannosta sekä jotain uutta testauksesta ja erilaisista järjestelmistä. Haluna myös läpäistä kurssi ja tehdä hyvää työtä. Puhelin: 040 715 9214 Sähköposti: jani.malmi(at)tietoenator.fi Sivu 7 / 24
Nimi: Rooli / vastuut: Kiinnostuksen aiheet: Jani Honkanen Arkkitehtuuri, vaatimusmäärittely, muutosten hallinta. - kokemusta projektityöskentelystä - kokemusta oikean asiakkaan vaatimusten huomioinnista - kokemusta arkkitehtuurisuunnittelusta - kurssin läpäisy (pakollinen) - merkintä kurssista CV:hen Puhelin: 040 774 0220 Sähköposti: jmhonka2(at)cc.hut.fi 2.2 Muut sidosryhmät Asiakas: Arto Arffman, Tekninen johtaja / Aureolis Oy arto.arffman(at)aureolis.com puh. 040 8422 750 Markus Rautopuro, Tekninen asiantuntija/ Aureolis Oy markus.rautopuro(at)aureolis.com puh. 040 8422 751 Kurssihenkilökunta: Petri Saloma, Mentori psaloma(at)cc.hut.fi 3 Tavoitteet Tässä kappaleessa kuvaillaan projektin tavoitteita eri näkökulmista. Varsinaiset vaatimukset on kuvattu vaatimustenmäärittelydokumentissa. 3.1 Asiakkaan tavoitteet Alla olevassa listassa on kuvattu asiakkaan Top-10 tavoitteet projektista: 1. Toiminnoiltaan karsittu ETL-työkalu, jonka perusteella voimme päättää jatketaanko oman ETL-työkalun kehitystä Sivu 8 / 24
2. ETL-työkalun kuvauskieli, joka on laajennettavissa tarpeen mukaan 3. Riittävä operaatioiden rajapinta, jotta sitä voidaan käyttää myöhemmin toteutettavien operaatioiden toteuttamisee 4. Versio ETL-työkalusta, josta voidaan jatkojalostaa käyttökelpoinen kehittynyt versio (ohjelman perustukset tehty huolella) 5. ETL-työkalun moottori pystyy suorittamaan prosessin ja toimimaan virhetilanteissa määrittelyjen mukaisesti 6. ETL-työkalun prosessien dokumentointitoiminnosta prototyyppi-tasoinen versio 7. ETL-työkaluun liittyvien, uusien tekniikoiden testaus käytännössä 8. Tietovarastopuolen kehittäminen 9. Tarjota parempia palveluita asiakkaille 10.Asiakaskunnan kasvattaminen uuden työkalun avustuksella Muut tavoitteet Näiden lisäksi Aureolis asettaa hankkeelle kokonaisuudessaan seuraavia tavoitteita: 1. Oman ETL-työkalun järkevyyden arviointi 2. Kaupallisia työkaluja paremman välineistön kehittäminen. (ominaisuuksien painotus ETL:n kehittämisen näkökulmasta ja käytännössä havaittujen puutteiden "paikkaus") 3. Kannoista ja käyttöjärjestelmistä riippumattoman sekä hinnaltaan skaalautuvan välineen saaminen käyttöön 4. Uudet tekniikat ja menetelmät 5. Oma väline -> kontrolli hinnoitteluun -> järkevä hinnoittelumalli tuotteeseen integroitaessa tai myytäessä ratkaisuja pienille asiakkaille (lisäarvon myynti) 6. Kehittämisen ja ylläpidon kustannustehokkuuden parantaminen 7. Kehityksen nopeuttaminen 8. Ratkaisujen uudelleenkäytettävyyden helpottaminen 9. Riippuvuuden vähentäminen välinetoimittajista 10.Yrityskuvan muuttaminen/parantaminen (välineen ja projektiryhmän kautta) 3.2 Ryhmän tavoitteet Projektiryhmän tavoitteita ovat: 1. Kehittää jatkokehityskelpoinen tietovarastointijärjestelmän runko. 2. Oppia työskentelemään ja kehittää taitojaan ohjelmistoprojektissa. Sivu 9 / 24
3. Oppia toimimaan osana ohjelmistokehitysryhmää ja kehittää omaa tietotaitoa asian tiimoilta 3.3 Projektin keskeyttämisen kriteerit Riippuen ongelmien vakavuudesta, on mahdollista, että projekti joudutaan keskeyttämään ennen sen loppumista. Tällaisia riskejä on kuvattu erikseen riskienhallinnan dokumentissa ja ne ovat luokiteltu kriittisiksi. Näitä ovat esimerkiksi tilanne, jossa useampi ryhmän jäsen joutuu jättämään projektin kesken. Tällöin on syytä harkita projektin keskeyttämistä. Kriiteerit keskeyttämiselle ovat seuraavat: Muutoksista johtuva töiden lisäys tulee ylivoimaiseksi nykyisille ryhmän jäsenille toteuttaa kurssin antamassa aikataulussa Asiakkaan puolelta tullut pyyntö lopettaa kehitystyöt Projektin keskeyttämisestä keskustellaan yhdessä asiakkaan, mentorin ja ryhmän jäsenten kesken ja sovitaan asiaan liittyvistä tehtävistä. Voidaan kuitenkin todeta, että projektin keskeyttäminen ei ole tarkoitus ja syiden pitää olla painavia, jotta kyseistä toimenpidettä tehdään. 3.4 Projektin lopettamisen kriteerit Projektin lopettamisen kriteerit määritellään, jotta voidaan todeta milloin projekti on syytä lopettaa. Projektille kurssi määrittelee aikarajat, jonka sisällä projektin toteutus pitää tehdä. Sitä ei kuitenkaan ole estetty, etteikö kehitystyö voisi jatkua seuraavassa projektissa, asiakkaan järjestelmänä. Projekti loppuu jos jokin seuraavista toteutuu: Kurssin määrittelemät aikarajat toteutukselle umpeutuvat Sovitut tavoitteet asiakkaan, ryhmän ja kurssin puolelta ovat saavutettu Projektin lopettaminen hyväksytään kurssin ja asiakkaan puolelta. Tällöin keskustelua käydään tavoitteiden onnistumisesta ja tuloksien sisällöstä. Sivu 10 / 24
4 Resurssit ja budjetti 4.1 Henkilöstö- ja aikaresurssit Kurssin laajuudeksi on määritelty 5 opintoviikkoa, joka vastaa noin 200h työtä per opiskelija. Ryhmässämme on 7 henkilöä, jolloin yhteinen työmäärä on 1400 miestyötuntia. Alla on määritelty tarkemmin jokaisen henkilön arvio työtunneista ja niiden jakautumisesta projektin aikana. Vaihe Mikko Jani H Jani M Risto Mika Teemu Timo PP 60 55 50 50 45 45 50 360 I1 50 50 55 45 50 50 50 350 I2 40 40 40 45 45 50 40 300 DE 40 45 45 50 50 45 50 320 190 190 190 190 190 190 190 1330 Työmääräarviot jäsenten kesken Työtunneista on laskettu yhteensä 190 tuntia, koska kurssin puolelta on arvioitu SEPAaiheiden työstämiseen kuluvan erikseen 10h/henkilö. Työmäärät perustuvat ryhmän jäsenien eri vastuualueisiin ja heidän henkilökohtaisiin toiveisiinsa. Alla on määritelty tarkemmin painotuksien syitä. Henkilö Mikko Jani H Jani M Risto Mika Teemu Timo Työmäärien painotuksien syyt Projektipäällikön työt vaikuttavat paljon työmääriin. Projektin käynnistäminen, suunnitelmien teko ja rutiinien hiominen työllistävät alkuvaiheessa enemmän. Vastuualueena arkkitehtuuri, painotusta alkupuolelle. Varamiehenä vaatimusmäärittelyissä. Vastuualueena vaatimusmäärittelyt, painotus alkupuolelle. Varamiehen arkkitehtuurissa. Vastuualueena testaus ja laadunvalvonta, painotusta toteutusvaiheisiin. Varamiehenä dokumentoinnissa. Vastuualueena riskienhallinta, painotusta alkupuolelle ja toteutusvaiheisiin. Pääohjelmoija ja panostusta työkalujen ylläpitoon ja toteutukseen, varamiehenä testauksessa ja laadunvalvonnassa. Vastuualueena dokumentointi, painotusta loppupuolelle. 4.2 Laite- ja ohjelmistoresurssit Työn toteutuksessa ryhmän jäsenet käyttävät omia kotitietokoneitaan ja tarvittaessa Teknillisen korkeakoulun tarjoamia tietokoneluokkia. Ohjelmistoresurssit ovat kaikki Sivu 11 / 24
saatavilla ilman maksullisia lisenssejä. Mikäli tarvetta maksullisille ohjelmistoille ilmenee, asiasta sovitaan asiakkaan kanssa 4.3 Budjetti Projektin ollessa opiskelutyö, ei työtunteja laskuteta asiakkaalta. Mielenkiinnon vuoksi kuitenkin oheisena on laskettu arvio projektin toteuttamisesta todellisuutta lähellä olevilla hinnoilla. Kyseisessä tilanteessa ohjelmiston toteutus tilattaisiin yritykseltä, joka toteuttaisi työn tuntilaskutuksen perusteella. Näin tilauksen tehneen yrityksen ei tarvitse huolehtia työntekijöiden työkaluista tai työtiloista. Arvio perustuu olettamuksiin, että tuntilaskutushinnat eri osaamistasoille ovat seuraavat: Titteli Hinta/tunti Projektipäällikkö 90 Vanhempi suunnittelija/ohjelmoija 55 Suunnittelija/ohjelmoija 45 Jonka perusteella asiakkaan hinta koko projektille olisi seuraava: Titteli Hlömäärä Tunnit Yhteensä Projektipäällikkö 1 190 h 17 100 Vanhempi suunnittelija/ohjelmoija 4 760 h 41 800 Suunnittelija/ohjelmoija 2 380 h 17 100 Yhteensä 7 1330 h 76 000 Projektin toteuttavan yrityksen sisäinen laskutus perustuisi seuraaviin palkkoihin: 1330 h = 177,3 htp / 7 työntekijällä = 25,3 työpäivää / henkilö. Keskimäärin kuitenkin voidaan olettaa, että tehokasta työaikaa 7,5 tunnsita on noin 5,5 tuntia, jolloin työpäivien määräksi tulee 34,5. Tämä taas vastaa noin 1,5 kuukauden työtä. Palkkaus on kuukausitasolla: Titteli Palkka/kk Todelliset kustannukset yritykselle (~=palkka * 1.5) Projektipäällikkö 4200 6300 Vanhempi suunnittelija/ohjelmoija 3800 5700 Suunnittelija/ohjelmoija 2900 4350 Joista laskemalla saadaan 1,5 kuukauden palkkamenoiksi 24 525. Tämän lisäksi pitää laskea laitehankinnat työntekijöille, työtilojen vuokrat ja mahdolliset muut henkilöstöetujen maksut. Laskukaava on hieman optimistinen, sillä siinä ei huomioida työntekijöihin liittyviä riskejä, taustatyötä tekevien ihmisten palkkoja jne. Perimmäinen tarkoitus, eli budjetoinnin havainnollistaminen kuitenkin selviää yllä olevista laskelmista. Sivu 12 / 24
5 Työskentelytavat ja työkalut Projektiryhmä on sopinut työskentelytavoista projektin alussa. Ne sisältävät mm. kokous-, kommunikaatio-, koodaus- ja testauskäytännöt. Yhteisesti sovittujen tapojen tarkoituksena on helpottaa ryhmätyöskentelyä ja madaltaa käytännön esteitä kommunikoinnille, suunnittelulle ja kehitystyölle. 5.1 Käytännöt Palaverit Projektiryhmän työskentelytapoihin kuuluvat viikottaiset palaverit, joita varten projektipäällikkö tekee agendan. Palaverissa sihteeriksi valittu tekee kokousmuistion, joka julkaistaan agendan kanssa projektin kotisivulla. Koko ryhmää koskevat palaverit järjestetään pääsääntöisesti torstaisin, sillä tämä päivä todettiin parhaiten sopivaksi. Tämän lisäksi eri vastuualueiden pienemmät ryhmät pitävät tarvittaessa omia tapaamisia. Asiakkaan kanssa ollaan yhteyksissä vähintään viikottain (viikkoraportti, ks. 5.1.3). Kommunikointi Projektiryhmällä on kotisivut osoitteessa http://www.hut.fi/~tnousiai/t-76.115/. Sivuilla julkaistaan: Kokousmuistiot Viikkoraportit Työtehtävälistat Kurssin palautukset Tapaamisten kalvot Kotisivujen päivittämisestä vastaa Teemu. Projektiryhmän uutispalvelin toimii tietopankkina ja ryhmän sisäisenä dokumenttien levityskanavana sekä keskusteluvälineenä. Ryhmällä on käytössään myös web-pohjainen kalenteri, johon kirjataan ryhmää koskevat aikataulut ja tapaamiset. Ryhmällä on käytössään Internet News-palvelin (snntpd, progress.tky.hut.fi), jota käytetään SSH-tunnelin yli tietoturvan takaamiseksi. Se on ryhmän pääasiallinen keskustelukanava ja sinne lähetetään myös uusimmat aineistot ja keskustellaan tilanteesta. Keskustelun ahkeruutta kuvaa se, että uutisryhmään on 26.10.2004 mennessä tullut 130 viestiä. Muita kommunikointitapoja ovat sähköposti ja MSN Messenger. Sähköpostia käytetään vain kiireelliseen ja henkilökohtaiseen kommunikointiin. Tällä pyritään välttämään sähköpostitulvaa ja sitä, että tärkeä viesti jäisi huomaamatta. 5.1.1 Iteratiivinen kehitystyö Työn pilkkominen riittävän pieniksi tehtäviksi ja kehitysvaiheiden iterointi on tärkeää suuren kokonaisuuden hallitsemiseksi. Iterointia toteutetaan erityisesti jokaisen vaiheen Sivu 13 / 24
alussa läpikäymällä sovitut tehtävät vaiheelle ja pilkkomalla ne pieniksi kokonaisuuksiksi viikottain. Tehtävän sopiva koko arvioidaan niin, että sen voi tehdä yksi henkilö alle viikossa (kurssin työviikkona, n. 10 h). Laadun takaamiseksi työn tuloksia katselmoidaan ryhmissä ja laaditaan tärkeille kokonaisuuksille useita iterointikierroksia. 5.1.1.1 Neuvottelut asiakkaan kanssa Projekti sisältää neljä eri vaihetta ja jokaisen vaiheen jälkeen on syytä keskustella asiakkaan kanssa edellisen vaiheen tuloksista. Samoin tutkitaan, mitä uutta seuraavassa vaiheessa pitää ottaa huomioon: Mietteet edellisestä vaiheesta ja mahdolliset parannus/muutosehdotukset Vaatimusmäärittelyiden paikkaansapitävyys ja mahdolliset korjaukset Riskienhallinnan tilanne ja mahdolliset uudet riskit Mahdollisuuksien kartoitus ja niiden kirjaaminen (positiiviset riskit) Asiakkaan kanssa keskustelu asiasta tehdään jo osittain palautetilaisuudessa, joka on pakollinen kurssin puolelta. Tämän lisäksi on hyvä pitää erillinen kokous, jossa voidaan keskustella lisää yllä olevista aiheista. 5.1.1.2 Vaatimusmäärittelyn hallinta Vaatimusmäärittelyn luonti tehdään kolmella viikon kestävällä iterointikierroksella PPvaiheessa. Tämä jälkeen vaatimusmäärittelyä käydään läpi vaiheiden alussa ja keskustellaan muutoksista asiakkaan kanssa. Kaikki muutokset sovitaan kirjallisesti ja niiden aiheuttamat lisätyöt/poistot arvioidaan. Vaatimushallintaa hoitaa vastuuhenkilönä Jani M. 5.1.1.3 Arkkitehtuurin hallinta Ohjelmistoarkkitehtuurin määrittely luodaan pääosin I1-vaiheessa, mutta sitä ylläpidetään jatkuvasti toteutusvaiheiden aikana. Muutoksien vaikutukset selvitetään ennen muutoksia ja kaikista oleellisista muutoksista neuvotellaan asiakkaan kanssa ensin. Vastuuhenkilönä arkkitehtuurissa on Jani H. Muutostenhallinta tullaan suorittamaan formaalisti. 5.1.1.4 Testauksen hallinta Testaussuunnitelmat tehdään alustavasti PP-vaiheessa, mutta varsinainen tarkempi suunnittelu toteutetaan toteutusvaiheissa. Testaukselle on määritelty oma vastuuhenkilö (Risto), joka pitää kirjaa tilanteesta ja ilmoittaa projektipäällikölle ja riskienhallinnasta vastaavalle mahdollisista ongelmista. Testaus on hyvin tärkeässä osassa, sillä työkalun toimintaan pitää ehdottomasti pystyä luottamaan. Sivu 14 / 24
5.1.2 Iteraatiovaiheiden suunnittelu Vaiheiden tarkempi suunnittelu tehdään aina ennen vaiheen alkua. PP-vaiheessa kuitenkin luodaan alustavat pohjat kaikelle toiminnalle projektin aikana. Suunnittelu tehdään asiakkaan ja ryhmän yhteisten sopimusten pohjalta kussakin tilanteessa. 5.1.3 Ajankäytön raportointi ja tehtävien jako Ajankäytön raportointiin ryhmä käyttää kurssin puolelta annettua Trapoli -järjestelmää. Projektipäällikkö tekee asiakkaalle ja mentorille viikoittain viikkoraportin, jossa käydään läpi edellisen viikon tehdyt työt ja työmäärät. Samoin arvioidaan tulevan viikon ohjelmaa ja työmääriä. Vaiheiden lopuksi arvioidaan työmäärien toteutuminen verrattuna suunnitelmiin. Työtehtävien jako on pääasiallisesti projektipäällikön vastuulla. Ryhmällä on viikoittaiset palaverit, joiden yhteydessä läpikäydään viikon aikana tehdyt työt. Samalla jaetaan uusia työtehtäviä seuraavalle viikolle. Projektin eri aihealueet ovat vastuutettu ryhmän jäsenille. Näiden kyseisten vastuualueiden tehtäväjakoa tekee myös kyseessä oleva vastuuhenkilö. Viikoittain ylläpidetään työtehtävälistaa, josta kukin ryhmän jäsen näkee hänelle tarkoitetut työt ja niiden tarkat määräajat. Jos suunnitelmiin tulee muutoksia, niin projektipäällikkö tai aihealueen vastuuhenkilö siirtää tarvittaessa työtehtävän toiselle henkilölle. 5.1.4 Virheiden seuranta Virheistä pidetään kirjaa asiakkaan järjestämällä JIRA-sovelluksella. Virhetietokantaan on pääsy sekä projektiryhmän jäsenillä että asiakkaalla. Virheen kirjaaminen on aina virheen löytäjän vastuulla. Mikäli virhe löytyy smoke test -testauksella tai automaattisella testauksella ja virhe pystytään saman tien korjaamaan, sitä ei kuitenkaan merkitä tietokantaan. 5.1.5 Dokumentointi Kaikki dokumentaatio tuotetaan doc- ja sxw-formaatissa yhteensopivuusongelmien välttämiseksi. Dokumentteihin luodaan yhtenäinen tyylipohja, joilla ulkoasu saadaan yhtenäiseksi. Jokaisella dokumentilla on vastuuhenkilö, joka vastaa lopullisen dokumentin tuottamisesta. Kaikki tuotettu dokumentaatio käydään läpi katselmusmenettelyllä. Dokumentti Projektisuunnitelma Riskienhallintadokumentti Vaatimusmäärittely Tekninen spesifikaatio Testaussuunnitelma Testausraportti Vastuuhenkilö Timo Mika Jani Malmi Jani Honkanen Risto Risto Sivu 15 / 24
Käyttöohjeet Loppuraportti Jani Honkanen Mikko 5.1.6 Projektin katselmoinnit Katselmointeja toteutetaan ryhmän sisällä aina ennen dokumenttien iteraatiokierroksen loppua. Katselmoinneille on määritelty vastuuhenkilö, joka vastaa materiaalien keruusta ja muiden ryhmän jäsenten informoinnista tilaisuudesta. Katselmoinnit toteutetaan noin 2-3 hengen ryhmissä. Dokumentti on kaikkien luettavissa noin pari tuntia ennen katselmointia ja tarkoitus on, että katselmointiin osallistuvat henkilöt ovat tutustuneet dokumenttiin jo ennen katselmointia. Dokumentti luetaan läpi yhdessä ja yksi henkilö kirjaa kommentit ylös. Näiden kommenttien pohjalta joko projektipäällikkö tai dokumentista vastaava jakaa töitä muille ryhmän jäsenille. Katselmoinneista yhdessä asiakkaan kanssa projektipäällikkö toimii asiakkaan suuntaan yhteyshenkilönä, joka informoi asiakasta katselmointien ja kokouksien agendasta. Tarkempi kuvaus katselmoinnin formaalista toiminnasta löytyy kappaleesta 5.3.1.4. 5.1.7 Vaatimustenhallinta Pyrimme keskustelemaan projektin eri vaiheessa vaatimuksista asiakkaan kanssa niin paljon kuin tarpeellista, jotta saamme todelliset vaatimukset tuotua esille. Asiakkaan kanssa kommunikoi vaatimuksista kolmen hengen ryhmä: Jani Honkanen, Mikko Ruokojoki ja Jani Malmi. Tarvittaessa myös muut voivat osallistua näihin tapaamisiin. Pyrimme analysoimaan ja validoimaan vaatimukset myös useamman henkilön avulla, mutta päävastuussa tästä ja vaatimusten hallinnasta on Jani Malmi. Luokittelemme vaatimukset kurssin suosittamalla tavalla seuraavasti: toiminnalliset vaatimukset ei-toiminnalliset vaatimukset rajoitteet käyttäjävaatimukset (käyttötapaukset). Muutenkin noudatamme kurssin vaatimustenmäärittelyn suosituksia ja ainoastaan tiettyjen taulukoiden rakenteen kohdalla olemme tehneet omia valintojamme. Tulemme päivittämään viikottain vaatimustenmäärittelydokumenttia sen vaatimusten statusten suhteen. Samoin tarkkailemme vaatimusten muutoksia viikottain. Mikäli asiakas haluaa lisätä jonkun uuden vaatimuksen, tulemme tarkastelemaan asiaa vähintään kolmen hengen ryhmässä ja miettimään uuden vaatimuksen aiheuttamaa työmäärän lisäystä. Muutokset vaatimuksiin hyväksytään niiden ollessa järkeviä ja mahdollisia projektin kannalta. Muuten ne hylätään. Mikäli koemme omalta osaltamme tarpeelliseksi muuttaa vaatimuksia, tulemme keskustelemaan niistä asiakkaan kanssa hyvissä ajoin. Sivu 16 / 24
5.1.8 Versionhallinta Versionhallintaan käytetään CVS:ää. Sääntönä on, että vain kääntyvää koodia saa viedä kantaan. Muutoslokiin tulee aina kirjata tehdyt muutokset tiiviisti, mutta mahdollisimman kuvaavasti. Jokainen iteraatiopalautus leimataan leimalla muotoa: ITER_X_Y, jossa X on iteraation numero ja Y iteraation sisäinen juokseva numero. Leimaamisen ja muut CVS:ään liittyvät suuremmat operaatiot hoitaa keskitetysti Pääohjelmoija (Teemu). 5.1.9 Ohjelmointikäytännöt Käytämme Sun Microsystemsin virallisia koodikäytäntöjä (ks. http://java.sun.com/docs/codeconv/html/codeconvtoc.doc.html). Suurin osa kehitystyöstä tehdään Eclipse IDE:llä, johon on määritelty Sunin koodikäytännöt. Hyödynnämme sen automaattisia koodin generointi- ja muotoiluominaisuuksia. 5.1.10 Riskienhallinta Riskienhallinnasta on erillinen dokumentti, joka on tämän projektisuunnitelman liitteenä. 5.1.11 Vertaistestaus Vertaistestauksen järjestämisestä sovitaan yhdessä asiakkaan ja vertaisryhmän kanssa. Vertaisryhmän testauksesta saadaan eniten irti, jos vertaisryhmä keskittyy destruktiiviseen testaukseen. Yleisesti ottaen negatiivisia testitapauksia on helpompi keksiä, jos ei tunne järjestelmää kovin hyvin. Vertaisryhmän tekemistä testeistä kerätään talteen syötteet ja tulosteet, jotta voidaan jälkeenpäin analysoida mitä testattiin. Monimutkaisessa prosessissa ei ole aina itsestään selvää, oliko ohjelman toiminta virheellistä vai ei. 5.2 Ryhmän SEPA-aiheet SEPA (Software Engineering Practice Assignment) on jaettu ryhmän kesken seuraavasti: Työmäärät / vaihe Pari Vastuuhlö SEPA-aihe PP I1 I2 DE Jani H & Mika Jani H Design patterns 60% 40% Jani M & Teemu Teemu Test automation on system test level 20% 40% 40% Risto & Timo Timo Static Methods 20% 60% 20% Mikko Mikko Progress tracking and control 30% 25% 20% 25% SEPA-päiväkirja kuuluu kurssin vaatimuksiin. Sivu 17 / 24
5.3 Laadunvarmistuksen suunnitelma 5.3.1 Projektin laadunvalvonta 5.3.1.1 Testaus 5.3.1.1.1 Testaustasot Projektissa pyritään käymään läpi kaikki ns. V-mallin mukaiset tasot. Projektissa varaudutaan kuitenkin alusta lähtien siihen, että annetussa ajassa ei välttämättä ehditä toteuttaa kaikkia vaatimuksia, jolloin ylempiä tasoja ei ehditä kokonaisuudessaan testata. 5.3.1.1.2 Testaustekniikat Todennäköisimmät ja samalla kriittisimmät virheet löytyvät järjestelmän toiminnallisuudesta. Pääpaino testauksessa on vaatimusmääritelmän kriittisiksi merkityissä ominaisuuksia. Funktionaalinen testaus pyritään suorittamaan automaattisesti. Automatisoitua testausta hyödynnetään yksikkötestauksen lisäksi järjestelmätestaustasolla. Kuvauskielen osalta tehdään kevyt käytettävyystestaus. Mikäli projektin puitteissa ehditään toteuttaa käyttöliittymä, suoritetaan ensimmäisten käyttöliittymäluonnosten jälkeen käytettävyystestaus prototyypin avulla. Kuormitustestausta ei tämän projektin puitteissa tehdä. 5.3.1.1.3 Testauksen raportointi Testien suorittaminen kirjataan lokiin. Testilokilla varmennetaan asiakkaalle se, että testausta on suoritettu. Löydetyt virheet raportoidaan JIRA-tietokantaan. Sivu 18 / 24
Korjaamattomien virheiden määrää käytetään arvioitaessa projektin etenemistä. Jos avoinna olevia virheitä on runsaasti, joudutaan niiden korjaamiseen varaamaan lisää aikaa. 5.3.1.1.4 Testitapaukset Testauksessa pyritään käyttämään automaattista testausta, mikäli se on mahdollista. Toimenpide-moduulien testausta varten luodaan erilaisia syötteitä sekä niitä vastaavia tuloksia. Erityisesti testataan myös ns. negatiiviset testitapaukset. Testauksessa käytetään ns. regressiotestausta, eli jo kertaalleen hyväksytysti tapahtuneet testiajot ajetaan virheen korjaamisen jälkeen uudestaan. Integraatiotestauksesta eteenpäin suoritetaan testaus pääosin kuvauskieli-skriptien avulla. Vertailutulos saadaan monimutkaisissa tapauksissa ulos vastaavista järjestelmistä. Skriptien avulla suoritetaan myös ns. regressio-testaus. Muita toimintoja varten luodaan sanallisesti kuvatut testitapaukset Excel-taulukko muotoon. 5.3.1.2 Katselmoinnit Tärkeimmät dokumentit käydään läpi formaalisti katselmointimenetelmällä. Tärkeimmät dokumentit ovat iteraatiosuunnitelmat sekä arkkitehtuurin ja rajapintojen määrittely. Lisäksi arkkitehtuurisuunnitelman jälkeen voidaan arvioida, mikäli jokin moduuli tarvitsee ei-funktionaalista testausta. Katselmointiin osallistuu 3-4 henkilöä. Katselmoitava dokumentti on jokaisella katselmointiin osallistuvalla henkilöllä luettavissa vähintään 2 tuntia ennen katselmointitilaisuutta. Katselmointitilaisuudessa on läsnä puheenjohtaja, sihteeri sekä varsinaiset katselmoijat. Katselmoitavan dokumentin vastuuhenkilöt eivät saa johtaa puhetta. Mikäli dokumentti on laaja, on syytä katselmoida dokumentti eri osissa. Dokumentti käydään läpi kappale kerrallaan, ja puheenjohtaja esittelee lyhyesti käsiteltävän kappaleen sisällön. Mikäli dokumentti noudattaa jotain standardia, esittelee puheenjohtaja myös lyhyesti standardin vaatimukset käsiteltävälle luvulle. Tämän jälkeen kukin osallistuja huomauttaa kappaleessa olevista virheistä puheenjohtajan annettua puheenvuoron. Sihteeri merkitsee kirjoitusvirheet ja epäselvät lauserakenteet alleviivauksilla paperiseen dokumenttiin, muut huomautukset, ehdotukset ja kritiikki kirjataan virhetietokantaan kuten minkä tahansa muukin virhe. Virheiden korjaamisesta ei käydä keskustelua, mutta puheenjohtaja voi harkintansa mukaan sallia lyhyiden ratkaisuehdotusten esittämisen. Tämä ei kuitenkaan saa viedä liikaa aikaa varsinaiselta tarkoitukselta, eli virheiden löytämiseltä. Katselmointeihin osallistuu mahdollisuuksien mukaan myös asiakkaan edustaja. 5.3.1.3 Iterointien laadunvalvonta Jokaisen iteraation alussa määritellään iteraation tavoitteet. Laadunvalvonnan tarkoituksena on tarjota käytännöt tavoitteiden toteutumisen arvioimiseksi. Kunkin Sivu 19 / 24
iteraation tavoitteet määritellään selkeästi ja yksiselitteisesti ennen toteutusta. Laadun mittarina käytetään korjattujen virheiden suhdetta löydettyihin virheisiin. 5.3.2 Iteraatiotason aiheet Iteraatiokohtaiset suunnitelmat tarkentuvat projektin edetessä. Iteraatio I1: Testauksessa keskitytään kuvauskielen käytettävyystestaukseen, koska sen laatu vaikuttaa hyvin voimakkaasti koko projektin onnistumiseen. Varsinaista koodia on vielä vähän, joten testauksessa suunnitelman ja arkkitehtuurin katselmointi saavat merkittävämmän osan. Automaattista testausta otetaan käyttöön. Järjestelmän osien yhteensopivuuden varmistamiseksi otetaan käyttöön smoke-testit. Myös näiden automatisointiin panostetaan. Iteraatio I2: Projektissa keskitytään uusien ominaisuuksien toteuttamiseen. Testauksen on määrä olla rutiininomaista ja hyvin automatisoitua. Järjestelmän moduulien määrä kasvaa suuresti, joten smoke-testaus ja regressiotestaus ovat tärkeitä. Iteraatio DE: Uusia ominaisuuksia ei enää toteuteta juurikaan, ja ohjelmiston dokumentointi, testaus ja laadunvarmistus saavat suuremman osan. 5.4 Työvälineet Käytettävät kehitystyökalut Ohjelmointi: Eclipse 3.0, Java SDK 1.4 Kaavioiden suunnittelu: MS Visio, Poseidon (tarvittaessa) Versionhallinta: Concurrent Versions System (CVS), eri client-versioita ja implementaatioita, WinCVS Virhetietokanta: Atlassian JIRA 5.5 Standardit Projektissa käytämme seuraavia standardeja: J2EE (Java 2 Enterprise Edition) XML (Extensible Markup Language) UML (Unified Modeling Language) Sivu 20 / 24
HTML (HyperText Markup Language) Sunin Code Conventions for the Java Programming Language Jyrki Kontion kehittämä RiskIt-mentelmä (Riskienhallinnan osalta osittain) 6 Vaiheistus Vaihe 1 projektin suunnittelu (PP) Tavoitteet Projektin suunnittelu Asiakkaaseen tutustuminen Asiakkaan tarpeisiin tutustuminen Aiheeseen tutustuminen (ETL) Ryhmän jäsenten tutustuminen toisiinsa Työtavoista ja työkaluista sopiminen Ohjelmiston arkkitehtuurin suunnittelu Ohjelmiston rajapintojen suunnittelu Kommunikointi asiakkaan, mentorin ja ryhmän välillä Kommunikointi ryhmän sisällä Käyttötapauksien määrittely Vaatimusmäärittelyt Riskienhallinnan arviointi ja sovitut tavat seurata riskien kehitystä SEPA aiheiden valinta pareittain Toimitettava aineisto Projektisuunnitelma Vaatimusmäärittely Riskienhallinta Kokouspöytäkirjat ja viikoittaiset tilanneraportit Edistymisraportti (kalvoina) SEPA-päiväkirjat Sivu 21 / 24
Vaihe 2 Toteutus 1 (I1) Tavoitteet Työtapojen ja työajan optimointi o o o Kokouksien vähentäminen Kokouksien osallistujajoukon vähentäminen Kommunikoinnin parantaminen Jatkaa arkkitehtuurista suunnittelua Aloittaa tekninen määrittely Aloittaa ohjelman toteuttaminen Toimitettava aineisto Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Tekninen spesifikaatio Testaussuunnitelma o o Testausraportti Testatut toiminnot Edistymisraportti Päivitetyt SEPA-päiväkirjat Näiden lisäksi asiakkaalle toimitetaan ensimmäinen versio ohjelmasta sisältäen tärkeimpiä perustoimintoja. Tarkempi suunnitelma I1 vaiheen sisällöstä ja iteraatiosta tehdään PP vaiheen lopussa. Vaihe 3 Toteutus 2 (I2) Tässä vaiheessa on tarkoitus edetä ohjelman toteuttamisessa seuraaviksi tärkeimpiin käyttötilanteisiin ja toteuttaa ne. Käyttöohjeiden laadinta aloitetaan ja arvioidaan nykytilanne vaatimusmäärittelyn ja toteutuneiden työaikojen tiedot. Tarkempi tämän vaiheen suunnittelu tehdään I1 vaiheen lopulla. Toimitettava aineisto Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen spesifikaatio Sivu 22 / 24
Päivitetty testaussuunnitelma o o Testausraportti Testatut toiminnot Edistymisraportti Päivitetyt SEPA-päiväkirjat Käyttöohjeiden esiversio Näiden lisäksi asiakkaalle toimitetaan toinen versio ohjelmasta sisältäen uusia ominaisuuksia. Vaihe 4 Viimeistely/toimitus (DE) Tässä vaiheessa vertaisryhmän testituloksien mukaan korjataan ohjelmassa mahdollisesti esiin tulleet viat ja ongelmat. Viimeistellään käyttöohjeet, luodaan loppuraportti ja valmistellaan tuotteen toimitus asiakkaalle. Tarkempi vaiheen suunnittelu tehdään I2- vaiheen lopulla. Toimitettava aineisto Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen spesifikaatio Päivitetty testaussuunnitelma o o Testausraportti Testatut toiminnot Edistymisraportti Päivitetyt SEPA-päiväkirjat Käyttöohjeiden lopullinen versio Loppuraportti Vertaistestauksen suunnitelma Vertaistestauksen tulosraportit Sivu 23 / 24
6.1 Aikataulu Päivämäärä Iteraatio / tapahtuma 23.9.2004-2.11.2004 (noin 5 viikkoa) Vaihe 1 - Suunnittelu ja projektisuunnitelma 11.10.2004-28.10.2004 (17 päivää) Vaatimusmäärittelyn luonti 3 iteraatiokierroksella 11.10.2004-28.10.2004 (17 päivää) Projektisuunnitelman luonti 3 iteraatiokierroksella 14.10.2004-28.10.2004 (14 päivää) Riskienhallinnan luonti 2 iteraatiokierroksella 14.10.2004-28.10.2004 (14 päivää) Laatukäsikirjan luonti 2 iteraatiokierroksella 22.10.2004 Asiakkaalle ensimmäiset versiot projektisuunnitelmasta ja vaatimusmäärittelystä 28.10.2004 Asiakkaalle toiset versiot dokumenteista 2.11.2004 Vaiheen 1 aineiston palautuspäivämäärä 5.11.2004-2.12.2004 (noin 4 viikkoa) Vaihe 2 - Toteutuskierros 1 30.11.2004 Vaiheen 2 iterointisuunnitelman palautus 30.11.2004 Vaiheen 2 aineiston palautuspäivämäärä 7.1.2005-10.2.2005 (noin 5 viikkoa) Vaihe 3 - Toteutuskierros 2 11.1.2005 Vaiheen 3 iterointisuunnitelman palautus 8.2.2005 Vaiheen 3 aineiston palautuspäivämäärä 11.2.2005-17.3.2005 (noin 5 viikkoa) Vaihe 4 - Toimitus ja viimeistely 15.2.2005 Vaiheen 4 iterointisuunnitelman palautus 1.3.2005 Ohjeistuksen toimitus vertaisryhmälle 8.3.2005 Vertaisryhmän testaustulokset 15.3.2005 Vaiheen 4 aineiston palautuspäivämäärä 7 Riskiloki Riskiloki on osana Riskienhallinta-dokumenttia, joka on liitteenä. 8 Liitteet (Riskienhallintadokumentti) Sivu 24 / 24