Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 5.4. Laatukustannukset US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria (USA). voitaisiin säästää 22 mrd $, jos lisenssiohjelmistoissa olisi 50 % vähemmän virheitä. NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, Washington, D.C., 2002; 2 1
Laadun kustannuksista 40-1000X Virheen korjaamisen suhteellinen kustannus 1 3-6X 10X 15-40X 30-70X (82X IBM keskiarvo) Vaatimusmäärittely Suunnittelu Koodaus Kehitys- Testaus Hyväksymis- Testaus Käyttöönotto, Ylläpito Boehm 1981. Software Engineering Economics. 3 Laatukustannuksia DeFeo Joseph A., 2001. The Tip of the Iceberg. Quality Progress, May 2001 4 2
Eritellään: Tuotelaatu Virhekustannukset Asiakastyytyväisyys Yms. Prosessilaatu Laadukkaita tuotteita tehokkaasti 5 ISO 9126: ohjelmiston laatu Functionality - suitability, accuracy, interoperability, security, compliance Reliability - maturity, fault tolerance, recoverability compliance Usability - understandability, learnability, operability, attractiveness, compliance Efficiency - time behavior, resource utilization, compliance Maintainability - analyzability, changeability, stability, testability, compliance Portability - adaptability, installability, co-existence, replaceability, compliance 6 3
Laadun tekijöitä Prosessit Kehitysmenetelmät -> esim. Oliopohjaisen tai aspect oriented paradigman vaikutus Henkilöstön osaaminen Laadunvarmistus 7 Eri prosessimalleja Organisaatio Tuotekehitys Järjestelmä Laitteisto TQM ISO 9000 ITIL Ohjelmisto Palvelu Myynti HAllinto Myynti CMMI SPICE SW-CMM K2 Quality partners () koulutusmateriaalista sovellettu. 8 4
Laadunvarmistus ja CMMI Level5 Level4 Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Level3 Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Integrated Teaming Integrated Supplier Management Decision Analysis and Resolution Organizational Environment for Integration Level2 Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Level1 SEI 2002. CMMI v. 1.1. 9 Prosesien ja tuotteen laadunvarmistus CMMI taso 2 Arvioidaan prosesseja Arvioidaan tuotoksia Kommunikoidaan ja ratkaistaan ongelmat Dokumentoidaan tarpeelliset tiedot SEI 2002. CMMI v. 1.1. 10 5
Verifiointi CMMI taso 3 Valitaan verifioitavat tuotokset Jokaisessa projektissa tarpeen mukaan, osa projektisuunnitelmaa Määritellään menetelmät Luodaan tarvittava ympäristö Työkalut, tukimateriaali yms. Luodaan proseduurit ja kriteerit SEI 2002. CMMI v. 1.1. 11 Verifiointi CMMI taso 3 Toteutetaan vertaiskatselmointeja Analysoidaan katselmoinneista kerättyä tietoa Verifioidaan valitut tuotokset Analysoidaan tulokset ja toteutetaan korjaavat toimenpiteet 12 6
Validointi CMMI taso 3 Valitaan validoitavat tuotokset Luodaan tarvittava ympäristö Laaditaan kriteerit ja proseduurit Validoidaan tuotokset Analysoidaan tulokset 13 Katselmointi/katselmus Voidaan puhua eri tarkoituksessa Projektin statuksen seuranta Virheiden etsiminen Jne. Useita eri menetelmiä 14 7
Tarkastus Vaatimus tarkastuksen järjestämisestä Aloitus Suunnittelu Käynnistyskokous Itsenäinen tarkastus Kirjauspalaveri Korjaus ja seuranta Lopetus Gilb & Graham 1993. Software inspection. 15 Tarkastuksen merkitys Fagan (1976) totesi tuotannon tehokkuuden kasvaneen kymmeniä prosentteja. Doolan (1992) laski, että jokainen tarkastus maksaa itsensä takaisin 30-kertaisesti. Grady ja Van Slack (1994) arvioivat HP:n säästäneen tarkastusten ansiosta 21,5 miljoonaa dollaria vuonna 1993. Russellin (1991) tutkimuksessa jokainen tarkastuksiin käytetty tunti säästi 33 tuntia ylläpitokustannuksia. Basili ja Selby (1987) totesivat koodin lukemisen olevan tehokkaampi tapa löytää jopa samoja virheitä kuin testaus. 16 8
Puutteita tarkastuskäytänteissä Tieto/motivaatio -> asiakkaan vaikutus Koulutus Koodin tarkastus Katselmointitietojen hyödyntäminen Seuranta ja valvonta Kollanus 2005. 17 Tarkastusten keskeisiä (käytännön) ongelmia Valmistautuminen (!!!!) Palaverissa ajaudutaan epäoleellisiin asioihin Asenne Liian paljon materiaalia Palaverin järjestäminen voi viivästyttää aikataulua Väärät ihmiset osallistuvat Ei ole varattu resursseja (kiireiset gurut!) Kollanus 2005. 18 9
Yleistä testauksesta Testaus on ohjelman suoritusta, jonka tarkoituksena on löytää virheitä (Myers 1979) Testaus on suunnitelmallista virheiden etsimistä Kriittisissä projekteissa hyvin suuri osa kustannuksista voi kulua testaukseen Hyvät menetelmät, kuten katselmoinnit pienentävät testauksen tarvetta Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta 19 Yleistä testauksesta Pelkkä testaus ei riitä Ei löydä puutteita Ei toteuta ohjelman validointia Ei kykene arvioimaan arkkitehtuurin toimivuutta, ylläpidettävyyttä, dokumentaatiota yms. Virheet voivat kumota toisensa -> ei näy testauksessa Testaus pystyy todistamaan ainoastaan ohjelman virheellisyyden, ei virheettömyyttä 20 10
Testausasenteen tasot Taso 0: Testauksella ja perkauksella (debugging) ei ole mitään eroa -> Testaus ei ole järjestelmällistä ja suunniteltua Taso 1: Testauksen on tarkoitus osoittaa, että ohjelmisto toimii (oikein) -> Ei voida koskaan täysin todistaa testaamalla Taso 2: Testauksen tarkoitus on osoittaa, että ohjelmisto ei toimi (oikein) -> Ei tiedetä, milloin testaaminen tulisi lopettaa Beizer, 1990. Software testing techniques 21 Testausasenteen tasot Taso 3: Testauksen ei ole tarkoitus todistaa mitään, vaan lisätä luottamusta siihen, että ohjelmiston laatu on riittävä ennen kuin se julkistetaan (riskin pienentäminen). -> Tilastollinen laadunvarmistus Taso 4: Testaus ei ole (vain) tietty toiminto vaan ajattelutapa, joka tuottaa vähäriskistä ohjelmistoa kohtuullisin testauskustannuksin. -> Testattavuuden huomioon ottaminen kaikissa vaiheissa tuottaa jo sinänsä parempaa ohjelmistoa Beizer, 1990. Software testing techniques 22 11
Gilb. T. 2005. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. 23 12