Jakość projektów informatycznych. Rozwój i testowanie ...

28

Transcript of Jakość projektów informatycznych. Rozwój i testowanie ...

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie,ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Opieka redakcyjna: Ewelina Burska

Projekt okładki: Studio Gravite/OlsztynObarek, Pokoński, Pazdrijowski, Zaprucki

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/zapejaMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

ISBN: 978-83-283-0156-6

Copyright © Helion 2015

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

Spis tre ciPrzedmowa ...................................................................................... 7

Rozdzia 1. Wprowadzenie .................................................................................. 9

Rozdzia 2. Koncepcja jako ci .......................................................................... 11Definicja jako ci ............................................................................................................. 11Normalizacja .................................................................................................................. 15Znaczenie jako ci w projektach informatycznych .......................................................... 16Koszty jako ci ................................................................................................................ 21

Rozdzia 3. Zarz dzanie jako ci ...................................................................... 35Zarz dzanie procesowe ................................................................................................... 35Zarz dzanie jako ci ....................................................................................................... 40Zarz dzanie przez jako ................................................................................................ 56Koncepcje zarz dzania jako ci ..................................................................................... 63

Zasady Deminga ......................................................................................................... 63Ko a jako ci ................................................................................................................ 75Inne koncepcje, narz dzia i techniki zarz dzania jako ci ......................................... 79

Zarz dzanie jako ci oprogramowania ........................................................................... 80Jako oprogramowania ............................................................................................. 80Kodeks post powania ................................................................................................. 85

Manifest jako ci ............................................................................................................. 87Standardy ........................................................................................................................ 88

ISO 9000 Quality Management .................................................................................. 89ISO 19011: 2011 — Guidelines for auditing management systems ........................... 91ISO/TS 16949: 2009 — Quality management systems — Particular

requirements for the application of ISO 9001: 2008 for automotive productionand relevant service part organizations .................................................................... 91

TickIT i TickIT plus ................................................................................................... 91ISO Technical Report 19759 (SWEBOK®) ................................................................ 93

Rozdzia 4. Zapewnienie jako ci ...................................................................... 95Wprowadzenie ................................................................................................................ 95Planowanie procesu zapewnienia jako ci ....................................................................... 99

Plan zapewnienia jako ci ........................................................................................... 99Czynniki wp ywu ..................................................................................................... 105Charakterystyki jako ciowe dla procesu i produktu ................................................. 106

Poleć książkęKup książkę

4 Jako projektów informatycznych

Weryfikacja i walidacja ................................................................................................ 118Przegl dy .................................................................................................................. 124Listy kontrolne ......................................................................................................... 137

Metryki ......................................................................................................................... 143Anomalie — charakterystyka i sposób obs ugi ............................................................. 148Standardy ...................................................................................................................... 159

ISO/IEC 25000: 2005 — Software Engineering — Software product QualityRequirements and Evaluation (SQuaRE) — Guide to SQuaRE ............................ 159

ISO 9241 — Ergonomics of Human System Interaction .......................................... 159ISO 31000: 2009 — Risk Management — Principles and guidelines ...................... 160IEEE 610.12: 1990 — Standard Glossary of Software Engineering Terminology ... 160IEEE 828: 2012 — Standard for Configuration Management in Systems

and Software Engineering ...................................................................................... 160IEEE 830: 1998 — Recommended Practice for Software Requirements

Specifications ......................................................................................................... 161IEEE 1233: 1996 — Guide for Developing of System Requirements

Specifications ......................................................................................................... 161IEEE 1362: 1998 — Guide for Information Technology — System Definition

— Concept of Operations (ConOps) Document .................................................... 161IEEE 29148: 2011 — Systems and software engineering — Life cycle

processes — Requirements engineering ................................................................ 161IEEE 730: 2002 — Standard for Software Quality Assurance Plans ....................... 162IEEE 1012: 1986 — Standard for Software Verification and Validation Plans ....... 162IEEE 1028: 2008 — Standard for Software Reviews and Audits ............................ 162IEEE 1044: 2009 — Standard Classification for Software Anomalies .................... 162IEEE 1061: 1998 — Standard for a Software Quality Metrics Methodology .......... 162

Rozdzia 5. Testowanie .................................................................................. 163Podstawy testowania .................................................................................................... 167Organizacja testów ....................................................................................................... 170

Niezale no testowania .......................................................................................... 170Kontekst testowania ................................................................................................. 173Strategia testów ........................................................................................................ 174Poziomy testów ........................................................................................................ 179Cele testowania ........................................................................................................ 183

Techniki testowe ........................................................................................................... 184Techniki oparte na intuicji i do wiadczeniu ............................................................. 186Techniki oparte na specyfikacji ................................................................................ 187Techniki oparte na kodzie ........................................................................................ 195Techniki oparte na usterkach .................................................................................... 201Techniki oparte na u yciu ........................................................................................ 202Techniki oparte na charakterze systemu ................................................................... 202

Proces testowy .............................................................................................................. 203Podstawowy proces testowy ..................................................................................... 203

Metryki zwi zane z testowaniem .................................................................................. 214Ocena produktu poddawanego testom ...................................................................... 215Ocena wykonywanych testów .................................................................................. 216

Dokumentacja testów ................................................................................................... 217Dokumentacja zarz dcza .......................................................................................... 220Dokumentacja specyfikacji testów ........................................................................... 226Dokumentacja wykonania testów ............................................................................. 232Dokumentacja raportów z testów ............................................................................. 233

Poleć książkęKup książkę

Spis tre ci 5

Wsparcie narz dziowe .................................................................................................. 236Standardy w testowaniu ................................................................................................ 237

BS 7925-1: 1998 — Software testing — Vocabulary .............................................. 237BS 7925-2: 1998 — Software testing — Software component testing .................... 237IEEE 1008: 1987 — Standard for Software Unit Testing ........................................ 237IEEE 829: 1998 — Standard for Test Documentation ............................................. 237ISO/IEC/IEEE 29119 — Software Testing .............................................................. 238Normy procesowe .................................................................................................... 244Inne standardy .......................................................................................................... 244

Rozdzia 6. Doskonalenie jako ci ................................................................... 247Doskonalenie procesów organizacyjnych ..................................................................... 248

CMMI® .................................................................................................................... 248TickITplus ................................................................................................................ 254ISO/IEC 15504 — Software Process Improvement and Capability

Determination (SPICE) .......................................................................................... 254Doskonalenie procesu testowego .................................................................................. 256

IDEAL ...................................................................................................................... 257TMMi® ..................................................................................................................... 258TPI® Next ................................................................................................................. 269CTP .......................................................................................................................... 271Inne modele doskonalenia procesu testowego .......................................................... 274

Lean Software Development (LSD) ............................................................................. 275Zasady LSD .............................................................................................................. 276

Rozdzia 7. Podsumowanie ............................................................................. 281

Literatura ..................................................................................... 283

Skorowidz .................................................................................... 291

Poleć książkęKup książkę

6 Jako projektów informatycznych

Poleć książkęKup książkę

Rozdzia 2.

Koncepcja jako ci

Jako to pewien stopie doskona o ci— Platon

Definicja jako ciTematu zapewnienia jako ci oraz testowania nie sposób rozpocz bez wprowadzeniapoj cia jako ci. Termin ten przewija si w niemal e wszystkich znanych cz owiekowiobszarach — mówimy o jako ci us ug, produktów, procesów, ale i o jako ci samegoycia. Mo na powiedzie , e w ostatnich czasach zapanowa a swoista moda na jako ,

poniewa wraz z rozwojem technologicznym, gospodarczym i spo ecznym konsumencioczekuj lepszego spe niania ich oczekiwa i zaspokajania potrzeb. Klienci wymagajwysokiej jako ci, producenci i us ugodawcy d do spe nienia oczekiwa (lub przy-najmniej sprawiania takiego wra enia) przez dostarczanie dóbr o nowej czy innowacyj-nej jako ci. Jako jest poj ciem modnym. Czym jednak jest i jak j zdefiniowa ?

