Oprogramowanie_godne_zaufania_Metodologia_techniki_i_narzedzia_projektowania_bezopr by Jakub Jóźwiak

Bezpieczne oprogramowanie. Metodologia, techniki i narzêdzia projektowania Autor: Bijay K. Jayaswal, Peter C. Patton ISBN: 978-83-246-1463-9 Tytu³ orygina³u: Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software Format: 172x245, stron: 816

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

Poznaj narzêdzia, techniki oraz metodologiê tworzenia niezawodnego oprogramowania • Jak przeprowadziæ weryfikacjê, oceniaæ i konserwowaæ oprogramowanie? • Jakie s¹ finansowe aspekty tworzenia oprogramowania godnego zaufania? • Jak zarz¹dzaæ portfelem technologii informatycznych? Jakoœæ oprogramowania to wielowarstwowe zagadnienie. Spojrzenie na ni¹ z kilku perspektyw jest kluczowe dla procesu tworzenia nowego produktu. Nale¿y przy tym wzi¹æ pod uwagê nie tylko op³acalnoœæ jego wytwarzania i konkurencyjnoœæ, ale tak¿e jawne i ukryte potrzeby naszych klientów oraz partnerów biznesowych. St¹d wynika potrzeba u¿ywania zintegrowanej technologii, pomagaj¹cej spe³niaæ wszystkie te wymagania. Odpowiada na ni¹ technologia projektowania oprogramowania godnego zaufania (ang. Designing for Trustworthy Software). S³u¿y ona wczesnemu rozwi¹zywaniu problemów zwi¹zanych z jakoœci¹ tworzonego produktu, dziêki czemu zapobiega powstawaniu b³êdów implementacji. Si³¹ tej technologii jest tak¿e fakt, ¿e wszelkie dzia³ania zwi¹zane z jakoœci¹ s¹ podejmowane przed napisaniem ka¿dego wiersza kodu. Ta ksi¹¿ka pomo¿e w poprawie jakoœci wszystkim tym, którzy wdra¿aj¹ rozwi¹zania wewnêtrzne i zewnêtrzne, prowadz¹ konsultacje i œwiadcz¹ pomoc techniczn¹. Zawiera ona prze³omowe rozwi¹zania dla specjalistów z dziedziny oprogramowania oraz jakoœci – od programistów po liderów projektu, od g³ównych architektów oprogramowania po klientów. Z tego podrêcznika dowiesz siê m.in., jak stosowaæ najlepsze praktyki w dziedzinie kontrolowania jakoœci, organizacji szkoleñ i zarz¹dzania w wyj¹tkowym œrodowisku rozwoju oprogramowania. • Metodologia rozwoju oprogramowania • Miary jakoœci oprogramowania • Koszty jakoœci oprogramowania • Narzêdzia i techniki projektowania oprogramowania godnego zaufania • Analityczny proces hierarchiczny • Z³o¿onoœæ, b³êdy i poka-yoke w procesach rozwoju oprogramowania • Ocena ryzyka oraz analiza przyczyn i skutków b³êdów (FEMA) • Technologie obiektowe i komponentowe • Techniki AHP, TRIZ, CoSQ i metoda Taguchiego • Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania • Wdra¿ania technologii DFTS • QFD dla projektów Twórz niezawodne oprogramowanie wysokiej jakoœci!

Spis tre ci

Wprowadzenie

Przedmowa

Podzi kowania

O autorach

CZ I

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

ROZDZIA 1.

Wspó czesne metodologie rozwoju oprogramowania

35 37

Rozwój oprogramowania — potrzeba nowego paradygmatu

Ramka 1.1. Z o ono komputerów

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

42 44 45 45 46 48 49 50 52 53

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

53 54 55 56 58

Metoda ADR

Siedem elementów procesu rozwoju stabilnego oprogramowania

Model rozwoju solidnego oprogramowania

Ramka 1.2. Krytyczne oprogramowanie steruj ce w lotnictwie

Kluczowe zagadnienia

Spis tre ci

Dodatkowe materia y

wiczenia internetowe

Pytania przegl dowe

Zagadnienia do dyskusji i projekty

Przypisy

ROZDZIA 2.

Wyzwania na drodze do oprogramowania godnego zaufania — solidny projekt w kontek cie oprogramowania

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

69 69 71 71

Ograniczenia tradycyjnych systemów kontroli jako ci

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego

Ramka 2.1. ycie i czasy doktora Genichiego Taguchiego

Ramka 2.2. Metodologia in ynierii jako ci w zarysie

Ramka 2.3. Taguchi o metodach Taguchiego

Ramka 2.4. Istota 14 punktów Deminga

Istota metod solidnego projektowania Taguchiego Zagadnienie stosunku sygna u do szumu Zagadnienie funkcji utraty jako ci Zagadnienie solidnego projektowania

83 83 85 87

Wyzwania na drodze do niezawodno ci oprogramowania — projektowanie oprogramowania godnego zaufania

Model rozwoju solidnego oprogramowania — proces DFTS w praktyce

Kluczowe zagadnienia

Dodatkowe materia y

wiczenia internetowe

Pytania przegl dowe

Pytania do dyskusji i projekty

Przypisy

ROZDZIA 3.

Miary jako ci oprogramowania

101

Pomiar jako ci oprogramowania

103

Klasyczne miary jako ci oprogramowania

103

Zarz dzanie przez jako

104

Ogólne miary jako ci oprogramowania

106

Spis tre ci

Metodologia pomiarów Wewn trzprocesowe miary jako ci do testowania oprogramowania Miary z o ono ci oprogramowania Nauka o oprogramowaniu Z o ono cyklomatyczna Miary punktów funkcyjnych Miary zadowolenia klienta i dost pno ci

106 107 109 110 112 113 114

Ramka 3.1. Miejska legenda o oprogramowaniu

115

Aktualne miary i modele

116

Nowe miary projektowania i oceny architektury

118

Powszechne problemy z projektowaniem architektury

119

Miary wzorców w OOAD

121

Kluczowe zagadnienia

122

Dodatkowe materia y

123

wiczenia internetowe

123

Pytania przegl dowe

123

Zagadnienia do dyskusji i projekty

124

Przypisy

124

ROZDZIA 4.

Finansowe perspektywy tworzenia oprogramowania godnego zaufania

127

Dlaczego DFTS wymaga ró nych analiz finansowych?

129

Koszty i jako — kiedy i dzi

130

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

134 134 135 137 146 148 149 149

Koszty jako ci oprogramowania w cyklu ycia

150

Studium przypadku 4.1. Zastosowanie CoSQ w Intents Software

152

CoSQ i kosztorysowanie bazuj ce na aktywno ciach ABC w firmach zajmuj cych si rozwojem oprogramowania Uruchamianie ABC przy rozwoju oprogramowania Korzy ci stosowania ABC

157 157 158 159

Ramka 4.1. ABC w przemy le us ugowym

160

Spis tre ci

Funkcja utraty jako ci w przypadku oprogramowania

160

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

161 161 162

Kluczowe zagadnienia

164

Dodatkowe materia y

166

wiczenia internetowe

166

Pytania przegl dowe

166

Zagadnienia do dyskusji

167

Problemy

168

Przypisy

168

ROZDZIA 5.

Infrastruktura organizacyjna i przywództwo przy stosowaniu DFTS

171

Wyzwania organizacyjne przy wdra aniu DFTS

173

Schemat wdra ania DFTS Etap 1. Budowanie wiadomo ci zarz du i przekonywanie go Etap 2. Komunikowanie o zgodno ci i zaanga owaniu wy szej kadry zarz dzaj cej Etap 3. Wykrywanie potencjalnych pu apek zwi zanych z inicjatyw DFTS

173 174 178 179

Ramka 5.1. Nienaganny cykl nauki i TPOV Etap 4. K adzenie podwalin pod organizacj skoncentrowan na jako ci Etap 5. Budowanie infrastruktury organizacyjnej Etap 6. Zrozumienie ról kluczowych osób Etap 7. Projektowanie wspomagaj cej struktury organizacyjnej Etap 8. Ustanawianie efektywnej komunikacji Etap 9. Tworzenie odpowiedniego systemu nagród Etap 10. Ustanawianie systemu CoSQ Etap 11. Planowanie i uruchamianie szkole w ca ej organizacji Etap 12. Wdra anie modelu DFTS Etap 13. Kontrolowanie nauki i post pów oraz przekazywanie informacji zwrotnych Etap 14. Utrwalanie usprawnie i zysków Etap 15. Integracja i rozszerzanie programu

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

czenie wszystkich elementów

213

Kluczowe zagadnienia

214

Dodatkowe materia y

218

wiczenia internetowe

218

Spis tre ci

Pytania przegl dowe

219

Zagadnienia do dyskusji i projekty

220

Przypisy

220

CZ II

NARZ DZIA I TECHNIKI PROJEKTOWANIA OPROGRAMOWANIA GODNEGO ZAUFANIA

ROZDZIA 6.

Siedem podstawowych narz dzi zarz dzania jako ci (P7)

223 225

Siedem podstawowych narz dzi (P7)

228

Ramka 6.1. Kaoru Ishikawa — rozwój specyficznie japo skiej strategii zarz dzania jako ci

230

P7 w kontek cie DFTS

232

Inne narz dzia, techniki i metodologie DFTS

233

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

234 235 235 236

Diagramy Pareto

236

Diagramy przyczynowo-skutkowe Tworzenie diagramów przyczynowo-skutkowych w celu okre lenia przyczyn U ywanie diagramów przyczynowo-skutkowych do klasyfikowania procesów

237 240 241

Diagramy rozproszenia

243

Arkusze kontrolne

246

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

246 247 248 248

Wykresy

248

Karty kontrolne

250

Kluczowe zagadnienia

252

Dodatkowe materia y

254

Pytania przegl dowe

254

Zagadnienia do dyskusji

254

Przypisy

255

ROZDZIA 7.

Spis tre ci

Narz dzia 7 ZP — analiza i interpretacja danych jako ciowych oraz werbalnych

257

Narz dzia N7 i 7 ZP

260

Typowe zastosowania narz dzi 7 ZP

261

Diagram pokrewie stwa

263

Diagramy wspó zale no ci

266

Diagram drzewa

270

Macierze priorytetów

272

Diagram macierzowy

274

Wykres programowy procesu decyzyjnego (PDPC)

274

Diagram sieci aktywno ci

275

Umiej tno ci behawioralne przydatne do stosowania narz dzi 7 ZP

276

Kluczowe zagadnienia

277

Dodatkowe materia y

278

Pytania przegl dowe

278

Zagadnienia do dyskusji i projekty

279

Przypisy

279

ROZDZIA 8.

Analityczny proces hierarchiczny

281

Okre lanie priorytetów, z o ono i analityczny proces hierarchiczny

283

AHP i podejmowanie decyzji w obliczu wielu celów S ownictwo Okre lanie struktury hierarchii celów Hierarchia decyzji

284 286 286 288

Studium przypadku 8.1. Informatyczny dylemat dyrektora do spraw systemów informacyjnych wspomagaj cych zarz dzanie (MIS)

289

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

290 290 292 295 297

Przybli anie wyników AHP na podstawie samodzielnych oblicze Pierwsza metoda tworzenia przybli onych rozwi za Druga metoda przybli ania. Kompleksowa analityczna metoda kryteriów do okre lania priorytetów Brassarda

298 302

Wnioski

312

Kluczowe zagadnienia

313

309

Spis tre ci

Dodatkowe materia y

314

wiczenia internetowe

314

Pytania przegl dowe

314

