Download - Bezpieczne oprogramowanie. Metodologia, techniki i ... · Zagadnienie funkcji utraty jakoci 85 ... Diagram drzewa 270 Macierze priorytetów 272 Diagram macierzowy 274 Wykres programowy

Wydawnictwo Helionul. Ko�ciuszki 1c44-100 Gliwicetel. 032 230 98 63e-mail: [email protected]

Bezpieczne oprogramowanie.Metodologia, technikii narzêdzia projektowaniaAutor: Bijay K. Jayaswal, Peter C. Patton ISBN: 978-83-246-1463-9Tytu³ orygina³u: Design for TrustworthySoftware: Tools, Techniques, and Methodologyof Developing Robust SoftwareFormat: 172x245, stron: 816

Poznaj narzêdzia, techniki oraz metodologiê tworzenia niezawodnego oprogramowania

� Jak przeprowadziæ weryfikacjê, oceniaæ i konserwowaæ oprogramowanie?� Jakie s¹ finansowe aspekty tworzenia oprogramowania godnego zaufania?� Jak zarz¹dzaæ portfelem technologii informatycznych?

Jako�æ oprogramowania to wielowarstwowe zagadnienie. Spojrzenie na ni¹ z kilku perspektyw jest kluczowe dla procesu tworzenia nowego produktu. Nale¿y przy tym wzi¹æ pod uwagê nie tylko op³acalno�æ jego wytwarzania i konkurencyjno�æ, ale tak¿e jawne i ukryte potrzeby naszych klientów oraz partnerów biznesowych. St¹d wynika potrzeba u¿ywania zintegrowanej technologii, pomagaj¹cej spe³niaæ wszystkiete wymagania. Odpowiada na ni¹ technologia projektowania oprogramowania godnego zaufania (ang. Designing for Trustworthy Software). S³u¿y ona wczesnemu rozwi¹zywaniu problemów zwi¹zanych z jako�ci¹ tworzonego produktu, dziêki czemu zapobiega powstawaniu b³êdów implementacji. Si³¹ tej technologii jest tak¿e fakt, ¿e wszelkie dzia³ania zwi¹zane z jako�ci¹ s¹ podejmowane przed napisaniem ka¿dego wiersza kodu.

Ta ksi¹¿ka pomo¿e w poprawie jako�ci wszystkim tym, którzy wdra¿aj¹ rozwi¹zania wewnêtrzne i zewnêtrzne, prowadz¹ konsultacje i �wiadcz¹ pomoc techniczn¹. Zawiera ona prze³omowe rozwi¹zania dla specjalistów z dziedziny oprogramowania oraz jako�ci � od programistów po liderów projektu, od g³ównych architektów oprogramowaniapo klientów. Z tego podrêcznika dowiesz siê m.in., jak stosowaæ najlepsze praktykiw dziedzinie kontrolowania jako�ci, organizacji szkoleñ i zarz¹dzania w wyj¹tkowym �rodowisku rozwoju oprogramowania.

� Metodologia rozwoju oprogramowania� Miary jako�ci oprogramowania� Koszty jako�ci oprogramowania� Narzêdzia i techniki projektowania oprogramowania godnego zaufania� Analityczny proces hierarchiczny� Z³o¿ono�æ, b³êdy i poka-yoke w procesach rozwoju oprogramowania� Ocena ryzyka oraz analiza przyczyn i skutków b³êdów (FEMA)� Technologie obiektowe i komponentowe� Techniki AHP, TRIZ, CoSQ i metoda Taguchiego� Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania� Wdra¿ania technologii DFTS� QFD dla projektów

Twórz niezawodne oprogramowanie wysokiej jako�ci!

http://helion.pl

http://helion.pl/zamow_katalog.htm

http://helion.pl/katalog.htm

http://helion.pl/add3571U~bezopr

http://helion.pl/page3571U~emaile.cgi

http://helion.pl/page3571U~cennik.htm

http://helion.pl/online.htm

mailto:[email protected]

http://helion.pl/view3571U~bezopr

http://www.helion.pl/view3571U~bezopr

Spis tre�ci 5

Spis tre�ci

Wprowadzenie 23

Przedmowa 25

Podzi�kowania 31

O autorach 33

CZ�� I WSPÓ�CZESNY PROCES ROZWOJU APLIKACJI, JEGO BRAKI I WYZWANIANA DRODZE DO OPROGRAMOWANIA GODNEGO ZAUFANIA 35

ROZDZIA� 1. Wspó�czesne metodologie rozwoju oprogramowania 37

Rozwój oprogramowania — potrzeba nowego paradygmatu 39Ramka 1.1. Z�o�ono� komputerów 41Strategie rozwoju oprogramowania i modele cyklu �ycia 42

Model utwórz i popraw 44Model wodospadu 45Model b�yskawicznych prototypów 45Model przyrostowy 46Programowanie ekstremalne 48Model spiralny 49Programowanie obiektowe 50Rozwój iteracyjny, czyli model ewolucyjny 52Porównanie ró�nych modeli cyklu �ycia 53

Usprawnienia procesu rozwoju oprogramowania 53Model RUP 54Model CMM 55Wytyczne rozwoju oprogramowania ISO 9000-3 56Porównanie modeli RUP, CMM i ISO 9000 58

Metoda ADR 60Siedem elementów procesu rozwoju stabilnego oprogramowania 60Model rozwoju solidnego oprogramowania 61Ramka 1.2. Krytyczne oprogramowanie steruj�ce w lotnictwie 62Kluczowe zagadnienia 63

6 Spis tre�ci

Dodatkowe materia�y 64wiczenia internetowe 64Pytania przegl�dowe 64Zagadnienia do dyskusji i projekty 65Przypisy 65

ROZDZIA� 2. Wyzwania na drodze do oprogramowania godnego zaufania— solidny projekt w kontek�cie oprogramowania 67

Niezawodno� oprogramowania — fakty i mity 69Podobie�stwa i ró�nice mi�dzy oprogramowaniem i wyrobami produkowanymi 69Porównywanie niezawodno�ci oprogramowania i sprz�tu 71Przyczyny zawodno�ci oprogramowania 71

Ograniczenia tradycyjnych systemów kontroli jako�ci 74Japo�skie systemy zarz�dzania jako�ci� i podej�cie Taguchiego 75Ramka 2.1. �ycie i czasy doktora Genichiego Taguchiego 75Ramka 2.2. Metodologia in�ynierii jako�ci w zarysie 77Ramka 2.3. Taguchi o metodach Taguchiego 78Ramka 2.4. Istota 14 punktów Deminga 80Istota metod solidnego projektowania Taguchiego 83

Zagadnienie stosunku sygna�u do szumu 83Zagadnienie funkcji utraty jako�ci 85Zagadnienie solidnego projektowania 87

Wyzwania na drodze do niezawodno�ci oprogramowania — projektowanieoprogramowania godnego zaufania 88

Model rozwoju solidnego oprogramowania — proces DFTS w praktyce 94Kluczowe zagadnienia 95Dodatkowe materia�y 97wiczenia internetowe 97Pytania przegl�dowe 97Pytania do dyskusji i projekty 98Przypisy 99

ROZDZIA� 3. Miary jako�ci oprogramowania 101

Pomiar jako�ci oprogramowania 103Klasyczne miary jako�ci oprogramowania 103Zarz�dzanie przez jako� 104Ogólne miary jako�ci oprogramowania 106

Spis tre�ci 7

Metodologia pomiarów 106Wewn�trzprocesowe miary jako�ci do testowania oprogramowania 107Miary z�o�ono�ci oprogramowania 109Nauka o oprogramowaniu 110Z�o�ono� cyklomatyczna 112Miary punktów funkcyjnych 113Miary zadowolenia klienta i dost�pno�ci 114

Ramka 3.1. Miejska legenda o oprogramowaniu 115Aktualne miary i modele 116Nowe miary projektowania i oceny architektury 118Powszechne problemy z projektowaniem architektury 119Miary wzorców w OOAD 121Kluczowe zagadnienia 122Dodatkowe materia�y 123wiczenia internetowe 123Pytania przegl�dowe 123Zagadnienia do dyskusji i projekty 124Przypisy 124

ROZDZIA� 4. Finansowe perspektywy tworzenia oprogramowaniagodnego zaufania 127

Dlaczego DFTS wymaga ró�nych analiz finansowych? 129Koszty i jako� — kiedy� i dzi� 130Koszty jako�ci oprogramowania 134

Korzy�ci p�yn�ce z analiz kosztów jako�ci 134Koszty zada� nakierowanych na popraw� jako�ci 135Klasyfikacja kosztów jako�ci oprogramowania 137Ustanawianie systemu tworzenia raportów CoSQ 146Korzy�ci inwestycji w jako� 148Warto� analiz CoSQ 149Pu�apki zwi�zane z programem CoSQ 149

Koszty jako�ci oprogramowania w cyklu �ycia 150Studium przypadku 4.1. Zastosowanie CoSQ w Intents Software 152CoSQ i kosztorysowanie bazuj�ce na aktywno�ciach 157

ABC w firmach zajmuj�cych si� rozwojem oprogramowania 157Uruchamianie ABC przy rozwoju oprogramowania 158Korzy�ci stosowania ABC 159

Ramka 4.1. ABC w przemy�le us�ugowym 160

8 Spis tre�ci

Funkcja utraty jako�ci w przypadku oprogramowania 160Finansowa ocena inwestycji w DFTS 161

Miary oceny DFTS 161Tworzenie platformy oceny finansowej programów DFTS 162

Kluczowe zagadnienia 164Dodatkowe materia�y 166wiczenia internetowe 166Pytania przegl�dowe 166Zagadnienia do dyskusji 167Problemy 168Przypisy 168

ROZDZIA� 5. Infrastruktura organizacyjna i przywództwoprzy stosowaniu DFTS 171

Wyzwania organizacyjne przy wdra�aniu DFTS 173Schemat wdra�ania DFTS 173

Etap 1. Budowanie �wiadomo�ci zarz�du i przekonywanie go 174Etap 2. Komunikowanie o zgodno�ci i zaanga�owaniu wy�szej

kadry zarz�dzaj�cej 178Etap 3. Wykrywanie potencjalnych pu�apek zwi�zanych z inicjatyw� DFTS 179

Ramka 5.1. Nienaganny cykl nauki i TPOV 188Etap 4. K�adzenie podwalin pod organizacj� skoncentrowan� na jako�ci 189Etap 5. Budowanie infrastruktury organizacyjnej 192Etap 6. Zrozumienie ról kluczowych osób 192Etap 7. Projektowanie wspomagaj�cej struktury organizacyjnej 203Etap 8. Ustanawianie efektywnej komunikacji 205Etap 9. Tworzenie odpowiedniego systemu nagród 206Etap 10. Ustanawianie systemu CoSQ 208Etap 11. Planowanie i uruchamianie szkole� w ca�ej organizacji 208Etap 12. Wdra�anie modelu DFTS 209Etap 13. Kontrolowanie nauki i post�pów

oraz przekazywanie informacji zwrotnych 210Etap 14. Utrwalanie usprawnie� i zysków 212Etap 15. Integracja i rozszerzanie programu 212

��czenie wszystkich elementów 213Kluczowe zagadnienia 214Dodatkowe materia�y 218wiczenia internetowe 218

Spis tre�ci 9

Pytania przegl�dowe 219Zagadnienia do dyskusji i projekty 220Przypisy 220

CZ�� II NARZ�DZIA I TECHNIKI PROJEKTOWANIA OPROGRAMOWANIAGODNEGO ZAUFANIA 223

ROZDZIA� 6. Siedem podstawowych narz�dzi zarzdzania jako�ci (P7) 225

Siedem podstawowych narz�dzi (P7) 228Ramka 6.1. Kaoru Ishikawa — rozwój specyficznie japo�skiej strategii

zarz�dzania jako�ci� 230P7 w kontek�cie DFTS 232Inne narz�dzia, techniki i metodologie DFTS 233Diagramy przebiegu 234

Diagramy przebiegu wysokiego poziomu 235Szczegó�owe diagramy przebiegu 235Torowe diagramy przebiegu 236

Diagramy Pareto 236Diagramy przyczynowo-skutkowe 237

Tworzenie diagramów przyczynowo-skutkowych w celu okre�lenia przyczyn 240U�ywanie diagramów przyczynowo-skutkowych do klasyfikowania procesów 241

Diagramy rozproszenia 243Arkusze kontrolne 246Histogramy 246

Okre�lanie rozk�adu 247Okre�lanie, czy wymogi specyfikacji zosta�y spe�nione 248Porównywanie danych za pomoc� warstw 248

Wykresy 248Karty kontrolne 250Kluczowe zagadnienia 252Dodatkowe materia�y 254Pytania przegl�dowe 254Zagadnienia do dyskusji 254Przypisy 255

10 Spis tre�ci

ROZDZIA� 7. Narz�dzia 7 ZP — analiza i interpretacja danych jako�ciowychoraz werbalnych 257

Narz�dzia N7 i 7 ZP 260Typowe zastosowania narz�dzi 7 ZP 261Diagram pokrewie�stwa 263Diagramy wspó�zale�no�ci 266Diagram drzewa 270Macierze priorytetów 272Diagram macierzowy 274Wykres programowy procesu decyzyjnego (PDPC) 274Diagram sieci aktywno�ci 275Umiej�tno�ci behawioralne przydatne do stosowania narz�dzi 7 ZP 276Kluczowe zagadnienia 277Dodatkowe materia�y 278Pytania przegl�dowe 278Zagadnienia do dyskusji i projekty 279Przypisy 279

ROZDZIA� 8. Analityczny proces hierarchiczny 281

Okre�lanie priorytetów, z�o�ono� i analityczny proces hierarchiczny 283AHP i podejmowanie decyzji w obliczu wielu celów 284

S�ownictwo 286Okre�lanie struktury hierarchii celów 286Hierarchia decyzji 288

Studium przypadku 8.1. Informatyczny dylemat dyrektora do spraw systemówinformacyjnych wspomagaj�cych zarz�dzanie (MIS) 289

Studium przypadku 8.1. Rozwi�zanie przygotowane za pomoc� Expert Choice 290Etap 1. Burza mózgów i tworzenie hierarchicznego modelu problemu 290Etap 2. Okre�lanie priorytetów celów na skali ilorazowej 292Etap 3. Okre�lanie priorytetów alternatyw z uwagi na ka�dy cel 295Etap 4. Synteza 297

Przybli�anie wyników AHP na podstawie samodzielnych oblicze� 298Pierwsza metoda tworzenia przybli�onych rozwi�za� 302Druga metoda przybli�ania. Kompleksowa analityczna metoda kryteriów

do okre�lania priorytetów Brassarda 309Wnioski 312Kluczowe zagadnienia 313

Spis tre�ci 11

Dodatkowe materia�y 314wiczenia internetowe 314Pytania przegl�dowe 314Zagadnienia do dyskusji i projekty 315Problemy 315

Problem 1. Zarz�dzanie z�o�ono�ci� przy przekszta�caniu systemów 315Problem 2. Zarz�dzanie z�o�ono�ci� oprogramowania w nowej firmie

z bran�y zaawansowanych technologii 318Problem 3. Z�o�ono� w systemach zarz�dzania kartami pacjentów 320Problem 4. System wspomagaj�cy podejmowanie decyzji

dotycz�cych odwiertów ropy naftowej 321Problem 5. Problem ROI 323Problem 6. Abstrakcyjne analizy z�o�ono�ci 323Problem 7. Wra�liwo� na z�o�ono� 324

Przypisy 324

ROZDZIA� 9. Z�oono��, b��dy i poka-yoke w procesach rozwojuoprogramowania 327

Poka-yoke jako system kontroli jako�ci 329Zasady poka-yoke 330Przyczyny defektów — zmienno�, b��dy i z�o�ono� 331Warunki stosowania poka-yoke 333Pomy�ki jako przyczyny defektów 334Kontrola z�o�ono�ci w rozwoju oprogramowania 336Pomy�ki, metody kontroli i poka-yoke 340Wdra�anie systemu poka-yoke 341Okre�lanie rozwi�zania bazuj�cego na poka-yoke 345Kluczowe zagadnienia 346Dodatkowe materia�y 348wiczenia internetowe 348Pytania przegl�dowe 349Zagadnienia do dyskusji i projekty 349Przypisy 350

12 Spis tre�ci

ROZDZIA� 10. 5S w obszarze inteligentnego zarzdzaniarozwojem oprogramowania 353

