Issuu on Google+

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

Wydawnictwo Helion ul. Koœciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl

Poznaj narzêdzia, techniki oraz metodologiê tworzenia niezawodnego oprogramowania • Jak przeprowadziæ weryfikacjê, oceniaæ i konserwowaæ oprogramowanie? • Jakie s¹ finansowe aspekty tworzenia oprogramowania godnego zaufania? • Jak zarz¹dzaæ portfelem technologii informatycznych? Jakoœæ oprogramowania to wielowarstwowe zagadnienie. Spojrzenie na ni¹ z kilku perspektyw jest kluczowe dla procesu tworzenia nowego produktu. Nale¿y przy tym wzi¹æ pod uwagê nie tylko op³acalnoœæ jego wytwarzania i konkurencyjnoœæ, ale tak¿e jawne i ukryte potrzeby naszych klientów oraz partnerów biznesowych. St¹d wynika potrzeba u¿ywania zintegrowanej technologii, pomagaj¹cej spe³niaæ 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. • Metodologia rozwoju oprogramowania • Miary jakoœci oprogramowania • Koszty jakoœci oprogramowania • Narzêdzia i techniki projektowania oprogramowania godnego zaufania • Analityczny proces hierarchiczny • Z³o¿onoœæ, b³êdy i poka-yoke w procesach rozwoju oprogramowania • Ocena ryzyka oraz analiza przyczyn i skutków b³êdów (FEMA) • Technologie obiektowe i komponentowe • Techniki AHP, TRIZ, CoSQ i metoda Taguchiego • Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania • Wdra¿ania technologii DFTS • QFD dla projektów Twórz niezawodne oprogramowanie wysokiej jakoœci!

5

Spis treci

Spis treci

Wprowadzenie

23

Przedmowa

25

Podzikowania

31

O autorach

33

CZ I

WSPÓCZESNY PROCES ROZWOJU APLIKACJI, JEGO BRAKI I WYZWANIA NA DRODZE DO OPROGRAMOWANIA GODNEGO ZAUFANIA

ROZDZIA 1.

Wspóczesne metodologie rozwoju oprogramowania

35 37

Rozwój oprogramowania — potrzeba nowego paradygmatu

39

Ramka 1.1. Zoono komputerów

41

Strategie rozwoju oprogramowania i modele cyklu ycia Model utwórz i popraw Model wodospadu Model byskawicznych prototypów Model przyrostowy Programowanie ekstremalne Model spiralny Programowanie obiektowe Rozwój iteracyjny, czyli model ewolucyjny Porównanie rónych modeli cyklu ycia

42 44 45 45 46 48 49 50 52 53

Usprawnienia procesu rozwoju oprogramowania Model RUP Model CMM Wytyczne rozwoju oprogramowania ISO 9000-3 Porównanie modeli RUP, CMM i ISO 9000

53 54 55 56 58

Metoda ADR

60

Siedem elementów procesu rozwoju stabilnego oprogramowania

60

Model rozwoju solidnego oprogramowania

61

Ramka 1.2. Krytyczne oprogramowanie sterujce w lotnictwie

62

Kluczowe zagadnienia

63

6

Spis treci

Dodatkowe materiay

64

wiczenia internetowe

64

Pytania przegldowe

64

Zagadnienia do dyskusji i projekty

65

Przypisy

65

ROZDZIA 2.

Wyzwania na drodze do oprogramowania godnego zaufania — solidny projekt w kontekcie oprogramowania

67

Niezawodno oprogramowania — fakty i mity Podobiestwa i rónice midzy oprogramowaniem i wyrobami produkowanymi Porównywanie niezawodnoci oprogramowania i sprztu Przyczyny zawodnoci oprogramowania

69 69 71 71

Ograniczenia tradycyjnych systemów kontroli jakoci

74

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

75

Ramka 2.1. ycie i czasy doktora Genichiego Taguchiego

75

Ramka 2.2. Metodologia inynierii jakoci 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 Zagadnienie stosunku sygnau do szumu Zagadnienie funkcji utraty jakoci Zagadnienie solidnego projektowania

83 83 85 87

Wyzwania na drodze do niezawodnoci oprogramowania — projektowanie oprogramowania godnego zaufania

88

Model rozwoju solidnego oprogramowania — proces DFTS w praktyce

94

Kluczowe zagadnienia

95

Dodatkowe materiay

97

wiczenia internetowe

97

Pytania przegldowe

97

Pytania do dyskusji i projekty

98

Przypisy

99

ROZDZIA 3.

Miary jakoci oprogramowania

101

Pomiar jakoci oprogramowania

103

Klasyczne miary jakoci oprogramowania

103

Zarzdzanie przez jako

104

Ogólne miary jakoci oprogramowania

106

7

Spis treci

Metodologia pomiarów Wewntrzprocesowe miary jakoci do testowania oprogramowania Miary zoonoci oprogramowania Nauka o oprogramowaniu Zoono cyklomatyczna Miary punktów funkcyjnych Miary zadowolenia klienta i dostpnoci

106 107 109 110 112 113 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 materiay

123

wiczenia internetowe

123

Pytania przegldowe

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 jakoci oprogramowania Korzyci pynce z analiz kosztów jakoci Koszty zada nakierowanych na popraw jakoci Klasyfikacja kosztów jakoci oprogramowania Ustanawianie systemu tworzenia raportów CoSQ Korzyci inwestycji w jako Warto analiz CoSQ Puapki zwizane z programem CoSQ

134 134 135 137 146 148 149 149

Koszty jakoci oprogramowania w cyklu ycia

150

Studium przypadku 4.1. Zastosowanie CoSQ w Intents Software

152

CoSQ i kosztorysowanie bazujce na aktywnociach ABC w firmach zajmujcych si rozwojem oprogramowania Uruchamianie ABC przy rozwoju oprogramowania Korzyci stosowania ABC

157 157 158 159

Ramka 4.1. ABC w przemyle usugowym

160

8

Spis treci

Funkcja utraty jakoci w przypadku oprogramowania

160

Finansowa ocena inwestycji w DFTS Miary oceny DFTS Tworzenie platformy oceny finansowej programów DFTS

161 161 162

Kluczowe zagadnienia

164

Dodatkowe materiay

166

wiczenia internetowe

166

Pytania przegldowe

166

Zagadnienia do dyskusji

167

Problemy

168

Przypisy

168

ROZDZIA 5.

Infrastruktura organizacyjna i przywództwo przy stosowaniu DFTS

171

Wyzwania organizacyjne przy wdraaniu DFTS

173

Schemat wdraania DFTS Etap 1. Budowanie wiadomoci zarzdu i przekonywanie go Etap 2. Komunikowanie o zgodnoci i zaangaowaniu wyszej kadry zarzdzajcej Etap 3. Wykrywanie potencjalnych puapek zwizanych z inicjatyw DFTS

173 174 178 179

Ramka 5.1. Nienaganny cykl nauki i TPOV Etap 4. Kadzenie podwalin pod organizacj skoncentrowan na jakoci Etap 5. Budowanie infrastruktury organizacyjnej Etap 6. Zrozumienie ról kluczowych osób Etap 7. Projektowanie wspomagajcej 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 caej organizacji Etap 12. Wdraanie modelu DFTS Etap 13. Kontrolowanie nauki i postpów oraz przekazywanie informacji zwrotnych Etap 14. Utrwalanie usprawnie i zysków Etap 15. Integracja i rozszerzanie programu

188 189 192 192 203 205 206 208 208 209 210 212 212

czenie wszystkich elementów

213

Kluczowe zagadnienia

214

Dodatkowe materiay

218

wiczenia internetowe

218

9

Spis treci

Pytania przegldowe

219

Zagadnienia do dyskusji i projekty

220

Przypisy

220

CZ II

NARZDZIA I TECHNIKI PROJEKTOWANIA OPROGRAMOWANIA GODNEGO ZAUFANIA

ROZDZIA 6.

Siedem podstawowych narzdzi zarz dzania jakoci (P7)

223 225

Siedem podstawowych narzdzi (P7)

228

Ramka 6.1. Kaoru Ishikawa — rozwój specyficznie japoskiej strategii zarzdzania jakoci

230

P7 w kontekcie DFTS

232

Inne narzdzia, techniki i metodologie DFTS

233

Diagramy przebiegu Diagramy przebiegu wysokiego poziomu Szczegóowe diagramy przebiegu Torowe diagramy przebiegu

234 235 235 236

Diagramy Pareto

236

Diagramy przyczynowo-skutkowe Tworzenie diagramów przyczynowo-skutkowych w celu okrelenia przyczyn Uywanie diagramów przyczynowo-skutkowych do klasyfikowania procesów

237 240 241

Diagramy rozproszenia

243

Arkusze kontrolne

246

Histogramy Okrelanie rozkadu Okrelanie, czy wymogi specyfikacji zostay spenione Porównywanie danych za pomoc warstw

246 247 248 248

Wykresy

248

Karty kontrolne

250

Kluczowe zagadnienia

252

Dodatkowe materiay

254

Pytania przegldowe

254

Zagadnienia do dyskusji

254

Przypisy

255

10

ROZDZIA 7.

Spis treci

Narzdzia 7 ZP — analiza i interpretacja danych jakociowych oraz werbalnych

257

Narzdzia N7 i 7 ZP

260

Typowe zastosowania narzdzi 7 ZP

261

Diagram pokrewiestwa

263

Diagramy wspózalenoci

266

Diagram drzewa

270

Macierze priorytetów

272

Diagram macierzowy

274

Wykres programowy procesu decyzyjnego (PDPC)

274

Diagram sieci aktywnoci

275

Umiejtnoci behawioralne przydatne do stosowania narzdzi 7 ZP

276

Kluczowe zagadnienia

277

Dodatkowe materiay

278

Pytania przegldowe

278

Zagadnienia do dyskusji i projekty

279

Przypisy

279

ROZDZIA 8.

Analityczny proces hierarchiczny

281

Okrelanie priorytetów, zoono i analityczny proces hierarchiczny

283

AHP i podejmowanie decyzji w obliczu wielu celów Sownictwo Okrelanie struktury hierarchii celów Hierarchia decyzji

284 286 286 288

Studium przypadku 8.1. Informatyczny dylemat dyrektora do spraw systemów informacyjnych wspomagajcych zarzdzanie (MIS)

289

Studium przypadku 8.1. Rozwizanie przygotowane za pomoc Expert Choice Etap 1. Burza mózgów i tworzenie hierarchicznego modelu problemu Etap 2. Okrelanie priorytetów celów na skali ilorazowej Etap 3. Okrelanie priorytetów alternatyw z uwagi na kady cel Etap 4. Synteza

290 290 292 295 297

Przyblianie wyników AHP na podstawie samodzielnych oblicze Pierwsza metoda tworzenia przyblionych rozwiza Druga metoda przybliania. Kompleksowa analityczna metoda kryteriów do okrelania priorytetów Brassarda

298 302

Wnioski

312

Kluczowe zagadnienia

313

309

11

Spis treci

Dodatkowe materiay

314

wiczenia internetowe

314

Pytania przegldowe

314

Zagadnienia do dyskusji i projekty

315

Problemy Problem 1. Zarzdzanie zoonoci przy przeksztacaniu systemów Problem 2. Zarzdzanie zoonoci oprogramowania w nowej firmie z brany zaawansowanych technologii Problem 3. Zoono w systemach zarzdzania kartami pacjentów Problem 4. System wspomagajcy podejmowanie decyzji dotyczcych odwiertów ropy naftowej Problem 5. Problem ROI Problem 6. Abstrakcyjne analizy zoonoci Problem 7. Wraliwo na zoono

315 315

321 323 323 324

Przypisy

324

ROZDZIA 9.

Zo ono , bdy i poka-yoke w procesach rozwoju oprogramowania

318 320

327

Poka-yoke jako system kontroli jakoci

329

Zasady poka-yoke

330

Przyczyny defektów — zmienno , bdy i zoono

331

Warunki stosowania poka-yoke

333

Pomyki jako przyczyny defektów

334

Kontrola zoonoci w rozwoju oprogramowania

336

Pomyki, metody kontroli i poka-yoke

340

Wdraanie systemu poka-yoke

341

Okrelanie rozwizania bazujcego na poka-yoke

345

Kluczowe zagadnienia

346

Dodatkowe materiay

348

wiczenia internetowe

348

Pytania przegldowe

349

Zagadnienia do dyskusji i projekty

349

Przypisy

350

12

Spis treci

ROZDZIA 10. 5S w obszarze inteligentnego zarz dzania rozwojem oprogramowania

353

5S — wielki krok w kierunku produktywnego rodowiska pracy

355

Etapy wdraania systemu 5S Etap 1. Selekcja i sortowanie Etap 2. Organizowanie i porzdkowanie Etap 3. Sprztanie i czyszczenie Etap 4. Standaryzacja Etap 5. Podtrzymywanie i samodyscyplina

356 356 356 357 357 357

System 5S i proces DFTS

358

Ramka 10.1. Od 5S do szczupego procesu DFTS

359

Przeamywanie oporu

362

Wdraanie 5S Etap 1. Przekonywanie zarzdu Etap 2. Szkolenia i wdraanie Etap 3. Powizanie z systemem nagród Etap 4. Kontynuacja i cige usprawnianie

363 363 364 364 365

Kluczowe zagadnienia

365

Dodatkowe materiay

366

wiczenia internetowe

366

Pytania przegldowe

366

Zagadnienia do dyskusji i projekty

367

