Määritelmä kehitysprosessim alleille

Ohjelmistojen kehitysprosessimallien tarkoituksena on määritellä tietojärjestel­

mien suunnitteluun ja kehitykseen liittyvien vaiheiden järjestys sekä luoda kritee­

rit siirtymiselle vaiheesta toiseen. Nämä sisältävät kriteerit nykyisen vaiheen val­

miusasteen määritykseen ja seuraavan vaiheen valintakriteerit ja edellytyksen sen toteuttamiseksi. Siten prosessimallit vastaavat kysymyksiin, mitä teemme seuraa- vaksi ja miten kauan teemme sitä. Kehitysprosessimallit eroavat ohjelmistometo- dologioista siinä, että ohjelmistometodologiat keskittyvät pääasiassa vaiheen suo­

rittamiseen (datan määrittely, kontrollirakenteet, vaatimusten allokointi) ja siihen miten havainnollistaa vaiheen tuotetta (vuokaaviot, syöttö/vaste-määrittely).

(Boehm, 1989.)

2.2 Kehittämisprosessimallit tieto järjestelmäkehityksessä

Kehitämisprosessimalli kuvaa mitä tietojärjestelmän kehittämiseksi pitäisi tehdä luettelemalla, luokittelemalla, määrittelemällä ja järjestämällä tietojärjestelmän kehittämiseen liittyvät tehtävät (Lyytinen, 1987). Tietojärjestelmä syntyy kehittä­

misprosessin tuloksena ja prosessimalli muodostaa siis rungon tietojärjestelmä- projektin vaiheista. Prosessimalleista puhtaaseen tietojärjestelmäprojektiin liitty­

vät läheisimmin tekniset mallit, kuten elinkaarimalli, prototyyppimalli ja PSC/

PlOCOmalli.

2.2.1 Elinkaarimalli

Perinteisesti tietojärjestelmien kehittäminen on perustunut elinkaarimalliin. Tieto­

järjestelmän kehittäminen koostuu tehtävistä, joille on määritelty suoritusjärjestys ja joiden tarkoituksena on ohjelmiston rakentaminen ja järjestelmän kehittäminen.

Elinkaarimallin mukaiselle järjestelmän kehittämiselle on lisäksi tunnusomaista rakennettavan järjestelmän suunnittelu siihen liittyvien toimintojen mukaisesti ja rakennettavan järjestelmän tarkentava kuvaaminen (Pressman, 1987). Elinkaari- malli on esitetty kuvassa 3.

esisuunnittelu

käyttöönotto yksityiskohtai­

nen suunnittelu

koodaus vaatimusten

määrittely järjestelmän analyysi

Kuva 3. Atk-kehitysprojektien elinkaarimalli. (Boehm, 1981.)

Elinkaarimallissa tietojärjestelmän kehittämiseen sovelletaan toimintopohjaista strategiaa. Tietojärjestelmä suunnitellaan jakamalla se toiminnallisiin osiin, jotka sitten yhdistetään lopulliseksi järjestelmäksi kuvan 3 mukaisesti. Tietojärjestelmän jakaminen tapahtuu peräkkäisiä iteroivia tasoja hyväksikäyttäen. Kehittämispro­

sessin aikana ongelman kuvaus muunnetaan ratkaisuehdotuksen kuvaukseksi.

Perinteisen elinkaarimallin vahvoja puolia ovat siihen liittyvä usko ennustetta­

vuuteen, kohdealueen muuttumattomuuteen, kehittämisprosessin hallittavuu­

teen ja kehittäjien rationaaliseen ongelmanratkaisukykyyn. Todellisuudessa pro­

jektit harvoin noudattavat järjestystä, jota malli ehdottaa. Iterointia tapahtuu aina ja se luo uusia ongelmia sovellusrakentamisessa. Toisena ongelmana on vaikeus määritellä järjestelmälle asetettavat vaatimukset tarkasti ennen kehitystyön aloit­

tamista. Kolmannen ongelman muodostaa itse asiakas. Asiakkaalta vaaditaan kärsivällisyyttä, sillä järjestelmää pystyy käyttämään vasta aivan projektin loppu­

vaiheessa. (Pressman, 1987.)

2.2.2 PSC-PIOCO-malli

PlOCO-malli on elinkaarimallin laajennus. PlOCO-malliin sisältyy kolme tietojär­

jestelmän kehittämiseen liittyvää mallia: metamalli ja sitä vastaava kuvauskieli, etenemistä kuvaava kehittämisprosessiin alli sekä malli, joka kuvaa kehittämisessä käytettävät päätöksenteko- ja laatukriteerit. Tietojärjestelmän metamalliin kuuluu kolme hierarkkista tasoa. Ne ovat järjestelmän vaikutus ja merkitys ympäristös­

