WCLIQUE. Ohjelmistoprojekti. Loppuraportti

Transkriptio

1 TKK/DISKO/Tik WCLIQUE Projektiryhmä Clique WCLIQUE Ohjelmistoprojekti Versio Projektiryhmä Clique: Janne Dufva, 75008T, Juha Kähkönen, 75014C, Raine Kärkkäinen, 75016E, Juha Lehtonen, 75019J, Ossi Ouri, 75022M, Sari Salin, 75026S, Tapani Tarri 52652D,

2 WCLIQUE 1(24) Versiohistoria Versio Pvm. Laatija Kuvaus T.Tarri

3 WCLIQUE 2(24) Tämä dokumentti sisältää wclique-ohjelmistoprojektin loppuraportin. Loppuraportissa esitetään projektin toteutuminen vaiheittain, vaiheiden aikana sekä projektin lopulliset saavutetut tulokset pääkohdiltaan, projektin työskentelymenetelmät sekä jälkilaskelmat tuotteen työmäärien, kehitysaikataulun ja laatuun liittyvien tekijöiden suhteen. Edellä mainittuja loppuraportin esityksiä tarkastellaan ja vertaillaan sekä suunniteltujen että toteutuneiden tavoitteiden osalta. Lopuksi arvioidaan myös kurssin sisältöä ja toteutusta mm opetustavoitteiden suhteen.

4 WCLIQUE 3(24) Sisällysluettelo 1. Johdanto Projektissa kehitettävä tuote Projektin toteutusympäristö Projektin sidosryhmät Projektin eteneminen Suunnitteluvaihe Toteutus Toteutus Toteutus Toteutus Luovutus Lopputulokset Asiakkaan ja projektin vaatimukset Asiakkaan esittämät vaatimukset wclique-ohjelmistotuotteelle Vaatimusten toteutuminen ja tulokset Projektityöskentely Suunniteltu ja toteutunut projektin toiminta Arviot toiminnasta Jälkilaskelmat Projektin kustannukset Työmäärälaskelmat Tuotteen raportoidut laadulliset tulokset Kurssipalaute... 22

5 WCLIQUE 4(24) 1. JOHDANTO 1.1 Projektissa kehitettävä tuote Projektin tarkoituksena oli kehittää algoritmeille, jotka etsivät suurimman painottoman tai painotetun klikin eli joukon solmuja annetusta graaffista, toteuttava C-kielinen ohjelmisto. Tämä ohjelmisto on tarkoitettu tutkimuskäyttöön. 1.2 Projektin toteutusympäristö Projekti toteutettiin ohjelmistotyökurssin Tik harjoitustyönä asiakkaan, joka oli TKK:n tietojenkäsittelylaboratorio, tarpeisiin. Projektiryhmän jäsenet koostuivat joukosta disko-opiskelijoita (insinööristä diplomi-insinööriksi), jotka työskentelevät Nokia Networks Oy:n palveluksessa. Projekti toteutettiin mm em tekijöistä johtuen TKK:n ja Nokia Networks:n sekä myös projektiryhmän jäsenten yksityistiloissa ja välineillä. Ohjelmistoa kehitettiin sekä NT-, Linux- että Unix-ympäristöissä. 1.3 Projektin sidosryhmät Seuraavassa (Taulukko 1) on esitetty projektin osapuolet ja sidosryhmät sekä heidän tehtävänsä projektin suhteen kuten ne ovat myös projektisuunnitelmassa esitetty. Taulukko 1 Asiakas TKK:n Tietojenkäsittelylaboratorio, tuotteen tilaaja Prof. Patric Östergård ja työn ohjaaja TkL Harri Haanpää. Kurssin Tik henkilökunta, assistentti Pekka Isto Tehtävän toimeksianto ja vaatimusmäärittelyt sekä avustaminen algoritmien soveltamisessa. Tarjosi projektissa tarvittavan koulutuksen ja osaltaan tarjosi työvälineet ja tilat projektin osien toteuttamiseksi. Opponointiryhmä Chaos Avusti projektin toteutuksen ja tuotteen laadullisissa tavoitteissa. Projektiryhmä Clique Vastasi asiakkaalle toimitettavan tuotteen kehityksestä ja toteutuksesta. 2. PROJEKTIN ETENEMINEN Projektin toteutus suunniteltiin tapahtuvaksi vaiheittain iteratiivisesti noudattaen kurssilla edellytettyä USDP-mallia (The Unified Software Development Process), mikä on geneerinen ohjelmistokehityksen viitekehys. Projektille laadittiin seuraavanlainen prosessivaiheistus ja aikataulutus:!" Projektin suunnittelu !" Toteutus !" Toteutus !" Toteutus !" Toteutus !" Luovutus

6 WCLIQUE 5(24) Suunnitteluvaiheessa tehtiin koko projektille suunnitelma karkealla tasolla ja suunnittelu- ja seuraava vaihe suunniteltiin tarkemmin. Jokaisen edeltäneen vaiheen aikana suunniteltiin seuraava vaihe aina tarkemmin. Kussakin vaiheessa suunnitteluvaiheen jälkeen periaatteen mukaan tuli käsitellä seuraavia työvaiheita:!" vaatimusmäärittely!" toiminnallinen määrittely!" tekninen määrittely!" toteutus!" testaus 2.1 Suunnitteluvaihe Suunnitteluvaiheen ( ) päätavoitteet olivat:!" projektin organisoituminen ja käynnistäminen!" asiakasvaatimusten laatiminen projektissa toteutettavalle ohjelmistotuotteelle!" tekijänoikeussopimuksen laatiminen!" projektisuunnitelman laatiminen projektille, tarkemmin suunnitteluvaiheelle ja toteutus 1 vaiheelle!" projektin toteutuksen ja hallinnan opiskelu kurssin vaatimusten mukaisesti Projekti organisoitui säädettyyn aikaan mennessä. Käynnistyspalaveri pidettiin yhdessä asiakkaan kanssa , jolloin asiakkaan taholta saatiin asiakasvaatimukset projektissa kehitettävän tuotteen suhteen. Tämän perusteella laadittiin vaatimusmäärittelydokumentti. Tätä dokumenttia ei kuitenkaan hyväksytetty erikseen asiakkaalla, mikä oli selvä epäkohta projektin hyväksyntäkäytännössä. Asiakkaan perehtyminen vaatimusmäärittelyyn jäi tässä vaiheessa kurssin vaatimusten mukaisesti luovutetun materiaalin varaan. Tekijänoikeussopimus saatiin laadittua yhteisymmärryksessä sekä asiakkaan että projektiryhmän kesken. Alkuperäinen tavoite kehittää tuote yleiseen tutkimuskäyttöön ei tekijänoikeusmielessä aiheuttanut ongelmia määrittelyissä. Projektisuunnitelman teko sujui selkeiden kurssilla annettujen ohjeiden ansiosta tässä vaiheessa ilman suurempia ongelmia. Puutteina projektisuunnitelmaan vielä jäi siinä mainitun dokumentaation aikataulutus sekä epätäsmällinen määrittely riskienhallinnan suhteen. Lisäksi projektisuunnitelman tiivistelmä jouduttiin seuraavassa vaiheessa korjaamaan kuvaamaan projektisuunnitelman rakenteen sijasta sen sisältöä. Standardien merkitys projektin kannalta sekä tehtävien allokointi resursseittain olisi voinut olla täsmällisemmin esitetty projektisuunnitelman ensimmäisessä versiosssa. Projektin raportoinnin ja seurannan PMIX-työkalun käytössä oli vaikeuksia tässä vaiheessa samoin kuin luovutettavan dokumentaation toimittamisessa korruptoitumattomana perille TKK:n palvelimelle. Projektin kotisivulta linkki vaiheen edistymisraporttiin:

