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

Transkriptio

1 Loppuraportti 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 Ensimmäinen luonnos Toinen luonnos Ensimmäinen

3 Sisältö i 1 Johdanto 1 2 Projektin tehtävä ja tavoite 1 3 Projekti Projektin kulku Aikataulu Projektin alku Määrittely ja vaatimukset Suunnittelu Toteutus Testaus Käyttöönotto Toteuttamatta jääneet ominaisuudet Dokumentointi Arvio projektista Hyvät puolet ja onnistumiset Vaikeudet ja epäonnistumiset Käytetyt menetelmät Käytetyt työkalut Projektityöskentely Projektiryhmä Yhteistyö Työnjako Yhteydenpito Työn määrä ja jakautuminen eri vaiheisiin Ohjaaja ja projektin vastuuhenkilöt Asiakas Yhteenveto 8

4 1 Johdanto 1 Ohjelmistotuotantoprojekti Populous toteutettiin syksyllä Projektin pohjana oli HIITperustutkimusyksikössä käytössä ollut populaatiosimulaattori, josta suunniteltiin ja toteutettiin osittain uusi toteutus osin vanhaa ohjelmistoa hyödyntäen. Tämä raportti sisältää kuvauksen projektin vaiheista ja toiminnasta sekä arvion projektityöstä kokonaisuutena. 2 Projektin tehtävä ja tavoite Erilaisten geenikartoitusmenetelmien ja genomin rakenteen selvittämiseen tarkoitettujen menetelmien testaamisessa simuloidut aineistot ovat välttämättömiä. Simulointiprosessin lähtökohtana on tyypillisesti yksi populaatioisolaatti. Populaatio koostuu pienestä joukosta yksilöitä, joista populaatio kasvaa annettuun loppukokoon saakka. Simulaatio jäljittelee perusjoukon geenien periytymistä jälkeläisille ja sukupolvelta toiselle laajenemisprosessin kuluessa. Tavoitteena oli toteuttaa populaatioiden simulointiin käytetty ohjelmisto osittain uudestaan. Entisen populaatiosimulaattorin toiminnassa ilmenneet ongelmat olivat lähtökohtana Populous-projektille. Vanha simulaattori oli tehty väitöskirjatyön pohjalta ja sitä on muokattu moneen kertaan. Projektissa tuotettavan ohjelmiston avulla halutaan selkeyttää populaatioiden simulointia. Aikaisempi toteutus koostui neljästä erillisestä osasta: genped, chrom, simco ja markertool, sekä näien lisäksi skripteistä, joilla niiden toiminta on yhdistetty. Projektin tavoitteena oli toteutettaa korvaava ohjelmisto kahdelle ensimmäiselle osalle (genped ja chrom) sekä yhdistää kaikki toiminnallisuus yhteen ohjelmistoon, jolloin skriptejä ei enää tarvittaisi. Lisäksi oli tavoitteena laatia käyttöliittymä ohjelmiston käytön helpottamiseksi. 3 Projekti Tässä luvussa käsitellään projektin eri vaiheita ja arvioidaan niiden sujumista. 3.1 Projektin kulku Projektin kulku jaettiin vesiputousmallin mukaisesti neljään vaiheeseen: määrittely, suunnittelu, toteutus ja testaus. Alussa vaiheista ja aikataulusta pidettiin tiukasti kiinni, mutta loppua kohti kiire hämärsi eri vaiheiden rajoja ja siirsi niiden päättymitä.