Przypisy

367

ROZDZIA 11. Zrozumienie potrzeb klienta — QFD w dziedzinie oprogramowania i gos klienta

369

QFD — pocztki i wprowadzenie Czym wyrónia si QFD wród innych systemów jakoci? Historia QFD Historia QFD dla oprogramowania Czym jest QFD i do czego suy? Koncentracja na priorytetach Definicja QFD Rozwinicia QFD Czteroetapowy model QFD Macierz „domu jakoci”

371 372 373 374 376 378 379 380 380 382

Problemy ze stosowaniem tradycyjnej wersji QFD do oprogramowania Niepowodzenia zwizane z tradycyjn wersj QFD

386 386

Spis treci

„Ta macierz jest za dua” „To zajmuje zbyt duo czasu” „Ju to wiemy”

13

387 388 389

Nowoczesna wersja QFD dla oprogramowania Byskawiczna metoda QFD Siedem narzdzi do zarzdzania i planowania (7 ZP) Zadowolenie klienta i warto

391 391 391 391

Byskawiczny 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. Okrelanie priorytetów potrzeb klienta Etap 9. Realizacja priorytetowych potrzeb klientów Póne rozwinicia. Szczegóowa analiza (wycznie) istotnych relacji „Dom jakoci” i nie tylko Projekty Six Sigma Dziaania nastpcze — stosowanie, ewolucja i usprawnianie procesu Byskawiczne programowanie Rozwinicie harmonogramu za pomoc zarzdzania projektem poprzez acuch krytyczny

393 393 395 396 396 397 401 401 402 403 405 406 408 408 408 409

Wprowadzanie QFD dla oprogramowania Czynnik ludzki w QFD Wyzwania i puapki w obszarze QFD Jak wdraa QFD dla oprogramowania?

409 410 410 413

Wnioski Nowoczesna wersja QFD w procesie DFTS

414 414

Kluczowe zagadnienia

415

Dodatkowe materiay

417

wiczenia internetowe

418

Pytania przegldowe

419

Zagadnienia do dyskusji

420

Przypisy

421

14

Spis treci

ROZDZIA 12. Kreatywno i innowacyjno w procesie projektowania oprogramowania — TRIZ i metodologia wyboru koncepcji Pugha

427

Potrzeba kreatywnoci w DFTS

429

Kreatywno i TRIZ

429

Ramka 12.1. Czym jest szczliwy 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 wasno intelektualna

447

Ramka 12.4. Obraz jest wart…

449

Kluczowe zagadnienia

450

Dodatkowe materiay

450

wiczenia internetowe

450

Pytania przegldowe

451

Zagadnienia do dyskusji i projekty

451

Przypisy

451

ROZDZIA 13. Ocena ryzyka oraz analiza przyczyn i skutków bdów (FMEA) w dziedzinie oprogramowania 453 FMEA — analizy przyczyn i efektów bdów

455

Zastosowania FMEA na wczesnych etapach

459

Analizy drzewa bdów oprogramowania

462

Przyczyny bdów w oprogramowaniu i ich róda

465

Okrelanie i ocena ryzyka na poszczególnych etapach DFTS

467

Kluczowe zagadnienia

468

Dodatkowe materiay

469

wiczenia internetowe

469

Pytania przegldowe

469

Zagadnienia do dyskusji i projekty

469

Przypisy

470

Spis treci

15

ROZDZIA 14. Technologie obiektowe i komponentowe oraz inne narzdzia programistyczne

471

G贸wne wyzwania w rozwoju biznesowych aplikacji dla przedsibiorstw

473

Analizy, projektowanie i programowanie obiektowe

473

Ramka 14.1. Narodziny programowania obiektowego

474

Ramka 14.2. Zalety warstwy poredniej jzyka Java

479

Technologia rozwoju oprogramowania na podstawie komponent贸w

481

Poprawa produktywnoci za pomoc programowania ekstremalnego

484

Zwikszanie niezawodnoci przy uyciu programowania wielowersyjnego Zalety NVP Wady NVP

486 487 487

Wsp贸czesne rodowiska programistyczne

488

Trendy w automatyzacji programowania

492

Kluczowe zagadnienia

495

Dodatkowe materiay

495

wiczenia internetowe

496

Pytania przegldowe

496

Zagadnienia do dyskusji i projekty

496

Przypisy

496

CZ III PROJEKTOWANIE OPROGRAMOWANIA GODNEGO ZAUFANIA

499

ROZDZIA 15. Miary jakoci 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 materiay

517

wiczenia internetowe

518

Pytania przegldowe

518

Zagadnienia do dyskusji i projekty

518

Problemy

518

Przypisy

518

16

Spis treci

ROZDZIA 16. Solidne oprogramowanie w kontekcie

521

Proces tworzenia specyfikacji oprogramowania

523

Ramka 16.1. Precyzyjne specyfikacje funkcjonalne

525

Czym jest solidne oprogramowanie?

526

Wymagania, jakie musi spenia solidne oprogramowanie

527

Ramka 16.2. Uzyskiwanie informacji od uytkownika kocowego

528

Ocena solidnoci oprogramowania

528

Ramka 16.3. Przykad projektowania parametr贸w

530

Kluczowe zagadnienia

531

Dodatkowe materiay

531

wiczenia internetowe

531

Pytania przegldowe

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

Przykad z dziedziny inynierii projektu

541

Przykad 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 materiay

553

wiczenia internetowe

553

Pytania przegldowe

553

Zagadnienia do dyskusji

553

Problemy

553

Przypisy

554

ROZDZIA 18. Weryfikacja, walidacja, testy i ocena w rozwoju oprogramowania godnego zaufania

555

Cig dalszy cyklu rozwoju

557

Ramka 18.1. Miejska legenda o oprogramowaniu biznesowym

558

Spis treci

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 materiay

572

wiczenia internetowe

572

Pytania przegldowe

573

Zagadnienia do dyskusji i projekty

573

Problemy

573

Przypisy

573

ROZDZIA 19. Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania

575

Koczenie cyklu rozwoju

577

Integracja

577

Ramka 19.1. Spitfire Supermarine

578

Wzbogacanie

578

Studium przypadku 19.1. Zwikszanie moliwoci elektronicznego systemu do prowadzenia dziaa wojennych

579

Konserwacja

581

Studium przypadku 19.2. Konserwacja system贸w oprogramowania u klienta

582

Ramka 19.2. Usunicie zaawansowanej funkcjonalnoci oprogramowania w wyniku konserwacji

583

Kluczowe zagadnienia

584

Dodatkowe materiay

584

wiczenia internetowe

584

Pytania przegldowe

585

Zagadnienia do dyskusji i projekty

585

Problemy

585

Przypisy

585

18

Spis treci

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

587

ROZDZIA 20. Przygotowanie organizacji do wdra ania DFTS

589

Czas na rozwaania

591

Studium przypadku 20.1. Denie do doskonaego procesu produkcji

591

Studium przypadku 20.2. Instytucjonalizacja Six Sigma w GE

594

Wyzwania stojce przed liderami w trakcie inicjatyw transformacyjnych

598

Ocena kluczowych elementów organizacji Wzbudzanie zaangaowania liderów Zrozumienie roli liderów Ocena strategicznych powiza Zapewnianie zaangaowania caej organizacji Zrozumienie koniecznoci koncentracji na kliencie Ocena obecnego poziomu zarzdzania jakoci

599 600 601 602 602 603 604

Kluczowe zagadnienia

605

Dodatkowe materiay

606

wiczenia internetowe

607

Pytania przegldowe

607

Zagadnienia do dyskusji i projekty

607

Przypisy

608

ROZDZIA 21. Uruchamianie inicjatywy DFTS

609

DFTS i platforma PICS

611

Planowanie

611

Wdraanie Etap 11. Uruchamianie szkole w caej organizacji Projektowanie programu szkole — dostosowanie i zrónicowanie Szkolenia dla personelu pomocniczego Etap 12. Wdraanie technologii DFTS — proces nauki i stosowania

612 613 614 615 616

Kontrola Etap 13. Systemy kontroli informacji zwrotnych

621 624

Studium przypadku 21.1. Cige uczenie si i wzbogacanie — proces Operating System korporacji GE Zarzdzanie projektem

627 631

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

632 632 632

Studium przypadku 21.2. Inicjatywy na rzecz jakoci i ich integracja w TCS

637

19

Spis treci

Zastosowania w maych firmach programistycznych i wioskach elektronicznych

640

Co dalej?

641

Kluczowe zagadnienia

641

Dodatkowe materiay

643

wiczenia internetowe

644

Pytania przegldowe

644

Zagadnienia do dyskusji

645

Przypisy

645

CZ V

SZE STUDIÓW PRZYPADKU

647

ROZDZIA 22. Koszty jakoci oprogramowania (CoSQ) w Raytheon’s Electronic Systems (RES) Group

653

Wprowadzenie

654

Program usprawnie w RES

654

Koszty jakoci oprogramowania Model CoSQ w RES Zbieranie danych CoSQ

655 655 656

Zdobyte dowiadczenia i wiedza Wiedza zdobyta w czasie korzystania z modelu CoSQ Uywanie danych CoSQ do zrozumienia wpywu usprawnie Koszty i zyski z programu CoSQ Instytucjonalizacja kontroli kosztów CoSQ

656 656 657 660 660

Wnioski ze studium przypadku

660

Przypisy

661

ROZDZIA 23. Zarz dzanie portfelem technologii informatycznych

663

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

665 665 668

Cz druga. Nowe, racjonalne podejcie Etap 1. Projekt Etap 2. Strukturyzacja zoonoci — koncentracja na celach Etap 3. Pomiar Etap 4. Synteza Etap 5. Optymalizacja

669 669 670 670 674 676

Ryzyko

679

20

Spis treci

Rozszerzenia

681

Podsumowanie

682

Przypisy

683

ROZDZIA 24. Definiowanie potrzeb klienta przy rozwoju zupenie nowego produktu — QFD dla nowatorskiego oprogramowania

685

Wprowadzenie Definicja wartoci Dlaczego nie zapyta ? Nowatorskie produkty

687 687 688 689

Definiowanie zupenie nowych potrzeb Metody okrelania potrzeb klientów

689 689

Narzdzia Siedem narzdzi do zarzdzania i planowania (7 ZP) w QFD

695 695

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

696 697

Ostatnie kroki Wprowadzanie nowatorskich produktów na rynek

699 699

Warstwy oporu

700

Wnioski

700

Podzikowania

700

Literatura cytowana

702

O autorze

704

ROZDZIA 25. Jurajskie QFD — integrowanie QFD dla usug i produktów

705

Profil firmy MD Robotics

707

Dlaczego QFD? Historia QFD Wymagania Kany

707 708 709

Spotkanie z triceratopsem na wyspie przygód Universal Studio na Florydzie Schemat QFD Analizy gosu klienta Rozwinicie emocji Rozwinicie ciaa Rozwinicie wymaga inynieryjnych

711 711 712 715 718 719

Podsumowanie

720

O autorach

723

Przypisy

723

Spis treci

21

ROZDZIA 26. QFD dla projektów. Lepsze zarz dzanie projektami rozwoju oprogramowania dziki byskawicznemu QFD

727

Wprowadzenie Niepowodzenia Czciowy sukces Zdefiniowane QFD Dobry pocztek

729 729 730 730 730

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

730 731 733

Koncentracja na wartoci w QFD dla projektu Siedem kroków do lepszych projektów

735 735

Podsumowanie

746

Podzikowania

746

Literatura cytowana

747

O autorze

749

ROZDZIA 27. QFD 2000. Integrowanie QFD i innych metod zarz dzania jakoci w celu usprawnienia procesu rozwoju nowych produktów

751

Popyt na nowe produkty

753

Jako i rozwój nowych produktów Wspóczesne narzdzia do zarzdzania jakoci Proces rozwoju nowych produktów

753 754 757

Materiay dotyczce QFD i innych metod zarzdzania jakoci Analityczny proces hierarchiczny (AHP) i analityczny proces sieciowy (ANP) Strategiczne karty wyników Byskawiczna QFD Analizy czne (conjoint) Spotkania z klientami Podejmowanie decyzji z udziaem klientów (CIDM) de Bono Deming Wizyty w gemba i analizy gosu klienta Planowanie hoshin Model Kano Inynieria kansei Badania gównych uytkowników Szczupa produkcja

760 760 761 761 761 761 761 761 761 762 762 762 762 763 763

22

Spis treci

Nowa strategia Lanchestera Programowanie neurolingwistyczne (NLP) Zarzdzanie projektem Wybór koncepcji metod Pugha QFD (wersja kompleksowa) Niezawodno QFD „róda do potrzeb” Siedem narzdzi do zarzdzania i planowania (7ZP) Siedem narzdzi do planowania produktu (7PP) Siedem narzdzi do sterowania jakoci (7SJ) Six Sigma, SPC Inynieria oprogramowania Bramki etapowe Strategiczne systemy informacyjne (SIS) Zarzdzanie acuchem dostaw Metody Taguchiego Teoria ogranicze (TOC) Zarzdzanie przez jako (TQM) TRIZ Inynieria wartoci

763 763 763 763 764 764 764 764 764 764 765 765 765 765 765 765 765 766 766 766

O autorze

766

Literatura cytowana

767

Sowniczek poj technicznych

769

Skorowidz nazwisk

779

Skorowidz

781

ROZDZIA 2