sään sekä järjestelmän looginen ja tekninen rakenne. Keskeinen laajennus elinkaa­

rimallin PlOCO-mallissa on uuden tietojärjestelmän tarkastelu jokaisesta tarkas­

telukulmasta jokaisessa järjestelmän kehitysvaiheessa. (Iivari et ai., 1987.)

Hiearkkisten tasojen lisäksi PlOCO-malliin liittyy neljä muuta erityispiirrettä:

päätöksenteko-orientoituneisuus, jossa nähdään kehittäminen selvitysprosessik- si, minkä vuoksi kehitysprosessin pitää tukea kehitettävään tietojärjestelmään liittyvien päätösten tekemistä. Toinen taustaolettamus on, ettei ole olemassa yhtä ainoaa, joka tilanteeseen sopivaa kehittämismallia, minkä vuoksi PlOCO-mallissa on pyritty antamaan mahdollisuus käyttää kuhunkin kehittämistilanteeseen par­

haiten soveltuvia menetelmiä. Lisäksi PlOCO-mallissa elinkaarimalliin on lisätty iteraatio ja rekursio, jotka mahdollistavat kehittämisen aikaisen oppimisen hyö­

dyntämisen. Neljänneksi PlOCO-malliin liityy perusta kehittämisaikaiselle pää­

töksenteolle ja laadunvarmistukselle. (Iivari et ai.,1987.)

PlOCO-malli on kuitenkin elinkaarimallin kaltainen siinä, että kehittämisproses­

siin katsotaan liittyvän rationaaliset päätöksentekokriteerit. Lisäksi PlOCO-malli on abstrakti ja monimutkainen, minkä takia sitä on vaikea soveltaa.

2.2.3 Prototyyppimalli

Prototyyppimallissa pyritään paikkaamaan elinkaarimallin puutteita määrittele­

mällä järjestelmän vaatimukset ja toiminnot vasta niiden toteuttamisen yhteydes­

sä. Käytännössä tämä tarkoittaa sitä, että kehittämisprosessin alkuvaiheessa kehit­

tämisryhmä kokeilee erilaisia ratkaisuvaihtoehtoja ja täsmentää järjestelmälle asetettuja vaatimuksia ja määrittelee järjestelmään sisältyvät toiminnot tarkem­

min. Vaatimusten määrittämisen salliminen kehittämisen myöhemmissäkin vai­

heissa mahdollistaa kehittämiseen liittyvän oppimisen hyödyntämisen.

Prototyyppimallin mukainen kehittämisprosessimalli sisältää useita toistuvia sen kuvausprosessin asemasta. Ideaalisesti prototyypitys palvelee mekanismina ohjelmistolle asetettavien vaatimusten identifioimiseksi (Pressman, 1987). Kuvas­

sa 4 on esitetty prototyypitys-malli ja sen vaiheet. Prototyypitys vaatii teknisesti kehittyneen ympäristön, jossa kehitys tapahtuu.

vaatimusten

määrittely

II

nopea

suunnittelu

1

prototyypin

rakentaminenvaatimusten

n

arviointi ja tarkennus

F

järjestelmä

a

valmiiksi

Kuva 4. Prototyyppimalli. (Pressman, 1987.)

Prototyypitys alkaa kuvan 4 mukaisesti vaatimusten määrittelyllä. Kehittäjä ja asiakas määrittelevät kaikki yleiset tavoitteet ohjelmistolle, identifioivat tunnetut vaatimukset ja spesifioivat alueet, jotka tarvitsevat lisämäärittelyjä. Määrittelyjen jälkeen suoritetaan "nopea suunnittelu". Suunnittelu kohdistuu ohjelmiston käyttäjälle näkyviin osiin (käyttöliittymät, tulosteet jne.). Suunnittelun tuloksena

muksia järjestelmälle. Prototyyppi "viilataan" iteraatioprosesin tuloksena vastaa­

maan käyttäjän tarpeita. Järjestelmä loppuvaiheet taphtuvat kuvan kahden vii­

meisen vaiheen silmukkaarakentessa vaatimus te arvioinnin ja tarkennuksen ja jär­

jestelmän rakentamisen välillä.

Mallin hyödyntämisen kannalta ei ole eduksi, että tuleva käyttäjä tai asiakas näkee järjestelmän edistymisen ja luulee järjestelmän jo olevan valmis, vaikka se on vasta

"harsittu" kasaan eikä sen laatua eikä ylläpidettävyyttä ole ollenkaan ehditty miettiä. Toinen ongelma muodostuu kehittäjän tehdessä useita kompromisseja implementoidessaan mahdollisimman nopeasti prototyyppiä. Myöhemmin ke­

hittäjä tottuu näihin kompromisseihin ja unohtaa syyt, miksi ratkaisut eivät olleet parhaimpia mahdollisia. (Pressman, 1987.)

2.3 Tekniikat ja menetelmät

Prototyypityksen, kuten muidenkin kehitysprosessimallien, mukaisen etenemis­

tavan mahdollistavia tekniikoita ja menetelmiä ovat mm. ohjelmistojen kehittämi­

nen käyttäen neljännen sukupolven kieliä (4 GL) tai CASE-välineitä (Computer Aided System Engineering).

Neljännen sukupolven tekniikat (4 GT) antavat ohjelmistosuunnittelijan määritel­

lä joitakin järjestelmän ominaisuuksista korkealla tasolla. Työkalu automaattisesti generoi lähdekoodin suunittelijan määrityksistä. Neljännen sukupolven tekniikan hyväksikäyttö alkaa vaatimusten määrittelyllä. Pienissä sovelluksissa on mahdol­

lista käyttää sen jälkeen suoraan 4 GL-työkalua, mutta suuria järjestelmiä raken­

nettaessa on välttämätöntä laatia järjestelmän suunnittelustrategia. 4 GT:n hyväks­

ikäyttö ilman strategiaa aiheuttaa samat ongelmat kuin perinteisten mallien käyttäminen järjestelmää rakennettaessa (huono laatu, ylläpidettävyys ja asiak­

kaan hyväksyntä). Kuvassa 5 on yleisellä tasolla havainnollistettu 4 GT:n mahdol­

listamaa sovelluskehitystä. Työn esimerkkitapauksena käsiteltävä KOP:n projek- tinohjausjärjes telmä on toteutettu pääosin neljännen sukupolven kieltä ja sovellus- kehitintä (Artemis) hyväksikäyttäen.

4GT:n puolestapuhujat väittävät ohjelmistojen kehitysaikojen pudonneen dra­

maattisesti ja kehittäjien tuottavuuden kasvaneen huomattavasti. Vastustajat taas väittävät, ettei 4 GT-työkalut ole ohjelmointikieliä helppokäyttöisempiä ja että sellaisten työkalujen tuottama lähdekoodi on tehotonta, lisäksi 4 GT:llä tehtyjen järjestelmien ylläpito olisi hankalaa.

vaatimusten

määrittely suunnittelu-

a

strategia

T 1

toteutus käyt­

täen 4GL:ä!|ll

n

Tuote

Kuva 5. Järjestelmän kehitys neljännen sukupolven tekniikoilla. (Pressman, 1987.) Tavallisimmin CASE:lla tarkoitetaan atk-teknistä suunnittelua, joka toteutetaan CASE-ohjelmistolia. CASE-välineet mahdollistavat kaikkien sovelluskehityksen vaiheiden toteutuksen yrityksen toiminto- ja tietomallien laadinnasta, analysoin­

tiin, tekniseen suunnitteluun, koodinkehitykseen ja käyttöönottoon. CASE-väli- neillä toteutetun tietojärjes telmäkehityksen vaiheet ovat kuvan 6 mukaiset.Joihinkin CASE-välineisiin on liitetty projektin hallintaa tukevia piirteitä ja on myös olemas­

sa projektinohjausohjelmistoja, jotka voi integroida CASE-välineisiin. Edellä ker­

rotuista ratkaisuista käytetään nimeä Integrated Project Support Environment (IPSE).

vaatimusten

määrittely kuvaus muodol­

Q

liselle kielelleautomaattinen

1

m

erointi

testaus ja muuntelu

optimointi

n П

_valmis

ohjelma

Joissakin yhteyksissä suunnittelua tukevia CASE-välineitä kutsutaan upper- CASE:ksi ja toteutuksen vastaavia lower-CASE-välineiksi. Kuvan 6 malli käsittää siten sekä upper- että lower-CASE:n.

CASE-välineiden hyväksikäytöllä saavutetaan mm. seuraavia etuja: sovellusten helpompi ylläpidettävyys, loppukäyttäjien tarpeiden parempi ymmärtäminen ja tuottavuuden ja laadun paraneminen. CASE:n laajemman hyväksikäytön esteitä ovat työkalujen heikko tämänhetkinen integrointi ja yritysten menetelmätunte- muksen puute. (Jones, 1990.)

2.4 Esimerkki mallien ja tekniikoiden yhdistämisestä

Yhdistämällä edellä kerrotuja malleja päästään melko lähelle "täydellistä" mallia.

Tässä esitelty malli on paljolti käytössä yrityskohtaisia tietojenkäsittelyprojekteja läpivietäessä. Koottu malli alkaa, kuten kaikki muutkin, vaatimusten määrittelyl­

lä. Määrittelyjen jälkeen astuu kuvaan prototyypitysvaihe, jossa neljännen suku­

polven kieltä hyväksikäyttäen luodaan prototyyppi (silmukka prototyypin ja 4 GL:n välillä). Kun prototyyppi on valmis ja sen vaatimuksia on tarkennettu ja rakennetta arvioitu, käytetään perinteistä elinkaarimallia lopullisen tuotteen ai­

kaansaamiseksi. (Pressman, 1987)

2.5 Mikä malli minnekin ?

Yleisesti voidaan todeta, että kehittämisprosessimallit soveltuvat eri tavoin erilai­

siin kehitämisympäristöihin ja -tilanteisiin. Elinkaarimalli soveltuu tilanteisiin, jossa ongelmat ovat teknisiä. Prototyyppimallia voidaan hyödyntää tilanteissa, joissa järjestelmän kehittäjät eivät ole varmoja, mitä toimintoja rakennettavan järjestelmän pitäisi sisältää. Lisäksi prototyyppimallin soveltamisen perusedelly­

tys on välineistön mahdollistama muutosten tekemisen nopeus ja helppous. Pro- totyypityksen apuna kokonaisuuden hallinnassa ovat esimerkiksi tietohakemis­

tot. Yleisimmin käytetään kuitenkin yhdistelmää useista eri malleista yrityskohtai­

sesti sovitettuina. Käytettyinä tekniikkoina ovat useissa kehitettävissä järjestel­

missä CASE-välineet ja neljännen sukupolven kielet ajaneet perinteisten ohjel­

mointikielten ohitse. Käytetyt mallit ja kehitysvälineet vaikuttavat kehitysprojek­

tin projektinohjaukseen erityyppisten ja -nimisten vaiheiden kautta: varsinaiset ohjausmenetelmät eivät paljoakaan eroa toisistaan. Poikkeuksen muodostavat (tulevat muodostamaan) CASE-välineiden edellä kerrotut IPSE-ympäristöt, jotka tulevaisuudessa tarjoavat erinomaiset puitteet suunnittelutyön kuin myös projek­

tin edistymän mittaamiseen. Tässä työssä keskitytään kuitenkin pääosin muihin malleihin ja tekniikoihin kuin CASE:n tarjoamiin mahdollisuuksiin.

3. ATK-KEHITYSPROJEKTIN SUUNNITTELU

Projektin suunnittelu muodostaa projektin hallinnan tärkeimmän vaiheen, vaikka sekä projektin suunnittelua että seurantaa tarvitaan lopputulosten saavuttamisek­

si. Suunnittelulla ja sen laadulla voidaan helpoiten ja parhaiten vaikuttaa projek­

tin lopullisiin kustannuksiin ja budjetissa pysymiseen. Suunnitelman pohjalta projektin etenemistä voidaan tehokkaasti valvoa. Tarvittaessa projekti on suunni­

teltava uudelleen toteutuksen aikana. Projektin suunnittelun on oltava realistista.

Tämä edellyttää projektin tavoitteiden ja tehtävien yksiselitteistä määrittelyä ja ai­

kataulu-ja laatutavoitteiden perustumista todelliseen resurssitilanteeseen. Lisäksi pitää käyttää mahdollisimman paljon historiatietoja aikaisemmista samantyyppi­

sistä projekteista. Karkeasti projektin suunnittelu voidaan jakaa kehitysvaiheiksi lähtötietojen keräämisestä projektin sisällön suunnitteluun (mitä?), projektin to­

teutuksen suunnitteluun (miten?) ja suunnittelun lopputulokseen, projektisuun­

nitelmaan.

Projektin suunnittelun ohjeistamiseen on olemassa useita malleja. Kertzner (1984) ehdottaa yhdeksänvaiheista mallia, jolloin kehitetään :

1. Tavoite, johon pyritään ja sen ositus

2. Ohjelma, jossa määritellään strategia ja toimenpiteet tavoitteiden saavut­

tamiseksi 3. Aikataulu 4. Budjetti 5. Ennusteet

6. Projektiorganisaation määrittäminen

7. Politiikka päätöksentekoon ja toimenpiteisiin

8. Yksityiskohtainen menetelmä politiikan toteuttamiseen 9. Standardi suoritusten arvioimiseksi.

Thayer jakaa suunnitteluvaiheen edellisestä hieman poiketen neljään osaan:

"ohjelman" suunnitteluun, tulevaisuuden tilanteiden ennustamiseen, budjetin valmisteluun ja varsinaiseen projektisuunnitelman laatimiseen. Ohjelma sisältää tehtävien suunnittelun, kustannus- ja resurssisuunnittelun ja aikataulutuksen, joka ottaa huomioon priorisoinnit, tavoitepäivät jne. Muut osatekijät ovat sisällöl­

tään samanlaisia (Thayer, 1988). Tässä työssä keskitytään atk-kehitysprojektien kannalta suunnittelun kaikkein tärkeimpiin osatekijöihin: projektin vaiheistuk­

seen ja ositukseen sekä projektin työmäärien ja riskien arviointiin.

Suunnittelun onnistumisen kriteerinä voidaan pitää vastausten löytämistä suur­

ten atk-kehitysprojektien seuraavassa esiteltävään ongelmakenttään.

Suurten projektien vaikeuksia (Roukala, 1986):

1. Suunnittelu on vaikeampaa kuin pienissä projekteissa. Tehtäviä ja niiden välisiä riippuvuuksia on paljon.

2. Projektin hallinta vie huomattavasti enemmän aikaa.

3. Projektijäsenten välinen yhteydenpito lisääntyy.

4. Henkilöt vaihtuvat. Tietty vaihtuvuus on luonnollista, mutta myös turhau­

tuminen ja motivaation puute voi saada henkilöitä hakeutumaan muihin tehtäviin.

5. Työteho ja tuottavuus laskevat.

6. Kuva toimintojen sisällöstä muuttuu työnteon aikana - tehdään päällek­

käistä työtä.

3.1 Projektin suunnittelu: mallista järjestelmäksi

Projektin suunnittelu on tulosorientoitunutta: se alkaa järjestelmän esittämisellä tuoterakenteena projektin osituksen avulla. Atk-kehitysprojekteissa projektin osituksen sijasta puhutaan useammin tuloksen osituksesta. Wolf (1989) yhdistää suunnittelumallissaan sekä tuloksen että projektin osituksen kuvan 7 mukaisesti.

Ositusten ominaispiirteitä ja eroja on selostettu luvussa 3.2. Tuloksen osituksessa kohdennetaan lopullinen tuote, mitä ja miten se tehdään ja mitä välivaiheita tarvitaan lopulliseen tuotteeseen pääsemiseksi. Ositusta seuraa projektin vaiheis­

tus: tuloksen osituksesta saadut työvaiheet vaiheistetaan aikataulun ja logiikan mukaisella tavalla. Osituksen lopputulosten, työpakettien, arvioinnin (kustannus- ja resurssi) jälkeen voidaan suunnitella projektiin tarvittavia resursseja ja päivä­

määriä. Ottamalla huomioon rajoittavat reunaehdot muutetaan edellä kerrotut suunnitteluvaiheetideaalimallista todelliseksi ja realistiseksi suunnitelmaksi. Tässä kuvattu suunnittelurakenne on kuvassa 7 ja sen osatekijöitä on tarkemmin analy­

soitu luvuissa 3.2-3.5.

Työpaketti on pienin yksikkö projektisuunnitelmassa ja se muodostaa kustannus- arvioinnin perustan. Työpaketit ovat erillisiä osatehtäviä tai työkokonaisuuksia, joilla kullakin on havaittava alku ja loppu sekä jonkinlainen lopputulos. Työpaket­

ti on riittävän suuri esimerkiksi ennusteiden tekoa varten ja toisaalta riittävän pieni poikkeamien havaitsemiseksi. Työpaketti pitäisi kiinnittää yhteen henkilöön eikä sen tulisi olla kuutta henkilötyöviikkoa suurempi. (Wolf, 1989.)

Suunnitteluasiantuntijat ja tietty määrä projektiin osallistujia määräävät jokaiselle työpaketille tulokset, välttämättömän työntekijämäärän ja kustannukset tiettyjen lähtöoletusten perusteella. Tämä suunnitelma on perusta kaikille myöhemmille suunnittelutoimilla. (Wolf, 1989.)

Projektin suunnittelu

Tuloksen ositus Vaiheistus

Projektin ositus

paketit

Asiantunti] aryhmä -kokoukset

-palaverit

T o im in ta verkko

Kuva 7. Atk-projektin suunnittelurakenne. (Wolf, 1989.)

Projektisuunnittelun päättyessä on olemassa määrittelyt työpaketeista ja niiden tuloksista, työpakettia tekevien ihmisten määrästä, kustannuksista ja päivämää­

ristä. Projektin ohjaus perustuu yhden vaiheen sisällä pääosin edellä kerrottuihin parametreihin. Useiden vaiheiden välillä tarkkailu ja ohjaustoimet kohdistuvat päätapahtumaan (milestone). (Wolf, 1989.)

3.2 Projektin ositus

Mitä suuremmasta ja monimutkaisemmasta projektista on kyse sitä vaikeampi on hallita kokonaisuutta. Kokonaisuuden hallinta on helpompaa, jos kokonaisuutta voidaan hallita osakokonaisuuksien avulla ja osakokonaisuuksien hallinta on helpompaa, jos ne jaetaan edelleen omiin osakokonaisuuksiinsa.

Projektin osituksella (WBS, Work Breakdown Structure) tarkoitetaan projektin ja­

kamista eri hierarkiatasoisiin suunnitelmiin, jossa ylempi hierarkiataso pilkotaan loogisesti ja systemaattisesti pienempiin osiin, jolloin myös näiden osien sisältö tulee yksityiskohtaisemmin määritellyksi. Ositetun projektin osia kutsutaan osa­

projekteiksi (laajat projektit). Systeemityön alkuvaiheessa usein muodostetaan projektin vaiheet osaprojektijaon "yli".

Tarkasteltaessa projektin ositusta käytännönläheisemmältä kannalta voidaan sitä pitää kaikkien niiden tehtävien luettelona, joka määrittelee suoritettavat tehtävät lyhyisiin, hallittaviin kokonaisuuksiin, joilla on määritellyt syötteet ja vasteet, aikataulut ja vastuuhenkilöt. WBS-rakennetta voidaan käyttää projektin aika- ja resurssi tavoitteiden kohdentamiseksi tehtävätasolle, ja myöhemmin se luo perus­

tan edistymäraportoinnille vertailukohtana selkeät ja tarkoituksenmukaiset pää­

tapahtumat. WBS:ään perustuva atk-kehitysprojekti sisältää tarvittavat työkalut kustannusten ja aikataulujen arvioimiseksi tarkasti sekä mahdollistaa hallittavuu­

den ja ohjattavuuden kehitystyön aikana. (Tausworthe, 1988.)

Osituksessa tulee noudattaa seuraavia perusperiaatteita (Kerzner et ai., 1984):

-Projektin ositus ja kunkin syntyvän elementin kuvaus tulee olla helppo ym­

märtää.

-Kaikki aikataulutukset perustuvat projektin osituksessa määritettyihin kokonaisuuksiin.

-Tehtäviä ei pitäisi yrittää epätoivoisesti jakaa aina alimmalle tasolle asti, vaan jakaa työ vain niin monelle tasolle, kuin työn toteuttamisen ja seuran­

nan kannalta on tarkoituksenmukaista.

-Työkokonaisuuksien rajat saattavat muuttua projektin kestäessä, joten työ­

kokonaisuudet pitäisi määritellä siten, että joustavuus säilyy projektin osituksessa.

Onnistunut projektin ositus helpottaa projektin läpiviemistä, kun taas epäonnistu­

nut ositus vaikeuttaa mm. vastuualueiden määritystä sekä projektin aika- ja kustannusseurantaa.

Tuloksen ositus

Yleisesti projektinosituksella tarkoitetaan juuri työn organisointia eli miten tehtä­

vä työ pilkotaan hallittaviin kokonaisuuksiin. Edellä kerrottua projektin ositusta voidaan käyttää myös tietojenkäsittelyn kehitysprojekteissa, mutta havainnolli­

sempaa ja selkeämpää on puhua tuloksen osituksesta. Tuloksen osituksella pyri­

tään selvittämään, mitä pitää saada missäkin vaiheessa aikaiseksi. Atk-projektin tuloksen ositus voidaan jakaa kolmella eri tavalla (Pere, 1988):

-lopputulos teknisesti eri osiin

-vaikutuksensa (kohdealueen) mukaisesti eri osiin -valmistumisasteen perusteella

Tuloksen osituksesta vaikutuksensa mukaisesti on mahdollista tehdä esimerkiksi seuraavalla tavalla

A211 Graafiset raportit

A

A3 Vaiheiden hallinta vaiheet

A4 Työaikakirjanpito tehtävät

Tuloksen jakaminen teknisesti erilliseen osiin muodostaa perustan projektin rajaa­

miselle. Teknisiä kokonaisuuksia ovat hajautetut ja keskitetyt sovellukset, tietova­

rastot ja tietoliikenne näiden kokonaisuuksien välillä. Sovelluksiin liittyy oleellise­

