Projektisuunnitelma. Populous. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Transkriptio

1 Projektisuunnitelma Populous Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 Kurssi Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Heli Borg Markus Heinonen Ville Luolajan-Mikkola Olli Orajärvi Asiakas Petteri Hintsanen Johtoryhmä Juha Taina Turjo Tuohiniemi Kotisivu Versiohistoria Versio Päiväys Tehdyt muutokset Päivitetty aikataulua Päivitetty versio Ensimmäinen versio Viimeinen luonnos Toinen luonnos Ensimmäinen luonnos

3 Sisältö i 1 Johdanto Työn aihepiiri Toteutettava tuote Organisaatio Projektiryhmä Projektin ohjaaja Projektin johtoryhmä Asiakas Vastuut Työn yleiskuvaus Osajärjestelmät Liitynnät muihin järjestelmiin Toteutusympäristö Ohjelmiston vaatimukset Kokoarvio LOC FP Aikataulu Vaiheet Projektisuunnitelma Vaatimusmäärittely Suunnittelu Toteutus Testaus Käyttöönotto Loppuraportti Aikajaksot Määräajat Työskentelytavat 7

4 ii 5.1 Kokoukset Bugien raportointi Riskianalyysi Suuri riski Mahdollinen riski Pieni riski Muuta Tuotettavat dokumentit

5 1 Johdanto 1 Tämä dokumentti kuvaa Helsingin yliopiston tietojenkäsittelytieteen laitoksen syksyn 2004 ohjelmistotuotantoprojektin Populous suunnitelman. Dokumentti on tarkoitettu pääasiassa ryhmän itsensä, asiakkaan ja projektin vastuuhenkilöiden luettavaksi. Kuvattuna ovat projektin tavoitteet, organisaatio, aikataulu ja yleisen tason suunnitelma projektn toteuttamiseksi. Tätä dokumenttia tullaan päivittämään tarpeen mukaan projektin edistyessä. 1.1 Työn aihepiiri Erilaisten geenikartoitusmenetelmien ja genomin rakenteen selvittämiseen tarkoitettujen menetelmien testaamisessa simuloidut aineistot ovat välttämättömiä. Simuloinnin kohteena on tyypillisesti ns. populaatioisolaatti: populaatio koostuu alkutilanteessa pienestä joukosta perustajayksilöitä, jonka jälkeen populaatio kasvaa tietyn ajan määriteltyyn loppukokoon saakka. Simulaatiossa jäljitellään perustajajoukon geenien periytymistä laajenemisprosessin aikana. 1.2 Toteutettava tuote Projektin tehtävänä on korvata osia HIIT-perustutkimusyksikössä jo käytössä olevasta populaatiosimulaattorina. Tavoitteena on suoraviivaista simulaatioprosessia, suunnitella ja toteuttaa ohjelmistolle käyttöliittymä sekä parantaa prosessin toimivuutta. 2 Organisaatio Projektin organisaatioon kuuluvat projektin toteuttava projektiryhmä, projektin ohjaaja, projektin johtoryhmä sekä asiakas. Projektiryhmän vastuualueet on määritelty omassa osiossaan. 2.1 Projektiryhmä Ville Luolajan-Mikkola, luolajan@cs.helsinki.fi Heli Borg, heli.borg@cs.helsinki.fi Markus Heinonen, markus.heinonen@cs.helsinki.fi Olli Orajärvi, olli.orajarvi@helsinki.fi

6 2 2.2 Projektin ohjaaja Jenni Valorinta, 2.3 Projektin johtoryhmä Juha Taina, Turjo Tuohiniemi 2.4 Asiakas Petteri Hintsanen, 2.5 Vastuut Projektipäällikkö - Ville Luolajan-Mikkola Mittarivastaava - Olli Orajärvi Vaatimusdokumentti - Heli Borg ja Olli Orajärvi Suunnitteludokumentti - Markus Heinonen ja Olli Orajärvi Testausdokumentit, käyttöohje - Heli Borg ja Markus Heinonen HTML-vastaava - Heli Borg 3 Työn yleiskuvaus Tässä luvussa määritellään projektin arkkitehtuuri karkealla tasolla, toteutusympäristö sekä vaatimuksia ohjelmistolle. Vaatimukset tarkennetaan vaatimusmäärittelyssä ja arkkitehtuuri suunniteludokumentissa. 3.1 Osajärjestelmät Nykyisen järjestelmän osat markertool ja simco säilytetään ennallaan. Osajärjestelmien genped ja chrom toiminnallisuus yhdistetään uuteen, tässä projektissa toteutettavaan sovellukseen. Uuden sovelluksen pääosa, populous, sisältää toteutuksen simulointiin, eli luo annetuilla parametreilla sukupuun markertool:n vaatimassa muodossa ja ajaa markertool:n. Tässä osassa sovellusta tulee olemaan sekä komentorivipohjainen käyttöliittymä batch-ajoja

