Wydawnictwo Helion

ul. Koœciuszki 1c

44-100 Gliwice

tel. [phone]

e-mail: [e-mail]

Bezpieczne oprogramowanie.

Metodologia, techniki

i narzêdzia projektowania

Autor: Bijay K. Jayaswal, Peter C. Patton

ISBN: 978-83-246-1463-9

Tytu³ orygina³u:

Design for Trustworthy

Software: Tools, Techniques, and Methodology

of Developing Robust Software

Format: 172x245, stron: 816

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

• Jak przeprowadziæ weryfikacjê, oceniaæ i konserwowaæ oprogramowanie?

• Jakie s¹ finansowe aspekty tworzenia oprogramowania godnego zaufania?

• Jak zarz¹dzaæ portfelem technologii informatycznych?

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!

Spis treci

5

Spis treci

Wprowadzenie

23

Przedmowa

25

Podzikowania

31

O autorach

33

CZ I

W

SPÓCZESNY PROCES ROZWOJU APLIKACJI

,

JEGO BRAKI I WYZWANIA

NA

DRODZE DO

OPROGRAMOWANIA GODNEGO ZAUFANIA

35

ROZDZIA 1.

Wspóczesne metodologie rozwoju oprogramowania

37

Rozwój oprogramowania — potrzeba nowego paradygmatu

39

Ramka 1.1. Zoono komputerów

41

Strategie rozwoju oprogramowania i modele cyklu ycia

42

Model utwórz i popraw

44

Model wodospadu

45

Model byskawicznych prototypów

45

Model przyrostowy

46

Programowanie ekstremalne

48

Model spiralny

49

Programowanie obiektowe

50

Rozwój iteracyjny, czyli model ewolucyjny

52

Porównanie rónych modeli cyklu ycia

53

Usprawnienia procesu rozwoju oprogramowania

53

Model RUP

54

Model CMM

55

Wytyczne rozwoju oprogramowania ISO 9000-3

56

Porównanie modeli RUP, CMM i ISO 9000

58

Metoda ADR

60

Siedem elementów procesu rozwoju stabilnego oprogramowania

60

Model rozwoju solidnego oprogramowania

61

Ramka 1.2. Krytyczne oprogramowanie 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

69

Podobiestwa i rónice midzy oprogramowaniem i wyrobami produkowanymi

69

Porównywanie niezawodnoci oprogramowania i sprztu

71

Przyczyny zawodnoci oprogramowania

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

83

Zagadnienie stosunku sygnau do szumu

83

Zagadnienie funkcji utraty jakoci

85

Zagadnienie solidnego projektowania

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

Spis treci

7

Metodologia pomiarów

106

Wewntrzprocesowe miary jakoci do testowania oprogramowania

107

Miary zoonoci oprogramowania

109

Nauka o oprogramowaniu

110

Zoono cyklomatyczna

112

Miary punktów funkcyjnych

113

Miary zadowolenia klienta i dostpnoci

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

134

Korzyci pynce z analiz kosztów jakoci

134

Koszty zada nakierowanych na popraw jakoci

135

Klasyfikacja kosztów jakoci oprogramowania

137

Ustanawianie systemu tworzenia raportów CoSQ

146

Korzyci inwestycji w jako

148

Warto analiz CoSQ

149

Puapki zwizane z programem CoSQ

149

Koszty jakoci oprogramowania w cyklu ycia

150

Studium przypadku 4.1. Zastosowanie CoSQ w Intents Software

152

CoSQ i kosztorysowanie bazujce na aktywnociach

157

ABC w firmach zajmujcych si rozwojem oprogramowania

157

Uruchamianie ABC przy rozwoju oprogramowania

158

Korzyci stosowania ABC

159

Ramka 4.1. ABC w przemyle usugowym

160

8

Spis treci

Funkcja utraty jakoci w przypadku oprogramowania

160

Finansowa ocena inwestycji w DFTS

161

Miary oceny DFTS

161

Tworzenie platformy oceny finansowej programów DFTS

162

Kluczowe zagadnienia

164

Dodatkowe 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

173

Etap 1. Budowanie wiadomoci zarzdu i przekonywanie go

174

Etap 2. Komunikowanie o zgodnoci i zaangaowaniu wyszej

kadry zarzdzajcej

178