7 WCLIQUE 6(24) 2.2 Toteutus 1 Vaiheen toteutus 1 ( ) päätavoitteet olivat:!" projektisuunnitelman päivitys suunnitteluvaiheessa saadun palautteen perusteella ja jatkon tarkempi suunnittelu!" toiminnallisen määrittelyn laatiminen karkealla tasolla!" arkitehtuurisuunnittelun aloitus käyttäen hyväksi UML-notaatiota!" moduulisuunnittelun aloitus!" käyttökirjan suunnittelun aloitus!" testaussuunnittelun aloitus Projektisuunnitelmaan täydennettiin asianmukaisesti liittyvien dokumenttien valmistumisajankohdat ja määriteltiin varahenkilökäytäntö. Toiminnallinen määrittely jäi tässä vaiheessa sisällön suhteen tarkoitettua vaillinaisemmaksi. Vaiheen aikana opiskeltuja Rational Rose-menetelmää ei nähty tarkoituksenmukaiseksi ottaa käyttöön tuotteen suunnittelussa, koska suunnittelumme ei ollut luokkaeikä olio-orientoitunutta. Päätettiin vielä perehtyä Nokia Research Center Oy:n kehittämään Mermaidtyökaluun, jolla UML:ää soveltaen voidaan määritellä ohjelmistotuotteita. Tätä ei kuitenkaan ennätetty hyödyntämään toiminnallisen määrittelyn laadinnassa tässä vaiheessa, mikä osaltaan vaikutti siihen, ettei määrittelyn sisällöllisiä tavoitteita vaiheen aikana saavutettu. Arkitehtuurisuunnittelu aloitettiin, mutta siinäkin vielä selvittelyn alla olevat työt UML-notaation ja siihen sovellettavan työkalun käyttöön saamiseksi aiheuttivat, että suunnittelun tuloksia ei saatu kovinkaan hyvin havainnollistettua. Arkitehtuurisuunnittelun täsmentymättömistä tuloksista johtuen ei nähty järkeväksi vielä aloittaa moduulisuunnittelua. Käyttökirjan suunnittelun pohjaksi tarvittiin riittävän pitkälle viety moduulisuunnittelu (moduulien hallinta käytön kannalta oleellista) ja sen vuoksi tietoiseti päätettiin käyttökirjan suunnittelu aloittaa vaiheessa toteutus 3. Testaussuunnitelma eteni hieman etuajassa toiminnalliseen määrittelyyn nähden ja siksi testaussuunnitelmassa viitattiin asioihin, jotka oli tarkoitus esittää myös toiminnallisessa määrittelyssä, mutta eivät edellä mainittujen lisäselvitystöiden vuoksi tulleet vielä kirjatuksi dokumenttiin. Testattavat toiminnot eivät tulleet täsmällisesti esille johtuen siitä, ettei niiden esitys ollut vielä valmis toiminnallisessa määrittelyssäkään. Projektin kotisivulta linkki vaiheen edistymisraporttiin:

8 WCLIQUE 7(24) 2.3 Toteutus 2 Vaiheen toteutus 2 ( ) päätavoitteet olivat:!" projektisuunnitelman päivitys!" vaatimusmäärittelyn päivitys!" toiminnallisen määrittelyn tarkennus!" teknisen määrittelyn ensimmäinen versio!" arkitehtuurisuunnittelun ensimmäinen kierros valmiiksi!" moduulisuunnittelun ensimmäinen kierros valmiiksi!" koodauksen aloitus!" testitapauksien suunnittelun aloitus!" testaussuunnittelun jatko!" ensimmäinen proto demottavaksi Projektisuunnitelman päivityksen yhteydessä saatiin kaikki siihen liittyvät dokumentit valmiiksi. Vaiheen tavoitteet ja tulokset eivät kuitenkaan tulleet projektisuunnitelmassa riittävän selvästi esille. Toiminnallisessa määrittelyssä sisällön valmistelu oli edennyt, mutta kaikelta osin sitä ei vielä saatu valmiiksi. Mm DIMACS:n binääri- ja ASCII -formaatit olivat vielä määrittelemättä. Teknisestä määrittelystä saatiin draft-versio valmiiksi, mutta hyväksyntää näin keskeneräiselle dokumentille ei vielä annettu. Arkitehtuurisuunnittelun ensimmäinen kierros saatiin valmiiksi sen hetkisen tuotemäärittelyn suhteen. Moduulisuunnittelua jatkettiin ja toteutuksia kuvattiin tässä vaiheessa mm vuokaavioesityksin, mutta tavoitteeksi kuitenkin asetettiin toteutusten pseudokoodaus seuraavassa vaiheessa. Testaussuunnittelua jatkettiin ja testitapauksia suunniteltiin vaatimusmäärittelyn ja professori Östergårdin prototyypin ollessa tapauksille perustana. Koodausta toteutettiin projektikatselmuksessa esitetyn protyypin aikaansaamiseksi, mutta tässäkin oli perustana professori Östergårdin prototyyppi. Demostraation käsikirjoitusta ei oltu tässä vaiheessa toteutettu. Projektikatselmuksessa todettiin tarve tehostaa yhteistyötä asiakkaan kanssa. Projektin kotisivulta linkki vaiheen edistymisraporttiin: Toteutus 3 Vaiheen toteutus 3 ( ) päätavoitteet olivat:!" projektisuunnitelman ja vaatimusmäärittelyn päivitykset!" toiminnallisen määrittelyn valmis versio!" teknisen määrittelyn ensimmäinen versio!" arkitehtuurisuunnittelun jatko!" moduulisuunnittelun jatko!" koodauksen jatko!" käyttökirjan suunnittelun aloitus!" testitapauksien suunnittelun jatko!" testisuunnitelman ensimmäinen versio!" demossa esitettävän proton testaus!" toiminnallisuuksiltaan kattava proto demottavaksi

