Voisitteko. Tarkastukset

Transkriptio

1 1 Voisitteko Tarkastukset Marko Komssi From: Hra Projektipäällikkö Sent: Tuesday, Dec 7, 2004 :19 To: Projektiryhmä Subject: Voisitteko katselmoida vielä yhden vaatimusdokumentin? Se on vain 6 sivua. Kokoamme virheet huomenna heti viikkokokouksen jälkeen klo Tyypillisiä ongelmia katselmointitavoissa Sisältö Tarkastettavan tuotteen tavoitteet ja riskit ovat epäselvät. Ei selvitetä, miksi ja kenelle dokumentti on kirjoitettu? Tarkastukset keskittyvät vääriin virheisiin. Kirjoitusvirheiden tms. hiominen on usein turhaa. Tarkastettavan alueen laajuus on liian suuri. Yleensä 6 sivun vaatimusdokumentti syö mehut hyväkuntoiseltakin tarkastajalta. Katselmoinnit keskittyvät vain virheiden etsintään (engl. defect detection) ja suoritetaan liian myöhäisessä vaiheessa tuotteen valmistusta. Opitaanko virheistä ja voidaanko projektin aikana tehdä suunnanmuutoksia tulosten ja analyysien perusteella? Staattinen testaus ja katselmointityypit Perinteinen tarkastusprosessi ja tarkastusten parametreja Onko tarkastuksista hyötyä? Eikö pelkkä dynaaminen testaus riitä? Tarkastussäännöt sekä tavoitteiden ja riskien huomioiminen Vaatimuksissa vähän on usein enemmän Miten matkakorttijärjestelmää olisi voitu parantaa vaatimusten tarkastuksella? Arkkitehdin ja tuotepäällikön motivointi 3 4 Staattinen testaus Katselmointityypit 2 Testausta ilman käännettyä koodia kutsutaan staattiseksi testaukseksi Staattisen testauksen merkitystä usein vähätellään verrattuna dynaamiseen testaukseen Suunnittelu Katselmointityyppi Inspection Osavaihe Esikäsittely Korjaaminen Kokous Varmennus Yritykset käyttävät huonoja menetelmiä: ohjelmoijat ja päälliköt luulevat tietävänsä esim. kuinka tarkastuksia tehdään Team Review Walkthrough Inspection is a method of static checking that can be performed on any of the intermediate products of software development (i.e., the URD, specification, design, or code) 1. Pair Programming Peer Deskcheck, Passaround Ad Hoc Review? 6 Finl France Germany Japan Sweden United Kingdom USA

2 2 Perinteinen tarkastusprosessi 3 Tarkastusten henkilöitä Moderaattori on yksittäisten tarkastusten keskeisin henkilö. Vastaa koko tarkastusprosessin läpiviennistä ja onnistumisesta. s ing Champion on henkilö joka vastaa tarkastusprosessin markkinoinnista ja hyvyydestä organisaatiossa (voi olla sama kuin moderaattori). Tarkastajat tekevät tarkastusten perusduunin. Kirjuri kirjoittaa virheet ylös. (Häntä ei usein käytetä, koska moderaattori ja hyvä tarkastusprosessi hoitaa tämän homman.) Tuotteen kirjoittaja on raukka, joka joutuu kestämään muiden kommentteja. 7 8 Tarkastusprosessin parametreja ja mittareita 3 EFFICIENCY = Löydettyjen virheiden lukumäärä käytettyyn aikamäärään nähden EFFECTIVENESS = Löydettyjen virheiden määrä per [Yksikkö]. Yksikkö voi olla esim. 1 KLOC tai 1Kwords DEFECT DENSITY = Arvio tuotteessa (jäljellä) olevien virheiden määrästä per [Yksikkö] Tarkastusprosessin parametreja ja mittareita (2) Tarkastussääntöjen ja -osavaiheiden sekä tarkastajien ja virtuaaliroolien lukumäärä Katselmoinnin osavaiheen kesto ja koko prosessin läpimenoaika Katselmointitahti (engl. checking rate) ja tarkastettavan tuotteen (osan) koko Tarkastajien kokemus (kyvyt) Hyväksymiskriteerit (engl. entry exit criteria) 9 Tarkastusten hyötyjä (miksi ei vain testata?) HP: tarkastuksille mitattu hyötysuhde :1. Arvioidut säästöt 20 miljoonaa dollaria 4 IBM: tarkastukset ovat aiheuttaneet 20 prossan tehokkuuden kasvun koodauksessa. Virheitä löydetty 2-4 kertaa nopeammin kuin dynaamisella testauksella 6 Lyhyt virheiden korjausaika Tarkastuksilla löydetään toisenlaisia virheitä kuin dynaamisella testauksella Ylläpidettävyys, testattavuus, väärät asiakasvaatimukset, Tarkastuksia voidaan tehdä aikaisessa vaiheessa projektia Psykologinen vaikutus: teet paremmin jos tiedät että sua kyylätään 7 Tarkastussäännöt Sääntöjen avulla tuetaan virheiden etsintää Säännön rikkominen lasketaan virheeksi CUSTOMER customer requirements must be real Does the statement in the specification describe the customer? Is the need of the customer correctly presented? Finl France Germany Japan Sweden United Kingdom USA

