In¿ynieria oprogramowania.
Jak zapewniæ jakoœæ
tworzonym aplikacjom

Autorzy: Bogdan Bereza-Jarociñski, Boles³aw Szomañski
ISBN: 978-83-246-1948-1
Format: 158u235, stron: 328

Twórz rozwi¹zania najwy¿szej jakoœci!

• Ile kosztuje najwy¿sza jakoœæ?
• Jak j¹ zapewniæ?
• Jakie znaczenie ma bezpieczeñstwo informacji?

In¿ynieria oprogramowania jest niezwykle obszern¹ dziedzin¹ wiedzy, zajmuj¹c¹ siê
wszelkimi aspektami produkcji oprogramowania. Obejmuje zagadnienia takie, jak
analiza, projektowanie czy te¿ wdro¿enie systemu informatycznego. Je¿eli kiedykolwiek
spotka³eœ siê z oprogramowaniem miernej jakoœci, niew¹tpliwie na którymœ z etapów
jego produkcji pojawi³ siê problem. Jak temu zapobiec?

O tym w³aœnie traktuje ta ksi¹¿ka. Dowiesz siê z niej, jak unikaæ b³êdów, tak aby
oprogramowanie, które wytworzysz, prezentowa³o najwy¿sz¹ jakoœæ! Poznasz podejœcie
do kwestii jakoœci w czasach wspó³czesnych oraz zobaczysz, jak temat ten by³ rozumiany
wczeœniej. Zdobêdziesz wiedzê na temat miar u¿ywanych w in¿ynierii oprogramowania
oraz najefektywniejszych metod i technik jego wytwarzania. Autor przedstawi Ci
równie¿ narzêdzia, które sprawi¹, ¿e Twoje rozwi¹zania stan¹ siê jeszcze lepsze.
Ponadto zobaczysz, jak wa¿ne s¹ tematy zwi¹zane z bezpieczeñstwem informacji.
Warto podkreœliæ, ¿e styl tej ksi¹¿ki ³¹czy lekkoœæ i przyjemnoœæ lektury z powa¿n¹
tematyk¹ poruszanych w niej zagadnieñ.

• Jakoœæ integralna
• Zarz¹dzanie ryzykiem
• Zarz¹dzanie procesami
• Cena jakoœci
• Spojrzenie na jakoœæ wczoraj, dziœ i jutro
• Zarz¹dzanie jakoœci¹
• Socjologiczne i antropologiczne podejœcie do jakoœci
• Certyfikacja w in¿ynierii oprogramowania
• Najlepsze metody oraz techniki
• Dostêpne narzêdzia, automatyzacja testów
• Istota bezpieczeñstwa informacji

Spraw, aby Twoje aplikacje by³y najwy¿szej jakoœci!

Spis tre"ci

Rozdzia% 1. Rozwa*ania wst-pne ...................................................................... 13

1.1. Nietypowa ksi!#ka: o jako$ci na weso%o ............................................................... 13
1.2. Jako$& integralna .................................................................................................. 13
1.3. Jako$& przedsi'wzi'& ............................................................................................ 14

Przyk%ad ........................................................................................................... 15
Zarz!dzanie projektami ................................................................................... 15
Zarz!dzanie procesami .................................................................................... 15
Zarz!dzanie celami biznesowymi .................................................................... 15
Zarz!dzanie jako$ci! ........................................................................................ 16

1.4. Podejmowanie decyzji i zarz!dzanie ryzykiem .................................................... 17

Podejmowanie decyzji i zarz!dzanie ryzykiem,

czyli wykorzystanie intuicji i racjonalno$ci .................................................. 17

Brakuje jednak podej$cia integralnego ............................................................ 17
Intuicji trzeba da& szans'! ................................................................................ 18
Mo#na si' nauczy&, jak wykorzystywa& w praktyce najlepsze $rodki

z dwojga $wiatów .......................................................................................... 18

1.5. Zintegrowane zarz!dzanie celami biznesowymi ................................................... 19

Budowanie si%y i powodzenia firmy na rynku ................................................. 19
Elementy jako$ci integralnej ............................................................................ 20

1.6. Zarz!dzanie procesami ......................................................................................... 21

Sukces w systematycznym doskonaleniu organizacji ...................................... 21
Na pocz!tku by% chaos ..................................................................................... 22
Op%aca si' praca dobrze zorganizowana .......................................................... 22
Drugi brat ........................................................................................................ 23
Zarz!dzanie procesem biznesowym ................................................................ 23

Rozdzia% 2. Dialektyka jako6ci .......................................................................... 25

2.1. Dlaczego jako$& si' op%aca? ................................................................................. 25
2.2. Komu bije jako$&? ................................................................................................ 26

Dwaj stolarze ................................................................................................... 26
Gorsze jest lepsze? ........................................................................................... 27
Czy stolarz zatrudni testera? ............................................................................ 28
Specjalno$&: testowanie programów ................................................................ 29
Ju# staro#ytni Grecy… .................................................................................... 29
Miliardy, co z dymem posz%y .......................................................................... 30
Nie trzeba katastrofy ........................................................................................ 30
Jak to sprzeda&? ............................................................................................... 31
Komu bije jako$&? ........................................................................................... 32

6

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

2.3. Poca%unek #ycia — transfuzja krwi dla informatyki ............................................. 32

My$li przewodnie ............................................................................................ 32
Testowanie wymaga celu ................................................................................. 33
Skutek zale#y od celu ...................................................................................... 33
Fachowo$& mo#e zaciemnia& g%ówne cele ....................................................... 33
Testujmy funkcje, a nie programy ................................................................... 34
Rozbie#ne cele mog! spowodowa& nieporozumienie ...................................... 34
Sprzeczne miary jako$ci .................................................................................. 34
Weryfikowa& czy aktualizowa&? Test jest postaw! mentaln! .......................... 35
Jako$& produktu — to tylko pocz!tek .............................................................. 35
Naturalna ewolucja — tester perfekcyjny ........................................................ 35
Testowanie w psychologii ............................................................................... 37
Teorie testowania w socjologii: naukowa weryfikacja .................................... 37
Kryteria normalno$ci — co jest normalne? ..................................................... 38
Pomiary ludzi ................................................................................................... 39
Jako$& w przemy$le farmaceutycznym ............................................................ 39
Testowanie w swataniu .................................................................................... 42
Audyt finansowy ............................................................................................. 44
Testowanie w przemy$le budowlanym ............................................................ 44
Testowanie w przemy$le samochodowym ....................................................... 46
Testowanie w krawiectwie .............................................................................. 48
Testowanie w sztuce ........................................................................................ 49
<ycie to testowanie .......................................................................................... 50
Bibliografia ...................................................................................................... 53

2.4. In#ynieria jako$ci — nauka czy szarlataneria? ..................................................... 54

Regu%y naukowego rozumowania .................................................................... 54
Ludzkie poznanie ............................................................................................. 55
Wa#no$& i weryfikacja wiedzy ........................................................................ 56
Wybór w%a$ciwej metody weryfikacji ............................................................. 60
Wykroczenia przeciw metodom naukowym .................................................... 61
Ró#ne populacje w badaniach QA ................................................................... 65
B%'dy obserwatora i skutki oczekiwania .......................................................... 66
Testowanie hipotez .......................................................................................... 66
Wiele uczestnicz!cych zmiennych .................................................................. 67
Konsekwencje i mo#liwo$ci ............................................................................ 68
Czy testowanie oprogramowania jest nauk!? .................................................. 68
Zalecenia ......................................................................................................... 69
Proces kontra jako$& produktu ......................................................................... 71
Negatywne skutki systemów jako$ci ............................................................... 72
Bibliografia ...................................................................................................... 73

Rozdzia% 3. Jako6> wczoraj, dzisiaj i jutro ......................................................... 75

3.1. Historia podej$cia do jako$ci (od Hammurabiego do Gatesa) .............................. 75

Definicje jako$ci .............................................................................................. 75
Jako$& we wspólnotach pierwotnych ............................................................... 76
Jako$& w staro#ytno$ci ..................................................................................... 77
Jako$& w $redniowieczu i w okresie odrodzenia .............................................. 81
Jako$& w XIX wieku ........................................................................................ 84
Jako$& w XX wieku ......................................................................................... 85
Zmiany w historii jako$ci ................................................................................ 89
Jako$& w informatyce ...................................................................................... 91
Jak! drog! posz%o oprogramowanie ................................................................. 92
Bibliografia ...................................................................................................... 93

Spis tre6ci

7

3.2. P'dzi parowóz historii: 20 lat przemian w informatyce ........................................ 94

Od sierpa i m%ota do Internetu ......................................................................... 95
Powolne zwyci'stwo u#yteczno$ci .................................................................. 96
Szybciej, wi'cej, dalej ..................................................................................... 97
Jako$& szyta na miar' ...................................................................................... 98
Samoobs%uga .................................................................................................... 99

3.3. W kryszta%owej kuli: in#ynieria oprogramowania za 10 lat ................................ 100

Typowe b%'dy przewidywania ....................................................................... 100
Szybko i intuicyjnie ....................................................................................... 102
Programowanie intencjonalne ........................................................................ 102
Testowanie eksploracyjne .............................................................................. 103
Spirale, iteracje, przyrost ............................................................................... 103

3.4. Szybko, zwinnie, ekstremalnie ........................................................................... 104

J'zyki programowania ................................................................................... 104
Architektury komponentowe ......................................................................... 105
Sztuczna inteligencja i programy samoucz!ce si' ......................................... 105
Podsumowanie: si%a czy inteligencja? ........................................................... 106

3.5. Drogowskaz do przysz%o$ci — m!dro$& b'dzie na serwerach, czyli ASP .......... 106

Babcia nie potrzebuje komputera ................................................................... 108
Czego potrzebuje babcia autora? ................................................................... 109
Szczegó%y rozwi!zania dla babci ................................................................... 109
Z czym nam si' to kojarzy? ........................................................................... 112
Kontrowersje ................................................................................................. 113
Jeszcze troch' recenzji — walka ze spamem ................................................. 113
Moc j'zyków ................................................................................................. 114
ZakoFczenie ................................................................................................... 115

3.6. Y2K — heca czy historia? Wspomnienia $wiadka ............................................. 115

Rozdzia% 4. ZarzDdzanie procesami ................................................................. 119

4.1. Zarz!dzanie jako$ci! — w%adza i zgie%k ............................................................. 119

Jak opanowa& stado bezg%owych kur, czyli zarz!dzanie konfiguracj! ........... 119
Rozmawia%a g'$ z prosi'ciem: raporty i $ledzenie b%'dów ............................ 120
Krajobraz przed bitw!: planowanie testów, analiza ryzyka ........................... 121
Husaria kontra pruska piechota: jak nie straci& impetu, nie trac!c g%owy? ....... 122
Krajobraz po bitwie: czy mo#na wypu$ci& produkt ju# jutro? ....................... 123
Obdzieranie poleg%ych, czyli jak by& m!drym po szkodzie ........................... 124
Ró#ne formy organizacji testowania .............................................................. 124
Kiedy zaczyna&, kiedy skoFczy&? .................................................................. 125

4.2. Znowu ten po$piech — jak szybko oceni& jako$& aplikacji? .............................. 125

Po$piech w informatyce ................................................................................. 125
Pomiary w po$piechu ..................................................................................... 126
Precz z grzybami ........................................................................................... 127
Grzybobranie ................................................................................................. 127
Testowanie uwzgl'dniaj!ce ryzyko ............................................................... 129
Jakie to %atwe... .............................................................................................. 129
Bilet do Davos ............................................................................................... 130
Jak spieszy& si' powoli .................................................................................. 130

4.3. Po co mierzy&? Miary w in#ynierii oprogramowania ......................................... 131

Czego nie mo#na zmierzy&, tego si' nie wie ................................................. 132
Ksi!#ka .......................................................................................................... 133

4.4. Mi'dzy biurokracj! a chaosem: ADP .................................................................... 134

K%opot ............................................................................................................ 134
Akcja i kontrakcja .......................................................................................... 135
Metametody ci'#kie: rezerwat le$nych dziadków .......................................... 136

8

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Metametody lekkie: rezerwat m%odych wilków ............................................. 136
Niedostatki rezerwatów ................................................................................. 137
ADP — nareszcie! ......................................................................................... 137
ADP od $rodka .............................................................................................. 138
Zadowoleni ludzie ......................................................................................... 138
Wysoka jako$& produktu ................................................................................ 139
Organizacja: wy#sza produktywno$& i sprawno$& w dzia%aniu ...................... 139
Proces nadzorowany, udoskonalany i daj!cy si' utrzyma& ............................ 139
Przedsi'wzi'cie zarz!dzane poprzez podejmowanie decyzji ......................... 139
Zapobieganie pomy%kom i b%'dom ................................................................ 139
Zasady ADP ................................................................................................... 140
Who is who .................................................................................................... 141
Referencje ...................................................................................................... 141

Rozdzia% 5. Socjologia i antropologia jako6ci .................................................. 143

5.1. In#ynier jako$ci — to nie brzmi dumnie ............................................................. 143

