Hirviö Projektisuunnitelma

Transkriptio

1 Hirviö Projektisuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. helmikuuta 2005 Tiivistelmä: Projektisuunnitelma kuvaa lyhyesti projektin, sen toimijat ja tavoitteet. Lisäksi suunnitelmassa listataan työtavat ja työkalut sekä projektin vaiheet. 1

2 Sisältö 1 Johdanto Projektin kuvaus Lopputuotteen oikeudet Järjestelmä ja ympäristö Termit ja määritelmät Henkilöstö ja toimijat Projektiryhmä Projektiryhmän tiedot Projektiryhmän jäsenet ja vastuualueet Muut toimijat Projektin tavoitteet ja päättymiskriteerit Asiakkaan tavoitteet lyhyesti Projektiryhmän tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeytyskriteerit Projektin päättymiskriteerit Resursointi Henkilöstö Materiaalit Budjetti Työtavat ja työkalut Käytännöt Iteratiivinen kehitys Iteraatiosuunnittelu Dokumentointi Raportointi Projektikatselmoinnit Ryhmän kokoukset Vaatimusten hallinta Muutostenhallinta Versionhallinta Koodaustavat Vertaistestaus SEPA -yhteenveto Laadunvalvontasuunnitelma Työkalut Käytäntöjen analysointi Standardit

3 6 Projektin vaiheet Aikataulu Dokumenttien valmistelu Projektin suunnittelu Tavoitteet Toimitukset Tehtävät Implementaatio I Tavoitteet Toimitukset Tehtävät Implementaatio II Tavoitteet Tehtävät Toimitukset Tehtävät Viimeistely ja toimitus Tavoitteet Toimitukset Tehtävät Riskienhallinta Skenaariot

4 Sorvakko Ensiversio, lähinnä dokumentin rakenne Sorvakko Kasattu eri ihmisten tekstit Sorvakko PP-vaiheen lopussa luovutettu dokumentti Sorvakko Korjaukset saadun palautteen perusteella Sorvakko I1-iteraation päivitykset Sorvakko I2-iteraation päivitykset 1 Johdanto Tämä dokumentti on Hirviö-ryhmän T Tietojenkäsittelyopin ohjelmatyö -kurssin projektisuunnitelma. 1.1 Projektin kuvaus Projektin tarkoituksena on tuottaa jaettu muistikirja ensisijaisesti professorien, toissijaisesti muun henkilökunnan käyttöön. Työkalun kantavana ideana on helpottaa saman pääaineen professorien välistä yhteydenpitoa ja pitää kirjaa opiskelijoille annetuista lupauksista ja esim. opiskelijan diplomityön edistymisestä. Projektin toissijaisena tavoitteena on laajentaa työkalua koskemaan myös kursseja ja jatko-opiskelijoita. Työkalun pitää olla käytettävissä heterogeenisissä ympäristöissä. Järjestelmän luonteen vuoksi tarvitaan pääsynvalvonta sekä muuta tietosuojaa henkilötietosuojan täyttämiseksi. Lisäksi työkalun pitää olla turvallisesti käytettävissä niin TKK:n sisä- kuin ulkopuoleltakin. Projektin asiakkaana on Teknillisen korkeakoulun Tietoliikenneohjelmistojen ja multimedian laboratorio (myöh. TML). Työkalun ovat tilanneet kaksi professoria, Teemupekka Virtanen ja Antti Ylä-Jääski. Asiakkaan puolelta projektille on tarjolla kaksi ohjaajaa, opettavat tutkijat Sanna Liimatainen ja Ursula Holmström. 1.2 Lopputuotteen oikeudet Projektin lopputuote on asiakkaalle tärkeä. Nykyinen tilanne kuluttaa liikaa professorien työaikaa eikä mikään takaa sitä, että opiskelijoille annetut lupaukset todella pidetään siinä muodossa missä ne on tehty. Tästäkin syystä johtuen asiakkaan vaatimuksena on, että projektin tuotosten käyttö- ja jatkokehitysoikeudet jäävät ryhmän lisäksi laboratoriolle. Asiakkaan kanssa on sovittu, että sopimus oikeuksista allekirjoitetaan projektin kuluessa. 1.3 Järjestelmä ja ympäristö Projektissa kehitetään professorien ja muun henkilökunnan käyttöön koordinointia ja viestintää helpottava järjestelmä. Järjestelmän toimintamalli on client-server -perustainen; kaikki informaatio pidetään keskitetysti palvelimella, johon asiakasohjelmilla otetaan yhteyttä. Erilaisten käyttöympäristöjen vuoksi järjestelmän käyttöliittymä on tarkoitus toteuttaa selainpohjaisesti. Järjestelmän ylläpitoa varten voidaan tarpeen vaatiessa toteuttaa esim. Javapohjainen graafinen käyttöliittymä, tarve tälle selvitetään projektin aikana. 1.4 Termit ja määritelmät CVS Concurrent Versioning System IRC Internet Relay Chat PEAR PHP Extension and Add-on Repository, PHP:n laajennuskirjasto PHP PHP: Hypertext Preprocessor, erityisesti WWW-sivujen luontiin tarkoitettu skriptikieli 4

5 SEPA Software Engineering Practice Assignment, ohjelmistotuotannon harjoitus TML Tietoliikenneohjelmistojen ja multimedian laboratorio UML Uniform Modelling Language, ohjelmiston mallinnuskieli XHTML extensible Hypertext Markup Language, sivunkuvauskieli 2 Henkilöstö ja toimijat Projektin organisaatiokaavio esitetään kuvassa 1. TML Asiakas Prof. Antti Ylä-Jääski Asiakas Prof. Teemupekka Virtanen Ohjaaja DI Ursula Holmström SoberIT Mentor Kennet Westerdahl Ohjaaja TkL Sanna Liimatainen Projektiryhmä Projektipäällikkö Samuli Sorvakko Prosessivastaava Jani Heikkinen Laatuvastaava Anssi Kalliolahti Käyttöliittymävastaava Jukka Larja Asiakasvastaava Kim Nylund Järjestelmäarkkitehti Liia Sarjakoski Tietoturvavastaava Timo Toivanen Kuva 1: Organisaatiokaavio 2.1 Projektiryhmä Projektiryhmän tiedot Projektiryhmässä on kolmannen-kuudennen vuoden opiskelijoita joista valtaosan pääaine on Tietoliikenneohjelmistojen ja multimedian laboratoriossa. Nimi: Sähköposti: Hirviö hirvio(at)tml.hut.fi 5

