SEPA päiväkirja. Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T Ohjelmistoprojekti I

Transkriptio

1 SEPA päiväkirja Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T Ohjelmistoprojekti I

2 Sisällysluettelo Sisällysluettelo Johdanto Menetelmän käyttö Yleinen suunnitelma Käyttöönottosuunnitelma Kokemukset ja muutokset Suunnitteluvaihe Iteraatio Iteraatio Yhteenveto Lähteet...8

3 1. Johdanto Staattisilla menetelmillä tarkoitetaan tässä ohjelmiston analyysiä suorittamatta kuitenkaan sitä. Yksi staattinen analysointitapa on esimerkiksi koodin katselmointi, jolla pyritään vähentämään ohjelmistosta löytyvien virheiden ja mahdollisien ongelmakohtien määrää. SEPAmme keskittyy juuri koodista löytyvien ongelmien vähentämiseen ohjelmassa. Valitsimme tämän aiheen koska pääsemme sen kautta tutustumaan kaikkeen projektia varten kirjoitettavaan lähdekoodiin, sekä työkaluihin ja menetelmiin joilla sitä voi analysoida. Näin saamme laajan kokonaiskuvan toteutettavasta ohjelmistosta. Samalla pääsemme tutustumaan toisten ohjelmointityyleihin ja mahdollisesti opimme jotain uutta. Uskomme että staattisten metodien käytöstä voi olla hyötyä tässä projektissa ja että se on kokeilemisen arvoinen tekniikka. 2. Menetelmän käyttö 2.1 Yleinen suunnitelma Kirjoitetun lähdekoodin katselmointia pyritään suorittamaan mahdollisimman pian koodin valmistumisen jälkeen, mutta viimeistään kummankin iteraation loppuvaiheessa pyritään käymään priorisoidusti suurin osa iteraation aikana kirjoitetusta lähdekoodista katselmoimalla (walkthrough, Object-Oriented & Classical Software Engineering, s 142 ->). Katselmoinnin valmistelevat Halttunen ja Närjänen. Siihen osallistuu edellämainittujen lisäksi katselmoitavan lähdekoodin kirjoittanut kehittäjä sekä testaaja. Katselmoinnissa käytetään apuna Borland Togetherin analysointityökaluja potentiaalisesti ongelmallisten luokkien ja metodien tunnistamiseen. Lisäksi mahdollisten ongelmakohtien löytämiseen voidaan käyttää JLint ohjelmaa. Katselmoinneissa vastuun pystyy jakamaan esimerkiksi 4 eri tavalla (Practical Software Testing, s.318): Katselmoinnin vetäjä suunnittelee ja valmistelee katselmoinnin. Kirjuri kirjoittaa ylös löytyneet bugit tai ongelmakohdat. Esittelijä (tässä tapauksessa koodin kirjoittaja) esittelee koodin ja hoitaa koodin korjaamisen, jos siitä löytyy ongelmia. Katselmoija valmistautuu katselmointiin ja arvioi esitettävää koodia (ei kuitenkaan esittelijää). Koska käytettävissä oleva aika on rajattua, voidaa käyttää Borland Togetherin työkaluja sekä JLint ohjelmaa ongelmien etsimiseen kaikesta kirjoitetusta koodista myös "katselmuksien" ulkopuolella. 2.1 Käyttöönottosuunnitelma Katselmointien valmistelu: Laatuvastaava päättää katsemoitavat koodiosiot. SepaTiimi (Mikko Närjänen ja Mikko Halttunen) tekee suosituksia laatuvastaavalle käyttäen suunnitelmassa mainittuja työkaluja potentiaalisesti ongelmallisten luokkien ja metodien etsimiseen. Esittelijää voidaan myös kuulla päätöksenteossa. Koodiosiot pyritään valitsemaan siten että kaikkien kehittäjien koodia katselmoidaan (vain yhden kehittäjän koodia yhdessä katselmoinnissa). Katselmoinnit pyritään keskittämään monimutkaisiin metodeihin ja luokkiin sekä alueille, joita JUnit-testit eivät kata. SepaTiimi ja Laatuvastaava valitsevat keskuudestaan johtajan. Sen jälkeen päätetään ketkä osallistuvat