Zagadnienia do dyskusji i projekty

315

Problemy Problem 1. Zarz dzanie z o ono ci przy przekszta caniu systemów Problem 2. Zarz dzanie z o ono ci oprogramowania w nowej firmie z bran y zaawansowanych technologii Problem 3. Z o ono w systemach zarz dzania kartami pacjentów Problem 4. System wspomagaj cy podejmowanie decyzji dotycz cych odwiertów ropy naftowej Problem 5. Problem ROI Problem 6. Abstrakcyjne analizy z o ono ci Problem 7. Wra liwo na z o ono

315 315

321 323 323 324

Przypisy

324

ROZDZIA 9.

Z o ono , b dy i poka-yoke w procesach rozwoju oprogramowania

318 320

327

Poka-yoke jako system kontroli jako ci

329

Zasady poka-yoke

330

Przyczyny defektów — zmienno , b dy i z o ono

331

Warunki stosowania poka-yoke

333

Pomy ki jako przyczyny defektów

334

Kontrola z o ono ci w rozwoju oprogramowania

336

Pomy ki, metody kontroli i poka-yoke

340

Wdra anie systemu poka-yoke

341

Okre lanie rozwi zania bazuj cego na poka-yoke

345

Kluczowe zagadnienia

346

Dodatkowe materia y

348

wiczenia internetowe

348

Pytania przegl dowe

349

Zagadnienia do dyskusji i projekty

349

Przypisy

350

Spis tre ci

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

353

5S — wielki krok w kierunku produktywnego rodowiska pracy

355

Etapy wdra ania systemu 5S Etap 1. Selekcja i sortowanie Etap 2. Organizowanie i porz dkowanie Etap 3. Sprz tanie i czyszczenie Etap 4. Standaryzacja Etap 5. Podtrzymywanie i samodyscyplina

356 356 356 357 357 357

System 5S i proces DFTS

358

Ramka 10.1. Od 5S do szczup ego procesu DFTS

359

Prze amywanie oporu

362

Wdra anie 5S Etap 1. Przekonywanie zarz du Etap 2. Szkolenia i wdra anie Etap 3. Powi zanie z systemem nagród Etap 4. Kontynuacja i ci g e usprawnianie

363 363 364 364 365

Kluczowe zagadnienia

365

Dodatkowe materia y

366

wiczenia internetowe

366

Pytania przegl dowe

366

Zagadnienia do dyskusji i projekty

367

Przypisy

367

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

369

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

371 372 373 374 376 378 379 380 380 382

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

386 386

Spis tre ci

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

387 388 389

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

391 391 391 391

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

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

Wprowadzanie QFD dla oprogramowania Czynnik ludzki w QFD Wyzwania i pu apki w obszarze QFD Jak wdra a QFD dla oprogramowania?

409 410 410 413

Wnioski Nowoczesna wersja QFD w procesie DFTS

414 414

Kluczowe zagadnienia

415

Dodatkowe materia y

417

wiczenia internetowe

418

Pytania przegl dowe

419

Zagadnienia do dyskusji

420

Przypisy

421

Spis tre ci

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

427

Potrzeba kreatywno ci w DFTS

429

Kreatywno i TRIZ

429

Ramka 12.1. Czym jest szcz liwy traf?

430

Ramka 12.2. Pionierzy

433

TRIZ w rozwoju oprogramowania

433

Ramka 12.3. Lingua latina non mortua est

434

TRIZ, QFD i metody Taguchiego

442

Burza mózgów

442

Metodologia wyboru koncepcji Pugha

444

Oprogramowanie jako w asno intelektualna

447

Ramka 12.4. Obraz jest wart…

449

Kluczowe zagadnienia

450

Dodatkowe materia y

450

wiczenia internetowe

450

Pytania przegl dowe

451

Zagadnienia do dyskusji i projekty

451

Przypisy

451

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

455

Zastosowania FMEA na wczesnych etapach

459

Analizy drzewa b dów oprogramowania

462

Przyczyny b dów w oprogramowaniu i ich ród a

465

Okre lanie i ocena ryzyka na poszczególnych etapach DFTS

467

Kluczowe zagadnienia

468

Dodatkowe materia y

469

wiczenia internetowe

469

Pytania przegl dowe

469

Zagadnienia do dyskusji i projekty

469

Przypisy

470

Spis tre ci

ROZDZIA 14. Technologie obiektowe i komponentowe oraz inne narz dzia programistyczne

471

G 贸wne wyzwania w rozwoju biznesowych aplikacji dla przedsi biorstw

473

Analizy, projektowanie i programowanie obiektowe

473

Ramka 14.1. Narodziny programowania obiektowego

474

Ramka 14.2. Zalety warstwy po redniej j zyka Java

479

Technologia rozwoju oprogramowania na podstawie komponent贸w

481

Poprawa produktywno ci za pomoc programowania ekstremalnego

484

Zwi kszanie niezawodno ci przy u yciu programowania wielowersyjnego Zalety NVP Wady NVP

486 487 487

Wsp贸 czesne rodowiska programistyczne

488

Trendy w automatyzacji programowania

492

Kluczowe zagadnienia

495

Dodatkowe materia y

495

wiczenia internetowe

496

Pytania przegl dowe

496

Zagadnienia do dyskusji i projekty

496

Przypisy

496

CZ III PROJEKTOWANIE OPROGRAMOWANIA GODNEGO ZAUFANIA

499

ROZDZIA 15. Miary jako ci i metody statystyczne w rozwoju oprogramowania godnego zaufania

501

Oprogramowanie godne zaufania

503

Inicjatywa Microsoftu na rzecz przetwarzania godnego zaufania

504

Statystyczne sterowanie procesem w rozwoju oprogramowania

507

Metody statystyczne dla architekt贸w oprogramowania

513

Kluczowe zagadnienia

517

Dodatkowe materia y

517

wiczenia internetowe

518

Pytania przegl dowe

518

Zagadnienia do dyskusji i projekty

518

Problemy

518

Przypisy

518

Spis tre ci

ROZDZIA 16. Solidne oprogramowanie w kontek cie

521

Proces tworzenia specyfikacji oprogramowania

523

Ramka 16.1. Precyzyjne specyfikacje funkcjonalne

525

Czym jest solidne oprogramowanie?

526

Wymagania, jakie musi spe nia solidne oprogramowanie

527

Ramka 16.2. Uzyskiwanie informacji od u ytkownika ko cowego

528

Ocena solidno ci oprogramowania

528

Ramka 16.3. Przyk ad projektowania parametr贸w

530

Kluczowe zagadnienia

531

Dodatkowe materia y

531

wiczenia internetowe

531

Pytania przegl dowe

532

Zagadnienia do dyskusji i projekty

532

Problemy

532

Przypisy

533

ROZDZIA 17. Metody Taguchiego i optymalizacja pod k tem solidnego oprogramowania

535

Metody Taguchiego w projektowaniu solidnego oprogramowania

537

Przyk ad z dziedziny in ynierii projektu

541

Przyk ad z obszaru projektowania i rozwoju oprogramowania

544

Macierze ortogonalne w eksperymentach Taguchiego nad projektowaniem parametr贸w

549

Zastosowania w DFTS

552

Kluczowe zagadnienia

552

Dodatkowe materia y

553

wiczenia internetowe

553

Pytania przegl dowe

553

Zagadnienia do dyskusji

553

Problemy

553

Przypisy

554

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

555

Ci g dalszy cyklu rozwoju

557

Ramka 18.1. Miejska legenda o oprogramowaniu biznesowym

558

Spis tre ci

Weryfikacja

559

Studium przypadku 18.1. Metody Taguchiego w weryfikacji projektu systemu RTOS

559

Walidacja

563

Studium przypadku 18.2. Metody Taguchiego w walidacji oprogramowania

563

Testy i ocena

566

Ramka 18.2. Anomalie z obszaru test贸w i debugowania

567

Kluczowe zagadnienia

571

Dodatkowe materia y

572

wiczenia internetowe

572

Pytania przegl dowe

573

Zagadnienia do dyskusji i projekty

573

Problemy

573

Przypisy

573

ROZDZIA 19. Integracja, wzbogacanie i konserwacja oprogramowania godnego zaufania

575

Ko czenie cyklu rozwoju

577

Integracja

577

Ramka 19.1. Spitfire Supermarine

578

Wzbogacanie

578

Studium przypadku 19.1. Zwi kszanie mo liwo ci elektronicznego systemu do prowadzenia dzia a wojennych

579

Konserwacja

581

Studium przypadku 19.2. Konserwacja system贸w oprogramowania u klienta

582

Ramka 19.2. Usuni cie zaawansowanej funkcjonalno ci oprogramowania w wyniku konserwacji

583

Kluczowe zagadnienia

584

Dodatkowe materia y

584

wiczenia internetowe

584

Pytania przegl dowe

585

Zagadnienia do dyskusji i projekty

585

Problemy

585

Przypisy

585

Spis tre ci

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

587

ROZDZIA 20. Przygotowanie organizacji do wdra ania DFTS

589

Czas na rozwa ania

591

Studium przypadku 20.1. D enie do doskona ego procesu produkcji

591

Studium przypadku 20.2. Instytucjonalizacja Six Sigma w GE

594

Wyzwania stoj ce przed liderami w trakcie inicjatyw transformacyjnych

598

Ocena kluczowych elementów organizacji Wzbudzanie zaanga owania liderów Zrozumienie roli liderów Ocena strategicznych powi za Zapewnianie zaanga owania ca ej organizacji Zrozumienie konieczno ci koncentracji na kliencie Ocena obecnego poziomu zarz dzania jako ci

599 600 601 602 602 603 604

Kluczowe zagadnienia

605

Dodatkowe materia y

606

wiczenia internetowe

607

Pytania przegl dowe

607

Zagadnienia do dyskusji i projekty

607

Przypisy

608

ROZDZIA 21. Uruchamianie inicjatywy DFTS

609

DFTS i platforma PICS

611

Planowanie

611

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

612 613 614 615 616

Kontrola Etap 13. Systemy kontroli informacji zwrotnych

621 624

Studium przypadku 21.1. Ci g e uczenie si i wzbogacanie — proces Operating System korporacji GE Zarz dzanie projektem

627 631

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

632 632 632

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

637

Spis tre ci

Zastosowania w ma ych firmach programistycznych i wioskach elektronicznych

640

Co dalej?

641

Kluczowe zagadnienia

641

Dodatkowe materia y

643

wiczenia internetowe

644

Pytania przegl dowe

644

Zagadnienia do dyskusji

645

Przypisy

645

CZ V

SZE STUDIÓW PRZYPADKU

647

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

653

Wprowadzenie

654

Program usprawnie w RES

654

Koszty jako ci oprogramowania Model CoSQ w RES Zbieranie danych CoSQ

655 655 656

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

656 656 657 660 660

Wnioski ze studium przypadku

660

Przypisy

661

ROZDZIA 23. Zarz dzanie portfelem technologii informatycznych

663

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

665 665 668

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

669 669 670 670 674 676

Ryzyko

679

Spis tre ci

Rozszerzenia

681

Podsumowanie

682

Przypisy

683

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

685

Wprowadzenie Definicja warto ci Dlaczego nie zapyta ? Nowatorskie produkty

687 687 688 689

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

689 689

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

695 695

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

696 697

Ostatnie kroki Wprowadzanie nowatorskich produktów na rynek

699 699

Warstwy oporu

700

Wnioski

700

Podzi kowania

700

Literatura cytowana

702

O autorze

704

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

705

Profil firmy MD Robotics

707

