Ohjelmistotyön tuottavuus

HETKY, ATK-TOIMINNAN TUOTTAVUUDEN LISÄÄMINEN
Seurahuone 1.12.83
Lauri Gröhn / Telenokia Oy

TUOTTAVUUSSTRATEGIAT

The organization ACTS, and then learns from what it has done. It experiments, it makes mistakes, it finds unanticipated success — and new strategic direction inexorably emerges.
We believe that the truly adaptive organization evolves in a very Darwinian way. The company is trying lots of things, making the right sorts of mistakes; that is to say, it is fostering its own mutations. /4/

LÄHTÖKOHTIA

Viitekehys kerää yhteen ne asiat, joita tarkasteltavan asian yhteydessä pidetään tärkeinä. Tietotekniikan viitekehykseen pitää voida sijoittaa mm. kaupallishallinnollinen atk, prosessi-atk ja tieteellistekninen atk, tekstinkäsittely jne. Tällä hetkellä tällaista kehikkoa ei ole olemassa. Tämä vaikeuttaa esityksen rajaamista.

Tietoliikenteen ja hajautuksen merkityksen kasvaminen ja toisaalta atk-osastojen uudelleen organisoituminen (esimerkkeinä Rosenlewin ja Enson tapaukset) johtaa ilmeisesti atk-osastojen roolin muuttumiseen. Esille nousevat järjestelmäarkkitehtuurit ja tekninen osaaminen.

Työvoiman puute aiheuttaa yhä enemmän tarvetta panostaa ohjelmistotyön tuottavuuteen ja sen tärkeään osatekijään — laatuun. Monet yritykset ovat heränneet luomaan tuottavuusstrategioitaan. Ilman ohjelmistotyöhön liittyviä kustannusmalleja ei strategioiden suunnittelussa koskaan voida päästä alkua pitemmälle.

Ostaja tarkoittaa laadulla tyypillisesti käyttökelpoisuutta ja luotettavuutta, valmistajalle on tärkeää myös toiminnan laatu. Seuraavassa keskitytään toiminnan laatuun eli siis pääasiassa tuottavuuteen.

COCOMO—KUSTANNUSMALLI

Ohjelmistotyössä arviointeihin kohdistuvat yllätykset aiheuttavat lisäkustannuksia eli joko

A. lisäresurssien tarvetta tai
B. laatutavoitteista tinkimistä

Yksi keino yllätysten välttämiseksi on kustannusmallien käyttö. Kustannusmallit lähtevät oletuksista, jotka esitetään eksplisiittisesti. Tällöin on mahdollista arvioida kustannuslaskelmien lähtökohtia, eikä tarvitse tyytyä hatusta vedettyjen lukujen tai mahdollisesti vanhentuneiden tilastojen käyttöön sellaisenaan.

COCOMO on yksi parhaista malleista, joiden avulla voidaan arvioida ohjelmistotyön määriä, aikatauluja, kuormituksia ja eri resurssitarpeita. Malli kiteyttää kaavoihinsa ja taulukoihinsa valtavan määrän kokemusperäistä tietoa /1/. Tärkeitä lisänäkemyksiä on esittänyt DeMarco /3/.

COCOMO kiteyttää nimenomaan sen, miten ohjelmistotyötä tehdään USA:ssa TRW—yhtymässä. Suomen olosuhteet ja kunkin yrityksen erityispiirteet edellyttävät, että malli kalibroidaan uudelleen riittävän tarkkuuden saavuttamiseksi.

Malli perustuu vaihejakoon (kritiikistä huolimatta). Jokaisen vaiheen sisällä on aktiviteetteja, joiden oikeat painotukset voidaan mallin avulla laskea.

Itse asiassa COCOMO on joukko hierarkkisia malleja. Syötteinä on ohjelmiston koko, moodi (esim. upotettu systeemi) ja arvot (”rasti ruutuun”) viidelletoista attribuutille, jotka kuuluvat neljään luokkaan:

A. tuote
B. tietokone
C. henkilöstö
D. projekti

Attribuuttien avulla saadaan laskettua eräänlainen teknologiakerroin, johon perustuen resurssiarvioihin voidaan saada kertalukueroja.

