OTM viikolla 17 ja 18. Tarkastukset ja katselmukset. terminologiaa

Transkriptio

1 OTM viikolla 17 ja 18 Tarkastukset ja katselmukset Viikko 17 Luennot, maanantai: Tarkastukset, inspections torstai: Testaus Viikkoharjoitukset: artikkeli Frederick P. Brooks, Jr: "No Silver Bullet - Essence and Accidents of Software Engineering". Ks. Myös Brooksin omat kommentit: ManMonth s.27 Viikko 18 Luennot Maanantai: vierailuluento Risto Kurki-Suonio, juridiikka To vappu Viikkoharjoitukset: tarkastusharjoitus Johdanto: terminologia Tarkastukset Esimerkki kustannusvaikutuksista Tarkastusmenettelyn vaiheet Tarkastuslistat Tarkastusten vaikutus Ongelmat Case Bell Case Ellemtel Case TUT/projektityö Terminologiaa terminologiaa Audit, assesment, arviointi: laatujärjestelmän ja organisaation toiminnan tarkastamista. Management review = johdon katselmus, tarkastetaan projektin tilanne (tai koko laatujärjestelmän tilanne, ISO 9). Verifiointi, todentaminen: tuote on määrittelynsä mukainen. Validointi, kelpoistaminenen: tuote sopii käyttötarkoitukseensa. Virhe (error, fault, failure) väärin, ei speksin mukainen (speksin täydellisyys?) ristiriita puuttuu liikaa Virheiden luokittelu: vakava, lievä, kosmeettinen tms. (Technical) Review = katselmus, tekninen katselmus Tarkoituksena vaiheen päättymisen toteaminen, eli siis tehdä prosessin eteneminen näkyväksi. 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. Joustava aikataulutus, vaiheen aikana useita. Tarkastettavana pienehkö kokonaisuus (tai osa laajempaa kokonaisuutta). Muutamia osallistujia 3-6, 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". Kutsutaan joskus "koodipoliisiksi", koodi selitetään poliisille. Termien katselmus, tarkastus ja läpikäynti käyttö edellä esitetyllä tavalla ei ole vakiintunut.

2 terminologiaa Tarkastukset Virtuaalikatselmus: katselmus voidaan tehdä ilman kokousta verkossa. Käytössä useissa avoimen lähdekoodin projekteissa. Avoimen lähdekoodin projektien yhteydessä vertaisarviointi-tyyppinen (peer review) "virtuaali"katselmointi on melko yleisesti käytössä. Pariohjelmointi: ketterissä ohjelmistokehitysmenetelmissä (agile) käytetty menetelmä, jossa koodia muokatessa saman näytön ääressä istuu kaksi henkilöä, eräänlaista reaaliaikaista katselmointia. Arkkitehtuuriarviointiin on kehitetty useita katselmointimenetelmiä (ATAM, SAAM). Tarkastusmenettely on systemaattinen yleisesti käytetty ryhmätyöhön perustuva menettely virheiden etsimiseksi mistä tahansa dokumentista ja myös ohjelmakoodista. Miksi käytetään? Tehokkaampi virheenetsimiskeino kuin testaus. Mahdollista löytää 8% virheistä. Virheet löytyvät aikaisemmin. Parantaa etenemisen näkyvyyttä. Toimii tiedonvälityskanavana. Varmistetaan, että kaikki ymmärtävät asiat samalla tavalla. Toimii koulutustilaisuutena. Sitouttaa tuloksiin. Stabiloi speksit. Rick Kazman, Mark Klein and Paul Clements: ATAM: Method for Architecture Evaluation. Technical report, CMU/SEI-TR-, ESC-TR- esitutkimus& sopimus Kuva 2.1 Virhekustannusten kertautuminen (Kuva 14.4) määrittely suunnittelu tarkastus katselmus, toimittajan katselmus, asiakas mukana ohjelmointi ja moduulitestaus integrointi järjestelmätestaus Mitä kauemmin virhe on järjestelmässä, sen kalliimmaksi se tulee. On useasti näytetty toteen, että yli puolet (6%) tuotteesta käytön aikana löytyvistä virheistä on peräisin ohjelmointia edeltävistä vaiheista (määrittely, suunnittelu). Testaukseen ja virheiden poistamiseen kuluu 5-8% projektin ajasta. aika Ylläpitoon kuluu lisäksi yli puolet elinkaarikustannuksista. Ketterien menetelmien kannattajat ovat kyseenalaistaneet Johtopäätös: tämän virheiden väitteen ennaltaehkäisyyn ja havaitsemiseen ajoissa kannattaa panostaa.