5 Aikataulu Projekti alkoi viikolla 37 ( ) ja kesti 13 viikkoa, aina viikolle 50 asti ( ). Kokonaistyömäärän arvioitiin päätyvään opintoviikkojen mukaiseen 240 tuntiin opiskelijaa kohden, eli arviolta tuntia viikossa. Aikataulun laatimisessa käytettiin hyväksi valmiiksi annettua aikatauluehdotusta, jossa projektin alkuvaiheille varattiin suurin osa projektin ajasta. Määrittelyvaihe saatiin tehtyä suunnitellussa kolmessa viikossa, mutta suunnitteluvaiheen ensimmäisen välivaiheen myöhästyminen hidasti toteutusvaiheeseen siirtymistä. Toteutukselle oli varattu kolme viikkoa, joka osoittautui riittämättömäksi suhteessa suunnittelun laajuuteen. Testaus- ja käyttöönottovaiheet sulautuivat ajanpuutteen vuoksi toteutusvaiheeseen Aikataulussa pyrittiin varautumaan todennäköisiin riskeihin, kuten ryhmän jäsenten poissaoloihin. Osa riskeistä toteutui, mutta niillä ei ollut kovinkaan suuri vaikutus projektin edistymiseen. Kaikkiin toteutuneisiin riskeihin ei kuitenkaan pystytty varautumaan riittävän hyvin, mikä aiheuttikin turhan kireän aikataulun projektin loppuvaiheessa Projektin alku Projekti alkoi varsin ripeästi. Ensimmäisen viikon aikana saatiin ryhmän yleiset asiat sovittua. Asiakas esitteli projektin taustan ja tavoitteet toisella tapaamisella, ja vaatimusmäärittely saatiin alulle toisella viikolla. Aikataulu ja projektisuunnitelma valmistuivat vaatimusmäärittelyvaiheen alkussa, ja projekti saatiin kunnolla käyntiin Määrittely ja vaatimukset Määrittelyvaiheen aikana asiakas osallistui kahteen ryhmätapaamiseen, ja näiden lisäksi vastasi sähköpostilla määritystä tehdessä heränneisiin kysymyksiin. Lähes joka tapaamisessa oli koko ryhmä paikalla. Vaatimusmäärittelyn tekeminen aloitettiin projekin toisella viikolla ja sen ensimmäinen versio valmistui ajallaan kahden viikon kuluessa. Korjaukset tähän tehtiin samoin aikataulun mukaisesti viikossa. Vaatimusmäärittelyyn pyrittiin saamaan mahdollisimman selkeä kuvaus nykyisestä järjestelmästä suunnittelua varten. Vaatimukset kartoitettiin pääasiassa käyttötapausten kautta Suunnittelu Suunnittelun pohjana käytettiin määrittelydokumentissa kuvattua yleistä arkkitehtuurisuunnitelmaa. Suunnitteluvaihe alkoi määrittelydokumentin ensimmäisen version valmistuttua projektin neljännellä viikolla. Koko vaiheen aikana kaikki suunnittelu tehtiin suunnitteludokumentin työstämisen ympärillä, keskittyen liikaakin vain dokumentin tuottamiseen eikä itse toteutuksen suunnitteluun. Suunnitteludokumentti jaettiin vastuualueittain ryhmän jäsenten kesken.

6 Suunnitteluvaiheen pääpaino oli arkkitehtuurin suunnittelulla ja ohjelmiston käyttöliittymäpuolella. Ohjelmiston simuloinnin toiminnallisuuden suunnitelma jäi pintapuoliseksi, sen toteuttamisen oletettiin olevan suhteellisen suoraviivaista vanhan ohjelmiston lähdekoodia apuna käyttäen. Käyttöliittymä suunniteltiin huolellisesti käyttäen apuna Helsingin yliopiston Tietojenkäsittelytieteen laitoksen ja Interactan yhteistyössä kehittämää Goal Derived Design -suunnitteluprosessia (GDD). Suunnittelussa varauduttiin arkkitehtuuria myöten toissijaisten ominaisuuksien helppoon karsimiseen mikäli näiden toteuttamiseen ei olisi aikaa. Alunperin todennäköisesti toteuttamatta jätettäviksi osioiksi arvioitiin palvelinkomponentti ja tähän yhteydessä oleva graafinen asiakasohjelmisto. Ohjelmisto suunniteltiin hierarkisella rakenteella, jossa jokaisen kahden kerroksen välillä oli yksi yhtenäinen rajapinta. Näin ohjelmiston kaikki ydintoiminnot saatiin keskitettyä komponentin omaiseksi kokonaisuudeksi, jota pystyisi käyttämään mitä erilaisimmista käyttöliittymistä Toteutus Toteutusvaihe oli tarkoitus aloittaa heti kun suunnitteludokumentin ensimmäinen versio olisi valmis. Nimellisesti vaihe aloitettiinkin ajallaan, mutta rungon lisäksi varsinainen toteutus alkoi myöhässä. Toteutuksen jako ryhmän jäsenten kesken tehtiin suunnitteludokumentin vastuualueiden mukaan. Ennakoitua vaikeammaksi osoittautunut simuloinnin toteutus osallaan viivästytti ohjelmiston valmistumista, ja osa suunnitelluista toissijaisista ominaisuuksista jouduttiin karsimaan: graafinen käyttöliittymä ja siihen tiiviisti sidoksissa ollut hajautuksen mahdollistava asiakas-palvelin-mallin liittymä ytimeen jäivät prototyyppiasteelle. Tähän oltiin varauduttu jo suunnitteluvaiheessa, eikä niiden poisjättämisen vaikuttanut muun ohjelman toiminnallisuuteen tai vaatinut suuria muutoksia pääohjelmassa. Lopulta toteutusvaihe venyi yhdessä testauksen kanssa aivan projektin loppuun saakka. Toteutuksen laajuus saatiin kiinnitettyä ajallaan toteutusvaiheen alkuperäiseen määräaikaan mennessä, mutta osa toiminnallisuudesta ja toteutusdokumentti oli kireän aikataulun takia jätettävä myöhemmäksi. Ensimmäisen yksinkertaisen testitapauksen kokonaisuudessaan suorittavan ohjelmiston versio saatiin valmiiksi vasta toteutusvaiheen jälkeen Testaus Testausvaihe sulautui käytännössä toteutusvaiheeseen. Testauksessa suunniteltiin käytettävän yksikkötestaustyökaluja, mutta tämän toteuttamiseen ei jäänyt aikaa. Pitkälti testaus toteutettiinkin toteutuksen yhteydessä kokeilemalla tuotettavaa koodia eri parametreilla. Järjestelmätestaukseen käytettiin valmiita testitapauksia, sekä luotiin joitakin uusia erikoisempia testitapauksia. Ohjelmiston tuotteiden oikeellisuuden tarkistukseen tehtiin tarkistusohjelmia, sekä niitä pyrittiin tulkitsemaan silmämääräisesti mahdollisia virheitä etsien.