Z definicj jako ci wi si pewne mity. Wielu ludzi stoi na stanowisku, e jako jestpoj ciem wysoce zale nym od percepcji poszczególnych jednostek, co przek ada sina niemierzalno i nieokre lono . Wed ug do popularnego twierdzenia, poniewadefinicja jako ci zale y od postrzegania danej osoby (co akurat jest prawd ), nie mo eby jednoznacznie okre lona, a co za tym idzie — zmierzona. Jest to niew tpliwieciekawe podej cie do tematu, jednak niezbyt zgodne ze stanem faktycznym.

Koncepcja jako ci znana jest ju od czasów staro ytnych. Po raz pierwszy poj cie znanedzi jako jako zosta o wprowadzone w Kodeksie Hammurabiego z 1750 r. p.n.e. W ko-deksie tym istnia przepis, który nakazywa kara mierci murarza, je li zbudowanyprzez niego dom nie by odpowiedniej jako ci — niska jako w tym kontek cieoznacza a dom, który zawala si i zabija mieszka ców.

W kolejnych wiekach poj cie jako ci by o rozwijane w Grecji, kolebce filozofii i naukprzyrodniczych.

Poleć książkęKup książkę

12 Jako projektów informatycznych

Pierwsz pisan definicj jako ci wprowadzi grecki filozof Platon (427 – 347 p.n.e.),okre laj c j jako „pewien stopie doskona o ci”. W tym uj ciu jako by a poj ciemfilozoficznym, silnie zwi zanym z koncepcj pi kna i warto ciowania danego przed-miotu przez u ytkownika (Kili ski 1979).

Nieco inne podej cie reprezentowa Arystoteles (384 – 322 p.n.e.), definiuj c jakojako „to, co sprawia, e rzecz jest rzecz , któr jest” (Skrzypek 2000). Definicja Ary-stotelesa jest o tyle istotna, e k adzie nacisk na powi zanie jako ci z przedmiotem,którego ta jako dotyczy. Mo na tu znale ród a nowoczesnych definicji okre laj cychjako jako zgodno wyrobu z okre lonymi charakterystykami.

Filozoficzne postrzeganie jako ci kontynuowano i rozszerzano w bli szych nam czasach.W XVII w. René Descartes (Kartezjusz) i John Locke opracowali i przyj li koncepcjdualistycznego uj cia jako ci, wed ug którego jako objawia si w dwu p aszczyznach:jako pierwotna tkwi ca w przedmiocie (np. waga, wymiary) oraz jako wtórnawynikaj ca z postrzegania zmys owego cz owieka (np. kolor, smak).

Warto zwróci uwag na to, e wymienione dotychczas koncepcje jako ci opieraj sina podstawach filozoficznych, do dalekich od obecnego postrzegania jako ci — sil-nie zwi zanego z technologi , rynkiem i aspektami biznesowymi. Ten stan rzeczyuleg zmianie w trakcie rewolucji przemys owej.

Oko o XVIII w., wraz z rozwojem techniki i wprowadzeniem rozwi za maj cych nacelu zwi kszenie produkcji, nast pi a wyra na zmiana postrzegania jako ci. Jakozacz to kojarzy z warto ci . Ocen jako ci pozostawiono w gestii rynku — w nowocze-snym uj ciu to rynek (konsumenci) okre la , co jest dobrej jako ci, a co nie. Warto zwrócite uwag na to, e ocenie podlega g ównie stosunek jako ci do ceny. W odró nieniuod czasów wcze niejszych zainteresowano si cen produktów i ich warto ci postrzeganprzez rynek. Zmieni y si te definicje jako ci.

Na prze omie XIX i XX w. wprowadzono seryjn produkcj i zacz to wykorzystywata my monta owe. Po raz kolejny zmieni o si postrzeganie jako ci — tym razem jakozgodno ze specyfikacj . Dodatkowo pojawi y si aspekty kontroli jako ci. WalterAndrew Shewhart (1891 – 1967), „ojciec” statystycznej kontroli jako ci, postulowa , abydefiniowa jako produktu w taki sposób, by mo na j by o porównywa w ró nychokresach.

Wspó cze nie dominuj ce definicje jako ci okre laj j najcz ciej jako spe nienie lubprzekroczenie wymaga klienta. Nacisk na spe nianie wymaga klienta wynika bez-po rednio ze zwi kszenia produkcji i us ug we wszystkich obszarach ycia cz owieka,co przek ada si na wy szy poziom ycia spo ecze stw i id ce za tym wy sze oczekiwa-nia wzgl dem konsumowanych produktów i us ug. Dodatkowym, bardzo wa nymczynnikiem jest ogromna konkurencja nierzadko wymuszaj ca na przedsi biorcachwalk o klienta.

Mo na si spodziewa , e wspó cze nie przyj te definicje jako ci b d ewoluowaw celu jak najpe niejszego oddania znaczenia jako ci w realiach globalnego spo ecze -stwa konsumpcyjnego.

Poleć książkęKup książkę

Rozdzia 2. Koncepcja jako ci 13

Obecnie stosowane definicje jako ci mo na sklasyfikowa zgodnie z podej ciemDavida A. Garvina (1984). Zaproponowa on podzia definicji jako ci na siedem kategorii:ogólne, zwi zane z produkcj , zwi zane z produktem, zwi zane z u ytkownikiem,zwi zane z tworzeniem warto ci, wielowymiarowe, strategiczne (tabela 2.1).

Tabela 2.1. Klasyfikacja definicji jako ci (Garvin 1984)

Jako — definicje ogólne

1931 W.A. Shewhart Dobro produktu, przy czym dobro ta mo e by zastosowanado wszystkich rodzajów produktów i us ug.

1951 J. Juran Podzia definicji jako ci dlaobszaru projektowania oraz zgodno ci.

1962 J. Juran Spe nienie da (jako rynkowa), jako projektowania, jakozgodno ci, preferencje klientów (przewaga nad konkurencj ),jako charakterystyk (funkcjonalno ), generalna doskona o(niesklasyfikowana gdzie indziej), funkcja lub odpowiedzialnozwi zana z osi gni ciem jako ci produktu, cz organizacjiodpowiedzialna za produkt (wydzia ).

1974 J. Juran Dopasowanie do u ytkowania — w 1988 r. nast pi o rozszerzeniedefinicji o poj cie klienta zewn trznego i wewn trznego.

Jako — definicje zwi zane z produkcj

1979 P. Crosby Zgodno z wymaganiami wewn trznymi i zewn trznymi.

Jako — definicje zwi zane z produktem

R. Shmalensee,J.H. Swan

Wytrzyma o , d ugie ycie produktu; podnoszenie parametrówproduktu jest równoznaczne z jako ci .

1983 J. Feigenbaum Zdolno do wykonywania zada , dzia ania, przydatno .1984 D.A. Garvin W a ciwe wykonanie oraz dodatkowe wyposa enie.1990 G. Taguchi,

D. ClausingJako jest zwi zana z w a ciwym projektowaniem.

Jako — definicje zwi zane z u ytkownikiem

1991 L. Dobyns, C.Crawford-Manson

Spe nienie wymaga klienta.

1951 J. Juran Przydatno dla u ytkowania.1987 J. Feigenbaum Kompozycja charakterystyk, marketingu, produkcji, projektowania

produktu lub us ugi, która w u ytkowaniu zaspokoi potrzeby klienta.

Jako — definicje zwi zane z tworzeniem warto ci

1982 I. Broh Doskona o lub przydatno do u ytku po akceptowalnej cenie.

Jako — definicje wielowymiarowe

1984 D.A. Garvin Jako produktu — wykonanie, dodatkowe wyposa enie,zgodno , wytrzyma o , zdolno do dzia ania, estetyka,postrzegana jako .

Poleć książkęKup książkę

14 Jako projektów informatycznych

Tabela 2.1. Klasyfikacja definicji jako ci (Garvin 1984) — ci g dalszy

Jako — definicje wielowymiarowe (cd.)

1991 A. Parasurman,L.L. Berry, A.Zeithami

Jako w odniesieniu do us ug — wykonanie cz ci materialnej,niezawodno , reakcja na problemy, kompetencje pracowników,empatia.

1993 NagrodaBaldridge’a