6 2.1.2 Projektiryhmän jäsenet ja vastuualueet Seuraavassa lyhyt esittely jokaisesta projektiryhmän jäsenestä. Nimi: Jani Heikkinen Rooli: Prosessivastaava Puhelin: Sähköposti: jahh(at)iki.fi Opinnot ja työkokemus: Viidennen vuoden opiskelija, pääaineena tietoliikenneohjelmistot ja sivuaineena ohjelmistojärjestelmät. Työskentelee neljättä vuotta ylläpitäjänä TML:ssä sekä ollut kurssiassistenttina muutamalla kurssilla. Nimi: Anssi Kalliolahti Rooli: Laatuvastaava Puhelin: Sähköposti: anssi.kalliolahti(at)iki.fi Opinnot ja työkokemus: Neljännen vuoden opiskelija, pääaineena ohjelmistojärjestelmät ja sivuaineena tietoliikenneohjelmistot. Työskentelee ohjelmistokehitystehtävissä, joista työkokemusta noin kaksi vuotta. Nimi: Jukka Larja Rooli: Käyttöliittymävastaava Puhelin: Sähköposti: jlarja(at)cc.hut.fi Opinnot ja työkokemus: Kuudennen vuoden opiskelija, pääaineena Sisällöntuotanto ja sivuaineena Vuorovaikutteinen digitaalinen media. Työskentelee neljättä vuotta assistenttina TML:ssä. Nimi: Kim Nylund Rooli: Asiakasvastaava, vastuuna on ohjelmiston vaatimusten hallinta ja asiakaskontaktit. Puhelin: Sähköposti: kim.nylund(at)hut.fi Opinnot ja Viidennen vuoden opiskelija, pääaineena tietoliikenneohjelmistot. Suorittaa sivuaineena aikuiskasvatustieteen approbaturin työkokemus: Helsingin yliopistolla. Työskentelee assistenttina kolmatta vuotta TML:ssä. Nimi: Liia Sarjakoski Rooli: Järjestelmäarkkitehti Puhelin: Sähköposti: liia.sarjakoski(at)hut.fi Opinnot ja työkokemus: Kolmannen vuoden opiskelija, pääaineena tietoliikenneohjelmistot. Työkokemusta kurssiassistenttina toimimisesta sekä WWWsovelluksista. Nimi: Samuli Sorvakko Rooli: Projektipäällikkö, vastuuna on huolehtia tehtävienjaosta ryhmän sisällä sekä viestinnän toimivuudesta. Lisäksi projektipäällikkö on päävastuussa koko projektista. Puhelin: Sähköposti: ssorvakk(at)niksula.hut.fi Opinnot ja Viidennen vuoden opiskelija, pääaineena tietoliikenneohjelmistot. työkokemus: assistenttina useilla Työskennellyt järjestelmäylläpitäjänä muutamissa firmoissa sekä kursseilla. 6

7 Nimi: Timo Toivanen Rooli: Tietoturvavastaava Puhelin: Sähköposti: thtoivan(at)cc.hut.fi Opinnot ja työkokemus: Viidennen vuoden opiskelija, pääaineena ohjelmistojärjestelmät, sivuaineina tietoliikenneohjelmistot ja avaruustekniikka. Työskennellyt assistenttina TML:ssä sekä tietojenkäsittelyopin laboratoriossa sekä muun muassa ylläpitotehtävissä. Jokainen ryhmän jäsen osallistuu järjestelmän toteuttamiseen ja on vastuussa koodaamansa luokan/paketin laadusta. 2.2 Muut toimijat Muut projektiin yhteydessä olevat tahot ovat asiakkaan edustajia sekä kurssin meille osoittama mentor. Nimi: Ursula Holmström Rooli: Ohjaaja Puhelin: Sähköposti: ursula(at)tml.hut.fi Esittely: DI, viidettä vuotta opettava tutkija TML:ssa Nimi: Sanna Liimatainen Rooli: Ohjaaja Puhelin: Sähköposti: sos(at)tml.hut.fi Esittely: Tekniikan lisensiaatti, viidettä vuotta opettava tutkija TML:ssa. Nimi: Teemupekka Virtanen Rooli: Asiakas Puhelin: Sähköposti: tpv(at)tml.hut.fi Esittely: TkT, Tietoliikenneohjelmistojen professori Nimi: Kennet Westerdahl Rooli: Mentor Puhelin: Sähköposti: kwesterd(at)cc.hut.fi Esittely: Työkokemus SysOpen Oyj:ssä 4 vuotta, nykyisin projektipäällikkö. Nimi: Antti Ylä-Jääski Rooli: Asiakas Puhelin: - Sähköposti: antti.yla-jaaski(at)tml.hut.fi Esittely: TkT, Tietoliikenneohjelmistojen professori, työkokemus Nokia Oyj 15 vuotta, ETH Zurich 5 vuotta. 7