Dlaczego QFD? Historia QFD Wymagania Kany

707 708 709

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

711 711 712 715 718 719

Podsumowanie

720

O autorach

723

Przypisy

723

Spis tre ci

ROZDZIA 26. QFD dla projektów. Lepsze zarz dzanie projektami rozwoju oprogramowania dzi ki b yskawicznemu QFD

727

Wprowadzenie Niepowodzenia Cz ciowy sukces Zdefiniowane QFD Dobry pocz tek

729 729 730 730 730

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

730 731 733

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

735 735

Podsumowanie

746

Podzi kowania

746

Literatura cytowana

747

O autorze

749

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

751

Popyt na nowe produkty

753

Jako i rozwój nowych produktów Wspó czesne narz dzia do zarz dzania jako ci Proces rozwoju nowych produktów

753 754 757

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

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

Spis tre ci

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

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

O autorze

766

Literatura cytowana

767

S owniczek poj technicznych

769

Skorowidz nazwisk

779

Skorowidz

781

ROZDZIA 2

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

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

Omówienie Wieloaspektowe spojrzenie na jako jest kluczowe w identyfikowaniu licznych wymaga klientów i innych partnerów. Wyst puj niezwyk e podobie stwa mi dzy zagadnieniami zwi zanymi z jako ci oprogramowania i wyrobów produkowanych, jednak nale y uwzgl dni tak e istotne ró nice. Koszty powodowane przez oprogramowanie niskiej jako ci s coraz bardziej kluczowe, poniewa koszt cyklu ycia typowego systemu przekracza cen sprz tu. Oprogramowanie wy szej jako ci pozwala istotnie zredukowa te koszty, poniewa 80 – 90% ich sumy poch ania konserwacja zwi zana z poprawianiem, adaptowaniem i rozwijaniem udost pnionego oprogramowania. Obecnie oko o 40% wydatków na rozwój oprogramowania poch aniaj testy potrzebne w celu usuni cia b dów. Kluczowa jest tak e niezawodno oprogramowania, poniewa stosunek b dów wyst puj cych w programach do usterek sprz towych mo e wynosi 100:1, a nawet jeszcze wi cej. W tym rozdziale opisujemy niepowodzenia tradycyjnych systemów zarz dzania jako ci w kontek cie udost pniania oprogramowania godnego zaufania. Proponujemy zintegrowan technologi rozwoju oprogramowania — projektowanie oprogramowania godnego zaufania (ang. Design for Trusthworthy Software — DFTS) — bazuj c na trzech kluczowych elementach: iteracyjnym modelu rozwoju solidnego oprogramowania, in ynierii optymalizacji projektu oprogramowania i technologii projektowania obiektowego. W DFTS wysi ki nad zapewnieniem jako ci koncentruj si na wczesnych etapach procesu rozwoju. Technologia ta

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

Struktura rozdzia u

Niezawodno oprogramowania — fakty i mity

Ograniczenia tradycyjnych systemów kontroli jako ci

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego

Istota metod Taguchiego do tworzenia solidnych projektów

Wyzwania na drodze do niezawodno ci oprogramowania — projektowanie oprogramowania godnego zaufania

Model rozwoju solidnego oprogramowania — proces DFTS w praktyce

Kluczowe zagadnienia

Dodatkowe materia y

wiczenia internetowe

Pytania przegl dowe

Zagadnienia do dyskusji i projekty

Przypisy

Niezawodno oprogramowania โ fakty i mity

Niezawodno oprogramowania โ fakty i mity Jako oprogramowania, podobnie jak jako sprz tu, to wieloaspektowe zagadnienie. W rzeczywisto ci spojrzenie na jako z kilku perspektyw jest kluczowe do zrozumienia i utworzenia warto ciowego produktu oraz zaspokojenia zestawu jawnych i ukrytych potrzeb klienta. Producent musi tak e spe ni wymania wielu innych partnerรณw, takich jak audytorzy, dostawcy, zwi zki bran owe, media i inne zainteresowane grupy. W ko cu, co nie najmniej istotne, ka dy wytwรณrca musi si upewni , e jego produkty s op acalne i konkurencyjne, aby mog y spe nia potrzeby w a cicieli przedsi biorstw. Jako obejmuje wszystkie takie potrzeby i wymagania. Cz sto mo na us ysze , e zagadnienia zwi zane z jako ci w wiecie oprogramowania s inne ni w przypadku innych produktรณw, jednak nie do ko ca jest to prawd . Ogรณlnie mรณwi c, zasady, systemy i metodologie jako ciowe stosowane do produkcji wyrobรณw s rรณwnie prawid owe w przypadku oprogramowania, sprz tu i innych dรณbr czy us ug. Jednak oprogramowanie ma specyficzne rodowisko projektowania i rozwoju, ktรณre trzeba zrozumie . Ponadto nale y pozna specyficzne wyzwania wynikaj ce z abstrakcyjnej natury systemรณw cyfrowych oraz poziomu z o ono ci wielu aplikacji, a tak e wzi pod uwag innowacyjno i trudno zada , do ktรณrych rozwi zywania zosta y zaprojektowane. Wierzymy, e w organizacjach zajmuj cych si rozwojem oprogramowania oraz takich, dla ktรณrych tworzenie aplikacji jest istotn dzia alno ci , zagadnienia zwi zane z architektur i projektowaniem s kluczowe dla d ugoterminowej op acalno ci i powodzenia firmy. We wszystkich takich organizacjach te zadania s zbyt wa ne, aby pozostawi je wy cznie in ynierom oprogramowania. Problem produkcji oprogramowania godnego zaufania jest prawdziwym wyzwaniem i wymaga ca kowitego zaanga owania kadry zarz dzaj cej. W tej ksi ce przedstawiamy podstawy filozoficzne, system zarz dzania oraz technologi do zarz dzania jako ci oprogramowania zarรณwno w du ych, jak i ma ych firmach, ze szczegรณlnym uwzgl dnieniem oprogramowania dla przedsi biorstw.

Podobie stwa i rรณ nice mi dzy oprogramowaniem i wyrobami produkowanymi Zrozumienie rรณ nic mi dzy oprogramowaniem i produkowanymi wyrobami jest niezb dne do zaprojektowania solidnego systemu zarz dzania jako ci oprogramowania. Jedynie wtedy mo na zaadaptowa systemy i metodologie, ktรณre przez ostatnie 50 lat mia y tak znacz cy wp yw na popraw jako ci wszelkich dรณbr produkowanych, a tak e innych wyrobรณw i us ug. Trzeba jednak uwzgl dni tak e wa ne rรณ nice, aby prawid owo rozwin system zarz dzania jako ci oprogramowania. Poni ej opisane s pewne zwi zane z tym tematem zagadnienia: x

Oprogramowanie i wyroby produkowane rรณ ni si w zakresie znaczenia rรณ nych etapรณw w procesie ich tworzenia (zobacz rysunki 2.1 i 2.2). Rozwรณj oprogramowania charakteryzuje si centralizacj projektu. Oprogramowanie to przyk ad czystego

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

RYSUNEK 2.1. Podstawowe etapy rozwoju wyrobów produkowanych

RYSUNEK 2.2. Podstawowe etapy rozwoju oprogramowania

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

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

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

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

Niezawodno oprogramowania — fakty i mity

Porównywanie niezawodno ci oprogramowania i sprz tu Zawodno sprz tu wynika g ównie z fizycznych b dów pojedynczych komponentów, co jest cz sto konsekwencj przewrotno ci natury. Z kolei w oprogramowaniu usterki charakteryzuj si nieci g ym dzia aniem systemów cyfrowych. Wiedza o projektowaniu i in ynierii urz dze jest atwiejsza do udokumentowania w celu zapobie enia b dom ni wiedza o oprogramowaniu. Ponadto teorie awarii sprz tu s rozwijane od lat i umo liwiaj zapewnienie wysokiej niezawodno ci w wyrobach produkowanych1. Dla porównania, baza wiedzy o niezawodno ci oprogramowania jest bardzo ma a — st d nieod czne problemy w zapewnianiu stabilno ci dzia ania aplikacji. Oprogramowaniu zawsze towarzysz urz dzenia. Je li jednak znana jest niezawodno komponentu sprz towego, zawsze mo na zoptymalizowa pewno dzia ania systemu, do czaj c jedynie komponenty programowe2. Ka dy system sk adaj cy si z oprogramowania i sprz tu mo e zawie z powodu usterek aplikacji wywo anej za pomoc zewn trznych polece . Awaria oprogramowania jest definiowana jako odchylenie od oczekiwanych wyników zewn trznych lub niezgodno danych wyj ciowych programu z okre lonymi wymaganiami. Oprogramowanie mo e zawie , kiedy jest u ywane w nieoczekiwanej sytuacji. Zwykle awaria mo e wyst pi z winy oprogramowania lub nieprzewidzianych warunków jego wykorzystania. Inaczej mówi c, aby wyst pi b d, program trzeba uruchomi . Bie cy trend kosztów systemów sprz towo-programowych zmierza w kierunku nieproporcjonalnej dominacji oprogramowania. Koszt cyklu ycia (LCC) typowego oprogramowania przekracza cen sprz tu, a 80 – 90% tych wydatków wi e si z konserwacj aplikacji w zakresie naprawiania, adaptowania i rozwijania udost pnionego programu w celu zaspokojenia zmieniaj cych si i rosn cych potrzeb u ytkowników. Oko o 40% ceny rozwoju oprogramowania poch aniaj testy maj ce na celu usuni cie b dów i zapewnienie wysokiej jako ci programu3. Stosunek zawodno ci oprogramowania do sprz tu mo e wynosi a 100:1 w typowych komputerach bazuj cych na obwodach scalonych4. Dla bardziej skomplikowanych chipów ten stosunek mo e by jeszcze wy szy, co daje bardzo wyra ne wskazówki dotycz ce kosztów i jako ci. W tabeli 2.1 zamieszczono przegl d podstawowych ró nic mi dzy niezawodno ci sprz tu i oprogramowania.

Przyczyny zawodno ci oprogramowania Zawodno oprogramowania to istotny problem spo eczny. W rzeczywisto ci ma on globalne znaczenie i na jego rozwi zanie po wi ca si znaczne zasoby. W poni szych punktach opisujemy podstawowe przyczyny zawodno ci oprogramowania. x

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

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

Kategoria

Niezawodno sprz tu

Podstawowa przyczyna

Z powodu efektów fizycznych

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

Przyczyny w cyklu ycia Analizy

Nieprawid owe zrozumienie klienta Nieprawid owe zrozumienie klienta

Wykonalno

B dne wymagania u ytkownika

Projekt

B dy w fizycznym projekcie

B dy w projekcie programu

Rozwój

Problemy z kontrol jako ci

B dy w kodzie programu

Dzia anie

Usterka i awaria

B dy programu (lub inne defekty albo awarie)

B dne wymagania u ytkownika

Efekty stosowania Funkcja projektu Dziedziny Relacje czasowe Modele matematyczne

Obszar czasu

Funkcje

Obszar danych

Sprz t zu ywa si i zaczyna zawodzi Oprogramowanie nie zu ywa si , ale zawodzi w wyniku nieznanych defektów lub b dów Fizyka b du Umiej tno ci programisty Czas (t) Czas i dane „Krzywa wannowa” Funkcja malej ca Dobrze rozwini ta teoretycznie Dobrze rozwini ta teoretycznie, i akceptowana ale o niskiej akceptacji R = f( , t), = intensywno b dów R = f(b dy [lub defekty albo Wyk adnicza (sta a ) awarie], t) Weibulla (rosn ca ) Bez znaczenia

