1. Johdanto Building software will always be hard. There is inherently no silver bullet. F. Brooks, 1987. Ohjelmisto- ja järjestelmätekniikka (software engineering, software systems engineering) määrittelevät, miten tietokonepohjaisia järjestelmiä (systems) ja niiden ohjelmistoja (software) tulisi toteuttaa. Ohjelmistojen tekeminen on riittävän vaikeaa, ilman että toistetaan jo todettuja virheitä ja keksitään samat asiat moneen kertaan. Empiirinen ohjelmistotutkimus 1 Empiirinen ohjelmistotutkimus 40 vuoden aikana ohjelmistotekniikassa on löydetty paljon käytännössä toimivia periaatteita: ns hyviksi havaittuja menetelmiä (best practices). Empiirisen ohjelmistotutkimuksen (Empirical software engineering, EOT) tavoitteena on validoida (varmentaa), millä reunaehdoilla käytetyt menetelmät toimivat. Empiirinen ohjelmistotutkimus 2 Empiirisen tutkimuksen perusta EOT kuten kaikki empiirinen tutkimus perustuu havaintoihin, (luonnon)lakeihin ja teorioihin. Yleensä havainnoista johdetaan laki, joka yleistetään teoriaksi. Jos (uudet) havainnot eivät sovi teoriaan, teoriaa täydennetään. Tällöin vanha teoria voi olla uuden teorian erikoistapaus. Empiirinen ohjelmistotutkimus 3 Havainnot, laki, teoria Havainnot ovat aistiemme antamia syötteitä. Ne voivat olla subjektiivisia tai objektiivisia. Kun jonkun ilmiön havainnoilla on jokin tunnistettu toistuva tekijä, saadaan laki. Laki on yleistys, jonka avulla voidaan ennustaa tulevia havaintoja. Laki selittää, miten jokin tapahtuu, mutta ei kerro miksi. Teoria selittää, miksi laki toimii. Empiirinen ohjelmistotutkimus 4 Havainto-laki-teoria Järjestelmällinen havainnointi 1 Havainto Ennustaa Toistuu samanlaisina Laki Selittää Teoria Varmentaa Havainnointi pitää saada sellaiseksi, että sen avulla saatuja tuloksia voidaan analysoida ja yleistää laeiksi ja teorioiksi Projektin tärkein tehtävä on saada tehtäväksi annettu tuotos valmiiksi. Sivutuotteena saadaan myös uutta tietoa. Projekteista kerätystä mittaustiedosta voidaan vetää yleisempiä johtopäätöksiä vastaavien projektien toiminnasta. Kyselytutkimuksessa (survey) käytetään lomakkeita ja haastatteluja kerättäessä tietoja halutusta ilmiöstä. Tulokseksi saadaan mielipiteitä, joita voidaan käyttää täydentämään muuta tutkimusta. Empiirinen ohjelmistotutkimus 5 Empiirinen ohjelmistotutkimus 6 Taina 1
Järjestelmällinen havainnointi 2 Tapaustutkimuksessa (case study) projektia tarkkaillaan ulkopuolelta keräämällä siitä tutkimuksen kannalta mielenkiintoista tietoa. Tutkittuun ilmiöön liittyvät tekijät luokitellaan etukäteen ja projektin aikana tekijöihin liittyvät havainnot ja toiminta dokumentoidaan. Ohjatussa kokeessa (controlled experiment) osallistujat valitaan satunnaisesti kahteen tai useampaan valvottuun ryhmään. Koe tehdään laboratorio-olosuhteissa, jossa yhtä ominaisuutta lukuun ottamatta samanlaiset ryhmät tekevät toisistaan riippumattomasti kokeessa vaadittavat tehtävät. Kokeen kannalta mielenkiintoisen ominaisuuden arvot vaihtelevat ryhmittäin. Havainnointimenetelmien heikkoudet Projektien tehtävä on tuottaa haluttu lopputulos, ei tuottaa uutta tietoa. Tulokset voivat olla turhia. Kyselytutkimuksella saadaan mielipiteitä, jotka yleensä eivät ole totuuksia. Tapaustutkimuksissa tutkimuksen kohteeseen ei vaikuteta, joten kohde saattaa ajautua tutkimuksen kannalta yhdentekevään suuntaan. Ohjatut kokeet ovat kalliita, joten niitä voidaan harvoin tehdä todellisessa ympäristössä. Ei ole selvää, miten hyvin laboratorioympäristössä saadut tulokset ovat yleistettävissä. Empiirinen ohjelmistotutkimus 7 Empiirinen ohjelmistotutkimus 8 Lait, hypoteesit ja teoreemat Laki (law): Empiirisin kokein validoitu sääntö, joka sopii reunaehdoilla useimpiin havaintoihin. Hypoteesi (hypothesis): Alustavasti hyväksytty ehdotus, joka tarjoaa hyödyllisen havaintoja tukevan näkökulman; toistaiseksi ei validoitu. Teoreema (theorem): Täsmällinen laki, jonka täytyy sopia kaikkiin havaintoihin. Empiirinen ohjelmistotutkimus 9 Empiirisen ohjelmistotutkimuksen lait EOT:n lait eivät ole yhtä vahvoja kuin fysiikan lait. Ne ovat luonteeltaan lähempänä taloustieteen lakeja. EOT:n lait eivät ole eksakteja (siis teoreemoja), sillä ne eivät päde aina. Kun laki pätee riittävän usein ja riittävän yleisin reunaehdoin, sitä voidaan käyttää teorian pohjana. Edellä riittävä on määrittelykysymys. Mitä vaan havaintoihin edes hiukan sopivaa voidaan kutsua laiksi, mutta kaikki tällaiset lait eivät kestä aikaa ja epäsopivien havaintojen hyökkäyksiä. Empiirinen ohjelmistotutkimus 10 Teoriat Teoria on selitys syistä, miksi jokin laki on voimassa. Teoria on voimassa juuri niin kauan kuin se pystyy selittämään laista tehdyt havainnot. Kun havainnot ovat ristiriidassa teorian kanssa, teoriaa täytyy täydentää tai korvata se paremmalla teorialla. EOT ja ohjelmistotekniikka Seuraavissa luvuissa esiteltävät lait ja hypoteesit auttavat ymmärtämään ohjelmistotekniikan perusteita. Hyväksytyt teoriat auttaisivat vielä enemmän, sillä niiden avulla voitaisiin johtaa uusia lakeja. Valitettavasti EOT:n teorioita on vähän ja lakien tulkinnat ovat kiistanalaisia. Empiirinen ohjelmistotutkimus 11 Empiirinen ohjelmistotutkimus 12 Taina 2
2. Vaatimusmäärittely Vaatimusmäärittely on ensimmäinen projektin osavaihe. Sitä pidetään myös tärkeimpänä vaiheena. Miksi? Ehkä seuraavat lait selittävät asiaa: Glass: Puutteelliset vaatimukset ovat todennäköisin epäonnistuneen projektin syy. Boehm: Vaatimusmäärittelyn ja suunnittelun virheiden korjaus on sitä kalliimpaa, mitä myöhemmin niitä yritetään korjata. Lisäksi (Glass, 2003): Glass: Puuttuvat vaatimukset ovat vaikeimmin havaittavia ja korjattavia virheitä. Empiirinen ohjelmistotutkimus 13 Vaatimusmäärittelyn validointi Vaatimusmäärittelystä on myös vaikeaa saada validoituja tuloksia, sillä vaatimusmäärittely on interaktiivista toimintaa, jota on vaikeaa tarkkailla ulkopuolelta häiritsemättä prosessia, ja vaatimusmäärittely on hankala prosessi, sillä kaikki helposti määriteltävät tuotteet on jo määritelty. Jokainen vaatimusmäärittelyprosessi on omalla tavallaan ainutkertainen. Empiirinen ohjelmistotutkimus 14 Vaatimusmäärittelyn lait Oppikirjassa esitellyt vaatimusmäärittelyn lait ja hypoteesit ovat luonteeltaan varoittavia. Ne voidaan tiivistää yhdeksi lauseeksi: Jos et ole tarkkana vaatimusmäärittelyssä, niin projektillesi voi käydä huonosti. Myös vaatimusmäärittelyn tekniikoita voitaisiin validoida, mutta toistaiseksi sellaista tutkimusta on vähän. Empiirinen ohjelmistotutkimus 15 Vaatimusmäärittelyn työvaiheet Vaatimusmäärittelyn työvaiheet ovat: 1. Vaatimusten kartoitus 2. Kartoitettujen vaatimusten analyysi 3. Vaatimusten tarkennus ja spesifiointi 4. Vaatimusten priorisointi 5. Sidosryhmien välisten konfliktien ratkonta 6. Vaatimusten validointi 7. Vaatimusten (dokumentin) hyväksyminen Vaiheet 1-6 toistuvat iteratiivisesti. Empiirinen ohjelmistotutkimus 16 Empiiristen tulosten ja työvaiheiden suhde Nyt esiteltävät vaatimusmäärittelyn empiiriset tulokset liittyvät seuraaviin työvaiheisiin: Glassin laki: Vaatimusten validointi Glassin hypoteesi: Vaatimusten kartoitus Boehmin 1. laki: Vaatimusten validointi Boehmin 2. laki: Vaatimusten validointi Davisin laki: Vaatimusten analyysi Boochin 1. hypoteesi: Vaatimusten kartoitus Empiirinen ohjelmistotutkimus 17 Empiiristen tulosten ja työvaiheiden suhde 2 Edellinen lista painottuu voimakkaasti vaatimusten kartoitukseen ja validointiin. Painottuminen on luonnollista, sillä kartoitus ja validointi ovat eräänlaisia vaatimusmäärittelyn tarkistuspisteitä: Kartoituksen jälkeen on jotain työstettävää. Analyysi, tarkennus, spesifiointi ja priorisointi tähtäävät kaikki samaan tavoitteeseen: vaatimusten validointiin. Empiirinen ohjelmistotutkimus 18 Taina 3
2.1. Glassin laki Puutteelliset vaatimukset ovat tärkein projektien epäonnistumisen syy. Robert Glass on eräs ohjelmistotekniikan suurista nimistä. Hänen lakinsa perustuu vaatimusmäärittelystä tehtyihin tapaustutkimuksiin. Vaikka suurin osa projekteista onnistuu, vielä on paljon parantamisen varaa. Glassin lain taustaa Kehno vaatimusmäärittely on vakava ongelma projekteille. Määrittelyongelmia syntyy, sillä usein vaatimusten kartoitus tehdään huonosti, vaatimuksia ei määritellä riittävän tarkasti, vaatimuksia ei ymmärretä oikein, vaatimuksia ei osata tarkentaa ja vaatimukset muuttuvat projektin aikana. Empiirinen ohjelmistotutkimus 19 Empiirinen ohjelmistotutkimus 20 Glassin lain taustaa 2 Tavallisin vaatimusmäärittelyn virhe on epätäydellinen tai virheellinen määrittely. Erityisesti ongelmia syntyy, jos projektin vaatimusmäärittely on ulkoistettu jollekin kolmannelle osapuolelle. Vaatimusmäärittelyyn vaaditaan sekä tarkkuutta että verifiointia, jotta ongelmat havaitaan ja korjataan ajoissa. Empiirinen ohjelmistotutkimus 21 Glassin lain perusteluja Glass perustaa tuloksensa tapaustutkimuksiin. Tällaista lakia ei oikein voi validoida muilla keinoilla. Glassin havaintoja epäonnistuneista projekteista: Liikaa vaatimuksia. Myöhään ilmenneitä muuttuvia vaatimuksia. Moniselitteisiä vaatimuksia. Epätäydellisiä vaatimuksia. Empiirinen ohjelmistotutkimus 22 Glassin lain teoria Vaatimusten määrittely on vaikeaa. Sidosryhmien tarpeet eroavat toisistaan. Vaatimusten priorisointi ei aina onnistu. Vaatimusmäärittely on oppimista ja neuvottelua. Työvaihe vaatii paljon sekä sidosryhmiltä että projektiryhmältä. Osallistujat eivät tiedä kaikkea, unohtavat, eivät osaa jakaa tietojaan jne. Asiakkaat eivät osaa ilmaista vaatimuksia. Empiirinen ohjelmistotutkimus 23 2.2. Glassin hypoteesi Puuttuvat vaatimukset ovat vaikeimmat havaita ja korjata. Tätä ei ole listattu oppikirjassa, mutta se on esitelty Glassin omassa kirjassa R. Glass, Facts and Fallacies of Software Engineering. Addison-Wesley, 2003. Glass listaa tämän kohdan fakta alle, mutta kurssin terminologialla tämä on hypoteesi. Empiirinen ohjelmistotutkimus 24 Taina 4
Glassin hypoteesin taustaa Vaatimusten kartoitus on ratkaistavan ongelman määrittelyä, johon tarvitaan yhteistyötä sidosryhmien edustajien kanssa. Yleensä tämä tarkoittaa sidosryhmien edustajien haastatteluja. Mitä enemmän mukana on inhimillisiä tekijöitä, sitä virhealttiimpaa on toiminta. Tulokset voivat olla sekä moniselitteisiä että vaikeasti kuvattavia: virhealttiita. Empiirinen ohjelmistotutkimus 25 Glassin hypoteesin taustaa 2 Myös vaatimusten mallinnus ja tulkinta ovat virhealttiita työvaiheita. Käyttäjävaatimuksia ei yleensä saada sellaisella tarkkuudella, että niistä voitaisiin suoraan johtaa malli. Järjestelmävaatimuksia varten tarvitaan käyttäjävaatimusten analyysia. Vajailla tiedoilla toimittaessa analyysi voi epäonnistua pahemman kerran. Empiirinen ohjelmistotutkimus 26 Glassin hypoteesin taustaa 3 Kun kaksi virhealtista prosessia yhdistetään, saadaan erityisen virhealtis prosessi. Kaikkia tuotteen vaatimuksia ei löydetä. Toisaalta tuotteen järjestelmätestaus perustuu tunnettuihin vaatimuksiin. Jos jokin vaatimus puuttuu, sitä ei ehkä osata kaivata. Pahimmillaan puuttuva vaatimus huomataan vasta tuotantokäytössä. Empiirinen ohjelmistotutkimus 27 Glassin hypoteesin perusteluja Glass perustaa hypoteesinsa sekä loogiseen päättelyyn että tuotantoon asti päässeiden virheiden analyysiin. Hän huomasi, että sitkeimmät virheet olivat puuttuvan logiikan virheet, kuten puuttuva haarauma koodissa. Miksi haaraumat puuttuvat? Koska niitä ei ole suunniteltu. Miksi? Koska ei ole ollut vaatimusta, joka olisi vaatinut ne. Empiirinen ohjelmistotutkimus 28 2.3. Boehmin ensimmäinen laki Virheitä syntyy eniten vaatimusmäärittely- ja suunnitteluvaiheessa. Mitä myöhemmin nämä virheet löytyvät, sitä kalliimmaksi niiden korjaaminen tulee. Boehmin ensimmäinen laki selittää, missä työvaiheessa virheet ylipäänsä ilmaantuvat. Laki voidaan varmentaa luokittelemalla löydetyt virheet ja arvioimalla kunkin virheen korjauskustannus. Empiirinen ohjelmistotutkimus 29 Boehmin ensimmäisen lain taustaa 1970-luvulla havaittiin, että suurin osa tuotteiden virheistä tulevat projektien elinkaaren alussa: suunnittelussa ja vaatimusmäärittelyssä. Molemmissa työvaiheissa tulee paljon virheitä, mutta vakavimmat virheet tehdään vaatimusmäärittelyssä. Pahimmillaan virheet havaitaan vasta asennettaessa ohjelmaa asiakkaalle. Empiirinen ohjelmistotutkimus 30 Taina 5
Boehmin ensimmäisen lain taustaa 2 Mitä kauemmin menee virheen teosta sen korjaamiseen, sitä kalliimmaksi sen korjaaminen loppujen lopuksi tulee. Seuraus: Virheen korjaamisen kalleuden määrää virheen elinikä. Kalleimmat virheet tulevat projektin alussa: vaatimusten kartoituksessa ja analyysissa. Seuraus 2: Jos voimme varmistaa, että virheet löytyvät nopeasti, voimme sallia useampia virheitä työvaiheisiin. Empiirinen ohjelmistotutkimus 31 Boehmin ensimmäisen lain perusteluja Boehm perustaa lakinsa 1974 TRW:lla (amerikkalainen monialayritys) tehtyyn tutkimukseen. Tutkimuksessa analysoitiin 224 virhettä. 64% virheistä liittyi suunnitteluun (ja vaatimusmäärittelyyn). Hyväksymistestauksessa suhde oli 45:9. 1975 Endres sai vastaavasti tuloksen: 60-70% kaikista projektin aikana löydetyistä virheistä on vaatimusmäärittely- tai suunnitteluvirheitä. Empiirinen ohjelmistotutkimus 32 Boehmin ensimmäisen lain teoria Miksi vaatimusmäärittelyn ja suunnittelun virheet ovat yleisimmät? Koska näissä työvaiheissa pitäisi hallita ongelma hyvin erilaisilla abstraktioilla kokonaisuudesta osiin ja oikeasta toiminnasta poikkeustilanteisiin. Miksi vaatimusmäärittelyn ja suunnittelun virheet ovat kalleimmat korjata? Koska unohdettu virhe synnyttää tulevissa työvaiheissa uusia virheitä. Empiirinen ohjelmistotutkimus 33 2.4. Boehmin toinen laki Prototyyppien käyttö vähentää merkittävästi erityisesti käyttöliittymien vaatimusmäärittelyn ja suunnittelun virheitä. Prototyyppejä on käytetty jo vuosikymmeniä vaatimusmäärittelyn apuvälineinä. Samoin protojen vaikutusta vaatimusmäärittelyyn on tutkittu paljon. Toisin kuin edelliset lait, Boehm validoi väitteensä ohjatulla kokeella. Empiirinen ohjelmistotutkimus 34 Boehmin toisen lain taustaa Laki on intuitiivisesti selkeä: Prototyypit kaventavat määrittelyn ja toteutuksen välistä kuilua. Kuva puhuu enemmän kuin tuhat sanaa. Proto puhuu enemmän kuin tuhat kuvaa. Prototyyppiä on helpompi ymmärtää kuin pelkkiä kirjattuja vaatimuksia. Prototyypit vähentävät sekä sidosryhmien keskinäisiä että sidosryhmien ja projektiryhmän välisiä epäselvyyksiä. Empiirinen ohjelmistotutkimus 35 Boehmin toisen lain perusteluja Boehmin toinen laki perustuu ohjattuun kokeeseen: Boehm käytti seitsemää ryhmää, joista neljässä käytettiin normaalia vaatimusmäärittelyä ilman prototyyppejä ja kolmessa käytettiin prototyyppejä. Kokeessa käytettiin maisteritason opiskelijoita, joiden tehtävänä oli kehittää interaktiivinen versio COCOMO-malliin perustuvasta prosessin arviointityökalusta. Empiirinen ohjelmistotutkimus 36 Taina 6
Boehmin toisen lain perusteluja 2 Kokeen tulokset olivat seuraavat: Prototyyppiryhmien tulokset olivat kooltaan hiukan pienemmät (samaa toiminnallisuutta kohden tuli vähemmän koodia). Molempien ryhmien tehokkuus oli suurin piirtein samaa luokkaa (isoa hajontaa). Prototyyppiryhmät tuottivat helppokäyttöisempiä ja helpommin opittavia järjestelmiä. Protoryhmien tuotteissa oli toisaalta vähemmän toimintoja. Empiirinen ohjelmistotutkimus 37 Boehmin toisen lain perusteluja 3 Vaikka Boehmin kokeen tulokset eivät ole kovin kummoisia, myöhemmät tutkimukset ovat vahvistaneet tuloksia. Prototyyppien käyttö vähentää ylimääräisten ominaisuuksien määrää tuotteissa. Bernstein esittää 1993 tehdyssä tutkimuksessa, että prototyypit vähentävät jopa 40% työmäärää. Vaarojakin on: asiakkaat saattavat ihastua liikaa protojen ominaisuuksiin. Empiirinen ohjelmistotutkimus 38 Boehmin toisen lain teoria Vaatimusmäärittelyn pahimpia ongelmia on moniselitteisyys. Mitä useampi sidosryhmä on riippuvainen tuotteesta, sitä varmempaa on, että syntyy väärinkäsityksiä. Prorotyypit vähentävät moniselitteisyyttä, sillä ne näyttävät sidosryhmille tuotteen lähes sellaisena kuin se tulee lopulta olemaan. Empiirinen ohjelmistotutkimus 39 2.5. Davisin laki Mallin hyöty riippuu valitusta näkökulmasta, mutta yksikään malli ei ole paras kaikkiin tarkoituksiin. Malleja käytetään kuvaamaan todellista tai suunniteltua järjestelmää, joskus myös käyttötapauksia tai vaatimuksia. Mallien arvo on sama kuin prototyyppien: ne vähentävät moniselitteisyyttä. Davisin lain mukaan vaatimusmäärittelyssä tarvitaan useita rinnakkaisia malleja. Empiirinen ohjelmistotutkimus 40 Davisin lain taustaa Mallinnus on osoittautunut erinomaiseksi keinoksi esittää järjestelmän toimintaa. Esimerkiksi vaatimusmäärittelyssä käytetään seuraavia malleja: Tietomallit: Luokkakaaviot Prosessimallit: Tietovuokaaviot Tilasiirtymät: Tilasiirtymäkaaviot Rakenteet: Oliokaaviot Toiminta: Sekvenssikaaviot Käyttötapaukset: Käyttötapauskaaviot Empiirinen ohjelmistotutkimus 41 Davisin lain taustaa 2 Jokainen kaaviotekniikka esittää näkymän mallinnettuun järjestelmään. Jokainen näkymä antaa jotain tietoa järjestelmästä ja piilottaa jotain muuta tietoa. Malli abstrahoi järjestelmää. Davisin mukaan ei ole olemassa sellaista mallia, joka parempana korvaisi kaikki toiset mallit. Sellainen malli ei piilottaisi järjestelmästä mitään tietoja, eli se olisi itse järjestelmä. Empiirinen ohjelmistotutkimus 42 Taina 7
Davisin lain perusteluja Davisin lain perusteluja 2 Davis perusti tuloksensa subjektiiviseen päättelyyn. Hän esitteli kolme toisistaan selvästi eroavaa järjestelmää, ja kokeili näiden vaatimusmäärittelyyn joukkoa mallinnuskeinoja. Järjestelmät olivat: Kirjamyymälän puoliautomaattinen järjestelmä Automatisoitu helikopterin laskeutumisjärjestelmä Järjestelmä siirtämään ihmisiä 30 minuutissa New Yorkista Tokioon. Empiirinen ohjelmistotutkimus 43 Ensimmäisen järjestelmän kohdalla voitiin Davisin mukaan käyttää hyvin eri tyyppisiä mallinnuskeinoja, jotka kaikki tuottivat hyödyllisiä mutta erilaisia tuloksia. Toisen järjestelmän ja varsinkin kolmannen järjestelmän kohdalla mallien hyöty oli pieni verrattuna järjestelmän määrittelyongelmiin. Ongelman määrittelyyn vaaditaan syvällistä tietoa käyttöympäristöstä. Pelkät mallit eivät siihen riitä. Empiirinen ohjelmistotutkimus 44 Davisin lain validointi Davisin perustelut ovat kevyet, mutta tulos on validi. Tulosta voitaisiin varmentaa lisää ohjatulla kokeella: Jaetaan ensin kokeeseen osallistujat sopivan kokoisiin ryhmiin. Puolet ryhmistä saa tehtäväksi tehdä vaatimusmäärittelyn käyttämällä ennalta valitsemaansa kuvaustekniikkaa. Loput saavat käyttää mitä tahansa kuvaustekniikoita. Empiirinen ohjelmistotutkimus 45 Davisin lain validointi 2 Ryhmien vaatimusmäärittelyjä vertaamalla, ja varsinkin jos ryhmät laitetaan tekemään prototyyppi, saataisiin toivottavasti vastauksia seuraaviin kysymyksiin: Miten ryhmien vaatimukset erosivat toisistaan? Miten kehitettävien järjestelmien toiminnallisuus erosi toisestaan? Miten syvällisen kuvan kehitettävästä tuotteesta ryhmät saivat? Miten tyytyväinen asiakas oli kehitettyihin prototyyppeihin? Empiirinen ohjelmistotutkimus 46 Davisin lain teoria Kokonaisuuden rakentaminen isosta joukosta yksityiskohtia on vaikeaa (kokeile esimerkiksi koota 10.000 palan palapeli.) Malli on kohteen yksinkertaistus. Sen avulla koko järjestelmästä saadaan helpommin hallittava yleistetty näkymä. Tarvitaan useita näkymiä, usea eri abstraktiotasolla oleva malli, kuvaamaan koko järjestelmä. Empiirinen ohjelmistotutkimus 47 2.6. Boochin ensimmäinen hypoteesi Oliomallinnus vähentää analyytikkojen ja käyttäjien välisiä kommunikaatio-ongelmia. Oliomallinnuksen hyvistä puolista on kirjoitettu hyllymetreittäin tekstiä. Viime vuosina oliomallinnus on tullut ohjelmointikielten ja suunnittelun kautta myös vaatimusmäärittelyyn. Boochin mukaan suuntauksen pitäisi helpottaa vaatimusten kartoitusta. Empiirinen ohjelmistotutkimus 48 Taina 8
Boochin ensimmäisen hypoteesin taustaa Sekä vaatimusmäärittelyssä että suunnittelussa oliomallinnus kuvaa, miten kehitettävä järjestelmä jakautuu eri kokoisiin moduuleihin: osajärjestelmiin, komponentteihin ja luokkiin; ja miten moduulit kommunikoivat keskenään. Intuitiivisesti ositus helpottaa ymmärtämistä, sillä kokonaisuuden sijaan riittää käsitellä vain yhtä osaa. Empiirinen ohjelmistotutkimus 49 Boochin ensimmäisen hypoteesin taustaa 2 Oliomallinnuksesta pidetään, sillä se muistuttaa ihmisten tapaa käsitellä asioita kokonaisuuksina, sen katsotaan helpottavan siirtymistä vaatimuksista suunnittelun kautta toteutukseen, siinä tietoa ja sen käsittelyä ei eroteta toisistaan siinä käytetään hyväksi havaittuja olioparadigman periaatteita, kuten abstrahointia, kapselointia, modulaarisuutta, hierarkkisuutta, tyypitystä ja rinnakkaisuutta. Empiirinen ohjelmistotutkimus 50 Boochin ensimmäisen hypoteesin taustaa 3 Vaikka oliomallinnus voi olla myös vaatimusmäärittelyn työkalu, sen avulla voidaan pääasiassa kuvata tulevaa järjestelmää. Sen sijaan ei ole aivan selvää, auttaako oliomallinnus kartoittamaan vaatimuksia. Itse asiassa perinteinen ositus prosesseihin (toimintoihin) voi olla sidosryhmille oliomaailmaa selkeämpi. Empiirinen ohjelmistotutkimus 51 Boochin ensimmäisen hypoteesin perusteluja (tai tyrmäystä) Oppikirjassa esitellyt perustelut vaikuttavat hypoteesin vastaisilta: Oliopohjaisus ei helpota sidosryhmien ja projektiryhmän välistä kommunkaatiota. Oliopohjaisuudella ei löydetä perinteisiä tapoja tehokkaammin vaatimuksia. Toisaalta tulokset ovat yli kymmenen vuotta vanhoja. Menetelmät kehittyvät. Vähintään voidaan sanoa, että hypoteesin validoinnissa on vielä työtä. Empiirinen ohjelmistotutkimus 52 Esiteltyjen lakien seurauksia Vaatimusmäärittelylle pitää varata tarpeeksi aikaa ja resursseja. Vaatimusmäärittelyn tulee olla iteratiivista. Iteratiivisuus helpottaa havaitsemaan puuttuvia vaatimuksia, kun vaatimuksia voidaan kartoittaa hallittavissa pienissä osissa. Prototyyppejä kannattaa käyttää. Vaatimusten analysoinnissa kannattaa tehdä useita eri abstraktiotasoilla olevia malleja tulevasta järjestelmästä. Ketterien prosessimallien tapa kerätä vähän vaatimuksia kerrallaan lyhentää virheiden elinkaarta ja siten säästää testauskuluissa. Empiirinen ohjelmistotutkimus 53 Lakien ja hypoteesien vaikutus vaatimusmäärittelyyn Oppikirjan lait ja hypoteesit antavat varsin ohuen kuvan vaatimusmäärittelyn lainalaisuuksista. Tämä ei tarkoita, että vaatimusmäärittely on kaaos. Hyväksi havaittuja menetelmiä ei vain ole vielä varmennettu kunnolla. Vaatimusmäärittelyn lainalaisuuksien validoinnissa on vielä paljon tehtävää. Empiirinen ohjelmistotutkimus 54 Taina 9
3. Suunnittelu Suunnittelu on teknisesti kaikkein haastavin ja luonteeltaan kaikkein ristiriitaisin työvaihe. Miksi? Curtis: Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa. Dyer: Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Simon jne: Suosi modulaarisuutta. Empiirinen ohjelmistotutkimus 55 Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Curtis & Dyer: Hyvä suunnittelu vaatii laajaa kokemusta. Dyer, Simon, jne.: Suunnittelu alkaa vajaista korkean tason vaatimuksista ja päättyy toteutusläheiseen tulokseen. Suunnittelussa on siis käsiteltävä ongelmaa sekä vaatimusmäärittelyn että toteutuksen näkökulmasta. Lähes jokainen suunnitelma on ainutkertainen, koska kerran tehtyä ohjelmistoa ei kannata suunnitella uudestaan kuin poikkeustapauksissa. Empiirinen ohjelmistotutkimus 56 Suunnittelun lait ja hypoteesit Oppikirjassa esitellyt suunnittelun lait ja hypoteesit liittyvät hyvän suunnittelun ominaisuuksiin. Ne voidaan tiivistää näin: Hyvässä suunnittelussa sovellusalue ja käytetyt menetelmät hallitaan suvereenisti. Suunnittelun tulee olla modulaarista. Mitä vähemmän yhteyksiä suunniteltavien moduulien välillä on, sen parempi. Empiirinen ohjelmistotutkimus 57 Suunnittelun työvaiheet Suunnittelussa on yleensä ainakin seuraavat työvaiheet: 1. Arkkitehtuurisuunnittelu 2. Osajärjestelmäsuunnittelu 3. Komponenttisuunnittelu 4. Luokkasuunnittelu 5. Tietorakennesuunnittelu 6. Algoritmisuunnittelu 7. Käyttöliittymäsuunnittelu Empiirinen ohjelmistotutkimus 58 Empiiristen tulosten ja työvaiheiden suhde Curtisin laki: 1-7 Simonin laki: 1-4 Constantinen laki: 3-4 Parnasin laki: 1-5 Denertin laki (ei käsitellä): 1 Fitts-Shneidermanin laki (ei käsitellä): 7 Boochin 2. hypoteesi: 1-4 Bauer-Zemanekin hypoteesi: 1-6 Dyerin hypoteesi: 1-7 Gamman hypoteesi: 4-6 Empiiristen tulosten ja työvaiheiden suhde 2 Kuten edellisestä listasta näkyy, esiteltävät lait ja hypoteesit ovat yleisiä: ne sopivat lähes kaikkiin työvaiheisiin. Itse asiassa monet laeista eivät rajoitu ohjelmistotekniikkaan vaan pätevät myös muissa insinööritieteissä. Todella hyvä empiirinen laki on niin yleinen, että ympäristö ei rajoita sitä. Empiirinen ohjelmistotutkimus 59 Empiirinen ohjelmistotutkimus 60 Taina 10
3.1. Curtisin laki Curtisin lain taustaa Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa Curtisin laki perustuu erityisesti sotilasteollisuuden ohjelmistojen tarkkailuun mutta pätee mille tahansa sovellusalueelle. Curtisin laki on ehkä tärkein suunnittelun laki. Sen mukaan laadukkaan ohjelmiston suunnittelu ei onnistu, jos suunnittelijat eivät tunne ympäristöä, missä ohjelmistoa tullaan käyttämään. Empiirinen ohjelmistotutkimus 61 Hyvään suunnitteluun vaaditaan sekä tietoa että ymmärrystä ohjelmiston sovellusalueesta (problem domain). Sovellusalueet ja niille tehtävät ohjelmistot eroavat vahvasti toisistaan. Kaikkien alojen asiantuntijaa ei ole. Kaikille aloille sopivia ohjelmia ei ole. Koodaustaito ei takaa suunnittelutaitoa. Empiirinen ohjelmistotutkimus 62 Curtisin lain taustaa 2: suunnittelun vaativuus palvelut, käyttäjien toiminta, rajoitteet, poikkeukset, laitteet Sovellusalueen hallinta Kuvaus rakenteet, arkkitehtuurit, algoritmit, resurssit, tiedot Koodauksen hallinta Hyvään suunnitteluun vaaditaan molempien alueiden hyvää hallintaa. Empiirinen ohjelmistotutkimus 63 Curtisin lain taustaa 3 Suunnittelun ongelmana on, että suunnittelijoiden pitää olla sekä sovellusalueen että kehitystyön asiantuntijoita. Useimmiten näin ei ole. Yleisin lienee tapaus, missä suunnittelijat ovat vain kehitystyön asiantuntijoita. Toki voi myös olla, että suunnittelijat ovat vain sovellusalueen asiantuntijoita. Empiirinen ohjelmistotutkimus 64 Curtisin lain perusteluja Curtis perustaa tuloksensa 1986 tekemäänsä 17 projektia kattaneeseen haastattelututkimukseen. Hänen tuloksensa olivat: Vain harvalla projektien jäsenistä oli sovellusalueen tuntemusta. Useimmiten yksi tai kaksi eniten sovellusaluetta tuntevaa henkilöä ottivat päävastuun suunnittelusta. Empiirinen ohjelmistotutkimus 65 Curtisin lain perusteluja 2 Curtisin tulokset jatkuvat: Samat pari sovellusalueen tuntijaa informoivat muita projektin jäseniä arkkitehtuurista. Suunnittelukokousten tehtävänä oli muokata suunnitelma koko projektiryhmän yhteiseksi näkemykseksi tehtävästä tuotteesta. Johtopäätös: suunnittelu jätettiin suosiolla sovellusalueen asiantuntijoille. Empiirinen ohjelmistotutkimus 66 Taina 11
Curtisin lain teoria Teoria 1 (oppikirja): Suunnittelu on yksi tietämyksen sovellus. Osa tietämyksestä on piilotietämystä (tacit knowledge), joka on hienompi sana kokemukselle. Pelkkä kirjoitettu tieto ei riitä matkalla vaatimuksista suunnitteluun, vaan tarvitaan myös vankkaa sovellusalueen tuntemista ja kokemusta. Empiirinen ohjelmistotutkimus 67 Curtisin lain teoria 2 Teoria 2 (luennoija): Jos Dyerin hypoteesi on voimassa, suunnittelussa johdettavien vaatimusten määrä on jopa 50-kertainen verrattuna käyttäjävaatimuksiin. Suuri osa johdetuista vaatimuksista koskee ohjelmiston suhdetta sovellusalueeseen. Näitä ohjelmiston ja sovellusalueen välisiä vaatimuksia ei voida suunnitella ilman vahvoja taustatietoja sovellusalueesta. Empiirinen ohjelmistotutkimus 68 3.2. Simonin laki Hierarkkisuus vähentää kompleksisuutta. Simonin laki käy perusteluksi esimerkiksi suunnittelussa käytettyyn luokka komponentti osajärjestelmä jaotteluun. Simonin laki ei ole pelkkää ohjelmistotekniikkaa, vaan sama laki pätee kaikkeen suunnitteluun. Simonin laki on yksi yleisesti hyväksytyistä insinööritieteiden suunnittelun laeista. Empiirinen ohjelmistotutkimus 69 Simonin lain taustaa Hierarkkisuus tarkoittaa, että järjestelmä rakentuu osajärjestelmistä, jotka rakentuvat osajärjestelmistä jne. kunnes päädytään perusosiin. Kompleksisuuden väheneminen tarkoittaa, että järjestelmän ymmärtäminen ja sen toiminta vaativat entistä vähemmän työtä ja energiaa. Hierarkkisten järjestelmien hallinta ja ymmärtäminen on siten helpompaa kuin eihierarkkisten järjestelmien. Empiirinen ohjelmistotutkimus 70 Simonin lain perusteluja Simon perustaa lakinsa havaintoihin luonnosta. Hänen mukaansa luonnossa hierarkkiset järjestelmät kehittyvät nopeammin kuin ilman rakennetta olevat järjestelmät. Evoluutio suosii hierarkkisia järjestelmiä, sillä ne toipuvat paremmin häiriöistä. Sama pätee keinotekoisiin järjestelmiin myös ohjelmistotekniikassa. Empiirinen ohjelmistotutkimus 71 Simonin lain teoria Simonin laki vaikuttaa olevan luonnonlaki, jolle teorian kehittäminen olisi enemmän filosofiaa kuin EOT:ta. Simon itse toteaa: En tiedä, ymmärrämmekö maailmaa, koska se on hierarkkinen, vai näemmekö maailman hierarkkisena, koska emme ymmärrä emmekä osaa havaita sen hierarkian vastaisia rakenteita. Empiirinen ohjelmistotutkimus 72 Taina 12
3.3. Constantinen laki Rakenne on stabiili, jos sen yhtenäisyys on vahva ja kytkentäaste matala. Yhtenäisyys (cohesion, binding): miten sidoksissa moduulin (osajärjestelmän, komponentin, luokan) osat ovat toisiinsa. Kytkentäaste: (coupling): miten sidoksissa moduuli on muihin moduuleihin. Eli hyvä moduuli hoitaa omat hommansa mahdollisimman riippumattomasti muista. Empiirinen ohjelmistotutkimus 73 Constantinen lain taustaa Constantinen laki on sukua Simonin laille. Lain perusteella mitä paremmin järjestelmän osat tekevät omat tehtävänsä ja mitä vähemmän niillä on keskinäisiä yhteyksiä, sitä paremmin järjestelmä sietää häiriöitä. Yhtenäisyys ja kytkentäaste näkyvät selvästi esimerkiksi oliopohjaisessa suunnittelussa ja suunnittelumalleissa. Empiirinen ohjelmistotutkimus 74 Constantinen lain perusteluja Sekä yhtenäisyys että kytkentäaste voidaan määritellä matemaattisesti. Määritelmän avulla yhtenäisyyttä ja kytkentäastetta voidaan mitata ohjelmakoodista, joten Constantinen lain testaamiseen voidaan käyttää staattisia metriikoita. Näitä tutkimuksia on jo tehty (Cidamber & Kemerer 1994, Basili 1996, Briand 1998). Empiirinen ohjelmistotutkimus 75 Constantinen lain perusteluja 2 Tutkimusten oleellisia tuloksia: Vahva yhtenäisyysłvähän virheitä: Vahva vastaavuus. Korkea sisäinen kytkentäaste (olio kutsuu muita) Ł enemmän virheitä: Vahva vastaavuus. Korkea ulkoinen kytkentäaste (oliota kutsutaan) Ł enemmän virheitä: Heikko vastaavuus. Empiirinen ohjelmistotutkimus 76 Constantinen lain teoria Korkea yhtenäisyys tarkoittaa, että moduulissa ei ole mitään ylimääräistä. Matala kytkentäaste tarkoittaa, että moduulit voidaan paremmin eristää toisistaan ja järjestelmässä on vähemmän yhteyksiä. Molemmat pienentävät virhealttiutta ja helpottavat testausta (vrt. Simonin laki). 3.4. Parnasin laki Vain piilotettua tietoa voidaan muuttaa ilman riskiä. Parnasin laki on kapseloinnin perusta, ja siten yksi ohjelmistotekniikan tärkeimmistä laeista. Laki on myös kaiken modulaarisuuden perusta yhdessä Simonin lain kanssa. Parnasin laki pätee yleisemmin myös muissa insinööritieteissä. Empiirinen ohjelmistotutkimus 77 Empiirinen ohjelmistotutkimus 78 Taina 13
Parnasin lain taustaa Parnasin laki on varmaankin tunnetuin ohjelmistotekniikan laki. Kaikki käyttävät sitä ajattelematta asiaa sen kummemmin. Parnasin lakia voidaan soveltaa vaikkapa projektinhallinnassa: kaikkien ei tarvitse tietää yksityiskohtia kaikista työvaiheista, vaan työvaiheiden tulokset ratkaisevat. Empiirinen ohjelmistotutkimus 79 Parnasin lain perusteluja Parnas perustaa lakinsa tapaustutkimukseen, missä hän tarkkaili Philipsin insinöörien työskentelyä. Parnas havaitsi, että modularisointi oli tärkeä suunnittelumenetelmä, mutta sitä ymmärrettiin huonosti. Parnasin lain alkuperäiset perustelut ovat varsin kevyet, mutta sittemmin laki on osoittanut voimansa useissa projekteissa ja tapaustutkimuksissa. Empiirinen ohjelmistotutkimus 80 Parnasin lain teoria Parnasin lain teoria voidaan perustaa kahteen faktaan: Suunnittelussa on tärkeää, että päätöksiä voidaan lykätä eteenpäin ilman riskiä siitä, että niiden sivuvaikutukset heijastuvat jo tehtyyn suunnitteluun pilaten sen. Ihmisen käsitys- ja omaksumiskyky on rajallinen. Tehtävään vaadittavan tiedon rajoittaminen helpottaa tehtävän tekoa. 3.5. Boochin toinen hypoteesi Oliopohjaiset suunnitelmat vähentävät virheitä ja rohkaisevat uudelleenkäyttöön. Boochin toinen hypoteesi on sukua vaatimusmäärittelyssä esitellylle Boochin ensimmäiselle hypoteesille. Jos Boochin hypoteesit ovat valideja, olioparadigmaa kannattaa käyttää koko projektin ajan. Empiirinen ohjelmistotutkimus 81 Empiirinen ohjelmistotutkimus 82 Boochin toisen hypoteesin taustaa Oliomallinnuksen katsotaan parantavan erityisesti suunnittelun laatua. Malleina oliot ovat helpompia mallintamiaan luonnon kohteita kuin perinteisen ohjelmoinnin aliohjelmat. Boochin hypoteeseista huolimatta oliomallinnus ei ole mikään viisasten kivi, joka ratkaisee kaikki ongelmat. Boochin toisen hypoteesin perusteluja Oikein käytettynä oliomallinnus on mainio työkalu. Vaatimusmäärittelyn käyttötapauksista voidaan eristää eri tasoisia olioita. Vaatimusmäärittelyn oliot voidaan jalostaa suunnittelussa käytettäviksi olioiksi. Hierarkkiset rakenteet, yhtenäisyys & kytkentäaste ja kapselointi ovat mukana suunnittelun alusta alkaen. Empiirinen ohjelmistotutkimus 83 Empiirinen ohjelmistotutkimus 84 Taina 14
Boochin toisen hypoteesin perusteluja 2 Valitettavasti oliomallinnuksella on kääntöpuolensa. Oliomallinnus sallii myös virheherkkiä rakenteita, kuten perintä, kuormitus ja myöhäinen sidonta. Näistä on myös empiirisiä tuloksia: Syvä perintähierarkiałenemmän virheitä Erittäin vahva vastaavuus. Paljon perillisiäłenemmän virheitä Vahva vastaavuus. Metodien korvausłenemmän virheitä Vahva vastaavuus. Empiirinen ohjelmistotutkimus 85 Boochin toisen hypoteesin perusteluja 3 Ei ole sattumaa, että Boochin toinen hypoteesi ei ole laki. Se ei toimi riittävän yleisillä ehdoilla. Sen sijaan on selvää, että oikein käytettynä oliomallinnus on oiva työkalu. Se sisältää aiemmista laeista saadut hyvät tulokset hierarkkisista rakenteista, kapseloinnista, yhtenäisyydestä ja kytkentäasteesta. Empiirinen ohjelmistotutkimus 86 3.6. Bauer-Zemanekin hypoteesi Formaalit menetelmät vähentävät merkittävästi suunnitteluvirheitä tai jopa eliminoivat ne aikaisin. Vaikka ohjelmistotekniikka ei perustu matematiikkaan, jotkut ohjelmistotekniikan alueet (esim. lasilaatikkotestaus) on voitu formalisoida matemaattisin menetelmin. B-Z:n hypoteesin mukaan matemaattinen formalismi sopii hyvin myös suunnitteluun. Empiirinen ohjelmistotutkimus 87 Bauer-Zemanekin hypoteesin taustaa Formaalit menetelmät perustuvat johonkin matemaattiseen formalismiin, jonka avulla jokin ratkaisu voidaan todistaa oikeaksi. Formalismin avulla voidaan kirjoittaa ongelman määrittely, todistaa määrittelystä ominaisuuksia, tehdä määrittelyyn perustuva ratkaisu, todistaa ratkaisu matemaattisesti oikeaksi. Empiirinen ohjelmistotutkimus 88 Bauer-Zemanekin hypoteesin taustaa 2 B-Z:n hypoteesille on paljon kannatusta, sillä matemaattista formalismia pidetään perimmäisenä suunnittelun ratkaisuna. Kannattaa kuitenkin huomata, että kaikkia ongelmia ei voida formuloida, formalismin ymmärtäminen ja varsinkin uuden formalismin kehittäminen vaatii vankkaa matemaattista taustaa, formalismin päivittäminen on vaikeaa. Empiirinen ohjelmistotutkimus 89 Bauer-Zemanekin hypoteesin perusteluja B-Z:n hypotesi on eräs eniten kiistellyistä EOT:n alueista. Aiheesta on tehty lukuisia tapaustutkimuksia, mutta tulokset ovat olleet ristiriitaisia. Hallin tutkimuksessa 1990 keskikokoisen projektin (58 KLOC) formaali määrittely paransi suunnittelua ja nopeutti virheiden löytymistä. Tuotteesta ei tarvittu luonnollisella kielellä tehtyä normaalia määrittelyä. Empiirinen ohjelmistotutkimus 90 Taina 15
Bauer-Zemanekin hypoteesin perusteluja 2 Hayesin tutkimuksessa 1985 CICSjärjestelmän (Customer Information Control System) ohjelmoijan manuaali määriteltiin uudestaan formaalilla kielellä. Määrittelyssä manuaalista löydettiin useita puutteita ja epäjohdonmukaisuuksia, jotka johtivat muutamien CICS-järjestelmän osien kirjoittamiseen uudestaan. Projektin tuloksena raportoitiin 60% virhevähennys ja 5,5 miljoonan dollarin kustannussäästö. Empiirinen ohjelmistotutkimus 91 Bauer-Zemanekin hypoteesin perusteluja 3 Vaikka tulokset ovat vakuuttavia, niiden yleistäminen isompaan projektijoukkoon ei ole itsestään selvää: Kyseessä oli lähinnä dokumentointi- ja ylläpitoprojekti, mikä pitää ottaa huomion tulosten analyysissa. Koko projekti kesti kaiken kaikkiaan 12 vuotta! Joka tapauksessa projekti on yksi eniten viitatuista formaalien menetelmien käytettävyystutkimuksista ja vahva osoitus siitä, että parhaimmillaan formaalit menetelmät ovat erittäin hyödyllisiä. Empiirinen ohjelmistotutkimus 92 Bauer-Zemanekin hypoteesin perusteluja 4 Pfleegerin ja Hattonin tutkimuksessa 1997 seurattiin noin 200 KLOC kokoisen C- kielisen ohjelman tekoa. Merkittäviä osia ohjelmasta määriteltiin formaalisti. Pfleeger ja Hatton mittasivat tuotteen osien virhetiheyttä sekä projektin aikana että tuotantokäytössä. Bauer-Zemanekin hypoteesin perusteluja 5 Pfleegerin ja Hattonin tulokset olivat: Projektin aikana: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 19,6 : 22% Ei-formaalit: 21,0 : 19% Tuotantokäytössä: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 0,58 : 0,12% Ei-formaalit: 1,61 : 0,27% Empiirinen ohjelmistotutkimus 93 Empiirinen ohjelmistotutkimus 94 Bauer-Zemanekin hypoteesin perusteluja 6 Pfleegerin ja Hattonin tulokset ovat vakuuttavia varsinkin tuotantokäytössä löytyneiden virheiden osalta. Siitä huolimatta kritiikkiäkin löytyy: Projektiin osallistujien kokemuksesta ei ole tietoa, ei myöskään osallistujen formaalien menetelmien tietotaidosta. Projektissa ei ilmeisesti käytetty tarkastuksia, sillä virheiden elinikä oli pitkä. Tarkastusten käyttö olisi ehkä kutistanut formaalien ja eiformaalien tulosten eroa. Empiirinen ohjelmistotutkimus 95 Bauer-Zemanekin hypoteesin perusteluja 7 Formaaleista menetelmistä on taitettu peistä molempiin suuntiin. Ehkä parhaiten alaa kuvaa seuraava Gerhard, Craigen, Ralston kommentti: There is no simple answer to the question: do the formal methods pay off? All cases involve so many interwoven factors that it is impossible to allocate payoff from formal methods versus other factors. Gerhard et al. Observation on Industrial Practice Using Formal Methods, Proc. Int l Conf. Software Eng., 1993, 24-33. Empiirinen ohjelmistotutkimus 96 Taina 16
3.7. Dyerin hypoteesi Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Dyerin hypoteesi on esitelty Glassin kirjassa R. Glass, Facts and Fallacies of Software Engineering. Glass kirjoittaa kirjassaan yrittäneensä saada Dyerin kommentoimaan hypoteesiaan, mutta Glassin mukaan Dyer ei vastannut yhteydenottopyyntöihin. Empiirinen ohjelmistotutkimus 97 Dyerin hypoteesin taustaa Siirtyminen vaatimusmäärittelystä suunnitteluun on samalla iso hyppy abstraktiossa. Vaatimusmäärittelyssä löytyneet vaatimukset eivät riitä suunnitteluun, vaan suunnittelun sivutuotteena löytyy uusia vaatimuksia. Näitä kutsutaan johdetuiksi vaatimuksiksi (derived requirements). Empiirinen ohjelmistotutkimus 98 Dyerin hypoteesin taustaa 2 Johdetut vaatimukset johtuvat erilaisista abstraktiotasoista. Vaatimusmäärittelyn mitä -abstraktio ei riitä suunnittelun miten -abstraktioon. Glassin mukaan johdettuja vaatimuksia voi olla pahimmillaan 50 kertaa alkuperäisiä vaatimuksia enemmän! Empiirinen ohjelmistotutkimus 99 Dyerin hypoteesin perusteluja Dyerin hypoteesia ei ole validoitu, vaikka Glassin mukaan hypoteesi on tunnettu jo vuosikymmeniä. Hypoteesin validointi vaatisi joukon projekteja, joista laskettaisiin vaatimusten lukumäärän suhde johdettujen vaatimusten lukumäärään. Ainakin opiskelijaprojekteissa hypoteesi on todettu useamman kerran oikeaksi. Empiirinen ohjelmistotutkimus 100 3.8. Gamman hypoteesi Suunnittelumallien avulla tehtävä uudelleenkäyttö johtaa nopeampaan ja parempaan ylläpitoon. Ohjelmistojen uudelleenkäyttö parantaa parhaimmillaan tuottavuutta ja laatua. Mitä tahansa voidaan käyttää uudestaan: vaatimuksia, suunnittelua, koodia, testejä Suunnittelussa käytetään yleisimmin hyväksi suunnittelumalleja (design patterns), jotka ovat hyväksi havaittuja tapoja ratkaista jokin suunnittelun ongelma. Empiirinen ohjelmistotutkimus 101 Gamman hypoteesin taustaa Suunnittelumallit esiteltiin 1995 Gamman ja kumppaneiden suunnittelumallikirjassa. Mallien kannattajien mukaan mallit parantavat ohjelmoijien tuottavuutta ja koodin laatua, parantavat uusien ohjelmoijíen taitoja näyttämällä valmiita hyviä suunnitelmia, helpottavat suunnittelijoiden välistä kommunikointia, rohkaisevat hyvien ideoiden jakamiseen ja parantavat ohjelmistojen ylläpidettävyyttä. Empiirinen ohjelmistotutkimus 102 Taina 17
Gamman hypoteesin taustaa 2 Suunnittelumallit ovat erittäin suosittuja, ja niitä on julkaistu useita satoja. Suosioon vaikuttaa varmasti se, että suunnitteluvaiheeseen ei juuri löydy hyväksi havaittuja tekniikoita. Oppikirja mainitsee suunnittelumallien lisäksi kehykset, jotka eivät ole yhtä yleisiä. Suunnittelumallit ovat juuri tällainen yleisesti käyttökelpoinen tekniikka. Empiirinen ohjelmistotutkimus 103 Gamman hypoteesin perusteluja Prechelt ja Unger tutkivat 1999 ja 2001 ohjatuissa kokeissa, miten suunnittelumallit hyödyntävät ylläpitoa: Ensimmäisessä kokeessa testattiin, vaikuttaako suunnittelumallien kommentointi ylläpitoon. Osallistujat olivat opiskelijoita. Toisessa kokeessa testattiin, vaikuttaako mallien käyttö ylläpidettävyyteen. Osallistujat olivat ammattilaisia. Empiirinen ohjelmistotutkimus 104 Gamman hypoteesin perusteluja 2 Ohjattujen kokeiden tulokset olivat: (1. koe) Mallit kommentoituna koodissa Ł nopea ylläpito: Vahva korrelaatio. (1. koe) Mallit kommentoituna koodissa Ł oikea ylläpito: Vahva korrelaatio. (2. koe) Malleja käytetty koodissa Ł helppo ylläpito: Heikko korrelaatio. 2. kokeessa tulokset olivat positiivisia, jos suunnittelumallin avulla saatiin tehtyä siistimpi ratkaisu kuin ilman suunnittelumalleja. Empiirinen ohjelmistotutkimus 105 Gamman hypoteesin perusteluja 3 Gamman hypoteesin empiiriset todisteet ovat huomattavasti vahvempia kuin monen oppikirjassa listatun lain. Yhtä hyvin voisimme puhua Gamman laista. Suunnittelumallit eivät sovi kaikkiin tilanteisiin. Väärään kohtaan laitettu väärä malli voi pilata koko suunnitelman. Oikein käytettynä suunnittelumallit parantavat ylläpidettävyyttä. Aihepiiriä tutkitaan edelleen. Empiirinen ohjelmistotutkimus 106 Esiteltyjen lakien seurauksia Hyväksi suunnittelijaksi ei tulla pelkällä opiskelulla. Curtisin lain mukaan hyvä suunnittelija hallitsee suvereenisti suunniteltavan ohjelmiston sovellusalueen. Tähän vaaditaan ennen kaikkea kokemusta. Simonin lain mukaan ei-pakollisen tiedon rajoittaminen parantaa suunnittelua. Tällaisen tiedon tunnistus suunnittelussa vaatii ennen kaikkea kokemusta. Empiirinen ohjelmistotutkimus 107 Esiteltyjen lakien seurauksia 2 Modulaarinen lähestymistapa parantaa ja helpottaa suunnittelua. Simonin, Constantinen, Parnasin ja Fitts- Shneidermanin lait johtavat kaikki samaan tulokseen. Lisäksi oppikirjassa on esitelty Denertin laki, jota voidaan käyttää standardoitujen arkkitehtuurien perusteena. Myös tämä laki johtaa samaan tulokseen. Empiirinen ohjelmistotutkimus 108 Taina 18
4. Verifiointi ja validointi Verifioinnissa varmennetaan, että järjestelmä toimii speksiensä mukaisesti. Yleensä se muotoillaan kysymykseksi Kehitämmekö järjestelmää oikein? Validoinnissa varmennetaan, että järjestelmä täyttää sille asetetut tarpeet. Yleensä se muotoillaan kysymykseksi Kehitämmekö oikeaa järjestelmää? Verifiointia ja validointia (V&V) tehdään koko projektin keston ajan. Empiirinen ohjelmistotutkimus 109 Verifiointi- ja validointitekniikat Tärkeimmät V&V-tekniikat ovat tarkastukset ja testaus: tarkastukset: selvitetään ohjatussa kokouksessa dokumentin puutteita ja virheitä. (dynaaminen) testaus: annetaan ohjelmalle syötteitä ja katsotaan, minkälaisia tuloksia ohjelma antaa niillä. Muita V&V-tekniikoita ovat esimerkiksi mallinnus, simulaatiot ja todistaminen. Empiirinen ohjelmistotutkimus 110 Verifioinnin ja validoinnin luonne V&V on laadunvarmistusta, ryhmätyötä ja rinnakkaisia menetelmiä. Miksi? Fagan: Tarkastukset parantavat merkittävästi tuotteen laatua. Hetzel-Myers: Parhaat tulokset saadaan yhdistelemällä V&V:n tekniikoita. Weinberg: Ohjelmoijan ei pidä testata omaa koodiaan. Dijkstra: Täydellinen testaus ei onnistu. Empiirinen ohjelmistotutkimus 111 V&V:n lait ja hypoteesit Oppikirjassa esitellyt V&V:n lait ovat käytännöllisiä. Ne eroavat luonteeltaan esimerkiksi vaatimusmäärittelyn laeista. Lakien ja hypoteesien sanoma voidaan tiivistää näin: V&V on laadunvarmistuksen työkalu. Siinä tarvitaan yhteistyötä sekä menetelmien että tekijöiden välillä. Empiirinen ohjelmistotutkimus 112 V&V:n lait ja liittyminen ohjelmistotekniikkaan Seuraavassa ovat lait ja hypoteesit ja niiden liittyminen ohjelmistotekniikkaan: Faganin laki: tarkastukset Porter-Vottan laki: tarkastukset Basilin laki: tarkastukset Hetzel-Myersin laki: tarkastukset, mustalaatikkotestaus, lasilaatikkotestaus Mills-Jonesin hypoteesi (ei käsitellä): laadunvarmistus, prosessinhallinta Empiirinen ohjelmistotutkimus 113 V&V:n lait ja liittyminen ohjelmistotekniikkaan 2 Maysin hypoteesi: mustalaatikkotestaus Hoaren hypoteesi (ei käsitellä): verifiointi Sackmanin ensimmäinen laki (ei käsitellä): virheenjäljitys Dijkstran laki: mustalaatikkotestaus, lasilaatikkotestaus Weinbergin laki: mustalaatikkotestaus Pareto-Zipf laki: ohjelmistotekniikka Gray-Serlin laki (ei käsitellä): rasitustestaus Empiirinen ohjelmistotutkimus 114 Taina 19
V&V:n lait ja liittyminen ohjelmistotekniikkaan 3 Nielsen-Normanin laki (ei käsitellä): käytettävyystestaus Gutjahrin hypoteesi (ei käsitellä): mustalaatikkotestaus Weyukerin hypoteesi (ei käsitellä): lasilaatikkotestaus Endres-Glatthaar hypoteesi (ei käsitellä): lasilaatikkotestaus Hamletin hypoteesi: mustalaatikkotestaus V&V:n lait ja liittyminen ohjelmistotekniikkaan 4 Kuten edellisestä listasta nähdään, V&V:n lakeja ja hypoteeseja on paljon ja niillä on usein täsmällinen merkitys. Itse asiassa varsinkin lasilaatikkotestauksesta olisi enemmänkin lakeja, mutta ne ovat eot:n kannalta harmaata aluetta. Lasilaatikkotestauksen lait perustuvat matematiikkaan, mutta niiden hyötyä arvioidaan empiirisin kokein. Empiirinen ohjelmistotutkimus 115 Empiirinen ohjelmistotutkimus 116 V&V:n lait ja liittyminen ohjelmistotekniikkaan 5 Eniten kaivataan lisää mustalaatikkotestauksen teoriaa ja menetelmiä. Tällä hetkellä mustalaatikkotestaus perustuu pääasiassa syöteavaruuden ositukseen. Tarkastusten tilanne on parempi. Teoria on osoittautunut hyväksi ja uutuudet ovat olleet kosmeettisia. Lasilaatikkotestaus on matemaattisesti parhaiten hallittu V&V-tekniikka. Empiirinen ohjelmistotutkimus 117 4.1. Faganin laki Tarkastukset parantavat merkittävästi tuottavuutta, laatua ja projektien stabiiliutta. Fagan esitti 1970-luvulla IBM:llä, miten dokumenteista voidaan tehokkaasti löytää virheitä muodollisilla tarkastustilaisuuksilla. Tarkastusten hyvyys on yksi vahvimmista EOT:n laeista. Sitä on sekä validoitu että varmennettu käytössä yli 30 vuoden ajan. Empiirinen ohjelmistotutkimus 118 Faganin lain taustaa Faganin tarkastukset ovat tuttuja: 1. Joukko tarkastajia saa tarkastettavan dokumentin luettavaksi useita päiviä ennen sovittua tarkastustilaisuutta. 2. Tarkastustilaisuutta johtaa puheenjohtaja. 3. Tarkastajat esittävät tilaisuudessa löytämiään dokumentin puutteita ja virheitä. 4. Puutteet ja virheet kirjataan ylös. 5. Lopuksi päätetään dokumentille tehtävät toimenpiteet. Faganin lain taustaa 2 Faganin lakia voidaan soveltaa minkä tahansa prosessin dokumenttiin. Parhaimmillaan se on kuitenkin silloin, kun dokumentti on saatu monesta lähteenä ryhmätyönä. Tarkastuksia pidetään aiheesta kaikkein tehokkaimpana V&V:n tekniikkana. Tästä huolimatta tarkastuksia tehdään yrityksissä edelleen yllättävän vähän. Tarkastusten sijaan muodissa ovat kevyemmät katselmointitekniikat, kuten pariohjelmointi ja koodin läpikäynti. Toki nämäkin parantavat laatua. Empiirinen ohjelmistotutkimus 119 Empiirinen ohjelmistotutkimus 120 Taina 20
Faganin lain perusteluja Faganin lain perusteluja 2 Fagan perustaa tuloksensa empiiriseen kokeeseen. Hän vertaili kahta prosessia, joista toisessa tarkastusten avulla tuotosta muokattiin aikaisin, ja joista toisessa ilman tarkastuksia muokkaus tehtiin testauksen jälkeen. Faganin mukaan tarkastukset antoivat 23% tuottavuuslisän. Empiirinen ohjelmistotutkimus 121 Tuottavuuden lisäksi Fagan vertasi laatua. Faganin mukaan tarkastusryhmässä kaikkien löydettyjen virheiden lukumäärä oli 38% pienempi kuin vertailevassa ryhmässä. Myös muista lähteistä on saatu vastaavia tuloksia: jopa lähes 100% löydetyistä virheistä on löydetty tarkastuksissa. Empiirinen ohjelmistotutkimus 122 Faganin lain teoria Faganin lain tehokkuus johtuu Boehmin ensimmäisestä laista. Tarkastusten avulla virheet löydetään aikaisin, joten niiden kustannus pysyy pienenä. Tarkastukset eivät kuitenkaan korvaa testausta. Varsinkin monimutkaisten oliopiirteiden virheiden löytäminen tarkastuksilla on vaikeaa. Käännösaikana evaluoitavien rakenteiden (esim. makrot ja aspektit) virheiden löytäminen tarkastuksilla on lähes mahdotonta. 4.2. Porter-Vottan laki Tarkastusten tehokkuus on melko riippumaton niiden toteutustavasta. Porter ja Votta pyrkivät selvittämään empiirisin kokein, miten tarkastuksia kannattaisi järjestää. Heidän tutkimuksensa tulos oli, että järjestelyt eivät erityisesti vaikuta. Alkuperäiset järjestelyt ovat ihan hyvät. Tarkastusprosessia on vaikea parantaa. Empiirinen ohjelmistotutkimus 123 Empiirinen ohjelmistotutkimus 124 Porter-Vottan lain taustaa Faganin tarkastukset on kuvattu aika yleisesti, joten niistä on tehty useita variaatioita. Esimerkiksi seuraaviin kysymyksiin on vastattu eri tavoin: Onko tarkastustilaisuuden tarkoituksena tehdä päätöksiä valmisteluvaiheessa löytyneistä virheistä, vai pitääkö virheet tunnistaa tarkastustilaisuudessa? Käytetäänkö dokumenttia kohden yhtä vai useaa tarkastustilaisuutta? Empiirinen ohjelmistotutkimus 125 Porter-Vottan lain taustaa 2 Intuitiivisesti tuntuisi, että yritykselle räätälöity tarkastusprosessi antaisi yleistä parempia tuloksia. Porter-Vottan lain mukaan intuitio on osin väärässä. Tarkastusvariaatioiden väliset erot ovat pienet. Merkittävin poikkeus laista ovat näkökulmapohjaiset tarkastukset, joita käsitellään Basilin laissa. Empiirinen ohjelmistotutkimus 126 Taina 21