9 WCLIQUE 8(24) Projektisuunnitelman päivitys suoritettiin tehtävälistaan, mutta edelleen jäi toteuttamatta tarkoitukseltaan epäselväksi jääneen edellisessä projektikatselmuksessa tehty parannusehdotus selkeästä seuraavan vaiheen tehtävien ja tavoitteiden määrittelyistä. Toiminnallisen määrittelyn päivitys suoritettiin pseudokoodista saatujen asiakaspalautteiden suhteen. Teknisen määrittelyn ensimmäinen versio saatiin valmiiksi, mutta se ei ehtinyt kuitenkaan hyväksyttäväksi projektin sisäiseen katselmukseen. Arkitehtuuri- ja moduulisuunnittelua jatkettiin keskeisimpinä asioina huomioida asiakkaan antamat kommentit laaditusta ohjelmiston pseudokoodista. Käyttökirjan suunnittelu aloitettiin. Koodausta toteutettiin suunniteltua vähemmän johtuen nimenomaan arkitehtuuri- ja moduulisuunnittelun osalle tulleista muutostarpeista. Käyttökirjan suunnittelu saatiin hyvään alkuun ja siitä tehtiin ensimmäinen draft-versio. Asiakasvaatimuksena ollutta LaTeX-formaattia ei kuitenkaan tarkoituksellisesti vielä tuettu tässä vaiheessa, koska koettiin työtä helpottavammaksi laatia ensin käsikirjan sisältö Word-editorilla. Testausta jatkettiin uudelleen suunniteltujen moduulien suhteen. Demottavaan protoon saatiin toteutettua eri "klikkilaskentojen" esitykset painotetuista tapauksista, mutta painottamattomat "klikkilaskennat" ja järjestäminen jäi vielä toteuttamatta. Tässä vaiheessa lähinnä pseudokoodauksen kautta esille tulleet virhemäärittelyt aiheuttivat selvästi viivästymää projektin suunniteltuun aikatauluun nähden ja arvio kokonaisviivästymästä oli yhden vaiheen luokkaa. Tämä luokiteltiin merkittäväksi riskiksi projektille asetettujen tavoitteiden suhteen. Projektin kotisivulta linkki vaiheen edistymisraporttiin: Toteutus 4 Vaiheen toteutus 4 ( ) päätavoitteet olivat:!" projektisuunnitelman yhteyteen liitettävä kuluneen ja seuraavan vaiheen tehtävien ja tavoitteiden määrittely!" toiminnallisen määrittelyn päivitys!" teknisen määrittelyn ensimmäisen version hyväksyminen!" arkkitehtuurisuunnittelu valmiiksi!" moduulisuunnittelu valmiiksi!" koodauksen jatko!" käyttökirjan suunnittelun jatko!" testitapauksien suunnittelu valmiiksi!" testisuunnitelman päivitys!" proton testaus!" toiminnallisuuksiltaan valmis proto demottavaksi Projektisuunnitelman kuluneen ja seuraavan vaiheen tehtävien ja tavoitteiden selkeä määrittely toteutettiin.

10 WCLIQUE 9(24) Projektiryhmän ymmärtämien asiakasvaatimusten mukaisesti saatiin projektiryhmän sisäisessä katselmuksessa hyväksyttyä tekninen määrittely. Arkitehtuurisuunnittelu saatiin valmiiksi. Moduulisuunnittelu saatiin valmiiksi. Koodaus saatiin muiltaosin valmiiksi paitsi klikkien käsittelytoimintojen, syötteen DIMACS binääri-formaatti-esityksen ja järjestämisen suhteen. Käyttökirjan ensimmäinen versio, ei kuitenkaan LaTeX-muodossa, saatiin arvioitavaksi. Integrointi-testausta tehtiin muttei saatu vielä valmiiksi. Viikko ja kaksi päivää ennen vaiheen projektikatselmusta pidettiin asiakkaan kanssa välikatselmus, jossa edellä mainitut tulokset esitettiin ja jätettiin asiakkaan arvioitavaksi. Testisuunnitelma todettiin projektikatselmuksessa vielä vaillinaiseksi. Samoin jäi testitapauksien laadinta kesken toteutus 4 -vaiheen aikana. Projektikatselmuksessa kommentoitiin myös käyttökirjassa olevista virheistä. Projektin kotisivulta linkki vaiheen edistymisraporttiin: Luovutus Vaiheen luovutus ( ) päätavoitteet olivat:!" koodaus (DIMACS binääri-formaatti, järjestäminen, klikkien käsittelytoiminnot, bugien korjaus)!" käyttökirjan viimeistely!" testaus (integrointi- ja hyväksyntätestaus, opponointiryhmän tuotteen testaus)!" loppuraportti!" loppudemonstraatio!" tuotteen luovutus Edellisessä vaiheessa toteutus 4 pidetyssä asiakaskatselmuksessa jätetyn aineiston arvioinnin tulokset asiakas esitti luovutusvaiheen alussa projektiryhmälle. Sen perusteella todettiin tuotteessa ja dokumentaaiossa olevat seuraavat puutteet ja/tai keskeneräisyydet:!" teknisessä määrittelyssä ei oltu esitetty selkeästi graafin talletusmuotoa!" käyttökirja ei ollut LaTeX-muodossa!" käyttökirjasta puuttui ohje aliohjelmien liittämisestä osaksi omaa ohjelmaa!" kieliasu ei ollut riittävän hyvä!" tehokkuusvertailu testauksessa oli tekemättä!" toiminnallisessa määrittelyssä virhe, kun mainitaan solmujen tulostaminen pilkuin erotettuna (4.2.3)!" modulaarisuus puutteellinen!" globaalisia muuttujia käytössä!" graafi ja sen oheistietorakenteet talletettu yhdessä dynaamisesti allokoidussa tietorakenteessa!" edelliset kahden kohdan epäkohdat aiheuttavat, että useampia graafeja ei voida ajaa rinnakkain!" käyttäjän antamat parametrit eivät kohdistuneet wclique-funktioon (käyttöliittymä-funktio)!" määrittelydokumentit olivat puutteellisia (asiakkaalle tärkein dokumentti on toiminnallinen määrittely)!" toiminnot painottamattomien klikkien käsittelylle puuttuivat tuotteesta!" järjestämistoiminto puuttui tuotteesta!" DIMACS binääri -formaatin käyttömahdollisuus puuttui tuotteesta!" koodissa true ja false määrittelemättä!" parametrina annettua tiedostonimeä kopioitaessa ei kopioitu merkkijonon loppunollaa!" muistin allokoinnissa varattiin tilaa cliquetblsize-tavua eikä cliquetblsize unsigned int:lle!" kaarenpoistotoiminto puuttui!" tuotteen tehokkuus pienempi kuin asiakkaan osoittamalla prototyypillä