Brak zgodno ci mi dzy ró nymi proponowanymi modelami funkcji czasu B dy = f(testy na danych)

Modele wzrostu

Istnieje kilka modeli

Miary

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

Intensywno b dów, liczba wykrytych lub pozosta ych defektów (lub awarii)

MTTF (ang. mean time to failure, czyli redni czas do wyst pienia awarii) 6

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

Niezawodno oprogramowania — fakty i mity

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

Kategoria

Niezawodno sprz tu

Niezawodno oprogramowania

Techniki wzrostu

Projektowanie, przewidywanie

Przewidywanie

Techniki przewidywania

Diagramy blokowe, drzewa b dów Analiza cie ek (analiza wszystkich cie ek to nierozwi zywalny problem, poniewa liczba mo liwo ci w nawet prostych programach mo e zmierza do niesko czono ci), z o ono , symulacje

Testy i ewaluacja

Akceptacja projektu i produkcji

Akceptacja projektu

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

Testowanie cie ek, symulacje, b dy, posiew Bayesa

MIL-STD-781C

Brak

Równoleg o

Mo e poprawia niezawodno

Trzeba rozwa y najcz stsze przyczyny

Rezerwa

Automatyczne wykrywanie i poprawianie b dów, automatyczne wykrywanie usterek i prze czanie

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

Logika wi kszo ciowa

m elementów z n

Niepraktyczna

Projekt Operacje Zastosowanie nadmiaru

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

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

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

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

Brak uzgodnionych kryteriów. W nowych i z o onych systemach programista cz sto tworzy kryteria niezawodno ci, które nie zawsze spe niaj wymagania u ytkowników.

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

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

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

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

Brak odpowiednich zach t. Cz sto bod ce rynkowe i regulacyjne w zakresie niezawodno ci oprogramowania s niewystarczaj ce, podczas gdy istnieje wiele czynników promuj cych innowacyjne funkcje, wygod stosowania i b yskawiczny cykl rozwoju.

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

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego

na koszty, czas trwania cyklu i jako produktu dostarczanego klientowi, je li udost pniane oprogramowanie nie ma odpowiednich w a ciwo ci w zakresie wydajno ci. Bardzo cz sto dzieje si tak, poniewa mened er produktu nie ma czasu i rodkĂłw, a musi udost pni projekt w fazie produkcyjnej. Na dalszych etapach produkty s sprawdzane i przesiewane w celu wykrycia jednostek, ktĂłre s niezgodne ze specyfikacj . Te jednostki s naprawiane, przetwarzane lub odrzucane. Takie systemy kontroli jako ci bazuj na dwĂłch podstawowych za o eniach: x

Wymagania klientĂłw s spe nione, je li produkt znajduje si w ramach uzgodnionych ogranicze wyznaczanych przez specyfikacj .

Biznesowe skutki wydajno ci lub jako ci produktĂłw â&#x20AC;&#x17E;ledwo spe niaj cych wymagania specyfikacjiâ&#x20AC;? i â&#x20AC;&#x17E;na poziomie docelowymâ&#x20AC;? s takie same.

Jak si wkrĂłtce oka e, adne z tych za o e nie jest uzasadnione. W. Edwards Deming7 by jednym z pierwszych analitykĂłw zarz dzania, ktĂłrzy zdali sobie spraw z brakĂłw systemĂłw jako ci zale nych od kontroli. Jednak to japo ski in ynier przemys owy Genichi Taguchi jako pierwszy zaproponowa alternatywny system zarz dzania jako ci , nazywany metodami Taguchiego. To podej cie zwraca uwag na warto â&#x20AC;&#x17E;poziomu docelowegoâ&#x20AC;? i potrzeb zarz dzania jako ci ju na pocz tku procesu â&#x20AC;&#x201D; w dziale bada i rozwoju, na etapach projektu i in ynierii cyklu rozwoju oprogramowania â&#x20AC;&#x201D; a nie polegania na kontroli maj cej na celu wykrywanie i naprawianie b dĂłw.

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego Metody Taguchiego to zestaw zasad i metodologii projektowych maj cych na celu usprawnienie produktĂłw i procesĂłw. Te techniki sk adaj si na dziedzin wiedzy nazywan in ynieri jako ci, solidn in ynieri czy, zw aszcza w Stanach Zjednoczonych, metodami Taguchiego od nazwiska autora tego podej cia, dr. Genichiego Taguchiego (zobacz ramki 2.1, 2.2 i 2.3).

Ramka 2.1. ycie i czasy doktora Genichiego Taguchiego8

Doktor Genichi Taguchi mia znacz cy wp yw na powstanie metodologii zarz dzania jako ci skoncentrowanej na projekcie. Taguchi urodzi si w 1924 roku w Japonii. Po s u bie w Wydziale Astronomicznym Instytutu Nawigacji Japo skiej Marynarki Wojennej w latach 1942 â&#x20AC;&#x201C; 1945 pracowa w Ministerstwie Zdrowia i Opieki oraz Instytucie Statystycznym Ministerstwa Edukacji. Zyska bogat wiedz na temat technik projektowania eksperymentalnego i stosowania tablic ortogonalnych, ucz c si od nagradzanego japo skiego statystyka Matosaburo Masuyamy, z ktĂłrym zetkn si w czasie pracy w Ministerstwie Zdrowia i Opieki. Doprowadzi o to do jego zaanga owania jako konsultanta w firmie Morinaga Pharmaceuticals i jej organizacji nadrz dnej, Morinaga Seika.

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

W 1950 roku Taguchi do czy do nowo powsta ego Laboratorium Komunikacji Elektrycznej w Nippon Telephone and Telegraph Company z zadaniem zwi kszenia wydajno ci dzia u bada i rozwoju poprzez szkolenie in ynierów w wydajnych technikach. Taguchi pracowa tam przez ponad 12 lat i w tym czasie rozpocz tworzenie swojej metodologii, któr dzi nazywa si metodami Taguchiego lub solidn in ynieri (zobacz ramka 2.2). Wtedy by tak e konsultantem japo skiego przemys u. W wyniku tego japo skie firmy, mi dzy innymi Toyota i jej dostawcy, zacz y, pocz wszy od wczesnych lat 50., szeroko stosowa metody Taguchiego. Pierwsza ksi ka Taguchiego, która przedstawia a tablice ortogonalne, zosta a opublikowana w 1951 roku. W latach 1954 – 55 Taguchi pracowa jako profesor zaproszony w Indyjskim Instytucie Statystycznym w Kalkucie w Indiach. W czasie tej wizyty zetkn si ze s awnymi statystykami: Ronaldem A. Fisherem i Walterem A. Shewhartem. W latach 1957 – 58 Taguchi opublikowa pierwsz wersj swej dwutomowej pracy Design of Experiments. Do Stanów Zjednoczonych przyby po raz pierwszy w 1962 roku jako zaproszony cz onek grupy badawczej na Uniwersytecie Princeton. W tym czasie odwiedzi AT&T Bell Laboratories. W Princeton Taguchi by go ciem powa anego statystyka Johna Tukeya, który u atwi mu wspó prac ze statystykami przemys owymi z Bell Laboratories. W 1962 roku Taguchi otrzyma stopie doktora Uniwersytetu Kyushu. W 1964 roku Taguchi zosta profesorem na tokijskim Uniwersytecie Aoyama Gakuin, któr to funkcj piastowa do roku 1982. W 1966 Taguchi wraz z kilkoma innymi autorami napisa ksi k Management by Total Results, która zosta a przet umaczona na j zyk chi ski przez Yuin Wu, wspó pracownika Taguchiego przy wielu pó niejszych pracach. Na tym etapie metody Taguchiego by y praktycznie nieznane na Zachodzie, cho stosowano je w Tajwanie i Indiach. W tym czasie i w latach 70. wi kszo zastosowa metod Taguchiego dotyczy a procesów produkcji. Przej cie do projektowania produktów mia o miejsce pó niej. We wczesnych latach 70. Taguchi rozwin zagadnienie funkcji utraty jako ci. Wtedy te opublikowa dwie dalsze ksi ki oraz trzecie wydanie pracy Design for Experiments. Taguchi zosta laureatem nagrody Deming Application Prize w 1960 roku oraz nagród Deminga za pozycje ksi kowe w latach 1951, 1953 i 1984, a do pó nych lat 70. zyska szerokie uznanie w Japonii. W 1980 roku zosta zaproszony do Stanów Zjednoczonych, gdzie ponownie odwiedzi AT&T Bell Laboratories. Uda o mu si , mimo problemów z komunikacj , przeprowadzi udane eksperymenty, które pozwoli y zastosowa metody Taguchiego w korporacji Bell Laboratories. Po wizycie Taguchiego w Stanach Zjednoczonych w 1980 roku coraz wi cej ameryka skich fabryk zacz o stosowa jego metodologi . Mimo niech tnego przyj cia tych metod przez grono ameryka skich statystyków, co prawdopodobnie wynika o ze sposobu ich rozpowszechniania, najwi ksze korporacje Stanów Zjednoczonych zacz y stosowa metodologi Taguchiego. W 1982 roku Taguchi zosta doradc japo skiej Organizacji do spraw Standardów. Za wk ad w rozwój przemys u na ca ym wiecie Taguchi otrzyma wiele wyró nie : x

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

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

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego

medal imienia Shewharta Ameryka skiego Stowarzyszenia na rzecz Kontroli Jako ci;

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

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

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

Ramka 2.2. Metodologia in ynierii jako ci w zarysie8, 9 Metodologia Taguchiego dotyczy optymalizacji produktu i procesu na etapach projektowania oraz prac dzia u bada i rozwoju przed rozpocz ciem produkcji. Jest to metodologia zarz dzania jako ci stosowana we wczesnych fazach rozwoju produktu lub procesu, która w mniejszym stopniu koncentruje si na osi ganiu jako ci poprzez kontrol . Jest to wydajna technika, obejmuj ca testy projektu przed rozpocz ciem etapu produkcji, fabrykacji lub sk adania. Dzi ki temu jako staje si funkcj prawid owego projektu, a nie nawet cis ych testów i kontroli. Podej cia Taguchiego mo na u ywa tak e jako metodologii rozwi zywania problemów zwi zanych z produkcj i procesami w obszarze fabrykowania. Jest te coraz cz ciej stosowane w innych dziedzinach przemys u, na przyk ad przy rozwoju oprogramowania. W odró nieniu od zachodniego podej cia do jako ci, w metodologii Taguchiego jako jest postrzegana raczej w kategoriach utraty jako ci ni samej jako ci. Utrata jako ci jest definiowana jako „straty powodowane przez produkt w spo eczno ci od momentu jego udost pnienia”. Ta utrata obejmuje straty ponoszone przez firm w postaci kosztów przetwarzania i utylizacji, wydatki na konserwacj oraz przestoje wynikaj ce z awarii sprz tu i napraw gwarancyjnych. Nale y uwzgl dni tak e koszty klientów powodowane przez zawodno oraz nisk wydajno produktu, prowadz ce do dalszych strat po stronie producenta w cznie ze spadkiem jego udzia ów w rynku. Okre laj c docelowy poziom jako ci jako najwy szy mo liwy, Taguchi wi e prost kwadratow funkcj straty z odchyleniem od poziomu docelowego. Funkcja utraty jako ci pokazuje, e zmniejszanie zmienno ci w zakresie jako ci prowadzi do zmniejszania strat i zwi zanej z tym poprawy jako ci. Gdy uwzgl dnimy takie podej cie do utraty jako ci, to strata wyst pi nawet w przypadku, kiedy produkt spe nia wymagania stawiane przez specyfikacj , a jest minimalna, je li producent d y do poziomu docelowego. W praktyce dla u ytkowników nie jest wa na specyfikacja, prawda? Klienci chc , aby produkt dzia a nawet wtedy, kiedy napi cie pr du jest niskie, droga wyboista, a operator terminala nieprzeszkolony. Produkt musi dzia a na docelowym poziomie w ró nych warunkach. Mówi c inaczej, nale y projektowa z uwzgl dnieniem ró nych warunków stosowania produktu przez u ytkowników. To w interesie producenta le y utrzymywanie wydajno ci produktu lub procesu tak blisko poziomu docelowego, jak to ekonomicznie mo liwe. Funkcja straty mo e pos u y do podj cia decyzji projektowych w kategoriach finansowych. Pomaga zdecydowa , czy dodatkowe koszty zwi kszenia odporno ci i usprawnienia produkcji s usprawiedliwione oraz czy oka si zasadne w warunkach rynkowych.

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