Etap 3. Wykrywanie potencjalnych puapek zwizanych z inicjatyw DFTS

179

Ramka 5.1. Nienaganny cykl nauki i TPOV

188

Etap 4. Kadzenie podwalin pod organizacj skoncentrowan na jakoci

189

Etap 5. Budowanie infrastruktury organizacyjnej

192

Etap 6. Zrozumienie ról kluczowych osób

192

Etap 7. Projektowanie wspomagajcej struktury organizacyjnej

203

Etap 8. Ustanawianie efektywnej komunikacji

205

Etap 9. Tworzenie odpowiedniego systemu nagród

206

Etap 10. Ustanawianie systemu CoSQ

208

Etap 11. Planowanie i uruchamianie szkole w caej organizacji

208

Etap 12. Wdraanie modelu DFTS

209

Etap 13. Kontrolowanie nauki i postpów

oraz przekazywanie informacji zwrotnych

210

Etap 14. Utrwalanie usprawnie i zysków

212

Etap 15. Integracja i rozszerzanie programu

212

czenie wszystkich elementów

213

Kluczowe zagadnienia

214

Dodatkowe materiay

218

wiczenia internetowe

218

Spis treci

9

Pytania przegldowe

219

Zagadnienia do dyskusji i projekty

220

Przypisy

220

CZ II

N

ARZDZIA I TECHNIKI PROJEKTOWANIA OPROGRAMOWANIA

GODNEGO

ZAUFANIA

223

ROZDZIA 6.

Siedem podstawowych narzdzi zarz dzania jakoci (P7)

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

234

Diagramy przebiegu wysokiego poziomu

235

Szczegóowe diagramy przebiegu

235

Torowe diagramy przebiegu

236

Diagramy Pareto

236

Diagramy przyczynowo-skutkowe

237

Tworzenie diagramów przyczynowo-skutkowych w celu okrelenia przyczyn

240

Uywanie diagramów przyczynowo-skutkowych do klasyfikowania procesów

241

Diagramy rozproszenia

243

Arkusze kontrolne

246

Histogramy

246

Okrelanie rozkadu

247

Okrelanie, czy wymogi specyfikacji zostay spenione

248

Porównywanie danych za pomoc warstw

248

Wykresy

248

Karty kontrolne

250

Kluczowe zagadnienia

252

Dodatkowe materiay

254

Pytania przegldowe

254

Zagadnienia do dyskusji

254

Przypisy

255

10

Spis treci

ROZDZIA 7.

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

284

Sownictwo

286

Okrelanie struktury hierarchii celów

286

Hierarchia decyzji

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

290

Etap 1. Burza mózgów i tworzenie hierarchicznego modelu problemu

290

Etap 2. Okrelanie priorytetów celów na skali ilorazowej

292

Etap 3. Okrelanie priorytetów alternatyw z uwagi na kady cel

295

Etap 4. Synteza

297

Przyblianie wyników AHP na podstawie samodzielnych oblicze

298

Pierwsza metoda tworzenia przyblionych rozwiza

302

Druga metoda przybliania. Kompleksowa analityczna metoda kryteriów

do okrelania priorytetów Brassarda

309

Wnioski

312

Kluczowe zagadnienia

313

Spis treci

11

Dodatkowe materiay

314

wiczenia internetowe

314

Pytania przegldowe

314

Zagadnienia do dyskusji i projekty

315

Problemy

315

Problem 1. Zarzdzanie zoonoci przy przeksztacaniu systemów

315

Problem 2. Zarzdzanie zoonoci oprogramowania w nowej firmie

z brany zaawansowanych technologii

318

Problem 3. Zoono w systemach zarzdzania kartami pacjentów

320

Problem 4. System wspomagajcy podejmowanie decyzji

dotyczcych odwiertów ropy naftowej

321

Problem 5. Problem ROI

323

Problem 6. Abstrakcyjne analizy zoonoci

323

Problem 7. Wraliwo na zoono

324

Przypisy

324

ROZDZIA 9.

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

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

356

Etap 1. Selekcja i sortowanie

356

Etap 2. Organizowanie i porzdkowanie

356

Etap 3. Sprztanie i czyszczenie

357

Etap 4. Standaryzacja

357

Etap 5. Podtrzymywanie i samodyscyplina

357

System 5S i proces DFTS

358