Tulosteina saadaan työmääräarvioita, optimiaikataulut, aktiviteettien painotukset eri vaiheiden sisällä jne. Työmääräarvioille luvataan yrityskohtaisen kalibroinnin jälkeen tarkkuudeksi vähintään 20 % todennäköisyydellä 68%.

Malli pitää itsestäänselvyytenä, että kehitystyön johto ja asiakas ovat tehtäviensä tasalla, koska näillä tekijöillä on erittäin suuri vaikutus kustannuksien syntyyn. Malli olettaa myös, etteivät spesifikaatiot muutu olennaisesti tai ainakin että ne kehittyvät kumulatiivisesti.

TUOTTAVUUTEEN VAIKUTTAVIA TEKIJÖITÄ

Seuraavassa esitetään joltakin COCOMO-mallin esittämiä tosiasioita lähtien tilanteesta USA/TRW. TRW:ssä tekee ohjelmistotyötä yli 5000 henkeä.

Suurissa projekteissa sulautettujen järjestelmien ohjelmistotyön tuottavuus on noin 1/3 vastaavan kokoisten kaupallishallinnollisten projektien tuottavuudesta.

Sulautettujen järjestelmien ohjelmistotyössä on pienten projektien (alle vuosi) tuottavuus keskimäärin 2,5-kertainen verrattuna suuriin projekteihin (useita kymmeniä miestyövuosia).

Mallin antamien työmäärien oletusarvot voidaan joskus joutua muuttamaan 7-kertaisiksi erilaisten korjaustekijöiden vaikutuksesta. Joskus korjauskerroin on luokkaa 0.3 eli vaihtelut voivat olla 20-kertaisia.

Ei siis ihme, että perinteinen projektimenettely, jossa työt pilkotaan muutaman viikon tehtäviksi, on lievästi sanottuna kyseenalainen lähestymistapa isojen ohjelmistoprojektien tapauksessa.

Ohjelmistotyön kustannusmallista voidaan johtaa paino— arvot tuottavuuteen vaikuttaville tekijöille, taulukko 1. Osaan tekijöistä on melkoiset mahdollisuudet päästä vaikuttamaan yritystasolla.

Taulukko 1. /1/

1.2 ohjelmointikielen käyttötaito
1.2 aikataulun kireys
1.2 tietokannan koko
1.3 työsuoritusten läpimenoaika
1.4 virtuaalisen koneen tuntemus
1.5 virtuaalisen koneen muuttuvuus
1.5 ohjelmistotyöskentely-ympäristö
1.5 modernien menetelmien käyttö
1.6 muistitilavaatimukset
1.6 sovellutusalueen tuntemus
1.7 suoritusnopeusvaatimukset
1.9 haluttu luotettavuus
2.0 ohjelmoijien kommunikointitaidot
2.1 systeemisuunnittelijoiden kommunikointitaidot
2.4 tuotteen monimutkaisuus

Taulukon mukaan ihmisten kyky toimia toistensa kanssa on ehdottomasti tärkein tuottavuuteen vaikuttava tekijä. Menetelmät ja työympäristöt ovat myös merkittäviä tuottavuustekijöitä. Mallien avulla voidaan arvioida näiden panos/hyöty-suhteita. COCOMO:n perusteella (USA/TRW-kalibrointi) ihmisten kouluttamiseen kannattaisi käyttää hyvinkin 10 prosenttia työajasta. Realistinen palkkahaitari ohjelmistotyön tekijöille voisi olla 6000-30000 markkaa.

ERÄS TUOTTAVUUSSTRATEGIA

Yrityksen tuottavuusstrategiaa luotaessa on ensin arvioitava lähtötilanne. Tällöin laaditaan taulukko, josta ilmenee, missä yritys on nyt eli tuottavuus-attribuuttien nykyiset arvot ja missä yritys haluaa olla esim. vuonna 85 eli attribuuttien tulevat arvot.

Tuottavuusstrategiaa kehitettäessä joudutaan kustannusmallin attribuutteja karsimaan. Toisaalta on tekijöitä, jotka on otettava mukaan. Tällaisia ovat mm.

– spesifikaatioiden muuttuvuus
– ohjelmiston uudelleenkäytettävyys.