Przywództwo, przep yw informacji i analizy, strategiczne planowaniejako ci, rozwój zasobów ludzkich, zarz dzanie procesami, wyniki,orientacja na klienta, satysfakcja klienta i pracowników.

Jako — definicje strategiczne

1980 M. Porter Jedna z dróg do odró nienia produktu od konkurencji — koniecznaw obszarach istotnych dla klienta.

1981 R.D. Buzzell,F.D. Wiersma

Produkt, który przekracza jako ci konkurentów, mo e zwi kszyswój udzia w rynku.

1986 W.E. Deming Produkt wy szej jako ci mo e poprawi postrzeganie firmy przezklientów.

Ciekaw definicj jako ci zaproponowa Leszek Wasilewski (Blikle 2014): „Jakoproduktu to miara braku wad w tym produkcie (im mniej wad, tym wy sza jako ), a wa-d produktu jest ka da taka negatywna cecha produktu — negatywna z punktu widzeniaklienta — której klient ma si prawo nie spodziewa ”. Definicja ta jest o tyle interesuj ca,e wyra nie wskazuje na zwi zek jako ci z istnieniem wad w produkcie, co b dzie

szczególnie istotne w dalszych rozwa aniach na temat jako ci w IT.

Na zako czenie warto przytoczy rozwa ania Garvina, który zdefiniowa jako za pomo-c o miu wymiarów, pokazuj c tym samym z o ono problematyki jako ci i wieloelementów sk adaj cych si na ni (Hiam 1999):

dzia anie, czyli cechy podstawowe produktu lub us ugi;

cechy uzupe niaj ce;

solidno wykonania, niezawodno dzia ania;

zgodno z normami;

trwa o , wyra ana d ugo ci ycia produktu;

atwo i szybko obs ugi;

estetyka, a wi c wygl d, smak czy zapach;

postrzeganie jako ci przez klienta.

Niezale nie od tego, któr z wy ej wspomnianych definicji jako ci obierzemy dla na-szych celów, nale y mie wiadomo , e jako trzeba rozpatrywa z punktu widzeniau ytkownika czy odbiorcy produktu, co oznacza, e nale y zna kontekst i przeznaczeniedanego produktu. W innym przypadku nie ma mo liwo ci oceny jako ci, nie ma temo liwo ci zapewnienia tej e jako ci w produkcie.

Poleć książkęKup książkę

Rozdzia 2. Koncepcja jako ci 15

NormalizacjaJako to nie tylko pewna ocena produktu przez jego odbiorc . To równie sposób komu-nikacji pomi dzy dostawc produktu a klientem, gdzie to klient decyduje o „warto ci”dobra. Zauwa y y to organizacje normalizuj ce, akcentuj c fakt, e stopie spe nieniaoczekiwa klienta stanowi rzeczywist miar oceny skuteczno ci dzia ania przedsi -biorstwa dostawcy dóbr i jego pozycji rynkowej. Organizacje te dostrzeg y równie ,e na jako sk ada si co wi cej ni tylko wyprodukowanie „dobrego” towaru — na

satysfakcj klienta przek ada si te zagwarantowanie dostaw danego produktu naokre lonym, stabilnym poziomie jako ci, po konkurencyjnej cenie i w ustalonych termi-nach. Aby to osi gn , potrzebne s odpowiednie procesy, jako e tylko dobrze zdefi-niowane procesy pozwalaj zapewni powtarzalno produkcji przy jednoczesnejeliminacji podstawowych b dów.

Pocz tków normalizacji w obszarze jako ci nale y szuka w latach 50. ubieg ego wieku.Wtedy to firmy funkcjonuj ce w krajach wolnego rynku zauwa y y konieczno za-pobiegania b dom, nie tylko ich wykrywania. Za „ojca” norm w dziedzinie jako cimo na uzna Stany Zjednoczone, gdzie w 1959 r. wydano norm MIL-Q-9858, opisuj csystem zapewnienia jako ci. Norma ta zosta a ochrzczona mianem Wymagania programujako ci i jako pierwsza definiowa a wymagania stawiane dostawcom oferuj cym sweprodukty armii USA. Kilka lat pó niej, w 1963 r., zaktualizowan norm opubliko-wano jako MIL-Q-9858A i sta a si ona podstaw do opracowania regulacji dotycz cychdostawców dla NATO wydanych w roku 1969 jako AQAP-1.

Interesuj ce w powy szych normach jest to, e na o y y one na dostawców i poddostaw-ców okre lone wymagania jako ciowe, dotycz ce wszystkich etapów powstawaniaproduktu, nie tylko wyniku ko cowego. Od tej pory producenci chc cy dostarczaswoje wyroby armii USA musieli zapewni spe nienie okre lonych wymaga jako cio-wych od fazy przedprodukcyjnej do poprodukcyjnej. Poniewa obowi zek spe nieniawymaga jako ciowych dotyczy te podwykonawców, grono zainteresowanych normamijako ciowymi poszerzy o si na inne obszary przemys u.

W kolejnym dziesi cioleciu (lata 70.) normalizacja obj a przemys maszynowy i energe-tyk j drow . Powsta y te pierwsze normy narodowe, np. BS 5750 w Wielkiej Brytanii,która jest uznawana za pierwszy wiatowy standard zarz dzania systemem jako ci.W 1987 r. standard ten sta si norm ISO 9000, której poszczególne elementy stano-wi podstaw budowania systemów zarz dzania jako ci (SZJ) w wielu organizacjach.Normy te zawieraj terminologie, wymagania i wytyczne dotycz ce wprowadzania,doskonalenia i kontrolowania systemu zarz dzania jako ci .

Pierwsza nowelizacja norm serii ISO 9000 mia a miejsce w roku 1994 i koncentro-wa a si na uj ciu pe nego cyklu ycia wyrobu — od momentu zdefiniowania potrzebklienta po u ytkowanie produktu. Druga nowelizacja, przeprowadzona w roku 2000, jesto tyle interesuj ca, e polega a na dokonaniu gruntownych zmian maj cych na celu przy-bli enie koncepcji SZJ do TQM1 oraz m.in. uwzgl dnienie do wiadcze zebranych

1 Total Quality Management — zarz dzanie przez jako . Koncepcja ta zostanie omówiona w nast pnym

rozdziale.

Poleć książkęKup książkę

16 Jako projektów informatycznych

podczas stosowania wcze niejszych wersji normy i zaakcentowanie znaczenia podej ciaprocesowego oraz zaanga owania najwy szego kierownictwa jako czynników o kluczo-wym znaczeniu dla powodzenia SZJ.

Obecnie podstaw do budowania systemów zarz dzania jako ci s dwie normy:

ISO 9001: 2008 — System zarz dzania jako ci — Wymagania;

ISO 9004: 2009 — Zarz dzanie maj ce na celu osi ganie trwa ego sukcesuorganizacji — Podej cie poprzez zarz dzanie jako ci .

Seria ISO 9000 opiera si na dwóch podstawowych za o eniach, które nale y mie nauwadze jako fundamentalne zasady jakiegokolwiek systemu zarz dzania jako ci :

Lepiej zapobiega ni leczy — przeciwdzia anie wyst powaniu wad i awariijest skuteczniejsze (i w ogólnym rozrachunku ta sze) ni ich wykrywaniei usuwanie. Z pomoc przychodz tu ró ne narz dzia, w ród których prymwiedzie FMEA (ang. Failure Model and Effects Analysis — analiza przyczyni skutków awarii), któr mo na postrzega jako swoiste rozwini cie diagramuIshikawy. Wymogiem normy ISO 9001 jest ci g e doskonalenie, a FMEAdostarcza ku temu rozwi zania.

Jako wymaga systemowego podej cia — organizacja rozumiana jako systemzarz dzania przedsi biorstwem jest obszarem o najwi kszym potencjaleoddzia ywania na poziom jako ci. Innymi s owy: jako zaczyna sina najwy szych szczeblach zarz dzania organizacj .

