In¿ynieria oprogramowania.
Jak zapewniæ jakoœæ
tworzonym aplikacjom
Autorzy: Bogdan Bereza-Jarociñski, Boles³aw Szomañski
ISBN: 978-83-246-1948-1
Format: 158235, 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 treci
Rozdzia 1. Rozwaania wstpne ...................................................................... 13
1.1. Nietypowa ksika: o jakoci na wesoo ............................................................... 13
1.2. Jako integralna .................................................................................................. 13
1.3. Jako przedsiwzi ............................................................................................ 14
Przykad ........................................................................................................... 15
Zarzdzanie projektami ................................................................................... 15
Zarzdzanie procesami .................................................................................... 15
Zarzdzanie celami biznesowymi .................................................................... 15
Zarzdzanie jakoci ........................................................................................ 16
1.4. Podejmowanie decyzji i zarzdzanie ryzykiem .................................................... 17
Podejmowanie decyzji i zarzdzanie ryzykiem,
czyli wykorzystanie intuicji i racjonalnoci .................................................. 17
Brakuje jednak podejcia integralnego ............................................................ 17
Intuicji trzeba da szans! ................................................................................ 18
Mona si nauczy , jak wykorzystywa w praktyce najlepsze rodki
z dwojga wiatów .......................................................................................... 18
1.5. Zintegrowane zarzdzanie celami biznesowymi ................................................... 19
Budowanie siy i powodzenia firmy na rynku ................................................. 19
Elementy jakoci integralnej ............................................................................ 20
1.6. Zarzdzanie procesami ......................................................................................... 21
Sukces w systematycznym doskonaleniu organizacji ...................................... 21
Na pocztku by chaos ..................................................................................... 22
Opaca si praca dobrze zorganizowana .......................................................... 22
Drugi brat ........................................................................................................ 23
Zarzdzanie procesem biznesowym ................................................................ 23
Rozdzia 2. Dialektyka jakoci .......................................................................... 25
2.1. Dlaczego jako si opaca? ................................................................................. 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 staroytni Grecy… .................................................................................... 29
Miliardy, co z dymem poszy .......................................................................... 30
Nie trzeba katastrofy ........................................................................................ 30
Jak to sprzeda ? ............................................................................................... 31
Komu bije jako ? ........................................................................................... 32
6
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
2.3. Pocaunek ycia — transfuzja krwi dla informatyki ............................................. 32
Myli przewodnie ............................................................................................ 32
Testowanie wymaga celu ................................................................................. 33
Skutek zaley od celu ...................................................................................... 33
Fachowo moe zaciemnia gówne cele ....................................................... 33
Testujmy funkcje, a nie programy ................................................................... 34
Rozbiene cele mog spowodowa nieporozumienie ...................................... 34
Sprzeczne miary jakoci .................................................................................. 34
Weryfikowa czy aktualizowa ? Test jest postaw mentaln .......................... 35
Jako produktu — to tylko pocztek .............................................................. 35
Naturalna ewolucja — tester perfekcyjny ........................................................ 35
Testowanie w psychologii ............................................................................... 37
Teorie testowania w socjologii: naukowa weryfikacja .................................... 37
Kryteria normalnoci — co jest normalne? ..................................................... 38
Pomiary ludzi ................................................................................................... 39
Jako w przemyle farmaceutycznym ............................................................ 39
Testowanie w swataniu .................................................................................... 42
Audyt finansowy ............................................................................................. 44
Testowanie w przemyle budowlanym ............................................................ 44
Testowanie w przemyle samochodowym ....................................................... 46
Testowanie w krawiectwie .............................................................................. 48
Testowanie w sztuce ........................................................................................ 49
ycie to testowanie .......................................................................................... 50
Bibliografia ...................................................................................................... 53
2.4. Inynieria jakoci — nauka czy szarlataneria? ..................................................... 54
Reguy naukowego rozumowania .................................................................... 54
Ludzkie poznanie ............................................................................................. 55
Wano i weryfikacja wiedzy ........................................................................ 56
Wybór waciwej metody weryfikacji ............................................................. 60
Wykroczenia przeciw metodom naukowym .................................................... 61
Róne populacje w badaniach QA ................................................................... 65
Bdy obserwatora i skutki oczekiwania .......................................................... 66
Testowanie hipotez .......................................................................................... 66
Wiele uczestniczcych zmiennych .................................................................. 67
Konsekwencje i moliwoci ............................................................................ 68
Czy testowanie oprogramowania jest nauk? .................................................. 68
Zalecenia ......................................................................................................... 69
Proces kontra jako produktu ......................................................................... 71
Negatywne skutki systemów jakoci ............................................................... 72
Bibliografia ...................................................................................................... 73
Rozdzia 3. Jako wczoraj, dzisiaj i jutro ......................................................... 75
3.1. Historia podejcia do jakoci (od Hammurabiego do Gatesa) .............................. 75
Definicje jakoci .............................................................................................. 75
Jako we wspólnotach pierwotnych ............................................................... 76
Jako w staroytnoci ..................................................................................... 77
Jako w redniowieczu i w okresie odrodzenia .............................................. 81
Jako w XIX wieku ........................................................................................ 84
Jako w XX wieku ......................................................................................... 85
Zmiany w historii jakoci ................................................................................ 89
Jako w informatyce ...................................................................................... 91
Jak drog poszo oprogramowanie ................................................................. 92
Bibliografia ...................................................................................................... 93
Spis treci
7
3.2. Pdzi parowóz historii: 20 lat przemian w informatyce ........................................ 94
Od sierpa i mota do Internetu ......................................................................... 95
Powolne zwycistwo uytecznoci .................................................................. 96
Szybciej, wicej, dalej ..................................................................................... 97
Jako szyta na miar ...................................................................................... 98
Samoobsuga .................................................................................................... 99
3.3. W krysztaowej kuli: inynieria oprogramowania za 10 lat ................................ 100
Typowe bdy przewidywania ....................................................................... 100
Szybko i intuicyjnie ....................................................................................... 102
Programowanie intencjonalne ........................................................................ 102
Testowanie eksploracyjne .............................................................................. 103
Spirale, iteracje, przyrost ............................................................................... 103
3.4. Szybko, zwinnie, ekstremalnie ........................................................................... 104
Jzyki programowania ................................................................................... 104
Architektury komponentowe ......................................................................... 105
Sztuczna inteligencja i programy samouczce si ......................................... 105
Podsumowanie: sia czy inteligencja? ........................................................... 106
3.5. Drogowskaz do przyszoci — mdro bdzie na serwerach, czyli ASP .......... 106
Babcia nie potrzebuje komputera ................................................................... 108
Czego potrzebuje babcia autora? ................................................................... 109
Szczegóy rozwizania dla babci ................................................................... 109
Z czym nam si to kojarzy? ........................................................................... 112
Kontrowersje ................................................................................................. 113
Jeszcze troch recenzji — walka ze spamem ................................................. 113
Moc jzyków ................................................................................................. 114
Zakoczenie ................................................................................................... 115
3.6. Y2K — heca czy historia? Wspomnienia wiadka ............................................. 115
Rozdzia 4. Zarzdzanie procesami ................................................................. 119
4.1. Zarzdzanie jakoci — wadza i zgiek ............................................................. 119
Jak opanowa stado bezgowych kur, czyli zarzdzanie konfiguracj ........... 119
Rozmawiaa g z prosiciem: raporty i ledzenie bdów ............................ 120
Krajobraz przed bitw: planowanie testów, analiza ryzyka ........................... 121
Husaria kontra pruska piechota: jak nie straci impetu, nie tracc gowy? ....... 122
Krajobraz po bitwie: czy mona wypuci produkt ju jutro? ....................... 123
Obdzieranie polegych, czyli jak by mdrym po szkodzie ........................... 124
Róne formy organizacji testowania .............................................................. 124
Kiedy zaczyna , kiedy skoczy ? .................................................................. 125
4.2. Znowu ten popiech — jak szybko oceni jako aplikacji? .............................. 125
Popiech w informatyce ................................................................................. 125
Pomiary w popiechu ..................................................................................... 126
Precz z grzybami ........................................................................................... 127
Grzybobranie ................................................................................................. 127
Testowanie uwzgldniajce ryzyko ............................................................... 129
Jakie to atwe... .............................................................................................. 129
Bilet do Davos ............................................................................................... 130
Jak spieszy si powoli .................................................................................. 130
4.3. Po co mierzy ? Miary w inynierii oprogramowania ......................................... 131
Czego nie mona zmierzy , tego si nie wie ................................................. 132
Ksika .......................................................................................................... 133
4.4. Midzy biurokracj a chaosem: ADP .................................................................... 134
Kopot ............................................................................................................ 134
Akcja i kontrakcja .......................................................................................... 135
Metametody cikie: rezerwat lenych dziadków .......................................... 136
8
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Metametody lekkie: rezerwat modych wilków ............................................. 136
Niedostatki rezerwatów ................................................................................. 137
ADP — nareszcie! ......................................................................................... 137
ADP od rodka .............................................................................................. 138
Zadowoleni ludzie ......................................................................................... 138
Wysoka jako produktu ................................................................................ 139
Organizacja: wysza produktywno i sprawno w dziaaniu ...................... 139
Proces nadzorowany, udoskonalany i dajcy si utrzyma ............................ 139
Przedsiwzicie zarzdzane poprzez podejmowanie decyzji ......................... 139
Zapobieganie pomykom i bdom ................................................................ 139
Zasady ADP ................................................................................................... 140
Who is who .................................................................................................... 141
Referencje ...................................................................................................... 141
Rozdzia 5. Socjologia i antropologia jakoci .................................................. 143
5.1. Inynier jakoci — 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
Przykad z projektu ........................................................................................ 147
Co wynika z nieporozumie? ........................................................................ 148
Kreatywno .................................................................................................. 149
Negocjacje ..................................................................................................... 149
Asertywno .................................................................................................. 150
Wystpienia publiczne ................................................................................... 150
Motywacja i zarzdzanie zespoem ............................................................... 151
Trening antystresowy i zarzdzanie emocjami .............................................. 151
Zarzdzanie 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 jestemy gotowi podj decyzj?” ................... 155
Psychologia podejmowania decyzji ............................................................... 156
Nieprzechodnio preferencji ........................................................................ 156
Preferencja czasowa i opóniona gratyfikacja ............................................... 157
Percepcja prawdopodobiestwa ..................................................................... 158
Co to jest testowanie uwzgldniajce ryzyko? ............................................... 164
Statystyka: podejmowanie decyzji w warunkach niepewnoci ...................... 165
Strategie decyzyjne ........................................................................................ 167
Podejmowanie decyzji przy uyciu statystyki Bayesa ................................... 168
Bibliografia .................................................................................................... 171
5.5. Psychologia jakoci ............................................................................................ 172
Psychologia i socjologia testowania .............................................................. 172
Status tego rozdziau ...................................................................................... 172
Dysonans poznawczy .................................................................................... 172
Psychologia testowania .................................................................................. 172
Praca konstruktywna i motywacja ................................................................. 173
Bezpieczestwo, niepokój ............................................................................. 174
Przegldy ....................................................................................................... 174
Dynamika grupowa ........................................................................................ 175
Studium komunikacji ..................................................................................... 175
Hierarchia potrzeb wg Maslova ..................................................................... 176
Spis treci
9
Osobiste zainteresowania i cele (teoria Hollanda) ......................................... 176
Wnioski ......................................................................................................... 177
Opis modelu Hackmana ................................................................................. 177
5.6. Czy warto si SPIN-a ? ...................................................................................... 178
Organizacje zajmujce si jakoci 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, uyteczno, wygoda .................................................. 191
6.1. Inwazja szaleców .............................................................................................. 191
6.2. Jak ulepszy wiat? ............................................................................................. 193
Frustracja, ponienie, agresja ......................................................................... 193
Szalecy rzdz domem wariatów ................................................................. 194
Sze grzechów gównych ............................................................................. 194
Niewite przymierze .................................................................................... 195
Pomoc nadciga ............................................................................................. 196
6.3. Psychologiczne podstawy uytecznoci .............................................................. 196
Stan obecny ................................................................................................... 196
Lista kontrolna niektórych czynników uytecznoci ..................................... 197
Rozdzia 7. ycie towarzyskie i uczuciowe ...................................................... 201
7.1. Adwentowa gwiazda 2003 .................................................................................. 201
Adwentowa gwiazda ...................................................................................... 201
Albomy to jacy-tacy? ................................................................................... 202
ycie towarzyskie i uczuciowe ...................................................................... 202
Koniec wojny niemiecko-brytyjskiej ............................................................. 203
O co tyle szumu? ........................................................................................... 203
O chorobie wspóuzalenienia ....................................................................... 204
7.2. Kupujc wiedz: przewodnik po szkoleniach ..................................................... 205
Motto ............................................................................................................. 205
Podstawy ....................................................................................................... 205
Pi zotych zasad, jak znale szkolenie testowe ......................................... 206
7.3. Jak sprzedawa nietypowe szkolenia? Podrcznik cynicznego sprzedawcy ....... 209
Wizja — pocztki .......................................................................................... 209
Przynta ......................................................................................................... 210
Strategia ......................................................................................................... 211
Motywacja nauczania = dochód z nauczania – alternatywny zysk ................ 211
Planowanie .................................................................................................... 212
Nauczyciele ................................................................................................... 212
Czynic karier nauczyciela atrakcyjn ......................................................... 213
Struktura pakietu szkoleniowego ................................................................... 214
Praktyczne techniki szkoleniowe kontra teoria .............................................. 216
wiadectwa i egzaminy ................................................................................. 217
Pakiety — moduowy model kursu ................................................................ 217
Wykonanie — licz si praktyczne szczegóy ............................................... 218
Bóg czy mamona? Zasady czy siy rynkowe? ............................................... 220
Konkurencja .................................................................................................. 221
Do zapamitania ............................................................................................ 221
10
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
7.4. Papierki i wiadectwa. Certyfikacja w inynierii oprogramowania .................... 222
Sens certyfikacji w przemyle informatycznym ............................................ 222
Certyfikacja w dziedzinie zapewnienia jakoci i testowania ......................... 223
Rodzaje certyfikatów ..................................................................................... 223
Poytki z certyfikatów ................................................................................... 224
Zagroenia ..................................................................................................... 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 midzynarodowe .................................................................... 228
7.6. To po prostu bzdura! ........................................................................................... 229
Wyznania sfrustrowanego trenera jakoci ..................................................... 229
Wedug ISEB i ISTQB… .............................................................................. 230
Jak wybiera si przypadki testowe w rzeczywistoci? ................................... 231
Peny obraz .................................................................................................... 233
W kocu: przykad ......................................................................................... 235
Rozdzia 8. Metody i techniki ......................................................................... 237
8.1. Sztuka, rzemioso, nauka .................................................................................... 237
Powiedzmy, e zbliaj si wybory ............................................................... 237
Grupa reprezentatywna .................................................................................. 237
Na tym samym polega testowanie ................................................................. 238
Sztuka ............................................................................................................ 238
Rzemioso ...................................................................................................... 239
Nauka ............................................................................................................ 240
8.2. Szlachetna sztuka testowania oprogramowania .................................................. 241
Nowa ksika ................................................................................................. 241
Klasyka odwieona ...................................................................................... 242
Nazewnictwo ................................................................................................. 243
8.3. eby banki rosy w si, a klienci yli dostatniej ................................................ 244
Praca mudna, mozolna, ale za to jaka jaowa! ............................................. 244
Kontrola instalacji wodnej pod cinieniem .................................................... 245
Pocigi pod specjalnym nadzorem ................................................................. 246
Szukanie dziury w caym ............................................................................... 246
Czego uytkownik nie lubi najbardziej? ........................................................ 247
Jako jest za darmo ...................................................................................... 247
8.4. Kracowo zwinne eksploracyjne piramidy ......................................................... 247
Historia polityczna ......................................................................................... 247
Ostrzeenie .................................................................................................... 248
Nowa religia .................................................................................................. 249
Zastosowanie eksploracji ............................................................................... 251
8.5. Cyryl jak Cyryl, ale metody! .............................................................................. 251
Nie warto marnowa czasu ............................................................................ 251
Ryzyko jest zbyt due .................................................................................... 252
Testowanie — osobna specjalno ? ............................................................... 252
Czy test moe si opaca ? ............................................................................ 253
Rachunek zysków i strat ................................................................................ 253
Kosmiczne pienidze ..................................................................................... 253
Co przetestowa , a co zlekceway ? ............................................................. 253
Sztuka testowania .......................................................................................... 254
Tester jako rzemielnik .................................................................................. 254
Spis treci
11
Metody formalne ........................................................................................... 255
Chop pi, a zboe samo ronie ...................................................................... 255
Kiedy testowa ? ............................................................................................. 255
Kto bdzie testerem? ..................................................................................... 256
Polowanie na pluskwy ................................................................................... 256
Schwytana pluskwa na uwizi ....................................................................... 257
Zaplecze frontu, czyli logistyka testowania ................................................... 257
Test na co dzie ............................................................................................. 258
Rozdzia 9. Warsztat fachowca ....................................................................... 259
9.1. Automatyzacja testów ......................................................................................... 259
Co to jest automatyzacja testowania? ............................................................ 260
Co znajduje si w skrzynce ze zotem: poytki z automatyzacji .................... 260
Gdzie rozmieszczone s miny: niebezpieczestwa automatyzacji ................. 261
Na zakoczenie .............................................................................................. 264
9.2. Czy jako jest za darmo? Opacalno 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 zotego rodka ......................................................................... 266
Kombajnem przez preri ................................................................................ 267
Potrzeba, jak zwykle, fachowców .................................................................. 268
Sierpy, snopowizaki i kombajny ................................................................. 270
Gdzie szuka dalej? ....................................................................................... 272
Rozdzia 10. Bezpiecze stwo informacji ............................................................ 273
10.1. Bezpieczestwo informacji: historia i stan obecny ............................................. 273
Wprowadzenie — bezpieczestwo informacji dawniej ................................. 273
Ochrona fizyczna i konstruowanie niezawodnego sprztu ............................ 276
Zapewnienie jakoci oprogramowania ........................................................... 277
Zapewnienie bezpieczestwa oprogramowania ............................................. 278
Zapewnienie bezpieczestwa systemów informatycznych ............................ 281
Zarzdzanie bezpieczestwem informacji ..................................................... 283
Systemy zarzdzania bezpieczestwem
informacji wedug norm ISO serii 27000 .................................................... 284
Próba przewidywania przyszoci .................................................................. 290
Bibliografia .................................................................................................... 292
10.2. Walka z cieniem — zabezpieczenia i odporno w praktyce .................................. 295
Streszczenie ................................................................................................... 295
Co to jest „bezpieczestwo”? ........................................................................ 295
Definicje bezpieczestwa .............................................................................. 296
Gdzie szuka bdów zabezpieczenia? .......................................................... 297
Testowanie zabezpiecze ............................................................................... 298
Ile testowa zabezpieczenia? ......................................................................... 298
Wraliwe czci ciaa smoka ......................................................................... 299
Uyteczno ................................................................................................... 300
Wykonanie ..................................................................................................... 301
Aspekty organizacyjne ................................................................................... 301
Proces testowania bezpieczestwa ................................................................. 302
Monitoring w trakcie dziaania operacyjnego ................................................ 303
Bibliografia .................................................................................................... 304
Organizacje, firmy, usugi i normy ................................................................ 305
Narzdzia ....................................................................................................... 305
12
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
10.3. Bezpieczestwo — praca u podstaw ................................................................... 306
Duo haasu o bezpieczestwo ...................................................................... 306
Bezpieczestwo wielopoziomowe ................................................................. 306
Trzy wiaty bezpieczestwa .......................................................................... 307
Normy, audyt, standardy ................................................................................ 307
Policjanci ....................................................................................................... 307
Testy penetracyjne ......................................................................................... 308
Praca u podstaw ............................................................................................. 308
Inynieria wymaga bezpieczestwa ............................................................. 308
Moliwoci analizy statycznej ....................................................................... 309
Bdy na poziomie kodowania: testy jednostkowe ........................................ 310
Bezpieczestwo czy bezpieczestwo? ........................................................... 310
Profits, stupid! ............................................................................................... 311
Leczy czy zapobiega ? ................................................................................ 312
Praca mudna, mozolna, za to — jaka jaowa! .............................................. 312
Skorowidz .................................................................................... 313
Rozdzia 4.
Zarzdzanie procesami
4.1. Zarzdzanie jakoci
— wadza i zgiek
Tak jak Wenus — podobno — wyonia si z morskiej piany, tak z chaotycznej biega-
niny, nerwowych zebra, nadgodzin programistów, rozpaczliwej krztaniny testerów,
zszarganych nerwów kierownika projektu oraz grób zniecierpliwionego klienta ma
si wyoni Ona: aplikacja-marzenie. Bezbdna. Zaspokajajca wszystkie, nawet naj-
skrytsze marzenia klienta. Idealna.
Wan rol w tym procesie odgrywa testowanie. To test powinien ostrzec: „Panowie,
mielimy budowa Wenus, a na razie widzimy tutaj piciogowego wielbda!”. Test
przypomni, ze bogini piknoci powinna mie dwie, nie za trzy nogi. Test policzy
palce u rk i zawoa, e cztery palce uchodz w komiksach, ale nie w rzeczywistoci.
O ile nietrudno odróni piciogowego wielbda od Wenus, o tyle bdy oprogramo-
wania nie zawsze s oczywiste i rzucajce si w oczy. Zdemaskowanie ich wymaga
skrztnej pracy, wspólnego wysiku wielu osób, którymi kto musi zarzdza i kierowa .
Jak? — o tym wanie bdzie mowa w dalszej czci rozdziau.
Jak opanowa stado bezgowych kur,
czyli zarzdzanie konfiguracj
Zgoszenie bdu — dokadny opis objawów i okolicznoci awarii, sporzdzony przez
testera sporym nakadem pracy po to, by uatwi programicie znalezienie i zlikwido-
wanie przyczyny awarii. Programista bardzo si dziwi: przecie ten bd zosta usu-
nity ju dwa tygodnie wczeniej! „Pewnie uye zej wersji”—– powiada testerowi.
„Ale skd, gówne okno dialogowe wywietlio 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 wic wersja
120
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
numer czternacie feralnego moduu. Tester poci si i czy program ponownie, tym
razem z najnowsz wersj. Awaria nie pojawia si wicej: dobrze. Niestety, po dwóch
tygodniach powraca! Co si stao? Po pó dnia dochodze udaje si ustali , e nowo
zatrudniony programista przez pomyk, czc program, znowu posuy si star wer-
sj feralnego moduu…
Brzmi to znajomo? Oczywicie. Mamy tu do czynienia z klasycznymi symptomami
niedostatków zarzdzania konfiguracj.
No, ale co to ma wspólnego z zarzdzaniem testami? Jak w opisanym przykadzie
— bardzo wiele. System czy program (zwaszcza niezbyt skomplikowany) moe si
niekiedy uda zbudowa — kosztem pewnego czasochonnego zamieszania — mimo
braków w zarzdzaniu konfiguracj. Natomiast zapewnienie jakoci bez dobrze funk-
cjonujcego zarzdzania konfiguracj jest zwykle niemal bezuyteczne. Zidentyfikowane
przez testerów awarie okazuj si albo dotyczy nieaktualnej wersji, albo wymagaj
detektywistycznej pracy, aby znale ich przyczyn w chaosie spltanych wersji po-
szczególnych moduów systemu. Marnuje si w ten sposób wiele czasu i wysiku, przez
co test tylko w ograniczonym stopniu dostarcza swego najwaniejszego produktu: in-
formacji pozwalajcej na znajdowanie i usuwanie bdów.
Z tego wanie powodu czsto zespó testujcy, a nie cay projekt informatyczny, jest
gorcym zwolennikiem uporzdkowania le dziaajcego zarzdzania konfiguracj. Nie
jest to dobre rozwizanie, ale o wiele lepsze ni dobrowolne oddanie si w rce cha-
osu, marnotrawstwa i baaganu. Cho wic nie chodzi tu o testowanie sensu stricto,
niejednemu kierownikowi zespou testujcego przyjdzie si z t problematyk zmierzy
i warto sobie z tego zdawa spraw. Jak konkretnie si to robi: zarzdzanie i kontrol
wersji, budow konfiguracji podstawowych (baselines) — to s ju zagadnienia na
osobny rozdzia.
Rozmawiaa g z prosiciem:
raporty i ledzenie bdów
Kiedy tester natknie si na awari bdc symptomem tkwicego w programie bdu,
fakt ten niesie w sobie dwa rodzaje informacji. Po pierwsze, ilo znajdujcych si
w programie bdów jest podstawow miar jego jakoci, a wic kluczow wielkoci,
któr naley wzi pod uwag, dokonujc decyzji dotyczcych wdroenia, wprowadze-
nia do produkcji czy dostarczenia klientom nowej wersji programu. Po drugie, zaobser-
wowana awaria pozwala zwykle zidentyfikowa bdcy jej przyczyn bd, usun go
i w ten sposób podnie jako programu.
Ani w jednym, ani w drugim przypadku nie wystarczy, by ta wiedza pozostaa w gowie
testera. Trzeba j przekaza programicie, aby rozpocz poszukiwania przyczyny
awarii, oraz kierownikowi projektu, aby móg sporzdzi statystyki bdów i oszacowa
biec jako konstruowanego systemu. Nawet jeli projekt jest jednoosobowy, nie
zawsze daje si wszystko zapamita i prowadzenie notatek na temat znajdowanych
i usuwanych bdów pozwala na uniknicie pomyek.
Tym celom — przekazywaniu oraz gromadzeniu informacji o awariach i bdach — su
tak zwane raporty albo zgoszenia bdów.
Rozdzia 4.
i Zarzdzanie procesami
121
Niektóre traktujce o testowaniu róda (m.in. tumaczona na jzyk polski ksika
amerykaskiego autora Rona Pattona Testowanie oprogramowania
1
) powicaj wiele
miejsca udzielaniu rad, jak powinien postpowa tester, aby dopilnowa , eby znale-
ziony bd rzeczywicie zosta potraktowany powanie i naprawiony. Takie podejcie
wydaje si by stawianiem sprawy na gowie. Po pierwsze, tester ma inne zajcia ni
zastpowanie — niefrasobliwego wida — kierownika projektu i ciganie programistów.
Po drugie, taka sytuacja stwarza realne zagroenie sprowokowania konfliktów midzy
testerami a konstruktorami. Po trzecie wreszcie, tester nie musi mie i zwykle nie ma
penej wiedzy potrzebnej do prawidowej oceny wagi znalezionego bdu. Do tego
konieczna jest — zalenie od rodzaju bdu — jeszcze wiedza na temat struktury i prio-
rytetów wymaga, potrzeb klienta, architektury systemu. Nie jest wcale oczywiste, e
kada awaria wymaga natychmiastowego rzucenia wszystkich dostpnych rodków
w celu jej rozbrojenia i usunicia! To zaley midzy innymi od zwizanego z ni ryzyka.
Do oszacowania ryzyka nie wystarczy zwykle jedna osoba: konieczna jest wspópraca
wielu uczestników projektu, któr umoliwiaj waciwie wykorzystane raporty bdów.
Zorganizowanie procedur zgaszania i ledzenia bdów jest jednym z podstawowych
zada kierownika testów.
Krajobraz przed bitw:
planowanie testów, analiza ryzyka
Jak powiedzia genera, a póniej prezydent Eisenhower, wprawdzie planowany prze-
bieg wydarze nigdy si nie sprawdza, ale mimo to ten dowódca, który planowa naj-
staranniej, ma najwiksze 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óniona — w porównaniu z planem — o dwa miesice, natomiast data dostawy
do klienta nie ulegnie zmianie, przez co na test systemu, zamiast przewidzianych dzie-
siciu, pozostan ledwo dwa tygodnie. Wiadomo, e jako pierwszych dostaw bdzie
taka, e wikszo czasu trzeba bdzie powici na podnoszenie zawieszajcego si
systemu, a nie na wykonywanie przypadków testowych. Oczywiste jest te, e znaj-
dowane bdy spowoduj niezaplanowany wzrost iloci dostarczanych do testowania
wersji programu, przez co czas powicony na ich instalacj i konfigurowanie oraz na
testy regresji wzronie — w porównaniu z planem — dramatycznie. Wreszcie wia-
domo, e proces odpluskwiania (ang. debugging) odcignie pewn ilo testerów na
pewien czas od testowania, a ponadto rodowisko testowe bdzie — w niezaplanowa-
nych wymiarach — zablokowane przez programistów usiujcych odtworzy awari
i zlokalizowa jej przyczyn.
Planujc, e wydarz si wszystkie te niezaplanowane historie, mamy realne podstawy,
by poradzi sobie z wyzwaniem, jakim jest zarzdzanie testami!
1
Nakad obecnie wyczerpany — wrzesie 2008.
122
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Husaria kontra pruska piechota:
jak nie straci impetu, nie tracc gowy?
Impet jest w testowaniu wany, ale musi to by impet kontrolowany, w przeciwnym
razie moe nas sprowadzi na manowce. ledzimy liczb wykonanych przypadków
testowych i porównujemy z zaplanowanymi — w ten sposób ewentualne opónienie
wyjdzie na jaw od samego pocztku, a nie dopiero wtedy, kiedy naronie do katastro-
falnych rozmiarów. ledzimy liczb otwartych, zgoszonych bdów — w ten sposób
moemy próbowa oszacowa ilo pozostaych jeszcze bdów, które zapewne wy-
szyby na jaw w trakcie dalszego testowania systemu, dziki czemu w kadej chwili
mamy do dyspozycji dane pozwalajce odpowiedzie na nieuniknione pytanie: co
kierownik testów sdzi o tym, eby dostawa do klienta miaa miejsce ju pojutrze?
czas testowania
(znormalizowany)
skumulowana liczba
wykonanych zada
testowych
zaplanowana
faktyczna
trudnoci, spitrzenie
bdów
naprawianie bdów
i testy regresji
nadrabianie start
szczliwy koniec
Rysunek 4.1.1.
ledzenie procesu przebiegu testów
Dostrzegszy niebezpieczne, narastajce rozbienoci midzy planem a rzeczywisto-
ci, kierownik testów ma do dyspozycji pi typów rodków zaradczych:
Zmiana harmonogramu testów — odroczenie zakoczenia i terminu dostawy
do klienta.
Zmiana kryteriów jakoci — obnienie poprzeczki, dopuszczenie do uytku systemu
mniej przetestowanego albo majcego wiksz ilo nierozwizanych bdów.
Wykorzystanie do testowania wikszej iloci osób, testowanie równolege.
Zamiana funkcjonalnoci — dostarczony system nie bdzie zawiera
wszystkich wczeniej planowanych funkcji.
Podniesienie wymaganej jakoci dostaw do testu systemowego — to umoliwi
sprawniejsze testowanie i przerzuci cz dziaa na nisze poziomy
(testy komponentów, integracyjne).
Ponadto czsto stosowanym rodkiem jest — kiedy gwatownie narasta ilo
zarejestrowanych zgosze bdów — czasowe zawieszenie wykonywania
nowych testów po to, by da programistom szans na usunicie spitrzenia
Rozdzia 4.
i Zarzdzanie procesami
123
i naprawienie jak najwikszej liczby bdów. W tym czasie zespó testowy
powica si wycznie testowaniu powtarzalnemu dostaw zawierajcych
kolejne poprawki.
Krajobraz po bitwie:
czy mona wypuci produkt ju jutro?
Decyzja o tym, czy mona ju zakoczy testowanie i wypuci , dostarczy albo roz-
pocz wdraanie programu, jest de facto decyzj biznesow, nie techniczn. Stoso-
wana w niektórych przedsibiorstwach zasada, e kierownik testów podpisuje zakocze-
nie testów i niejako tym samym wasn gow gwarantuje dostateczn jako produktu,
jest absurdem. Testowanie nie jest na dobr spraw zakoczone nigdy, zawsze pozo-
staje — z podpisem kierownika czy bez niego — pewne ryzyko, e w programie po-
zostay niezauwaone bdy.
Nie znaczy to jednak, e testowa trzeba w nieskoczono , bo z drugiej strony czai
si przecie ryzyko opónienia, kar umownych, niezadowolonych klientów, utraty
udziaów w rynku na rzecz szybszych czy odwaniejszych konkurentów. Analiza ry-
zyka i podjcie decyzji jest w 100% zadaniem dla kierownictwa lub sponsorów pro-
jektu, ewentualnie dla dziau marketingu. Test ma natomiast za zadanie dostarczy
decydentom jak najprecyzyjniejsze dane dotyczce ryzyka technicznego w oparciu
o dotychczasowe wyniki testowania.
Istnieje wiele kryteriów oszacowania jakoci produktu w oparciu o rezultaty testów.
Bierze si na przykad pod uwag, jaki procent zada testowych zosta dotychczas
wykonany, ile pozostao otwartych (nierozwizanych) zgosze bdów itd. Interesujc
metod jest technika oszacowania iloci pozostaych jeszcze w programie nieznanych
bdów na podstawie funkcji najlepiej pasujcej do krzywej okrelajcej skumulowan
ilo dotychczas znalezionych bdów. Wyjanienie — na ilustracji poniej.
czas testowania
(znormalizowany)
skumulowana liczba
wykonanych zada
testowych
zaplanowana
faktyczna
trudnoci, spitrzenie
bdów
naprawianie bdów
i testy regresji
nadrabianie start
szczliwy koniec
Rysunek 4.1.2.
Szacowanie liczby pozostaych defektów
Oczywicie istotno takich oszacowa zaley od liczby oraz jakoci wykonanych te-
stów. Do ich oceny su rozmaite miary pokrycia (np. wymaga, funkcji, kodu).
124
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Obdzieranie polegych,
czyli jak by mdrym po szkodzie
Projekt zakoczony, produkt sprzedany, kod i dokumentacja zoone w archiwum i prze-
kazane do dziau zajmujcego si serwisem — czy to ju koniec pracy? Otó nie, bo
z danych uzyskanych w trakcie testowania mona jeszcze niejedn ciekaw informa-
cj wycisn . Wprawdzie na popraw jakoci wytworzonego przez zakoczony pro-
jekt produktu informatycznego ju za póno, nie da si take podwyszy jakoci de-
cyzji, które ju zapady, ale mona uzyska wiedz pozwalajc by moe kolejne
projekty poprowadzi lepiej i sprawniej.
Bogatym ródem wiadomoci jest baza danych z raportami bdów. Mona na przy-
kad szczegóowo zanalizowa pewn liczb losowo wybranych raportów i spróbowa
odpowiedzie na pytanie, jaka bya pierwsza przyczyna zaistnienia danego bdu? Czy
byy ni niejasno sformuowane wymagania, czy niedostateczna znajomo jzyka przez
programistów, czy niedocignicia organizacyjne?
Warto te przyjrze si statystykom raportów bdów. Kiedy pojawio si ich najwicej?
Jaki by czas naprawy bdu? Ile raportów okazao si faszywych? Odpowiedzi na te
pytania niejednokrotnie pozwol zidentyfikowa sabe punkty w procesach i procedu-
rach projektów lub niedostatki organizacyjne w przedsibiorstwie.
Róne formy organizacji testowania
Nie zawsze jedyn i najlepsz form organizacji testów jest stworzenie osobnego zespou
testowego. Zalenie od charakteru projektu, typu produktu, przyjtej metodyki wytwa-
rzania korzystne moe okaza si zastosowanie innych rozwiza organizacyjnych.
Programici sami testuj wasny kod. Metoda czsto stosowana w testach
moduowych (jednostkowych, komponentów). Jej wady s oczywiste.
Testowanie koleeskie (ang. buddy testing): programici nawzajem testuj
swój kod. Stosowane midzy innymi w popularnym ostatnio „Programowaniu
Ekstremalnym” (XP, Extreme Programming).
Tester (lub testerzy) s czonkami zespou programistów, podlegaj kierownikowi
zespou lub projektu.
Osobny zespó testujcy majcy wasnego kierownika.
Osobny dzia w przedsibiorstwie zajmujcy si pewnymi rodzajami testów.
Outsourcing testów do innego przedsibiorstwa: stosowane wówczas, gdy
wymagana jest niezalena certyfikacja systemu oraz gdy niezbdne jest
skomplikowane i kosztowne rodowisko testowe (np. w testowaniu konfiguracji,
testowaniu zgodnoci z wymaganiami rodowiskowymi itp.).
Wybór waciwej organizacji testowania jest wanym zadaniem dla kierownika
projektu. Warto pamita , e w wikszych projektach kilka rónych form
organizacyjnych moe istnie jednoczenie, na przykad testowanie koleeskie
na poziomie testów komponentów, odrbny zespó do testu systemowego,
outsourcing w celu uzyskania niezalenej certyfikacji.
Rozdzia 4.
i Zarzdzanie procesami
125
Kiedy zaczyna, kiedy sko czy?
Jak zwykle bywa — dobrze wiemy. Jak powinno by — zwile opisuje rysunek 4.1.3.
Czynnoci wykonywane przez zespó testowy napisane s tustym drukiem na jasno-
szarym tle.
Specyfikacja
wymaga
Specyfikacja
konstrukcji
Kodowanie
Testy komponentów
Testy integracyjne
Test systemu
Test akceptacyjny
Walidacja
wymaga
Testowalno
wymaga
Przegld
Przegld
Przygotowanie
testów
Przygotowanie
testów
Testowanie
Rysunek 4.1.3.
Przegld modelu „V”
4.2. Znowu ten popiech — jak szybko
oceni jako aplikacji?
Popiech w informatyce
Zrobi cokolwiek szybko? Znowu ten popiech. Znane jest przecie porzekado: „co
nagle, to po diable” i niezliczone przykady sytuacji, kiedy zabrako czasu i rodków,
aby co wykona dobrze, ale znalazo si potem i jedno, i drugie, aby to co wielo-
krotnie poprawia . Informatyka to brana cierpica od swego powstania na syndrom
czarodziejskiej plasteliny. Kilkadziesit lat temu udao si ludziom speni swe odwieczne
marzenie i znale 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
ukad sterujcy do pralki automatycznej. Figurki lepione z naszej czarodziejskiej pla-
steliny — instrukcji mikroprocesora — rzeczywicie mona tworzy zadziwiajco szybko
w porównaniu z przedmiotami z drewna, metalu czy betonu, a ponadto mona je po-
tem wzgldnie atwo poprawia bez potrzeby burzenia caoci, jeli co si nie ca-
kiem uda. Ludzikowi z plasteliny mona nawet, kiedy ju jest gotowy, oderwa nog
i zastpi j inn, lepsz, ale te wyglda on potem jak… ludzik z plasteliny.
126
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Programowanie naraone jest na nieustann pokus bylejakoci i popiechu, których
skutkiem jest bardzo czsto albo fatalna jako aplikacji, albo lekcewaenie uytkow-
nika i jego potrzeb, przez co wiat zapeniaj zawodne i pokraczne, niewygodne w ob-
sudze twory z plasteliny. Po co zbiera i analizowa wymagania, skoro mona zacz
budowa od razu, a potem, w razie czego, wszystko si przerobi? Po co starannie pro-
jektowa system, skoro mona od razu zacz kodowanie, a potem jako si te, niepa-
sujce do siebie, czci poskleja w cao ? Po co dba o jako projektu, skoro w ba-
aganie te daje si pracowa , i po co wysila si na produkty dobrej jakoci, skoro
czarodziejska plastelina pozwala na pozór bezkarnie poprawia , sztukowa , zaizolowa
kawakiem dtki, przymocowa drutem?
Mio jest sobie pozrzdzi , ale z drugiej strony nie mona zaprzeczy , e to dziki
systemom informatycznym dzisiejszy wiat ogromnie przewysza ten sprzed lat
trzydziestu i czterdziestu pod wzgldem moliwoci, dobrobytu, bezpieczestwa i or-
ganizacji, cokolwiek na ten temat sdz rozmaici zwolennicy powrotu do jaski czy
wrcz na drzewa.
Ponadto, szydzc sobie z typowego projektu informatycznego: drwala, który nie ma
czasu porzdnie naostrzy siekiery, bo tak bardzo si spieszy z rbaniem drewna, nie
sposób przecie zapomnie o zagroeniach z przeciwnej strony: drwalach tak zajtych
ostrzeniem siekiery, e nie maj czasu na cinanie drzew. Czynniki psychologiczne po-
woduj, e chtnie — uchylajc si przed naprawd trudnymi wyzwaniami — ucie-
kamy w rytualizacj, mnoenie zbdnej dokumentacji, mani zebra i posiedze, wiar
w rzekomo uzdrowicielsk moc procedur, procesów, poziomów dojrzaoci i sprawnoci,
duszcych prawdziw kreatywno i skuteczno .
Czy nie ma drogi poredniej midzy jedn a drug skrajnoci? Jest, oczywicie — to
popiech kontrolowany, gdzie umiejtno i wprawa pozwalaj porusza si szybko,
lecz pewnie, a cieki na skróty niekoniecznie prowadz na manowce.
Pomiary w popiechu
Warunkiem skutecznego popiechu kontrolowanego jest umiejtno nadzoru w biegu,
tak eby zakrt móc przej na piszczcych oponach, ale z niego nie wylecie , poko-
nujc za na skróty bezdroa, orientowa si zrcznie za pomoc mapy, kompasu, ze-
garka i bystrych oczu — i nie zabdzi .
Nie jestemy w stanie kontrolowa tego, czego nie umiemy zmierzy . Ale pomiar nie
jest w informatyce sowem lubianym — nawet poddany mi przez Redakcj tytu tego
artykuu omija je, zastpujc niebudzcym lku sowem ocena. Cho jako specjalista
w brany nie raz spieraem si przy piwie, czy to testowanie, czy te utrzymanie opro-
gramowania jest bardziej niesusznie lekcewaone w praktyce naszego przemysu, wy-
daje si, e palma pierwszestwa naley si jednak pomiarom. Dobry kierowca raj-
dowy nie musi wysiada z samochodu i mierzy promienia skrtu tam tylko dziki
temu, e wprawa pozwala mu mierzy bez przerywania jazdy. Przewodnik, na pozór
bez wysiku wyprowadzajcy przez gste krzaki wprost na zamierzony punkt, nie wlecze
za sob wielokilometrowej nici Ariadny tylko dlatego, e nieustannie podczas marszu
Rozdzia 4.
i Zarzdzanie procesami
127
mierzy przebyt odlego , kierunek, nachylenie terenu. W przemyle informatycznym
chtnie udajemy kierowców Formuy 1 oraz dzielnych przewodników, nie majc nie-
zbdnych po temu umiejtnoci mierzenia.
Brak umiejtnoci sprawnego mierzenia uniemoliwia zarzdzanie ryzykiem, zast-
pujc je unikaniem ryzyka — lub bezsensown brawur. Unikanie ryzyka w inynierii
oprogramowania rodzi projekty sztywne, zbiurokratyzowane, nieskuteczne, omijajce
waciwe wyzwania. Bezsensowna brawura oznacza fanfaronad przy wyznaczaniu ce-
lów, rodków i terminów, po czym… To, co zdarza si potem, take mona oczywi-
cie zmierzy . Odpowiedni miar, nie do koca jeszcze uznan przez fizyków, jest
„och-nie-sekunda” (ang. oh-no-second), stosowana do okrelenia czasu upywajcego
od chwili, gdy si zorientowalimy, e popenilimy NAPRAWD DU
Y B
D
(np. klikajc „wylij do wszystkich” na koniec maila penego wspomnie z bardzo
gorcej nocy).
O zarzdzaniu 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
Wyobramy sobie, e penimy funkcj Naczelnika Jakiej Jednostki Administracyjnej.
Najnowsza polityka rzdu kadzie szczególny nacisk na oczyszczanie lasów z grzybów.
Dlaczego — niewane, ale nietrudno sobie wyobrazi … Grzyby przecie bywaj
trujce, a ludno musi by chroniona przed zagroeniami. Nastpnie jestemy nowo-
czesnym europejskim krajem, a grzyby nie maj witamin, nie poddaj si racjonalnej
hodowli i wzbudzaj — jako pozbawione chlorofilu — zastrzeenia wojujcych ro-
dowisk wegetariaskich. Poza tym grzyby to pasoyty, co kóci si z ideami solidary-
zmu spoecznego (lub jest ich zoliw karykatur), a ich preferencje seksualne te s
— zdaje si — nad wyraz nieprawomylne. Niech do grzybów ma wyranie ponad-
partyjny charakter, wic lasy maj by odgrzybione, a za dwa dni przyjedzie — o czym
da nam cynk kolega z Ssiedniej Jednostki Administracyjnej — Nadzwyczajna Komisja,
eby sprawdzi stan odgrzybienia naszego lasu podmiejskiego. Tak wic mamy SZYBKO
OCENI JAKO LASU!
Nie musz dodawa , e dotd w tej sprawie nie zrobiono nic. Gdyby las by ju wcze-
niej systematycznie odgrzybiany, nie byoby paniki. Oczywicie identycznie jest
z potrzeb szybkiej oceny jakoci aplikacji. Gdyby projekt by od pocztku prowa-
dzony porzdnie, jako aplikacji byaby po prostu znana — realizowana i mierzona
cay czas. Có, jednak wiat jest niedoskonay, wic idziemy mierzy w popiechu.
Grzybobranie
Zasada podstawowa — nie da si trafnie oceni stanu zagrzybienia lasu, nie wysyajc
tam ludzi odpowiednio zmotywowanych, umiejcych szuka grzybów! Mona, rzecz
prosta, wysa do lasu krótkowidza, który na grzybach si nie zna, dla cakowitej pew-
noci mówic mu zowieszczym gosem: „Mam nadziej, e przyniesie mi pan DOBRE
128
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
wiadomoci!”. Wtedy ocena jakoci lasu bdzie wprawdzie odpowiednio szybka, ale
cakowicie nietrafna, a nie o to chyba nam chodzi. miejc si z takiej metody, nie
zapominajmy, e dokadnie tak odbywa si czsto próba szybkiej oceny jakoci apli-
kacji — jeli nie wykonuj jej fachowi testerzy, odpowiednio nagradzani za przyno-
szenie wieci o bdach, wynik pomiaru jest bezwartociowy.
Dobry grzybiarz szuka grzybów tam, gdzie spodziewa si je znale . Wykorzystujc
sobie tylko znane intuicje, wie gdzie zwykle rosn kolaki, gdzie rydze, a gdzie opieki,
dziki czemu przynosi ich pene kosze. Tak samo dowiadczony tester wykorzystuje
swe wczeniejsze dowiadczenia, aby szuka bdy ocenianej aplikacji tam, gdzie spo-
dziewa si je znale . Jak rydze lubi rosn pod wierkami, tak bdy lubi si na
przykad gromadzi w pobliu wartoci kracowych, na granicach przedziaów, i do-
bry tester tam wanie bdzie ich szuka. Dalej, bdy chtnie dojrzewaj w miejscach
odludnych, których nikt od dawna nie testowa, bo kod jest tak zawiy, e lepiej go
nie rusza . Wiemy te, e obecno kilku bdów zwykle oznacza, e jest ich tam
o wiele wicej — wynikaj bowiem z tych samych bdów projektowania. Kolejn
regu streszcza powiedzenie „gdzie kucharek sze …” — jeli kod by wielokrotnie
zmieniany, jeli modyfikowao go wielu programistów — warto poszuka bdów.
Zasad jest wiele, a profesjonalni testerzy powinni je zna .
Wró my do podmiejskiego lasu. Dowiadczony grzybiarz szuka grzybów tam, gdzie
zwykle rosn, ale niekoniecznie tam, gdzie bdzie ich szuka nasza Nadzwyczajna
Komisja. Jeli czonkowie Komisji s agodnymi, leniwymi grubasami, zadowol si
pobienym sprawdzeniem bezporedniej okolicy wygodnych cieek i tam wanie
— wbrew instynktowi grzybiarza — trzeba przeszuka teren szczególnie starannie.
Jeli w skad Komicji wchodz ambitne, mode wilki, bd si stara wykaza , szu-
kajc w nietypowych miejscach — nieche wic grzybiarze strwoonego Naczelnika
Jednostki na wszelki wypadek przepatrz miejsca pod kamieniami, wród gstych krza-
ków czy w inne, do których podejrzewamy, e chtnie skieruj si mode wilki.
Przenoszc si na chwil z powrotem w dziedzin oceny jakoci aplikacji, naley oce-
nia przede wszystkim to, czym najczciej posuguj si uytkownicy kocowi. Skoro
nie ma si do dyspozycji dostatecznie dugiego czasu, aby oceni wszystko, warto skon-
centrowa si na obszarach, gdzie — z racji intensywnego uytkowania — prawdopo-
dobiestwo awarii, jeli s tam bdy — jest najwysze. Dziki temu jako aplikacji
— mierzona rednim czasem midzy awariami — bdzie wysza, oczywicie przy
zaoeniu, e znalezione podczas oceniania bdy bd te usuwane.
Grzyb grzybowi nierówny. Doniesiono Naczelnikowi Jednostki, e Komisja jest szcze-
gólnie uczulona na muchomory sromotnikowe, pewnie ze wzgldu na ich ksztat. Dla-
tego naczelnik uczula swoich grzybiarzy, aby szukali — wbrew swoim naturalnym,
grzybiarskim instynktom — wanie sromotników. Tak samo przy szybkiej ocenie ja-
koci aplikacji koncentrujemy si na tych bdach, których skutki z punktu widzenia
uytkowników s szczególnie ze, a mniej czasu powicamy bdom, o których wia-
domo, e — jeli nawet gdzie s — nie bd dla uytkowników zbyt dotkliwe.
W rodku lasu jest ostaniec — pionowa, kilkunastometrowa skaa. Moe na jej szczycie
te rosn jakie grzyby, a który z czonków Komisji uprawia sporty ekstremalne i tam
si wdrapie? Moe, ale z drugiej strony, spenetrowanie wierzchoka skay wymagaoby
Rozdzia 4.
i Zarzdzanie procesami
129
drabin, stray poarnej, kto wie, czy nie helikoptera, co pochonoby znaczn cz
rodków dostpnych na szybk ocen jakoci lasu, przez co gorzej zostayby spene-
trowane jego atwiej dostpne rejony. W tej sytuacji chyba rozsdniej jednak bdzie
zostawi w spokoju ska. Tumaczy si potem, e w lesie wprawdzie jest peno grzy-
bów, ale za to wolny od nich jest trudno dostpny ostaniec — to nie bdzie brzmiao
dobrze.
Std wypywa kolejny wniosek dla oceniania jakoci aplikacji — jeli mamy ograniczone
zasoby, a sowo „szybko” oznacza, e brakuje nam najcenniejszego z nich, czyli czasu
— trzeba uwzgldni , na ile trudne i kosztowne s pewne testy, tak eby dostpne rodki
rozdysponowa raczej równomiernie, a nie tylko w jednym, szczególnie zasobochonnym
obszarze.
Testowanie uwzgldniajce ryzyko
Powysze rozwaania s streszczeniem podejcia znanego jako testowanie uwzgldnia-
jce ryzyko (ang. risk based testing). Jeli jako musimy oceni szybko, testujemy (oce-
niamy, mierzymy) przede wszystkim to, co najwaniejsze, uwzgldniajc cztery klu-
czowe parametry:
Prawdopodobie stwo bdu — szkoda czasu, aby szuka bdów tam,
gdzie by moe ich nie ma.
Konsekwencje awarii — przy ocenie jakoci naley szuka raczej awarii
katastrofalnych ni niegronych, kosmetycznych.
Prawdopodobie stwo zastosowania — trafniej ocenimy jako , biorc pod
uwag przede wszystkim to, czym uytkownicy posuguj si na co dzie,
ni to, z czego korzystaj raz do roku lub wcale.
atwo testowania — przy szybkiej ocenie warto te wzi po uwag,
by — o ile nie chodzi o awarie katastrofalne — raczej unika wikania si
w próby oceny tego, czego pomiar jest zbyt kosztowny i czasochonny.
Jakie to atwe...
Warum einfach? Kompliziert geht es auch! — powiadaj nasi zachodni ssiedzi. Po-
peniam zdaje si bd, przedstawiajc atwo zrozumia przypowie o grzybach za-
miast epatowania licznymi skomplikowanymi nazwami i trzyliterowymi skrótami. Prze-
czytawszy wstpn wersj artykuu, kto powiedzia „to cae testowanie jest w gruncie
rzeczy bardzo proste”. Owszem, jeli wiemy, gdzie rosn grzyby (znamy si dobrze
na informatyce, na testowaniu i na projektach informatycznych), jeli znamy dziedzin
zastosowania (ocena czstoci zastosowania oraz konsekwencji awarii) oraz techno-
logi testów (ocena atwoci testowania). Przydaje si te nieza znajomo technik
pomiaru oraz analizy ich wyników, troch statystyki… POZA TYM caa reszta to
rzeczywicie odrobina zdrowego rozsdku.
130
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Bilet do Davos
Cae kosze usunitych z lasu grzybów wywieziono daleko — czy mona spokojnie
oczekiwa inspekcji? Czy moe 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 duy grzyb jednak wykrya?
Trudno powiedzie — testowanie uwzgldniajce ryzyko pozwala skutecznie znaj-
dowa bdy, nawet w popiechu do trafnie oceni jako aplikacji, ale nigdy nie
wie si dokadnie, na ile jest ono dokadne: czy czasem — mimo stara — jaka
funkcja nie zostaa pominita, jaka cz systemu zapomniana?
eby t pewno
uzyska , naleaoby — wró my do historii o lesie — wzi dokadn map lasu, po-
dzieli j na kwadraty i cay las systematycznie przeczesa . Wprawdzie wiele z miejsc zi-
dentyfikowanych tym sposobem byoby zupenie bezsensownych, na przykad plaa,
gdzie jako ywo grzyby nie rosn, lub rodek bagna, gdzie komisja nigdy nie dotrze,
ale jest to koszt systematycznoci, cena za ubezpieczenie od skutków przeoczenia lub
zapomnienia.
W odniesieniu do oceny jakoci aplikacji odpowiednikiem mapy jest model dziaania
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 wic oszacowa niezawodno wykonanych ocen, ale na to
przy ocenie szybkiej nie mamy zwykle czasu. Jedno jest wic pewne — ocena szybka
jest zawsze mniej pewna ni ocena spokojna, oczywicie pod warunkiem starannoci
jednakowej w obu przypadkach.
Jak spieszy si powoli
Spieszc si, nie trzeba rezygnowa z mylenia. Nie chodzi przecie o to, by wyko-
nywa mnóstwo szybkich, nerwowych ruchów, gono krzycze przez kilka na raz
telefonów i pracowa — nieefektywnie — po dwadziecia godzin na dob, tylko o to,
by mimo popiechu pozosta skutecznym i skoncentrowanym na celu.
Pogodzi popiech ze spokojn systematycznoci usiuj metodyki „systematycznego
testowania w popiechu” (tak celnie okreli je dr Lucjan Stapp z Politechniki Warszaw-
skiej w swym wystpieniu na jednym z zebra Stowarzyszenia Jakoci Systemów
Informatycznych).
Jedna z nich to testowanie eksploracyjne (ang. exploratory testing): zespó technik
wspomagajcych testerów w sytuacji na pozór beznadziejnej, kiedy jednoczenie trzeba
uczy si aplikacji, wykonywa testy i projektowa nowe zadania testowe. Za pomoc
szeregu kreatywnych sposobów — przydatnych take wówczas, gdy popiech nie
jest a tak wielki — projektuje si nowe testy na podstawie obserwacji i analizy wy-
ników testów wanie wykonywanych. Jednym sowem, podejcie eksploracyjne po-
prawia skuteczno testów wtedy, gdy nie ma czasu, by je starannie zaplanowa , tylko
trzeba strzaem z biodra szybko oceni jako aplikacji.
Rozdzia 4.
i Zarzdzanie procesami
131
Czciowo odmienne podejcie prezentuje testowanie zwinne (ang. agile testing). Jego
podstawa to zasada testowania parami: testerzy pracuj w dwuosobowych zespoach,
testy wykonuj wspólnie. Takie podejcie budzi uzasadnione wtpliwoci, czy nie jest
po prostu dublowaniem kosztów, ale praktyczne dowiadczenia sugeruj, e faktycz-
nie pozwala na wiksz skuteczno .
Kilka lat temu gono byo o metodyce programowania ekstremalnego (ang. extreme
programming), gdzie programici pracuj w parach, zamieniajc si pisaniem kodu
i przygotowywaniem (automatycznych) testów dla tworzonego wanie kodu. Progra-
mowanie ekstremalne postuluje ponadto ograniczenie do minimum tradycyjnej, ci-
kiej dokumentacji, blisk wspóprac programistów z przedstawicielami klienta, czste
— nawet kilka razy na dzie — budowanie caego systemu. Z jednej strony progra-
mowanie ekstremalne obiecuje wprawdzie nisz czasochonno projektów, czym pasuje
do naszego tematu; z drugiej strony — postuluje przygotowywanie testów oceniaj-
cych jako , jeszcze zanim powstanie kod, co nie do koca ju zgadza si z paradyg-
matem „szybkiej oceny jakoci 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 ówiu i o zajcu.
4.3. Po co mierzy?
Miary w inynierii oprogramowania
Miary czsto kojarz nam si z czym pozytywnym; mówi si: umiarkowany, miar-
kowa, zna miar, na miar, miarowo.
Z drugiej strony, brak miary te chwilami brzmi obiecujco, jak w sowie bezmierny.
Miary s niebezpieczne dla tych, którzy usiuj co ukry , wol mtniactwo i niejed-
noznaczno od precyzji. Miary trzeba dobrze rozumie , tak wic niektórym ludziom
wydaj si one niebezpieczne; wedug Flawiusza to Kain wynalaz „miary i wagi,
zmieni ow niewinn i szlachetn prostot, w jakiej yli ludzie, póki ich nie znali,
w ycie pene oszustwa
2
”.
Miary, które znamy na co dzie, wydaj si oczywiste, ale nie ma nic oczywistego w tym,
aby od prostego „zimno”, „rednio” i „ciepo” przej do skal, gdzie wartoci liczbowe
przypisywane temperaturze powietrza odnoszone s do dugoci supka rtci zamknitej
w szklanej rurce. Fakt, e istniej trzy róne, powszechnie stosowane skale tempera-
tury: Fahrenheita, Celsjusza i Kelvina, z których kada 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 czciowo arbitralnie sposobem od-
wzorowania natenia pewnych atrybutów rzeczywistoci — oj, to brzmi bardzo na-
ukowo, ale ma konkretny, praktyczny sens.
2
Józef Flawiusz, Staroytnoci ydowskie, I.2.2, wyd. polskie: Warszawa 1962, s. 105 — cytat wg prezentacji
Andrzeja Kobyliskiego na Konferencji SJSI, Serock, maj 2005.
132
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Inynieria — zestaw zdefiniowanych, powtarzalnych technik projektowania, wytwa-
rzania i utrzymania rozmaitych rzeczy — nie moe istnie bez pomiarów. Trudno
wyobrazi sobie inyniera, który nie umie mierzy dugoci, ciaru, napicia czy
natenia, albo lekarza bez termometru i narzdzi do precyzyjnego pomiaru chemicz-
nego skadu krwi. Jedynie inynieria oprogramowania choruje na brak umiejtnoci
pomiaru nie tylko wasnych procesów, ale nawet produktów!
Czego nie mona zmierzy, tego si nie wie
Zapyta kto — jakie to ma znaczenie? Czy to kolejna z wielu mód, kolejne goosowne
twierdzenie, jakoby co bardzo zego dziao si z przemysem informatycznym, pod-
czas gdy goym okiem wida , e dzieje si cakiem dobrze?
Dobrze — zaley w odniesieniu do czego. W porównaniu z przemysem elektronicznym
przyrost wydajnoci w produkcji oprogramowania jest od wielu lat skromny. Produkty
programistyczne czsto okazuj si zawodne, a ich spektakularne niepowodzenia — jak
na przykad osawione dwuletnie opónienie oddania do uytku lotniska w Denver
w 1995 roku z powodu przekroczenia terminu dostawy oprogramowania systemu ba-
gaowego — przechodz do legendy. Wielkie jest zrónicowanie produktywnoci pro-
gramistów w rónych firmach i projektach — wedug niektórych danych rónice wy-
nosz nawet 600:1 (sze set do jednego, to nie jest bd w druku).
Jednoczenie — tu akurat brana informatyczna niczym specjalnym si nie wyrónia
— goosowne twierdzenia i slogany wystpuj masowo. „Nasze najnowsze techniki
gwarantuj 100% wzrostu produktywnoci”, „uycie narzdzi pozwoli skróci testo-
wanie o ” — przykady mona mnoy . Czego nam brakuje, by móc przeciwstawi
wiedz próbom manipulacji? Systematycznego stosowania pomiarów i dostpu do ich
wyników.
Planowanie projektów informatycznych okazuje si w praktyce niejednokrotnie zwy-
kym wróeniem z fusów. Jak oszacowa pracochonno projektu produkcji opro-
gramowania, którego wymagania s opisem sowno-muzycznym? Nieatwo na takiej
podstawie oszacowa wielko produktu, na przykad w formie liczby wierszy kodu,
a nawet majc do dyspozycji takie oszacowanie, nie ma prostej i godnej zaufania metody,
aby przeoy je na liczb koniecznych osobodni.
Brak umiejtnoci mierzenia powoduje, e jakiekolwiek dyskusje porównujce zalety
i wady rónych metod, technik, jzyków programowania i modelowania cierpi na chro-
niczn dowolno , na odwoywanie si do anegdotycznych, statystycznie nieistotnych
przykadów. Nie umiejc mierzy przebiegu projektów, nie potrafimy na dobr spra-
w nimi zarzdza . Intuicja, objawienia, i-cing — wszystko to bardzo ciekawe metody
pod warunkiem, e uzupeniaj proces decyzyjny i przewidywania oparte na pomia-
rach, a nie usiuj je zastpowa. Zarzdzanie ryzykiem staje si fikcj, jeli ani nie
potrafimy zagroe zidentyfikowa , ani oszacowa kosztów zapobiegania, ani oceni
ich prawdopodobiestwa. W opublikowanym niedawno artykule napisaem, e „w prze-
myle informatycznym chtnie udajemy kierowców Formuy 1 oraz dzielnych prze-
wodników, nie majc niezbdnych ku temu umiejtnoci mierzenia”.
Rozdzia 4.
i Zarzdzanie procesami
133
Jak nauczy si trudnej sztuki wykonywania pomiarów i analizy ich wyników? Jak nie
da si w przyszoci zagada elokwentnym zwolennikom Jedynie Susznej Drogi, czy
bdzie ni czysty Brak Procedur, czy ISO 9000, czy CMM, czy cokolwiek innego, tylko
doj samodzielnie do wasnych wniosków, wybiera to, co rzeczywicie najlepsze dla
nas i naszych firm?
Doskonaym, praktycznym przewodnikiem jest wydana pod koniec ubiegego roku
ksika
3
dr. Andrzeja Kobyliskiego z SGH pod niezbyt chwytliwym marketingowo
tytuem Modele jakoci produktów i procesów programowych. Nazwabym j chtniej
Informatyk mierzy.
Ksika
Pierwsza, podstawowa zaleta omawianej ksiki dla praktyków informatyki to jej przy-
stpno . Cho jest to pozycja naukowa, akademicka, jednak zarówno jej jzyk, jak
i zorientowany na praktyczne potrzeby tryb wykadu umoliwiaj skuteczn lektur
take osobom majcym gównie praktyczne dowiadczenia informatyczne.
Jako to pojcie kluczowe dla praktyki informatycznej, a mimo to niebezpiecznie
niejednoznaczne. Cho definicji jakoci jest wiele, a kada zasuguje na osobn mo-
nografi, istnieje przecie dua, niezaspokojona potrzeba jednoznacznego okrelenia
jakoci 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 czci ksiki.
Cz druga dotyczy jakoci produktu. Omawia atrybuty jakoci produktów, zale-
noci midzy nimi oraz sposoby ich pomiarów. To tematyka o duym znaczeniu dla
wszystkich udziaowców projektu informatycznego. Niedostatki wiedzy na ten temat
powoduj, e klienci niejasno i niepoprawnie okrelaj swoje wymagania, analitycy
systemowi sporzdzaj niepene modele, inynierowie jakoci maj problemy z jed-
noznaczn ocen jakoci gotowego lub budowanego wanie produktu.
Jeli w projektach zdarzaj si kopoty, próbuje si je rozwizywa , usprawniajc pro-
cesy i procedury. Jest wiele rónych modeli, jak postpowa , aby okreli i wdroy
usprawnienia, a kady 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 dziaa i konkurowa , wic
firmy musz take si zmienia , by sprosta nowym wyzwaniom. Róne s przyczyny
i cele zmian, a udoskonalenie sposobu pracy jest jednym z waniejszych. Próba udo-
skonalenia moe zakoczy si trojako:
3
Andrzej Kobyliski Modele jakoci produktów i procesów programowych, Szkoa Gówna Handlowa
w Warszawie, Warszawa 2005, ISSN 0867-7727. Mona j kupi w Oficynie Wydawniczej SGH,
www.wydawnictwo.waw.pl.
134
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Rysunek 4.3.1.
Koszty zmiany w czasie
SKUTECZNO
I SPRAWNO
CZAS
Stan
pocztkowy
Analiza
zmiany
Wdraanie
zmiany
Sukces
Niepowo-
dzenie
Klska
Aby zmniejszy ryzyko niepowodzenia, trzeba sprawnie przeprowadzi analiz mo-
liwej zmiany oraz skutecznie zrealizowa jej wdroenie. Jak posi niezbdn do tego
celu wiedz? Czytajc cz trzeci ksiki, gdzie znajdziemy zarówno przegld ist-
niejcych, znanych metod oceny i doskonalenia procesów, jak i porównanie wynika-
jcych z nich korzyci oraz zagroe.
Tematyka budzca spore emocje, a przy tym znaczca dla powodzenia projektów oraz
firm, to kwestia relacji midzy udoskonalaniem procesów a jakoci produktów. Kady
pewnie sysza sarkastyczne historyjki o wdroeniach certyfikatów ISO 9000, wyma-
gajcych jakoby jedynie naklejenia karteczek z nazw na wszystkie znajdujce si w fir-
mie przedmioty, mnocych zbdn papierologi i nieprzekadajcych si w aden sposób
na jako produktów. Na przykad synny Tom DeMarco jest sceptycznie usposobiony
do korzyci pyncych z osigania wyszych poziomów CMM, twierdzc, e prowadzi
to wycznie do polepszenia chwilowej sprawnoci kosztem zmniejszenia elastycznoci
i utraty strategicznej efektywnoci.
Cz czwarta ksiki powicona jest temu wanie zagadnieniu ujtemu w unikalny,
wasny sposób autora.
Podsumowujc — ksika Andrzeja Kobyliskiego to pozycja, któr kady meneder
firmy czy kierownik projektu informatycznego bdzie czyta z duym zainteresowaniem,
a naley j take poleci inynierom jakoci oraz inynierom testów. Bo przecie, eby
mówi o jakoci, trzeba j umie mierzy , test jest za podstawowym sposobem pomiaru!
4.4. Midzy biurokracj a chaosem: ADP
Kopot
Kiedy byem dzieckiem, przeyem okres fascynacji robieniem na drutach. Opanowawszy
sztuk zaptlania kilku rodzajów oczek, stworzyem co na ksztat dugiego na metr,
nierównego szalika skadajcego si z bezadnej mieszanki wzorów i oczek. Nie dao
si tego do niczego uywa i zaraz potem porzuciem krótkotrwae zamiowanie.
Rozdzia 4.
i Zarzdzanie procesami
135
Podobnie, cho nie a tak le, wygldao tworzenie oprogramowania w pierwszych
dwóch dekadach istnienia komputerów. Przedsiwzicia informatyczne (ang. projects)
byy chaotyczne i nieplanowe, nie stosowano systematycznej inynierii wymaga (ang.
requirements engineering), kod tworzono bez uprzedniego projektowania (ang. design),
wic produkt kocowy zwykle nie mia trafnej funkcjonalnoci, nie by wygodny
w uytkowaniu ani atwy w utrzymaniu.
W roku 1968 podczas konferencji inynierii oprogramowania NATO (NATO Software
Engineering Conference) termin inynieria oprogramowania po raz pierwszy pojawi
si oficjalnie [1]. Doczekao si uznania twierdzenie, e tworzenie oprogramowania
to co wicej ni zgodne z reguami jzyka programowania stawianie szeregu instrukcji;
e istniej systematyczne, zdyscyplinowane i mierzalne metody wykonywania tego
procesu.
Wkrótce — 7 padziernika 2008 r. [2] — przyjdzie nam zatem obchodzi 40. rocznic
tego wydarzenia
4
. Gdzie inynieria oprogramowania znajduje si dzisiaj?
Akcja i kontrakcja
Na poziomie kodowania (implementacji) i czciowo take projektowania zaszy ogromne
zmiany. Od paradygmatu GOTO, przez metody strukturalne, przez nieudane próby j-
zyków 4. generacji, przemys informatyczny wszed w er metod i jzyków obiektowych.
Od tworzenia kadej aplikacji niemal od zera, przez biblioteki funkcji, dotarlimy
do hierarchii klas, bibliotek czonych dynamicznie [3] i wielojzykowej platformy
CORBA [4]. Od niewydarzonego, topornego interfejsu wierszowego [5] przeszlimy
do znacznie wygodniejszych interfejsów graficznych [6]; zaczto te coraz systema-
tyczniej uprawia inynieri interakcji [7].
Mniej radykalne przemiany zachodziy na wyszych poziomach procesu: projektowa-
nia architektury, inynierii wymaga oraz testowania, ale i tutaj mona bez wtpienia
wskaza wiele nowych metod, modeli oraz narzdzi.
Dzi — w porównaniu z sytuacj sprzed 40 lat — mamy wic do dyspozycji o wiele
wicej znacznie potniejszych sposobów pracy, dziki którym daje si tworzy pro-
dukty coraz bardziej zoone coraz szybciej.
W tyle za rosnc skutecznoci i sprawnoci metod technicznych pozostawaa i po-
zostaje nauka o zarzdzaniu przedsiwziciami. Nasza wiedza o tym, jak optymalnie
organizowa przedsiwzicia informatyczne, jak dobiera oraz wiza ze sob metody
i narzdzia, uwzgldniajc rodzaj produktu, wymagania niezawodnoci oraz szereg czyn-
ników ludzkich, wci pozostaje w powijakach. Pojawio si i zyskao krótkotrwa
saw wiele nowoci: gono byo raz o TQM, kiedy indziej o clean-room software
engineering, o technikach przyrostowych, o daily build, o modelowaniu obiektowym,
o RUP — nazwy mona mnoy . Narastajca zoono i ociao modeli procesów
wytwarzania oprogramowania spowodowaa kontrakcj: od okoo 15 lat coraz wiksz
popularnoci ciesz si metodyki lekkie i zwinne (ang. agile [8]).
4
Esej napisany we wrzeniu 2007 roku.
136
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Procesy — zarówno cikie, 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 mona podzieli na dwie wielkie stronnictwa: metametody cikie i metametody
lekkie (terminologia wasna autora artykuu).
Metametody cikie: rezerwat lenych dziadków
Cikich, rozbudowanych metod mierzenia i udoskonalania procesów jest wiele; wy-
mieniamy je poniej. Pozwalam sobie w odniesieniu do nich uywa zoliwego okre-
lenia rezerwat lenych dziadków ze wzgldu na ich skonno do odrywania nadbudowy
od bazy (samemu bdc niewtpliwym lenym dziadkiem, mam jak wida skonno
do uywania terminologii z minionych epok, nie tylko w informatyce). Cikie metody
postuluj budow i utrzymywanie ogromnego aparatu nadzorujcego, przez co wyma-
gaj znacznych zasobów i nakadów, a ich stosowanie w praktyce przedsiwzi in-
formatycznych powoduje due spowolnienie procesu i niech jego uczestników. Std
syndrom rezerwatu: ambitne, rozbudowane metodyki yj yciem niezalenym od
realiów projektów.
Przykady 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 imponujca i grona lista skrótowców — ze szczegóami oraz praktyk mona si
zapozna midzy innymi na spotkaniach sieci SPIN (Software Process Improvement
Network, www.spin-pl.org) w Gdasku, Krakowie, Szczecinie, Warszawie i we
Wrocawiu
5
.
Metametody lekkie: rezerwat modych wilków
Metody lekkie mona podsumowa — naraajc si na zarzut niejakiej przesady — jako
minimalizowanie wszelkich dziaa oprócz czysto konstrukcyjnych. Czyli w pewnym
stopniu nastpuje odwrócenie sytuacji: zamiast rezerwatu lenych dziadków mamy
rezerwat modych wilków, które — z bogosawiestwem swoich proroków — biuro-
kracji metod cikich przeciwstawiaj zorientowane na skuteczno konkretnego pro-
jektu podejcie na skróty. Przykady 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 dziaalno SPIN-ów zaktywizowaa si w Gdasku i w Krakowie, a osaba w innych
miastach (stan z sierpnia 2008 roku).
Rozdzia 4.
i Zarzdzanie procesami
137
Niedostatki rezerwatów
Saboci metod i modeli cikich s oczywiste: w wielu przypadkach ich zoono
i koszty postpowania wedug ich wskaza po prostu przewyszaj korzyci, tak jak
koszt instalacji linii robotów przemysowych w maomiasteczkowym warsztacie sa-
mochodowym.
Nawet jednak, jeli potencjalnie inwestycja w cik metodyk ma szanse si zwróci ,
to jej nieelastyczno , ignorowanie mechanizmów psychologicznych i spoecznych, za-
wio i oddalenie od konkretów, stanowi powan przeszkod w ich zastosowaniu.
Z drugiej strony, metody lekkie s na dobr spraw rezygnacj walkowerem z korzy-
ci gromadzenia i stosowania dobrych praktyk, z midzyprojektowego transferu wiedzy
i umiejtnoci, z systematyzacji i dyscypliny, które nie zawsze s tylko obcieniem.
Wyranie potrzebna jest trzecia droga — droga midzy biurokracj a chaosem.
ADP — nareszcie!
Zapoznajc si z metodyk, opisan przez Adama Kolaw i Dorot Huizinga w ich
majcej si ukaza we wrzeniu ksice Automated Defect Prevention: Best Practices
in Software Management [9], co chwila miaem ch zawoa „nareszcie!”. Nareszcie
pewne oczywiste prawdy, które a dziw, e nie zostay wyartykuowane wczeniej,
doczekay si opisania! Nareszcie mamy model procesu informatycznego, opisujcy
projektow rzeczywisto w miejsce hermetycznego, penego pobonych, acz niere-
alnych ycze wiata modeli cikich. Nareszcie otrzymujemy metodyk, która w spójn
jedno czy trzy zwykle obce sobie dotd wiaty:
skuteczne projektowanie oraz implementacj kodu;
pomiary, ocen oraz udoskonalanie procesów i procedur;
psychologi uczestników przedsiwzicia informatycznego.
A si prosi, aby metodzie ADP nada jak bardziej porywajc nazw, skoro przy-
chodzi jej konkurowa ze swoistym fundamentalizmem tradycyjnych — zarówno
lekkich, jak i cikich — metod. Czy istnieje korelacja midzy jakoci projektu a ja-
koci produktu oraz czy jest to zaleno przyczynowa? Wydaje si, e tej kluczowej
kwestii powinna by powicona wikszo prac dotyczcych procesów oraz ich udo-
skonalania, ale tak nie jest. Dominuje — zaiste przypominajce 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 zostay zarejestro-
wane i na ile metodzie wanie mona przypisa ich zaistnienie. Oto grony cytat: Zna-
komite wyniki oraz sama liczba znanych przedsibiorstw, które stosuj SixSigma, s
dowodem na to, e SixSigma nie jest przemijajc mod! Od telekomunikacji, poprzez
sektor finansowy, a po przedsibiorstwa zajmujce si technologiami informatycz-
nymi, wiele renomowanych firm zademonstrowao moc SxSigma w swoich organiza-
cjach [13].
138
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
Trudno o bardziej racy przykad mylenia fundamentalistycznego, mylcego rze-
czowe argumenty z pozorn si okrzyków pasujcych raczej do manifestacji ni do
naukowej czy inynierskiej debaty.
ADP od rodka
Patrzc na spis zagadnie poruszanych przez ADP, nie widzi si na pierwszy rzut oka
jej rewolucyjnego charakteru. Gówne rozdziay ksiki to „Planowanie oraz infra-
struktura”, „Specyfikacja i zarzdzanie wymaganiami”, „Projektowanie architektury
oraz projektowanie szczegóowe” i tak dalej a do „Testowania” i „Wdroenia”. Po-
zornie nihil novi sub sole.
Sia ADP tkwi jednak nie w efekciarskim stawianiu na gowie faktu, e informatyczne
przedsiwzicia skadaj si w rzeczywistoci 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 okrela swoje cele.
Zadowoleni ludzie
Dotd sprawy psychologii, ludzkiego zadowolenia, motywacji i kreatywnoci musiay
wdziera si do inynierii oprogramowania albo chykiem, w aurze lekkiego skandalu,
albo traktowane byy instrumentalnie jako dowody na wyszo metod lekkich: XP jest
odwieajcym, nowym podejciem. XP jest skuteczny, poniewa kadzie nacisk na
zaangaowanie klienta i promuje prac zespoow. A zatem jak by to miao dziaa?
Najbardziej zadziwiajcym aspektem XP jest prostota regu i procedur. Na pocztku
wydaj si niezrczne i naiwne, ale wkrótce staj si mile widzian odmian. Klienci
s zadowoleni z bycia partnerami w procesie programowania, a programici aktywnie
uczestnicz w tym procesie bez wzgldu na dowiadczenie [14].
Kto omieliby si postawi pytanie, czy wdroenie na przykad ITIL zwiksza rado
ycia zatrudnionych? Kto, z drugiej strony, sprzeciwiby si goosownemu — 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 zdoao wpisa czynnik ludzki w sam metod, nie tylko jako ozdobnik. Nie
mamy tu miejsca, aby opisa wiele, posu si wic dwoma znamiennymi cytatami:
osignicie równowagi pomidzy dyscyplin i kreatywnoci jest trudne oraz zarówno
nadmierna nuda, jak i nadmierny niepokój czyni ludzi mniej efektywnymi i bardziej
skonnymi do bdu.
Tym niekorzystnym tendencjom ma zapobiega waciwie, elastycznie stosowane ADP.
Rozdzia 4.
i Zarzdzanie procesami
139
Wysoka jako produktu
Ten podstawowy cel metodyk ginie czsto w nawale szczegóów samej metody. ADP
stawia go na drugim miejscu.
Organizacja: wysza produktywno
i sprawno w dziaaniu
Nareszcie nie chodzi o to, bymy si stali dojrzalsi (cho by kosztem skutecznoci
i sprawnoci), ani o to, bymy potrafili umieci etykietki na kadej procedurze i ka-
dym artefakcie naszej organizacji, tylko o produktywno i sprawno . Jak je osign ,
zaley od produktu, charakterystyki projektu, ludzkich kwalifikacji i preferencji, a ADP
uatwia ich okrelenie oraz pomiar stopnia realizacji. W tym sensie ADP jest nie tyle
metodyk, co metametodyk, nie recept, lecz „recept jak-wybra -wasciw-recept”,
od lat bezskutecznie poszukiwan przez praktyków.
Proces nadzorowany, udoskonalany
i dajcy si utrzyma
CMMI poziom 5 czy lepiej poziom 2? Formalne modelowanie wymaga czy niepre-
cyzyjny opis sowny? Nie ma na te pytania jedynej susznej odpowiedzi, natomiast
niezalenie od tego, jak brzmi w konkretnym przypadku, opaca si wiedzie , co ro-
bimy (proces nadzorowany), umie , jeli trzeba, poprawi procedury (proces udosko-
nalany) oraz zachowa zdolno do przestrzegania w rzeczywistoci tych praktyk, które
uznajemy za dla nas najlepsze (proces dajcy si utrzyma) — oto sens ADP.
Przedsiwzicie zarzdzane
poprzez podejmowanie decyzji
Podejmowanie decyzji, zarzdzanie zmianami i ryzykiem — to kolejny klucz do po-
wodzenia przedsiwzi informatycznych. Aby móc jednak podejmowa dobre decyzje,
niezbdna jest informacja, niezalenie od tego, czy proces decyzyjny jest sformalizo-
wany i racjonalny, czy intuicyjny i podwiadomy [16]. ADP kadzie nacisk na gro-
madzenie i analiz danych projektowych oraz na automatyzacj tego procesu.
Zapobieganie pomykom i bdom
Oprogramowanie jest substancj pozwalajc — inaczej ni kamie, stal czy drewno
— wzgldnie atwo usuwa defekty w zbudowanych z niej produktach nawet wtedy,
gdy produkt jest w peni ukoczony. Ta cenna waciwo ma jednak ogromnie
niekorzystne skutki uboczne, promuje bowiem mylenie krótkowzroczne, usuwa-
nie defektów zamiast ich przyczyn, co powoduje chroniczn zawodno produktów
140
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
informatycznych. ADP zaleca podejcie przeciwne: analiz przyczyn pomyek i b-
dów (ang. root cause analysis) oraz ich systematyczne usuwanie wsparte automatycz-
nymi narzdziami.
Zasady ADP
Znajomo podstawowych zasad ADP pozwala zrozumie skuteczno i prostot tej
metodyki.
Stworzenie infrastruktury jednoczcej ludzi i technologi. Metody takie jak
na przykad CMMI mówi wiele o tym, co naley zrobi , ale niewiele o tym,
jak: nie podaj szczegóowych wskazówek wspomagajcych przeoenie zacnych
zaoe w konkretn praktyk i projektowe korzyci. ADP przeciwnie — okrela,
jak za pomoc narzdzi uatwi i usprawni rzeczywiste wdroenie zalece.
Okrelenie i zastosowanie dobrych praktyk — to normatywna cz ADP,
a wic 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 dotyczce
implementacji kodu.
Dostosowanie dobrych praktyk — nie istnieje uniwersalny zbiór dobrych
praktyk; kada firma, dziedzina i projekt powinny ogólne dobre praktyki
modyfikowa i uzupenia , gromadzc wasne, szczególne dowiadczenia.
A wic model czy metod nie tyle si wdraa wedug z góry zaoonego
skryptu, co projektuje, buduje i wdraa jednoczenie.
Pomiary i monitorowanie statusu projektu — automatyczny system
gromadzenia i analizy stanu projektu pozwala zarówno na sprawne okrelenie
jego statusu, jak i na identyfikacj jego sabych stron i moliwych usprawnie.
Stosowanie tej zasady pozwala — posugujc si terminologi CMMI
— wdroy elementy poziomu pitego CMMI nawet w organizacjach
niespeniajcych wszystkich formalnych jego wymogów!
Automatyzacja — wemy do rki struktur dowolnego duego modelu,
na przykad COBIT; przecie niemoliwe, naraone na liczne pomyki
i poraajco — nie bójmy si tego sowa! — nudne byoby jego wdroenie
bez zakrojonej na szerok skal automatyzacji przestrzegania jego wytycznych!
ADP kadzie ogromny nacisk na automatyzacj procedur, przez co ich
przestrzeganie staje si moliwe bez naraania ludzi na konieczno uciliwego,
rcznego wprowadzania danych wymaganych przez procedury, odcia ich
od frustrujcych, rutynowych zada, ogranicza zagroenie pomykami.
Przyrostowe wdroenie praktyk ADP. To zupena nowo — dotd nawet
metodyki zalecajce przyrostowe tworzenie oprogramowania nie przewidyway
przyrostowego wdraania samych siebie! Istnieje szereg czynników
psychologicznych powodujcych opór przed zmianami. Liczne kursy
„mikkie” usiuj nas nauczy , jak z tym oporem sobie radzi rozmaitymi
psycho- i socjotechnikami, ale nikt jako dotd nie zaproponowa oczywistego
rozwizania (dobrze skdind znanego politykom podwyszajcym podatki)
— stopniowo i krok po kroku!
Rozdzia 4.
i Zarzdzanie procesami
141
Who is who
Adam Kolawa [10], zaoyciel w 1987 roku amerykaskiej firmy Parasoft [11], której
jest prezesem, oraz Dorota Huizinga [12], profesor informatyki na Uniwersytecie Ful-
lertona w Kalifornii, to osoby majce szczególne kompetencje do stworzenia nowego
paradygmatu — ADP.
ADP nie poleca adnych okrelonych narzdzi. Ksika zawiera obszern list narzdzi,
zarówno komercyjnych, ogólnodostpnych i open-source, mogcych znale zastoso-
wanie we wdraaniu metodyki.
Wicej danych na temat wydarze, usug i szkole na temat ADP mona znale
w Internecie
6
.
Referencje
[1] http://en.wikipedia.org/wiki/Software_engineering
[2] http://en.wikipedia.org/wiki/List_of_publications_in_computer_science#Software_
engineering:_Report_of_a_conference_sponsored_by_the_NATO_Science_
Committee
[3] http://en.wikipedia.org/wiki/Dynamic_linking#Dynamic_linking
[4] http://en.wikipedia.org/wiki/Corba
[5] http://en.wikipedia.org/wiki/Command_line_interface
[6] http://en.wikipedia.org/wiki/History_of_the_graphical_user_interface
[7] http://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction
[8] http://en.wikipedia.org/wiki/Agile_software_development
[9] http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html
[10] http://www.socaltech.com/fullstory/0000180.html
[11] http://en.wikipedia.org/wiki/Parasoft
[12] http://dorota.ecs.fullerton.edu/
[13] http://www.motorola.com/content.jsp?globalObjectId=3081
6
Rok po napisaniu tego artykuu powstaa ADPQB — ADP Qualifications Board. Adres: www.adpqb.org.
142
Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom
[14] http://www.ccsr.cse.dmu.ac.uk/conferences/ccsrconf/ethicomp2001/abstracts/
bogdan.html
[15] http://www.devx.com/opinion/Article/26776/0
[16] http://www.bettersoftware.eu/white_papers/dobre_decyzje_0.4.pdf
[17] http://www.bettersoftware.eu/adp.html
Wyszukiwarka
Podobne podstrony:
Inzynieria Oprogramowania str 2 Nieznany
Inzynieria Oprogramowania str 1 Nieznany
informatyka inzynieria oprogramowania jak zapewnic jakosc tworzonym aplikacjom bogdan bereza jarocin
,Inzynieria oprogramowania L, o Nieznany
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
ZadanieNaZaliczenie, WAT, semestr IV, Inżynieria oprogramowania
Rafał Polak 12k2 lab8, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
zagadnienia egzaminacyjne z przedmiotu inżynieria oprogramowania zIO
Inżynieria oprogramowania Diagramy ERD
Inzynieria wyklad wprowadzajacy Nieznany
2006 06 Wstęp do Scrum [Inzynieria Oprogramowania]
więcej podobnych podstron