Ryhmän nimi: Crossing

Transkriptio

1 Projektisuunnitelma Ryhmän nimi: Crossing Tekijät: Timo Nummenmaa (PM) Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått Toimeksiantaja: Timo Poranen (UTA) Muutospäivämäärä: Versionumero: 1.0.0

2 Sisällysluettelo 1. Johdanto Projektin laajuus Ohjelmiston tärkeimmät toiminnot Tehokkuus- ja toiminta-asiat Hallinta- ja tekniset rajoitukset Osallistujat Ryhmän rakenne Organisaation rakenne Sidosryhmät Hallinnan raportointi ja kommunikaatio Projektin läpivientiarviot Arviointitekniikat COCOMO II, reuse model COCOMO' COCOMO II Tulokset Riskien hallinta Projektin riskit Riskitaulukko Yleiskuva riskien lieventämisestä, seurannasta ja hallinnasta Projektin aikataulu Projektin tehtäväjoukko Toiminnallinen ositus Tehtäväverkko Aikataulukuvaaja Seuranta- ja kontrollointimekanismit Laadunvarmistus ja kontrollointi Muutosten hallinta ja kontrollointi Liitteet

3 1. Johdanto Tämä projektisuunnitelma on osa sekä Tampereen yliopiston projektityö- että ohjelmistoprojektin johtaminen -kurssia. Projektityöhön kuuluu toimeksiantajan projektin suunnittelu, dokumentointi ja toteutus. Projektisuunnitelman tarkoitus on antaa alustava kuva projektista, sen kulusta ja muista projektiin liittyvistä asioista. Projektityön toimeksiantaja on Tampereen yliopiston tietojenkäsittelytieteiden laitos, tarkemmin tutkija Timo Poranen. Projektimme pohjautuu laitoksella kehitettyyn tekstipohjaiseen ohjelmaan, joka on tarkoitettu graafien käsittelyyn. Ohjelma pystyy laskemaan annetusta graafista erilaisia ominaisuuksia, joiden avulla graafeja voidaan tutkia. Tarkoituksena on projektityökurssin puitteissa muokata olemassa olevaa ohjelmaa niin, että sitä voidaan projektin valmistuttua käyttää ilman kaupallista osaa, joka on tällä hetkellä pakollinen. Näin muutkin graafitutkimuksesta kiinnostuneet voisivat hyödyntää ohjelmaa ja saataisiin ohjelma jakoon avoimen GNU-lisenssin alaisuuteen. Samalla on tarkoituksena lisätä ohjelmaan täysin uutta toiminnallisuutta graafien käsittelyyn ja havainnollistamiseen Projektin laajuus Projektin pohjana toimii olemassa oleva apptopinv-ohjelma, joka sisältää useita toimintoja graafien ominaisuuksien käsittelyyn. Projektin puitteissa on annetusta ohjelmasta tarkoituksena luoda uusi versio, jossa kaupallinen LEDA-apukirjasto on korvattu. Tähän tarkoitukseen käytämme vapaasti saatavilla olevaa GTL-kirjastoa, joka sisältää risteämäarvojen laskemiseen tarvittavia apufunktioita, kuten graafin taso-ominaisuuden testauksen. Lisäksi ohjelmaan on tarkoituksena tuoda uusia algoritmeja, jotta niiden tehokkuutta graafien risteämäarvojen laskemisessa voidaan tutkia. Projektin tavoitteisiin kuuluu myös tulosgraafien visualisoinnin mahdollistaminen. Yleisellä tasolla pyrimme lisäksi muokkaamaan apptopinv-ohjelmasta nykyistä selkeämmän. Jatkokehittelyä silmällä pitäen on tarkoituksena erottaa apukirjaston tarjoamat palvelut selkeästi muusta ohjelmasta Ohjelmiston tärkeimmät toiminnot 3