Warto zwróci uwag na to, e normy ISO serii 9000 nie s normami technicznymi — niedefiniuj parametrów, jakie powinny spe nia wyroby procesu produkcyjnego, jedynieopisuj pewne zasady, których przestrzeganie mo e zapewni odpowiedni jako .Do tematu norm wróc w rozdziale dotycz cym kosztów jako ci.

Znaczenie jako ciw projektach informatycznych

We wspó czesnym wiecie cena zale y od jako ci, a nie od kosztów,które nie interesuj nabywcy— Wac aw Wilczy ski

Wszystkim czytelnikom zapewne doskonale znany jest artobliwy obrazek przedsta-wiaj cy poszczególne etapy projektowe: od pozyskania wymaga , poprzez ich analizi zaprojektowanie docelowego rozwi zania po dostarczenie gotowego produktu do klienta.Etapy te i ich produkty wizualizowane s za pomoc kolejnych projektów tworzonegowyrobu, który w ko cowej fazie znacznie odbiega (niedopowiedzenie stulecia…) odwyobra e i potrzeb klienta. Grafiki te s zabawne i poprawiaj humor, warto jednakpowa niej pochyli si nad znaczeniem, które ze sob nios .

Poleć książkęKup książkę

Rozdzia 2. Koncepcja jako ci 17

Czy rzeczywi cie tak cz sto w wyniku realizacji projektów powstaje co zgo a odmienne-go od oczekiwa klienta? Czy naprawd tak cz sto klient p aci za co , czego niechcia , lub, co gorsza, czego nie potrzebuje do realizacji swoich celów biznesowych,poniewa nie spe nia to takiej funkcji? Odpowied nie napawa optymizmem. Niestety— tak. Z punktu widzenia biznesowego projekty bardzo cz sto — o wiele za cz sto— ko cz si mniejszym lub wi kszym niepowodzeniem. W sytuacjach ekstremalnychw ogóle si nie ko cz , gdy sfrustrowany klient, widz c mizerne efekty prac dostawcy,rezygnuje z kontynuacji prac projektowych. W mniej ekstremalnych i niestety bardzo cz -stych sytuacjach rezygnacja z uko czenia projektu nie jest mo liwa z ró nych powo-dów: od wzgl dów finansowych (zainwestowano przecie wiele rodków w zaplanowaniei realizacj prac projektowych) po formalne (kwestie umów i wymaga formalnych),a z powodu ró nego rodzaju b dów procesowych klient otrzymuje niepe ny czy/i nieod-powiedni do swoich potrzeb produkt. Przyk ady mo na podawa niemal e w niesko -czono : od drobnych usterek powoduj cych rozczarowanie klienta i stwierdzenie:„My la em, e to b dzie inaczej dzia a o/wygl da o” po wady w praktyce uniemo li-wiaj ce wdro enie produktu i jego sprawne u ytkowanie.

Sk d takie problemy? I dlaczego s one tak cz sto (wr cz notorycznie) spotykanew bran y IT?

Powodów jest wiele. Nale y zacz od przyczyny fundamentalnej, powtarzaj cej siw przera aj cym odsetku przedsi wzi : nieprawid owe okre lenie przedmiotu zamówie-nia. Czyli w prostych s owach: zamawiaj cy albo nie wie dok adnie, czego potrzebuje,albo nie jest w stanie tego precyzyjnie okre li . Mo na by rzec — to nie problem! Odtego jest dostawca rozwi zania, by doradzi , podpowiedzie , zasugerowa … Nic bar-dziej mylnego. Nikt, poza klientem, nie jest w stanie okre li tego, czego klient po-trzebuje do realizacji swojej dzia alno ci biznesowej. To klient okre la cele i wyniki reali-zacji projektu, poniewa to klient b dzie korzysta z wytworzonego rozwi zania. To klientmusi zdefiniowa , co chce osi gn za pomoc systemu informatycznego czy innegoproduktu powsta ego w wyniku realizacji prac projektowych. Problem le y w tym, ebardzo cz sto po stronie klienta brakuje etapu przedprojektowego, który to etap powi-nien podda analizie funkcjonowanie organizacji, ustali cele biznesowe i procesy re-alizuj ce te cele, okre li obszary niezb dne do doskonalenia. Dopiero na tej podstawiewy aniaj si cele, które nale y zrealizowa , aby usprawni dzia anie danej organizacji,co w nast pnej kolejno ci powoduje przygotowanie propozycji projektów maj cychdostarczy rodków do realizacji owych celów. Omawiany etap nosi nazw analizyprzedsi biorstwa (IIBA 2005) i niestety w wielu (zbyt wielu!) przypadkach jest zu-pe nie pomijany. Zamiast tego klient rado nie tworzy kilka „wymaga ” dla konkretnegosystemu informatycznego, licz c na to, e ten w a nie system w cudowny sposób uzdrowifunkcjonowanie firmy… To zupe nie jak podawanie losowego leku choremu, u któregonie wykonano adnych bada i diagnostyki, z nadziej e ten w a nie lek zadzia a. Trudnosi dziwi , je li b dzie inaczej, prawda? A jednak w przypadku projektów IT za ka -dym razem klient nie mo e wyj ze zdumienia, e produkt projektu, którego kosztys horrendalne, nie tylko nie pomaga — czasami nawet jest gwo dziem do trumny.

Innym typowym problemem w projektach IT jest brak w a ciwych procesów — nietylko tych bezpo rednio zwi zanych z jako ci , ale i innych, kluczowych dla wytwo-rzenia samego produktu. Zastanówmy si : jakie s realia wielu projektów? Na co naj-cz ciej skar si cz onkowie projektów? Na podstawie obserwacji bran y i rozmówz wieloma osobami, od „szeregowych” pracowników po mened erów, mo na wysnu

Poleć książkęKup książkę

18 Jako projektów informatycznych

nast puj cy wniosek — czas. Brakuje czasu na niemal e wszystko — na kompletne ze-branie wymaga , na ich analiz , na projekt rozwi zania, na implementacj , na testy…Znowu — sk d ten problem? Przecie po to jest planowanie projektu, by ustali reali-styczny czas trwania poszczególnych czynno ci, prawda? Teoretycznie — tak. W prakty-ce bywa ró nie. W praktyce bardzo cz sto trudno jest oszacowa potrzebny nak adpracy na podstawie niezbyt dok adnych wymaga klienta, a poniewa nie ma czasu (sic!)b d mo liwo ci (lub, co gorsza, ch ci) na doprecyzowanie wymaga i ustalenie, czegow a ciwie klient potrzebuje i co dany projekt ma dostarczy , dostawca zwykle wyceniadany projekt, zak adaj c pewne rzeczy. Za o enia te bardzo cz sto dotycz wymagai zakresu rozwi zania — dostawcy wydaje si , e do zrobienia b dzie mniej ni to siokazuje w rzeczywisto ci. Taka metoda szacowania rzadko si sprawdza — miemtwierdzi , e niewiele zespo ów projektowych ma na stanie kompetentn wró k umie-j c przewidywa przysz o i czyta w my lach. Jakie s tego efekty? Ju podczaspierwszych etapów projektowych wychodzi na jaw, e w zak adanych parametrach cza-sowych lub finansowych po prostu nie ma mo liwo ci wykonania pewnych prac. Sku-tek — aby dotrzyma niemo liwych do spe nienia terminów, dostawca „optymalizuje”plany, dokonuj c ci . Zwykle ci cia dotycz analizy wymaga i testów. Implementacjiraczej nie da si skróci , poniewa w jaki sposób nale y dostarczy klientowi produkt(co nie znaczy, e mo na powiedzie , e nie s podejmowane próby „przyspieszenia”deweloperów… O efekty tych prób warto zapyta testerów). Ale wymagania i testy toidealni kandydaci do skrócenia czasu trwania projektu. Pisz to stwierdzenie z przek semi lekk frustracj , poniewa mimo tylu przyk adów pope niania tego b du i jego efektóws ludzie, którzy nadal wierz , e na podstawie wymaga klienta i w asnego wyczucia te-matu mo na wyprodukowa rozwi zanie zgodne z oczekiwaniami odbiorcy. Niezwyklezaskakuj ce jest to, e wiele osób nie widzi potrzeby dok adnej analizy wymaga i opra-cowania starannego projektu rozwi zania, po czym nie mo e wyj ze zdziwienia, eklient nie jest zachwycony przedstawionym wytworem prac projektowych. Czasem nietrzeba czeka a do demonstracji produktu klientowi, poniewa braki zostaj ujawnioneju w testach (oczywi cie zak adaj c, e i testów nie „uci to”), co skutkuje konieczno-ci rozleg ych, pracoch onnych i kosztownych przeróbek. Co dziwne, wielu dostawców

