Projektisuunnitelma Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14
Muutoshistoria Versio Pvm Päivittäjä Muutos 1.0 19.10.2007 Johannes Suanto Esitetty Iteraatiodemossa, päivitetty versioksi 1.0 0.08 18.10.2007 Johannes Suanto Päivitetty katselmointikommenttien perusteella 0.07 17.10.2007 Johannes Suanto Päivitetty kohta 2-5.4, 7 0.06 11.10.2007 Johannes Suanto Päivitetty kohtia 6, 6.1 ja 6.2 mentorin ja asiakkaan palautteen pohjalta 0.05 4.10.2007 Johannes Suanto Päivitetty kohtia 2, 3.1 ja 3.2 0.04 2.10.2007 Mikko Luukkonen Päivitetty kohtia 3.2, 5.1.8 0.03 2.10.2007 Johannes Suanto Päivitetty layouttia sekä kohtia 1, 2, 6, 6.1, 6.2 0.02 1.10.2007 Matti Eerola Pieniä korjauksia ja kappaleen 5 kirjoittelua. 0.01 27.9.2007 Johannes Suanto Ensimmäinen versio
Sisällysluettelo 1. Johdanto...1 2. Sidosryhmät ja henkilöstö...1 3. Tavoitteet...3 3.1. Projektin tavoitteet...3 3.2. Henkilökohtaiset oppimistavoitteet...4 4. Resurssit ja budjetti...5 4.1. Henkilöstön ajan resursointi...6 4.2. Materiaalit...7 4.3. Budjetti...8 5. Käytännöt ja työkalut...8 5.1. Käytännöt...8 5.1.1. Iteratiivinen kehitys...8 5.1.2. Iteraatioiden suunnittelu...8 5.1.3. Dokumentointi...8 5.1.4. Riskienhallinta...9 5.1.5. Työajan seuraaminen...9 5.1.6. Kommunikointi...10 5.1.7. Iteraatiodemo...10 5.1.8. Vikojen seuraaminen...10 5.1.9. Versionhallinta...10 5.1.10. Ohjelmointistandardit...10 5.1.11. Prosessin kehitys...11 5.1.12. Vaatimustenhallinta...11 5.1.13. Suunnittelu...11 5.2. Laadunvarmistussuunnitelma...11 5.3. Työkalut...11 5.4. Standardit...11 6. Vaiheistus...12 6.1. Aikataulut...12
6.2. Projektisuunnittelu (PP-iteraatio)...13 6.2.1. Tavoitteet...13 6.2.2. Tuotokset...13 6.2.3. Tehtävät...14 6.2.4. Riskit...15 6.3. Implementaatio 1...16 6.4. Implementaatio 2...16 7. Riskit...16
1. Johdanto Tämän projektin tarkoituksena on toteuttaa "Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan". Projektin tilaaja on Innofactor Oy ja projektin tuottajana toimii Teknillinen Korkeakoulu. 2. Sidosryhmät ja henkilöstö Projekti toteutetaan osana Teknillisen Korkeakoulun tarjoamaa "T-76.4115 and T-76.5115 Software Development Project I and II" kurssia. Projektiryhmän jäsenet ovat kurssin opiskelijoita ja toimivat projektin kaikissa rooleissa. Asiakkaana toimii Innofactor Oy, joka on tilannut kurssilta "Ratkaisun ohjelmistotuotelinjan monikielisyyden hallintaan". Innofactor on nimennyt projektista vastaavan henkilön omassa organisaatiossaan (Mikko Lampi) sekä erillisen yhteyshenkilön (Juha Kauppi) projektia varten. Lisäksi Juha Kauppi toimii asiakkaan teknisenä asiantuntijana, joka tarvittaessa ottaa mukaan myös muita asiakkaan asiantuntijoita. Varsinaiset ohjelmistotuotelinjan loppukäyttäjät ovat myös eräs sidosryhmä, joka kuitenkin tässä tapauksessa sisällytetään Innofactorin toimintaan. Näin toimitaan koska projektiryhmällä ei ole missään vaiheessa suoraa kosketusta loppukäyttäjiin, vaan Innofactorin asiantuntijat edustavat heitä tässä projektissa. Teknillisen Korkeakoulun puolelta kurssihenkilökunta toimii myös yhtenä sidosryhmänä. Eritoten kurssin vastaava Jari Vanhanen sekä projektiryhmän mentorina toimiva Seppo Sahi ovat aktiivisesti mukana projektin etenemisessä. Lisäksi sidosryhmiksi voidaan laskea muut projektiryhmät, koska kurssin aikana vaihdetaan kokemuksia projektiryhmien välillä, sekä Accenturen konsultit, jotka seuraavat projektiryhmien etenemistä laadunvarmistusnäkökulmasta. Alla on kuvattu projektin varsinainen organisaatiokaavio. 1 / 17
Kuva 1. Organisaatiokaavio Projektiryhmä koostuu seuraavista Teknillisen Korkeakoulun opiskelijoista ja työntekijöistä. Taulukko 1. Projektiryhmän jäsenet Rooli Nimi Sähköposti Puhelin Projektipäällikkö Johannes Suanto Johannes.Suanto[##]tkk.fi 050-545 2153 Arkkitehti Matti Eerola mveerol2[##]cc.hut.fi 040-757 2883 Laadunvarmistuspäällikkö Mikko Luukkonen Mikko.Luukkonen[##]tkk.fi 040-765 6403 Kehittäjä Aleksi Tolvanen atolvane[##]cc.hut.fi 040-708 7384 Kehittäjä Arto Tolonen arto.tolonen[##]tkk.fi 040-064 3075 Kehittäjä Eero Klami eklami[##]cc.hut.fi 050-359 9444 Kehittäjä Lauri Helkkula lhelkkul[##]cc.hut.fi 045-678 3444 Kehittäjä Otto Miettinen ojmietti[##]cc.hut.fi 040-080 8119 Projektiryhmän mentor Seppo Sahi seppo.sahi##google.com 050-537 0356 Projektiryhmän www-sivut löytyvät osoitteesta: www.tkk.fi/~jsuanto/projekti 2 / 17
3. Tavoitteet 3.1. Projektin tavoitteet Projektin tavoitteena on tarkentaa olemassa olevat monikielisyyden hallinnan määritelmät ja suunnitelmat toteuttamista edellyttävälle tasolle. Lisäksi tavoitteena on suunnitella ja toteuttaa ohjelmistokomponentti sekä varmistaa toteutetun komponentin laadukkuus, toiminta osana varioitavaa tuotelinjaa ja dokumentoida se. Toteutettava ohjelmistokomponentti koostuu tietomallista, yleiskäyttöisestä kirjastosta, jota ohjelmistokehittäjät käyttävät ja jota käytetään kielitermien eli monikielisten tekstien esittämiseen käyttöliittymäkerroksella sekä käyttöliittymästä, jolla monikielisyyttä voidaan hallita (tekstien kääntäminen, muokkaaminen jne.). Ohjelmistokomponentin toteutustekniikkoina käytetään.net ja SQL Server 2005:a. Projektin projektisuunnitteluiteraatiossa on tarkoitus tuottaa projektisuunnitelma, alustava aikataulu ja arkkitehtuuri. Tämän iteraation aikana tutustutaan myös asiakkaan toimintaympäristöön, terminologiaan ja käytössä olevaan, projektin kannalta oleelliseen, ohjeistukseen. Iteraatio 1 vaiheessa tuotetaan ohjelmistokomponentin ensimmäinen toimiva ja testattu versio, joka toteuttaa asiakkaan priorisoimat perustoiminnot. Iteraatio 2 vaiheessa ohjelmistokomponentin toimintaa parannetaan ja siihen lisätään mahdollisuuksien mukaan sellaisia asiakkaan toivomia toimintoja joita ei ehditty toteuttaa iteraatio 1:ssä. Toteutettavassa ohjelmistokomponentissa on erityisesti kiinnitettävä huomioita suorituskykyyn, skaalautuvuuteen, helppokäyttöisyyteen ja ylläpidettävyyteen. Asiakkaan kanssa käytyjen keskustelujen aikana tavoitteet priorisoitiin seuraavasti. Taulukko 2: Asiakkaan priorisoidut tavoitteet Nro 1 2 3 Kriteeri Hallittavuus: Termistön suuren koon ja vaihtelevan käytön vuoksi hallittavuus on noussut ehdottomaksi tärkeimmäksi kriteeriksi. Suorituskyky ja skaalautuvuus: Suuren ja kasvavan käyttäjämäärän vuoksi on tärkeää että ratkaisu on suorituskykyinen ja kykenee skaalautumaan hyvin myös tulevaisuudessa Käytettävyys: Käyttäjät ovat tällä hetkellä kehittäjiä, projektipäälliköitä tai muita asiantuntijoita, joten käyttöliittymän on ennemmin oltava tehokas kuin käyttäjää ohjaava työkalu. Tavoitteiden täyttymiskriteerejä ei ole vielä tarkennettu asiakkaan kanssa. Ne tarkennetaan kun asiakas on priorisoinut funktionaaliset toiminnot, jolloin kriteerit merkitään alla olevaan taulukkoon jokaisen tavoitteen osalta. 3 / 17
Taulukko 3. Tavoitteiden täyttymiskriteerit Tavoite 1. Hallittavuus 2. Suorituskyky 3. Skaalautuvuus 4. Käytettävyys Täyttymiskriteeri 3.2. Henkilökohtaiset oppimistavoitteet Kurssin tavoitteisiin kuuluu myös henkilökohtaisten oppimistavoitteiden asettaminen, seuraaminen ja saavuttaminen projektiryhmän kaikille opiskelijajäsenille. Nämä oppimistavoitteet on merkitty projektin alussa alla olevaan taulukkoon ja niiden täyttymistä seurataan projektin aikana. Taulukko 4 Henkilökohtaiset oppimistavoitteet Henkilö Oppimistavoitteet - Oppia johtamaan projektia paremmin - Tutustua uusiin prosesseihin ja tekniikoihin Johannes Suanto ohjelmistokehityksen saralta - Arkkitehtina toimiminen. - Erilaisten laatukäytäntöjen toteuttaminen Matti Eerola käytännössä - Vaatimustenmäärittelyn ja laadunvarmistuksen oppiminen teorian ja työkalujen tasolla. - Arkkitehtuurin suunnittelusta toteutukseen etenemisen ymmärtäminen. ASP.NET:iin Mikko Luukkonen tutustuminen. - Oppia toimimaan ryhmässä aiheeseen liittyen; ryhmän jäsenille sopivien työtapojen etsiminen, kommunikointi ryhmän jäsenten kanssa paljolti hajautetussa projektissa ("etätyöstä" syntyvät haasteet), vastuualueiden jakautuminen eri jäsenten välillä ja muut suuren ryhmän ja projektin hallintaan liittyvät probleemat. - Kehitysympäristö on jo melko tuttu, joten tekniikoiden oppiminen ei ole niin tärkeällä sijalla. Kuitenkin mielenkiintoista on nähdä joidenkin työkalujen, kuten Wikin ja Bugzillan hyödyllisyys ja käytettävyys tällaisessa projektissa. - Yleisesti kaikki asiat mitä ei teoriakursseilla opi vaan vain ja ainoastaan kantapään kautta. Vaikka olen kehittäjänä, niin nyt on mahdollisuus myös nähdä vähän pintaa syvemmälle eli nähdä myös hieman koodaamisen ulkopuolelle. Töissä Aleksi Tolvanen 4 / 17
kehittäjänä ei oikein ehdi eikä pysty muuta kuin liukuhihnalta koodata asioita mitä pyydetään. Kurssilla pystynee paremmin keskittymään kaikkeen ohjelmiston suunnittelusta ohjelmiston toimitukseen asti. Lisäksi ohjelmiston kunnollinen testaus eri tekniikoita käyttäen. Töissä kun se jää monesti aika vähälle lähinnä ajanpuutteen takia. - Käytettävien teknologioiden (.net, c#, jne.) oppiminen - Käytettävien metodit ja prosessit (TDD, jne.) oppiminen - Koko projektin seuraaminen ja ymmärtäminen alusta loppuun Arto Tolonen - Käsitys expertti trion hommista - C#/.NET ympäristön oppiminen - Ohjelmistoprojektin koko elinkaaren näkeminen ja osallistuminen alusta Eero Klami toimitukseen asti. - saada opetetusta teoriasta käytännön kokemuksia - saada parempi yleiskuva koko projektin Lauri Helkkula elinkaaresta - Oppia projektissa käytetyt ohjelmointikielet, jotka tulevat minulle melko uusina tuttavuuksina, sille tasolle, että ne voi hyvällä omatunnolla mainita osaavansa. - Oppia toimimaan projektissa, jossa täytyy opetella paljon uutta pystyäkseen toteuttamaan annetut tehtävät - Oppia lisää projektin ohjauspuolestakin - Lisätä kokemusta ohjelmistoarkkitehtuurin suunnittelusta Otto Miettinen 4. Resurssit ja budjetti Projektille on resursoitu henkilöitä seuraavasti. 1kpl projektipäällikkö (Suanto) 1kpl laadunvarmistuspäällikkö (Luukkonen) 1kpl arkkitehti (Eerola) 5kpl kehittäjiä (Helkkula, Klami, Miettinen, Tolonen, Tolvanen) Projektin työmääräksi on arvioitu 150 tuntia jokaisen henkilön osalta. Tämän lisäksi kurssin vanhaa versiota suorittavat henkilöt (Luukkonen, Eerola, Helkkula) toteuttavat projektiin kuuluvan "Software Engineering Practice Assignment" (SEPA) osion aiheesta "Automated Unit Testing". SEPA osion 5 / 17
tekemiseen on laskettu kuluvan noin 40 tuntia / henkilö yli kurssin normaalin 150 tuntia/henkilö arvion. Tämän johdosta SEPAa suorittaville henkilöille on resursoitu kokonaisuudessaan 190 tuntia tämän projektin tekemiseen (150h + 40h). 4.1. Henkilöstön ajan resursointi Projektin alussa henkilöiden ajankäytölle laaditaan arvio, jota päivitetään jokaisen iteraation jälkeen. Arviointiin lasketaan mukaan kaikki erilliset tehtävät sekä "yleiset tehtävät" kuten kokoukset, uusien asioiden opiskelu, infrastruktuurin ylläpito ja viestinnän seuranta. Alla olevaan taulukkoon on merkitty projektisuunnittelu-iteraation aikana tehdyt arviot henkilöiden ajankäytöstä eri iteraatioiden aikana. Taulukkoa päivitetään jokaisen iteraation alussa. 6 / 17
Taulukko 5: Ajankäytön arvio, SEPA mukaan lukien Henkilö PP I1 I2 Yhteensä Suanto 70 40 40 150 Luukkonen 70 60 60 190 Eerola 70 60 60 190 Helkkula 30 80 80 190 Klami 25 65 60 150 Miettinen 25 70 55 150 Tolonen 25 75 50 150 Tolvanen 25 65 60 150 Total 340 515 465 1320 4.2. Materiaalit Projektissa käytetään seuraavia Teknillisen Korkeakoulun MSDN Academic Alliance-lisenssin kautta hankittuja ohjelmistoja: Microsoft Visual Studio Pro 2005 Microsoft Project 2007 Teknillisen Korkeakoulun kautta on saatu käyttöön myös seuraavia sovelluksia CVS MediaWiki Bugzilla MagicDraw UML Lisäksi käytetään seuraavia vapaasti satavilla olevia ohjelmistoja Microsoft SQL Server 2005 Management Studio Express NUnit 7 / 17
4.3. Budjetti Projektilla ei ole varsinaista budjettia vaan kaikki projektiryhmän tekemä työ tehdään opintojen puitteissa ja käytetyt materiaalit ovat joko vapaasti saatavilla olevia tai Teknillisen Korkeakoulun kautta hankittuja. Jokaisen iteraation lopuksi tehdään kuitenkin arvio siitä mitä vastaava työ olisi tullut maksamaan kaupallisen toimittajan tekemänä. Hintaperusteena käytetään jonkin suuren suomessa toimivan ITtoimittajan henkilötyöpäivän (htp) hintaa. 5. Käytännöt ja työkalut 5.1. Käytännöt Alla kuvataan projektissa käytetyt käytännöt ja työkalut. 5.1.1. Iteratiivinen kehitys Iteratiivisella kehityksellä tarkoitetaan kehitystä joka tapahtuu syklisesti, jolloin ensimmäisen kierroksen lopputulos toimii seuraavan kierroksen lähtöpisteenä. Jokaisen iteraation alussa pidetään asiakkaan kanssa iteraatiosuunnittelukokous jonka perusteella luodaan iteraatiosuunnitelma. Tässä suunnitelmassa määritellään mitä toimia iteraation aikana tehdään. Näitä toimia voivat olla mm. vaatimusmäärittely, ohjelmiston suunnittelu, ohjelmointi ja testaus. Samalla päätetään mitä toiminnallisuutta iteraation aikana ohjelmistoon toteutetaan. Asiakas pidetään ajan tasalla viikoittaisilla edistymisraporteilla sekä jokaisen iteraation lopussa pidettävällä iteraatiodemolla, jossa esitellään iteraation tuotokset. Lisäksi asiakkaan kanssa pidetään kokouksia tarpeen mukaan. 5.1.2. Iteraatioiden suunnittelu Jokaisen iteraation alussa pidetään asiakkaan kanssa iteraation suunnittelukokous, missä asiakkaan kanssa päätetään mitä toiminnallisuuksia toteutetaan tämän iteraation aikana. Päätettyjen tehtävien lisäksi sekä asiakas että projektiryhmä keksii todennäköisesti iteraatioiden aikana lisää tehtäviä. Mikäli nämä eivät ole olemassa olevien tehtävien tarkentamista otetaan ne käsittelyyn vasta seuraavan iteraation suunnittelukokouksessa. Iteraation suunnittelukokoukseen vaaditaan valmistautumista. Projektiryhmän on käytävä läpi jäljellä olevat toiminnallisuusvaatimukset / tehtävät ja annettava niille arvio niiden vaatimasta työmäärästä ja vaikuttavuudesta arkkitehtuuriin, jotta asiakas voi huomioida nämä tiedot omassa priorisoinnissaan. 5.1.3. Dokumentointi Projektisuunnitelma, projektin hallintaan sekä asiakkaan kanssa kommunikointiin liittyvät dokumentit ovat projektipäällikön vastuulla. Projektipäällikkö myös kokoaa ja muuttaa pdf muotoon iteraatiodemoon 8 / 17
tarvittavat dokumentit yhdessä dokumenteista vastaavien henkilöiden kanssa. Arkkitehti on vastuussa arkkitehtuurikuvauksesta sekä muista suoraan arkkitehtuuriin liittyvistä kuvauksista (esim. use caset). Laadunvarmistuspäällikkö vastaa laadunvarmistusohjeistuksesta, vaatimusmäärittelydokumentista sekä näihin liittyvistä muista kuvauksista. Jokainen kehittäjä on omalta osaltaan vastuussa kirjoittamastaan koodin kommentoinnista sekä mahdollisista käytön- ja käyttöohjeista. Vastuuhenkilön lisäksi dokumenttien laadinnassa käytetään muiden projektiryhmäläisten asiantuntemusta ja aikaa mahdollisuuksien mukaan työtaakan tasaamiseksi ja tiedon levittämiseksi projektiryhmässä. Dokumentit pyritään katselmoimaan projektiryhmän sisällä ja tärkeimmät dokumentit katselmoitutetaan myös asiakkaalla. Pääasiallisena katselmoinnin organisoijana toimii projektipäällikkö. Aikataulujen niin vaatiessa myös muut voivat käynnistää katselmoinnit. Dokumentit luodaan sopivalla toimisto-ohjelmalla (esim. Microsoft Office). Hajautetusti päivitettävien dokumenttien osalta käytetään Google-Docs palvelua, joka mahdollistaa monen käyttäjän samanaikaisetkin editoinnit dokumenteille sekä säilyttää dokumenttien revisiohistorian. 5.1.4. Riskienhallinta Riskit tunnistetaan aluksi ohjelmistoasiantuntijoiden toimesta ja ne kirjataan riskilokiin tämän projektisuunnitelman kohdassa 7. Projektin aikana riskejä kartoitetaan jatkuvasti eri tapaamisissa sekä projektiryhmän jäsenten normaalissa työssä. Kun jokin riski havaitaan siitä ilmoitetaan ohjelmistoasiantuntijoille, ja tarvittaessa koko projektiryhmälle. Projektipäällikkö huolehtii siitä että tunnistetut riskit tulee merkittyä ja päivitettyä projektisuunnitelmaan. Riskejä käsitellään myös osana muita kokouksia, sekä projektiryhmän sisällä että asiakkaan kanssa. Riskien kirjaaminen ja päivittäminen projektisuunnitelmaan tapahtuu myös tällöin projektipäällikön toimesta. 5.1.5. Työajan seuraaminen Työaika seurataan 0,25 tunnin tarkkuudella, siten että raportointijakso on yksi viikko. Projektipäällikkö ylläpitää tuntitaulukkoa (Excel), johon on kirjattu avoinna olevat tehtävät, niiden arvioidut tuntimäärät, henkilöille suunnitellut tehtävät tunteineen sekä toteutuneet tunnit. Projektiryhmäläiset raportoivat jokaisena maanantaina klo 18 mennessä sähköpostitse projektipäällikölle edellisenä viikkona käyttämänsä tunnit. Raportoinnissa käytetään projektipäällikön luomaa ja ylläpitämää mallipohjaa, josta käy ilmi avoinna olevat tehtävät, joihin on mahdollista käyttää tunteja. Tuntitaulukkoon ja siitä tuntiraportointimallipohjaan, luodaan uusia tehtäviä projektipäällikön toimesta sitä mukaa kun tunnistetaan tarpeita uusille tehtäville. Kaikki projektiryhmäläiset voivat luonnollisesti ehdottaa uusien tehtävien luomista tilanteen niin vaatiessa. Käytetty työaika raportoidaan asiakkaalle viikoittaisessa raportissa sekä jokaisen iteraation lopussa pidettävässä iteraatiodemossa. Projektiryhmäläiset voivat seurata tilannetta projektipäällikön Google Docsissa ylläpitämästä tuntitaulukosta. 9 / 17
5.1.6. Kommunikointi Projektiryhmällä on käytössään IRC-kanava jonka kautta on mahdollista kysyä ja saada vastauksia ad-hoctapaan. Teknillisen Korkeakoulun tarjoamaan MediaWikiä käytetään projektiryhmän sisäisten ohjeiden (infrastruktuurin yms. asennusohjeet) luomiseen ja ylläpitoon. Järjestelmän avoimuuden vuoksi se ei kuitenkaan sovellu luottamuksellisen tiedon säilyttämiseen. Sähköpostia käytetään normaaliin kommunikaatioon projektiryhmän jäsenten kesken sekä ensisijaisena kommunikaatiokanavana asiakkaaseen päin sekä virallisempien asioiden kuten työaikaraporttien toimittamiseen. Kokousten järjestämisessä käytetään apuvälineenä www.doodle.ch -palvelua, jonka kautta on mahdollista sopia parhaiten kaikille sopiva aika. Kokouksia pyritään järjestämään tilanteeseen sopivalla kokoonpanolla. Asiakkaan kanssa pyritään pitämään kokouksia tarvittaessa, eritoten iteraatioiden alussa ja lopussa. 5.1.7. Iteraatiodemo Projektipäällikkö kokoaa iteraatiodemoon tarvittavan dokumentaation ja muuntaa sen pdf-muotoon mahdollisuuksien mukaan. Valmisteleva työ pyritään saattamaan valmiiksi viimeistään demotilaisuutta edeltämänä päivänä. Arkkitehti puolestaan valmistelee ohjelmistojen demot. 5.1.8. Vikojen seuraaminen Vikojen seurantaan käytetään koulun tarjoamaa Bugzillaa, joka on käyttäjätunnuksen ja salasanan takana. Tarkemmat ohjeistukset käytöstä tulevat laadunvarmistussuunnitelmaan. 5.1.9. Versionhallinta Versionhallintaan käytetään CVS:ää. Tarkempi kuvaus eri työkaluista löytyy kohdasta 5.3 Työkalut. Koodi tulisi hakea versionhallinnasta aina kun aloittaa työskentelyn ja viedä takaisin työskentelyn päätteeksi. Versionhallinnasta hakeminen ja sinne vieminen voi tapahtua useamminkin ja se olisi hyödyllistä, jos useampi ohjelmoija muokkaa samaa toiminnallisuutta. Versionhallintaan viennin yhteydessä on suositeltavaa kirjoittaa jokin muutoksia kuvaava viesti, joka tallennetaan CVS:ään. Arkkitehti merkitsee (tag) jokaisen kehitysiteraation puolivälissä ja lopussa kaikki versionhallinnan alaiset tiedostot. Versionhallinnan alaisia tiedostoja ovat ohjelmiston ja testien lähdekoodi ja arkkitehtuurityökalujen tuottamat tiedostot. 5.1.10. Ohjelmointistandardit Koodausstandardina käytetään Innofactor Oy:n ohjelmointistandardeja, jotka ovat pitkälti yleisten C# ohjelmoinnin käytäntöjen mukaisia. Jokainen ryhmän jäsen on saanut kopion Innofactorin ohjelmointiohjeesta, jossa selitetään Innofactorilla käytettäviä ohjelmointikäytäntöjä. Lisäksi ryhmän jäsenillä on kopio ohjelmakoodin kommentointi -ohjeesta. 10 / 17
5.1.11. Prosessin kehitys Jokaisen projekti-iteraation päätteeksi projektiryhmä kokoontuu miettimään miten iteraatio meni ja miten seuraavassa iteraatiossa tulisi, toimia jotta se menisi paremmin. Näihin kokouksiin pyritään saamaan mukaan myös ryhmän mentor. Muut prosessinkehitystoimet on kuvattu laadunvarmistusohjeistuksessa (ks. kohta 5.2). 5.1.12. Vaatimustenhallinta Vaatimustenhallinta on kuvattu laadunvarmistussuunnitelmassa (ks. kohta 5.2) 5.1.13. Suunnittelu Arkkitehtuurin suunnittelu on luonnollisesti arkkitehdin vastuulla. Kehittäjät osallistuvat arkkitehtuurin suunnitteluun siltä osin kuin suunnittelusta voi erottaa sopivan kokoisia alueita kehittäjille. Arkkitehtuuria pyritään suunnittelemaan samalla työkalulla kuin millä alemman tason suunnittelu tehdään. Aina se ei kuitenkaan ole mahdollista. Alemman tason suunnittelun tehtävät lisätään tehtävälistaan aina kun tarvetta suunnitteluun tulee. Tehtävälistasta suunnittelutehtävät jaetaan eteenpäin normaalin käytännön mukaisesti. 5.2. Laadunvarmistussuunnitelma Laadunvarmistussuunnitelma on eriytetty erilliseksi dokumentikseen, joka valmistuu 2.11 mennessä. 5.3. Työkalut Ohjelmistokehitysympäristönä käytetään Microsoft Visual Studio 2005 Pro -ohjelmaa. CVS on tuttu kaikille kehittäjille ja he saavat käyttää omavalintaistaan ohjelmistoa CVS:n käyttöön. Kehitysympäristöön on esimerkiksi tarjolla lisäosa, jolla sen saa toimimaan suoraan CVS:n kanssa (http://www.jalindi.com/igloo/). Voi myös käyttää erillistä ohjelmaa kuten WinCVS. Todennäköisesti helpoin vaihtoehto on käyttää WinCVS:ää, jonka voi ladata ilmaiseksi osoitteesta http://www.wincvs.org/ (versio 2.0.2.4). Arkkitehtuurin ja alemman tason suunnitteluun käytetään MagicDraw UML -ohjelmistoa. Tietokannan rakenteen suunnittelussa käytetään Microsoftin Visual Studio 2005 - SQL Management Studio - ohjelmistoista löytyvää tietokantadiagrammi -työkalua. 5.4. Standardit Projektissa käytetään asiakkaan ohjelmointi- ja dokumentointiohjeita. 11 / 17
6. Vaiheistus Projekti on vaiheistettu kolmeen erilliseen vaiheeseen; Projektin suunnittelu, Iteraatio 1 ja Iteraatio 2. Ensimmäiseen Projektin suunnittelu vaiheeseen kuuluu varsinaisen projektisuunnittelun lisäksi mm. projektiin tutustuminen, työtavoista sopiminen ja muu projektiin liittyvä valmistelutyö kuten infrastruktuurin ja työkalujen valinta ja käyttöönotto. Iteraatioiden 1 ja 2 aikana tehdään suurin osa varsinaisesta projektityöstä, eli ohjelmistotuotelinjan monikielisyyden hallinnan ratkaisun toteuttamisesta tilaajalle. 6.1. Aikataulut Projektilla on sekä ulkoisia että sisäisiä virstanpylväitä. Alla on listattu kaikki projektin kannalta tärkeät päivämäärät kuten iteraatioiden päättymiset, sisäiset aikarajat, tapaamiset asiakkaan kanssa jne. Aikataulua täydennetään ja tarkennetaan jatkuvasti. Taulukko 6: Aikataulu Päivämäärä Tehtävä Status 14.9.2007 Ohjelmistoasiantuntijatiimien kokoaminen OK 18.9.2007 Asiakasinfo, ensimmäinen tapaaminen asiakkaan edustajan kanssa OK 21.9.2007 Kaikki kehittäjät rekrytoitu ryhmään OK 24.9.2007 Asiantuntijatiimin ensimmäinen suunnittelukokous OK 25.9.2007 Vaihe "Projektisuunnittelu" alkaa 25.9.2007 Luento kurssilla käytettävästä prosessikehyksestä OK 1.10.2007 Ensimmäinen suunnittelukokous koko ryhmällä. Mentor mukana OK 3.10.2007 Ensimmäinen suunnittelukokous asiakkaan kanssa. OK 5.10.2007 Projektisuunnittelu iteraation suunnitelman deadline; tämän asiakirjan kohtien 6.1 ja 6.2 toimittaminen asiakkaalle ja mentorille OK 6.10.2007 Arkkitehtuurin suunnittelukokous OK 11.10.2007 Arkkitehtuurikokous asiakkaan kanssa OK 12.10.2007 Päivitetty versio iteraatiosuunnitelmasta, Infrastruktuurin asennuskokous Työn alla 13.10.2007 Suunnittelukokous Projektisuunnittelu iteraation dokumenttien palauttaminen, 19.10.2007 Iteraatiodemo Työn alla 25.10.2007 Vaihe "Implementaatio 1" alkaa Iteraatio 1-vaiheen iteraatiosuunnitelman deadline (tämän 2.11.2007 asiakirjan kohdat 6.1, 6.3 sekä laadunvarmistusdokumentti) 12 / 17
10.12.2007 Iteraatio 1-vaiheen dokumenttien palauttaminen 11.12.2007 Iteraatiodemo 15.1.2007 Vaihe "Implementaatio 2" alkaa Iteraatio 2-vaiheen iteraatiosuunnitelman deadline (tämän 18.1.2008 asiakirjan kohdat 6.1, 6.4 sekä laadunvarmistusdokumentti) 8.2.2008 Varaa demo asiakkaan ja mentorin kanssa, osoitettava nähtävissä olevaa edistystä Lopullisen version ja testausohjeiden toimittaminen 22.2.2008 vertaisryhmälle testausta varten Vertaisryhmän projektin testitulosten raportoiminen 26.2.2008 vertaisryhmälle 3.3.2008 Dokumenttien palauttaminen 4-5.3.2008 Iteraatiodemo 6.2. Projektisuunnittelu (PP-iteraatio) Projektisuunnittelu-iteraation tarkoituksena on, varsinaisen projektisuunnitelman tekemisen lisäksi, mahdollistaa ryhmän muodostuminen, työprosesseista sopiminen, työkalujen hankkiminen ja muiden varsinaista projektia edeltävien toimien tekeminen. 6.2.1. Tavoitteet Projektisuunnittelu-iteraation tärkeimmät tavoitteet ovat: Projektisuunnitelman luominen ja saattaminen sellaiselle valmiusasteelle, että sen perusteella on mahdollista ja turvallista aloittaa varsinaisen projektin tekeminen. Tähän kuuluu mm. asiakkaaseen ja tehtävään tutustuminen, karkea aikataulutus ja tehtävien määrittely, käytettävissä olevien resurssien karkea jako sekä prosessien alustava dokumentointi. Toimintakentän ymmärtäminen siten että projektiin osallistuvat ymmärtävät asiakkaan toimintakenttää riittävästi, jotta asiakkaan tarpeet ja käyttämä kieli sekä terminologia ymmärretään oikein alkavaa projektia ajatellen. Vaatimusmäärittely yleisellä tasolla sekä projektin konkreettisten tavoitteiden asettaminen yhdessä asiakkaan kanssa. Tähän kuuluu asiakkaalle tärkeimpien funktionaalisten vaatimusten ja priorisointien selvittäminen. Lisäksi arkkitehtuurisesti tärkeiden käyttötapausten kuvaaminen siten, että ne tarkentavat yllä mainittuja vaatimuksia ja tuovat mahdollisesti esiin uusia tavoitteita. Tässä nimenomaisessa projektissa suuri osa tavoitteista on jo määritelty etukäteen asiakkaan luomassa arkkitehtuurikuvauksessa (Diplomityö: J. Kauppi) Toimintatapojen suunnittelu ja jalkautus. Projektisuunnittelu iteraation aikana projektin laadunvarmistusohjeisto luodaan ja siihen kirjataan projektissa käytettävät toimintatavat, kuten ohjelmointi-, dokumentointi- ja testausstandardit. Ohjeistossa määriteltyjen toimintatapojen jalkauttaminen aloitetaan myös projektin tässä vaiheessa ja sitä jatketaan koko projektin ajan. 6.2.2. Tuotokset Projektisuunnittelu-iteraation tärkeimmät konkreettiset tuotokset esitellään iteraatiodemossa 19.10.2007. 13 / 17
Niihin kuuluvat seuraavat dokumentit: Projektisuunnitelma, joskin sen kohdan 5.2 Laadunvarmistussuunnitelma ei vielä tarvitse olla tarkentunut lopulliseen muotoonsa. Vaatimusmäärittelydokumentti sillä tarkkuudella kun se on mahdollista projektin tässä vaiheessa. Edistymisraportti, joka kuvaa projektin edistymistä, siihen liittyviä tehtäviä ja niihin käytettyä aikaa. 6.2.3. Tehtävät Projektisuunnittelu-iteraatioon kuuluu tässä iteraatiossa alla mainitut tehtävät. Niiden kuormittavuus on arvioitu projektisuunnittelu-iteraation alussa, taulukossa merkityllä tavalla. Tämä tulee tarkentumaan iteraation mittaan. Taulukko 7: Projektisuunnittelu iteraation tehtävät ID Tehtävä 1 Projektiin tutustuminen (kaikille pakollinen tehtävä, perus arkkitehtuuri-dokumenttiin ja tehtävänantoon tutustuminen) Suunnitellut tunnit 34 2 Projektisuunnitelman tekeminen 14 3 4 5 6 7 Asiakkaan tarpeiden kartoittaminen, vaihe 1 Arkkitehtuurin jalostaminen (annetusta arkkitehtuurista eteenpäin) Laadunvarmistusohjeistukseen tutustuminen (koodaus- ja dokumentointistandardit) Projektin laadunvarmistusohjeiston tarkentaminen (ohjeiden kokoaminen yhteen tätä projektia varten) Laadunvarmistusprosessin jatkuva päivitys 8 Arkkitehtuurin jatkuva päivitys 7 9 Projektisuunnitelman jatkuva päivitys 10 13 7 8 6 8 14 / 17
Projektin hallinnointi (tuntiseuranta, projektin 10 etenemisen seuraaminen ja ohjaus, raportointi asiakkaalle) 14 Lisäksi tulee iteraation lopuksi tehtävät: Iteraatiodemoon valmistautuminen: 12 tuntia Iteraatiodemo tilaisuus: 12 tuntia Lisäksi yleisiin tehtäviin on varattu aikaa seuraavasti: Kokoukset: 66 tuntia Infrastruktuurin perustaminen ja ylläpito: 23 tuntia Uusien asioiden opiskelu: 34 tuntia Viestinnän seuranta: 16 tuntia Projektisuunnittelu-iteraatioon on siis suunniteltu käytettävän 139 tuntia yleisiin tehtäviin sekä 145 tuntia varsinaisiin tehtäviin ja iteraatiodemoon. Yhteensä siis 284 tuntia Osa projektilaisista suorittaa kurssin vanhemman version johon kuuluu myös erillinen SEPA (Software Engineering Practice Assignment) osio, aiheena "automated unit testing". Tähän liittyvät tehtävät tullaan myös merkitsemään projektiin kuuluviksi, kunhan tehtävät selkiytyvät siten, että kurssin vanhaa versiota suorittavilla on käytettävissään 40 ylimääräistä tuntia SEPA-tehtävien tekemiseen verrattuna kurssin uudempaa versiota suorittaviin. Tehtävien keskinäinen tärkeysjärjestys ja keskinäinen riippuvuus on tässä vaiheessa vielä suhteellisen alkeellinen. Ensimmäisenä, ja tärkeimpänä tehtävänä, on luonnollisesti (1) Projektiin tutustuminen. Tämän pohjalta voidaan aloittaa tehtävät (2) "Projektisuunnitelman tekeminen", (3) "Asiakkaan tarpeiden kartoittaminen, vaihe 1", (4) "Arkkitehtuurin jalostaminen" ja (5) "Laadunvarmistusohjeistukseen tutustuminen". Näiden tehtävien pohjalta syntyy dokumentaation ensimmäiset versiot, joita aletaan jatkojalostamaan välittömästi tehtävissä (6), (7), (8) ja (9). Alkumetreiltä asti aina loppuun asti kestävä tehtävänä on (10) "Projektin hallinnointi". Lisäksi aikaa kuluu projektin eri vaiheissa "yleisiin" tehtäviin kuten kokouksiin, infrastruktuurin luomiseen ja ylläpitoon, uusien asioiden opiskeluun sekä viestinnän seurantaan. 6.2.4. Riskit Riskit kuvataan tarkemmin tämän projektisuunnitelman kappaleessa 7. "Riskit". Lyhyenä yhteenvetona voidaan kuitenkin todeta, että suurin osa nyt tunnistetuista riskeistä liittyy asiakkaan tarpeiden riittävän hyvään ymmärtämiseen (ymmärretäänkö mikä on asiakkaalle oikeasti tärkeää), tarpeeksi selkeän arkkitehtuurin tuottamiseen (saadaanko aikaan niin selvä ja realistinen tavoitetilan kuva, että sen pohjalta on mahdollista aloittaa toteutus) tai projektin resurssitilanteen muuttumiseen (henkilöiden 15 / 17
sairastuminen, keskeyttäminen jne.). Riskejä pyritään vähentämään asiakkaan kanssa käydyllä avoimella kommunikaatiolla, projektin tavoitteiden selkeällä määrittelyllä yhdessä asiakkaan kanssa sekä projektitiimin motivoitumisen ylläpitämisellä keskinäisin tapaamisin sekä painottamalla projektista saatavia hyötyjä asiakkaalle ja projektiin osallistuville. 6.3. Implementaatio 1 Implementaatio 1:n tarkempi suunnittelu tapahtuu projektisuunnittelu iteraation päätyttyä, jolloin tämä kohta tarkennetaan. 6.4. Implementaatio 2 Implementaatio 2:n tarkempi suunnittelu tapahtuu Iteraatio 1:n päätyttyä, jolloin tämä kohta tarkennetaan. 7. Riskit Alla kuvataan suurimmat tunnistetut riskit. Taulukko 8: Riskiloki (Todennäköisyys 1=pienin, 3=suurin, Vaikuttavuus 1= pienin, 3=suurin). ID Riski Tod. Vaik. Vaikutukset Korjaavat toimet Vastuu 1 Kehittäjä lopettaa kesken projektin 2 3 Tärkeää tietoa katoaa Projektin laajuutta joudutaan pienentämään Yhteishengen luominen ja ylläpito. (riskin välttäminen) Kriittisten osien kehityksessä on mukana enemmän kuin yksi henkilö (vaikutuksen minimointi) Läheinen yhteistyö asiakkaan kanssa (välttäminen) Projektipäällikkö 2 Asiakkaan tarpeiden riittämätön ymmärtäminen 1 2 Toteutettava ohjelmisto ei vastaa asiakkaan toiveita Ohjelmiston vaatimusten katselimoituttaminen tarpeeksi usein jotta korjaavat toimet ovat mahdollisia (minimointi) Ohjelmistoasiantuntijat 16 / 17
3 4 5 N Tuotettu arkkitehtuuri ei ole niin selvä, että sen pohjalta voitaisiin ryhtyä ohjelmoimaan 1 3 asiakkaan realistinen tavoitetila 2 2 Aikataulu osoittautuu liian kireäksi 2 3 Ohjelmointi on tehotonta ja joudutaan korjaamaan sekä muokkaamaan jo tehtyä materiaalia asiakas olettaa että projektin lopputulos on huomattavasti laajempi kuin mitä projekti ryhmä olettaa Joudutaan jättämään jotain toimintoja pois tai toimintoja ei saada valmiiksi läheinen yhteistyö asiakkaan arkkitehtuurivastaavien kanssa (välttäminen) selkeä arkkitehtuuri dokumentaatio (minimointi) tiivis yhteistyö asiakkaan kanssa, vaatimusmäärittelyn katselmointi asiakkaalla (välttäminen) Tavoitetilan seuraaminen ja siihen vaikuttaminen projektin aikana (minimointi) Tavoitteiden priorisointi ja viikoittainen edistyksen seuranta (välttäminen) Arkkitehti, laadunvarmistus päällikkö projektipäällikkö, arkkitehti kaikki Viitteet 17 / 17