Metod Taguchiego mo na u ywa w trybie „offline” w czasie projektowania lub na bie co w produkcji. Taguchi dzieli kontrol jako ci w trybie „offline” na trzy etapy. 1. Projektowanie systemu obejmuje tworzenie pomys u na projekt przy u yciu burzy mózgów, bada lub innych technik. Projektowanie systemu jako ca o ci obejmuje tak e inne narz dzia, techniki i metodologie, zw aszcza AHP (ang. Analytic Hierarchy Process), QFD (ang. Quality Function Deployment), TRIZ (ang. Theory of Inventive Problem Solving) i FMEA (ang. Failure Modes and Effects Analysis), opisane odpowiednio w rozdzia ach 8., 11., 12. i 13. 2. Projektowanie parametrów to istota metod Taguchiego. To pod tym wzgl dem Japo czycy tradycyjnie si wyró niali i osi gali wysokie poziomy jako ci bez wzrostu kosztów, co jest g ówn przyczyn ich przewagi konkurencyjnej. Testowane s nominalne w a ciwo ci projektu lub wybrane poziomy czynników procesu. Ustalane s kombinacje poziomów parametrów produktu lub poziomów operacji wchodz cych w sk ad procesu, które okaza y si najmniej wra liwe na zmiany w czynnikach rodowiskowych i inne niekontrolowalne elementy (szum). To zagadnienie opisujemy w rozdzia ach 16. i 17. 3. Projektowanie odporno ci nale y zastosowa do projektu produktu lub procesu, je li zmniejszenie wariancji uzyskane na etapie projektowania parametrów jest niewystarczaj ce. Ta faza dodatkowo zwi ksza odporno na czynniki maj ce du y wp yw na wariancj . Nale y zastosowa funkcj straty i po wi ci wi cej rodków tylko wtedy, je li jest to konieczne. Mo na zwi kszy odporno albo kupi lepsze materia y lub wyposa enie, je li jest to niezb dne, co podkre la japo sk filozofi inwestycji na ko cu, a nie na pocz tku, jak jest to praktykowane w firmach zachodnich.

Ramka 2.3. Taguchi o metodach Taguchiego10 x

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

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

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

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

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

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego

u ywaj dynamicznego stosunku SN jako wska nika wydajno ci do oceny solidno ci funkcji produktu. x

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

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

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

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

Metody Taguchiego zosta y uznane za jedno z najwa niejszych in ynieryjnych osi gni XX wieku. Cho techniki statystyczne u ywane przez Taguchiego maj pocz tki w eksperymentalnych praktykach projektowych rozwini tych przez angielskiego statystyka sir Ronalda Fishera, ich filozoficzne podstawy s niezaprzeczalnie japo skie. Metody Taguchiego i inne japo skie systemy zarz dzania jako ci , takie jak kaizen (ci g e usprawnianie), kanban (dok adnie na czas), zarz dzanie przez jako czy szczup a produkcja, zosta y zainspirowane rozwa aniami ameryka skiego guru z obszaru jako ci, W. Edwardsa Deminga, przedstawionymi w jego ksi kach: 14 Points of Management, Seven Deadly Diseases i Obstacles to Quality Products. Proponowana przez Richarda Zultnera adaptacja zasad Deminga do rozwoju oprogramowania jest opisana w rozdziale 5. Metody Taguchiego i inne systemy zarz dzania jako ci po o y y podwaliny pod niezwyk y rozwój Japonii jako pot gi przemys owej po II wojnie wiatowej. Trudno przeceni wp yw Deminga na prace Taguchiego. Podobnie jak inni japo scy specjali ci do spraw jako ci, Taguchi by pod du ym wp ywem Deminga. Aby zrozumie specyficzne podej cie Taguchiego, nale y przeanalizowa jego kontekst i korzenie. Metody Taguchiego i wspó czesne japo skie systemy zarz dzania jako ci mia y swe pocz tki po II wojnie wiatowej. Deming, którego cz sto okre la si mianem ojca wspó czesnego ruchu na rzecz jako ci, po raz pierwszy odwiedzi Japoni w 1946 roku. W nast pnych dziesi cioleciach kontynuowa wspó prac z rz dem oraz przemys em japo skim i wyszkoli tysi ce japo skich mened erów oraz in ynierów. Ci mened erowie byli zainteresowani wspó czesnymi ameryka skimi zasadami zarz dzania. Jednak Deming zaproponowa im co zupe nie nowego, co, jego zdaniem, mia o pomóc w przekszta ceniu Japonii w dobrze prosperuj ce spo ecze stwo i odbudowa jej pozycj jako znacz cej pot gi przemys owej. Istota zasad zarz dzania Deminga jest dobrze znana (zobacz ramk 2.4), cho nie s one zbyt szeroko stosowane poza Japoni . Te zasady obejmuj g os klienta, zmniejszanie wariancji, stosowanie wska ników statystycznych, zyskiwanie zaufania i szacunku

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

Ramka 2.4. Istota 14 punktów Deminga11 1. B d wierny zamiarom usprawniania produktów i us ug. Cel to osi gni cie konkurencyjno ci, pozostanie w grze i zapewnienie miejsc pracy. 2. Zarz d musi zda sobie spraw z wyzwa zwi zanych z jako ci , pozna zakres odpowiedzialno ci i przej przywództwo na drodze zmian. 3. Nale y przesta uwa a kontrol za najwa niejszy element osi gania jako ci. Trzeba wyeliminowa potrzeb masowych inspekcji poprzez wbudowanie jako ci w produkt. 4. Trzeba sko czy z nagradzaniem dzia a na podstawie ceny. W zamian nale y minimalizowa koszty czne. Ka dy produkt powinien by dostarczany przez tylko jednego dostawc , co tworzy d ugotrwa y zwi zek bazuj cy na lojalno ci i zaufaniu. 5. Nale y trwale i nieustannie usprawnia system produkcji i us ug, aby poprawi jako oraz wydajno , a tym samym ci gle zmniejsza koszty. 6. Trzeba prowadzi szkolenia zawodowe. Je li ludzie s nieodpowiednio wyszkoleni, nie b d pracowa w taki sam sposób, a to wprowadza zmienno . 7. Nale y wdro y system przywództwa. Deming wprowadza rozró nienie mi dzy przywództwem i nadzorem. Ten drugi bazuje na normach i poziomach. Celem nadzoru powinno by pomaganie ludziom, maszynom i urz dzeniom w lepszym wykonywaniu zada . Nadzór zarz du wymaga starannego przemy lenia, podobnie jak nadzór pracowników odpowiedzialnych za produkcj . 8. Trzeba pozby si l ku, aby ka dy móg wydajnie pracowa dla firmy. 9. Nale y znie podzia y mi dzy wydzia ami. Osoby odpowiedzialne za badania, projektowanie, sprzeda i produkcj musz pracowa jako zespó , aby przewidywa problemy z wytwarzaniem i stosowaniem produktów lub us ug. 10. Trzeba pozby si sloganów, napomnie i norm dla si y roboczej, które dotycz braku defektów i nowych poziomów produktywno ci. Takie napomnienia prowadz wy cznie do powstawania antagonizmów. Wi kszo przyczyn niskiej jako ci i wydajno ci le y po stronie systemu i tym samym znajduje si poza kontrol si y roboczej. 11a. Nale y wyeliminowa standardy pracy (normy) dla fabryki. Trzeba zast pi je przywództwem. 11b. Trzeba wyeliminowa zarz dzanie przez zadania oraz liczby (z celami numerycznymi) i zast pi je przywództwem. 12a. Nale y usun przeszkody, które pozbawiaj pracowników zatrudnianych na godziny prawa do dumy z pracy. Pracownicy nadzoru powinni odpowiada nie za same liczby, ale za jako . 12b. Trzeba usun bariery, które pozbawiaj zarz d i in ynierów prawa do dumy z pracy. Oznacza to mi dzy innymi rezygnacj z dorocznych rankingów wydajno ci i zarz dzania przez cele. 13. Nale y wprowadzi dynamiczny program edukacji i samodoskonalenia. 14. Trzeba zach ci wszystkie osoby w firmie do pracy nad przekszta ceniami. Transformacja to zadanie dla wszystkich.

Japo skie systemy zarz dzania jako ci i podej cie Taguchiego

wspó pracowników oraz ci g e usprawnianie w obszarze procesów, a tak e produktów i us ug. W Japonii podej cie Deminga by o z entuzjazmem studiowane i stosowane oraz mia o znacz cy wp yw na przemys tego kraju. W 1951 roku Japo skie Stowarzyszenie Naukowców i In ynierów (ang. Japanese Union of Scientists and Engineers — JUSE) uhonorowa o Deminga, nazywaj c jego imieniem presti ow nagrod z dziedziny jako ci. Jednak w Stanach Zjednoczonych teorie Deminga by y ignorowane przez prawie 30 lat. Uwa a si , e mog o to doprowadzi do utraty konkurencyjno ci wielu ga zi ameryka skiego przemys u, takich jak motoryzacja i AGD, w których japo skie korporacje poczyni y ogromne post py. Wiele prac Taguchiego by o inspirowanych 14 punktami zarz dzania Deminga. W szczególnym stopniu dotyczy to zasady braku zale no ci od inspekcji przy osi ganiu jako ci. W procesie rozwoju produktu Taguchi cofn si jeszcze o krok, k ad c nacisk na inspekcj w dziale bada i rozwoju oraz na etapie projektowania i in ynierii. Zwraca uwag na znaczenie tego, aby produkt dzia a na sta ym, docelowym poziomie, a nie by tylko ledwie zgodny ze specyfikacj . Na rysunkach 2.3, 2.4 i 2.5 zademonstrowali my, e mo na to osi gn w dwóch krokach. Najpierw nale y zmniejszy wariancj , a nast pnie dostosowa odpowiedni czynnik, aby osi gn wyniki mo liwie jak najbli sze docelowym wymaganiom klienta, trzeba te wzi pod uwag koszty, projekt i inne ograniczenia.

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

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

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