8 3 Projektin tavoitteet ja päättymiskriteerit 3.1 Asiakkaan tavoitteet lyhyesti Tavoite 1 Opiskelijakohtaisten muistiinpanojen tallentaminen 2 Hakujen tekeminen nimen tai opiskelijanumeron perusteella 3 Järjestelmän käyttäminen sekä laboratorion sisältä että etänä Arviointikriteeri Ryhmä arvioi vaatimusmäärittelyn perusteella ja hyväksyttää valmistumisen asiakkaalla. Ryhmä arvioi ja testaa hakujen toimivuuden. Ryhmä toteuttaa teknisen osuuden näin, asiakkaan vastuulla on asentaa lopputuote s.e. se on käytettävissä laboratorion palomuurin ulkopuolelta. 4 Opiskelijan perustietojen tallentaminen Ryhmä arvioi asiakkaan hyväksymien testauskäytäntöjen pohjalta tallennuksen toimivuuden. 5 Opiskelijakohtaisten tiedostojen tallentaminen Ryhmä arvioi asiakkaan hyväksymien testauskäytäntöjen pohjalta tallennuksen toimivuuden. 6 Tietoturvallinen järjestelmä Ryhmä arvioi sisäisen testauksen ja vertaustestauksen perusteella järjestelmän kokonaisturvallisuuden, asiakas hyväksyy testauskäytännöt. 7 Diplomitöiden seuraaminen Asiakas ilmoittaa haluamansa kriteerit diplomitöiden tiloille. Tämän jälkeen ryhmä arvioi seurannan toimivuuden asiakkaan hyväksymien testauskäytäntöjen mukaisesti. 8 Työryhmät Ryhmä toteuttaa työryhmätoiminnallisuuden asiakkaan hyväksymällä tavalla ja testaa toimivuuden sovittujen käytäntöjen mukaisesti. 9 Raportit Asiakas arvioi ryhmän toteuttamien raporttien sopivuuden. 10 Opiskelijakäyttöliittymä Ryhmä arvioi ja verteistestaa opiskelijakäyttöliittymän toimivuuden asiakkaan antamien kriteerien perusteella. 3.2 Projektiryhmän tavoitteet Kaikille projektiryhmän jäsenille yhteisenä tavoitteena on saada arvokasta kokemusta ohjelmiston suunnittelu-, kehitys- ja toteutusprosessista. Projekti tarjoaa hyvän mahdollisuuden päästä soveltamaan eri kursseilla opittuja menetelmiä kohtuullisen turvallisessa ja vähäriskisessä ympäristössä. Kurssinäkökulmasta katsoen ryhmämme pyrkii suorittamaan projektin siten, että kurssin ohjemateriaalin kirjain ja henki täytetään. Tarkoituksemme siis on suorittaa kurssi niin hyvin kuin pystymme. Arvosanatavoitteemme on kiitettävä (5). 3.3 Henkilökohtaiset oppimistavoitteet Jani Heikkinen: Tavoitteena oppia käytännössä ohjelmistoprosessin ohjausmenetelmiä ohjelmistoprojektissa. Janin SEPA-tehtäväaiheena on refaktorointi, jossa pyritään parantamaan lähdekoodia ilman uusien toimintojen lisäämistä sekä estää lähdekoodin hajoamista pitkäaikaisessa ohjelmistokehityksessä. 8

9 Anssi Kalliolahti: Tavoitteena päästä kokeilemaan itselle uusia ohjelmistotuotannon menetelmiä. SEPA-tehtävänä Anssilla on suunnittelumallien (Design Patterns) soveltaminen. Jukka Larja: Tavoitteena oppia soveltamaan käytännössä eri kursseilla opittuja työtapoja suurehkossa projektissa. Erityisesti Jukan pyrkimyksenä on erilaisten työkalujen sujuvan käytön opettelu ja opittujen taitojen soveltaminen käyttöliittymän suunnittelussa ja toteutuksessa. SEPA-tehtävänä on heuristinen arviointi (Heuristic evaluation). Tehtävä on tarkoitus tehdä yhdessä tietoturvavastaava Timo Toivasen kanssa. Pyrkimyksenä on kehittää käyttöliittymää tietoturvaa heikentämättä. Kim Nylund: Tavoitteena oppia toimimaan isohkon projektiryhmän jäsenenä. Tavoitteena myös oppia toimimaan rajapintana asiakkaan ja ryhmän välillä, sekä oppia kirjoittamaan asiakkaan tarpeet selkeiksi vaatimuksiksi. Lisäksi Kimin tavoitteena on oppia ryhmätyökalujen käyttöä. SEPA-aiheena on, Jani Heikkisen kanssa yhdessä, koodin refaktorointi (Refactoring). Liia Sarjakoski: Tavoitteena oppia toimimaan ohjelmistoprojektissa ja tutustua ohjelmistotuotantoon liittyviin hyviin käytäntöihin. Tavoitteena myös oppia erityisesti arkkitehtuurisuunnittelusta. SEPA-tehtävänä suunnittelumallien (Design Patterns) soveltaminen arkkitehtuuriin. Samuli Sorvakko: Projektipäällikkönä Samulin tavoite on projektin johtamisen opettelu kohtuullisen turvallisessa ympäristössä. SEPA-tehtäväksi hän valitsi eri toimijoiden välisen viestinnän merkityksen selvittämisen. Timo Toivanen: Tämä on ensimmäinen suurehko ohjelmistoprojekti, joten miltei kaikki projektiin liittyvä on uuden opettelua. Erityisesti tarkoituksena on oppia pitämään huolta projektin tietoturvanäkökohdista sen kaikissa vaiheissa. SEPA-tehtävä on tarkoitus tehdä yhdessä käyttöliittymävastaava Jukka Larjan kanssa, koska perinteisesti käytettävyys ja tietoturva on mielletty vaikeasti yhdistettäviksi tavoitteiksi. Projektin yhteydessä olisi tarkoitus oppia miten nämä sovitetaan yhteen niin, että kummankin osa-alueen tavoitteet toteutuvat riittävän hyvin. 3.4 Projektin keskeytyskriteerit Projekti katsotaan keskeytyneeksi, jos vähintään kaksi projektiryhmän jäsentä jättää projektin kesken. Projekti voidaan myös keskeyttää koko ryhmän yhteisellä päätöksellä. 3.5 Projektin päättymiskriteerit Projekti päättyy jonkin seuraavan ehdon toteutuessa: Kurssin päättymispäivämäärä ohitetaan Projektin asiakas hyväksyy projektin päättymisen Kaikki projektille määrätyt tuotokset on testattu ja hyväksytysti toimitettu 4 Resursointi 4.1 Henkilöstö paksulla fontilla merkityt tunnit ovat toteutuneita tunteja 9