Kariera testera ................................................................................................ 144

5.2. Samotno$& testera: organizacje i konferencje ..................................................... 144

Szkolenia i certyfikaty ................................................................................... 145

5.3. Psychologia projektu .......................................................................................... 146

Przyk%ad z projektu ........................................................................................ 147
Co wynika z nieporozumieF? ........................................................................ 148
Kreatywno$& .................................................................................................. 149
Negocjacje ..................................................................................................... 149
Asertywno$& .................................................................................................. 150
Wyst!pienia publiczne ................................................................................... 150
Motywacja i zarz!dzanie zespo%em ............................................................... 151
Trening antystresowy i zarz!dzanie emocjami .............................................. 151
Zarz!dzanie ryzykiem i podejmowanie decyzji ............................................. 152

5.4. Dobre decyzje: intuicja i racjonalno$& ................................................................ 153

Streszczenie ................................................................................................... 153
Wprowadzenie ............................................................................................... 153
Na przystawk': trzy krótkie historie, aby skusi& czytelnika .......................... 154
Opowiadanie o wybieraniu metod testowania ............................................... 155
Opowiadanie na temat „Czy jeste$my gotowi podj!& decyzj'?” ................... 155
Psychologia podejmowania decyzji ............................................................... 156
Nieprzechodnio$& preferencji ........................................................................ 156
Preferencja czasowa i opóXniona gratyfikacja ............................................... 157
Percepcja prawdopodobieFstwa ..................................................................... 158
Co to jest testowanie uwzgl'dniaj!ce ryzyko? ............................................... 164
Statystyka: podejmowanie decyzji w warunkach niepewno$ci ...................... 165
Strategie decyzyjne ........................................................................................ 167
Podejmowanie decyzji przy u#yciu statystyki Bayesa ................................... 168
Bibliografia .................................................................................................... 171

5.5. Psychologia jako$ci ............................................................................................ 172

Psychologia i socjologia testowania .............................................................. 172
Status tego rozdzia%u ...................................................................................... 172
Dysonans poznawczy .................................................................................... 172
Psychologia testowania .................................................................................. 172
Praca konstruktywna i motywacja ................................................................. 173
BezpieczeFstwo, niepokój ............................................................................. 174
Przegl!dy ....................................................................................................... 174
Dynamika grupowa ........................................................................................ 175
Studium komunikacji ..................................................................................... 175
Hierarchia potrzeb wg Maslova ..................................................................... 176

Spis tre6ci

9

Osobiste zainteresowania i cele (teoria Hollanda) ......................................... 176
Wnioski ......................................................................................................... 177
Opis modelu Hackmana ................................................................................. 177

5.6. Czy warto si' SPIN-a&? ...................................................................................... 178

Organizacje zajmuj!ce si' jako$ci! w Polsce ................................................ 178
Gdzie jest Forum Romanum? ........................................................................ 179
Quo vadis, udoskonalanie procesów? ............................................................ 180

5.7. W poszukiwaniu idealnych pracowników i szefów ............................................ 181

Jacy s! ludzie? ............................................................................................... 181
Mierzenie ludzi .............................................................................................. 182
THOMAS INTERNATIONAL ..................................................................... 184
Zastosowanie THOMAS-a w praktyce .......................................................... 186
Autystyczni testerzy ...................................................................................... 187

Rozdzia% 6. Interakcja, u*yteczno6>, wygoda .................................................. 191

6.1. Inwazja szaleFców .............................................................................................. 191
6.2. Jak ulepszy& $wiat? ............................................................................................. 193

Frustracja, poni#enie, agresja ......................................................................... 193
SzaleFcy rz!dz! domem wariatów ................................................................. 194
Sze$& grzechów g%ównych ............................................................................. 194
Nie$wi'te przymierze .................................................................................... 195
Pomoc nadci!ga ............................................................................................. 196

6.3. Psychologiczne podstawy u#yteczno$ci .............................................................. 196

Stan obecny ................................................................................................... 196
Lista kontrolna niektórych czynników u#yteczno$ci ..................................... 197

Rozdzia% 7. Gycie towarzyskie i uczuciowe ...................................................... 201

7.1. Adwentowa gwiazda 2003 .................................................................................. 201

Adwentowa gwiazda ...................................................................................... 201
Albo$my to jacy-tacy? ................................................................................... 202
<ycie towarzyskie i uczuciowe ...................................................................... 202
Koniec wojny niemiecko-brytyjskiej ............................................................. 203
O co tyle szumu? ........................................................................................... 203
O chorobie wspó%uzale#nienia ....................................................................... 204

7.2. Kupuj!c wiedz': przewodnik po szkoleniach ..................................................... 205

Motto ............................................................................................................. 205
Podstawy ....................................................................................................... 205
Pi'& z%otych zasad, jak znaleX& szkolenie testowe ......................................... 206

7.3. Jak sprzedawa& nietypowe szkolenia? Podr'cznik cynicznego sprzedawcy ....... 209

Wizja — pocz!tki .......................................................................................... 209
Przyn'ta ......................................................................................................... 210
Strategia ......................................................................................................... 211
Motywacja nauczania = dochód z nauczania – alternatywny zysk ................ 211
Planowanie .................................................................................................... 212
Nauczyciele ................................................................................................... 212
Czyni!c karier' nauczyciela atrakcyjn! ......................................................... 213
Struktura pakietu szkoleniowego ................................................................... 214
Praktyczne techniki szkoleniowe kontra teoria .............................................. 216
\wiadectwa i egzaminy ................................................................................. 217
Pakiety — modu%owy model kursu ................................................................ 217
Wykonanie — licz! si' praktyczne szczegó%y ............................................... 218
Bóg czy mamona? Zasady czy si%y rynkowe? ............................................... 220
Konkurencja .................................................................................................. 221
Do zapami'tania ............................................................................................ 221

10

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

7.4. Papierki i $wiadectwa. Certyfikacja w in#ynierii oprogramowania .................... 222

Sens certyfikacji w przemy$le informatycznym ............................................ 222
Certyfikacja w dziedzinie zapewnienia jako$ci i testowania ......................... 223
Rodzaje certyfikatów ..................................................................................... 223
Po#ytki z certyfikatów ................................................................................... 224
Zagro#enia ..................................................................................................... 224
ASQ Certified Reliability Engineer ............................................................... 225
IEEE Certified Software Development Professional ..................................... 226
QAI (Quality Assurance Institute) ................................................................. 227
Certified Quality Analyst ............................................................................... 227
Certified Software Test Engineer .................................................................. 227
BCS/ISEB: SW Testing Foundation Certificate,

SW Testing Practitioner Certificate ............................................................. 227

7.5. ISTQB: certyfikaty mi'dzynarodowe .................................................................... 228
7.6. To po prostu bzdura! ........................................................................................... 229

Wyznania sfrustrowanego trenera jako$ci ..................................................... 229
Wed%ug ISEB i ISTQB… .............................................................................. 230
Jak wybiera si' przypadki testowe w rzeczywisto$ci? ................................... 231
Pe%ny obraz .................................................................................................... 233
W koFcu: przyk%ad ......................................................................................... 235

Rozdzia% 8. Metody i techniki ......................................................................... 237

8.1. Sztuka, rzemios%o, nauka .................................................................................... 237

Powiedzmy, #e zbli#aj! si' wybory ............................................................... 237
Grupa reprezentatywna .................................................................................. 237
Na tym samym polega testowanie ................................................................. 238
Sztuka ............................................................................................................ 238
Rzemios%o ...................................................................................................... 239
Nauka ............................................................................................................ 240

8.2. Szlachetna sztuka testowania oprogramowania .................................................. 241

Nowa ksi!#ka ................................................................................................. 241
Klasyka od$wie#ona ...................................................................................... 242
Nazewnictwo ................................................................................................. 243

8.3. <eby banki ros%y w si%', a klienci #yli dostatniej ................................................ 244

Praca #mudna, mozolna, ale za to jaka ja%owa! ............................................. 244
Kontrola instalacji wodnej pod ci$nieniem .................................................... 245
Poci!gi pod specjalnym nadzorem ................................................................. 246
Szukanie dziury w ca%ym ............................................................................... 246
Czego u#ytkownik nie lubi najbardziej? ........................................................ 247
Jako$& jest za darmo ...................................................................................... 247

8.4. KraFcowo zwinne eksploracyjne piramidy ......................................................... 247

Historia polityczna ......................................................................................... 247
Ostrze#enie .................................................................................................... 248
Nowa religia .................................................................................................. 249
Zastosowanie eksploracji ............................................................................... 251

8.5. Cyryl jak Cyryl, ale metody! .............................................................................. 251

Nie warto marnowa& czasu ............................................................................ 251
Ryzyko jest zbyt du#e .................................................................................... 252
Testowanie — osobna specjalno$&? ............................................................... 252
Czy test mo#e si' op%aca&? ............................................................................ 253
Rachunek zysków i strat ................................................................................ 253
Kosmiczne pieni!dze ..................................................................................... 253
Co przetestowa&, a co zlekcewa#y&? ............................................................. 253
Sztuka testowania .......................................................................................... 254
Tester jako rzemie$lnik .................................................................................. 254

Spis tre6ci

11

Metody formalne ........................................................................................... 255
Ch%op $pi, a zbo#e samo ro$nie ...................................................................... 255
Kiedy testowa&? ............................................................................................. 255
Kto b'dzie testerem? ..................................................................................... 256
Polowanie na pluskwy ................................................................................... 256
Schwytana pluskwa na uwi'zi ....................................................................... 257
Zaplecze frontu, czyli logistyka testowania ................................................... 257
Test na co dzieF ............................................................................................. 258

Rozdzia% 9. Warsztat fachowca ....................................................................... 259

9.1. Automatyzacja testów ......................................................................................... 259

Co to jest automatyzacja testowania? ............................................................ 260
Co znajduje si' w skrzynce ze z%otem: po#ytki z automatyzacji .................... 260
Gdzie rozmieszczone s! miny: niebezpieczeFstwa automatyzacji ................. 261
Na zakoFczenie .............................................................................................. 264

9.2. Czy jako$& jest za darmo? Op%acalno$& automatyzacji ....................................... 264

Krótki poradnik dla szefów dzia%ów informatyki .......................................... 264
Przekuwamy infrastruktur' na lemiesze ........................................................ 265
Cyryl jak Cyryl, ale metody! ......................................................................... 266
Przez namolno$& do pedagogicznego sukcesu ............................................... 266
Jako$& jest za darmo? .................................................................................... 266
Prosta zasada z%otego $rodka ......................................................................... 266
Kombajnem przez preri' ................................................................................ 267
Potrzeba, jak zwykle, fachowców .................................................................. 268
Sierpy, snopowi!za%ki i kombajny ................................................................. 270
Gdzie szuka& dalej? ....................................................................................... 272

Rozdzia% 10. BezpieczeNstwo informacji ............................................................ 273

10.1. BezpieczeFstwo informacji: historia i stan obecny ............................................. 273

Wprowadzenie — bezpieczeFstwo informacji dawniej ................................. 273
Ochrona fizyczna i konstruowanie niezawodnego sprz'tu ............................ 276
Zapewnienie jako$ci oprogramowania ........................................................... 277
Zapewnienie bezpieczeFstwa oprogramowania ............................................. 278
Zapewnienie bezpieczeFstwa systemów informatycznych ............................ 281
Zarz!dzanie bezpieczeFstwem informacji ..................................................... 283
Systemy zarz!dzania bezpieczeFstwem

informacji wed%ug norm ISO serii 27000 .................................................... 284

Próba przewidywania przysz%o$ci .................................................................. 290
Bibliografia .................................................................................................... 292

10.2. Walka z cieniem — zabezpieczenia i odporno$& w praktyce .................................. 295

Streszczenie ................................................................................................... 295
Co to jest „bezpieczeFstwo”? ........................................................................ 295
Definicje bezpieczeFstwa .............................................................................. 296
Gdzie szuka& b%'dów zabezpieczenia? .......................................................... 297
Testowanie zabezpieczeF ............................................................................... 298
Ile testowa& zabezpieczenia? ......................................................................... 298
Wra#liwe cz'$ci cia%a smoka ......................................................................... 299
U#yteczno$& ................................................................................................... 300
Wykonanie ..................................................................................................... 301
Aspekty organizacyjne ................................................................................... 301
Proces testowania bezpieczeFstwa ................................................................. 302
Monitoring w trakcie dzia%ania operacyjnego ................................................ 303
Bibliografia .................................................................................................... 304
Organizacje, firmy, us%ugi i normy ................................................................ 305
Narz'dzia ....................................................................................................... 305

12

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

10.3. BezpieczeFstwo — praca u podstaw ................................................................... 306