5S — wielki krok w kierunku produktywnego �rodowiska pracy 355Etapy wdra�ania systemu 5S 356

Etap 1. Selekcja i sortowanie 356Etap 2. Organizowanie i porz�dkowanie 356Etap 3. Sprz�tanie i czyszczenie 357Etap 4. Standaryzacja 357Etap 5. Podtrzymywanie i samodyscyplina 357

System 5S i proces DFTS 358Ramka 10.1. Od 5S do szczup�ego procesu DFTS 359Prze�amywanie oporu 362Wdra�anie 5S 363

Etap 1. Przekonywanie zarz�du 363Etap 2. Szkolenia i wdra�anie 364Etap 3. Powi�zanie z systemem nagród 364Etap 4. Kontynuacja i ci�g�e usprawnianie 365

Kluczowe zagadnienia 365Dodatkowe materia�y 366wiczenia internetowe 366Pytania przegl�dowe 366Zagadnienia do dyskusji i projekty 367Przypisy 367

ROZDZIA� 11. Zrozumienie potrzeb klienta— QFD w dziedzinie oprogramowania i g�os klienta 369

QFD — pocz�tki i wprowadzenie 371Czym wyró�nia si� QFD w�ród innych systemów jako�ci? 372Historia QFD 373Historia QFD dla oprogramowania 374Czym jest QFD i do czego s�u�y? 376Koncentracja na priorytetach 378Definicja QFD 379Rozwini�cia QFD 380Czteroetapowy model QFD 380Macierz „domu jako�ci” 382

Problemy ze stosowaniem tradycyjnej wersji QFD do oprogramowania 386Niepowodzenia zwi�zane z tradycyjn� wersj� QFD 386

Spis tre�ci 13

„Ta macierz jest za du�a” 387„To zajmuje zbyt du�o czasu” 388„Ju� to wiemy” 389

Nowoczesna wersja QFD dla oprogramowania 391B�yskawiczna metoda QFD 391Siedem narz�dzi do zarz�dzania i planowania (7 ZP) 391Zadowolenie klienta i warto� 391

B�yskawiczny proces QFD 393Etap 1. Kluczowy cel projektu 393Etap 2. Kluczowy segment klientów 395Etap 3. Kluczowe etapy procesu 396Etap 4. Wizyta w gemba 396Etap 5. Jakie s� potrzeby klienta? 397Etap 6. Struktura potrzeb klienta 401Etap 7. Analiza struktury potrzeb klienta 401Etap 8. Okre�lanie priorytetów potrzeb klienta 402Etap 9. Realizacja priorytetowych potrzeb klientów 403Pó�ne rozwini�cia. Szczegó�owa analiza (wy��cznie) istotnych relacji 405„Dom jako�ci” i nie tylko 406Projekty Six Sigma 408Dzia�ania nast�pcze — stosowanie, ewolucja i usprawnianie procesu 408B�yskawiczne programowanie 408Rozwini�cie harmonogramu za pomoc� zarz�dzania projektem

poprzez �a�cuch krytyczny 409Wprowadzanie QFD dla oprogramowania 409

Czynnik ludzki w QFD 410Wyzwania i pu�apki w obszarze QFD 410Jak wdra�a QFD dla oprogramowania? 413

Wnioski 414Nowoczesna wersja QFD w procesie DFTS 414

Kluczowe zagadnienia 415Dodatkowe materia�y 417wiczenia internetowe 418Pytania przegl�dowe 419Zagadnienia do dyskusji 420Przypisy 421

14 Spis tre�ci

ROZDZIA� 12. Kreatywno�� i innowacyjno�� w procesie projektowaniaoprogramowania — TRIZ i metodologia wyborukoncepcji Pugha 427

Potrzeba kreatywno�ci w DFTS 429Kreatywno� i TRIZ 429Ramka 12.1. Czym jest szcz��liwy traf? 430Ramka 12.2. Pionierzy 433TRIZ w rozwoju oprogramowania 433Ramka 12.3. Lingua latina non mortua est 434TRIZ, QFD i metody Taguchiego 442Burza mózgów 442Metodologia wyboru koncepcji Pugha 444Oprogramowanie jako w�asno� intelektualna 447Ramka 12.4. Obraz jest wart… 449Kluczowe zagadnienia 450Dodatkowe materia�y 450wiczenia internetowe 450Pytania przegl�dowe 451Zagadnienia do dyskusji i projekty 451Przypisy 451

ROZDZIA� 13. Ocena ryzyka oraz analiza przyczyn i skutków b��dów (FMEA)w dziedzinie oprogramowania 453

FMEA — analizy przyczyn i efektów b��dów 455Zastosowania FMEA na wczesnych etapach 459Analizy drzewa b��dów oprogramowania 462Przyczyny b��dów w oprogramowaniu i ich �ród�a 465Okre�lanie i ocena ryzyka na poszczególnych etapach DFTS 467Kluczowe zagadnienia 468Dodatkowe materia�y 469wiczenia internetowe 469Pytania przegl�dowe 469Zagadnienia do dyskusji i projekty 469Przypisy 470

Spis tre�ci 15

ROZDZIA� 14. Technologie obiektowe i komponentowe oraz inne narz�dziaprogramistyczne 471

G�ówne wyzwania w rozwoju biznesowych aplikacji dla przedsi�biorstw 473Analizy, projektowanie i programowanie obiektowe 473Ramka 14.1. Narodziny programowania obiektowego 474Ramka 14.2. Zalety warstwy po�redniej j�zyka Java 479Technologia rozwoju oprogramowania na podstawie komponentów 481Poprawa produktywno�ci za pomoc� programowania ekstremalnego 484Zwi�kszanie niezawodno�ci przy u�yciu programowania wielowersyjnego 486

Zalety NVP 487Wady NVP 487

Wspó�czesne �rodowiska programistyczne 488Trendy w automatyzacji programowania 492Kluczowe zagadnienia 495Dodatkowe materia�y 495wiczenia internetowe 496Pytania przegl�dowe 496Zagadnienia do dyskusji i projekty 496Przypisy 496

CZ�� III PROJEKTOWANIE OPROGRAMOWANIA GODNEGO ZAUFANIA 499

ROZDZIA� 15. Miary jako�ci i metody statystycznew rozwoju oprogramowania godnego zaufania 501

Oprogramowanie godne zaufania 503Inicjatywa Microsoftu na rzecz przetwarzania godnego zaufania 504Statystyczne sterowanie procesem w rozwoju oprogramowania 507Metody statystyczne dla architektów oprogramowania 513Kluczowe zagadnienia 517Dodatkowe materia�y 517wiczenia internetowe 518Pytania przegl�dowe 518Zagadnienia do dyskusji i projekty 518Problemy 518Przypisy 518

16 Spis tre�ci

ROZDZIA� 16. Solidne oprogramowanie w kontek�cie 521

Proces tworzenia specyfikacji oprogramowania 523Ramka 16.1. Precyzyjne specyfikacje funkcjonalne 525Czym jest solidne oprogramowanie? 526Wymagania, jakie musi spe�nia solidne oprogramowanie 527Ramka 16.2. Uzyskiwanie informacji od u�ytkownika ko�cowego 528Ocena solidno�ci oprogramowania 528Ramka 16.3. Przyk�ad projektowania parametrów 530Kluczowe zagadnienia 531Dodatkowe materia�y 531wiczenia internetowe 531Pytania przegl�dowe 532Zagadnienia do dyskusji i projekty 532Problemy 532Przypisy 533

ROZDZIA� 17. Metody Taguchiego i optymalizacjapod ktem solidnego oprogramowania 535

Metody Taguchiego w projektowaniu solidnego oprogramowania 537Przyk�ad z dziedziny in�ynierii projektu 541Przyk�ad z obszaru projektowania i rozwoju oprogramowania 544Macierze ortogonalne w eksperymentach Taguchiego nad projektowaniem

parametrów 549Zastosowania w DFTS 552Kluczowe zagadnienia 552Dodatkowe materia�y 553wiczenia internetowe 553Pytania przegl�dowe 553Zagadnienia do dyskusji 553Problemy 553Przypisy 554

ROZDZIA� 18. Weryfikacja, walidacja, testy i ocenaw rozwoju oprogramowania godnego zaufania 555

Ci�g dalszy cyklu rozwoju 557Ramka 18.1. Miejska legenda o oprogramowaniu biznesowym 558

Spis tre�ci 17

Weryfikacja 559Studium przypadku 18.1. Metody Taguchiego w weryfikacji projektu

systemu RTOS 559Walidacja 563Studium przypadku 18.2. Metody Taguchiego w walidacji oprogramowania 563Testy i ocena 566Ramka 18.2. Anomalie z obszaru testów i debugowania 567Kluczowe zagadnienia 571Dodatkowe materia�y 572wiczenia internetowe 572Pytania przegl�dowe 573Zagadnienia do dyskusji i projekty 573Problemy 573Przypisy 573

ROZDZIA� 19. Integracja, wzbogacanie i konserwacjaoprogramowania godnego zaufania 575

Ko�czenie cyklu rozwoju 577Integracja 577Ramka 19.1. Spitfire Supermarine 578Wzbogacanie 578Studium przypadku 19.1. Zwi�kszanie mo�liwo�ci elektronicznego systemu

do prowadzenia dzia�a� wojennych 579Konserwacja 581Studium przypadku 19.2. Konserwacja systemów oprogramowania u klienta 582Ramka 19.2. Usuni�cie zaawansowanej funkcjonalno�ci oprogramowania

w wyniku konserwacji 583Kluczowe zagadnienia 584Dodatkowe materia�y 584wiczenia internetowe 584Pytania przegl�dowe 585Zagadnienia do dyskusji i projekty 585Problemy 585Przypisy 585

18 Spis tre�ci

CZ�� IV ��CZENIE WSZYSTKICH ELEMENTÓW — WDRA ANIE PROGRAMU DFTS 587

ROZDZIA� 20. Przygotowanie organizacji do wdraania DFTS 589

Czas na rozwa�ania 591Studium przypadku 20.1. D��enie do doskona�ego procesu produkcji 591Studium przypadku 20.2. Instytucjonalizacja Six Sigma w GE 594Wyzwania stoj�ce przed liderami w trakcie inicjatyw transformacyjnych 598Ocena kluczowych elementów organizacji 599

Wzbudzanie zaanga�owania liderów 600Zrozumienie roli liderów 601Ocena strategicznych powi�za� 602Zapewnianie zaanga�owania ca�ej organizacji 602Zrozumienie konieczno�ci koncentracji na kliencie 603Ocena obecnego poziomu zarz�dzania jako�ci� 604

Kluczowe zagadnienia 605Dodatkowe materia�y 606wiczenia internetowe 607Pytania przegl�dowe 607Zagadnienia do dyskusji i projekty 607Przypisy 608

ROZDZIA� 21. Uruchamianie inicjatywy DFTS 609

DFTS i platforma PICS 611Planowanie 611Wdra�anie 612

Etap 11. Uruchamianie szkole� w ca�ej organizacji 613Projektowanie programu szkole� — dostosowanie i zró�nicowanie 614Szkolenia dla personelu pomocniczego 615Etap 12. Wdra�anie technologii DFTS — proces nauki i stosowania 616

Kontrola 621Etap 13. Systemy kontroli informacji zwrotnych 624

Studium przypadku 21.1. Ci�g�e uczenie si� i wzbogacanie— proces Operating System korporacji GE 627

Zarz�dzanie projektem 631Zabezpieczanie 632

Etap 14. Utrwalanie usprawnie� i zysków 632Etap 15. Integracja i rozwój inicjatywy 632

Studium przypadku 21.2. Inicjatywy na rzecz jako�ci i ich integracja w TCS 637

Spis tre�ci 19

Zastosowania w ma�ych firmach programistycznych i wioskach elektronicznych 640Co dalej? 641Kluczowe zagadnienia 641Dodatkowe materia�y 643wiczenia internetowe 644Pytania przegl�dowe 644Zagadnienia do dyskusji 645Przypisy 645

CZ�� V SZE�� STUDIÓW PRZYPADKU 647

ROZDZIA� 22. Koszty jako�ci oprogramowania (CoSQ)w Raytheon’s Electronic Systems (RES) Group 653

Wprowadzenie 654Program usprawnie� w RES 654Koszty jako�ci oprogramowania 655

Model CoSQ w RES 655Zbieranie danych CoSQ 656

Zdobyte do�wiadczenia i wiedza 656Wiedza zdobyta w czasie korzystania z modelu CoSQ 656U�ywanie danych CoSQ do zrozumienia wp�ywu usprawnie� 657Koszty i zyski z programu CoSQ 660Instytucjonalizacja kontroli kosztów CoSQ 660

Wnioski ze studium przypadku 660Przypisy 661

ROZDZIA� 23. Zarzdzanie portfelem technologii informatycznych 663

Cz�� pierwsza. Wyzwanie 665Pi� etapów iteracyjnego procesu 665Obiektywno�, subiektywno� i jako� 668

Cz�� druga. Nowe, racjonalne podej�cie 669Etap 1. Projekt 669Etap 2. Strukturyzacja z�o�ono�ci — koncentracja na celach 670Etap 3. Pomiar 670Etap 4. Synteza 674Etap 5. Optymalizacja 676

Ryzyko 679

20 Spis tre�ci

Rozszerzenia 681Podsumowanie 682Przypisy 683

ROZDZIA� 24. Definiowanie potrzeb klienta przy rozwoju zupe�nie nowegoproduktu — QFD dla nowatorskiego oprogramowania 685

Wprowadzenie 687Definicja warto�ci 687Dlaczego nie zapyta? 688Nowatorskie produkty 689

Definiowanie zupe�nie nowych potrzeb 689Metody okre�lania potrzeb klientów 689

Narz�dzia 695Siedem narz�dzi do zarz�dzania i planowania (7 ZP) w QFD 695

Ramka 24.1. Czym jest teoria ogranicze�? 696Procesy wnioskowania w TOC 697

Ostatnie kroki 699Wprowadzanie nowatorskich produktów na rynek 699

Warstwy oporu 700Wnioski 700Podzi�kowania 700Literatura cytowana 702O autorze 704

ROZDZIA� 25. Jurajskie QFD — integrowanie QFD dla us�ug i produktów 705

Profil firmy MD Robotics 707Dlaczego QFD? 707

Historia QFD 708Wymagania Kany 709

Spotkanie z triceratopsem na wyspie przygód Universal Studio na Florydzie 711Schemat QFD 711Analizy g�osu klienta 712Rozwini�cie emocji 715Rozwini�cie cia�a 718Rozwini�cie wymaga� in�ynieryjnych 719

Podsumowanie 720O autorach 723Przypisy 723

Spis tre�ci 21

ROZDZIA� 26. QFD dla projektów. Lepsze zarzdzanie projektamirozwoju oprogramowania dzi�ki b�yskawicznemu QFD 727

Wprowadzenie 729Niepowodzenia 729Cz��ciowy sukces 730Zdefiniowane QFD 730Dobry pocz�tek 730

Problemy w trakcie rozwoju nowych produktów 730Niespójny rozwój jest niewydajny 731Spójny rozwój jest wydajny 733

Koncentracja na warto�ci w QFD dla projektu 735Siedem kroków do lepszych projektów 735

Podsumowanie 746Podzi�kowania 746Literatura cytowana 747O autorze 749

ROZDZIA� 27. QFD 2000. Integrowanie QFD i innych metodzarzdzania jako�ci w celu usprawnienia procesu rozwojunowych produktów 751

Popyt na nowe produkty 753Jako� i rozwój nowych produktów 753

Wspó�czesne narz�dzia do zarz�dzania jako�ci� 754Proces rozwoju nowych produktów 757

Materia�y dotycz�ce QFD i innych metod zarz�dzania jako�ci� 760Analityczny proces hierarchiczny (AHP) i analityczny proces sieciowy (ANP) 760Strategiczne karty wyników 761B�yskawiczna QFD 761Analizy ��czne (conjoint) 761Spotkania z klientami 761Podejmowanie decyzji z udzia�em klientów (CIDM) 761de Bono 761Deming 761Wizyty w gemba i analizy g�osu klienta 762Planowanie hoshin 762Model Kano 762In�ynieria kansei 762Badania g�ównych u�ytkowników 763Szczup�a produkcja 763

22 Spis tre�ci