10 Heikkinen Kalliolahti Larja Nylund Sarjakoski Sorvakko Toivanen PP Tot Tot Toim Yht Taulukko 1: Työtuntisuunnitelma tunteina Kustannus kpl Kappalehinta Yhteensä Projektiryhmän työtunnit EUR/h EUR Asiakkaan työtunnit EUR/h EUR Laitteistokustannukset EUR 2000 EUR Yhteensä Taulukko 2: Projektin kokonaiskustannukset 4.2 Materiaalit Ryhmän käytössä on levytilaa TML:n CVS-palvelimelta ja lisäksi projektin sähköpostilista on laboratorion sähköpostipalvelimella. Laboratorio antaa ryhmän käyttöön myös kehityspalvelimen. Kehitystyötä voidaan tehdä laboratorion yleiskäyttöisiltä päätteiltä. Ryhmämme voi käyttää myös TML:n kokoustiloja sekä asiakaspalaverien että sisäisten kokousten pitämiseen. 4.3 Budjetti Projektin työmääräkustannukset olisivat huomattavat, mikäli projekti toteutettaisiin täysin kaupallisesti. On epätodennäköistä, että korkeakoulu olisi halukas panostamaan projektiin sen tarvitsemia summia. Taulukossa 2 on esitetty arvio projektin kokonaiskustannuksista. 5 Työtavat ja työkalut 5.1 Käytännöt Iteratiivinen kehitys Tuotteen kehityksessä käytetään inkrementaalista iteraatiomallia ja käyttökuvauksia. Jokainen iteraatio jaetaan aktiviteetteihin ja niistä edelleen tehtäviin. Toteutus (implementointi) tehdään inkrementaalisesti järjestyksessä: järjestelmän arkkitehtuuri, avaintoiminnot, toissijaiset toiminnot ja viimeistely. Tämä käytäntö suosii arkkitehtuuriin painottuvaa testausta, minkä vuoksi oliosuunnittelussa tulee noudattaa vastuulähtöistä suunnittelua (responsibility-driven design) [2]. Jokaisen iteraation lopussa järjestelmä tulee olla testattu ja käyttövalmis implementoitujen toimintojen osalta Iteraatiosuunnittelu Jokaisen iteraation alussa tavoitteet ja toimitukset suunnitellaan yhdessä asiakkaan kanssa. Iteraatiosuunnittelussa arvioidaan tärkeimpiin käyttökuvauksiin ja toimintoihin kuluva aika. Asiakas määrittelee toimitettavien osien prioriteetin. Toimitukset jaetaan tehtäviin, joiden toteuttamiseen kuluva aika tulisi olla n. 10h 20h. 10

11 Jos iteraation aikana havaitaan, että tehtävän/tehtävien toteuttamiseen kuluva aika on enemmän tai vähemmän kuin suunniteltu aika, iteraation toimitettavien osien määrää voidaan vähentää tai lisätä. Käytettävä aika pyritään pitämään suunnitellulla tasolla. Ensimmäisen iteraation suunnitelussa otetaan huomioon asiakkaan ensisijaisesti haluamat toiminnot, jotka luovat pohjan järjestelmän arkkitehtuurille. Tässä vaiheessa analysoidaan, suunnitellaan ja toteutetaan järjestelmän arkkitehtuuri ja sen tärkeimmät toiminnot. Arkkitehtuurista laaditaan määrittelydokumentti (kts. kappale 6.2.2). Ensimmäisessä iteraatiovaiheessa suunnitellaan testaus arkkitehtuurille ja avaintoiminnoille. Testauksessa löydetyt virheet raportoidaan ja korjataan (kts. kappale 5.1.4). Toisessa iteraativaioheessa toissijaiset toiminnot analysoidaan, suunnitellaan ja yhdistetään olemassaolevaan arkkitehtuuriin. Tässä vaiheessa kirjoitetaan alustava järjestelmän käyttöohje. Kolmas iteraatiovaihe alkaa pienellä inkrementtitoteutuksella, jossa kehitetään olemassa olevia toiminnallisuuksia ja asiakkaalle luovutettavat ohjeet. Vaihe päättyy järjestelmätestaukseen Dokumentointi Dokumentit kirjoitetaan LaTeX-muotoon. Ryhmä palauttaa dokumentit kurssille PDF-muodossa, käyttäen muunnokseen pdflatex-työkalua. LaTeX-tiedostojen tulee olla aina virheettömästi käännettävissä, ennenkuin tiedosto päivitetään CVS:ään. Jokaisen dokumenttiin liitetään sanahakemisto kaikista uusista termeistä, joita dokumentissa on käytetty. Sanahakemiston täytyy olla selvästi indeksoitu, jotta siihen voidaan viitata muista dokumenteista tarvittaessa. Kaikki dokumentit kirjoitetaan siten, että niiden sisältöön voidaan projektin kuluessa viitata yksiselitteisesti. Yksi asiakokonaisuus dokumentoidaan vain yhdessä dokumentissa, johon muista dokumenteista viitataan. Dokumenteilla tarkoitetaan tässä myös käyttö- ja testikuvauksia (use cases, test cases). Dokumenttien muutoksenhallintaa varten toteutetaan LaTeX-makropaketti, jolla kukin ryhmän jäsen voi lisätä dokumentteihin omia kommenttejaan. Kommentit tulostuvat dokumentin esikatseluversioihin mutta niiden näkyminen estetään dokumenttia tuotettaessa. Tällä parannetaan tekstin kirjoittajan ja muutoksen ehdottajan välistä viestintää Raportointi Muutosraportit lähetetään ryhmän sähköpostilistalle. Listalle lähetetään ilmoitus kaikista merkittävistä muutoksista dokumentaatiossa, ohjelmistossa sekä työkaluissa. Lisäksi listalla koordinoidaan ryhmän sisäistä työnjakoa eri osa-alueiden toteuttamisen suhteen. Pienemmistä muutoksista keskusteluun voidaan käyttää ryhmän IRC-kanavaa. Keskusteluosapuolet ovat velvollisia tekemään keskustelustaan sähköpostiraportin muulle ryhmälle, mikäli keskustelussa on sovittu jotain merkittävää. Lajittelun selkiyttämiseksi kaikkiin listalle tuleviin sähköpostiviesteihin lisätään otsikkoon tunniste [hirviö]. Vikaraportoinnissa käytetään kurssin suosittelemaa Bugzilla-järjestelmää. Viat kirjataan Bugzillaan mahdollisimman täydellisinä heti niiden löydyttyä. Ryhmäpalavereissa (katselmoinneissa) jaetaan vastuut ja korjausaikataulut vioille. Edistymisraportteja on kahta lajia. Ensimmäinen on kurssin vaatimuksiin kuuluva, joka vaiheen lopussa palautettava raportti. Toinen on vapaamuotoisempi, n. kahden viikon välein projektin toimijoille lähetettävä raportti, jossa kerrotaan viimeaikaisista kehityksistä. Edistymisraporteista on vastuussa projektipäällikkö. 11

