Virtuaalinen tarkastus. Katselmoinnit osa 3. Paritarkastus. N-kertainen tarkastus (n-fold inspection)

Transkriptio

1 Virtuaalinen tarkastus Katselmoinnit osa 3 Sami Kollanus Ei tarvetta olla samaan aikaan samassa paikassa Tueksi erilaisia työkaluja Asynkroninen vs. synkroninen Tarpeen hajautetuissa projekteissa Vain tarvittaessa 2 Paritarkastus N-kertainen tarkastus (n-fold inspection) Työpari tarkastaa toistensa töitä Minimoidaan resurssienkulutus Esim. Kusumoto ym. 1998: Tekijä + katselmoija Ensin tekijä esittelee tuotoksen ja katselmoija esittää tarpeellisia kysymyksiä Molemmat katselmoivat dokumentin yhdessä tarkistuslistaa käyttäen Sosiaalinen paine?? Sama dokumentti tarkastetaan useamman riippumattoman tiimin voimin Tiimit tekevät työn samanaikaisesti Kattavampi osuus virheistä löydetään Kysymyksiä: Resurssit -> sovellusalue Katselmoijien saatavuus Osaaminen 3 Martin & Tsai (1990) 4

2 Vaiheistettu tarkastus (phased inspection) Eri näkökulmat katselmoidaan eri vaiheissa esim. koodille: Vaihe 1: dokumenttien formaatti, kieli, yms. Vaihe 2: koodin ulkoasu Vaihe 3: Koodin luettavuus, muuttujien nimeäminen yms. Vaihe 4: gotot, globaalit muuttujat yms. Vaihe 5: silmukat, tiedostojen sulkeminen Vaihe 6: Ohjelman toiminta Sopivat resurssit eri vaiheille Otoskatselmointi (sampling) Ensin esitarkastus: Yksi tarkastaja % dokumenteista Selvitetään, mistä dokumenteista löytyy eniten virheitä Priorisoidaan dokumentit varsinaista tarkastusta varten Knight & Myers (1993) 5 Thelin ym. (2004) 6 Palaverin keventäminen Tarkistuslista Useita eri ajatuksia koko palaverin merkityksestä Kelly & Shepard (2004): Jätetään palaveri pois Pidetään kuitenkin käynnistyspalaveri Sauer ym. (2000): Itsenäiseen tarkastukseen voi osallistua suurempi tiimi Palaverin sijasta pari asiantuntijaa käy dokumentin läpi Tavallinen tapa tarkastaa dokumenttia 50 % käyttää tarkistuslistoja, 35 % adhoc (Ciolkowski 2003) 100 % ad-hoc (Kollanus 2006) Organisaation toimintaan mukautettuja 7 8

3 Esimerkki tarkistuslistasta projektisuunnitelmalle Esimerkki tarkistuslistasta projektisuunnitelmalle Clarity Is the project plan appropriately composed, being neither too detailed nor too general? In the meaning of each plan component clear and un unambiguous? Is the relationship between plan components clear? Is the plan organized in a logical and clear way and consistent with an applicaple template? Compeleteness Are relevant details missing from any plan components? Consistency Is the content consistent with the project s scope and objectives? Correctness Are all estimates realistically achievable?... Wiegers (2002) 9 Wiegers (2002) 10 Kritiikkiä tarkistuslistoista Muita lukumenetelmiä Liian yleisiä eli niitä ei ole riittävästi mukautettu ympäristöön, jossa niitä käytetään. Konkreettinen ohjeistus tarkistuslistojen käytöstä usein puuttuu. Jos tarkistuslistat perustuvat aiempiin kokemuksiin, on niiden perusteella vaikea havaita uudenlaisia virheitä. Skenaariopohjainen Virhelähtöinen Perspektiivipohjainen Käyttäjälähtöinen Abstraktiopohjainen Tehtäväkeskeinen Laitenberger ja DeBaud (2000) 11 12

4 Skenaario vs. tarkistuslista (reqs) Skenaario vs. tarkistuslista (reqs) Tarkistuslista: Ambiguous Information Are the individual requirements stated so that they are discrete, unambiguous, and testable? Are all mode transitions specified deterministicly? Ambiguities Or Missing Functionality Scenario 1. Identify the required precision, response time, etc. for each functional requirement. (a) Are all required precisions indicated? 2. For each requirement, identify all monitored events. (a) Does a sequence of events exist for which multiple output values can be computed? (b) Does a sequence of events exist for which no output value will be computed? 3. For each system mode, identify all monitored events. (a) Does a sequence of events exist for which transitions into two or more system modes is allowed? Porter ja Votta (1998) 13 Porter ja Votta (1998) 14 Perspektiivipohjainen lukutekniikka Käyttäjälähtöinen lukutekniikka Vaatimusmäärittelyn katselmointiin Osallistujilla eri roolit Jokainen osallistuja lähestyy vaatimuksia omasta roolistaan käsin Esim. testaaja luo ensin vaatimusten pohjalta testaussuunnitelman Suunniteludokumentteja varten Otetaan pohjaksi määritellyt käyttötapaukset ja tarkastetaan dokumentti niiden avulla Keskitytään käyttäjän kannalta keskeisiin virheisiin Basili ym. (1996) 15 Thelin ym. (2001) 16

5 Tehtäväkeskeinen tarkastus Lähteet Koodia varten Lukijan täytyy tehdä koodista korkeamman tason kuvaus, joka sisältää seuraavat elementit: Tieto Suorituslogiikka Yhteys suunnitteludokumentteihin Kollanus 2006, lisensiaattityö: pdf Muutama muu, joiden viitteet löytyvät edellisen lähdeluettelosta Thelin ym. (2001) 17 18