Wyzwania na drodze do oprogramowania godnego zaufania — solidny projekt w kontekcie oprogramowania Projektuj produkty tak, aby nie zawodziy w praktyce. Tym samym zmniejszysz liczb defektów w fabryce. Genichi Taguchi

Poprawa wymaga zmian. Doskonao wynika z czstego ich wprowadzania. Winston Churchill

Omówienie Wieloaspektowe spojrzenie na jako jest kluczowe w identyfikowaniu licznych wymaga klientów i innych partnerów. Wystpuj niezwyke podobiestwa midzy zagadnieniami zwizanymi z jakoci oprogramowania i wyrobów produkowanych, jednak naley uwzgldni take istotne rónice. Koszty powodowane przez oprogramowanie niskiej jakoci s coraz bardziej kluczowe, poniewa koszt cyklu ycia typowego systemu przekracza cen sprztu. Oprogramowanie wyszej jakoci pozwala istotnie zredukowa te koszty, poniewa 80 – 90% ich sumy pochania konserwacja zwizana z poprawianiem, adaptowaniem i rozwijaniem udostpnionego oprogramowania. Obecnie okoo 40% wydatków na rozwój oprogramowania pochaniaj testy potrzebne w celu usunicia bdów. Kluczowa jest take niezawodno oprogramowania, poniewa stosunek bdów wystpujcych w programach do usterek sprztowych moe wynosi 100:1, a nawet jeszcze wicej. W tym rozdziale opisujemy niepowodzenia tradycyjnych systemów zarzdzania jakoci w kontekcie udostpniania oprogramowania godnego zaufania. Proponujemy zintegrowan technologi rozwoju oprogramowania — projektowanie oprogramowania godnego zaufania (ang. Design for Trusthworthy Software — DFTS) — bazujc na trzech kluczowych elementach: iteracyjnym modelu rozwoju solidnego oprogramowania, inynierii optymalizacji projektu oprogramowania i technologii projektowania obiektowego. W DFTS wysiki nad zapewnieniem jakoci koncentruj si na wczesnych etapach procesu rozwoju. Technologia ta

67

68

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

pozwala na cig interakcj z uytkownikami i midzy osobami pracujcymi nad produktem na rónych etapach, pomaga uwzgldni opinie klientów oraz umoliwia wczesn i cig analiz ryzyka, optymalizacj projektu i zastosowanie odpowiedniej technologii rozwoju oprogramowania. W tym rozdziale podkrelamy kluczow rol prawdziwego zaangaowania ze strony menederów na drodze do tworzenia oprogramowania godnego zaufania.

Struktura rozdziau „

Niezawodno oprogramowania — fakty i mity

„

Ograniczenia tradycyjnych systemów kontroli jakoci

„

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

„

Istota metod Taguchiego do tworzenia solidnych projektów

„

Wyzwania na drodze do niezawodnoci oprogramowania — projektowanie oprogramowania godnego zaufania

„

Model rozwoju solidnego oprogramowania — proces DFTS w praktyce

„

Kluczowe zagadnienia

„

Dodatkowe materiay

„

wiczenia internetowe

„

Pytania przegldowe

„

Zagadnienia do dyskusji i projekty

„

Przypisy

Niezawodno oprogramowania โ€” fakty i mity

69

Niezawodno oprogramowania โ€” fakty i mity Jako oprogramowania, podobnie jak jako sprztu, to wieloaspektowe zagadnienie. W rzeczywistoci spojrzenie na jako z kilku perspektyw jest kluczowe do zrozumienia i utworzenia wartociowego produktu oraz zaspokojenia zestawu jawnych i ukrytych potrzeb klienta. Producent musi take speni wymania wielu innych partnerรณw, takich jak audytorzy, dostawcy, zwizki branowe, media i inne zainteresowane grupy. W kocu, co nie najmniej istotne, kady wytwรณrca musi si upewni , e jego produkty s opacalne i konkurencyjne, aby mogy spenia potrzeby wacicieli przedsibiorstw. Jako obejmuje wszystkie takie potrzeby i wymagania. Czsto mona usysze , e zagadnienia zwizane z jakoci w wiecie oprogramowania s inne ni w przypadku innych produktรณw, jednak nie do koca jest to prawd. Ogรณlnie mรณwic, zasady, systemy i metodologie jakociowe stosowane do produkcji wyrobรณw s rรณwnie prawidowe w przypadku oprogramowania, sprztu i innych dรณbr czy usug. Jednak oprogramowanie ma specyficzne rodowisko projektowania i rozwoju, ktรณre trzeba zrozumie . Ponadto naley pozna specyficzne wyzwania wynikajce z abstrakcyjnej natury systemรณw cyfrowych oraz poziomu zoonoci wielu aplikacji, a take wzi pod uwag innowacyjno i trudno zada, do ktรณrych rozwizywania zostay zaprojektowane. Wierzymy, e w organizacjach zajmujcych si rozwojem oprogramowania oraz takich, dla ktรณrych tworzenie aplikacji jest istotn dziaalnoci, zagadnienia zwizane z architektur i projektowaniem s kluczowe dla dugoterminowej opacalnoci i powodzenia firmy. We wszystkich takich organizacjach te zadania s zbyt wane, aby pozostawi je wycznie inynierom oprogramowania. Problem produkcji oprogramowania godnego zaufania jest prawdziwym wyzwaniem i wymaga cakowitego zaangaowania kadry zarzdzajcej. W tej ksice przedstawiamy podstawy filozoficzne, system zarzdzania oraz technologi do zarzdzania jakoci oprogramowania zarรณwno w duych, jak i maych firmach, ze szczegรณlnym uwzgldnieniem oprogramowania dla przedsibiorstw.

Podobiestwa i rรณ nice midzy oprogramowaniem i wyrobami produkowanymi Zrozumienie rรณnic midzy oprogramowaniem i produkowanymi wyrobami jest niezbdne do zaprojektowania solidnego systemu zarzdzania jakoci oprogramowania. Jedynie wtedy mona zaadaptowa systemy i metodologie, ktรณre przez ostatnie 50 lat miay tak znaczcy wpyw na popraw jakoci wszelkich dรณbr produkowanych, a take innych wyrobรณw i usug. Trzeba jednak uwzgldni take wane rรณnice, aby prawidowo rozwin system zarzdzania jakoci oprogramowania. Poniej opisane s pewne zwizane 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 przykad 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 powizane wanie z projektem. Dlatego problemy z jakoci i niezawodnoci s zawsze wynikiem bdów projektowych, które s z kolei wynikaj z pewnych braków poznawczych. x

W oprogramowaniu nie ma niczego, co mona porówna do produkcji czy montau, kiedy to mona zrekompensowa , a nawet naprawi bdy popenione na etapie projektowania. W przypadku oprogramowania produkcja w zasadzie nie ma miejsca. Sam kod programu jest po prostu dalszym etapem projektu. Ponadto nie mona tu powiedzie , e produkt jest „wykonany i dostarczony”. Zawsze mona zaprojektowa aplikacj od nowa, zmodyfikowa j lub zaktualizowa , a przez to zmieni . Ta charakterystyczna dla oprogramowania elastyczno czsto prowadzi do podejcia „dostarczmy to teraz — bdy zawsze bdziemy mogli poprawi póniej”.

x

W odrónieniu od wyrobów produkowanych, w przypadku oprogramowania nie ma odpowiednika etapu analizy projektu. Wikszo analiz (testów) trzeba przeprowadza na kodzie programu. Dlatego problemy lub pomyki projektowe mog pozosta ukryte a do pónych etapów procesu rozwoju lub nawet do czasu rozpoczcia korzystania z aplikacji.

Mona take zauway , e obecnie dziaalno wielu producentów sprztu w coraz wikszym stopniu zaley od oprogramowania. Takie zoone systemy winduj na nastpny poziom wyzwania w zakresie projektowania programów.

Niezawodno oprogramowania — fakty i mity

71

Porównywanie niezawodnoci oprogramowania i sprztu Zawodno sprztu wynika gównie z fizycznych bdów pojedynczych komponentów, co jest czsto konsekwencj przewrotnoci natury. Z kolei w oprogramowaniu usterki charakteryzuj si niecigym dziaaniem systemów cyfrowych. Wiedza o projektowaniu i inynierii urzdze jest atwiejsza do udokumentowania w celu zapobieenia bdom ni wiedza o oprogramowaniu. Ponadto teorie awarii sprztu s rozwijane od lat i umoliwiaj zapewnienie wysokiej niezawodnoci w wyrobach produkowanych1. Dla porównania, baza wiedzy o niezawodnoci oprogramowania jest bardzo maa — std nieodczne problemy w zapewnianiu stabilnoci dziaania aplikacji. Oprogramowaniu zawsze towarzysz urzdzenia. Jeli jednak znana jest niezawodno komponentu sprztowego, zawsze mona zoptymalizowa pewno dziaania systemu, doczajc jedynie komponenty programowe2. Kady system skadajcy si z oprogramowania i sprztu moe zawie z powodu usterek aplikacji wywoanej za pomoc zewntrznych polece. Awaria oprogramowania jest definiowana jako odchylenie od oczekiwanych wyników zewntrznych lub niezgodno danych wyjciowych programu z okrelonymi wymaganiami. Oprogramowanie moe zawie , kiedy jest uywane w nieoczekiwanej sytuacji. Zwykle awaria moe wystpi z winy oprogramowania lub nieprzewidzianych warunków jego wykorzystania. Inaczej mówic, aby wystpi bd, program trzeba uruchomi . Biecy trend kosztów systemów sprztowo-programowych zmierza w kierunku nieproporcjonalnej dominacji oprogramowania. Koszt cyklu ycia (LCC) typowego oprogramowania przekracza cen sprztu, a 80 – 90% tych wydatków wie si z konserwacj aplikacji w zakresie naprawiania, adaptowania i rozwijania udostpnionego programu w celu zaspokojenia zmieniajcych si i rosncych potrzeb uytkowników. Okoo 40% ceny rozwoju oprogramowania pochaniaj testy majce na celu usunicie bdów i zapewnienie wysokiej jakoci programu3. Stosunek zawodnoci oprogramowania do sprztu moe wynosi a 100:1 w typowych komputerach bazujcych na obwodach scalonych4. Dla bardziej skomplikowanych chipów ten stosunek moe by jeszcze wyszy, co daje bardzo wyrane wskazówki dotyczce kosztów i jakoci. W tabeli 2.1 zamieszczono przegld podstawowych rónic midzy niezawodnoci sprztu i oprogramowania.

Przyczyny zawodnoci oprogramowania Zawodno oprogramowania to istotny problem spoeczny. W rzeczywistoci ma on globalne znaczenie i na jego rozwizanie powica si znaczne zasoby. W poniszych punktach opisujemy podstawowe przyczyny zawodnoci oprogramowania. x

Brak zaangaowania kadry zarzdzajcej. Najczstsz przyczyn problemów z jakoci jest brak zaangaowania, powicenia i wsparcia kadry zarzdzajcej. Deming5 oszacowa kiedy, e powody zwizane z zarzdzaniem mog odpowiada

72

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

TABELA 2.1. Rónice i podobiestwa w niezawodnoci sprztu i oprogramowania

Kategoria

Niezawodno sprztu

Podstawowa przyczyna

Z powodu efektów fizycznych

6

Niezawodno oprogramowania Z powodu bdów programisty (lub defektów albo awarii programu)

Przyczyny w cyklu ycia Analizy

Nieprawidowe zrozumienie klienta Nieprawidowe zrozumienie klienta

Wykonalno

Bdne wymagania uytkownika

Projekt

Bdy w fizycznym projekcie

Bdy w projekcie programu

Rozwój

Problemy z kontrol jakoci

Bdy w kodzie programu

Dziaanie

Usterka i awaria

Bdy programu (lub inne defekty albo awarie)

Bdne wymagania uytkownika

Efekty stosowania Funkcja projektu Dziedziny Relacje czasowe Modele matematyczne

Obszar czasu

Funkcje

Obszar danych

Sprzt zuywa si i zaczyna zawodzi Oprogramowanie nie zuywa si, ale zawodzi w wyniku nieznanych defektów lub bdów Fizyka bdu Umiejtnoci programisty Czas (t) Czas i dane „Krzywa wannowa” Funkcja malejca Dobrze rozwinita teoretycznie Dobrze rozwinita teoretycznie, i akceptowana ale o niskiej akceptacji R = f(, t),  = intensywno bdów R = f(bdy [lub defekty albo Wykadnicza (staa ) awarie], t) Weibulla (rosnca ) Bez znaczenia

Brak zgodnoci midzy rónymi proponowanymi modelami funkcji czasu Bdy = f(testy na danych)

Modele wzrostu

Istnieje kilka modeli

Istnieje kilka modeli

Miary

, MTBF (ang. mean time between failures, czyli redni czas pomidzy awariami)

Intensywno bdów, liczba wykrytych lub pozostaych defektów (lub awarii)