12 Työajan raportointiin käytetään kurssin tarjoamaa Trapoli-järjestelmää. Projektipäällikkö huolehtii siitä, että järjestelmässä on tarvittavat tehtäväkuvaukset. Kukin ryhmän jäsen on vastuussa siitä, että tehdyt tunnit tulevat kirjatuksi (puolen tunnin tarkkuudella) Trapolijärjestelmään mahdollisimman pian suorituksen jälkeen Projektikatselmoinnit Ennen varsinaista projektikatsemointia mentorille ja asiakkaan edustajille lähetetään käsiteltävä katselmointimateriaali, johon pyydetään tutustumaan ennen itse katselmointia. Projektikatselmoinneissa esitetään kalvoesitys, jolla kerrotaan lyhyesti projektin tilasta mentorille sekä asiakkaan edustajille. Projektikatselmointien kulusta sekä esityksen valmistelusta on vastuussa projektipäällikkö Ryhmän kokoukset Ryhmä pyrkii kokoontumaan mahdollisimman täydellisenä viikottain pidettävään kokoukseen. Kokouksessa päätetään projektin aikataulun perusteella seuraavaksi suoritettavat tehtävät ja määrätään niille vastuuhenkilö. Jokaisesta kokouksesta tehdään pöytäkirja, johon kirjataan kokouksessa käsitellyt ja päätetyt asiat. Tehtäväseurantaa varten projektipäällikkö ylläpitää tehtävälistaa, johon merkitään tehtävä, tehtävän vastuuhenkilö sekä tehtävän määräaika Vaatimusten hallinta Vaatimusten hallinta on koko projektin kestävä prosessi, jonka perustana on vaatimusmäärittelydokumentti. Vaatimusten hallinnan tavoitteena on varmistaa, että asiakkaan vaatimukset otetaan huomioon projektin jokaisessa vaiheessa. Vaatimusten hallintaan kuuluu myös vaatimusten muutosten hallinta. Vaatimusten hallinnasta vastaa asiakasvastaava, joka toimii läheisessä yhteistyössä asiakkaan kanssa. Kukin vaatimus tulee täyttää suunnittelussa, toteutuksessa ja testauksessa myöhemmin projektissa. Vaatimusten täyttymistä seurataan vaatimusmäärittelydokumentissa annettavien tunnisteiden perusteella. Seuraavassa luvussa kerrotaan lisää vaatimusmuutoksista Muutostenhallinta Projektiryhmän tai asiakkaan ehdottama vaatimus saa ensiksi statuksen ehdotus. Tässä tilassa olevaa vaatimusta voi muuttaa sellaisenaan. Kun asiakas ja projektiryhmä hyväksyy vaatimuksen, se saa statuksen hyväksytty. Hyväksyttyyn vaatimukseen voidaan tehdä muutoksia, jos muilla vaatimuksilla tai dokumenteilla ei ole siihen riippuvuuksia tai jos muiden vaatimusten ja dokumenttien riippuvuudet voidaan myös muuttaa. Muutos voidaan kuitenkin tehdä vain, jos asiakas ja projektiryhmä hyväksyvät muutoksen. Toteutettua vaatimusta muutetaan vain hyvin painavista syistä ja samoilla edellytyksillä kuin hyväksyttyjä vaatimuksia. Kun vaatimus on verifioitu, sitä ei enää muuteta. Muutokset vaatimuksissa päivitetään vaatimusmäärittelydokumenttiin sekä kaikkiin niihin dokumentteihin, joissa ne esiintyvät. Etenkin muutokset projektisuunnitelmassa päivitetään tähän dokumenttiin. Muutokset otetaan huomioon myös ohjelmakoodissa ja testitapauksissa. Laaja-alaisista muutoksista tulee informoida kaikkia osapuolia, joiden vastuualueella muutos tapahtuu. 12