Nowa strategia Lanchestera 763Programowanie neurolingwistyczne (NLP) 763Zarz�dzanie projektem 763Wybór koncepcji metod� Pugha 763QFD (wersja kompleksowa) 764Niezawodno� 764QFD „�ród�a do potrzeb” 764Siedem narz�dzi do zarz�dzania i planowania (7ZP) 764Siedem narz�dzi do planowania produktu (7PP) 764Siedem narz�dzi do sterowania jako�ci� (7SJ) 764Six Sigma, SPC 765In�ynieria oprogramowania 765Bramki etapowe 765Strategiczne systemy informacyjne (SIS) 765Zarz�dzanie �a�cuchem dostaw 765Metody Taguchiego 765Teoria ogranicze� (TOC) 765Zarz�dzanie przez jako� (TQM) 766TRIZ 766In�ynieria warto�ci 766

O autorze 766Literatura cytowana 767

S�owniczek poj�� technicznych 769

Skorowidz nazwisk 779

Skorowidz 781

67

ROZDZIA� 2

Wyzwania na drodzedo oprogramowania godnego

zaufania — solidny projektw kontek�cie oprogramowania

Projektuj produkty tak, aby nie zawodzi�y w praktyce.Tym samym zmniejszysz liczb� defektów w fabryce.

Genichi Taguchi

Poprawa wymaga zmian. Doskona�o�� wynika z cz�stego ich wprowadzania.

Winston Churchill

OmówienieWieloaspektowe spojrzenie na jako�� jest kluczowe w identyfikowaniu licznych wyma-ga� klientów i innych partnerów. Wyst�puj� niezwyk�e podobie�stwa mi�dzy zagad-nieniami zwi�zanymi z jako�ci� oprogramowania i wyrobów produkowanych, jednaknale�y uwzgl�dni� tak�e istotne ró�nice. Koszty powodowane przez oprogramowanieniskiej jako�ci s� coraz bardziej kluczowe, poniewa� koszt cyklu �ycia typowego sys-temu przekracza cen� sprz�tu. Oprogramowanie wy�szej jako�ci pozwala istotniezredukowa� te koszty, poniewa� 80 – 90% ich sumy poch�ania konserwacja zwi�zanaz poprawianiem, adaptowaniem i rozwijaniem udost�pnionego oprogramowania.Obecnie oko�o 40% wydatków na rozwój oprogramowania poch�aniaj� testy potrzebnew celu usuni�cia b��dów. Kluczowa jest tak�e niezawodno�� oprogramowania, ponie-wa� stosunek b��dów wyst�puj�cych w programach do usterek sprz�towych mo�ewynosi� 100:1, a nawet jeszcze wi�cej. W tym rozdziale opisujemy niepowodzeniatradycyjnych systemów zarz�dzania jako�ci� w kontek�cie udost�pniania oprogramo-wania godnego zaufania. Proponujemy zintegrowan� technologi� rozwoju oprogra-mowania — projektowanie oprogramowania godnego zaufania (ang. Design forTrusthworthy Software — DFTS) — bazuj�c� na trzech kluczowych elementach: itera-cyjnym modelu rozwoju solidnego oprogramowania, in�ynierii optymalizacji projektuoprogramowania i technologii projektowania obiektowego. W DFTS wysi�ki nad zapew-nieniem jako�ci koncentruj� si� na wczesnych etapach procesu rozwoju. Technologia ta

68 Rozdzia� 2 • Wyzwania na drodze do oprogramowania godnego zaufania

pozwala na ci�g�� interakcj� z u�ytkownikami i mi�dzy osobami pracuj�cymi nad pro-duktem na ró�nych etapach, pomaga uwzgl�dni� opinie klientów oraz umo�liwiawczesn� i ci�g�� analiz� ryzyka, optymalizacj� projektu i zastosowanie odpowiedniejtechnologii rozwoju oprogramowania. W tym rozdziale podkre�lamy kluczow� rol�prawdziwego zaanga�owania ze strony mened�erów na drodze do tworzenia opro-gramowania godnego zaufania.

Struktura rozdzia�u� Niezawodno�� oprogramowania

— fakty i mity

� Ograniczenia tradycyjnych systemówkontroli jako�ci

� Japo�skie systemy zarz�dzania jako�ci�i podej�cie Taguchiego

� Istota metod Taguchiego do tworzeniasolidnych projektów

� Wyzwania na drodze do niezawodno�cioprogramowania — projektowanieoprogramowania godnego zaufania

� Model rozwoju solidnegooprogramowania — proces DFTSw praktyce

� Kluczowe zagadnienia

� Dodatkowe materia�y

� wiczenia internetowe

� Pytania przegl�dowe

� Zagadnienia do dyskusji i projekty

� Przypisy

Niezawodno� oprogramowania — fakty i mity 69

Niezawodno�� oprogramowania — fakty i mityJako� oprogramowania, podobnie jak jako� sprz�tu, to wieloaspektowe zagadnienie.W rzeczywisto�ci spojrzenie na jako� z kilku perspektyw jest kluczowe do zrozumieniai utworzenia warto�ciowego produktu oraz zaspokojenia zestawu jawnych i ukrytychpotrzeb klienta. Producent musi tak�e spe�ni wymania wielu innych partnerów, takichjak audytorzy, dostawcy, zwi�zki bran�owe, media i inne zainteresowane grupy. W ko�cu,co nie najmniej istotne, ka�dy wytwórca musi si� upewni, �e jego produkty s� op�acalnei konkurencyjne, aby mog�y spe�nia potrzeby w�a�cicieli przedsi�biorstw. Jako� obejmujewszystkie takie potrzeby i wymagania.

Cz�sto mo�na us�ysze, �e zagadnienia zwi�zane z jako�ci� w �wiecie oprogramowanias� inne ni� w przypadku innych produktów, jednak nie do ko�ca jest to prawd�. Ogólniemówi�c, zasady, systemy i metodologie jako�ciowe stosowane do produkcji wyrobów s�równie prawid�owe w przypadku oprogramowania, sprz�tu i innych dóbr czy us�ug. Jed-nak oprogramowanie ma specyficzne �rodowisko projektowania i rozwoju, które trzebazrozumie. Ponadto nale�y pozna specyficzne wyzwania wynikaj�ce z abstrakcyjnejnatury systemów cyfrowych oraz poziomu z�o�ono�ci wielu aplikacji, a tak�e wzi� poduwag� innowacyjno� i trudno� zada�, do których rozwi�zywania zosta�y zaprojektowane.

Wierzymy, �e w organizacjach zajmuj�cych si� rozwojem oprogramowania oraz takich,dla których tworzenie aplikacji jest istotn� dzia�alno�ci�, zagadnienia zwi�zane z archi-tektur� i projektowaniem s� kluczowe dla d�ugoterminowej op�acalno�ci i powodzeniafirmy. We wszystkich takich organizacjach te zadania s� zbyt wa�ne, aby pozostawi jewy��cznie in�ynierom oprogramowania. Problem produkcji oprogramowania godnegozaufania jest prawdziwym wyzwaniem i wymaga ca�kowitego zaanga�owania kadry zarz�-dzaj�cej. W tej ksi��ce przedstawiamy podstawy filozoficzne, system zarz�dzania oraztechnologi� do zarz�dzania jako�ci� oprogramowania zarówno w du�ych, jak i ma�ychfirmach, ze szczególnym uwzgl�dnieniem oprogramowania dla przedsi�biorstw.

Podobie�stwa i rónice mi�dzy oprogramowaniemi wyrobami produkowanymiZrozumienie ró�nic mi�dzy oprogramowaniem i produkowanymi wyrobami jest nie-zb�dne do zaprojektowania solidnego systemu zarz�dzania jako�ci� oprogramowania.Jedynie wtedy mo�na zaadaptowa systemy i metodologie, które przez ostatnie 50 latmia�y tak znacz�cy wp�yw na popraw� jako�ci wszelkich dóbr produkowanych, a tak�einnych wyrobów i us�ug. Trzeba jednak uwzgl�dni tak�e wa�ne ró�nice, aby prawid�oworozwin� system zarz�dzania jako�ci� oprogramowania. Poni�ej opisane s� pewne zwi�zanez tym tematem zagadnienia:

� Oprogramowanie i wyroby produkowane ró�ni� si� w zakresie znaczenia ró�nychetapów w procesie ich tworzenia (zobacz rysunki 2.1 i 2.2). Rozwój oprogramowaniacharakteryzuje si� centralizacj� projektu. Oprogramowanie to przyk�ad czystego


RYSUNEK 2.1.Podstawowe etapy rozwoju wyrobów produkowanych

RYSUNEK 2.2.Podstawowe etapy rozwoju oprogramowania

projektu, w którym wszystkie operacje s� powi�zane w�a�nie z projektem.Dlatego problemy z jako�ci� i niezawodno�ci� s� zawsze wynikiem b��dówprojektowych, które s� z kolei wynikaj� z pewnych braków poznawczych.

� W oprogramowaniu nie ma niczego, co mo�na porówna do produkcji czy monta�u,kiedy to mo�na zrekompensowa, a nawet naprawi b��dy pope�nione na etapieprojektowania. W przypadku oprogramowania produkcja w zasadzie nie ma miejsca.Sam kod programu jest po prostu dalszym etapem projektu. Ponadto nie mo�natu powiedzie, �e produkt jest „wykonany i dostarczony”. Zawsze mo�nazaprojektowa aplikacj� od nowa, zmodyfikowa j� lub zaktualizowa, a przezto zmieni. Ta charakterystyczna dla oprogramowania elastyczno� cz�sto prowadzido podej�cia „dostarczmy to teraz — b��dy zawsze b�dziemy mogli poprawipó�niej”.

� W odró�nieniu od wyrobów produkowanych, w przypadku oprogramowanianie ma odpowiednika etapu analizy projektu. Wi�kszo� analiz (testów) trzebaprzeprowadza na kodzie programu. Dlatego problemy lub pomy�ki projektowemog� pozosta ukryte a� do pó�nych etapów procesu rozwoju lub nawet do czasurozpocz�cia korzystania z aplikacji.

Mo�na tak�e zauwa�y, �e obecnie dzia�alno� wielu producentów sprz�tu w coraz wi�k-szym stopniu zale�y od oprogramowania. Takie z�o�one systemy winduj� na nast�pnypoziom wyzwania w zakresie projektowania programów.


Porównywanie niezawodno�ci oprogramowania i sprz�tuZawodno� sprz�tu wynika g�ównie z fizycznych b��dów pojedynczych komponentów, cojest cz�sto konsekwencj� przewrotno�ci natury. Z kolei w oprogramowaniu usterki cha-rakteryzuj� si� nieci�g�ym dzia�aniem systemów cyfrowych. Wiedza o projektowaniui in�ynierii urz�dze� jest �atwiejsza do udokumentowania w celu zapobie�enia b��dom ni�wiedza o oprogramowaniu. Ponadto teorie awarii sprz�tu s� rozwijane od lat i umo�liwiaj�zapewnienie wysokiej niezawodno�ci w wyrobach produkowanych1. Dla porównania,baza wiedzy o niezawodno�ci oprogramowania jest bardzo ma�a — st�d nieod��czneproblemy w zapewnianiu stabilno�ci dzia�ania aplikacji.

Oprogramowaniu zawsze towarzysz� urz�dzenia. Je�li jednak znana jest niezawodno�komponentu sprz�towego, zawsze mo�na zoptymalizowa pewno� dzia�ania systemu, do��-czaj�c jedynie komponenty programowe2. Ka�dy system sk�adaj�cy si� z oprogramowaniai sprz�tu mo�e zawie� z powodu usterek aplikacji wywo�anej za pomoc� zewn�trznychpolece�. Awaria oprogramowania jest definiowana jako odchylenie od oczekiwanych wyni-ków zewn�trznych lub niezgodno� danych wyj�ciowych programu z okre�lonymi wyma-ganiami. Oprogramowanie mo�e zawie�, kiedy jest u�ywane w nieoczekiwanej sytuacji.Zwykle awaria mo�e wyst�pi z winy oprogramowania lub nieprzewidzianych warunkówjego wykorzystania. Inaczej mówi�c, aby wyst�pi� b��d, program trzeba uruchomi.

Bie��cy trend kosztów systemów sprz�towo-programowych zmierza w kierunku nie-proporcjonalnej dominacji oprogramowania. Koszt cyklu �ycia (LCC) typowego oprogra-mowania przekracza cen� sprz�tu, a 80 – 90% tych wydatków wi��e si� z konserwacj�aplikacji w zakresie naprawiania, adaptowania i rozwijania udost�pnionego programuw celu zaspokojenia zmieniaj�cych si� i rosn�cych potrzeb u�ytkowników. Oko�o 40% cenyrozwoju oprogramowania poch�aniaj� testy maj�ce na celu usuni�cie b��dów i zapewnieniewysokiej jako�ci programu3.

Stosunek zawodno�ci oprogramowania do sprz�tu mo�e wynosi a� 100:1 w typowychkomputerach bazuj�cych na obwodach scalonych4. Dla bardziej skomplikowanych chipówten stosunek mo�e by jeszcze wy�szy, co daje bardzo wyra�ne wskazówki dotycz�ce kosz-tów i jako�ci. W tabeli 2.1 zamieszczono przegl�d podstawowych ró�nic mi�dzy nieza-wodno�ci� sprz�tu i oprogramowania.

Przyczyny zawodno�ci oprogramowaniaZawodno� oprogramowania to istotny problem spo�eczny. W rzeczywisto�ci ma on glo-balne znaczenie i na jego rozwi�zanie po�wi�ca si� znaczne zasoby. W poni�szych punk-tach opisujemy podstawowe przyczyny zawodno�ci oprogramowania.

� Brak zaanga�owania kadry zarz�dzaj�cej. Najcz�stsz� przyczyn� problemówz jako�ci� jest brak zaanga�owania, po�wi�cenia i wsparcia kadry zarz�dzaj�cej.Deming5 oszacowa� kiedy�, �e powody zwi�zane z zarz�dzaniem mog� odpowiada


TABELA 2.1.Ró�nice i podobie�stwa w niezawodno�ci sprz�tu i oprogramowania6

Kategoria Niezawodno�� sprz�tuNiezawodno��oprogramowania

Podstawowa przyczyna Z powodu efektów fizycznych Z powodu b��dów programisty(lub defektów albo awarii programu)

Przyczyny w cyklu �ycia

Analizy Nieprawid�owe zrozumienie klienta Nieprawid�owe zrozumienie klienta

Wykonalno� B��dne wymagania u�ytkownika B��dne wymagania u�ytkownika

Projekt B��dy w fizycznym projekcie B��dy w projekcie programu

Rozwój Problemy z kontrol� jako�ci B��dy w kodzie programu

Dzia�anie Usterka i awaria B��dy programu (lub inne defektyalbo awarie)

Efekty stosowania

Funkcja projektu

Dziedziny Sprz�t zu�ywa si� i zaczyna zawodzi

Relacje czasowe

Modele matematyczne Fizyka b��du

Czas (t)

Obszar czasu „Krzywa wannowa”

Dobrze rozwini�ta teoretyczniei akceptowana

Funkcje R = f(�, t), � = intensywno� b��dów

Wyk�adnicza (sta�a �)

Weibulla (rosn�ca �)

Obszar danych Bez znaczenia

Oprogramowanie nie zu�ywa si�,ale zawodzi w wyniku nieznanychdefektów lub b��dów

Umiej�tno�ci programisty

Czas i dane

Funkcja malej�ca

Dobrze rozwini�ta teoretycznie,ale o niskiej akceptacji

R = f(b��dy [lub defekty alboawarie], t)

Brak zgodno�ci mi�dzy ró�nymiproponowanymi modelami funkcjiczasu

B��dy = f(testy na danych)

Modele wzrostu Istnieje kilka modeli Istnieje kilka modeli

Miary �, MTBF (ang. mean time betweenfailures, czyli �redni czas pomi�dzyawariami)

MTTF (ang. mean time to failure,czyli �redni czas do wyst�pieniaawarii)

Intensywno� b��dów, liczbawykrytych lub pozosta�ychdefektów (lub awarii)

6 Przedruk za pozwoleniem z W. Kuo, V. Rajendra Prasad, F. A. Tillman i Ching-Lai Wang. Optimal ReliabilityDesign. Cambridge University Press, Cambridge, 2001, punkt 13.5.1, s. 4.


TABELA 2.1.Ró�nice i podobie�stwa w niezawodno�ci sprz�tu i oprogramowania — ci�g dalszy