11 WCLIQUE 10(24) projektiryhmä piti asiakkaan kanssa kokouksen, jossa käytiin läpi asiakkaan esittämät puutteet projektin tähän astisissa tuloksissa. Tässä kokouksessa asiakas toi esille kirjallisen tilannekatsauksen projektista. Siinä todettiin, ettei määrittelydokumentteja oltu asetettu asiakkaan hyväksyttäväksi sen lisäksi että niissä edelleen on puutteita ja virheitä. Lisäksi esitettiin merkitykset asetetuille pääasiallisille vaateille, joita projektille voidaan asettaa ja lopuksi priorisoitiin ne kriteerit, jotka voidaan projektin onnistumisen rajaksi asettaa. Kokouksessa todettiin esitetyistä puutteista osa korjatuksi vaiheen toteutus 4 viimeisten päivien aikana. Vielä korjaamattomien puutteiden suhteen todettiin, että projektiryhmä pyrkii korjaamaan myös ne. Todettiin, että projektin kuluessa asiakkaan esittämä toiminto info-parametriin liittyen ei ole alkuperäinen asiakasvaatimus ja siksi ei ehdoton toteuttaa projektin aikana. Projektiryhmä kuitenkin totesi, että toiminto toteutetaan, jos jäljellä oleva aika antaa siihen mahdollisuuden. Suureksi riskiksi kaikkien edellä mainittujen puutteiden poistamisen onnistumiselle todettiin jäljellä olevan ajan niukkuus ennen projektin suunniteltua päätöstä. Edellä mainittujen puutteiden korjausten tulokset on esitetty kappaleessa 3.2 kuten myös muiden tuotteelle ja projektille asettujen vaatimusten toteutumat ja tulokset. Projektin tulos sekä tuotteen että sen dokumentaation suhteen luovutettiin asiakkaalle mennessä tarkastettavaksi ja testattavaksi kokouksessa asiakas totesi, että hyväksyntätestaus tapahtuu omatoimisesti asiakkaan taholla pidettiin asiakkaan kanssa sovittu katselmus, jossa asiakkaan oli tarkoitus antaa palautteensa testaamastaan tuoteesta ja tarkastamasta materiaalista. Asiakkaalla ei ollut tähän mennessä tuotteen testejä ja materiaalin tarkastuksia kaikilta osin tehty. Katselmuksessa tarkastettiin vielä vaatimusmäärittely ja toiminnallinen määrittely sekä testisuunnitelma ja käyttöohje ja sovittiin, että vielä löytyneet puutteet korjataan ja dokumentit lähetetetään viimeistään aamupäivän aikana asiakkaalle lopullista hyväksyntää varten. 3. LOPPUTULOKSET Tässä luvussa esitetään pääkohdittain ensin ne projektin suunnitteluvaiheen alussa esitetyt asiakkaan määrittelemät vaatimukset kehitettävän tuotteen suhteen kuin myös oleelliset asetetut vaatimukset ohjelmistotyökurssin taholta. Sen jälkeen esitetään, miten vaatimukset ovat toteutuneet projektin aikana. Toteutuma-arvioissa huomioidaan myös kappaleessa 2.6 mainitut toteutus 4-vaiheen aikana pidetyn asiakaskatselmuksen johdosta asiakkaan esille tuomat vaatimusten täsemennykset. Mikäli tulokset poikkeavat alkuperäisistä vaatimuksista, arvioidaan poikkeamien perusteita. 3.1 Asiakkaan ja projektin vaatimukset Asiakkaan esittämät vaatimukset wclique-ohjelmistotuotteelle Seuraavassa taulukossa (Taulukko 2) on esitetty ne ohjelmistotuotetta koskevat asiakasvaatimukset pääkohdittain, jotka asiakas esitti pidetyssä projektin aloituskokouksessa. Taulukkossa on mainittu myös, onko vaatimus (mandatory) ja ensijijainen (primary goal) tai toissijainen (secondary goal), vai onko se pelkästään "voisi olla" (nice to have).

12 WCLIQUE 11(24) Taulukko 2 Vaatimus Ensisijainen päämäärä tässä projektissa on muodostaa toimiva käyttöympäristö algoritmille, jota voidaan kutsua toisesta C kielellä tehdystä ohjelmasta komennolla wclique ja jonka rutiineja voidaan käyttää yhdessä nauty-ohjelmiston kanssa. wclique-ohjelmistossa on oltava ominaisuus käsitellä sekä painottamattomia että painotettuja graafeja. wclique-ohjelmistossa on oltava ominaisuus laskea suurimman klikin koko. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki suurimmat klikit wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki kokoa S olevat klikit. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki klikit, jotka ovat vähintään kokoa S. wclique-ohjelmistossa on oltava ominaisuus, jossa kolmessa edellisessä vaatimuksessa, kun kaikki klikit laskettu, klikkejä ei ole tallennettu muistiin, mutta ovat annetun funktion kutsuttavissa. wclique-ohjelmistossa on oltava ominaisuus, jolla solmut ovat järjestettävissä eri tavoilla, erityisesti ominaisuus, jossa ei uudelleen järjestystä. Klikkien solmujen laskeminen annetuin välein. wclique-ohjelmistossa on oltava ominaisuus käsitellä sekä painottamattomia että painotettuja graafeja. Toimii Linux/Unix:n komennoilla. Lukee yleisiä graafin formaatteja. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea suurimman klikin koko. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki suurimmat klikit. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki kokoa S olevat klikit. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki klikit, jotka ovat vähintään kokoa S. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus, jolla solmut ovat järjestettävissä eri tavoilla, erityisesti ominaisuus, jossa ei uudelleenjärjestystä. Toimii Linux/Unix:n komennoilla. Ohjelmointikieli C. Toimittava Linux:ssa, Unix:ssa ja muissa tärkeissä käyttöjärjestelmissä. Algoritmin on suoriuduttava suurista graafeista. Käyttökirja, LaTeX-editorilla, englanninkielinen Prioriteetti ensisijainen ensisijainen ensisijainen ensisijainen ensisijainen ensisijainen ensisijainen ensisijainen voisi olla toissijainen toissijainen toissijainen toissijainen toissijainen toissijainen toissijainen Tarkemmin vaatimukset on esitetty projektin vaatimusmäärittelydokumentissa. Projektin kotisivulta linkki vaatimusmäärittelyyn:

13 WCLIQUE 12(24) Seuraavassa on esitetty oleelliset tavoitteet projektityössä kurssin taholta:!" loppukatselmus !" toteutus vaiheittain soveltaen USDP:tä (edellytetyt vaiheet esitetty luvussa 2.)!" projektisuunnitelma (sisältää MS Project-tiedoston)!" vaatimusmäärittely!" toiminnallinen määrittely!" tekninen määrittely!" testaussuunnitelma!" testausraportit!" edistymisraportit!" käyttöohje!" loppuraportti!" projektin kotisivu!" projektikatselmukset ja tuotedemot!" opponointitestaus!" raportoinnin ja mittarityökalujen käyttö (PMIX, Tirana, Burana, Vica) Tarkemmin kurssin vaatimukset on esitetty kurssin web-sivuilla: Vaatimusten toteutuminen ja tulokset Projektin tulokset jätettiin asiakaspalaverissa sovitun perusteella tarkastettavaksi ja hyväksyttäväksi asiakkaalle. Seuraavassa taulukossa (Taulukko 3) on esitetty vaatimukset ja niihin mennessä saadut asiakkaan kommentit. Taulukko 3 Vaatimus Lopputulos Ensisijainen tavoite tässä projektissa on muodostaa toimiva käyttöympäristö algoritmille, jota voidaan kutsua toisesta C kielellä tehdystä ohjelmasta komennolla wclique ja jonka rutiineja voidaan käyttää yhdessä nauty-ohjelmiston kanssa. wclique-ohjelmistossa on oltava ominaisuus käsitellä sekä painottamattomia että painotettuja graafeja. wclique-ohjelmistossa on oltava ominaisuus laskea suurimman klikin koko. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki suurimmat klikit wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki kokoa S olevat klikit.

14 WCLIQUE 13(24) wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki klikit, jotka ovat vähintään kokoa S. wclique-ohjelmistossa on oltava ominaisuus, jossa kolmessa edellisessä vaatimuksessa, kun kaikki klikit laskettu, klikkejä ei ole tallennettu muistiin, mutta ovat parametrina annetun funktion kutsuttavissa. wclique-ohjelmistossa on oltava ominaisuus, jolla solmut ovat järjestettävissä eri tavoilla, erityisesti ominaisuus, jossa ei uudelleen järjestystä. Klikkien solmujen laskeminen annetuin välein. wclique-ohjelmistossa on oltava ominaisuus käsitellä sekä painottamattomia että painotettuja graafeja. Toimii Linux/Unix:n komennoilla. Lukee yleisiä graafin formaatteja. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea suurimman klikin koko. Toimii Linux/Unix:n käskyillä. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki suurimmat klikit. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki kokoa S olevat klikit. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus laskea yksi tai kaikki klikit, jotka ovat vähintään kokoa S. Toimii Linux/Unix:n komennoilla. wclique-ohjelmistossa on oltava ominaisuus, jolla solmut ovat järjestettävissä eri tavoilla, erityisesti ominaisuus, jossa ei uudelleen järjestystä. Toimii Linux/Unix:n komennoilla. Ohjelmointikieli C. Toimittava Linux:ssa, Unix:ssa ja muissa tärkeissä käyttöjärjestelmissä. Tätä "nice to have" vaatimusta ei toteutettu. Asiakas totesi vaatimuksen täytetyksi.

