Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00557 010253 11042612 na godz. na dobę w sumie
Oprogramowanie godne zaufania. Metodologia, techniki i narzędzia projektowania - książka
Oprogramowanie godne zaufania. Metodologia, techniki i narzędzia projektowania - książka
Autor: , Liczba stron: 816
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-1463-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

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

Jakość oprogramowania to wielowarstwowe zagadnienie. Spojrzenie na nią z kilku perspektyw jest kluczowe dla procesu tworzenia nowego produktu. Należy przy tym wziąć pod uwagę nie tylko opłacalność jego wytwarzania i konkurencyjność, ale także jawne i ukryte potrzeby naszych klientów oraz partnerów biznesowych. Stąd wynika potrzeba używania zintegrowanej technologii, pomagającej spełniać 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 jakością tworzonego produktu, dzięki czemu zapobiega powstawaniu błędów implementacji. Siłą tej technologii jest także fakt, że wszelkie działania związane z jakością są podejmowane przed napisaniem każdego wiersza kodu.

Ta książka pomoże w poprawie jakości wszystkim tym, którzy wdrażają rozwiązania wewnętrzne i zewnętrzne, prowadzą konsultacje i świadczą pomoc techniczną. Zawiera ona przełomowe rozwiązania dla specjalistów z dziedziny oprogramowania oraz jakości - od programistów po liderów projektu, od głównych architektów oprogramowania po klientów. Z tego podręcznika dowiesz się m.in., jak stosować najlepsze praktyki w dziedzinie kontrolowania jakości, organizacji szkoleń i zarządzania w wyjątkowym środowisku rozwoju oprogramowania.

Twórz niezawodne oprogramowanie wysokiej jakości!

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