3 3 Tarkastussäännöt tavoiteiden ja riskien pohjalta 8 Case: tavoitteiden ja riskien huomioiminen Keräsimme vaatimusdokumenttiin liittyviä tavoitteita ja riskejä: TAVOITE: Dokumentti muodostaa yhteisen tuntemuksen tehtävään tuotteeseen RISKI: Ihmiset eivät lue dokumenttia (kunnolla) Kysyimme auttavia kysymyksiä tavoitteille ja riskeille Missä tilanteessa ihmiset eivät lue dokumenttia (kunnolla)? Määrittelimme kysymysten perusteella joukon tarkastussääntöjä Minimaalinen (Minimal), Asiaankuuluva (Relevant) ja Asiakas (Customer) Dokumentin virhedata Eiku uudestaan Customer Mininal Relevant 0 Customer Unknown Minimal Specific 241-sanainen vaatimusdokumentti (Internet Security 200) 13-sanainen vaatimusdokumentti (Internet Security 200) 1 16 Vähän on enemmän PI: vaiheiden painotus projektin alussa Tarkkuudella ja tarkkuudella on eroa (accuracy vs. precision) Vaatimusten paikkaansapitävyys tai niiden desimaalitarkkuus? Vaikka kuulostaa oudolta, niin saat vähemmän vahinkoa aikaan jos kirjoitat liian vähän sen sijaan että kirjoitat liian paljon 9 Jopa pieninnätkin vaatimukset sisältävät enemmän kaloreita kuin arvaatkaan Tiiviys osana vaatimusten tarkastusstrategiaa Sitten sinulla on lyhyt ja luettava dokumentti, jota ihmiset viitsivät lukea ja josta he kysyvät kysymyksiä 9 s ing Progressiivinen tarkastuskonsepti (PI) 8 Noin kolme sääntöä Kevyet kriteerit Finl France Germany Japan Sweden United Kingdom USA