Ponadto Taguchi podkre la warto tolerancji projektu zarówno w rodowisku produkcyjnym, jak i rodowisku u ytkownika. W tym momencie warto przedstawi g ówne nakazy filozofii jako ci Taguchiego. Oto one. 1. Ci g a poprawa jako ci i redukcja kosztów s niezb dne dla przetrwania biznesu. 2. Wa n miar jako ci produktu jest strata ogólna spowodowana przez produkt w spo ecze stwie obliczana za pomoc funkcji straty jako ci. 3. Zmiana przedprodukcyjnych procedur eksperymentalnych z ró nicowania jednego czynnika na raz na modyfikowanie wielu czynników jednocze nie. Jest to tak zwane statystyczne projektowanie eksperymentów (ang. Statistical Design of Experiments — SDE) lub po prostu projektowanie eksperymentów (ang. Design of Experiments — DOE). Dlatego jako mo na wbudowa w produkt i proces. 4. Straty klienta wynikaj ce z niskiej jako ci s mniej wi cej proporcjonalne do kwadratu odchylenia cech wydajno ci od poziomu docelowego (warto ci nominalnej). Taguchi zmieni cele eksperymentów i definicj jako ci z osi gania zgodno ci ze specyfikacj na d enie do poziomu docelowego i minimalizacj zmienno ci. 5. Zmienno wydajno ci produktu (lub us ugi) mo na zmniejszy , sprawdzaj c nieliniowy wp yw czynników (parametrów) kontrolnych na cechy wydajno ci. Wszelkie odchylenia od poziomu docelowego prowadz do niskiej jako ci. Jednym z g ównych celów Taguchiego jest usprawnienie projektu produktu i procesu poprzez wykrycie kontrolowalnych czynników i ich warto ci, co minimalizuje zmienno w stosunku do wyniku docelowego. Ustawiaj c kontrolowalne parametry na ich optymalny poziom, mo na sprawi , e produkt b dzie bardziej odporny na zmiany w dzia aniu, stosowaniu i warunkach rodowiskowych. Podstawowa zasada metod Taguchiego dotyczy raczej usuwania negatywnych efektów przyczyn ni powodów tych niekorzystnych skutków. Dzi ki temu mo na uzyska produkt wy szej jako ci najmniejszym mo liwym kosztem. Ta strategia neutralizacji samych skutków, a nie przyczyn, jest m drym rozwi zaniem, poniewa mo e by atwiejsza, a tak e bardziej wydajna ze wzgl du na koszty i szybsza. Metody Taguchiego maj dwa kluczowe cele projektowe:

Istota metod solidnego projektowania Taguchiego

zmniejszenie i minimalizacj zmienno ci produktu i ekonomiczne osi gni cie poziomu docelowego,

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

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

Zagadnienie stosunku sygna u do szumu Wed ug Taguchiego na solidno trzeba zwróci uwag na etapie projektowania lub w dziale bada i rozwoju. Wi e si to ze specyficznym filozoficznym za o eniem, e prawdziw solidno mo na jedynie zaprojektowa i wbudowa w produkt lub projekt, a nie skontrolowa i naprawi . Mówi c inaczej, podstawowym has em jest „zapobiega , a nie leczy ”. Wymaga to tak e rozwi zywania problemów na pocz tku pracy, w dziale bada i rozwoju, w trakcie zaawansowanej in ynierii i projektowania, a nie w trakcie produkcji i kontroli lub, co gorsza, po dostarczeniu produktu do klienta. Metody Taguchiego zapewniaj wydajn ze wzgl du na koszty i czas metodologi projektowania oraz testowania produktów pod k tem solidno ci przed rozpocz ciem ich produkcji. Metody te s u tak e do rozwi zywania problemów ró nego rodzaju czy modyfikowania projektów wadliwych procesów. Poni ej znajduj si definicje niektórych podstawowych poj u ywanych w metodach Taguchiego. Sygna to co , co produkt (lub cz albo podzespó ) ma dostarcza , zgodnie z jego charakterystyk dzia ania lub funkcjonaln . W odbiorniku telewizyjnym lub telefonie sygna y to co , co produkt (odbiornik lub aparat) przekazuje jako obraz lub d wi k. Dobry sygna to taki, który zachowuje jako mimo szumu (wewn trznych i zewn trznych interferencji elektromagnetycznych w odbiorniku telewizyjnym lub telefonie).

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

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

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

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

Szumy powoduj , e produkty dzia aj niezgodnie ze specyfikacj lub ca kowicie zawodz . Dzia anie produktu jest zdominowane przez szum jednostkowy (wewn trzny) na wczesnych etapach cyklu ycia produktu, zewn trzny w trakcie stosowania i pogarszanie sprawno ci (mi dzy produktami) pod koniec ycia. Solidno i solidne projektowanie prowadz do braku wra liwo ci na czynniki powoduj ce szum na ró nych etapach cyklu ycia produktu, cho wp ywów tych nie mo na wyeliminowa i usuwane s jedynie ich efekty. Dla odbiorników telewizyjnych powszechnym szumem jest „ nie enie” ekranu, pioruny, sztormy, wahania napi cia i inne niekorzystne warunki dzia ania. W przypadku oprogramowania kluczowe czynniki zwi zane z szumem, które powoduj zmienno , to nieprawid owe korzystanie z aplikacji przez klientów, napastnicy i hakerzy, robaki i wirusy, przypadkowe lub celowo z o liwe naruszenie zabezpiecze , brak dokumentacji, nieodpowiednie szkolenia, awarie procedur, niedozwolony dost p i u ywanie oraz korzystanie z systemu do wykonywania zada , do których nie jest przeznaczony. Taguchi sugeruje, e jako miary jako ci nale y u ywa stosunku sygna u do szumu, SN (ang. signal-to-noise)12. Taguchi twierdzi, e stosunek SN: x

mo e s u y do oceny solidno ci funkcji produktu, poniewa reprezentuje funkcjonalno ;

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

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

Istota metod solidnego projektowania Taguchiego

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

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

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

Zagadnienie funkcji utraty jako ci Jak ju wspomnieli my, to zagadnienie jest podstawowym odst pstwem od zachodniego podej cia do jako ci. Taguchi zajmuje si bardziej utrat jako ci ni ni sam , a tak e skutkami takich strat dla klienta, producenta i spo eczno ci jako ogó u. Jasno wynika z tego, e jako produktu to co wi cej ni tylko niezawodno , a koszty produktu obejmuj nie tylko cen produkcji i rachunki za materia y. Klienci oczekuj niezawodno ci w czasie trwania cyklu ycia produktu, a w ostatecznym rozrachunku istotna jest optymalizacja kosztów tego cyklu. Klienci coraz bardziej domagaj si bezb dnych dostaw i dzia ania. Oczekuj ró nych dodatkowych funkcji i udogodnie . Coraz cz ciej te poszukuj stabilnego, wysokiej jako ci dzia ania na poziomie docelowym i nie zadowalaj si niestabilnym funkcjonowaniem w ramach specyfikacji. Zapewnienie dzia ania na poziomie docelowym mo e wymaga poniesienia znacz cych kosztów, ale te zapewnia korzy ci zarówno producentowi, jak i klientom. Jest to jedna z podstawowych zasad metodologii Taguchiego. Fowlkes i Creveling klasyfikuj koszty cyklu ycia wed ug nast puj cych kategorii13: x

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

koszty powi zane z obs ug konserwacji, gwarancjami, naprawami, wymianami, utylizacj i odzyskiwaniem;

koszty klienta, które obejmuj przestoje, koszty operacyjne i wynikaj ce z rozwi zywania b dów;

koszty marketingu, które obejmuj czas wypuszczania produktu na rynek, promocje oraz zatrzymywanie klientów i zdobywanie nowych.

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

Utrata jako ci jest definiowana jako „strata, któr produkt powoduje w spo eczno ci od czasu jego wprowadzenia”. Obejmuje to straty firmy zwi zane z kosztami przeróbek, utylizacji, konserwacji i przestojów wynikaj cych z awarii sprz tu, a tak e z roszczeniami gwarancyjnymi. S to równie koszty ponoszone przez klienta w wyniku zawodno ci i s abej wydajno ci produktu, co prowadzi do dalszych strat producenta wraz z utrat udzia ów w rynku. Mog pojawi si te straty w spo eczno ci, je li dane produkty lub us ugi wi si ze sk adowaniem odpadów, zanieczyszczeniem rodowiska, przest pczo ci czy zagro eniem bezpiecze stwa i zdrowia. Okre laj c warto docelow cech jako ciowych na najwy szym mo liwym poziomie, Taguchi wi e prost kwadratow funkcj straty z odst pstwami od warto ci docelowej. Funkcja utraty jako ci pokazuje, e redukcja zmienno ci w okolicach poziomu docelowego prowadzi do zmniejszania si strat, z czego wynika wzrost jako ci. Ta funkcja s u y do podejmowania decyzji projektowych na podstawie czynników finansowych i pozwala okre li , czy dodatkowe koszty, jakich wymaga wy sza jako , oka si warte poniesienia z perspektywy rynku. Z punktu widzenia producenta czne koszty mo na wyrazi w nast puj cy sposób:

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

Straty produkcyjne obejmuj utylizacj , przeróbki, opó nienia i tak dalej. Utrata jako ci to koszt awarii produktów, który powstaje po ich udost pnieniu. Obejmuje to straty w wyniku zwrotów, gwarancji i napraw, a tak e utraty dobrej opinii, co prowadzi do zmniejszenia udzia ów w rynku. Utrata Jako ci mo e by bardzo du a nawet wtedy, kiedy produkt jest zgodny ze specyfikacj . Ta warto jest równa zeru tylko wtedy, kiedy produkt dzia a dok adnie na poziomie docelowym. Taguchi proponuje przybli ony i atwy wzór na funkcj utraty jako ci (ang. quality loss function — QLF): Utrata = O2K, gdzie O = odst pstwo od poziomu docelowego; K = koszty rodków niezb dnych do zapewnienia dzia ania produktu na poziomie docelowym.

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

Istota metod solidnego projektowania Taguchiego

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

Pozwala okre li na podstawie takich szacunków poziom docelowy tolerancji i jako ci.

Stanowi wydajny pod wzgl dem czasu i kosztów proces szacowania optymalnego projektu. Inaczej mówi c, proces projektowania lepszego produktu jest ta szy i szybszy ni w przypadku tradycyjnego projektowania eksperymentów czy innych metod.

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

Zagadnienie solidnego projektowania Taguchi zaleca nast puj c strategi solidnego projektowania: x

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

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

Solidne projektowanie za pomoc metod Taguchiego przebiega w trzech nast puj cych etapach: x

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

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

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

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

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

Wyzwania na drodze do niezawodno ci oprogramowania — projektowanie oprogramowania godnego zaufania Oprogramowanie to najbardziej zdradliwy komponent ka dego systemu informatycznego. Dwa pozosta e elementy, sprz t i sieci komunikacyjne, uzyska y przez ostatnie 50 lat du o wy szy poziom wydajno ci i niezawodno ci. Na przyk ad wydajno mikroprocesorów wzros a w stopniu o oko o 200 milionów razy wy szym ni wydajno oprogramowania. Wspó czesne sieci komunikacyjne umo liwiaj przenoszenie olbrzymich ilo ci danych, obrazów i d wi ku oraz dost p do nich zarówno w obr bie organizacji, jak i globalnie. Wspó czesne sieci komunikacyjne, a zw aszcza Internet, wi si z gro b przypadkowego lub celowego nieupowa nionego dost pu oraz s podatne na inne zagro enia, jednak to braki projektowe w oprogramowaniu odpowiadaj za najwi ksz cz wra liwo ci i zawodno ci systemów informacyjnych. Nawet mimo niezwyk ego poziomu wydajno ci sprz tu, ostateczne wyniki dzia ania ka dego systemu informatycznego zale od niezawodno ci oprogramowania — i to jest tematem niniejszej ksi ki. W tabeli 2.2 opisujemy pewne cz sto stosowane definicje i atrybuty jako ci oprogramowania. Miary oprogramowania s omówione do szczegó owo w rozdziale 3., jednak w tym miejscu warto omówi kilka podstawowych zagadnie . Najbardziej fundamentalne z nich to poj cie samej jako ci. Jako oprogramowania mo na zdefiniowa jako stopie spe niania wymaga lub oczekiwa klientów albo u ytkowników przez system, komponent lub proces. Mo e to obejmowa kilka elementów, z których najcz ciej wymieniana jest wiarygodno oprogramowania. Zwi zana jest ona z ró nymi wymaganiami u ytkownika, w czaj c w to niezawodno , bezpiecze stwo, zabezpieczenia i dost pno 14. Jest to bliskie u ywanemu w tej ksi ce poj ciu oprogramowania godnego zaufania, które jednak obejmuje dodatkowo mo liwo zdobywania zaufania klientów i spe nianie ich jawnych, Wyzwania na drodze do niezawodno ci oprogramowania