7 Käyttöönotto Projektiryhmä ei asentanut tuotetta lopulliseen ympäristöönsä, vaan käyttöönoton otti asiakas hoitaakseen. Käyttöönottoa ja ympäristön toimivuuden testaamista varten luotiin käyttötapauksista valmiit parametritiedostot, joiden avulla testiajoja voidaan vaivatta suorittaa. 3.2 Toteuttamatta jääneet ominaisuudet Suunnittelussa otettiin huomioon lähes kaikki toivotut ohjelmiston ominaisuudet, niin ensisijaiset kuin vapaaehtoiset vaatimuksetkin. Suunnitteluvaiheessa pyrittiin huomioimaan mahdollisesti poisjääviä ominaisuuksia, ja nämä ovatkin suunniteltu jopa yksityiskohtaisemmin kuin varmasti toteutettavat osuudet. Suurin lopullisesta toteutuksesta jätetty ominaisuus oli graafinen käyttöliittymä. Käyttöliittymä olisi suunnitelmien mukaan ollut yhteydessä palvelinsovelluksiin, joissa varsinainen simulointi olisi tapahtunut. Aika ei kuitenkaan lopulta riittänyt kaiken tämän toteuttamiseen, vaan käyttöliittymä ja palvelin jäivät toimimattomiksi prototyypeiksi. Suunnittelun pohjalta on kuitenkin mahdollista toteuttaa nämä puuttuvat ominaisuudet jälkikäteen. Graafisen asiakkaan ja palvelimen poisjääminen tarkoittaa myös, että niitä käyttäen toteutettava simuloinnin hajautus jäi myös suunnitteluasteelle. Kaikki nämä toteuttamatta jääneet ominaisuudet olivat toissijaisia vaatimuksia. 3.3 Dokumentointi Osittain projektin käyttämästä vesiputousmallista johtuen dokumentoinnilla oli ehkä liiankin suuri rooli projektin tuottamisessa. Varsinkin suunnitteluvaiheessa dokumentin tuottaminen oli jopa tärkeämmässä asemassa kuin itse projektin suunnittelu. Dokumentoinnissa käytetty LaTeX-järjestelmä ei ollut projektin jäsenille ennestään tuttu, mikä osaltaan lisäsi dokumentoinnin hankaluutta ja vähensi sen mielekkyyttä. Dokumentointi oli raskasta, eikä riittävän hyväksi saatuja mutta jossain määrin virheellisiä tai vajaita tietoja korjattu riittävästi. 3.4 Arvio projektista Yleisesti ottaen projekti onnistui kohtalaisen hyvin. Tarkempi erittely projektin onnistumisista ja epäonnistumisista on käsitelty aliluvuissa. Lisäksi tässä luvussa arvioidaan projektin puitteita.