Du#o ha%asu o bezpieczeFstwo ...................................................................... 306
BezpieczeFstwo wielopoziomowe ................................................................. 306
Trzy $wiaty bezpieczeFstwa .......................................................................... 307
Normy, audyt, standardy ................................................................................ 307
Policjanci ....................................................................................................... 307
Testy penetracyjne ......................................................................................... 308
Praca u podstaw ............................................................................................. 308
In#ynieria wymagaF bezpieczeFstwa ............................................................. 308
Mo#liwo$ci analizy statycznej ....................................................................... 309
B%'dy na poziomie kodowania: testy jednostkowe ........................................ 310
BezpieczeFstwo czy bezpieczeFstwo? ........................................................... 310
Profits, stupid! ............................................................................................... 311
Leczy& czy zapobiega&? ................................................................................ 312
Praca #mudna, mozolna, za to — jaka ja%owa! .............................................. 312

Skorowidz .................................................................................... 313

Rozdzia 4.

Zarz&dzanie procesami

4.1. Zarz&dzanie jako"ci&

— w2adza i zgie2k

Tak jak Wenus — podobno — wy%oni%a si' z morskiej piany, tak z chaotycznej biega-
niny, nerwowych zebraF, nadgodzin programistów, rozpaczliwej krz!taniny testerów,
zszarganych nerwów kierownika projektu oraz gróXb zniecierpliwionego klienta ma
si' wy%oni& Ona: aplikacja-marzenie. Bezb%'dna. Zaspokajaj!ca wszystkie, nawet naj-
skrytsze marzenia klienta. Idealna.

Wa#n! rol' w tym procesie odgrywa testowanie. To test powinien ostrzec: „Panowie,
mieli$my budowa& Wenus, a na razie widzimy tutaj pi'ciog%owego wielb%!da!”. Test
przypomni, ze bogini pi'kno$ci powinna mie& dwie, nie za$ trzy nogi. Test policzy
palce u r!k i zawo%a, #e cztery palce uchodz! w komiksach, ale nie w rzeczywisto$ci.

O ile nietrudno odró#ni& pi'ciog%owego wielb%!da od Wenus, o tyle b%'dy oprogramo-
wania nie zawsze s! oczywiste i rzucaj!ce si' w oczy. Zdemaskowanie ich wymaga
skrz'tnej pracy, wspólnego wysi%ku wielu osób, którymi kto$ musi zarz!dza& i kierowa&.
Jak? — o tym w%a$nie b'dzie mowa w dalszej cz'$ci rozdzia%u.

Jak opanowa> stado bezg%owych kur,
czyli zarzDdzanie konfiguracjD

Zg%oszenie b%'du — dok%adny opis objawów i okoliczno$ci awarii, sporz!dzony przez
testera sporym nak%adem pracy po to, by u%atwi& programi$cie znalezienie i zlikwido-
wanie przyczyny awarii. Programista bardzo si' dziwi: przecie# ten b%!d zosta% usu-
ni'ty ju# dwa tygodnie wcze$niej! „Pewnie u#y%e$ z%ej wersji”—– powiada testerowi.
„Ale# sk!d, g%ówne okno dialogowe wy$wietli%o numer najnowszej wersji, Z15” — opo-
nuje tester. „Tak, ale to wersja programu g%ównego. Ten modu% móg% mie& inn! wersj'!”.
Sprawdzaj! obaj. Okazuje si', #e adres 0xA1F0 zawiera warto$& 0xE, a wi'c wersja

120

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

numer czterna$cie feralnego modu%u. Tester poci si' i %!czy program ponownie, tym
razem z najnowsz! wersj!. Awaria nie pojawia si' wi'cej: dobrze. Niestety, po dwóch
tygodniach powraca! Co si' sta%o? Po pó% dnia dochodzeF udaje si' ustali&, #e nowo
zatrudniony programista przez pomy%k', %!cz!c program, znowu pos%u#y% si' star! wer-
sj! feralnego modu%u…

Brzmi to znajomo? Oczywi$cie. Mamy tu do czynienia z klasycznymi symptomami
niedostatków zarz!dzania konfiguracj!.

No, ale co to ma wspólnego z zarz!dzaniem testami? Jak w opisanym przyk%adzie
— bardzo wiele. System czy program (zw%aszcza niezbyt skomplikowany) mo#e si'
niekiedy uda& zbudowa& — kosztem pewnego czasoch%onnego zamieszania — mimo
braków w zarz!dzaniu konfiguracj!. Natomiast zapewnienie jako$ci bez dobrze funk-
cjonuj!cego zarz!dzania konfiguracj! jest zwykle niemal bezu#yteczne. Zidentyfikowane
przez testerów awarie okazuj! si' albo dotyczy& nieaktualnej wersji, albo wymagaj!
detektywistycznej pracy, aby znaleX& ich przyczyn' w chaosie spl!tanych wersji po-
szczególnych modu%ów systemu. Marnuje si' w ten sposób wiele czasu i wysi%ku, przez
co test tylko w ograniczonym stopniu dostarcza swego najwa#niejszego produktu: in-
formacji pozwalaj!cej na znajdowanie i usuwanie b%'dów.

Z tego w%a$nie powodu cz'sto zespó% testuj!cy, a nie ca%y projekt informatyczny, jest
gor!cym zwolennikiem uporz!dkowania Xle dzia%aj!cego zarz!dzania konfiguracj!. Nie
jest to dobre rozwi!zanie, ale o wiele lepsze ni# dobrowolne oddanie si' w r'ce cha-
osu, marnotrawstwa i ba%aganu. Cho& wi'c nie chodzi tu o testowanie sensu stricto,
niejednemu kierownikowi zespo%u testuj!cego przyjdzie si' z t! problematyk! zmierzy&
i warto sobie z tego zdawa& spraw'. Jak konkretnie si' to robi: zarz!dzanie i kontrol'
wersji, budow' konfiguracji podstawowych (baselines) — to s! ju# zagadnienia na
osobny rozdzia%.

Rozmawia%a g-6 z prosi-ciem:
raporty i 6ledzenie b%-dów

Kiedy tester natknie si' na awari' b'd!c! symptomem tkwi!cego w programie b%'du,
fakt ten niesie w sobie dwa rodzaje informacji. Po pierwsze, ilo$& znajduj!cych si'
w programie b%'dów jest podstawow! miar! jego jako$ci, a wi'c kluczow! wielko$ci!,
któr! nale#y wzi!& pod uwag', dokonuj!c decyzji dotycz!cych wdro#enia, wprowadze-
nia do produkcji czy dostarczenia klientom nowej wersji programu. Po drugie, zaobser-
wowana awaria pozwala zwykle zidentyfikowa& b'd!cy jej przyczyn! b%!d, usun!& go
i w ten sposób podnie$& jako$& programu.

Ani w jednym, ani w drugim przypadku nie wystarczy, by ta wiedza pozosta%a w g%owie
testera. Trzeba j! przekaza& programi$cie, aby rozpocz!% poszukiwania przyczyny
awarii, oraz kierownikowi projektu, aby móg% sporz!dzi& statystyki b%'dów i oszacowa&
bie#!c! jako$& konstruowanego systemu. Nawet je$li projekt jest jednoosobowy, nie
zawsze daje si' wszystko zapami'ta& i prowadzenie notatek na temat znajdowanych
i usuwanych b%'dów pozwala na unikni'cie pomy%ek.

Tym celom — przekazywaniu oraz gromadzeniu informacji o awariach i b%'dach — s%u#!
tak zwane raporty albo zg-oszenia b-.dów.

Rozdzia% 4. ZarzDdzanie procesami

121

Niektóre traktuj!ce o testowaniu Xród%a (m.in. t%umaczona na j'zyk polski ksi!#ka
amerykaFskiego autora Rona Pattona Testowanie oprogramowania

1

) po$wi'caj! wiele

miejsca udzielaniu rad, jak powinien post'powa& tester, aby dopilnowa&, #eby znale-
ziony b%!d rzeczywi$cie zosta% potraktowany powa#nie i naprawiony. Takie podej$cie
wydaje si' by& stawianiem sprawy na g%owie. Po pierwsze, tester ma inne zaj'cia ni#
zast'powanie — niefrasobliwego wida& — kierownika projektu i $ciganie programistów.
Po drugie, taka sytuacja stwarza realne zagro#enie sprowokowania konfliktów mi'dzy
testerami a konstruktorami. Po trzecie wreszcie, tester nie musi mie& i zwykle nie ma
pe%nej wiedzy potrzebnej do prawid%owej oceny wagi znalezionego b%'du. Do tego
konieczna jest — zale#nie od rodzaju b%'du — jeszcze wiedza na temat struktury i prio-
rytetów wymagaF, potrzeb klienta, architektury systemu. Nie jest wcale oczywiste, #e
ka#da awaria wymaga natychmiastowego rzucenia wszystkich dost'pnych $rodków
w celu jej rozbrojenia i usuni'cia! To zale#y mi'dzy innymi od zwi!zanego z ni! ryzyka.
Do oszacowania ryzyka nie wystarczy zwykle jedna osoba: konieczna jest wspó%praca
wielu uczestników projektu, któr! umo#liwiaj! w%a$ciwie wykorzystane raporty b%'dów.

Zorganizowanie procedur zg%aszania i $ledzenia b%'dów jest jednym z podstawowych
zadaF kierownika testów.

Krajobraz przed bitwD:
planowanie testów, analiza ryzyka

Jak powiedzia% genera%, a póXniej prezydent Eisenhower, wprawdzie planowany prze-
bieg wydarzeF nigdy si' nie sprawdza, ale mimo to ten dowódca, który planowa% naj-
staranniej, ma najwi'ksze szanse poradzenia sobie z (niezaplanowan!) sytuacj! na polu
bitwy.

To samo dotyczy testowania. Wiadomo z góry, #e dostawa do testu systemowego b'-
dzie opóXniona — w porównaniu z planem — o dwa miesi!ce, natomiast data dostawy
do klienta nie ulegnie zmianie, przez co na test systemu, zamiast przewidzianych dzie-
si'ciu, pozostan! ledwo dwa tygodnie. Wiadomo, #e jako$& pierwszych dostaw b'dzie
taka, #e wi'kszo$& czasu trzeba b'dzie po$wi'ci& na podnoszenie zawieszaj!cego si'
systemu, a nie na wykonywanie przypadków testowych. Oczywiste jest te#, #e znaj-
dowane b%'dy spowoduj! niezaplanowany wzrost ilo$ci dostarczanych do testowania
wersji programu, przez co czas po$wi'cony na ich instalacj' i konfigurowanie oraz na
testy regresji wzro$nie — w porównaniu z planem — dramatycznie. Wreszcie wia-
domo, #e proces odpluskwiania (ang. debugging) odci!gnie pewn! ilo$& testerów na
pewien czas od testowania, a ponadto $rodowisko testowe b'dzie — w niezaplanowa-
nych wymiarach — zablokowane przez programistów usi%uj!cych odtworzy& awari'
i zlokalizowa& jej przyczyn'.

Planuj!c, #e wydarz! si' wszystkie te niezaplanowane historie, mamy realne podstawy,
by poradzi& sobie z wyzwaniem, jakim jest zarz!dzanie testami!

1

Nak%ad obecnie wyczerpany — wrzesieF 2008.

122

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Husaria kontra pruska piechota:
jak nie straci> impetu, nie tracDc g%owy?

Impet jest w testowaniu wa#ny, ale musi to by& impet kontrolowany, w przeciwnym
razie mo#e nas sprowadzi& na manowce. \ledzimy liczb' wykonanych przypadków
testowych i porównujemy z zaplanowanymi — w ten sposób ewentualne opóXnienie
wyjdzie na jaw od samego pocz!tku, a nie dopiero wtedy, kiedy naro$nie do katastro-
falnych rozmiarów. \ledzimy liczb' otwartych, zg%oszonych b%'dów — w ten sposób
mo#emy próbowa& oszacowa& ilo$& pozosta%ych jeszcze b%'dów, które zapewne wy-
sz%yby na jaw w trakcie dalszego testowania systemu, dzi'ki czemu w ka#dej chwili
mamy do dyspozycji dane pozwalaj!ce odpowiedzie& na nieuniknione pytanie: co
kierownik testów s!dzi o tym, #eby dostawa do klienta mia%a miejsce ju# pojutrze?

czas testowania

(znormalizowany)

skumulowana liczba

wykonanych zada"

testowych

zaplanowana

faktyczna

trudno#ci, spi$trzenie

b%$dów

naprawianie b%$dów

i testy regresji

nadrabianie start

szcz$#liwy koniec

Rysunek 4.1.1.

4ledzenie procesu przebiegu testów

Dostrzeg%szy niebezpieczne, narastaj!ce rozbie#no$ci mi'dzy planem a rzeczywisto-
$ci!, kierownik testów ma do dyspozycji pi'& typów $rodków zaradczych:

Zmiana harmonogramu testów — odroczenie zakoFczenia i terminu dostawy
do klienta.

Zmiana kryteriów jako$ci — obni#enie poprzeczki, dopuszczenie do u#ytku systemu
mniej przetestowanego albo maj!cego wi'ksz! ilo$& nierozwi!zanych b%'dów.

Wykorzystanie do testowania wi'kszej ilo$ci osób, testowanie równoleg%e.

Zamiana funkcjonalno$ci — dostarczony system nie b'dzie zawiera%
wszystkich wcze$niej planowanych funkcji.

