Menetelmäraportti Ohjelmakoodin tarkastaminen
Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5 2.1.4. Tarkastustilaisuus...5 2.1.5. Korjaus...5 2.1.6. Jälkiseuranta...5 2.2. Tarkastusryhmä...5 3. Tarkastusmenetelmän hyötyjä...7 4. Menetelmän soveltaminen projektissa...8 4.1. HyperCode-ohjelmakoodin tarkastusprosessi...8 5. Lähdeluettelo...9 Versio- ja muutoshistoria Versio Päiväys Tekijä Kuvaus 0.1 22.03.02 Tuomas Lindström Ensimmäinen luonnos 0.2 24.03.02 Tuomas Lindström Lisätty Kuva 2.1 ja luvut 3 ja 4 Tallennettu: 24.03.02 23:24 Tulostettu: 25.03.02 11:03 Menetelmäraportti: Ohjelmakoodin tarkastaminen 2
1. Johdanto Tässä dokumentissa on kuvattu laadukkaan lähdekoodin tuottamiseen Dtvprojektissa käytetty lähdekoodin tarkastus -menetelmä. Tarkastuksessa ohjelmakoodi käydään huolellisesti läpi ja löytyneet virheet raportoidaan ohjelmakoodin tekijälle, joka korjaa löytyneet virheet. Menetelmä pyrkii löytämään virheet ennen testausta, jolloin virheet on helpompi korjata ja varsinainen testaus sujuu nopeammin. Menetelmäraportti: Ohjelmakoodin tarkastaminen 3
2. Menetelmän kuvaus Tarkastusmenetelmä kehitettiin IBM:llä 1970-luvulla laadunvarmistukseen. Tarkistuksilla pyritään varmistamaan laatua koko ohjelmistoprosessin elinkaaren ajan. Tarkastusmenetelmää käytetään yleensä dokumenttien tarkastukseen esim. vastaako vaatimusmäärittely vaatimuksia mutta sitä käytetään myös parantamaan ohjelmakoodin laatua. Tässä dokumentissa keskityn juuri ohjelmakoodin tarkastamiseen. [1] Tarkastuksessa tarkastettava dokumentti tai lähdekoodi luetaan läpi huolellisesti kohta kohdalta ja pyritään löytämään siitä puutteita ja virheitä. 2.1. Tarkastusprosessi Työvaihe Tarkastettava dokumentti Valmistautuminen K Suunnittelu Tarkastustilaisuus Uusintatarkastus? E Esittely tarpeen? E Tarkastuspöytäkirja Korjaus K Esittely Hyväksytty dokumentti Jälkiseuranta Kuva 2.1: Tarkastusprosessin vaiheet. [1] 2.1.1. Suunnittelu Suunnitteluvaiheessa tarkistetaan, että tarkastettava materiaali on valmis tarkastettavaksi. Ohjelmakoodilla tämä tarkoittaa käytännössä sitä, että se kääntyy ja näyttää toimivan ilman suurempia testauksia. Ohjelmakoodia ei Menetelmäraportti: Ohjelmakoodin tarkastaminen 4
tulisi tarkastaa yli 500 riviä yhdessä tarkastuksessa, joten tarkastus pilkotaan useampaan osaan tarvittaessa [1]. Suunnitteluvaiheessa valitaan myös tarkastusryhmä, varataan aika ja paikka tarkastukselle sekä lähetetään tarkastettava materiaali tarkastusryhmälle. [2] 2.1.2. Esittely Esittely on valinnainen vaihe, jossa tarkastajille esitellään tarkastuksen kohde mikäli se ei ole entuudestaan tuttu [2]. Esittely voi olla myös haitallinen toimenpide, koska siinä ohjelmoija esittää omia mahdollisesti virheellisiä käsityksiään [1]. 2.1.3. Valmistautuminen Valmistautumisvaiheessa tarkastajat käyvät tarkastettavan koodin läpi yksin ja yrittävät etsiä virheitä ohjelmakoodista. Tässä vaiheessa on hyvä käyttää tarkastuslistaa, joka helpottaa tarkastuksen tekemistä. Ryhmämme käyttämä tarkastuslista löytyy liitteestä 1. Kukin tarkastaja kirjaa muistiin löytämänsä virheet, jotta ne voidaan käydä läpi varsinaisessa tarkastustilaisuudessa. [2] 2.1.4. Tarkastustilaisuus Tarkastustilaisuudessa tarkastusryhmä tarkastaa materiaalin ryhmänä. Ohjelmoija lukee ja tulkitsee ohjelmakoodia tarkastajille, jotka keskeyttävät ohjelmoijan aina virheen huomatessaan. Löytynyt virhe luokitellaan ja kirjataan ylös. Jos virhettä ei voida osoittaa todelliseksi virheeksi, kirjataan ylös, ettei virhettä pystytty tarkastustilaisuuden puitteessa osoittaa todelliseksi ja virhettä voidaan tulkita tarkemmin tilaisuuden jälkeen vapaamuotoisemmassa kokouksessa. Löydetyt virheet jaoitellaan vielä suurempiin ja vähäpätöisempiin. Virhe on suuri mikäli sen johdosta ohjelma ei täytä vaatimuksiaan. Tilaisuuden lopuksi virheet kootaan yhteen ja päätetään tarvitaanko uusintatarkastus vai riittäkkö korjausten teko ja jälkiseuranta. [2] 2.1.5. Korjaus Korjausvaiheessa ohjelmoija korjaa kaikki tarkastuksessa löytyneet suuremmat virheet ja resurssien puitteissa pienemmät löydökset. [2] 2.1.6. Jälkiseuranta Jälkiseurannassa ohjelmoija ja takastuksen puheenjohtaja käyvät läpi tehdyt korjaukset ja mahdolliset uudet virheet. Mikäli korjaukset on tehty, ohjelmakoodi hyväksytään. [2] 2.2. Tarkastusryhmä Tarkastusryhmä koostuu puheenjohtajasta, tarkastajista, alustajasta, sihteeristä ja tekijästä eli ohjelmoijasta. Jokainen ryhmän jäsen toimii Menetelmäraportti: Ohjelmakoodin tarkastaminen 5
mahdollisen muun tehtävän oheessa tarkastajana. Taulukossa 1 on kuvattu ryhmän eri jäsenten tehtävät. [2] Rooli Puheenjohtaja Tarkastaja Alustaja Sihteeri Tekijä Tehtävä Puheenjohtaja suunnittelee tarkastuksen ja valitsee tarkastusryhmän. Puheenjohtaja johtaa tarkastusprosessia ja on vastuussa, että tarkastus suoritetaan kunnolla. Ryhmän jokainen jäsen toimii tarkastajana. Tarkastajat ovat vastuussa virheiden löytämisestä valmistautumisvaiheessa ja tarkistustilanteessa. Alustajan tehtävä on tulkata ohjelmakoodia tarkastutilaisuudessa tarkastajille. Alustaja on usein ohjelmakoodin tekijä. Sihteeri kirjaa ylös tarkastuksessa löytyneet virheet. Sihteeri on usein ohjelmakoodin tekijä. Tekijä on ohjelmakoodin kirjoittaja. Tekijän tehtävänä on kertoa toteutuksesta muille tarkastajille ja vastata tarkastajien ohjelmakoodia koskeviin kysymyksiin. Tekijä tekee vaaditut korjaukset ohjelmakoodiin tarkastuksen jälkeen. Taulukko 2.1: Tarkastusryhmän roolien tehtävät Menetelmäraportti: Ohjelmakoodin tarkastaminen 6
3. Tarkastusmenetelmän hyötyjä Tarkastusten tehokkuus perustuu siihen, että virheet löydetään ajoissa. Ilman tarkastuksia suurin osa virheistä löytyy todennäköisimmin testattaessa valmista ohjelmaa. Tällöin virheen korjaamiseen tarvittava työmäärä on suurempi kuin jos virhe olisi löytynyt aikaisemmin. On arvioitu, että tarkastamalla löytyy jopa 80% kaikista virheistä, joka johtaa vähempään työmäärään testauksessa. Ohjelmoija myös tekee tietoisesti parempaa ohjemakoodia kun hän tietää, että se tarkastetaan. [1] Bell-Northern Researchissa tehtyjen tutkimusten perusteella ohjelmakoodista löytyy 0.8-1 virhettä/henkilötyötunti. Testaamalla virheitä löytyy 2-4 kertaa hitaammin, koska testattaessa havaittu virhe on vielä paikallistettava ohjelmakoodista ja tulkittava miksi ohjelmakoodi on virheellinen. Tarkastettaessa virheen paikka on heti selvä. [1] Menetelmäraportti: Ohjelmakoodin tarkastaminen 7
4. Menetelmän soveltaminen projektissa Projektiryhmällä oli tarkoituksena soveltaa ohjelmakoodin tarkastusmenetelmää projektin T3-vaiheessa. Tarkastusten organisointi osoittautui kuitenkin yllättävänä työlääksi ja tarkastuksia suoritettiinkin vain kerran. Ohjelmakoodin tarkastus saatiin sovituksi pidettävän 21.3.2002. Tarkastuksen kohteeksi valittiin editorin [3] paketin: com.digita.digitv keskeisimmät kohdat. Ohjelmakoodi jaettiin tarkastusryhmän jäsenille hyvissä ajoin 18.3.2002. Varsinaisen tarkastustilaisuuden alussa jouduttiin toteamaan, että kyseisiin ohjelmakoodeihin oli tullut tarkastukseen valmistautumisen aikana vielä niin paljon muutoksia, että tarkastaminen olisi ollut turhaa työtä. Siksi päätettiin muuttaa suunnitelmia ja kokeilla tarkastuksen pitämistä wwwympäristössä hieman hypercode-prosessia [4] mukaillen. Tarkastusta varten luotiin projektin ryhmätyöympäristöön keskustelusäie, johon löydetyt virheet raportoitiin. 4.1. HyperCode-ohjelmakoodin tarkastusprosessi HyperCode on www-pohjainen ohjelmakoodin tarkastusjärjestelmä. Järjestelmässä tarkastettava materiaali jaetaan tarkastusryhmälle sähköisessä muodossa. Varsinaista tarkastuskokousta ei pidetä, vaan tarkastajat tarkastavat ohjelmakoodia yksin ja raportoivat löytämistään virheistä muille tarkastajille internet-selaimella hypercode-järjestelmään. [4] Menetelmäraportti: Ohjelmakoodin tarkastaminen 8
5. Lähdeluettelo [1] Ilkka Haikala ja Jukka Märijärvi. Ohjelmistotuotanto, 7. uudistettu painos, Talentum Media, 2001. [2] National Aeronautics and Space Administration. Software formal ispections guidebook, 1993. [3] Pekka Koskinen. Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset: Tekninen määrittely, 2002. [4] Perpich, Perry, Porter, Votta, Wade. Anywhere, Anytime Code Inspections: Using the Web to Remote Ispection Bottlenecks in Large-Scale Software Development, ICSE 97 Boston MA USA, 1997. Menetelmäraportti: Ohjelmakoodin tarkastaminen 9