Kustannusmallin apuneuvoja soveltaen asetetaan tavoitteita 4-5 vuoden jaksoille pyrkien optimoimaan eri attribuuteista aiheutuvia kustannuksia. On suhteellisen helppo arvioida, paljonko tietyn tasoinen ohjelmistotyöskentely-ympäristö (laitteet ja ohjelmistot) tulee maksamaan ja kustannusmallin avulla voidaan arvioida, paljonko tuottavuus lisääntyy.

TRW:n tuottavuusstrategia on esitetty taulukossa 2. Taulukosta voidaan päätellä, että TRW pyrkii neljässä vuodessa lisäämään tuottavuuttaan yli 3-kertaiseksi.

Taulukko 2. /1/

Tuottavuustekijä

Tuottavuuden lisäys 81-85

Työkalut

Menetelmät

Vasteajat

Systeemisuunnittelijoiden kommunikointitaidot

Ohjelmoijien kommunikointitaidot

Virtuaalisen koneen muuttumattomuus

Määrittelyjen pysyvyys

Ohjelmien uudelleenkäyttö

12 %20 %

12 %

14 %

17 %

12 %

18 %

29 %

Kunkin tekijän prosenttiluku kuva tavoiteltua tuottavuuden lisäystä, kun muut tekijät pidetään vakiona. Kokonaisvaikutus tuottavuuteen syntyy osavaikutusten tulona.

Taulukosta voidaan päätellä ainakin, että TRW panostaa voimakkaasti ihmisiin ja heidän kykyihinsä toimia toistensa kanssa. Kannattaa vielä uudelleen korostaa, että prosenttiluvut eivät ole hurskaita toivomuksia, vaan perustuvat:

– kustannusmalliin
– selvään arvioon lähtötilanteesta, joka tietyillä alueella on jo hyvä
– selvään näkemykseen mahdollisuuksisata (kustannusmallien antamien kokemusten viisastuttamana)

LAATUUN VAIKUTTAVIA SEIKKOJA

Laatu on yksi tuottavuuden osatekijöistä. Laadun kannalta on mielenkiintoista se, että ylläpitokustannuksia arvioitaessa saa luotettavuus-attribuutti suuren arvon ( kustannukset suuria), jos kehitysvaiheessa luotettavuusvaatimuksista on tingitty. Myös kehitysvaiheen puutteelliset menetelmät johtavat ennalta arvioitavissa oleviin lisäkustannuksiin.

Mielenkiintoisimpia kustannusmallin esiintuomia seikkoja löytyy kuvasta 1. Siinä esitetään työmäärien riippuvuus aikataulun kireydestä.

Kuva 1.

COCOMO—mallin mukaan on olemassa optimiaika (ja miehitys) projektin läpiviemiselle. Kuva ilmentää politiikkaa, jossa projektia voidaan nopeuttaa ainoastaan 25 %. Kustannukset (= resurssit) tietysti lisääntyvät. Jos resursseja lisätään tästä, aikataulu rupeaakin venymään. Vertaa Brooksin lakiin!

Yksi näkökulma laatuun ja tuottavuuteen liittyy päätetyöskentelyyn. Laadun kannalta saattaa olla ongelmallista ”pääte-joka-huoneeseen”-mentaliteetti, joka voi johtaa yritys-erehdys tyyppiseen työskentelytapaan. Boehm /1/ viittaa eräisiin lähteisiin, joiden mukaan:

– Tuottavuus on sitä suurempi, mitä kauempana pääte on ohjelmoijan työhuoneesta.
– Tuottavuus paranee, jos päätetyöskentely estetään sopivaksi ajaksi jokaisen käännöskierroksen jälkeen.
– En pitänyt siitä, että pääte lukittiin tietyksi ajaksi, mutta se antoi minulle mahdollisuuden myös ajatella.”

Edellisen perusteella voisi esittää väitteen:

TYÖASEMIEN KAUPPAAJAT MYYVÄT TUOTTAVUUTTA JA LAATUA, MUTTA VIIME KÄDESSÄ LOPPUTULOS RIIPPUU KÄYTTÄJÄSTÄ.

TILANNE SUOMESSA

Eräiden mielestä tuottavuusasiat ovat hyvin, etenkin pankkimaailmassa, eikä asiaa tarvitse tutkia. Toisille nykyisten tuottavuusmallien taustalla piilevä vaihejako, ”josta on luovuttu tai josta pitäisi luopua”, on este asiaan perehtymiselle. Tai sitten väitetään, että tuottavuus paranee, kun keksitään sellainen korkeantason kieli, jolla ohjelmoinnin lisäksi voidaan myös spesifioida ja suunnitella.

Joillekin ohjelmistotyöskentely-ympäristöt ovat tuottavuuden viimeinen sana. Kuitenkin hallinnon rationalisoijat ovat oppineet, että automatisointi auttaa vain rutiiniasioissa. Myös toimistoautomaatio ihmiset ovat päätymässä samaan.

Monet uskovat menetelmiin, vaikka käytössä olevat menetelmät ovat vain kuvausmenetelmiä, eikä luovan suunnittelun salaisuuksia ole vielä selvitetty. Eräät vannovat termeillä bottom—up ja top—down. Toiset toimivat outside—in, inside—out tai most—critical—component—first. JSP, SUM tai ISAC on vienyt monien sielun. Amerikkalaisen profeetan mukaan rakenteelliset menetelmät puolestaan pelastavat vain pieniä projekteja /2/.

Eräs maahantuojayritys mainostaa: ”James Martin, atk-alan kuuluisin futurologi, ennustaa X:ään tutustuttuaan sillä voitavan saavuttaa jopa 1000 %:n tuottavuuden kasvu sovelluskehityksessä.” Hienoa sinänsä, mutta kyse on pelkästään käyttäjien sovelluskehittimen avulla generoimista standardiratkaisuista.

Kyseinen amerikkalainen yritys, jonka tuotetta kaupataan, teki sovelluskehittimen kehitystyötä sangen alkeellisin välinein — tuottamattomasti. Systeemityöhön voi myös liittyä todellista ohjelmistotyötä, mutta aina ei. Tällöin ei tarvita ohjelmistotyön ammattilaisiakaan.

Kustannusten arvioinnin yhtenä vaikeutena on, ettei yleispätevää menetelmää ole, vaan on tyydyttävä metamenetelmiin, jotka lähtökohtana on mahdollista luoda yrityskohtainen arviointijärjestelmä. Arviointi- järjestelmät sellaisenaan eivät ole siirrettäviä, vaikka niitä hyväuskoisille standardiratkaisuina kaupitellaankin.

Ohjelmistotyön kustannusten arviointijärjestelmän luominen edellyttää todellisten kustannusten mittaamisjärjestelmää ja tämä puolestaan laadunmittausjärjestelmää. Tähän kaikkeen tarvitaan ohjelmistoprojektin vetäjistä riippumatonta ryhmää, jonka työtä pitää puolestaan mitata arvioinnin laatumittareilla. Maksaako vai eikö maksaa? Maksaako tänään vähän vai huomenna paljon?

TUOTTAVUUS JA TULEVAISUUS

Ohjelmistotyön tuottavuuden teoreettisten perusteiden selvittämisessä yksi suuntaus on kognitiivinen psykologia, jonka piirissä tutkitaan miten ihminen ottaa vastaan, tallentaa ja käyttää tietoa. Tällä sektorilla on tutkijoilla vielä paljon työtä edessään.

Toistaiseksi tuottavuuden kehittämisessä joudutaan tyytymään fenomenologisiin malleihin, jotka ovat kulttuuri- ja yrityssidonnaisia. COCOMO-malli edellyttää yrityskohtaisen kalibroinnin suorittamiseksi systemaattista määrätyn formaatin mukaista tiedonkeruuta usean vuoden ajalta, riittävän monista projekteista tai osaprojekteista. Luotettava ohjelmistotyön tuottavuusstrategia voidaan laatia vasta kalibroinnin jälkeen.

Ohjelmistotuotteiden laadun teoreettisten tarkastelujen perustana saattaa olla systeemiteoria. Mielen kiintoisia osa-alueita ovat hierarkioiden teoria, mallinnettavuus jne. Käytännössä joudutaan tyytymään fenomenologisella tasolla erilaisiin ohjelmistotekniikkoihin, joiden hyödyllisyyttä on vaikea vertailla ilman kustannusmalleja.