Darmowy fragment publikacji:

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 (cid:149) Jak przeprowadzi(cid:230) weryfikacjŒ, ocenia(cid:230) i konserwowa(cid:230) oprogramowanie? (cid:149) Jakie s„ finansowe aspekty tworzenia oprogramowania godnego zaufania? (cid:149) Jak zarz„dza(cid:230) portfelem technologii informatycznych? Jako(cid:156)(cid:230) oprogramowania to wielowarstwowe zagadnienie. Spojrzenie na ni„ z kilku perspektyw jest kluczowe dla procesu tworzenia nowego produktu. Nale¿y przy tym wzi„(cid:230) pod uwagŒ nie tylko op‡acalno(cid:156)(cid:230) jego wytwarzania i konkurencyjno(cid:156)(cid:230), ale tak¿e jawne i ukryte potrzeby naszych klient(cid:243)w oraz partner(cid:243)w biznesowych. St„d wynika potrzeba u¿ywania zintegrowanej technologii, pomagaj„cej spe‡nia(cid:230) wszystkie te wymagania. Odpowiada na ni„ technologia projektowania oprogramowania godnego zaufania (ang. Designing for Trustworthy Software). S‡u¿y ona wczesnemu rozwi„zywaniu problem(cid:243)w zwi„zanych z jako(cid:156)ci„ tworzonego produktu, dziŒki czemu zapobiega powstawaniu b‡Œd(cid:243)w implementacji. Si‡„ tej technologii jest tak¿e fakt, ¿e wszelkie dzia‡ania zwi„zane z jako(cid:156)ci„ s„ podejmowane przed napisaniem ka¿dego wiersza kodu. Ta ksi„¿ka pomo¿e w poprawie jako(cid:156)ci wszystkim tym, kt(cid:243)rzy wdra¿aj„ rozwi„zania wewnŒtrzne i zewnŒtrzne, prowadz„ konsultacje i (cid:156)wiadcz„ pomoc techniczn„. Zawiera ona prze‡omowe rozwi„zania dla specjalist(cid:243)w z dziedziny oprogramowania oraz jako(cid:156)ci (cid:150) od programist(cid:243)w po lider(cid:243)w projektu, od g‡(cid:243)wnych architekt(cid:243)w oprogramowania po klient(cid:243)w. Z tego podrŒcznika dowiesz siŒ m.in., jak stosowa(cid:230) najlepsze praktyki w dziedzinie kontrolowania jako(cid:156)ci, organizacji szkoleæ i zarz„dzania w wyj„tkowym (cid:156)rodowisku rozwoju oprogramowania. (cid:149) Metodologia rozwoju oprogramowania (cid:149) Miary jako(cid:156)ci oprogramowania (cid:149) Koszty jako(cid:156)ci oprogramowania (cid:149) NarzŒdzia i techniki projektowania oprogramowania godnego zaufania (cid:149) Analityczny proces hierarchiczny (cid:149) Z‡o¿ono(cid:156)(cid:230), b‡Œdy i poka-yoke w procesach rozwoju oprogramowania (cid:149) Ocena ryzyka oraz analiza przyczyn i skutk(cid:243)w b‡Œd(cid:243)w (FEMA) (cid:149) Technologie obiektowe i komponentowe (cid:149) Techniki AHP, TRIZ, CoSQ i metoda Taguchiego (cid:149) Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania (cid:149) Wdra¿ania technologii DFTS (cid:149) QFD dla projekt(cid:243)w Tw(cid:243)rz niezawodne oprogramowanie wysokiej jako(cid:156)ci! Wydawnictwo Helion ul. Ko(cid:156)ciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Spis treĂci Spis treĂci Wprowadzenie Przedmowa PodziÚkowania O autorach CZ}¥m I WSPӒCZESNY PROCES ROZWOJU APLIKACJI, JEGO BRAKI I WYZWANIA NA DRODZE DO OPROGRAMOWANIA GODNEGO ZAUFANIA ROZDZIA’ 1. Wspóïczesne metodologie rozwoju oprogramowania Rozwój oprogramowania — potrzeba nowego paradygmatu Ramka 1.1. ZïoĝonoĂÊ komputerów Strategie rozwoju oprogramowania i modele cyklu ĝycia Model utwórz i popraw Model wodospadu Model bïyskawicznych prototypów Model przyrostowy Programowanie ekstremalne Model spiralny Programowanie obiektowe Rozwój iteracyjny, czyli model ewolucyjny Porównanie róĝnych modeli cyklu ĝycia Usprawnienia procesu rozwoju oprogramowania Model RUP Model CMM Wytyczne rozwoju oprogramowania ISO 9000-3 Porównanie modeli RUP, CMM i ISO 9000 Metoda ADR Siedem elementów procesu rozwoju stabilnego oprogramowania Model rozwoju solidnego oprogramowania Ramka 1.2. Krytyczne oprogramowanie sterujÈce w lotnictwie Kluczowe zagadnienia 5 23 25 31 33 35 37 39 41 42 44 45 45 46 48 49 50 52 53 53 54 55 56 58 60 60 61 62 63 6 Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy Spis treĂci 64 64 64 65 65 ROZDZIA’ 2. Wyzwania na drodze do oprogramowania godnego zaufania — solidny projekt w kontekĂcie oprogramowania NiezawodnoĂÊ oprogramowania — fakty i mity 67 69 Podobieñstwa i róĝnice miÚdzy oprogramowaniem i wyrobami produkowanymi 69 71 Porównywanie niezawodnoĂci oprogramowania i sprzÚtu 71 Przyczyny zawodnoĂci oprogramowania 74 75 75 77 78 80 83 83 85 87 Ograniczenia tradycyjnych systemów kontroli jakoĂci Japoñskie systemy zarzÈdzania jakoĂciÈ i podejĂcie Taguchiego Ramka 2.1. ¿ycie i czasy doktora Genichiego Taguchiego Ramka 2.2. Metodologia inĝynierii jakoĂci w zarysie Ramka 2.3. Taguchi o metodach Taguchiego Ramka 2.4. Istota 14 punktów Deminga Istota metod solidnego projektowania Taguchiego Zagadnienie stosunku sygnaïu do szumu Zagadnienie funkcji utraty jakoĂci Zagadnienie solidnego projektowania Wyzwania na drodze do niezawodnoĂci oprogramowania — projektowanie oprogramowania godnego zaufania Model rozwoju solidnego oprogramowania — proces DFTS w praktyce Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Pytania do dyskusji i projekty Przypisy ROZDZIA’ 3. Miary jakoĂci oprogramowania Pomiar jakoĂci oprogramowania Klasyczne miary jakoĂci oprogramowania ZarzÈdzanie przez jakoĂÊ Ogólne miary jakoĂci oprogramowania 88 94 95 97 97 97 98 99 101 103 103 104 106 Spis treĂci Metodologia pomiarów WewnÈtrzprocesowe miary jakoĂci do testowania oprogramowania Miary zïoĝonoĂci oprogramowania Nauka o oprogramowaniu ZïoĝonoĂÊ cyklomatyczna Miary punktów funkcyjnych Miary zadowolenia klienta i dostÚpnoĂci Ramka 3.1. Miejska legenda o oprogramowaniu Aktualne miary i modele Nowe miary projektowania i oceny architektury Powszechne problemy z projektowaniem architektury Miary wzorców w OOAD Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy ROZDZIA’ 4. Finansowe perspektywy tworzenia oprogramowania godnego zaufania Dlaczego DFTS wymaga róĝnych analiz finansowych? Koszty i jakoĂÊ — kiedyĂ i dziĂ Koszty jakoĂci oprogramowania KorzyĂci pïynÈce z analiz kosztów jakoĂci Koszty zadañ nakierowanych na poprawÚ jakoĂci Klasyfikacja kosztów jakoĂci oprogramowania Ustanawianie systemu tworzenia raportów CoSQ KorzyĂci inwestycji w jakoĂÊ WartoĂÊ analiz CoSQ Puïapki zwiÈzane z programem CoSQ Koszty jakoĂci oprogramowania w cyklu ĝycia Studium przypadku 4.1. Zastosowanie CoSQ w Intents Software CoSQ i kosztorysowanie bazujÈce na aktywnoĂciach ABC w firmach zajmujÈcych siÚ rozwojem oprogramowania Uruchamianie ABC przy rozwoju oprogramowania KorzyĂci stosowania ABC Ramka 4.1. ABC w przemyĂle usïugowym 7 106 107 109 110 112 113 114 115 116 118 119 121 122 123 123 123 124 124 127 129 130 134 134 135 137 146 148 149 149 150 152 157 157 158 159 160 8 Spis treĂci Funkcja utraty jakoĂci w przypadku oprogramowania Finansowa ocena inwestycji w DFTS Miary oceny DFTS Tworzenie platformy oceny finansowej programów DFTS Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji Problemy Przypisy ROZDZIA’ 5. Infrastruktura organizacyjna i przywództwo przy stosowaniu DFTS Wyzwania organizacyjne przy wdraĝaniu DFTS Schemat wdraĝania DFTS Etap 1. Budowanie ĂwiadomoĂci zarzÈdu i przekonywanie go Etap 2. Komunikowanie o zgodnoĂci i zaangaĝowaniu wyĝszej kadry zarzÈdzajÈcej Etap 3. Wykrywanie potencjalnych puïapek zwiÈzanych z inicjatywÈ DFTS Ramka 5.1. Nienaganny cykl nauki i TPOV Etap 4. Kïadzenie podwalin pod organizacjÚ skoncentrowanÈ na jakoĂci Etap 5. Budowanie infrastruktury organizacyjnej Etap 6. Zrozumienie ról kluczowych osób Etap 7. Projektowanie wspomagajÈcej struktury organizacyjnej Etap 8. Ustanawianie efektywnej komunikacji Etap 9. Tworzenie odpowiedniego systemu nagród Etap 10. Ustanawianie systemu CoSQ Etap 11. Planowanie i uruchamianie szkoleñ w caïej organizacji Etap 12. Wdraĝanie modelu DFTS Etap 13. Kontrolowanie nauki i postÚpów oraz przekazywanie informacji zwrotnych Etap 14. Utrwalanie usprawnieñ i zysków Etap 15. Integracja i rozszerzanie programu ’Èczenie wszystkich elementów Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe 160 161 161 162 164 166 166 166 167 168 168 171 173 173 174 178 179 188 189 192 192 203 205 206 208 208 209 210 212 212 213 214 218 218 Spis treĂci Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy CZ}¥m II NARZ}DZIA I TECHNIKI PROJEKTOWANIA OPROGRAMOWANIA GODNEGO ZAUFANIA Siedem podstawowych narzÚdzi zarzÈdzania jakoĂciÈ (P7) ROZDZIA’ 6. Siedem podstawowych narzÚdzi (P7) Ramka 6.1. Kaoru Ishikawa — rozwój specyficznie japoñskiej strategii 9 219 220 220 223 225 228 zarzÈdzania jakoĂciÈ P7 w kontekĂcie DFTS Inne narzÚdzia, techniki i metodologie DFTS Diagramy przebiegu Diagramy przebiegu wysokiego poziomu Szczegóïowe diagramy przebiegu Torowe diagramy przebiegu Diagramy Pareto Diagramy przyczynowo-skutkowe 230 232 233 234 235 235 236 236 237 240 Tworzenie diagramów przyczynowo-skutkowych w celu okreĂlenia przyczyn Uĝywanie diagramów przyczynowo-skutkowych do klasyfikowania procesów 241 243 246 246 247 248 248 248 250 252 254 254 254 255 OkreĂlanie rozkïadu OkreĂlanie, czy wymogi specyfikacji zostaïy speïnione Porównywanie danych za pomocÈ warstw Wykresy Karty kontrolne Kluczowe zagadnienia Dodatkowe materiaïy Pytania przeglÈdowe Zagadnienia do dyskusji Przypisy Diagramy rozproszenia Arkusze kontrolne Histogramy 10 Spis treĂci ROZDZIA’ 7. NarzÚdzia 7 ZP — analiza i interpretacja danych jakoĂciowych oraz werbalnych NarzÚdzia N7 i 7 ZP Typowe zastosowania narzÚdzi 7 ZP Diagram pokrewieñstwa Diagramy wspóïzaleĝnoĂci Diagram drzewa Macierze priorytetów Diagram macierzowy Wykres programowy procesu decyzyjnego (PDPC) Diagram sieci aktywnoĂci UmiejÚtnoĂci behawioralne przydatne do stosowania narzÚdzi 7 ZP Kluczowe zagadnienia Dodatkowe materiaïy Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy ROZDZIA’ 8. Analityczny proces hierarchiczny OkreĂlanie priorytetów, zïoĝonoĂÊ i analityczny proces hierarchiczny AHP i podejmowanie decyzji w obliczu wielu celów Sïownictwo OkreĂlanie struktury hierarchii celów Hierarchia decyzji Studium przypadku 8.1. Informatyczny dylemat dyrektora do spraw systemów informacyjnych wspomagajÈcych zarzÈdzanie (MIS) Studium przypadku 8.1. RozwiÈzanie przygotowane za pomocÈ Expert Choice Etap 1. Burza mózgów i tworzenie hierarchicznego modelu problemu Etap 2. OkreĂlanie priorytetów celów na skali ilorazowej Etap 3. OkreĂlanie priorytetów alternatyw z uwagi na kaĝdy cel Etap 4. Synteza Przybliĝanie wyników AHP na podstawie samodzielnych obliczeñ Pierwsza metoda tworzenia przybliĝonych rozwiÈzañ Druga metoda przybliĝania. Kompleksowa analityczna metoda kryteriów do okreĂlania priorytetów Brassarda Wnioski Kluczowe zagadnienia 257 260 261 263 266 270 272 274 274 275 276 277 278 278 279 279 281 283 284 286 286 288 289 290 290 292 295 297 298 302 309 312 313 Spis treĂci Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Problemy Problem 1. ZarzÈdzanie zïoĝonoĂciÈ przy przeksztaïcaniu systemów Problem 2. ZarzÈdzanie zïoĝonoĂciÈ oprogramowania w nowej firmie z branĝy zaawansowanych technologii Problem 3. ZïoĝonoĂÊ w systemach zarzÈdzania kartami pacjentów Problem 4. System wspomagajÈcy podejmowanie decyzji dotyczÈcych odwiertów ropy naftowej Problem 5. Problem ROI Problem 6. Abstrakcyjne analizy zïoĝonoĂci Problem 7. WraĝliwoĂÊ na zïoĝonoĂÊ Przypisy ROZDZIA’ 9. ZïoĝonoĂÊ, bïÚdy i poka-yoke w procesach rozwoju oprogramowania Poka-yoke jako system kontroli jakoĂci Zasady poka-yoke Przyczyny defektów — zmiennoĂÊ, bïÚdy i zïoĝonoĂÊ Warunki stosowania poka-yoke Pomyïki jako przyczyny defektów Kontrola zïoĝonoĂci w rozwoju oprogramowania Pomyïki, metody kontroli i poka-yoke Wdraĝanie systemu poka-yoke OkreĂlanie rozwiÈzania bazujÈcego na poka-yoke Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy 11 314 314 314 315 315 315 318 320 321 323 323 324 324 327 329 330 331 333 334 336 340 341 345 346 348 348 349 349 350 12 Spis treĂci ROZDZIA’ 10. 5S w obszarze inteligentnego zarzÈdzania rozwojem oprogramowania 5S — wielki krok w kierunku produktywnego Ărodowiska pracy Etapy wdraĝania systemu 5S Etap 1. Selekcja i sortowanie Etap 2. Organizowanie i porzÈdkowanie Etap 3. SprzÈtanie i czyszczenie Etap 4. Standaryzacja Etap 5. Podtrzymywanie i samodyscyplina System 5S i proces DFTS Ramka 10.1. Od 5S do szczupïego procesu DFTS Przeïamywanie oporu Wdraĝanie 5S Etap 1. Przekonywanie zarzÈdu Etap 2. Szkolenia i wdraĝanie Etap 3. PowiÈzanie z systemem nagród Etap 4. Kontynuacja i ciÈgïe usprawnianie Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy ROZDZIA’ 11. Zrozumienie potrzeb klienta — QFD w dziedzinie oprogramowania i gïos klienta QFD — poczÈtki i wprowadzenie Czym wyróĝnia siÚ QFD wĂród innych systemów jakoĂci? Historia QFD Historia QFD dla oprogramowania Czym jest QFD i do czego sïuĝy? Koncentracja na priorytetach Definicja QFD RozwiniÚcia QFD Czteroetapowy model QFD Macierz „domu jakoĂci” Problemy ze stosowaniem tradycyjnej wersji QFD do oprogramowania Niepowodzenia zwiÈzane z tradycyjnÈ wersjÈ QFD 353 355 356 356 356 357 357 357 358 359 362 363 363 364 364 365 365 366 366 366 367 367 369 371 372 373 374 376 378 379 380 380 382 386 386 Spis treĂci „Ta macierz jest za duĝa” „To zajmuje zbyt duĝo czasu” „Juĝ to wiemy” Nowoczesna wersja QFD dla oprogramowania Bïyskawiczna metoda QFD Siedem narzÚdzi do zarzÈdzania i planowania (7 ZP) Zadowolenie klienta i wartoĂÊ Bïyskawiczny proces QFD Etap 1. Kluczowy cel projektu Etap 2. Kluczowy segment klientów Etap 3. Kluczowe etapy procesu Etap 4. Wizyta w gemba Etap 5. Jakie sÈ potrzeby klienta? Etap 6. Struktura potrzeb klienta Etap 7. Analiza struktury potrzeb klienta Etap 8. OkreĂlanie priorytetów potrzeb klienta Etap 9. Realizacja priorytetowych potrzeb klientów Póěne rozwiniÚcia. Szczegóïowa analiza (wyïÈcznie) istotnych relacji „Dom jakoĂci” i nie tylko Projekty Six Sigma Dziaïania nastÚpcze — stosowanie, ewolucja i usprawnianie procesu Bïyskawiczne programowanie RozwiniÚcie harmonogramu za pomocÈ zarzÈdzania projektem poprzez ïañcuch krytyczny Wprowadzanie QFD dla oprogramowania Czynnik ludzki w QFD Wyzwania i puïapki w obszarze QFD Jak wdraĝaÊ QFD dla oprogramowania? Wnioski Nowoczesna wersja QFD w procesie DFTS Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji Przypisy 13 387 388 389 391 391 391 391 393 393 395 396 396 397 401 401 402 403 405 406 408 408 408 409 409 410 410 413 414 414 415 417 418 419 420 421 14 Spis treĂci ROZDZIA’ 12. KreatywnoĂÊ i innowacyjnoĂÊ w procesie projektowania oprogramowania — TRIZ i metodologia wyboru koncepcji Pugha Potrzeba kreatywnoĂci w DFTS KreatywnoĂÊ i TRIZ Ramka 12.1. Czym jest szczÚĂliwy traf? Ramka 12.2. Pionierzy TRIZ w rozwoju oprogramowania Ramka 12.3. Lingua latina non mortua est TRIZ, QFD i metody Taguchiego Burza mózgów Metodologia wyboru koncepcji Pugha Oprogramowanie jako wïasnoĂÊ intelektualna Ramka 12.4. Obraz jest wart… Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy ROZDZIA’ 13. Ocena ryzyka oraz analiza przyczyn i skutków bïÚdów (FMEA) w dziedzinie oprogramowania FMEA — analizy przyczyn i efektów bïÚdów Zastosowania FMEA na wczesnych etapach Analizy drzewa bïÚdów oprogramowania Przyczyny bïÚdów w oprogramowaniu i ich ěródïa OkreĂlanie i ocena ryzyka na poszczególnych etapach DFTS Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy 427 429 429 430 433 433 434 442 442 444 447 449 450 450 450 451 451 451 453 455 459 462 465 467 468 469 469 469 469 470 Spis treĂci ROZDZIA’ 14. Technologie obiektowe i komponentowe oraz inne narzÚdzia programistyczne Gïówne wyzwania w rozwoju biznesowych aplikacji dla przedsiÚbiorstw Analizy, projektowanie i programowanie obiektowe Ramka 14.1. Narodziny programowania obiektowego Ramka 14.2. Zalety warstwy poĂredniej jÚzyka Java Technologia rozwoju oprogramowania na podstawie komponentów Poprawa produktywnoĂci za pomocÈ programowania ekstremalnego ZwiÚkszanie niezawodnoĂci przy uĝyciu programowania wielowersyjnego Zalety NVP Wady NVP Wspóïczesne Ărodowiska programistyczne Trendy w automatyzacji programowania Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy CZ}¥m III PROJEKTOWANIE OPROGRAMOWANIA GODNEGO ZAUFANIA ROZDZIA’ 15. Miary jakoĂci i metody statystyczne w rozwoju oprogramowania godnego zaufania Oprogramowanie godne zaufania Inicjatywa Microsoftu na rzecz przetwarzania godnego zaufania Statystyczne sterowanie procesem w rozwoju oprogramowania Metody statystyczne dla architektów oprogramowania Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Problemy Przypisy 15 471 473 473 474 479 481 484 486 487 487 488 492 495 495 496 496 496 496 499 501 503 504 507 513 517 517 518 518 518 518 518 16 Spis treĂci ROZDZIA’ 16. Solidne oprogramowanie w kontekĂcie Proces tworzenia specyfikacji oprogramowania Ramka 16.1. Precyzyjne specyfikacje funkcjonalne Czym jest solidne oprogramowanie? Wymagania, jakie musi speïniaÊ solidne oprogramowanie Ramka 16.2. Uzyskiwanie informacji od uĝytkownika koñcowego Ocena solidnoĂci oprogramowania Ramka 16.3. Przykïad projektowania parametrów Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Problemy Przypisy ROZDZIA’ 17. Metody Taguchiego i optymalizacja pod kÈtem solidnego oprogramowania Metody Taguchiego w projektowaniu solidnego oprogramowania Przykïad z dziedziny inĝynierii projektu Przykïad z obszaru projektowania i rozwoju oprogramowania Macierze ortogonalne w eksperymentach Taguchiego nad projektowaniem parametrów Zastosowania w DFTS Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji Problemy Przypisy ROZDZIA’ 18. Weryfikacja, walidacja, testy i ocena w rozwoju oprogramowania godnego zaufania CiÈg dalszy cyklu rozwoju Ramka 18.1. Miejska legenda o oprogramowaniu biznesowym 521 523 525 526 527 528 528 530 531 531 531 532 532 532 533 535 537 541 544 549 552 552 553 553 553 553 553 554 555 557 558 Spis treĂci Weryfikacja Studium przypadku 18.1. Metody Taguchiego w weryfikacji projektu systemu RTOS Walidacja Studium przypadku 18.2. Metody Taguchiego w walidacji oprogramowania Testy i ocena Ramka 18.2. Anomalie z obszaru testów i debugowania Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Problemy Przypisy ROZDZIA’ 19. Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania Koñczenie cyklu rozwoju Integracja Ramka 19.1. Spitfire Supermarine Wzbogacanie Studium przypadku 19.1. ZwiÚkszanie moĝliwoĂci elektronicznego systemu do prowadzenia dziaïañ wojennych Konserwacja Studium przypadku 19.2. Konserwacja systemów oprogramowania u klienta Ramka 19.2. UsuniÚcie zaawansowanej funkcjonalnoĂci oprogramowania w wyniku konserwacji Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Problemy Przypisy 17 559 559 563 563 566 567 571 572 572 573 573 573 573 575 577 577 578 578 579 581 582 583 584 584 584 585 585 585 585 18 Spis treĂci CZ}¥m IV ’kCZENIE WSZYSTKICH ELEMENTÓW — WDRA¿ANIE PROGRAMU DFTS ROZDZIA’ 20. Przygotowanie organizacji do wdraĝania DFTS Czas na rozwaĝania Studium przypadku 20.1. DÈĝenie do doskonaïego procesu produkcji Studium przypadku 20.2. Instytucjonalizacja Six Sigma w GE Wyzwania stojÈce przed liderami w trakcie inicjatyw transformacyjnych Ocena kluczowych elementów organizacji Wzbudzanie zaangaĝowania liderów Zrozumienie roli liderów Ocena strategicznych powiÈzañ Zapewnianie zaangaĝowania caïej organizacji Zrozumienie koniecznoĂci koncentracji na kliencie Ocena obecnego poziomu zarzÈdzania jakoĂciÈ Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji i projekty Przypisy ROZDZIA’ 21. Uruchamianie inicjatywy DFTS DFTS i platforma PICS Planowanie Wdraĝanie Etap 11. Uruchamianie szkoleñ w caïej organizacji Projektowanie programu szkoleñ — dostosowanie i zróĝnicowanie Szkolenia dla personelu pomocniczego Etap 12. Wdraĝanie technologii DFTS — proces nauki i stosowania Kontrola Etap 13. Systemy kontroli informacji zwrotnych Studium przypadku 21.1. CiÈgïe uczenie siÚ i wzbogacanie — proces Operating System korporacji GE ZarzÈdzanie projektem Zabezpieczanie Etap 14. Utrwalanie usprawnieñ i zysków Etap 15. Integracja i rozwój inicjatywy Studium przypadku 21.2. Inicjatywy na rzecz jakoĂci i ich integracja w TCS 587 589 591 591 594 598 599 600 601 602 602 603 604 605 606 607 607 607 608 609 611 611 612 613 614 615 616 621 624 627 631 632 632 632 637 Spis treĂci Zastosowania w maïych firmach programistycznych i wioskach elektronicznych Co dalej? Kluczowe zagadnienia Dodatkowe materiaïy mwiczenia internetowe Pytania przeglÈdowe Zagadnienia do dyskusji Przypisy CZ}¥m V SZE¥m STUDIÓW PRZYPADKU ROZDZIA’ 22. Koszty jakoĂci oprogramowania (CoSQ) w Raytheon’s Electronic Systems (RES) Group Wprowadzenie Program usprawnieñ w RES Koszty jakoĂci oprogramowania Model CoSQ w RES Zbieranie danych CoSQ Zdobyte doĂwiadczenia i wiedza Wiedza zdobyta w czasie korzystania z modelu CoSQ Uĝywanie danych CoSQ do zrozumienia wpïywu usprawnieñ Koszty i zyski z programu CoSQ Instytucjonalizacja kontroli kosztów CoSQ Wnioski ze studium przypadku Przypisy ROZDZIA’ 23. ZarzÈdzanie portfelem technologii informatycznych CzÚĂÊ pierwsza. Wyzwanie PiÚÊ etapów iteracyjnego procesu ObiektywnoĂÊ, subiektywnoĂÊ i jakoĂÊ CzÚĂÊ druga. Nowe, racjonalne podejĂcie Etap 1. Projekt Etap 2. Strukturyzacja zïoĝonoĂci — koncentracja na celach Etap 3. Pomiar Etap 4. Synteza Etap 5. Optymalizacja Ryzyko 19 640 641 641 643 644 644 645 645 647 653 654 654 655 655 656 656 656 657 660 660 660 661 663 665 665 668 669 669 670 670 674 676 679 20 Rozszerzenia Podsumowanie Przypisy ROZDZIA’ 24. Definiowanie potrzeb klienta przy rozwoju zupeïnie nowego produktu — QFD dla nowatorskiego oprogramowania Wprowadzenie Definicja wartoĂci Dlaczego nie zapytaÊ? Nowatorskie produkty Definiowanie zupeïnie nowych potrzeb Metody okreĂlania potrzeb klientów NarzÚdzia Siedem narzÚdzi do zarzÈdzania i planowania (7 ZP) w QFD Ramka 24.1. Czym jest teoria ograniczeñ? Procesy wnioskowania w TOC Ostatnie kroki Wprowadzanie nowatorskich produktów na rynek Warstwy oporu Wnioski PodziÚkowania Literatura cytowana O autorze ROZDZIA’ 25. Jurajskie QFD — integrowanie QFD dla usïug i produktów Profil firmy MD Robotics Dlaczego QFD? Historia QFD Wymagania Kany Spotkanie z triceratopsem na wyspie przygód Universal Studio na Florydzie Schemat QFD Analizy gïosu klienta RozwiniÚcie emocji RozwiniÚcie ciaïa RozwiniÚcie wymagañ inĝynieryjnych Podsumowanie O autorach Przypisy Spis treĂci 681 682 683 685 687 687 688 689 689 689 695 695 696 697 699 699 700 700 700 702 704 705 707 707 708 709 711 711 712 715 718 719 720 723 723 Spis treĂci ROZDZIA’ 26. QFD dla projektów. Lepsze zarzÈdzanie projektami rozwoju oprogramowania dziÚki bïyskawicznemu QFD Wprowadzenie Niepowodzenia CzÚĂciowy sukces Zdefiniowane QFD Dobry poczÈtek Problemy w trakcie rozwoju nowych produktów Niespójny rozwój jest niewydajny Spójny rozwój jest wydajny Koncentracja na wartoĂci w QFD dla projektu Siedem kroków do lepszych projektów Podsumowanie PodziÚkowania Literatura cytowana O autorze 21 727 729 729 730 730 730 730 731 733 735 735 746 746 747 749 ROZDZIA’ 27. QFD 2000. Integrowanie QFD i innych metod zarzÈdzania jakoĂciÈ w celu usprawnienia procesu rozwoju nowych produktów Materiaïy dotyczÈce QFD i innych metod zarzÈdzania jakoĂciÈ Popyt na nowe produkty JakoĂÊ i rozwój nowych produktów Wspóïczesne narzÚdzia do zarzÈdzania jakoĂciÈ Proces rozwoju nowych produktów 751 753 753 754 757 760 Analityczny proces hierarchiczny (AHP) i analityczny proces sieciowy (ANP) 760 761 Strategiczne karty wyników Bïyskawiczna QFD 761 761 Analizy ïÈczne (conjoint) 761 Spotkania z klientami 761 Podejmowanie decyzji z udziaïem klientów (CIDM) de Bono 761 761 Deming 762 Wizyty w gemba i analizy gïosu klienta 762 Planowanie hoshin Model Kano 762 762 Inĝynieria kansei 763 Badania gïównych uĝytkowników Szczupïa produkcja 763 22 Spis treĂci Nowa strategia Lanchestera Programowanie neurolingwistyczne (NLP) ZarzÈdzanie projektem Wybór koncepcji metodÈ Pugha QFD (wersja kompleksowa) NiezawodnoĂÊ QFD „ěródïa do potrzeb” Siedem narzÚdzi do zarzÈdzania i planowania (7ZP) Siedem narzÚdzi do planowania produktu (7PP) Siedem narzÚdzi do sterowania jakoĂciÈ (7SJ) Six Sigma, SPC Inĝynieria oprogramowania Bramki etapowe Strategiczne systemy informacyjne (SIS) ZarzÈdzanie ïañcuchem dostaw Metody Taguchiego Teoria ograniczeñ (TOC) ZarzÈdzanie przez jakoĂÊ (TQM) TRIZ Inĝynieria wartoĂci O autorze Literatura cytowana Sïowniczek pojÚÊ technicznych Skorowidz nazwisk Skorowidz 763 763 763 763 764 764 764 764 764 764 765 765 765 765 765 765 765 766 766 766 766 767 769 779 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 — fakty i mity „ Ograniczenia tradycyjnych systemów kontroli jakoĂci „ Japoñskie systemy zarzÈdzania jakoĂciÈ i podejĂcie Taguchiego „ Istota metod Taguchiego do tworzenia solidnych projektów „ Wyzwania na drodze do niezawodnoĂci oprogramowania — projektowanie oprogramowania godnego zaufania „ Model rozwoju solidnego oprogramowania — proces DFTS w praktyce „ Kluczowe zagadnienia „ Dodatkowe materiaïy „ mwiczenia internetowe „ Pytania przeglÈdowe „ Zagadnienia do dyskusji i projekty „ Przypisy 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: x 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. x 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”. x 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. x 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 oprogramowania 6 Kategoria NiezawodnoĂÊ sprzÚtu Podstawowa przyczyna Z powodu efektów fizycznych NiezawodnoĂÊ oprogramowania Z powodu bïÚdów programisty (lub defektów albo awarii programu) Przyczyny w cyklu ĝycia Analizy WykonalnoĂÊ Projekt Rozwój Dziaïanie Efekty stosowania Funkcja projektu Dziedziny Relacje czasowe Modele matematyczne Obszar czasu Funkcje Obszar danych Modele wzrostu Miary Nieprawidïowe zrozumienie klienta Nieprawidïowe zrozumienie klienta BïÚdne wymagania uĝytkownika BïÚdy w fizycznym projekcie Problemy z kontrolÈ jakoĂci Usterka i awaria BïÚdne wymagania uĝytkownika BïÚdy w projekcie programu BïÚdy w kodzie programu BïÚdy programu (lub inne defekty albo awarie) SprzÚt zuĝywa siÚ i zaczyna zawodziÊ Fizyka bïÚdu Czas (t) „Krzywa wannowa” Dobrze rozwiniÚta teoretycznie i akceptowana R = f(Ȝ, t), Ȝ = intensywnoĂÊ bïÚdów Wykïadnicza (staïa Ȝ) Weibulla (rosnÈca Ȝ) Bez znaczenia Istnieje kilka modeli Ȝ, MTBF (ang. mean time between failures, czyli Ăredni czas pomiÚdzy awariami) MTTF (ang. mean time to failure, czyli Ăredni czas do wystÈpienia awarii) Oprogramowanie nie zuĝywa siÚ, ale zawodzi w wyniku nieznanych defektów lub bïÚdów UmiejÚtnoĂci programisty Czas i dane Funkcja malejÈca Dobrze rozwiniÚta teoretycznie, ale o niskiej akceptacji R = f(bïÚdy [lub defekty albo awarie], t) Brak zgodnoĂci miÚdzy róĝnymi proponowanymi modelami funkcji czasu BïÚdy = f(testy na danych) Istnieje kilka modeli IntensywnoĂÊ bïÚdów, liczba wykrytych lub pozostaïych defektów (lub 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 Kategoria NiezawodnoĂÊ sprzÚtu NiezawodnoĂÊ oprogramowania Przewidywanie Techniki wzrostu Techniki przewidywania Diagramy blokowe, drzewa bïÚdów Analiza Ăcieĝek (analiza wszystkich Projektowanie, przewidywanie Testy i ewaluacja Projekt Operacje Zastosowanie nadmiaru RównolegïoĂÊ Rezerwa Akceptacja projektu i produkcji MIL-STD-781C (wykïadnicze) Inne metody (niewykïadnicze) MIL-STD-781C Moĝe poprawiaÊ niezawodnoĂÊ Automatyczne wykrywanie i poprawianie bïÚdów, automatyczne wykrywanie usterek i przeïÈczanie Logika wiÚkszoĂciowa m elementów z n Ă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 Akceptacja projektu Testowanie Ăcieĝek, symulacje, bïÚdy, posiew Bayesa Brak Trzeba rozwaĝyÊ najczÚstsze przyczyny Automatyczne wykrywanie i poprawianie bïÚdów, automatyczne kontrolowanie i ponowne inicjowanie oprogramowania 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. x 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Ú. x 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ñ. x 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. x 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. x 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. x 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. x Abstrakcyjne dziaïanie systemów cyfrowych. Naturalnie abstrakcyjne dziaïanie systemów cyfrowych sprawia, ĝe trudno zapewniÊ jakoĂÊ oprogramowania. x 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: x Wymagania klientów sÈ speïnione, jeĂli produkt znajduje siÚ w ramach uzgodnionych ograniczeñ wyznaczanych przez specyfikacjÚ. x 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; x x 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 x medal imienia Shewharta Amerykañskiego Stowarzyszenia na rzecz Kontroli JakoĂci; x NiebieskÈ WstÚgÚ cesarza Japonii, przyznanÈ w 1990 roku za wkïad w rozwój przemysïu; x 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 x 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. x Projektuj produkty tak, aby nie zawodziïy w praktyce. Tym samym zmniejszysz liczbÚ defektów w fabryce. x x 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. x 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. x 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. x 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. x x 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
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Oprogramowanie godne zaufania. Metodologia, techniki i narzędzia projektowania
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


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