13 5.1.9 Versionhallinta Versionhallinnassa käytetään CVS:ää. Jokaisen iteraation lopuksi kaikki toimitettavat merkitään samaan julkaisuun (release). Jos on tarvetta, voidaan käyttää myös kappaleessa esitetyn koodaustavan mukaisia julkaisukanditaatteja tai mikrojulkaisuja. Tehtyjen muutoksien kommentointi on pakollista CVS:ään. Kommenttien tulee viitata jokaisen talletetun (commit) tiedoston sisäiseen rakenteeseen Koodaustavat Toteutuksessa noudatetaan PEAR:n PHP koodaustyylistandardin ( manual/en/standards.php) koodaustapoja Vertaistestaus Projektiryhmä suorittaa vertaistestausta viimeisen iteraatiokierroksen aikana. Ryhmälle määritellään myöhemmin vertaistestausryhmä, jonka kanssa testausta tehdään ristiin SBTMmenetelmällä. Aikaa vertaistestaukselle on varattava vähintään kahdeksan tuntia. 5.2 SEPA -yhteenveto Aihe Vastuuhenkilö(t) Käyttöaika Yhteydenpitokäytännöt Samuli Sorvakko PP-DE Heuristinen evaluointi Jukka Larja ja Timo Toivanen I1-I2 Design Patterns Anssi Kalliolahti ja Liia Sarjakoski I1-I2 Refaktorointi Jani Heikkinen ja Kim Nylund I1-I2 Projektin vaiheet: PP projektisuunnittelu I1,I2 Toteutuskierrokset DE toimitus 5.3 Laadunvalvontasuunnitelma Ennen projektisuunnitelmakierroksen päättymistä kaikki tuotettavat dokumentit katselmoidaan. Katselmointiin liittyvä materiaali lähetetään katselmointiryhmälle ennen varsinaista katselmointia. Katselmointiryhmä tutustuu materiaaliin ennalta ja kirjaa ylös epäselvyydet ja esille tulleet virheet. Katselmoinnissa dokumentaatiosta vastaava henkilö käy läpi dokumentin, jonka aikana muu ryhmä esittää kysymyksensä. Katselmoinnissa esille tulleet muutokset päivitetään katselmoituun materiaaliin. Tarkka laadunvalvontasuunnitelma tehdään ensimmäisen implementaatiokierroksen alussa. 5.4 Työkalut Projektissa käytetään seuraavia työkaluja: 13