4 Ohjelmiston toiminta voidaan jakaa karkeasti kolmeen osaan; graafin lukeminen tiedostosta tai satunnainen generointi, haluttujen arvojen laskeminen ja tulosgraafin havainnollistaminen. Näistä tärkeimpänä voidaan pitää arvojen laskemista Tehokkuus- ja toiminta-asiat Ohjelman tehokkuus ei saisi juurikaan laskea aikaisemmasta versiosta. Graafien käsittelyyn tarvittavan ajan tulee pysyä järkevissä puitteissa. Ohjelman toiminnan oikeellisuus on myös tärkeää. Suurempienkaan syötegraafien kohdalla ei ongelmia saisi esiintyä, vaikka kyseisen vaatimuksen täydellinen testaaminen onkin melko mahdotonta. Virheellisten tulosten esiintyminen vie mielekkyyden esimerkiksi eri algoritmien tehokkuuden vertailusta Hallinta- ja tekniset rajoitukset Hallinnan osalta ovat voimassa normaalit projektityöhön kuuluvat rajoitukset. Dokumentit, katselmoinnit ja toteutus on hoidettava annettujen päivämäärien mukaisesti. Teknisiä rajoituksia toteutuksen suhteen saattaa aiheutua pyrkimyksestä tehdä ohjelmasta useita käyttöjärjestelmiä tukeva. Laajennettavuuden tarjoaminen tulevaisuutta varten asettaa myös tiettyjä rajoja toteutukselle. 2. Osallistujat 2.1. Ryhmän rakenne Projektiryhmä on seuraava: Timo Nummenmaa, projektipäällikkö Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått 4

5 Seuraavassa taulukossa on määritelty ryhmän jäsenten vastuualueet pääpiirteittäin. Taulukko on kuitenkin vain suuntaa antava. Timo Aki Jussi Rami Harri Projektin johtaja X Suunnitelmien kirjoitus X X Ohjelman suunnittelu X X Ohjelmoinnin päävastuu X X Viikkoraporttien teko X Testaus X X X X X Koodin dokumentointi X X Koodien arviointi X X X X X Käyttöopas X X X X CVS:n ylläpito X WWW-sivujen ylläpito X Laatuvastaava X 2.2. Organisaation rakenne 2.3. Sidosryhmät Asiakas: Timo Poranen Ohjausryhmä: Timo Poranen, Timo Nummenmaa Loppukäyttäjät: Graafitutkijat 2.4. Hallinnan raportointi ja kommunikaatio Projektin etenemistä seurataan viikkoraporttien avulla. Ryhmän sisällä kommunikointi hoidetaan viikottaisissa palavereissa sekä sähköpostin avulla. Asiakkaaseen ollaan yhteydessä sähköpostin 5

6 avulla sekä kasvotusten palavereiden ja tapaamisten muodossa. Viikkopalaveri pidetään yleensä keskiviikkoisin neljästä eteenpäin. Käymme läpi projektin edistymistä sekä edellisellä viikolla asetettuja tehtäviä ja määritellään tulevia tehtäviä. Viikkoraportit, tuntikirjanpidot ja suunnitelmat ovat saatavilla projektin sivuilla osoitteessa 3. Projektin läpivientiarviot 3.1 Arviointitekniikat Arvioidaksemme projektin aikataulua, työmäärää ja kustannuksia käytimme sekä COCOMO II:ta että alkuperäistä COCOMOa vuodelta Työmäärää arvioitaessa on aluksi pyritty löytämään likiarvo olemassa olevan koodin uudelleenkäytön kustannukselle. Tätä rivimääräarviota on hyödynnetty Cocomo'88:n basic- ja intermediate- sekä Cocomo II:n early design -mallin arviointimenetelmissä COCOMO II, reuse model Projektille annettiin pohjaksi apptopinv-ohjelmisto, joten realistista työmääräarviota varten tarvitaan arvio olemassa olevan koodin muokkaamiselle. COCOMO II:n uudelleenkäyttömallilla on pyritty löytämään likiarvo muokkaamisen kustannukselle koodiriveinä. Mallia varten arvioimme muutoksen määrää ja omaa ohjelman tuntemustamme. Nimi Arvio Muuttuja Percent design modified 40 DM Percent code modified 30 CM Percent of integration required 30 IM software Assessment and Assimilation 6 AA increment Programmer unfamiliarity factor 0.8 UNFM Lisäksi arvioimme olemassaolevan koodin tasoa. 6