Podniesienie wymaganej jako$ci dostaw do testu systemowego — to umo#liwi
sprawniejsze testowanie i przerzuci cz'$& dzia%aF na ni#sze poziomy
(testy komponentów, integracyjne).

Ponadto cz'sto stosowanym $rodkiem jest — kiedy gwa%townie narasta ilo$&
zarejestrowanych zg%oszeF b%'dów — czasowe zawieszenie wykonywania
nowych testów po to, by da& programistom szans' na usuni'cie spi'trzenia

Rozdzia% 4. ZarzDdzanie procesami

123

i naprawienie jak najwi'kszej liczby b%'dów. W tym czasie zespó% testowy
po$wi'ca si' wy%!cznie testowaniu powtarzalnemu dostaw zawieraj!cych
kolejne poprawki.

Krajobraz po bitwie:
czy mo*na wypu6ci> produkt ju* jutro?

Decyzja o tym, czy mo#na ju# zakoFczy& testowanie i wypu$ci&, dostarczy& albo roz-
pocz!& wdra#anie programu, jest de facto decyzj! biznesow!, nie techniczn!. Stoso-
wana w niektórych przedsi'biorstwach zasada, #e kierownik testów podpisuje zakoFcze-
nie testów i niejako tym samym w%asn! g%ow! gwarantuje dostateczn! jako$& produktu,
jest absurdem. Testowanie nie jest na dobr! spraw' zakoFczone nigdy, zawsze pozo-
staje — z podpisem kierownika czy bez niego — pewne ryzyko, #e w programie po-
zosta%y niezauwa#one b%'dy.

Nie znaczy to jednak, #e testowa& trzeba w nieskoFczono$&, bo z drugiej strony czai
si' przecie# ryzyko opóXnienia, kar umownych, niezadowolonych klientów, utraty
udzia%ów w rynku na rzecz szybszych czy odwa#niejszych konkurentów. Analiza ry-
zyka i podj'cie decyzji jest w 100% zadaniem dla kierownictwa lub sponsorów pro-
jektu, ewentualnie dla dzia%u marketingu. Test ma natomiast za zadanie dostarczy&
decydentom jak najprecyzyjniejsze dane dotycz!ce ryzyka technicznego w oparciu
o dotychczasowe wyniki testowania.

Istnieje wiele kryteriów oszacowania jako$ci produktu w oparciu o rezultaty testów.
Bierze si' na przyk%ad pod uwag', jaki procent zadaF testowych zosta% dotychczas
wykonany, ile pozosta%o otwartych (nierozwi!zanych) zg%oszeF b%'dów itd. Interesuj!c!
metod! jest technika oszacowania ilo$ci pozosta%ych jeszcze w programie nieznanych
b%'dów na podstawie funkcji najlepiej pasuj!cej do krzywej okre$laj!cej skumulowan!
ilo$& dotychczas znalezionych b%'dów. Wyja$nienie — na ilustracji poni#ej.

czas testowania

(znormalizowany)

skumulowana liczba

wykonanych zada"

testowych

zaplanowana

faktyczna

trudno#ci, spi$trzenie

b%$dów

naprawianie b%$dów

i testy regresji

nadrabianie start

szcz$#liwy koniec

Rysunek 4.1.2.

Szacowanie liczby pozosta-ych defektów

Oczywi$cie istotno$& takich oszacowaF zale#y od liczby oraz jako$ci wykonanych te-
stów. Do ich oceny s%u#! rozmaite miary pokrycia (np. wymagaF, funkcji, kodu).

124

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Obdzieranie poleg%ych,
czyli jak by> mDdrym po szkodzie

Projekt zakoFczony, produkt sprzedany, kod i dokumentacja z%o#one w archiwum i prze-
kazane do dzia%u zajmuj!cego si' serwisem — czy to ju# koniec pracy? Otó# nie, bo
z danych uzyskanych w trakcie testowania mo#na jeszcze niejedn! ciekaw! informa-
cj' wycisn!&. Wprawdzie na popraw' jako$ci wytworzonego przez zakoFczony pro-
jekt produktu informatycznego ju# za póXno, nie da si' tak#e podwy#szy& jako$ci de-
cyzji, które ju# zapad%y, ale mo#na uzyska& wiedz' pozwalaj!c! by& mo#e kolejne
projekty poprowadzi& lepiej i sprawniej.

Bogatym Xród%em wiadomo$ci jest baza danych z raportami b%'dów. Mo#na na przy-
k%ad szczegó%owo zanalizowa& pewn! liczb' losowo wybranych raportów i spróbowa&
odpowiedzie& na pytanie, jaka by%a pierwsza przyczyna zaistnienia danego b%'du? Czy
by%y ni! niejasno sformu%owane wymagania, czy niedostateczna znajomo$& j'zyka przez
programistów, czy niedoci!gni'cia organizacyjne?

Warto te# przyjrze& si' statystykom raportów b%'dów. Kiedy pojawi%o si' ich najwi'cej?
Jaki by% czas naprawy b%'du? Ile raportów okaza%o si' fa%szywych? Odpowiedzi na te
pytania niejednokrotnie pozwol! zidentyfikowa& s%abe punkty w procesach i procedu-
rach projektów lub niedostatki organizacyjne w przedsi'biorstwie.

Ró*ne formy organizacji testowania

Nie zawsze jedyn! i najlepsz! form! organizacji testów jest stworzenie osobnego zespo-u
testowego. Zale#nie od charakteru projektu, typu produktu, przyj'tej metodyki wytwa-
rzania korzystne mo#e okaza& si' zastosowanie innych rozwi!zaF organizacyjnych.

Programi$ci sami testuj! w%asny kod. Metoda cz'sto stosowana w testach
modu%owych (jednostkowych, komponentów). Jej wady s! oczywiste.

Testowanie kole#eFskie (ang. buddy testing): programi$ci nawzajem testuj!
swój kod. Stosowane mi'dzy innymi w popularnym ostatnio „Programowaniu
Ekstremalnym” (XP, Extreme Programming).

Tester (lub testerzy) s! cz%onkami zespo%u programistów, podlegaj! kierownikowi
zespo%u lub projektu.

Osobny zespó% testuj!cy maj!cy w%asnego kierownika.

Osobny dzia% w przedsi'biorstwie zajmuj!cy si' pewnymi rodzajami testów.

Outsourcing testów do innego przedsi'biorstwa: stosowane wówczas, gdy
wymagana jest niezale#na certyfikacja systemu oraz gdy niezb'dne jest
skomplikowane i kosztowne $rodowisko testowe (np. w testowaniu konfiguracji,
testowaniu zgodno$ci z wymaganiami $rodowiskowymi itp.).

Wybór w%a$ciwej organizacji testowania jest wa#nym zadaniem dla kierownika
projektu. Warto pami'ta&, #e w wi'kszych projektach kilka ró#nych form
organizacyjnych mo#e istnie& jednocze$nie, na przyk%ad testowanie kole#eFskie
na poziomie testów komponentów, odr'bny zespó% do testu systemowego,
outsourcing w celu uzyskania niezale#nej certyfikacji.

Rozdzia% 4. ZarzDdzanie procesami

125

Kiedy zaczyna>, kiedy skoNczy>?

Jak zwykle bywa — dobrze wiemy. Jak powinno by& — zwi'Xle opisuje rysunek 4.1.3.
Czynno$ci wykonywane przez zespó% testowy napisane s! t%ustym drukiem na jasno-
szarym tle.

Specyfikacja
wymaga"

Specyfikacja
konstrukcji

Kodowanie

Testy komponentów

Testy integracyjne

Test systemu

Test akceptacyjny

Walidacja
wymaga"

Testowalno#$

wymaga"

Przegl%d

Przegl%d

Przygotowanie

testów

Przygotowanie

testów

Testowanie

Rysunek 4.1.3.

Przegl8d modelu „V”

4.2. Znowu ten po"piech — jak szybko

oceni9 jako"9 aplikacji?

Po6piech w informatyce

Zrobi& cokolwiek szybko? Znowu ten po$piech. Znane jest przecie# porzekad%o: „co
nagle, to po diable” i niezliczone przyk%ady sytuacji, kiedy zabrak%o czasu i $rodków,
aby co$ wykona& dobrze, ale znalaz%o si' potem i jedno, i drugie, aby to co$ wielo-
krotnie poprawia&. Informatyka to bran#a cierpi!ca od swego powstania na syndrom
czarodziejskiej plasteliny. Kilkadziesi!t lat temu uda%o si' ludziom spe%ni& swe odwieczne
marzenie i znaleX& substancj', z której daje si' szybko i %atwo zbudowa& wiele najroz-
maitszych rzeczy: a to system bazodanowy, a to telefoni' komórkow!, a to wbudowany
uk%ad steruj!cy do pralki automatycznej. Figurki lepione z naszej czarodziejskiej pla-
steliny — instrukcji mikroprocesora — rzeczywi$cie mo#na tworzy& zadziwiaj!co szybko
w porównaniu z przedmiotami z drewna, metalu czy betonu, a ponadto mo#na je po-
tem wzgl'dnie %atwo poprawia& bez potrzeby burzenia ca%o$ci, je$li co$ si' nie ca%-
kiem uda. Ludzikowi z plasteliny mo#na nawet, kiedy ju# jest gotowy, oderwa& nog'
i zast!pi& j! inn!, lepsz!, ale te# wygl!da on potem jak… ludzik z plasteliny.

126

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Programowanie nara#one jest na nieustann! pokus$ bylejako'ci i po'piechu, których
skutkiem jest bardzo cz'sto albo fatalna jako$& aplikacji, albo lekcewa#enie u#ytkow-
nika i jego potrzeb, przez co $wiat zape%niaj! zawodne i pokraczne, niewygodne w ob-
s%udze twory z plasteliny. Po co zbiera& i analizowa& wymagania, skoro mo#na zacz!&
budowa& od razu, a potem, w razie czego, wszystko si' przerobi? Po co starannie pro-
jektowa& system, skoro mo#na od razu zacz!& kodowanie, a potem jako$ si' te, niepa-
suj!ce do siebie, cz'$ci poskleja w ca%o$&? Po co dba& o jako$& projektu, skoro w ba-
%aganie te# daje si' pracowa&, i po co wysila& si' na produkty dobrej jako$ci, skoro
czarodziejska plastelina pozwala na pozór bezkarnie poprawia&, sztukowa&, zaizolowa&
kawa%kiem d'tki, przymocowa& drutem?

Mi%o jest sobie pozrz'dzi&, ale z drugiej strony nie mo#na zaprzeczy&, #e to dzi'ki
systemom informatycznym dzisiejszy 'wiat ogromnie przewy,sza ten sprzed lat
trzydziestu i czterdziestu pod wzgl'dem mo#liwo$ci, dobrobytu, bezpieczeFstwa i or-
ganizacji, cokolwiek na ten temat s!dz! rozmaici zwolennicy powrotu do jaskiF czy
wr'cz na drzewa.

Ponadto, szydz!c sobie z typowego projektu informatycznego: drwala, który nie ma
czasu porz!dnie naostrzy& siekiery, bo tak bardzo si' spieszy z r!baniem drewna, nie
sposób przecie# zapomnie& o zagro#eniach z przeciwnej strony: drwalach tak zaj'tych
ostrzeniem siekiery, #e nie maj! czasu na $cinanie drzew. Czynniki psychologiczne po-
woduj!, #e ch'tnie — uchylaj-c si$ przed naprawd$ trudnymi wyzwaniami — ucie-
kamy w rytualizacj', mno#enie zb'dnej dokumentacji, mani' zebraF i posiedzeF, wiar'
w rzekomo uzdrowicielsk! moc procedur, procesów, poziomów dojrza%o$ci i sprawno$ci,
dusz!cych prawdziw! kreatywno$& i skuteczno$&.

Czy nie ma drogi po$redniej mi'dzy jedn! a drug! skrajno$ci!? Jest, oczywi$cie — to
po'piech kontrolowany, gdzie umiej'tno$& i wprawa pozwalaj! porusza& si' szybko,
lecz pewnie, a $cie#ki na skróty niekoniecznie prowadz! na manowce.

Pomiary w po6piechu

Warunkiem skutecznego po$piechu kontrolowanego jest umiej'tno$& nadzoru w biegu,
tak #eby zakr't móc przej$& na piszcz!cych oponach, ale z niego nie wylecie&, poko-
nuj!c za$ na skróty bezdro#a, orientowa& si' zr'cznie za pomoc! mapy, kompasu, ze-
garka i bystrych oczu — i nie zab%!dzi&.

Nie jeste$my w stanie kontrolowa& tego, czego nie umiemy zmierzy&. Ale pomiar nie
jest w informatyce s%owem lubianym — nawet poddany mi przez Redakcj' tytu% tego
artyku%u omija je, zast'puj!c niebudz!cym l'ku s%owem ocena. Cho& jako specjalista
w bran#y nie raz spiera%em si' przy piwie, czy to testowanie, czy te# utrzymanie opro-
gramowania jest bardziej nies%usznie lekcewa#one w praktyce naszego przemys%u, wy-
daje si', #e palma pierwszeFstwa nale#y si' jednak pomiarom. Dobry kierowca raj-
dowy nie musi wysiada& z samochodu i mierzy& promienia skr'tu ta$m! tylko dzi'ki
temu, #e wprawa pozwala mu mierzy& bez przerywania jazdy. Przewodnik, na pozór
bez wysi%ku wyprowadzaj!cy przez g'ste krzaki wprost na zamierzony punkt, nie wlecze
za sob! wielokilometrowej nici Ariadny tylko dlatego, #e nieustannie podczas marszu

