Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00311 008159 15930303 na godz. na dobę w sumie
Jakość projektów informatycznych. Rozwój i testowanie oprogramowania - ebook/pdf
Jakość projektów informatycznych. Rozwój i testowanie oprogramowania - ebook/pdf
Autor: Liczba stron: 296
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-2120-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook (-40%), audiobook).

Zarządzaj jakością projektu od narodzin po końcowe testy!

Zapewnianie wysokiej jakości oprogramowania to niełatwe zadanie. Osiągniesz ją, jeśli będziesz przestrzegać wysokich standardów procesu wytwarzania i dopilnujesz, by każdy problem został rozwiązany do końca. Jednak zadziwiająco wielu producentów nie traktuje poważnie sygnałów o błędach. Ujawniają się one dopiero podczas testowania, czyli na etapie, gdy już niewiele można zrobić. Ta książka podpowie Ci, jak już na pierwszych etapach tworzenia kodu wykrywać i rozwiązywać pojawiające się problemy. Popraw efektywność swojej pracy już dziś!

Karolina Zmitrowicz zebrała najistotniejsze koncepcje z dziedziny zarządzania jakością oprogramowania i uzupełniła je o własne doświadczenia. Znajdziesz tu omówienie podstaw testowania oraz pomoc w organizacji i planowaniu pracy. Nauczysz się tworzyć jakość, a nie tylko ją sprawdzać. Poznasz przydatne metody weryfikacji i walidacji, podstawy tworzenia dokumentacji wyników i narzędzia Lean Software Development. Dzięki zawartym w książce wskazówkom udoskonalisz swoje produkty, zoptymalizujesz proces ich wytwarzania i powiększysz grono zachwyconych klientów.