7 Attribuutti Arvio Numeerinen arvo Structure low 40 Application clarity nominal 30 Self-descriptiveness low 40 Ohjelman arvionnin numeeristen arvojen keskiarvosta saadaan kerroin kuvaamaan sitä, kuinka paljon työtä olemassa olevan koodin ymmärtäminen tuottaa: Software understanding increment (SU) = ( ) / 3 Muokkauksen määrän arvioinneista lasketaan painotettu kerroin, joka pyrkii mallintamaan eri muutosalueiden vaativuutta tarkemmin: Adaptation Adjustment Factor (AAF) = 0.4*DM + 0.3*CM + 0.3*IM = 34 Muutoskerrointa kuvaavan funktion kaava määräytyy AAF-arvon mukaan. Koska prosentuaalinen muutos on arvioitu alle 50 %:ksi, lasketaan kerroin kaavalla: Adaptation Adjustment Modifier (AAM) = (AA + AAF * ( * (SU)*(UNFM))) / AAM-kerroin arvioi, kuinka paljon alkuperäisestä koodimäärästä vaatii muokkausta. Pahimmillaan olemassaolevan koodin muokkaaminen saattaa yli kaksinkertaistaa työmäärän verrattuna kokonaan uuden koodin kirjoittamiseen. Muuttuja ESLOC kertoo arvion muutoksen määrästä: ESLOC = AAM * ASLOC Valmisohjelmilla laskimme, että apptopinv sisältää noin 6000 riviä koodia, eli arvioimme muutoksen seuraavasti: ESLOC = AAM * riviä koodia. COCOMOa varten arvioimme lisäksi tuottavamme noin 1000 riviä omaa koodia, joten kokonaiskoodimääräksi arvioimme: kokonaismäärä = muokaamista vastaava koodimäärä + uuden koodin määrä 4600 riviä 7

8 koodia COCOMO'88 Basic COCOMO -malli pyrkii arvioimaan projektin työmäärää koodirivien määrän (KSLOC, tuhatta riviä koodia) ja yleisen vaikeusasteen perusteella. Mallissa projektit luokitellaan vaikeutensa mukaan kolmeen luokkaan: helppo, normaali tai vaikea tehtävä. Kaavoissa esiintyvät kertoimet (A, B, C ja D) on otettu COCOMO-mallista löytyvästä suppeasta taulukosta. Arvioimme projektimme normaaliksi tehtäväksi, joten työmääräarvio MM (man month) saadaan kaavalla: MM = A * KSLOC ^ B = 3.0 * KSLOC ^ 1.12 Työmääräarviota vastaava kalenteriaika-arvio TDEV saadaan kaavalla: TDEV = C * MM ^ D = 2.5 * MM ^ 0.35 Basic COCOMO mallin mukainen projektimme työmäärä: MM = 3.0 * 4.6 ^ Vastaava kalenteriaika-arvio: TDEV = 2.5 * ^ Basic COCOMO -malli on hyvin yleisluontoinen, eikä se huomioi tarkemmin projektiin liittyviä tekijöitä. Intermediate COCOMO -malli arvioi lisäksi henkilöstöä, kehitysympäristöä ja projektia kustannuskertoimen avulla. Kustannuskertoimet saadaan arvioimalla 15 osatekijää asteikolla: very low, low, nominal, high, very high, extra high. Sanallisia arvoja vastaavat kertoimet saadaan kiinteästä taulukosta. 8