nie widzi problemu w konieczno ci ci g ych poprawek i wielokrotnie powtarzanychtestów maj cych na celu sprawdzenie poprawno ci wprowadzania tych poprawek, zupe niejakby prace te by y wykonywane w ramach wolontariatu i nic nie kosztowa y. A przecieznaczny odsetek b dów wynika z nieprecyzyjnych, sprzecznych czy niejednoznacznychwymaga . Logicznym wnioskiem by oby raczej zwi kszenie nak adu prac zwi zanychz analiz wymaga i projektowaniem rozwi zania w celu unikni cia problemów na pó -niejszych etapach projektu. Nie od dzi wiadomo, e defekty znajdowane pó niej kosz-tuj wi cej (tabela 2.2). Ale nie — z uporem godnym lepszej sprawy wiele organiza-cji IT pope nia ci gle ten sam b d, licz c na uzyskanie innych wyników.

Tabela 2.2. Wzgl dny koszt naprawy defektu w ró nych fazach wytwarzania (McConnell 2004)

Faza wykrycia defektu

Faza wprowadzeniadefektu

Wymagania Architektura Implemen-tacja

Testysystemowe

Wdro enie

Wymagania 1 3 5 – 10 10 10 – 100Architektura – 1 10 15 25 – 100Implementacja – – 1 10 10 – 25

Poleć książkęKup książkę

Rozdzia 2. Koncepcja jako ci 19

Istnieje jeszcze wiele innych czynników przek adaj cych si na zwi kszone ryzykoniepowodzenia projektu IT.

Gartner (2014), organizacja zajmuj ca si m.in. badaniami rynku, przeprowadzi a analizprzyczyn niepowodze projektów. Zapytano respondentów o okre lenie powodów, z któ-rych projekty realizowane w firmach respondentów nie odnios y sukcesu. W odpowie-dziach powtarza o si sze przyczyn:

problemy z funkcjonalno ci ,

opó nienia,

problemy z jako ci ,

przekroczenie bud etu,

zamkni cie projektu po wdro eniu,

projekty odrzucone lub niezaimplementowane z innych przyczyn.

Procentowy udzia powy szych czynników w ogólnej pora ce projektu przedstawiawykres (rysunek 2.1).

Rysunek 2.1.Przyczynyniepowodzeprojektów IT(Gartner 2012)

Warto zauwa y , e wskazane przez firm Gartner przyczyny niepowodze s ogólnymiczynnikami podanymi przez respondentów — nie pokazuj one rzeczywistych ródeproblemów, a jedynie ich skutki, efekty ko cowe zaobserwowane przez uczestnikówbada . Trudno pokusi si o wyeliminowanie czynników ryzyka, nie znaj c realnychprzyczyn problemu — fakt ten potwierdza yby statystyki od lat wskazuj ce niemal do-k adnie takie same czynniki wp ywaj ce na pora ki projektowe. Nic w tym dziwnego

Poleć książkęKup książkę

20 Jako projektów informatycznych

— skoro nie wiadomo, co jest prawdziwym ród em problemu, nie dojdziemy do rozwi -zania eliminuj cego problem. Pope niamy ci gle te same b dy skutkuj ce tymi samymiefektami na przestrzeni lat. A przecie , cytuj c Alberta Einsteina, „szale stwem jestrobi wci to samo i oczekiwa ró nych rezultatów”.

Czy jest szansa na popraw tej sytuacji i wyci gni cie wniosków, które umo liwi ybyzmniejszenie ryzyka pora ki projektu? Oczywi cie. Z pomoc przychodz tu narz dziazarz dzania jako ci , takie jak analiza przyczyn podstawowych czy diagramy Ishikawy,pozwalaj ce na identyfikacj rzeczywistego ród a problemu. Prób zdiagnozowaniasytuacji i syntetycznego podsumowania róde problemów w projektach IT podj to w pu-blikacji Co robimy le i jak tego unikn ? (Zmitrowicz, Chrabski 2014a). Autorzy oparliswoje wnioski na wynikach bada statystycznych prowadzonych przez mi dzynaro-dowe organizacje, w tym Gartner (2012) i Standish Group (1995), wyró niaj c nast -puj ce wyzwania zwi zane z przedsi wzi ciami informatycznymi:

cele i wizja,

niew a ciwe planowanie projektu,

s aba komunikacja,

niew a ciwe zarz dzanie oczekiwaniami interesariuszy,

problemy z wymaganiami i ich zakresem,

brak umiej tno ci mi kkich,

nierealistyczne oczekiwania,

brak zasobów ludzkich,

brak odpowiedniego wsparcia narz dziowego i metodycznego.

Co najmniej kilka z opisywanych we wspomnianej publikacji czynników bezpo rednioprzek ada si na nisk skuteczno procesów wytwórczych, a co za tym idzie, na zwi k-szone ryzyko dostarczenia nieodpowiedniego produktu (lub niedostarczenia produktuw ogóle).

Wszystko to jest bardzo ciekawe, lecz dociekliwy czytelnik zapyta: „Ale co to ma wspól-nego z jako ci ?”. A czym jest jako , je li nie spe nieniem wymaga odbiorcy? Je linie znamy dok adnych wymaga co do zamawianego produktu i stale, procesowo, niemonitorujemy poziomu zgodno ci produktu z tymi wymaganiami, to jak mamy zapewnijako ? Wbrew obiegowym opiniom jako to nie tylko testowanie — wr cz przeciwnie,testy znajduj si na ko cu procesu prowadz cego do osi gni cia wymaganego stanujako ci.

Spójrzmy na temat z innej strony. Jak zapewniana jest jako samochodów czy zegarkówz wysokiej pó ki, ciesz cych si nies abn cym zainteresowaniem i zaufaniem nabywców?W te produkty jako si wbudowywuje od samego pocz tku: od szczegó owych wy-maga , poprzez precyzyjny, zwalidowany projekt a po dok adnie okre lony, powtarzalnyproces produkcji. W tym przypadku o „ci ciu” na etapie projektowania nie ma mowy,gdy producenci znakomicie zdaj sobie spraw z wagi projektu dla jako ci ca ego pro-duktu i z konsekwencji wszelkich zaniedba . „Ale to co innego” — móg by oburzy si

Poleć książkęKup książkę

Rozdzia 2. Koncepcja jako ci 21

czytelnik znaj cy realia projektów IT, w których trudno mówi o produkcji seryjnej czystabilnych wymaganiach. Jednak czy to naprawd a taka ró nica? Budujemy produktna konkretne zamówienie konkretnego klienta. Dostarczane na pocz tku projektu wyma-gania dotycz ce oprogramowania bywaj nieprecyzyjne i mog si w pewnym stopniuzmieni . A wi c tym bardziej, drogi Czytelniku, powiniene dba o jako i ustali takiezapewniaj ce j procesy, by maksymalnie zmniejszy ryzyko dostarczenia produktuniezgodnego z wymaganiami klienta. rodków do tego nie brakuje — dostarczaj ichprocesy zarz dzania jako ci — brakuje najcz ciej wiadomo ci i ch ci.

Koszty jako ciJako jest za darmo— Philip Crosby

