2. Vaatimusmäärittely. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

Transkriptio

1 2. on ensimmäinen projektin osavaihe. Sitä pidetään myös tärkeimpänä vaiheena. Miksi? Ehkä seuraavat lait selittävät asiaa: Glass: huono vaatimusmäärittely on 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ä. n validointi stä 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 speksattavat tuotteet on jo speksattu ja jokainen vaatimusmäärittelyprosessi on omalla tavallaan ainutkertainen. 1 2 n lait n työvaiheet Oppikirjassa esitellyt vaatimusmäärittelyn lait ja hypoteesit ovat luonteeltaan varoittavia. Ne voidaan tiivistää yhdeksi lauseeksi: Jos et ole tarkkana vaatimusmäärittelyssä, et saa aikaan laadukasta lopputulosta. Toki myös vaatimusmäärittelyn tekniikoita voitaisiin validoida, mutta toistaiseksi sellaista tutkimusta on vähän 3 n 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. 4 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 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

2 2.1. Glassin laki Glassin lain taustaa n virheet ovat projektien epäonnistumisten pääsyy. Robert Glass on tutkinut epäonnistuneita projekteja jo vuosikymmeniä. Hänen lakinsa perustuu tehtyyn tutkimukseen ja tarkoittaa nimenomaan epäonnistuneita projekteja. Suurin osa projekteista onnistuu, joten Glassin laki ei koske kaikkia projekteja. Vajaa vaatimusmäärittely on ongelmana lähes kaikille projekteille. Ongelmia 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, vaatimukset muuttuvat projektin aikana. 7 8 Glassin lain taustaa 2 Glassin lain perusteluja Tavallisin vaatimusmäärittelyn virhe on epätäydellinen tai virheellinen määrittely. Erityisesti ongelmia syntyy, jos projektin vaatimusmäärittely on ulkoistettu jollekin kolmannelle osapuolelle. yn vaaditaan siis tarkkuutta, jotta ongelmat havaitaan ja korjataan ajoissa. 9 Glass perustaa tuloksensa tapaustutkimuksiin. Tällaista lakia ei oikein voisi validoida muilla keinoilla. Glassin havaintoja epäonnistuneista projekteista: Liikaa vaatimuksia. Myöhään ilmenneitä muuttuvia vaatimuksia. Moniselitteisiä vaatimuksia. Epätäydellisiä vaatimuksia. 10 Glassin lain teoria Vaatimusten määrittely on vaikeaa. Sidosryhmien tarpeet eroavat toisistaan. Vaatimusten priorisointi ei aina onnistu. 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 Glassin hypoteesi Puuttuvat vaatimukset ovat vaikemmat 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, Glass listaa tämän kohdan fakta alle, mutta kurssin terminologialla tämä on hypoteesi

3 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 inhimmillisiä tekijöitä, sitä virhealttiimpaa on toiminta. Tulokset voivat olla sekä moniselitteisiä että vaikeasti strukturoitavia: virhealttiita. Glassin hypoteesin taustaa 2 Myös vaatimusten mallinnus ja tulkinta ovat virhealttiita työvaiheita. Käyttäjien 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 Glassin hypoteesin taustaa 3 Glassin hypoteesin perusteluja Kun kaksi virhealtista prosessia yhdistetään, saadaan erityisen virhealtis prosessi. Kaikkia 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ä. 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 Boehmin ensimmäinen laki ja suunnittelu ovat projektien virheherkimpiä työvaiheita. Näiden virheiden korjaus on sitä kalliimpaa, mitä myöhemmin niitä yritetään korjata. Boehmin ensimmäinen laki selittää, missä työvaiheessa virheet ylipäänsä ilmaantuvat. Laki voidaan varmentaa luokittelemalla löydetyt virheet ja arvioimalla kunkin virheen korjauskustannus. 17 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. 18 3