Rozdzia% 4. ZarzDdzanie procesami

127

mierzy przebyt! odleg%o$&, kierunek, nachylenie terenu. W przemy$le informatycznym
ch'tnie udajemy kierowców Formu%y 1 oraz dzielnych przewodników, nie maj!c nie-
zb'dnych po temu umiej'tno$ci mierzenia.

Brak umiej'tno$ci sprawnego mierzenia uniemo#liwia zarz-dzanie ryzykiem, zast'-
puj!c je unikaniem ryzyka — lub bezsensown! brawur!. Unikanie ryzyka w in#ynierii
oprogramowania rodzi projekty sztywne, zbiurokratyzowane, nieskuteczne, omijaj!ce
w%a$ciwe wyzwania. Bezsensowna brawura oznacza fanfaronad' przy wyznaczaniu ce-
lów, $rodków i terminów, po czym… To, co zdarza si' potem, tak#e mo#na oczywi-
$cie zmierzy&. Odpowiedni! miar!, nie do koFca jeszcze uznan! przez fizyków, jest
„och-nie-sekunda” (ang. oh-no-second), stosowana do okre$lenia czasu up%ywaj!cego
od chwili, gdy si' zorientowali$my, #e pope%nili$my NAPRAWD` DU<Y BqvD
(np. klikaj!c „wy$lij do wszystkich” na koniec maila pe%nego wspomnieF z bardzo
gor!cej nocy).

O zarz!dzaniu ryzykiem i o skutecznych pomiarach napisz' wkrótce, jak mi czas i Re-
dakcja pozwol!. Na razie pora przej$& do sedna: jak szybko oceni& jako$& produktu,
czyli jak mierzy. w biegu?

Precz z grzybami

WyobraXmy sobie, #e pe%nimy funkcj' Naczelnika Jakiej$ Jednostki Administracyjnej.
Najnowsza polityka rz!du k%adzie szczególny nacisk na oczyszczanie lasów z grzybów.
Dlaczego — niewa#ne, ale nietrudno sobie wyobrazi&… Grzyby przecie# bywaj!
truj!ce, a ludno$& musi by& chroniona przed zagro#eniami. Nast'pnie jeste$my nowo-
czesnym europejskim krajem, a grzyby nie maj! witamin, nie poddaj! si' racjonalnej
hodowli i wzbudzaj! — jako pozbawione chlorofilu — zastrze#enia wojuj!cych $ro-
dowisk wegetariaFskich. Poza tym grzyby to paso#yty, co k%óci si' z ideami solidary-
zmu spo%ecznego (lub jest ich z%o$liw! karykatur!), a ich preferencje seksualne te# s!
— zdaje si' — nad wyraz nieprawomy$lne. Niech'& do grzybów ma wyraXnie ponad-
partyjny charakter, wi'c lasy maj! by& odgrzybione, a za dwa dni przyjedzie — o czym
da% nam cynk kolega z S!siedniej Jednostki Administracyjnej — Nadzwyczajna Komisja,
#eby sprawdzi& stan odgrzybienia naszego lasu podmiejskiego. Tak wi'c mamy SZYBKO
OCENIx JAKO\x LASU!

Nie musz' dodawa&, #e dot!d w tej sprawie nie zrobiono nic. Gdyby las by1 ju, wcze-
'niej systematycznie odgrzybiany, nie by1oby paniki. Oczywi$cie identycznie jest
z potrzeb! szybkiej oceny jako$ci aplikacji. Gdyby projekt by% od pocz!tku prowa-
dzony porz!dnie, jako$& aplikacji by%aby po prostu znana — realizowana i mierzona
ca%y czas. Có#, jednak $wiat jest niedoskona%y, wi'c idziemy mierzy& w po$piechu.

Grzybobranie

Zasada podstawowa — nie da si' trafnie oceni& stanu zagrzybienia lasu, nie wysy%aj!c
tam ludzi odpowiednio zmotywowanych, umiej!cych szuka& grzybów! Mo#na, rzecz
prosta, wys%a& do lasu krótkowidza, który na grzybach si' nie zna, dla ca%kowitej pew-
no$ci mówi!c mu z%owieszczym g%osem: „Mam nadziej', #e przyniesie mi pan DOBRE

128

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

wiadomo$ci!”. Wtedy ocena jako$ci lasu b'dzie wprawdzie odpowiednio szybka, ale
ca%kowicie nietrafna, a nie o to chyba nam chodzi. \miej!c si' z takiej metody, nie
zapominajmy, #e dok%adnie tak odbywa si' cz'sto próba szybkiej oceny jako$ci apli-
kacji — je$li nie wykonuj! jej fachowi testerzy, odpowiednio nagradzani za przyno-
szenie wie$ci o b%'dach, wynik pomiaru jest bezwarto$ciowy.

Dobry grzybiarz szuka grzybów tam, gdzie spodziewa si' je znaleX&. Wykorzystuj!c
sobie tylko znane intuicje, wie gdzie zwykle rosn! koXlaki, gdzie rydze, a gdzie opieFki,
dzi'ki czemu przynosi ich pe%ne kosze. Tak samo do$wiadczony tester wykorzystuje
swe wcze$niejsze do$wiadczenia, aby szuka& b%'dy ocenianej aplikacji tam, gdzie spo-
dziewa si' je znaleX&. Jak rydze lubi! rosn!& pod $wierkami, tak b%'dy lubi! si' na
przyk%ad gromadzi& w pobli#u warto$ci kraFcowych, na granicach przedzia%ów, i do-
bry tester tam w%a$nie b'dzie ich szuka%. Dalej, b%'dy ch'tnie dojrzewaj! w miejscach
odludnych, których nikt od dawna nie testowa%, bo kod jest tak zawi%y, #e lepiej go
nie rusza&. Wiemy te#, #e obecno$& kilku b%'dów zwykle oznacza, #e jest ich tam
o wiele wi'cej — wynikaj! bowiem z tych samych b%'dów projektowania. Kolejn!
regu%' streszcza powiedzenie „gdzie kucharek sze$&…” — je$li kod by% wielokrotnie
zmieniany, je$li modyfikowa%o go wielu programistów — warto poszuka& b%'dów.
Zasad jest wiele, a profesjonalni testerzy powinni je zna&.

Wró&my do podmiejskiego lasu. Do$wiadczony grzybiarz szuka grzybów tam, gdzie
zwykle rosn!, ale niekoniecznie tam, gdzie b'dzie ich szuka& nasza Nadzwyczajna
Komisja. Je$li cz%onkowie Komisji s! %agodnymi, leniwymi grubasami, zadowol! si'
pobie#nym sprawdzeniem bezpo$redniej okolicy wygodnych $cie#ek i tam w%a$nie
— wbrew instynktowi grzybiarza — trzeba przeszuka& teren szczególnie starannie.
Je$li w sk%ad Komicji wchodz! ambitne, m%ode wilki, b'd! si' stara& wykaza&, szu-
kaj!c w nietypowych miejscach — niech#e wi'c grzybiarze strwo#onego Naczelnika
Jednostki na wszelki wypadek przepatrz! miejsca pod kamieniami, w$ród g'stych krza-
ków czy w inne, do których podejrzewamy, #e ch'tnie skieruj! si' m%ode wilki.

Przenosz!c si' na chwil' z powrotem w dziedzin' oceny jako$ci aplikacji, nale#y oce-
nia& przede wszystkim to, czym najcz'$ciej pos%uguj! si' u#ytkownicy koFcowi. Skoro
nie ma si' do dyspozycji dostatecznie d%ugiego czasu, aby oceni& wszystko, warto skon-
centrowa& si' na obszarach, gdzie — z racji intensywnego u#ytkowania — prawdopo-
dobieFstwo awarii, je$li s! tam b%'dy — jest najwy#sze. Dzi'ki temu jako$& aplikacji
— mierzona $rednim czasem mi'dzy awariami — b'dzie wy#sza, oczywi$cie przy
za%o#eniu, #e znalezione podczas oceniania b%'dy b'd! te# usuwane.

Grzyb grzybowi nierówny. Doniesiono Naczelnikowi Jednostki, #e Komisja jest szcze-
gólnie uczulona na muchomory sromotnikowe, pewnie ze wzgl'du na ich kszta%t. Dla-
tego naczelnik uczula swoich grzybiarzy, aby szukali — wbrew swoim naturalnym,
grzybiarskim instynktom — w%a$nie sromotników. Tak samo przy szybkiej ocenie ja-
ko$ci aplikacji koncentrujemy si' na tych b%'dach, których skutki z punktu widzenia
u#ytkowników s! szczególnie z%e, a mniej czasu po$wi'camy b%'dom, o których wia-
domo, #e — je$li nawet gdzie$ s! — nie b'd! dla u#ytkowników zbyt dotkliwe.

W $rodku lasu jest ostaniec — pionowa, kilkunastometrowa ska%a. Mo#e na jej szczycie
te# rosn! jakie$ grzyby, a który$ z cz%onków Komisji uprawia sporty ekstremalne i tam
si' wdrapie? Mo#e, ale z drugiej strony, spenetrowanie wierzcho%ka ska%y wymaga%oby

Rozdzia% 4. ZarzDdzanie procesami

129

drabin, stra#y po#arnej, kto wie, czy nie helikoptera, co poch%on'%oby znaczn! cz'$&
$rodków dost'pnych na szybk! ocen' jako$ci lasu, przez co gorzej zosta%yby spene-
trowane jego %atwiej dost'pne rejony. W tej sytuacji chyba rozs!dniej jednak b'dzie
zostawi& w spokoju ska%'. T%umaczy& si' potem, #e w lesie wprawdzie jest pe%no grzy-
bów, ale za to wolny od nich jest trudno dost'pny ostaniec — to nie b'dzie brzmia%o
dobrze.

St!d wyp%ywa kolejny wniosek dla oceniania jako$ci aplikacji — je$li mamy ograniczone
zasoby, a s%owo „szybko” oznacza, #e brakuje nam najcenniejszego z nich, czyli czasu
— trzeba uwzgl'dni&, na ile trudne i kosztowne s! pewne testy, tak #eby dost'pne $rodki
rozdysponowa& raczej równomiernie, a nie tylko w jednym, szczególnie zasoboch%onnym
obszarze.

Testowanie uwzgl-dniajDce ryzyko

Powy#sze rozwa#ania s! streszczeniem podej$cia znanego jako testowanie uwzgl'dnia-
j!ce ryzyko (ang. risk based testing). Je$li jako$& musimy oceni& szybko, testujemy (oce-
niamy, mierzymy) przede wszystkim to, co najwa#niejsze, uwzgl'dniaj!c cztery klu-
czowe parametry:

Prawdopodobie5stwo b1$du — szkoda czasu, aby szuka& b%'dów tam,
gdzie by& mo#e ich nie ma.

Konsekwencje awarii — przy ocenie jako$ci nale#y szuka& raczej awarii
katastrofalnych ni# niegroXnych, kosmetycznych.

Prawdopodobie5stwo zastosowania — trafniej ocenimy jako$&, bior!c pod
uwag' przede wszystkim to, czym u#ytkownicy pos%uguj! si' na co dzieF,
ni# to, z czego korzystaj! raz do roku lub wcale.

8atwo'. testowania — przy szybkiej ocenie warto te# wzi!& po uwag',
by — o ile nie chodzi o awarie katastrofalne — raczej unika& wik%ania si'
w próby oceny tego, czego pomiar jest zbyt kosztowny i czasoch%onny.

Jakie to %atwe...