Ramka 10.1. Od 5S do szczupego procesu DFTS

359

Przeamywanie oporu

362

Wdraanie 5S

363

Etap 1. Przekonywanie zarzdu

363

Etap 2. Szkolenia i wdraanie

364

Etap 3. Powizanie z systemem nagród

364

Etap 4. Kontynuacja i cige usprawnianie

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

371

Czym wyrónia si QFD wród innych systemów jakoci?

372

Historia QFD

373

Historia QFD dla oprogramowania

374

Czym jest QFD i do czego suy?

376

Koncentracja na priorytetach

378

Definicja QFD

379

Rozwinicia QFD

380

Czteroetapowy model QFD

380

Macierz „domu jakoci”

382

Problemy ze stosowaniem tradycyjnej wersji QFD do oprogramowania

386

Niepowodzenia zwizane z tradycyjn wersj QFD

386

Spis treci

13

„Ta macierz jest za dua”

387

„To zajmuje zbyt duo czasu”

388

„Ju to wiemy”

389

Nowoczesna wersja QFD dla oprogramowania

391

Byskawiczna metoda QFD

391

Siedem narzdzi do zarzdzania i planowania (7 ZP)

391

Zadowolenie klienta i warto

391

Byskawiczny proces QFD

393

Etap 1. Kluczowy cel projektu

393

Etap 2. Kluczowy segment klientów

395

Etap 3. Kluczowe etapy procesu

396

Etap 4. Wizyta w gemba

396

Etap 5. Jakie s potrzeby klienta?

397

Etap 6. Struktura potrzeb klienta

401

Etap 7. Analiza struktury potrzeb klienta

401

Etap 8. Okrelanie priorytetów potrzeb klienta

402

Etap 9. Realizacja priorytetowych potrzeb klientów

403

Póne rozwinicia. Szczegóowa analiza (wycznie) istotnych relacji

405

„Dom jakoci” i nie tylko

406

Projekty Six Sigma

408

Dziaania nastpcze — stosowanie, ewolucja i usprawnianie procesu

408

Byskawiczne programowanie

408

Rozwinicie harmonogramu za pomoc zarzdzania projektem

poprzez acuch krytyczny

409

Wprowadzanie QFD dla oprogramowania

409

Czynnik ludzki w QFD

410

Wyzwania i puapki w obszarze QFD

410

Jak wdraa QFD dla oprogramowania?

413

Wnioski

414

Nowoczesna wersja QFD w procesie DFTS

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

486

Zalety NVP

487

Wady NVP

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 P

ROJEKTOWANIE 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

599

Wzbudzanie zaangaowania liderów

600

Zrozumienie roli liderów

601

Ocena strategicznych powiza

602

Zapewnianie zaangaowania caej organizacji

602

Zrozumienie koniecznoci koncentracji na kliencie

603

Ocena obecnego poziomu zarzdzania jakoci

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

612

Etap 11. Uruchamianie szkole w caej organizacji

613

Projektowanie programu szkole — dostosowanie i zrónicowanie

614

Szkolenia dla personelu pomocniczego

615

Etap 12. Wdraanie technologii DFTS — proces nauki i stosowania

616

Kontrola

621

Etap 13. Systemy kontroli informacji zwrotnych

624

Studium przypadku 21.1. Cige uczenie si i wzbogacanie

— proces Operating System korporacji GE

627

Zarzdzanie projektem

631

Zabezpieczanie

632

Etap 14. Utrwalanie usprawnie i zysków

632

Etap 15. Integracja i rozwój inicjatywy

632

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

637

Spis treci

19

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

S

ZE 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

655

Model CoSQ w RES

655

Zbieranie danych CoSQ

656

Zdobyte dowiadczenia i wiedza

656

Wiedza zdobyta w czasie korzystania z modelu CoSQ

656

Uywanie danych CoSQ do zrozumienia wpywu usprawnie

657

Koszty i zyski z programu CoSQ

660

Instytucjonalizacja kontroli kosztów CoSQ

660

Wnioski ze studium przypadku

660

Przypisy

661

ROZDZIA 23. Zarz dzanie portfelem technologii informatycznych

663

Cz pierwsza. Wyzwanie

665

Pi etapów iteracyjnego procesu

665

Obiektywno , subiektywno i jako

668

Cz druga. Nowe, racjonalne podejcie

