Projektisuunnitelma. Ryhmän nimi: Toimeksiantaja: Toimeksiantajan edustaja: Versio: Katselmoitu (pvm.):

Transkriptio

1 Projektisuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1

2 1 Johdanto Tässä luvussa annetaan yleiskuva ohjelmistoprojektista. Tämä dokumentti sisältää esimerkkejä muutamista tärkeimmistä käsitteistä ja tekniikoista, joita projektisuunnitelmassa voi käyttää (kurssilla so. tulee). Esimerkit liittyvät kuvitteellisen autokorjaamon tietojärjestelmään. Tässä tulee huomata, että esimerkit eivät pyri olemaan täydellisiä, vaan havainnollisia. Joitain ilmeisiä kohtia on jätetty täyttämättä (kurssilla ne tulee täyttää). Edelleen tässä esimerkkidokumentissa jotkin kohdat on täytetty hyvin niukasti. Kurssin www-sivuilta löytyviin muihin dokumenttipohjiin sisältyvät esimerkit liittyvät samaiseen autokorjaamon tietojärjestelmään. 1.1 Projektin laajuus Esitetään ohjelmiston kuvaus. Kuvataan tärkeimmät syötteet, toiminnallisuus ja tulokset puuttumatta toteutukseen liittyviin yksityiskohtiin. 1.2 Ohjelmiston tärkeimmät toiminnot Esitetään ohjelmiston toiminnallinen ositus täällä (aikataulutusta varten). Autokorjaamon tietojärjestelmä jakaantuu asiakkaiden hallintaan, korjaus- ja huoltotoimenpiteiden kirjausjärjestelmään, laskutusjärjestelmään ja varastonhallintaan. Toimenpiteitä päivitetään järjestelmään töiden lomassa (pääte hallin puolella). Toimenpiteistä näkee suoraan varastotilanteen ja pystyy tulostamaan laskun. Laskutustapoja on useita. Varastojärjestelmästästä liittymismahdollisuus varaosatoimittajien tilausjärjestelmiin. Järjestelmästä tulee pystyä tulostamaan erilaisia viikoittaisia ja kuukausittaisia raportteja. 1.3 Tehokkuus- ja toiminta-asiat Kirjataan erityisvaatimukset tehokkuudesta tai toiminnoista tänne. Toimenpiteen tallentamiseen tietylle asiakkaalle ei saa mennä liikaa aikaa. Eikä muihinkaan toimintoihin. Mitään tarkkoja ja tiukkoja aikarajoja ei anneta tässä (täsmällisempiä löytyy vaatimusmäärittelyssä). 1.4 Hallinta- ja tekniset rajoitukset Kirjataan kaikki projektin läpivientiin liittyvät erityisrajoitteet tänne. Esim. resurssirajoitteet tai viimeinen mahdollinen toimituspäivä (so. päivä, jonka jälkeen yhteydenpito lakkaa). Kirjataan myös tekniset lähestymiset tai lähtökohdat kehittämiseen 2

3 tänne. Myös erilaiset oletukset, riippuvuudet ja muut reunaehdot voidaan kirjata tänne. WWW-käyttöliittymät järjestelmiin. 1.5 Määritelmät, termit, akronyymit ja lyhenteet 2 Osallistujat Kuvataan tapa, jolla osallistujat organisoituvat, ja raportointimekanismit. 2.1 Ryhmän rakenne Kuvataan projektiryhmän rakenne. Määritellään roolit ja vastuuhenkilöt. AA: projektipäällikkö. BB: suunnittelija, vastuualueena tietokanta ja vaatimusmäärittely. CC: suunnittelija, vastuualueena WWW-liittymä ja testaussuunnitelma. jne. 2.2 Organisaation rakenne Kuvataan organisaation rakenne lyhyesti. Autokorjaamo koostuu toimistosta ja korjaamohallista. Toimiston puolelta hoituvat tilausten vastaanotot, laskutus ja varastotäydennykset ja ostolaskujen maksut. Hallin puolelta varastotäydennykset, toimenpidekirjaamiset jne. 2.3 Sidosryhmät Kuvaus sidosryhmistä ja sieltä löytyvistä vastuuhenkilöistä. Korjaamo käyttää pääasiassa viittä eri varaosatoimittajaa, nimet, yhteystiedot ja vastuut voi kirjatata. Huomautuksena, että myös kurssin luennoitsija on syytä mainita tässä: tarkoitus on tehdä selväksi, että tiedottamisessa ei saa sivuuttaa kurssin luennoitsijaa. Lisäksi: Asiakas: (näitä rivejä voi olla useampia) Isto Aho: projektin omistaja. 2.4 Hallinnan raportointi ja kommunikaatio Yksilöidään mekanismit edistymisen raportointiin ja ryhmän sisäiseen ja ulkoiseen kommunikointiin. 3