7 varten, että interaktiivinen tekstipohjainen ncurses-kirjastolla toteutettu käyttöliittymä. Lisäksi populous-osajärjestelmää voidaan ajaa palvelintilassa, jolloin simulaatioajoja tehdään asiakassovellusten tekemistä palvelupyynnöistä. Järjestelmän asiakassovellus toteutetaan siten, että se voi ajaa useamman simulaatioajon sarjan rinnakkain useilla eri palvelimilla. Asiakassovellukseen tehdään mahdollisuus käyttää aikaisemman ajon tulosta uusien alkuarvona, sekä määritellä luodaanko palvelinsovelluksessa pelkkä sukupuu vai prosessoidaanko se markertool:lla ja simcolla Liitynnät muihin järjestelmiin Toteutettavan sovelluksen tulostus toimii syötteenä nykyisen järjestelmän sovellukselle markertool (protokolla tarkennetaan myöhemmin). Uudessa järjestelmässä on myös voitava asettaa alkuarvot aikaisemman ajon tuloksesta, eli sovelluksen on ymmärrettävä myös markertool-sovelluksen tulostusmuoto. 3.3 Toteutusympäristö Projekti toteutetaan tietojenkäsittelytieteen laitoksen Linux-ympäristössä. Pääosa projektista toteutetaan C++-kielellä, ainoastaan erillinen asiakasohjelmisto toteutetaan Javalla. Kaikki tuotettu ohjelmakoodi säilytetään keskitetysti CVS-järjestelmässä. Ohjelmiston kehityksessä voi kukin käyttää haluamaansa kehitysympäristöä, mutta kehitys on oltava mahdollista ja luontevaa myös ilman erillistä yhtenäistä ympäristöä. Ohjelmiston koontiversiot käännetään keskitetysti kehityspalvelimella make-komennolla. 3.4 Ohjelmiston vaatimukset Tässä dokumentissa on ohjelmiston vaatimukset esitetty yleisellä tasolla, ja niitä päivitetään tarpeen mukaan. Osa tässä esitetyistä vaatimuksista on optionaalisia, mutta niitä ei ole eritelty, vaan kaikki näistä on tarkoitus suunnitella ja toteuttaa. Vaatimusten karsimisesta neuvotellaan asiakkaan kanssa erikseen. Ohjelmiston on oltava tulostukseltaan yhteensopiva nykyisen järjestelmän komponenttien markertool ja simco kanssa. Ohjelmistoon on tuotettava nykyistä komentorivipohjaista intuitiivisempi käyttöliittymä. Sovellusta on kuitenkin pystyttävä ajamaan myös pelkästään komentoriviltä batch-ajoja silmälläpitäen. Uutena ominaisuutena ohjelmistoon on toteutettava tuki alipopulaatioille, jolloin alkupopulaatio jaetaan algoritmilla haluttuun määrään osia. Alipopulaatioiden sisällä jäsenet pariutuvat kuten normaalissa isossa populaatiossa, mutta alipopulaatioiden kesken pariutuminen tapahtuu vain annetulla todennäköisyydellä.