Kategoria Niezawodno�� sprz�tuNiezawodno��oprogramowania

Techniki wzrostu Projektowanie, przewidywanie Przewidywanie

Techniki przewidywania Diagramy blokowe, drzewa b��dów Analiza �cie�ek (analiza wszystkich�cie�ek to nierozwi�zywalnyproblem, poniewa� liczbamo�liwo�ci w nawet prostychprogramach mo�e zmierzado niesko�czono�ci), z�o�ono�,symulacje

Testy i ewaluacja Akceptacja projektu i produkcji Akceptacja projektu

Projekt MIL-STD-781C (wyk�adnicze)Inne metody (niewyk�adnicze)

Testowanie �cie�ek, symulacje,b��dy, posiew Bayesa

Operacje MIL-STD-781C Brak

Zastosowanie nadmiaru

Równoleg�o� Mo�e poprawia niezawodno� Trzeba rozwa�y najcz�stszeprzyczyny

Rezerwa Automatyczne wykrywaniei poprawianie b��dów, automatycznewykrywanie usterek i prze��czanie

Automatyczne wykrywaniei poprawianie b��dów, automatycznekontrolowanie i ponowneinicjowanie oprogramowania

Logika wi�kszo�ciowa m elementów z n Niepraktyczna

za oko�o 85% ogólnych problemów z jako�ci� w organizacji. Pó�niej Demingzrewidowa� te szacunki i podniós� je do 94%. Dotyczy to zarówno oprogramowania,jak i wyrobów produkowanych.

� Niewystarczaj�ca interakcja z u�ytkownikami. rodowisko i wymaganiau�ytkowników nie zosta�y prawid�owo zrozumiane. Powszechnie uwa�a si�,�e nale�y d��y do poznania opinii klientów i dobrze zrozumie oraz zinterpretowaich jawne i niejawne wymagania. Niestety, udzia� u�ytkowników w rozwojuoprogramowania po napisaniu i uzgodnieniu specyfikacji jest cz�sto znikomy.Ten brak ci�g�ej interakcji z u�ytkownikami oraz ich zmieniaj�cymi si�i ewoluuj�cymi wymaganiami nie zawsze jest dostrzegany w procesie rozwojuoprogramowania. Jest to istotna przyczyna problemów z jako�ci� oprogramowaniai trzeba temu po�wi�ci nale�yt� uwag�.

� Rosn�ca z�o�ono��. Systemy oprogramowania s� tworzone do obs�ugi problemówo rosn�cej z�o�ono�ci. Cz�sto nie ma r�cznych rozwi�za�, które mog�yby pomócw zrozumieniu natury istniej�cych trudno�ci. Oprogramowanie umo�liwia


projektantowi zmierzenie si� z ogromnymi trudno�ciami i udost�pnieniedodatkowych funkcji oraz udogodnie�, które nie zawsze zwi�kszaj� prawdziw�warto� programu. Z�o�one systemy oprogramowania u�ywane do automatycznejkontroli lotu, w silnikach do masowego wyszukiwania, w handlu elektronicznymczy do zarz�dzania globalnymi przelewami gotówki w ró�nych walutach nie maj�r�cznych odpowiedników, z którymi mo�na je porówna. Trudno� i innowacyjno�prowadz� do z�o�ono�ci oraz zwi�zanych z ni� komplikacji projektowychi poznawczych, z czego wynikaj� wyzwania w rozwoju oprogramowania w obszarzeniezawodno�ci, bezpiecze�stwa i zabezpiecze�.

� Brak uzgodnionych kryteriów. W nowych i z�o�onych systemach programistacz�sto tworzy kryteria niezawodno�ci, które nie zawsze spe�niaj� wymaganiau�ytkowników.

� Presja czasu zwi�zana z konkurencyjno�ci�. Konkurencyjna potrzeba skracaniaczasu cyklu rozwoju („mo�emy to pó�niej naprawi, ale dostarczy musimyna czas”) w niemal nieunikniony sposób prowadzi do b��dów w projekciei na innych etapach. Bardzo cz�sto po prostu brakuje czasu na wyczerpuj�cetesty i usuwanie b��dów.

� Ograniczony zakres automatyzacji. Rozwój i stosowanie oprogramowaniato operacje w du�ym stopniu bazuj�ce na czynniku ludzkim. Narz�dzia doautomatyzacji, takie jak CASE i projektowanie obiektowe, s� na pewno pomocne,ale zakres automatyzacji w oprogramowaniu jest ograniczony w porównaniudo wyrobów produkowanych.

� Powi�zanie z Internetem. Coraz szersze zastosowania i integracja systemówoprogramowania z Internetem nara�a je na zagro�enia wynikaj�ce z przypadkulub celowo szkodliwej dzia�alno�ci. Niebezpiecze�stwo mo�e by bardzo powa�ne:od kradzie�y to�samo�ci, przez masowe oszustwa finansowe, po zagro�enienarodowego systemu bezpiecze�stwa.

� Abstrakcyjne dzia�anie systemów cyfrowych. Naturalnie abstrakcyjne dzia�aniesystemów cyfrowych sprawia, �e trudno zapewni jako� oprogramowania.

� Brak odpowiednich zach�t. Cz�sto bod�ce rynkowe i regulacyjne w zakresieniezawodno�ci oprogramowania s� niewystarczaj�ce, podczas gdy istnieje wieleczynników promuj�cych innowacyjne funkcje, wygod� stosowania i b�yskawicznycykl rozwoju.

Ograniczenia tradycyjnych systemów kontroli jako�ciPraktyki zapewniania jako�ci zwykle koncentruj� si� na pó�nych operacjach, takich jakprodukcja lub testy (zobacz rysunki 2.1 i 2.2). Takie podej�cie nie zawsze prowadzi dooptymalnego projektu nawet w przypadku du�ej liczby powtarzanych cykli projekt-pro-totyp-testy, które zasadniczo przebiegaj� przy u�yciu metody prób i b��dów. Ma to wp�yw

Japo�skie systemy zarz�dzania jako�ci� i podej�cie Taguchiego 75

na koszty, czas trwania cyklu i jako� produktu dostarczanego klientowi, je�li udost�p-niane oprogramowanie nie ma odpowiednich w�a�ciwo�ci w zakresie wydajno�ci. Bardzocz�sto dzieje si� tak, poniewa� mened�er produktu nie ma czasu i �rodków, a musi udo-st�pni projekt w fazie produkcyjnej. Na dalszych etapach produkty s� sprawdzane i prze-siewane w celu wykrycia jednostek, które s� niezgodne ze specyfikacj�. Te jednostki s�naprawiane, przetwarzane lub odrzucane. Takie systemy kontroli jako�ci bazuj� na dwóchpodstawowych za�o�eniach:

� Wymagania klientów s� spe�nione, je�li produkt znajduje si� w ramachuzgodnionych ogranicze� wyznaczanych przez specyfikacj�.

� Biznesowe skutki wydajno�ci lub jako�ci produktów „ledwo spe�niaj�cychwymagania specyfikacji” i „na poziomie docelowym” s� takie same.

Jak si� wkrótce oka�e, �adne z tych za�o�e� nie jest uzasadnione. W. Edwards Deming7

by� jednym z pierwszych analityków zarz�dzania, którzy zdali sobie spraw� z brakówsystemów jako�ci zale�nych od kontroli. Jednak to japo�ski in�ynier przemys�owy GenichiTaguchi jako pierwszy zaproponowa� alternatywny system zarz�dzania jako�ci�, nazywanymetodami Taguchiego. To podej�cie zwraca uwag� na warto� „poziomu docelowego”i potrzeb� zarz�dzania jako�ci� ju� na pocz�tku procesu — w dziale bada� i rozwoju, naetapach projektu i in�ynierii cyklu rozwoju oprogramowania — a nie polegania na kon-troli maj�cej na celu wykrywanie i naprawianie b��dów.

Japo�skie systemy zarzdzania jako�cii podej�cie TaguchiegoMetody Taguchiego to zestaw zasad i metodologii projektowych maj�cych na celu uspraw-nienie produktów i procesów. Te techniki sk�adaj� si� na dziedzin� wiedzy nazywan�in�ynieri� jako�ci, solidn� in�ynieri� czy, zw�aszcza w Stanach Zjednoczonych, metodamiTaguchiego od nazwiska autora tego podej�cia, dr. Genichiego Taguchiego (zobacz ramki2.1, 2.2 i 2.3).

Ramka 2.1. �ycie i czasy doktora Genichiego Taguchiego8, 9

Doktor Genichi Taguchi mia� znacz�cy wp�yw na powstanie metodologii zarz�dzania jako-�ci� skoncentrowanej na projekcie. Taguchi urodzi� si� w 1924 roku w Japonii. Po s�u�biew Wydziale Astronomicznym Instytutu Nawigacji Japo�skiej Marynarki Wojennej w latach1942 – 1945 pracowa� w Ministerstwie Zdrowia i Opieki oraz Instytucie StatystycznymMinisterstwa Edukacji. Zyska� bogat� wiedz� na temat technik projektowania eksperymen-talnego i stosowania tablic ortogonalnych, ucz�c si� od nagradzanego japo�skiego staty-styka Matosaburo Masuyamy, z którym zetkn�� si� w czasie pracy w Ministerstwie Zdrowiai Opieki. Doprowadzi�o to do jego zaanga�owania jako konsultanta w firmie MorinagaPharmaceuticals i jej organizacji nadrz�dnej, Morinaga Seika.


W 1950 roku Taguchi do��czy� do nowo powsta�ego Laboratorium Komunikacji Elektrycz-nej w Nippon Telephone and Telegraph Company z zadaniem zwi�kszenia wydajno�ci dzia�ubada� i rozwoju poprzez szkolenie in�ynierów w wydajnych technikach. Taguchi pracowa�tam przez ponad 12 lat i w tym czasie rozpocz�� tworzenie swojej metodologii, któr� dzi�nazywa si� metodami Taguchiego lub solidn� in�ynieri� (zobacz ramka 2.2). Wtedy by�tak�e konsultantem japo�skiego przemys�u. W wyniku tego japo�skie firmy, mi�dzy innymiToyota i jej dostawcy, zacz��y, pocz�wszy od wczesnych lat 50., szeroko stosowa metodyTaguchiego. Pierwsza ksi��ka Taguchiego, która przedstawia�a tablice ortogonalne, zosta�aopublikowana w 1951 roku.

W latach 1954 – 55 Taguchi pracowa� jako profesor zaproszony w Indyjskim InstytucieStatystycznym w Kalkucie w Indiach. W czasie tej wizyty zetkn�� si� ze s�awnymi statysty-kami: Ronaldem A. Fisherem i Walterem A. Shewhartem. W latach 1957 – 58 Taguchi opu-blikowa� pierwsz� wersj� swej dwutomowej pracy Design of Experiments. Do Stanów Zjedno-czonych przyby� po raz pierwszy w 1962 roku jako zaproszony cz�onek grupy badawczej naUniwersytecie Princeton. W tym czasie odwiedzi� AT&T Bell Laboratories. W PrincetonTaguchi by� go�ciem powa�anego statystyka Johna Tukeya, który u�atwi� mu wspó�prac� zestatystykami przemys�owymi z Bell Laboratories. W 1962 roku Taguchi otrzyma� stopie�doktora Uniwersytetu Kyushu.

W 1964 roku Taguchi zosta� profesorem na tokijskim Uniwersytecie Aoyama Gakuin, któr�to funkcj� piastowa� do roku 1982. W 1966 Taguchi wraz z kilkoma innymi autorami napisa�ksi��k� Management by Total Results, która zosta�a przet�umaczona na j�zyk chi�ski przezYuin Wu, wspó�pracownika Taguchiego przy wielu pó�niejszych pracach. Na tym etapiemetody Taguchiego by�y praktycznie nieznane na Zachodzie, cho stosowano je w Tajwaniei Indiach. W tym czasie i w latach 70. wi�kszo� zastosowa� metod Taguchiego dotyczy�a pro-cesów produkcji. Przej�cie do projektowania produktów mia�o miejsce pó�niej. We wcze-snych latach 70. Taguchi rozwin�� zagadnienie funkcji utraty jako�ci. Wtedy te� opubliko-wa� dwie dalsze ksi��ki oraz trzecie wydanie pracy Design for Experiments. Taguchi zosta�laureatem nagrody Deming Application Prize w 1960 roku oraz nagród Deminga za pozycjeksi��kowe w latach 1951, 1953 i 1984, a do pó�nych lat 70. zyska� szerokie uznanie w Japonii.

W 1980 roku zosta� zaproszony do Stanów Zjednoczonych, gdzie ponownie odwiedzi�AT&T Bell Laboratories. Uda�o mu si�, mimo problemów z komunikacj�, przeprowadziudane eksperymenty, które pozwoli�y zastosowa metody Taguchiego w korporacji BellLaboratories. Po wizycie Taguchiego w Stanach Zjednoczonych w 1980 roku coraz wi�cejameryka�skich fabryk zacz��o stosowa jego metodologi�. Mimo niech�tnego przyj�cia tychmetod przez grono ameryka�skich statystyków, co prawdopodobnie wynika�o ze sposobu ichrozpowszechniania, najwi�ksze korporacje Stanów Zjednoczonych zacz��y stosowa meto-dologi� Taguchiego.

W 1982 roku Taguchi zosta� doradc� japo�skiej Organizacji do spraw Standardów. Za wk�adw rozwój przemys�u na ca�ym �wiecie Taguchi otrzyma� wiele wyró�nie�:

� trzykrotnie nagrod� Deming Prize za wk�ad w dziedzin� in�ynierii jako�ci;

� medal Willarda F. Rockwella za po��czenie in�ynierii i metod statystycznychdo osi�gni�cia b�yskawicznych korzy�ci w zakresie kosztów i jako�ci poprzezoptymalizacj� procesu projektowania i produkcji wyrobów;


� medal imienia Shewharta Ameryka�skiego Stowarzyszenia na rzecz KontroliJako�ci;

� Niebiesk� Wst�g� cesarza Japonii, przyznan� w 1990 roku za wk�ad w rozwójprzemys�u;

� honorowe cz�onkostwo w Ameryka�skim Stowarzyszeniu na rzecz Kontroli Jako�ci.

Znalaz� si� te� w motoryzacyjnej galerii s�aw oraz na �wiatowym poziomie galerii s�awz dziedziny in�ynierii, nauki i technologii.

Ramka 2.2. Metodologia in�ynierii jako�ci w zarysie8, 9

Metodologia Taguchiego dotyczy optymalizacji produktu i procesu na etapach projekto-wania oraz prac dzia�u bada� i rozwoju przed rozpocz�ciem produkcji. Jest to metodologiazarz�dzania jako�ci� stosowana we wczesnych fazach rozwoju produktu lub procesu, któraw mniejszym stopniu koncentruje si� na osi�ganiu jako�ci poprzez kontrol�. Jest to wydajnatechnika, obejmuj�ca testy projektu przed rozpocz�ciem etapu produkcji, fabrykacji lub sk�a-dania. Dzi�ki temu jako� staje si� funkcj� prawid�owego projektu, a nie nawet �cis�ych testówi kontroli. Podej�cia Taguchiego mo�na u�ywa tak�e jako metodologii rozwi�zywania pro-blemów zwi�zanych z produkcj� i procesami w obszarze fabrykowania. Jest te� coraz cz��ciejstosowane w innych dziedzinach przemys�u, na przyk�ad przy rozwoju oprogramowania.

W odró�nieniu od zachodniego podej�cia do jako�ci, w metodologii Taguchiego jako� jestpostrzegana raczej w kategoriach utraty jako�ci ni� samej jako�ci. Utrata jako�ci jest defi-niowana jako „straty powodowane przez produkt w spo�eczno�ci od momentu jego udost�p-nienia”. Ta utrata obejmuje straty ponoszone przez firm� w postaci kosztów przetwarzaniai utylizacji, wydatki na konserwacj� oraz przestoje wynikaj�ce z awarii sprz�tu i naprawgwarancyjnych. Nale�y uwzgl�dni tak�e koszty klientów powodowane przez zawodno� oraznisk� wydajno� produktu, prowadz�ce do dalszych strat po stronie producenta w��cznie zespadkiem jego udzia�ów w rynku. Okre�laj�c docelowy poziom jako�ci jako najwy�szy mo�-liwy, Taguchi wi��e prost� kwadratow� funkcj� straty z odchyleniem od poziomu docelo-wego. Funkcja utraty jako�ci pokazuje, �e zmniejszanie zmienno�ci w zakresie jako�ci pro-wadzi do zmniejszania strat i zwi�zanej z tym poprawy jako�ci.