4 4 PI: vaiheiden painotus projektin lopussa Tämä olisi voitu tehdä toisin, vai mitä? s ing Mitähän tämän tuotteen vaatimusmäärittelyyn on kirjoitettu? Suorituskyky: 0 ihmistä minuutissa? Lisää sääntöjä ja tarkastajia Tiukat kriteerit Käyttötapausmalli 1: Henkilö matkustaa junalla Helsingistä Espooseen (osa 1) Käyttötapausmalli 1: Henkilö matkustaa junalla Helsingistä Espooseen (osa 2) Primary actor: It-henkilö Secondary actors: HKL ja matkakorttisysteemi Goal: Matkustaja haluaa maksaa matkan. Level: Käyttäjän tavoite Scope: Matkakorttisysteemi Preconditions: Matkustajalla on matkakortti Main success scenario: 1. Matkustaja astuu junaan 2. Matkustaja maksaa kortilla matkan 3. Systeemi veloittaa matkan oikein 4. Systeemi ilmoittaa matkustajalle tapahtumasta Extensions: 2a. Matkustajalla on huono näkö: 2a1. 2a4. Matkustaja saa tiedon 2b. Matkustaja käyttää korttia ensimmäistä kertaa: 2b1. 2b4. Matkustaja saa tiedon 2c. Matkustaja on lyhyt lapsi: 2c1. 2c4. Matkustaja saa tiedon 3a. Matkakortissa on vähän rahaa: Primary actor: Köyhä it-henkilö Secondary actors: HKL ja matkakorttisysteemi Goal: Matkustaja ei halua maksaa sakkoja. Level: Käyttäjän tavoite Scope: Matkakorttisysteemi Preconditions: Matkustajalla on matkakortti Main success scenario: 1. Matkustaja astuu junaan 2. Matkustaja maksaa kortilla matkan 3. Systeemi veloittaa matkan oikein 4. Matkustaja on varma, että maksu on oikein veloitettu. Matkustaja ei joudu maksamaan sakkoja Extensions: 2a. Matkustajalla on huono näkö: 2a1. 2a4. Matkustaja on varma 2b. Matkustaja käyttää korttia ensimmäistä kertaa: 2b1. 2b4. Matkustaja on varma 2c. Matkustaja on lyhyt lapsi: 2c1. 2c4. Matkustaja on varma 3a. Matkakortissa on vähän rahaa: 3a1. 3a Profiili: ohjelmistoarkkitehti Profiili: tuotepäällikkö Hän on usein tulospainotteinen ihminen. Tulos tässä tarkoittaa makeeta suunnittelua ja koodia yms. Hän on innovatiivinen ja karttaa kaikin voimin yksitoikkoista työtä. Hänellä on erinomainen kyky ajatella sekä abstrakteja että yksityiskohtaisia aiheita. Tällaiset henkilöt ovat arvokkaita mm. vaatimusten, testitapausten, ja koodinpätkien tarkastuksissa Miten arkkitehti motivoidaan tarkastamaan? Hän on usein tulospainotteinen ihminen Tulos tässä tarkoittaa kovaa palkkaa ja kovaa myyntiä Hän karttaa kaikin voimin tapaamisia teknisten ihmisten kanssa ja/tai on liian tekninen ja olettaa (lue: määrää) liikaa Hän haluaa aina asioiden tapahtuvan nopeasti (ja paljon). Tällaiset henkilöt ovat kuitenkin arvokkaita mm. vaatimusten ja erityisesti vision (bisnes casen) tarkastamisessa. Miten tuotepäällikkö motivoidaan tarkastamaan? Finl France Germany Japan Sweden United Kingdom USA

5 Yhteenveto Lähteet Tarkastuksilla voidaan tukea esimerkiksi vaatimusdokumentin minimaalisuutta projektin eri tuotantovaiheilla Tarkastussäännöt kannattaa johtaa tavoitteista ja riskeistä Tarkastusprosessi kannattaa pitää dynaamisena 1. Martin, J., Tsai, W.T., N-fold Inspection: A Requirements Analysis Technique. Communications of the ACM 33, 2, (1990), Wiegers, K., When Two Eyes Aren't Enough. Software Development 9, (2001), Gilb, T., Graham D., Software Inspection. Addison-Wesley (1993). 4. Grady, R.B., Van Slack, T., Key Lessons in Achieving WidespreadInspection Use. IEEE Software, 11, 4 (1994), Fagan, M.E., Design Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 1, 3 (1976), Russel, G.W., Experience with Inspections in Ultralarge-Scale Developments. IEEE Software, 8, 1 (1991), Wiegers, K.E., Peer Reviews in Software: A Practical Guide. Addison-Wesley (2001). 8. Komssi, M., Increasing Responsiveness Economy of Software Inspection. Proceedings of the 12th European Conference on Software Testing, Analysis & Review (EuroSTAR '2004), Cologne, Germany, December Cockburn, A., Writing Effective Use Cases. Addison-Wesley (2001).. McConnell, S., Achieving Leaner Software. IEEE Software, 14, 6 (1997), Finl France Germany Japan Sweden United Kingdom USA