669

Etap 1. Projekt

669

Etap 2. Strukturyzacja zoonoci — koncentracja na celach

670

Etap 3. Pomiar

670

Etap 4. Synteza

674

Etap 5. Optymalizacja

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

687

Definicja wartoci

687

Dlaczego nie zapyta ?

688

Nowatorskie produkty

689

Definiowanie zupenie nowych potrzeb

689

Metody okrelania potrzeb klientów

689

Narzdzia

695

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

695

Ramka 24.1. Czym jest teoria ogranicze?

696

Procesy wnioskowania w TOC

697

Ostatnie kroki

699

Wprowadzanie nowatorskich produktów na rynek

699

Warstwy oporu

700

Wnioski

700

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?

707

Historia QFD

708

Wymagania Kany

709

Spotkanie z triceratopsem na wyspie przygód Universal Studio na Florydzie

711

Schemat QFD

711

Analizy gosu klienta

712

Rozwinicie emocji

715

Rozwinicie ciaa

718

Rozwinicie wymaga inynieryjnych

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

729

Niepowodzenia

729

Czciowy sukces

730

Zdefiniowane QFD

730

Dobry pocztek

730

Problemy w trakcie rozwoju nowych produktów

730

Niespójny rozwój jest niewydajny

731

Spójny rozwój jest wydajny

733

Koncentracja na wartoci w QFD dla projektu

735

Siedem kroków do lepszych projektów

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

753

Wspóczesne narzdzia do zarzdzania jakoci

754

Proces rozwoju nowych produktów

757

Materiay dotyczce QFD i innych metod zarzdzania jakoci

760

Analityczny proces hierarchiczny (AHP) i analityczny proces sieciowy (ANP)

760

Strategiczne karty wyników

761

Byskawiczna QFD

761

Analizy czne (conjoint)

761

Spotkania z klientami

761

Podejmowanie decyzji z udziaem klientów (CIDM)

761

de Bono

761

Deming

761

Wizyty w gemba i analizy gosu klienta

762

Planowanie hoshin

762

Model Kano

762

Inynieria kansei

762

Badania gównych uytkowników

763

Szczupa produkcja

763

22

Spis treci

Nowa strategia Lanchestera

763

Programowanie neurolingwistyczne (NLP)

763

Zarzdzanie projektem

763

Wybór koncepcji metod Pugha

763

QFD (wersja kompleksowa)

764

Niezawodno

764

QFD „róda do potrzeb”

764

Siedem narzdzi do zarzdzania i planowania (7ZP)

764

Siedem narzdzi do planowania produktu (7PP)

764

Siedem narzdzi do sterowania jakoci (7SJ)

764

Six Sigma, SPC

765

Inynieria oprogramowania

765

Bramki etapowe

765

Strategiczne systemy informacyjne (SIS)

765

Zarzdzanie acuchem dostaw

765

Metody Taguchiego

765

Teoria ogranicze (TOC)

765

Zarzdzanie przez jako (TQM)

766

TRIZ

766

Inynieria wartoci

766

O autorze

766

Literatura cytowana

767

Sowniczek poj technicznych

769

Skorowidz nazwisk

779

Skorowidz

781

67

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 wyma-
ga klientów i innych partnerów. Wystpuj niezwyke podobiestwa midzy zagad-
nieniami 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 sys-
temu 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, ponie-
wa 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 oprogramo-
wania godnego zaufania. Proponujemy zintegrowan technologi rozwoju oprogra-
mowania — projektowanie oprogramowania godnego zaufania (ang. Design for
Trusthworthy Software — DFTS) — bazujc na trzech kluczowych elementach: itera-
cyjnym modelu rozwoju solidnego oprogramowania, inynierii optymalizacji projektu
oprogramowania i technologii projektowania obiektowego. W DFTS wysiki nad zapew-
nieniem jakoci koncentruj si na wczesnych etapach procesu rozwoju. Technologia ta

68

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

pozwala na cig interakcj z uytkownikami i midzy osobami pracujcymi nad pro-
duktem 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 opro-
gramowania 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. Jed-
nak 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 archi-
tektur 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 zarz-
dzajcej. 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 nie-
zbdne 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 wik-

szym 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 cha-
rakteryzuj 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 produkowanych

1

. 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, do-
czajc jedynie komponenty programowe

2

