Ohjelmistotekniikka - Luento 9 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 1
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 2
Laatu 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. 6
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ä 7
McCallin laatukolmio muunnokset Ylläpidettävyys Joustavuus Testattavuus Tuotteen muutos Siirrettävyys Uudelleenkäytettävyys Yhteistoiminnallisuus Tuotteen siirto Tuotteen toiminta Oikeellisuus Käytettävyys Tehokkuus asiakkaan tarpeet Luotettavuus Eheys tieto ja sen saanti 8
degree to which software is composed of discrete components such that a change in one component has minimal impact on other components Ohjelmiston tulee olla hyödyllinen siirettävyys device independence self-containedness accuracy luotettavuus completeness robustness/integrity yleinen hyöty hyöty käytössä tehokkuus consistency accountability käytettävyys device efficiency accessibility testattavuus communicativeness self-descriptiveness ylläpidettävyys ymmärrettävyys structuredness conciseness legibility muunneltavuus augmentability Boehmin malli (Boehm et al. 1978) degree to which design can be extended compactness of program code
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 10
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 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 sovelluksen ominaispiirteet Luotettavuus Ylläpidettävyys Ylläpidettävyys Siirrettävyys Ylläpidettävyys Tehokkuus, luotettavuus Tehokkuus, luotettavuus Toiminnallisuus -> security Toiminnallisuus -> interoperability laatuominaisuudet 12
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? 13
Laatudilemma Huono laatu Riittävän hyvä Perfektionismi Time-to-market Asiakastyytyväisyys
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
94 Vaatimusten määrittely 0 0 % 0 10 10 Integrointitestaus 6 4 Suunnittelu 6 4 * 1.5 = 6 25 0 % 37 10 27 Läpi kulkevat Kertautuvat Vaiheen uudet Virheenpoisto % Koodaus & yksikkötestaus 10 27 * 3 = 81 25 20 % 0 0 50 % 47 Hyväksymistestaus 94 0 0 50 % 24 Järjestelmätestaus 0 0 50 % Kun ei käytetä katselmointia Virheitä jää 12
24 Vaatimusten määrittely 0 70 % 0 10 3 Integrointitestaus 2 1 Suunnittelu 2 1 * 1.5 = 1.5 25 50 % 15 5 10 Läpi kulkevat Kertautuvat Vaiheen uudet Virheenpoisto % Koodaus & yksikkötestaus 5 10 * 3 = 30 25 60 % 0 0 50 % 12 Hyväksymistestaus 24 0 0 50 % 6 Järjestelmätestaus 0 0 50 % Kun käytetään katselmointia Virheitä jää 3
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 (Ekatselmointi) vie 6 työtuntia keskimäärin yhden vaatimusmäärittelyvirheen löytäminen ja korjaaminen testausvaiheessa (Etestaus) vie 45 työtuntia Työmäärän säästö = Etestaus - Ekatselmointi = 45-6 = noin 40 työtuntia/virhe Kun katselmoinnilla löytyi vaatimusmäärittelyissä virheitä 22, säästö katselmointia käytettäessä on noin 880 työtuntia 20
Ovat: Mitä katselmoinnit ovat/ eivät ole? 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 21
Osallistujat katselmoinnin vetäjä (moderaattori) standardien noudattamisen tarkastaja (SQA) tekijä ylläpidon asiantuntija kirjuri käyttäjän edustaja katselmoija 22
Katselmoinnin suoritus 1. 2. 3. valmistaudu - etsi epäilyksiä tuotteesta ennen kirjauspalaveria katselmoi tuotetta - älä tekijää pysy rauhallisena, tee kysymyksiä - älä syytä 4. 5. 6. noudata katselmoinnin asialistaa ota esiin epäilyksiä, älä ratkaise niitä kiinnitä huomiosi ratkaisun oikeellisuuteen - vältä keskustelua tyyliseikoista 7. 8. aikatauluta katselmoinnit projektisuunnitelmaan talleta katselmoinnin tulokset ja raportoi niistä 23
Inspection Issue Log Project: Origin: Requirements, Design, Implementation, Testing Inspection ID: Meeting Date: Recorder: Type: Severity: Missing, Wrong, Extra, Usability, Performance, Style, Clarity, Question Major, minor Defects Found: Major, minor Defects Corrected: Major minor Origin Type Severity Location Description 1. 2. 3. 4. 5. 6. Wiegers 2002
Inspection Issue Log Project: OT-esimerkkiprojekti Origin: Requirements, Design, Implementation, Testing Inspection ID: 20171120-2A Meeting Date: 2017-11-20 Recorder: AJu Type: Severity: Missing, Wrong, Extra, Usability, Performance, Style, Clarity, Question Major, minor Defects Found: 2_ Major, 1_ minor Defects Corrected: Major minor Origin Type Severity Location Description 1. R M M CR-2 Käyttäjää ei määritelty 2. I C/S m main.cpp Puuttuva pääohjelmakommentti 3. D W M CD-pack-2 Väärä yhteysnuolityyppi yläluokan (käyttäjä) ja aliluokan (asiakas) välillä, pitäisi olla periytys, eikä yksisuunt. assosiaatio 4. 5. 6. Huom! Ei yleensä kuin yksi dokumentti (kooditiedosto, tai entiteetti ) kerrallaan tarkastukseen! Wiegers 2002
Inspection Summary Report Inspection Identification: Project: Inspection ID: Meeting Date: Work Product Description: Inspectors Signature Preparation Time Author: AJu 3 hours Moderator: JLa 4 hours Recorder: HHe 2 hours Reader: NNe 3 hours Inspector: SPu 4.5 hours Inspection Data Pages or Lines of Code: Meeting Time: 1 hours Planned for Inspection: 3 Total Planning Effort: 1 labor hours Actually Inspected: 3 Total Overview Effort: 0.5 labor hours Total Preparation Effort: 16.5 labor hours Actual Rework Effort: 5 labor hours Product Appraisal ACCEPTED NOT ACCEPTED as is reinspect following rework conditionally upon verification inspection not completed Verifier: AJu Projected Rework Completion Date: 13.12.2017 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? 27
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 ai jokaisesta tuotteesta i. Talletetaan virheiden määrä, fi jotka löytyivät osasta ai. Lasketaan arvio virheiden määrästä tuotteessa i kertomalla fi arvolla 1/ai. 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 31
Laadunvarmistusryhmän rooli (esim. RUP prosessissa) LV-suunnitelma projektille - auditoinnit, katselmoinnit - sopivat standardit 1 - raportointi Inception (aloitus) Elaboration (kehittäminen) -käyttötapausmallit -analyysimalli -arkkitehtuurikuvaus 3 Katselmoi projektin prosessin aktiviteetteja (vastaako määriteltyä) -tuotteen ominaisuudet -alustavat käyttötapausmallit suunnittelu mallintaminen 5 2 Osallistuu projektin ohjelmistoprosessin kehittämiseen Varmistaa, että poikkeamat työssä ja tuotteissa dokumentoidaan ja niistä raportoidaan ja poikkeamia seurataan kommunikointi julkaisu Production (tuotanto) Ohjelmiston lisäys (inkrementti) toimitus Transition (siirto) -valmis ohjelmiston osa -Beta testauksen raportit -käyttäjän palautteet rakentaminen Construction (rakentaminen) -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) 33
2 10 5 17 17 Tiedonkeruulomake (checksheet) Käsitteet Määritelmät Hierarkia Rakenne Prosessin laatu Laatunäkökulman ymmärtäminen Yhteydet Tarkastus & katselmointi Testaus Yleiset Esimerkit Yrityssidonnaiset Laatumalli Kehitysprosessi Työkalut Tilat Resurssien laatu Henkilöstö Laadukkaan ohjelmiston kehittäminen Pylväskaavio (bar graph) faults/hr Ishikawa kaavio Pareto kaavio 40 30 20 10 50 01 5 10 15 20 25 UCL LCL Valvontakaavio (control chart) 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% -6-5 -4-3 -2-1 0 1 2 3 4 5 6 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% 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 36
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% 39
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) 40
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ä 41
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 42
Haikala (luentomateriaali) 2005
Haikala (luentomateriaali) 2005 44
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 % 45
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.