4 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. 19 Boehmin ensimmäisen lain perusteluja Boehm perustaa lakinsa 1970-luvulla tehtyihin tapaustutkimuksiin. n hypoteeseja on vaikea tutkia muuten kuin tapaustutkimuksin Endres sai vastaavasti tuloksen: 60-70% kaikista projektin aikana löydetyistä virheistä on vaatimusmäärittely- tai suunnitteluvirheitä. Muidenkin tulokset ovat samanlaisia. 20 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 poikii tulevissa työvaiheissa uusia virheitä Boehmin toinen laki Prototyyppien käyttö vähentää merkittävästi erityisesti käyttöliittymän 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 aiemmat lait, Bohem:n toinen laki on validoitu ohjatulla kokeella. 22 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ä jännitteitä. 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

5 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. 25 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. 26 Boehmin toisen lain teoria n pahimpia ongelmia on moniselitteisyys. Mitä useampi sidosryhmä on riippuvainen tuotteesta, sitä varmempaa on, että väärinkäsityksiä syntyy. Prorotyypit vähentävät moniselitteisyyttä, sillä ne näyttävät sidosryhmille tuotteen sellaisena kuin se tulee olemaan. Lopputulos ei tällöin riipu tulkinnoista Davisin laki Mallin hyöty riippuu valitusta näkökulmasta. Mikään malli ei sovi kaikkiin tilanteisiin. 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. 28 Davisin lain taustaa Mallinnus on osoittautunut erinomaiseksi keinoksi esittää järjestelmän toimintaa. Esimerkiksi vaatimusmäärittelyssä käytetään seuraavia malleja: Tietomallit: ER-kaaviot ja johdannaiset Prosessimallit: Tietovuokaaviot Tilasiirtymät: Tilasiirtymäkaaviot Rakenteet: Luokkakaaviot Toiminta: Sekvenssikaaviot Davisin lain taustaa 2 Jokainen kaaviotekniikka esittää näkymän mallinnettuun järjestelmään. Jokainen näkymä antaa 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 eli käytännössä ei piilottaisi järjestelmästä mitään tietoja

6 Davisin lain perusteluja 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: Automatisoidun kirjamyymälän järjestelmä Automaattinen helikopterin laskeutumisjärjestelmä Järjestelmä siirtämään ihmisiä 30 minuutissa New Yorkista Tokioon. 31 Davisin lain perusteluja 2 Ensimmäisen järjestelmän kohdalla voitiin Davisin mukaan käyttää hyvin eri tyyppisiä mallinnuskeinoja, jotka kaikki tuottivat hyödyllisiä tuloksia. Toisen järjestelmän ja varsinkin kolmannen järjestelmän kohdalla käytetyn mallin hyöty oli pieni verrattuna kehitettävän järjestelmän ongelmiin. Näin ollen pelkkä sopivan mallin valinta ei vaatimusmäärittelyssä riitä. 32 Davisin lain validointi Davisin lain validointi 2 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. 33 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? 34 Davisin lain teoria Me ihmiset emme ole kovin hyviä kokoamaan kokonaisuutta isosta joukosta yksityiskohtia. Malli on kohteen yksinkertaistus. Sen avulla koko järjestelmästä saadaan helpommin hallittava yleistetty näkymä. Tarvitaan useita näkymiä, useita eri abstraktiotasoilla olevia erilaisia malleja, kuvaamaan koko järjestelmä 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 aikoina oliomallinnus on tullut ohjelmointikielten ja suunnittelun kautta myös vaatimusmäärittelyyn. Boochin mukaan suuntauksen pitäisi helpottaa vaatimusten kartoitusta. 36 6

7 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. 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, hierarkisuutta, tyypitystä ja rinnakkaisuutta 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. perusteluja (tai tyrmäystä) Oppikirjassa esitellyt hypoteesin perustelut vaikuttavat ensi silmäyksellä täysin hypoteesin vastaisilta: Oliopohjaisus ei helpota interaktioita sidosryhmiin. Oliopohjaisuudella ei löydetä perinteisiä tapoja tehokkaammin vaatimuksia. Vähintään voidaan sanoa, että hypoteesin validoinnissa on vielä työtä Esiteltyjen lakien seurauksia lle pitää varata tarpeeksi aikaa ja resursseja. n 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ä. 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. Se tarkoittaa vain, että hyväksi havaittuja menetelmiä ei ole vielä varmennettu kunnolla. n lainalaisuuksien validoinnissa on vielä paljon tutkittavaa