8 Hyvät puolet ja onnistumiset Projektin alkupuoli sujui hyvin ja aikataulussa pysyttiin. Määrittely saatiin tehtyä riittävällä tarkkuudella, eikä määrittelydokumenttia jouduttu jälkikäteen juurikaan korjaamaan. Määrittelyn pohjalta saatiin helposti tehtyä toimiva ohjelmiston arkkitehtuuri. Toteutusvaihe sujui sille varatusta lyhyestä ajasta ja suunnittelun liiallisesta suppeudesta huolimatta hyvin; ohjelmiston tärkeimmät toiminnallisuudet saatiin toteutettua, ja toteuttamatta jäivät ainoastaan toissijaiset ominaisuudet, joiden arveltiin jo suunnitteluvaiheessa olevan mahdollisesti liian työläät toteuttaa aikataulun puitteissa Vaikeudet ja epäonnistumiset Suunnitteluvaiheelle varattu pitkä aika sai ryhmän toimimaan turhankin tehottomasti suunnitteluyksityiskohtien hiomiseksi. Suunnitteluvaihe jäi yleisen arkkitehtuurin vakiintumisen jälkeen aika yleiselle tasolle, ja keskittyi liikaa dokumentin tuottamiseen suunnittelun sijaan. Tämä kostautui toteutusvaiheessa kun osaa ohjelmiston toiminnoista ei oltu suunniteltu riittävällä tarkkuudella, vaan ne piti suunnitella vielä jo muutenkin liian lyhyen toteutusvaiheen aikana. Toteutusvaiheen venyessä myös ohjelmiston testaaminen jäi liian vähäiseksi. Testauksen suunnittelu jäi suunnitteludokumentin tapaan hyvin yleiseksi, eikä siinä mainittua yksikkötestausta saatu suoritettua suunnitellussa laajudessa. Ohjelmistoa on kuitenkin testattu hyvin paljon toteutuksen ohessa, ja lisäksi testausvaiheen aikana on käyty läpi hyvin monta eri testitapausta. Testitapauksien sisältö ja tulosten raportointi on käsitelty testausdokumentissa 3.5 Käytetyt menetelmät Projektissa käytetty vesiputousmalli ajoi asiansa, mutta jokin inkrementaalinen ja kevyempi malli olisi mahdollisesti ollut toimivampi valinta. Tällöin nyt toteutusvaiheessa havaitut yllättävät tekniset ongelmat olisivat tulleet vastaan jo huomattavasti aikaisemmin projektissa, ja niihin olisi voitu reagoida paremmin, mahdollisesti suunnittelua ja määrittelyä muuttamalla. 3.6 Käytetyt työkalut Projektiryhmällä ei ollut yhteisesti sovittua käytössä olevaa kehitysympäristöä, vaan jokainen sai kehittää ohjelmistoa haluamassaan ympäristössä. Lopullinen toimintaympäristö oli tietojenkäsittelytieteen laitoksen Linux, jossa ohjelmiston kehitystyökaluina olivat g++-kääntäjä ja make. Nämä työkalut koettiin riittävän hyviksi, tosin tottumattomalle hyvin karuiksi. Dokumenttien ja lähdekoodin versionhallintaan käytettiin CVS:ää, jonka käyttö koettiin varsinkin projektin alkupuolella hankalaksi. Useamman henkilön saman tiedoston yhtä-