Dbaj o jakość — pamiętaj, że stać Cię na więcej!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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/Olsztyn Obarek, Pokoński, Pazdrijowski, Zaprucki Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: 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/zapeja Moż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(cid:264)ci Przedmowa ...................................................................................... 7 Rozdzia(cid:228) 1. Wprowadzenie .................................................................................. 9 Rozdzia(cid:228) 2. Koncepcja jako(cid:264)ci .......................................................................... 11 Definicja jako(cid:286)ci ............................................................................................................. 11 Normalizacja .................................................................................................................. 15 Znaczenie jako(cid:286)ci w projektach informatycznych .......................................................... 16 Koszty jako(cid:286)ci ................................................................................................................ 21 Rozdzia(cid:228) 3. Zarz(cid:241)dzanie jako(cid:264)ci(cid:241) ...................................................................... 35 Zarz(cid:261)dzanie procesowe ................................................................................................... 35 Zarz(cid:261)dzanie jako(cid:286)ci(cid:261) ....................................................................................................... 40 Zarz(cid:261)dzanie przez jako(cid:286)(cid:252) ................................................................................................ 56 Koncepcje zarz(cid:261)dzania jako(cid:286)ci(cid:261) ..................................................................................... 63 Zasady Deminga ......................................................................................................... 63 Ko(cid:225)a jako(cid:286)ci ................................................................................................................ 75 Inne koncepcje, narz(cid:266)dzia i techniki zarz(cid:261)dzania jako(cid:286)ci(cid:261) ......................................... 79 Zarz(cid:261)dzanie jako(cid:286)ci(cid:261) oprogramowania ........................................................................... 80 Jako(cid:286)(cid:252) oprogramowania ............................................................................................. 80 Kodeks post(cid:266)powania ................................................................................................. 85 Manifest jako(cid:286)ci ............................................................................................................. 87 Standardy ........................................................................................................................ 88 ISO 9000 Quality Management .................................................................................. 89 ISO 19011: 2011 — Guidelines for auditing management systems ........................... 91 ISO/TS 16949: 2009 — Quality management systems — Particular requirements for the application of ISO 9001: 2008 for automotive production and relevant service part organizations .................................................................... 91 TickIT i TickIT plus ................................................................................................... 91 ISO Technical Report 19759 (SWEBOK®) ................................................................ 93 Rozdzia(cid:228) 4. Zapewnienie jako(cid:264)ci ...................................................................... 95 Wprowadzenie ................................................................................................................ 95 Planowanie procesu zapewnienia jako(cid:286)ci ....................................................................... 99 Plan zapewnienia jako(cid:286)ci ........................................................................................... 99 Czynniki wp(cid:225)ywu ..................................................................................................... 105 Charakterystyki jako(cid:286)ciowe dla procesu i produktu ................................................. 106 Poleć książkęKup książkę 4 Jako(cid:264)(cid:232) projektów informatycznych Weryfikacja i walidacja ................................................................................................ 118 Przegl(cid:261)dy .................................................................................................................. 124 Listy kontrolne ......................................................................................................... 137 Metryki ......................................................................................................................... 143 Anomalie — charakterystyka i sposób obs(cid:225)ugi ............................................................. 148 Standardy ...................................................................................................................... 159 ISO/IEC 25000: 2005 — Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE ............................ 159 ISO 9241 — Ergonomics of Human System Interaction .......................................... 159 ISO 31000: 2009 — Risk Management — Principles and guidelines ...................... 160 IEEE 610.12: 1990 — Standard Glossary of Software Engineering Terminology ... 160 IEEE 828: 2012 — Standard for Configuration Management in Systems and Software Engineering ...................................................................................... 160 IEEE 830: 1998 — Recommended Practice for Software Requirements Specifications ......................................................................................................... 161 IEEE 1233: 1996 — Guide for Developing of System Requirements Specifications ......................................................................................................... 161 IEEE 1362: 1998 — Guide for Information Technology — System Definition — Concept of Operations (ConOps) Document .................................................... 161 IEEE 29148: 2011 — Systems and software engineering — Life cycle processes — Requirements engineering ................................................................ 161 IEEE 730: 2002 — Standard for Software Quality Assurance Plans ....................... 162 IEEE 1012: 1986 — Standard for Software Verification and Validation Plans ....... 162 IEEE 1028: 2008 — Standard for Software Reviews and Audits ............................ 162 IEEE 1044: 2009 — Standard Classification for Software Anomalies .................... 162 IEEE 1061: 1998 — Standard for a Software Quality Metrics Methodology .......... 162 Rozdzia(cid:228) 5. Testowanie .................................................................................. 163 Podstawy testowania .................................................................................................... 167 Organizacja testów ....................................................................................................... 170 Niezale(cid:298)no(cid:286)(cid:252) testowania .......................................................................................... 170 Kontekst testowania ................................................................................................. 173 Strategia testów ........................................................................................................ 174 Poziomy testów ........................................................................................................ 179 Cele testowania ........................................................................................................ 183 Techniki testowe ........................................................................................................... 184 Techniki oparte na intuicji i do(cid:286)wiadczeniu ............................................................. 186 Techniki oparte na specyfikacji ................................................................................ 187 Techniki oparte na kodzie ........................................................................................ 195 Techniki oparte na usterkach .................................................................................... 201 Techniki oparte na u(cid:298)yciu ........................................................................................ 202 Techniki oparte na charakterze systemu ................................................................... 202 Proces testowy .............................................................................................................. 203 Podstawowy proces testowy ..................................................................................... 203 Metryki zwi(cid:261)zane z testowaniem .................................................................................. 214 Ocena produktu poddawanego testom ...................................................................... 215 Ocena wykonywanych testów .................................................................................. 216 Dokumentacja testów ................................................................................................... 217 Dokumentacja zarz(cid:261)dcza .......................................................................................... 220 Dokumentacja specyfikacji testów ........................................................................... 226 Dokumentacja wykonania testów ............................................................................. 232 Dokumentacja raportów z testów ............................................................................. 233 Poleć książkęKup książkę Spis tre(cid:264)ci 5 Wsparcie narz(cid:266)dziowe .................................................................................................. 236 Standardy w testowaniu ................................................................................................ 237 BS 7925-1: 1998 — Software testing — Vocabulary .............................................. 237 BS 7925-2: 1998 — Software testing — Software component testing .................... 237 IEEE 1008: 1987 — Standard for Software Unit Testing ........................................ 237 IEEE 829: 1998 — Standard for Test Documentation ............................................. 237 ISO/IEC/IEEE 29119 — Software Testing .............................................................. 238 Normy procesowe .................................................................................................... 244 Inne standardy .......................................................................................................... 244 Rozdzia(cid:228) 6. Doskonalenie jako(cid:264)ci ................................................................... 247 Doskonalenie procesów organizacyjnych ..................................................................... 248 CMMI® .................................................................................................................... 248 TickITplus ................................................................................................................ 254 ISO/IEC 15504 — Software Process Improvement and Capability Determination (SPICE) .......................................................................................... 254 Doskonalenie procesu testowego .................................................................................. 256 IDEAL ...................................................................................................................... 257 TMMi® ..................................................................................................................... 258 TPI® Next ................................................................................................................. 269 CTP .......................................................................................................................... 271 Inne modele doskonalenia procesu testowego .......................................................... 274 Lean Software Development (LSD) ............................................................................. 275 Zasady LSD .............................................................................................................. 276 Rozdzia(cid:228) 7. Podsumowanie ............................................................................. 281 Literatura ..................................................................................... 283 Skorowidz .................................................................................... 291 Poleć książkęKup książkę 6 Jako(cid:264)(cid:232) projektów informatycznych Poleć książkęKup książkę Rozdzia(cid:228) 2. Koncepcja jako(cid:264)ci Jako(cid:286)(cid:252) to pewien stopie(cid:276) doskona(cid:225)o(cid:286)ci — Platon Definicja jako(cid:264)ci Tematu zapewnienia jako(cid:286)ci oraz testowania nie sposób rozpocz(cid:261)(cid:252) bez wprowadzenia poj(cid:266)cia jako(cid:286)ci. Termin ten przewija si(cid:266) w niemal(cid:298)e wszystkich znanych cz(cid:225)owiekowi obszarach — mówimy o jako(cid:286)ci us(cid:225)ug, produktów, procesów, ale i o jako(cid:286)ci samego (cid:298)ycia. Mo(cid:298)na powiedzie(cid:252), (cid:298)e w ostatnich czasach zapanowa(cid:225)a swoista moda na jako(cid:286)(cid:252), poniewa(cid:298) wraz z rozwojem technologicznym, gospodarczym i spo(cid:225)ecznym konsumenci oczekuj(cid:261) lepszego spe(cid:225)niania ich oczekiwa(cid:276) i zaspokajania potrzeb. Klienci wymagaj(cid:261) wysokiej jako(cid:286)ci, producenci i us(cid:225)ugodawcy d(cid:261)(cid:298)(cid:261) do spe(cid:225)nienia oczekiwa(cid:276) (lub przy- najmniej sprawiania takiego wra(cid:298)enia) przez dostarczanie dóbr o nowej czy innowacyj- nej jako(cid:286)ci. Jako(cid:286)(cid:252) jest poj(cid:266)ciem modnym. Czym jednak jest i jak j(cid:261) zdefiniowa(cid:252)? Z definicj(cid:261) jako(cid:286)ci wi(cid:261)(cid:298)(cid:261) si(cid:266) pewne mity. Wielu ludzi stoi na stanowisku, (cid:298)e jako(cid:286)(cid:252) jest poj(cid:266)ciem wysoce zale(cid:298)nym od percepcji poszczególnych jednostek, co przek(cid:225)ada si(cid:266) na niemierzalno(cid:286)(cid:252) i nieokre(cid:286)lono(cid:286)(cid:252). Wed(cid:225)ug do(cid:286)(cid:252) popularnego twierdzenia, poniewa(cid:298) definicja jako(cid:286)ci zale(cid:298)y od postrzegania danej osoby (co akurat jest prawd(cid:261)), nie mo(cid:298)e by(cid:252) jednoznacznie okre(cid:286)lona, a co za tym idzie — zmierzona. Jest to niew(cid:261)tpliwie ciekawe podej(cid:286)cie do tematu, jednak niezbyt zgodne ze stanem faktycznym. Koncepcja jako(cid:286)ci znana jest ju(cid:298) od czasów staro(cid:298)ytnych. Po raz pierwszy poj(cid:266)cie znane dzi(cid:286) jako jako(cid:286)(cid:252) zosta(cid:225)o wprowadzone w Kodeksie Hammurabiego z 1750 r. p.n.e. W ko- deksie tym istnia(cid:225) przepis, który nakazywa(cid:225) kara(cid:252) (cid:286)mierci(cid:261) murarza, je(cid:286)li zbudowany przez niego dom nie by(cid:225) odpowiedniej jako(cid:286)ci — niska jako(cid:286)(cid:252) w tym kontek(cid:286)cie oznacza(cid:225)a dom, który zawala si(cid:266) i zabija mieszka(cid:276)ców. W kolejnych wiekach poj(cid:266)cie jako(cid:286)ci by(cid:225)o rozwijane w Grecji, kolebce filozofii i nauk przyrodniczych. Poleć książkęKup książkę 12 Jako(cid:264)(cid:232) projektów informatycznych Pierwsz(cid:261) pisan(cid:261) definicj(cid:266) jako(cid:286)ci wprowadzi(cid:225) grecki filozof Platon (427 – 347 p.n.e.), okre(cid:286)laj(cid:261)c j(cid:261) jako „pewien stopie(cid:276) doskona(cid:225)o(cid:286)ci”. W tym uj(cid:266)ciu jako(cid:286)(cid:252) by(cid:225)a poj(cid:266)ciem filozoficznym, silnie zwi(cid:261)zanym z koncepcj(cid:261) pi(cid:266)kna i warto(cid:286)ciowania danego przed- miotu przez u(cid:298)ytkownika (Kili(cid:276)ski 1979). Nieco inne podej(cid:286)cie reprezentowa(cid:225) Arystoteles (384 – 322 p.n.e.), definiuj(cid:261)c jako(cid:286)(cid:252) jako „to, co sprawia, (cid:298)e rzecz jest rzecz(cid:261), któr(cid:261) jest” (Skrzypek 2000). Definicja Ary- stotelesa jest o tyle istotna, (cid:298)e k(cid:225)adzie nacisk na powi(cid:261)zanie jako(cid:286)ci z przedmiotem, którego ta jako(cid:286)(cid:252) dotyczy. Mo(cid:298)na tu znale(cid:296)(cid:252) (cid:296)ród(cid:225)a nowoczesnych definicji okre(cid:286)laj(cid:261)cych jako(cid:286)(cid:252) jako zgodno(cid:286)(cid:252) wyrobu z okre(cid:286)lonymi charakterystykami. Filozoficzne postrzeganie jako(cid:286)ci kontynuowano i rozszerzano w bli(cid:298)szych nam czasach. W XVII w. René Descartes (Kartezjusz) i John Locke opracowali i przyj(cid:266)li koncepcj(cid:266) dualistycznego uj(cid:266)cia jako(cid:286)ci, wed(cid:225)ug którego jako(cid:286)(cid:252) objawia si(cid:266) w dwu p(cid:225)aszczyznach: jako(cid:286)(cid:252) pierwotna tkwi(cid:261)ca w przedmiocie (np. waga, wymiary) oraz jako(cid:286)(cid:252) wtórna wynikaj(cid:261)ca z postrzegania zmys(cid:225)owego cz(cid:225)owieka (np. kolor, smak). Warto zwróci(cid:252) uwag(cid:266) na to, (cid:298)e wymienione dotychczas koncepcje jako(cid:286)ci opieraj(cid:261) si(cid:266) na podstawach filozoficznych, do(cid:286)(cid:252) dalekich od obecnego postrzegania jako(cid:286)ci — sil- nie zwi(cid:261)zanego z technologi(cid:261), rynkiem i aspektami biznesowymi. Ten stan rzeczy uleg(cid:225) zmianie w trakcie rewolucji przemys(cid:225)owej. Oko(cid:225)o XVIII w., wraz z rozwojem techniki i wprowadzeniem rozwi(cid:261)za(cid:276) maj(cid:261)cych na celu zwi(cid:266)kszenie produkcji, nast(cid:261)pi(cid:225)a wyra(cid:296)na zmiana postrzegania jako(cid:286)ci. Jako(cid:286)(cid:252) zacz(cid:266)to kojarzy(cid:252) z warto(cid:286)ci(cid:261). Ocen(cid:266) jako(cid:286)ci pozostawiono w gestii rynku — w nowocze- snym uj(cid:266)ciu to rynek (konsumenci) okre(cid:286)la(cid:225), co jest dobrej jako(cid:286)ci, a co nie. Warto zwróci(cid:252) te(cid:298) uwag(cid:266) na to, (cid:298)e ocenie podlega(cid:225) g(cid:225)ównie stosunek jako(cid:286)ci do ceny. W odró(cid:298)nieniu od czasów wcze(cid:286)niejszych zainteresowano si(cid:266) cen(cid:261) produktów i ich warto(cid:286)ci(cid:261) postrzegan(cid:261) przez rynek. Zmieni(cid:225)y si(cid:266) te(cid:298) definicje jako(cid:286)ci. Na prze(cid:225)omie XIX i XX w. wprowadzono seryjn(cid:261) produkcj(cid:266) i zacz(cid:266)to wykorzystywa(cid:252) ta(cid:286)my monta(cid:298)owe. Po raz kolejny zmieni(cid:225)o si(cid:266) postrzeganie jako(cid:286)ci — tym razem jako zgodno(cid:286)(cid:252) ze specyfikacj(cid:261). Dodatkowo pojawi(cid:225)y si(cid:266) aspekty kontroli jako(cid:286)ci. Walter Andrew Shewhart (1891 – 1967), „ojciec” statystycznej kontroli jako(cid:286)ci, postulowa(cid:225), aby definiowa(cid:252) jako(cid:286)(cid:252) produktu w taki sposób, by mo(cid:298)na j(cid:261) by(cid:225)o porównywa(cid:252) w ró(cid:298)nych okresach. Wspó(cid:225)cze(cid:286)nie dominuj(cid:261)ce definicje jako(cid:286)ci okre(cid:286)laj(cid:261) j(cid:261) najcz(cid:266)(cid:286)ciej jako spe(cid:225)nienie lub przekroczenie wymaga(cid:276) klienta. Nacisk na spe(cid:225)nianie wymaga(cid:276) klienta wynika bez- po(cid:286)rednio ze zwi(cid:266)kszenia produkcji i us(cid:225)ug we wszystkich obszarach (cid:298)ycia cz(cid:225)owieka, co przek(cid:225)ada si(cid:266) na wy(cid:298)szy poziom (cid:298)ycia spo(cid:225)ecze(cid:276)stw i id(cid:261)ce za tym wy(cid:298)sze oczekiwa- nia wzgl(cid:266)dem konsumowanych produktów i us(cid:225)ug. Dodatkowym, bardzo wa(cid:298)nym czynnikiem jest ogromna konkurencja nierzadko wymuszaj(cid:261)ca na przedsi(cid:266)biorcach walk(cid:266) o klienta. Mo(cid:298)na si(cid:266) spodziewa(cid:252), (cid:298)e wspó(cid:225)cze(cid:286)nie przyj(cid:266)te definicje jako(cid:286)ci b(cid:266)d(cid:261) ewoluowa(cid:252) w celu jak najpe(cid:225)niejszego oddania znaczenia jako(cid:286)ci w realiach globalnego spo(cid:225)ecze(cid:276)- stwa konsumpcyjnego. Poleć książkęKup książkę Rozdzia(cid:228) 2. (cid:105) Koncepcja jako(cid:264)ci 13 Obecnie stosowane definicje jako(cid:286)ci mo(cid:298)na sklasyfikowa(cid:252) zgodnie z podej(cid:286)ciem Davida A. Garvina (1984). Zaproponowa(cid:225) on podzia(cid:225) definicji jako(cid:286)ci na siedem kategorii: ogólne, zwi(cid:261)zane z produkcj(cid:261), zwi(cid:261)zane z produktem, zwi(cid:261)zane z u(cid:298)ytkownikiem, zwi(cid:261)zane z tworzeniem warto(cid:286)ci, wielowymiarowe, strategiczne (tabela 2.1). Tabela 2.1. Klasyfikacja definicji jako(cid:286)ci (Garvin 1984) Jako(cid:264)(cid:232) — definicje ogólne 1931 W.A. Shewhart 1951 1962 J. Juran J. Juran 1974 J. Juran Dobro(cid:252) produktu, przy czym dobro(cid:252) ta mo(cid:298)e by(cid:252) zastosowana do wszystkich rodzajów produktów i us(cid:225)ug. Podzia(cid:225) definicji jako(cid:286)ci dla obszaru projektowania oraz zgodno(cid:286)ci. Spe(cid:225)nienie (cid:298)(cid:261)da(cid:276) (jako(cid:286)(cid:252) rynkowa), jako(cid:286)(cid:252) projektowania, jako(cid:286)(cid:252) zgodno(cid:286)ci, preferencje klientów (przewaga nad konkurencj(cid:261)), jako(cid:286)(cid:252) charakterystyk (funkcjonalno(cid:286)(cid:252)), generalna doskona(cid:225)o(cid:286)(cid:252) (niesklasyfikowana gdzie indziej), funkcja lub odpowiedzialno(cid:286)(cid:252) zwi(cid:261)zana z osi(cid:261)gni(cid:266)ciem jako(cid:286)ci produktu, cz(cid:266)(cid:286)(cid:252) organizacji odpowiedzialna za produkt (wydzia(cid:225)). Dopasowanie do u(cid:298)ytkowania — w 1988 r. nast(cid:261)pi(cid:225)o rozszerzenie definicji o poj(cid:266)cie klienta zewn(cid:266)trznego i wewn(cid:266)trznego. Jako(cid:264)(cid:232) — definicje zwi(cid:241)zane z produkcj(cid:241) 1979 P. Crosby Zgodno(cid:286)(cid:252) z wymaganiami wewn(cid:266)trznymi i zewn(cid:266)trznymi. Jako(cid:264)(cid:232) — definicje zwi(cid:241)zane z produktem R. Shmalensee, J.H. Swan J. Feigenbaum D.A. Garvin G. Taguchi, D. Clausing 1983 1984 1990 Wytrzyma(cid:225)o(cid:286)(cid:252), d(cid:225)ugie (cid:298)ycie produktu; podnoszenie parametrów produktu jest równoznaczne z jako(cid:286)ci(cid:261). Zdolno(cid:286)(cid:252) do wykonywania zada(cid:276), dzia(cid:225)ania, przydatno(cid:286)(cid:252). W(cid:225)a(cid:286)ciwe wykonanie oraz dodatkowe wyposa(cid:298)enie. Jako(cid:286)(cid:252) jest zwi(cid:261)zana z w(cid:225)a(cid:286)ciwym projektowaniem. Jako(cid:264)(cid:232) — definicje zwi(cid:241)zane z u(cid:276)ytkownikiem 1991 Spe(cid:225)nienie wymaga(cid:276) klienta. L. Dobyns, C. Crawford- Manson J. Juran J. Feigenbaum 1951 1987 Przydatno(cid:286)(cid:252) dla u(cid:298)ytkowania. Kompozycja charakterystyk, marketingu, produkcji, projektowania produktu lub us(cid:225)ugi, która w u(cid:298)ytkowaniu zaspokoi potrzeby klienta. Jako(cid:264)(cid:232) — definicje zwi(cid:241)zane z tworzeniem warto(cid:264)ci 1982 I. Broh Doskona(cid:225)o(cid:286)(cid:252) lub przydatno(cid:286)(cid:252) do u(cid:298)ytku po akceptowalnej cenie. Jako(cid:264)(cid:232) — definicje wielowymiarowe 1984 D.A. Garvin Jako(cid:286)(cid:252) produktu — wykonanie, dodatkowe wyposa(cid:298)enie, zgodno(cid:286)(cid:252), wytrzyma(cid:225)o(cid:286)(cid:252), zdolno(cid:286)(cid:252) do dzia(cid:225)ania, estetyka, postrzegana jako(cid:286)(cid:252). Poleć książkęKup książkę 14 Jako(cid:264)(cid:232) projektów informatycznych Tabela 2.1. Klasyfikacja definicji jako(cid:286)ci (Garvin 1984) — ci(cid:261)g dalszy Jako(cid:264)(cid:232) — definicje wielowymiarowe (cd.) 1991 A. Parasurman, L.L. Berry, A. Zeithami Nagroda Baldridge’a Jako(cid:286)(cid:252) w odniesieniu do us(cid:225)ug — wykonanie cz(cid:266)(cid:286)ci materialnej, niezawodno(cid:286)(cid:252), reakcja na problemy, kompetencje pracowników, empatia. Przywództwo, przep(cid:225)yw informacji i analizy, strategiczne planowanie jako(cid:286)ci, rozwój zasobów ludzkich, zarz(cid:261)dzanie procesami, wyniki, orientacja na klienta, satysfakcja klienta i pracowników. 1993 Jako(cid:264)(cid:232) — definicje strategiczne 1980 M. Porter 1981 1986 R.D. Buzzell, F.D. Wiersma W.E. Deming Jedna z dróg do odró(cid:298)nienia produktu od konkurencji — konieczna w obszarach istotnych dla klienta. Produkt, który przekracza jako(cid:286)ci(cid:261) konkurentów, mo(cid:298)e zwi(cid:266)kszy(cid:252) swój udzia(cid:225) w rynku. Produkt wy(cid:298)szej jako(cid:286)ci mo(cid:298)e poprawi(cid:252) postrzeganie firmy przez klientów. Ciekaw(cid:261) definicj(cid:266) jako(cid:286)ci zaproponowa(cid:225) Leszek Wasilewski (Blikle 2014): „Jako(cid:286)(cid:252) produktu to miara braku wad w tym produkcie (im mniej wad, tym wy(cid:298)sza jako(cid:286)(cid:252)), a wa- d(cid:261) produktu jest ka(cid:298)da taka negatywna cecha produktu — negatywna z punktu widzenia klienta — której klient ma si(cid:266) prawo nie spodziewa(cid:252)”. Definicja ta jest o tyle interesuj(cid:261)ca, (cid:298)e wyra(cid:296)nie wskazuje na zwi(cid:261)zek jako(cid:286)ci z istnieniem wad w produkcie, co b(cid:266)dzie szczególnie istotne w dalszych rozwa(cid:298)aniach na temat jako(cid:286)ci w IT. Na zako(cid:276)czenie warto przytoczy(cid:252) rozwa(cid:298)ania Garvina, który zdefiniowa(cid:225) jako(cid:286)(cid:252) za pomo- c(cid:261) o(cid:286)miu wymiarów, pokazuj(cid:261)c tym samym z(cid:225)o(cid:298)ono(cid:286)(cid:252) problematyki jako(cid:286)ci i wielo(cid:286)(cid:252) elementów sk(cid:225)adaj(cid:261)cych si(cid:266) na ni(cid:261) (Hiam 1999): (cid:141) dzia(cid:225)anie, czyli cechy podstawowe produktu lub us(cid:225)ugi; (cid:141) cechy uzupe(cid:225)niaj(cid:261)ce; (cid:141) solidno(cid:286)(cid:252) wykonania, niezawodno(cid:286)(cid:252) dzia(cid:225)ania; (cid:141) zgodno(cid:286)(cid:252) z normami; (cid:141) trwa(cid:225)o(cid:286)(cid:252), wyra(cid:298)ana d(cid:225)ugo(cid:286)ci(cid:261) (cid:298)ycia produktu; (cid:141) (cid:225)atwo(cid:286)(cid:252) i szybko(cid:286)(cid:252) obs(cid:225)ugi; (cid:141) estetyka, a wi(cid:266)c wygl(cid:261)d, smak czy zapach; (cid:141) postrzeganie jako(cid:286)ci przez klienta. Niezale(cid:298)nie od tego, któr(cid:261) z wy(cid:298)ej wspomnianych definicji jako(cid:286)ci obierzemy dla na- szych celów, nale(cid:298)y mie(cid:252) (cid:286)wiadomo(cid:286)(cid:252), (cid:298)e jako(cid:286)(cid:252) trzeba rozpatrywa(cid:252) z punktu widzenia u(cid:298)ytkownika czy odbiorcy produktu, co oznacza, (cid:298)e nale(cid:298)y zna(cid:252) kontekst i przeznaczenie danego produktu. W innym przypadku nie ma mo(cid:298)liwo(cid:286)ci oceny jako(cid:286)ci, nie ma te(cid:298) mo(cid:298)liwo(cid:286)ci zapewnienia tej(cid:298)e jako(cid:286)ci w produkcie. Poleć książkęKup książkę Rozdzia(cid:228) 2. (cid:105) Koncepcja jako(cid:264)ci Normalizacja 15 Jako(cid:286)(cid:252) to nie tylko pewna ocena produktu przez jego odbiorc(cid:266). To równie(cid:298) sposób komu- nikacji pomi(cid:266)dzy dostawc(cid:261) produktu a klientem, gdzie to klient decyduje o „warto(cid:286)ci” dobra. Zauwa(cid:298)y(cid:225)y to organizacje normalizuj(cid:261)ce, akcentuj(cid:261)c fakt, (cid:298)e stopie(cid:276) spe(cid:225)nienia oczekiwa(cid:276) klienta stanowi rzeczywist(cid:261) miar(cid:266) oceny skuteczno(cid:286)ci dzia(cid:225)ania przedsi(cid:266)- biorstwa dostawcy dóbr i jego pozycji rynkowej. Organizacje te dostrzeg(cid:225)y równie(cid:298), (cid:298)e na jako(cid:286)(cid:252) sk(cid:225)ada si(cid:266) co(cid:286) wi(cid:266)cej ni(cid:298) tylko wyprodukowanie „dobrego” towaru — na satysfakcj(cid:266) klienta przek(cid:225)ada si(cid:266) te(cid:298) zagwarantowanie dostaw danego produktu na okre(cid:286)lonym, stabilnym poziomie jako(cid:286)ci, po konkurencyjnej cenie i w ustalonych termi- nach. Aby to osi(cid:261)gn(cid:261)(cid:252), potrzebne s(cid:261) odpowiednie procesy, jako (cid:298)e tylko dobrze zdefi- niowane procesy pozwalaj(cid:261) zapewni(cid:252) powtarzalno(cid:286)(cid:252) produkcji przy jednoczesnej eliminacji podstawowych b(cid:225)(cid:266)dów. Pocz(cid:261)tków normalizacji w obszarze jako(cid:286)ci nale(cid:298)y szuka(cid:252) w latach 50. ubieg(cid:225)ego wieku. Wtedy to firmy funkcjonuj(cid:261)ce w krajach wolnego rynku zauwa(cid:298)y(cid:225)y konieczno(cid:286)(cid:252) za- pobiegania b(cid:225)(cid:266)dom, nie tylko ich wykrywania. Za „ojca” norm w dziedzinie jako(cid:286)ci mo(cid:298)na uzna(cid:252) Stany Zjednoczone, gdzie w 1959 r. wydano norm(cid:266) MIL-Q-9858, opisuj(cid:261)c(cid:261) system zapewnienia jako(cid:286)ci. Norma ta zosta(cid:225)a ochrzczona mianem Wymagania programu jako(cid:286)ci i jako pierwsza definiowa(cid:225)a wymagania stawiane dostawcom oferuj(cid:261)cym swe produkty armii USA. Kilka lat pó(cid:296)niej, w 1963 r., zaktualizowan(cid:261) norm(cid:266) opubliko- wano jako MIL-Q-9858A i sta(cid:225)a si(cid:266) ona podstaw(cid:261) do opracowania regulacji dotycz(cid:261)cych dostawców dla NATO wydanych w roku 1969 jako AQAP-1. Interesuj(cid:261)ce w powy(cid:298)szych normach jest to, (cid:298)e na(cid:225)o(cid:298)y(cid:225)y one na dostawców i poddostaw- ców okre(cid:286)lone wymagania jako(cid:286)ciowe, dotycz(cid:261)ce wszystkich etapów powstawania produktu, nie tylko wyniku ko(cid:276)cowego. Od tej pory producenci chc(cid:261)cy dostarcza(cid:252) swoje wyroby armii USA musieli zapewni(cid:252) spe(cid:225)nienie okre(cid:286)lonych wymaga(cid:276) jako(cid:286)cio- wych od fazy przedprodukcyjnej do poprodukcyjnej. Poniewa(cid:298) obowi(cid:261)zek spe(cid:225)nienia wymaga(cid:276) jako(cid:286)ciowych dotyczy(cid:225) te(cid:298) podwykonawców, grono zainteresowanych normami jako(cid:286)ciowymi poszerzy(cid:225)o si(cid:266) na inne obszary przemys(cid:225)u. W kolejnym dziesi(cid:266)cioleciu (lata 70.) normalizacja obj(cid:266)(cid:225)a przemys(cid:225) maszynowy i energe- tyk(cid:266) j(cid:261)drow(cid:261). Powsta(cid:225)y te(cid:298) pierwsze normy narodowe, np. BS 5750 w Wielkiej Brytanii, która jest uznawana za pierwszy (cid:286)wiatowy standard zarz(cid:261)dzania systemem jako(cid:286)ci. W 1987 r. standard ten sta(cid:225) si(cid:266) norm(cid:261) ISO 9000, której poszczególne elementy stano- wi(cid:261) podstaw(cid:266) budowania systemów zarz(cid:261)dzania jako(cid:286)ci(cid:261) (SZJ) w wielu organizacjach. Normy te zawieraj(cid:261) terminologie, wymagania i wytyczne dotycz(cid:261)ce wprowadzania, doskonalenia i kontrolowania systemu zarz(cid:261)dzania jako(cid:286)ci(cid:261). Pierwsza nowelizacja norm serii ISO 9000 mia(cid:225)a miejsce w roku 1994 i koncentro- wa(cid:225)a si(cid:266) na uj(cid:266)ciu pe(cid:225)nego cyklu (cid:298)ycia wyrobu — od momentu zdefiniowania potrzeb klienta po u(cid:298)ytkowanie produktu. Druga nowelizacja, przeprowadzona w roku 2000, jest o tyle interesuj(cid:261)ca, (cid:298)e polega(cid:225)a na dokonaniu gruntownych zmian maj(cid:261)cych na celu przy- bli(cid:298)enie koncepcji SZJ do TQM1 oraz m.in. uwzgl(cid:266)dnienie do(cid:286)wiadcze(cid:276) zebranych 1 Total Quality Management — zarz(cid:261)dzanie przez jako(cid:286)(cid:252). Koncepcja ta zostanie omówiona w nast(cid:266)pnym rozdziale. Poleć książkęKup książkę 16 Jako(cid:264)(cid:232) projektów informatycznych podczas stosowania wcze(cid:286)niejszych wersji normy i zaakcentowanie znaczenia podej(cid:286)cia procesowego oraz zaanga(cid:298)owania najwy(cid:298)szego kierownictwa jako czynników o kluczo- wym znaczeniu dla powodzenia SZJ. Obecnie podstaw(cid:261) do budowania systemów zarz(cid:261)dzania jako(cid:286)ci(cid:261) s(cid:261) dwie normy: (cid:141) ISO 9001: 2008 — System zarz(cid:261)dzania jako(cid:286)ci(cid:261) — Wymagania; (cid:141) ISO 9004: 2009 — Zarz(cid:261)dzanie maj(cid:261)ce na celu osi(cid:261)ganie trwa(cid:225)ego sukcesu organizacji — Podej(cid:286)cie poprzez zarz(cid:261)dzanie jako(cid:286)ci(cid:261). Seria ISO 9000 opiera si(cid:266) na dwóch podstawowych za(cid:225)o(cid:298)eniach, które nale(cid:298)y mie(cid:252) na uwadze jako fundamentalne zasady jakiegokolwiek systemu zarz(cid:261)dzania jako(cid:286)ci(cid:261): (cid:141) Lepiej zapobiega(cid:252) ni(cid:298) leczy(cid:252) — przeciwdzia(cid:225)anie wyst(cid:266)powaniu wad i awarii jest skuteczniejsze (i w ogólnym rozrachunku ta(cid:276)sze) ni(cid:298) ich wykrywanie i usuwanie. Z pomoc(cid:261) przychodz(cid:261) tu ró(cid:298)ne narz(cid:266)dzia, w(cid:286)ród których prym wiedzie FMEA (ang. Failure Model and Effects Analysis — analiza przyczyn i skutków awarii), któr(cid:261) mo(cid:298)na postrzega(cid:252) jako swoiste rozwini(cid:266)cie diagramu Ishikawy. Wymogiem normy ISO 9001 jest ci(cid:261)g(cid:225)e doskonalenie, a FMEA dostarcza ku temu rozwi(cid:261)zania. (cid:141) Jako(cid:286)(cid:252) wymaga systemowego podej(cid:286)cia — organizacja rozumiana jako system zarz(cid:261)dzania przedsi(cid:266)biorstwem jest obszarem o najwi(cid:266)kszym potencjale oddzia(cid:225)ywania na poziom jako(cid:286)ci. Innymi s(cid:225)owy: jako(cid:286)(cid:252) zaczyna si(cid:266) na najwy(cid:298)szych szczeblach zarz(cid:261)dzania organizacj(cid:261). Warto zwróci(cid:252) uwag(cid:266) na to, (cid:298)e normy ISO serii 9000 nie s(cid:261) normami technicznymi — nie definiuj(cid:261) parametrów, jakie powinny spe(cid:225)nia(cid:252) wyroby procesu produkcyjnego, jedynie opisuj(cid:261) pewne zasady, których przestrzeganie mo(cid:298)e zapewni(cid:252) odpowiedni(cid:261) jako(cid:286)(cid:252). Do tematu norm wróc(cid:266) w rozdziale dotycz(cid:261)cym kosztów jako(cid:286)ci. Znaczenie jako(cid:264)ci w projektach informatycznych We wspó(cid:225)czesnym (cid:286)wiecie cena zale(cid:298)y od jako(cid:286)ci, a nie od kosztów, które nie interesuj(cid:261) nabywcy — Wac(cid:225)aw Wilczy(cid:276)ski Wszystkim czytelnikom zapewne doskonale znany jest (cid:298)artobliwy obrazek przedsta- wiaj(cid:261)cy poszczególne etapy projektowe: od pozyskania wymaga(cid:276), poprzez ich analiz(cid:266) i zaprojektowanie docelowego rozwi(cid:261)zania po dostarczenie gotowego produktu do klienta. Etapy te i ich produkty wizualizowane s(cid:261) za pomoc(cid:261) kolejnych projektów tworzonego wyrobu, który w ko(cid:276)cowej fazie znacznie odbiega (niedopowiedzenie stulecia…) od wyobra(cid:298)e(cid:276) i potrzeb klienta. Grafiki te s(cid:261) zabawne i poprawiaj(cid:261) humor, warto jednak powa(cid:298)niej pochyli(cid:252) si(cid:266) nad znaczeniem, które ze sob(cid:261) nios(cid:261). Poleć książkęKup książkę Rozdzia(cid:228) 2. (cid:105) Koncepcja jako(cid:264)ci 17 Czy rzeczywi(cid:286)cie tak cz(cid:266)sto w wyniku realizacji projektów powstaje co(cid:286) zgo(cid:225)a odmienne- go od oczekiwa(cid:276) klienta? Czy naprawd(cid:266) tak cz(cid:266)sto klient p(cid:225)aci za co(cid:286), czego nie chcia(cid:225), lub, co gorsza, czego nie potrzebuje do realizacji swoich celów biznesowych, poniewa(cid:298) nie spe(cid:225)nia to takiej funkcji? Odpowied(cid:296) nie napawa optymizmem. Niestety — tak. Z punktu widzenia biznesowego projekty bardzo cz(cid:266)sto — o wiele za cz(cid:266)sto — ko(cid:276)cz(cid:261) si(cid:266) mniejszym lub wi(cid:266)kszym niepowodzeniem. W sytuacjach ekstremalnych w ogóle si(cid:266) nie ko(cid:276)cz(cid:261), gdy(cid:298) sfrustrowany klient, widz(cid:261)c mizerne efekty prac dostawcy, rezygnuje z kontynuacji prac projektowych. W mniej ekstremalnych i niestety bardzo cz(cid:266)- stych sytuacjach rezygnacja z uko(cid:276)czenia projektu nie jest mo(cid:298)liwa z ró(cid:298)nych powo- dów: od wzgl(cid:266)dów finansowych (zainwestowano przecie(cid:298) wiele (cid:286)rodków w zaplanowanie i realizacj(cid:266) prac projektowych) po formalne (kwestie umów i wymaga(cid:276) formalnych), a z powodu ró(cid:298)nego rodzaju b(cid:225)(cid:266)dów procesowych klient otrzymuje niepe(cid:225)ny czy/i nieod- powiedni do swoich potrzeb produkt. Przyk(cid:225)ady mo(cid:298)na podawa(cid:252) niemal(cid:298)e w niesko(cid:276)- czono(cid:286)(cid:252): od drobnych usterek powoduj(cid:261)cych rozczarowanie klienta i stwierdzenie: „My(cid:286)la(cid:225)em, (cid:298)e to b(cid:266)dzie inaczej dzia(cid:225)a(cid:225)o/wygl(cid:261)da(cid:225)o” po wady w praktyce uniemo(cid:298)li- wiaj(cid:261)ce wdro(cid:298)enie produktu i jego sprawne u(cid:298)ytkowanie. Sk(cid:261)d takie problemy? I dlaczego s(cid:261) one tak cz(cid:266)sto (wr(cid:266)cz notorycznie) spotykane w bran(cid:298)y IT? Powodów jest wiele. Nale(cid:298)y zacz(cid:261)(cid:252) od przyczyny fundamentalnej, powtarzaj(cid:261)cej si(cid:266) w przera(cid:298)aj(cid:261)cym odsetku przedsi(cid:266)wzi(cid:266)(cid:252): nieprawid(cid:225)owe okre(cid:286)lenie przedmiotu zamówie- nia. Czyli w prostych s(cid:225)owach: zamawiaj(cid:261)cy albo nie wie dok(cid:225)adnie, czego potrzebuje, albo nie jest w stanie tego precyzyjnie okre(cid:286)li(cid:252). Mo(cid:298)na by rzec — to nie problem! Od tego jest dostawca rozwi(cid:261)zania, by doradzi(cid:252), podpowiedzie(cid:252), zasugerowa(cid:252)… Nic bar- dziej mylnego. Nikt, poza klientem, nie jest w stanie okre(cid:286)li(cid:252) tego, czego klient po- trzebuje do realizacji swojej dzia(cid:225)alno(cid:286)ci biznesowej. To klient okre(cid:286)la cele i wyniki reali- zacji projektu, poniewa(cid:298) to klient b(cid:266)dzie korzysta(cid:225) z wytworzonego rozwi(cid:261)zania. To klient musi zdefiniowa(cid:252), co chce osi(cid:261)gn(cid:261)(cid:252) za pomoc(cid:261) systemu informatycznego czy innego produktu powsta(cid:225)ego w wyniku realizacji prac projektowych. Problem le(cid:298)y w tym, (cid:298)e bardzo cz(cid:266)sto po stronie klienta brakuje etapu przedprojektowego, który to etap powi- nien podda(cid:252) analizie funkcjonowanie organizacji, ustali(cid:252) cele biznesowe i procesy re- alizuj(cid:261)ce te cele, okre(cid:286)li(cid:252) obszary niezb(cid:266)dne do doskonalenia. Dopiero na tej podstawie wy(cid:225)aniaj(cid:261) si(cid:266) cele, które nale(cid:298)y zrealizowa(cid:252), aby usprawni(cid:252) dzia(cid:225)anie danej organizacji, co w nast(cid:266)pnej kolejno(cid:286)ci powoduje przygotowanie propozycji projektów maj(cid:261)cych dostarczy(cid:252) (cid:286)rodków do realizacji owych celów. Omawiany etap nosi nazw(cid:266) analizy przedsi(cid:266)biorstwa (IIBA 2005) i niestety w wielu (zbyt wielu!) przypadkach jest zu- pe(cid:225)nie pomijany. Zamiast tego klient rado(cid:286)nie tworzy kilka „wymaga(cid:276)” dla konkretnego systemu informatycznego, licz(cid:261)c na to, (cid:298)e ten w(cid:225)a(cid:286)nie system w cudowny sposób uzdrowi funkcjonowanie firmy… To zupe(cid:225)nie jak podawanie losowego leku choremu, u którego nie wykonano (cid:298)adnych bada(cid:276) i diagnostyki, z nadziej(cid:261) (cid:298)e ten w(cid:225)a(cid:286)nie lek zadzia(cid:225)a. Trudno si(cid:266) dziwi(cid:252), je(cid:286)li b(cid:266)dzie inaczej, prawda? A jednak w przypadku projektów IT za ka(cid:298)- dym razem klient nie mo(cid:298)e wyj(cid:286)(cid:252) ze zdumienia, (cid:298)e produkt projektu, którego koszty s(cid:261) horrendalne, nie tylko nie pomaga — czasami nawet jest gwo(cid:296)dziem do trumny. Innym typowym problemem w projektach IT jest brak w(cid:225)a(cid:286)ciwych procesów — nie tylko tych bezpo(cid:286)rednio zwi(cid:261)zanych z jako(cid:286)ci(cid:261), ale i innych, kluczowych dla wytwo- rzenia samego produktu. Zastanówmy si(cid:266): jakie s(cid:261) realia wielu projektów? Na co naj- cz(cid:266)(cid:286)ciej skar(cid:298)(cid:261) si(cid:266) cz(cid:225)onkowie projektów? Na podstawie obserwacji bran(cid:298)y i rozmów z wieloma osobami, od „szeregowych” pracowników po mened(cid:298)erów, mo(cid:298)na wysnu(cid:252) Poleć książkęKup książkę 18 Jako(cid:264)(cid:232) projektów informatycznych nast(cid:266)puj(cid:261)cy wniosek — czas. Brakuje czasu na niemal(cid:298)e wszystko — na kompletne ze- branie wymaga(cid:276), na ich analiz(cid:266), na projekt rozwi(cid:261)zania, na implementacj(cid:266), na testy… Znowu — sk(cid:261)d ten problem? Przecie(cid:298) po to jest planowanie projektu, by ustali(cid:252) reali- styczny czas trwania poszczególnych czynno(cid:286)ci, prawda? Teoretycznie — tak. W prakty- ce bywa ró(cid:298)nie. W praktyce bardzo cz(cid:266)sto trudno jest oszacowa(cid:252) potrzebny nak(cid:225)ad pracy na podstawie niezbyt dok(cid:225)adnych wymaga(cid:276) klienta, a poniewa(cid:298) nie ma czasu (sic!) b(cid:261)d(cid:296) mo(cid:298)liwo(cid:286)ci (lub, co gorsza, ch(cid:266)ci) na doprecyzowanie wymaga(cid:276) i ustalenie, czego w(cid:225)a(cid:286)ciwie klient potrzebuje i co dany projekt ma dostarczy(cid:252), dostawca zwykle wycenia dany projekt, zak(cid:225)adaj(cid:261)c pewne rzeczy. Za(cid:225)o(cid:298)enia te bardzo cz(cid:266)sto dotycz(cid:261) wymaga(cid:276) i zakresu rozwi(cid:261)zania — dostawcy wydaje si(cid:266), (cid:298)e do zrobienia b(cid:266)dzie mniej ni(cid:298) to si(cid:266) okazuje w rzeczywisto(cid:286)ci. Taka metoda szacowania rzadko si(cid:266) sprawdza — (cid:286)miem twierdzi(cid:252), (cid:298)e niewiele zespo(cid:225)ów projektowych ma na stanie kompetentn(cid:261) wró(cid:298)k(cid:266) umie- j(cid:261)c(cid:261) przewidywa(cid:252) przysz(cid:225)o(cid:286)(cid:252) i czyta(cid:252) w my(cid:286)lach. Jakie s(cid:261) tego efekty? Ju(cid:298) podczas pierwszych etapów projektowych wychodzi na jaw, (cid:298)e w zak(cid:225)adanych parametrach cza- sowych lub finansowych po prostu nie ma mo(cid:298)liwo(cid:286)ci wykonania pewnych prac. Sku- tek — aby dotrzyma(cid:252) niemo(cid:298)liwych do spe(cid:225)nienia terminów, dostawca „optymalizuje” plany, dokonuj(cid:261)c ci(cid:266)(cid:252). Zwykle ci(cid:266)cia dotycz(cid:261) analizy wymaga(cid:276) i testów. Implementacji raczej nie da si(cid:266) skróci(cid:252), poniewa(cid:298) w jaki(cid:286) sposób nale(cid:298)y dostarczy(cid:252) klientowi produkt (co nie znaczy, (cid:298)e mo(cid:298)na powiedzie(cid:252), (cid:298)e nie s(cid:261) podejmowane próby „przyspieszenia” deweloperów… O efekty tych prób warto zapyta(cid:252) testerów). Ale wymagania i testy to idealni kandydaci do skrócenia czasu trwania projektu. Pisz(cid:266) to stwierdzenie z przek(cid:261)sem i lekk(cid:261) frustracj(cid:261), poniewa(cid:298) mimo tylu przyk(cid:225)adów pope(cid:225)niania tego b(cid:225)(cid:266)du i jego efektów s(cid:261) ludzie, którzy nadal wierz(cid:261), (cid:298)e na podstawie wymaga(cid:276) klienta i w(cid:225)asnego wyczucia te- matu mo(cid:298)na wyprodukowa(cid:252) rozwi(cid:261)zanie zgodne z oczekiwaniami odbiorcy. Niezwykle zaskakuj(cid:261)ce jest to, (cid:298)e wiele osób nie widzi potrzeby dok(cid:225)adnej analizy wymaga(cid:276) i opra- cowania starannego projektu rozwi(cid:261)zania, po czym nie mo(cid:298)e wyj(cid:286)(cid:252) ze zdziwienia, (cid:298)e klient nie jest zachwycony przedstawionym wytworem prac projektowych. Czasem nie trzeba czeka(cid:252) a(cid:298) do demonstracji produktu klientowi, poniewa(cid:298) braki zostaj(cid:261) ujawnione ju(cid:298) w testach (oczywi(cid:286)cie zak(cid:225)adaj(cid:261)c, (cid:298)e i testów nie „uci(cid:266)to”), co skutkuje konieczno- (cid:286)ci(cid:261) rozleg(cid:225)ych, pracoch(cid:225)onnych i kosztownych przeróbek. Co dziwne, wielu dostawców nie widzi problemu w konieczno(cid:286)ci ci(cid:261)g(cid:225)ych poprawek i wielokrotnie powtarzanych testów maj(cid:261)cych na celu sprawdzenie poprawno(cid:286)ci wprowadzania tych poprawek, zupe(cid:225)nie jakby prace te by(cid:225)y wykonywane w ramach wolontariatu i nic nie kosztowa(cid:225)y. A przecie(cid:298) znaczny odsetek b(cid:225)(cid:266)dów wynika z nieprecyzyjnych, sprzecznych czy niejednoznacznych wymaga(cid:276). Logicznym wnioskiem by(cid:225)oby raczej zwi(cid:266)kszenie nak(cid:225)adu prac zwi(cid:261)zanych z analiz(cid:261) wymaga(cid:276) i projektowaniem rozwi(cid:261)zania w celu unikni(cid:266)cia problemów na pó(cid:296)- niejszych etapach projektu. Nie od dzi(cid:286) wiadomo, (cid:298)e defekty znajdowane pó(cid:296)niej kosz- tuj(cid:261) wi(cid:266)cej (tabela 2.2). Ale nie — z uporem godnym lepszej sprawy wiele organiza- cji IT pope(cid:225)nia ci(cid:261)gle ten sam b(cid:225)(cid:261)d, licz(cid:261)c na uzyskanie innych wyników. Tabela 2.2. Wzgl(cid:266)dny koszt naprawy defektu w ró(cid:298)nych fazach wytwarzania (McConnell 2004) Faza wprowadzenia defektu Wymagania Architektura Implementacja Faza wykrycia defektu Wymagania Architektura 1 – – 3 1 – Implemen- tacja 5 – 10 10 1 Testy systemowe 10 15 10 Wdro(cid:298)enie 10 – 100 25 – 100 10 – 25 Poleć książkęKup książkę Rozdzia(cid:228) 2. (cid:105) Koncepcja jako(cid:264)ci 19 Istnieje jeszcze wiele innych czynników przek(cid:225)adaj(cid:261)cych si(cid:266) na zwi(cid:266)kszone ryzyko niepowodzenia projektu IT. Gartner (2014), organizacja zajmuj(cid:261)ca si(cid:266) m.in. badaniami rynku, przeprowadzi(cid:225)a analiz(cid:266) przyczyn niepowodze(cid:276) projektów. Zapytano respondentów o okre(cid:286)lenie powodów, z któ- rych projekty realizowane w firmach respondentów nie odnios(cid:225)y sukcesu. W odpowie- dziach powtarza(cid:225)o si(cid:266) sze(cid:286)(cid:252) przyczyn: (cid:141) problemy z funkcjonalno(cid:286)ci(cid:261), (cid:141) opó(cid:296)nienia, (cid:141) problemy z jako(cid:286)ci(cid:261), (cid:141) przekroczenie bud(cid:298)etu, (cid:141) zamkni(cid:266)cie projektu po wdro(cid:298)eniu, (cid:141) projekty odrzucone lub niezaimplementowane z innych przyczyn. Procentowy udzia(cid:225) powy(cid:298)szych czynników w ogólnej pora(cid:298)ce projektu przedstawia wykres (rysunek 2.1). Rysunek 2.1. Przyczyny niepowodze(cid:276) projektów IT (Gartner 2012) Warto zauwa(cid:298)y(cid:252), (cid:298)e wskazane przez firm(cid:266) Gartner przyczyny niepowodze(cid:276) s(cid:261) ogólnymi czynnikami podanymi przez respondentów — nie pokazuj(cid:261) one rzeczywistych (cid:296)róde(cid:225) problemów, a jedynie ich skutki, efekty ko(cid:276)cowe zaobserwowane przez uczestników bada(cid:276). Trudno pokusi(cid:252) si(cid:266) o wyeliminowanie czynników ryzyka, nie znaj(cid:261)c realnych przyczyn problemu — fakt ten potwierdza(cid:225)yby statystyki od lat wskazuj(cid:261)ce niemal do- k(cid:225)adnie takie same czynniki wp(cid:225)ywaj(cid:261)ce na pora(cid:298)ki projektowe. Nic w tym dziwnego Poleć książkęKup książkę 20 Jako(cid:264)(cid:232) projektów informatycznych — skoro nie wiadomo, co jest prawdziwym (cid:296)ród(cid:225)em problemu, nie dojdziemy do rozwi(cid:261)- zania eliminuj(cid:261)cego problem. Pope(cid:225)niamy ci(cid:261)gle te same b(cid:225)(cid:266)dy skutkuj(cid:261)ce tymi samymi efektami na przestrzeni lat. A przecie(cid:298), cytuj(cid:261)c Alberta Einsteina, „szale(cid:276)stwem jest robi(cid:252) wci(cid:261)(cid:298) to samo i oczekiwa(cid:252) ró(cid:298)nych rezultatów”. Czy jest szansa na popraw(cid:266) tej sytuacji i wyci(cid:261)gni(cid:266)cie wniosków, które umo(cid:298)liwi(cid:225)yby zmniejszenie ryzyka pora(cid:298)ki projektu? Oczywi(cid:286)cie. Z pomoc(cid:261) przychodz(cid:261) tu narz(cid:266)dzia zarz(cid:261)dzania jako(cid:286)ci(cid:261), takie jak analiza przyczyn podstawowych czy diagramy Ishikawy, pozwalaj(cid:261)ce na identyfikacj(cid:266) rzeczywistego (cid:296)ród(cid:225)a problemu. Prób(cid:266) zdiagnozowania sytuacji i syntetycznego podsumowania (cid:296)róde(cid:225) problemów w projektach IT podj(cid:266)to w pu- blikacji Co robimy (cid:296)le i jak tego unikn(cid:261)(cid:252)? (Zmitrowicz, Chrabski 2014a). Autorzy oparli swoje wnioski na wynikach bada(cid:276) statystycznych prowadzonych przez mi(cid:266)dzynaro- dowe organizacje, w tym Gartner (2012) i Standish Group (1995), wyró(cid:298)niaj(cid:261)c nast(cid:266)- puj(cid:261)ce wyzwania zwi(cid:261)zane z przedsi(cid:266)wzi(cid:266)ciami informatycznymi: (cid:141) cele i wizja, (cid:141) niew(cid:225)a(cid:286)ciwe planowanie projektu, (cid:141) s(cid:225)aba komunikacja, (cid:141) niew(cid:225)a(cid:286)ciwe zarz(cid:261)dzanie oczekiwaniami interesariuszy, (cid:141) problemy z wymaganiami i ich zakresem, (cid:141) brak umiej(cid:266)tno(cid:286)ci mi(cid:266)kkich, (cid:141) nierealistyczne oczekiwania, (cid:141) brak zasobów ludzkich, (cid:141) brak odpowiedniego wsparcia narz(cid:266)dziowego i metodycznego. Co najmniej kilka z opisywanych we wspomnianej publikacji czynników bezpo(cid:286)rednio przek(cid:225)ada si(cid:266) na nisk(cid:261) skuteczno(cid:286)(cid:252) procesów wytwórczych, a co za tym idzie, na zwi(cid:266)k- szone ryzyko dostarczenia nieodpowiedniego produktu (lub niedostarczenia produktu w ogóle). Wszystko to jest bardzo ciekawe, lecz dociekliwy czytelnik zapyta: „Ale co to ma wspól- nego z jako(cid:286)ci(cid:261)?”. A czym jest jako(cid:286)(cid:252), je(cid:286)li nie spe(cid:225)nieniem wymaga(cid:276) odbiorcy? Je(cid:286)li nie znamy dok(cid:225)adnych wymaga(cid:276) co do zamawianego produktu i stale, procesowo, nie monitorujemy poziomu zgodno(cid:286)ci produktu z tymi wymaganiami, to jak mamy zapewni(cid:252) jako(cid:286)(cid:252)? Wbrew obiegowym opiniom jako(cid:286)(cid:252) to nie tylko testowanie — wr(cid:266)cz przeciwnie, testy znajduj(cid:261) si(cid:266) na ko(cid:276)cu procesu prowadz(cid:261)cego do osi(cid:261)gni(cid:266)cia wymaganego stanu jako(cid:286)ci. Spójrzmy na temat z innej strony. Jak zapewniana jest jako(cid:286)(cid:252) samochodów czy zegarków z wysokiej pó(cid:225)ki, ciesz(cid:261)cych si(cid:266) nies(cid:225)abn(cid:261)cym zainteresowaniem i zaufaniem nabywców? W te produkty jako(cid:286)(cid:252) si(cid:266) wbudowywuje od samego pocz(cid:261)tku: od szczegó(cid:225)owych wy- maga(cid:276), poprzez precyzyjny, zwalidowany projekt a(cid:298) po dok(cid:225)adnie okre(cid:286)lony, powtarzalny proces produkcji. W tym przypadku o „ci(cid:266)ciu” na etapie projektowania nie ma mowy, gdy(cid:298) producenci znakomicie zdaj(cid:261) sobie spraw(cid:266) z wagi projektu dla jako(cid:286)ci ca(cid:225)ego pro- duktu i z konsekwencji wszelkich zaniedba(cid:276). „Ale to co innego” — móg(cid:225)by oburzy(cid:252) si(cid:266) Poleć książkęKup książkę Rozdzia(cid:228) 2. (cid:105) Koncepcja jako(cid:264)ci 21 czytelnik znaj(cid:261)cy realia projektów IT, w których trudno mówi(cid:252) o produkcji seryjnej czy stabilnych wymaganiach. Jednak czy to naprawd(cid:266) a(cid:298) taka ró(cid:298)nica? Budujemy produkt na konkretne zamówienie konkretnego klienta. Dostarczane na pocz(cid:261)tku projektu wyma- gania dotycz(cid:261)ce oprogramowania bywaj(cid:261) nieprecyzyjne i mog(cid:261) si(cid:266) w pewnym stopniu zmieni(cid:252). A wi(cid:266)c tym bardziej, drogi Czytelniku, powiniene(cid:286) dba(cid:252) o jako(cid:286)(cid:252) i ustali(cid:252) takie zapewniaj(cid:261)ce j(cid:261) procesy, by maksymalnie zmniejszy(cid:252) ryzyko dostarczenia produktu niezgodnego z wymaganiami klienta. (cid:285)rodków do tego nie brakuje — dostarczaj(cid:261) ich procesy zarz(cid:261)dzania jako(cid:286)ci(cid:261) — brakuje najcz(cid:266)(cid:286)ciej (cid:286)wiadomo(cid:286)ci i ch(cid:266)ci. Koszty jako(cid:264)ci Jako(cid:286)(cid:252) jest za darmo — Philip Crosby Cz(cid:266)st(cid:261) obaw(cid:261) przed wdro(cid:298)eniem systemu zarz(cid:261)dzania jako(cid:286)ci(cid:261), czy te(cid:298) podj(cid:266)ciem ja- kichkolwiek innych zorganizowanych dzia(cid:225)a(cid:276) zmierzaj(cid:261)cych ku zapewnieniu jako(cid:286)ci produktów, s(cid:261) koszty. W wielu organizacjach nadal pokutuje przekonanie, (cid:298)e jako(cid:286)(cid:252) kosztuje, a w zwi(cid:261)zku z tym, (cid:298)eby dostarczy(cid:252) produkty o odpowiedniej jako(cid:286)ci, klient musi odpowiednio zap(cid:225)aci(cid:252). Czyli do standardowych kosztów produkcji nale(cid:298)a(cid:225)oby doliczy(cid:252) dodatek na zapewnienie jako(cid:286)ci, co znacznie (w rozumieniu producenta) zwi(cid:266)k- szy ca(cid:225)kowity koszt projektu. Poniewa(cid:298) za(cid:286) w dobie olbrzymiej konkurencji klient mo(cid:298)e przebiera(cid:252) w(cid:286)ród ofert wielu dostawców, przedsi(cid:266)biorcy wychodz(cid:261) z za(cid:225)o(cid:298)enia, (cid:298)e nale(cid:298)y utrzyma(cid:252) atrakcyjn(cid:261) cen(cid:266) oferowanego towaru czy us(cid:225)ugi, aby to ich ofert(cid:266) wybrano i by to w(cid:225)a(cid:286)nie oni realizowali projekt. My(cid:286)lenie w taki sposób powoduje, (cid:298)e jako(cid:286)(cid:252) spada na dalszy (czasem bardzo daleki) plan, a priorytetem staje si(cid:266) koszt i czas reali- zacji przedsi(cid:266)wzi(cid:266)cia. Dostawcy rozwi(cid:261)za(cid:276) t(cid:225)umacz(cid:261) wysokie koszty zapewnienia jako(cid:286)ci wydatkami ponoszo- nymi na szczegó(cid:225)ow(cid:261) analiz(cid:266), przygotowanie dok(cid:225)adnej specyfikacji produktu, dalej kontrol(cid:266) jako(cid:286)ci tej specyfikacji, wzmo(cid:298)one testowanie (zwykle na kilku poziomach i w co najmniej kilku cyklach) i wszelkie „dodatkowe” czynno(cid:286)ci, które musz(cid:261) przed- si(cid:266)wzi(cid:261)(cid:252), aby uzyska(cid:252) po(cid:298)(cid:261)dany przez klienta poziom jako(cid:286)ci. Przedstawiaj(cid:261) szcze- gó(cid:225)owe wyceny, by udowodni(cid:252), (cid:298)e osi(cid:261)gni(cid:266)cie pewnego poziomu jako(cid:286)ci musi kosztowa(cid:252) tyle i tyle. Rzecz jasna wielu klientów przera(cid:298)a sama my(cid:286)l o ponoszeniu dodatkowych kosztów, nie mówi(cid:261)c ju(cid:298) o tym, (cid:298)e co najmniej osobliwe wydaje im si(cid:266) (cid:298)(cid:261)danie za- p(cid:225)aty za jako(cid:286)(cid:252), czyli oczywist(cid:261) cech(cid:266) zamawianego produktu (nabywaj(cid:261)c np. krzes(cid:225)o, oczekujemy, (cid:298)e b(cid:266)dzie nam s(cid:225)u(cid:298)y(cid:225)o przez krótszy czy d(cid:225)u(cid:298)szy czas, zapewniaj(cid:261)c pe- wien komfort odpoczynku; nikt raczej nie spodziewa si(cid:266) otrzymania produktu, który oka(cid:298)e si(cid:266) niezdatny do u(cid:298)ytkowania, niewygodny czy nietrwa(cid:225)y). Nale(cid:298)y uwzgl(cid:266)dni(cid:252) fakt, (cid:298)e stosunkowo spory odsetek klientów bran(cid:298)y IT nie zdaje sobie sprawy z tego, (cid:298)e o ile dla nich jako(cid:286)(cid:252) zamawianego produktu jest oczywisto(cid:286)ci(cid:261), o tyle dla dostawców parametry jako(cid:286)ciowe to cechy produktu, które podlegaj(cid:261) wycenie, i je(cid:286)li nie zostan(cid:261) uwzgl(cid:266)dnione w szacowaniu kosztów projektu, nie zostan(cid:261) po prostu zaimplementowane. Tym sposobem klient oczekuje taniego, dobrego produktu w ustalonym terminie, dostaw- ca za(cid:286) balansuje na kraw(cid:266)dzi katastrofy, staraj(cid:261)c si(cid:266) zmie(cid:286)ci(cid:252) w ograniczonym bud(cid:298)ecie i czasie, by dostarczy(cid:252) klientowi jaki(cid:286) produkt, przy czym jaki(cid:286) jest tu s(cid:225)owem kluczowym. Poleć książkęKup książkę 22 Jako(cid:264)(cid:232) projektów informatycznych To przekonanie prowadzi do kuriozalnych sytuacji, w których realizuje si(cid:266) projekty, maj(cid:261)c na uwadze jedynie wymagany zakres funkcjonalny produktu, bud(cid:298)et przewidziany na realizacj(cid:266) przedsi(cid:266)wzi(cid:266)cia i czas dostawy produktu do klienta. Zapomina si(cid:266) w tym wy(cid:286)cigu o jednej istotnej kwestii — jako(cid:286)ci. Nie jest sztuk(cid:261) oddanie klientowi produktu, który nie spe(cid:225)ni oczekiwa(cid:276). W takich przypadkach obie strony s(cid:261) przegrane: klient, ponie- wa(cid:298) dosta(cid:225) nie to, czego potrzebowa(cid:225), i dostawca, bo wytworzy(cid:225) produkt, z którego niskiej jako(cid:286)ci zdaje sobie doskonale spraw(cid:266), i nie napawa go dum(cid:261) efekt w(cid:225)asnych prac. Sytuacja, mo(cid:298)na by rzec, patowa. Jak tego typu problemów unikn(cid:261)(cid:252)? Po pierwsze i chyba najwa(cid:298)niejsze, nale(cid:298)y budowa(cid:252) (cid:286)wiadomo(cid:286)(cid:252) jako(cid:286)ciow(cid:261). Po obu stronach: zamawiaj(cid:261)cego i producenta. Je(cid:286)li dla stron jako(cid:286)(cid:252) produktu ma znaczenie, trzeba si(cid:266) liczy(cid:252) z pewnymi konsekwencjami. Konsekwencje te funkcjonuj(cid:261) ju(cid:298) na zasadzie prawd w (cid:286)wiecie IT (nie tylko IT zreszt(cid:261), jako (cid:298)e dotycz(cid:261) dowolnych us(cid:225)ug), znanych pod nazw(cid:261) prawo dwóch trzecich: Szybko i dobrze — nie b(cid:266)dzie tanio. Tanio i szybko — nie b(cid:266)dzie dobrze. Tanio i dobrze — nie b(cid:266)dzie szybko. Prawo dwóch trzecich uros(cid:225)o do rangi (cid:298)artu bran(cid:298)owego, doczeka(cid:225)o si(cid:266) nawet w(cid:225)asnego demotywatora (rysunek 2.2). Rysunek 2.2. Prawo dwóch trzecich (SplaszFX 2011) Mimo zastosowanego tu lekkiego podej(cid:286)cia do tematu trzeba jednak przyj(cid:261)(cid:252) do wia- domo(cid:286)ci i zaakceptowa(cid:252) fakt, (cid:298)e prawo dwóch trzecich nie jest (cid:298)artem informatyków — w taki sposób naprawd(cid:266) dzia(cid:225)a wszelki biznes. Nie nale(cid:298)y oczekiwa(cid:252) wysokiej jako(cid:286)ci, je(cid:286)li nie chce si(cid:266) zainwestowa(cid:252) odpowiednich nak(cid:225)adów. Niestety, klienci cz(cid:266)sto sami Poleć książkęKup książkę Rozdzia(cid:228) 2. (cid:105) Koncepcja jako(cid:264)ci 23 sobie szkodz(cid:261), wybieraj(cid:261)c najta(cid:276)sz(cid:261) ofert(cid:266) (s(cid:225)ynne kryterium ceny, widoczne swego czasu zw(cid:225)aszcza w przetargach publicznych) i dziwi(cid:261)c si(cid:266) pó(cid:296)niej, (cid:298)e „to nie jest to, czego chcieli(cid:286)my”. Szkodz(cid:261) te(cid:298) sobie dostawcy, nie wyja(cid:286)niaj(cid:261)c jasno, (cid:298)e nie da si(cid:266) po(cid:225)(cid:261)czy(cid:252) ni- skiej ceny z wysok(cid:261) jako(cid:286)ci(cid:261). „Chytry dwa razy traci” — mówi polskie przys(cid:225)owie, trafnie podsumowuj(cid:261)c zasady obowi(cid:261)zuj(cid:261)ce w (cid:286)wiecie IT. Niska jako(cid:286)(cid:252) produktu oznacza, (cid:298)e klient otrzyma(cid:225) produkt niespe(cid:225)niaj(cid:261)cy jego oczekiwa(cid:276). Konsekwencje tego mog(cid:261) zasadniczo przybra(cid:252) nast(cid:266)puj(cid:261)ce formy: (cid:141) Klient sk(cid:225)ada reklamacj(cid:266) i (cid:298)(cid:261)da naprawy lub wymiany produktu na taki, który b(cid:266)dzie zgodny z oczekiwaniami. Dodatkowo klient mo(cid:298)e (cid:298)(cid:261)da(cid:252) pokrycia strat poniesionych w wyniku u(cid:298)ytkowania wadliwego produktu i zap(cid:225)aty kar umownych przewidzianych w ramach umowy z producentem. (cid:141) Klient zra(cid:298)a si(cid:266) do firmy producenta — mo(cid:298)e zaakceptowa(cid:252) poniesione na wadliwy produkt koszty, jednak opinia, jak(cid:261) g(cid:225)osi o produkcie i samym dostawcy, mog(cid:225)aby skutecznie zniech(cid:266)ci(cid:252) aktualnych i przysz(cid:225)ych klientów. W tym przypadku producent teoretycznie nie ponosi bezpo(cid:286)rednich kosztów, jednak w ogólnym rozrachunku koszty biznesowe oraz koszty utraty klientów i mo(cid:298)liwo(cid:286)ci biznesowych s(cid:261) olbrzymie, mog(cid:261) doprowadzi(cid:252) nawet do upadku firmy. Opisane wy(cid:298)ej konsekwencje to skutki braku jako(cid:286)ci. Nie musi do nich doj(cid:286)(cid:252), je(cid:286)li zapla- nujemy i wdro(cid:298)ymy (cid:286)rodki maj(cid:261)ce na celu zapewnienie jako(cid:286)ci, ponosz(cid:261)c przy tym rzecz jasna pewien koszt, jednak z pewno(cid:286)ci(cid:261) ni(cid:298)szy ni(cid:298) koszty braku jako(cid:286)ci. Tym sposobem dochodzimy do tematu kosztów jako(cid:286)ci. Jakie nak(cid:225)ady trzeba ponie(cid:286)(cid:252), by zapewni(cid:252) jako(cid:286)(cid:252) produktów? Nak(cid:225)ady te znane s(cid:261) w zarz(cid:261)dzaniu jako(cid:286)ci(cid:261) pod nazw(cid:261) koszty jako(cid:286)ci. Dotycz(cid:261) one wszelkich wydatków (czy raczej inwestycji) poniesionych na uzyskanie pewno(cid:286)ci, (cid:298)e produkty oddawane klientowi wykonane s(cid:261) zgodnie z oczekiwaniami i potrzebami. Wed(cid:225)ug Johna Banka (1996) „Koszt jako(cid:286)ci to niejako skrócony wzór wszystkich kosztów poniesionych przy wytwarzaniu wysokiej jako(cid:286)ci produktu lub us(cid:225)ugi. Sk(cid:225)adaj(cid:261) si(cid:266) na nie koszty profilaktyki, koszty szacowania, koszty wewn(cid:266)trznych b(cid:225)(cid:266)dów, koszty zwi(cid:261)- zane z przekroczeniem wymaga(cid:276) klientów, a tak(cid:298)e koszty wynikaj(cid:261)ce z utraconych ko- rzy(cid:286)ci. W sumie koszty te mog(cid:261) poch(cid:225)on(cid:261)(cid:252) 20 – 30 proc. przychodów lub obrotów firmy”. Koszty jako(cid:286)ci s(cid:261) wi(cid:266)c sum(cid:261) wszystkich kosztów operacyjnych zwi(cid:261)zanych z osi(cid:261)gni(cid:266)- ciem jako(cid:286)ci. Stanowi(cid:261) one element ogólnych kosztów wytwarzania produktu i jako takie powinny by(cid:252) uj(cid:266)te w ca(cid:225)kowitym bud(cid:298)ecie realizacji przedsi(cid:266)wzi(cid:266)cia. Ponadto koszty jako(cid:286)ci umo(cid:298)liwiaj(cid:261) ilo(cid:286)ciow(cid:261) ocen(cid:266) skuteczno(cid:286)ci funkcjonowania systemu zarz(cid:261)dzania jako(cid:286)ci(cid:261) stosowanego w danym przedsi(cid:266)biorstwie, s(cid:261) zatem pomocnym wska(cid:296)nikiem w optymalizacji procesów. Koszty jako(cid:286)ci mo(cid:298)na sklasyfikowa(cid:252) na kilka sposobów. Norma ISO 9004: 1994 rekomen- duje podzia(cid:225) kosztów jako(cid:286)ci na koszty zwi(cid:261)zane z operacjami wewn(cid:266)trznymi oraz z dzia(cid:225)alno(cid:286)ci(cid:261) zewn(cid:266)trzn(cid:261) przedsi(cid:266)biorstwa (rysunek 2.3). Koszty wewn(cid:266)trzne to koszty zgodno(cid:286)ci, czyli nak(cid:225)ady na zapobieganie usterkom i ocen(cid:266) jako(cid:286)ci produktu, oraz koszty niezgodno(cid:286)ci, czyli te zwi(cid:261)zane z b(cid:225)(cid:266)dami. Koszty zewn(cid:266)trzne wi(cid:261)(cid:298)(cid:261) si(cid:266) Poleć książkęKup książkę 24 Jako(cid:264)(cid:232) projektów informatycznych Rysunek 2.3. Koszty jako(cid:286)ci wed(cid:225)ug ISO 9004: 1994 z reprezentacj(cid:261) i dowodami wymaganymi jako obiektywne wykazanie jako(cid:286)ci. Zalicza si(cid:266) do nich ((cid:224)a(cid:276)cucki 1994) koszty oceny zgodno(cid:286)ci systemu jako(cid:286)ci przez instytucje certyfi- kacyjne (np. koszty uzyskania certyfikacji ISO 9001) oraz koszty bada(cid:276) i oceny w(cid:225)a- (cid:286)ciwo(cid:286)ci produktu przez niezale(cid:298)ne o(cid:286)rodki badawcze i audytuj(cid:261)ce. Klasyfikacja ISO nie przewiduje jednak pewnego istotnego czynnika wp(cid:225)ywaj(cid:261)cego na to, (cid:298)e koszty wynikaj(cid:261)ce z braku jako(cid:286)ci s(c
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

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

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: