Ohjelmistotuotannon perusongelmista, kuten ohjelmistojen huonosta laatutasosta, projektien aikataulujen venymisestä ja alati kohoavista kustannuksista on pitkään yritetty päästä eroon tehostamalla ohjelmistotyötä yksittäisin menetelmin ja välinein, esimerkiksi uusin määrittely- ja suunnittelumenetelmin tai CASE-välineiden avulla. Todellisuudessa ongelmat ovat monesti olleet itse ohjelmistotuotantoprosessissa ja sen hallinnassa. Kun sulautetun ohjelmistotuotannon osuus suomalaisessa ohjelmistotyöstä on viime vuosikymmenen aikana erittäin nopeasti kasvanut, on samalla kasvaneiden prosessinhallinnan ongelmien ratkaisemista ollut pakko nopeuttaa.

Ohjelmistotuotantoprosessin kehittämisellä voi olla vain yksi lähtökohta: yrityksen liiketoiminnalliset tavoitteet ja niistä johdetut ohjelmistotuotannon tavoitteet. Nämä eivät suinkaan ole samoja eri yrityksissä. Jotkut yritykset voivat esimerkiksi vahvan markkina-asemansa avulla keskittyä järjestelmiensä laatuun, jolloin prosessissa painottuvat laadun tuottaminen ja sen varmistus. Toisten on taas pakko yrittää saada jokainen mahdollinen kauppa, jolloin pääasioiksi tulevat lyhyt toimitusaika ja tuotannon kaikinpuolinen tehokkuus.

Tavoitteiden pohjalta tulisi arvioida, mallintaa ja mitata ohjelmistotuotannon nykytila ja luoda askelittainen prosessin parantamisohjelma halutun tavoitetilan saavuttamiseksi. Prosessin parantaminen ja sen jatkuva tuki on myös osattava organisoida oikein. (Känsälä)

Seuraavaksi esitetään suoraviivainen tapa suorittaa ohjelmistoprosessin arviointia.

Yrityksessä voi olla tuntuma siitä missä työskentelymenetelmissä olisi parantamisen varaa. Tällöin voidaan suorittaa kyseisen ongelma-alueen työskentelymenetelmien arviointi seuraavan esimerkin kuvaamalla tavalla.

Ohjelmiston kokonaistestausprosessi

Ohjelmiston kokonaistestausprosessin tarkoituksena on testata integroituohjelmisto siten, että tuote täyttää ohjelmiston vaatimukset. Onnistuneesti suoritetun prosessin tuloksena pitäisi syntyä:

• Integroidulle ohjelmistolle kehitetään ohjelmiston vaatimusten tarkastusta varten hyväksymistestauskriteerit
• Integroitu ohjelmisto tullaan tarkastamaan käyttäen määriteltyjä hyväksymiskriteerejä
• Testitulokset taltioidaan
• Taantumatestaussuunnitelman kehittäminen
• Taantumatestauksen suorittaminen tarvittaessa

• Kehitä integroidulle ohjelmistolle testaussuunnitelma, mukaan lukien taantumatestausstrategia.

• Kehitä integroidulle ohjelmistolle testitapaukset. Kuvaa suoritettavat testitapaukset, jotka ilmaisevat ohjelmiston vaatimusten tarkastamisen, syöttötiedot ja tarkastuskriteerit. Joukon testitapauksia pitäisi demonstroida ohjelman ja ohjelmiston vaatimusten yhteensopivuutta.

• Testaa integroitu ohjelmisto. Testaa integroitu ohjelmisto hyväksymiskriteerejä vastaan ja dokumentoi tulokset.

• Taantumatestaa integroitu ohjelmisto. Jos ohjelmiston osiin on tehty muutoksia niin suorita taantumatestaus taantumatestausstrategian mukaisesti.

Esimerkiksi kunkin testitapauksen tulisi sisältää:

• tarkoitus
• syöttötiedot
• odotetut tulokset
• kohdistus vaatimuksiin

ja kunkin testituloksen tulisi sisältää:

• testauspäivämäärä
• kohde
• testitulokset (sisältäen vertailun odotettuun tulokseen)
• testilaitteisto
• vikaraportti

Arvioinnin aikana tarkastellaan prosessiin liittyviä peruskäytäntöjä ja niiden suorittamiseen liittyviä työtuloksia ja annetaan prosessille arvosana soveltaen seuraavaa asteikkoa:

N (not) = ei saavutettu (<15% ominaisuudesta saavutettu)

P (Partially) = osittain saavutettu (15-50 % ominaisuudesta saavutettu)

L (Largely) = laajasti saavutettu (51-85 % ominaisuudesta saavutettu)

F (Fully) = täysin saavutettu (>85 % ominaisuudesta saavutettu)

Karkeasti voidaan sanoa, että mikäli prosessi suoritetaan yrityksessä käyttämällä edellä kuvattuja peruskäytäntöjä ja vain alle 50 % prosessin työtuloksista saavutetaan niin prosessin arvosanaksi annetaan P eli prosessin tavoite saavutettiin vain osittain. Mikäli prosessin kaikki työtulokset saadaan toteutettua niin annetaan arvosanaksi F (täysin saavutettu) ja prosessi on tällöin kyvykkyystasolla yksi.

Arvioinnin aikana voidaan käyttää esimerkiksi alla olevan kaltaista arviointilomaketta. Lomakkeelta tulisi löytyä arvioinnin kohde ja tarkoitus sekä arviointitulos ja sen perusteet. Lisäksi on tärkeää, että arvioinnin aikana havaitut kehittämisideat sekä prosessin heikkoudet ja vahvuudet kirjataan muistiin.

Yritys: Arvioinnin suorittaja:

Päivämäärä:

Esimerkki arviointilomake

Kokonaistestausprosessin profiili ja kyvykkyystaso

Kokonaistestausprosessille voidaan määritellä arvioinnin perusteella prosessin profiili ja kyvykkyystaso. Kyvykkyystasoista ja prosessin profiileista kerrotaan enemmän myöhemmin.

PA = Prosessin hallinnan ominaisuus