Gdy uwzgl�dnimy takie podej�cie do utraty jako�ci, to strata wyst�pi nawet w przypadku,kiedy produkt spe�nia wymagania stawiane przez specyfikacj�, a jest minimalna, je�li pro-ducent d��y do poziomu docelowego. W praktyce dla u�ytkowników nie jest wa�na specy-fikacja, prawda? Klienci chc�, aby produkt dzia�a� nawet wtedy, kiedy napi�cie pr�dujest niskie, droga wyboista, a operator terminala nieprzeszkolony. Produkt musi dzia�a nadocelowym poziomie w ró�nych warunkach. Mówi�c inaczej, nale�y projektowa� z uwzgl�d-nieniem ró�nych warunków stosowania produktu przez u�ytkowników. To w interesieproducenta le�y utrzymywanie wydajno�ci produktu lub procesu tak blisko poziomu doce-lowego, jak to ekonomicznie mo�liwe. Funkcja straty mo�e pos�u�y do podj�cia decyzjiprojektowych w kategoriach finansowych. Pomaga zdecydowa, czy dodatkowe koszty zwi�k-szenia odporno�ci i usprawnienia produkcji s� usprawiedliwione oraz czy oka�� si� zasadnew warunkach rynkowych.


Metod Taguchiego mo�na u�ywa w trybie „offline” w czasie projektowania lub na bie��cow produkcji.

Taguchi dzieli kontrol� jako�ci w trybie „offline” na trzy etapy.

1. Projektowanie systemu obejmuje tworzenie pomys�u na projekt przy u�yciu burzymózgów, bada� lub innych technik. Projektowanie systemu jako ca�o�ci obejmujetak�e inne narz�dzia, techniki i metodologie, zw�aszcza AHP (ang. Analytic HierarchyProcess), QFD (ang. Quality Function Deployment), TRIZ (ang. Theory of InventiveProblem Solving) i FMEA (ang. Failure Modes and Effects Analysis), opisane odpowiedniow rozdzia�ach 8., 11., 12. i 13.

2. Projektowanie parametrów to istota metod Taguchiego. To pod tym wzgl�demJapo�czycy tradycyjnie si� wyró�niali i osi�gali wysokie poziomy jako�ci bezwzrostu kosztów, co jest g�ówn� przyczyn� ich przewagi konkurencyjnej. Testowanes� nominalne w�a�ciwo�ci projektu lub wybrane poziomy czynników procesu. Ustalanes� kombinacje poziomów parametrów produktu lub poziomów operacji wchodz�cychw sk�ad procesu, które okaza�y si� najmniej wra�liwe na zmiany w czynnikach�rodowiskowych i inne niekontrolowalne elementy (szum). To zagadnienie opisujemyw rozdzia�ach 16. i 17.

3. Projektowanie odporno�ci nale�y zastosowa do projektu produktu lub procesu,je�li zmniejszenie wariancji uzyskane na etapie projektowania parametrów jestniewystarczaj�ce. Ta faza dodatkowo zwi�ksza odporno� na czynniki maj�ce du�ywp�yw na wariancj�. Nale�y zastosowa funkcj� straty i po�wi�ci wi�cej �rodkówtylko wtedy, je�li jest to konieczne. Mo�na zwi�kszy odporno� albo kupi lepszemateria�y lub wyposa�enie, je�li jest to niezb�dne, co podkre�la japo�sk� filozofi�inwestycji na ko�cu, a nie na pocz�tku, jak jest to praktykowane w firmach zachodnich.

Ramka 2.3. Taguchi o metodach Taguchiego10

� Utrata jako�ci wynika g�ównie z awarii produktu po jego sprzeda�y. „Solidno�”wyrobu jest bardziej funkcj� jego projektu ni� bie��cej kontroli, choby naj�ci�lejszej,procesu produkcji.

� Projektuj produkty tak, aby nie zawodzi�y w praktyce. Tym samym zmniejszyszliczb� defektów w fabryce.

� Udost�pniaj�c produkt, który ledwie spe�nia standardy korporacji, producent niezyskuje prawie nic w porównaniu z rozpowszechnianiem wadliwego wyrobu. Nale�yd��y do poziomu docelowego, a nie jedynie mie�ci si� w ramach specyfikacji.

� In�ynieria jako�ci (metody Taguchiego) to technologia przewidywania b��dówjako�ciowych i zapobiegania im na wczesnych etapach rozwoju i projektowaniaproduktu, w��cznie z problemami zwi�zanymi z funkcjami produktu,zanieczyszczeniem �rodowiska i innymi kosztami, które pojawiaj� si� w pó�nychfazach produkcji oraz po wypuszczeniu wyrobu na rynek.

� Nie u�ywaj miar jako�ci zwi�zanych z klientem (takich jak procent defektówczy niezawodno�) jako wczesnych miar jako�ci w dziale bada� i rozwoju. W zamian


u�ywaj dynamicznego stosunku SN jako wska�nika wydajno�ci do oceny solidno�cifunkcji produktu.

� Solidne produkty zapewniaj� silny „sygna�” niezale�nie od zewn�trznego „szumu”i z minimaln� ilo�ci� „szumów” wewn�trznych. Usprawnienie projektu, czyliznacz�cy wzrost w stosunku sygna�u do szumu komponentu, zwi�kszy solidno�produktu jako ca�o�ci.

� Nale�y wytrwale pracowa w celu uzyskania projektów, które mo�na produkowana nieustannie wysokim poziomie. Nale�y stale stawia wysokie wymagania fabryce.

� Jest wi�ksze prawdopodobie�stwo problemów z powodu du�ej zmienno�ci w obr�biespecyfikacji ni� sta�ego odchylenia poza ni�. Je�li odst�pstwo od poziomu docelowegojest sta�e, mo�liwe jest dostosowanie procesu do tego poziomu.

� Warunki panuj�ce w fabryce rzadko s� tak szkodliwe, jak zmienno� w u�ytkowaniuproduktów przez u�ytkowników.

Metody Taguchiego zosta�y uznane za jedno z najwa�niejszych in�ynieryjnychosi�gni� XX wieku. Cho techniki statystyczne u�ywane przez Taguchiego maj� pocz�tkiw eksperymentalnych praktykach projektowych rozwini�tych przez angielskiego staty-styka sir Ronalda Fishera, ich filozoficzne podstawy s� niezaprzeczalnie japo�skie. MetodyTaguchiego i inne japo�skie systemy zarz�dzania jako�ci�, takie jak kaizen (ci�g�e uspraw-nianie), kanban (dok�adnie na czas), zarz�dzanie przez jako�� czy szczup�a produkcja,zosta�y zainspirowane rozwa�aniami ameryka�skiego guru z obszaru jako�ci, W. EdwardsaDeminga, przedstawionymi w jego ksi��kach: 14 Points of Management, Seven Deadly Dise-ases i Obstacles to Quality Products. Proponowana przez Richarda Zultnera adaptacja zasadDeminga do rozwoju oprogramowania jest opisana w rozdziale 5. Metody Taguchiegoi inne systemy zarz�dzania jako�ci� po�o�y�y podwaliny pod niezwyk�y rozwój Japonii jakopot�gi przemys�owej po II wojnie �wiatowej.

Trudno przeceni wp�yw Deminga na prace Taguchiego. Podobnie jak inni japo�scyspecjali�ci do spraw jako�ci, Taguchi by� pod du�ym wp�ywem Deminga. Aby zrozumiespecyficzne podej�cie Taguchiego, nale�y przeanalizowa jego kontekst i korzenie. MetodyTaguchiego i wspó�czesne japo�skie systemy zarz�dzania jako�ci� mia�y swe pocz�tki poII wojnie �wiatowej. Deming, którego cz�sto okre�la si� mianem ojca wspó�czesnego ruchuna rzecz jako�ci, po raz pierwszy odwiedzi� Japoni� w 1946 roku. W nast�pnych dziesi�cio-leciach kontynuowa� wspó�prac� z rz�dem oraz przemys�em japo�skim i wyszkoli� tysi�cejapo�skich mened�erów oraz in�ynierów. Ci mened�erowie byli zainteresowani wspó�cze-snymi ameryka�skimi zasadami zarz�dzania. Jednak Deming zaproponowa� im co� zupe�-nie nowego, co, jego zdaniem, mia�o pomóc w przekszta�ceniu Japonii w dobrze pro-speruj�ce spo�ecze�stwo i odbudowa jej pozycj� jako znacz�cej pot�gi przemys�owej.

Istota zasad zarz�dzania Deminga jest dobrze znana (zobacz ramk� 2.4), cho nie s�one zbyt szeroko stosowane poza Japoni�. Te zasady obejmuj� g�os klienta, zmniejszaniewariancji, stosowanie wskaników statystycznych, zyskiwanie zaufania i szacunku


Ramka 2.4. Istota 14 punktów Deminga11

1. B�d� wierny zamiarom usprawniania produktów i us�ug. Cel to osi�gni�ciekonkurencyjno�ci, pozostanie w grze i zapewnienie miejsc pracy.

2. Zarz�d musi zda sobie spraw� z wyzwa� zwi�zanych z jako�ci�, pozna zakresodpowiedzialno�ci i przej� przywództwo na drodze zmian.

3. Nale�y przesta uwa�a kontrol� za najwa�niejszy element osi�gania jako�ci. Trzebawyeliminowa potrzeb� masowych inspekcji poprzez wbudowanie jako�ci w produkt.

4. Trzeba sko�czy z nagradzaniem dzia�a� na podstawie ceny. W zamian nale�yminimalizowa koszty ��czne. Ka�dy produkt powinien by dostarczany przez tylkojednego dostawc�, co tworzy d�ugotrwa�y zwi�zek bazuj�cy na lojalno�ci i zaufaniu.

5. Nale�y trwale i nieustannie usprawnia system produkcji i us�ug, aby poprawi jako�oraz wydajno�, a tym samym ci�gle zmniejsza koszty.

6. Trzeba prowadzi szkolenia zawodowe. Je�li ludzie s� nieodpowiednio wyszkoleni,nie b�d� pracowa w taki sam sposób, a to wprowadza zmienno�.

7. Nale�y wdro�y system przywództwa. Deming wprowadza rozró�nienie mi�dzyprzywództwem i nadzorem. Ten drugi bazuje na normach i poziomach. Celemnadzoru powinno by pomaganie ludziom, maszynom i urz�dzeniom w lepszymwykonywaniu zada�. Nadzór zarz�du wymaga starannego przemy�lenia, podobniejak nadzór pracowników odpowiedzialnych za produkcj�.

8. Trzeba pozby si� l�ku, aby ka�dy móg� wydajnie pracowa dla firmy. 9. Nale�y znie� podzia�y mi�dzy wydzia�ami. Osoby odpowiedzialne za badania,

projektowanie, sprzeda� i produkcj� musz� pracowa jako zespó�, aby przewidywaproblemy z wytwarzaniem i stosowaniem produktów lub us�ug.

10. Trzeba pozby si� sloganów, napomnie� i norm dla si�y roboczej, które dotycz�braku defektów i nowych poziomów produktywno�ci. Takie napomnienia prowadz�wy��cznie do powstawania antagonizmów. Wi�kszo� przyczyn niskiej jako�cii wydajno�ci le�y po stronie systemu i tym samym znajduje si� poza kontrol� si�yroboczej.

11a. Nale�y wyeliminowa standardy pracy (normy) dla fabryki. Trzeba zast�pi jeprzywództwem.

11b. Trzeba wyeliminowa zarz�dzanie przez zadania oraz liczby (z celaminumerycznymi) i zast�pi je przywództwem.

12a. Nale�y usun� przeszkody, które pozbawiaj� pracowników zatrudnianychna godziny prawa do dumy z pracy. Pracownicy nadzoru powinni odpowiadanie za same liczby, ale za jako�.

12b. Trzeba usun� bariery, które pozbawiaj� zarz�d i in�ynierów prawa do dumyz pracy. Oznacza to mi�dzy innymi rezygnacj� z dorocznych rankingówwydajno�ci i zarz�dzania przez cele.

13. Nale�y wprowadzi dynamiczny program edukacji i samodoskonalenia.14. Trzeba zach�ci wszystkie osoby w firmie do pracy nad przekszta�ceniami.

Transformacja to zadanie dla wszystkich.


wspó�pracowników oraz ci�g�e usprawnianie w obszarze procesów, a tak�e produktówi us�ug. W Japonii podej�cie Deminga by�o z entuzjazmem studiowane i stosowane orazmia�o znacz�cy wp�yw na przemys� tego kraju. W 1951 roku Japo�skie StowarzyszenieNaukowców i In�ynierów (ang. Japanese Union of Scientists and Engineers — JUSE)uhonorowa�o Deminga, nazywaj�c jego imieniem presti�ow� nagrod� z dziedziny jako�ci.Jednak w Stanach Zjednoczonych teorie Deminga by�y ignorowane przez prawie 30 lat.Uwa�a si�, �e mog�o to doprowadzi do utraty konkurencyjno�ci wielu ga��zi ameryka�-skiego przemys�u, takich jak motoryzacja i AGD, w których japo�skie korporacje poczy-ni�y ogromne post�py.

Wiele prac Taguchiego by�o inspirowanych 14 punktami zarz�dzania Deminga.W szczególnym stopniu dotyczy to zasady braku zale�no�ci od inspekcji przy osi�ga-niu jako�ci. W procesie rozwoju produktu Taguchi cofn�� si� jeszcze o krok, k�ad�c naciskna inspekcj� w dziale bada� i rozwoju oraz na etapie projektowania i in�ynierii. Zwraca�uwag� na znaczenie tego, aby produkt dzia�a� na sta�ym, docelowym poziomie, a nie by�tylko ledwie zgodny ze specyfikacj�. Na rysunkach 2.3, 2.4 i 2.5 zademonstrowali�my,�e mo�na to osi�gn� w dwóch krokach. Najpierw nale�y zmniejszy wariancj�, a nast�p-nie dostosowa odpowiedni czynnik, aby osi�gn� wyniki mo�liwie jak najbli�sze docelo-wym wymaganiom klienta, trzeba te� wzi� pod uwag� koszty, projekt i inne ograniczenia.

RYSUNEK 2.3.Rozk�ad wydajno�ci w granicach specyfikacji, ale niesta�ej i poni�ej poziomu docelowego

RYSUNEK 2.4.Rozk�ad wydajno�ci sta�ej, ale poni�ej poziomu docelowego


RYSUNEK 2.5.Rozk�ad wydajno�ci sta�ej i w pobli�u poziomu docelowego

Ponadto Taguchi podkre�la� warto� tolerancji projektu zarówno w �rodowisku pro-dukcyjnym, jak i �rodowisku u�ytkownika. W tym momencie warto przedstawi g�ównenakazy filozofii jako�ci Taguchiego. Oto one.

1. Ci�g�a poprawa jako�ci i redukcja kosztów s� niezb�dne dla przetrwania biznesu. 2. Wa�n� miar� jako�ci produktu jest strata ogólna spowodowana przez produkt

w spo�ecze�stwie obliczana za pomoc� funkcji straty jako�ci. 3. Zmiana przedprodukcyjnych procedur eksperymentalnych z ró�nicowania jednego

czynnika na raz na modyfikowanie wielu czynników jednocze�nie. Jest to takzwane statystyczne projektowanie eksperymentów (ang. Statistical Design ofExperiments — SDE) lub po prostu projektowanie eksperymentów (ang. Designof Experiments — DOE). Dlatego jako� mo�na wbudowa� w produkt i proces.

4. Straty klienta wynikaj�ce z niskiej jako�ci s� mniej wi�cej proporcjonalnedo kwadratu odchylenia cech wydajno�ci od poziomu docelowego (warto�cinominalnej). Taguchi zmieni� cele eksperymentów i definicj� jako�ci z osi�ganiazgodno�ci ze specyfikacj� na d��enie do poziomu docelowego i minimalizacj�zmienno�ci.

5. Zmienno� wydajno�ci produktu (lub us�ugi) mo�na zmniejszy, sprawdzaj�cnieliniowy wp�yw czynników (parametrów) kontrolnych na cechy wydajno�ci.Wszelkie odchylenia od poziomu docelowego prowadz� do niskiej jako�ci.