4 katselmointiin ja valitaan kirjuri. Johtaja ja SepaTiimi valmistelevat listat kohdista joita eivät katselmoitavassa koodissa ymmärrä ja kohdista joiden uskovat olevan virheellisiä Osallistujien roolit: Johtaja (leader) Laatuvastaava tai SepaTiimin jäsen. Suunnittelee katselmoinnin, valmistelee listat tarkistettavista asioista yhdessä SepaTiimin kanssa, vastaa siitä että kaikki katselmointii osallistuvat ovat valmistautuneet asianmukaisesti, johtaa katselmoinnin, tekee katselmointiraportin (tarvittaessa SepaTiimin avustuksella) ja vastaa siitä että havaitut epäkohdat korjataan. Kirjuri (recorder) Testaaja tai SepaTiimin jäsen. Kirjaa muistiin löydetyt epäkohdat, muut löydöt ja mahdolliset suositukset. Muistiin kirjatut asiat tulee kirjoittaa riittävällä tarkkuudella (esimerkiksi tiedosto, rivi, ja tietoa ongelmasta), että kohtaa korjaava henkilö löytää kohdan nopeasti ja saa selville nopeasti, että mitä kyseisessä kohdassa oli vialla. Esittelijä (reader) Katselmoitavan koodin kirjoittanut henkilö. Esittelee katselmoitavan koodin sekä korjaa havaitut epäkohdat katselmoinnin jälkeen. Katselmoijat (reviewers) Valmistautuvat katselmointiin tutustumalla katselmoitavaan koodiin, osallistuvat katselmointiin, arvioivat katselmoitavan koodin ja tarvittaessa osallistuvat havaittujen epäkohtien korjaamiseen katselmoinnin jälkeen Tuloksiin reagointi: Jos katselmoinnissa ei löytynyt mitään korjattavaa, merkitään kyseinen kohta koodista katselmoiduksi ja kyseistä koodipätkää ei katselmoida uudestaan muulloin kuin koodin muuttuessa. Jos katselmoinnin aikana ilmenee korjattavaa, korjaa kyseisen koodin kirjoittanut henkilö koodin mahdollisimman pikaisesti ja lähettää jollekkin katselmoinnista mukana olleista henkilöistä kyseisen koodin kohdan tarkastettavaksi. Jos katselmoijan mielestä koodissa on edelleenkin vikaa, voi hän kutsua uuden täyden katselmoinnin koolle. 3. Kokemukset ja muutokset 3.1 Suunnitteluvaihe Suunnitteluvaiheessa emme käyttäneet staattisi menetelmiä, koska tällöin koodia ei vielä ollut, mitä olisi voinut testata. 3.2 Iteraatio 1 SEPA:n suunnitelma oli kirjoitettu liian korkealla tasolla, joten joduimme tarkentamaan useita kohtia. Lisäksi suunnitelmamme käyttöönotosta ei ollut ehkä paras mahdollinen sillä tavalla, että sysäsimme itsellemme erittäin paljon lisätyötä. Järkevämpää olisi ollut kouluttaa muut ryhmäläiset katselmoimaan ja muuttaa käytäntöä siten, että koodin kirjoittanut ilmoittaa qa:lle, joka määrää 2 muuta henkilöä katselmoimaan koodia. Totesimme että katselmoinnit ovat varsin työläitä toteuttaa. Tämä johtuu suurelta osin siitä että niihin on syytä valmistautua kunnolla tutustumalla katselmoitavaan koodiin, jos aikoo löytää muita kuin ohjelmointityyliin ja kommentointiin liittyviä puutteita.