Haluttaessa päästä prosessin suorittamisessa korkeammalle tasolle ryhdytään arvioimaan prosessin hallintaa eli prosessin hallintokäytäntöjä ja niiden ominaisuuksia. Jos halutaan saavuttaa hallittu prosessi on prosessi ja sen työtulokset pystyttävä tuottamaan hallitusti, pelkkä suorittaminen ei siis riitä. Prosessin suorittamisen aikataulujen ja vastuiden tunnistaminen ja suunnittelu kuuluvat osaksi hallittua prosessia. Prosessin ja työtulosten hallinnalle on esitetty kuvaukset standardin osassa 5.

Ohjelmistoprosessien mallintaminen ja työtulosten sekä niiden ominaisuuksien määrittely voi tuntua vaikealta. Kussakin prosessissa sovellettavat käytännöt ja työtulosten kuvaukset helpottaisivat ja nopeuttaisivat ohjelmistoprosessien arviointia ja parantamista huomattavasti. Onneksi tähän ongelmaan on olemassa ratkaisu.

Apuna yrityksen ohjelmistotuotannon nykytilan arvioimisessa ja mallintamisessa voidaan käyttää erilaisia arviointi- ja kehittämismalleja. Näistä tunnetuin on SEI:n (Software Engineering Institute) kehittämä CMM-malli (Capability Maturity Model). CMM-mallista on olemassa telealalle tehty sovitus Trillium, johon liittyvä materiaali on julkisesti saatavilla. CMM-mallia käytetään eniten yhdysvalloissa, josta se on myös kotoisin.

Kuva 1. Ohjelmistostandardien ja kehysmallien suhteet

Seuraavaksi esitellään ISO/IEC 15504 standardin historia ja perusarkkitehtuuri.

ISO 15504 eli SPICE on kansainvälinen standardi ohjelmistotuotantoprosessin arvioimiseen ja sen oletetaan olevan yleinen viitekehys ohjelmistotuotantoprosessin arvioimisessa.

Kansainvälisen ohjelmistotuotannon standardointi komitean (ISO/IEC JTC1/SC7 ) organisoimien tutkimusten tulosten pohjalta WG10 (Working Group 10) aloitti vuonna 1993 työnsä ohjelmistotoiminnan arviointijärjestelmän kehittämiseksi. Kehittämisprojektille annettiin nimeksi SPICE. Työryhmän tavoitteena oli luoda yhtenäinen arviointistandardi ohjelmistoprosessien arvioimiseen.

Kehittämisprojektin sisällä järjestettiin kaksivaiheinen käytännön kokeilu, jolla pyrittiin varmistamaan standardin soveltuminen tehtäväänsä. Työryhmän tuottamia dokumenttiluonnoksia hyödynnettiin joukossa ohjelmistoyrityksiä kahdessa eri vaiheessa ja palaute otettiin huomioon standardiluonnoksen jatkokehityksessä. Vuoden 1998 loppuun mennessä oli standardiehdokkaalla takanaan kaksi käytännön kokeiluvaihetta ja sen dokumentit julkaistiin teknisenä raporttina.

Standardiluonnoksen jatkokehityksen kolmas vaihe alkoi vuonna 1999. Standardi on ollut vakaa vuoteen 2001 saakka.

ISO/IEC 15504 täydentää useita muita kansainvälisiä organisaatioiden ja prosessien kyvykkyyden ja tehokkuuden arviointiin kehitettyjä standardeja ja malleja, mm ISO 9000 sarjaa (erityisesti ISO/IEC 12207, ohjelmiston elinkaariprosessit) ja CMM:ää (Capability Mature Model, SEI).

ISO 15504 standardi muodostuu yhdeksästä osasta. Tässä luvussa kuvataan kaikki yhdeksän osaa sekä niiden roolit standardissa. Alla olevassa kuvassa 2 on esitetty ISO 15504 standardin osat.

Kuva 2. ISO 15504 standardin osat. (ISO/IEC 15504-1:1998)

Osa 1 (informatiivinen) kuvaa standardin dokumentit ja niiden väliset riippuvuudet. Lisäksi ensimmäinen osa antaa ohjeiston oikean standardin osan valitsemiseen ja hyödyntämiseen. Osassa 1 selitetään myös standardin sisältämät vaatimukset sekä sen soveltuvuuden arvioinnin suorittamiseen.

Osa 2 (normatiivinen) määrittelee kaksiulotteisen viitemallin prosessien arviointiin kuvaamalla prosessit ja niiden kyvykkyydet. Viitemalli määrittelee joukon prosesseja luokiteltuina niiden tarkoituksen mukaan sekä kehysmallin, jonka avulla prosessien kyvykkyyttä arvioidaan. Lisäksi osassa esitellään ISO 15504 yhteensopivan arviointimallin vaatimukset.

Osa 3 (normatiivinen) määrittelee menettelytavat arvioinnin suorittamiselle, jotta arvioinnin tulos on luotettava ja toistettava.

Osa 4 (informatiivinen) tuottaa ohjeiston ohjelmistoprosessin arvioinnin suorittamiseen sekä tulkitsee ISO/IEC 15504-2 ja ISO/IEC 15504-3 vaatimukset eri arviointimuodoissa. Ohjeisto kattaa kattaa dokumentoidun arviointiprosessin valinnan ja käytön mukaan lukien yhteensopivan arviointimallin ja sitä tukevat työkalut. Ohjeisto on tarpeeksi yleinen ollakseen sopiva kaikenlaisiin organisaatioihin. Lisäksi arvioinnin suorittamiseen esitetään erilaisia menetelmiä ja tekniikoita, joita valikoima työkaluja tukee.

Osassa 5 (informatiivinen) kuvataan esimerkki arviointimalli, joka on suoraan yhteensopiva ISO/IEC TR 155504-2 kuvatun viitemallin kanssa. Kuvattu arviointimalli laajentaa viitemallin sisältämällä perustavan joukon prosessin suorituskykyä ja kyvykkyyttä kuvaavia indikaattoreita.

Osa 6 (informatiivinen) kuvaa arvioijalta vaadittavan pätevyyden, kokemuksen ja koulutuksen, jotta hän on pätevä suorittamaan prosessien arviointia. Osassa 6 kuvataan myös mekanismit, joita voidaan käyttää testaamaan arvioijan pätevyyttä sekä kelpoistamaan arvioijan koulutus ja kokemus.

Osa 7 (informatiivinen) kuvaa kuinka määritellä syötteet ja kuinka hyödyntää arvioinnin tuloksia prosessien parantamisessa. Ohjeisto sisältää esimerkkejä prosessien parantamisesta erilaisissa tilanteissa.

Osa 8 kuvaa kuinka määritellä syötteet sekä käyttää arvioinnin tuloksia prosessin kyvykkyystason määrittelemiseen. Se opastaa kyvykkyystason määrittelyssä suoraviivaisissa sekä myös monimutkaisemmissa tilanteissa mukaan lukien esimerkiksi tulevaisuuden kyvykkyystason määrittely. Ohjeisto prosessin kyvykkyystason määrittämiseen on sovellettavissa sekä itsearvioinnissa että hankkijan mahdollisen toimittajan kyvykkyystason arvioimisessa.

Osassa 9 (informatiivinen) määritellään standardin sanasto.

Ohjelmistoprosessin arvioinnilla on kaksi käyttötapaa (kuva 3).

Kuva 3. Ohjelmistoprosessin arviointi SPICE standardin mukaan

Ohjelmistoprosessin arvioinnin ensimmäinen käyttötapa on ohjelmistoprosessien parantaminen, jolloin prosessin nykytilaa kuvaavia arviointituloksia voidaan tarkastella organisaation liiketoiminnan tarpeiden kannalta. Arviointitulosten perusteella voidaan järjestää kehitettävät prosessit tärkeysjärjestykseen.

Ohjelmistoprosessin arvioinnin toinen käyttötapa on prosessin kyvykkyyden arviointi. Arvioimalla prosessin kyvykkyyttä voidaan muodostaa kuva prosessin soveltuvuudesta aiottuun käyttötarkoitukseensa. Kyvykkyydenarviointia voidaan käyttää esimerkiksi toimittajavalinnan yhteydessä tai yrityksen halutessa osoittaa kyvykkyytensä jollakin ohjelmistoliiketoiminnan alueella

SPICE –standardi sisältää kaksiulotteisen viitemallin prosessin kyvykkyyden arvioimiseksi – ensimmäinen ulottuvuus määrittelee arvioitavat prosessit ja toinen ulottuvuus kuvaa asteikon kyvykkyyden mittaamiselle. Kuvassa 4 esitetään viitemallin kaksiulotteinen rakenne.

Prosessiulottuvuuden prosessit ryhmitellään standardissa kolmeen elinkaariprosessialueeseen (vrt. ISO/IEC 12207), jotka sisältävät viisi prosessiryhmää prosessin toiminnan luonteen mukaisesti luokiteltuina. Prosessialueet ja -ryhmät ovat:

• I Varsinaiset elinkaariprosessit
• Asiakas-toimittajasuhteen hallinnan prosessit (CUS)
• Ohjelmistojen kehittämisprosessit (ENG)
• II Tukevat elinkaariprosessit
• Ohjelmistokehitystä tukevat prosessit (SUP)
• III Organisationaaliset elinkaariprosessit
• Ohjelmistokehityksen hallinnan prosessit (MAN)
• Organisaation tarjoamien puitteiden prosessit (ORG)

Prosessiryhmien sisältämät prosessit on esitetty liitteessä 1. Jokaiselle prosessille kuvataan tarkoituslause (purpose statement), joka kuvaa prosessin suorittamisen tavoitteet. Prosessin tarkoituslauseen vaatimukset täytetään suorittamalla erilaisia toimintoja ja tehtäviä, jotka ovat tyypillisiä tuotettavalle tuotteelle. Näiden peruskäytäntöjen (base practices) avulla voidaan määritellä prosessin tavoitteiden saavuttaminen. Viitemalli ei määrittele miten tai missä järjestyksessä tarkoituslauseen tavoitteet täytetään. Standardin prosessiryhmien ja prosessien kuvauksia voidaan käyttää myös apuna määriteltäessä yrityksen omia prosesseja.

Viitemallin kyvykkyysulottuvuus määrittelee mitta-asteikon prosessin kyvykkyystasolle mille tahansa prosessille. Prosessin kyvykkyys ilmaistaan prosessin hallinnan ominaisuuksina (ks. kuva 4, kyvykkyysulottuvuus), jotka on ryhmitelty kyvykkyystasoille. Jokainen hallinnan ominaisuus mittaa prosessin kyvykkyyden tiettyä näkökulmaa. Itse prosessin hallinnan ominaisuudet mitataan prosentti asteikolla ja näin saadaan yksityiskohtaisempi näkökulma tiettyyn prosessin kyvykkyyden osa-alueeseen, jota tarvitaan tukemaan prosessin parantamista ja kyvykkyystason määrittelyä. Prosessin hallinnan ominaisuuksia käytetään päätettäessä onko prosessi saavuttanut määritellyn kyvykkyystason.

Viitemallissa on kuusi kyvykkyystasoa:

Taso 0: Keskeneräinen prosessi

Taso 1: Toimiva prosessi

Taso 2: Hallittu prosessi

Taso 3: Vakiintunut prosessi

Taso 4: Ennustettava prosessi

Taso 5: Optimoituva (itseohjautuva) prosessi

Taso 0: Prosessin tavoitteen saavuttamisessa epäonnistutaan. Prosessilla on vain muutamia tai ei yhtään helposti tunnistettavaa lopputulosta.

Taso 1: Prosessin tarkoitus yleisti saavutetaan. Suoritus ei ole tiukasti suunniteltu tai jäljitettävissä. Organisaation jäsenet tiedostavat, että toiminto tulee suorittaa ja on olemassa yleinen sopimus siitä, että toiminto suoritetaan niin vaadittaessa. Prosessin tulokset on tunnistettu ja ne todistavat prosessin tarkoituksen saavuttamisen.

Taso 2: Prosessi tuottaa tuotteensa määriteltyjen toimintatapojen avulla ja prosessi on suunniteltu ja jäljitettävissä. Tuotteet vastaavat määriteltyjä standardeja ja vaatimuksia. Suurin ero edelliseen tasoon on, että prosessin tuotteet täyttävät määritellyt laatuvaatimukset annettujen aikataulujen ja resurssien rajoissa.

Taso 3: Prosessi suoritetaan ja hallitaan käyttämällä määriteltyjä hyvän ohjelmistotuotantotavan mukaisia periaatteita. Prosessin yksittäiset toteutukset suoritetaan hyväksytyn ja räätälöidyn standardin sekä dokumentoidun prosessin mukaisesti, jotta asetetut tulokset saavutetaan. Prosessin toteuttamisessa tarvittavat voimavarat on määritelty. Suurin ero edelliseen tasoon on se, että vakiintuneella tasolla käytettään standardiprosesseja, joiden avulla prosessin tulos saavutetaan.

Taso 4: Ennustettava prosessi suoritetaan jatkuvasti kontrolloidun käytännön mukaan määriteltyjen tavoitteiden saavuttamiseksi. Prosessin suorituskyvystä kerätään yksityiskohtaista tietoa ja se analysoidaan. Tämä johtaa prosessin kyvykkyyden määrälliseen ymmärtämiseen ja kasvaneeseen kykyyn ennustaa ja hallita prosessin suorituskykyä. Prosessin suorituskyky on määrällisesti hallittu. Prosessin tulosten laatu on määrällisesti tiedossa. Suurin ero edelliseen tasoon on että prosessi suoritetaan jatkuvasti kontrolloidusti prosessin tulosten saavuttamiseksi.

Taso 5: Prosessin suorittaminen optimoidaan ottamalla huomioon liiketoiminnan nykyiset ja tulevat tarpeet. Prosessi onnistuu toistuvasti täyttämään liiketoiminnan tavoitteet. Prosessin suorituskyvyn määrälliset tehokkuus ja pätevyystavoitteet ovat vakiintuneet organisaation liiketoiminnan tavoitteiden mukaisiksi. Prosessin jatkuva valvonta näiden tavoitteiden pohjalta mahdollistetaan määrällisen palautteen avulla ja prosessin parantaminen saavutetaan tulosten analysoinnilla. Prosessin optimointi vaatii innovatiivisia ideoita, teknologiaa sekä tehottomien prosessien muuttamista siten, että ne vastaavat määritettyjä tavoitteita ja päämääriä. Ensisijainen ero edelliseen tasoon on se, että määritetyt ja standardoidut prosessit dynaamisesti muuttuvat ja mukautuvat tehokkaasti vastaamaan liiketoiminnan nykyisiä sekä tulevia tavoitteita.

Edellä kuvatun viitemallin perusteella ei voida suorittaa luotettavaa prosessin kyvykkyyden arviointia, koska yksityiskohtien taso ei ole riittävä. Standardin 5 osassa laajennetaan edellä kuvattua viitemallia ja esitetään esimerkki arviointimalli, joka on suoraan yhteensopiva osassa 2 kuvatun viitemallin kanssa. Malli sisältää perustavan joukon prosessin suorituskykyä ja kyvykkyyttä kuvaavia indikaattoreita. Arviointimallin ja viitemallin suhde on esitetty kuvassa 5.

Kuva 5. Ohjelmistoprosessin arviointimalli. (ISO/IEC 15504-5:1998)

Standardin (ISO/IEC 15504) osan viisi arviointimallissa kuvataan prosessiryhmät ja prosessit standardin viitemallin mukaisesti. Lisäksi mallissa kuvataan esimerkin omaisesti prosesseihin liittyvät työtulokset. Niitä voidaan käyttää, kun selvitetään prosessin suorittamisen mahdollisia syötteitä ja tuloksia. Peruskäytäntöjen, työtulosten ja työtuloksiin liityvien ominaisuuksien olemassa olo tuottaa todisteen siihen liityvien prosessien suorittamisesta. Prosessin suorittaminen onnistuneesti vastaa kyvykkyystasoa 1. Jokaiselle työtulokselle on määritelty tietyt ominaisuudet, jotka se tyypillisesti sisältää. Esimerkiksi, jos työtulos on tarkastusmerkintä, niin tarkastusmerkinnän täytyy sisältää mm. seuraavat asiat:

• mitä tarkastettiin
• kuka tarkasti
• tarkastuksen tilanne jne.

Kun siirrytään prosessin kyvykkyyden arvioinnissa tasoille 2-5, siirrytään arvioimaan prosessin hallintokäytäntöjä sekä niiden ominaisuuksia. Esimerkiksi kypsyystasolle 2 (hallittu prosessi) on kuvattu seuraavat hallintokäytännöt prosessin suorittamisen hallinnalle:

• tunnista prosessin suorittamisen päämäärät (esimerkiksi aikataulu ja voimavarojen käyttö)
• suunnittele prosessin suorittaminen päämäärien mukaisesti tunnistamalla prosessin toiminnot, niiden aikataulut ja voimavarojen käyttö
• suunnittele ja kohdista vastuut prosessin työtulosten saavuttamiseksi
• hallitse toimintojen toteutus jatkuvalla jäljittämisellä ja uudelleen suunnittelulla, jotta työtulokset vastaavat määriteltyjä päämääriä.

Jokaiseen hallintokäytäntöön liittyy käytännön suoritukseen, voimavaroihin ja infrastruktuuriin liittyviä ominaisuuksia, jotka on määritelty yksittäisen hallintokäytännön yhteydessä. Esimerkiksi prosessin suorittamisen hallintaan liittyvään hallintokäytäntöön, jossa suunnitellaan ja kohdistetaan prosessin vastuut liittyy seuraavanlaisia ominaisuuksia:

• käytännön suorittamisen ominaisuudet: esimerkiksi vastuista ja valtuuksista on sovittu ja ne on dokumentoitu sekä työtulosten välitavoitteet on määritelty.
• prosessin hallintaa avustavat voimavarat ja infrastruktuuri: esimerkiksi projektin hallintatyökalu ja kommunikointimekanismi.
• hallintokäytäntöä tukevat prosessit: esimerkiksi MAN. 2 Projektinhallinta prosessi ja ORG.3 Henkilövoimavarojen hallinta.

Standardin (ISO/IEC 15504) osan viisi kuvaama arviointimalli on kuitenkin vain ohjeellinen ja arvioija voi käyttää sitä apuna suorittaessaan arviointia. Arviointiprosessi tulee dokumentoida siten, että se selvästi ilmaisee mittarin tyypin ja luokan. Tällöin arvioijan lausunto voidaan helposti vahvistaa tai tarkastaa standardin (ISO/IEC 15504) osan kolme vaatimusten mukaan.

Tavallaan kolmas ulottuvuus on arvioinnissa sovellettava asteikko. Sen on oltava ainakin neliportainen ja sisällytettävä ainakin seuraava asteikko:

N (not) = ei saavutettu (<15% ominaisuudesta saavutettu)

P (Partially)=osittain saavutettu (15-50 % ominaisuudesta saavutettu)

L (Largely)=laajasti saavutettu (51-85 % ominaisuudesta saavutettu)

F (Fully)=täysin saavutettu (>85 % ominaisuudesta saavutettu)

Käytännössä arviointiasteikkoa pitää tulkita yrityksen ohjelmistotuotannon tyypin mukaan, mitään ehdotonta totuusasteikkoa ei ole ainakaan vielä olemassa. Arviointiasteikon soveltamisen tuloksena kukin prosessin hallinnan ominaisuus saa yllämainitun arvosanan ja on osa prosessin kyvykkyysprofiilia.

Seuraavaksi esitellään tarkemmin ohjelmistoprosessin arvioinnin toista käyttötapaa, ohjelmistoprosessin parantamista. Esitys perustuu standardin 7 osaan.

Motivaatio prosessin parantamiselle löytyy tavallisesti yrityksen tarpeista saavuttaa korkeampaa ohjelmiston laatua, pienemmät kehityskustannukset, nopeampi kehitysaika tai parempi ohjelmistotuotteiden- ja prosessien ennustettavuus ja kontrolloitavuus.

Liiketoiminnan tavoitteista johdetut ohjelmistotuotannon parantamiskohteet ohjaavat arvioitavien prosessien valintaa, parantamistavoitteiden tunnistamista ja viimekädessä tehokkaimpien parantamiskeinojen tunnistamista. Tavoitteet tulisi asettaa joko takaamaan hyvän ohjelmistotuotannon käytännöt tai tehokkuus, jolla prosessi toteuttaa liiketoiminnan tavoitteet tai molemmat. Kun tavoitteet on määritelty niin voidaan etsiä niille mittarit. Jokaista parantamiskohdetta tulisi kohdella omana projektinaan. Projektit tulisi suunnitella huolellisesti, hallita riskit ja tiedottaa projektin etenemisestä asianomaisille.

Organisaation liiketoiminnan tavoitteiden ja tarpeiden analysoinnin jälkeen on olennaista luoda johdon tietoisuus prosessin parantamisohjelman tarpeellisuudesta. Tämä vaatii johdon taloudellista sitoutumista. Prosessin parantamisohjelman tavoitteet tulee selvästi ilmaista ja ymmärtää ja ilmaista käyttäen mitattavia prosessin tavoitteita. Prosessin parantamisohjelma tulee ottaa osaksi organisaation strategista liiketoiminta suunnitelmaa.

Lopullinen päätös toteuttaa parannukset, yhdessä parantamisohjelman tärkeimpien prosessien budjettien määrittämisen kanssa ja pääprosessien tärkeysjärjestyksen kanssa mahdollistaa parantamisprosessin edetä seuraavien vaiheiden kautta:

• Prosessin parantamisen aloittaminen
• Arvioinnin suorittaminen niillä alueilla, joilla parantamisen uskotaan olevan hyödyllistä
• Prosessin parantamisohjelman suunnitelma toimintaohjeineen arvioinnin tulosten tuloksena
• Parantamissuunnitelman toteuttaminen suunnitelman pohjalta
• Parannusten vahvistaminen
• Parannusten säilyttäminen ylläpitämällä uutta suoritustasoa kunnes stabiilitila on saavutettu
• Suorituskyvyn tarkkailu prosessin parantamisohjelman jatkamiseksi vertailemalla tuloksia mitattaviin tavoitteisiin jotka on määritelty parannussuunnitelmassa.

Ohjelmistoprosessin parantamisen kustannukset ovat SEI:n mukaan usein noin 3-5 % organisaation ohjelmistokehityksen kokonaiskustannuksista. Kustannusten määrä riippuu tietysti organisaation koosta, tyypistä ja parannusten laajuudesta (Krasner).

Edellä kuvattua prosessimallia voidaan käyttää tunnistamaan käytäntöjä, joiden tulee olla mukana kunkin prosessin kyvykkyyden parantamiseksi. Seuraavaksi esitellään lyhyesti prosessin parantamisprosessin kulku.

Kuva 6. Ohjelmistoprosessin parantamisen vaiheet

Ohjelmistoprosessin parantamisprojektin alkuvaiheessa luodaan alustava prosessin parantamisohjelma, joka on itsenäinen suunnitelma, joka sisältää organisaation prosessien nykytilan kuvauksen ja historian sekä alustavat parantamisalueet. Seuraavaksi keskitytään prosessin arvioinnin valmisteluun ja suorittamiseen. Arvioinnin avulla voidaan saada tarkempaa tietoa parantamiskohteista.

Arvioinnin valmistelu alkaa arvioinnin sponsorin tunnistamisella. Sponsori on henkilö (johtaja), joka sitoutuu prosessin parantamisohjelmaan ja vaatii arvioinnin suoritettavaksi sekä tarjoaa sille voimavarat. Sponsori varmistaa, että arvioinnin syötteet (tarkoitus, laajuus, rajoitteet ja vastuut) ovat asianmukaisesti määritelty siten, että ne kohtaavat prosessin parantamisohjelman tarpeet. On todennäköistä, että pätevän arvioijan avustus ja ohjeet auttavat sponsoria muotoilemaan arvioinnin syötteet.

Sponsorilla on valta varmistaa, että arviointi voidaan suorittaa tehokkaasti ja hän ottaa vastuun arvioinnin tuloksesta.

Vastuu arvioinnin asianmukaisesta suorittamisesta on arvioijalla. Uskottavuus on avaintekijä arviointiryhmän ja arvioijan valinnassa. Yleensä ulkopuolisen arvioijan valinta saattaa osoittautua uskottavammaksi (ulkopuolisen näkökulma)

Arvioinnin tarkoitus on tuottaa tietoa organisaatioyksikön prosessin kyvykkyydestä arviointituloksen muodossa. Arvioinnin tarkoituksen määrittely opastaa arviointiryhmää arvioinnin suorittamisen aikana erityisesti koskien arvioinnin aikana kerättävän tiedon määrää, luonnetta ja sisältöä. Tarkoituksen määrittelyn tulee tehdä selväksi, että arviointi tehdään osana prosessin parantamisohjelmaa ja sen tulee sisältää selvät kuvaukset laadunparannus tavoitteista ja erityisesti kohteista, joiden odotetaan riippuvan arviointituloksista.

Arvioinnin laajuus määrittelee rajat arvioinnille sekä yrityksessä, että arvioitavien prosessien osalta.

Prosessin parannusohjelman kohteena voi olla koko organisaatio, organisaation osa, yksittäinen projekti tai projektin osa. Prosessin arviointi kuitenkin kohdistuu organisaatioyksikön prosessien kontekstiin erityisesti sovellusalueeseen sekä tuotteelle tai palvelulle tyypilliseen kokoon, kriittisyyteen ja monimutkaisuuteen tai laatuominaisuuksiin. Jos prosessin arviointiohjelma erottelee organisaatioyksiköt eri tyyppisine toimintoineen on jokainen niistä arvioitava erikseen.

Mitä laajempi arviointi suoritetaan sitä suurempia ponnisteluja tarvitaan edustavien tulosten saavuttamiseksi. Siksi sponsori saattaa haluta rajoittaa arvioinnin laajuutta niihin prosesseihin, joista oletetaan saatavan suurin parannusmahdollisuus. Prosessiryhmille/prosesseille, jotka alun perin näyttävät vaikuttavan parantamistavoitteiden saavuttamiseen tulee antaa etuoikeus. Tämä alustava järjestys saattaa muuttua arvioinnin suorittamisen ja tulosten analysoinnin jälkeen.

Arvioinnin laajuuden kuvaukseen tulee sisältää kaikki oletukset ja arvioinnit prosessiryhmien, prosessien ja käytäntöjen vahvuuksista tai heikkouksista.

Toteutettavan prosessin mallintaminen tulee tehdä keräämällä edustava valikoima tietoa, joka kuvaa luotettavasti ohjelmistoprosessin nykytilan. Siksi on käytännöllistä arvioida projekteja, joita pidetään joko huonoina tai parhaina esimerkkeinä organisaation nykyisten prosessien suorituksesta. Tällä tavalla organisaation huonointen ja parhaiden tapausten erot löydetään ja voidaan ottaa huomioon parantamisessa.

Laajuus määritellään alustavasti organisaatioyksikössä käytettävien ja ymmärrettyjen prosessien termeillä. Lopulta organisaation prosessit täytyy kuitenkin kartoittaa sellaista prosessimallia vastaan, joka on yhteensopiva standardin viitemallin kanssa, jotta arviointiryhmä voi suorittaa arvioinnin. Kohdistuksen voi hoitaa sponsori tai arviointiryhmä. Jos organisaation prosesseja ei voida kohdistaa yksi yhteen prosessimallin kanssa niin ne tulee määritellä lisäprosesseiksi.

Arvioitavien prosessien määrittelyn lisäksi laajuudessa tulee selvästi kuvata näytteenottostrategia, organisaatioyksikkö ja sen piirteet sekä tuotteen/palvelun piirteet. Erityisesti tuotteen/palvelun piirteet tuottavat kontekstin, jossa arviointiryhmä arvioi käytetyn käytännön sopivuuden. Tämä vaikuttaa myös toimialan parhaisiin käytäntöihin tehtävän vertailun luotettavuuteen.

Sponsori saattaa haluta rajoittaa arviointiryhmän valinnanvapautta määrittelemällä arvioinnin näytteenottostrategian valitsemalla haastateltavat ihmiset ja tiedon käytön. Kaikki rajoitukset, niin positiiviset kuin negatiivisetkin dokumentoidaan arvioinnin rajoituksiksi.

Jokaisen arvioitavan prosessin omistajan tulisi aina osallistua arviointiin.

Arvioinnin tulosten omistus ja tiedon luottamuksellisuus voi olla ongelma monissa yrityksissä. Mikä tahansa tilanne onkin, niin arvioinnin rajoitusten tulee sisältää selvä lausunto siitä, kuinka arvioinnin tuloksia ja tietoa käytetään ja käsitellään.

Prosessin arviointi aloitettiin valmistelemalla arvioinnin syötteet (ks edellinen luku). Arviointiryhmä suorittaa arvioinnin ja se tuottaa tulokset, jotka muodostuvat:

• Prosessin nykytilan profiili
• Arviointitiedot ( kaikki tieto, joka on asianmukaista kuvaamaan arvioinnin tuloksia, erityisesti viitteet, jotka tukevat prosessin ominaisuuksien arvostelua)
• Lisätiedot prosessin parantamiseen (parantamistavoitteiden tunnistamiseen, mittarit ja kohteet)

Lisätiedot voivat sisältää:

• Olemassa olevat parhaat käytännöt, jotka voidaan omaksua ja vakiinnuttaa organisaatioon
• Kokemukset organisaatiossa aikaisemmin sovelletuista menetelmistä ja työvälineistä
• Yrityskulttuuriasiat, jotka saattavat nopeuttaa/haitata parantamispyrkimyksiä
• Organisaation asiat, jotka saattavat vaikuttaa prosessin parantamisen mahdollisiin hyötyihin
• Koulutustarve

Arviointitulokset eivät näytä ainoastaan mitkä prosessit ovat matalalla kypsyystasolla vaan myös vaihtelevuuden asteen organisaatioyksikössä. Molemmat näkökulmat ovat hyödyllisiä päätettäessä parantamisohjelman toimenpiteiden tärkeysjärjestystä.

Arviointitulosten analysointi tuottaa tietoa prosessin nykyisistä vahvuuksista ja heikkouksista sekä osoittaa parantamismahdollisuudet. Analysointi voidaan suorittaa käyttämällä prosessin kyvykkyystason arvostelua ja prosessin hallinnan ominaisuuden arvostelua yhdessä arviointikontekstin tiedon kanssa.

Vahvat pisteet tunnistetaan prosesseista joilla on korkein kyvykkyystaso arvostelu. Vahvuudet voivat tukea prosessin parantamista seuraavasti:

• vahvat prosessit tuottavat kokemuksen hyvistä käytännöistä, jotka voidaan omaksua ja vakiinnuttaa organisaatiossa
• Korkeimmilla kyvykkyystasoilla prosessi ryhmän sisällä olevat prosessit saattavat näyttää mahdollisuuden loppujenkin prosessiryhmän prosessien tehokkuuden parantamiseen.

Heikkouksia voivat olla:

• Prosessit alhaisella kyvykkyystasolla
• Prosessit puuttuvine käytäntöineen
• Epätasapainoiset prosessin hallinnan ominaisuudet kyvykkyystason sisällä, jotka ovat tarpeellisia erityisen tarpeen saavuttamiseksi
• Alhaiset prosessin hallinnan ominaisuudet läpi arvioitujen prosessien saattavat osoittaa heikkouksia tietyssä prosessiryhmässä (esimerkiksi alahaiset pisteet prosessin kyvykkyydessä tasolla 2 saattavat näyttää heikkouksia ohjelmistokehityksen hallinnan ja tuen prosessiryhmissä.)

Arviointitulokset eivät näytä ainoastaan mitkä prosessit ovat matalalla kypsyystasolla vaan myös vaihtelevuuden työskentelytapojen välillä organisaatiossa. Molemmat näkökulmat ovat hyödyllisiä päätettäessä parantamisohjelman tärkeysjärjestystä.

Arviointitiedot tulee säilyttää tuloksineen, jos myöhemmin tulee tarve varmistaa, että arviointi suoritettiin standardin mukaisesti.

Arvioinnin aikana kerätty tieto, erityisesti kyvykkyystasot ja prosessin ominaisuuksien arvostelut analysoidaan organisaation tarpeiden valossa:

• parantamisalueiden tunnistaminen
• ohjelmistoprosessin laadullisten tavoitteiden sekä mitattavien parantamistavoitteiden asettaminen
• toimintosuunnitelman luominen sekä integrointi prosessin parannusohjelman suunnitelmaan

Johdon tulee hyväksyä parannusalueet, kohteet ja tavoitteet ja päivittää prosessin parantamissuunnitelmaa ja siten sitouttaa organisaatio suorittamaan suunnitellut parannukset. Päätökset tulee viestiä selvästi kaikelle henkilökunnalle johon se vaikuttaa.

Parannusalueet tulee tunnistaa ja järjestää tärkeysjärjestykseen perustuen kuvassa kolme esitettyihin tekijöihin. Tekijät ovat:

• arviointitulokset, jotka esittävät heikkoa tai vahvaa aluetta arvioiduista prosesseista
• organisaation tarpeet, jotka asettavat yleiset parantamistavoitteet parannusohjelmalle
• alan normit ja parhaat käytännöt jotka tarjoavat vertailukehyksen arviointituloksille
• mahdolliset olemassa olevat tehokkuusmittarit tunnistavat parantamisen tärkeysjärjestyksen organisaatiolla toiminnassa yleisesti. (esim. kerätään tietoa puuteiden lukumäärästä/tuote jne)
• riskit liittyen, joko siihen ettei parannustavoitteita saavuteta tai parannus toimenpiteisiin liittyen

Kuva 7. Parannuskohteiden tunnistaminen ja priorisointi

Yleensä aloitetaan useampia prosessin parantamisprojekteja, jotka sisältävät yhden tai useamman parantamistoimenpiteen. Jokainen projekti sisältää seuraavat neljä päätehtävää:

• toteuttamistavan valitseminen (vaihtoehtojen arviointi, pilottiprojekti vai koko organisaatio)
• yksityiskohtaisen toteutussuunnitelman valmistelu ja hyväksyminen (tavoitteet, aikataulut, vastuut, seuranta)
• prosessin parantamistoimenpiteiden toteuttaminen suunnitelman mukaisesti (johdon tuki, muutokset yrityskulttuurissa, sitouttaminen, koulutus)
• toteutuksen seuranta (etenemisen seuranta, tavoitteiden toteutumisen seuranta)

Kun prosessin parantamisprojekti on suoritettu niin organisaation pitäisi:

• vahvistaa, että suunnitellut päämäärät ja tavoitteet on saavutettu ja odotetut hyödyt ovat toteutuneet. (uudelleen arviointi)
• vahvistaa, että halutut muutokset organisaatiokulttuurissa ovat toteutuneet ilman sivuvaikutuksia
• uudelleen arvioida parannettuun prosessiin liittyvät riskit
• uudelleen arvioida ja vertailla parannusten kustannuksia ja hyötyjä odotettuihin kustannuksiin ja hyötyihin

Yrityksen johdon tulee hyväksyä projektin tulokset ja arvioida tulosten ja organisaation tarpeiden vastaavuus.

Parannusten vahvistamisen jälkeen ohjelmistoprosessia tarvitsee ylläpitää uudella suoritustasolla. Parannettua prosessia pitäisi käyttää kaikissa soveltuvissa kohteissa. Tämä vaatii johdolta parannetun prosessin vakiinnuttamisen tarkkailua ja tarvittaessa kykyä rohkaista prosessin hyödyntämiseen esimerkiksi organisaation muissa projekteissa.

Organisaation ohjelmistotuotantoprosesseja tulisi seurata jatkuvasti ja uusia prosessin parannusohjelmia pitäisi valita ja toteuttaa osana jatkuvaa prosessin parannusohjelmaa, koska lisäparannukset ovat aina mahdollisia.

Joskus alkuinnostus ja sitoutuminen katoavat, kun nopeita tuloksia ei välittömästi ole odotettavissa. Jotkut tehdyt parannukset, kuten koodin analysointityökalun käyttö, tuottavat parempia tuloksia välittömästi. Toiset käytännöt, kuten mittari perusteinen arviointi saattavat vaatia oman aikansa sijoitusten realisoimiseksi. Oppimiskäyrä havainnollistaa asiaa (kuva 8.). Prosessin parantamiseen tehdyllä investoinnilla on vaikutus sen hetkiseen tuottavuuteen, koska aika joka käytetään parempien työskentelytapojen kehittämiseen ei ole käytössä päivän tehtäviin. Voi olla houkuttelevaa hylätä parannukset, kun tuottavuus ei toteutuksesta huolimatta näytä heti parantuvan. Kuitenkin yleensä pitkällä tähtäimellä tehdyt parannukset maksavat itsensä takaisin. (Wiegers)

Kuva 8. Prosessin parantamisen oppimiskäyrä (Wiegers)

Yksi tapa, jolla prosessin laatua voidaan mitata on uudelleen käsittelyn osuuden mittaaminen projekteissa. Uudelleen käsittelyn osuus on matalan kyvykkyystason organisaatioissa raportoitu vaihtelevan välillä 40-60% ohjelmiston kokonaiskehitysajasta. Koska jatkuva uudelleen käsittely syö voimavaroja uusien toimintojen toteutuksesta se voidaan suoraan sitoa liiketoiminnan mittareihin, kuten asiakkaan tarpeiden tai vaatimusten tyydyttämiseen. Uusintakäsittelyn- ja prosessin parantamiskustannusten osuudet on esitetty graafisesti ajan suhteen kuvassa 9. Parantamistoimenpiteisiin uhratut investoinnit maksavat itsensä takaisin moninkertaisesti.

Kuva 9. Prosessin laatu

Prosessin parantaminen prosessin parantamisen vuoksi ei pitkällä tähtäimellä ole kestävää toimintaa. Parannusten täytyy näkyä parannuksina tuotteissa ja työskentelymenetelmissä. Yksi säännöllisesti käytetty yksinkertainen mittari tuotteen laadulle on tuotteen puutteiden lukumäärä. Keskimääräinen trendi organisaation tuotteiden puutteiden lukumäärästä kertoo paljon siitä maksavatko vakiintuneet muutokset itsensä takaisin ajan kuluessa.

Kuvassa 10 esitetään IBM:n, HP:n ja Motorolan kokemuksia puutteiden määrän vähenemisestä ajan suhteen prosessin parantamistoimenpiteiden seurauksena.

Kuva 10. Tuotteen laatu

Projektin ennustettavuutta voidaan mitata usealla tavalla tutkimalla esimerkiksi seuraavia trendejä: suunniteltu ja toteutunut toimitusaika sekä ajallaan toimitettujen tuotteiden määrä ja myöhästyneiden tuotteiden määrä sekä edellä mainittujen mittareiden välisiä suhteita. Kuva 11 esittää esimerkin parannuksesta ajallaan toimitettujen tuotteiden osuudessa viiden vuoden ajalta. Todelliset keskimääräiset työkustannukset verrattuna budjetoituun työkustannuksiin voidaan esittää graafisesti samalla tavalla. Samalla kun organisaation suunnittelun tarkkuus paranee, heidän työskentelynsä paranee ja edellä mainitut mittarit paranevat.

Kuva 11. Ennustettavuus

Muiden tärkeiden alueiden hyödyistä on vähän raportteja ja lisäksi on olemassa joukko laadullisia hyötyjä ohjelmistoprosessin parantamisesta, jotka ovat tunnistettavissa mutta vaikeasti mitattavissa. Koulutus ja muut henkilöstö voimavaroihin kohdistetut ponnistelut luovat osaamiseen syvyyttä ja laaja-alaisuutta. Tältä alueelta ei ole raportoitu suoraan ohjelmistoprosessin parantamisen aikaansaamista hyödyistä. Asiakastyytyväisyys on mitattavaa, mutta raportteja siitä miten prosessin parantamistoimenpiteet ovat siihen vaikuttaneet ei yleisesti ole saatavilla. Useimmat suurimmat ohjelmistoprosessin parantamisen hyödyt ovat ihmisiin liittyviä eikä niitä voida ilmaista euroina. Niitä saattavat olla: työtyytyväisyys, työntekijän ylpeys työstään, eksperttiyden lisääntyminen ja yrityksen kasvanut maine osaajana. (Krasner 1997)

Krasnerin raportti kokonaisuudessaan löytyy osoitteesta: http://www.utexas.edu/coe/sqi/newsletter/PDF/spi.pdf

• Tärkeimmät muutokset on aloitettava organisaation ylimmästä johdosta
• Keskity liiketoiminnan tavoitteisiin, jotka haluat saavuttaa käyttämällä prosessin parantamista keinona toteuttaa ne
• Sovella olemassa olevia parantamismalleja ja parhaita käytäntöjä omaan tilanteesi (SPICE)
• Prosessin nykytilan ymmärtäminen on ensimmäinen askel (Prosessin arviointi)
• Korjaa prosessia, älä ihmisiä
• Muutos on jatkuvaa
• Parantaminen vaatii investointeja (yrityksen tulevaisuuteen)
• Älä odota näkeväsi ihmeitä heti
• Jatkuvan paranemisen ylläpito edellyttää sen tukemista aika ajoittain

FiSMA, Finnish Software Metrics Association: ISO 15504: Software Process Improvement and Capability Determination. Internett WWW-sivu, URL: http://www.sttf.fi/html/level1_spicefin.html. (22.4.2001).

ISO/IEC -15504-1 1998. Information Technology - Software Process Assesment - Part 1: A Concepts and Introductory Guide. International Organisation for Standardisation (Ed.). CH-1211 Geneva, Switzerland, Casa Postale 56.

ISO/IEC -15504-2 1998. Information Technology - Software Process Assesment - Part 2: A Reference Model For Processes and Process Capability. International Organisation for Standardisation (Ed.). CH-1211 Geneva, Switzerland, Casa Postale 56.

ISO/IEC -15504-5 1998. Information Technology - Software Process Assesment - Part 3: Performing an assessment. International Organisation for Standardisation (Ed.). CH-1211 Geneva, Switzerland, Casa Postale 56.

ISO/IEC -15504-5 1998. Information Technology - Software Process Assesment - Part 5: An Assesment model and indicator guidance. International Organisation for Standardisation (Ed.). CH-1211 Geneva, Switzerland, Casa Postale 56.

ISO/IEC -15504-5 1998. Information Technology - Software Process Assesment - Part 5: Guide for use in process improvement. International Organisation for Standardisation (Ed.). CH-1211 Geneva, Switzerland, Casa Postale 56.

ISO/IEC -15504-5 1998. Information Technology - Software Process Assesment - Part 8: Guide for use in determining supplier process capability. International Organisation for Standardisation (Ed.). CH-1211 Geneva, Switzerland, Casa Postale 56.

Krasner, Herb: Accumulation the Body of Evidence for The Payoff of Software Process Improvement - 1997. WWW-sivu, URL: http://www.utexas.edu/coe/sqi/newsletter/PDF/spi.pdf (22.4.2001).

Känsälä, Kari: ProHAKE - kohti ohjelmistotuotannon parempaa hallintaa WWW-sivu, URL: http://www.pcuf.fi/sytyke/kirj/st953/prohaka1.htm

Wiegers, Karl E.: Why Is Process Improvement So Hard? WWW-sivu, URL: http://www.processimpact.com/articles/spi_so_hard.html (22.4.2001).