14 Työkalu CVS Xemacs Trapoli Bugzilla LaTeX Dia HttpUnit PhpUnit PhpDoc PhpEclipse Työkalujen lähdetietoja: Kuvaus Versionhallintajärjestelmä, joka ei ole rakennus- (build tool), projektinhallinta-, viestintä-, muutostenhallinta- tai testaustyökalu Tekstieditori ja sovelluskehitysjärjestelmä Aikaraportointityökalu Virheenseuraamisjärjestelmä Dokumenttien valmistelu- ja latomajärjestelmä Diagrammien suunnitteluohjelma Yksikkötestaustyökalu, joka emuloi selainta Yksikkötestaustyökalu PHP lähdekoodin dokumentointityökalu PHP liitin Eclipse integroituun kehitysympäristöön Viite Lähdetieto TK1 CVS TK2 LaTeX TK3 Bugzilla TK4 Xemacs (php-mode) prog-modes_21.html TK5 PhpUnit Cookbook TK6 PHPDoc TK7 Eclipse eclipse.platform.doc.user/tasks/running_eclipse.htm 5.5 Käytäntöjen analysointi Jokaisen iteraation lopussa ryhmä analysoi käytettyjä työtapoja ja työkaluja. Analysoinnin tulokset raportoidaan edistymisraportissa (kts. kappale 5.1.4). 5.6 Standardit PEAR PHP koodaustyylistandardi ( XHTML v1.1 ( Unified Modeling Language (UML) v1.5 ( formal/uml.htm) 6 Projektin vaiheet 6.1 Aikataulu Taulukossa 3 esitellään projektin karkea aikataulu, jota tarkennetaan projektin edetessä. Aikataulu pohjautuu kurssin sivuilla esitettyyn aikatauluun[1] Dokumenttien valmistelu Kaikkiin kierroksiin kuuluu valmisteltavia dokumentteja. Kunkin dokumentin valmisteluun kuuluu vähintään kolme vaihetta. Ensimmäisessä vaiheessa kirjoitetaan esiversio dokumentista. Yleensä tämä vaihe on kaikkein työläin. Toisessa vaiheessa esiversio toimitetaan katselmoitavaksi asiakkaan edustajille. Asiakkaalta pyydetään dokumentista kritiikkiä, kommentteja ja parannusehdotuksia. Tässä vaiheessa 14

15 Pvm Klo Kuvaus Projektisuunnitelma ( ) :00 Asiakastapaaminen (järjestäytyminen ja yleiskatsaus) :00 Asiakastapaaminen (vaatimusmäärittely) :00 Projektisuunnitelmakierroksen iteraatiosuunnitelma :00 Asiakastapaaminen (vaatimusmäärittely) Seuraavista asiakastapaamisista sovitaan erikseen :00 Sisäinen määräaika suunnitelmadokumenteille :00 Suunnitelmadokumenttien ja -raporttien palautus :00 Palautetilaisuus Implementaatiokierros I ( ) :00 Kierroksella toteutettavien use casejen viimeistely :00 Ensimmäisen implementaatiokierroksen iteraatiosuunnitelma :00 Sisäinen deadline arkkitehtuurikuvaukselle :00 Kierroksen testaussuunnitelma valmis :00 Sisäinen määräaika kierroksen dokumenteille :00 Ensimmäisen implementaatiokierroksen dokumenttien palautus :00 Palautetilaisuus Joululoma ( ) Tarvittaessa varaslähtö Implementaatiokierros II:lle Implementaatiokierros II ( ) :00 Toisen implementaatiokierroksen iteraatiosuunnitelma :00 Sisäinen checkpoint, varmistetaan eteneminen ja jaetaan työt :00 Sisäinen määräaika kierroksen dokumenteille :00 Järjestelmätestauksen aloitus :00 Järjestelmätestauksen DL :00 Dokumenttien ja raporttien palautus :00 Palautetilaisuus Viimeistely ja toimitus ( ) :00 Viimeistelykierroksen iteraatiosuunnitelma :00 Järjestelmän ja testiohjeistuksen toimitus vertaisryhmälle :00 Vertaisarvioinnin palautus :00 Sisäinen määräaika kierroksen dokumenteille :00 Dokumenttien ja raporttien palautus :00 Lopullinen demonstraatio Taulukko 3: Projektin aikataulu suoritetaan myös ryhmän sisäistä kritiikkiä luettamalla dokumenttia niillä, jotka eivät ole olleet sen kirjoitustyössä mukana. Viimeisessä vaiheessa dokumenttia muokataan soveltuvin osin edellisessä vaiheessa saadun kritiikin pohjalta. 6.2 Projektin suunnittelu Tavoitteet Projektin suunnitteluvaiheessa kartoitetaan asiakkaan kanssa projektille asetetut vaatimukset ja tavoitteet sekä aikataulutetaan projekti. Lisäksi vaiheen tarkoituksena on tutustuttaa projektissa työskentelevät toisiinsa sekä asiakkaan edustajiin. Vaiheen aikana rakennetaan projektin tarvitsemat puitteet kehitysympäristön ja ajan- ja dokumenttienhallinnan osalta. Projektin suunnittelusta päävastuussa on projektipäällikkö. Projektipäällikön vastuulla on koordinoida projektisuunnitelman kirjoitus sekä pitää huolta dokumentin muutoksista. 15

16 6.2.2 Toimitukset Dokumentti Määräaika Vastuuhenkilö Projektisuunnitelma Samuli Sorvakko Vaatimusmäärittely Kim Nylund Tilannekatsaus Samuli Sorvakko SEPA-aiheenvalinnat Tehtävät Suunnitteluvaiheen tärkeimpänä tehtävänä on projektisuunnitelman ja vaatimusmäärittelyn tekeminen. Nämä dokumentit luovat pohjan projektin myöhemmille vaiheille, joten tähän vaiheeseen uhrattu aika maksanee itsensä moninkertaisesti takaisin projektin edetessä. Kuvassa 2 on kuvattu suunnitteluvaiheen työtuntisuunnitelma. Vaatimusmäärittelyn tueksi pyrimme tapaamaan asiakasta mahdollisimman monesti. Kuten ohjelmistoprojekteissa yleensäkin, asiakas ei osaa antaa suoraan valmista tarkkaa vaatimusmäärittelyä, vaan ennemminkin ideoita ja olisi kiva jos -tyylisiä kommentteja. Vaatimusmäärittelyn tarkoitus on selventää, mitä asiakas todella tarvitsee. Projektimme ensimmäinen haaste onkin näiden ideoiden rajaaminen ja kirjoittaminen tarkan vaatimusmääritelmän muotoon. Kuva 2: Trapolitehtävät suunnittelukierroksella 6.3 Implementaatio I Tavoitteet Ensimmäisen implementaatiovaiheen tavoitteena on saada projektin arkkitehtuuri suunniteltua sekä toteuttaa määrätyt ydintoiminnallisuudet. 16

17 Ydintoiminnallisuudet Projektin ydintoiminnallisuudet ovat tietokannan määritteleminen ja toteuttaminen sekä käyttäjien tunnistautuminen ja sisäänkirjautuminen paikallisilla tunnuksilla. Lisäksi tässä vaiheessa pyritään saamaan käyttöliittymän runkoelementit valmiiksi, ulkoasu jätetään tässä vaiheessa vielä täysin huomiotta. 6.4 Toimitukset Toimitus Määräaika Vastuuhenkilö Dokumentit Päivitetty projektisuunnitelma Samuli Sorvakko Päivitetty vaatimusmäärittely Kim Nylund Arkkitehtuurikuvaus Liia Sarjakoski Testausmäärittely Anssi Kalliolahti Tietoturvakuvaus Timo Toivanen Tilannekatsaus Samuli Sorvakko Toteutuksen osat Tietokantarakenne Anssi Kalliolahti Tietokanta-abstraktio Jani Heikkinen Kirjautuminen ja sessionhallinta Liia Sarjakoski Käyttöliittymärunko Jukka Larja 6.5 Tehtävät Ensimmäisen toteutuskierroksen pääasiallisena tehtävänä on arkkitehtuurisuunnitelman tekeminen sekä järjestelmän päärungon toteuttaminen. Rungon lisäksi toteutetaan kirjautuminen järjestelmään sekä muistiinpanon lisääminen. Kuvassa 3 on nähtävissä kaikki kierrokselle suunnitellut tehtävät. Kuva 3: Ensimmäisen iteraatiokierroksen Trapoli-tehtävät 17

18 6.6 Implementaatio II Tavoitteet Toisessa implementaatiovaiheessa tarkoituksena on toteuttaa järjestelmän varsinainen toiminnallisuus ensimmäisellä kierroksella rakennetun infrastruktuurin pälle. Lisäksi toisella kierroksella toteutetaan asiakkaan vaatimat raportti- ja muut kyselyt. 6.7 Tehtävät Toisen toteutuskierroksen tehtävät jakautuvat uusien ominaisuuksien toteuttamiseen sekä testaamiseen ja järjestelmän dokumentointiin. Dokumenteista uutena palautetaan käyttöohjeen ensimmäinen versio Toimitukset Toimitus Määräaika Vastuuhenkilö Dokumentit Päivitetty vaatimusmäärittely (sis.) Kim Nylund Päivitetty projektisuunnitelma (sis.) Samuli Sorvakko Päivitetty testaussuunnitelma (sis.) Anssi Kalliolahti Arkkitehtuurikuvaus 8.2. Liia Sarjakoski Testiraportti 8.2. Anssi Kalliolahti Päivitetty tietoturvakuvaus 8.2. Timo Toivanen Käyttöohjeen ensiversio 8.2. Jukka Larja Tilannekatsaus 8.2. Samuli Sorvakko Toteutuksen osat Päivitetty käyttöliittymärakenne Jukka Larja Päivitetty tietokantarakenne Jani Heikkinen Opiskelijakohtaisten muistiinpanojen tallennus (F1) Liia Sarjakoski Hakujen tekeminen (F2) Kim Nylund Opiskelijan tietojen tallettaminen (F3) Anssi Kalliolahti Tiedostojen tallennus (F4) Jani Heikkinen Diplomitöiden seuraaminen (F5) Jukka Larja Ylläpitotyökalu (F7) Timo Toivanen Raportit (F8) Kim Nylund Varmuuskopiointi(F10) Jani Heikkinen Tehtävät Toisen implementaatiokierroksen tehtäväjakauma kuvassa Viimeistely ja toimitus Viimeisen vaiheen suunnitelmat ja tavoitteet tarkentuvat Implementaatio II -kierroksen lopulla Tavoitteet Viimeistelyvaiheessa ohjelmisto paketoidaan ja paketin asennustoimenpiteet dokumentoidaan. Lisäksi viimeistelyvaiheessa päivitetään kaikki dokumentit sekä kirjoitetaan raportti projektin kulusta. 18

19 Kuva 4: Toisen iteraatiokierroksen Trapoli-tehtävät Toimitukset Toimitus Määräaika Vastuuhenkilö Dokumentit Projektisuunnitelma Samuli Sorvakko Vaatimusmäärittely Kim Nylund Arkkitehtuurikuvaus Liia Sarjakoski Testausmäärittely Anssi Kalliolahti Tietoturvakuvaus Timo Toivanen Testiraportti Anssi Kalliolahti Tilannekatsaus Samuli Sorvakko Asennusohje Jani Heikkinen Käyttöohje Jukka Larja Toteutuksen osat Valmis ohjelmapaketti Jani Heikkinen Tehtävät Viimeistelykierroksen tehtävät kuvassa 5. 7 Riskienhallinta Riskienhallinta pyrkii varautumaan, tunnistamaan ja reagoimaan projektin aikana ilmeneviin ongelmiin. Mikäli ongelma-alueet kyetään tunnistamaan jo ennen varsinaisten ongelmien ilmenemistä, voidaan niihin varautua ja niiden mahdollista vaikutusta projektin kulkuun voidaan vähentää tai jopa poistaa kokonaan. Kukin riski on jaettu jo ennakkoon jollekin ryhmän jäsenistä, jotta tällä olisi mahdollisimman paljon aikaa paneutua ongelmakohtiin ja keksiä keinoja ongelmien välttämiseksi. Ennen implementaatio I-vaiheen alkua sovitaan, mitä riskejä ryhdytään aktiivisesti seuraamaan. Samalla esitellään riskien ehkäisemiseksi suunnitellut toimenpiteet ja koostetaan näistä erillinen dokumentti. Riskejä on jonkin verran suodatettu jo ennen tähän kirjaamista, sillä hyvin epätodennäköisiin tai projektin kannalta merkityksettömiin riskeihin paneutuminen olisi liian työlästä hyötyihin 19

20 Kuva 5: Viimeistelykierroksen Trapoli-tehtävät suhteutettuna. 7.1 Skenaariot Riskiskenaariot on taulukossa 4. Viitteet [1] T Schedule viitattu [2] Stephen R. Schach, Object-Oriented and Classical Software Engineering, 5th edition, 2002, viitattu

21 ID Riski Vaikutus Vastuu Aikatauluongelmat S1 Ryhmän jäsenillä liikaa Töiden kasaantuminen Samuli Sorvakko muita kuin projektiin liittyviä vastuita määräaikoja edeltäviin päiviin, aikatauluista lipsuminen S2 Asiakkaalla liian vähän Kim Nylund aikaa paneutua projektiin Ryhmän sisäiset ongelmat G1 Ryhmän sisäiset tavoitteet erilaiset G2 Ryhmän osaamistaso vaihteleva Palautteen saaminen asiakkaalta hidastuu, tapaamisten järjestäminen hankaloituu Jotkut haluavat kurssista paremman arvosanan kuin toiset Osa ryhmäläisistä on kokeneita ohjelmoijia, toisille tämä on ensimmäinen suurempi ohjelmistoprojekti, saattaa aiheuttaa laatuongelmia G3 Jokin ryhmän jäsen Ryhmäläisen työpanos voidaan sairastuu ja/tai luovuttaa joutua jakamaan pikaisella kesken projektin aikataululla muille Ryhmästä riippumattomat ongelmat E1 Asiakkaan edustajien virkasuhteita katkolla Muutokset asiakkaan edustajissa aiheuttavat ylimääräistä työtä projektin tavoitteiden selvittämisessä uusille edustajille E2 Asiakkas ei voi ottaa Asiakas ei saa tuotetta käyttöönsä tuotantokäyttöön PHP5 kieltä Työvälineongelmat T1 Tuotantoympäristöä Ei välttämättä osata varautua ei vielä ole määritelty tuotantoympäristön erityispiirteisiin tarkkaan T2 Tuotantoympäristön viat Tuotantoympäristöön kuuluvissa kolmansien osapuolien komponenteissa saattaa ilmetä vikoja T3 T4 Tuotantoympäristön tietoturvaongelmat Käytetään ennestään tuntemattomia työkaluja Tuotantoympäristöön kuuluvissa kolmansien osapuolien komponenteissa saattaa ilmetä tietoturvaongelmia Työkalujen ominaisuudet saattavat aiheuttaa yllätyksiä ja viivästyksiä asennuksessa tai käytössä Taulukko 4: Riskiskenaariot Samuli Sorvakko Anssi Kalliolahti Jani Heikkinen Kim Nylund Anssi Kalliolahti Liia Sarjakoski Liia Sarjakoski Timo Toivanen Jani Heikkinen 21