AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 7
Dokumenttihistoria Muutoshistoria Revision päiväys: 1.11.2004 Seuraavan revision päiväys (päiväys) Revision Numero Revision Päiväys Yhteenveto muutoksista Muutokset merkitty 0.1 21.10.04 Ensimmäinen versio (kuvaus menetelmästä). (Ei) 0.2 01.11.04 Päivitetty dokumenttia johdannon ja rakenteen osalta. (Ei) 0.3 28.11.04 Lisätty I1-vaiheen teksti (Ei) Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Rauli Ikonen Pasi Kallioniemi Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Seppo Sahi Tehtävä Mentor Aihe: RI & PK Sivu 2 of 7
Sisällysluettelo 1. Esittely...4 1.1 Tarkoitus...4 1.2 Menetelmän kuvaus...4 1.3 Viitteet...5 2. Käyttöönotto...6 3. Kokemukset ja muutokset...7 3.1 PP-vaihe...7 3.2 I1-vaihe...7 3.3 I2-vaihe...7 3.4 FD-vaihe...7 3.5 Yhteenveto...7 Aihe: RI & PK Sivu 3 of 7
1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata AgilElephant projektissa käytettyä SEPA (Software Engineering Practice Assignment)-menetelmää. Menetelmä esitellään ja perustellaan luvussa 1. Luku 2 sisältää suunnitelmat menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta projektin tarpeisiin. 1.2 Menetelmän kuvaus SEPA aiheenamme on staattiset metodit koodianalysoinnnissa. Staattinen koodianalysointi tarkoittaa ohjelmakoodin analysointia ilman että koodi ajetaan. Mahdollisia analysoitavia asioita ovat koodin laatu (rakenne, koko, viittaukset moduulista toiseen jne..), ohjelmakoodin virheet sekä koodin oikeellisuus tehtävien toiminnallisuuksien kannalta. Yleisesti staattista koodianalyysiä voidaan tehdä automatisoidusti työkaluilla tai ihmisten tekemänä, esim. koodikatselmuksilla. Automatisoidussa staattisessa analysoinnissa käytetään työkaluja jotka laskevat erilaisia mittareita ohjelmakoodista ja luovat niistä raportteja varoittaen ohjelmakoodin huonosta laadusta tai virheistä. Käytettyjä mittareita ovat mm. metodissa/luokassa olevan koodin rivimäärä, yhden luokan viittausten määrä moduulista toiseen, sekä McCaben syklomaattinen kompleksisuus (ohjelmakoodin haarautumisluku). Myös bugeja voidaan analysoida koodista ohjelmilla jotka esim. ensin tekevät koodista vuokaavion ja analysoivat tämän avulla onko mahdollisuuksia ikuisiin silmukoihin tai rinnakkaisuusongelmiin. Raporttien tekeminen ei ole ainoa vaihtoehto automatisoinnille, sillä nykyisin osa työkaluista pystyy integroitumaan käytettävään kehitysympäristöön ja antamaan ohjelmoijalle suoraan palautetta hänen kirjoittaessaan koodia. Koodia ei välttämättä voida analysoida kattavasti automatisoituna. Tällöin analysointiin käytetään ihmisiä. Koodikatselmus on tekniikka jolla pystytään levittämään tietämystä koodien toiminnasta usealle henkilöille projektissa, samalla varmistaen että tehty toiminnallisuus on selkeä sekä toimiva. Uuden ominaisuuden katselmoinnissa valitaan joukko ihmisiä tekemään katselmointia. Tällöin henkilö(t) käyvät tehdyn ominaisuuden lävitse tekijän opastuksella, ja he esittävät tekijälle kysymyksiä epäselvistä kohdista ja kommentoivat koodia. Toiminta perustuu siihen että tekijästä tulee helposti sokea omille virheilleen ja on mahdollisesti jumittunut tottumuksesta johonkin huonoon koodaustyyliin, joten ulkopuolisten ihmisten antama palaute toimii kehittävänä tekijänä virheiden paljastuksen ohella. Valitsimme tämän aiheen siksi että koimme sen tarjoavan hyvän ja realistisen mahdollisuuden parantaa ohjelmakoodin laatua tällä kurssilla tehtävässä projektissa. Lisäksi staattinen koodianalysointi on mielestämme mielenkiintoinen alue johon kumpikaan meistä ei ole vielä työelämässä päässyt tutustumaan. Toivomme että asia osoittautuu vaivan arvoiseksi ja tämän kurssin jälkeen osaamme soveltaa sitä työelämässä menestyksekkäästi. Aihe: RI & PK Sivu 4 of 7
1.3 Viitteet Staattinen analyysi: Finding faults in multi-threaded programs, Cyrille Artho 2001; http://artho.com/jlint/mthesis.pdf Koodikatselmukset: Practical Software Testing. Ilene Burnstein 2003. Aihe: RI & PK Sivu 5 of 7
2. Käyttöönotto Tulemme integroimaan staattisia koodianalysointityökaluja kääntöympäristöömme niin, että työkalut ajetaan automaattisesti päivittäisen käännöksen yhteydessä ja saadut tulokset liitetään kääntöjärjestelmän luomaan raporttiin. Järjestelmään integroitavat työkalut ovat FindBugs ja JavaNcss. Edellinen hakee koodista automaattisesti yleisiä ohjelmointivirheitä ja jälkimmäinen laskee koodiista kompleksisuustunnuslukuja. Lisäksi tulemme ajamaan satunnaisesti JLint-työkalua ja mahdollisesti Teaminaboxia. Näitä ei kuitenkaan integroida buildijärjestelmään. Sen lisäksi, että FindBugsin löytämät virheet korjataan, tullaan virheet myös kategorisoimaan asteikolla vähäinen (ei mahdollisesti lainkaan virhe), normaali ja vakava. Lisävirheiden löytämiseksi tulemme suorittamaan koodista kaksi kahden tunnin koodikatselmointia, toinen vaiheen I1 ja toinen vaiheen I2 lopussa. Katselmoinneissa löytyneet virheet kategorioidaan kuten automaattityökalujen löytämät virheet. Vaiheen I2 jälkeen tulemme analysoimaan löytyneet ongelmat, käyttäen pohjana koodin kompleksisuusmittareita: Korreloiko löytyneiden virheiden määrä suhteessa luokkien ja metodien kompleksisuuksiin. Ottaen huomioon kehitettävän järjestelmän suhteellisen pienen koon ja staattiseen koodianalyysiin käytettävissä olevan varsin rajallisen ajan, on mahdollista, että virheitä ei löydy niin paljon, että niistä voisi tehdä mielekästä tilastollista analyysiä. Jos näin käy rajoittuu menetelmän hyöty lähinnä koodin parempaan laatuun sekä raportointiin kokemuksista staattisista koodianalyysityökaluista yleensä. Virheiden korjaamisen ja kompleksisuuteen pohjautuvan analysoinnin lisäksi tulemme vaiheen I2 loppupuolella käyttämään noin neljä tuntia koodin refaktorointiin. Refaktoroitavat osat valitaan JavaNcss:n tuottamien kompleksisuusmittarien ja oman harkinnan pohjalta; refaktoroitavaksi päätyvät kompleksisuudeltaan suurimmat metodit mitkä vaikuttavat myös asianomaisista kaikkein vaikeaselkoisimmilta. Tälläkin pyritään luonnollisesti ohjelman laadun ja jatkokehityksen parannettavuuteen. Aihe: RI & PK Sivu 6 of 7
3. Kokemukset ja muutokset 3.1 PP-vaihe Staattisia menetelmiä ei sovellettu vielä tässä vaiheessa. 3.2 I1-vaihe I1-vaiheessa integroitiin sekä JavaNcss että FindBugs buildijärjestelmän osaksi. Järjestelmä ajaa molemmat työkalut joka yö normaalin käännöksen yhteydessä ja laittaa tulokset esille osoitteeseen http://bannedwagon.net/agil/reports/. Koska järjestelmän todellinen implementointi alkoi vasta iteraation aivan loppupuolella, ei tämän iteraation puitteissa vielä voitu tehdä mitään erityistä analyysiä virheistä tai luokkien kompleksisuuksista. Ainakin FindBugs kuitenkin osoitti jo hyödyllisyytensä löytämällä kolme todellista virhettä (SA, UwF, DE) sekä neljä validia huomautusta huonosta rakenteesta ja tehottomasta koodista (EI, EI2, Dm, RCN). Kaikkien löydettyjen varsinaisten virheiden vakavuusaste oli normaali. Kaksi rakennevirhettä (EI, EI2) esiintyi yhteensä 22 kertaa. (Tarkempi listaus virhekoodeista ja virheistä lisätään I2-vaiheessa.) I1-vaiheessa oli alkuperäisen suunnitelman mukaan myös tarkoitus suorittaa koodikatselmus. Johtuen implementaation myöhäisestä alkamisajankohdasta ei koodikatselmointia ehditty suorittaa tässä vaiheessa. I1-vaiheen koodikatselmus siirretään tästä johtuen I2-vaiheen puoliväliin ja I2-vaiheen loppuun suunniteltu katselmus suoritetaan FD-vaiheen puolivälissä. 3.3 I2-vaihe 3.4 FD-vaihe 3.5 Yhteenveto Aihe: RI & PK Sivu 7 of 7