Wyzwania na drodze do niezawodno ci oprogramowania

TABELA 2.2. Wybrane atrybuty zwi zane z jako ci oprogramowania

Jako oraz atrybuty i systemy jako ci

Opis

Jako

Stopie , w jakim systemy, komponenty lub procesy spe niaj , po pierwsze, jawne, niejawne i nieoczekiwane potrzeby lub oczekiwania klientów i u ytkowników oraz, po drugie, okre lone i ukryte wymagania innych partnerów.

Projektowanie pod k tem Six Sigma

System projektowania i rozwoju nowych produktów, procesów i us ug, które spe niaj wymagania klientów i s pozbawione defektów.

Projektowanie oprogramowania godnego zaufania (DFTS)

System projektowania i rozwoju oprogramowania, na którym mo na polega (obejmuje to niezawodno , bezpiecze stwo, zabezpieczenia, dost pno i mo liwo konserwacji, cho nie ogranicza si do tych cech) i które pozwala reagowa na klienta na ró nych etapach cyklu ycia oprogramowania.

Solidna architektura (nazywana tak e modelem rozwoju solidnego oprogramowania — RSDM)

Model rozwoju oprogramowania s u cy do tworzenia oprogramowania godnego zaufania (zobacz rysunek 2.6).

Solidne projektowanie

Metodologia utworzona przez Genichiego Taguchiego w celu rozwoju najni szym mo liwym kosztem produktów i procesów dzia aj cych na poziomie docelowym zgodnie z wymaganiami klienta, mimo obecno ci czynników, które powoduj zmienno w rodowisku u ytkownika i produkcyjnym.

Six Sigma

Filozofia, system zarz dzania i metodologia stosowane w celu usprawniania istniej cych produktów, procesów i us ug tak, aby by y pozbawione b dów i spe nia y wymagania klientów w ekonomiczny sposób.

Oprogramowanie

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

Dost pno oprogramowania

Mo liwo udost pniania przez oprogramowanie okre lonych funkcji, kiedy u ytkownik ich potrzebuje.

Wiarygodno oprogramowania

Stopie , w jakim systemy, komponenty lub procesy producenta oprogramowania potrafi spe nia okre lone wymagania oraz potrzeby i oczekiwania u ytkowników.

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

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

Jako oraz atrybuty i systemy jako ci

Opis

Solidno oprogramowania

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

Projekt oprogramowania

Architektura i kod programu wykonuj cego okre lon funkcj .

Mo liwo konserwacji oprogramowania

atwo modyfikowania systemów lub komponentów oprogramowania po ich udost pnieniu w celu naprawy b dów, poprawy dzia ania i innych cech lub zaadaptowania do zmienionego rodowiska. Cz sto okre la si j jako MTBF/(MTBF + MTTR).

Jako oprogramowania

Zdatno oprogramowania do u ytku. Stopie , w jakim oprogramowanie ma okre lony zestaw atrybutów potrzebnych do spe niania jawnych lub ukrytych potrzeb klienta i zapewnia jego zadowolenie. Prawid owe dzia anie programu jest niezb dne, ale niewystarczaj ce, je li oprogramowanie nie zapewnia satysfakcji klienta.

Atrybuty jako ci oprogramowania

Ró ne wymagania dotycz ce oprogramowania, takie jak niezawodno , bezpiecze stwo, zabezpieczenia i dost pno , potrzebne do spe nienia okre lonych lub ukrytych potrzeb.

Niezawodno oprogramowania

To poj cie jest zwi zane z jako ci projektu oprogramowania. Wi e si raczej z wykrywaniem b dów ni ich naprawianiem. Jest to mo liwo wykonywania okre lonej funkcji przez system lub komponent oprogramowania w okre lonych warunkach i czasie.

Bezpiecze stwo oprogramowania

Brak czynników, które mog spowodowa mier , obra enia, chorob , uszkodzenia, brak kontroli lub dost pu do danych, naruszenie prywatno ci lub szkody w sprz cie, mieniu i rodowisku.

Skalowalno oprogramowania

Mo liwo uruchomienia aplikacji komputerowej na wi kszej maszynie lub procesorach równoleg ych w celu obs ugi wi kszej liczby transakcji lub zapewnienie wy szej przepustowo ci tak, aby wydajno skalowa a si liniowo lub prawie liniowo pod wzgl dem ilo ci operacji. Oznacza to, e je li aplikacja potrafi obs ugiwa okre lon liczb transakcji na danym serwerze, powinna skalowa si tak, aby obs ugiwa a cztery razy wi ksz ich liczb na czterokrotnie wi kszym serwerze.

Wyzwania na drodze do niezawodno ci oprogramowania

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

Jako oraz atrybuty i systemy jako ci

Opis

Zabezpieczenia oprogramowania

Cechy oprogramowania dotycz ce jego odporno ci na atak i zapewniaj ce ochron poufno ci, integralno ci danych oraz dost pno ci systemu.

Szybko realizacji transakcji przez oprogramowanie

Tempo obs ugi transakcji przez aplikacj na danym komputerze, zwykle mierzone w tysi cach transakcji na minut .

Mo liwo aktualizowania oprogramowania

Mo liwo atwej zmiany konfiguracji oprogramowania w celu obs ugi wi kszej liczby, wi kszych lub bardziej skomplikowanych transakcji.

Przetwarzanie godne zaufania

System sk adaj cy si ze sprz tu, oprogramowania i sieci, na którym mo na polega (obejmuje to niezawodno , bezpiecze stwo, zabezpieczenia, dost pno i mo liwo konserwacji, cho nie ogranicza si do tych cech) i który umo liwia reagowanie na klienta na ró nych etapach cyklu ycia.

Oprogramowanie godne zaufania

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

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

Niezawodno ci, czyli mo liwo ci wykonywania przez oprogramowanie oczekiwanych funkcji w okre lonych warunkach i czasie. Jest to jako zwi zana z projektem oprogramowania i dotyczy raczej wykrywania b dów ni ich naprawiania.

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

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

Rozdzia 2 โ ข Wyzwania na drodze do oprogramowania godnego zaufania

RYSUNEK 2.6. Model rozwoju solidnego oprogramowania

Mo liwo ci konserwacji, ktรณra dotyczy atwo ci modyfikowania systemรณw lub komponentรณw oprogramowania po ich udost pnieniu w celu naprawy b dรณw, poprawy dzia ania lub innych cech albo adaptacji produktu do zmieniaj cego si rodowiska.

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

Wyzwania na drodze do niezawodno ci oprogramowania

obecno ci odpowiednich cech solidnego projektu oprogramowania, mo liwo ci prowadzenia szkole i przekazywania wiedzy, umiej tno ci pomocy w integracji istniej cych systemów, udost pniania pomocy technicznej po wdro eniu, mo liwo ci udost pniania zaktualizowanego oprogramowania i systemów oraz spe niania wymaga klientów w zakresie kosztów i harmonogramu dostarczania produktów. Szczególnie istotna jest mo liwo zdobywania zaufania klientów i spe nianie ich jawnych, niejawnych, a nawet nieoczekiwanych potrzeb. S to g ówne aspekty oprogramowania godnego zaufania, które jednak s potrzebne w ró nym stopniu w zale no ci od kategorii oprogramowania i jego zastosowa . Przyk adowo reagowanie na klienta to szczególnie wa ny element w przypadku oprogramowania dla przedsi biorstw. Wa ne jest tu, aby twórca oprogramowania zna i uwzgl dnia g os klienta (ang. voice of customer — VOC), interpretowa go prawid owo i móg na tej podstawie tworzy oprogramowanie godne zaufania. Warto poczyni pewne uwagi na temat zwrotu „godne zaufania”. W dziedzinie zarz dzania jako ci tego wyra enia po raz pierwszy u y Deming, który stosowa je w znaczeniu czynnika decyduj cego o wyborze dostawców w kontek cie „usuwania l ków” w ród pracowników. Uwa amy zastosowanie tego s owa przez Deminga i kontekst, w jakim go u ywa , za bardzo znacz ce dla komunikatu, który sami chcemy przekaza : godne zaufania i niezawodne oprogramowanie, a w zasadzie dowolny produkt i ka da us uga, mog by udost pniane tylko przez osoby godne zaufania. Tego zwrotu u yto tak e w programie przetwarzania godnego zaufania (ang. Trushworthy Computing — TWC) Microsoftu uruchomionym w 2002 roku. Prezes Microsoftu, Bill Gates, w prze omowych powiadomieniach przes anych w styczniu i lipcu 200215 do 50000 pracowników korporacji na ca ym wiecie napisa : „W przesz o ci starali my si , aby nasze oprogramowanie i us ugi by y atrakcyjne dla klientów ze wzgl du na nowe funkcje i przez mo liwo bogatego rozszerzania naszej platformy […] wykonali my pod tym wzgl dem doskona robot , jednak wszystkie te wspania e mo liwo ci oka si nieistotne, je li klienci nie b d ufa naszym produktom. Dlatego teraz w sytuacji wyboru mi dzy nowymi funkcjami i rozwi zywaniem problemu z zabezpieczeniami musimy stawia na zabezpieczenia”. Gates ponadto napisa , e wierzy, i TWC „b dzie najwy szym priorytetem dla firmy i przemys u przez nast pn dekad — celem jest utworzenie dla klientów rodowiska przetwarzania godnego zaufania, które jest równie niezawodne, co elektryczno zasilaj ca obecnie nasze domy i firmy”. Zapewnienie oprogramowaniu równej niezawodno ci, co w przypadku elektryczno ci, to olbrzymie wyzwanie dla przemys u zwi zanego z produkcj oprogramowania. Wyra nie wida potrzeb wspó pracy mi dzy przemys em rozwoju oprogramowania, profesjonalistami z bran y oprogramowania, u ytkownikami oprogramowania, agencjami odpowiedzialnymi za regulacje i instytutami badawczymi na ca ym wiecie. Proponowana w tej ksi ce metodologia DFTS zapewnia spójn struktur i technologi do rozwi zywania tego typu problemów z jako ci .

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