15 WCLIQUE 14(24) Algoritmin on suoriuduttava suurista graafeista. User manual, LaTeX-editorilla, englanninkielinen Asiakkaan lisätoivomus oli saada komentoriviparametriksi "info-toiminto". Asiakas totesi vaatimuksen täytetyksi. Ulkoasu olisi voinut olla asiakkaan mielestä parempi. Projektin testeissä todettiin tämän lisätoivomuksen täyttyvän. Kappaleessa 6 mainitut vaiheessa toteutus 3 pidetyn asiakaskatselmuksen tuloksena esitetyt puutteet ja epäkohdat ja niiden status projektin lopussa (Taulukko 4): Taulukko 4 Puute/Epäkohta Lopputulos Teknisessä määrittelyssä ei oltu esitetty selkeästi Asiakas hyväksyi määrittelyn graafin talletusmuotoa. Käyttökirja ei ollut LaTex-muodossa. Asiakas hyväksyi käyttökirjan Käyttökirjasta puuttui ohje aliohjelmien Asiakas hyväksyi käyttökirjan liittämisestä osaksi omaa ohjelmaa. Kieliasu ei ollut riittävän hyvä. Asiakas hyväksyi kieliasun Tehokkuusvertailu testauksessa oli tekemättä. Toiminnallisessa määrittelyssä virhe, kun mainitaan solmujen tulostaminen pilkuin erotettuna (4.2.3). Asiakas hyväksyi määrittelyn Modulaarisuus puutteellinen. Asiakas hyväksyi teknisenmäärittelyn Globaalisia muuttujia käytössä. Graaffi ja sen oheistietorakenteet talletettu yhdessä dynaamisesti allokoidussa tietorakenteessa. Edelliset kahden kohdan epäkohdat aiheuttavat, että useampia graafeja ei voida ajaa rinnakkain. Käyttäjän antamat parametrit eivät kohdistuneet wclique-funktioon (käyttöliittymä-funktio). Määrittelydokumentit olivat puutteellisia (asiakkaalle tärkein dokumentti on toiminnallinen määrittely). Asiakas hyväksyi määrittelydokumentit

16 WCLIQUE 15(24) Toiminnot painottomien klikkien käsittelylle puuttuivat tuotteesta. Järjestämistoiminto puuttui tuotteesta. DIMACS binääri-formaatin käyttömahdollisuus puuttui tuotteesta. Koodissa true ja false määrittelemättä. Parametrina annettua tiedostonimeä kopioitaessa ei kopioitu merkkijonon loppunollaa. Muistin allokoinnissa varattiin tilaa cliquetblsizetavua eikä cliquetblsize unsigned int:lle. Kaarenpoistotoiminto puuttui. Tuotteen tehokkuus pienempi kuin asiakkaan osoittamalla prototyypillä. Kurssin taholta asetetut vaatimukset ja niiden toteutuminen on esitetty seuraavassa taulukossa (Taulukko 5). Taulukko 5 Vaatimus Tulos Loppukatselmus Pidettiin klo Toteutus vaiheittain soveltaen USDP:tä. Toteutettu kurssissa edellytetyt vaiheet. Vaiheiden toteutumisen kuvaukset esitetty luvussa 2. Projektisuunnitelma. Toteutettu kurssin edellyttämissä vaiheissa. Kommentit projektisuunnitelman onnistumisista ja epäkohdista on esitetty luvussa 2. ja ryhmän kurssiarvostelussa, jonka web-sivun linkki on: Vaatimusmäärittely. Asiakkaan hyväksyntä Toiminnallinen määrittely. Asiakkaan hyväksyntä Tekninen määrittely. Asiakkaan hyväksyntä