Warum einfach? Kompliziert geht es auch! — powiadaj! nasi zachodni s!siedzi. Po-
pe%niam zdaje si' b%!d, przedstawiaj!c %atwo zrozumia%! przypowie$& o grzybach za-
miast epatowania licznymi skomplikowanymi nazwami i trzyliterowymi skrótami. Prze-
czytawszy wst'pn! wersj' artyku%u, kto$ powiedzia% „to ca%e testowanie jest w gruncie
rzeczy bardzo proste”. Owszem, je$li wiemy, gdzie rosn! grzyby (znamy si' dobrze
na informatyce, na testowaniu i na projektach informatycznych), je$li znamy dziedzin'
zastosowania (ocena cz'sto$ci zastosowania oraz konsekwencji awarii) oraz techno-
logi' testów (ocena %atwo$ci testowania). Przydaje si' te# niez%a znajomo$& technik
pomiaru oraz analizy ich wyników, troch' statystyki… POZA TYM ca%a reszta to
rzeczywi$cie odrobina zdrowego rozs!dku.

130

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Bilet do Davos

Ca%e kosze usuni'tych z lasu grzybów wywieziono daleko — czy mo#na spokojnie
oczekiwa& inspekcji? Czy mo#e mimo wszystko lepiej zarezerwowa& dla siebie i ro-
dziny miejsca w samolocie do Szwajcarii i skromny apartament w Davos, na wypadek
gdyby Nadzwyczajna Komisja jaki$ du#y grzyb jednak wykry%a?

Trudno powiedzie& — testowanie uwzgl'dniaj!ce ryzyko pozwala skutecznie znaj-
dowa& b%'dy, nawet w po$piechu do$& trafnie oceni& jako$& aplikacji, ale nigdy nie
wie si' dok%adnie, na ile jest ono dok%adne: czy czasem — mimo staraF — jaka$
funkcja nie zosta%a pomini'ta, jaka$ cz'$& systemu zapomniana? <eby t' pewno$&
uzyska&, nale#a%oby — wró&my do historii o lesie — wzi!& dok%adn! map' lasu, po-
dzieli& j! na kwadraty i ca%y las systematycznie przeczesa&. Wprawdzie wiele z miejsc zi-
dentyfikowanych tym sposobem by%oby zupe%nie bezsensownych, na przyk%ad pla#a,
gdzie jako #ywo grzyby nie rosn!, lub $rodek bagna, gdzie komisja nigdy nie dotrze,
ale jest to koszt systematyczno$ci, cena za ubezpieczenie od skutków przeoczenia lub
zapomnienia.

W odniesieniu do oceny jako$ci aplikacji odpowiednikiem mapy jest model dzia%ania
lub struktury aplikacji, a odpowiednikiem dzielenia mapy na kwadraty — projekto-
wanie testów z modelu za pomoc! algorytmu. To jest konieczne, aby móc oceni& tak
zwane pokrycie testowe, a wi'c oszacowa& niezawodno$& wykonanych ocen, ale na to
przy ocenie szybkiej nie mamy zwykle czasu. Jedno jest wi'c pewne — ocena szybka
jest zawsze mniej pewna ni# ocena spokojna, oczywi$cie pod warunkiem staranno$ci
jednakowej w obu przypadkach.

Jak spieszy> si- powoli

Spiesz!c si', nie trzeba rezygnowa& z my$lenia. Nie chodzi przecie# o to, by wyko-
nywa& mnóstwo szybkich, nerwowych ruchów, g%o$no krzycze& przez kilka na raz
telefonów i pracowa& — nieefektywnie — po dwadzie$cia godzin na dob', tylko o to,
by mimo po$piechu pozosta& skutecznym i skoncentrowanym na celu.

Pogodzi& po$piech ze spokojn! systematyczno$ci! usi%uj! metodyki „systematycznego
testowania w po$piechu” (tak celnie okre$li% je dr Lucjan Stapp z Politechniki Warszaw-
skiej w swym wyst!pieniu na jednym z zebraF Stowarzyszenia Jako$ci Systemów
Informatycznych).

Jedna z nich to testowanie eksploracyjne (ang. exploratory testing): zespó% technik
wspomagaj!cych testerów w sytuacji na pozór beznadziejnej, kiedy jednocze$nie trzeba
uczy& si' aplikacji, wykonywa& testy i projektowa& nowe zadania testowe. Za pomoc!
szeregu kreatywnych sposobów — przydatnych tak#e wówczas, gdy po$piech nie
jest a# tak wielki — projektuje si' nowe testy na podstawie obserwacji i analizy wy-
ników testów w%a$nie wykonywanych. Jednym s%owem, podej$cie eksploracyjne po-
prawia skuteczno$& testów wtedy, gdy nie ma czasu, by je starannie zaplanowa&, tylko
trzeba strza%em z biodra szybko oceni& jako$& aplikacji.

Rozdzia% 4. ZarzDdzanie procesami

131

Cz'$ciowo odmienne podej$cie prezentuje testowanie zwinne (ang. agile testing). Jego
podstawa to zasada testowania parami: testerzy pracuj! w dwuosobowych zespo%ach,
testy wykonuj! wspólnie. Takie podej$cie budzi uzasadnione w!tpliwo$ci, czy nie jest
po prostu dublowaniem kosztów, ale praktyczne do$wiadczenia sugeruj!, #e faktycz-
nie pozwala na wi'ksz! skuteczno$&.

Kilka lat temu g%o$no by%o o metodyce programowania ekstremalnego (ang. extreme

programming), gdzie programi$ci pracuj! w parach, zamieniaj!c si' pisaniem kodu
i przygotowywaniem (automatycznych) testów dla tworzonego w%a$nie kodu. Progra-
mowanie ekstremalne postuluje ponadto ograniczenie do minimum tradycyjnej, ci'#-
kiej dokumentacji, blisk! wspó%prac' programistów z przedstawicielami klienta, cz'ste
— nawet kilka razy na dzieF — budowanie ca%ego systemu. Z jednej strony progra-
mowanie ekstremalne obiecuje wprawdzie ni#sz! czasoch%onno$& projektów, czym pasuje
do naszego tematu; z drugiej strony — postuluje przygotowywanie testów oceniaj!-
cych jako$&, jeszcze zanim powstanie kod, co nie do koFca ju# zgadza si' z paradyg-
matem „szybkiej oceny jako$ci aplikacji”.

Wszystkim, którzy szukaj- cudownych dróg na skróty i sposobów, jak szybko wy-
kona. to, co najlepiej wykonywa. spokojnie, dobrze w tym miejscu przypomnie.
bajk$ o ,ó1wiu i o zaj-cu.

4.3. Po co mierzy9?

Miary w in?ynierii oprogramowania

Miary cz'sto kojarz! nam si' z czym$ pozytywnym; mówi si': umiarkowany, miar-
kowaA, znaA miar., na miar., miarowo.

Z drugiej strony, brak miary te# chwilami brzmi obiecuj!co, jak w s%owie bezmierny.

Miary s! niebezpieczne dla tych, którzy usi%uj! co$ ukry&, wol! m'tniactwo i niejed-
noznaczno$& od precyzji. Miary trzeba dobrze rozumie&, tak wi'c niektórym ludziom
wydaj! si' one niebezpieczne; wed%ug Flawiusza to Kain wynalaz% „miary i wagi,
zmieni% ow! niewinn! i szlachetn! prostot', w jakiej #yli ludzie, póki ich nie znali,
w #ycie pe%ne oszustwa

2

”.

Miary, które znamy na co dzieF, wydaj! si' oczywiste, ale nie ma nic oczywistego w tym,
aby od prostego „zimno”, „$rednio” i „ciep%o” przej$& do skal, gdzie warto$ci liczbowe
przypisywane temperaturze powietrza odnoszone s! do d%ugo$ci s%upka rt'ci zamkni'tej
w szklanej rurce. Fakt, #e istniej! trzy ró#ne, powszechnie stosowane skale tempera-
tury: Fahrenheita, Celsjusza i Kelvina, z których ka#da ma punkt zerowy przy innej
temperaturze, a dwie pierwsze ró#ni! si' rozmiarem jednostki skali, wskazuje, #e miary
nie s! niczym oczywistym, #e s! przyjmowanym cz'$ciowo arbitralnie sposobem od-
wzorowania nat'#enia pewnych atrybutów rzeczywisto$ci — oj, to brzmi bardzo na-
ukowo, ale ma konkretny, praktyczny sens.

2

Józef Flawiusz, StaroBytnoCci Bydowskie, I.2.2, wyd. polskie: Warszawa 1962, s. 105 — cytat wg prezentacji

Andrzeja KobyliFskiego na Konferencji SJSI, Serock, maj 2005.

132

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

In#ynieria — zestaw zdefiniowanych, powtarzalnych technik projektowania, wytwa-
rzania i utrzymania rozmaitych rzeczy — nie mo#e istnie& bez pomiarów. Trudno
wyobrazi& sobie in#yniera, który nie umie mierzy& d%ugo$ci, ci'#aru, napi'cia czy
nat'#enia, albo lekarza bez termometru i narz'dzi do precyzyjnego pomiaru chemicz-
nego sk%adu krwi. Jedynie in#ynieria oprogramowania choruje na brak umiej'tno$ci
pomiaru nie tylko w%asnych procesów, ale nawet produktów!

Czego nie mo*na zmierzy>, tego si- nie wie

Zapyta kto$ — jakie to ma znaczenie? Czy to kolejna z wielu mód, kolejne go%os%owne
twierdzenie, jakoby co$ bardzo z%ego dzia%o si' z przemys%em informatycznym, pod-
czas gdy go%ym okiem wida&, #e dzieje si' ca%kiem dobrze?

Dobrze — zale#y w odniesieniu do czego. W porównaniu z przemys%em elektronicznym
przyrost wydajno$ci w produkcji oprogramowania jest od wielu lat skromny. Produkty
programistyczne cz'sto okazuj! si' zawodne, a ich spektakularne niepowodzenia — jak
na przyk%ad os%awione dwuletnie opóXnienie oddania do u#ytku lotniska w Denver
w 1995 roku z powodu przekroczenia terminu dostawy oprogramowania systemu ba-
ga#owego — przechodz! do legendy. Wielkie jest zró#nicowanie produktywno$ci pro-
gramistów w ró#nych firmach i projektach — wed%ug niektórych danych ró#nice wy-
nosz! nawet 600:1 (sze$&set do jednego, to nie jest b%!d w druku).

Jednocze$nie — tu akurat bran#a informatyczna niczym specjalnym si' nie wyró#nia
— go%os%owne twierdzenia i slogany wyst'puj! masowo. „Nasze najnowsze techniki
gwarantuj! 100% wzrostu produktywno$ci”, „u#ycie narz'dzi pozwoli skróci& testo-
wanie o |” — przyk%ady mo#na mno#y&. Czego nam brakuje, by móc przeciwstawi&
wiedz' próbom manipulacji? Systematycznego stosowania pomiarów i dost'pu do ich
wyników.

Planowanie projektów informatycznych okazuje si' w praktyce niejednokrotnie zwy-
k%ym wró#eniem z fusów. Jak oszacowa& pracoch%onno$& projektu produkcji opro-
gramowania, którego wymagania s! opisem s%owno-muzycznym? Nie%atwo na takiej
podstawie oszacowa& wielko$& produktu, na przyk%ad w formie liczby wierszy kodu,
a nawet maj!c do dyspozycji takie oszacowanie, nie ma prostej i godnej zaufania metody,
aby prze%o#y& je na liczb' koniecznych osobodni.

Brak umiej'tno$ci mierzenia powoduje, #e jakiekolwiek dyskusje porównuj!ce zalety
i wady ró#nych metod, technik, j'zyków programowania i modelowania cierpi! na chro-
niczn! dowolno$&, na odwo%ywanie si' do anegdotycznych, statystycznie nieistotnych
przyk%adów. Nie umiej!c mierzy& przebiegu projektów, nie potrafimy na dobr! spra-
w' nimi zarz!dza&. Intuicja, objawienia, i-cing — wszystko to bardzo ciekawe metody
pod warunkiem, #e uzupe-niaj8 proces decyzyjny i przewidywania oparte na pomia-
rach, a nie usi%uj! je zast.powaA. Zarz!dzanie ryzykiem staje si' fikcj!, je$li ani nie
potrafimy zagro#eF zidentyfikowa&, ani oszacowa& kosztów zapobiegania, ani oceni&
ich prawdopodobieFstwa. W opublikowanym niedawno artykule napisa%em, #e „w prze-
my$le informatycznym ch'tnie udajemy kierowców Formu%y 1 oraz dzielnych prze-
wodników, nie maj!c niezb'dnych ku temu umiej'tno$ci mierzenia”.

Rozdzia% 4. ZarzDdzanie procesami

133

Jak nauczy& si' trudnej sztuki wykonywania pomiarów i analizy ich wyników? Jak nie
da& si' w przysz%o$ci zagada& elokwentnym zwolennikom Jedynie S%usznej Drogi, czy
b'dzie ni! czysty Brak Procedur, czy ISO 9000, czy CMM, czy cokolwiek innego, tylko
doj$& samodzielnie do w%asnych wniosków, wybiera& to, co rzeczywi$cie najlepsze dla
nas i naszych firm?

Doskona%ym, praktycznym przewodnikiem jest wydana pod koniec ubieg%ego roku
ksi!#ka

3

dr. Andrzeja KobyliFskiego z SGH pod niezbyt chwytliwym marketingowo

tytu%em Modele jakoCci produktów i procesów programowych. Nazwa%bym j! ch'tniej
Informatyk mierzy.

KsiD*ka

Pierwsza, podstawowa zaleta omawianej ksi!#ki dla praktyków informatyki to jej przy-
st'pno$&. Cho& jest to pozycja naukowa, akademicka, jednak zarówno jej j'zyk, jak
i zorientowany na praktyczne potrzeby tryb wyk%adu umo#liwiaj! skuteczn! lektur'
tak#e osobom maj!cym g%ównie praktyczne do$wiadczenia informatyczne.

Jako'. to poj'cie kluczowe dla praktyki informatycznej, a mimo to niebezpiecznie
niejednoznaczne. Cho& definicji jako$ci jest wiele, a ka#da zas%uguje na osobn! mo-
nografi', istnieje przecie# du#a, niezaspokojona potrzeba jednoznacznego okre$lenia
jako$ci tak, by móc j! mierzy&, ocenia&, porównywa&, zapisywa& w kontraktach i wy-
maganiach. W jaki sposób jako$& wpisuje si' w praktyk' projektu informatycznego — to
tematyka pierwszej cz'$ci ksi!#ki.

Cz'$& druga dotyczy jako'ci produktu. Omawia atrybuty jako$ci produktów, zale#-
no$ci mi'dzy nimi oraz sposoby ich pomiarów. To tematyka o du#ym znaczeniu dla
wszystkich udzia%owców projektu informatycznego. Niedostatki wiedzy na ten temat
powoduj!, #e klienci niejasno i niepoprawnie okre$laj! swoje wymagania, analitycy
systemowi sporz!dzaj! niepe%ne modele, in#ynierowie jako$ci maj! problemy z jed-
noznaczn! ocen! jako$ci gotowego lub budowanego w%a$nie produktu.

Je$li w projektach zdarzaj! si' k%opoty, próbuje si' je rozwi!zywa&, usprawniaj!c pro-
cesy i procedury. Jest wiele ró#nych modeli, jak post'powa&, aby okre$li& i wdro#y&
usprawnienia, a ka#dy z nich ma swoich zwolenników i przeciwników. Czym si' od
siebie ró#ni!, który najlepiej pasuje do naszych potrzeb? Nie jest to pytanie teoretyczne.
Zmienia si' $rodowisko, w którym firmom przychodzi dzia%a& i konkurowa&, wi'c
firmy musz! tak#e si' zmienia&, by sprosta& nowym wyzwaniom. Ró#ne s! przyczyny
i cele zmian, a udoskonalenie sposobu pracy jest jednym z wa#niejszych. Próba udo-
skonalenia mo#e zakoFczy& si' trojako:

3

Andrzej KobyliFski Modele jakoCci produktów i procesów programowych, Szko%a G%ówna Handlowa

w Warszawie, Warszawa 2005, ISSN 0867-7727. Mo#na j! kupi& w Oficynie Wydawniczej SGH,
www.wydawnictwo.waw.pl.

134

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Rysunek 4.3.1.
Koszty zmiany w czasie

SKUTECZNO+,

I SPRAWNO+,

CZAS

Stan

pocz9tkowy

Analiza

zmiany

WdraBanie

zmiany

Sukces

Niepowo-

dzenie

KlGska

Aby zmniejszy& ryzyko niepowodzenia, trzeba sprawnie przeprowadzi& analiz' mo#-
liwej zmiany oraz skutecznie zrealizowa& jej wdro#enie. Jak posi!$& niezb'dn! do tego
celu wiedz'? Czytaj!c cz'$& trzeci! ksi!#ki, gdzie znajdziemy zarówno przegl!d ist-
niej!cych, znanych metod oceny i doskonalenia procesów, jak i porównanie wynika-
j!cych z nich korzy$ci oraz zagro#eF.

Tematyka budz!ca spore emocje, a przy tym znacz!ca dla powodzenia projektów oraz
firm, to kwestia relacji mi'dzy udoskonalaniem procesów a jako$ci! produktów. Ka#dy
pewnie s%ysza% sarkastyczne historyjki o wdro#eniach certyfikatów ISO 9000, wyma-
gaj!cych jakoby jedynie naklejenia karteczek z nazw! na wszystkie znajduj!ce si' w fir-
mie przedmioty, mno#!cych zb'dn! papierologi' i nieprzek%adaj!cych si' w #aden sposób
na jako$& produktów. Na przyk%ad s%ynny Tom DeMarco jest sceptycznie usposobiony
do korzy$ci p%yn!cych z osi!gania wy#szych poziomów CMM, twierdz!c, #e prowadzi
to wy%!cznie do polepszenia chwilowej sprawno$ci kosztem zmniejszenia elastyczno$ci
i utraty strategicznej efektywno$ci.

Cz'$& czwarta ksi!#ki po$wi'cona jest temu w%a$nie zagadnieniu uj'temu w unikalny,
w%asny sposób autora.

Podsumowuj!c — ksi!#ka Andrzeja KobyliFskiego to pozycja, któr! ka#dy mened#er
firmy czy kierownik projektu informatycznego b'dzie czyta& z du#ym zainteresowaniem,
a nale#y j! tak#e poleci& in#ynierom jako$ci oraz in#ynierom testów. Bo przecie#, #eby
mówi& o jako$ci, trzeba j! umie& mierzy&, test jest za$ podstawowym sposobem pomiaru!

4.4. Mi@dzy biurokracj& a chaosem: ADP

K%opot

Kiedy by%em dzieckiem, prze#y%em okres fascynacji robieniem na drutach. Opanowawszy
sztuk' zap'tlania kilku rodzajów oczek, stworzy%em co$ na kszta%t d%ugiego na metr,
nierównego szalika sk%adaj!cego si' z bez%adnej mieszanki wzorów i oczek. Nie da%o
si' tego do niczego u#ywa& i zaraz potem porzuci%em krótkotrwa%e zami%owanie.

Rozdzia% 4. ZarzDdzanie procesami

135

Podobnie, cho& nie a# tak Xle, wygl!da%o tworzenie oprogramowania w pierwszych
dwóch dekadach istnienia komputerów. Przedsi'wzi'cia informatyczne (ang. projects)
by%y chaotyczne i nieplanowe, nie stosowano systematycznej in#ynierii wymagaF (ang.
requirements engineering), kod tworzono bez uprzedniego projektowania (ang. design),
wi'c produkt koFcowy zwykle nie mia% trafnej funkcjonalno$ci, nie by% wygodny
w u#ytkowaniu ani %atwy w utrzymaniu.