5 3.2.1 Tuloksia Tilastoja ohjelmallisesti löydetyistä ongelmista. Nämä eivät loppujen lopuksi läheskään kaikki olleet virheitä: Ongelma Määrä Selitys Maagisia numeroita 133 Kenttiä, joiden pitäisi olla lokaaleja 26 Koodityyli, turhia puolipisteitä: 2 Hankalia if-lauseita: 5 Turhia lokaaleja muuttujia: 2 Tyhjiä try-catch blokkeja: 3 javadoc-ongelmia: 695 käyttämättömiä muuttujia: 99 JSDK 5.0 spesifisiä ongelmia: 43 Suorituskykyongelmia: 9 Mahdollisia bugeja: 30 Näistä 4 oli oikeasti. (3 nullpointer-ongelmia sekä 1 settermetodi, jossa asetettiin aina false

6 Tilastoja katselmoinneissa löydetyistä ongelmista. Tilasto on laskettu arvioimalla katselmoinneissa merkityistä ongelmista ja ongelmista, joita ei merkitty. Tällaisia olivat runsaat määrät this-ongelmia sekä javadoc-ongelmia: Ongelma Määrä Selitys Javadoc -ongelmia ja -puutteita: 35% Kommenttiongelmia ja -puutteita: 20% Koodin tyyli (this vittaukset, ja liian pitkät rivit tms.): 15% Maagisia numeroita: 15% Metodeilla ja muuttujilla väärät (puuttuvat tai liian suuret) näkyvyydet: 5% Ongelmia luokkarakenteessa: 5% Oikeita bugeja: 3% Hankalia if-lauseita: 2% Katselmoinneissa siis löytyi erittäin paljon ongelmia ja tuli todistettua, että katselmoinneista on hyötyä. Huonon suunnitelman takia katselmointisepan kirjoittajille tuli paljon työtä tässä vaiheessa, mutta senkin voi laskea opetustilanteeksi sillä, että nyt jokainen henkilö projektiryhmästä on päässyt osallistumaan katselmointehin ja tietää mitä siellä tulisi tapahtua. Tällöin voimme siirtää vastuuta seuraavassa iteraatiossa myös muulle projektiryhmälle. 3.3 Iteraatio 2 Toisessa iteraatiossa katselmointeja suoritettiin koko iteraation ajan, että koodin kirjoittaja muisti hieman paremmin kirjoitetun koodin. Tämä tapa oli selvästi parempi kuin yrittää käydä läpi monen luokan koodia iteraation lopussa. Muutoksena suunnitelmiin toisessa iteraatiossa katselmoinneissa ei enää ollut mukana kuin 3 henkilöä yleensä - koodin kirjoittaja, katselmoinnin kirjuri sekä johtaja. Kirjuri ja johtaja toimivat myös katselmoijina. Koska koodikatselmoinnit olivat tulleet kaikille asianosaisille tutuiksi ensimmäisessä iteraatiossa, ne saatiin toteutettua hiukan epämuodollisemmin ja sujuvammin. Esimerkiksi katselmoitavien luokkien valinta tehtiin katselmoijien kesken johtoryhmän antamien suuntaviivojen mukaisesti. Valinnassa annettiin paljon painoarvoa koodin kirjottaneen kehittäjän näkemyksille. Toisessa iteraatiossa kokeiltiin testinä myös katselmoida vain muuttuneita koodin kohtia, mutta tämä

7 osoittautui erittäin hankalaksi kun katselmoitavasta koodista ei edes koodin kirjoittaja nähnyt riippuvuuksia ja kokonaisuutta. Tämä menetelmä tiputettiin käytöstä heti seuraavaan katselmointiin. Koodin muuttuneita kohtia pystyy selvästikin käyttämään vain viitteenä siitä, että mitä voisi katselmoida Tuloksia Katselmointien tuloksia: Ongelma Määrä Selitys Javadoc -ongelmia ja -puutteita: 10% Kommenttiongelmia ja -puutteita: 11% Koodin tyyli (this vittaukset, ja liian pitkät rivit tms.): 6% Maagisia numeroita: 25% Metodeilla ja muuttujilla väärät (puuttuvat tai liian suuret) näkyvyydet: 3% Ongelmia luokkarakenteessa: 15% Oikeita bugeja: 30% Hankalia if-lauseita: 0% 3.4 Yhteenveto Toisessa iteraatiossa bugeja löytyi: Valpas Virheitä Rivejä Simulaattori Virheitä Rivejä 2 424

8 Analysaattori Virheitä Rivejä Mielenkiintoista ensimmäisen ja toisen iteraation tuloksissa on se, että ensimmäisessä iteraatiossa selvästi oli enemmän javadoc ja kommentointiongelmia sekä ongelmia koodin tyylissä. Toisessa iteraatiossa taas löytyi selvästi enemmän "oikeita" bugeja, joihin lasketaan esimerkiksi mahdolliset nullpointer-virheet, ajatusvirheet tai koodi, joka ei olisi toiminut niin, miten sen olisi tarkoitus toimia. Katselmointien tuloksista voisi nopeasti katsoa, että toisen iteraation aikana olisi kirjoitettu huonompilaatuista koodia, mutta uskomme, että saimme selvästi enemmän irti koodikatselmoinneista toisessa iteraatiossa kuin ensimmäisessä, kun katselmointiprosessi oli tuttu ja osallistujat olivat valmistautuneet paremmin katselmointeihin. Uskomme myös, että kehittäjät kirjoittivat toisessa iteraatiossa tyyliltään paremmin projektin vaatimuksia vastaavaa ja paremmin kommentoitua koodia, kun asiaan oli kiinnitetty huomiota ensimmäisessä iteraatiossa. Ilman katselmointeja olisi koodin sekaan jäänyt varmasti ongelmakohtia, jotka olisivat saattaneet tulevaisuudessa aiheuttaa vakaviakin ongelmia. Erityisesti katselmointien hyöty tuli selvästi esille siten, että koodin kirjoittaja esitteli koodia katselmoijille, jolloin koodin kirjoittaja palasi kirjoittamaansa koodiin ja tuli selittäessään miettineeksi, mitä koodissa tehdään tai tulisi tehdä, jolloin virheellisesti toimivat kohdat tulivat esille. 4. Lähteet Schach, Object-oriented and Classical Software Engineering, McGraw Hill 2005, s Ilene Burnstein, Practical Software Testing, Springer 2003, s , (Walkthrough)