Model rozwoju solidnego oprogramowania — proces DFTS w praktyce Oprogramowanie w porównaniu z innymi produktami tworzonymi za pomoc in ynierii to przyk ad czystego projektu. Jak ju wspomnieli my, zawodno oprogramowania to zawsze wynik b dów w projekcie i intelektualnych braków cz owieka16. Dlatego jeszcze bardziej istotny jest w tym przypadku moment, w którym rozwi zywane s problemy z jako ci . Filozofia i systemy proponowane w tej ksi ce zapewniaj twórcom oprogramowania dzia aj c na wczesnych etapach metodologi , która pozwala zidentyfikowa optymalne funkcje i ustawienia solidnego (godnego zaufania) oprogramowania. Omówione wcze niej elementy systemu s przedstawione w proponowanym przez nas modelu rozwoju solidnego oprogramowania (ang. Robust Software Development Model — RSDM) utworzonym jako u atwienie do rozwoju oprogramowania godnego zaufania (zobacz rysunek 2.6). Ten model spe nia siedem kluczowych wymaga procesu rozwoju solidnego oprogramowania omówionego w rozdziale 1. Bazuje na logicznych zasadach zarz dzania i sprawdzonych narz dziach, technikach i metodologiach charakteryzuj cych si nast puj cymi kluczowymi elementami: x

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

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

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

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

Tworzeniem wielu wersji programu17 w sytuacji, kiedy potrzebne jest nadmiarowe oprogramowanie. Sprawia to, e statystycznie awarie nadmiarowych kopii s tak niezale ne, jak to mo liwe. W tym celu w ró nych programach nale y stosowa odmienne j zyki programowania, narz dzia programistyczne, technologie rozwoju i strategie testowania (zobacz rozdzia 14.).

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

Kluczowe zagadnienia

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

B dziemy na zmian odnosi si do modelu RSDM i procesu DFTS — model opisuje proces, a proces jest ilustrowany przez model. W kilku ostatnich dziesi cioleciach wyewoluowa y liczne modele rozwoju oprogramowania. Wiele z nich, na przyk ad model wodospadu, etapowe modele cyklu ycia, model spiralny czy model V, maj swe pocz tki w lotnictwie i innych ga ziach przemys u produkcyjnego, dlatego nie zawsze odpowiadaj rzeczywisto ci procesu rozwoju oprogramowania. RSDM to model iteracyjny, który umo liwia interakcj zarówno z wewn trznymi, jak i z zewn trznymi klientami oraz uchwycenie VOC w procesie rozwoju. Ponadto jest solidny i elastyczny, a tak e mo na go dostosowa do dowolnego procesu rozwoju oprogramowania. W nast pnych rozdzia ach opisujemy zastosowania tego modelu i jego elementy ze szczególnym uwzgl dnieniem kontekstu rozwoju oprogramowania dla przedsi biorstw. Chcemy przypomnie , e w organizacjach zajmuj cych si rozwojem oprogramowania i w innych firmach, w których prace nad technologiami informatycznymi stanowi istotn dzia alno , rozwój oprogramowania jest zbyt wa ny, aby pozostawi go samym in ynierom oprogramowania. Zarz dzanie t aktywno ci nale y do obowi zków prezesa i wy szej kadry zarz dzaj cej. Musz oni zapewni niezb dne przywództwo, utworzy prawid ow infrastruktur zarz dzania i rozwija rodowisko pod k tem tworzenia oprogramowania godnego zaufania.

Kluczowe zagadnienia x

Wieloaspektowe spojrzenie na jako jest niezb dne do zrozumienia i spe nienia zestawu jawnych oraz niejawnych wymaga klientów i innych partnerów.

Zazwyczaj zasady, systemy i metodologie zarz dzania jako ci odpowiednie dla wyrobów produkowanych mo na stosowa tak e dla oprogramowania. Jednak oprogramowanie wi e si ze specyficznym rodowiskiem projektowania i rozwoju. Trzeba zrozumie z o ono cz sto zwi zan z oprogramowaniem i uwzgl dni innowacyjno oraz trudno zada , do których obs ugi jest projektowane.

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

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

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

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

statystycznych, zdobywanie zaufania i szacunku wspó pracowników oraz ci g e usprawnianie. Deming wskazuje na braki systemów zarz dzania jako ci zale nych od kontroli. x

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

Filozofi zarz dzania jako ci Taguchiego mo na podsumowa w nast puj cy sposób: x

Ci g a poprawa jako ci i redukcja kosztów s konieczne dla przetrwania biznesu.

Wa n miar jako ci jest ogólna strata wygenerowana przez dany produkt w spo eczno ci, mierzona funkcj utraty jako ci.

Nale y wbudowa jako w produkt lub proces poprzez projekt, u ywaj c techniki statystycznego projektowania eksperymentów.

Straty klientów z powodu niskiej jako ci s nieliniowe i mo ne je oszacowa jako kwadrat odchylenia cech dzia ania od ich poziomu docelowego.

Zmienno dzia ania produktu mo na zmniejszy , analizuj c nieliniowy wp yw „czynników kontroli” na cechy funkcjonowania.

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

Oprogramowanie godne zaufania spe nia liczne jawne i niejawne potrzeby klientów, a tak e musi umo liwia dostosowanie produktu do nich. W kontek cie oprogramowania dla przedsi biorstw oprogramowanie godne zaufania musi spe nia przynajmniej nast puj ce wymagania: niezawodno , bezpiecze stwo, zabezpieczenia, mo liwo konserwacji i reagowanie na klienta.

Proces DFTS charakteryzuje si okre lonymi cechami. Oto one: x

prawdziwe zaanga owanie kadry zarz dzaj cej i wspieraj ca to infrastruktura;

mo liwo identyfikacji jawnych i niejawnych wymaga za pomoc QFD;

optymalizacja wymaga klienta poprzez wdro enie metod Taguchiego;

ustanowienie praktyki jednoczesnego pisania kodu i przeprowadzania testów;

stosowanie w razie konieczno ci nadmiarowego oprogramowania;

wdra anie odpowiednich narz dzi do zarz dzania jako ci i planowania, takich jak TRIZ, Pugh i FMEA;

stosowanie innowacyjnych narz dzi do rozwoju oprogramowania, takich jak projektowanie obiektowe.

Dodatkowe materia y

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

wiczenia internetowe http://www.asiusa.com/publications/images/HBR.pdf Po przeczytaniu artyku u Taguchiego i Clausinga dost pnego pod powy szym adresem przygotuj si do dyskusji wniosków na jego temat. 1. Przeanalizuj problemy zwi zane ze stylem my lenia „w ramach specyfikacji — poza specyfikacj ” powi zanym z podej ciem „zero defektów” w kontek cie oprogramowania. Jakie rozwi zanie oferuje metodologia Taguchiego? 2. Podaj trzy przyk ady „sygna u” i „szumu” w kontek cie rozwoju oprogramowania. 3. Zaproponuj zestaw zalece umo liwiaj cych usprawnienie procesu rozwoju oprogramowania. Ten artyku jest dost pny tak e w nast puj cych miejscach: x

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

http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_detail.jhtml?id= ´90114&referral=8636&_requestid=9765.

Pytania przegl dowe 1. Opisz, jak wieloaspektowe spojrzenie na jako pomaga zaspokoi potrzeby ró norodnych partnerów. Zilustruj odpowied przyk adami zwi zanymi ze znanym Ci oprogramowaniem. 2. Czy problemy z jako ci oprogramowania s zasadniczo odmienne od wyst puj cych w wyrobach produkowanych? Jakie s podobie stwa i ró nice mi dzy oprogramowaniem i wyrobami produkowanymi w zakresie procesu ich rozwoju? 3. Porównaj niezawodno oprogramowania i sprz tu. Wyja nij skutki takiego stanu rzeczy na przyk adzie trzech z o onych systemów sk adaj cych si z oprogramowania i sprz tu. 4. Wymie g ówne powody zawodno ci oprogramowania. Które z nich uwa asz za najwa niejsze? 5. Opisz dwa najwa niejsze problemy z tradycyjnymi systemami kontroli jako ci i wp yw, jaki maj na oprogramowanie.

Rozdzia 2 • Wyzwania na drodze do oprogramowania godnego zaufania

6. Opisz istot 14 punktów zarz dzania Deminga i wyja nij ich znaczenie w dzisiejszym wiecie. 7. Wyja nij, jak metody Taguchiego wi si z zaleceniami Deminga wymienionymi w 14 punktach i jak je wspieraj . 8. Jak brzmi pi filozoficznych nakazów podej cia Taguchiego? Wyja nij ich zwi zek z rozwojem oprogramowania. Czy w przypadku sprz tu s one inne? Je li tak, to w jaki sposób? 9. Podsumuj kluczowe zasady metod Taguchiego i trzy etapy solidnego oprogramowania. Opisz, jak wspomagaj one proces rozwoju oprogramowania. 10. Wymie i opisz pi g ównych wyzwa na drodze do tworzenia oprogramowania godnego zaufania. Zilustruj odpowied dwoma znanymi Ci produktami z dziedziny oprogramowania. 11. Opisz cechy modelu rozwoju solidnego oprogramowania. Wyja nij, jak te w a ciwo ci oraz sam model jako ca o mo na porówna z dwoma podobnymi modelami opisanymi w rozdziale 1.

Pytania do dyskusji i projekty 1. Jak 14 punktów zarz dzania Deminga rozwi zuje ograniczenia tradycyjnych systemów kontroli jako ci? Mo esz pos u y si tabelami 5.2, 5.3 i 5.4 z rozdzia u 5. Jak zastosowa wskazówki Deminga do bran y rozwoju oprogramowania? Przedstaw odpowied na zaj ciach. 2. Omów i porównaj zastosowanie metodologii Taguchiego w przypadku oprogramowania dla przedsi biorstw i produktów fabrykowanych. Mo esz pos u y si materia em z rozdzia ów od 16. do 19. Przedstaw odpowied na zaj ciach. 3. Opisz zalety i wyzwania zwi zane z wdra aniem w organizacji metodologii projektowania oprogramowania godnego zaufania (DFTS). Jakie s mo liwe ród a oporu przy jej wprowadzaniu? Jak mo na sobie z nimi poradzi ? Przedstaw odpowied na zaj ciach. 4. Wyobra sobie, e jeste cz onkiem zespo u zarz dzaj cego wysokiego stopnia kierowanego przez prezesa. Zespó otrzyma od zarz du firmy zajmuj cej si rozwojem oprogramowania zadanie identyfikacji g ównych przyczyn problemów z jako ci oprogramowania i zaproponowania platformy umo liwiaj cej ich rozwi zanie. Napisz informacj dla zarz du po wst pnej ocenie. Zaprezentuj j na zaj ciach.

Przypisy

Przypisy 1

Bev Littlewood i Lorenzo Strigini, Software Reliability and Dependability: A Roadmap, Proc. ICSE 2000, 22nd International Conference on Software Engineering, s. 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.

Ibid., punkt 1.3.3., s. 5.

D. Simmons, N. Ellis, H. W. Kuo, Software Measurement: A Visualization Toolkit for Project Control and Process Improvement (Prentice-Hall, 1998).

N. Logothetis, Managing for Total Quality (London, Prentice-Hall International, 1992), s. 27.

Zaadaptowane za przyzwoleniem, op. cit., Kuo i inni, s. 4.

W. Edwards Deming, Out of the Crisis (Cambridge, MA, MIT Press, 2000). Nale y zwróci szczególn uwag na punkt 3. z 14 punktów o zarz dzaniu.

http://www.asiusa.com/about/asi_thought_genichi.aspx.

http://www.berr.gov.uk.

Genichi Taguchi i Don Clausing, Robust Quality, „Harvard Business Review”, stycze – luty 1990, s. 68.

Zaadaptowane z ksi ki Out of Crisis Deminga.

Yuin Wu i Alan Wu, Taguchi Methods for Robust Design (Nowy Jork, ASME, 2000), s. 13 – 28.

William Y. Fowlkes i Clyde M. Creveling, Engineering Methods for Robust Product Design: Using Taguchi Methods in Technology and Product Development (Reading, MA, Addison-Wesley, 1997).

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

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

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

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.