17 WCLIQUE 16(24) Testaussuunnitelma. Asiakkaan hyväksyntä Kommentteja ryhmän kurssiarvostelussa, linkki: Testausraportit. Testausraportit luovutettu Edistymisraportit. Edistymisraportit laadittiin vaiheittain, kuten kurssin edellytyksenä oli. Puutteena mainittiin, että edistymisraportti ei aina antanut todellista kuvaa projektin tilasta. Käyttöohje. Asiakkaan hyväksyntä Projektin kotisivu. Laadittiin projektin suunnitteluvaiheen aikana. Projektikatselmukset ja tuotedemot. Toteutettiin vaiheissa edellytettyinä ajankohtina. Kommentit ryhmän kurssiarvostelussa, linkki: Opponointitestaus. Toteutui ja raportti luovutettu luovutusvaiheessa. Raportoinnin ja mittarityökalujen käyttö. Käytetty, kuten edellytetty kurssin taholta. Alkuvaikeuksia mm PMIX:ssa. Tuntiraportoinnissa työtuntimääräarvioiden teossa eroavaisuuksia henkilöiden välillä.. Toteutui. Tuotteen testausten perusteella voidaan todeta, että vaatimusten täyttyminen jäi vähintään kahdelta osin vaillinaiseksi. Tuotteen tehokkuustesteissä testattava graafi vaikutti ajon nopeuteen. Keskimäärin asiakkaan antama prototyyppi oli yhtä monessa tapauksessa wcliqueta nopeampi kuin wclique oli ko prototyyppiä nopeampi. Tietyn graafin testiajoissa ajot keskeytyivät virheeseen sekä asiakkaan prototyypillä että wcliquella. Virheen syytä ei kyetty jäljellä olevan ajan puitteissa selvittämään, mutta yhtenä epäilyksenä on jonkinlainen virhe itse graafissa. Tarkemmat testien tulokset löytyvät wcliquen testausraportista: Tuotteen lopputuloksena syntyi aliohjelmakirjasto. Esimerkiksi tutkimuskäyttöön on edelleen mahdollista kehittää ohjelmistoja, jotka käyttävät näitä aliohjelmia klikkien laskemiseen graafeista. Toisaalta näitä aliohjelmia voidaan käyttää tuotteen ohjelmiston komentoriviltä ajettavan pääohjelman kautta. 4. PROJEKTITYÖSKENTELY 4.1 Suunniteltu ja toteutunut projektin toiminta Projektiryhmän jäsenille määriteltiin projektisuunnitelmassa seuraavat tehtävät (projektisuunnitelman luku 5, linkki projektisuunnitelmaan:

18 WCLIQUE 17(24) Tapani Tarri, Sari Salin Janne Dufva Juha Kähkönen Raine Kärkkäinen Juha Lehtonen Ossi Ouri Projektipäällikkö Dokumentointipäällikkö Asiakasvastaava Laatupäällikkö Algoritmiasiantunija Arkitehtuurivastaava Suunnittelupäällikkö Projektin toiminnan suunnittelussa määriteltiin projektin toteutuksen vastuualueet ja niille toteuttajat siten, että projektiryhmästä muodostui useampi vastuualuekohtainen ryhmä (projektisuunnitelman luku 5, linkki projektisuunnitelmaan: Projektin hallinta ja tuki: Projektin tekninen toteutus: Asiakasvaatimukset: Projektin seuranta ja valvonta: Janne Dufva, Juha Kähkönen, Sari Salin, Tapani Tarri Juha Kähkönen, Raine Kärkkäinen, Juha Lehtonen, Ossi Ouri Janne Dufva Juha Kähkönen ja Tapani Tarri projektiryhmän jäseninä Projektisuunnitelmassa määriteltiin projektiryhmän jäsenille vaiheessa toteutus 2 varahenkilökäytäntö (projektisuunnitelman kappale 12.6). Tätä varahenkilökäytäntöä sovellettiin myös dokumenttien tarkastus- ja hyväksyntätoimintaan siten, että dokumentin laatijan 1. varahenkilö toimi dokumentin tarkastajana ja 2. varahenkilö hyväksyjänä ( kts. projektisuunnitelman liite "Tarkastukset ja katselmoinnit", Projektityöskentely suunniteltiin toteutettavaksi vaiheittain. Vaihe aloitettiin projektikokouksella, jossa projektiryhmä kokoontui projektipäällikön kutsumana. Vaiheen alun projektikokouksessa todettiin edellisen vaiheen osalta saatu palaute ja tilanne ja suunniteltiin niiden suhteen tarpeelliset jatkotoimenpiteet sekä käytiin läpi projektisuunnitellut ja edellisessä vaiheessa täsmennetyt kuluvan vaiheen tehtävät ja tavoitteet sekä niiden vastuuhenkilöt sekä näiden tehtävien vaikutus projektiin kokonaisuutena. Projektisuunnitelman mukaisesti aloituskokousen jälkeen vaiheen aikana tuli toteuttaa:!" tuotteen arkitehtuuri- ja moduulisuunnittelua sekä koodausta (projektin tekninen toteutus)!" käyttökirjan suunnittelu (projektin hallinta ja tuki, asiakasvaatimukset)!" vaatimus-, toiminnallisen ja teknisen määrittelyn laadintaa ja päivitystä (asiakasvaatimukset)!" projektin suunnittelua (projektin hallinta ja tuki)!" testaukset (projektin tekninen toteutus)!" vaiheen tulosten katselmointi (projektiryhmä)!" raportointi, mittarit, dokumenttien hallinta ja luovutus (projektin hallinta ja tuki, projektiryhmä) Vaiheen loppupuolella pidettiin projektipäällikön kutsusta projektikokous, jossa todettiin vaiheen aikaiset tulokset, varmistettiin luovutettavan aineiston luovutuksen toteutuminen ja suunniteltiin vaiheen päättävä projektikatselmus. Projektityöskentelyssä suunniteltiin käytettäväksi projektin etenemisen raportointiin ja seurantaan kurssin tarjoamia työkaluja Tiranaa, Buranaa ja ViCaa. Edellä esitetty suunniteltu projektityöskentelyn kuvaus pääpiirteittäin on tarkemmin esitetty projektisuunnitelmassa ja sen liitteissä (

19 WCLIQUE 18(24) 4.2 Arviot toiminnasta Projektisuunnitelmassa määritellyt tehtävät projektiryhmän jäsenille pysyivät voimassa koko projektin kulun ajan. Samoin toimi vastuualuekohtaiset ryhmämäärittelyt henkilönimien suhteen. Sen sijaan projektisuunnitellussa tehtävienjaossa henkilöiden suhteen jouduttiin joustamaan. Varsinkin teknisen toteutuksen suhteen rajoja määriteltiin ryhmän sisällä vallitsevien henkilökohtaisten mahdollisuuksien ja rajoitusten mukaan. Teknisestä toteutuksesta vastaavat ryhmän jäsenet joutuivat kaikki osallisiksi laatimaan arkitehtuurisuunnittelua, moduulisuunnittelua, koodausta ja tuotteen testausta. Sen lisäksi teknisestä toteutuksesta vastaavan ryhmän jäsenten osallistuminen toiminnallisen ja teknisen määrittelyn sekä käyttökirjan sisällön tuottamiseen oli merkittävä ja heidän tuotteen teknisen asiantuntemuksensa vuoksi välttämätöntä. Tämä joustomahdollisuus koettiin projektin toteutuksessa positiiviseksi asiaksi ja se, ettei sitä oltu painotettu kovinkaan vahvasti projektisuunnitelmassa, olisi saattanut olla lopputulokseen vaikuttava riski, joka ei nyt onneksi kuitenkaan lauennut. Vaiheittaisesta suunnitellusta projektityöskentelystä kyettiin pitämään pääpiirteittäin kiinni. Yksityiskohtaisissa tekemisissä ja niiden vaihekohtaisissa suunnitelluissa määrissä toteutuneen ja suunnitellun välillä syntyi eroja. Arvioidut työmäärät vaiheissa arkitehtuuri- ja moduulisuunnittelulle, koodaukselle, testauksen toteutumiselle, määrittelydokumenttien laadinnalle ja käyttökirjan suunnittelulle erosivat toteutuneista määristä tehtäväkohtaisella tasolla enemmän kuin kumulatiivisesti laskettuna kaikkien tehtävien suhteen. Tämä johtui siitä, että inkrementaalista ja iteratiivista työskentelymallia ei kyetty toteuttamaan siten vaihekohtaisesti, kuten alunperin oli suunniteltu. Esimerkiksi koodausta ei voitu paljoakaan toteuttaa ennen kuin arkitehtuuri- ja moduulisuunnittelua oli viety riittävän pitkälle. Samoin ei voitu ensimmäisissä vaiheissa tehdä suunnitellussa määrissä testauksia kun ei ollut riittävästi testattavaa koodia. Teknisen määrittelyn täsmennys ja käyttökirjan suunnittelun aloitus vaati myös sen, että arkitehtuuri- ja moduulisuunnittelu oli viety riittävän pitkälle ensimmäisten vaiheiden aikana. Alkuperäinen suunniteltu tavoite esim käyttökirjan suunnittelun aloitukselle oli vaiheessa toteutus1, mutta se jouduttiin em syiden vuoksi muuttamaan vaiheen toteutus1 jälkeen projektisuunnitelmaan alkavaksi vasta vaiheessa toteutus3. Alussa suunnitellut projektikokoukset pystyttiin toteuttamaan alkuperäisen suunnitelman mukaisesti. Tosin kaikkien projektiryhmäläisten osanotto projektikokouksiin ei aina onnistunut kuten ei myöskään projektikatselmuksiin, mutta se oli jo ennakkoon tiedostettavissa oleva asia ja siksi hallittavissa. Projektin alussa oli suunniteltu, että projektiryhmän sisäiset katselmukset toteutetaan projektikokousten puitteissa, mutta nämä jouduttiin katselmusten tehon lisäämiseksi toteuttamaan selvästi erillisinä tapahtumina. Vaiheen toteutus2 aikana koettiin mm asiakkaan taholta puutteeksi se, että asiakaskontakteja ei toteudu projektin tarpeiden kannalta riittävästi. Tämän vuoksi otettiin projektityöskentelyssä käyttöön noin joka toinen viikko tapahtuneet kokoukset projektiryhmän ja asiakkaan kesken. Projektin työmäärät tehtävittäin suunniteltiin MS Project-ohjelmistolla (projektisuunnitelman mukaisesti), josta tiedot syötettiin PMIX-työkalulla kurssin palvelimeen. Tehtäväkohtaiset toteutumat raportoitiin kurssin edellyttämällä Tiranalla. Buranalla raportoitiin tuotteen vaiheiden aikana ilmenneitä virheitä ja koodirivien määrää. ViCaa käytettiin lähinnä tutustumismielessä ja mm tämän loppuraportin laadinnassa (luku 5.) hyväksi.

20 WCLIQUE 19(24) Projektin tehtävien ja toteutumien seurantaan otettiin vaiheessa toteutus2 projektiryhmän käyttöön actionpoint-rekisteri. 5. JÄLKILASKELMAT 5.1 Projektin kustannukset Seuraavassa taulukossa (Taulukko 6) on esitetty projektisuunnitelmat projektissa muodostuvista kustannuksista: Taulukko 6 Kustannuslaji Määrä ja yksikköhinta SUMMA/FIM seitsemän projektihenkilöä 2100 tuntia, 367 mk/h kurssin henkilökunta 70 tuntia, 367 mk/h kaksi asiakkaan edustajaa 90 tuntia, 367 mk/h tilakustannukset 6 kk, mk/kk laitekustannukset 6 kk 7 työasemaa, 2000 mk/kk työasema materiaalikustannukset konttori- ja atk tarvikkeet 7 erää, 1000 mk/erä 7000 matkakustannukset 7 henkilöä 6 kk, 500 mk/henkilökk Yhteensä Toteutuneiden projektikustannusten suhteen muutokset suunniteltuun nähden aiheutuivat pääasiassa toteutuneista projektiryhän jäsenten työmääristä. Nämä suunnitellut ja toteutuneet työmäärät esitetään kappaleessa 5.2. Kustannuksina projektiryhmän jäsenten työmäärät olivat FIM ja kokonaiskustannuksiltaan projektin voidaan arvioida olleen FIM, mikä on 30% vähemmän kuin suunnitteluvaiheen arvio. 5.2 Työmäärälaskelmat Projektin suunnitteluvaiheessa arvioitiin projektin toteutukseen tarvittavat työmäärät tunteina vaiheittain kunkin projektiryhmän jäsenen osalta. Tuntimäärät on esitetty seuraavassa taulukossa (Taulukko 7, lähde: MS Project:lla laadittu tiedosto clique.mpp).

21 WCLIQUE 20(24) Taulukko 7 Vaihe/ Henkilö Projektin suunnittelu Toteutus 1 Toteutus 2 Toteutus 3 Toteutus 4 Luovutus Kokonais Tuntimäärä/hlö J. Dufva J. Kähkönen R..Kärkkäinen J.Lehtonen O.Ouri S.Salin T.Tarri Kokonaistuntimäärä/ vaihe Ero suurimman ja Pienimmän tuntimäärän Suhteen. 34% 31% 53% 37% 48% 39% 34% MS Project:lla tehdyssä suunnittelussa on systemaattisesti 100% virhe ylöspäin työmääräesityksissä. Virheellisenä oletuksena oli, että ohjelmisto huomioi Resource Sheet:llä määritellyt Max.Units:n arvon 50% siten, että tuntimäärät lasketaan Duration:ssa olevien päivien lukumäärän suhteen puolittaen sekä työpäivien määrät että niiden työtuntien määrät. Näinhän ei tietenkään ole, koska silloin em Max.Units:n arvo vastaisi 25%. Tämä kaksinkertainen tuntimäärä näkyy myös ViCa-seurantajärjestelmässä. Kurssin puitteissa hyväksyttävä projektin toteutus huomioidaan kunkin projektin jäsenen kohdalla viiden opintoviikon suorituksena. Tämä tarkoittaa noin 200 tunnin työmäärää projektiryhmän jäsentä kohti eli yhteensä 1400 tuntia, kun ryhmässä on seitsemän jäsentä. Koska projektien toteutuksessa työmääräarviot helposti tulevat arvioitua liian vähäisiksi, tehtiin projektin suunnitteluvaiheessa oletus, että työmäärä keskimäärin on 50% suurempi, kuin kurssin opintoviikkojen osoittama määrä eli mainitun 1400 tunnin suhteen käytettiin kokonaistuntimäärän arvioinnissa kerrointa 1,5 ja sen pohjalta suunniteltiin henkilökohtaiset osuudet vaiheittain. Tämä myös voitiin olettaa realistisesti mahdolliseksi projektin tehtäville allokoitavan ajan suhteen. Suuremman aikamäärän allokointi projektin hyväksi olisi tarkoittanut sitä, että projektin jäsenten olisi pitänyt löytää lisäaikaa projektin tehtävien suorittamiseksi jäsenten projektin ulkopuolisista tekemisistä tai että projekti ei olisi valmistunut kurssin asettamaan aikarajaan mennessä. Tehtävät määriteltiin henkilöille sen mukaan, mitä arvioitiin kunkin henkilön kohdalla olevan hänen osaamisalueellaan ja mieluimmin niin, että paremmin hallitsemana kuin muilla projektin jäsenillä keskimäärin. Tämän vuoksi esim ohjelmointiosuuksien toteutus projektissa jäi enemmän henkilöille, jotka vastasivat projektin teknisestä toteutuksesta. Tämä tehtävien keskittyminen henkilöiden osaamisten mukaan oli perusteena myös sille, että suunniteltujen työmäärien ero tunteina eri henkilöiden välillä voitiin katsoa hyväksyttäväksi. Kaikkien projektiryhmän jäsenten kohdalla voitiin olettaa, että tyämäärä vastaisi vähintään kurssin viiden opintoviikon suoritusta.

22 WCLIQUE 21(24) Seuraavassa taulukossa (Taulukko 8) esitetään projektin vaiheiden aikana raportoidut projektin jäsenten toteutuneet työmäärät tunteina (lähde: Tirana-tuntiraporttien tarkastelu ViCa-seurantajärjestelmällä). Taulukko 8 Vaihe/ Henkilö Projektin suunnittelu Toteutus 1 Toteutus 2 Toteutus 3 Toteutus 4 Luovutus Kokonais Tuntimäärä/hlö J. Dufva J. Kähkönen R..Kärkkäinen J.Lehtonen O.Ouri S.Salin T.Tarri Kokonaistuntimäärä/ vaihe Ero suurimman ja Pienimmän tuntimäärän Suhteen. 83% 93% 88% 100% 100% 100% 80% Ero suunnitellun ja toteutuneen työmäärän suhteen kokonaisuutena on 37 %, mikä osoittaa mm sen, että edellä mainittu 1,5:n varmuuskerroin suunnitellun työmäärän suhteen oli suurinpiirtein oikea. Seuraavassa on tarkemmin arvioitu eroja työlajeittain suunnitellun ja toteutuneen välillä. Kokouksien ja katselmusten suhteen työmääräarviot projektisuunnittelussa olivat noin 250 tuntia (kaksi projektipalaveria ja katselmus keskimäärin vaihetta kohden) mikä vastasi suurin piirtein myös toteutunutta kokouksien ja katselmuksien määrää. Suunnittelutyön projektisuunniteltu työmäärä oli noin 500 tuntia ja toteutunut työmäärä oli tästä 35%. Eron merkittävimpänä syynä oli se, että yhden henkilön kohdalla suunnittelutyön toteutuminen oli estynyt henkilökohtaisista syistä ja tämä osuus jouduttiin jakamaan muiden projektiryhmän jäsenten osuuksiin. Testauksen suunnittelun osuus 150 tuntia oli myös projektinsuunnittelussa kohdistettu suunnittelutyön osuuteen. Ohjelmoinnin projektisuunniteltu työmäärä oli noin 250 tuntia ja toteutunut työmäärä oli tästä 50%. Eron merkittävimpänä syynä oli se, että ohjelmiston laajuus koodiriveinä arvioitiin suunnitteluvaiheessa suuremmaksi kuin oli toteutunut määrä sekä se, että suunnittelutyön pseudokoodauksen tuloksia voitiin hyödyntää hyvin itse ohjelmiston koodauksessa. Dokumentoinnin projektisuunniteltu työmäärä oli noin 550 tuntia ja toteutunut työmäärä oli tästä 45%. Eron merkittävimpänä syynä oli se, että varsinaista dokumentointityötä ja tehtäviä, joita dokumentoitiin, on vaikea selkeästi erottaa toisistaan, joten mahdollista on, että myös dokumentoinnin osuutta on raportoitu muiden tehtävien piikkiin. Toisaalta dokumentointityön määrän toteutuma noudattaa samaa linjaa kuin projektin kokonaistyömäärän toteutuma suunniteltuun kokonaistyömäärään verrattuna. Testauksen projektisuunniteltu työmäärä oli noin 100 tuntia ja toteutunut työmäärä oli tästä 50%. Eron merkittävimpänä syynä oli se, että testausta aikaisemmissa vaiheissa ei juurikaan tapahtunut, koska testattavaa koodia ei ollut testattavaksi. Tähän arvioon ei ole huomioitu testaussuunnitelman tekoa eikä dokumentointityötä testauksen vuoksi.

23 WCLIQUE 22(24) Projektinhallintatehtävien projektisuunniteltu työmäärä oli noin 450 tuntia ja toteutunut työmäärä oli tästä 60%, mikä vastasi suhteellisesti samaa, mikä oli projektin suunnitellun ja toteutuneen kokonaistyömäärän suhde. ATK-ylläpitotehtäviä ja opiskeluosuuksia ei oltu huomioitu projektisuunnittelussa ja näiden toteutunut osuus projektin kokonaistyömäärästä oli alle 5%. 5.3 Tuotteen raportoidut laadulliset tulokset Virheitä projektin aikana Burana-järjestelmässä raportoitiin neljä kappaletta. Kaikki virheet luokiteltiin Burana:ssa sw-bug:ksi ja korjattiin projektin aikana. Koodirivejä raportoitiin Burana-järjestelmässä yhteensä 1861 kpl, joista kommenttirivejä on 520 kpl. Moduleja Burana:ssa esitettiin kolme kpl. 6. KURSSIPALAUTE Ohjelmistotyökurssin tarkoitus perehdyttää harjoitustyön kautta oppilaat ymmärtämään ja hallitsemaan tuotekehitysprojektien toimintaa on tärkeä osa tietoteknistä koulutusohjelmaa muiden usein teoreettisempien ja luentotyyppisten kurssien joukossa. Tämän kurssin kautta opiskelijalle avautuu mahdollisuus tutustua yrityselämässä käytettäviin toimintamalleihin ja tapoihin projektityyppisessä työskentelyssä. Kun vielä tuodaan harjoitustöiden aiheiksi oikeita yritysmailman tarpeita ohjelmistotuotteille ja saadaan näitä yrityksiä projektiryhmien asiakkaiksi, on kosketus toimintaan realistinen. Kuitenkin tässä vaiheessa, kun samalla opiskellaan toimintamalleja, on kurssimuotoinen tuki ja ohjaus tarpeen projektiryhmissä työskenteleville opiskelijoille. Kurssin puitteissa järjestetyt koulutus- ja esitystapahtumat palvelivat kohtuullisen hyvin tätä tarkoitusta. Koulutustapahtumia ja esityksiä järjestettiin kuitenkin vain yhdeltä taholta tietyn yrityksen tai henkilön toimesta kutakin aihetta kohden, mikä ei antanut aina mahdollisuutta verrata toisiinsa erillaisia yrityselämässä koettuja ja käytössä olevia malleja. Tähän puutteeseen löytynee hyvänä perusteluna jälleen se, että kurssin ajalliset rajoitukset eivät anna mahdollisuuksia laajempiin ja useampien mallien opiskeluun kurssin puitteissa. Tämä laajempi tutustuminen jää siten opiskelijoiden toteutettavaksi kurssin ulkopuolisissa toiminnoissaan, mihin varmasti tarjoutuu opiskelijoille mahdollisuuksia muiden kurssien ja varsinkin työelämän antatamien keinojen kautta. Kurssin asettamat vaatimukset toteutusmalleille ja menetelmille sekä käytettäville työkaluille olivat myös hyvin laadittu. Nämä mallit, menetelmät ja työkalut sellaisinaan tai vastaavanlaisina toteutuksina ovat yleisesti käytössä tämänpäivän yritysmailman projektitoiminnoissa ja ovat siten ajantasalla olevina palvelemassa opiskelijoiden mahdollisuutta perehtyä projektitoimintaan siten kuin se nykyaikana tapahtuu. Kurssin puitteissa saatava asiantunteva ohjaus ja tuki kurssin henkilökunnalta oli pyydettäessä saatavilla, mutta katselmusten kautta systemaattisesti tuleva tuki tuntui hiukan riittämättömältä, kun katselmuksia toteutettiin vai kerran vaiheen aikana ja siinä käytettävissä ollut aika lähes kokonaisuudessa kului projektin tulosten esittämiseen. Tämän vuoksi olisi ollut tarvetta myös kurssin henkilökunnalta tulevaan systemaattiseen ohjaustoimintaan esimerkiksi projektikatselmusten jälkeen.

24 TKK/DISKO/Tik WCLIQUE Projektiryhmä Clique Kurssiluonteisuutensa takia oli projektin toteutus suunniteltava ja toteutettava kurssin taholta asetetuissa puitteissa. Tämä ei suonut kaikilta osin projektin toteuttamista itse ohjelmistokehitystehtävän ja asiakkaan tarpeiden kannalta optimaalisesti. Projekti oli istutettava tapahtumaan kurssin taholta esitetyissä vaiheissa ja aikataulussa ja projektiryhmän resurssimäärät olivat projektityöstä riippumatta ko seitsemän henkilöä. Toinen usein projektityöskentelyssä käytetty lähestymistapa projektin suunnitteluun on laatia kehitettävälle tuotteelle esitutkimus, jossa huomioidaan tuotteelle asetettavat asiakasvaatimukset ja sen perusteella määritellään projektin toteutusaikataulu ja resurssitarpeet. Lisäksi projektin teknisen johdon ollessa kurssin henkilökuntaan kuuluvan tehtävänä, ei se suonut projektin tavoitteiden täyttymiselle sellaista sitoutumista teknisen johdon taholta, mitä käytännön projektitoteutuksissa tältä sitoutumiselta odotetaan. Opponenttitestaus toi parannusideoita esille osapuolten ohjelmistoissa ja antoi tietynlaisen objektiivisen käsityksen tuotteen onnistumisesta, kun arviot esitettiin toisen projektiryhmän testien perusteella.