5. tarkoittaa niitä toimintoja, jotka tehdään ohjelmalle sen käyttöönoton jälkeen. on kallein työvaihe. Glassin mukaan 40-80% kustannuksista kuluu siihen. Kumma kyllä tätä ei ole listattu ylläpidon laeissa. Täten ylläpito on ohjelmiston elinkaaren tärkein työvaihe! Ylläpidon merkitys Ylläpidon merkitys on kasvanut vakaasti viimeiset 30 vuotta. Syy tähän on laitteiston ja ohjelmistojen välisten suhteiden muutoksessa. Alussa laitteet olivat kalliita ja ohjelmistot halpoja (pieniä). Nyt tilanne on kääntynyt toisin päin. 1 2 Ylläpidon osa-alueet Ylläpidon lakien suhde ohjelmistotuotantoon Oppikirjassa ylläpito jaetaan kolmeen osaan: Hoitoylläpidolla (administration) pidetään huolta ohjelmiston käytöstä. Evoluutioylläpidolla (evolution) muokataan ohjelmistoa vastaamaan muuttuneisiin vaatimuksiin. Korjausylläpidolla (maintenance) korjataan julkaisun jälkeen löytyneet ohjelmistoviat. Seuraavassa ovat oppikirjassa esitellyt ylläpidon lait ja niiden suhde ylläpidon osa-alueisiin ja ohjelmistotuotantoon: Lehmanin ensimmäinen laki: evoluutioylläpito. Lehmanin toinen laki: evoluutioylläpito. Lehmanin kolmas laki: evoluutioylläpito. Basili-Möllerin laki: testaus, korjausylläpito, evoluutioylläpito. 3 4 Ylläpidon lakien suhde ohjelmistotuotantoon 2 Ylläpidon lakien suhde ohjelmistotuotantoon 3 McCaben hypoteesi: korjausylläpito. Wilden hypoteesi: korjausylläpito. Konjunktuuri 5 (ei käsitellä): hoitoylläpito. Konjunktuuri 6 (ei käsitellä): hoitoylläpito, korjausylläpito. (Konjunktuurit 1-4 liittyvät järjestelmien käyttöönottoon, joka ei kuulu kurssin sisältöön.) Ylläpidon lakeja hallitsee suvereenisti Lehman. Hänen empiiriset tuloksensa ylläpidosta on aiheen perustutkimusta. Itse asiassa Lehman määritteli viisi ylläpidon lakia, mutta oppikirjaan lait on tiivistetty kolmeen. Myös Basili-Möllerin laki on erittäin merkittävä eikä edes rajoitu ylläpitoon. 5 6 1
5.1. Lehmanin ensimmäinen laki Käytössä olevat järjestelmät muuttuvat. Lehmanin ensimmäinen laki on ylläpidon tunnetuin laki. Sitä voidaan käyttää perusteluna evoluutioylläpidolle. Lain mukaan järjestelmän käyttö johtaa vääjäämättömästi järjestelmään tehtäviin muutoksiin. Käyttö muutos on ohjelmistojen keskeinen ominaisuus. 7 Lehmanin ensimmäisen lain taustaa Jokainen ei-triviaali jatkuvassa käytössä oleva ohjelmisto vaatii muutoksia. Vaatimukset muuttuvat ohjelmiston elinkaaren aikana. Kilpailijoiden tuotteisiin tulee uusia ominaisuuksia, joten myös omaan tuotteisiin tarvitaan lisäpotkua. Yleensä muutokset tarkoittavat ohjelmiston koon kasvua. 8 Lehmanin ensimmäisen lain perusteluja Lehman ja Belady tutkivat 1970-1975 OS/360 käyttöjärjestelmän julkaistuja versioita. Yhteensä julkaisuja oli 25. Tutkimuksen muakaan järjestelmän koko kasvoi tutkimusaikana kahdeksankertaiseksi: 1MLOC 8MLOC. Vastaavia tuloksia on saatu myös muiden käyttöohjelmistojen kasvusta. 9 Lehmanin ensimmäisen lain teoria Käytössä olevien ohjelmistojen muutospaineisiin on monia syitä: Ohjelmistossa on ollut keinotekoisia rajoitteita, jotka ovat vanhentuneet elinkaaren aikana. Ominaisuuksia on jäänyt toteuttamatta kehitystyövaiheessa. Ohjelmistoliiketoiminnan kilpailu vaatii uusia ohjelmistojen ominaisuuksia. 10 5.2. Lehmanin toinen laki Lehmanin toisen lain taustaa Kehittyvä järjestelmä tulee ajan kanssa entistä kompleksisemmaksi ellei kehitystä vastaan tehdä työtä. Lehmanin toinen laki on lähes yhtä tunnettu kuin Lehmanin ensimmäinen laki, mutta ei yhtä laajalti hyväksytty. Laki muistuttaa meitä siitä, että muutokset heijastuvat laajemmalle alueelle kuin vain muokkausta kaipaavaan osaan koodia. 11 Lehmanin ensimmäinen laki käsitteli ohjelmistojen kasvua. Toinen laki käsittelee kasvun vaikutuksia. Järjestelmä kasvaa, kun siihen lisätään uusia ominaisuuksia, poistetaan vanhoja rajoituksia ja sovitetaan järjestelmä uusille sovellusalueille. Jokainen muutos rikkoo hiukan ohjelman alkuperäistä rakennetta. 12 2
Lehmanin toisen lain taustaa 2 Itse puhun luennoijana kursseillani kriittisestä massasta: Ohjelman kriittinen massa on se koko, minkä jälkeen jokainen muutos rikkoo siitä jotain muuta. Lehmanin toisen lain mukaan ajan kanssa ohjelman kriittinen massa pienenee, ellei asialle tehdä jotain. Kriittisen massan kasvatus vaatii työtä. 13 Lehmanin toisen lain taustaa 3 Lehmanin toinen laki on voimassa, kun valmiiseen ohjelmistoon lisätään vaiheittain ominaisuuksia. Näin laki pätee myös lisäävissä prosessimalleissa. Niissä valmiiseen ohjelmistoon ytimeen lisätään uutta toiminnallisuutta. Lisäävissä malleissa koodin pitäminen siistinä vaatii siten lisätyötä. 14 Lehmanin toisen lain perusteluja Lehmanin toisen lain teoria Oppikirjan perustelut laille ovat enemmän laadullisia kuin eksakteja. Lehman itse pitää lakiaan analogisena termodynamiikan toiselle laille siis entropialle. Dvorak puolestaan tutki 1994 Lehmanin lakia käytännössä. Hän huomasi, että päivitykset tosiaan muuttivat ohjelmistoissa käytettyjä ratkaisuja. 15 Jokainen ohjelmistoon tehtävä muutos vaikuttaa tavalla tai toisella ohjelmiston rakenteeseen. Ohjelmisto ei enää täysin vastaa alkuperäistä dokumentaatiota. Koska ohjelmistoa ei voida suunnitella uudestaan ja refaktoroida jokaisen muutoksen jälkeen, muutokset kertyvät ajan kanssa. Näin laatu kärsii. 16 5.3. Lehmanin kolmas laki Lehmanin kolmannen lain taustaa Järjestelmän kehityskulku määräytyy (liiketoiminnan) palauteprosessin mukaan. Lehmanin kolmas laki on yhdistelmä kolmesta laista. Näin oppikirjan kirjoittajat ovat saaneet tehtyä laista alkuperäistä yleisemmän. Lain mukaan ohjelmiston kehitys riippuu siitä, minkä tyyppistä liiketoimintaa sillä tehdään. 17 Lehmanin kolmas laki ei ole yhtä vahvasti hyväksytty kuin aiemmat lait (joista toisestakin on jo vastaväitteitä). Ajatuksena Lehmanilla on, että ohjelmiston ominaisuudet määräytyvät pääasiassa kilpailun ja asiakkaiden toiveiden mukaan. Näin asiakkaalta ja liiketoiminnasta saatu palaute määrää tuotteen piirteet. 18 3
Lehmanin kolmannen lain perusteluja Lehman perustelee lakinsa tutkimukseen OS/360-käyttöjärjestelmästä. Lehman huomasi, että OS/360- päivitykset liittyivät erityisen voimakkaasti laitteistopäivityksiin. Näin Lehmanin johtopäätös oli, että OS/360:n tapauksessa laitteistotoimittajat vaikuttivat ohjelmiston ominaisuuksiin. 19 Lehmanin kolmannen lain perusteluja 2 Vaikka Lehmanin perusteluja on vaikea yleistää OS/360:n ulkopuolelle, itse laissa on järkeä. Kaupallisen ohjelmiston tarkoituksena on tuottaa voittoa. Tämä onnistuu pitämällä asiakkaat tyytyväisinä. Näin ollen asiakkaiden palaute on ehkä voimakkain tulokseen vaikuttava syöte. 20 Lehmanin kolmannen lain teoria 5.4. Basili-Möllerin laki Lehmanilla on aika voimakas käsitys palautteen vaikutuksesta ohjelmistoihin. Hänen mukaansa ohjelmistojen ominaisuudet ovat seurausta vuorovaikutuksesta ja palautteesta. Oppikirjan kirjoittajien mukaan useilla järjestelmillä on niin paljon vapausasteita, että Lehmanin kolmas laki ei päde niille. 21 Pienillä muutoksilla on suuria muutoksia korkeampi virhetiheys. Basili-Möllerin laki tarjoaa tärkeän näkökulman ylläpitoon. Se kertoo, että ylläpidossa on oltava tarkkana erityisesti pienten muutosten kanssa. Optimaalisinta olisi tehdä vain suuria muutoksia, mutta luonnollisesti myös pienet virheet pitää korjata sitä mukaa, kun niitä löydetään. 22 Basili-Möllerin lain taustaa Basili-Möllerin lain perusteluja Basili-Möllerin lain sanoma on, että ohjelmistoon tehdyt pienet muutokset ovat kaikkein kriittisimpiä. Tällaisilla muutoksilla virhetiheys (virheitä / koodirivi) on kaikkein suurin. Luonnollisesti isoissa päivityksessä syntyy lukumääräisesti enemmän virheitä. Tämä ei ole ristiriidassa Basili- Möllerin lain kanssa. 23 Basili-Möllerin laki on oikeastaan kaksi eri lakia: Basilin laki ja Möllerin laki. Molemmat tutkivat toisistaan riippumattomasti samaa asiaa. Basili ja Perricone tutkivat 1984 NASAn Fortranilla tehtyihin muutoksiin tehtyjä muutoksia. Möller tutki 1985 Siemensin BS/2000- käyttöjärjestelmään tehtyjä muutoksia. 24 4
Basili-Möllerin lain perusteluja 2 Basili-Möllerin lain perusteluja 3 Basili ja Perricone analysoivat tutkimuksessaan 215 testauksessa ja ylläpidossa kolmen vuoden aikana löydettyä virhettä. Virheiden sijoittumisessa moduuleihin päti Pareto-Zipfin laki: virheitä löytyi vain 26% moduuleista. Seuraavalla kalvolla ovat Basilin ja Perriconen tutkimuksen tulokset. 25 Moduulin koko 50 100 150 200 >200 Kaikkien moduulien kompleksius 6,0 19,6 27,5 56,7 77,5 Virheellisten moduulien kompleksius 6,2 17,9 28,1 52,7 60,0 Virheitä / KLOC 65,0 33,0 24,6 13,4 9,7 26 Basili-Möllerin lain perusteluja 4 Basili-Möllerin lain teoria Myös Möller sai omassa tutkimuksessaan samansuuntaisia tuloksia. Lisäksi Selby sai 1988 tekemässään ohjelmistojen uudelleenkäytön tutkimuksessa teoriaa tukevia tuloksia. Näin ollen Basili-Möllerin laki on validoitu kohtuullisen kattavasti. 27 Basili-Möllerin laki perustuu Simonin lakiin hierarkkisista rakenteista. Pienissä korjauksissa hierarkiaa rikotaan suhteessa enemmän kuin suurissa korjauksissa. Molemmissa nimittäin tarvitaan tietoa ja viittauksia vanhaan ympärillä olevaan koodiin. Näin pienet korjaukset ovat suhteellisesti suuria korjauksia riskialttiimpia. 28 5.5. McCaben hypoteesi Monimuotoisuusmetriikat (complexity metrics) ovat hyviä tuotteen luotettavuuden ja ylläpidettävyyden mittareita. Monimuotoisuusmetriikka tarkoittaa ohjelmasta laskettavaa sen rakenteen monimutkaisuuden ilmaisevaa lukuarvoa. McCaben hypoteesin mukaan sopivat metriikat ennustavat ylläpidon helppouden. McCaben hypoteesin taustaa Parhaiten tunnettu monimuotoisuusmetriikka perustuu McCaben kehittämään syklomaattiseen monimuotoisuuteen (cyclomatic complexity). Mittari kuvaa tietyn ohjelman osan alusta loppuun menevien riippumattomien polkujen määrää. 29 30 5
McCaben hypoteesin taustaa 2 McCaben hypoteesin perusteluja Riippumaton polku on jokin sellainen reitti ohjelman osan alusta sen loppuun, jota ei saada lineaarisena kombinaationa muista vastaavista poluista. Yleensä McCaben monimuotoisuusmittaa käytetään metodeihin. Tällöin mittari antaa riippumattomiin polkuihin perustuvan kattavuuskriteerin. 31 McCaben hypoteesi tarjoaisi toteutuessaan kätevän keinon arvioida ylläpidon kustannuksia: mitä pienempi syklinen monimuotoisuus, sitä helpompaa pitäisi ylläpidon olla. McCaben hypoteesia on yritetty validoida varsin huonolla menestyksellä. 32 McCaben hypoteesin perusteluja 2 McCaben hypoteesin perusteluja 3 Niodusch tutki 1983, mten DOS/VSEkäyttöjärjestelmästä havaitut virheet korreloivat McCaben mittarin lukemien kanssa. Yllättäen tuloksena oli, että mittaria paremmin virheiden määrää korreloi koodirivien määrä. Toisin sanottuna monimutkaiset rakenteet eivät olleet juurikaan sen yksinkertaisia rakenteita virheherkempiä 33 Nioduschin lisäksi Basilin ja Perriconen aineistosta (Basili-Möllerin laki) voidaan laskea vastaavat arvot. Tulokset ovat samansuuntaiset Nioduschin kanssa. Samoin Fentonin ja Ohlssonin vuonna 2000 tehdyssä kokeessa havaittiin, että McCaben metriikka ei ole sen parempi virhetiheyden ennustaja kuin mitä koodirivien määrä on. 34 5.6. Wilden hypoteesi Wilden hypoteesin taustaa Oliopohjaisten ohjelmistojen ylläpito on vaikeaa. Oliopohjaisuus ei pääty kehitystyön päättymiseen, vaan sitä tarvitaan yhtä lailla ylläpidossa. Norman Wilde esitti 1993, että kehitystyössä oliopohjaisuudella saavutettava hyöty häviää ainakin osittain ylläpitovaiheessa. 35 Kuten sanottu, ylläpidon osuus kaikista kustannuksista on 40-80%. Tämä tarkoittaa, että säästöt/resurssien tuhlaus näkyvät erityisesti ylläpitovaiheessa. Kuitenkin suurin osa oliopohjaisuustutkimuksista käsittelee oliopohjaisia menetelmiä nimenomaan kehitystyön apuvälineinä. 36 6
Wilden hypoteesiin perusteluja Wilden hypoteesin perusteluja 2 Wilde ei validoi hypoteesiaan empiirisin kokein. Sen sijaan hän perustelee väitteensä oliopohjaisten ohjelmien ominaisuuksilla. Wilden mukaan oliopohjaisia ohjelmia on vaikea ymmmärtää, koska niissä yleensä on paljon pieniä metodeita, joiden suhdetta on vaikea ymmärtää. Samoin perintä tuottaa ongelmia. 37 Daly teki 1996 kokeen, jossa hän tutki, miten perintä vaikuttaa ylläpitoon. Hänen kokeessaan kaksi oppilasryhmää piti yllä 400 rivin C++-ohjelmia. Toisen ryhmän ohjelmassa oli kolmitasoinen perintähierarkia. Toisen ryhmän ohjelmassa ei ollut perintää. Toisessa kokeessa käytettiin lisäksi viisitasoista perintähierarkiaa. 38 Wilden hypoteesin perusteluja 3 Wilden hypoteesin perusteluja 4 Dalyn tulokset olivat seuraavat: Matala vs. ei perintää ylläpitoaika: perinnällä selvästi pienempi ylläpitoaika. Syvä vs. ei perintää ylläpitoaika: ilman perintää hiukan pienempi ylläpitoaika. Unger toisti kokeen 1998. Hänen tuloksissaan sekä matala että syvä perintä vaativat litteää rakennetta enemmän ylläpitoa ja olivat myös tätä virhealttiimpia. 39 Daly ja Unger saivat siis kokeistaan eri tulokset. Oppikirjan mukaan tulosten ero selittyy sillä, miten Dalyn kokeessa oppilaat suorittivat ylläpitotehtävät. Kirjoittajien mukaan Dalyn kokeessa perintähierarkiaa käytettiin ylläpidon mallina. Oppikirjasta ei selviä, miksi tämän pitäisi olla paha asia! 40 Esiteltyjen lakien seurauksia Esiteltyjen lakien seurauksia 2 Ylläpidon lait voidaan tiivistää seuraavaksi yleiseksi tulokseksi: vaihe vaatii paljon työtä, huomattavaa tarkkuutta ja korjausten ja päivitysten lisäksi koodin uudelleenmuokkausta (refaktorointia). Lehmanin lait ja Basili-Möllerin laki johtavat tähän samaan tulokseen. Myös Wilden hypoteesi viittaa samaan. Toinen tulos voidaan päätellä Wilden hypoteesista, vaikka sitä ei ole validoitu kunnolla: Kehitystyön menetelmiä käytettäessä ei pidä ajatella pelkästään kehitystyön vaatimia piirteitä vaan myös ylläpidettävyyttä. Toisin sanottuna jokaisen vähänkään vaikeamman ratkaisun kohdalla kannattaa miettiä, miten se vaikuttaa ylläpitoon. 41 42 7