. 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 wyni-
ków zewntrznych lub niezgodno danych wyjciowych programu z okrelonymi wyma-
ganiami. 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 nie-

proporcjonalnej dominacji oprogramowania. Koszt cyklu ycia (LCC) typowego oprogra-
mowania 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 programu

3

.

Stosunek zawodnoci oprogramowania do sprztu moe wynosi a 100:1 w typowych

komputerach bazujcych na obwodach scalonych

4

. Dla bardziej skomplikowanych chipów

ten stosunek moe by jeszcze wyszy, co daje bardzo wyrane wskazówki dotyczce kosz-
tów i jakoci. W tabeli 2.1 zamieszczono przegld podstawowych rónic midzy nieza-
wodnoci sprztu i oprogramowania.

Przyczyny zawodnoci oprogramowania

Zawodno oprogramowania to istotny problem spoeczny. W rzeczywistoci ma on glo-
balne znaczenie i na jego rozwizanie powica si znaczne zasoby. W poniszych punk-
tach opisujemy podstawowe przyczyny zawodnoci oprogramowania.

x

Brak zaangaowania kadry zarzdzajcej. Najczstsz przyczyn problemów
z jakoci jest brak zaangaowania, powicenia i wsparcia kadry zarzdzajcej.
Deming

5

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

6

Kategoria

Niezawodno sprztu

Niezawodno
oprogramowania

Podstawowa przyczyna

Z powodu efektów fizycznych

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

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)

Efekty stosowania

Funkcja projektu

Dziedziny

Sprzt zuywa si i zaczyna zawodzi

Relacje czasowe

Modele matematyczne

Fizyka bdu

Czas (t)

Obszar czasu

„Krzywa wannowa”

Dobrze rozwinita teoretycznie
i akceptowana

Funkcje

R = f(, t),  = intensywno bdów

Wykadnicza (staa )

Weibulla (rosnca )

Obszar danych

Bez znaczenia

Oprogramowanie nie zuywa si,
ale zawodzi w wyniku nieznanych
defektów lub bdów

Umiejtnoci programisty

Czas i dane

Funkcja malejca

Dobrze rozwinita teoretycznie,
ale o niskiej akceptacji

R = f(bdy [lub defekty albo
awarie], t)

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)

MTTF (ang. mean time to failure,
czyli redni czas do wystpienia
awarii)

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

6

Przedruk za pozwoleniem z W. Kuo, V. Rajendra Prasad, F. A. Tillman i Ching-Lai Wang. Optimal Reliability

Design. Cambridge University Press, Cambridge, 2001, punkt 13.5.1, s. 4.

Niezawodno oprogramowania — fakty i mity

73

TABELA 2.1.

Rónice i 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

Projekt

MIL-STD-781C (wykadnicze)

Inne metody (niewykadnicze)

Testowanie cieek, symulacje,
bdy, posiew Bayesa

Operacje

MIL-STD-781C

Brak

Zastosowanie nadmiaru

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

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-pro-
totyp-testy, które zasadniczo przebiegaj przy uyciu metody prób i bdów. Ma to wpyw

Japoskie systemy zarzdzania jakoci i podejcie Taguchiego

75

na koszty, czas trwania cyklu i jako produktu dostarczanego klientowi, jeli udostp-
niane oprogramowanie nie ma odpowiednich waciwoci w zakresie wydajnoci. Bardzo
czsto dzieje si tak, poniewa meneder produktu nie ma czasu i rodków, a musi udo-
stpni projekt w fazie produkcyjnej. Na dalszych etapach produkty s sprawdzane i prze-
siewane w celu wykrycia jednostek, które s niezgodne ze specyfikacj. Te jednostki s
naprawiane, przetwarzane lub odrzucane. Takie systemy kontroli 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 Deming

7

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 kon-
troli 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 uspraw-
nienie 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 Taguchiego

8

,

9

Doktor Genichi Taguchi mia znaczcy wpyw na powstanie metodologii zarzdzania jako-
ci 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 eksperymen-
talnego i stosowania tablic ortogonalnych, uczc si od nagradzanego japoskiego staty-
styka 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 Elektrycz-
nej 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 statysty-
kami: Ronaldem A. Fisherem i Walterem A. Shewhartem. W latach 1957 – 58 Taguchi opu-
blikowa pierwsz wersj swej dwutomowej pracy Design of Experiments. Do Stanów Zjedno-
czonych przyby po raz pierwszy w 1962 roku jako zaproszony 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 pro-
cesów produkcji. Przejcie do projektowania produktów miao miejsce póniej. We wcze-
snych latach 70. Taguchi rozwin zagadnienie funkcji utraty jakoci. Wtedy te opubliko-
wa 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 meto-
dologi 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