3 Esimerkki: virheiden etsiminen testaamalla Esimerkki: virheiden etsiminen tarkastamalla Löytyvät tarkastamalla ja osittain järj. testauksessa Löytyvät tarkastamalla ja ositain järj. testauksessa Löytyvät moduulitestaamalla ja tarkastamalla Löytyvät moduulitestaamalla Moduulitestaus Löytyvät testaamalla ja tarkastamalla Löytyvät moduulitestaamalla Tarkastus Korjausaika.2pv / virhe Ei löydy tarkastamalla eikä testaamalla Korjausaika.5pv / virhe * 1 = 5 päivää Ei löydy tarkastamalla eikä testaamalla * 12 = 2.4 päivää Moduulitestaus Järjestelmätestaus Korjausaika.5pv / virhe * 5 = 2.5 päivää Korjausaika 2pv / virhe Järjestelmätestaus Asiakas * 4 = 8 päivää Asiakas Korjausaika 2pv / virhe Ajankäyttö: 5pv + 8pv = 13 päivää Ajankäyttö: = n. 5 päivää Työvaihe Valmistautuminen Ei saa olla Keskeneräinen, Alle 5 sivua. Tarkastettava dokumentti K Tarkastustilaisuus Tarkastuspöytäkirja Vaiheet Suunnittelu Max. 2 tuntia Osallistujat, aikataulu uusintatarkastus? esittely tarpeen? E E Hyväksytty dokumentti Tekijä korjaa K Materiaali jaetaan ja esitellään lyhyesti. 15 min Sovitaan tarkastusistunnosta: aika, roolit. Esittely Korjaus Jälkiseuranta Roolit 2-6 henkeä. Moderaattori eli juontaja eli puheenjohtaja: huolehtii aikataulussa pysymisestä ja asian etenemisestä kokouksessa (ei mielellään tekijän linjaesimies). Ohjeita puheenjohtajalle: hillitse selittelyä; huolehdi aikataulussa pysymisestä; estä rönsyily ja liika ideointi; rohkaise/provosoi passiivisia. Tekijä (syytetty :-). Ohjeita tekijälle: älä selittele; älä tuo keskeneräistä tuotetta tarkastettavaksi. 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 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. Materiaaliin tutustuminen, kirjataan: - "ei ymmärrä" -lista - virhelista - pikkuvirhelista (kirj. virheet) Virheiden analysointi prosessin kehittämiseksi Joku osallistujista yhdessä korjaukset tehneen/tehneiden kanssa

4 Tarkastusistunto Mitä tarkastetaan? Max. 2 tuntia. Pitäisi syntyä synergiaa: löytyy uusia puuteita/virheitä. Ei selitellä ja puolustella. Ei pisteiden keräilyä. Ei syytellä. Tilaisuus ei saa muuttua ideointipalaveriksi. Etsitään virheet -- ei korjata. Sovitaan lopputuloksesta ja jälkiseurannasta. Dokumenttina syntyy tarkastuspöytäkirja, johon tulos kirjataan: osallistujat ajankäyttö / osallistuja hyväksytty / hylätty korjausaikataulu yhteenveto virheistä mahd. seurantamenettely Seuraava lista suunnilleen prioriteettijärjesteyksessä. Tarjous, sopimus (ISO 9). Määrittelydokumentit (toiminnallinen määrittely). Projektisuunnitelma. Suunnitteludokumentit (tekninen määrittely). Testaussuunnitelmat. Koodi. Käyttäjälle menevä dokumentaatio. Koulutusmateriaali, koulutussuunnitelma. Käyttöönottosuunnitelma. Tarkastuslistat Tarkastusten vaikutuksesta Käytetään apuna tarkastuksissa. Laaditaan (ja ylläpidetään) kutakin vaihetuotetta varten kokemusten perusteella. Tarkastuslistat voivat olla projekti/tuotekohtaisesti - dynaamisia (=uusia kohtia lisätään tarkastusten yhteydessä). Esimerkki, opetusohjelman muuttaminen jonkun kurssin osalta Soveltuvuus pääaineeseen, vs. sivuaineet Koulutusohjelman vaihtajat Koulutusohjelman rakenne Rajapinnat muihin kursseihin, päällekäisyys Kurssien rytmitys lukujärjestykseen Käytettävissä olevat opettajat Laitteet/ohjelmistot Opetustilavaikutukset Kustannusvaikutukset Toimintamallit siirtymäkaudelle Imago ja politiikka Intissä olevat opiskelijat Tarkastusten käyttö muuttaa kustannusjakauman etupainotteisemmaksi. Monet virheet eivät löydy testaamalla (s. 219). Tarkoituksena on löytää virheitä => inhimillisesti ottaen "arkaluontoinen" prosessi. Tarkastuksella voidaan löytää tyypillisesti n. 8% 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.

5 Staffing costs Kuva 14.5 Without inspections Ilman tarkastuksia Määrittely Tarkastusten kanssa Määrittely Staff resources With inspections Suunnittelu Ohjelmointi, moduulitestaus Integrointi, testaus Suunnittelu Ohjelmointi, moduulitestaus Integrointi, testaus varsinainen työ Req s Design Coding Testing virheiden aiheuttama lisätyö 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 Experience with Inspections in Ultra-Large Scale Developments. Raportti Bell-Northern Researchin tarkastusten käyttöönotosta. Toimittaa puhelinkeskuksia, koodin kokonaismäärä 15 miljoonaa riviä. Tuloksia 2.5 miljoonan koodirivin tarkastuksista (rivimäärät eivät sisällä kommentteja). Tarkastus neljän hengen ryhmissä: pj, sihteeri, esittelijä, tekijä. Työteho:.8-1 virhettä/htt (henkilötyötunti). htt sisältää myös valmisteluun käytetyn ajan. 2-4 kertaa nopeampaa kuin virheiden etsiminen ja korjaaminen testaamalla. Asiakkaan raportoiman virheen korjaus vie keskimäärin 4.5 työ päivää. Tarkastusvauhti 15 riviä tunnissa (Fagan: esittelyssä 5 riviä, valmistautuessa 125 riviä tunnissa ja tarkastuksessa 9 riviä tunnissa).

6 Havaintoja Koodissa aluksi virheitä n. 4-5 kpl tuhatta riviä kohti. Näistä 8% on löydettävissä tarkastamalla (sopivalla vauhdilla). Virheitä, jotka eivät löydy testaamalla turha koodi, standardeja noudattamaton koodi ja kommenteissa olevat virheet. Virheiden poistaminen tarkastamalla koodia 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ä. Ongelmia Kuva 14.7 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.

7 Case 2 - ELLEMTEL (=Ericsson) OS32 Case 2 - ELLEMTEL OS32 Changing operating system for a new processor Size: 2 khours = 115 man-years Total number of people: 73 Duration: ~ 3 months Compiler developed in parallel with this project Processor board developed in parallel with this project -> Neither target machine nor compiler for the machine were not available for SW designers Cleanroom technology Incremental developments Extensive reviews of ALL documents: 2 days/week No compilation until system design test phase No unit debugging Think Tank - Cross functional team to solve technical problems early Work in teams instead of one designer per block Used to be: Reviews take my time so I can t follow my schedule Case 2 - ELLEMTEL OS32 Case 2 - ELLEMTEL OS32 EXTENSIVE REVIEWS 4% preparation and review time planned per designer One day for preparation, one day for reviews per week If not enough material for review, the day will be used for work meetings. 6 weeks of design -> 12 days for reviews. 12 days for reviews instead of debugging: no loss of calendar time A way to ensure that everybody is working for the same goal To spread knowledge Weak designers get more support Improved follow-up and feed-back RESULTS Planned hours vs. accrued +/- 5% on yearly basis. Time schedule compliance within 2-3 weeks on yearly basis In testing it takes 17,3 man hours to find one defect In reviews it takes,9 man hours to find one defect The most important benefit: iterative development by frequent reviews The use of development teams was a success Loss of prestige is avoided by teamwork and by reviewing it before errors cumulate. Improved follow-up and feedback

8 RESULTS Case 2 - ELLEMTEL OS32 Ericsson Typical Cleanroom Unit Efficiency: 2,6 6 LOC/man hour Internal faults,6 1,7-3,4 F/KLOC (From the 1st execution) Faults during operation? -,1 F/KLOC number of pages (average) (1/7) Dokumenttitarkastuksista (tarkastuslomakkeista) kerättyjä tietoja tarkastuksen kesto; esimerkiksi 1,75 h tarkastukseen kulunut kokonaisaika (valm+tark); esimerkiksi 22,5 h löydösten eli virheiden lukumäärä; esimerkiksi 23 tarkastuksen kohteen sivumäärä; esimerkiksi 37. Näistä saadaan helposti laskettua muiden muassa seuraavia tilastoja virhetiheys: virhettä / sivu (esimerkiksi,62) läpikäyntinopeus: montako sivua / tunnissa (esimerkiksi 21,14) löytymisnopeus: virhettä / tunnissa (esimerkiksi 13,14) virheen löytämisen kokonaisaika: kokonaisaika / virhelukumäärä (esimerkiksi, h) ajankäyttö yhtä sivua kohti: tarkastusaika / sivu (esimerkiksi 2,84 min). number of pages (average) (2/7) findings (average) (3/7) = määrittely määrittely = suunnittely suunnittely = testaussuunnitelma

9 findings / hour (average) (4/7) findings / page (average) (5/7) 3 1, ,8 15 1,6,4 5, Think about that... "cost" = person-hour/defect (average) (6/7) Case 3 - Inspections at TUT % of project time spent to inspections (7/7),9,8,7,6,5,4,3,2, If If one one working-hour working-hour cost cost is is 1 1 Euros, Euros, then then cost cost for for detecting detecting one one defect defect at at inspections inspections is is about about 5 5 Euros. Euros min avg max