Sivu 1 (5) SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T Versio Päiväys Tekijä Kuvaus 0.1 27.10.2004 Timo Sallinen Ensimmäinen versio 1.0 31.10.2004 Timo Sallinen Korjauksia, lisäyksiä Johdantoon 1.1 1.11.2004 Risto Kunnas Korjauksia, lisätty IEEE-viite 2.0 30.11.2004 Timo Sallinen I1-vaiheen kokemukset 2.1 07.02.2005 Risto Kunnas I2-vaiheen katselmoinnin kokemukset 2.2 08.02.2005 Timo Sallinen Lisätty suunnitelmaa DE-vaiheen osalta 2.3 10.03.2005 Timo Sallinen Päivitystä DE-vaiheen osalta 2.4 14.03.2005 Timo Sallinen Yhteenveto 2.5 15.03.2005 Risto Kunnas Lisätty kommentteja Sisällysluettelo 1 Johdanto...1 2 SEPA harjoittelu käytännössä... 1 3 Kokemukset ja muutokset... 2 3.1 Vaihe PP projektin suunnittelu...2 3.2 Vaihe I1 Implementaatio 1... 2 3.3 Vaihe I2 Implementaatio 2... 3 3.4 Vaihe DE Toimitus & Viimeistely... 4 3.5 Yhteenveto...4 4 Viitteet... 5 1 Johdanto Valitsemamme SEPA-aihe on ohjelmakoodin läpikäynti katselmointimenetelmällä ilman koodin suorittamista. Tarkempi kuvaus menetelmästä ja sen eduista verrattuna funktionaaliseen eli ohjelmakoodia suorittamalla tapahtuvaan testaukseen löytyy kurssin T-76.613 Ohjelmistojen testaus ja laadunvarmistus kurssimateriaalista[1]. Testauskurssilla käytiin läpi katselmointitekniikkaa, ja se tuntui tehokkaalta menetelmällä. Ajatus formaalista dokumentin tai koodin läpikäynnistä tuntuu kiinnostavalta ajatukselta. Yleisesti pelkällä funktionaalisella testauksella ei pystytä testaamaan kattavasti ohjelman toimintaa, kaikkia suorituspolkuja ei saada parhaimmillaankaan ajettua laajoissa järjestelmissä. Katselmointimenettelyssä havaitaan myös sovelluskoodin laatuun liittyviä virheitä, esim. huonot ohjelmointikäytännöt, ei pelkästään suorituksenaikaisia virheitä. 2 SEPA harjoittelu käytännössä Koodin katselmointia käytetään toiminnaltaan monimutkaisempien moduulien testauksessa, sekä moduulien välisten rajapintojen testaukseen. Tarkempi arvio siitä, mihin koodikatselmointia käytetään, tehdään arkkitehtuurisuunnittelun ja testaussuunnittelun yhteydessä.
Sivu 2 (5) Katselmoinnin kulku on kuvattu projektisuunnitelmassa, ja se noudattaa mahdollisuuksien rajoissa IEEE-standardia katselmoinnista [2]. Koodin katselmoinnissa katselmoitavat osat rajataan maksimissaan 500 koodiriviin. Kaikkea koodia ei käydä läpi vaan katselmoitavat ohjelmakooditiedostot valitaan automaattisilla työkaluilla (kuten CCCC, JavaNCSS) tehtyjen raporttien perusteella. Katselmoitava ohjelmakoodi käydään läpi formaalissa katselmointitilaisuudessa, jonka tulokset merkitään normaalin menettelyn mukaisesti virhetietokantaan. 3 Kokemukset ja muutokset 3.1 Vaihe PP projektin suunnittelu Koodikatselmointeja ei käytetty suunnitteluvaiheessa. 3.2 Vaihe I1 Implementaatio 1 SEPAn tarkoituksena oli alun perin ohjelmakoodin testaaminen staattisilla metodeilla, erityisesti katselmoimalla. Tässä vaiheessa projektia ei kuitenkaan ollut sellaista koodia, jota olisi ollut järkevä katselmoida, sillä kaikki koodi oli prototyyppimäistä. Katselmointia suoritettiin kuitenkin mm. testitapauksille sekä tekniselle spesifikaatiolle. Katselmoinneissa ei ohjeistuksesta huolimatta päästy kovinkaan lähelle formaalia katselmointiprosessia [2]. Osasyynä tähän oli siinä, että katselmoitavat dokumentit, varsinkin tekninen spesifikaatio, olivat osittain keskeneräisiä. Suuri osa dokumentoitavista asioista oli jollain tavalla auki, ja katselmointitilaisuudesta muodostui tällöin aivoriihi. Oikeampi tapa olisi ollut kirjata puuttuva asia ja määrittää sille myöhemmin vastuuhenkilö tai erillinen aivoriihi. Lisäksi katselmoinneissa ajauduttiin välillä turhaan keskusteluun aiheesta, joka olisi vain voitu merkitä tarkennusta kaipaavaksi. Katselmoinnit pyrittiin pitämään ajan säästämiseksi pienissä ryhmissä, mikä tuntui aluksi järkevältä ajatukselta. Pienessä ryhmässä (3-4 henkilöä) formaali katselmointimenetelmä ei kuitenkaan ole niin tehokas ajansäästäjä kuin suuremmassa (7 henkilöä tai enemmän). Pienessä ryhmässä on mahdollista toimia vapaammin, ilman, että kenenkään aikaa menee hukkaan. Kaikille katselmointiin osallistujille ei ehkä näin muodostunut oikeaa kuvaa katselmoinnin hyödyllisyydestä, ja siitä, miksi katselmoinnin kulku on niin tiukasti määritelty. Virheitä katselmointimenetelmällä löydettiin paljon, mutta vertailudataa ei juuri ole, jotta voitaisiin sanoa tarkemmin, kuinka hyvin katselmointi onnistui. Seuraavissa vaiheissa pyritään käyttämään vertailudatana muita testimenetelmiä. Dokumenteissa voidaan harkita ns. error seeding tekniikkaa, eli tehdään dokumentteihin tahallaan virheitä, ja katsotaan kuinka moni näistä löydetään. Keskimäärin katselmointitilaisuudet kestivät reilun tunnin, ja katselmointeihin osallistujat käyttivät valmistautumiseen hiukan alle kaksi tuntia. Katselmoitavan dokumentin vastuuhenkilöt eivät kuitenkaan juuri valmistautuneet katselmointiin. Katselmointimenetelmä tuntuu sopivan hyvin dokumenttien virheiden etsimiseen, ja se on oikeastaan ainoa keino tekstinkäsittelyohjelman oikoluvun lisäksi. Dokumenteista ei kuitenkaan aina tiedä, että mitä siinä tulisi olla, kun taas ohjelmakoodista on yleensä olemassa jokin speksi, josta näkee mitä ohjelmakoodin tulisi tehdä. Joissain tapauksissa tarkistuslistat, joita käytettiin teknisen spesifikaation katselmoinnissa, dokumenttipohjat ja standardit auttavat hieman.
Sivu 3 (5) 3.3 Vaihe I2 Implementaatio 2 Katselmointitilaisuus 21.01.05 Katselmointitilaisuudessa oli tarkoituksena arvioida Join toimenpiteen toteutusta. Pääpaino oli dokumentoinnin ja luettavuuden parantaminen. Tämä nähtiin tärkeäksi, sillä Join oli tähän mennessä pisimmälle kehitetty toimenpide, ja sen dokumentointi ja koodin tyyli olisi esimerkkinä muille toimenpiteille. Myös mahdollisten bugien etsiminen koodista oli yksi katselmoinnin tavoitteista. Katselmoinnin kattavuutta päätettiin arvioida ns. error seedin eli virheiden kylvö menetelmällä. Toimenpiteen vastuuhenkilö Teemu teki tahallisesti toimenpiteeseen kolme virhettä, joiden avulla voidaan arvioida, kuinka monta prosenttia olemassa olevista virheistä löydettiin. Virheiden kylvöstä tiesivät Teemu sekä Risto, muille katselmointiin osallistuneille ei asiasta kerrottu etukäteen. Katselmoinnissa tehtiin useita huomioita paremmasta ohjelmointityylistä, puutteellisesta kommentoinnista, sekä yleisesti eri komponenttien käyttötavoista. Varsinaisia virheitä löydettiin vain muutama, jotka liittyivät erikoistilanteisiin, joita ei vielä oltu funtionaalisesti missään vaiheessa ajettu tai testattu. Erikoisesti katselmoinnin aikana paljastui virhe eräässä toisessa toimenpiteessä (Export) mahdollisesti olevassa väärin käytetystä metodikutsusta, kun heräsi keskustelua, mihin erästä metodia tulee käyttää. Yhtään kylvettyä virhettä ei kuitenkaan löydetty. Tähän on monia syitä: Katselmoijat eivät olleet harjaantuneet katselmoimaan, katselmoitavaa koodia oli enemmän kuin on suositeltavaa, kylvetyt virheet olivat sellaisia jotka yleensä huomaa ajon aikana ja joita ei normaalisti osaa etsiä ellei siihen ole syytä sekä koodin osittain vaikea luettavuus. Katselmointitilaisuuden perusteella näyttäisi siltä, että tietyn tyylisiä virheitä on vaikeaa ainakin harjaantumattoman ihmisen vaikea löytää, ellei ole jotain syytä olettaa, että jossain kohtaa koodia on virhe. Toisaalta, sellaisia virheitä, joita on vaikea simuloida koodia ajamalla, löytyvät katselmoimalla vähemmällä vaivalla. Aivan mitä tahansa koodia ei kannata katselmoida. Error seedingin käyttö sen sijaan yllätti positiivisesti, sillä ilman tämän kaltaista mittaria katselmointitilaisuuden onnistumisesta olisi hyvin vaikea sanoa mitään. Nyt ei jäänyt kattavuudesta turhan yltiöpositiivista kuvaa, mikä on usein vaarana, jos virheitä kuitenkin löydetään. Metriikkojen kerääminen Vaiheen lopussa otettiin käyttöön Eclipsen Metrics-plugin [3]. Plugin mahdollistaa reaaliaikaisen koodin seurannan, ja erilaisten statiikkojen keräämisen. Näitä ovat muunmassa: Koodin syklinen kompleksisuus Ylipitkät metodit Metodit, joiden parametrimäärä ylittää suositeltavan rajan Lausekkeiden suuri määrä metodissa Koheesion puute tai liialliset kytkökset Näiden perusteella voidaan arvioida luokkakohtaisesti koodin laatua. Testien perusteella mitään todella merkittäviä laadullisia ongelmia koodissa ei havaittu. Selkeästi yleisin ongelma oli ylipitkät metodit, mutta näissäkin rivimäärä oli keskimäärin reilusti alle 100. Kokemukset pluginin käytöstä
Sivu 4 (5) olivat varsin positiivisia, automaattinen koodin arvointi helpottaa tyypillisten ongelmakohtien löytämistä koodista. Toki näiden tulosten arviointi vaatii ihmissilmää. DE-vaiheessa suoritetaan vielä yksi koodikatselmointi, katselmoinnin kohde valitaan em. metriikkojen perusteella. 3.4 Vaihe DE Toimitus & Viimeistely Alkuperäisestä suunnitelmasta poiketen uutta muodollista koodikatselmointitilaisuutta ei enää järjestetty. Tähän oli syynä se, että yleisesti painopiste siirtyi järjestelmätestaukseen, eikä aikaisempien kokemusten perusteella staattisesta katselmoinnista ollut juurikaan hyötyä koodin osalta. Järjestelmän yleisen luonteen takia yksittäisten luokkien tai koodilohkojen testaaminen on jossain määrin ongelmallista ja vain järjestelmätestauksella voidaan saada riittäviä tuloksia. Projektin aikana löydetyt virheet olivat suureksi osaksi virheitä koko prosessissa tai ongelmia siinä, ettei järjestelmä toipunut poikkeustilanteista esim. lähdedatan suhteen. Näiden havaitseminen muuten kuin ajonaikana on hankalaa. Sinänsä hyväksi havaittua dokumentaation katselmointia ei ollut mahdollista suorittaa, koska dokumentaatioon tuli vielä merkittäviä muutoksia viime metreille asti. I2-vaiheessa käyttöön otettua Eclipsen Metrics-pluginia käytettiin yleiseen koodin laadun parantamiseen. Tämän näyttämien varoitusten perusteella korjattiin projektista ylipitkiä metodeja ja poistettiin turhia kytkentöjä. Menettely helpottaa laajassa projektissa mahdollisten ongelmakohtien löytämistä, kokemuksen perusteella virheiden todennäköisyys kasvaa ylipitkissä ja huonosti suunnitelluissa metodeissa. Lisäksi DE vaiheessa käytiin pintapuolisesti läpi ohjelmakoodin kommentointi. Kommentoinnin ohella pyrittiin kiinnittämään huomiota monimutkaisiin ja mahdollisesti myös virhealtiisiin rakenteisiin. Kommentointia tuntui olleen riittävästi, mutta Javadoc kommentit puuttuivat monesta paikasta. 3.5 Yhteenveto Kokemusten perusteella formaali katselmointi sopii verrattain hyvin dokumentaation läpi käymiseen. Haasteena tässä on se, että katselmointi lipsuu helposti aivoriiheksi, jos formaalia tekniikkaa ei saada ylläpidettyä. Tällöin tilaisuudesta ei saada niin paljon irti. Koodin katselmoinnin kannalta ongelmaksi muodostui arvioijien kokemattomuus, virheiden löytäminen vaatii harjaantumista. Sen sijaan laadullisesti virheet ja puutteet kommentoinnissa löytyvät helpommin. Oleellista on myös koodin luonne, jos potentiaaliset virheet ovat luonteeltaan sellaisia, jotka tulevat helposti esille ajonaikana, ei katselmointi liene paras mahdollinen menetelmä testaamiseen. Jatkossa staattista arviointia on varmasti mahdollista hyödyntää. Erityisesti kokemattomien ohjelmoijien kyseessä olleessa katselmoinnilla voitaisiin eliminoida huonoja ratkaisuja tai mahdollisesti väärin opittuja tekniikoita. Kurssin puitteissa tätä mahdollisuutta ei ollut. Dokumentaation läpikäynnissä saavutetaan kokemusten perusteella merkittävästi parempi lopputulos kuin pintapuolisella silmäilyllä, joka ei ohjaa muodolliseen ja huolelliseen virheiden etsimiseen. Katselmoinnissa kannattaa keskittyä kriittisimpiin osiin. Ongelma on tällöin krittisimmän osan määrittely. Tässä SEPA:ssa kokeilluilla työkaluilla se on mahdollista, mutta tämän projektin
Sivu 5 (5) puitteissa ei oikein löytynyt sellaista kriittisistä kriittisintä osaa, vaan kaikki toiminnallisuus oli riippuvaista toisista, joten järkevän katselmointikohteen löytäminen oli lähinnä arpapeliä. Katselmoinnilla ei voida kuitenkaan korvata funktionaalista testausta eikä päinvastoin: molemmissa löytyy erityyppisiä virheitä. 4 Viitteet [1] Juha Itkonen. 2004. Reviews and Inspections Lecture Slides. [Viitattu: 27.10.2004] Saatavissa: http://www.soberit.hut.fi/t-76.613/2004/material/t76613_lecture7_04.pdf [2] IEEE Standard for software reviews. Document number IEEE 1028-1997 [3] http://www.teaminabox.co.uk/downloads/metrics/