Jednym z g�ównych celów Taguchiego jest usprawnienie projektu produktu i procesupoprzez wykrycie kontrolowalnych czynników i ich warto�ci, co minimalizuje zmienno�w stosunku do wyniku docelowego. Ustawiaj�c kontrolowalne parametry na ich optymalnypoziom, mo�na sprawi, �e produkt b�dzie bardziej odporny na zmiany w dzia�aniu, sto-sowaniu i warunkach �rodowiskowych. Podstawowa zasada metod Taguchiego dotyczyraczej usuwania negatywnych efektów przyczyn ni� powodów tych niekorzystnych skut-ków. Dzi�ki temu mo�na uzyska produkt wy�szej jako�ci najmniejszym mo�liwymkosztem. Ta strategia neutralizacji samych skutków, a nie przyczyn, jest m�drym rozwi�-zaniem, poniewa� mo�e by �atwiejsza, a tak�e bardziej wydajna ze wzgl�du na kosztyi szybsza. Metody Taguchiego maj� dwa kluczowe cele projektowe:

Istota metod solidnego projektowania Taguchiego 83

� zmniejszenie i minimalizacj� zmienno�ci produktu i ekonomiczne osi�gni�ciepoziomu docelowego,

� zapewnienie tolerancji mierzonej na etapach tworzenia projektu i prototypu, którejest przenoszone na dalsze fazy w produkcji i �rodowisku u�ytkownika.

Istota metod solidnego projektowania TaguchiegoSolidno� to kluczowy koncept metod Taguchiego. „Solidno�” oznacza zdrowie, moc,energi� i si��. Taguchi definiuje j� jako „stan, w którym dzia�anie technologii, produktulub procesu jest w minimalnym stopniu nara�one na czynniki powoduj�ce zmienno�(zarówno w produkcji, jak i �rodowisku u�ytkownika) przy najni�szym koszcie wyprodu-kowania jednostki”. Jest to zdolno� produktu lub procesu do funkcjonowania i spe�nianiawymaga� klientów (ze wzgl�du na niezawodno�, bezpiecze�stwo, zabezpieczenia i takdalej), mimo obecno�ci ró�nych czynników zak�ócaj�cych, które mog� powodowa zmien-no�. Solidny proces lub produkt dzia�a w oczekiwany sposób niezale�nie od wszelkichszkodliwych wp�ywów, zwanych szumem. Szum wynika z wszelkiego rodzaju zmienno�ci:�rodowiskowej wariancji w trakcie stosowania produktu przez klienta, zmienno�ci w czasieprodukcji poszczególnych jednostek i komponentów oraz zró�nicowania komponentóww wyniku starzenia si� i pogarszania cech.

Zagadnienie stosunku sygna�u do szumuWed�ug Taguchiego na solidno� trzeba zwróci uwag� na etapie projektowania lubw dziale bada� i rozwoju. Wi��e si� to ze specyficznym filozoficznym za�o�eniem, �eprawdziw� solidno� mo�na jedynie zaprojektowa i wbudowa w produkt lub projekt,a nie skontrolowa i naprawi. Mówi�c inaczej, podstawowym has�em jest „zapobiega,a nie leczy”. Wymaga to tak�e rozwi�zywania problemów na pocz�tku pracy, w dzialebada� i rozwoju, w trakcie zaawansowanej in�ynierii i projektowania, a nie w trakcie pro-dukcji i kontroli lub, co gorsza, po dostarczeniu produktu do klienta. Metody Taguchiegozapewniaj� wydajn� ze wzgl�du na koszty i czas metodologi� projektowania oraz testo-wania produktów pod k�tem solidno�ci przed rozpocz�ciem ich produkcji. Metody te s�u��tak�e do rozwi�zywania problemów ró�nego rodzaju czy modyfikowania projektów wadli-wych procesów.

Poni�ej znajduj� si� definicje niektórych podstawowych poj� u�ywanych w metodachTaguchiego.

Sygna� to co�, co produkt (lub cz�� albo podzespó�) ma dostarcza, zgodnie z jegocharakterystyk� dzia�ania lub funkcjonaln�. W odbiorniku telewizyjnym lub telefoniesygna�y to co�, co produkt (odbiornik lub aparat) przekazuje jako obraz lub d�wi�k.Dobry sygna� to taki, który zachowuje jako� mimo szumu (wewn�trznych i zewn�trznychinterferencji elektromagnetycznych w odbiorniku telewizyjnym lub telefonie).


Szum to wszystkie czynniki, które powoduj� wariancj�. Taguchi stwierdzi�, �e wieluczynników powoduj�cych szum, takich jak sposób stosowania przez u�ytkownika (naj-cz�stsza przyczyna zmienno�ci), warunki na drodze czy pogoda, nie mo�na kontrolowalub wyeliminowa. To szum powoduje odchylenia charakterystyk dzia�ania i funkcjonal-nych od docelowej jako�ci. Mo�na wyró�ni trzy typy czynników zwi�zanych z szumem:

� Szum zewn�trzny, nazywany tak�e szumem �rodowiskowym, obejmuje czynnikizewn�trzne (�rodowiskowe), takie jak interferencje cieplne lub elektromechaniczne,szoki mechaniczne i elektryczne, kurz czy nieprawid�owe korzystanie ze sprz�tuprzez u�ytkownika. W przypadku samochodu te czynniki obejmuj� temperatur�,�nieg, drog�, warunki jazdy, kurz i tak dalej.

� Szum wewn�trzny, zwany tak�e wariancj� komponentów lub wewn�trznympogarszaniem sprawno�ci cz��ci, wynika ze zu�ywania si� i starzenia.

� Szum mi�dzy produktami, nazywany tak�e wariancj� produkcyjn� lub wariancj�elementów, dotyczy zmienno�ci obecnej mi�dzy poszczególnymi produktami,mimo �e s� tworzone wed�ug tych samych specyfikacji. Mo�e to wynikaze zmienno�ci w zakresie materia�ów i procesów.

Szumy powoduj�, �e produkty dzia�aj� niezgodnie ze specyfikacj� lub ca�kowiciezawodz�. Dzia�anie produktu jest zdominowane przez szum jednostkowy (wewn�trzny) nawczesnych etapach cyklu �ycia produktu, zewn�trzny w trakcie stosowania i pogarszaniesprawno�ci (mi�dzy produktami) pod koniec �ycia. Solidno� i solidne projektowanieprowadz� do braku wra�liwo�ci na czynniki powoduj�ce szum na ró�nych etapach cyklu�ycia produktu, cho wp�ywów tych nie mo�na wyeliminowa i usuwane s� jedynie ichefekty. Dla odbiorników telewizyjnych powszechnym szumem jest „�nie�enie” ekranu,pioruny, sztormy, wahania napi�cia i inne niekorzystne warunki dzia�ania.

W przypadku oprogramowania kluczowe czynniki zwi�zane z szumem, które powoduj�zmienno�, to nieprawid�owe korzystanie z aplikacji przez klientów, napastnicy i hakerzy,robaki i wirusy, przypadkowe lub celowo z�o�liwe naruszenie zabezpiecze�, brak doku-mentacji, nieodpowiednie szkolenia, awarie procedur, niedozwolony dost�p i u�ywanieoraz korzystanie z systemu do wykonywania zada�, do których nie jest przeznaczony.

Taguchi sugeruje, �e jako miary jako�ci nale�y u�ywa stosunku sygna�u do szumu,SN (ang. signal-to-noise)12. Taguchi twierdzi, �e stosunek SN:

� mo�e s�u�y do oceny solidno�ci funkcji produktu, poniewa� reprezentujefunkcjonalno�;

� reprezentuje stosunek tolerancji (lub „�redni�” w terminologii statycznej)do zmienno�ci;

� kiedy stosuje si� go do oceny solidno�ci produktu lub procesu, nale�y go okre�lamianem przetwarzalno�ci (w energi�, moc, informacj�, obraz, dat� i tak dalej).


Przyk�adowo dla urz�dzenia elektromechanicznego, takiego jak silnik elektryczny,stosunek SN mo�na wyrazi w nast�puj�cy sposób:

Ogólnie stosunek SN w systemach bazuj�cych na in�ynierii, takich jak silniki czygeneratory, mo�na opisa w poni�szy sposób:

W przypadku oprogramowania jest to przekszta�canie informacji, danych, obrazówi innych elementów, a nie energii czy mocy. Solidne projektowanie zarówno w dziedzinieoprogramowania, jak i sprz�tu, ma maksymalizowa stosunek SN pod k�tem optymali-zacji projektu.

Zagadnienie funkcji utraty jako�ciJak ju� wspomnieli�my, to zagadnienie jest podstawowym odst�pstwem od zachodniegopodej�cia do jako�ci. Taguchi zajmuje si� bardziej utrat� jako�ci ni� ni� sam�, a tak�eskutkami takich strat dla klienta, producenta i spo�eczno�ci jako ogó�u. Jasno wynikaz tego, �e jako� produktu to co� wi�cej ni� tylko niezawodno�, a koszty produktu obej-muj� nie tylko cen� produkcji i rachunki za materia�y. Klienci oczekuj� niezawodno�ciw czasie trwania cyklu �ycia produktu, a w ostatecznym rozrachunku istotna jest opty-malizacja kosztów tego cyklu. Klienci coraz bardziej domagaj� si� bezb��dnych dostawi dzia�ania. Oczekuj� ró�nych dodatkowych funkcji i udogodnie�. Coraz cz��ciej te� poszu-kuj� stabilnego, wysokiej jako�ci dzia�ania na poziomie docelowym i nie zadowalaj� si�niestabilnym funkcjonowaniem w ramach specyfikacji. Zapewnienie dzia�ania na pozio-mie docelowym mo�e wymaga poniesienia znacz�cych kosztów, ale te� zapewnia korzy�cizarówno producentowi, jak i klientom. Jest to jedna z podstawowych zasad metodologiiTaguchiego.Fowlkes i Creveling klasyfikuj� koszty cyklu �ycia wed�ug nast�puj�cych kategorii13:

� koszty dóbr, które obejmuj� faktury za materia�y oraz wydatki na produkcj�;� koszty powi�zane z obs�ug� konserwacji, gwarancjami, naprawami, wymianami,

utylizacj� i odzyskiwaniem;� koszty klienta, które obejmuj� przestoje, koszty operacyjne i wynikaj�ce

z rozwi�zywania b��dów;� koszty marketingu, które obejmuj� czas wypuszczania produktu na rynek,

promocje oraz zatrzymywanie klientów i zdobywanie nowych.


Utrata jako�ci jest definiowana jako „strata, któr� produkt powoduje w spo�eczno�ciod czasu jego wprowadzenia”. Obejmuje to straty firmy zwi�zane z kosztami przeróbek,utylizacji, konserwacji i przestojów wynikaj�cych z awarii sprz�tu, a tak�e z roszczeniamigwarancyjnymi. S� to równie� koszty ponoszone przez klienta w wyniku zawodno�ci i s�a-bej wydajno�ci produktu, co prowadzi do dalszych strat producenta wraz z utrat� udzia�óww rynku. Mog� pojawi si� te� straty w spo�eczno�ci, je�li dane produkty lub us�ugi wi��si� ze sk�adowaniem odpadów, zanieczyszczeniem �rodowiska, przest�pczo�ci� czy zagro-�eniem bezpiecze�stwa i zdrowia.

Okre�laj�c warto� docelow� cech jako�ciowych na najwy�szym mo�liwym poziomie,Taguchi wi��e prost� kwadratow� funkcj� straty z odst�pstwami od warto�ci docelowej.Funkcja utraty jako�ci pokazuje, �e redukcja zmienno�ci w okolicach poziomu docelo-wego prowadzi do zmniejszania si� strat, z czego wynika wzrost jako�ci. Ta funkcjas�u�y do podejmowania decyzji projektowych na podstawie czynników finansowych i po-zwala okre�li, czy dodatkowe koszty, jakich wymaga wy�sza jako�, oka�� si� warteponiesienia z perspektywy rynku. Z punktu widzenia producenta ��czne koszty mo�nawyrazi w nast�puj�cy sposób:

��czne koszty wynikaj�ce z rezygnacji z jako�ci = straty produkcyjne+utrata jako�ci

Straty produkcyjne obejmuj� utylizacj�, przeróbki, opó�nienia i tak dalej. Utrata jako-�ci to koszt awarii produktów, który powstaje po ich udost�pnieniu. Obejmuje to stratyw wyniku zwrotów, gwarancji i napraw, a tak�e utraty dobrej opinii, co prowadzi dozmniejszenia udzia�ów w rynku. Utrata Jako�ci mo�e by bardzo du�a nawet wtedy, kiedyprodukt jest zgodny ze specyfikacj�. Ta warto� jest równa zeru tylko wtedy, kiedyprodukt dzia�a dok�adnie na poziomie docelowym.

Taguchi proponuje przybli�ony i �atwy wzór na funkcj� utraty jako�ci (ang. qualityloss function — QLF):

Utrata = O2K, gdzie

O = odst�pstwo od poziomu docelowego;

K = koszty �rodków niezb�dnych do zapewnienia dzia�ania produktu na poziomie docelowym.

To wyra�enie jest przybli�eniem, a nie „prawem natury”10. Jest to narz�dzie dla in�y-nierów, a nie prawo naukowe. Wskazuje jedynie na fakt, �e wyst�puje „prawo rosn�cychkosztów” wraz z odchylaniem si� dzia�ania produktu od poziomu docelowego. Trudnoutworzy ogólny i dok�adny model kosztów. Jedn� z przyczyn tej trudno�ci jest to, �eprodukt mo�e mie ró�nych u�ytkowników i by u�ywany w zmienny sposób w odmien-nych warunkach �rodowiskowych. Taguchi sugeruje, �e firmy maj�ce lepsze sposoby sza-cowania kosztów powinny u�ywa w�a�nie ich. Jednak przedstawiona wcze�niej wersjaprzybli�enia funkcji QLF jest warto�ciowa z nast�puj�cych wzgl�dów.


� Zapewnia in�ynierom i mened�erom prosty sposób szacowania kosztów odchyle�od poziomu docelowego.

� Pozwala okre�li na podstawie takich szacunków poziom docelowy tolerancjii jako�ci.

� Stanowi wydajny pod wzgl�dem czasu i kosztów proces szacowania optymalnegoprojektu. Inaczej mówi�c, proces projektowania lepszego produktu jest ta�szyi szybszy ni� w przypadku tradycyjnego projektowania eksperymentów czy innychmetod.

QLF i stosunek SN to dwie miary jako�ci w metodach Taguchiego. Oba te wska�nikik�ad� nacisk na dzia�ania pocz�tkowe (projektowe), a przy ocenie jako�ci bazuj� na mia-rach zwi�zanych z klientem, takich jak koszty w dolarach i cechy dzia�ania (funkcjo-nalne). Jak piszemy w rozdzia�ach 16. i 17., wska�niki te s� powi�zane ze sob� i stanowi�warto�ciowe miary w metodologiach Taguchiego.

Zagadnienie solidnego projektowaniaTaguchi zaleca nast�puj�c� strategi� solidnego projektowania:

� Stosowanie tablic ortogonalnych do przeprowadzania eksperymentów na sucho.Tablica ortogonalna to macierz, która jest integraln� cz��ci� metod Taguchiego.Analiza produktu lub procesu pod k�tem solidno�ci obejmuje identyfikacj�czynników zak�ócaj�cych, które powoduj� odchylenia. Mo�e to by �mudnei kosztowne zadanie. Taguchi zaprojektowa� tablice ortogonalne w celuwyizolowania czynników zak�ócaj�cych spo�ród innych w sposób wydajnyze wzgl�du na czas i koszty. Zastosowanie tej techniki do rozwoju oprogramowaniajest opisane w rozdziale 17.

� Maksymalizacja miar wydajno�ci i stosunku SN w celu optymalizacji projektuz uwzgl�dnieniem czynników kontrolnych.

Solidne projektowanie za pomoc� metod Taguchiego przebiega w trzech nast�puj�cychetapach:

� Projektowanie systemu, zwi�zane z rozwojem zarysu lub prototypu projektu.Jest to niezb�dne w celu zdefiniowania wyj�ciowych cech produktu lub procesu.Ta faza w swej istocie przypomina projektowanie systemów stosowane na zachodzie.