Cz st obaw przed wdro eniem systemu zarz dzania jako ci , czy te podj ciem ja-kichkolwiek innych zorganizowanych dzia a zmierzaj cych ku zapewnieniu jako ciproduktów, s koszty. W wielu organizacjach nadal pokutuje przekonanie, e jakokosztuje, a w zwi zku z tym, eby dostarczy produkty o odpowiedniej jako ci, klientmusi odpowiednio zap aci . Czyli do standardowych kosztów produkcji nale a obydoliczy dodatek na zapewnienie jako ci, co znacznie (w rozumieniu producenta) zwi k-szy ca kowity koszt projektu. Poniewa za w dobie olbrzymiej konkurencji klient mo eprzebiera w ród ofert wielu dostawców, przedsi biorcy wychodz z za o enia, e nale yutrzyma atrakcyjn cen oferowanego towaru czy us ugi, aby to ich ofert wybranoi by to w a nie oni realizowali projekt. My lenie w taki sposób powoduje, e jakospada na dalszy (czasem bardzo daleki) plan, a priorytetem staje si koszt i czas reali-zacji przedsi wzi cia.

Dostawcy rozwi za t umacz wysokie koszty zapewnienia jako ci wydatkami ponoszo-nymi na szczegó ow analiz , przygotowanie dok adnej specyfikacji produktu, dalejkontrol jako ci tej specyfikacji, wzmo one testowanie (zwykle na kilku poziomachi w co najmniej kilku cyklach) i wszelkie „dodatkowe” czynno ci, które musz przed-si wzi , aby uzyska po dany przez klienta poziom jako ci. Przedstawiaj szcze-gó owe wyceny, by udowodni , e osi gni cie pewnego poziomu jako ci musi kosztowatyle i tyle. Rzecz jasna wielu klientów przera a sama my l o ponoszeniu dodatkowychkosztów, nie mówi c ju o tym, e co najmniej osobliwe wydaje im si danie za-p aty za jako , czyli oczywist cech zamawianego produktu (nabywaj c np. krzes o,oczekujemy, e b dzie nam s u y o przez krótszy czy d u szy czas, zapewniaj c pe-wien komfort odpoczynku; nikt raczej nie spodziewa si otrzymania produktu, któryoka e si niezdatny do u ytkowania, niewygodny czy nietrwa y). Nale y uwzgl dnifakt, e stosunkowo spory odsetek klientów bran y IT nie zdaje sobie sprawy z tego,e o ile dla nich jako zamawianego produktu jest oczywisto ci , o tyle dla dostawców

parametry jako ciowe to cechy produktu, które podlegaj wycenie, i je li nie zostanuwzgl dnione w szacowaniu kosztów projektu, nie zostan po prostu zaimplementowane.Tym sposobem klient oczekuje taniego, dobrego produktu w ustalonym terminie, dostaw-ca za balansuje na kraw dzi katastrofy, staraj c si zmie ci w ograniczonym bud eciei czasie, by dostarczy klientowi jaki produkt, przy czym jaki jest tu s owem kluczowym.

Poleć książkęKup książkę

22 Jako projektów informatycznych

To przekonanie prowadzi do kuriozalnych sytuacji, w których realizuje si projekty,maj c na uwadze jedynie wymagany zakres funkcjonalny produktu, bud et przewidzianyna realizacj przedsi wzi cia i czas dostawy produktu do klienta. Zapomina si w tymwy cigu o jednej istotnej kwestii — jako ci. Nie jest sztuk oddanie klientowi produktu,który nie spe ni oczekiwa . W takich przypadkach obie strony s przegrane: klient, ponie-wa dosta nie to, czego potrzebowa , i dostawca, bo wytworzy produkt, z którego niskiejjako ci zdaje sobie doskonale spraw , i nie napawa go dum efekt w asnych prac.

Sytuacja, mo na by rzec, patowa. Jak tego typu problemów unikn ? Po pierwsze i chybanajwa niejsze, nale y budowa wiadomo jako ciow . Po obu stronach: zamawiaj cegoi producenta. Je li dla stron jako produktu ma znaczenie, trzeba si liczy z pewnymikonsekwencjami. Konsekwencje te funkcjonuj ju na zasadzie prawd w wiecie IT(nie tylko IT zreszt , jako e dotycz dowolnych us ug), znanych pod nazw prawo dwóchtrzecich:

Szybko i dobrze — nie b dzie tanio.

Tanio i szybko — nie b dzie dobrze.

Tanio i dobrze — nie b dzie szybko.

Prawo dwóch trzecich uros o do rangi artu bran owego, doczeka o si nawet w asnegodemotywatora (rysunek 2.2).

Rysunek 2.2.Prawo dwóchtrzecich(SplaszFX 2011)

Mimo zastosowanego tu lekkiego podej cia do tematu trzeba jednak przyj do wia-domo ci i zaakceptowa fakt, e prawo dwóch trzecich nie jest artem informatyków— w taki sposób naprawd dzia a wszelki biznes. Nie nale y oczekiwa wysokiej jako ci,je li nie chce si zainwestowa odpowiednich nak adów. Niestety, klienci cz sto sami

Poleć książkęKup książkę

Rozdzia 2. Koncepcja jako ci 23

sobie szkodz , wybieraj c najta sz ofert (s ynne kryterium ceny, widoczne swegoczasu zw aszcza w przetargach publicznych) i dziwi c si pó niej, e „to nie jest to, czegochcieli my”. Szkodz te sobie dostawcy, nie wyja niaj c jasno, e nie da si po czy ni-skiej ceny z wysok jako ci . „Chytry dwa razy traci” — mówi polskie przys owie,trafnie podsumowuj c zasady obowi zuj ce w wiecie IT. Niska jako produktu oznacza,e klient otrzyma produkt niespe niaj cy jego oczekiwa . Konsekwencje tego mog

zasadniczo przybra nast puj ce formy:

Klient sk ada reklamacj i da naprawy lub wymiany produktu na taki, któryb dzie zgodny z oczekiwaniami. Dodatkowo klient mo e da pokrycia stratponiesionych w wyniku u ytkowania wadliwego produktu i zap aty karumownych przewidzianych w ramach umowy z producentem.

Klient zra a si do firmy producenta — mo e zaakceptowa poniesionena wadliwy produkt koszty, jednak opinia, jak g osi o produkcie i samymdostawcy, mog aby skutecznie zniech ci aktualnych i przysz ych klientów.W tym przypadku producent teoretycznie nie ponosi bezpo rednich kosztów,jednak w ogólnym rozrachunku koszty biznesowe oraz koszty utraty klientówi mo liwo ci biznesowych s olbrzymie, mog doprowadzi nawetdo upadku firmy.

Opisane wy ej konsekwencje to skutki braku jako ci. Nie musi do nich doj , je li zapla-nujemy i wdro ymy rodki maj ce na celu zapewnienie jako ci, ponosz c przy tymrzecz jasna pewien koszt, jednak z pewno ci ni szy ni koszty braku jako ci.

Tym sposobem dochodzimy do tematu kosztów jako ci. Jakie nak ady trzeba ponie ,by zapewni jako produktów?

Nak ady te znane s w zarz dzaniu jako ci pod nazw koszty jako ci. Dotycz onewszelkich wydatków (czy raczej inwestycji) poniesionych na uzyskanie pewno ci, eprodukty oddawane klientowi wykonane s zgodnie z oczekiwaniami i potrzebami.Wed ug Johna Banka (1996) „Koszt jako ci to niejako skrócony wzór wszystkich kosztówponiesionych przy wytwarzaniu wysokiej jako ci produktu lub us ugi. Sk adaj si nanie koszty profilaktyki, koszty szacowania, koszty wewn trznych b dów, koszty zwi -zane z przekroczeniem wymaga klientów, a tak e koszty wynikaj ce z utraconych ko-rzy ci. W sumie koszty te mog poch on 20 – 30 proc. przychodów lub obrotów firmy”.

Koszty jako ci s wi c sum wszystkich kosztów operacyjnych zwi zanych z osi gni -ciem jako ci. Stanowi one element ogólnych kosztów wytwarzania produktu i jako takiepowinny by uj te w ca kowitym bud ecie realizacji przedsi wzi cia. Ponadto kosztyjako ci umo liwiaj ilo ciow ocen skuteczno ci funkcjonowania systemu zarz dzaniajako ci stosowanego w danym przedsi biorstwie, s zatem pomocnym wska nikiemw optymalizacji procesów.