W roku 1968 podczas konferencji in#ynierii oprogramowania NATO (NATO Software
Engineering Conference) termin in#ynieria oprogramowania po raz pierwszy pojawi%
si' oficjalnie [1]. Doczeka%o si' uznania twierdzenie, #e tworzenie oprogramowania
to co$ wi'cej ni# zgodne z regu%ami j'zyka programowania stawianie szeregu instrukcji;
#e istniej! systematyczne, zdyscyplinowane i mierzalne metody wykonywania tego
procesu.

Wkrótce — 7 paXdziernika 2008 r. [2] — przyjdzie nam zatem obchodzi& 40. rocznic'
tego wydarzenia

4

. Gdzie in#ynieria oprogramowania znajduje si' dzisiaj?

Akcja i kontrakcja

Na poziomie kodowania (implementacji) i cz'$ciowo tak#e projektowania zasz%y ogromne
zmiany. Od paradygmatu GOTO, przez metody strukturalne, przez nieudane próby j'-
zyków 4. generacji, przemys% informatyczny wszed% w er' metod i j'zyków obiektowych.

Od tworzenia ka#dej aplikacji niemal od zera, przez biblioteki funkcji, dotarli$my
do hierarchii klas, bibliotek %!czonych dynamicznie [3] i wieloj'zykowej platformy
CORBA [4]. Od niewydarzonego, topornego interfejsu wierszowego [5] przeszli$my
do znacznie wygodniejszych interfejsów graficznych [6]; zacz'to te# coraz systema-
tyczniej uprawia& in#ynieri' interakcji [7].

Mniej radykalne przemiany zachodzi%y na wy#szych poziomach procesu: projektowa-
nia architektury, in#ynierii wymagaF oraz testowania, ale i tutaj mo#na bez w!tpienia
wskaza& wiele nowych metod, modeli oraz narz'dzi.

Dzi$ — w porównaniu z sytuacj! sprzed 40 lat — mamy wi'c do dyspozycji o wiele
wi'cej znacznie pot'#niejszych sposobów pracy, dzi'ki którym daje si' tworzy& pro-
dukty coraz bardziej z%o#one coraz szybciej.

W tyle za rosn!c! skuteczno$ci! i sprawno$ci! metod technicznych pozostawa%a i po-
zostaje nauka o zarz!dzaniu przedsi'wzi'ciami. Nasza wiedza o tym, jak optymalnie
organizowa& przedsi'wzi'cia informatyczne, jak dobiera& oraz wi!za& ze sob! metody
i narz'dzia, uwzgl'dniaj!c rodzaj produktu, wymagania niezawodno$ci oraz szereg czyn-
ników ludzkich, wci!# pozostaje w powijakach. Pojawi%o si' i zyska%o krótkotrwa%!
s%aw' wiele nowo$ci: g%o$no by%o raz o TQM, kiedy indziej o clean-room software
engineering, o technikach przyrostowych, o daily build, o modelowaniu obiektowym,
o RUP — nazwy mo#na mno#y&. Narastaj!ca z%o#ono$& i oci'#a%o$& modeli procesów
wytwarzania oprogramowania spowodowa%a kontrakcj': od oko%o 15 lat coraz wi'ksz!
popularno$ci! ciesz! si' metodyki lekkie i zwinne (ang. agile [8]).

4

Esej napisany we wrze$niu 2007 roku.

136

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Procesy — zarówno ci'#kie, jak i zwinne — nie s! jednak dane raz na zawsze, po-
winny si' zmienia&. Jak mierzy& i ocenia&, a w miar' potrzeby zmienia&, udoskonala&,
usprawnia& nasze procesy? Powsta% szereg metametodyk (metodyk usprawniania metodyk),
które mo#na podzieli& na dwie wielkie stronnictwa: metametody ci'#kie i metametody
lekkie (terminologia w%asna autora artyku%u).

Metametody ci-*kie: rezerwat le6nych dziadków

Ci'#kich, rozbudowanych metod mierzenia i udoskonalania procesów jest wiele; wy-
mieniamy je poni#ej. Pozwalam sobie w odniesieniu do nich u#ywa& z%o$liwego okre-
$lenia rezerwat leCnych dziadków ze wzgl'du na ich sk%onno$& do odrywania nadbudowy
od bazy (samemu b'd!c niew!tpliwym le$nym dziadkiem, mam jak wida& sk%onno$&
do u#ywania terminologii z minionych epok, nie tylko w informatyce). Ci'#kie metody
postuluj! budow' i utrzymywanie ogromnego aparatu nadzoruj!cego, przez co wyma-
gaj! znacznych zasobów i nak%adów, a ich stosowanie w praktyce przedsi'wzi'& in-
formatycznych powoduje du#e spowolnienie procesu i niech'& jego uczestników. St!d
syndrom rezerwatu: ambitne, rozbudowane metodyki #yj! #yciem niezale#nym od
realiów projektów.

Przyk%ady takich metod/modeli to rodziny ISO 9000 – ISO 9001, Six Sigma, CMMI,
COBIT, ITIL, TickIT, ISO/IEC 12207, Bootstrap, SPICE, ISO/IEC 15504 oraz meto-
dyki udoskonalania procesu testowego TMM, MMAST, TAP, TCMM, TIM, TOM,
TSM, TPI.

To imponuj!ca i groXna lista skrótowców — ze szczegó%ami oraz praktyk! mo#na si'
zapozna& mi'dzy innymi na spotkaniach sieci SPIN (Software Process Improvement
Network, www.spin-pl.org) w GdaFsku, Krakowie, Szczecinie, Warszawie i we
Wroc%awiu

5

.

Metametody lekkie: rezerwat m%odych wilków

Metody lekkie mo#na podsumowa& — nara#aj!c si' na zarzut niejakiej przesady — jako
minimalizowanie wszelkich dzia%aF oprócz czysto konstrukcyjnych. Czyli w pewnym
stopniu nast'puje odwrócenie sytuacji: zamiast rezerwatu le$nych dziadków mamy
rezerwat m%odych wilków, które — z b%ogos%awieFstwem swoich proroków — biuro-
kracji metod ci'#kich przeciwstawiaj! zorientowane na skuteczno$& konkretnego pro-
jektu podej$cie na skróty. Przyk%ady takich metod to XP (eXtreme Programming), me-
todyki Agile (np. Agile SCRUM), metody ewolucyjne (iteracyjne), prototypowanie, daily
build, RAD (ang. Rapid Application Development). W dziedzinie testowania specyficzn!
form! lekkiej metodyki s! testy eksploracyjne (ang. exploratory testing).

5

Od tego czasu dzia%alno$& SPIN-ów zaktywizowa%a si' w GdaFsku i w Krakowie, a os%ab%a w innych

miastach (stan z sierpnia 2008 roku).

Rozdzia% 4. ZarzDdzanie procesami

137

Niedostatki rezerwatów

S%abo$ci metod i modeli ci'#kich s! oczywiste: w wielu przypadkach ich z%o#ono$&
i koszty post'powania wed%ug ich wskazaF po prostu przewy#szaj! korzy$ci, tak jak
koszt instalacji linii robotów przemys%owych w ma%omiasteczkowym warsztacie sa-
mochodowym.

Nawet jednak, je$li potencjalnie inwestycja w ci'#k! metodyk' ma szanse si' zwróci&,
to jej nieelastyczno$&, ignorowanie mechanizmów psychologicznych i spo%ecznych, za-
wi%o$& i oddalenie od konkretów, stanowi! powa#n! przeszkod' w ich zastosowaniu.