MTTF (ang. mean time to failure, czyli redni czas do wystpienia 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.

73

Niezawodno oprogramowania — fakty i mity

TABELA 2.1. Rónice i podobiestwa w niezawodnoci sprztu i oprogramowania — cig dalszy

Kategoria

Niezawodno sprztu

Niezawodno oprogramowania

Techniki wzrostu

Projektowanie, przewidywanie

Przewidywanie

Techniki przewidywania

Diagramy blokowe, drzewa bdów Analiza cieek (analiza wszystkich cieek to nierozwizywalny problem, poniewa liczba moliwoci w nawet prostych programach moe zmierza do nieskoczonoci), zoono , symulacje

Testy i ewaluacja

Akceptacja projektu i produkcji

Akceptacja projektu

MIL-STD-781C (wykadnicze) Inne metody (niewykadnicze)

Testowanie cieek, symulacje, bdy, posiew Bayesa

MIL-STD-781C

Brak

Równolego

Moe poprawia niezawodno

Trzeba rozway najczstsze przyczyny

Rezerwa

Automatyczne wykrywanie i poprawianie bdów, automatyczne wykrywanie usterek i przeczanie

Automatyczne wykrywanie i poprawianie bdów, automatyczne kontrolowanie i ponowne inicjowanie oprogramowania

Logika wikszociowa

m elementów z n

Niepraktyczna

Projekt Operacje Zastosowanie nadmiaru

za okoo 85% ogólnych problemów z jakoci 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

Niewystarczajca interakcja z uytkownikami. rodowisko i wymagania uytkowników nie zostay prawidowo zrozumiane. Powszechnie uwaa si, e naley dy do poznania opinii klientów i dobrze zrozumie oraz zinterpretowa ich jawne i niejawne wymagania. Niestety, udzia uytkowników w rozwoju oprogramowania po napisaniu i uzgodnieniu specyfikacji jest czsto znikomy. Ten brak cigej interakcji z uytkownikami oraz ich zmieniajcymi si i ewoluujcymi wymaganiami nie zawsze jest dostrzegany w procesie rozwoju oprogramowania. Jest to istotna przyczyna problemów z jakoci oprogramowania i trzeba temu powici naleyt uwag.

x

Rosnca zoono. Systemy oprogramowania s tworzone do obsugi problemów o rosncej zoonoci. Czsto nie ma rcznych rozwiza, które mogyby pomóc w zrozumieniu natury istniejcych trudnoci. Oprogramowanie umoliwia

74

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

projektantowi zmierzenie si z ogromnymi trudnociami i udostpnienie dodatkowych funkcji oraz udogodnie, które nie zawsze zwikszaj prawdziw warto programu. Zoone systemy oprogramowania uywane do automatycznej kontroli lotu, w silnikach do masowego wyszukiwania, w handlu elektronicznym czy do zarzdzania globalnymi przelewami gotówki w rónych walutach nie maj rcznych odpowiedników, z którymi mona je porówna . Trudno i innowacyjno prowadz do zoonoci oraz zwizanych z ni komplikacji projektowych i poznawczych, z czego wynikaj wyzwania w rozwoju oprogramowania w obszarze niezawodnoci, bezpieczestwa i zabezpiecze. x

Brak uzgodnionych kryteriów. W nowych i zoonych systemach programista czsto tworzy kryteria niezawodnoci, które nie zawsze speniaj wymagania uytkowników.

x

Presja czasu zwizana z konkurencyjnoci. Konkurencyjna potrzeba skracania czasu cyklu rozwoju („moemy to póniej naprawi , ale dostarczy musimy na czas”) w niemal nieunikniony sposób prowadzi do bdów w projekcie i na innych etapach. Bardzo czsto po prostu brakuje czasu na wyczerpujce testy i usuwanie bdów.

x

Ograniczony zakres automatyzacji. Rozwój i stosowanie oprogramowania to operacje w duym stopniu bazujce na czynniku ludzkim. Narzdzia 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

Powizanie z Internetem. Coraz szersze zastosowania i integracja systemów oprogramowania z Internetem naraa je na zagroenia wynikajce z przypadku lub celowo szkodliwej dziaalnoci. Niebezpieczestwo moe by bardzo powane: od kradziey tosamoci, przez masowe oszustwa finansowe, po zagroenie narodowego systemu bezpieczestwa.

x

Abstrakcyjne dziaanie systemów cyfrowych. Naturalnie abstrakcyjne dziaanie systemów cyfrowych sprawia, e trudno zapewni jako oprogramowania.

x

Brak odpowiednich zacht. Czsto bodce rynkowe i regulacyjne w zakresie niezawodnoci oprogramowania s niewystarczajce, podczas gdy istnieje wiele czynników promujcych innowacyjne funkcje, wygod stosowania i byskawiczny cykl rozwoju.

Ograniczenia tradycyjnych systemów kontroli jakoci Praktyki zapewniania jakoci zwykle koncentruj si na pónych operacjach, takich jak produkcja lub testy (zobacz rysunki 2.1 i 2.2). Takie podejcie nie zawsze prowadzi do optymalnego projektu nawet w przypadku duej liczby powtarzanych cykli projekt-prototyp-testy, które zasadniczo przebiegaj przy uyciu metody prób i bdów. Ma to wpyw

75

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

na koszty, czas trwania cyklu i jako produktu dostarczanego klientowi, jeli udostpniane oprogramowanie nie ma odpowiednich waciwoci w zakresie wydajnoci. Bardzo czsto dzieje si tak, poniewa meneder produktu nie ma czasu i rodkĂłw, a musi udostpni projekt w fazie produkcyjnej. Na dalszych etapach produkty s sprawdzane i przesiewane w celu wykrycia jednostek, ktĂłre s niezgodne ze specyfikacj. Te jednostki s naprawiane, przetwarzane lub odrzucane. Takie systemy kontroli jakoci bazuj na dwĂłch podstawowych zaoeniach: x

Wymagania klientĂłw s spenione, jeli produkt znajduje si w ramach uzgodnionych ogranicze wyznaczanych przez specyfikacj.

x

Biznesowe skutki wydajnoci lub jakoci produktów „ledwo speniajcych wymagania specyfikacji� i „na poziomie docelowym� s takie same.

Jak si wkrótce okae, adne z tych zaoe nie jest uzasadnione. W. Edwards Deming7 by jednym z pierwszych analityków zarzdzania, którzy zdali sobie spraw z braków systemów jakoci zalenych od kontroli. Jednak to japoski inynier przemysowy Genichi Taguchi jako pierwszy zaproponowa alternatywny system zarzdzania jakoci, nazywany metodami Taguchiego. To podejcie zwraca uwag na warto „poziomu docelowego� i potrzeb zarzdzania jakoci ju na pocztku procesu — w dziale bada i rozwoju, na etapach projektu i inynierii cyklu rozwoju oprogramowania — a nie polegania na kontroli majcej na celu wykrywanie i naprawianie bdów.

Japoskie systemy zarz dzania jakoci i podejcie Taguchiego Metody Taguchiego to zestaw zasad i metodologii projektowych majcych na celu usprawnienie produktĂłw i procesĂłw. Te techniki skadaj si na dziedzin wiedzy nazywan inynieri jakoci, solidn inynieri czy, zwaszcza w Stanach Zjednoczonych, metodami Taguchiego od nazwiska autora tego podejcia, 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 znaczcy wpyw na powstanie metodologii zarzdzania jakoci skoncentrowanej na projekcie. Taguchi urodzi si w 1924 roku w Japonii. Po subie w Wydziale Astronomicznym Instytutu Nawigacji Japoskiej Marynarki Wojennej w latach 1942 – 1945 pracowa w Ministerstwie Zdrowia i Opieki oraz Instytucie Statystycznym Ministerstwa Edukacji. Zyska bogat wiedz na temat technik projektowania eksperymentalnego i stosowania tablic ortogonalnych, uczc si od nagradzanego japoskiego statystyka Matosaburo Masuyamy, z którym zetkn si w czasie pracy w Ministerstwie Zdrowia i Opieki. Doprowadzio to do jego zaangaowania jako konsultanta w firmie Morinaga Pharmaceuticals i jej organizacji nadrzdnej, Morinaga Seika.

76

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

W 1950 roku Taguchi doczy do nowo powstaego Laboratorium Komunikacji Elektrycznej w Nippon Telephone and Telegraph Company z zadaniem zwikszenia wydajnoci dziau bada i rozwoju poprzez szkolenie inynieró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 inynieri (zobacz ramka 2.2). Wtedy by take konsultantem japoskiego przemysu. W wyniku tego japoskie firmy, midzy innymi Toyota i jej dostawcy, zaczy, poczwszy od wczesnych lat 50., szeroko stosowa metody Taguchiego. Pierwsza ksika Taguchiego, która przedstawiaa tablice ortogonalne, zostaa 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 sawnymi statystykami: Ronaldem A. Fisherem i Walterem A. Shewhartem. W latach 1957 – 58 Taguchi opublikowa pierwsz wersj swej dwutomowej pracy Design of Experiments. Do Stanów Zjednoczonych przyby po raz pierwszy w 1962 roku jako zaproszony czonek grupy badawczej na Uniwersytecie Princeton. W tym czasie odwiedzi AT&T Bell Laboratories. W Princeton Taguchi by gociem powaanego statystyka Johna Tukeya, który uatwi mu wspóprac ze statystykami przemysowymi 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 ksik Management by Total Results, która zostaa przetumaczona na jzyk chiski przez Yuin Wu, wspópracownika Taguchiego przy wielu póniejszych pracach. Na tym etapie metody Taguchiego byy praktycznie nieznane na Zachodzie, cho stosowano je w Tajwanie i Indiach. W tym czasie i w latach 70. wikszo zastosowa metod Taguchiego dotyczya procesów produkcji. Przejcie do projektowania produktów miao miejsce póniej. We wczesnych latach 70. Taguchi rozwin zagadnienie funkcji utraty jakoci. Wtedy te opublikowa dwie dalsze ksiki oraz trzecie wydanie pracy Design for Experiments. Taguchi zosta laureatem nagrody Deming Application Prize w 1960 roku oraz nagród Deminga za pozycje ksikowe 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. Udao mu si, mimo problemów z komunikacj, przeprowadzi udane eksperymenty, które pozwoliy zastosowa metody Taguchiego w korporacji Bell Laboratories. Po wizycie Taguchiego w Stanach Zjednoczonych w 1980 roku coraz wicej amerykaskich fabryk zaczo stosowa jego metodologi. Mimo niechtnego przyjcia tych metod przez grono amerykaskich statystyków, co prawdopodobnie wynikao ze sposobu ich rozpowszechniania, najwiksze korporacje Stanów Zjednoczonych zaczy stosowa metodologi Taguchiego. W 1982 roku Taguchi zosta doradc japoskiej Organizacji do spraw Standardów. Za wkad w rozwój przemysu na caym wiecie Taguchi otrzyma wiele wyrónie: x

trzykrotnie nagrod Deming Prize za wkad w dziedzin inynierii jakoci;

x

medal Willarda F. Rockwella za poczenie inynierii i metod statystycznych do osignicia byskawicznych korzyci w zakresie kosztów i jakoci poprzez optymalizacj procesu projektowania i produkcji wyrobów;

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

x

medal imienia Shewharta Amerykaskiego Stowarzyszenia na rzecz Kontroli Jakoci;

x

Niebiesk Wstg cesarza Japonii, przyznan w 1990 roku za wkad w rozwój przemysu;

x

honorowe czonkostwo w Amerykaskim Stowarzyszeniu na rzecz Kontroli Jakoci.

Znalaz si te w motoryzacyjnej galerii saw oraz na wiatowym poziomie galerii saw z dziedziny inynierii, nauki i technologii.

Ramka 2.2. Metodologia inynierii jakoci w zarysie8, 9 Metodologia Taguchiego dotyczy optymalizacji produktu i procesu na etapach projektowania oraz prac dziau bada i rozwoju przed rozpoczciem produkcji. Jest to metodologia zarzdzania jakoci stosowana we wczesnych fazach rozwoju produktu lub procesu, która w mniejszym stopniu koncentruje si na osiganiu jakoci poprzez kontrol. Jest to wydajna technika, obejmujca testy projektu przed rozpoczciem etapu produkcji, fabrykacji lub skadania. Dziki temu jako staje si funkcj prawidowego projektu, a nie nawet cisych testów i kontroli. Podejcia Taguchiego mona uywa take jako metodologii rozwizywania problemów zwizanych z produkcj i procesami w obszarze fabrykowania. Jest te coraz czciej stosowane w innych dziedzinach przemysu, na przykad przy rozwoju oprogramowania. W odrónieniu od zachodniego podejcia do jakoci, w metodologii Taguchiego jako jest postrzegana raczej w kategoriach utraty jakoci ni samej jakoci. Utrata jakoci jest definiowana jako „straty powodowane przez produkt w spoecznoci od momentu jego udostpnienia”. Ta utrata obejmuje straty ponoszone przez firm w postaci kosztów przetwarzania i utylizacji, wydatki na konserwacj oraz przestoje wynikajce z awarii sprztu i napraw gwarancyjnych. Naley uwzgldni take koszty klientów powodowane przez zawodno oraz nisk wydajno produktu, prowadzce do dalszych strat po stronie producenta wcznie ze spadkiem jego udziaów w rynku. Okrelajc docelowy poziom jakoci jako najwyszy moliwy, Taguchi wie prost kwadratow funkcj straty z odchyleniem od poziomu docelowego. Funkcja utraty jakoci pokazuje, e zmniejszanie zmiennoci w zakresie jakoci prowadzi do zmniejszania strat i zwizanej z tym poprawy jakoci. Gdy uwzgldnimy takie podejcie do utraty jakoci, to strata wystpi nawet w przypadku, kiedy produkt spenia wymagania stawiane przez specyfikacj, a jest minimalna, jeli producent dy do poziomu docelowego. W praktyce dla uytkowników nie jest wana specyfikacja, prawda? Klienci chc, aby produkt dziaa nawet wtedy, kiedy napicie prdu jest niskie, droga wyboista, a operator terminala nieprzeszkolony. Produkt musi dziaa na docelowym poziomie w rónych warunkach. Mówic inaczej, naley projektowa z uwzgldnieniem rónych warunków stosowania produktu przez uytkowników. To w interesie producenta ley utrzymywanie wydajnoci produktu lub procesu tak blisko poziomu docelowego, jak to ekonomicznie moliwe. Funkcja straty moe posuy do podjcia decyzji projektowych w kategoriach finansowych. Pomaga zdecydowa , czy dodatkowe koszty zwikszenia odpornoci i usprawnienia produkcji s usprawiedliwione oraz czy oka si zasadne w warunkach rynkowych.

77

78

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

Metod Taguchiego mona uywa w trybie „offline” w czasie projektowania lub na bieco w produkcji. Taguchi dzieli kontrol jakoci w trybie „offline” na trzy etapy. 1. Projektowanie systemu obejmuje tworzenie pomysu na projekt przy uyciu burzy mózgów, bada lub innych technik. Projektowanie systemu jako caoci obejmuje take inne narzdzia, techniki i metodologie, zwaszcza 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 rozdziaach 8., 11., 12. i 13. 2. Projektowanie parametrów to istota metod Taguchiego. To pod tym wzgldem Japoczycy tradycyjnie si wyróniali i osigali wysokie poziomy jakoci bez wzrostu kosztów, co jest gówn przyczyn ich przewagi konkurencyjnej. Testowane s nominalne waciwoci projektu lub wybrane poziomy czynników procesu. Ustalane s kombinacje poziomów parametrów produktu lub poziomów operacji wchodzcych w skad procesu, które okazay si najmniej wraliwe na zmiany w czynnikach rodowiskowych i inne niekontrolowalne elementy (szum). To zagadnienie opisujemy w rozdziaach 16. i 17. 3. Projektowanie odpornoci naley zastosowa do projektu produktu lub procesu, jeli zmniejszenie wariancji uzyskane na etapie projektowania parametrów jest niewystarczajce. Ta faza dodatkowo zwiksza odporno na czynniki majce duy wpyw na wariancj. Naley zastosowa funkcj straty i powici wicej rodków tylko wtedy, jeli jest to konieczne. Mona zwikszy odporno albo kupi lepsze materiay lub wyposaenie, jeli jest to niezbdne, co podkrela japosk filozofi inwestycji na kocu, a nie na pocztku, jak jest to praktykowane w firmach zachodnich.

Ramka 2.3. Taguchi o metodach Taguchiego10 x

Utrata jakoci wynika gównie z awarii produktu po jego sprzeday. „Solidno ” wyrobu jest bardziej funkcj jego projektu ni biecej kontroli, cho by najcilejszej, procesu produkcji.

x

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

x

Udostpniajc produkt, który ledwie spenia standardy korporacji, producent nie zyskuje prawie nic w porównaniu z rozpowszechnianiem wadliwego wyrobu. Naley dy do poziomu docelowego, a nie jedynie mieci si w ramach specyfikacji.

x

Inynieria jakoci (metody Taguchiego) to technologia przewidywania bdów jakociowych i zapobiegania im na wczesnych etapach rozwoju i projektowania produktu, wcznie z problemami zwizanymi 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 uywaj miar jakoci zwizanych z klientem (takich jak procent defektów czy niezawodno ) jako wczesnych miar jakoci w dziale bada i rozwoju. W zamian

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

79

uywaj dynamicznego stosunku SN jako wskanika wydajnoci do oceny solidnoci funkcji produktu. x

Solidne produkty zapewniaj silny „sygna” niezalenie od zewntrznego „szumu” i z minimaln iloci „szumów” wewntrznych. Usprawnienie projektu, czyli znaczcy wzrost w stosunku sygnau do szumu komponentu, zwikszy solidno produktu jako caoci.

x

Naley wytrwale pracowa w celu uzyskania projektów, które mona produkowa na nieustannie wysokim poziomie. Naley stale stawia wysokie wymagania fabryce.

x

Jest wiksze prawdopodobiestwo problemów z powodu duej zmiennoci w obrbie specyfikacji ni staego odchylenia poza ni. Jeli odstpstwo od poziomu docelowego jest stae, moliwe jest dostosowanie procesu do tego poziomu.

x

Warunki panujce w fabryce rzadko s tak szkodliwe, jak zmienno w uytkowaniu produktów przez uytkowników.

Metody Taguchiego zostay uznane za jedno z najwaniejszych inynieryjnych osigni XX wieku. Cho techniki statystyczne uywane przez Taguchiego maj pocztki w eksperymentalnych praktykach projektowych rozwinitych przez angielskiego statystyka sir Ronalda Fishera, ich filozoficzne podstawy s niezaprzeczalnie japoskie. Metody Taguchiego i inne japoskie systemy zarzdzania jakoci, takie jak kaizen (cige usprawnianie), kanban (dokadnie na czas), zarzdzanie przez jako czy szczupa produkcja, zostay zainspirowane rozwaaniami amerykaskiego guru z obszaru jakoci, W. Edwardsa Deminga, przedstawionymi w jego ksikach: 14 Points of Management, Seven Deadly Diseases 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 zarzdzania jakoci pooyy podwaliny pod niezwyky rozwój Japonii jako potgi przemysowej po II wojnie wiatowej. Trudno przeceni wpyw Deminga na prace Taguchiego. Podobnie jak inni japoscy specjalici do spraw jakoci, Taguchi by pod duym wpywem Deminga. Aby zrozumie specyficzne podejcie Taguchiego, naley przeanalizowa jego kontekst i korzenie. Metody Taguchiego i wspóczesne japoskie systemy zarzdzania jakoci miay swe pocztki po II wojnie wiatowej. Deming, którego czsto okrela si mianem ojca wspóczesnego ruchu na rzecz jakoci, po raz pierwszy odwiedzi Japoni w 1946 roku. W nastpnych dziesicioleciach kontynuowa wspóprac z rzdem oraz przemysem japoskim i wyszkoli tysice japoskich menederów oraz inynierów. Ci menederowie byli zainteresowani wspóczesnymi amerykaskimi zasadami zarzdzania. Jednak Deming zaproponowa im co zupenie nowego, co, jego zdaniem, miao pomóc w przeksztaceniu Japonii w dobrze prosperujce spoeczestwo i odbudowa jej pozycj jako znaczcej potgi przemysowej. Istota zasad zarzdzania Deminga jest dobrze znana (zobacz ramk 2.4), cho nie s one zbyt szeroko stosowane poza Japoni. Te zasady obejmuj gos 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. Bd wierny zamiarom usprawniania produktów i usug. Cel to osignicie konkurencyjnoci, pozostanie w grze i zapewnienie miejsc pracy. 2. Zarzd musi zda sobie spraw z wyzwa zwizanych z jakoci, pozna zakres odpowiedzialnoci i przej przywództwo na drodze zmian. 3. Naley przesta uwaa kontrol za najwaniejszy element osigania jakoci. Trzeba wyeliminowa potrzeb masowych inspekcji poprzez wbudowanie jakoci w produkt. 4. Trzeba skoczy z nagradzaniem dziaa na podstawie ceny. W zamian naley minimalizowa koszty czne. Kady produkt powinien by dostarczany przez tylko jednego dostawc, co tworzy dugotrway zwizek bazujcy na lojalnoci i zaufaniu. 5. Naley trwale i nieustannie usprawnia system produkcji i usug, aby poprawi jako oraz wydajno , a tym samym cigle zmniejsza koszty. 6. Trzeba prowadzi szkolenia zawodowe. Jeli ludzie s nieodpowiednio wyszkoleni, nie bd pracowa w taki sam sposób, a to wprowadza zmienno . 7. Naley wdroy system przywództwa. Deming wprowadza rozrónienie midzy przywództwem i nadzorem. Ten drugi bazuje na normach i poziomach. Celem nadzoru powinno by pomaganie ludziom, maszynom i urzdzeniom w lepszym wykonywaniu zada. Nadzór zarzdu wymaga starannego przemylenia, podobnie jak nadzór pracowników odpowiedzialnych za produkcj. 8. Trzeba pozby si lku, aby kady móg wydajnie pracowa dla firmy. 9. Naley znie podziay midzy wydziaami. Osoby odpowiedzialne za badania, projektowanie, sprzeda i produkcj musz pracowa jako zespó, aby przewidywa problemy z wytwarzaniem i stosowaniem produktów lub usug. 10. Trzeba pozby si sloganów, napomnie i norm dla siy roboczej, które dotycz braku defektów i nowych poziomów produktywnoci. Takie napomnienia prowadz wycznie do powstawania antagonizmów. Wikszo przyczyn niskiej jakoci i wydajnoci ley po stronie systemu i tym samym znajduje si poza kontrol siy roboczej. 11a. Naley wyeliminowa standardy pracy (normy) dla fabryki. Trzeba zastpi je przywództwem. 11b. Trzeba wyeliminowa zarzdzanie przez zadania oraz liczby (z celami numerycznymi) i zastpi je przywództwem. 12a. Naley 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 zarzd i inynierów prawa do dumy z pracy. Oznacza to midzy innymi rezygnacj z dorocznych rankingów wydajnoci i zarzdzania przez cele. 13. Naley wprowadzi dynamiczny program edukacji i samodoskonalenia. 14. Trzeba zachci wszystkie osoby w firmie do pracy nad przeksztaceniami. Transformacja to zadanie dla wszystkich.

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

81

wspópracowników oraz cige usprawnianie w obszarze procesów, a take produktów i usug. W Japonii podejcie Deminga byo z entuzjazmem studiowane i stosowane oraz miao znaczcy wpyw na przemys tego kraju. W 1951 roku Japoskie Stowarzyszenie Naukowców i Inynierów (ang. Japanese Union of Scientists and Engineers — JUSE) uhonorowao Deminga, nazywajc jego imieniem prestiow nagrod z dziedziny jakoci. Jednak w Stanach Zjednoczonych teorie Deminga byy ignorowane przez prawie 30 lat. Uwaa si, e mogo to doprowadzi do utraty konkurencyjnoci wielu gazi amerykaskiego przemysu, takich jak motoryzacja i AGD, w których japoskie korporacje poczyniy ogromne postpy. Wiele prac Taguchiego byo inspirowanych 14 punktami zarzdzania Deminga. W szczególnym stopniu dotyczy to zasady braku zalenoci od inspekcji przy osiganiu jakoci. W procesie rozwoju produktu Taguchi cofn si jeszcze o krok, kadc nacisk na inspekcj w dziale bada i rozwoju oraz na etapie projektowania i inynierii. Zwraca uwag na znaczenie tego, aby produkt dziaa na staym, docelowym poziomie, a nie by tylko ledwie zgodny ze specyfikacj. Na rysunkach 2.3, 2.4 i 2.5 zademonstrowalimy, e mona to osign w dwóch krokach. Najpierw naley zmniejszy wariancj, a nastpnie dostosowa odpowiedni czynnik, aby osign wyniki moliwie jak najblisze docelowym wymaganiom klienta, trzeba te wzi pod uwag koszty, projekt i inne ograniczenia.

RYSUNEK 2.3. Rozkad wydajnoci w granicach specyfikacji, ale niestaej i poniej poziomu docelowego

RYSUNEK 2.4. Rozkad wydajnoci staej, ale poniej poziomu docelowego

82

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

RYSUNEK 2.5. Rozkad wydajnoci staej i w pobliu poziomu docelowego

Ponadto Taguchi podkrela warto tolerancji projektu zarówno w rodowisku produkcyjnym, jak i rodowisku uytkownika. W tym momencie warto przedstawi gówne nakazy filozofii jakoci Taguchiego. Oto one. 1. Ciga poprawa jakoci i redukcja kosztów s niezbdne dla przetrwania biznesu. 2. Wan miar jakoci produktu jest strata ogólna spowodowana przez produkt w spoeczestwie obliczana za pomoc funkcji straty jakoci. 3. Zmiana przedprodukcyjnych procedur eksperymentalnych z rónicowania jednego czynnika na raz na modyfikowanie wielu czynników jednoczenie. 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 mona wbudowa w produkt i proces. 4. Straty klienta wynikajce z niskiej jakoci s mniej wicej proporcjonalne do kwadratu odchylenia cech wydajnoci od poziomu docelowego (wartoci nominalnej). Taguchi zmieni cele eksperymentów i definicj jakoci z osigania zgodnoci ze specyfikacj na denie do poziomu docelowego i minimalizacj zmiennoci. 5. Zmienno wydajnoci produktu (lub usugi) mona zmniejszy , sprawdzajc nieliniowy wpyw czynników (parametrów) kontrolnych na cechy wydajnoci. Wszelkie odchylenia od poziomu docelowego prowadz do niskiej jakoci. Jednym z gównych celów Taguchiego jest usprawnienie projektu produktu i procesu poprzez wykrycie kontrolowalnych czynników i ich wartoci, co minimalizuje zmienno w stosunku do wyniku docelowego. Ustawiajc kontrolowalne parametry na ich optymalny poziom, mona sprawi , e produkt bdzie bardziej odporny na zmiany w dziaaniu, stosowaniu i warunkach rodowiskowych. Podstawowa zasada metod Taguchiego dotyczy raczej usuwania negatywnych efektów przyczyn ni powodów tych niekorzystnych skutków. Dziki temu mona uzyska produkt wyszej jakoci najmniejszym moliwym kosztem. Ta strategia neutralizacji samych skutków, a nie przyczyn, jest mdrym rozwizaniem, poniewa moe by atwiejsza, a take bardziej wydajna ze wzgldu na koszty i szybsza. Metody Taguchiego maj dwa kluczowe cele projektowe:

Istota metod solidnego projektowania Taguchiego

83

x

zmniejszenie i minimalizacj zmiennoci produktu i ekonomiczne osignicie poziomu docelowego,

x

zapewnienie tolerancji mierzonej na etapach tworzenia projektu i prototypu, które jest przenoszone na dalsze fazy w produkcji i rodowisku uytkownika.

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 dziaanie technologii, produktu lub procesu jest w minimalnym stopniu naraone na czynniki powodujce zmienno (zarówno w produkcji, jak i rodowisku uytkownika) przy najniszym koszcie wyprodukowania jednostki”. Jest to zdolno produktu lub procesu do funkcjonowania i speniania wymaga klientów (ze wzgldu na niezawodno , bezpieczestwo, zabezpieczenia i tak dalej), mimo obecnoci rónych czynników zakócajcych, które mog powodowa zmienno . Solidny proces lub produkt dziaa w oczekiwany sposób niezalenie od wszelkich szkodliwych wpywów, zwanych szumem. Szum wynika z wszelkiego rodzaju zmiennoci: rodowiskowej wariancji w trakcie stosowania produktu przez klienta, zmiennoci w czasie produkcji poszczególnych jednostek i komponentów oraz zrónicowania komponentów w wyniku starzenia si i pogarszania cech.

Zagadnienie stosunku sygnau do szumu Wedug Taguchiego na solidno trzeba zwróci uwag na etapie projektowania lub w dziale bada i rozwoju. Wie si to ze specyficznym filozoficznym zaoeniem, e prawdziw solidno mona jedynie zaprojektowa i wbudowa w produkt lub projekt, a nie skontrolowa i naprawi . Mówic inaczej, podstawowym hasem jest „zapobiega , a nie leczy ”. Wymaga to take rozwizywania problemów na pocztku pracy, w dziale bada i rozwoju, w trakcie zaawansowanej inynierii i projektowania, a nie w trakcie produkcji i kontroli lub, co gorsza, po dostarczeniu produktu do klienta. Metody Taguchiego zapewniaj wydajn ze wzgldu na koszty i czas metodologi projektowania oraz testowania produktów pod ktem solidnoci przed rozpoczciem ich produkcji. Metody te su take do rozwizywania problemów rónego rodzaju czy modyfikowania projektów wadliwych procesów. Poniej znajduj si definicje niektórych podstawowych poj uywanych w metodach Taguchiego. Sygna to co, co produkt (lub cz albo podzespó) ma dostarcza , zgodnie z jego charakterystyk dziaania lub funkcjonaln. W odbiorniku telewizyjnym lub telefonie sygnay to co, co produkt (odbiornik lub aparat) przekazuje jako obraz lub dwik. Dobry sygna to taki, który zachowuje jako mimo szumu (wewntrznych i zewntrznych 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 powodujcych szum, takich jak sposób stosowania przez uytkownika (najczstsza przyczyna zmiennoci), warunki na drodze czy pogoda, nie mona kontrolowa lub wyeliminowa . To szum powoduje odchylenia charakterystyk dziaania i funkcjonalnych od docelowej jakoci. Mona wyróni trzy typy czynników zwizanych z szumem: x

Szum zewntrzny, nazywany take szumem rodowiskowym, obejmuje czynniki zewntrzne (rodowiskowe), takie jak interferencje cieplne lub elektromechaniczne, szoki mechaniczne i elektryczne, kurz czy nieprawidowe korzystanie ze sprztu przez uytkownika. W przypadku samochodu te czynniki obejmuj temperatur, nieg, drog, warunki jazdy, kurz i tak dalej.

x

Szum wewntrzny, zwany take wariancj komponentów lub wewntrznym pogarszaniem sprawnoci czci, wynika ze zuywania si i starzenia.

x

Szum midzy produktami, nazywany take wariancj produkcyjn lub wariancj elementów, dotyczy zmiennoci obecnej midzy poszczególnymi produktami, mimo e s tworzone wedug tych samych specyfikacji. Moe to wynika ze zmiennoci w zakresie materiaów i procesów.

Szumy powoduj, e produkty dziaaj niezgodnie ze specyfikacj lub cakowicie zawodz. Dziaanie produktu jest zdominowane przez szum jednostkowy (wewntrzny) na wczesnych etapach cyklu ycia produktu, zewntrzny w trakcie stosowania i pogarszanie sprawnoci (midzy produktami) pod koniec ycia. Solidno i solidne projektowanie prowadz do braku wraliwoci na czynniki powodujce szum na rónych etapach cyklu ycia produktu, cho wpywów tych nie mona wyeliminowa i usuwane s jedynie ich efekty. Dla odbiorników telewizyjnych powszechnym szumem jest „nieenie” ekranu, pioruny, sztormy, wahania napicia i inne niekorzystne warunki dziaania. W przypadku oprogramowania kluczowe czynniki zwizane z szumem, które powoduj zmienno , to nieprawidowe korzystanie z aplikacji przez klientów, napastnicy i hakerzy, robaki i wirusy, przypadkowe lub celowo zoliwe naruszenie zabezpiecze, brak dokumentacji, nieodpowiednie szkolenia, awarie procedur, niedozwolony dostp i uywanie oraz korzystanie z systemu do wykonywania zada, do których nie jest przeznaczony. Taguchi sugeruje, e jako miary jakoci naley uywa stosunku sygnau do szumu, SN (ang. signal-to-noise)12. Taguchi twierdzi, e stosunek SN: x

moe suy do oceny solidnoci funkcji produktu, poniewa reprezentuje funkcjonalno ;

x

reprezentuje stosunek tolerancji (lub „redni” w terminologii statycznej) do zmiennoci;

x

kiedy stosuje si go do oceny solidnoci produktu lub procesu, naley go okrela mianem przetwarzalnoci (w energi, moc, informacj, obraz, dat i tak dalej).

Istota metod solidnego projektowania Taguchiego

85

Przykadowo dla urzdzenia elektromechanicznego, takiego jak silnik elektryczny, stosunek SN mona wyrazi w nastpujcy sposób:

Ogólnie stosunek SN w systemach bazujcych na inynierii, takich jak silniki czy generatory, mona opisa w poniszy sposób:

W przypadku oprogramowania jest to przeksztacanie informacji, danych, obrazów i innych elementów, a nie energii czy mocy. Solidne projektowanie zarówno w dziedzinie oprogramowania, jak i sprztu, ma maksymalizowa stosunek SN pod ktem optymalizacji projektu.

Zagadnienie funkcji utraty jakoci Jak ju wspomnielimy, to zagadnienie jest podstawowym odstpstwem od zachodniego podejcia do jakoci. Taguchi zajmuje si bardziej utrat jakoci ni ni sam, a take skutkami takich strat dla klienta, producenta i spoecznoci jako ogóu. Jasno wynika z tego, e jako produktu to co wicej ni tylko niezawodno , a koszty produktu obejmuj nie tylko cen produkcji i rachunki za materiay. Klienci oczekuj niezawodnoci w czasie trwania cyklu ycia produktu, a w ostatecznym rozrachunku istotna jest optymalizacja kosztów tego cyklu. Klienci coraz bardziej domagaj si bezbdnych dostaw i dziaania. Oczekuj rónych dodatkowych funkcji i udogodnie. Coraz czciej te poszukuj stabilnego, wysokiej jakoci dziaania na poziomie docelowym i nie zadowalaj si niestabilnym funkcjonowaniem w ramach specyfikacji. Zapewnienie dziaania na poziomie docelowym moe wymaga poniesienia znaczcych kosztów, ale te zapewnia korzyci zarówno producentowi, jak i klientom. Jest to jedna z podstawowych zasad metodologii Taguchiego. Fowlkes i Creveling klasyfikuj koszty cyklu ycia wedug nastpujcych kategorii13: x

koszty dóbr, które obejmuj faktury za materiay oraz wydatki na produkcj;

x

koszty powizane z obsug konserwacji, gwarancjami, naprawami, wymianami, utylizacj i odzyskiwaniem;

x

koszty klienta, które obejmuj przestoje, koszty operacyjne i wynikajce z rozwizywania bdów;

x

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 jakoci jest definiowana jako „strata, któr produkt powoduje w spoecznoci od czasu jego wprowadzenia”. Obejmuje to straty firmy zwizane z kosztami przeróbek, utylizacji, konserwacji i przestojów wynikajcych z awarii sprztu, a take z roszczeniami gwarancyjnymi. S to równie koszty ponoszone przez klienta w wyniku zawodnoci i sabej wydajnoci produktu, co prowadzi do dalszych strat producenta wraz z utrat udziaów w rynku. Mog pojawi si te straty w spoecznoci, jeli dane produkty lub usugi wi si ze skadowaniem odpadów, zanieczyszczeniem rodowiska, przestpczoci czy zagroeniem bezpieczestwa i zdrowia. Okrelajc warto docelow cech jakociowych na najwyszym moliwym poziomie, Taguchi wie prost kwadratow funkcj straty z odstpstwami od wartoci docelowej. Funkcja utraty jakoci pokazuje, e redukcja zmiennoci w okolicach poziomu docelowego prowadzi do zmniejszania si strat, z czego wynika wzrost jakoci. Ta funkcja suy do podejmowania decyzji projektowych na podstawie czynników finansowych i pozwala okreli , czy dodatkowe koszty, jakich wymaga wysza jako , oka si warte poniesienia z perspektywy rynku. Z punktu widzenia producenta czne koszty mona wyrazi w nastpujcy sposób:

czne koszty wynikajce z rezygnacji z jakoci = straty produkcyjne+utrata jakoci

Straty produkcyjne obejmuj utylizacj, przeróbki, opónienia i tak dalej. Utrata jakoci to koszt awarii produktów, który powstaje po ich udostpnieniu. Obejmuje to straty w wyniku zwrotów, gwarancji i napraw, a take utraty dobrej opinii, co prowadzi do zmniejszenia udziaów w rynku. Utrata Jakoci moe by bardzo dua nawet wtedy, kiedy produkt jest zgodny ze specyfikacj. Ta warto jest równa zeru tylko wtedy, kiedy produkt dziaa dokadnie na poziomie docelowym. Taguchi proponuje przybliony i atwy wzór na funkcj utraty jakoci (ang. quality loss function — QLF): Utrata = O2K, gdzie O = odstpstwo od poziomu docelowego; K = koszty rodków niezbdnych do zapewnienia dziaania produktu na poziomie docelowym.

To wyraenie jest przyblieniem, a nie „prawem natury”10. Jest to narzdzie dla inynierów, a nie prawo naukowe. Wskazuje jedynie na fakt, e wystpuje „prawo rosncych kosztów” wraz z odchylaniem si dziaania produktu od poziomu docelowego. Trudno utworzy ogólny i dokadny model kosztów. Jedn z przyczyn tej trudnoci jest to, e produkt moe mie rónych uytkowników i by uywany w zmienny sposób w odmiennych warunkach rodowiskowych. Taguchi sugeruje, e firmy majce lepsze sposoby szacowania kosztów powinny uywa wanie ich. Jednak przedstawiona wczeniej wersja przyblienia funkcji QLF jest wartociowa z nastpujcych wzgldów.

Istota metod solidnego projektowania Taguchiego

87

x

Zapewnia inynierom i menederom prosty sposób szacowania kosztów odchyle od poziomu docelowego.

x

Pozwala okreli na podstawie takich szacunków poziom docelowy tolerancji i jakoci.

x

Stanowi wydajny pod wzgldem czasu i kosztów proces szacowania optymalnego projektu. Inaczej mówic, proces projektowania lepszego produktu jest taszy i szybszy ni w przypadku tradycyjnego projektowania eksperymentów czy innych metod.

QLF i stosunek SN to dwie miary jakoci w metodach Taguchiego. Oba te wskaniki kad nacisk na dziaania pocztkowe (projektowe), a przy ocenie jakoci bazuj na miarach zwizanych z klientem, takich jak koszty w dolarach i cechy dziaania (funkcjonalne). Jak piszemy w rozdziaach 16. i 17., wskaniki te s powizane ze sob i stanowi wartociowe miary w metodologiach Taguchiego.

Zagadnienie solidnego projektowania Taguchi zaleca nastpujc strategi solidnego projektowania: x

Stosowanie tablic ortogonalnych do przeprowadzania eksperymentów na sucho. Tablica ortogonalna to macierz, która jest integraln czci metod Taguchiego. Analiza produktu lub procesu pod ktem solidnoci obejmuje identyfikacj czynników zakócajcych, które powoduj odchylenia. Moe to by mudne i kosztowne zadanie. Taguchi zaprojektowa tablice ortogonalne w celu wyizolowania czynników zakócajcych sporód innych w sposób wydajny ze wzgldu na czas i koszty. Zastosowanie tej techniki do rozwoju oprogramowania jest opisane w rozdziale 17.

x

Maksymalizacja miar wydajnoci i stosunku SN w celu optymalizacji projektu z uwzgldnieniem czynników kontrolnych.

Solidne projektowanie za pomoc metod Taguchiego przebiega w trzech nastpujcych etapach: x

Projektowanie systemu, zwizane z rozwojem zarysu lub prototypu projektu. Jest to niezbdne w celu zdefiniowania wyjciowych cech produktu lub procesu. Ta faza w swej istocie przypomina projektowanie systemów stosowane na zachodzie.

x

Projektowanie parametrów. Jest to kluczowy etap solidnego projektowania, w którym Japoczycy wyróniaj si, tworzc solidne produkty niszym kosztem. Jest to metodologia redukujca zmienno poprzez zmniejszenie wraliwoci produktu lub procesu w zakresie wydajnoci na róda 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 poczenia poziomów parametrów produktu lub poziomów operacyjnych procesu,

88

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

które s najmniej wraliwe na zmiany w warunkach rodowiskowych i inne niekontrolowalne czynniki (szum). Jest to istota metod Taguchiego w zakresie solidnego projektowania. x

Projektowanie tolerancji, które, jeli to konieczne, suy dalszemu zmniejszaniu zmiennoci poprzez zwikszenie odpornoci na czynniki majce duy wpyw na wariancj. Na tym etapie stosowana jest funkcja utraty jakoci w celu sprawdzenia, czy koszt poprawy jakoci jest uzasadniony ekonomicznie. Inwestycje w zwikszenie tolerancji poprzez zastosowanie lepszych materiaów i sprztu naley wprowadza wtedy, kiedy wymaga tego rynek, a nie jako wyjciowe podejcie.

W rozdziaach 16. i 17. opisujemy metody Taguchiego oraz sposób ich przystosowania do rozwoju oprogramowania. Ich zastosowanie na pocztkowych etapach rozwoju oprogramowania jest przedstawione w rozdziaach 18. i 19.

Wyzwania na drodze do niezawodnoci oprogramowania — projektowanie oprogramowania godnego zaufania Oprogramowanie to najbardziej zdradliwy komponent kadego systemu informatycznego. Dwa pozostae elementy, sprzt i sieci komunikacyjne, uzyskay przez ostatnie 50 lat duo wyszy poziom wydajnoci i niezawodnoci. Na przykad wydajno mikroprocesorów wzrosa w stopniu o okoo 200 milionów razy wyszym ni wydajno oprogramowania. Wspóczesne sieci komunikacyjne umoliwiaj przenoszenie olbrzymich iloci danych, obrazów i dwiku oraz dostp do nich zarówno w obrbie organizacji, jak i globalnie. Wspóczesne sieci komunikacyjne, a zwaszcza Internet, wi si z grob przypadkowego lub celowego nieupowanionego dostpu oraz s podatne na inne zagroenia, jednak to braki projektowe w oprogramowaniu odpowiadaj za najwiksz cz wraliwoci i zawodnoci systemów informacyjnych. Nawet mimo niezwykego poziomu wydajnoci sprztu, ostateczne wyniki dziaania kadego systemu informatycznego zale od niezawodnoci oprogramowania — i to jest tematem niniejszej ksiki. W tabeli 2.2 opisujemy pewne czsto stosowane definicje i atrybuty jakoci oprogramowania. 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 pojcie samej jakoci. Jako oprogramowania mona zdefiniowa jako stopie speniania wymaga lub oczekiwa klientów albo uytkowników przez system, komponent lub proces. Moe to obejmowa kilka elementów, z których najczciej wymieniana jest wiarygodno oprogramowania. Zwizana jest ona z rónymi wymaganiami uytkownika, wczajc w to niezawodno , bezpieczestwo, zabezpieczenia i dostpno 14. Jest to bliskie uywanemu w tej ksice pojciu oprogramowania godnego zaufania, które jednak obejmuje dodatkowo moliwo zdobywania zaufania klientów i spenianie ich jawnych, Wyzwania na drodze do niezawodnoci oprogramowania

Wyzwania na drodze do niezawodnoci oprogramowania

89

TABELA 2.2. Wybrane atrybuty zwizane z jakoci oprogramowania

Jako oraz atrybuty i systemy jakoci

Opis

Jako

Stopie, w jakim systemy, komponenty lub procesy speniaj, po pierwsze, jawne, niejawne i nieoczekiwane potrzeby lub oczekiwania klientów i uytkowników oraz, po drugie, okrelone i ukryte wymagania innych partnerów.

Projektowanie pod ktem Six Sigma

System projektowania i rozwoju nowych produktów, procesów i usug, które speniaj wymagania klientów i s pozbawione defektów.

Projektowanie oprogramowania godnego zaufania (DFTS)

System projektowania i rozwoju oprogramowania, na którym mona polega (obejmuje to niezawodno , bezpieczestwo, zabezpieczenia, dostpno i moliwo 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 take modelem rozwoju solidnego oprogramowania — RSDM)

Model rozwoju oprogramowania sucy do tworzenia oprogramowania godnego zaufania (zobacz rysunek 2.6).

Solidne projektowanie

Metodologia utworzona przez Genichiego Taguchiego w celu rozwoju najniszym moliwym kosztem produktów i procesów dziaajcych na poziomie docelowym zgodnie z wymaganiami klienta, mimo obecnoci czynników, które powoduj zmienno w rodowisku uytkownika i produkcyjnym.

Six Sigma

Filozofia, system zarzdzania i metodologia stosowane w celu usprawniania istniejcych produktów, procesów i usug tak, aby byy pozbawione bdów i speniay wymagania klientów w ekonomiczny sposób.

Oprogramowanie

Programy komputerowe, procedury i (zwykle) zwizane z nimi dokumentacja oraz dane dotyczce dziaania systemu komputerowego.

Dostpno oprogramowania

Moliwo udostpniania przez oprogramowanie okrelonych funkcji, kiedy uytkownik ich potrzebuje.

Wiarygodno oprogramowania

Stopie, w jakim systemy, komponenty lub procesy producenta oprogramowania potrafi spenia okrelone wymagania oraz potrzeby i oczekiwania uytkowników.

90

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

TABELA 2.2. Wybrane atrybuty zwizane z jakoci oprogramowania — cig dalszy

Jako oraz atrybuty i systemy jakoci

Opis

Solidno oprogramowania

Obejmuje, wród innych atrybutów, niezawodno , bezpieczestwo, zabezpieczenia i dostpno .

Projekt oprogramowania

Architektura i kod programu wykonujcego okrelon funkcj.

Moliwo konserwacji oprogramowania

atwo modyfikowania systemów lub komponentów oprogramowania po ich udostpnieniu w celu naprawy bdów, poprawy dziaania i innych cech lub zaadaptowania do zmienionego rodowiska. Czsto okrela si j jako MTBF/(MTBF + MTTR).

Jako oprogramowania

Zdatno oprogramowania do uytku. Stopie, w jakim oprogramowanie ma okrelony zestaw atrybutów potrzebnych do speniania jawnych lub ukrytych potrzeb klienta i zapewnia jego zadowolenie. Prawidowe dziaanie programu jest niezbdne, ale niewystarczajce, jeli oprogramowanie nie zapewnia satysfakcji klienta.

Atrybuty jakoci oprogramowania

Róne wymagania dotyczce oprogramowania, takie jak niezawodno , bezpieczestwo, zabezpieczenia i dostpno , potrzebne do spenienia okrelonych lub ukrytych potrzeb.

Niezawodno oprogramowania

To pojcie jest zwizane z jakoci projektu oprogramowania. Wie si raczej z wykrywaniem bdów ni ich naprawianiem. Jest to moliwo wykonywania okrelonej funkcji przez system lub komponent oprogramowania w okrelonych warunkach i czasie.

Bezpieczestwo oprogramowania

Brak czynników, które mog spowodowa mier , obraenia, chorob, uszkodzenia, brak kontroli lub dostpu do danych, naruszenie prywatnoci lub szkody w sprzcie, mieniu i rodowisku.

Skalowalno oprogramowania

Moliwo uruchomienia aplikacji komputerowej na wikszej maszynie lub procesorach równolegych w celu obsugi wikszej liczby transakcji lub zapewnienie wyszej przepustowoci tak, aby wydajno skalowaa si liniowo lub prawie liniowo pod wzgldem iloci operacji. Oznacza to, e jeli aplikacja potrafi obsugiwa okrelon liczb transakcji na danym serwerze, powinna skalowa si tak, aby obsugiwaa cztery razy wiksz ich liczb na czterokrotnie wikszym serwerze.

Wyzwania na drodze do niezawodnoci oprogramowania

91

TABELA 2.2. Wybrane atrybuty zwizane z jakoci oprogramowania — cig dalszy

Jako oraz atrybuty i systemy jakoci

Opis

Zabezpieczenia oprogramowania

Cechy oprogramowania dotyczce jego odpornoci na atak i zapewniajce ochron poufnoci, integralnoci danych oraz dostpnoci systemu.

Szybko realizacji transakcji przez oprogramowanie

Tempo obsugi transakcji przez aplikacj na danym komputerze, zwykle mierzone w tysicach transakcji na minut.

Moliwo aktualizowania oprogramowania

Moliwo atwej zmiany konfiguracji oprogramowania w celu obsugi wikszej liczby, wikszych lub bardziej skomplikowanych transakcji.

Przetwarzanie godne zaufania

System skadajcy si ze sprztu, oprogramowania i sieci, na którym mona polega (obejmuje to niezawodno , bezpieczestwo, zabezpieczenia, dostpno i moliwo konserwacji, cho nie ogranicza si do tych cech) i który umoliwia reagowanie na klienta na rónych etapach cyklu ycia.

Oprogramowanie godne zaufania

Oprogramowanie, na którym mona polega (obejmuje to niezawodno , bezpieczestwo, zabezpieczenia, dostpno i moliwo konserwacji, cho nie ogranicza si do tych cech) i które umoliwia reagowanie na klienta na rónych etapach cyklu ycia.

niejawnych, a nawet nieoczekiwanych potrzeb, a cechy te s tu bardzo istotne. Pi gównych wyzwa zwizanych z tworzeniem oprogramowania godnego zaufania to zapewnienie nastpujcych cech: x

Niezawodnoci, czyli moliwoci wykonywania przez oprogramowanie oczekiwanych funkcji w okrelonych warunkach i czasie. Jest to jako zwizana z projektem oprogramowania i dotyczy raczej wykrywania bdów ni ich naprawiania.

x

Bezpiecze stwa, które dotyczy nieobecnoci czynników mogcych spowodowa mier , obraenia, chorob, uszkodzenia, brak dostpu lub kontroli danych, naruszenie prywatnoci czy szkody w sprzcie, mieniu lub rodowisku.

x

Zabezpiecze , zwizanych z odpornoci oprogramowania na atak, co zapewnia ochron poufnoci i integralnoci danych oraz dostpu do systemu.

92

Rozdzia 2 โ€ข Wyzwania na drodze do oprogramowania godnego zaufania

RYSUNEK 2.6. Model rozwoju solidnego oprogramowania

x

Moliwoci konserwacji, ktรณra dotyczy atwoci modyfikowania systemรณw lub komponentรณw oprogramowania po ich udostpnieniu w celu naprawy bdรณw, poprawy dziaania lub innych cech albo adaptacji produktu do zmieniajcego si rodowiska.

x

Reagowania na klienta, czyli moliwoci producenta zwizanych z uzyskiwaniem i interpretowaniem wymaga klienta oraz reagowaniem na nie. Wymaga to take

Wyzwania na drodze do niezawodnoci oprogramowania

93

obecnoci odpowiednich cech solidnego projektu oprogramowania, moliwoci prowadzenia szkole i przekazywania wiedzy, umiejtnoci pomocy w integracji istniejcych systemów, udostpniania pomocy technicznej po wdroeniu, moliwoci udostpniania zaktualizowanego oprogramowania i systemów oraz speniania wymaga klientów w zakresie kosztów i harmonogramu dostarczania produktów. Szczególnie istotna jest moliwo zdobywania zaufania klientów i spenianie 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 zalenoci od kategorii oprogramowania i jego zastosowa. Przykadowo reagowanie na klienta to szczególnie wany element w przypadku oprogramowania dla przedsibiorstw. Wane jest tu, aby twórca oprogramowania zna i uwzgldnia gos klienta (ang. voice of customer — VOC), interpretowa go prawidowo i móg na tej podstawie tworzy oprogramowanie godne zaufania. Warto poczyni pewne uwagi na temat zwrotu „godne zaufania”. W dziedzinie zarzdzania jakoci tego wyraenia po raz pierwszy uy Deming, który stosowa je w znaczeniu czynnika decydujcego o wyborze dostawców w kontekcie „usuwania lków” wród pracowników. Uwaamy zastosowanie tego sowa przez Deminga i kontekst, w jakim go uywa, za bardzo znaczce dla komunikatu, który sami chcemy przekaza : godne zaufania i niezawodne oprogramowanie, a w zasadzie dowolny produkt i kada usuga, mog by udostpniane tylko przez osoby godne zaufania. Tego zwrotu uyto take w programie przetwarzania godnego zaufania (ang. Trushworthy Computing — TWC) Microsoftu uruchomionym w 2002 roku. Prezes Microsoftu, Bill Gates, w przeomowych powiadomieniach przesanych w styczniu i lipcu 200215 do 50000 pracowników korporacji na caym wiecie napisa: „W przeszoci staralimy si, aby nasze oprogramowanie i usugi byy atrakcyjne dla klientów ze wzgldu na nowe funkcje i przez moliwo bogatego rozszerzania naszej platformy […] wykonalimy pod tym wzgldem doskona robot, jednak wszystkie te wspaniae moliwoci oka si nieistotne, jeli klienci nie bd ufa naszym produktom. Dlatego teraz w sytuacji wyboru midzy nowymi funkcjami i rozwizywaniem problemu z zabezpieczeniami musimy stawia na zabezpieczenia”. Gates ponadto napisa, e wierzy, i TWC „bdzie najwyszym priorytetem dla firmy i przemysu przez nastpn dekad — celem jest utworzenie dla klientów rodowiska przetwarzania godnego zaufania, które jest równie niezawodne, co elektryczno zasilajca obecnie nasze domy i firmy”. Zapewnienie oprogramowaniu równej niezawodnoci, co w przypadku elektrycznoci, to olbrzymie wyzwanie dla przemysu zwizanego z produkcj oprogramowania. Wyranie wida potrzeb wspópracy midzy przemysem rozwoju oprogramowania, profesjonalistami z brany oprogramowania, uytkownikami oprogramowania, agencjami odpowiedzialnymi za regulacje i instytutami badawczymi na caym wiecie. Proponowana w tej ksice metodologia DFTS zapewnia spójn struktur i technologi do rozwizywania tego typu problemów z jakoci.

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 inynierii to przykad czystego projektu. Jak ju wspomnielimy, zawodno oprogramowania to zawsze wynik bdów w projekcie i intelektualnych braków czowieka16. Dlatego jeszcze bardziej istotny jest w tym przypadku moment, w którym rozwizywane s problemy z jakoci. Filozofia i systemy proponowane w tej ksice zapewniaj twórcom oprogramowania dziaajc na wczesnych etapach metodologi, która pozwala zidentyfikowa optymalne funkcje i ustawienia solidnego (godnego zaufania) oprogramowania. Omówione wczeniej elementy systemu s przedstawione w proponowanym przez nas modelu rozwoju solidnego oprogramowania (ang. Robust Software Development Model — RSDM) utworzonym jako uatwienie do rozwoju oprogramowania godnego zaufania (zobacz rysunek 2.6). Ten model spenia siedem kluczowych wymaga procesu rozwoju solidnego oprogramowania omówionego w rozdziale 1. Bazuje na logicznych zasadach zarzdzania i sprawdzonych narzdziach, technikach i metodologiach charakteryzujcych si nastpujcymi kluczowymi elementami: x

Infrastruktur zapewniajc organizacji konieczne przywództwo i system komunikacji, szkole oraz nagród, który wyranie wspiera proces DFTS (zobacz rozdzia 5.).

x

Niezawodnym systemem zbierania danych, który pozwala prawidowo wykrywa wymagania uytkowników (VOC) w iteracyjny sposób na rónych etapach cyklu rozwoju oprogramowania (zobacz rozdzia 11.).

x

Wdraaniem metod Taguchiego w celu optymalizacji projektowania oprogramowania i jednoczenie uwzgldniania rónych wymaga klienta, takich jak niezawodno , koszty i czas trwania cyklu (zobacz rozdziay 16. i 17.).

x

Ustanowieniem praktyki jednoczesnego pisania kodu i przeprowadzania testów oraz zapewniania wystarczajcego czasu na usuwanie bdów. Ta strategia prowadzi do procesu debugowania wydajnego ze wzgldu na koszty i czas, poniewa informacje o nateniu lub czstotliwoci bdów oprogramowania s wtedy szybciej dostpne (zobacz rozdzia 18.).

x

Tworzeniem wielu wersji programu17 w sytuacji, kiedy potrzebne jest nadmiarowe oprogramowanie. Sprawia to, e statystycznie awarie nadmiarowych kopii s tak niezalene, jak to moliwe. W tym celu w rónych programach naley stosowa odmienne jzyki programowania, narzdzia programistyczne, technologie rozwoju i strategie testowania (zobacz rozdzia 14.).

x

Wdraaniem odpowiednich narzdzi do zarzdzania jakoci i planowania, takich jak QFD, TRIZ, Pugh i FMEA, które s szeroko stosowane w produkcji, co jest zgodne z najlepszymi praktykami (zobacz odpowiednio rozdziay 11., 12. i 13.).

Kluczowe zagadnienia

x

95

Stosowaniem innowacyjnych narzdzi do rozwoju oprogramowania, takich jak projektowanie obiektowe (ang. Object-Oriented Design — OOD), programowanie ekstremalne czy odpowiednie narzdzia CASE.

Bdziemy na zmian odnosi si do modelu RSDM i procesu DFTS — model opisuje proces, a proces jest ilustrowany przez model. W kilku ostatnich dziesicioleciach wyewoluoway liczne modele rozwoju oprogramowania. Wiele z nich, na przykad model wodospadu, etapowe modele cyklu ycia, model spiralny czy model V, maj swe pocztki w lotnictwie i innych gaziach przemysu produkcyjnego, dlatego nie zawsze odpowiadaj rzeczywistoci procesu rozwoju oprogramowania. RSDM to model iteracyjny, który umoliwia interakcj zarówno z wewntrznymi, jak i z zewntrznymi klientami oraz uchwycenie VOC w procesie rozwoju. Ponadto jest solidny i elastyczny, a take mona go dostosowa do dowolnego procesu rozwoju oprogramowania. W nastpnych rozdziaach opisujemy zastosowania tego modelu i jego elementy ze szczególnym uwzgldnieniem kontekstu rozwoju oprogramowania dla przedsibiorstw. Chcemy przypomnie , e w organizacjach zajmujcych si rozwojem oprogramowania i w innych firmach, w których prace nad technologiami informatycznymi stanowi istotn dziaalno , rozwój oprogramowania jest zbyt wany, aby pozostawi go samym inynierom oprogramowania. Zarzdzanie t aktywnoci naley do obowizków prezesa i wyszej kadry zarzdzajcej. Musz oni zapewni niezbdne przywództwo, utworzy prawidow infrastruktur zarzdzania i rozwija rodowisko pod ktem tworzenia oprogramowania godnego zaufania.

Kluczowe zagadnienia x

Wieloaspektowe spojrzenie na jako jest niezbdne do zrozumienia i spenienia zestawu jawnych oraz niejawnych wymaga klientów i innych partnerów.

x

Zazwyczaj zasady, systemy i metodologie zarzdzania jakoci odpowiednie dla wyrobów produkowanych mona stosowa take dla oprogramowania. Jednak oprogramowanie wie si ze specyficznym rodowiskiem projektowania i rozwoju. Trzeba zrozumie zoono czsto zwizan z oprogramowaniem i uwzgldni innowacyjno oraz trudno zada, do których obsugi jest projektowane.

x

Zadanie utworzenia oprogramowania godnego zaufania to prawdziwe wyzwanie i wymaga istotnego zaangaowania kadry zarzdzajcej.

x

Tradycyjne systemy kontroli jakoci bazuj na dwóch bdnych zaoeniach: po pierwsze, wymagania klienta s spenione, jeli 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.

x

14 punktów zarzdzania Deminga sucych do poprawy jakoci obejmuje wsuchiwanie si w gos 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 cige usprawnianie. Deming wskazuje na braki systemów zarzdzania jakoci zalenych od kontroli. x

Japoski inynier przemysowy Genichi Taguchi rozwin alternatywny system zarzdzania jakoci — metody Taguchiego. Taguchi podkrela warto „poziomu docelowego” i zaleca dbao o jako na wczesnych etapach, zamiast zalenoci od kontroli majcych wykry i naprawi bdy w dalszych fazach rozwoju.

x

Filozofi zarzdzania jakoci Taguchiego mona podsumowa w nastpujcy sposób: x

Ciga poprawa jakoci i redukcja kosztów s konieczne dla przetrwania biznesu.

x

Wan miar jakoci jest ogólna strata wygenerowana przez dany produkt w spoecznoci, mierzona funkcj utraty jakoci.

x

Naley wbudowa jako w produkt lub proces poprzez projekt, uywajc techniki statystycznego projektowania eksperymentów.

x

Straty klientów z powodu niskiej jakoci s nieliniowe i mone je oszacowa jako kwadrat odchylenia cech dziaania od ich poziomu docelowego.

x

Zmienno dziaania produktu mona zmniejszy , analizujc nieliniowy wpyw „czynników kontroli” na cechy funkcjonowania.

x

Solidne projektowanie przy uyciu metod Taguchiego przebiega w trzech fazach: projektowania systemu, projektowania parametrów i projektowania tolerancji.

x

Oprogramowanie godne zaufania spenia liczne jawne i niejawne potrzeby klientów, a take musi umoliwia dostosowanie produktu do nich. W kontekcie oprogramowania dla przedsibiorstw oprogramowanie godne zaufania musi spenia przynajmniej nastpujce wymagania: niezawodno , bezpieczestwo, zabezpieczenia, moliwo konserwacji i reagowanie na klienta.

x

Proces DFTS charakteryzuje si okrelonymi cechami. Oto one: x

prawdziwe zaangaowanie kadry zarzdzajcej i wspierajca to infrastruktura;

x

moliwo identyfikacji jawnych i niejawnych wymaga za pomoc QFD;

x

optymalizacja wymaga klienta poprzez wdroenie metod Taguchiego;

x

ustanowienie praktyki jednoczesnego pisania kodu i przeprowadzania testów;

x

stosowanie w razie koniecznoci nadmiarowego oprogramowania;

x

wdraanie odpowiednich narzdzi do zarzdzania jakoci i planowania, takich jak TRIZ, Pugh i FMEA;

x

stosowanie innowacyjnych narzdzi do rozwoju oprogramowania, takich jak projektowanie obiektowe.

Dodatkowe materiay

97

Dodatkowe materiay http://www.prenhallprofessional.com/title/0131872508 http://www.agilenty.com/publications

wiczenia internetowe http://www.asiusa.com/publications/images/HBR.pdf Po przeczytaniu artykuu Taguchiego i Clausinga dostpnego pod powyszym adresem przygotuj si do dyskusji wniosków na jego temat. 1. Przeanalizuj problemy zwizane ze stylem mylenia „w ramach specyfikacji — poza specyfikacj” powizanym z podejciem „zero defektów” w kontekcie oprogramowania. Jakie rozwizanie oferuje metodologia Taguchiego? 2. Podaj trzy przykady „sygnau” i „szumu” w kontekcie rozwoju oprogramowania. 3. Zaproponuj zestaw zalece umoliwiajcych usprawnienie procesu rozwoju oprogramowania. Ten artyku jest dostpny take w nastpujcych miejscach: x

Genichi Taguchi i Don Clausing, Robust Quality, „Harvard Business Review”, Stycze – Luty 1990.

x

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 przykadami zwizanymi ze znanym Ci oprogramowaniem. 2. Czy problemy z jakoci oprogramowania s zasadniczo odmienne od wystpujcych w wyrobach produkowanych? Jakie s podobiestwa i rónice midzy oprogramowaniem i wyrobami produkowanymi w zakresie procesu ich rozwoju? 3. Porównaj niezawodno oprogramowania i sprztu. Wyjanij skutki takiego stanu rzeczy na przykadzie trzech zoonych systemów skadajcych si z oprogramowania i sprztu. 4. Wymie gówne powody zawodnoci oprogramowania. Które z nich uwaasz za najwaniejsze? 5. Opisz dwa najwaniejsze problemy z tradycyjnymi systemami kontroli jakoci i wpyw, jaki maj na oprogramowanie.

98

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

6. Opisz istot 14 punktów zarzdzania Deminga i wyjanij ich znaczenie w dzisiejszym wiecie. 7. Wyjanij, jak metody Taguchiego wi si z zaleceniami Deminga wymienionymi w 14 punktach i jak je wspieraj. 8. Jak brzmi pi filozoficznych nakazów podejcia Taguchiego? Wyjanij ich zwizek z rozwojem oprogramowania. Czy w przypadku sprztu s one inne? Jeli 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. Wyjanij, jak te waciwoci oraz sam model jako cao mona porówna z dwoma podobnymi modelami opisanymi w rozdziale 1.

Pytania do dyskusji i projekty 1. Jak 14 punktów zarzdzania Deminga rozwizuje ograniczenia tradycyjnych systemów kontroli jakoci? Moesz posuy si tabelami 5.2, 5.3 i 5.4 z rozdziau 5. Jak zastosowa wskazówki Deminga do brany rozwoju oprogramowania? Przedstaw odpowied na zajciach. 2. Omów i porównaj zastosowanie metodologii Taguchiego w przypadku oprogramowania dla przedsibiorstw i produktów fabrykowanych. Moesz posuy si materiaem z rozdziaów od 16. do 19. Przedstaw odpowied na zajciach. 3. Opisz zalety i wyzwania zwizane z wdraaniem w organizacji metodologii projektowania oprogramowania godnego zaufania (DFTS). Jakie s moliwe róda oporu przy jej wprowadzaniu? Jak mona sobie z nimi poradzi ? Przedstaw odpowied na zajciach. 4. Wyobra sobie, e jeste czonkiem zespou zarzdzajcego wysokiego stopnia kierowanego przez prezesa. Zespó otrzyma od zarzdu firmy zajmujcej si rozwojem oprogramowania zadanie identyfikacji gównych przyczyn problemów z jakoci oprogramowania i zaproponowania platformy umoliwiajcej ich rozwizanie. Napisz informacj dla zarzdu po wstpnej ocenie. Zaprezentuj j na zajciach.

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). Naley zwróci szczególn uwag na punkt 3. z 14 punktów o zarzdzaniu.

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”, stycze – luty 1990, s. 68.

11

Zaadaptowane z ksiki 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, Addison-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.


Oprogramowanie_godne_zaufania_Metodologia_techniki_i_narzedzia_projektowania_bezopr