Koszty jako ci mo na sklasyfikowa na kilka sposobów. Norma ISO 9004: 1994 rekomen-duje podzia kosztów jako ci na koszty zwi zane z operacjami wewn trznymi orazz dzia alno ci zewn trzn przedsi biorstwa (rysunek 2.3). Koszty wewn trzne tokoszty zgodno ci, czyli nak ady na zapobieganie usterkom i ocen jako ci produktu,oraz koszty niezgodno ci, czyli te zwi zane z b dami. Koszty zewn trzne wi si

Poleć książkęKup książkę

24 Jako projektów informatycznych

Rysunek 2.3. Koszty jako ci wed ug ISO 9004: 1994

z reprezentacj i dowodami wymaganymi jako obiektywne wykazanie jako ci. Zalicza sido nich ( a cucki 1994) koszty oceny zgodno ci systemu jako ci przez instytucje certyfi-kacyjne (np. koszty uzyskania certyfikacji ISO 9001) oraz koszty bada i oceny w a-ciwo ci produktu przez niezale ne o rodki badawcze i audytuj ce.

Klasyfikacja ISO nie przewiduje jednak pewnego istotnego czynnika wp ywaj cegona to, e koszty wynikaj ce z braku jako ci s w rzeczywisto ci jeszcze wi ksze, je liuwzgl dnimy koszty niewymierne. Mówi o tym TQM, wyró niaj c nie tylko koszty we-wn trzne i zewn trzne, ale i koszty widoczne i niewidoczne (tabela 2.3).

Tabela 2.3. Klasyfikacja kosztów w TQM (Dahlgaard i in. 2004)

Wyszczególnienie Koszty wewn trzne Koszty zewn trzne cznie

Koszty widoczne 1a. Koszty braków i napraw1b. Koszty zapobiegania i ocen

2. Koszty gwarancjii koszty reklamacji

1 + 2

Koszty niewidoczne 3a. Utrata wydajno ci wskutekniskiej jako ci i niew a ciwegozarz dzania3b. Koszty zapobiegania i ocen

4. Utrata reputacjiwskutek niskiejjako cii niew a ciwegozarz dzania

3 + 4 (?)

cznie 1 + 3 (?) 1 + 2 + 3 + 4 (?)

Widoczne w tabeli znaki zapytania wskazuj , e poza znanymi kosztami, które mo-emy obliczy (1 + 2), istniej jeszcze inne czynniki powoduj ce, e koszt czny po-

zostaje nieznany.

Poleć książkęKup książkę

Skorowidz5 x dlaczego, 80

Aanaliza

kosztów jako ci, 45op acalno ci, 44Pareto, 80post pu i wyników, 210procesów, 45przyczyn niepowodze projektów, 19raportów incydentów, 210warto ci brzegowych, 188

anomalia, 148, 151, 209, 233cykl ycia, 155

APQC, 38artefakt, 156aspekty

jako ci oprogramowania, 94praktyczne, 94

ASQ, American Society for Quality, 79, 95atrakcyjno , Attractiveness, 110atrybuty

awarii, 154defektu, 150, 151funkcjonalno ci, 108niezawodno ci, 109procesu, 256przenaszalno ci, 111wydajno ci, 110

audyt, 45, 102, 133audyt wewn trzny, 48awaria, 149

Bbezpiecze stwo, Security, 109, 112b d, 149

budowaoprogramowania, 93procesu, 36

Ccele

biznesowe, 266jako ci, 53testowania, 183, 266

charakterystyki jako ciowedla procesu, 106dla produktu, 106

ci g e doskonalenie, 50CMMI, 243, 248, 256

obszary procesów, 252standardowa praktyka, 250standardowy cel, 250

CTP, Ctitical Testing Processes, 257, 271–274cykl ycia

anomalii, 155defektu, 158

czynniki wp ywu, 105

Ddefekt, 18, 66, 147–150, 155definicja jako ci, 11, 13Deming William Edwards, 56diagram

Ishikawy, 20, 30, 45, 79przypadków u ycia, 193

dojrza o , Maturity, 109dokumentacja

ISO 9001, 51raportów z testów, 233specyfikacji testów, 226testów, 169, 217, 245

Poleć książkęKup książkę

292 Jako projektów informatycznych

dokumentacjawykonania testów, 232zarz dcza, 220

doskonaleniejako ci, 247procesów organizacyjnych, 248procesu testowego, 256

dzia aniakoryguj ce, 47zapobiegawcze, 47

dzienniki testów, 217

Eelementy

procesu, 62systemu zarz dzania, 89

Ffaza wykrycia defektu, 18filozofia

kaizen, 58lean, 275

FMEA, 16, 79, 226, 247FTR, Formal Technical Review, 97funkcjonalno , Functionality, 108funkcjonowanie kó jako ci, 78

Gg sto b dów, 215grupy procesów, 44

Hharmonogram, 103

IIDEAL, 257, 258identyfikacja

procesów, 36, 37ryzyka, 178

IEEE1008, 2371012, 1621028, 124–129, 162, 2431044, 150, 154, 162, 2431061, 162, 24512207, 82, 1181233, 1611362, 161

2014, 9429148, 161610, 160, 167, 243730, 162828, 102, 160, 243829, 169, 218, 237830, 102, 161

incydenty, 235inspekcja, inspection, 129, 132interoperacyjno , Interoperability, 109Ishikawa Kaoru, 75ISO

19011, 9131000, 1609000, 36, 79, 959001, 16, 51, 909004, 16, 24, 909241, 159

ISO/IEC15504, 25415504-2, 9225000, 159, 2459126, 108, 1119126-1, 107–109

ISO/IEC/IEEE29119, 204, 24029119-3, 245

ISO/TR 10017, 91ISO/TS 16949, 91ISO-19011, 91ISTQB, 164, 204, 275ISTQB/SJSI 2012, 175

Jjako , 11, 80, 93

cele, 53definicje

strategiczne, 14wielowymiarowe, 13, 14zwi zane z produkcj , 13zwi zane z produktem, 13zwi zane z tworzeniem warto ci, 13zwi zane z u ytkownikiem, 13

doskonalenie, 247klasyfikacja kosztów, 24ko o, 75koszty, 21ksi ga, 53metody poprawy, 55normy, 16optymalny poziom, 31osiem zasad, 49

Poleć książkęKup książkę

Skorowidz 293

plan zapewnienia, 99polityka, 52procesy zarz dzania, 41redukcja kosztów, 26rozwa ania Garvina, 14trójk t, 114zarz dzanie kosztami, 32

JIT, just-in-time, 80

Kkaizen, 58kategorie

procesów, 38, 255przyczyn problemu, 30

klasyfikacjaanomalii, 149, 155, 162definicji jako ci, 13kategorii anomalii, 153kosztów, 24krytyczno ci anomalii, 151procesów, 38technik testowych, 185usterek, 215

kodeks post powaniainteres publiczny, 86ja, 87kierownictwo, 86klient i pracodawca, 86os d, 86produkt, 85wspó pracownicy, 86zawód, 86

ko a jako ci, 75, 78koncepcja

jako ci, 11lean, 275zarz dzania jako ci , 63

kontekst testowania, 173kontrola

jako ci, 10, 41, 46, 67, 148testów, 211

kosztyjako ci, 21, 23jako ci organizacji, 25naprawy defektu, 18niewidoczne, 24oceny, 27wadliwo ci, 27wewn trzne, 24widoczne, 24zapobiegania, 27zewn trzne, 24, 27

ksi ga jako ci, 53

L, lista kontrolna, 45, 137, 139LSD, Lean Software Development, 275atwo

adaptacji, Adaptability, 111analizy, Analysability, 110instalacji, Installability, 111konserwacji, Maintainability, 108, 110, 112nauki, Learnability, 110testowania, Testability, 110wprowadzania zmian, Changeability, 110zast pienia, Replaceability, 111zrozumienia, Understandability, 110

Mmacierz

oceny dojrza o ci, 271RACI, 225RASCI, 225ledzenia wymaga , 208

V&V, 103manifest jako ci, 87maszyna stanów, 190metody

in ynierii oprogramowania, 93poprawy jako ci, 55

metryki, 143, 214dla jako ci w u yciu, 107jako ci, 45wewn trzne, 107zewn trzne, 107

miary produktu, 215MMAST, 274model