Z drugiej strony, metody lekkie s! na dobr! spraw' rezygnacj! walkowerem z korzy-
$ci gromadzenia i stosowania dobrych praktyk, z mi'dzyprojektowego transferu wiedzy
i umiej'tno$ci, z systematyzacji i dyscypliny, które nie zawsze s! tylko obci!#eniem.

WyraXnie potrzebna jest trzecia droga — droga mi'dzy biurokracj! a chaosem.

ADP — nareszcie!

Zapoznaj!c si' z metodyk!, opisan! przez Adama Kolaw' i Dorot' Huizinga w ich
maj!cej si' ukaza& we wrze$niu ksi!#ce Automated Defect Prevention: Best Practices
in Software Management [9], co chwila mia%em ch'& zawo%a& „nareszcie!”. Nareszcie
pewne oczywiste prawdy, które a# dziw, #e nie zosta%y wyartyku%owane wcze$niej,
doczeka%y si' opisania! Nareszcie mamy model procesu informatycznego, opisuj!cy
projektow! rzeczywisto$& w miejsce hermetycznego, pe%nego pobo#nych, acz niere-
alnych #yczeF $wiata modeli ci'#kich. Nareszcie otrzymujemy metodyk', która w spójn!
jedno$& %!czy trzy zwykle obce sobie dot!d $wiaty:

skuteczne projektowanie oraz implementacj' kodu;

pomiary, ocen' oraz udoskonalanie procesów i procedur;

psychologi' uczestników przedsi'wzi'cia informatycznego.

A# si' prosi, aby metodzie ADP nada& jak!$ bardziej porywaj!c! nazw', skoro przy-
chodzi jej konkurowa& ze swoistym fundamentalizmem tradycyjnych — zarówno
lekkich, jak i ci'#kich — metod. Czy istnieje korelacja mi'dzy jako$ci! projektu a ja-
ko$ci! produktu oraz czy jest to zale#no$& przyczynowa? Wydaje si', #e tej kluczowej
kwestii powinna by& po$wi'cona wi'kszo$& prac dotycz!cych procesów oraz ich udo-
skonalania, ale tak nie jest. Dominuje — zaiste przypominaj!ce niekiedy religijny fa-
natyzm — cyzelowanie metod oraz szczegó%owe opisywanie przypisywanych im cudów,
bez prób cho&by odpowiedzi na pytanie, na ile rzetelnie owe cuda zosta%y zarejestro-
wane i na ile metodzie w%a$nie mo#na przypisa& ich zaistnienie. Oto groXny cytat: Zna-
komite wyniki oraz sama liczba znanych przedsi.biorstw, które stosuj8 SixSigma, s8
dowodem na to, Be SixSigma nie jest przemijaj8c8 mod8! Od telekomunikacji, poprzez
sektor finansowy, aB po przedsi.biorstwa zajmuj8ce si. technologiami informatycz-
nymi, wiele renomowanych firm zademonstrowa-o moc SxSigma w swoich organiza-
cjach [13].

138

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

Trudno o bardziej ra#!cy przyk%ad my$lenia fundamentalistycznego, myl!cego rze-
czowe argumenty z pozorn! si%! okrzyków pasuj!cych raczej do manifestacji ni# do
naukowej czy in#ynierskiej debaty.

ADP od 6rodka

Patrz!c na spis zagadnieF poruszanych przez ADP, nie widzi si' na pierwszy rzut oka
jej rewolucyjnego charakteru. G%ówne rozdzia%y ksi!#ki to „Planowanie oraz infra-
struktura”, „Specyfikacja i zarz!dzanie wymaganiami”, „Projektowanie architektury
oraz projektowanie szczegó%owe” i tak dalej a# do „Testowania” i „Wdro#enia”. Po-
zornie nihil novi sub sole.

Si%a ADP tkwi jednak nie w efekciarskim stawianiu na g%owie faktu, #e informatyczne
przedsi'wzi'cia sk%adaj! si' w rzeczywisto$ci z takich a nie innych faz czy etapów, lecz
na sposobie ich modelowania, pomiaru oraz realizacji procesów udoskonalania rady-
kalnie realistycznym i zorientowanym przede wszystkim na praktyczn! skuteczno$&.

Spójrzmy, jak ADP okre$la swoje cele.

Zadowoleni ludzie

Dot!d sprawy psychologii, ludzkiego zadowolenia, motywacji i kreatywno$ci musia%y
wdziera& si' do in#ynierii oprogramowania albo chy%kiem, w aurze lekkiego skandalu,
albo traktowane by%y instrumentalnie jako dowody na wy#szo$& metod lekkich: XP jest
odCwieBaj8cym, nowym podejCciem. XP jest skuteczny, poniewaB k-adzie nacisk na
zaangaBowanie klienta i promuje prac. zespo-ow8. A zatem jak by to mia-o dzia-aA?
Najbardziej zadziwiaj8cym aspektem XP jest prostota regu- i procedur. Na pocz8tku
wydaj8 si. niezr.czne i naiwne, ale wkrótce staj8 si. mile widzian8 odmian8. Klienci
s8 zadowoleni z bycia partnerami w procesie programowania, a programiCci aktywnie
uczestnicz8 w tym procesie bez wzgl.du na doCwiadczenie [14].

Kto o$mieli%by si' postawi& pytanie, czy wdro#enie na przyk%ad ITIL zwi'ksza rado$&
#ycia zatrudnionych? Kto, z drugiej strony, sprzeciwi%by si' go%os%ownemu — co nie
oznacza, #e koniecznie nieprawdziwemu! — twierdzeniu, #e OOP jest w jaki$ mi-
styczny sposób lepsze i bardziej odpowiada ludzkim potrzebom ni# programowanie
strukturalne? — tylko nieliczni [15].

ADP zdo%a%o wpisa& czynnik ludzki w sam! metod', nie tylko jako ozdobnik. Nie
mamy tu miejsca, aby opisa& wiele, pos%u#' si' wi'c dwoma znamiennymi cytatami:
osi8gni.cie równowagi pomi.dzy dyscyplin8 i kreatywnoCci8 jest trudne oraz zarówno
nadmierna nuda, jak i nadmierny niepokój czyni8 ludzi mniej efektywnymi i bardziej
sk-onnymi do b-.du.

Tym niekorzystnym tendencjom ma zapobiega& w%a$ciwie, elastycznie stosowane ADP.

Rozdzia% 4. ZarzDdzanie procesami

139

Wysoka jako6> produktu

Ten podstawowy cel metodyk ginie cz'sto w nawale szczegó%ów samej metody. ADP
stawia go na drugim miejscu.

Organizacja: wy*sza produktywno6>
i sprawno6> w dzia%aniu

Nareszcie nie chodzi o to, by$my si' stali dojrzalsi (cho&by kosztem skuteczno$ci
i sprawno$ci), ani o to, by$my potrafili umie$ci& etykietki na ka#dej procedurze i ka#-
dym artefakcie naszej organizacji, tylko o produktywno$& i sprawno$&. Jak je osi!gn!&,
zale#y od produktu, charakterystyki projektu, ludzkich kwalifikacji i preferencji, a ADP
u%atwia ich okre$lenie oraz pomiar stopnia realizacji. W tym sensie ADP jest nie tyle
metodyk!, co metametodyk!, nie recept!, lecz „recept! jak-wybra&-w%asciw!-recept'”,
od lat bezskutecznie poszukiwan! przez praktyków.

Proces nadzorowany, udoskonalany
i dajDcy si- utrzyma>

CMMI poziom 5 czy lepiej poziom 2? Formalne modelowanie wymagaF czy niepre-
cyzyjny opis s%owny? Nie ma na te pytania jedynej s%usznej odpowiedzi, natomiast
niezale#nie od tego, jak brzmi w konkretnym przypadku, op%aca si' wiedzie&, co ro-
bimy (proces nadzorowany), umie&, je$li trzeba, poprawi& procedury (proces udosko-
nalany) oraz zachowa& zdolno$& do przestrzegania w rzeczywisto$ci tych praktyk, które
uznajemy za dla nas najlepsze (proces daj8cy si. utrzymaA) — oto sens ADP.

Przedsi-wzi-cie zarzDdzane
poprzez podejmowanie decyzji

Podejmowanie decyzji, zarz!dzanie zmianami i ryzykiem — to kolejny klucz do po-
wodzenia przedsi'wzi'& informatycznych. Aby móc jednak podejmowa& dobre decyzje,
niezb'dna jest informacja, niezale#nie od tego, czy proces decyzyjny jest sformalizo-
wany i racjonalny, czy intuicyjny i pod$wiadomy [16]. ADP k%adzie nacisk na gro-
madzenie i analiz' danych projektowych oraz na automatyzacj' tego procesu.

Zapobieganie pomy%kom i b%-dom

Oprogramowanie jest substancj! pozwalaj!c! — inaczej ni# kamieF, stal czy drewno
— wzgl'dnie %atwo usuwa& defekty w zbudowanych z niej produktach nawet wtedy,
gdy produkt jest w pe%ni ukoFczony. Ta cenna w%a$ciwo$& ma jednak ogromnie
niekorzystne skutki uboczne, promuje bowiem my$lenie krótkowzroczne, usuwa-
nie defektów zamiast ich przyczyn, co powoduje chroniczn! zawodno$& produktów

Czytaj dalej...

140

In*ynieria oprogramowania. Jak zapewni> jako6> tworzonym aplikacjom

informatycznych. ADP zaleca podej$cie przeciwne: analiz' przyczyn pomy%ek i b%'-
dów (ang. root cause analysis) oraz ich systematyczne usuwanie wsparte automatycz-
nymi narz'dziami.

Zasady ADP

Znajomo$& podstawowych zasad ADP pozwala zrozumie& skuteczno$& i prostot' tej
metodyki.

Stworzenie infrastruktury jednocz-cej ludzi i technologi$. Metody takie jak

na przyk%ad CMMI mówi! wiele o tym, co nale#y zrobi&, ale niewiele o tym,
jak: nie podaj! szczegó%owych wskazówek wspomagaj!cych prze%o#enie zacnych
za%o#eF w konkretn! praktyk' i projektowe korzy$ci. ADP przeciwnie — okre$la,
jak za pomoc! narz'dzi u%atwi& i usprawni& rzeczywiste wdro#enie zaleceF.

Okre'lenie i zastosowanie dobrych praktyk — to normatywna cz'$& ADP,

a wi'c podobna nieco do metodyk i modeli tradycyjnych. To, czym ADP
korzystnie si' wyró#nia, to uznanie istnienia dobrych praktyk na wielu ró#nych
poziomach, od ogólnych zasad SQA po szczegó%owe wskazówki dotycz!ce
implementacji kodu.

Dostosowanie dobrych praktyk — nie istnieje uniwersalny zbiór dobrych

praktyk; ka#da firma, dziedzina i projekt powinny ogólne dobre praktyki
modyfikowa& i uzupe%nia&, gromadz!c w%asne, szczególne do$wiadczenia.
A wi'c model czy metod' nie tyle si' wdra#a wed%ug z góry za%o#onego
skryptu, co projektuje, buduje i wdra#a jednocze$nie.

Pomiary i monitorowanie statusu projektu — automatyczny system

gromadzenia i analizy stanu projektu pozwala zarówno na sprawne okre$lenie
jego statusu, jak i na identyfikacj' jego s%abych stron i mo#liwych usprawnieF.
Stosowanie tej zasady pozwala — pos%uguj!c si' terminologi! CMMI
— wdro#y& elementy poziomu pi!tego CMMI nawet w organizacjach
niespe%niaj!cych wszystkich formalnych jego wymogów!

Automatyzacja — weXmy do r'ki struktur' dowolnego du#ego modelu,

na przyk%ad COBIT; przecie# niemo#liwe, nara#one na liczne pomy%ki
i pora#aj!co — nie bójmy si' tego s%owa! — nudne by%oby jego wdro#enie
bez zakrojonej na szerok! skal' automatyzacji przestrzegania jego wytycznych!
ADP k%adzie ogromny nacisk na automatyzacj' procedur, przez co ich
przestrzeganie staje si' mo#liwe bez nara#ania ludzi na konieczno$& uci!#liwego,
r'cznego wprowadzania danych wymaganych przez procedury, odci!#a ich
od frustruj!cych, rutynowych zadaF, ogranicza zagro#enie pomy%kami.

Przyrostowe wdro,enie praktyk ADP. To zupe%na nowo$& — dot!d nawet

metodyki zalecaj!ce przyrostowe tworzenie oprogramowania nie przewidywa%y
przyrostowego wdra#ania samych siebie! Istnieje szereg czynników
psychologicznych powoduj!cych opór przed zmianami. Liczne kursy
„mi'kkie” usi%uj! nas nauczy&, jak z tym oporem sobie radzi& rozmaitymi
psycho- i socjotechnikami, ale nikt jako$ dot!d nie zaproponowa% oczywistego
rozwi!zania (dobrze sk!din!d znanego politykom podwy#szaj!cym podatki)
— stopniowo i krok po kroku!