LAADUN VAIKUTUSKETJU

Samankaltaiset tiedostot
LAADUN VAIKUTUSKETJU. Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Laadun vaikutusketju. Laadun vaikutusketju. Laadun vaikutusketju

LAADUN VAIKUTUSKETJU

Ohjelmistojen virheistä

ITK130 Ohjelmistojen luonne

Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen. Antti-Pekka Tuovinen (Jukka Paakki et al.

OHJELMISTOJEN LAATU. Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Laatu. Ohjelmistoprosessit ja ohjelmistojen. Neljä näkökulmaa laatuun

TOIMINNALLINEN MÄÄRITTELY MS

OHJELMISTOJEN LAATU. Ohjelmistoprosessit ja ohjelmistojen. Laatu. Laatu. Neljä näkökulmaa laatuun. Ohjelmisto

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen. Antti-Pekka Tuovinen (Jukka Paakki et al.

Sytyke ry:n laivaseminaari Software Technology Transfer Pekka Forselius

Ohjelmistotuotanto, s /27/2003

Käytettävyyslaatumallin rakentaminen verkkosivustolle

Studio ART Oy. Yritysesittely. Studio ART Oy. Kasöörintie Oulu p

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille

Yhdeksän mittaria ohjelmistotuotannon. seuraamiseen. tsoft. Vesa Tenhunen Joensuun yliopisto, TKT:n laitos

LAATURAPORTTI Iteraatio 1

Yleiskuvaus - LVpalvelukerroksen. laadulliset vaatimukset Jari Kokko & Vesa Mettovaara LUVAT JA VALVONTA -KÄRKIHANKE

Tietojärjestelmän osat

Kuka vastaa tietojärjestelmähankkeen laadusta?

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpidon lajeja

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

Testaaminen ohjelmiston kehitysprosessin aikana

Tapahtuipa Testaajalle...

Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia

Käytettävyydestä bisnestä: Tutkimuksesta tuotekehityksen kilpailutekijäksi

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Ohjelmistojen suunnittelu

Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

10 metriikkaa, joilla parannat johtamisen tasoa. Pekka Forselius, Senior Advisor, FiSMA ry Risto Nevalainen, Senior Advisor, FiSMA ry

58160 Ohjelmoinnin harjoitustyö

Ohjelmiston toteutussuunnitelma

Hankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi

Mittaamisen maailmasta muutamia asioita. Heli Valkeinen, erikoistutkija, TtT TOIMIA-verkoston koordinaattori

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Tilaajien rooli virtaustehokkuuden kehittämisessä

TIETOKANNAN SUUNNITTELU

He who stops being better stops being good

811312A Tietorakenteet ja algoritmit I Johdanto

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Fujitsu SPICE Lite. Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat. Copyright 2010 FUJITSU

Onnistunut Vaatimuspohjainen Testaus

Laadunvarmistustekniikat

Vikasietoisuus ja luotettavuus

Menetelmäraportti - Konfiguraationhallinta

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

Standardit osana käyttäjäkeskeistä suunnittelua

Arviointi ja mittaaminen

Uudelleenkäytön jako kahteen

Kahdenlaista testauksen tehokkuutta

Ohjelmistojen testaus

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Suomi.fi - Tietoturvallisuus sovelluskehityksessä. VAHTI sähköisen asioinnin tietoturvaseminaari

Tutkittua tietoa. Tutkittua tietoa 1

Työkalujen merkitys mittaamisessa

Suunnitteluvaihe prosessissa

Digitaalinen haavoittuvuus MATINE Tampere

TIEDÄTKÖ TUKEEKO HR YRITYKSESI LIIKETOIMINTAA? mittaamalla oikea suunta johtamiseen

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki

Toiminnallinen turvallisuus

Sulautettujen järjestelmien vikadiagnostiikan kehittäminen ohjelmistopohjaisilla menetelmillä

Käytettävyyden testaus

RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.

Ylläpitodokumentti. Boa Open Access. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

SYSTEEMITYÖ. Tärkeitä sanoja

Ohjelmistotuotanto s

OHJELMISTOJEN LAADUN JA KOON MITTAAMINEN

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä

Käyttäjäkeskeinen suunnittelu

KÄYTETTÄVYYSPÄIVÄ Meeri Mäntylä (sis. osia Anne Pirisen esityksestä) KÄYTETTÄVYYS. Mitä merkitystä sillä on?

Ohjelmistoprosessit ja ohjelmistojen laatu

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Ohjelmistotuotanto, syksy laatu Ohjelmiston laatu

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan

T Projektikatselmus

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)

Turvallisen sovelluskehityksen käsikirja. Antti Vähä-Sipilä, F-Secure

Ohjelmistoprosessit ja ohjelmistojen laatu Syksy 2012

Ohjelmistotuotteen hallinnasta

Kuntatuottavuuden ja tuloksellisuuden käsitteet. Versio

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki

Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2011

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä

Tuloksellinen kunta on kaikkien etu. Kunta-alan tuloksellisuuskampanja

IBM Iptorin pilven reunalla

Aki Jääskeläinen Tutkijatohtori Tampereen teknillinen yliopisto

Työasemien hallinta Microsoft System Center Configuration Manager Jarno Mäki Head of Training Operations M.Eng, MCT, MCSE:Security, MCTS

Kuopio Testausraportti Kalenterimoduulin integraatio

Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza

Transkriptio:

Käytön laadun ja tuotelaadun väliset riippuvuudet eli LAADUN VAIKUTUSKETJU 49 Laadun vaikutusketju Prosessi Ohjelmiston Ohjelmistotuotteen vaikutus vaikuttaa vaikuttaa vaikuttaa Prosessi n Sisäiset -tekijät Ulkoiset -tekijät Käytön aikainen riippuu riippuu riiippuu Määritellyt käyttötilanteet Prosessin mitat Sisäiset mitat Ulkoiset mitat Käytön aikaiset mitat [Nev13] Risto Nevalaisen esitys Järjestelmän ja ohjelmiston mittaaminen. http://www.sfsedu.fi/materiaalit (kts. IT-Standardit) 50 1

Laadun vaikutusketju Lähtökohtana ovat käyttäjän tarpeet ja käytön tilanteet Esimerkki: joukkoliikenteen aikataulutiedon hakeminen on-line palvelusta mobiililaitteella Käyttäjän tarpeet ja odotukset (käytön aikainen ): Tehokkuus (eli vaikuttavuus), tyytyväisyys - Tietojen pitää olla täsmällisiä ja ajan tasalla Tehollisuus, tyytyväisyys - Halutun linjan ja vuoron tietojen löytäminen pitää olla intuitiivista ja nopeaa 51 Laadun vaikutusketju Käytön un vaikuttavat palvelun ulkoiset piirteet (järjestelmän black-box tarkastelu) Käytettävyys - esimerkiksi Kuinka monen askelen (klikkauksen, muun syötteen) takana halutut tiedot ovat? Kuinka selvän ja nopean palautteen käli antaa käyttäjän toiminnoista? Suorituskyky (tehokkuus) - esimerkiksi Kuinka kauan koko käyttötapaus kestää? Kuinka kauan yksittäisten tietonäyttöjen tai sivujen latautuminen kestää? Kuinka nopeasti sovellus käynnistyy? Kuinka nopea tietoliikenneyhteys tarvitaan jne. (Data quality ei käsitellä tällä kurssilla) 52 2

Laadun vaikutusketju Sisäinen mahdollistaa (tai estää!) halutun ulkoisen laadun saavuttamisen (järjestelmän whitebox eli lasilaatikkotarkastelu) Suorituskyky (esim. tiedonhakujen kesto) määräytyy pitkälle ohjelmiston (ja laitteiston) arkkitehtuurista ja teknologiavalinnoista sekä tekniikoiden oikeasta käytöstä Käytettävyyteen vaikuttavat suoraan käyttöliittymän suunnittelu (esim. useimmin tarvittujen toimintojen nostaminen aloitusnäyttöön sekä niiden suorittamiseen tarvittavien vuorovaikutusten määrän minimointi) ja epäsuoremmin palvelun eri toimintojen käytön monitorointija tilastointikyvykkyys (instrumentointi, logit) 53 Laadun vaikutusketju Palvelun toteutuksessa käytettävät resurssit ja menetelmät vaikuttavat kaikkiin laadun alueisiin Käytettävyyssuunnittelijoiden ja ohjelmistoarkkitehtien sekä kehittäjien tiedot, taidot ja kokemus - ja ennen muuta asenne (myös johdon) Aikataulu ja budjetti suhteessa toim. määrään Käyttäjien osallistaminen kehitykseen ja käyttäjien palautteen systeemaattinen kerääminen ja hyödyntäminen Laatutavoitteiden esilletuonti ja jatkuva arviointi 54 3

Laadun vaikutusketju Kehittämisprosessin Ohjelmiston Järjestelmän Järjestelmän käytön aikainen Resurssien Muiden osajärjestelmien Määritelty käyttötilanne A B A vaikuttaa B:hen, tai B seuraa A:sta Sidosryhmät Tehtävä Ympäristö [Nev13] Risto Nevalaisen esitys Järjestelmän ja ohjelmiston mittaaminen. http://www.sfsedu.fi/materiaalit (kts. IT-Standardit) 55 Käyttäjäryhmät ja ISO/IEC 25010 tunnistaa 3 käyttäjäryhmää 1. Pääasiallinen käyttäjä (primary user) Henkilö, joka on järjestelmän kanssa vuorovaikutuksessa järjestelmän pääkäyttötarkoituksen mukaisesti 2. Toissijainen, pääkäyttöä tukeva käyttäjä (secondary user) Sisällön tuottaja, järjestelmävalvoja, turvallisuusvalvoja Ylläpitäjä, asentaja, suunnittelija (analyst), testaaja 3. Epäsuora käyttäjä (indirect usr) Vastaanottaa järjestelmän tuottamia tulostietoja, mutta ei itse ole vuorovaikutuksessa sen kanssa 56 4

Käyttäjäryhmät ja Jokaisella käyttäjäryhmällä on omat tarpeensa, jotka tulee ottaa huomioon järjestelmän määrittelyssä, suunnittelussa ja toteutuksessa Tuotelaadun piirteet ovat eri tavalla tärkeitä eri käyttäjäryhmille Ohjelmiston ja sitä suorittavan järjestelmän ominaisuudet määräävät tuotelaadun eri käyttöyhteyksissä (ja eri käyttäjäryhmille) Taulukko seuraavalla dialla 57 Käyttäjäryhmät ja Tuotepiirre Toiminnallinen sopivuus Vaikuttaa pääkäyttäjän kokemaan käytön un X Vaikuttaa ylläpitotehtävissä koettuun un Muiden sidosryhmien näkemä Tehokkuus X X Yhteensopivuus Käytettävyys X Luotettavuus X X Turvallisuus X X Ylläpidettävyys Siirrettävyys X X X 58 5

Sisäisen ja ulkoisen laadun piirteet Toiminnallinen sopivuus Tehokkuus Yhteensopivuus Käytettävyys Luotettavuus Turvallisuus Ylläpidettävyys Siirrettävyys Toiminnallinen kattavuus Vasteaika Resurssien käyttösuhde Kapasiteetti Toiminnallinen oikeellisuus Toiminnallinen soveltuvuus Rinnakkaiselo Yhteensopivuus Soveltuvuuden selkeys Opittavuus Helppokäyttöisyys Käyttövirheiden estäminen Saatavuus Tietosuoja Aitous Käyttöliittymänmiellyttävyys Ohjelmistotuotteen kypsyys Vikasietoisuus Toipumisvalmius Koskemattomuus Kiistämättömyys Todenperäisyys Rakenteellinen selkeys Testattavuus Uudelleenkäytettävyys Analysoitavuus Muunneltavuus Sovitettavuus Asennettavuus Korvattavuus Matala kynnys Ulkoinen, pääasiassa ulkoinen, sekä sisäinen että ulkoinen, pääasiassa sisäinen 59 Mistä ne tulevat? OHJELMISTOJEN VIOISTA 60 6

Blue screen of death 61 Vioista Vikojen vähäinen määrä on perinteisesti ollut yksi tärkeimpiä laadun indikaattoreita Esimerkiksi ohjelmistojen laadun ja kehitysprojektien tuottavuuden parissa pitkän päivätyön tehnyt Capers Jones on määritellyt [Jon08] laadun seuraavasti The absence of defects that would make software either stop completely or produce unacceptable results. Defects can be traced to requirements, to design, to code, to documentation, or to bad fixes of previous defects. Tällä tavoin määritelty on kvantifioitavissa melko suoraviivaisesti (sekä mittaamista että ennustamista varten), mutta on muuten kovin suppea Jones on myöhemmin laajentanutkin laadun määritelmäänsä kattamaan mm. käytettävyyden [Jon08] Capers Jones, Applied Software Measurement. McGraw-Hill, 2008. 62 7

Virhe vika - häiriö Ohjelmistojen laadun kannalta on oleellista erotella toisistaan (kehitys-) virhe eli erehdys (error, mistake), (ohjelmisto-) vika (fault) ja (toiminta-) häiriö (failure/defect). Koodin kirjoittajat tekevät virheitä. Virhe voi koskea rakennetta (esim. viittaus väärään muuttujaan) tai koodin logiikkaa (esim. vaatimus on tulkittu väärin, käytetään jotain APIa väärällä tavalla) jne. Kun erehdyksessä kirjoitettu koodi saa ohjelmiston toimimaan väärin, kyse on (ohjelmisto-) viasta. Kaikki viat eivät tee näin, sillä vikaa seuraavat koodirivit saattavat neutraloida vian vaikutuksen, tai vika voi peittyä toisten vikojen vaikutuksesta. 63 Virhe vika - häiriö Kun viallista koodia suoritetaan, syntyy häiriö. Kaikista ohjelmistovioista ei seuraa toimintahäiriöitä. Vika saattaa olla hautautuneena koodiin sellaiseen paikkaan, että sitä ei suoriteta koskaan (esimerkiksi harvinaiseen poikkeuskäsittelijään tai käytännössä mahdottomaan parametrien kombinaatioon). Puhekielen bugi (bug) tarkoittaa yleensä virhettä tai vikaa Defekti (defect) voi tarkoittaa myös vikaa 64 8

Virheet, viat ja häiriöt Vain osa kaikista virheistä näkyy vikoina ja osa vioista häiriöinä loppukäyttäjälle asti (ohjemiston tuotantoversiossa) Suuri osa häiriöistä tulee ilmi jo kehitysaikana testauksen ja muun laadunvarmistuksen ansioista Kuitenkin mikä tahansa koodiin jäänyt passiivinen vika saattaa koodia muutettaessa aktivoitua ja mikä tahansa vika saattaa sopivassa käytössä aiheuttaa häiriön. Kehitystiimille laadukas tuote tarkoittaa vähäistä vikojen määrää. Loppukäyttäjän kannalta se tarkoittaa vähäistä häiriöiden määrää. 65 Virheet, viat ja häiriöt Yleensä ohjelmistoista raportoitujen häiriöiden määrä on välillä 0,1 5,0 häiriötä tuhatta koodiriviä kohden Capers Jones on kerännyt vuosikymmeniä asiakkaidensa projekteista (n. 13000 kpl) tietoja häiriöpotentiaaleista (defect potentials) ja häiriöiden poistamistehokkuudesta (defect removal efficiency) Jonesin data [Jon13] osoittaa keskimääräiseksi häiriöpotentiaaliksi 5,0 häiriötä per toimintopiste (~ 50-60 riviä Javan tasoista ohjelmointikieltä) ja keskim. häiriöiden poistamistehokkuudeksi 85% Eli noin 15 häiriötä per 1 KLOC Parhailla projekteilla luvut ovat 2,5 ja 96% eli 2,6 per 1 KLOC Kts. diat 23 25 [Jon13] [Jon13] Capers Jones, Software Quality: A Survey of the State of the Art, 2013. http://namcookanalytics.com/software-quality-survey-state-art/ (haettu 16.3.2015) 66 9

Ohjelmistojen virhetyypit 1 Koska ohjelmistohankkeissa tehdyt virheet vaikuttavat ohjelmiston un, on tärkeää tietää, minkä tyyppisiä virheitä tehdään. Galin [Gal04] listaa yhdeksän virhetyyppiä ja antaa kustakin esimerkkejä: 1. Väärin määritellyt vaatimukset Vaatimusten määrittelytavassa on virheitä Puuttuvia vaatimuksia Epätäydellisiä vaatimuksia Ylimääräisiä vaatimuksia 2. Asiakkaan ja kehittäjän väliset kommunikaatiokatkokset Asiakkaan vaatimukset ymmärretään väärin Asiakkaan muutostoiveet ymmärretään väärin Asiakkaan vastaukset kysymyksiin ymmärretään väärin [Gal04] Daniel Galin: Software Quality Assurance - From Theory to Implementation. Pearson Education, 2004 67 Ohjelmistojen virhetyypit 2 3. Tahalliset poikkeamat vaatimuksista Ohjelmistossa uudelleenkäytetään koodia ilman kunnollista analyysia vaadittavista muutoksista Osa vaatimuksista jää toteuttamatta budjetin tai aikataulun ylittymisen johdosta Kehitystiimi muuttaa vaatimuksia kysymättä asiasta asiakkaalta 4. Ohjelmiston logiikan suunnitteluvirheet Väärien tai tilanteeseen sopimattomien algoritmien käyttö Tilasiirtymävirheet Raja-arvovirheet 5. Koodausvirheet Painovirheet Kielioppivirheet Vaatimusten tai suunnittelun tulkintavirheet 68 10

Ohjelmistojen virhetyypit 3 6. Dokumentointi- ja koodausohjeiden noudattamatta jättämiset Vaikealukuiset dokumentit Vaikeaselkoinen ohjelmakoodi 7. Testausprosessissa oikomiset Vajaa testaussuunnitelma Löydettyjen vikojen ja virheiden kehno dokumentointi Tiukan aikataulun johdosta tapahtuva puutteellinen vikojen ja virheiden korjaus 8. Toimintatapavirheet Väärin tulkittu ohjelmiston tarkoitettu käyttötapa (käyttötapaus) 9. Dokumentointivirheet Dokumentoimattomat toiminnot Virheelliset toimintaohjeet Ylimääräiset ja puuttuvat toiminnot 69 Häiriöiden lähteet Jonesin mukaan Capers Jones on kerännyt vuosikymmeniä asiakkaidensa erityyppisistä projekteista tietoja häiriötiheyksistä ja niiden syntyyhteyksistä (eli virhetyypeistä) Katso dia 58 esityksessä [Jon13] Jones & Bonsignour [JoB11] For large systems, requirements defects, architectural defects, and design defects are the main sources of quality problems (Ch. 2) [Jon13] Capers Jones, Software Quality: A Survey of the State of the Art, 2013. http://namcookanalytics.com/software-quality-survey-state-art/ (haettu 16.3.2015) [JoB11] C. Jones, O. Bonsignour, The Economics of Software Quality. Addison-Wesley Professional, 2011 70 11

Vikojen estäminen ja poistaminen Monet ohjelmistokehityksen menetelmät, työtavat ja työkalut tähtäävät vikojen syntymisen estämiseen tai vikojen tehokkaaseen poistamiseen Tehokkuus, jolla kehityksen aikana poistetaan vikoja ohjelmistosta, on perinteisesti ollut keskeinen mittari kehitysprosessin laadulle Tehokkuuden mittaaminen vaatii kirjanpitoa havaituista vioista, niiden vakavuudesta ja lähteestä/syntyvaiheesta Nopeaa reagointia korostavissa web-projekteissa painotetaan pikemmin häiriöiden nopeaa havaitsemista tuotannossa ja korjausten pikaista julkaisua Tästä lisää myöhemmin kurssilla 71 Show me the money OHJELMISTOJEN LAADUN TALOUDELLINEN MERKITYS 72 12

Laatu, kustannukset ja tuotot Ohjelmistoja tuottavia ja käyttäviä organisaatioita kiinnostaa taloudellisesta näkökulmasta laadun vaikutus seuraaviin asioihin [JoB11] Kehityksen, ylläpidon, parannuksen ja tuen kustannukset. Kehityksen, ylläpidon, parannuksen ja tuen aikataulut Ohjelmiston suorat myyntitulot Liitännäispalveluista ja tuotteista saatavat tulot O:n käytön oppimiskäyrä O:n käytöstä seuraavat operationaaliset säästöt Uudet liiketoimintamahdollisuudet, jotka o:n käyttö tuo mukanaan Liiketoiminnan ja yrityksen johdon näkökulmasta on tärkeää, että käytetty laadun määritelmä ja mittarit mahdollistavat laadun vaikutusten kvantifioinnin 73 Laadun taloudellinen merkitys Tiivistettynä, vaikuttaa neljään taloudellisesti merkittävään alueeseen ohjelmistojen tuotannossa ja käytössä 1. Ohjelmistojen kehittämisen ja ylläpidon kustannukset ja työmäärä 2. Kaupallisten ohjelmistojen kannattavuus 3. Inhimillisen työn tuottavuus 4. Ohjelmistojen rooli uusissa ja innovatiivisissa tuotteissa ja palveluissa 74 13

Huonon laadun vaikutus kehitykseen ja ylläpitoon Huono Venyttää testausta ja aiheuttaa epävarmuutta toimitusaikatauluun Korjaukset ja uudelleen tekeminen aiheuttavat suurimman kustannuspaineen Aiheuttaa ylitöitä ja budjetin pettämisen Vaatii julkaisun jälkeen kallista asiakastukea Lisää julkaisun jälkeisen ylläpidon kustannuksia Voi viedä oikeudenkäyntiin sopimusrikkomuksesta 75 Hyvän laadun vaikutus kehitykseen ja ylläpitoon Hyvä Lyhentää testaukseen käytettyä aikaa ja parantaa toimitusaikataulun ennustettavuutta Vähentää korjausten ja uudelleen tekemisen määrää jopa 50% Vähentää yllättäviä ylitöitä ja pienentää kuluylityksiä Vähentää julkaisun jälkeistä asiakastuen tarvetta Vähentää julkaisun jälkeisen ylläpidon kustannuksia Pienentää oikeudenkäyntien riskiä 76 14

Huonon laadun vaikutus inhimillisen työn tuottavuuteen Huono Lisää toimintahäiriöistä johtuvaa odottelua ja toimettomuutta Voi hidastaa toimenpiteiden suoritusta ja pienentää työpanoksen tuottavuutta Voi johtaa onnettomuuksiin tai transaktiovirheisiin Häiriöiden seurausten korjaaminen aiheuttaa ylimääräistä työtä Lisää myös väärien häiriöraporttien määrää Johtaa välillisiin vahinkoihin ja kalliisiin liiketoiminnan ongelmiin 77 Hyvän laadun vaikutus inhimillisen työn tuottavuuteen Hyvä Vähentää toimintahäiriöitä ja niistä johtuvaa toimettomuutta Auttaa optimoimaan työntekijöiden työsuorituksia Vähentää onnettomuuksien tai transaktiovirheiden todennäköisyyksiä Pienentää häiriöiden seurausten korjaamistarvetta Vähentää väärien ja aiheettomien häiriöraporttien määrää Vähentää välillisiä vahinkoja ja liiketoiminnan ongelmia 78 15

Quality is free Philip Crosby It is always cheaper to do the job right the first time Quality is free, but no one is ever going to know it if there isn't some sort of agreed-on system of measurement http://www.philipcrosby.com/25years/read.html http://en.wikipedia.org/wiki/philip_b._crosby 79 16