010758002 Ohjelmistotuotanto - Tarkastukset ja katselmoinnit Versionhallinta

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

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

3. Laadunvarmistukseen liittyviä termejä

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. Näiden termien käyttö ei ole vakiintunut. Tarkista aina, mistä puhutaan, kun näitä termejä käytetään! 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".

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. 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. Tarkastukset ja katselmoinnit projektissa

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

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

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

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. 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. 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. 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. 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. 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. 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. Without inspections Staff resources With inspections Req’s Design Coding Testing Henkilöstökustannukset

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

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. 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. 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. Tarkastusvauhdin vaikutus tarkastustulokseen

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. 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. Versionhallinta osana laadunvarmistustoimintaa

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. 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. 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. 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. 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. Versiograafi, esimerkki 1.3 1.4 1.0 1.1 1.2 2.0 2.1 1.1.1 1.1.2

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

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

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. 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. 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. 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. 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!