4 Kuinka viikkoraportointi organisoidaan tarkemmin? Onko jokin tietty viikoittainen aika ja paikka, jossa tavataan? Huomautus: kurssin luennoitsijalle on tultava viikkoraportteja edistymisestä. Kurssin www-sivuilta löytyy malli viikkoraportista. Lisäksi asiakkaille on lähetettävä säännöllisesti erillisiä koostettuja raportteja edistymisestä (näistä lisää aliluvussa 5.1). Tänne vielä tulee kirjata, mitkä raportit ja dokumentit välitetään kenellekin, ja milloin. 3 Projektin läpivientiarviot Tässä luvussa annetaan projektin hinta-, työmäärä- ja aika-arviot. Ks. kalvot kustannusja aikatauluarvioiden tekemisestä. 3.1 Arvioinneissa käytetty historiallinen data Kuvaa historiallisen datan, joka on oleellista esitettäville arvioille. Historiadataa ei ole juurikaan käytettävissä tätä projektia varten. (Mikäli löytyy, kannattaa kokemuksia käyttää hyväksi.) 3.2 Sovellettavat arviointitekniikat ja tulokset Esitetään kunkin arviointitekniikan kuvaus ja niillä saavutettavat arviot. COCOMO-mallin tarkempia kuvauksia löytyy useasta eri kirjasta. Kurssin luentokalvoilla on tiivis kuvaus COCOMO-mallista Arviointitekniikka m Esitetään tekniikkaan m liittyvät taulukot ja kaavat. Luku toistetaan kullekin m tekniikalle. Tähän esimerkkiin on valittu kaksi tekniikkaa, COCOMO (constructive cost model) ja toimintopisteanalyysi (function point). (Tämän luvun otsikko olisi valmiissa dokumentissa jokin toinen kuin Arviointitekniikka m.) COCOMO Lyhyt kuvaus COCOMO-mallista. (Ks. kalvot.) Toimintopisteanalyysi Lyhyt kuvaus toimintopisteanalyysista. (Ks. kalvot.) Arviointi tekniikalla m Arviot, jotka saadaan tekniilla m. Tämä toistetaan kutakin luvun alilukua kohden. 4

5 Esimerkissä arviot toistetaan COCOMO-mallille ja toimintopisteanalyysille. (Tämän luvun otsikko olisi valmiissa dokumentissa jokin toinen.) COCOMO Esitetään COCOMOlla saatavat arviot. (Ks. kalvot.) Toimintopisteanalyysi kalvot.) Esitetään toimintopistenalyysilla saatavat arviot. (Ks. 3.3 Arviointien koosteet Esitetään nykyhetken lopulliset hinta-, työmäärä- ja aikakestoarviot projektista. 3.4 Projektin resurssit Kuvataan ihmiset, laitteet, ohjelmat, työkalut ja muut tarvittavat resurssit. Samalla kuvataan resurssien allokointi ja käyttö ja käytettävissä oleva budjetti. Projektiryhmän lisäksi tarvitaan asiakkaan puolelta tämän projektin omistaja (jos liittyy johonkin heidän projektiin, saattaisi olla esimerkiksi projektipäällikkö). Esimerkissä tämä olisi korjaamopäällikkö. Lisäksi tarvitaan järjestelmän tulevia käyttäjiä, esimerkissä vastaisi yhtä tai kahta mekaanikkoa. Järjestelmä toteutetaan linuxilla, joten tarvitaan yksi serveri, josta löytyy GCC ja gmake Lisäksi tarvitaan versionhallintasovellus, ja tietokanta- ja wwwpalvelin, jotka voivat olla serverillä (tarkemmat versiot ja nimet mukaan). Projektiryhmää varten tarvitaan viisi linux-työasemaa, joista löytyy käännöstyökalut. Koneiden tulee olla verkotettu keskenään. Projektia varten on budjetoitu ryhmän osalta * 200 työtuntia. Euroissa 200 * 20 * * 17 * 1.8, mikä tekee noin euroa. (Tähän vielä sopiva voittomarginaali ja tilakulut.) 4 Riskien hallinta Tässä luvussa pohditaan projektin riskeja ja tapoja hallita niitä. Ks. kalvot riskien hallinnista. 4.1 Projektin riskit Kuvataan kukin riski. Ks. seuraava aliluku. 5

6 Taulukko 1: Tarve integroida/liittyä muihin systeemeihin. olemassa oleviin systeemeihin: Sovellus kehitetään puhtaalta pöydältä vs. sovellusta kehitetään nykyisen (ei oman) päälle. Tuore kokeilu vs. peritään olemassa olevaa teknologiaa ja systeemejä. Ei tarvitse muuttaa muiden koodia vs. tarvitsee koskea muiden koodeihin. Ei tarvitse tehdä mutkikkaita liittymiä muiden tekemiin sovelluksiin vs. tarvitsee tehdä. Tehtävän systeemin ei tarvitse integroitua jonkin tuntemattoman kolmannen osapuolen systeemin tai tuotteen kanssa vs. tarvitsee integroitua. Ei tarvitse kommunikoida/liittyä suoraan jonkin tuntemattoman laitteistojen kanssa vs. tarvitsee kommunikoida/liittyä. tuleviin systeemeihin: Uuden systeemin ei tarvitse olla erityisen mukautuva tulevaisuuden tarpeisiin vs. systeemin täytyy olla kohtuullisen mukautuva tuntemattomien tulevien tarpeiden varalta. Systeemin tuskin tarvitsee liityntää johonkin vielä määrittelemättömään tulevaan systeemiin vs. tarvinnee liitynnän. 4.2 Riskitaulukko Esitetään täydellinen riskitaulukko: riskin nimi, todennäköisyys ja vaikutus. Seuraava lista perustuu kirjan Coping with IS/IT risk management, Tony Moynihan, riskilistaan. Lista on alla jaettu osioihin, joista tärkeimmistä voisi olla pari sanaa edellisessä aliluvussa. Lisäksi oman projektin kannalta tärkeimmistä yksittäisistä riskeistä saisi olla mainintoja edellisessä aliluvussa. Edelleen osa edellisen sivun kohdista ei sellaisenaan toimi riskin nimenä : jos niitä käyttää, tulisi miettiä, mistä riskistä kyseissä kohdassa on kyse. 6

7 Taulukko 2: Projektin haltijan olemassaolo/kokemus/sitoutuminen. Asiakas/sponsori on selvästi tunnistettava henkilö vs. on lavea (esim. komitea). Toimitaan suoraan päätöksentekijän kanssa vs. toimitaan henkilön kanssa, jolla ei ole päätäntävaltaa. Joku asiakasorganisaatiosta on ottanut selvän vastuun ja omistajuuden projektista vs. kukaan ei näytä haluavan omistaa projektia. Projektinomistaja on tarpeeksi korkealla organisaatiossa suojatakseen ja auttaakseen tarvittaessa vs. tällaista henkilöä ei löydy. Projektinomistajalla on iso panos projektin onnistumisessa vs. hänellä ei ole juurikaan menetettävää, vaikka projekti epäonnistuisi. Asiakas näyttää hyvin pystyvän hoitamaan kaiken politiikan projektin ympärillä vs. voi olla tehoton. Asiakkaan yhteyshenkilö(i)llä on tarvittavaa aikaa, osaamista ja arvovaltaa vs. jotain luetelluista ei löydy. Pääasiallinen kontakti tuntuu hyvin organisoituneelta ja pätevältä vs. kontakti(t) on vähän kaikkialla asiakkaan organisaatiossa. 7

8 Taulukko 3: Projektin laajuus/mutkikkuuden hallinta. Tämä on yhden hengen projekti vs. tarvitaan monia henkilöitä. Tarvitaan yhtä tai kahta henkilöä vs. tarvitaan kolme tai useampia. Tarvitaan vähemmän kuin viisi analysoijaa / suunnittelijaa vs. tarvitaan viisi tai enemmän. Projektiin tarvitaan korkeintaan kolme kuukautta vs. tarvitaan yli kolme kuukautta. mutkikkuudesta: Projekti on alle yhden henkilötyövuoden vs. on yli tuon. Projektille löytyy henkilöt ja taidot kokoaikaiseen työskentelyyn vs. henkilöt/taidot täytyy jakaa muiden projektien kesken. Projektissa tarvitaan vain muutamia periaatteita/käytäntöjä vs. tarvitaan monia periaatteita. Määrittelijät myös toteuttavat vs. toteuttajat erikseen. On mahdollista tehdä omalla porukalla vs. tarvitaan laajahkoa alihankintaa. 8

9 Taulukko 4: Asiakkaalle koituvien muutosten taso/laajuus. Hyödynnetään tietotekniikkaa asiakkaan nykyisille toiminnoille/systeemeille vs. toiminnot/systeemit ovat uusia asiakkalle. Päivitetään nykyistä systeemiä vs. korvataan nykyinen systeemi uudella ja hyvin erilaisella. Toiminnallisuus ei ole uutta asiakkaalle vs. on radikaalisti uutta. Toimintatavoissa ei isoja muutoksia vs. tulee isoja muutoksia. Systeemi ei muuta juurikaan asiakkaan organisaatiota vs. tarkoittaa laajoja muutoksia. Systeemi ei integroi eri toimistojen toiminnallisuuksia vs. integroi. Systeemi liittyy vain yhden osa-alueeseen vs. liittyy useaan toimintojen osa-alueisiin. Asiakas ei tarvitse isohkoja taitojen päivityksiä vs. tarvitsee. Taulukko 5: Kuinka asiakas ymmärtää ja tuntee vaatimukset? Ovat miettineet vaatimuksia vs. eivät ole miettineet. Toimitaan osaavien ihmisten kanssa, jotka tietävät mitä haluavat vs. eivät tiedä tarpeitansa. Hyvä ymmärrys ongelmista, jotka halutaan ratkaistavan vs. tarvitsee työskennellä heidän kanssaan löytääkseen heidän ongelmat. Asiakas tietää mitä haluaa ja se myös kuullostaa järkevältä vs. heitä tarvitsee kouluttaa, jotta voi näyttää, mitä he oikeasti haluavat. He tietävät mitä haluavat ja kuinka sen saavuttaa vs. he haluavat työntää koko projektin jonkun hoidettavaksi. Asiakas osaa määritellä ongelman IT-alan termein vs. meidään täytyy määritellä ongelma. Tarpeet tulevat nopeasti ja selvästi esille vs. täytyy hieman tehdä prototyyppejä. 9

10 Taulukko 6: Asiakkaan tai käyttäjien it-osaaminen ja kokemus. Käyttäjät tietokonetaitoisia vs. käyttäjillä ei tietokonetaitoja. Käyttäjät kokeneitä tietokoneen käyttäjiä vs. käyttäjillä vähän tai ei ollenkaan käyttökokemusta. Käyttäjät taidokkaita, jotka tietävät, mikä on mahdollista ja mahdotonta vs. eivät tiedä mahdollisen/mahdottoman rajaa. Asiakkaalla on realistiset näkemykset aikataulusta, kustannuksista ja tehtävissä olevasta vs. asiakkaalla epärealistisia näkemyksiä. Asiakkaalla on kokemusta IT-projekteista vs. on kokematon. Asiakas on koulutettu, tietää mitä kuuluu ITprojekteihin vs. asiakasta täytyy kouluttaa. Osalliset osaavat tarpeeksi hoitaakseen osuutensa projektista vs. osallisia täytyy kouluttaa, jotta pystyvät hoitamaan osuutensa. 10

11 Taulukko 7: Projektin pääasiallinen kontrolli. Asiakas jäsentelee (strukturoi) projektin vs. jäsentely tehdään itse. Asiakkaalla on kykenevä, joten kontrollin voi turvallisesti jakaa vs. asiakkaalla ei ole taitoja, joten kontrolli pidettävä itsellä. Itsellä on tarpeeksi kontrollia, jotta voi varmistua, että kaikki tulee tehtyä vs. olemme riippuvaisia asiakkaan halukkuudesta tehdä asioita. Voidaan vaikuttaa vaatimuksiin vs. vaatimukset ovat kiveen hakattuja. Jos tulee huono tunne, voin sanoa seis, kun ongelmasta puhutaan vs. ei pysty sanomaan seis. Voidaan saada joustoa aikatauluihin vs. työskennellään tiukassa asiakkaan määräämässä aikataulussa. Asiakas asettaa selkeitä tarkastuspisteitä ja toimituspäivämääriä vs. asiakas ei määritä työtahtia (lainkaan). Kontrollia ei tarvitse jakaa kolmannen osapuolen kanssa vs. tarvitsee jakaa. Ei tarvitse nojata kolmanteen osapuoleen kriittisten ei-standardien laittoistojen tai ohjelmistojen osalta vs. tarvitsee nojata. Ei olla riippuvaisia alihankkijoista vs. ollaan (raskaasti) riippuvaisia. 11

12 Taulukko 8: Innostus/tuki/energia projektia kohtaan. Projektille on aitoa tukea kaikilla tasoilla vs. joillain tasoilla on tukea mutta ei kaikilla. Henkilöt, joiden kanssa toimitaan, ovat mukana projektissa hankalissa ja helpoissa vaiheissa/tilanteissa vs. jos jokin menee pieleen, ollaan omillamme. Käyttäjät ovat sitoutuneet saamaan lopputulokset kohdalleen vs. ei löydy käyttäjää, jolla olisi vakiintunutta kiinnostusta aiheeseen. Asiakas on valmis sitoutumaan selkeästi projektiin vs. ei ole selkeästi sitoutunut. Asiakas on passiivinen ja jättää asiat meille työnnettäväksi vs. asiakas on aktiivinen ja vetää projektia haluamaansa suuntaan. Käyttäjät, joiden työhön systeemi eniten vaikuttaa, haluavat aidosti systeemiä vs. eivät näytä haluavan. Ei löydy syytä ajatella, että ihmiset ovat vihamielisiä projektia kohtaan vs. kohdekäyttäjät ovat vihamielisiä. Taulukko 9: Suunnittelijan sovelluskokemus. Sovelluksesta löytyy kokemusta vs. sovellus on uusi. Tarvittavat taidot löytyy suoraan vs. kaikkea osaamista ei löydy. Olemme tehneet samanlaista aiemmin vs. toimitetaan asioita, jotka uusia meille. 12

13 Taulukko 10: Erillisten kohderyhmien lukumäärä. Tarvitsee huomioida vain yksi ryhmä samankaltaisia käyttäjiä vs. useita ryhmiä erilaisin tarpein. Ei löydy sisäisiä eturistiriitoja sen suhteen, mitä tehdään ja mikä on tarpeen vs. löytyy vakavia eturistiriitoja. Projektilla on vain yksi eturyhmä vs. projektilla on useita keskenään eri linjoilla olevia eturyhmiä. Ei löydy piilo-ohjelmia vs. todellista tavoitetta ei kerrota. Taulukko 11: Suunnittelijoiden tuntemus käytettävästä ympäristöstä ja menetelmistä Ympäristä/kehitysväline on uusi vs. on tuttu. Kehitysmenetelmät ovat uusia vs. ovat tuttuja. Taulukko 12: Kenen kanssa pääasiassa toimitaan. Yksittäisen ihmisen kanssa vs. komitean tai ryhmän kanssa. Suoraan loppukäyttäjien kanssa vs. loppukäyttäjiin ei yhteyttä. Työskennellään jonkin asiakkaan organisaation kautta vs. projekti tehdään suoraan käyttäjille. Taulukko 13: Sovelluksen looginen mutkikkuus. Sovellus on suoraviivainen vs. mutkikas. Prosessointilogiikka/algoritmit helppoja vs. vaikeita. Systeemi on tarpeeksi pieni/yksinkertainen, jotta yksittäinen ihminen voi sen hallita vs. liian laaja tai vaikea yhdelle ihmiselle. 13

14 Taulukko 14: Uuden systeemin kriittisyys ja käyttöönoton peruutettavuus. Uutta systeemiä voidaan pilottikäyttää, kunnes se saadaan toimimaan halutulla tavalla vs. pitää onnistua ensimmäisellä kerralla. Jos oma systeemi ei toimi, he voivat palata käyttämään vanhaa systeemiä vs. palaaminen ei onnistu. Projekti toteutetaan vaiheissa vs. koko systeemin täytyy toimia yhtä aikaa heti käyttöönotettaessa. Taulukko 15: Suunnittelijoiden ymmärrys toimialasta. Haasteet pääasiassa teknisiä vs. haasteet liittyvät liiketoiminnan ymmärtämiseen. Tunnemme tämän liiketoimialan vs. emme tunne. Taulukko 16: Teknologian kypsyys Toteutus teknologialla, joka ei ole kovin uutta vs. teknologia uutta. Teknologia ei ole viimeisintä huutoa vs. tyhjänpäiväistä viimeisintä huutoa. Taulukko 17: Ratkaisujen pätevyysvahvistusten helppous. Asiakkaalle voidaan näyttää aikaisessa vaiheessa prototyyppi/paperinäytöt vs. ei voida. On mahdollista testata ja vahvistaa ratkaisu ennen kuin näytetään asiakkaalle vs. asiakkaalta tarvitaan paljon syötettä. Taulukko 18: Asiakkaan halukkuus/kykenevyys toteutuksen tekemiseen. Asiakkaalla on halua ja taitoa hallita toteuttamiseen liittyvät asiat. Täytyy itse järjestää toteutus. Asiakas on toteutusnäkökannalta pätevä (osaa hallinnoida verkkonsa, PCnsä jne.) vs. asiakas tarvitsee paljon teknistä avustusta ja opettamista. 14

15 Taulukko 19: Kehitysympäristön valinnan vapaus. Kehitysympäristö voidaan valita itse vs. kehitysympäristö annetaan. Tekninen arkkitehtuuri määritellään itse vs. on määritelty ennalta. Taulukko 20: Kehittäjän maa-/kulttuuri-/kielituntemus. Tunnetaan maa/kulttuuri vs. ei tunneta. Ei kieliongelmia vs. Eivät puhu hyvin meidän äidinkieltä. Taulukko 21: Asiakkaan liiketoimintaympäristön vakaus. Asiakkaan organisaatio on vakaa vs. siellä tapahtuu juuri paljon ja isoja muutoksia. Asiakkaan liiketoimintaympäristö on kohtuullisen vakaa. Muuttuu voimakkaasti par aikaa. 15

16 Taulukko 22: Muita huomioitavia asioita. Päätöksentekijät ovat myös käyttäjiä vs. eivät ole. Käyttäjillä on paljon annettavaa suunnitelmille vs. systeemi käyttäjilleen kuulematta heitä. Asiakas on valmis innovatiivisiin ratkaisuihin vs. ratkaisun täytyy olla turvallinen ja varovainen. Asiakkaan tavoitteena näyttää olevan mahdollisimman tarkka toimittajan hyödyntäminen (viimeistä piirtoa myöten) vs. asiakas näkee meidät partrerina ongelmanratkaisussa. Voidaan turvallisesti kokeilla uusia asioita ja oppia uusia taitoja vs. täytyy huolella pysytellä kokeillun ja testatun parissa. Asiakas tekee oman hyväksymistestauksen vs. asiakas jättää meille systeemin testaamisen ja päättämisen, milloin ok. Kyse eräajosysteemistä vs. reaaliaikasysteemistä. Päätavoitteena parantaa liiketoimintaprosesseja vs. hmm, jotain muuta. Systeemi on liiketoimintokriittinen vs. ei ole. Asiakkaalla on hyviä IT kokemuksia vs. menneisyydestä löytyy pettymys. Asiakkaan tilat ovat ok ja hyvällä alueella vs. tilat eivät ok ja slummissa Asiakas näyttää maksukykyiseltä vs. rahan saaminen voi olla vaikeaa. Asiakkaalla on tulevaan varautuva IT-osasto vs. asiakkaan IT-osasto on lähinnä jarru. Asiakas on yksittäinen henkilö tai hyvin pieni yritys vs. asiakas on isompi yritys. He ovat suoraviivaisia, asiallisia, jalat maassa -ihmisiä vs. heiltä löytyy paljon haihattelijoita. He ovat varovaista väkeä ja haluavat kaiken tarkistettavan vähintään kahdesti vs. sallivat tekemisen ilman turhia kaksoistarkastamisia. He vaativat kaiken olevan määritellyn pikkudetaljeja myöten vs. eivät kiusaa turhalla byrokratialla. 16

17 4.3 Yleiskuva riskien lieventämisestä, seurannasta ja hallinnasta Tänne voi napata luentokalvoista jotain tärkeimpiä tai omaan projektiin soveltuvimpia kohtia. 5 Projektin aikataulu Tässä luvussa annetaan yleiskuva projektin tehtävistä ja projektin aikataulutustyökalun (esim. taulukkolaskentaohjelman taulukko) tulostukset. 5.1 Projektin tehtäväjoukko Esitetään tuotantomalli, kehystehtävät ja tehtäväjoukko, joka projektille on valittu. Ks. kalvot. Osa esimerkin kohdista saattaisi sopia paremmin johonkin toiseen alilukuun tässä luvussa... Lyhyesti: syksyllä määritellään ja keväällä toteutetaan. Syksyn aikana: projekti käynnistetään, sopimusten allekirjoitukset, projektisuunnitelman tekoa, vaatimusten keruuta, alustavia teknisiä suunnitelmia. Lisäksi mukana on vähintään kaksi katselmointia: projektisuunnitelma ja vaatimusmäärittelyt. Syksyn lopuksi esitetään omat suunnitelmat ja vastataan tarjouspyyntöön toteutuksesta. Keväällä: toteutuksen suunnittelua ja toteutusta, testaus, työn esittely ja luovutus, ja projektin päättöpalaveri. Lisäksi mukana vähintään kaksi katselmointia. Projektiryhmä tapaa viikoittain ja tiedottaa etenemisestään viikkoraportein Isto Aholle. Lisäksi projektiryhmä tekee kunkin kuukauden ensimmäisen viikon aikana etenemisraportin asiakkaalle. (Nämä asiat tulee löytyä jo aliluvusta 2.4.) Projektin aloitus: tutustuminen, sopimusten allekirjoitukset. Osaamisen kartoitusta. Osaamistarpeiden kartoitusta (sen mukaan, mitä projekti luultavasti tarvinnee). Projektisuunnitelman kirjoittamiseen liittyvät toimet ja tehtävät: Projektin tavoitteen selvennys ja kirjaaminen eli tärkeimmät toiminnot ja rajoitukset. Projektin arvioiden tekeminen, riskien tunnistaminen, analysointi ja tärkeimpien valinta seurantaan, projektin aikataulun muodostaminen, osallistujien ja ryhmän rakenteet ja kommunikointi, ja lopuksi seuranta- ja kontrollointimekanismien suunnittelu, kirjaaminen ja käyttöönotto. Vaatimusmäärittelyn kirjoittamiseen liittyvät toimet ja tehtävät: tavoitteet, ympäristö ja tärkeimmät rajoitteet johdantoon, käyttöskenaarioiden muodostus (käyttäjäprofiilit 17

18 ja käyttötavat), tietomalli, toiminnallinen kuvaus, käyttäytymismalli, rajoitteet ja hyväksymiskriteerit. Toteutussuunnitelman kirjoittamiseen liittyvät toimet ja tehtävät: johdanto, datasuunnitelma, arkkitehtuuri- ja komponenttitason suunnitelma, käyttöliittymäsuunnitelma, rajoitteet ja testauksesta. Testaussuunnitelman kirjoittamiseen liittyvät toimet ja tehtävät: johdannon asiat, testaussuunnitelma (moduli-, integrointi-, hyväksymis-, järjestelmätestit ym.), testausmenettely (suunnitelman eri testityypeille), testausresurssit, testityötuotokset ja testiloki. Toteuttamiseen liittyvät toimet ja tehtävät: tähän löytyy sopivia kokonaisuuksia sitä mukaan kuin vaatimukset valmistuvat. Testaamiseen liittyvät toimet ja tehtävät: tähän löytyy sopivia kokonaisuuksia sitä mukaan kuin vaatimukset valmistuvat. Projektin läpivientiin liittyvät säännölliset toimet ja tehtävät: viikoittaiset seurantapalaverit ja niiden raportit, kuukaisittaiset asiakkaalle lähetettävät edistymisraportit, säännölliset suunnittelukokoukset. Katselmointitilaisuudet: valmistelu, lukeminen, tapaaminen ja toimenpiteet. Riskitilanteen päivitys kunkin katselmoinnin aikoihin. Projektin läpivientiin liittyvät muut toimet ja tehtävät. Suunnitelmien esittelytilaisuus: esitelmän valmistelu ja itse esitelmä. Projektin esittelytilaisuus: esitelmän valmistelu (projektista ja tuotteesta), itse esitelmä. Henkilökohtaiset tehtävät (arviointiraportteja). 5.2 Toiminnallinen ositus Toiminnallisuus pilkotaan aikataulutusta varten tänne. Mukana voi olla toiminnallisuuden priorisointia. Tämä tarkentuu, kun tärkeimmät vaatimukset saadaan selville. Seuraavissa listoissa moni kohta tulee käsitellä tarkemmin. Ks. myös wbs-kalvot. 5.3 Tehtäväverkko Projektin tehtävät ja niiden riippuvuudet kirjataan piirrettävään kaavioon (esim. kaveri-ohjelman prosessikaavio tai tietovirtakaavio). Tämä tarkentuu, kun tärkeimmät vaatimukset saadaan selville. Kaavio perustuu edellisen aliluvun toiminnalliseen ositukseen. 5.4 Aikataulukuvaaja Esitetään projektin aikataulukuvaaja. Tämä ehkä sisältää aikajanan koko projektille tai kullekin osallistujalle. Tämä tarkentuu, kun tärkeimmät vaatimukset saadaan 18

19 selville. Muutenkin aikataulu elää läpi projektin tarkentuen loppua kohden. 6 Seuranta- ja kontrollointimekanismit Yksilöidään projektin seurannassa ja kontrolloinnissa käytettävät tekniikat. 6.1 Laadunvarmistus ja kontrollointi Esitetään yleiskuva ohjelmiston laadunvarmistuksesta. Laadunvarmistuksesta löytyy oma dokumenttinsa kurssin www-sivuilta. Luentokalvoilla on enemmän asiaa katselmoinneista ja niiden järjestämisestä. Kuvataan lyhyesti projektin raportointi- ja tarkastusmekanismit (katselmukset), ja niihin liittyvät päivämäärät. Mainitaan, kuka on minkäkin katselmoinnin puheenjohtaja. Lisäksi määrätään kunkin katselmoinnin muut roolit ja kuhunkin rooliin liittyvät vastuut. 6.2 Muutosten hallinta ja kontrollointi Esitetään yleiskuva muutosten hallista. Liittyy projektin aikana tuleviin muutostarpeisiin. Lisäksi kuvaus tuotteenhallinnasta. 7 Liitteet Tarvittava lisätieto laitetaan tänne. 19