� Projektowanie parametrów. Jest to kluczowy etap solidnego projektowania,w którym Japo�czycy wyró�niaj� si�, tworz�c solidne produkty ni�szym kosztem.Jest to metodologia redukuj�ca zmienno� poprzez zmniejszenie wra�liwo�ciproduktu lub procesu w zakresie wydajno�ci na �ród�a wariancji, a nie poprzezprób� kontroli lub eliminacji tych czynników. Na tym etapie odbywaj� si� testynominalnych funkcji projektu lub wybranych poziomów czynników procesu orazpo��czenia poziomów parametrów produktu lub poziomów operacyjnych procesu,


które s� najmniej wra�liwe na zmiany w warunkach �rodowiskowych i inneniekontrolowalne czynniki (szum). Jest to istota metod Taguchiego w zakresiesolidnego projektowania.

� Projektowanie tolerancji, które, je�li to konieczne, s�u�y dalszemu zmniejszaniuzmienno�ci poprzez zwi�kszenie odporno�ci na czynniki maj�ce du�y wp�ywna wariancj�. Na tym etapie stosowana jest funkcja utraty jako�ci w celusprawdzenia, czy koszt poprawy jako�ci jest uzasadniony ekonomicznie. Inwestycjew zwi�kszenie tolerancji poprzez zastosowanie lepszych materia�ów i sprz�tu nale�ywprowadza wtedy, kiedy wymaga tego rynek, a nie jako wyj�ciowe podej�cie.

W rozdzia�ach 16. i 17. opisujemy metody Taguchiego oraz sposób ich przystosowaniado rozwoju oprogramowania. Ich zastosowanie na pocz�tkowych etapach rozwoju opro-gramowania jest przedstawione w rozdzia�ach 18. i 19.

Wyzwania na drodze do niezawodno�ci oprogramowania— projektowanie oprogramowania godnego zaufaniaOprogramowanie to najbardziej zdradliwy komponent ka�dego systemu informatycznego.Dwa pozosta�e elementy, sprz�t i sieci komunikacyjne, uzyska�y przez ostatnie 50 lat du�owy�szy poziom wydajno�ci i niezawodno�ci. Na przyk�ad wydajno� mikroprocesorówwzros�a w stopniu o oko�o 200 milionów razy wy�szym ni� wydajno� oprogramowania.Wspó�czesne sieci komunikacyjne umo�liwiaj� przenoszenie olbrzymich ilo�ci danych,obrazów i d�wi�ku oraz dost�p do nich zarówno w obr�bie organizacji, jak i globalnie.Wspó�czesne sieci komunikacyjne, a zw�aszcza Internet, wi�� si� z gro�b� przypadko-wego lub celowego nieupowa�nionego dost�pu oraz s� podatne na inne zagro�enia, jed-nak to braki projektowe w oprogramowaniu odpowiadaj� za najwi�ksz� cz�� wra�liwo�cii zawodno�ci systemów informacyjnych. Nawet mimo niezwyk�ego poziomu wydajno�cisprz�tu, ostateczne wyniki dzia�ania ka�dego systemu informatycznego zale�� od nieza-wodno�ci oprogramowania — i to jest tematem niniejszej ksi��ki.

W tabeli 2.2 opisujemy pewne cz�sto stosowane definicje i atrybuty jako�ci oprogra-mowania. Miary oprogramowania s� omówione do� szczegó�owo w rozdziale 3., jednakw tym miejscu warto omówi kilka podstawowych zagadnie�. Najbardziej fundamentalnez nich to poj�cie samej jako�ci. Jako� oprogramowania mo�na zdefiniowa jako stopie�spe�niania wymaga� lub oczekiwa� klientów albo u�ytkowników przez system, kompo-nent lub proces. Mo�e to obejmowa kilka elementów, z których najcz��ciej wymienianajest wiarygodno� oprogramowania. Zwi�zana jest ona z ró�nymi wymaganiami u�ytkow-nika, w��czaj�c w to niezawodno�, bezpiecze�stwo, zabezpieczenia i dost�pno�14. Jest tobliskie u�ywanemu w tej ksi��ce poj�ciu oprogramowania godnego zaufania, które jednakobejmuje dodatkowo mo�liwo� zdobywania zaufania klientów i spe�nianie ich jawnych,

Wyzwania na drodze do niezawodno�ci oprogramowania

Wyzwania na drodze do niezawodno�ci oprogramowania 89

TABELA 2.2.Wybrane atrybuty zwi�zane z jako�ci� oprogramowania

Jako�� oraz atrybuty i systemy jako�ci Opis

Jako� Stopie�, w jakim systemy, komponenty lubprocesy spe�niaj�, po pierwsze, jawne, niejawnei nieoczekiwane potrzeby lub oczekiwania klientówi u�ytkowników oraz, po drugie, okre�lone i ukrytewymagania innych partnerów.

Projektowanie pod k�tem Six Sigma System projektowania i rozwoju nowychproduktów, procesów i us�ug, które spe�niaj�wymagania klientów i s� pozbawione defektów.

Projektowanie oprogramowania godnegozaufania (DFTS)

System projektowania i rozwoju oprogramowania,na którym mo�na polega (obejmuje toniezawodno�, bezpiecze�stwo, zabezpieczenia,dost�pno� i mo�liwo� konserwacji, cho nieogranicza si� do tych cech) i które pozwalareagowa na klienta na ró�nych etapach cyklu�ycia oprogramowania.

Solidna architektura (nazywana tak�e modelemrozwoju solidnego oprogramowania — RSDM)

Model rozwoju oprogramowania s�u��cy dotworzenia oprogramowania godnego zaufania(zobacz rysunek 2.6).

Solidne projektowanie Metodologia utworzona przez GenichiegoTaguchiego w celu rozwoju najni�szym mo�liwymkosztem produktów i procesów dzia�aj�cychna poziomie docelowym zgodnie z wymaganiamiklienta, mimo obecno�ci czynników, którepowoduj� zmienno� w �rodowisku u�ytkownikai produkcyjnym.

Six Sigma Filozofia, system zarz�dzania i metodologiastosowane w celu usprawniania istniej�cychproduktów, procesów i us�ug tak, aby by�ypozbawione b��dów i spe�nia�y wymaganiaklientów w ekonomiczny sposób.

Oprogramowanie Programy komputerowe, procedury i (zwykle)zwi�zane z nimi dokumentacja oraz dane dotycz�cedzia�ania systemu komputerowego.

Dost�pno� oprogramowania Mo�liwo� udost�pniania przez oprogramowanieokre�lonych funkcji, kiedy u�ytkownik ichpotrzebuje.

Wiarygodno� oprogramowania Stopie�, w jakim systemy, komponenty lubprocesy producenta oprogramowania potrafi�spe�nia okre�lone wymagania oraz potrzebyi oczekiwania u�ytkowników.


TABELA 2.2.Wybrane atrybuty zwi�zane z jako�ci� oprogramowania — ci�g dalszy


Solidno� oprogramowania Obejmuje, w�ród innych atrybutów, niezawodno�,bezpiecze�stwo, zabezpieczenia i dost�pno�.

Projekt oprogramowania Architektura i kod programu wykonuj�cegookre�lon� funkcj�.

Mo�liwo� konserwacji oprogramowania �atwo� modyfikowania systemówlub komponentów oprogramowania po ichudost�pnieniu w celu naprawy b��dów, poprawydzia�ania i innych cech lub zaadaptowaniado zmienionego �rodowiska. Cz�sto okre�la si�j� jako MTBF/(MTBF + MTTR).

Jako� oprogramowania Zdatno� oprogramowania do u�ytku. Stopie�,w jakim oprogramowanie ma okre�lony zestawatrybutów potrzebnych do spe�niania jawnychlub ukrytych potrzeb klienta i zapewnia jegozadowolenie. Prawid�owe dzia�anie programujest niezb�dne, ale niewystarczaj�ce, je�lioprogramowanie nie zapewnia satysfakcji klienta.

Atrybuty jako�ci oprogramowania Ró�ne wymagania dotycz�ce oprogramowania,takie jak niezawodno�, bezpiecze�stwo,zabezpieczenia i dost�pno�, potrzebnedo spe�nienia okre�lonych lub ukrytych potrzeb.

Niezawodno� oprogramowania To poj�cie jest zwi�zane z jako�ci� projektuoprogramowania. Wi��e si� raczej z wykrywaniemb��dów ni� ich naprawianiem. Jest to mo�liwo�wykonywania okre�lonej funkcji przez systemlub komponent oprogramowania w okre�lonychwarunkach i czasie.

Bezpiecze�stwo oprogramowania Brak czynników, które mog� spowodowa �mier,obra�enia, chorob�, uszkodzenia, brak kontrolilub dost�pu do danych, naruszenie prywatno�cilub szkody w sprz�cie, mieniu i �rodowisku.

Skalowalno� oprogramowania Mo�liwo� uruchomienia aplikacji komputerowejna wi�kszej maszynie lub procesorachrównoleg�ych w celu obs�ugi wi�kszej liczbytransakcji lub zapewnienie wy�szej przepustowo�citak, aby wydajno� skalowa�a si� liniowo lubprawie liniowo pod wzgl�dem ilo�ci operacji.Oznacza to, �e je�li aplikacja potrafi obs�ugiwaokre�lon� liczb� transakcji na danym serwerze,powinna skalowa si� tak, aby obs�ugiwa�a czteryrazy wi�ksz� ich liczb� na czterokrotnie wi�kszymserwerze.


TABELA 2.2.Wybrane atrybuty zwi�zane z jako�ci� oprogramowania — ci�g dalszy


Zabezpieczenia oprogramowania Cechy oprogramowania dotycz�ce jegoodporno�ci na atak i zapewniaj�ce ochron�poufno�ci, integralno�ci danych oraz dost�pno�cisystemu.

Szybko� realizacji transakcji przezoprogramowanie

Tempo obs�ugi transakcji przez aplikacj� na danymkomputerze, zwykle mierzone w tysi�cach transakcjina minut�.

Mo�liwo� aktualizowania oprogramowania Mo�liwo� �atwej zmiany konfiguracjioprogramowania w celu obs�ugi wi�kszej liczby,wi�kszych lub bardziej skomplikowanychtransakcji.

Przetwarzanie godne zaufania System sk�adaj�cy si� ze sprz�tu, oprogramowaniai sieci, na którym mo�na polega (obejmuje toniezawodno�, bezpiecze�stwo, zabezpieczenia,dost�pno� i mo�liwo� konserwacji, cho nieogranicza si� do tych cech) i który umo�liwiareagowanie na klienta na ró�nych etapachcyklu �ycia.

Oprogramowanie godne zaufania Oprogramowanie, na którym mo�na polega(obejmuje to niezawodno�, bezpiecze�stwo,zabezpieczenia, dost�pno� i mo�liwo�konserwacji, cho nie ogranicza si� do tych cech)i które umo�liwia reagowanie na klienta naró�nych etapach cyklu �ycia.

niejawnych, a nawet nieoczekiwanych potrzeb, a cechy te s� tu bardzo istotne. Pi� g�ów-nych wyzwa� zwi�zanych z tworzeniem oprogramowania godnego zaufania to zapewnie-nie nast�puj�cych cech:

� Niezawodno�ci, czyli mo�liwo�ci wykonywania przez oprogramowanieoczekiwanych funkcji w okre�lonych warunkach i czasie. Jest to jako� zwi�zanaz projektem oprogramowania i dotyczy raczej wykrywania b��dów ni� ichnaprawiania.

� Bezpieczestwa, które dotyczy nieobecno�ci czynników mog�cych spowodowa�mier, obra�enia, chorob�, uszkodzenia, brak dost�pu lub kontroli danych,naruszenie prywatno�ci czy szkody w sprz�cie, mieniu lub �rodowisku.

� Zabezpiecze, zwi�zanych z odporno�ci� oprogramowania na atak, co zapewniaochron� poufno�ci i integralno�ci danych oraz dost�pu do systemu.


RYSUNEK 2.6.Model rozwoju solidnego oprogramowania

� Mo�liwo�ci konserwacji, która dotyczy �atwo�ci modyfikowania systemów lubkomponentów oprogramowania po ich udost�pnieniu w celu naprawy b��dów,poprawy dzia�ania lub innych cech albo adaptacji produktu do zmieniaj�cegosi� �rodowiska.

� Reagowania na klienta, czyli mo�liwo�ci producenta zwi�zanych z uzyskiwaniemi interpretowaniem wymaga� klienta oraz reagowaniem na nie. Wymaga to tak�e


obecno�ci odpowiednich cech solidnego projektu oprogramowania, mo�liwo�ciprowadzenia szkole� i przekazywania wiedzy, umiej�tno�ci pomocy w integracjiistniej�cych systemów, udost�pniania pomocy technicznej po wdro�eniu, mo�liwo�ciudost�pniania zaktualizowanego oprogramowania i systemów oraz spe�nianiawymaga� klientów w zakresie kosztów i harmonogramu dostarczania produktów.Szczególnie istotna jest mo�liwo� zdobywania zaufania klientów i spe�nianieich jawnych, niejawnych, a nawet nieoczekiwanych potrzeb.

S� to g�ówne aspekty oprogramowania godnego zaufania, które jednak s� potrzebnew ró�nym stopniu w zale�no�ci od kategorii oprogramowania i jego zastosowa�. Przyk�a-dowo reagowanie na klienta to szczególnie wa�ny element w przypadku oprogramowaniadla przedsi�biorstw. Wa�ne jest tu, aby twórca oprogramowania zna� i uwzgl�dnia� g�osklienta (ang. voice of customer — VOC), interpretowa� go prawid�owo i móg� na tej pod-stawie tworzy oprogramowanie godne zaufania.

Warto poczyni pewne uwagi na temat zwrotu „godne zaufania”. W dziedzinie zarz�-dzania jako�ci� tego wyra�enia po raz pierwszy u�y� Deming, który stosowa� je w znaczeniuczynnika decyduj�cego o wyborze dostawców w kontek�cie „usuwania l�ków” w�ród pra-cowników. Uwa�amy zastosowanie tego s�owa przez Deminga i kontekst, w jakim go u�y-wa�, za bardzo znacz�ce dla komunikatu, który sami chcemy przekaza: godne zaufaniai niezawodne oprogramowanie, a w zasadzie dowolny produkt i ka�da us�uga, mog� byudost�pniane tylko przez osoby godne zaufania. Tego zwrotu u�yto tak�e w programieprzetwarzania godnego zaufania (ang. Trushworthy Computing — TWC) Microsoftuuruchomionym w 2002 roku. Prezes Microsoftu, Bill Gates, w prze�omowych powiado-mieniach przes�anych w styczniu i lipcu 200215 do 50000 pracowników korporacji naca�ym �wiecie napisa�: „W przesz�o�ci starali�my si�, aby nasze oprogramowanie i us�ugiby�y atrakcyjne dla klientów ze wzgl�du na nowe funkcje i przez mo�liwo� bogategorozszerzania naszej platformy […] wykonali�my pod tym wzgl�dem doskona�� robot�,jednak wszystkie te wspania�e mo�liwo�ci oka�� si� nieistotne, je�li klienci nie b�d� ufanaszym produktom. Dlatego teraz w sytuacji wyboru mi�dzy nowymi funkcjami i rozwi�-zywaniem problemu z zabezpieczeniami musimy stawia na zabezpieczenia”. Gates ponadtonapisa�, �e wierzy, i� TWC „b�dzie najwy�szym priorytetem dla firmy i przemys�u przeznast�pn� dekad� — celem jest utworzenie dla klientów �rodowiska przetwarzania godnegozaufania, które jest równie niezawodne, co elektryczno� zasilaj�ca obecnie nasze domyi firmy”. Zapewnienie oprogramowaniu równej niezawodno�ci, co w przypadku elektrycz-no�ci, to olbrzymie wyzwanie dla przemys�u zwi�zanego z produkcj� oprogramowania.Wyra�nie wida potrzeb� wspó�pracy mi�dzy przemys�em rozwoju oprogramowania, pro-fesjonalistami z bran�y oprogramowania, u�ytkownikami oprogramowania, agencjamiodpowiedzialnymi za regulacje i instytutami badawczymi na ca�ym �wiecie. Proponowanaw tej ksi��ce metodologia DFTS zapewnia spójn� struktur� i technologi� do rozwi�zy-wania tego typu problemów z jako�ci�.