na osana varsinaiset laitteistot, niiden käyttöliittymät ja sovellusten mahdolliset liittymät muihin sovelluksiin (integrointiaste). Tietovarastoja mietittäessä pitäisi ottaa huomioon niiden yhteiskäyttöisyys ja ominaisuudet myös muiden kuin suunniteltavan järjestelmän osalta. Tuloksen tekninen ositus helpottuu projektin edetessä ja sitä on tarkennettava vaihesuunnittelun yhteydessä. (Pere, 1988.) Kohdealueen ja vaikutusten huomioon ottaminen tuloksen jakamisessa käsittää järjestelmään tulevien toimintojen määrittelyn, niiden ajankohtaisuuden spesifio­

innin ja mahdollisen työn jakamisen. Kuten edellä, ositus helpottuu työn edetessä ja sitä on tarkennettava projektin vaiheita suunniteltaessa. Mahdollisuuksien mukaan kohdealuetta tulee rajata selkeäksi ja yksiselitteiseksi kokonaisuudeksi.

(Pere, 1988.)

Valmistusasteen perusteella tapahtuva tuloksen ositus määrittelee, mitä missäkin vaiheessa on oltava valmiina, jotta projekti voi edetä johdonmukaisesti kohti asetettuja tavoitteita. Valmiusaste voi käsittää myös eräänlaisena tavoitetasona.

Määrittelemällä tietty tavoitetaso (valmiusaste) aina projektin lopputulokseksi voidaan projektissa selvemmin keskittyä kohtuullisen lyhyen aikajänteen tulosten saavuttamiseen. Mitä lähemmäs toteutusta tullaan sitä tarkemmin on pyrittävä pysymään tavoitetason puitteissa. Yhteneväinen käytäntö on hyödyllinen (systee­

mi työmalli), koska silloin kokemus kehittyy parhaiten ja tehtäviä on helpoin jakaa.

Osittaminen voidaan tehdä useilla eri lähestymistavoilla. Top-down-tavoiteorien- toituneesti voidaan jakaa tavoite pienempiin osa- ja alitavoitteisiin. Bottom-up- ongelmaorientoituvaa lähestymistapaa käyttäen saadaan selville ongelmien vai- kutuskenttä (ongelma y vaikuttaa tehtävään xx ja ongelmaan y vaikuttaa taas ongelmat yx ja yz). Modulaarinen lähestymistapa on eräs suositumpia: lopputu­

loksesta ositetaan selkeät, yksittäiset kokonaisuudet ja vasta myöhemmin keskity­

tään paloiteltujen kokonaisuuksien integrointiin. (Pere, 1988.)

3.3 Projektin vaiheistus

Vaiheistuksessa esitetään etenemistapa projektin lopputuloksen aikaansaamisek­

si jakamalla projektin suoritus vaiheisiin. Vaiheistus perustuu osaksi luvussa kaksi esitettyihin kehitysprosessimalleihin ja toisaalta suoraan projektin tuloksen osiin.

Käytetyt atk-kehitysvälineet, -menetelmät ja yrityskulttuuri vaikuttavat mallien yrityskohtais tamiseen. Käytännössä projekti vaiheistetaan tarpeen mukaan eli kehittämistilanteen ja projektin tehtävien mukaan. Vaiheistuksen avulla pyritään yhtenäistämään yrityksen ohjelmistotuotannon ja -projektien johtaminen jaka­

malla ohjelmistokehitystyö hallittaviin suunnittelukierroksiin ja auttaa siten pro­

jektien suunnittelussa, seurannassa ja johtamisessa. Vaiheistuksen ja tuloksen osituksen liittymisestä toisiinsa on yksinkertaistettu esimerkki kuvassa 8.

Projektin alkuvaiheessa vaiheistus ei yleensä noudata osaprojektijakoa, vaan vaiheissa tarkastellaan suurempia kokonaisuuksia. Projektin loppuvaiheessa sensijaan vaiheet kannattaa yleensä rajata koskemaan vain yhtä osaprojektia.

Projektin vaiheistuksella saavutetaan yleensä seuraavia etuja: parempi hallitta­

vuus, organisaation motivointi, riskien pieneneminen, suunnittelun ja seurannan helpottuminen ja toiminnan tavoitteellisuuden paraneminen. Eräs merkittävim­

mistä eduista on myös se, että projektin vaiheet voivat tuottaa itsenäisiä tuloksia, joista mahdollisesti saadaan hyötyjä jo ennen koko tuloksen valmistumista. Vai­

heistuksen avulla voidaan laatia yksityiskohtaiset kehittämistyön ohjeet ja siten toiminta tulee kaikissa projekteissa samanlaiseksi. (Pere, 1988.)

Tuloksen ositus Projektin vaiheistus

Valmiita tuloksia saadaan käyttöön jatkuvasti.

Iteraatioprosessi projektin jatkuessa.

Pitkän tähtäyksen tavoit­

teiden huomiointi

Kuva 8. Tuloksen ositus ja projektin vaiheistus. (Pere, 1988.)

Esimerkkinä todellisesta vaiheistusmallista on KOP:n kehittämä ja käyttämä tietojärjestelmien rakentamisin alli STEMMA. Se pohjautuu useiden vaiheiden osalta perinteiseen elinkaarimalliin ja osa vaiheista ovat samoja, mutta ne nimetty eri tavoin. STEMMA koostuu seuraavista vaiheista: kokonaistutkimus, esitutki­

mus, määrittely, tekninen suunnittelu, toteutus, systeemitestaus, käyttöönotto ja ylläpito. Tekninen suunnittelu ja toteutus jakaantuvat vielä tietokanta- ja sovellus­

kohtaiseen tarkastelukulmaan.

3.4 Työmäärän arviointi

3.4.1 Yleistä

Tietojärjestelmäprojektin työmäärän arviointi on vaikeaa. Vaikka arvioijan arviot menisivät systemaattisesti pieleen (yleensä alakanttiin), ei tehdyistä virheistä opita. Puutteellisten seurantajärjestelmien ja projektin jälkiarvioinnin laiminlyön­

nin vuoksi arvioija menettää ainoan mahdollisuutensa saada täsmällistä palautet­

ta ja näin kehittyä.

Päättyneestä projektista ei oteta oppia ja seuraavan projektin arvioinnissa tehdään samat virheet uudelleen. Kun yrityksen työntekijöiden tuottavuutta ei mitata, on arvioitava sekä kohdejärjestelmän kokoa että sitä aikaa, mitä tietyn suuruisen järjestelmän tuottamiseen kuluu.

Tom DeMarcon määritelmä työmääräarviosta:"Työmäärän arvio on optimistisin ennustus, joka ei ole täysin mahdoton toteuttaa". Usein arviointitilanne vaikuttaa samalla tavalla. Tarjoustilanteessa arvioidaan työmäärät ja huomataan, että hinta muodostuu liian korkeaksi ja aletaan pienentää työmääriä. Projektipäällikkö saa riesakseen projektin, jossa on valmiiksi resursseihin nähden epärealistinen aika­

taulu. (Kurvinen, 1990b.)

Systemaattisilla menetelmillä, joihin kuuluvat luvussa 3.4.1 esiteltävät koko- ja resurssimallit, voidaan pienentää arviointiin liittyvää riskiä. Yksinkertaisempi tapa (ns. klubiaskimenetelmä) on jakaa järjestelmän osat 3-5 vaikeusluokkaan ja arvioida eri luokkiin kuuluviin tehtäviin tarvittavat työmäärät. Tällä menetelmäl­

lä päästään hämmästyttävän lähelle formaalimpien menetelmien tuloksia. Jotain oleellista saattaa kuitenkin jäädä helpommin huomaamatta kuin systemaattisissa menetelmissä. Riskiä voidaan pienentää käyttämällä joko useampaa arviointime­

netelmää ja/tai useampaa toisistaan riippumatonta henkilöä saman projektin arvioinnissa. Jos tulokset poikkeavat huomattavasti toisistaan, ei ole syytä ottaa keskiarvoa lopulliseksi arvoksi. Erojen syyt tulee selvittää ja päästä yksimielisyy­

teen lopullisesta arvosta. (Kurvinen, 1990b.)

3.4.2 Systemaattiset menetelmät

Jotta olisi mahdollista hallita tietojärjestelmien kehitysprojekteja, täytyy projektin ominaisuuksia ja työmääriä pystyä mittaamaan. Käytettävien mittareiden pitäisi kohdistua järjestelmän niihin ominaisuuksiin, joita asiakkaat pitävät tärkeinä.

Useimmat käytettävissä olevista mittareista kohdistuu ohjelmistoprojektien alka­

ja kustannustekijöihin. Ohjelmiston koon ja kehittämishankkeen resurssitarpeen arviointimenetelmät perustuvat matemaattisten ja tilastollisten arviointimallien

käyttöön. Ohjelmiston koon arviointiin tarkoitettuja malleja kutsutaan kokomal-

käyttöön. Ohjelmiston koon arviointiin tarkoitettuja malleja kutsutaan kokomal-

In document Utilizing project management to boost software engineering projects in large user organizations (sivua 11-0)