Kokemukset tällä alueella ovat osoittaneet ainakin kaksi seikkaa:

1. Menetelmien käyttöönotto sinänsä ei ole ihmelääke, jonka avulla kuka tahansa voisi tehdä laadukasta ohjelmistotyötä. Menetelmät täytyy ensin kunnolla oppia, osaaminen ratkaisee, ei itse tekniikka. Osaamiseen auttaa viimekädessä käytännön työ ja riittävän asiantunteva monipuolinen ohjaus.

2. Tekniikoiden ja menetelmien valinta riippuu siitä mitä, missä, miten ohjelmistotyötä tehdään, kuka tekee jne. Eli lähtökohtana tulee olla jokin ohjelmistotyön taksonomia.

Usein puhutaan neljänlaisesta tiedosta:

A. Pseudotieto
B. Rekisteröivä tieto
C. Selittävä ja yhdistelevä tieto
D. Oivaltava tieto

Tuottavuudesta tietomme harvoin yltävät oivaltavan tiedon tasolle. Laatualueella tilanne on huonompi ja luotettavuusasiat ovat rekisteröinnin tasolla. On hämmästyttävää, että näillä tietotekniikan ydin alueilla olemme ainakin toistaiseksi tiedon alimmilla tasoilla. Tietoyhteiskunnan perimmäiseen olemukseen pitäisi kuulua selittävän ja oivaltavan tiedon valta-asema rekisteröivään ja pseudotietoon verrattuna

VIITTEET

/1/ BOEHM, Barry: Software Engineering Economics. Prentice—Hall, 1981.
/2/ FOX, Joseph: Software and Its Development. Prentice—Hall, 1983.
/3/ DeMARCO, Tom: Controlling Software Projects – Management, Measurements & Estimation. Yourdon Press 1982.
/4/ PETERS, WATERMAN: In Search of Excellence. Harper & Row 1983.

LISÄÄ TUOTTAVUUDESTA JA LAADUSTA

GRÖHN, Lauri:

Laatutyö ei saa olla liturgiaa. Insinööriuutiset 27.k.1982.
Käytännön laatutyöstä tietokoneohjelmistojen alueella. Laatu— ja standardisointipäivät 26.-28.4.1982, Turku.
Ohjelmistojen laatu ja ohjelmistotyön tuottavuus. Blanko—82, Oulu.
Ohjelmien katselmusten teoria ja käytäntö. Elektroniikka ja automaatio 21/82.
Ohjelmien katselmukset käytännössä. Elektroniikka ja automaatio 1/83.
Software Engineering Meta-Environment for Electronics Industry. Nordic Workshop On Research Directions in Advanced Software Environments, Linköping 15iL83
Ohjelmistotyön viitekehys elektroniikkateollisuudessa. Elektroniikka ja automaatio 6/83.
Ohjelmistotyön kaksi kulttuuria. Elektroniikka ja automaatio 10/83.
Ohjelmistotyön tuottavuus. Elektroniikka ja automaatio 11—12/83.
SCM, kustannukset ja tuottavuus. Inskon kurssi “Ohjelmistotuotteen hallinta (SCM)” Aulanko 6.—9.9.1983.
Tuottavuus ja laatu ohjelmistotyössä. ELKOM—83 elektronhikkapäivät, Helsinki 2.-4-11-83

grohn

Asun Nauvossa, Bryssel 97-04 Tutkinto: teoreettinen fysiikka. Työura: Yliopisto, iltaoppikoulu, Ollituote, Kone, Telefenno, Telenokia, Tekes 84-97, yrittäjä Bryssel, Euroopan komissio (mm, km). Yrittäjä 05-17. Rakensin kotona tietokoneen 76. Skepsis ry:n siht. 91-92, pj. 93. Kehitin 1997 (Psion) ja 2001-2015 (pc/mac) ohjelman, joka muuttaa valokuvat musiikiksi: http://www.synestesia.com/cd05/2005.html

Ilmoita asiaton viesti

Kiitos!

Ilmoitus asiattomasta sisällöstä on vastaanotettu