9 Kustannustekijä Arvio Numeerinen arvo Muuttuja Luotettavuusvaatimukset nominal 1 RELY Tietokannan koko nominal 1 DATA Tuotteen monimutkaisuus high 1.15 CPLX Suoritusaikavaatimukset nominal 1 TIME Muistirajoitukset nominal 1 STOR Kehitysympäristön nominal 1 VIRT kypsyystaso Kehitysjärjestelmän nominal 1 TURN 'kierrosaika' Suunnittelijoiden low 1.19 ACAP kyvykkyys Sovellusalueen tuntemus low 1.13 AEXP Ohjelmoijien kyvykkyys low 1.17 PCAP Kehitysjärjestelmän low 1.1 VEXP tuntemus Ohjelmointikielen low 1.07 LEXP tuntemus Nykyaikaisten high 0.91 MODP menetelmien käyttö Kehitystyökalujen käyttö nominal 1 TOOL Aikataulun kireys high 1.08 SCED Intermediate COCOMO -malli pyrkii tarkentamaan työmääräarviota kertomalla Basic-mallin työmääräarvion jokaisella 15 kustannuskertoimella. Saadaan uusi työmääräarvio: MM = 3.0 * 4.6 ^ 1.12 * (edellisen taulukon 1:stä poikkeavien arvojen tulo) = 3.0 * 4.6 ^ 1.12 * 1.15 * 1.19 * 1.13 * 1.17 * 1.1 * 1.07 * 0.91 * Vastaava työaika-arvio: TDEV = 2.5 * MM ^ kuukautta Projektin tarkempi analysointi Intermediate-mallilla selkeästi kasvattaa arviota työmäärästä COCOMO II Koska käytämme COCOMO II -mallin uudelleenkäytön laskentaa avuksi, lienee luontevaa laskea myös työmääräarvio sen avulla. Valitsimme käyttöön early design -mallin, joka on tietyin osin laajennettu COCOMO Intermediate, mutta toisaalla myös suppeampi. COCOMO II -malli pyrkii tarkentamaan vanhan COCOMO'88:n arvioita tuomalla käyttöön ajureita, 9

10 jotka on tarkoitus kalibroida vastaamaan omaa organisaatiota. Kalibrointi vaatisi useamman projektin tietoja, joiden avulla mallia voisi hivuttaa lähemmäksi todellisuutta. Tällaista mahdollisuutta ei tällä projektilla ole, minkä takia käytössä on 'valmiit' likiarvot ajureille julkisista lähteistä. COCOMO'88-mallissa valittiin kiinteät kertoimet A, B, C ja D hyvin suppeasta taulukosta. Uudessa versiossa eksponentit B ja D pyritään arvioimaan tarkemmin projektin luonnetta vastaavaksi. Suositeltavaa olisi myös kalibroida kertoimet A ja C vastaamaan omaa organisaatiota, mutta tähän meillä ei ole mahdollisuutta. Kertoimet A, B, C ja D ovat siis napattu suoraan julkisesta lähteestä. Kaavat ja vakiot COCOMO II -mallin mukaiseen arviointiin: MM = A * KSLOC ^ E * EM TDEV = C * PM ^ F A = 2.94 B = 0.91 C = 3.67 D = 0.28 E = B * SM F = D * (E B) EM = kustannuskertoimien tulo (seitsemän kerrointa early design mallissa) SM = skaalauskertoimien summa (viisi attribuuttia) Arvioimme skaalauskertoimet seuraavasti: Nimi Arvio Numeerinen Muuttuja arvo Precedentedness low 3.24 PREC Development Flexibility low 4.86 FLEX Architecture / Risk resolution low 3.38 RESL Team Cohesion nominal 2.97 TEAM Process Maturity nominal 2.73 PMAT Näiden avulla saamme laskettua eksponentin E: 10

11 E = B * (PREC + FLEX + RESL + TEAM + PMAT) = * = Sekä eksponentin F: F = D * (E B) = * ( ) = Kustannuskertoimet vastaavat vanhan COCOMO-mallin vastaavia. Early design -malliin on valittu seitsemän kerrointa edustamaan 17:ää post design mallin kerrointa. Nimi Arvio Numeerinen arvo Muuttuja Product reliability and complexity nominal 1 RCPX Required reuse high 1.14 RUSE Platform difficulty nominal 1 PDIF Personnel capability low 1.16 PERS Personnel experience low 1.11 PREX Facilities nominal 1 FCIL Required development schedule high 1 SCED Työmäärälle saadaan arvio: MM = A * KSLOC ^ E * (RCPX * RUSE * PDIF * PERS * PREX * FCIL * SCED) = 2.94 * 4.6 ^ * ( ) = Ja työajalle: TDEV = C * MM ^ F = 3.67 * ^ = kuukautta 11

12 3.2 Tulokset Cocomo II:n reuse-mallilla saimme likimääräisen arvion siitä, kuinka monta riviä koodia joudumme kirjoittamaan. Uuden koodin määräksi saimme noin riviä, joka tekee (920, jos projektipäällikkö lasketaan mukaan) riviä henkilöä kohden. Cocomo I:n intermediate-mallilla laskimme työmääräksi 8,42 kuukautta. Henkilöä kohden työmäärä on (8,42/4) * 21 * 7,5 332 tuntia per henkilö. Jos projektipäällikkö lasketaan mukaan, niin tuntimääräksi muodostuu noin 265 tuntia per henkilö. Cocomo II mallia käytettäessä työmäärä kasvaa vielä suuremmaksi, eli noin 9,77 kuukauteen. Tämä tekee 385 tai 308 tuntia henkilöä kohden. 4. Riskien hallinta 4.1 Projektin riskit Seuraavassa mainitaan lyhyesti riskit, joita projektissamme saatetaan kohdata. Luvussa 4.2 on esitetty samat riskit laajemmin ja taulukkomuodossa. Riskit on jaoteltu kahteen pääjaksoon: yleiset ja tekniset riskit. Yleiset riskit: Kiinteä aikataulu saattaa aiheuttaa ongelmia, esimerkiksi sairasteluiden takia. Tekijöillä on omat aikataulut, joten yhteisten tapaamisten sopiminen on kohtuullisen vaikeaa. Projekti on melko laaja ja tutkimusluonteinen. Kuinka hyvin asiakas on tavoitettavissa kysymyksiä varten? Tekniset riskit: GTL:n toiminta. GTL:n vapaasti levitettävissä oleva versio on vanha. Se sisältää bugeja. GTL:n ja apptopinv:n yhteensopivuus. Mitä tarvii apptopinv:lle tehdä, jotta GTL saadaan korvaamaan LEDA:a? Muokatun koodin testaaminen on hyvin vaikeaa. Pystymme testaamaan ohjelmointivirheet 12

13 pois, mutta funktion palautusarvoja on lähes mahdotonta testata. UTAG:n (oma graafikirjasto) toteuttamisessa syntyvät ongelmat; se pitää olla helposti muokattavissa, helppokäyttöinen ja dokumentoitu selvästi. Miten riittää aika? Graafin esittäminen graafisesti. 4.2 Riskitaulukko Seuraavassa taulukossa on kuvailtu tarkemmin riskit, joita saatamme kohdata. Jokaiselle riskille on määritetty sen todennäköisyys, vaikutus, vakavuus, havannointi ja välttäminen. Vaikutus ja välttäminen ovat kirjattu sanallisesti. Todennäköisyys, vakavuus ja havannointi on luokiteltu seuraavien numeroarvojen perusteella. Todennäköisyys: 0: Erittäin pieni 1: Pieni 2: Kohtuullinen 3: Suuri 4: Erittäin suuri Vakavuus: 0: Mitätön 1: Hallittavissa oleva 2: Vakava 3: Katastrofaalinen Havannointi: 0: Helppo 1: Keskinkertainen 2: Hankala 3: Hyvin hankala 13

14 Riskin kuvaus Yleiset riskit: Kiinteän aikataulun ongelmat (esim. sairastelu) Tekijöiden tavoitettavuus Toden- Vaikutus 3 Toiset saattavat joutua tekemään joskus ylimääräistä työtä, joitakin tapaamisia joudutaan peruumaan tai aikataulussa ei pysytä. Hankaloittaa projektin läpiviemistä. 2 Jotkut joutunevat jättämään jotain muuta väliin. Projektin laajuus 4 Projektin laajuus ja sen luonne Asiakkaan tavoitettavuus huomioon ottaen kaikkia vaatimuksia ei välttämättä pystytä täyttämään ajan puitteissa. 1 Saattaa olla, että asiakas ei ole aina tavoitettavissa kysymyksiä varten. Lisännee omaa tiedonhakua. Tekniset riskit: GTL:n toiminta 3 GTL:n vapaasti käytettävissä GTL:n ja apptopinv:n yhteensopivuus olevaa versio on vanha ja se saattaa sisältää virheitä, joten sitä joudutaan testaamaan tarkasti. 3 Apptopinv:iä saatetaan joutua muokkaamaan huomattavastikin, jotta GTL korvaisi LEDAn ongelmitta. näköi- syys Vakavuus Havannointi Välttäminen 1 0 Priorisoidaan tehtävät hyvissä ajoin 0 0 Etsitään korvaavia työskentelytapoja kasvokkain istumiselle ja tiedon jakamiselle 2 1 Pyritään hyvissä ajoin paikallistamaan mahdolliset ongelmakohdat 0 0 Yritetään hakea vastauksia ryhmänä, ei jokainen erikseen. 2 (3) 1 Testataan uusi kirjasto mahdollisimman tarkasti helpoilla syötteillä. 1 0 Löytää mahdolliset ongelmat aikaisessa vaiheessa ja tarkentaa suunnitelmaa niiden osalta. 14

15 Riskin kuvaus Muokatun koodin testaaminen UTAG:n (oma graafikirjasto) toteuttaminen. Se pitää olla mahdollisimman hyvin muokattavissa ja laajennattavissa. UTAG:n käytettävyys UTAG:n dokumentointi Graafin tallennus gml-formaatissa Graafin esittäminen graafisesti Algoritmi risteämäarvolle Todennäköisyys Vaikutus Vakavuus Havannointi Välttäminen 4 Meidän pitää vain luottaa 2 3 Hankalasti siihen, että meidän testattavien muokkaamamme koodi toimii, funktioiden sillä sitä on melko vaikea listaaminen ja testata. Virheet pystytään tarkempi poistamaan, mutta funktion dokumentaatio. palautetta ei. 3 Ulkopuolisen hankala lukea koodia. 3 Lopputuotteen hankala käyttöönotto. 3 Hankaloittaa uudelleenkäyttöä ja muokkaamista. 2 Tallennettua graafia ei saa ladattua GUI:hin. 4 Piirretty graafi ei välttämättä vastaa teoreettista mallia. Hieman sama kuin Muokatun koodin testaaminen. 1 0 Pyritään evaluoimaan ja kommentoimaan toisten koodia, yhteinen koodauskonventio 1 1 Arkkitehtuurilla pyritään löytämään ideaalirakenne aikaisessa vaiheessa. 1 1 Sovitaan alkuvaiheessa dokumentityyli, oikoluetaan toisten tekstiä. 1 0 Tarkistetaan tallennetun graafin validius valituilla formaateilla. 2 2 Yksinkertaisilla graafeilla pyritään löytämään ongelmalliset tilanteet. 5 Tätä joudutaan etsimään. 2 3 Asiakas on lupautunut auttamaan ongelman ratkaisussa ja tulosten varmentamisessa. 15

16 4.3 Yleiskuva riskien lieventämisestä, seurannasta ja hallinnasta Riskien lieventämiseksi riskejä pitää seurata. Etenkin vakavaksi määritellyt ongelmat pitää olla jatkuvassa seurannassa. Riskejä saadaan lievennettyä myös varautumalla niihin etukäteen. Jokaista riskiä tulee kuitenkin seurata tarkasti. Riskit pitää analysoida tarkasti ja suunnitella toimenpiteet niiden varalle. Seurantaan liittyy myös riskien tunnistaminen. Riskiä on vaikeampi huomata, jos sitä ei osata odottaa. Lisäksi riski saattaa osoittautua isommaksi, jos se tulee yllättäen. Riskien hallintaan liittyy lieventäminen ja seuranta. Kaikki osa-alueet ovat yhteydessä toisiinsa. Ilman hallintaa ei riskejä pystytä lieventämään tai seuraamaan. Riskien hallinta jatkuu iteratiivisesti koko projektityön ajan. Siihen kuuluu kaikki riskien tunnistamisesta arviointiin. 5. Projektin aikataulu 5.1 Projektin tehtäväjoukko Projektissa muokataan olemassa oleva graafien eräiden topologisten invarianttien laskemiseen luotua ohjelmaa, apptopinv, yleiskäyttöiseksi kirjastoksi. Pääasiallisina suunnittelukriteereinä ovat helppokäyttöisyys, laajennettavuus ja osittaisen käytön mahdollistamisen (eli tutkija voi ottaa vain ne toiminnallisuudet, jotka ovat tilanteeseen nähden tarpeelliset). Ohjelmassa aiemmin käytössä ollut kaupallinen kirjasto, LEDA, poistetaan ja se korvataan jollakin vastaavalla eikaupallisella graafikirjastolla. Tämän lisäksi projektissa rakennetaan useita uusia graafialgoritmeja graafin risteävyyslukujen minimoimiseen. Lisäksi luodaan mahdollisuudet tallettaa graafit sellaisessa muodossa, että niitä voidaan visualisoida jollain kolmannen osapuolen ohjelmistolla. Nimetyt tehtävät jaetaan kahteen eri kategoriaan. Pakolliseen kategoriaan katsotaan kuuluvan edellä mainitut arkkitehtuurillinen uudelleenjärjestäminen, kaupallisen LEDA-kirjaston korvaaminen ja muutaman tärkeimmän uuden graafialgoritmin lisääminen kirjastoon. Muut toiminnallisuudet järjestetään tärkeysjärjestykseen ja niistä pyritään toteuttamaan mahdollisimman moni projektin määräaikaan mennessä. Projektissa käytetään perinteisen vesiputous-tuotantomallin laajennettua versiota, jossa jokaisen 16

