1 010758002 Ohjelmistotuotanto - Tarkastukset ja katselmoinnit Versionhallinta Kevät 2004 Hanna-Kaisa Lammi LTY/Tite.

Esitys aiheesta: "1 010758002 Ohjelmistotuotanto - Tarkastukset ja katselmoinnit Versionhallinta Kevät 2004 Hanna-Kaisa Lammi LTY/Tite."— Esityksen transkriptio:

1 1 010758002 Ohjelmistotuotanto - Tarkastukset ja katselmoinnit Versionhallinta Kevät 2004 Hanna-Kaisa Lammi LTY/Tite

2 2 Sisältö Terminologiaa Tarkastukset Tarkastusmenettelyn vaiheet Ongelmia Versionhallinta (SCM)

3 3 Laadunvarmistukseen liittyviä termejä

4 4 Terminologiaa (1/2) Audit, assessment, arviointi: laatujärjestelmän ja organisaation toiminnan tarkastamista. Management review: johdon katselmus, tarkastetaan yrityksen laatujärjestelmän tilanne, esim. ISO 9001 Verifiointi, todentaminen: tuote on määrittelynsä mukainen. Validointi, kelpoistaminen: tuote sopii käyttötarkoitukseensa. Virhe (error, fault, failure) –väärin oleva, ei speksin mukainen (huomioitava speksin täydellisyysaste) –ristiriitainen –puuttuvia osia –liikoja osia Virheiden luokittelu: vakava, lievä, kosmeettinen tms.

5 5 Terminologiaa (2/2) (Technical) Review = katselmus, tekninen katselmus –Tarkoituksena vaiheen päättymisen toteaminen –Pidetään tärkeimmissä etapeissa, esimerkiksi määrittely- tai suunnitteluvaiheen päättyessä. Kattaa kokonaisen vaihetuotteen. –Paljon osallistujia, myös ulkopuolisia. Inspection = tarkastus: –Tarkoituksena virheiden löytäminen (speksiinsä nähden). –Joustava aikataulutus, vaiheen aikana useita. –Tarkastettavana pienehkö kokonaisuus (tai osa laajempaa kokonaisuutta). –Muutamia osallistujia (esim. 3-6), yleensä projektin sisäinen. Walkthrough = läpikäynti –Läpikäynti on epämuodollinen tarkastuksen muoto, joka tehdään yleensä vain koodille. –Tekijä selittää, mitä hän "luulee ohjelmansa tekevän". Näiden termien käyttö ei ole vakiintunut. Tarkista aina, mistä puhutaan, kun näitä termejä käytetään!

6 6 Tarkastukset Tarkastuksilla tarkoitetaan virheiden etsimistä esim. dokumentista tai ohjelmakoodista. Yleensä käytetään ryhmätyömenetelmiä. Tarkastukset ovat aina ennalta suunniteltua ja systemaattisesti eteneviä. 5-15 % projektin kustannuksista koostuu tarkastuksista

7 7 Mihin tarkastuksia tarvitaan? –tehokkaampi virheenetsimiskeino kuin testaus –mahdollista löytää jopa 80% virheistä –virheet löytyvät aikaisemmassa vaiheessa –parantaa etenemisen näkyvyyttä –toimii tiedonvälityskanavana –varmistetaan, että kaikki ymmärtävät asiat samalla tavalla –toimii koulutustilaisuutena –sitouttaa tuloksiin –stabiloi speksit –...

8 8 Tarkastukset ja katselmoinnit projektissa

9 9 Virhekustannusten kertautuminen Mitä kauemmin virhe on järjestelmässä, sen kalliimmaksi se tulee. On useasti näytetty toteen, että yli puolet (60%) tuotteesta käytön aikana löytyvistä virheistä on peräisin ohjelmointia edeltävistä vaiheista (määrittely, suunnittelu). Testaukseen ja virheiden poistamiseen kuluu 50-80% projektin ajasta. Ylläpitoon kuluu lisäksi yli puolet elinkaarikustannuksista. Johtopäätös: virheiden ennaltaehkäisyyn ja havaitsemiseen ajoissa kannattaa panostaa.

10 10 Esimerkki: virheiden etsiminen testaamalla Moduulitestaus Järjestelmätestaus Asiakas Korjausaika 2pv / virhe Korjausaika 0.5pv / virhe Löytyvät tarkastamalla ja osittain järj. testauksessa Löytyvät testaamalla ja tarkastamalla Löytyvät moduulitestaamalla Ei löydy tarkastamalla eikä testaamalla Ajankäyttö: 0.5pv*10+2pv*4= 13pv