8 Ohjelmistoa halutaan ajettavan useita kertoja peräkkäin aina edellisten tulosten pohjalta. Tätä varten on ohjelmistoon tehtävä mahdollisuus asettaa alkuarvot markertoolsovelluksen tulostuksen pohjalta. Samoilla alkuarvoilla tehtäviä ryhmäajoja on voitava suorittaa rinnakkain määritellyillä koneilla. Ohjelmistossa on voitava luoda myös pelkkä sukupuu, joka voidaan prosessoida tarpeen mukaan useampaankin kertaan rinnakkain markertool- ja simco-sovelluksilla Kokoarvio Ohjelmiston kokoa on pyritty arvioimaan sekä aikaisemman tiedon että projektisuunnitelmavaiheessa tunnettujen vaadittujen toiminnallisuuksien pohjalta. Projektiin arvioidaan käytettävän 960 työtuntia LOC Aikaisemmissa ohjelmistotuotantoprojekteissa on kukin jäsen tuottanut keskimäärin noin 600 riviä lähdekoodia LOC-menetelmän mukaan. Koska tässä projektissa sovelluksen vaativimmat osat ovat algoritmien toteuttamisessa, jäisi ohjelmiston koko alle keskimääräisen, mutta koska lisäksi asiakasohjelmisto toteutetaan Javalla, voidaan ohjelmarivien määrän päätyvän lähelle keskiarvoa. Kun ryhmässä on neljä jäsentä, on arvio ohjelmarivien määrästä siten FP Syötteiden lukumäärä (8, keskimääräinen) alkupopulaation koko loppupopulaation koko sukupolvien määrä alipopulaatioiden määrä alipopulaatioiden risteytymistodennäköisyys alkupopulaation alkuarvot markertool-sovelluksen ajo valinnaiseksi sukupuun syöttö (vain markertool:n ajamista varten) Tulosteiden lukumäärä (1, monimutkainen)

9 5 sukupuu Ulkoisten liittymien lukumäärä (1, keskimääräinen) markertool-sovelluksen ajaminen Count-total = 43 Sovituskertoimet Fi (0 = ei ollenkaan, 3 = keskimääräisesti, 5 = oleellisesti) Tietoliikenne 2 Hajautettu laskenta 2 Suorituskykyvaatimukset 2 Käyttöympäristö (aiempi kuormitus) 1 Reaaliaikainen tietojen syöttö 0 Tietojen syötön kompleksisuus 3 Tiedostojen reaaliaikainen päivitys 0 Syötteiden, tulosteiden yms. monimutkaisuus 4 Prosessoinnin kompleksisuus 5 Uudelleenkäytettävyys 4 Asennus ja käyttöönotto 2 Monta eri kohdeorganisaatiota 1 Päivitettävyys ja helppokäyttöisyys 3 Yhteensä 29 FP = 40 4 Aikataulu Projektimallina käytetään vesiputousmallia. Ohjelmiston ylläpito rajataan projektin ulkopuolelle; ylläpitoon tarvittava materiaali toimitetaan asiakkaalle valmiin ohjelmiston yhteydessä. 4.1 Vaiheet Projekti on jaettu seitsemään vaiheeseen. Jokaisen vaiheen tulos toimii seuraavaan vaiheeseen syötteenä, eikä vaiheita voidan siten suorittaa merkittävissä määrin rinnakkain Projektisuunnitelma Projektin tavoitteet, organisaatio, aikataulu sekä muita yleisiä projektiin liittyviä asioita kirjataan projektisuunnitelmaan. Suunnitelman tietoja päivitetään tarpeen mukaan projektin edistyessä.

10 Vaatimusmäärittely Kartoitetaan asiakkaan kanssa ohjelmiston vaatimukset, sidosryhmät, toiminnot, liittymät ja rajoitukset. Tuloksena saadaan määrittelydokumentti Suunnittelu Suunnitellaan ohjelmiston rakenne määrittelydokumentin pohjalta. Tuloksena saadaan dokumentti, joka kuvaa ohjelmiston arkkitehtuurin, tarvittavat algoritmit, tietorakenteet, käyttöliittymän ja testaussuunnitelman Toteutus Ohjelmisto toteutetaan suunnitteludokumentin mukaisesti. Tuloksena saadaan vaatimukset täyttävä ohjelmisto ja käyttöohje. Toteutuksen yhteydessä luodaan ohjelmiston osille testitapauksia, joita käytetään testausvaiheessa Testaus Tuotettu ohjelmisto testataan suunnitteluvaiheessa tehdyn testaussuunnitelman mukaisesti. Tuloksena saadaan testausdokumentti Käyttöönotto Ohjelmisto siirretään toteutusympäristöstä tuotantoympäristöön. Käyttöönoton jälkeen tehdään loppuraportti Loppuraportti Ohjelmiston käyttöönoton jälkeen luodaan loppuraportti yhteenvetona projektin kulusta. 4.2 Aikajaksot Vaiheet on jaettu osittain päällekäisiin aikajaksoihin. Aikajaksot on esitetty Gantt-kaaviona kuvassa 1. Jaksoille on jaettu aikaa seuraavasti: Projektisuunnitelma Vaatimusmäärittely Suunnittelu Toteutus Testaus Käyttöönotto 1,5vk 4,5vk 5vk 3,5vk 2vk 2vk