17 vaiheen (vaatimusmäärittely, analyysi ja suunnittelu, toteutus, testaus, ylläpito) aikana suoritetaan vaiheiden validointi ja varmennus ja tarvittaessa palataan mallin ylemmille kerroksille tekemään muutoksia prosessiin. Projektin luonne huomioiden voidaan projektin aikana nähdä tapahtuvan kaksi erillistä toteutus- ja testausvaihetta. Ensimmäisessä osassa järjestetään olemassaoleva koodi uudestaan sekä korvataan LEDA-kirjasto ja jälkimmäisessä osassa toteutetaan uudet ominaisuudet. Projekti voidaan katsoa ajallisesti jakautuvan kolmeen eri vaiheeseen. Ensimmäisessä vaiheessa projekti käynnistetään, laaditaan suunniteluraportti ja vaatimusmäärittelu sekä tutustutaan olemassa olevaan lähdekoodiin (vaatimusmäärittely ja analyysi). Toisessa vaiheessa laaditaan arkkitehtuuri- ja testaussuunnitelma. Olemassa oleva lähdekoodi muutetaan vastaamaan suunnitelmia. Toisessa vaiheessa LEDA myös korvataan valitulla kirjastolla ja näin saatu kokonaisuus testataan ja varmistetaan toimivaksi (suunnittelu, toteutus, testaus). Toiseen vaiheen loppupuoliskolla aloitetaan laatimaan toteutussuunnitelmaa. Kolmannessa vaiheessa toteutetaan uusia graafialgoritmeja ja kirjaston laajennuksia aikataulun suomissa puitteissa (toteutus, testaus, ylläpito). 5.2 Toiminnallinen ositus I - vaihe (syksy 2004): Laaditaan projektisuunnitelma Laaditaan vaatimusmäärittely Tutustutaan olemassa olevaan koodiin Etsitään vaihtoehto LEDA-kirjastolle II - vaihe (joulukuu maaliskuuta 2005): Toteutussuunnitelma Muodostetaan arkkitehtuurisuunnitelma Muutetaan olemassa oleva koodi arkkitehtuuria vastaavaan muotoon Korvataan LEDA valitulla vaihtoehdolla Testataan kirjaston toimivuus 17

18 III - vaihe (maaliskuu toukokuu 2005): Testaussuunnitelma Lisätään vaiheittain valitut algoritmit Rakennetaan kirjastoon lisäosia, mm. tulostus & tallennus Visualisointi (l. graafin tallennus koordinaattien kera eri tiedostomuodoissa) Testaus 5.3 Tehtäväverkko Tehtäväverkko kuvaa projektin riippuvuussuhteita ja kulkua hyvin yleisellä tasolla. Tehtäväverkko tarkentuu huomattavasti ensimmäisen vaiheen aikana ja etenkin vaatimusmäärittelyn valmistuttua. Tehtäväverkkoa päivitetään jatkuvasti läpi koko projektin. Tehtäväverkko on näkyvissä liitteissä (Liite 1). 5.4 Aikataulukuvaaja Aikataulukuvaaja esittää projektin yleisen kulun ja eri vaiheiden sijoittumisen ajalliseen kehykseen. Kuvaaja on alustava ja hyvin yleisluonteinen, mutta se tulee tarkentumaan läpi koko projektin ajan päivitysten yhteydessä. Projektin kotisivuilla julkaistaan myös tarkemmat viikkoihin jaksotetut kuvaajat, joista käy myös ilmi, missä vaiheessa kukin tehtävä etenee. Projektisuunnitelma Koodiin tutustuminen LEDAn korvaaja Vaatimusmäärittely Testaussuunnitelma Toteutussuunnitelma Arkkitehtuurisuunitelma I toteutusvaiheen toteutus Korvataan LEDA I toteutusvaiheen testaus Uusien Algoritmien lisäys Muut laajennukset Visualisointi Testaus I Vaihe II Vaihe III Vaihe Virstanpylväs 18

19 6 Seuranta- ja kontrollointimekanismit 6.1 Laadunvarmistus ja kontrollointi Projekti pyritään raportoimaan suhteellisen tarkasti. Tuotetuista dokumenteista järjestetään katselmointeja. Ainakin projektisuunnitelmasta, vaatimusmäärittelystä sekä toteutus- ja testaussuunnitelmasta järjestetään katselmointi. Niiden tavoitteena on löytää virheet, väärinkäsitykset ja ongelmat mahdollisimman varhaisessa vaiheessa. Katselmointien ansiosta projektista tulee myös hallittavampi. Lisäksi koodin osista olisi hyvä järjestää katselmoinnit, mutta näitä asioita ei ole vielä lyöty lukkoon. Alla olevassa taulukossa on listattu kaikki pakolliset katselmoinnit ja osallistujien roolit. Projektisuunnitelman katselmointi järjestetään Muista päivämääristä ei ole vielä päätetty. Sulkeisiin on merkitty takaraja kyseiselle katselmoinnille, mutta ne tullaan pitämään joitakin päiviä ennen takarajaa. Katselmointi Päivämäärä Harri Rami Jussi Aki projektisuunnitelma sihteeri puheenjohtaja esittelijä vaatimusmäärittely sihteeri puheenjohtaja esittelijä testaussuunnitelma ( ) esittelijä sihteeri puheenjohtaja toteutussuunnitelma ( ) puheenjohtaja esittelijä sihteeri Katselmointien roolit: Puheenjohtaja: Puheenjohtaja johtaa katselmointia. Hän pitää myöskin kiinni aikataulusta, eli toisin sanoen yrittää hillitä puhujia, estää rönsyilyä tai vaihtoehtoisesti kannustaa keskustelemaan. Tiedottaa katselmoinnista vähintään viisi arkipäivää ennen tilaisuutta ja jakaa asialistan, mahdollisen tarkastuslistan ja muun taustamateriaalin. Esittelijä: Esittelee kokonaisuuden ja sitten kunkin osan lyhyesti. Esittelee käyttötapaukset ja varmistaa, että osallistujilla on sama näkemys tapauksista. Sihteeri: Kirjaa löytyneet ongelmakohdat. Lisäksi projektilla on laatuvastaava. Projektimme laatuvastaava on Harri Smått. Projektin etenemisestä laaditaan myös viikkoraportit, joiden avulla kurssin vetäjäkin pystyy seuraamaan projektin kulkua. 19

20 6.2 Muutosten hallinta ja kontrollointi Jokainen mahdollinen muutos kontrolloidaan tarkasti. Mahdolliset muutokset suunnitelmiin saattavat koskea esimerkiksi LEDA-kirjaston korvaajaa. Jokainen ehdotettu muutos analysoidaan tarkasti ja toteutetaan, jos se on mahdollista tai tarpeellista. Dokumentit ja koodit versioidaan ja projektin edetessä niitä tullaan muokkaamaan. Tähänkin dokumenttiin tulee varmasti muutoksia tulevaisuudessa. Vanhatkin versiot dokumenteista tullaan kuitenkin pitämään arkistossa. 20

21 7. Liitteet Liite 1 (Tehtäväverkko): 21

22