Oprogramowanie godne zaufania Metodologia, techniki i narzedzia projektowania
Bezpieczne oprogramowanie. Metodologia, techniki i narzędzia projektowania Autor: Bijay K. Jayaswal, Peter C. Patton ISBN: 978-83-246-1463-9 Tytuł oryginału: Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software Format: 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? JakoSć 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łacalnoSć jego wytwarzania i konkurencyjnoSć, 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ć wszystkie te 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 jakoScią 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 jakoScią są podejmowane przed napisaniem każdego wiersza kodu. Ta książka pomoże w poprawie jakoSci wszystkim tym, którzy wdrażają rozwiązania wewnętrzne i zewnętrzne, prowadzą konsultacje i Swiadczą pomoc techniczną. Zawiera ona przełomowe rozwiązania dla specjalistów z dziedziny oprogramowania oraz jakoSci od programistów po liderów projektu, od głównych architektów oprogramowania po klientów. Z tego podręcznika dowiesz się m.in., jak stosować najlepsze praktyki w dziedzinie kontrolowania jakoSci, organizacji szkoleń i zarządzania w wyjątkowym Srodowisku rozwoju oprogramowania. " Metodologia rozwoju oprogramowania " Miary jakoSci oprogramowania " Koszty jakoSci oprogramowania " Narzędzia i techniki projektowania oprogramowania godnego zaufania " Analityczny proces hierarchiczny " ZłożonoSć, błędy i poka-yoke w procesach rozwoju oprogramowania Wydawnictwo Helion " Ocena ryzyka oraz analiza przyczyn i skutków błędów (FEMA) ul. KoSciuszki 1c " Technologie obiektowe i komponentowe 44-100 Gliwice " Techniki AHP, TRIZ, CoSQ i metoda Taguchiego tel. 032 230 98 63 " Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania e-mail: helion@helion.pl " Wdrażania technologii DFTS " QFD dla projektów Twórz niezawodne oprogramowanie wysokiej jakoSci! 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 WYZWANIA NA DRODZE DO OPROGRAMOWANIA GODNEGO ZAUFANIA 35 ROZDZIA 1. Wspó czesne metodologie rozwoju oprogramowania 37 Rozwój oprogramowania potrzeba nowego paradygmatu 39 Ramka 1.1. Z o ono komputerów 41 Strategie rozwoju oprogramowania i modele cyklu ycia 42 Model utwórz i popraw 44 Model wodospadu 45 Model b yskawicznych prototypów 45 Model przyrostowy 46 Programowanie ekstremalne 48 Model spiralny 49 Programowanie obiektowe 50 Rozwój iteracyjny, czyli model ewolucyjny 52 Porównanie ró nych modeli cyklu ycia 53 Usprawnienia procesu rozwoju oprogramowania 53 Model RUP 54 Model CMM 55 Wytyczne rozwoju oprogramowania ISO 9000-3 56 Porównanie modeli RUP, CMM i ISO 9000 58 Metoda ADR 60 Siedem elementów procesu rozwoju stabilnego oprogramowania 60 Model rozwoju solidnego oprogramowania 61 Ramka 1.2. Krytyczne oprogramowanie steruj ce w lotnictwie 62 Kluczowe zagadnienia 63 6 Spis tre ci Dodatkowe materia y 64 wiczenia internetowe 64 Pytania przegl dowe 64 Zagadnienia do dyskusji i projekty 65 Przypisy 65 ROZDZIA 2. Wyzwania na drodze do oprogramowania godnego zaufania solidny projekt w kontek cie oprogramowania 67 Niezawodno oprogramowania fakty i mity 69 Podobie stwa i ró nice mi dzy oprogramowaniem i wyrobami produkowanymi 69 Porównywanie niezawodno ci oprogramowania i sprz tu 71 Przyczyny zawodno ci oprogramowania 71 Ograniczenia tradycyjnych systemów kontroli jako ci 74 Japo skie systemy zarz dzania jako ci i podej cie Taguchiego 75 Ramka 2.1. ycie i czasy doktora Genichiego Taguchiego 75 Ramka 2.2. Metodologia in ynierii jako ci w zarysie 77 Ramka 2.3. Taguchi o metodach Taguchiego 78 Ramka 2.4. Istota 14 punktów Deminga 80 Istota metod solidnego projektowania Taguchiego 83 Zagadnienie stosunku sygna u do szumu 83 Zagadnienie funkcji utraty jako ci 85 Zagadnienie solidnego projektowania 87 Wyzwania na drodze do niezawodno ci oprogramowania projektowanie oprogramowania godnego zaufania 88 Model rozwoju solidnego oprogramowania proces DFTS w praktyce 94 Kluczowe zagadnienia 95 Dodatkowe materia y 97 wiczenia internetowe 97 Pytania przegl dowe 97 Pytania do dyskusji i projekty 98 Przypisy 99 ROZDZIA 3. Miary jako ci oprogramowania 101 Pomiar jako ci oprogramowania 103 Klasyczne miary jako ci oprogramowania 103 Zarz dzanie przez jako 104 Ogólne miary jako ci oprogramowania 106 Spis tre ci 7 Metodologia pomiarów 106 Wewn trzprocesowe miary jako ci do testowania oprogramowania 107 Miary z o ono ci oprogramowania 109 Nauka o oprogramowaniu 110 Z o ono cyklomatyczna 112 Miary punktów funkcyjnych 113 Miary zadowolenia klienta i dost pno ci 114 Ramka 3.1. Miejska legenda o oprogramowaniu 115 Aktualne miary i modele 116 Nowe miary projektowania i oceny architektury 118 Powszechne problemy z projektowaniem architektury 119 Miary wzorców w OOAD 121 Kluczowe zagadnienia 122 Dodatkowe materia y 123 wiczenia internetowe 123 Pytania przegl dowe 123 Zagadnienia do dyskusji i projekty 124 Przypisy 124 ROZDZIA 4. Finansowe perspektywy tworzenia oprogramowania godnego zaufania 127 Dlaczego DFTS wymaga ró nych analiz finansowych? 129 Koszty i jako kiedy i dzi 130 Koszty jako ci oprogramowania 134 Korzy ci p yn ce z analiz kosztów jako ci 134 Koszty zada nakierowanych na popraw jako ci 135 Klasyfikacja kosztów jako ci oprogramowania 137 Ustanawianie systemu tworzenia raportów CoSQ 146 Korzy ci inwestycji w jako 148 Warto analiz CoSQ 149 Pu apki zwi zane z programem CoSQ 149 Koszty jako ci oprogramowania w cyklu ycia 150 Studium przypadku 4.1. Zastosowanie CoSQ w Intents Software 152 CoSQ i kosztorysowanie bazuj ce na aktywno ciach 157 ABC w firmach zajmuj cych si rozwojem oprogramowania 157 Uruchamianie ABC przy rozwoju oprogramowania 158 Korzy 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 160 Finansowa ocena inwestycji w DFTS 161 Miary oceny DFTS 161 Tworzenie platformy oceny finansowej programów DFTS 162 Kluczowe zagadnienia 164 Dodatkowe materia y 166 wiczenia internetowe 166 Pytania przegl dowe 166 Zagadnienia do dyskusji 167 Problemy 168 Przypisy 168 ROZDZIA 5. Infrastruktura organizacyjna i przywództwo przy stosowaniu DFTS 171 Wyzwania organizacyjne przy wdra aniu DFTS 173 Schemat wdra ania DFTS 173 Etap 1. Budowanie wiadomo ci zarz du i przekonywanie go 174 Etap 2. Komunikowanie o zgodno ci i zaanga owaniu wy szej kadry zarz dzaj cej 178 Etap 3. Wykrywanie potencjalnych pu apek zwi zanych z inicjatyw DFTS 179 Ramka 5.1. Nienaganny cykl nauki i TPOV 188 Etap 4. K adzenie podwalin pod organizacj skoncentrowan na jako ci 189 Etap 5. Budowanie infrastruktury organizacyjnej 192 Etap 6. Zrozumienie ról kluczowych osób 192 Etap 7. Projektowanie wspomagaj cej struktury organizacyjnej 203 Etap 8. Ustanawianie efektywnej komunikacji 205 Etap 9. Tworzenie odpowiedniego systemu nagród 206 Etap 10. Ustanawianie systemu CoSQ 208 Etap 11. Planowanie i uruchamianie szkole w ca ej organizacji 208 Etap 12. Wdra anie modelu DFTS 209 Etap 13. Kontrolowanie nauki i post pów oraz przekazywanie informacji zwrotnych 210 Etap 14. Utrwalanie usprawnie i zysków 212 Etap 15. Integracja i rozszerzanie programu 212 czenie wszystkich elementów 213 Kluczowe zagadnienia 214 Dodatkowe materia y 218 wiczenia internetowe 218 Spis tre ci 9 Pytania przegl dowe 219 Zagadnienia do dyskusji i projekty 220 Przypisy 220 CZ II NARZ DZIA I TECHNIKI PROJEKTOWANIA OPROGRAMOWANIA GODNEGO ZAUFANIA 223 ROZDZIA 6. Siedem podstawowych narz dzi zarz dzania jako ci (P7) 225 Siedem podstawowych narz dzi (P7) 228 Ramka 6.1. Kaoru Ishikawa rozwój specyficznie japo skiej strategii zarz dzania jako ci 230 P7 w kontek cie DFTS 232 Inne narz dzia, techniki i metodologie DFTS 233 Diagramy przebiegu 234 Diagramy przebiegu wysokiego poziomu 235 Szczegó owe diagramy przebiegu 235 Torowe diagramy przebiegu 236 Diagramy Pareto 236 Diagramy przyczynowo-skutkowe 237 Tworzenie diagramów przyczynowo-skutkowych w celu okre lenia przyczyn 240 U ywanie diagramów przyczynowo-skutkowych do klasyfikowania procesów 241 Diagramy rozproszenia 243 Arkusze kontrolne 246 Histogramy 246 Okre lanie rozk adu 247 Okre lanie, czy wymogi specyfikacji zosta y spe nione 248 Porównywanie danych za pomoc warstw 248 Wykresy 248 Karty kontrolne 250 Kluczowe zagadnienia 252 Dodatkowe materia y 254 Pytania przegl dowe 254 Zagadnienia do dyskusji 254 Przypisy 255 10 Spis tre ci ROZDZIA 7. Narz dzia 7 ZP analiza i interpretacja danych jako ciowych oraz werbalnych 257 Narz dzia N7 i 7 ZP 260 Typowe zastosowania narz dzi 7 ZP 261 Diagram pokrewie stwa 263 Diagramy wspó zale no ci 266 Diagram drzewa 270 Macierze priorytetów 272 Diagram macierzowy 274 Wykres programowy procesu decyzyjnego (PDPC) 274 Diagram sieci aktywno ci 275 Umiej tno ci behawioralne przydatne do stosowania narz dzi 7 ZP 276 Kluczowe zagadnienia 277 Dodatkowe materia y 278 Pytania przegl dowe 278 Zagadnienia do dyskusji i projekty 279 Przypisy 279 ROZDZIA 8. Analityczny proces hierarchiczny 281 Okre lanie priorytetów, z o ono i analityczny proces hierarchiczny 283 AHP i podejmowanie decyzji w obliczu wielu celów 284 S ownictwo 286 Okre lanie struktury hierarchii celów 286 Hierarchia decyzji 288 Studium przypadku 8.1. Informatyczny dylemat dyrektora do spraw systemów informacyjnych wspomagaj cych zarz dzanie (MIS) 289 Studium przypadku 8.1. Rozwi zanie przygotowane za pomoc Expert Choice 290 Etap 1. Burza mózgów i tworzenie hierarchicznego modelu problemu 290 Etap 2. Okre lanie priorytetów celów na skali ilorazowej 292 Etap 3. Okre lanie priorytetów alternatyw z uwagi na ka dy cel 295 Etap 4. Synteza 297 Przybli anie wyników AHP na podstawie samodzielnych oblicze 298 Pierwsza metoda tworzenia przybli onych rozwi za 302 Druga metoda przybli ania. Kompleksowa analityczna metoda kryteriów do okre lania priorytetów Brassarda 309 Wnioski 312 Kluczowe zagadnienia 313 Spis tre ci 11 Dodatkowe materia y 314 wiczenia internetowe 314 Pytania przegl dowe 314 Zagadnienia do dyskusji i projekty 315 Problemy 315 Problem 1. Zarz dzanie z o ono ci przy przekszta caniu systemów 315 Problem 2. Zarz dzanie z o ono ci oprogramowania w nowej firmie z bran y zaawansowanych technologii 318 Problem 3. Z o ono w systemach zarz dzania kartami pacjentów 320 Problem 4. System wspomagaj cy podejmowanie decyzji dotycz cych odwiertów ropy naftowej 321 Problem 5. Problem ROI 323 Problem 6. Abstrakcyjne analizy z o ono ci 323 Problem 7. Wra liwo na z o ono 324 Przypisy 324 ROZDZIA 9. Z o ono , b dy i poka-yoke w procesach rozwoju oprogramowania 327 Poka-yoke jako system kontroli jako ci 329 Zasady poka-yoke 330 Przyczyny defektów zmienno , b dy i z o ono 331 Warunki stosowania poka-yoke 333 Pomy ki jako przyczyny defektów 334 Kontrola z o ono ci w rozwoju oprogramowania 336 Pomy ki, metody kontroli i poka-yoke 340 Wdra anie systemu poka-yoke 341 Okre lanie rozwi zania bazuj cego na poka-yoke 345 Kluczowe zagadnienia 346 Dodatkowe materia y 348 wiczenia internetowe 348 Pytania przegl dowe 349 Zagadnienia do dyskusji i projekty 349 Przypisy 350 12 Spis tre ci ROZDZIA 10. 5S w obszarze inteligentnego zarz dzania rozwojem oprogramowania 353 5S wielki krok w kierunku produktywnego rodowiska pracy 355 Etapy wdra ania systemu 5S 356 Etap 1. Selekcja i sortowanie 356 Etap 2. Organizowanie i porz dkowanie 356 Etap 3. Sprz tanie i czyszczenie 357 Etap 4. Standaryzacja 357 Etap 5. Podtrzymywanie i samodyscyplina 357 System 5S i proces DFTS 358 Ramka 10.1. Od 5S do szczup ego procesu DFTS 359 Prze amywanie oporu 362 Wdra anie 5S 363 Etap 1. Przekonywanie zarz du 363 Etap 2. Szkolenia i wdra anie 364 Etap 3. Powi zanie z systemem nagród 364 Etap 4. Kontynuacja i ci g e usprawnianie 365 Kluczowe zagadnienia 365 Dodatkowe materia y 366 wiczenia internetowe 366 Pytania przegl dowe 366 Zagadnienia do dyskusji i projekty 367 Przypisy 367 ROZDZIA 11. Zrozumienie potrzeb klienta QFD w dziedzinie oprogramowania i g os klienta 369 QFD pocz tki i wprowadzenie 371 Czym wyró nia si QFD w ród innych systemów jako ci? 372 Historia QFD 373 Historia QFD dla oprogramowania 374 Czym jest QFD i do czego s u y? 376 Koncentracja na priorytetach 378 Definicja QFD 379 Rozwini cia QFD 380 Czteroetapowy model QFD 380 Macierz domu jako ci 382 Problemy ze stosowaniem tradycyjnej wersji QFD do oprogramowania 386 Niepowodzenia 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 391 B yskawiczna metoda QFD 391 Siedem narz dzi do zarz dzania i planowania (7 ZP) 391 Zadowolenie klienta i warto 391 B yskawiczny proces QFD 393 Etap 1. Kluczowy cel projektu 393 Etap 2. Kluczowy segment klientów 395 Etap 3. Kluczowe etapy procesu 396 Etap 4. Wizyta w gemba 396 Etap 5. Jakie s potrzeby klienta? 397 Etap 6. Struktura potrzeb klienta 401 Etap 7. Analiza struktury potrzeb klienta 401 Etap 8. Okre lanie priorytetów potrzeb klienta 402 Etap 9. Realizacja priorytetowych potrzeb klientów 403 Pó ne rozwini cia. Szczegó owa analiza (wy cznie) istotnych relacji 405 Dom jako ci i nie tylko 406 Projekty Six Sigma 408 Dzia ania nast pcze stosowanie, ewolucja i usprawnianie procesu 408 B yskawiczne programowanie 408 Rozwini cie harmonogramu za pomoc zarz dzania projektem poprzez a cuch krytyczny 409 Wprowadzanie QFD dla oprogramowania 409 Czynnik ludzki w QFD 410 Wyzwania i pu apki w obszarze QFD 410 Jak wdra a QFD dla oprogramowania? 413 Wnioski 414 Nowoczesna wersja QFD w procesie DFTS 414 Kluczowe zagadnienia 415 Dodatkowe materia y 417 wiczenia internetowe 418 Pytania przegl dowe 419 Zagadnienia do dyskusji 420 Przypisy 421 14 Spis tre ci ROZDZIA 12. Kreatywno i innowacyjno w procesie projektowania oprogramowania TRIZ i metodologia wyboru koncepcji Pugha 427 Potrzeba kreatywno ci w DFTS 429 Kreatywno i TRIZ 429 Ramka 12.1. Czym jest szcz liwy traf? 430 Ramka 12.2. Pionierzy 433 TRIZ w rozwoju oprogramowania 433 Ramka 12.3. Lingua latina non mortua est 434 TRIZ, QFD i metody Taguchiego 442 Burza mózgów 442 Metodologia wyboru koncepcji Pugha 444 Oprogramowanie jako w asno intelektualna 447 Ramka 12.4. Obraz jest wart& 449 Kluczowe zagadnienia 450 Dodatkowe materia y 450 wiczenia internetowe 450 Pytania przegl dowe 451 Zagadnienia do dyskusji i projekty 451 Przypisy 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 455 Zastosowania FMEA na wczesnych etapach 459 Analizy drzewa b dów oprogramowania 462 Przyczyny b dów w oprogramowaniu i ich ród a 465 Okre lanie i ocena ryzyka na poszczególnych etapach DFTS 467 Kluczowe zagadnienia 468 Dodatkowe materia y 469 wiczenia internetowe 469 Pytania przegl dowe 469 Zagadnienia do dyskusji i projekty 469 Przypisy 470 Spis tre ci 15 ROZDZIA 14. Technologie obiektowe i komponentowe oraz inne narz dzia programistyczne 471 G ówne wyzwania w rozwoju biznesowych aplikacji dla przedsi biorstw 473 Analizy, projektowanie i programowanie obiektowe 473 Ramka 14.1. Narodziny programowania obiektowego 474 Ramka 14.2. Zalety warstwy po redniej j zyka Java 479 Technologia rozwoju oprogramowania na podstawie komponentów 481 Poprawa produktywno ci za pomoc programowania ekstremalnego 484 Zwi kszanie niezawodno ci przy u yciu programowania wielowersyjnego 486 Zalety NVP 487 Wady NVP 487 Wspó czesne rodowiska programistyczne 488 Trendy w automatyzacji programowania 492 Kluczowe zagadnienia 495 Dodatkowe materia y 495 wiczenia internetowe 496 Pytania przegl dowe 496 Zagadnienia do dyskusji i projekty 496 Przypisy 496 CZ III PROJEKTOWANIE OPROGRAMOWANIA GODNEGO ZAUFANIA 499 ROZDZIA 15. Miary jako ci i metody statystyczne w rozwoju oprogramowania godnego zaufania 501 Oprogramowanie godne zaufania 503 Inicjatywa Microsoftu na rzecz przetwarzania godnego zaufania 504 Statystyczne sterowanie procesem w rozwoju oprogramowania 507 Metody statystyczne dla architektów oprogramowania 513 Kluczowe zagadnienia 517 Dodatkowe materia y 517 wiczenia internetowe 518 Pytania przegl dowe 518 Zagadnienia do dyskusji i projekty 518 Problemy 518 Przypisy 518 16 Spis tre ci ROZDZIA 16. Solidne oprogramowanie w kontek cie 521 Proces tworzenia specyfikacji oprogramowania 523 Ramka 16.1. Precyzyjne specyfikacje funkcjonalne 525 Czym jest solidne oprogramowanie? 526 Wymagania, jakie musi spe nia solidne oprogramowanie 527 Ramka 16.2. Uzyskiwanie informacji od u ytkownika ko cowego 528 Ocena solidno ci oprogramowania 528 Ramka 16.3. Przyk ad projektowania parametrów 530 Kluczowe zagadnienia 531 Dodatkowe materia y 531 wiczenia internetowe 531 Pytania przegl dowe 532 Zagadnienia do dyskusji i projekty 532 Problemy 532 Przypisy 533 ROZDZIA 17. Metody Taguchiego i optymalizacja pod k tem solidnego oprogramowania 535 Metody Taguchiego w projektowaniu solidnego oprogramowania 537 Przyk ad z dziedziny in ynierii projektu 541 Przyk ad z obszaru projektowania i rozwoju oprogramowania 544 Macierze ortogonalne w eksperymentach Taguchiego nad projektowaniem parametrów 549 Zastosowania w DFTS 552 Kluczowe zagadnienia 552 Dodatkowe materia y 553 wiczenia internetowe 553 Pytania przegl dowe 553 Zagadnienia do dyskusji 553 Problemy 553 Przypisy 554 ROZDZIA 18. Weryfikacja, walidacja, testy i ocena w rozwoju oprogramowania godnego zaufania 555 Ci g dalszy cyklu rozwoju 557 Ramka 18.1. Miejska legenda o oprogramowaniu biznesowym 558 Spis tre ci 17 Weryfikacja 559 Studium przypadku 18.1. Metody Taguchiego w weryfikacji projektu systemu RTOS 559 Walidacja 563 Studium przypadku 18.2. Metody Taguchiego w walidacji oprogramowania 563 Testy i ocena 566 Ramka 18.2. Anomalie z obszaru testów i debugowania 567 Kluczowe zagadnienia 571 Dodatkowe materia y 572 wiczenia internetowe 572 Pytania przegl dowe 573 Zagadnienia do dyskusji i projekty 573 Problemy 573 Przypisy 573 ROZDZIA 19. Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania 575 Ko czenie cyklu rozwoju 577 Integracja 577 Ramka 19.1. Spitfire Supermarine 578 Wzbogacanie 578 Studium przypadku 19.1. Zwi kszanie mo liwo ci elektronicznego systemu do prowadzenia dzia a wojennych 579 Konserwacja 581 Studium przypadku 19.2. Konserwacja systemów oprogramowania u klienta 582 Ramka 19.2. Usuni cie zaawansowanej funkcjonalno ci oprogramowania w wyniku konserwacji 583 Kluczowe zagadnienia 584 Dodatkowe materia y 584 wiczenia internetowe 584 Pytania przegl dowe 585 Zagadnienia do dyskusji i projekty 585 Problemy 585 Przypisy 585 18 Spis tre ci CZ IV CZENIE WSZYSTKICH ELEMENTÓW WDRA ANIE PROGRAMU DFTS 587 ROZDZIA 20. Przygotowanie organizacji do wdra ania DFTS 589 Czas na rozwa ania 591 Studium przypadku 20.1. D enie do doskona ego procesu produkcji 591 Studium przypadku 20.2. Instytucjonalizacja Six Sigma w GE 594 Wyzwania stoj ce przed liderami w trakcie inicjatyw transformacyjnych 598 Ocena kluczowych elementów organizacji 599 Wzbudzanie zaanga owania liderów 600 Zrozumienie roli liderów 601 Ocena strategicznych powi za 602 Zapewnianie zaanga owania ca ej organizacji 602 Zrozumienie konieczno ci koncentracji na kliencie 603 Ocena obecnego poziomu zarz dzania jako ci 604 Kluczowe zagadnienia 605 Dodatkowe materia y 606 wiczenia internetowe 607 Pytania przegl dowe 607 Zagadnienia do dyskusji i projekty 607 Przypisy 608 ROZDZIA 21. Uruchamianie inicjatywy DFTS 609 DFTS i platforma PICS 611 Planowanie 611 Wdra anie 612 Etap 11. Uruchamianie szkole w ca ej organizacji 613 Projektowanie programu szkole dostosowanie i zró nicowanie 614 Szkolenia dla personelu pomocniczego 615 Etap 12. Wdra anie technologii DFTS proces nauki i stosowania 616 Kontrola 621 Etap 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 631 Zabezpieczanie 632 Etap 14. Utrwalanie usprawnie i zysków 632 Etap 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 640 Co dalej? 641 Kluczowe zagadnienia 641 Dodatkowe materia y 643 wiczenia internetowe 644 Pytania przegl dowe 644 Zagadnienia do dyskusji 645 Przypisy 645 CZ V SZE STUDIÓW PRZYPADKU 647 ROZDZIA 22. Koszty jako ci oprogramowania (CoSQ) w Raytheon s Electronic Systems (RES) Group 653 Wprowadzenie 654 Program usprawnie w RES 654 Koszty jako ci oprogramowania 655 Model CoSQ w RES 655 Zbieranie danych CoSQ 656 Zdobyte do wiadczenia i wiedza 656 Wiedza zdobyta w czasie korzystania z modelu CoSQ 656 U ywanie danych CoSQ do zrozumienia wp ywu usprawnie 657 Koszty i zyski z programu CoSQ 660 Instytucjonalizacja kontroli kosztów CoSQ 660 Wnioski ze studium przypadku 660 Przypisy 661 ROZDZIA 23. Zarz dzanie portfelem technologii informatycznych 663 Cz pierwsza. Wyzwanie 665 Pi etapów iteracyjnego procesu 665 Obiektywno , subiektywno i jako 668 Cz druga. Nowe, racjonalne podej cie 669 Etap 1. Projekt 669 Etap 2. Strukturyzacja z o ono ci koncentracja na celach 670 Etap 3. Pomiar 670 Etap 4. Synteza 674 Etap 5. Optymalizacja 676 Ryzyko 679 20 Spis tre ci Rozszerzenia 681 Podsumowanie 682 Przypisy 683 ROZDZIA 24. Definiowanie potrzeb klienta przy rozwoju zupe nie nowego produktu QFD dla nowatorskiego oprogramowania 685 Wprowadzenie 687 Definicja warto ci 687 Dlaczego nie zapyta ? 688 Nowatorskie produkty 689 Definiowanie zupe nie nowych potrzeb 689 Metody okre lania potrzeb klientów 689 Narz dzia 695 Siedem narz dzi do zarz dzania i planowania (7 ZP) w QFD 695 Ramka 24.1. Czym jest teoria ogranicze ? 696 Procesy wnioskowania w TOC 697 Ostatnie kroki 699 Wprowadzanie nowatorskich produktów na rynek 699 Warstwy oporu 700 Wnioski 700 Podzi kowania 700 Literatura cytowana 702 O autorze 704 ROZDZIA 25. Jurajskie QFD integrowanie QFD dla us ug i produktów 705 Profil firmy MD Robotics 707 Dlaczego QFD? 707 Historia QFD 708 Wymagania Kany 709 Spotkanie z triceratopsem na wyspie przygód Universal Studio na Florydzie 711 Schemat QFD 711 Analizy g osu klienta 712 Rozwini cie emocji 715 Rozwini cie cia a 718 Rozwini cie wymaga in ynieryjnych 719 Podsumowanie 720 O autorach 723 Przypisy 723 Spis tre ci 21 ROZDZIA 26. QFD dla projektów. Lepsze zarz dzanie projektami rozwoju oprogramowania dzi ki b yskawicznemu QFD 727 Wprowadzenie 729 Niepowodzenia 729 Cz ciowy sukces 730 Zdefiniowane QFD 730 Dobry pocz tek 730 Problemy w trakcie rozwoju nowych produktów 730 Niespójny rozwój jest niewydajny 731 Spójny rozwój jest wydajny 733 Koncentracja na warto ci w QFD dla projektu 735 Siedem kroków do lepszych projektów 735 Podsumowanie 746 Podzi kowania 746 Literatura cytowana 747 O autorze 749 ROZDZIA 27. QFD 2000. Integrowanie QFD i innych metod zarz dzania jako ci w celu usprawnienia procesu rozwoju nowych produktów 751 Popyt na nowe produkty 753 Jako i rozwój nowych produktów 753 Wspó czesne narz dzia do zarz dzania jako ci 754 Proces rozwoju nowych produktów 757 Materia y dotycz ce QFD i innych metod zarz dzania jako ci 760 Analityczny proces hierarchiczny (AHP) i analityczny proces sieciowy (ANP) 760 Strategiczne karty wyników 761 B yskawiczna QFD 761 Analizy czne (conjoint) 761 Spotkania z klientami 761 Podejmowanie decyzji z udzia em klientów (CIDM) 761 de Bono 761 Deming 761 Wizyty w gemba i analizy g osu klienta 762 Planowanie hoshin 762 Model Kano 762 In ynieria kansei 762 Badania g ównych u ytkowników 763 Szczup a produkcja 763 22 Spis tre ci Nowa strategia Lanchestera 763 Programowanie neurolingwistyczne (NLP) 763 Zarz dzanie projektem 763 Wybór koncepcji metod Pugha 763 QFD (wersja kompleksowa) 764 Niezawodno 764 QFD ród a do potrzeb 764 Siedem narz dzi do zarz dzania i planowania (7ZP) 764 Siedem narz dzi do planowania produktu (7PP) 764 Siedem narz dzi do sterowania jako ci (7SJ) 764 Six Sigma, SPC 765 In ynieria oprogramowania 765 Bramki etapowe 765 Strategiczne systemy informacyjne (SIS) 765 Zarz dzanie a cuchem dostaw 765 Metody Taguchiego 765 Teoria ogranicze (TOC) 765 Zarz dzanie przez jako (TQM) 766 TRIZ 766 In ynieria warto ci 766 O autorze 766 Literatura cytowana 767 S owniczek poj technicznych 769 Skorowidz nazwisk 779 Skorowidz 781 ROZDZIA 2 Wyzwania na drodze do oprogramowania godnego zaufania solidny projekt w 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ówienie Wieloaspektowe 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, jednak nale y uwzgl dni tak e istotne ró nice. Koszty powodowane przez oprogramowanie niskiej jako ci s coraz bardziej kluczowe, poniewa koszt cyklu ycia typowego sys- temu przekracza cen sprz tu. Oprogramowanie wy szej jako ci pozwala istotnie zredukowa te koszty, poniewa 80 90% ich sumy poch ania konserwacja zwi zana z poprawianiem, adaptowaniem i rozwijaniem udost pnionego oprogramowania. Obecnie oko o 40% wydatków na rozwój oprogramowania poch aniaj testy potrzebne w 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 e wynosi 100:1, a nawet jeszcze wi cej. W tym rozdziale opisujemy niepowodzenia tradycyjnych 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 for Trusthworthy Software DFTS) bazuj c na trzech kluczowych elementach: itera- cyjnym modelu rozwoju solidnego oprogramowania, in ynierii optymalizacji projektu oprogramowania i technologii projektowania obiektowego. W DFTS wysi ki nad zapew- nieniem jako ci koncentruj si na wczesnych etapach procesu rozwoju. Technologia ta 67 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 liwia wczesn i ci g analiz ryzyka, optymalizacj projektu i zastosowanie odpowiedniej technologii 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 Model rozwoju solidnego
fakty i mity oprogramowania proces DFTS w praktyce Ograniczenia tradycyjnych systemów
kontroli jako ci Kluczowe zagadnienia
Japo skie systemy zarz dzania jako ci Dodatkowe materia y
i podej cie Taguchiego wiczenia internetowe
Istota metod Taguchiego do tworzenia
Pytania przegl dowe
solidnych projektów Zagadnienia do dyskusji i projekty
Wyzwania na drodze do niezawodno ci
Przypisy
oprogramowania projektowanie oprogramowania godnego zaufania Niezawodno oprogramowania fakty i mity 69 Niezawodno oprogramowania fakty i mity Jako oprogramowania, podobnie jak jako sprz tu, to wieloaspektowe zagadnienie. W rzeczywisto ci spojrzenie na jako z kilku perspektyw jest kluczowe do zrozumienia i utworzenia warto ciowego produktu oraz zaspokojenia zestawu jawnych i ukrytych potrzeb klienta. Producent musi tak e spe ni wymania wielu innych partnerów, takich jak 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 acalne i konkurencyjne, aby mog y spe nia potrzeby w a cicieli przedsi biorstw. Jako obejmuje wszystkie takie potrzeby i wymagania. Cz sto mo na us ysze , e zagadnienia zwi zane z jako ci w wiecie oprogramowania s inne ni w przypadku innych produktów, jednak nie do ko ca jest to prawd . Ogólnie mó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 trzeba zrozumie . Ponadto nale y pozna specyficzne wyzwania wynikaj ce z abstrakcyjnej natury systemów cyfrowych oraz poziomu z o ono ci wielu aplikacji, a tak e wzi pod uwag 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 powodzenia firmy. We wszystkich takich organizacjach te zadania s zbyt wa ne, aby pozostawi je wy cznie in ynierom oprogramowania. Problem produkcji oprogramowania godnego zaufania jest prawdziwym wyzwaniem i wymaga ca kowitego zaanga owania kadry zarz - dzaj cej. W tej ksi ce przedstawiamy podstawy filozoficzne, system zarz dzania oraz technologi do zarz dzania jako ci oprogramowania zarówno w du ych, jak i ma ych firmach, ze szczególnym uwzgl dnieniem oprogramowania dla przedsi biorstw. Podobie stwa i ró nice mi dzy oprogramowaniem i wyrobami produkowanymi Zrozumienie 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 lat mia y tak znacz cy wp yw na popraw jako ci wszelkich dóbr produkowanych, a tak e innych wyrobów i us ug. Trzeba jednak uwzgl dni tak e wa ne ró nice, aby prawid owo rozwin system zarz dzania jako ci oprogramowania. Poni ej opisane s pewne zwi zane z tym tematem zagadnienia: Oprogramowanie i wyroby produkowane ró ni si w zakresie znaczenia ró nych etapów w procesie ich tworzenia (zobacz rysunki 2.1 i 2.2). Rozwój oprogramowania charakteryzuje si centralizacj projektu. Oprogramowanie to przyk ad czystego 70 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania 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ów projektowych, 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 etapie projektowania. W przypadku oprogramowania produkcja w zasadzie nie ma miejsca. Sam kod programu jest po prostu dalszym etapem projektu. Ponadto nie mo na tu powiedzie , e produkt jest wykonany i dostarczony . Zawsze mo na zaprojektowa aplikacj od nowa, zmodyfikowa j lub zaktualizowa , a przez to zmieni . Ta charakterystyczna dla oprogramowania elastyczno cz sto prowadzi do podej cia dostarczmy to teraz b dy zawsze b dziemy mogli poprawi pó niej . W odró nieniu od wyrobów produkowanych, w przypadku oprogramowania nie ma odpowiednika etapu analizy projektu. Wi kszo analiz (testów) trzeba przeprowadza na kodzie programu. Dlatego problemy lub pomy ki projektowe mog pozosta ukryte a do pó nych etapów procesu rozwoju lub nawet do czasu rozpocz 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 pny poziom wyzwania w zakresie projektowania programów. Niezawodno oprogramowania fakty i mity 71 Porównywanie niezawodno ci oprogramowania i sprz tu Zawodno sprz tu wynika g ównie z fizycznych b dów pojedynczych komponentów, co jest cz sto konsekwencj przewrotno ci natury. Z kolei w oprogramowaniu usterki cha- rakteryzuj si nieci g ym dzia aniem systemów cyfrowych. Wiedza o projektowaniu i 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 czne problemy 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 oprogramowania i sprz tu mo e zawie z powodu usterek aplikacji wywo anej za pomoc zewn trznych polece . 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ów jego 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 programu w celu zaspokojenia zmieniaj cych si i rosn cych potrzeb u ytkowników. Oko o 40% ceny rozwoju oprogramowania poch aniaj testy maj ce na celu usuni cie b dów i zapewnienie wysokiej jako ci programu3. Stosunek zawodno ci oprogramowania do sprz tu mo e wynosi a 100:1 w typowych komputerach bazuj cych na obwodach scalonych4. Dla bardziej skomplikowanych chipów ten 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 oprogramowania Zawodno 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ów z 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 72 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania TABELA 2.1. Ró nice i podobie stwa w niezawodno ci sprz tu i oprogramowania6 Niezawodno Kategoria Niezawodno sprz tu 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 defekty albo awarie) Efekty stosowania Funkcja projektu Dziedziny Sprz t zu ywa si i zaczyna zawodzi Oprogramowanie nie zu ywa si , ale zawodzi w wyniku nieznanych Relacje czasowe defektów lub b dów Modele matematyczne Fizyka b du Umiej tno ci programisty Czas (t) Czas i dane Obszar czasu Krzywa wannowa Funkcja malej ca Dobrze rozwini ta teoretycznie Dobrze rozwini ta teoretycznie, i akceptowana ale o niskiej akceptacji Funkcje R = f( , t), = intensywno b dów R = f(b dy [lub defekty albo Wyk adnicza (sta a ) awarie], t) Weibulla (rosn ca ) Obszar danych Bez znaczenia Brak zgodno ci mi dzy ró nymi proponowanymi modelami funkcji czasu B dy = f(testy na danych) Modele wzrostu Istnieje kilka modeli Istnieje kilka modeli Miary , MTBF (ang. mean time between Intensywno b dów, liczba failures, czyli redni czas pomi dzy wykrytych lub pozosta ych awariami) defektów (lub awarii) MTTF (ang. mean time to failure, czyli redni czas do wyst pienia awarii) 6 Przedruk za pozwoleniem z W. Kuo, V. Rajendra Prasad, F. A. Tillman i Ching-Lai Wang. Optimal Reliability Design. Cambridge University Press, Cambridge, 2001, punkt 13.5.1, s. 4. Niezawodno oprogramowania fakty i mity 73 TABELA 2.1. Ró nice i podobie stwa w niezawodno ci sprz tu i oprogramowania ci g dalszy Niezawodno Kategoria Niezawodno sprz tu oprogramowania Techniki wzrostu Projektowanie, przewidywanie Przewidywanie Techniki przewidywania Diagramy blokowe, drzewa b dów Analiza cie ek (analiza wszystkich cie ek to nierozwi zywalny problem, poniewa liczba mo liwo ci w nawet prostych programach mo e zmierza do niesko czono ci), z o ono , symulacje Testy i ewaluacja Akceptacja projektu i produkcji Akceptacja projektu Projekt MIL-STD-781C (wyk adnicze) Testowanie cie ek, symulacje, b dy, posiew Bayesa Inne metody (niewyk adnicze) Operacje MIL-STD-781C Brak Zastosowanie nadmiaru Równoleg o Mo e poprawia niezawodno Trzeba rozwa y najcz stsze przyczyny Rezerwa Automatyczne wykrywanie Automatyczne wykrywanie i poprawianie b dów, automatyczne i poprawianie b dów, automatyczne wykrywanie usterek i prze czanie kontrolowanie i ponowne inicjowanie 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 Deming zrewidowa 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 wymagania u 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 zinterpretowa ich jawne i niejawne wymagania. Niestety, udzia u ytkowników w rozwoju oprogramowania 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 rozwoju oprogramowania. Jest to istotna przyczyna problemów z jako ci oprogramowania i trzeba temu po wi ci nale yt uwag . Rosn ca z o ono . Systemy oprogramowania s tworzone do obs ugi problemów o rosn cej z o ono ci. Cz sto nie ma r cznych rozwi za , które mog yby pomóc w zrozumieniu natury istniej cych trudno ci. Oprogramowanie umo liwia 74 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania projektantowi zmierzenie si z ogromnymi trudno ciami i udost pnienie dodatkowych funkcji oraz udogodnie , które nie zawsze zwi kszaj prawdziw warto programu. Z o one systemy oprogramowania u ywane do automatycznej kontroli lotu, w silnikach do masowego wyszukiwania, w handlu elektronicznym czy 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 projektowych i poznawczych, z czego wynikaj wyzwania w rozwoju oprogramowania w obszarze niezawodno ci, bezpiecze stwa i zabezpiecze . Brak uzgodnionych kryteriów. W nowych i z o onych systemach programista cz sto tworzy kryteria niezawodno ci, które nie zawsze spe niaj wymagania u ytkowników. Presja czasu zwi zana z konkurencyjno ci . Konkurencyjna potrzeba skracania czasu cyklu rozwoju ( mo emy to pó niej naprawi , ale dostarczy musimy na czas ) w niemal nieunikniony sposób prowadzi do b dów w projekcie i na innych etapach. Bardzo cz sto po prostu brakuje czasu na wyczerpuj ce testy i usuwanie b dów. Ograniczony zakres automatyzacji. Rozwój i stosowanie oprogramowania to operacje w du ym stopniu bazuj ce na czynniku ludzkim. Narz dzia do automatyzacji, takie jak CASE i projektowanie obiektowe, s na pewno pomocne, ale zakres automatyzacji w oprogramowaniu jest ograniczony w porównaniu do wyrobów produkowanych. Powi zanie z Internetem. Coraz szersze zastosowania i integracja systemów oprogramowania z Internetem nara a je na zagro enia wynikaj ce z przypadku lub 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 enie narodowego systemu bezpiecze stwa. Abstrakcyjne dzia anie systemów cyfrowych. Naturalnie abstrakcyjne dzia anie systemów cyfrowych sprawia, e trudno zapewni jako oprogramowania. Brak odpowiednich zach t. Cz sto bod ce rynkowe i regulacyjne w zakresie niezawodno ci oprogramowania s niewystarczaj ce, podczas gdy istnieje wiele czynników promuj cych innowacyjne funkcje, wygod stosowania i b yskawiczny cykl rozwoju. Ograniczenia tradycyjnych systemów kontroli jako ci Praktyki zapewniania jako ci zwykle koncentruj si na pó nych operacjach, takich jak produkcja lub testy (zobacz rysunki 2.1 i 2.2). Takie podej cie nie zawsze prowadzi do optymalnego 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. Bardzo cz 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óch podstawowych za o eniach: Wymagania klientów s spe nione, je li produkt znajduje si w ramach uzgodnionych ogranicze wyznaczanych przez specyfikacj . Biznesowe skutki wydajno ci lub jako ci produktów ledwo spe niaj cych wymagania 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ów systemów jako ci zale nych od kontroli. Jednak to japo ski in ynier przemys owy Genichi Taguchi jako pierwszy zaproponowa alternatywny system zarz dzania jako ci , nazywany metodami 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, na etapach 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 zarz dzania jako ci i podej cie Taguchiego Metody 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, metodami Taguchiego od nazwiska autora tego podej cia, dr. Genichiego Taguchiego (zobacz ramki 2.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 bie w Wydziale Astronomicznym Instytutu Nawigacji Japo skiej Marynarki Wojennej w latach 1942 1945 pracowa w Ministerstwie Zdrowia i Opieki oraz Instytucie Statystycznym Ministerstwa 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 Zdrowia i Opieki. Doprowadzi o to do jego zaanga owania jako konsultanta w firmie Morinaga Pharmaceuticals i jej organizacji nadrz dnej, Morinaga Seika. 76 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania 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 u bada 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 innymi Toyota i jej dostawcy, zacz y, pocz wszy od wczesnych lat 50., szeroko stosowa metody Taguchiego. Pierwsza ksi ka Taguchiego, która przedstawia a tablice ortogonalne, zosta a opublikowana w 1951 roku. W latach 1954 55 Taguchi pracowa jako profesor zaproszony w Indyjskim Instytucie Statystycznym 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 na Uniwersytecie Princeton. W tym czasie odwiedzi AT&T Bell Laboratories. W Princeton Taguchi by go ciem powa anego statystyka Johna Tukeya, który u atwi mu wspó prac ze statystykami 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 przez Yuin Wu, wspó pracownika Taguchiego przy wielu pó niejszych pracach. Na tym etapie metody Taguchiego by y praktycznie nieznane na Zachodzie, cho stosowano je w Tajwanie i 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 pozycje ksi 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 , przeprowadzi udane eksperymenty, które pozwoli y zastosowa metody Taguchiego w korporacji Bell Laboratories. Po wizycie Taguchiego w Stanach Zjednoczonych w 1980 roku coraz wi cej ameryka skich fabryk zacz o stosowa jego metodologi . Mimo niech tnego przyj cia tych metod przez grono ameryka skich statystyków, co prawdopodobnie wynika o ze sposobu ich rozpowszechniania, 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 ad w 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 statystycznych do osi gni cia b yskawicznych korzy ci w zakresie kosztów i jako ci poprzez optymalizacj procesu projektowania i produkcji wyrobów; Japo skie systemy zarz dzania jako ci i podej cie Taguchiego 77 medal imienia Shewharta Ameryka skiego Stowarzyszenia na rzecz Kontroli Jako ci; Niebiesk Wst g cesarza Japonii, przyznan w 1990 roku za wk ad w rozwój przemys 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 aw z 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 metodologia zarz dzania jako ci stosowana we wczesnych fazach rozwoju produktu lub procesu, która w mniejszym stopniu koncentruje si na osi ganiu jako ci poprzez kontrol . Jest to wydajna technika, 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ów i 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 ciej stosowane 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 jest postrzegana 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 przetwarzania i utylizacji, wydatki na konserwacj oraz przestoje wynikaj ce z awarii sprz tu i napraw gwarancyjnych. Nale y uwzgl dni tak e koszty klientów powodowane przez zawodno oraz nisk wydajno produktu, prowadz ce do dalszych strat po stronie producenta w cznie ze spadkiem 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 du jest niskie, droga wyboista, a operator terminala nieprzeszkolony. Produkt musi dzia a na docelowym 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 interesie producenta 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 decyzji projektowych w kategoriach finansowych. Pomaga zdecydowa , czy dodatkowe koszty zwi k- szenia odporno ci i usprawnienia produkcji s usprawiedliwione oraz czy oka si zasadne w warunkach rynkowych. 78 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania Metod Taguchiego mo na u ywa w trybie offline w czasie projektowania lub na bie co w produkcji. Taguchi dzieli kontrol jako ci w trybie offline na trzy etapy. 1. Projektowanie systemu obejmuje tworzenie pomys u na projekt przy u yciu burzy mózgów, bada lub innych technik. Projektowanie systemu jako ca o ci obejmuje tak e inne narz dzia, techniki i metodologie, zw aszcza AHP (ang. Analytic Hierarchy Process), QFD (ang. Quality Function Deployment), TRIZ (ang. Theory of Inventive Problem Solving) i FMEA (ang. Failure Modes and Effects Analysis), opisane odpowiednio w rozdzia ach 8., 11., 12. i 13. 2. Projektowanie parametrów to istota metod Taguchiego. To pod tym wzgl dem Japo czycy tradycyjnie si wyró niali i osi gali wysokie poziomy jako ci bez wzrostu kosztów, co jest g ówn przyczyn ich przewagi konkurencyjnej. Testowane s nominalne w a ciwo ci projektu lub wybrane poziomy czynników procesu. Ustalane s kombinacje poziomów parametrów produktu lub poziomów operacji wchodz cych w sk ad procesu, które okaza y si najmniej wra liwe na zmiany w czynnikach rodowiskowych i inne niekontrolowalne elementy (szum). To zagadnienie opisujemy w 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 jest niewystarczaj ce. Ta faza dodatkowo zwi ksza odporno na czynniki maj ce du y wp yw na wariancj . Nale y zastosowa funkcj straty i po wi ci wi cej rodków tylko wtedy, je li jest to konieczne. Mo na zwi kszy odporno albo kupi lepsze materia 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, cho by naj ci lejszej, procesu produkcji. Projektuj produkty tak, aby nie zawodzi y w praktyce. Tym samym zmniejszysz liczb defektów w fabryce. Udost pniaj c produkt, który ledwie spe nia standardy korporacji, producent nie zyskuje prawie nic w porównaniu z rozpowszechnianiem wadliwego wyrobu. Nale y d y do poziomu docelowego, a nie jedynie mie ci si w ramach specyfikacji. In ynieria jako ci (metody Taguchiego) to technologia przewidywania b dów jako ciowych i zapobiegania im na wczesnych etapach rozwoju i projektowania produktu, w cznie z problemami zwi zanymi z funkcjami produktu, zanieczyszczeniem rodowiska i innymi kosztami, które pojawiaj si w pó nych fazach produkcji oraz po wypuszczeniu wyrobu na rynek. Nie u ywaj miar jako ci zwi zanych z klientem (takich jak procent defektów czy niezawodno ) jako wczesnych miar jako ci w dziale bada i rozwoju. W zamian Japo skie systemy zarz dzania jako ci i podej cie Taguchiego 79 u ywaj dynamicznego stosunku SN jako wska nika wydajno ci do oceny solidno ci funkcji produktu. Solidne produkty zapewniaj silny sygna niezale nie od zewn trznego szumu i z minimaln ilo ci szumów wewn trznych. Usprawnienie projektu, czyli znacz 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 produkowa na 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 bie specyfikacji ni sta ego odchylenia poza ni . Je li odst pstwo od poziomu docelowego jest sta e, mo liwe jest dostosowanie procesu do tego poziomu. Warunki panuj ce w fabryce rzadko s tak szkodliwe, jak zmienno w u ytkowaniu produktów przez u ytkowników. Metody Taguchiego zosta y uznane za jedno z najwa niejszych in ynieryjnych osi gni XX wieku. Cho techniki statystyczne u ywane przez Taguchiego maj pocz tki w eksperymentalnych praktykach projektowych rozwini tych przez angielskiego staty- styka sir Ronalda Fishera, ich filozoficzne podstawy s niezaprzeczalnie japo skie. Metody Taguchiego 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. Edwardsa Deminga, przedstawionymi w jego ksi kach: 14 Points of Management, Seven Deadly Dise- ases i Obstacles to Quality Products. Proponowana przez Richarda Zultnera adaptacja zasad Deminga do rozwoju oprogramowania jest opisana w rozdziale 5. Metody Taguchiego i inne systemy zarz dzania jako ci po o y y podwaliny pod niezwyk y rozwój Japonii jako pot gi przemys owej po II wojnie wiatowej. Trudno przeceni wp yw Deminga na prace Taguchiego. Podobnie jak inni japo scy specjali ci do spraw jako ci, Taguchi by pod du ym wp ywem Deminga. Aby zrozumie specyficzne podej cie Taguchiego, nale y przeanalizowa jego kontekst i korzenie. Metody Taguchiego i wspó czesne japo skie systemy zarz dzania jako ci mia y swe pocz tki po II wojnie wiatowej. Deming, którego cz sto okre la si mianem ojca wspó czesnego ruchu na 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 ce japo 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, zmniejszanie wariancji, stosowanie wska ników statystycznych, zyskiwanie zaufania i szacunku 80 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania Ramka 2.4. Istota 14 punktów Deminga11 1. B d wierny zamiarom usprawniania produktów i us ug. Cel to osi gni cie konkurencyjno ci, pozostanie w grze i zapewnienie miejsc pracy. 2. Zarz d musi zda sobie spraw z wyzwa zwi zanych z jako ci , pozna zakres odpowiedzialno ci i przej przywództwo na drodze zmian. 3. Nale y przesta uwa a kontrol za najwa niejszy element osi gania jako ci. Trzeba wyeliminowa potrzeb masowych inspekcji poprzez wbudowanie jako ci w produkt. 4. Trzeba sko czy z nagradzaniem dzia a na podstawie ceny. W zamian nale y minimalizowa koszty czne. Ka dy produkt powinien by dostarczany przez tylko jednego 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 dzy przywództwem i nadzorem. Ten drugi bazuje na normach i poziomach. Celem nadzoru powinno by pomaganie ludziom, maszynom i urz dzeniom w lepszym wykonywaniu zada . Nadzór zarz du wymaga starannego przemy lenia, podobnie jak 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 przewidywa problemy 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 ci i wydajno ci le y po stronie systemu i tym samym znajduje si poza kontrol si y roboczej. 11a. Nale y wyeliminowa standardy pracy (normy) dla fabryki. Trzeba zast pi je przywództwem. 11b. Trzeba wyeliminowa zarz dzanie przez zadania oraz liczby (z celami numerycznymi) i zast pi je przywództwem. 12a. Nale y usun przeszkody, które pozbawiaj pracowników zatrudnianych na godziny prawa do dumy z pracy. Pracownicy nadzoru powinni odpowiada nie za same liczby, ale za jako . 12b. Trzeba usun bariery, które pozbawiaj zarz d i in ynierów prawa do dumy z pracy. Oznacza to mi dzy innymi rezygnacj z dorocznych rankingów wydajno 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. Japo skie systemy zarz dzania jako ci i podej cie Taguchiego 81 wspó pracowników oraz ci g e usprawnianie w obszarze procesów, a tak e produktów i us ug. W Japonii podej cie Deminga by o z entuzjazmem studiowane i stosowane oraz mia o znacz cy wp yw na przemys tego kraju. W 1951 roku Japo skie Stowarzyszenie Naukowcó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 nacisk na 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 82 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania 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 ówne nakazy 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 tak zwane statystyczne projektowanie eksperymentów (ang. Statistical Design of Experiments SDE) lub po prostu projektowanie eksperymentów (ang. Design of Experiments DOE). Dlatego jako mo na wbudowa w produkt i proces. 4. Straty klienta wynikaj ce z niskiej jako ci s mniej wi cej proporcjonalne do kwadratu odchylenia cech wydajno ci od poziomu docelowego (warto ci nominalnej). Taguchi zmieni cele eksperymentów i definicj jako ci z osi gania zgodno 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 c nieliniowy 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 procesu poprzez wykrycie kontrolowalnych czynników i ich warto ci, co minimalizuje zmienno w stosunku do wyniku docelowego. Ustawiaj c kontrolowalne parametry na ich optymalny poziom, mo na sprawi , e produkt b dzie bardziej odporny na zmiany w dzia aniu, sto- sowaniu i warunkach rodowiskowych. Podstawowa zasada metod Taguchiego dotyczy raczej 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 liwym kosztem. 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 koszty i szybsza. Metody Taguchiego maj dwa kluczowe cele projektowe: Istota metod solidnego projektowania Taguchiego 83 zmniejszenie i minimalizacj zmienno ci produktu i ekonomiczne osi gni cie poziomu docelowego, zapewnienie tolerancji mierzonej na etapach tworzenia projektu i prototypu, które jest przenoszone na dalsze fazy w produkcji i rodowisku u ytkownika. Istota metod solidnego projektowania Taguchiego Solidno to kluczowy koncept metod Taguchiego. Solidno oznacza zdrowie, moc, energi i si . Taguchi definiuje j jako stan, w którym dzia anie technologii, produktu lub 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 niania wymaga klientów (ze wzgl du na niezawodno , bezpiecze stwo, zabezpieczenia i tak dalej), 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 wszelkich szkodliwych wp ywów, zwanych szumem. Szum wynika z wszelkiego rodzaju zmienno ci: rodowiskowej wariancji w trakcie stosowania produktu przez klienta, zmienno ci w czasie produkcji poszczególnych jednostek i komponentów oraz zró nicowania komponentów w wyniku starzenia si i pogarszania cech. Zagadnienie stosunku sygna u do szumu Wed ug Taguchiego na solidno trzeba zwróci uwag na etapie projektowania lub w dziale bada i rozwoju. Wi e si to ze specyficznym filozoficznym za o eniem, e prawdziw 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 dziale bada 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 Taguchiego zapewniaj 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 metodach Taguchiego. Sygna to co , co produkt (lub cz albo podzespó ) ma dostarcza , zgodnie z jego charakterystyk dzia ania lub funkcjonaln . W odbiorniku telewizyjnym lub telefonie sygna 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 trznych interferencji elektromagnetycznych w odbiorniku telewizyjnym lub telefonie). 84 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania Szum to wszystkie czynniki, które powoduj wariancj . Taguchi stwierdzi , e wielu czynnikó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 kontrolowa lub 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 czynniki zewn trzne ( rodowiskowe), takie jak interferencje cieplne lub elektromechaniczne, szoki mechaniczne i elektryczne, kurz czy nieprawid owe korzystanie ze sprz tu przez 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 trznym pogarszaniem 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 wynika ze zmienno ci w zakresie materia ów i procesów. Szumy powoduj , e produkty dzia aj niezgodnie ze specyfikacj lub ca kowicie zawodz . Dzia anie produktu jest zdominowane przez szum jednostkowy (wewn trzny) na wczesnych etapach cyklu ycia produktu, zewn trzny w trakcie stosowania i pogarszanie sprawno ci (mi dzy produktami) pod koniec ycia. Solidno i solidne projektowanie prowadz 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 ich efekty. 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 ywanie oraz 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 reprezentuje funkcjonalno ; 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 la mianem przetwarzalno ci (w energi , moc, informacj , obraz, dat i tak dalej). Istota metod solidnego projektowania Taguchiego 85 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 czy generatory, mo na opisa w poni szy sposób: W przypadku oprogramowania jest to przekszta canie informacji, danych, obrazów i innych elementów, a nie energii czy mocy. Solidne projektowanie zarówno w dziedzinie oprogramowania, jak i sprz tu, ma maksymalizowa stosunek SN pod k tem optymali- zacji projektu. Zagadnienie funkcji utraty jako ci Jak ju wspomnieli my, to zagadnienie jest podstawowym odst pstwem od zachodniego podej cia do jako ci. Taguchi zajmuje si bardziej utrat jako ci ni ni sam , a tak e skutkami takich strat dla klienta, producenta i spo eczno ci jako ogó u. Jasno wynika z 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 ci w czasie trwania cyklu ycia produktu, a w ostatecznym rozrachunku istotna jest opty- malizacja kosztów tego cyklu. Klienci coraz bardziej domagaj si bezb dnych dostaw i 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 ci zarówno producentowi, jak i klientom. Jest to jedna z podstawowych zasad metodologii Taguchiego. 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. 86 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania Utrata jako ci jest definiowana jako strata, któr produkt powoduje w spo eczno ci od 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 roszczeniami gwarancyjnymi. 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 ów w 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 funkcja s 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 warte poniesienia z perspektywy rynku. Z punktu widzenia producenta czne koszty mo na wyrazi 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 straty w wyniku zwrotów, gwarancji i napraw, a tak e utraty dobrej opinii, co prowadzi do zmniejszenia udzia ów w rynku. Utrata Jako ci mo e by bardzo du a nawet wtedy, kiedy produkt jest zgodny ze specyfikacj . Ta warto jest równa zeru tylko wtedy, kiedy produkt dzia a dok adnie na poziomie docelowym. Taguchi proponuje przybli ony i atwy wzór na funkcj utraty jako ci (ang. quality loss 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 cych kosztów wraz z odchylaniem si dzia ania produktu od poziomu docelowego. Trudno utworzy ogólny i dok adny model kosztów. Jedn z przyczyn tej trudno ci jest to, e produkt 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 wersja przybli enia funkcji QLF jest warto ciowa z nast puj cych wzgl dów. Istota metod solidnego projektowania Taguchiego 87 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 tolerancji i jako ci. Stanowi wydajny pod wzgl dem czasu i kosztów proces szacowania optymalnego projektu. Inaczej mówi c, proces projektowania lepszego produktu jest ta szy i szybszy ni w przypadku tradycyjnego projektowania eksperymentów czy innych metod. QLF i stosunek SN to dwie miary jako ci w metodach Taguchiego. Oba te wska niki k 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 projektowania Taguchi 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 mudne i kosztowne zadanie. Taguchi zaprojektowa tablice ortogonalne w celu wyizolowania czynników zak ócaj cych spo ród innych w sposób wydajny ze wzgl du na czas i koszty. Zastosowanie tej techniki do rozwoju oprogramowania jest opisane w rozdziale 17. Maksymalizacja miar wydajno ci i stosunku SN w celu optymalizacji projektu z uwzgl dnieniem czynników kontrolnych. Solidne projektowanie za pomoc metod Taguchiego przebiega w trzech nast puj cych etapach: 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 ci produktu lub procesu w zakresie wydajno ci na ród a wariancji, a nie poprzez prób kontroli lub eliminacji tych czynników. Na tym etapie odbywaj si testy nominalnych funkcji projektu lub wybranych poziomów czynników procesu oraz po czenia poziomów parametrów produktu lub poziomów operacyjnych procesu, 88 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania które s najmniej wra liwe na zmiany w warunkach rodowiskowych i inne niekontrolowalne czynniki (szum). Jest to istota metod Taguchiego w zakresie solidnego projektowania. Projektowanie tolerancji, które, je li to konieczne, s u y dalszemu zmniejszaniu zmienno ci poprzez zwi kszenie odporno ci na czynniki maj ce du y wp yw na wariancj . Na tym etapie stosowana jest funkcja utraty jako ci w celu sprawdzenia, czy koszt poprawy jako ci jest uzasadniony ekonomicznie. Inwestycje w zwi kszenie tolerancji poprzez zastosowanie lepszych materia ów i sprz tu nale y wprowadza 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 przystosowania do 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 zaufania Oprogramowanie to najbardziej zdradliwy komponent ka dego systemu informatycznego. Dwa pozosta e elementy, sprz t i sieci komunikacyjne, uzyska y przez ostatnie 50 lat du o wy szy poziom wydajno ci i niezawodno ci. Na przyk ad wydajno mikroprocesorów wzros 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 ci i zawodno ci systemów informacyjnych. Nawet mimo niezwyk ego poziomu wydajno ci sprz 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., jednak w tym miejscu warto omówi kilka podstawowych zagadnie . Najbardziej fundamentalne z 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 wymieniana jest 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 to bliskie u ywanemu w tej ksi ce poj ciu oprogramowania godnego zaufania, które jednak obejmuje 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 lub procesy spe niaj , po pierwsze, jawne, niejawne i nieoczekiwane potrzeby lub oczekiwania klientów i u ytkowników oraz, po drugie, okre lone i ukryte wymagania innych partnerów. Projektowanie pod k tem Six Sigma System projektowania i rozwoju nowych produktów, procesów i us ug, które spe niaj wymagania klientów i s pozbawione defektów. Projektowanie oprogramowania godnego System projektowania i rozwoju oprogramowania, zaufania (DFTS) 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 pozwala reagowa na klienta na ró nych etapach cyklu ycia oprogramowania. Solidna architektura (nazywana tak e modelem Model rozwoju oprogramowania s u cy do rozwoju solidnego oprogramowania RSDM) tworzenia oprogramowania godnego zaufania (zobacz rysunek 2.6). Solidne projektowanie Metodologia utworzona przez Genichiego Taguchiego w celu rozwoju najni szym mo liwym kosztem produktów i procesów dzia aj cych na poziomie docelowym zgodnie z wymaganiami klienta, mimo obecno ci czynników, które powoduj zmienno w rodowisku u ytkownika i produkcyjnym. Six Sigma Filozofia, system zarz dzania i metodologia stosowane w celu usprawniania istniej cych produktów, procesów i us ug tak, aby by y pozbawione b dów i spe nia y wymagania klientów w ekonomiczny sposób. Oprogramowanie Programy komputerowe, procedury i (zwykle) zwi zane z nimi dokumentacja oraz dane dotycz ce dzia ania systemu komputerowego. Dost pno oprogramowania Mo liwo udost pniania przez oprogramowanie okre lonych funkcji, kiedy u ytkownik ich potrzebuje. Wiarygodno oprogramowania Stopie , w jakim systemy, komponenty lub procesy producenta oprogramowania potrafi spe nia okre lone wymagania oraz potrzeby i oczekiwania u ytkowników. 90 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania TABELA 2.2. Wybrane atrybuty zwi zane z jako ci oprogramowania ci g dalszy Jako oraz atrybuty i systemy jako ci Opis Solidno oprogramowania Obejmuje, w ród innych atrybutów, niezawodno , bezpiecze stwo, zabezpieczenia i dost pno . Projekt oprogramowania Architektura i kod programu wykonuj cego okre lon funkcj . Mo liwo konserwacji oprogramowania atwo modyfikowania systemów lub komponentów oprogramowania po ich udost pnieniu w celu naprawy b dów, poprawy dzia ania i innych cech lub zaadaptowania do 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 zestaw atrybutów potrzebnych do spe niania jawnych lub ukrytych potrzeb klienta i zapewnia jego zadowolenie. Prawid owe dzia anie programu jest niezb dne, ale niewystarczaj ce, je li oprogramowanie nie zapewnia satysfakcji klienta. Atrybuty jako ci oprogramowania Ró ne wymagania dotycz ce oprogramowania, takie jak niezawodno , bezpiecze stwo, zabezpieczenia i dost pno , potrzebne do spe nienia okre lonych lub ukrytych potrzeb. Niezawodno oprogramowania To poj cie jest zwi zane z jako ci projektu oprogramowania. Wi e si raczej z wykrywaniem b dów ni ich naprawianiem. Jest to mo liwo wykonywania okre lonej funkcji przez system lub komponent oprogramowania w okre lonych warunkach i czasie. Bezpiecze stwo oprogramowania Brak czynników, które mog spowodowa mier , obra enia, chorob , uszkodzenia, brak kontroli lub dost pu do danych, naruszenie prywatno ci lub szkody w sprz cie, mieniu i rodowisku. Skalowalno oprogramowania Mo liwo uruchomienia aplikacji komputerowej na wi kszej maszynie lub procesorach równoleg ych w celu obs ugi wi kszej liczby transakcji lub zapewnienie wy szej przepustowo ci tak, aby wydajno skalowa a si liniowo lub prawie liniowo pod wzgl dem ilo ci operacji. Oznacza to, e je li aplikacja potrafi obs ugiwa okre lon liczb transakcji na danym serwerze, powinna skalowa si tak, aby obs ugiwa a cztery razy wi ksz ich liczb na czterokrotnie wi kszym serwerze. Wyzwania na drodze do niezawodno ci oprogramowania 91 TABELA 2.2. Wybrane atrybuty zwi zane z jako ci oprogramowania ci g dalszy Jako oraz atrybuty i systemy jako ci Opis Zabezpieczenia oprogramowania Cechy oprogramowania dotycz ce jego odporno ci na atak i zapewniaj ce ochron poufno ci, integralno ci danych oraz dost pno ci systemu. Szybko realizacji transakcji przez Tempo obs ugi transakcji przez aplikacj na danym oprogramowanie komputerze, zwykle mierzone w tysi cach transakcji na minut . Mo liwo aktualizowania oprogramowania Mo liwo atwej zmiany konfiguracji oprogramowania w celu obs ugi wi kszej liczby, wi kszych lub bardziej skomplikowanych transakcji. Przetwarzanie godne zaufania System sk adaj cy si ze sprz tu, oprogramowania i sieci, 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óry umo liwia reagowanie na klienta na ró nych etapach cyklu 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 na ró 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 oprogramowanie oczekiwanych funkcji w okre lonych warunkach i czasie. Jest to jako zwi zana z projektem oprogramowania i dotyczy raczej wykrywania b dów ni ich naprawiania. Bezpiecze stwa, 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 zapewnia ochron poufno ci i integralno ci danych oraz dost pu do systemu. 92 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania RYSUNEK 2.6. Model rozwoju solidnego oprogramowania Mo liwo ci konserwacji, która dotyczy atwo ci modyfikowania systemów lub komponentów oprogramowania po ich udost pnieniu w celu naprawy b dów, poprawy dzia ania lub innych cech albo adaptacji produktu do zmieniaj cego si rodowiska. Reagowania na klienta, czyli mo liwo ci producenta zwi zanych z uzyskiwaniem i interpretowaniem wymaga klienta oraz reagowaniem na nie. Wymaga to tak e Wyzwania na drodze do niezawodno ci oprogramowania 93 obecno ci odpowiednich cech solidnego projektu oprogramowania, mo liwo ci prowadzenia szkole i przekazywania wiedzy, umiej tno ci pomocy w integracji istniej cych systemów, udost pniania pomocy technicznej po wdro eniu, mo liwo ci udost pniania zaktualizowanego oprogramowania i systemów oraz spe niania wymaga klientów w zakresie kosztów i harmonogramu dostarczania produktów. Szczególnie istotna jest mo liwo zdobywania zaufania klientów i spe nianie ich jawnych, niejawnych, a nawet nieoczekiwanych potrzeb. S to g ówne aspekty oprogramowania godnego zaufania, które jednak s potrzebne w 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 oprogramowania dla przedsi biorstw. Wa ne jest tu, aby twórca oprogramowania zna i uwzgl dnia g os klienta (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 znaczeniu czynnika 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 zaufania i niezawodne oprogramowanie, a w zasadzie dowolny produkt i ka da us uga, mog by udost pniane tylko przez osoby godne zaufania. Tego zwrotu u yto tak e w programie przetwarzania godnego zaufania (ang. Trushworthy Computing TWC) Microsoftu uruchomionym w 2002 roku. Prezes Microsoftu, Bill Gates, w prze omowych powiado- mieniach przes anych w styczniu i lipcu 200215 do 50000 pracowników korporacji na ca ym wiecie napisa : W przesz o ci starali my si , aby nasze oprogramowanie i us ugi by y atrakcyjne dla klientów ze wzgl du na nowe funkcje i przez mo liwo bogatego rozszerzania 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 ufa naszym produktom. Dlatego teraz w sytuacji wyboru mi dzy nowymi funkcjami i rozwi - zywaniem problemu z zabezpieczeniami musimy stawia na zabezpieczenia . Gates ponadto napisa , e wierzy, i TWC b dzie najwy szym priorytetem dla firmy i przemys u przez nast pn dekad celem jest utworzenie dla klientów rodowiska przetwarzania godnego zaufania, które jest równie niezawodne, co elektryczno zasilaj ca obecnie nasze domy i 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, agencjami odpowiedzialnymi za regulacje i instytutami badawczymi na ca ym wiecie. Proponowana w tej ksi ce metodologia DFTS zapewnia spójn struktur i technologi do rozwi zy- wania tego typu problemów z jako ci . 94 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania Model rozwoju solidnego oprogramowania proces DFTS w praktyce Oprogramowanie w porównaniu z innymi produktami tworzonymi za pomoc in ynierii to przyk ad czystego projektu. Jak ju wspomnieli my, zawodno oprogramowania to zawsze wynik b dów w projekcie i intelektualnych braków cz owieka16. Dlatego jeszcze bardziej istotny jest w tym przypadku moment, w którym rozwi zywane s problemy z 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 zidentyfikowa optymalne funkcje i ustawienia solidnego (godnego zaufania) oprogramowania. Omówione wcze niej elementy systemu s przedstawione w proponowanym przez nas modelu rozwoju solidnego 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 cymi kluczowymi elementami: Infrastruktur zapewniaj c organizacji konieczne przywództwo i system komunikacji, szkole oraz nagród, który wyra nie wspiera proces DFTS (zobacz rozdzia 5.). Niezawodnym systemem zbierania danych, który pozwala prawid owo wykrywa wymagania u ytkowników (VOC) w iteracyjny sposób na ró nych etapach cyklu rozwoju oprogramowania (zobacz rozdzia 11.). Wdra aniem metod Taguchiego w celu optymalizacji projektowania oprogramowania i jednocze nie uwzgl dniania ró nych wymaga klienta, takich jak niezawodno , koszty i czas trwania cyklu (zobacz rozdzia y 16. i 17.). Ustanowieniem praktyki jednoczesnego pisania kodu i przeprowadzania testów oraz zapewniania wystarczaj cego czasu na usuwanie b dów. Ta strategia prowadzi do procesu debugowania wydajnego ze wzgl du na koszty i czas, poniewa informacje o nat eniu lub cz stotliwo ci b dów oprogramowania s wtedy szybciej dost pne (zobacz rozdzia 18.). Tworzeniem wielu wersji programu17 w sytuacji, kiedy potrzebne jest nadmiarowe oprogramowanie. Sprawia to, e statystycznie awarie nadmiarowych kopii s tak niezale ne, jak to mo liwe. W tym celu w ró nych programach nale y stosowa odmienne j zyki programowania, narz dzia programistyczne, technologie rozwoju i strategie testowania (zobacz rozdzia 14.). Wdra aniem odpowiednich narz dzi do zarz dzania jako ci i planowania, takich jak QFD, TRIZ, Pugh i FMEA, które s szeroko stosowane w produkcji, co jest zgodne z najlepszymi praktykami (zobacz odpowiednio rozdzia y 11., 12. i 13.). Kluczowe zagadnienia 95 Stosowaniem innowacyjnych narz dzi do rozwoju oprogramowania, takich jak projektowanie obiektowe (ang. Object-Oriented Design OOD), programowanie ekstremalne 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 cioleciach wyewoluowa y liczne modele rozwoju oprogramowania. Wiele z nich, na przyk ad model wodospadu, etapowe modele cyklu ycia, model spiralny czy model V, maj swe pocz tki w lotnictwie i innych ga ziach przemys u produkcyjnego, dlatego nie zawsze odpowia- daj rzeczywisto ci procesu rozwoju oprogramowania. RSDM to model iteracyjny, który umo liwia interakcj zarówno z wewn trznymi, jak i z zewn trznymi klientami oraz uchwycenie VOC w procesie rozwoju. Ponadto jest solidny i elastyczny, a tak e mo na go dostosowa do dowolnego procesu rozwoju oprogramowania. W nast pnych rozdzia ach opisujemy zastosowania tego modelu i jego elementy ze szczególnym uwzgl dnieniem kontekstu rozwoju oprogramowania dla przedsi biorstw. Chcemy przypomnie , e w organizacjach zajmuj cych si rozwojem oprogramowania i w 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 szej kadry zarz dzaj cej. Musz oni zapewni niezb dne przywództwo, utworzy prawid ow infrastruktur zarz dzania i rozwija rodowisko pod k tem tworzenia oprogramowania godnego 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. Jednak oprogramowanie wi e si ze specyficznym rodowiskiem projektowania i rozwoju. Trzeba zrozumie z o ono cz sto zwi zan z oprogramowaniem i uwzgl dni innowacyjno oraz trudno zada , do których obs ugi jest projektowane. Zadanie utworzenia oprogramowania godnego zaufania to prawdziwe wyzwanie i wymaga istotnego zaanga owania kadry zarz dzaj cej. Tradycyjne systemy kontroli jako ci bazuj na dwóch b dnych za o eniach: po pierwsze, 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 ze specyfikacj i na poziomie docelowym , s takie same. 14 punktów zarz dzania Deminga s u cych do poprawy jako ci obejmuje ws uchiwanie si w g os klientów, zmniejszanie wariancji, stosowanie miar 96 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania statystycznych, zdobywanie zaufania i szacunku wspó pracowników oraz ci g e usprawnianie. Deming wskazuje na braki systemów zarz dzania jako ci zale nych od kontroli. Japo ski in ynier przemys owy Genichi Taguchi rozwin alternatywny system zarz dzania jako ci metody Taguchiego. Taguchi podkre la warto poziomu docelowego i zaleca dba o o jako na wczesnych etapach, zamiast zale no ci od kontroli maj cych wykry i naprawi b dy w dalszych fazach rozwoju. Filozofi zarz dzania jako ci Taguchiego mo na podsumowa w nast puj cy sposó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 cie oprogramowania dla przedsi biorstw oprogramowanie godne zaufania musi spe 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 y http://www.prenhallprofessional.com/title/0131872508 http://www.agilenty.com/publications wiczenia internetowe http://www.asiusa.com/publications/images/HBR.pdf Po przeczytaniu artyku u Taguchiego i Clausinga dost pnego pod powy szym adresem przygotuj 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 cie oprogramowania. 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 przegl dowe 1. Opisz, jak wieloaspektowe spojrzenie na jako pomaga zaspokoi potrzeby ró norodnych partnerów. Zilustruj odpowied przyk adami zwi zanymi ze znanym Ci oprogramowaniem. 2. Czy problemy z jako ci oprogramowania s zasadniczo odmienne od wyst puj cych w wyrobach produkowanych? Jakie s podobie stwa i ró nice mi dzy oprogramowaniem i wyrobami produkowanymi w zakresie procesu ich rozwoju? 3. Porównaj niezawodno oprogramowania i sprz tu. Wyja nij skutki takiego stanu 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 asz za najwa niejsze? 5. Opisz dwa najwa niejsze problemy z tradycyjnymi systemami kontroli jako ci i wp yw, jaki maj na oprogramowanie. 98 Rozdzia 2 " Wyzwania na drodze do oprogramowania godnego zaufania 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 wymienionymi w 14 punktach i jak je wspieraj . 8. Jak brzmi pi filozoficznych nakazów podej cia Taguchiego? Wyja nij ich zwi 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 solidnego oprogramowania. Opisz, jak wspomagaj one proces rozwoju oprogramowania. 10. Wymie i opisz pi g ównych wyzwa na drodze do tworzenia oprogramowania godnego zaufania. Zilustruj odpowied dwoma znanymi Ci produktami z dziedziny oprogramowania. 11. Opisz cechy modelu rozwoju solidnego oprogramowania. Wyja nij, jak te w a ciwo ci oraz sam model jako ca o mo na porówna z dwoma podobnymi modelami 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 u 5. 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 przypadku oprogramowania dla przedsi biorstw i produktów fabrykowanych. Mo esz pos 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 metodologii projektowania oprogramowania godnego zaufania (DFTS). Jakie s mo liwe ród a oporu przy jej wprowadzaniu? Jak mo na sobie z nimi poradzi ? Przedstaw odpowied na zaj ciach. 4. Wyobra sobie, e jeste cz onkiem zespo u zarz dzaj cego wysokiego stopnia kierowanego przez prezesa. Zespó otrzyma od zarz du firmy zajmuj cej si rozwojem oprogramowania zadanie identyfikacji g ównych przyczyn problemów z jako ci oprogramowania i zaproponowania platformy umo liwiaj cej ich rozwi zanie. Napisz informacj dla zarz du po wst pnej ocenie. Zaprezentuj j na zaj ciach. Przypisy 99 Przypisy 1 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.