11 11 Esimerkki: virheiden etsiminen tarkastamalla Löytyvät tarkastamalla ja ositain järj. testauksessa Löytyvät testaamalla ja tarkastamalla Löytyvät moduulitestaamalla Ei löydy tarkastamalla eikä testaamalla Ajankäyttö: 0.2pv*12 +0.5pv*5= n. 5pv Moduulitestaus Järjestelmätestaus AsiakasKorjausaika 2pv / virhe Korjausaika 0.2pv / virhe Korjausaika 0.5pv / virhe Tarkastus

12 12 Vaiheet Ei saa olla Keskeneräinen, Alle 50 sivua. Osallistujat, aikataulu Materiaali jaetaan ja esitellään lyhyesti. 15 min Sovitaan tarkastusistunnosta: aika, roolit. roolit. Materiaaliin tutustuminen, kirjataan: - "ei ymmärrä" -lista - virhelista - pikkuvirhelista (kirj. virheet) Max. 2 tuntia Tekijä korjaa Joku osallistujista yhdessä korjaukset tehneen/tehneiden kanssa Virheiden analysointi prosessin kehittämiseksi

13 13 Tarkastuksen roolit 2-6 henkeä. Moderaattori eli juontaja eli puheenjohtaja: huolehtii aikataulussa pysymisestä ja asian etenemisestä kokouksessa (ei mielellään tekijän linjaesimies). Tekijä (syytetty :-). Esittelijä: esittelee materiaalia (voi olla tekijä). Sihteeri: kirjaa virheet (voi olla tekijä). Tarkastaja: kaikki toimivat tarkastajina. Muita rooleja: sovellusalueen tai jonkun teknologian asiantuntija, kieliasun tarkastaja, käyttäjänäkökulman edustaja…

14 14 Ohjeita tarkastukseen osallistuville Ohjeita puheenjohtajalle: hillitse selittelyä; huolehdi aikataulussa pysymisestä; estä rönsyily ja liika ideointi; rohkaise/provosoi passiivisia. Ohjeita tekijälle: älä selittele; älä tuo keskeneräistä tuotetta tarkastettavaksi. Ohjeita kaikille: valmistaudu huolellisesti; ole ystävällinen, varo loukkaamasta tekijää; pysyttele teknisissä asioissa -- arvioi tuotetta, älä tekijää; anna myös positiivisia kommentteja; osoita ongelmat; älä esitä korjausehdotuksia; anna korjaukset pikkuvirheisiin.

15 15 Tarkastusistunto Maksimiaika 2 tuntia. Pitäisi syntyä synergiaa: löytyy uusia puutteita tai virheitä. Ei selitellä ja puolustella tai keräillä pisteitä Tilaisuus ei saa muuttua ideointipalaveriksi. Vain etsitään virheet, ei korjata niitä tilaisuudessa! Ei syytellä. Sovitaan lopputuloksesta ja jälkiseurannasta. Dokumenttina syntyy tarkastuspöytäkirja, johon kirjataan –osallistujat –ajankäyttö / osallistuja –hyväksytty / hylätty –korjausaikataulu yhteenveto virheistä –mahdollinen seurantamenettely

16 16 Mitä tarkastetaan? Tarjous ja sopimus (ISO 9001) Määrittelydokumentit (toiminnallinen määrittely) Projektisuunnitelma Suunnitteludokumentit (tekninen määrittely) Testaussuunnitelmat Koodi Käyttäjälle menevä dokumentaatio Koulutusmateriaali, koulutussuunnitelma Käyttöönottosuunnitelma Muut tarvittavat asiat, joista sovitaan projektikohtaisesti

17 17 Tarkastuslistat Käytetään apuna tarkastuksissa. Laaditaan (ja ylläpidetään) kutakin vaihetuotetta varten kokemusten perusteella. Tarkastuslistat voivat olla sekä projekti- että tuotekohtaisesti dynaamisia eli uusia kohtia lisätään aina tarkastusten yhteydessä

18 18 Esimerkki tarkastuslistasta Opetusohjelman muuttaminen jonkun kurssin osalta –Soveltuvuus pääaineeseen, vs. sivuaineet –Koulutusohjelman vaihtajat –Koulutusohjelman rakenne –Rajapinnat muihin kursseihin, päällekkäisyydet –Kurssien rytmitys lukujärjestykseen –Käytettävissä olevat opettajat –Laitteet/ohjelmistot –Opetustilavaikutukset