Boehma, 118CMMI, 250CTP, 274jako ci McCalla, 115, 116jako ci oprogramowania, 109kosztów procesów, 26MMAST, 274PAF, 26PMBOK, 41procesów testowych, 240procesu, 61SPICE, 256strat spo ecznych jako ci, 26TIM, 275TOM, 275TMMi, 264TPI® Next, 269TQM, 60TSM, 274

Poleć książkęKup książkę

294 Jako projektów informatycznych

modeledoskonalenia procesu testowego, 274jako ci, 106jako ci produktu, 107wzrostu niezawodno ci, 215

monitorowanie testów, 211mo liwo wspó istnienia, Co-existence, 111

Nnarz dzia

do zarz dzania testami, 146do zarz dzania wymaganiami, 146kontroli jako ci, 45zarz dzania jako ci , 79

niezale no testowania, 170niezawodno , Reliability, 108, 112normalizacja, 15normy procesowe, 243nota wydania produktu, 218notacja UML, 192

OOAT, Operational Acceptance Testing, 183ocena

kryteriów zako czenia testów, 210porównawcza, 44

odporno na b dy, Fault-tolerance, 109operatywno , Operability, 110opis

procedury testowej, 232przypadków testowych, 230warunków testowych, 227

oprogramowaniebudowa, 93ekonomia in ynierii, 94jako , 93modele, 93piel gnacja, 93projektowanie, 93testowanie, 93, 94wymagania, 93zapewnienie jako ci, 96zarz dzanie in ynieri , 93zarz dzanie konfiguracj , 93

optymalny poziom jako ci, 31organizacja testów, 170orientacja na klienta, 49

PPDCA, 32, 49, 76, 247, 257persony, 202

perspektywy produktu, 114piel gnacja oprogramowania, 93plan

doskonalenia procesów, 45jako ci oprogramowania, 44, 82testów, 132, 207, 217, 245V&V, 121zapewnienia jako ci, 99zarz dzania jako ci , 45

podejmowanie decyzji, 50podej cie

procesowe, 50systemowe do zarz dzania, 50

podstawowy proces testowy, 170, 203podstawy

in ynierii, 94matematyki, 94oblicze , 94

politykajako ci, 52testów, 217, 267

pomiary pokrycia/staranno ci, 216pomy ka, 149posiew usterek, 216poziom dojrza o ci

mierzony, 263optymalizacja, 263organizacji, 93wst pny, 259zarz dzany, 261zdefiniowany, 262

poziomyniezale no ci testowania, 172testów, 179

praktyki in ynierii oprogramowania, 93prawo dwóch trzecich, 22procedury testowe, 217proces, 35

in ynierii oprogramowania, 93, 106oceny dojrza o ci, 269planowania jako ci, 44przegl du formalnego, 135realizacji przegl du, 135testowy, 170, 174, 203, 256, 261zarz dzania jako ci , 41, 45

procesydynamiczne, 205operacyjne, 38organizacyjne, 248pomocnicze, 37wspomagaj ce, 38zarz dcze, 205

profile operacyjne, 202program Bugzilla, 158

Poleć książkęKup książkę

Skorowidz 295

projektowaniei implementacja testów, 207oprogramowania, 93przypadków testowych, 169

przedzia y równowa no ci, 187przegl d, 45, 102, 124

formalny, 135kierowniczy, 127techniczny, 126zarz dzania, 47kole e ski, 103na zako czenie fazy, 103

przejrzenie, 124przenaszalno , Portability, 108, 112przep yw

kontroli dla testów decyzji, 200zada , Workflow, 155

przyczynyniepowodze projektów, 19wyst powania przerw, 29

przypadektestowy, 167, 217u ycia, 140, 193, 194

przywództwo, 49

QQA, Quality Assurance, 95QFD, Quality Function Deployment, 72

RR&D, Research & Development, 72RAM, responsibility assignment matrix, 225raport

anomalii, 217incydentu, 234podsumowuj cy testy, 217, 233

realizacja przegl du, 135redukcja kosztów jako ci, 26reengineering, 57relacje z dostawcami, 50Risk Management, 160rola, 101, 102rozwa ania Garvina, 14rozwój rodowiska testowego, 209ryzyko, 178ryzyko niepowodzenia projektu, 19

S, Six Sigma, 56, 80specyfikacja wymaga , 139

SPICE, 254atrybuty procesu, 256poziomy dojrza o ci, 255

SQA, 101, 102SQM, Software Quality Management, 81SQuaRE, 111, 159stabilno , Stability, 110standardy, 88statystyki usterek, 215strategie testowe, 174–177, 217, 268struktura

dokumentacji testów, 218modelu TMMi, 264procedury testowej, 231przypadku testowego, 228, 229raportu incydentu, 234raportu podsumowuj cego, 234

SWEBOK, 80, 93, 118, 163–166, 179, 216system zarz dzania, 89

jako ci , 48, 62, 79ledzenie wymaga , 208

Ttablica

decyzyjna, 189przej stanów, 192

technikianalityczne, 83dynamiczne, 83kontroli jako ci, 45oparte na

charakterze systemu, 202intuicji i do wiadczeniu, 186kodzie, 195ludziach, 83przep ywie danych, 201przep ywie kontroli, 196specyfikacji, 187usterkach, 201u yciu, 202

statyczne, 83testowe, 184walidacji i weryfikacji, 120techniki zarz dzania jako ci , 79, 83

testalia, 167testowanie, 83, 163

ad hoc, 186decyzji, 198eksploracyjne, 187instalacji, 184instrukcji, 196konfiguracji, 184

Poleć książkęKup książkę

296 Jako projektów informatycznych

testowanieoparte na ryzyku, 177oparte na specyfikacji formalnej, 192oprogramowania, 93u yteczno ci, 184wydajno ci, 184zgodno ci, 184

TestSPICE, 275testy

akceptacyjne, 181, 184alfa, 183beta, 183integracji, 180jednostkowe, 179mutacyjne, 202obci eniowe, 184odtwarzalno ci, 184regresji, 184systemowe, 181

Tickit, 91Tickit plus, 91, 254TMM, 258, 275TMMi, 55, 97, 177, 220, 256–268, 275

struktura modelu, 264zastosowania, 265

TOM, 275Tom Gilb, 87TPI Next, 257, 269–271TPI® Next, 269

kluczowy obszar, 270macierz oceny dojrza o ci, 271

TQC, 56TQM, Total Quality Management, 15, 55–80, 248trójk t jako ci, 114TSM, 274typy

strategii testów, 176testów, 184usterek, 215

U, VUAT, 181UML, 192usterka, 149, 215u ycie listy kontrolnej, 139u yteczno , Usability, 108–111V&V, veryfication and validation, 118, 120, 123

Wwalidacja, 103, 118walidacja wymaga , 103wdra anie TQM, 57

weryfikacja, 103, 118w a ciwo ci

audytu, 134inspekcji, 130, 131przegl du kierowniczego, 128, 129przegl du technicznego, 127przejrzenia, 125, 126

wska nikinspekcji, 132mutacji, 217

wsparcie narz dziowe, 235wydajno , Efficiency, 108, 111wykonywanie

przegl du, 102testów, 209

wykorzystanieczasu, Time Behaviour, 110zasobów, Resource Behaviour, 110

wykresliczby b dów, 147, 148Pareto, 29

wykrycie defektu, 18wyrocznia testowa, 169

Zzaanga owanie ludzi, 49zadania SQA, 101, 102zamkni cie testów, 213zapewnianie jako ci, 45, 96, 99zarz dzanie

anomaliami, 155incydentami, 209in ynieri oprogramowania, 93jako ci oprogramowania, 35, 40, 80–82, 94konfiguracj oprogramowania, 84, 93kosztami jako ci, 32procesowe, 35projektem, 84przez jako , 56, 58ryzykiem, 84testami, 146wydaniem, 84

zasadyDeminga, 63–75jako ci, 49LSD, 276

zastosowanie przegl du, 120zdolno do odtworzenia, Recoverability, 109zgadywanie b dów, 201znaczenie jako ci, 16

Poleć książkęKup książkę