1 / 29

Ohjelmistotekniikka Tarkastukset ja katselmukset

Ohjelmistotekniikka Tarkastukset ja katselmukset. Kevät 2002 Päivi Ovaska LTKK/Tite. Sisältö. Johdanto: terminologia Tarkastukset Esimerkki kustannusvaikutuksista Tarkastusmenettelyn vaiheet T arkastuslistat Tarkastusten vaikutus Ongelmat Case Bell Case Ellemtel.

sondra
Download Presentation

Ohjelmistotekniikka Tarkastukset ja katselmukset

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OhjelmistotekniikkaTarkastukset ja katselmukset . Kevät 2002 Päivi Ovaska LTKK/Tite

  2. Sisältö • Johdanto: terminologia • Tarkastukset • Esimerkki kustannusvaikutuksista • Tarkastusmenettelyn vaiheet • Tarkastuslistat • Tarkastusten vaikutus • Ongelmat • Case Bell • Case Ellemtel

  3. Laadunvarmistukseen liittyviä termejä

  4. 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 9001). • Verifiointi, todentaminen: tuote on määrittelynsä mukainen. • Validointi, kelpoistaminen: 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.

  5. …terminologiaa • (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". Termien katselmus, tarkastus ja läpikäynti käyttöedellä esitetyllä tavalla ei ole vakiintunut.

  6. Tarkastukset • Tarkastusmenettely on systemaattinen yleisesti käytetty ryhmätyöhön perustuva menettely virheiden etsimiseksi mistä tahansa dokumentista ja myös ohjelmakoodista. • 5% to 15% projektin kustannuksista. • Miksi käytetään? • Tehokkaampi virheenetsimiskeino kuin testaus. • Mahdollista löytää 80% 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..

  7. Kuva 2.10

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

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

  10. Esimerkki: virheiden etsiminen tarkastamalla Löytyvättarkastamalla ja ositain järj. testauksessa Löytyvättestaamalla ja tarkastamalla Tarkastus Löytyvätmoduulitestaamalla Korjausaika 0.2pv / virhe Ei löydytarkastamallaeikä testaamalla Moduulitestaus Korjausaika 0.5pv / virhe Ajankäyttö: 0.2pv*12 +0.5pv*5= n. 5pv Järjestelmätestaus Asiakas Korjausaika 2pv / virhe

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

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

  13. Tarkastusistunto • Max. 2 tuntia. • Pitäisi syntyä synergiaa: löytyy uusia puuteita/virheitä. • Ei selitellä ja puolustella. • Ei pisteiden keräilyä. • Tilaisuus ei saa muuttua ideointipalaveriksi. • Etsitään virheet -- ei korjata. • Ei syytellä. • Sovitaan lopputuloksesta ja jälkiseurannasta. • Dokumenttina syntyy tarkastuspöytäkirja, johon tulos kirjataan: • osallistujat • ajankäyttö / osallistuja • hyväksytty / hylätty • korjausaikatauluyhteenveto virheistä • mahd. Seurantamenettely

  14. Mitä tarkastetaan? • Seuraava lista suunnilleen prioriteettijärjesteyksessä. • Tarjous, 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.

  15. Tarkastuslistat • 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 tarkastustenyhteydessä). • 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

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

  17. Staffing costs Without inspections Staff resources With inspections Req’s Design Coding Testing

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

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

  20. 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: 0.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 150 riviä tunnissa (Fagan: esittelyssä 500 riviä, valmistautuessa 125 riviä tunnissa ja tarkastuksessa 90 riviä tunnissa).

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

  22. 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ä.

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

  24. Tarkastusvauhdin vaikutus tarkastustulokseen

  25. Case 2 - ELLEMTEL (=Ericsson) OS32 • Changing operating system for a new processor • Size: 200 khours = 115 man-years • Total number of people: 73 • Duration: ~ 30 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

  26. Case 2 - ELLEMTEL OS32 • 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”

  27. Case 2 - ELLEMTEL OS32 EXTENSIVE REVIEWS • 40% 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. • 60 weeks of design -> 120 days for reviews. • 120 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

  28. Case 2 - ELLEMTEL OS32 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 0,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

  29. Case 2 - ELLEMTEL OS32 RESULTS Typical Ericsson Cleanroom Unit • Efficiency: 2,06 6 LOC/man hour • Internal faults 0,6 1,7-3,4 F/KLOC (From the 1st execution) • Faults during operation ? 0-0,1 F/KLOC

More Related