19 19 Tarkastusten vaikutuksesta Tarkastusten käyttö muuttaa kustannusjakauman etupainotteisemmaksi. Monet virheet eivät löydy testaamalla Tarkoituksena on löytää virheitä => inhimillisesti ottaen "arkaluontoinen" prosessi. Tarkastuksella voidaan löytää tyypillisesti n. 80% virheistä (= enemmän kuin esimerkiksi testaamalla). Tarkastukset yleensä n. 5-15% projektin kokonaistyömäärästä. Tarkastuksilla on myös muita etuja –Varahenkilö –Oppiminen –Perehtyminen toisten tekemään työhön. –Sitoutuminen projektin tuloksiin.

20 20 Henkilöstökustannukset Without inspections With inspections Req’s DesignCodingTesting Staff resources

21 21 Virheiden aiheuttaman lisätyön osuus eri vaiheissa

22 22 Pahimmat ongelmat Pahimmat kompastuskivet: asenteet ja organisointi Tarkastustilaisuudessa –valmistautumattomuus –perehtymisen työmäärä –motivointi, asenteet –rönsyily –lepsu puheenjohtaja –ideointi, korjailu –työmäärää ei oteta huomioon aikataulutuksessa (varsinkin muiden projektien tarkastuksiin osallistuminen) –liikaa materiaalia

23 23 Havaintoja Koodissa aluksi virheitä n. 40-50 kpl tuhatta riviä kohti. Näistä 80% on löydettävissä tarkastamalla (sopivalla vauhdilla). Virheitä, jotka eivät löydy testaamalla –turha koodi, –standardeja noudattamaton koodi ja –kommenteissa olevat virheet.

24 24 Testaus vs. tarkastukset Virheiden korjaaminen tarkastamalla on huomattavasti testausta halvempaa. Miksi? –Testaus Testin suunnittelu Testiympäristön pystyttäminen Testin suorittaminen Tulosten tarkastaminen => virheet Virheiden jäljitys (debug) Virheiden korjaus –Tarkastaminen Yleiskatsaus Valmistautuminen Tarkastus Korjaus: jäljitystä ei tarvita, korjaukset usein ilmeisiä

25 25 Tarkastusvauhdin vaikutus tarkastustulokseen

26 26 Ongelmia Tarkastusten tehokkuudesta ei ole käytettävissä todisteita. Tarkastukset vievät paljon aikaa (virheet vievät vielä enemmän). Väärinkäsitykset tarkastustekniikasta: mitä tahansa kommentointia pidetään tarkastuksena. "Low tech" -tekniikan imago, ihmiset luulevat, että testaus ja jäljitys on nopeampaa.

27 27 Yhteenveto Tarkastuksilla ja katselmoinneilla saadaan parhaimmassa tapauksessa parannettua tehtävän järjestelmän laatua. Tarkastukset ja katselmoinnit pitää aikatauluttaa ja niihin tulee varata rahaa. Tarkastusten ja katselmointien merkitys tulee selventää projektin kaikille osapuolille, jotta niillä saavutetaan halutut tulokset.

28 28 Versionhallinta osana laadunvarmistustoimintaa

29 29 Software Control Management Puhekielessä käytetään useita eri nimiä: –Configuration management, konfiguraation hallinta –Version management, versionhallinta –monissa teoksissa käytetään kuitenkin termiä Software Control Management, SCM (joku kirja käyttää termiä kokoonpanon hallinta, tässä käytetään englanninkielistä termiä) Termeissä on laajuuseroja

30 30 Tarkoitus SCM:n tarkoituksena on hallita eri järjestelmän osien versioita niin, että projekti pysyy yhtenäisenä koko projektin ajan. Yleensä hallitaan lähdekoodia, mutta voidaan soveltaa myös –vaatimuksiin –suunnitelmiin –testitapauksiin –käyttäjädokumentaatioon –jne.

31 31 Ilman SCM:ta ilmeneviä ongelmia Tulipa editoitua tiedoston vanhaa versiota, koska en huomannut, että toinen suunnittelija on kirjannut oikean version itselleen editoitavaksi. Sotkin jotenkin muutokseni, ei auta kuin palata takaisin alkuperäiseen tiedostoon ja aloittaa alusta. Mihinkäs hakemistoon minä talletinkaan sen tiedoston? En löydä ohjelman sitä versiota, jonka talletin viime viikolla ennen kuin aloitin nämä viimeiset muutokset. Joku on muuttanut tiedostoa, mutta en saa selvää, mitä muutoksia aiotaan tehdä. Missähän he pitävät tällä hetkellä muutettavaa tiedostoa? Olen uusi projektissa, enkä tiedä mitkä tiedostot pitäisi ottaa mukaan, jotta saisin testattua muutosteni vaikutusta.

32 32 Ilman SCM:ta ilmeneviä ongelmia En ole muuttanut koodia kahteen viikkoon, mutta ohjelma ei käänny. Kukaan ei myönnä muuttaneensa mitään. Ohjelmani toimii eri tavalla kuin viimeksi, enkä keksi kuka on muuttanut sitä ja miksi. En pysty korjaamaan tätä vikaa, koska en saa ongelmaa päälle (en saa järjestelmää sellaiseen tilaan, että virhe tulisi esiin). En saa ongelmaa päälle, koska en tiedä, millainen kokoonpano ohjelmasta on asiakkaalla. En pysty korjaamaan tätä vikaa, koska toinen suunnittelija on ottanut tiedoston muutettavaksi eikä saa muutostaan valmiiksi ainakaan viikkoon. Vihaan sitä, kun joku toinen muuttaa samaa tiedostoa kanssani samanaikaisesti ja minun muutokseni menevät roskiin. Lähde: http://www.kyamk.fi/~apapo/akatemia/scm/scm.htm

33 33 Miksi SCM on tärkeää? eri ihmisten on pystyttävä tuottamaan koodia samaan järjestelmään hallitusti (esim. maantieteellisesti hajautettu tiimi) virheiden korjaus nopeutuu, kun tiedetään tarkasti mihin versioon korjaukset tehdään eri versioiden haaroittaminen (branching) eri alustoille tai asiakkaille onnistuu hallitusti muutosten tekeminen vain yhteen haaraan on mahdollista

34 34 Versiograafi, esimerkki 1.01.11.2 1.41.3 2.12.0 1.1.21.1.1

35 35 Keskeisiä tehtäviä Versionhallinta Ohjelmiston rakentamisen hallinta Muutospyyntöjen hallinta Julkaisujen hallinta Jakelun hallinta Asennuksen hallinta

36 36 Versionhallinta Valvoo ohjelmiston eri osien versioita ja niiden muutoksia Perusominaisuudet: –uusien versioiden teko, –uusien ja vanhojen versioiden muokkaus –version muutostietojen hallinta

37 37 Ohjelmiston rakentamisen hallinta hallitaan komentosarjojen (scripts) tai ohjelmistojen erilaisten kokoonpanojen (builds), esim. testaustarkoituksiin, rakentamista suunnitteluvaiheessa suunnitellaan kokoonpanojärjestys, SCM pitää huolen käytännön toteutuksen onnistumisesta SCM ei ole työkaluriippuvainen

38 38 Muutospyyntöjen hallinta Muutospyyntöjen toteutus voidaan jäljittää SCM-järjestelmän logitiedostojen avulla Auttaa myös muita havaitsemaan, kuinka joku osa järjestelmästä on muuttunut ja kuinka se pitäisi muualla ottaa huomioon

39 39 Muita Julkaisunhallinta: määrittää, mitkä järjestelmän osat (ja dokumentaatio) kuuluu yhteen muodostaen eheän kokonaisuuden Jakelunhallinta: menetelmä, jolla lopputuote jaetaan asiakkaalle Asennuksen hallinta: ohjelmiston asennus oikeilla asennusparametreilla

40 40 Työkaluja CVS (Concurrent versions system) – ilmainen (http://www.cvshome.org/) MS Visual SourceSafe (http://msdn.microsoft.com/ssafe/) Rational ClearCase (http://www.rational.com/products/clearcase/) muita esim. PVCS, Uniface, Perforce, Starteam

41 41 Yhteenveto SCM on apuvälineenä koko projektin ajan sekä yleensä myös tuotteen elinkaaren loppuun saakka. SCM:n käyttö tulee suunnitella, sopiva väline valita ja projektin jäsenet tulee kouluttaa sen käyttöön. Yrityksen oman ohjeiston lisäksi tulee vielä projektikohtaisesti sopia SCM:n käytön yksityiskohdista!