Ohjelmistotekniikka - Luento 8 Jouni Lappalainen Luku 14: Laatukäsitteet - laatumallit - ohjelmiston laadun dilemma Luku 15: Katselmointitekniikat - katselmoinnin hyödyt - formaalit tekniset katselmoinnit Luku 16: Laadunvarmistus - laadunvarmistuksen elementit - laaduvarmistuksen tehtävät, tavoitteet ja metriikat - tilastollinen laadunvarmistus (six sigma), ISO 9000 standardit - ohjelmiston luotettavuus
Soveltuvat lait ja pohdiskelun aiheita 1. Tarkastukset lisäävät huomattavasti tuottavuutta, laatua ja projektin vakautta / no 17, Fagan 1976 2. Eri V&V menetelmien yhdistelmä voittaa aina yksittäisen menetelmän / no 20, Hetzel 1976, Myers 1978 3. Virheiden esto on parempaa kuin virheiden poisto / hyp_no 9, Mays 1990 McCallin laatumalli on kehitetty jo 1970 luvulla. Malli on kuitenkin vieläkin käyttökelpoinen. Kerro syitä, mistä tämä voisi johtua Voiko ohjelma olla virheetön ja siitä huolimatta laadultaan huono? Perustele mielipiteesi. Virheiden määrä on yksi laadun indikaattori. Mitä muita indikaattoreita tunnet? Luentomateriaalissa (sivu 11) esitellään laatutekijöiden (kriteerien) välisiä yhteyksiä. Uudelleenkäytön ja käytettävyyden välille ei ole esitetty yhteyttä. Mieti millainen se voisi olla ja perustele esitystäsi. Mitä yhteistä on aktiviteeteilla katselmointi (review), tarkastus (inspection), läpikäynti (walkthrough) ja pariohjelmointi (pair programming). Missä suhteessa ne eroavat toisistaan?
Laatu Quality... you know what it is, yet you don t know what it is. But that s self-contradictory. But some things are better than others; that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There s nothing to talk about. But if you can t say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn t exist at all. But for all practical purposes it really does exist. What else are the grades based on? Why else would people pay fortunes for some things and throw others in the trash pile? Obviously some things are better than others... but what s the betterness?... So round and round you go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is Quality? What is it?» Zen and the Art of Motorcycle Maintenance, Robert Persig 1974 3
Laatu 5 näkökulmaa laatuun: Transcendental: you know when it s there, but you cannot point your finger at it User: Does it do what I need it to do? Manufacturer: Does it do what it was specified to do? Product: Does it have good functionality and features? Value: How much will someone/i pay for this? 4
Laatu American Heritage Dictionary määrittelee laadun a characteristic or attribute of something. Ohjelmistojen yhteydessä tarkastellaan kahdenlaista laatua: Suunnittelun laatu tarkastelee, miten suunnitelmat vastaavat vaatimuksissa määriteltyjä toimintoja ja piirteitä. Vastaavuuden laatu (Quality of conformance) tarkastelee, miten toteutus noudattaa suunnitelmia ja lopullinen tuote vastaa vaatimuksia ja suorituskykytavoitteita. Kuitenkin, Robert Glassin yleistajuinen määrittely painottaa ohjelmiston kannalta tärkeitä tekijöitä käyttäjän tyytyväisyys = sopiva tuote + hyvä laatu + toimitus suunnitellun budjetin ja aikataulun mukaisesti 5
Mitä tarkoitetaan ohjelmiston laadulla? Software quality / ISO Std., 1986 The totality of features and characteristics of a software product that bear on its ability to satisfy specified or implied needs. Ohjelmistotuotteen kaikki ne piirteet ja ominaisuudet, joilla tuote täyttää asetetut tai oletettavat tarpeet.
Ohjelmiston laatutavoitteet Johdettu yleisistä laatutavoitteista Walter Shewhart, W Edwards Deming ja Joseph Juran toimivat kaikki 1920 luvulla AT&T Bell Labs yrityksessä Deming (Japanissa 1950-1980) Asiakkaalle tärkeä tuote Juran (Quality Control Handbook, 1951) Sopiva käyttöön Crosby (Quality is free, 1979) Täyttää vaatimukset Nolla virhettä
McCallin laatukolmio muunnokset Ylläpidettävyys Joustavuus Testattavuus Tuotteen muutos Tuotteen siirto Siirrettävyys Uudelleenkäytettävyys Yhteistoiminnallisuus Tuotteen toiminta Oikeellisuus Käytettävyys Tehokkuus asiakkaan tarpeet Luotettavuus Eheys tieto ja sen saanti
device independence Ohjelmiston tulee olla hyödyllinen siirettävyys self-containedness accuracy luotettavuus completeness robustness/integrity yleinen hyöty hyöty käytössä tehokkuus consistency accountability device efficiency käytettävyys accessibility testattavuus communicativeness self-descriptiveness ylläpidettävyys ymmärrettävyys structuredness conciseness legibility Boehmin malli (Boehm et al. 1978) muunneltavuus augmentability
ISO/IEC 9126-1 laatuominaisuudet Toiminnallisuus (Functionality) suitability, accuracy, interoperability, security Luotettavuus (Reliability) maturity, fault tolerance, recoverability Käytettävyys (Usability) understandability, learnability, operability, attractiveness Tehokkuus (Efficiency) time behaviour, resource utilisation Ylläpidettävyys (Maintainability) analysability, changeability, stability, testability Siirrettävyys (Portability) adaptability, installability, co-existence, replaceability
Correctness Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability C R E I U M T F P R I Inverse Neutral Direct Examples of the relationships between criteria Integrity vs. efficiency (inverse) The control access to data or software requires additional code and processing leading to a longer runtime and additional storage requirements. Usability vs. efficiency (inverse) Improvements in the human/computer interface may significantly increase the amount of code required. Portability vs. efficiency (inverse) The use of optimized software or system utilities will lead to a decrease in portability. Maintainability vs. flexibility (direct) Maintainable code arises from code that is well structures. This will also assist any modifications or alterations that are required. Thus a direct relationship exists between these properties. Gillies A., Software Quality, Theory and Management,1997 Perry W., Effective methods of EDP Quality Assurance, 1987
Sovelluksen laatutekijöiden valinta ja priorisointi sovelluksen ominaispiirteet laatuominaisuudet Ihmishenki vaarassa Pitkäikäinen järjestelmä Muutosherkkä järjestelmä Kypsymätön teknologia Monia muutoksia elinaikana Reaaliaikasovellus Laitteistoon sulautettu Tietoturva Järjestelmät yhteydessä toisiinsa Luotettavuus ----------------- Ylläpidettävyys -------------- Ylläpidettävyys ----------------- Siirrettävyys -------------- Ylläpidettävyys -------------- Tehokkuus, luotettavuus -------------- Tehokkuus, luotettavuus --------------- Toiminnallisuus -> security --------------- Toiminnallisuus -> interoperability
Laatutekijöiden yhteys ei-toiminnallisiin vaatimuksiin Ei-toiminnalliset vaatimukset Tuotevaatimukset Yrityskohtaiset vaatimukset Ulkopuoliset vaatimukset Käytettävyyteen liittyvät Toiminnallisuuteen liittyvät Luotettavuuteen liittyvät Tehokkuuteen liittyvät Ylläpidettävyyteen liittyvät Siirrettävyyteen liittyvät ymmärrettävyys toimivuus analysoitavuus muutettavuus opittavuus viehättävyys vakaus testattavuus
Laadun mittaus Mieluusti ei-kvalitatiivisia mittauksia Hankala mitata, ei saada suoria mittauksia Sen lisäksi mitataan aina jotain laadun ilmentymää/tekijää eikä laatua sinänsä Mikä yhteys on laatutekijällä ja tuotteen laadulla? 14
Laatudilemma Huono laatu Riittävän hyvä Perfektionismi Time-to-market Asiakastyytyväisyys 15
Mitä laatu maksaa? C quality = C prevention + C appraisal + C failure perustuu Feigenbaumin esitykseen 1950 luvulla ennaltaehkäisykustannukset (prevention) koulutus prosessin parantaminen arviointikustannukset (appraisal) katselmointi ja tarkastus testauksen suunnittelu testitapausten ja testimateriaalin suunnittelu testien suoritus kertaalleen häiriökustannukset (failure) sisäiset häiriöt korjauskustannukset rakentamisvaiheessa ulkoiset häiriöt korjauskustannukset asiakkaan huomaamista häiriöistä Pressmanin jaottelu: Prevention Failure (internal, external)
$16.000 $14.000 $14.102 $12.000 $10.000 $8.000 $6.000 $7.136 $4.000 $2.000 $139 $455 $977 Vaatimusm. Suunnittelu Koodaus Testaus Ylläpito Virheiden ja puutteellisuuksien korjauskustannukset (Pressman 2010, Boehm & Basili 2001)
15. Katselmointitekniikat... there is no particular reason" why your friend and colleague" cannot also be your sternest critic." Jerry Weinberg! 18
Spesifikaatioiden määrittely 0 0 10 0 % Suunnittelu Läpi kulkevat Kertautuvat Vaiheen uudet Virheen poisto % 94 10 Integrointitestaus 6 4 6 4 * 1.5 = 6 25 0 % 37 10 27 Koodaus & yksikkötestaus 10 27 * 3 = 81 25 20 % 0 0 50 % Hyväksymistestaus 94 47 0 0 50 % Järjestelmätestaus 24 Kun ei käytetä katselmointia 0 50 % 0 Virheitä jää 12
Spesifikaatioiden määrittely 0 0 10 70 % Suunnittelu Läpi kulkevat Kertautuvat Vaiheen uudet Virheen poisto % 24 3 Integrointitestaus 2 1 2 1 * 1.5 = 1.5 25 50 % 15 5 10 Koodaus & yksikkötestaus 5 10 * 3 = 30 25 60 % 0 0 50 % Hyväksymistestaus 24 12 0 0 50 % Järjestelmätestaus 6 Kun käytetään katselmointia 0 0 Virheitä jää 3 50 %
Työmäärän säästö katselmoinnin avulla Oletetaan, että vaatimusmäärittelydokumentti on 32 sivua ja siinä on 18 UML kaaviota. Katselmoinnilla löytyy 18 minor ja 4 major virhettä. virhetiheys on 1.2 virhettä/uml kaavio ja 0.68 virhettä/sivu Työmäärä (effort) yhden minor tyyppisen virheen löytämiseen ja korjaamiseen on 4 työtuntia ja major tyyppisen virheen löytämiseen ja korjaamiseen on 18 työtuntia. keskimäärin yhden vaatimusmäärittelyvirheen löytäminen ja korjaaminen katselmoinnilla (E katselmointi ) vie 6 työtuntia keskimäärin yhden vaatimusmäärittelyvirheen löytäminen ja korjaaminen testausvaiheessa (E testaus ) vie 45 työtuntia Työmäärän säästö = E testaus - E katselmointi = 45-6 = noin 40 työtuntia/virhe Kun katselmoinnilla löytyi vaatimusmäärittelyissä virheitä 22, säästö kun käytetään katselmointia on noin 880 työtuntia 21
Mitä katselmoinnit ovat/eivät ole? Ovat: 1. Palaveri, jonka ohjelmistosuunnittelijat ovat järjestäneet ohjelmistosuunnittelijoille 2. Työtuotteen teknistä arviointia ohjelmistokehityksen aikana 3. Ohjelmiston laadunvarmistuksen mekanismi 4. Harjoittelun perusta Eivät ole 1. Projektin etenemisen arviointia 2. Palaveri, jonka tärkein tarkoitus on informaation jakaminen 3. Mekanismi poliittiselle tai henkilökohtaiselle kostolle 22
Osallistujat katselmoinnin " vetäjä" (moderaattori)" standardien noudattamisen! tarkastaja (SQA)! tekijä" ylläpidon! asiantuntija!! kirjuri" käyttäjän! edustaja! katselmoija" 23
Katselmoinnin suoritus The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 1." 2." valmistaudu - etsi epäilyksiä" tuotteesta ennen kirjauspalaveria" katselmoi tuotetta - " älä tekijää " 4." 5." 3." pysy rauhallisena, " tee kysymyksiä -" älä syytä" noudata katselmoinnin asialistaa" The image cannot be displayed. Your computer may not have enough ota esiin epäilyksiä, älä ratkaise niitä" 6." 7." kiinnitä huomiosi ratkaisun oikeellisuuteen - " vältä keskustelua tyyliseikoista" aikatauluta katselmoinnit projektisuunnitelmaan " 8." talleta katselmoinnin tulokset ja raportoi niistä" 24
Inspection Issue Log Project: Origin: Requirements, Design, Implementation, Testing Inspection ID: Type: Missing, Wrong, Extra, Usability, Performance, Style, Clarity, Question Meeting Date: Recorder: Severity: Major, minor Defects Found: Major, minor Defects Corrected: Major minor Origin Type Severity Location Description 1. 2. 3. 4. 5. 6. Wiegers 2002
Inspection Summary Report Inspection Identification: Project: Inspection ID: Meeting Date: Work Product Description: Inspectors Signature Preparation Time Author: hours Moderator: hours Recorder: hours Reader: hours Inspector: hours Inspection Data Pages or Lines of Code: Meeting Time: hours Planned for Inspection: Total Planning Effort: labor hours Actually Inspected: Total Overview Effort: labor hours Total Preparation Effort: labor hours Actual Rework Effort: labor hours Product Appraisal ACCEPTED NOT ACCEPTED as is reinspect following rework conditionally upon verification inspection not completed Verifier: Projected Rework Completion Date: Wiegers 2002
Suppea tarkistuslista vaatimusmäärittelyille Ymmärrettävyys Ymmärtääkö lukija käytetyt käsitteet ja termit? Onko käytetty kieli ymmärrettävää? Yksiselitteisyys Onko termien ja käsitteiden käytössä ristiriitaisuuksia? Onko vaatimusten tärkeysjärjestys selvä (mitä täytyy toteuttaa, mitä ei välttämättä aina)? Oikeellisuus Ovatko esitetyt vaatimukset testattavia (esitetäänkö myös hyväksytyt arvot nopeudelle, helppoudelle jne.)? Jäljitettävyys Ovatko kaikki vaatimukset jäljitettävissä ylemmän tason tehtävänantoon?
Katselmointityyppien eroavaisuuksia (Wiegers 2002) Characteristic Inspection Team review Walkthrough Leader Moderator Moderator/Author Author Material presenter Reader Moderator Author Granularity of material presented Small chunks Pages or sections Author s discretion Recorder used Yes Yes Maybe Documented procedure followed Yes Maybe Maybe Specific participant roles Yes Yes No Defect checklists used Yes Yes No Data collected and analyzed Yes Maybe No Product appraisal determined Yes Yes No
Otosvetoiset katselmoinnit Sample-Driven Reviews (SDRs) / Thelin et al. 2001 SDR katselmoinneilla pyritään määrittämään sellaiset työtuotteet (artifaktat), joille tehdään täydellinen FTR. Tämä tehdään siten, että Tarkastetaan osa a i jokaisesta tuotteesta i. Talletetaan virheiden määrä, f i jotka löytyivät osasta a i. Lasketaan arvio virheiden määrästä tuotteessa i kertomalla f i arvolla 1/a i. Lajitellaan saadun arvon perusteella työtuotteet laskevaan järjestykseen. Suunnataan katselmointiresurssit näin saadun työtuotteiden listan alkupäähän. 29
16. Ohjelmiston laadunvarmistus (tai laadunhallinta) Prosessin " määrittely ja" standardit" Formaalit" tekniset" katselmoinnit" Analyysi" ja " raportointi" Mittaus" Testien " suunnittelu" ja " katselmointi" 30
Ohjelmiston laadunvarmistus (Galin 2004) tarkoittaa systemaattisia ja suunniteltuja toimintoja, joita tarvitaan varmistamaan riittävällä tarkkuudella, että ohjelmistotuotteen kehitysprosessi tai sen ylläpitoprosessi täyttävät niille asetetut toiminnalliset tekniset vaatimukset kuten myös, että ne pysyvät aikataulussa ja asetetussa budjetissa
Laadunvarmistusryhmän rooli (esim. RUP prosessissa) LV-suunnitelma projektille - auditoinnit, katselmoinnit - sopivat standardit 1 - raportointi Inception (aloitus) - tuotteen ominaisuudet - alustavat käyttötapausmallit Elaboration (kehittäminen) - käyttötapausmallit - analyysimalli - arkkitehtuurikuvaus suunnittelu mallintaminen 3 Katselmoi projektin prosessin aktiviteetteja (vastaako määriteltyä) 2 Osallistuu projektin ohjelmistoprosessin kehittämiseen kommunikointi rakentaminen Construction (rakentaminen) Varmistaa, että poikkeamat työssä ja tuotteissa 5 dokumentoidaan ja niistä raportoidaan ja poikkeamia seurataan julkaisu Production (tuotanto) Ohjelmiston lisäys (inkrementti) toimitus Transition (siirto) - valmis ohjelmiston osa - Beta testauksen raportit - käyttäjän palautteet - suunnittelumalli - testisuunnitelmat - testitapaukset 4 Auditoi ohjelmistotyön tuotteita (vastaako suunniteltuja)
Tilastollinen prosessinvalvonta (SPC) Ishikawa on esittänyt seitsemää työkalua laatutiedon keruuseen ja analyysiin (B7 tools) Työkalujoukon perustana oli Shewhartin valvontakaavio (control chart) prosessin vuokaavio - nähdään, mitä on tehty tiedonkeruulomake - merkitään esiintymismäärä pylväskaavio (histogrammi) - nähdään karkea vaihtelu Pareto-kaavio - saadaan esille tärkeät ongelmat syy-seuraus-kaavio (Ishikawa)- löydetään ongelmien aiheuttajat hajontakaavio (scatter) - löydetään riippuvuudet valvontakaavio - voidaan valvoa vaihtelua (prosessi stabiiliksi)
2 10 5 Tiedonkeruulomake (checksheet) 17 Käsitteet Määritelmät Laatunäkökulman ymmärtäminen Hierarkia Yhteydet Esimerkit Yrityssidonnaiset 17 Rakenne Laadukkaan ohjelmiston kehittäminen Prosessin laatu Tarkastus & katselmointi Testaus Yleiset Laatumalli Kehitysprosessi Työkalut Tilat Resurssien laatu Henkilöstö 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 run bb wb insp faults/hr Ishikawa kaavio Pylväskaavio (bar graph) Pareto kaavio 50 40 30 20 10 0 1 5 10 15 20 25 Valvontakaavio (control chart) UCL LCL 800 600 400 200 100 0 0,2 0,4 0,6 0,8 1 1,2 Hajontakaavio (scatter diagram) Pylväskaavio (histogram graph) Lohkokaavio (flowchart)
TQM (Total Quality Management) Pyritään saamaan kaikki ihmiset ja prosessit laadunhallinnan piiriin. Asiakkaan tarpeet - asiakkaan hyväksyntä Prosessin parantaminen - jatkuva Rakentajan laatu - laatukulttuuri - johdon sitoutuminen Metriikat, mallit, mittaukset ja analyysi SPC TQM:n osana 35
Six sigma ohjelmistotuotannossa Termi six sigma on johdettu standardipoikkeamasta (keskihajonnasta) 3.4 virhettä miljoonassa tapauksessa merkitsee erittäin korkeaa laatua. 31% 69% DPMO = defective parts per million opportunities 1 sigma = 691.462 DPMO 69% 2 sigma = 308.538 DPMO 31% 3 sigma = 66.807 DPMO 6,7% 4 sigma = 6.210 DPMO 0,62% 5 sigma = 233 DPMO 0,023% 6 sigma = 3,4 DPMO 0,00034% -6-5 -4-3 -2-1 0 1 2 3 4 5 6 99.38% 99.99966% To account for real-life increase in process variation over time, an empirically-based 1.5 sigma shift is introduced into the calculation
Six sigma ohjelmistotuotannossa Teollisuudessa suosittu tilastollisen laadunvarmistuksen menetelmä Motorola otti käyttöön 1980 luvulla Six sigma menetelmä koostuu kolmesta päävaiheesta: Määrittele (define) asiakkaan vaatimukset, toimitukset ja projektin tavoitteet huolellisesti. Mittaa (measure) prosessia ja sen tuotoksia nykyisen laadun määrittelemiseksi (kerää virhemetriikkaa). Analysoi (analyze) virhemetriikkaa tärkeimpien virhelähteiden tunnistamiseksi. ja kahdesta avustavasta vaiheesta Paranna (improve) prosessia virheiden syiden poistamiseksi. Valvo (control) prosessia, jotta virheiden aiheuttajat eivät ilmesty uudelleen. eli saadaan DMAIC menetelmä 37
Six sigma ohjelmistotuotannossa... Jos organisaatio on suunnittelemassa ohjelmistoprosessia (ei parantamassa), silloin ydinvaiheiden Määrittele (define) asiakkaan vaatimukset, toimitukset ja projektin tavoitteet huolellisesti. Mittaa (measure) prosessia ja sen tuotoksia nykyisen laadun määrittelemiseksi (kerää virhemetriikkaa). Analysoi (analyze) virhemetriikkaa tärkeimpien virhelähteiden tunnistamiseksi. lisäksi tulee kaksi avustavaa vaihetta Suunnittele (design) prosessi, jossa (1) vältetään virheiden aiheuttajat ja (2) vastataan asiakkaan vaatimuksiin. Varmista (verify), että prosessissa todella vältetään virheitä ja vastataan asiakkaan vaatimuksiin. eli saadaan DMADV menetelmä 38
Ohjelmiston luotettavuus (reliability, dependability) Vikaantumisväli mean-time-between-failure (MTBF) on yksinkertainen luotettavuuden mittari MTBF = MTTF + MTTR Lyhenteet MTTF ja MTTR ovat mean-time-to-failure ja mean-time-to-repair. Ohjelmiston palveluaste (software availability) on todennäköisyys, että ohjelma toimii vaatimusten mukaisesti tiettynä aikaan, ja määritellään Palveluaste = [MTTF/(MTTF + MTTR)] x 100%
IFIP WG 10.4 (www.dependability.org) WG 10.4 määrittelee dependability termin the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers oikeutettu luottamus tietokonejärjestelmän tuottamaan palveluun luottamus on subjektiivinen arvo, perustuu sidosryhmän tarpeeseen Dependability voidaan edelleen määritellä laatutekijöillä Luotettavuus, käyttövarmuus (reliability) järjestelmä palvelee ennalta määritellyllä tavalla Palveluaste, saatavuus (availability) järjestelmän palvelut ovat käytettävissä tarvittaessa Turvallisuus (safety) järjestelmä ei aiheuta vaaraa käyttäjälle Varmuus (security) järjestelmä on kestää hyökkäykset (confidentiality, integrity, availability)
ISO 9000 standardisarja ISO 9001: yritykselle, jolla on tuotekehitystä ja tuotantoa, laajin malli Sertifiointi tapahtuu tämän mallin mukaan ISO 9002: tuotantoprosessin hallintaan, keskilaaja malli ISO 9003: lopputuotteen laadun varmistukseen, suppein malli ISO 9004: soveltamisohje standardien soveltamiselle ISO 9000-3: soveltamisohje, kuinka ISO 9001 standardia tulisi tulkita ohjelmistoyrityksissä
ISO 9001 standardin mukaisia minimivaatimuksia laatujärjestelmälle Laatukäsikirja on olemassa Johto on määritellyt laatupolitiikan ja sitoutunut siihen Laatupäällikkö on nimetty huolehtimaan laatujärjestelmästä Laatujärjestelmä on olemassa todistettavasti (sopivasti dokumentoitu ja todisteita työn valvonnasta) Organisaation jäsenten toimenkuvat on määritelty Sisäisiä laatujärjestelmän arviointeja (auditointeja) suoritetaan suunnitelmallisesti Alihankkijoiden toiminta on valvonnassa Dokumenttien hallinta on kunnossa Korjaavat toimenpiteet laatupoikkeamien hallintaan on määritelty
Haikala (luentomateriaali) 2005
Haikala (luentomateriaali) 2005
Soveltuvat lait ja pohdiskelun aiheita 1. Tarkastukset lisäävät huomattavasti tuottavuutta, laatua ja projektin vakautta / no 17, Fagan 1976 Kuten Boehmin laki kertoi, puutteellisuudet vaatimuksissa ovat suurin syy projektin häiriöille. Tarkastuksilla voidaan jo kehitystyön alkuvaiheissa poistaa virheitä. Fagan raportoi myöhemmässä paperissa (1986), että säännöllisillä tarkastuksilla on poistettu 50-93 prosenttia tuoteen koko elinajan virheistä. Muita tuloksia tarkastuksien tehokkuudesta Weller 1992 70% Grady & van Slack 1994 60-70 %
2. Eri V&V menetelmien yhdistelmä voittaa aina yksittäisen menetelmän / no 20, Hetzel 1976, Myers 1978 Laatutekniikoiden yhdistelyn merkitys löydettyjen virheiden määrään/ Wood et al 1997 Yhdistetyt tekniikat Ohjelma A Ohjelma B Ohjelma C Valkealaatikkotestaus yksin Tarkastus + mustalaatikkotestaus Tarkastus + musta + valkealaatikkotestaus 48 % 53 % 73 % 63 % 71 % 81 % 76 % 83 % 90 %
Soveltuvat lait ja pohdiskelun aiheita 3. Virheiden esto on parempaa kuin virheiden poisto / hyp_no 9, Mays 1990 Maysin mukaan ns. mini-postmortem (katselmointi) jokaisen kehitysvaiheen jälkeen auttaa vaiheessa tehtyjen virheiden syiden selvittämisessä. Kun syy tiedetään, prosessia voidaan parantaa. Vastaavasti myös muita virheiden luokittelua ja syitä analysoivia menetelmiä (kuten Orthogonal Defect Classification, ODC) voidaan käyttää prosessin parantamiseen ja siten virheiden estämiseen.
Soveltuvat lait ja pohdiskelun aiheita McCallin laatumalli on kehitetty jo 1970 luvulla. Malli on kuitenkin vieläkin käyttökelpoinen. Kerro syitä, mistä tämä voisi johtua. Voiko ohjelma olla virheetön ja siitä huolimatta laadultaan huono? Perustele mielipiteesi. Virheiden määrä on yksi laadun indikaattori. Mitä muita indikaattoreita tunnet? Luentomateriaalissa (sivu 11) esitellään laatutekijöiden (kriteerien) välisiä yhteyksiä. Uudelleenkäytön ja käytettävyyden välille ei ole esitetty yhteyttä. Mieti millainen se voisi olla ja perustele esitystäsi. Mitä yhteistä on aktiviteeteilla katselmointi (review), tarkastus (inspection), läpikäynti (walkthrough) ja pariohjelmointi (pair programming). Missä suhteessa ne eroavat toisistaan?
Harjoitustehtävät: viikko 6 1. Tutustu käsitteisiin refaktorointi (refactoring) ja koodin paha haju (code smell) ja kerro lyhyesti, mitä ne tarkoittavat. Valitse Fowlerin listasta (http://refactoring.com/catalog/ index.html) viisi refaktorointitekniikkaa ja selitä niiden tarkoitus. 2. Valitse pankkiyhteysohjelma, jonka tunnet ja arvioi sen laatua käyttämällä luennoilla esiteltyä tarkistuslistaa (Olsina et al. 1999) 49
Harjoitustehtävät: viikko 6 3. Suorita tarkastus toisen ryhmän tekemälle vaatimusmäärittelydokumentille. Tarkastukseen kuuluu yksin tehty tarkastus (valmistautuminen) ja kirjauspalaveri, jossa kerätään yhteen yksin tehdyn tarkastuksen tulokset. Voit käyttää hyväksi luennoilla esiteltyjä lomakkeita, jotka löytyy kurssisivulta (Noppa) kohdasta Yhteinen lisämateriaali. Voit käyttää apuna myös tarkistuslistoja (Checklists tai Tarkistuslista_VM), jotka löytyvät samalta sivulta. Ryhmä voi pitää itse kirjauspalaverin ja raportoida harjoitusten vetäjille käytetystä ajasta ja löydetyistä epäilyistä dokumenttipohjien Inspection Issue Log ja Inspection Summary Form avulla viikon 7 harjoituksissa. Jos ette saa tarkastettavaa materiaalia toiselta ryhmältä, kysykää sopivaa materiaalia harjoitusten vetäjiltä harjoituksissa (tai luennoijalta). 50