9 aikainen käsittely olisi saanut olla järjestetty jotenkin paremmin; CVS:n kanssa piti olla hyvin varovainen että ei vahingossa hävitä toisen päivitystä, ja versioiden yhdistäminen näissä tilanteissa oli varsinkin tiukalla aikataululla turhauttavaa. LaTeX dokumentointityökaluna oli riittävä, mutta ei sekään mikään paras mahdollinen. Kenelläkään ryhmässä ei ollut aikaisempaa kokemusta LaTeX:n käytöstä, ja alkuvaiheen dokumentoinnissa menikin turhan suuri osa ajasta työkalun opetteluun 6 4 Projektityöskentely Tässä luvussa kuvataan ja arvioidaan projektiryhmän työskentelyä ja projektin osapuolten toimintaa. 4.1 Projektiryhmä Projektiryhmässä oli neljä jäsentä, joka on kohtalaisen vähän ohjelmistotuotantoprojektin ryhmälle. Tässä luvussa arvioidaan projektiryhmän työskentelyä, niin yksilöiden työskentelyä kuin kokonaisuuden toimivuuttakin Yhteistyö Ryhmähenki oli kohtalaisen hyvä. Ryhmän viikottaisista tapaamisista pidettiin hyvin kiinni, eikä niistä oltu poissa tai myöhässä ilman hyvää syytä. Projektin ulkopuolella ryhmän jäsenet eivät olleet yhteydessä toisiinsa. Jokainen teki oman osuutensa jokseenkin omissa oloissaan eikä siten myöskään häirinnyt toisten työntekoa. Ongelmatilanteissa toisia ryhmän jäseniä autettiin eikä ketään jätetty pulaan Työnjako Tehtävät jaettiin tasaisesti kaikkien ryhmän jäsenten kesken, eikä työmäärässä syntynyt kovinkaan suuria eroja ryhmän jäsenten kesken. Työmäärä painoittui liiaksi työn loppuvaiheeseen, mutta jokaisella ryhmän jäsenellä oli projektin aikana jonkinasteinen tyhjäkäyntivaihe, jolloin tehtäviä ei ollut tarpeeksi Yhteydenpito Projektiryhmä kokoontui kaksi kertaa viikossa ryhmätapaamiseen, joissa oli yleensä koko ryhmä koolla. Näiden lisäksi järjestettiin erillinen mm. arkkitehtuurin suunnitteluun aikataulussa pysymiseksi. Tapaamisten ulkopuolella hoidettiin kommunikointi sähköpostilla. Yhteydenpitoa olisi toivottu olevan enemmänkin, mutta sen määrä koettiin kuitenkin riittäväksi projektin tekemisen kannalta.

10 Viikot: Yht. Heli Markus Olli Ville Yhteensä Vaihe Työtunnit Projektisuunnitelma 36 Vaatimusmäärittely 111 Suunnittelu 213 Toteutus 271 Testaus 80 Käyttöönotto 1 Loppuraportti 13 Muut 195 Taulukko 1: Työtuntien jakautuminen ajallisesti Taulukko 2: Työtuntien jakautuminen vaiheisiin Työn määrä ja jakautuminen eri vaiheisiin Projektisuunnitelmassa oli varattu projektin käyttöön 960 tuntia, eli 240 tuntia jäsentä kohti. Projektiin käytettiin lopulta 920 tuntia, eli jonkin verran vähemmän kuin oli varauduttu. Projektin työtuntien jakautuminen ajallisesti viikoittain on esitetty taulukossa 1 ja jakautuminen projektin eri vaiheisiin taulukossa Ohjaaja ja projektin vastuuhenkilöt Projektin ohjaajana toimi Jenni Valorinta. Ohjaaja osallistui jonkin verran projektin hallinnollisten asioiden järjestelyyn projektin alkupuolella, ja piti ryhmän tietoisena aikataulusta tarpeen vaatiessa. Antoi hyvin palautetta projektin edistymisestä ja oli myös aktiivisesti mukana käyttöliittymän kehittämisessä. Projektin vastuuhenkilöt Juha Taina ja Turjo Tuohiniemi eivät osallistuneet suoraan projektiryhmän toimintaan. 4.3 Asiakas Projektin asiakas oli Petteri Hintsanen, joka antoi suhteellisen vapaat kädet ohjelmiston suunnitteluun ja toteutukseen. Asiakas antoi ryhmälle tarpeelliset taustatiedot aiheesta ja vastasi koko projektin ajan ryhmässä heränneisiin kysymyksiin nopeasti ja tyhjentävästi. Antoi myös arvokasta palautetta määrittely- ja suunniteludokumenteista ja oikaisi väärin ymmärrettyjä tai ilmaistuja asioita, ehkäisten mahdollisesti suuria ongelmia projektin

11 8 myöhäisemmässä vaiheessa. 5 Yhteenveto Ryhmän jäsenet pitivät projektia kohtalaisen hyvin onnistuneena. Projektin ydintoiminnallisuus saatiin toteutettua ja dokumentoitua, ja toissijaisten vaatimusten mukaisia toiminnallisiakin saatiin hyvin pitkälle suunniteltua ja prototyypattua mahdollista jatkokehitystä ajatellen. Kaikki ryhmän jäsenet olivat hyvin sitoutuneita projektiin. Projekti koettiin opettavaisena, joskaan ei täysin työelämää vastaavana, kokemuksena ohjelmistotuotantoprojektista ja ryhmätyöskentelystä.