77

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 zarysie

8, 9

Metodologia Taguchiego dotyczy optymalizacji produktu i procesu na etapach projekto-
wania 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 ska-
dania. Dziki temu jako staje si funkcj prawidowego projektu, a nie nawet cisych testów
i kontroli. Podejcia Taguchiego mona uywa take jako metodologii rozwizywania pro-
blemó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 defi-
niowana jako „straty powodowane przez produkt w spoecznoci od momentu jego udostp-
nienia”. 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 mo-
liwy, Taguchi wie prost kwadratow funkcj straty z odchyleniem od poziomu docelo-
wego. Funkcja utraty jakoci pokazuje, e zmniejszanie zmiennoci w zakresie jakoci pro-
wadzi 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 pro-
ducent dy do poziomu docelowego. W praktyce dla uytkowników nie jest wana specy-
fikacja, 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 uwzgld-
nieniem rónych warunków stosowania produktu przez uytkowników. To w interesie
producenta ley utrzymywanie wydajnoci produktu lub procesu tak blisko poziomu doce-
lowego, jak to ekonomicznie moliwe. Funkcja straty moe posuy do podjcia decyzji
projektowych w kategoriach finansowych. Pomaga zdecydowa , czy dodatkowe koszty zwik-
szenia odpornoci i usprawnienia produkcji s usprawiedliwione oraz czy oka si zasadne
w warunkach rynkowych.

78

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

Metod Taguchiego 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 Taguchiego

10

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 staty-
styka sir Ronalda Fishera, ich filozoficzne podstawy s niezaprzeczalnie japoskie. Metody
Taguchiego i inne japoskie systemy zarzdzania jakoci, takie jak kaizen (cige uspraw-
nianie), 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 Dise-
ases i Obstacles to Quality Products. Proponowana przez Richarda Zultnera adaptacja zasad
Deminga do rozwoju oprogramowania jest opisana w rozdziale 5. Metody Taguchiego
i inne systemy 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 dziesicio-
leciach kontynuowa wspóprac z rzdem oraz przemysem japoskim i wyszkoli tysice
japoskich menederów oraz inynierów. Ci menederowie byli zainteresowani wspócze-
snymi amerykaskimi zasadami zarzdzania. Jednak Deming zaproponowa im co zupe-
nie nowego, co, jego zdaniem, miao pomóc w przeksztaceniu Japonii w dobrze pro-
sperujce 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 Deminga

11

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 ameryka-
skiego przemysu, takich jak motoryzacja i AGD, w których japoskie korporacje poczy-
niy ogromne postpy.

Wiele prac Taguchiego byo inspirowanych 14 punktami zarzdzania Deminga.

W szczególnym stopniu dotyczy to zasady braku zalenoci od inspekcji przy osiga-
niu 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 nastp-
nie dostosowa odpowiedni czynnik, aby osign wyniki moliwie jak najblisze docelo-
wym 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 pro-

dukcyjnym, 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, sto-
sowaniu i warunkach rodowiskowych. Podstawowa zasada metod Taguchiego dotyczy
raczej usuwania negatywnych efektów przyczyn ni powodów tych niekorzystnych skut-
ków. Dziki temu mona uzyska produkt wyszej jakoci najmniejszym moliwym
kosztem. Ta strategia neutralizacji samych skutków, a nie przyczyn, jest mdrym rozwi-
zaniem, 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 wyprodu-
kowania 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 zmien-
no . 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 pro-
dukcji i kontroli lub, co gorsza, po dostarczeniu produktu do klienta. Metody Taguchiego
zapewniaj wydajn ze wzgldu na koszty i czas metodologi projektowania oraz testo-
wania produktów pod ktem solidnoci przed rozpoczciem ich produkcji. Metody te su
take do rozwizywania problemów rónego rodzaju czy modyfikowania projektów wadli-
wych 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 (naj-
czstsza przyczyna zmiennoci), warunki na drodze czy pogoda, nie mona kontrolowa
lub wyeliminowa . To szum powoduje odchylenia charakterystyk dziaania i funkcjonal-
nych 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 doku-
mentacji, 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 optymali-
zacji 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 obej-
muj nie tylko cen produkcji i rachunki za materiay. Klienci oczekuj niezawodnoci
w czasie trwania cyklu ycia produktu, a w ostatecznym rozrachunku istotna jest opty-
malizacja kosztów tego cyklu. Klienci coraz bardziej domagaj si bezbdnych dostaw
i dziaania. Oczekuj rónych dodatkowych funkcji i udogodnie. Coraz czciej te poszu-
kuj stabilnego, wysokiej jakoci dziaania na poziomie docelowym i nie zadowalaj si
niestabilnym funkcjonowaniem w ramach specyfikacji. Zapewnienie dziaania na pozio-
mie 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 kategorii