Model rozwoju solidnego oprogramowania— proces DFTS w praktyceOprogramowanie w porównaniu z innymi produktami tworzonymi za pomoc� in�ynieriito przyk�ad czystego projektu. Jak ju� wspomnieli�my, zawodno� oprogramowania tozawsze wynik b��dów w projekcie i intelektualnych braków cz�owieka16. Dlatego jeszczebardziej istotny jest w tym przypadku moment, w którym rozwi�zywane s� problemyz jako�ci�. Filozofia i systemy proponowane w tej ksi��ce zapewniaj� twórcom oprogra-mowania dzia�aj�c� na wczesnych etapach metodologi�, która pozwala zidentyfikowaoptymalne funkcje i ustawienia solidnego (godnego zaufania) oprogramowania. Omówionewcze�niej elementy systemu s� przedstawione w proponowanym przez nas modelu rozwojusolidnego oprogramowania (ang. Robust Software Development Model — RSDM) utworzo-nym jako u�atwienie do rozwoju oprogramowania godnego zaufania (zobacz rysunek 2.6).Ten model spe�nia siedem kluczowych wymaga procesu rozwoju solidnego oprogra-mowania omówionego w rozdziale 1. Bazuje na logicznych zasadach zarz�dzania i spraw-dzonych narz�dziach, technikach i metodologiach charakteryzuj�cych si� nast�puj�cymikluczowymi elementami:

� Infrastruktur� zapewniaj�c� organizacji konieczne przywództwo i systemkomunikacji, szkole� oraz nagród, który wyra�nie wspiera proces DFTS (zobaczrozdzia� 5.).

� Niezawodnym systemem zbierania danych, który pozwala prawid�owo wykrywawymagania u�ytkowników (VOC) w iteracyjny sposób na ró�nych etapach cyklurozwoju oprogramowania (zobacz rozdzia� 11.).

� Wdra�aniem metod Taguchiego w celu optymalizacji projektowaniaoprogramowania i jednocze�nie uwzgl�dniania ró�nych wymaga� klienta, takichjak niezawodno�, koszty i czas trwania cyklu (zobacz rozdzia�y 16. i 17.).

� Ustanowieniem praktyki jednoczesnego pisania kodu i przeprowadzania testóworaz zapewniania wystarczaj�cego czasu na usuwanie b��dów. Ta strategia prowadzido procesu debugowania wydajnego ze wzgl�du na koszty i czas, poniewa�informacje o nat��eniu lub cz�stotliwo�ci b��dów oprogramowania s� wtedyszybciej dost�pne (zobacz rozdzia� 18.).

� Tworzeniem wielu wersji programu17 w sytuacji, kiedy potrzebne jest nadmiaroweoprogramowanie. Sprawia to, �e statystycznie awarie nadmiarowych kopii s� takniezale�ne, jak to mo�liwe. W tym celu w ró�nych programach nale�y stosowaodmienne j�zyki programowania, narz�dzia programistyczne, technologie rozwojui strategie testowania (zobacz rozdzia� 14.).

� Wdra�aniem odpowiednich narz�dzi do zarz�dzania jako�ci� i planowania, takichjak QFD, TRIZ, Pugh i FMEA, które s� szeroko stosowane w produkcji, co jestzgodne z najlepszymi praktykami (zobacz odpowiednio rozdzia�y 11., 12. i 13.).

Kluczowe zagadnienia 95

� Stosowaniem innowacyjnych narz�dzi do rozwoju oprogramowania, takich jakprojektowanie obiektowe (ang. Object-Oriented Design — OOD), programowanieekstremalne czy odpowiednie narz�dzia CASE.

B�dziemy na zmian� odnosi si� do modelu RSDM i procesu DFTS — model opi-suje proces, a proces jest ilustrowany przez model. W kilku ostatnich dziesi�cioleciachwyewoluowa�y liczne modele rozwoju oprogramowania. Wiele z nich, na przyk�ad modelwodospadu, etapowe modele cyklu �ycia, model spiralny czy model V, maj� swe pocz�tkiw lotnictwie i innych ga��ziach przemys�u produkcyjnego, dlatego nie zawsze odpowia-daj� rzeczywisto�ci procesu rozwoju oprogramowania. RSDM to model iteracyjny, któryumo�liwia interakcj� zarówno z wewn�trznymi, jak i z zewn�trznymi klientami orazuchwycenie VOC w procesie rozwoju. Ponadto jest solidny i elastyczny, a tak�e mo�na godostosowa do dowolnego procesu rozwoju oprogramowania. W nast�pnych rozdzia�achopisujemy zastosowania tego modelu i jego elementy ze szczególnym uwzgl�dnieniemkontekstu rozwoju oprogramowania dla przedsi�biorstw.

Chcemy przypomnie, �e w organizacjach zajmuj�cych si� rozwojem oprogramowania iw innych firmach, w których prace nad technologiami informatycznymi stanowi� istotn�dzia�alno�, rozwój oprogramowania jest zbyt wa�ny, aby pozostawi go samym in�ynie-rom oprogramowania. Zarz�dzanie t� aktywno�ci� nale�y do obowi�zków prezesa i wy�szejkadry zarz�dzaj�cej. Musz� oni zapewni niezb�dne przywództwo, utworzy prawid�ow�infrastruktur� zarz�dzania i rozwija �rodowisko pod k�tem tworzenia oprogramowaniagodnego zaufania.

Kluczowe zagadnienia� Wieloaspektowe spojrzenie na jako� jest niezb�dne do zrozumienia i spe�nienia

zestawu jawnych oraz niejawnych wymaga� klientów i innych partnerów.� Zazwyczaj zasady, systemy i metodologie zarz�dzania jako�ci� odpowiednie dla

wyrobów produkowanych mo�na stosowa tak�e dla oprogramowania. Jednakoprogramowanie wi��e si� ze specyficznym �rodowiskiem projektowania i rozwoju.Trzeba zrozumie z�o�ono� cz�sto zwi�zan� z oprogramowaniem i uwzgl�dniinnowacyjno� oraz trudno� zada�, do których obs�ugi jest projektowane.

� Zadanie utworzenia oprogramowania godnego zaufania to prawdziwe wyzwaniei wymaga istotnego zaanga�owania kadry zarz�dzaj�cej.

� Tradycyjne systemy kontroli jako�ci bazuj� na dwóch b��dnych za�o�eniach: popierwsze, wymagania klienta s� spe�nione, je�li produkt jest zgodny ze specyfikacj�,a po drugie, biznesowe skutki sytuacji, w których jako� jest „ledwie zgodna zespecyfikacj�” i „na poziomie docelowym”, s� takie same.

� 14 punktów zarz�dzania Deminga s�u��cych do poprawy jako�ci obejmujews�uchiwanie si� w g�os klientów, zmniejszanie wariancji, stosowanie miar


statystycznych, zdobywanie zaufania i szacunku wspó�pracowników oraz ci�g�eusprawnianie. Deming wskazuje na braki systemów zarz�dzania jako�ci� zale�nychod kontroli.

� Japo�ski in�ynier przemys�owy Genichi Taguchi rozwin�� alternatywny systemzarz�dzania jako�ci� — metody Taguchiego. Taguchi podkre�la warto� „poziomudocelowego” i zaleca dba�o� o jako� na wczesnych etapach, zamiast zale�no�ciod kontroli maj�cych wykry i naprawi b��dy w dalszych fazach rozwoju.

� Filozofi� zarz�dzania jako�ci� Taguchiego mo�na podsumowa w nast�puj�cysposób:� Ci�g�a poprawa jako�ci i redukcja kosztów s� konieczne dla przetrwania

biznesu.� Wa�n� miar� jako�ci jest ogólna strata wygenerowana przez dany produkt

w spo�eczno�ci, mierzona funkcj� utraty jako�ci.� Nale�y wbudowa jako� w produkt lub proces poprzez projekt, u�ywaj�c

techniki statystycznego projektowania eksperymentów.� Straty klientów z powodu niskiej jako�ci s� nieliniowe i mo�ne je oszacowa

jako kwadrat odchylenia cech dzia�ania od ich poziomu docelowego.� Zmienno� dzia�ania produktu mo�na zmniejszy, analizuj�c nieliniowy wp�yw

„czynników kontroli” na cechy funkcjonowania.� Solidne projektowanie przy u�yciu metod Taguchiego przebiega w trzech fazach:

projektowania systemu, projektowania parametrów i projektowania tolerancji.� Oprogramowanie godne zaufania spe�nia liczne jawne i niejawne potrzeby

klientów, a tak�e musi umo�liwia dostosowanie produktu do nich. W kontek�cieoprogramowania dla przedsi�biorstw oprogramowanie godne zaufania musispe�nia przynajmniej nast�puj�ce wymagania: niezawodno�, bezpiecze�stwo,zabezpieczenia, mo�liwo� konserwacji i reagowanie na klienta.

� Proces DFTS charakteryzuje si� okre�lonymi cechami. Oto one:� prawdziwe zaanga�owanie kadry zarz�dzaj�cej i wspieraj�ca to infrastruktura;� mo�liwo� identyfikacji jawnych i niejawnych wymaga� za pomoc� QFD;� optymalizacja wymaga� klienta poprzez wdro�enie metod Taguchiego;� ustanowienie praktyki jednoczesnego pisania kodu i przeprowadzania testów;� stosowanie w razie konieczno�ci nadmiarowego oprogramowania;� wdra�anie odpowiednich narz�dzi do zarz�dzania jako�ci� i planowania, takich

jak TRIZ, Pugh i FMEA;� stosowanie innowacyjnych narz�dzi do rozwoju oprogramowania, takich jak

projektowanie obiektowe.

Dodatkowe materia�y 97

Dodatkowe materia�yhttp://www.prenhallprofessional.com/title/0131872508http://www.agilenty.com/publications

�wiczenia internetowehttp://www.asiusa.com/publications/images/HBR.pdf

Po przeczytaniu artyku�u Taguchiego i Clausinga dost�pnego pod powy�szym adresemprzygotuj si� do dyskusji wniosków na jego temat.

1. Przeanalizuj problemy zwi�zane ze stylem my�lenia „w ramach specyfikacji— poza specyfikacj�” powi�zanym z podej�ciem „zero defektów” w kontek�cieoprogramowania. Jakie rozwi�zanie oferuje metodologia Taguchiego?

2. Podaj trzy przyk�ady „sygna�u” i „szumu” w kontek�cie rozwoju oprogramowania. 3. Zaproponuj zestaw zalece� umo�liwiaj�cych usprawnienie procesu rozwoju

oprogramowania.

Ten artyku� jest dost�pny tak�e w nast�puj�cych miejscach:� Genichi Taguchi i Don Clausing, Robust Quality, „Harvard Business Review”,

Stycze� – Luty 1990.� http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_detail.jhtml?id=�90114&referral=8636&_requestid=9765.

Pytania przegldowe 1. Opisz, jak wieloaspektowe spojrzenie na jako� pomaga zaspokoi potrzeby

ró�norodnych partnerów. Zilustruj odpowied� przyk�adami zwi�zanymi zeznanym Ci oprogramowaniem.

2. Czy problemy z jako�ci� oprogramowania s� zasadniczo odmienne od wyst�puj�cychw wyrobach produkowanych? Jakie s� podobie�stwa i ró�nice mi�dzyoprogramowaniem i wyrobami produkowanymi w zakresie procesu ich rozwoju?

3. Porównaj niezawodno� oprogramowania i sprz�tu. Wyja�nij skutki takiegostanu rzeczy na przyk�adzie trzech z�o�onych systemów sk�adaj�cych si�z oprogramowania i sprz�tu.

4. Wymie� g�ówne powody zawodno�ci oprogramowania. Które z nich uwa�aszza najwa�niejsze?

5. Opisz dwa najwa�niejsze problemy z tradycyjnymi systemami kontroli jako�cii wp�yw, jaki maj� na oprogramowanie.


6. Opisz istot� 14 punktów zarz�dzania Deminga i wyja�nij ich znaczenie w dzisiejszym�wiecie.

7. Wyja�nij, jak metody Taguchiego wi�� si� z zaleceniami Deminga wymienionymiw 14 punktach i jak je wspieraj�.

8. Jak brzmi pi� filozoficznych nakazów podej�cia Taguchiego? Wyja�nij ichzwi�zek z rozwojem oprogramowania. Czy w przypadku sprz�tu s� one inne?Je�li tak, to w jaki sposób?

9. Podsumuj kluczowe zasady metod Taguchiego i trzy etapy solidnegooprogramowania. Opisz, jak wspomagaj� one proces rozwoju oprogramowania.

10. Wymie� i opisz pi� g�ównych wyzwa� na drodze do tworzenia oprogramowaniagodnego zaufania. Zilustruj odpowied� dwoma znanymi Ci produktami z dziedzinyoprogramowania.

11. Opisz cechy modelu rozwoju solidnego oprogramowania. Wyja�nij, jakte w�a�ciwo�ci oraz sam model jako ca�o� mo�na porówna z dwoma podobnymimodelami opisanymi w rozdziale 1.

Pytania do dyskusji i projekty 1. Jak 14 punktów zarz�dzania Deminga rozwi�zuje ograniczenia tradycyjnych

systemów kontroli jako�ci? Mo�esz pos�u�y si� tabelami 5.2, 5.3 i 5.4 z rozdzia�u5. Jak zastosowa wskazówki Deminga do bran�y rozwoju oprogramowania?Przedstaw odpowied� na zaj�ciach.

2. Omów i porównaj zastosowanie metodologii Taguchiego w przypadkuoprogramowania dla przedsi�biorstw i produktów fabrykowanych. Mo�eszpos�u�y si� materia�em z rozdzia�ów od 16. do 19. Przedstaw odpowied�na zaj�ciach.

3. Opisz zalety i wyzwania zwi�zane z wdra�aniem w organizacji metodologiiprojektowania oprogramowania godnego zaufania (DFTS). Jakie s� mo�liwe �ród�aoporu przy jej wprowadzaniu? Jak mo�na sobie z nimi poradzi? Przedstawodpowied� na zaj�ciach.

4. Wyobra� sobie, �e jeste� cz�onkiem zespo�u zarz�dzaj�cego wysokiego stopniakierowanego przez prezesa. Zespó� otrzyma� od zarz�du firmy zajmuj�cej si�rozwojem oprogramowania zadanie identyfikacji g�ównych przyczyn problemówz jako�ci� oprogramowania i zaproponowania platformy umo�liwiaj�cej ichrozwi�zanie. Napisz informacj� dla zarz�du po wst�pnej ocenie. Zaprezentujj� na zaj�ciach.

Przypisy 99

Przypisy1 Bev Littlewood i Lorenzo Strigini, Software Reliability and Dependability: A Roadmap,

Proc. ICSE 2000, 22nd International Conference on Software Engineering, s. 2.2 W. Kuo, V. Rajendra Prasad, F. A. Tillman, Ching-Lai Wand, Optimal Reliability Design

(Cambridge, Cambridge University Press, 2001), punkt 13.5.1, s. 325.3 Ibid., punkt 1.3.3., s. 5.4 D. Simmons, N. Ellis, H. W. Kuo, Software Measurement: A Visualization Toolkit for

Project Control and Process Improvement (Prentice-Hall, 1998).5 N. Logothetis, Managing for Total Quality (London, Prentice-Hall International, 1992),

s. 27.6 Zaadaptowane za przyzwoleniem, op. cit., Kuo i inni, s. 4.7 W. Edwards Deming, Out of the Crisis (Cambridge, MA, MIT Press, 2000). Nale�y zwró-

ci szczególn� uwag� na punkt 3. z 14 punktów o zarz�dzaniu.8 http://www.asiusa.com/about/asi_thought_genichi.aspx.9 http://www.berr.gov.uk.10 Genichi Taguchi i Don Clausing, Robust Quality, „Harvard Business Review”, sty-

cze� – luty 1990, s. 68.11 Zaadaptowane z ksi��ki Out of Crisis Deminga.12 Yuin Wu i Alan Wu, Taguchi Methods for Robust Design (Nowy Jork, ASME, 2000),

s. 13 – 28.13 William Y. Fowlkes i Clyde M. Creveling, Engineering Methods for Robust Product Design:

Using Taguchi Methods in Technology and Product Development (Reading, MA, Addi-son-Wesley, 1997).

14 Op. cit. Littlewood i Strigini, s. 1.15 http://www.microsoft.com/mscorp/execmail/2002/07-18twc.mspx.16 Op. cit. Littlewood i Strigini, s. 2.17 N. Ashrafi, O. Berman, M. Cutler, Optimal design of large software-systems using N-version

programming, „IEEE Transactions on Reliability”, R-43 (2): 344 – 350, 1994.