11 7 Kuva 1: Projektin aikataulu GANTT-kaaviona. 4.3 Määräajat Määräajat on laskettu aikajaksojen keston mukaan siten, että ne olisivat aina projektikokousta edeltävänä päivänä. Takaraja dokumenteille on keskiviikkona klo 14:00 ja maanantaina klo 16:00, koska niiden tutustumiseen ennen seuraavaa kokousta halutaan antaa vähintään yksi ilta- ja yksi aamupäivä aikaa. pe T1 Projektisuunnitelma ke T2 Määrittelydokumentti ma Määrittelydokumentin korjaukset ma T3 Suunnitteludokumenin FTR ma Suunnitteludokumentti ja testaussuunnitelma korjauksineen ke T4 Ohjelmiston toteutus valmis ke T5 Testausdokumentti ke T6 Loppuraportti pe Projektin takaraja 5 Työskentelytavat Ryhmällä on säännöllisiä tapaamisia, joissa jokaisen ryhmän jäsenen on syytä olla läsnä. Lisäksi voidaan tarvittaessa sopia muista tapaamisista, samoin tapaamisista asiakkaan kanssa. Tapaamisten ulkopuolella hoidetaan kommunikaatio pääasiassa sähköpostitse, mutta tarvittaessa myös puhelimitse. Ryhmän kotisivut löytyvät osoitteesta Kotisivuille liitetään tuotetut dokumentit, pöytäkirjat, ajankohtaista tietoa projektin vaiheesta, osallistujien yhteystiedot sekä linkkejä hyödyllisille ulkopuolisille sivustoille. Ryhmän kotihakemisto on /home/group/populous/, johon kaikki projektin materiaali tuotetaan. Valmiit tuotokset pidetään selvästi erillään keskeneräisistä sijoittamalla ne eri alihakemistoon. Kaikista tuotteista kopioidaan uuden version julkaisun yhteydessä kappale tuotteet-hakemistoon

12 8 siten, että versionumero sisältyy tiedoston nimeen. 5.1 Kokoukset Ryhmä tapaa säännöllisesti kaksi kertaa viikossa: tiistaisin klo 14:15-16:00 huoneessa A318 ja torstaisin klo 08:30-9:45 huoneessa C131. Näiden lisäksi järjestetään 1-2 viikon välein seurantakokous, jossa arvioidaan projektin edistymistä suhteessa aikatauluun. Jokaisen vaiheen lopussa pidetään suunnittelukokous. Suunnitteludokumentille pidetään vielä erillinen tarkastuskokous, jota varten suunnitteludokumentti on oltava toimitettu vähintään kahta päivää aikaisemmin. 5.2 Bugien raportointi Toteutusvaiheessa löydetyistä ohjelmiston bugeista raportoidaan niiden vakavuudesta ja vaikutusalueesta riippuen joko ilmoittamalla kyseisen osion vastaavalle tai koko ryhmälle. Suuremmista ohjelmiston virheistä, esim. rakenteellisista ongelmista, on syytä keskustella ryhmätapaamisissa. 6 Riskianalyysi Riskianalyysi on jaettu kolmeen osaan riskin todennäköisyyden perusteella, suuresta pieneen riskiin. Jokaiselle riskille on annettu määrittely, vaikutus (asteikolla pieni, kohtalainen, suuri, kriittinen), toiminta riskin toteutuessa sekä mahdolliset keinot ennaltaehkäisyyn ja tunnistamiseen. 6.1 Suuri riski Jäsen sairastuu Vaikutus: Pienestä kohtalaiseen sairauden pituudesta ja vakaudesta riippuen. Toiminta: Sairastuneen jäsenen tehtäviä jaetaan tarpeen mukaan muille ryhmän jäsenille. Myös sairastunut pidetään ajan tasalla projektin kehityksestä Uusien työkalujen opettelu hidastaa projektin edistymistä Vaikutus: Kohtalainen. Toiminta: Perehdytään työkaluihin tarkemmin yhdessä. Ryhmän jäsenten taidot eivät riitä suunnitellun toteuttamiseen Vaikutus: Kohtalainen.

13 Toiminta: Pyritään jakamaan tehtäviä paremmin taitoja vastaavasti, pyritään nostamaan taito riittävälle tasolle tai neuvotellaan asiakkaan kanssa ominaisuuksien karsimisesta Mahdollinen riski Huono ohjelmakoodin laatu Vaikutus: Suuri. Toiminta: Ohjelmakoodia siistittävä mahdollisuuksien puitteissa. Tunnistaminen: Vaikeuksia lukea toisten tuottamaa ohjelmakoodia, löytää virheiden aiheuttajia ja refaktoroida ohjelmistoa. Ennaltaehkäisy: Sovitaan yhteisistä ohjelmointityyleistä, noudetaan hyviä ohjemointikäytäntöjä ja puututaan asiaan heti kun siihen on aihetta Arvioitua suurempi työmäärä Vaikutus: Suuri. Toiminta: Neuvoteltava asiakkaan kanssa ominaisuuksien karsimisesta. Ennaltaehkäsy: Pyritään työmäärää arvioitaessa ottamaan huomioon mahdolliset sitä lisäävät tekijät. Aikataulu pettää Vaikutus: Suuri. Toiminta: Neuvoteltava asiakkaan kanssa ominaisuuksien karsimisesta Ennaltaehkäsy: Arvioidaan aikataulu realistisesti. Epäselvät vaatimukset Vaikutus: Kohtalainen. Toiminta: Oltava yhteydessä asiakkaaseen kunnes epäselvyydet on saatu selvitettyä. Tunnistaminen: Eri näkemyksiä vaatimuksista ryhmän sisällä, erimilisyyksiä asiakkaan kanssa Ennaltaehkäisy: Käydään vaatimukset tarkasti alusta alkaen läpi. 6.3 Pieni riski Jäsen keskeyttää Vaikutus: Kriittinen.

14 Toiminta: Jaetaan keskeyttäneen työt muille. Karsitaan tuotteen ominaisuuksia tarvittaessa. Lopputulos ei tyydytä asiakkaan tarpeita Vaikutus: Kriittinen. Toiminta: Keskustellaan asiakkaan kanssa toimenpiteistä. Ennaltaehkäisy: Hyväksytetään vaatimusmäärittely ja suunnitteludokumentti asiakkaalla. Asiakkaan vaatimusten muuttuminen Vaikutus: Kohtalainen. Toiminta: Ohjelmiston suunnitelmaa muutettava vaatimusten täyttämiseksi. Aikataulusta riippuen neuvoteltava ohjelmiston ominaisuuksien karsimisesta asiakkaan kanssa. Ennaltaehkäisy: Pyritään varautumaan erilaisiin variaatioihin ja suunnitellaan ohjelmistosta joustava. Lisäksi kartoitetaan vaatimukset ja hyväksytetään vaatimusmäärittely ja suunnitteludokumentti asiakkaalla. Laitteisto-ongelmat laitoksen koneissa (palvelin, työasemat, tulostimet) Vaikutus: Kohtalaisesta kriittiseen. Toiminta: Ilmoitettava ylläpidolle asiasta Muuta Tässä osiossa käsitellään kaikkia projektin kulkuun liittyviä mutta muihin osioihin kuulumattomia asioita. 7.1 Tuotettavat dokumentit Projektin dokumentit tehdään LaTeX-muodossa, josta luodaan PDF-versio. Projekteja pidetään ohjelmakoodin tapaan CVS-järjestelmässä kehityksen ajan. Projektisuunnitelman lisäksi tuotetaan projektin aikana seuraavat dokumentit: Vaatimusdokumentti Suunnitteludokumentti Testaussuunnitelma Käyttöohje Testausraportti Loppuraportti