13

:

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 sa-
bej 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 zagro-
eniem 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 docelo-
wego prowadzi do zmniejszania si strat, z czego wynika wzrost jakoci. Ta funkcja
suy do podejmowania decyzji projektowych na podstawie czynników finansowych i po-
zwala 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 jako-

ci 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 = O

2

K, 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 iny-

nieró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 odmien-
nych warunkach rodowiskowych. Taguchi sugeruje, e firmy majce lepsze sposoby sza-
cowania 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 mia-
rach zwizanych z klientem, takich jak koszty w dolarach i cechy dziaania (funkcjo-
nalne). 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 opro-
gramowania 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 przypadko-
wego lub celowego nieupowanionego dostpu oraz s podatne na inne zagroenia, jed-
nak 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 nieza-
wodnoci oprogramowania — i to jest tematem niniejszej ksiki.

W tabeli 2.2 opisujemy pewne czsto stosowane definicje i atrybuty jakoci oprogra-

mowania. Miary oprogramowania s omówione do szczegóowo w rozdziale 3., jednak
w tym miejscu warto omówi kilka podstawowych zagadnie. Najbardziej fundamentalne
z nich to pojcie samej jakoci. Jako oprogramowania mona zdefiniowa jako stopie
speniania wymaga lub oczekiwa klientów albo uytkowników przez system, kompo-
nent lub proces. Moe to obejmowa kilka elementów, z których najczciej wymieniana
jest wiarygodno oprogramowania. Zwizana jest ona z rónymi wymaganiami uytkow-
nika, 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ów-
nych wyzwa zwizanych z tworzeniem oprogramowania godnego zaufania to zapewnie-
nie 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. Przyka-
dowo 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 pod-
stawie tworzy oprogramowanie godne zaufania.

Warto poczyni pewne uwagi na temat zwrotu „godne zaufania”. W dziedzinie zarz-

dzania 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 pra-
cowników. Uwaamy zastosowanie tego sowa przez Deminga i kontekst, w jakim go uy-
wa, 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 powiado-
mieniach przesanych w styczniu i lipcu 2002

15

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 rozwi-
zywaniem 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 elektrycz-
noci, to olbrzymie wyzwanie dla przemysu zwizanego z produkcj oprogramowania.
Wyranie wida potrzeb wspópracy midzy przemysem rozwoju oprogramowania, pro-
fesjonalistami 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 rozwizy-
wania 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 czowieka

16

. 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 oprogra-
mowania 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) utworzo-
nym jako uatwienie do rozwoju oprogramowania godnego zaufania (zobacz rysunek 2.6).
Ten model spenia siedem kluczowych wymaga procesu rozwoju solidnego oprogra-
mowania omówionego w rozdziale 1. Bazuje na logicznych zasadach zarzdzania i spraw-
dzonych 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 programu

17

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

95

x

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 opi-

suje 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 odpowia-
daj 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 inynie-
rom 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”, sty-
cze – 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, Addi-
son-Wesley, 1997).

14

Op. cit. Littlewood i Strigini, s. 1.

15

http://www.microsoft.com/mscorp/execmail/2002/07-18twc.mspx.

16

Op. cit. Littlewood i Strigini, s. 2.

17

N. Ashrafi, O. Berman, M. Cutler, Optimal design of large software-systems using N-version
programming, „IEEE Transactions on Reliability”, R-43 (2): 344 – 350, 1994.