In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf ·...

33
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!

Transcript of In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf ·...

Page 1: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

In¿ynieria oprogramowania.Jak zapewniæ jakoœætworzonym aplikacjomAutorzy: Bogdan Bereza-Jarociñski, Boles³aw Szomañski ISBN: 978-83-246-1948-1Format: 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!

Page 2: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Spis tre�ciRozdzia� 1. Rozwa�ania wst�pne ...................................................................... 13

1.1. Nietypowa ksi��ka: o jako�ci na weso�o ............................................................... 131.2. Jako� integralna .................................................................................................. 131.3. Jako� przedsi�wzi� ............................................................................................ 14

Przyk�ad ........................................................................................................... 15Zarz�dzanie projektami ................................................................................... 15Zarz�dzanie procesami .................................................................................... 15Zarz�dzanie celami biznesowymi .................................................................... 15Zarz�dzanie jako�ci� ........................................................................................ 16

1.4. Podejmowanie decyzji i zarz�dzanie ryzykiem .................................................... 17Podejmowanie decyzji i zarz�dzanie ryzykiem,

czyli wykorzystanie intuicji i racjonalno�ci .................................................. 17Brakuje jednak podej�cia integralnego ............................................................ 17Intuicji trzeba da szans�! ................................................................................ 18Mo�na si� nauczy, jak wykorzystywa w praktyce najlepsze �rodki

z dwojga �wiatów .......................................................................................... 181.5. Zintegrowane zarz�dzanie celami biznesowymi ................................................... 19

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

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

Rozdzia� 2. Dialektyka jako�ci .......................................................................... 252.1. Dlaczego jako� si� op�aca? ................................................................................. 252.2. Komu bije jako�? ................................................................................................ 26

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

Page 3: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

6 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

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

Rozdzia� 3. Jako�� wczoraj, dzisiaj i jutro ......................................................... 753.1. Historia podej�cia do jako�ci (od Hammurabiego do Gatesa) .............................. 75

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

Page 4: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Spis tre�ci 7

3.2. P�dzi parowóz historii: 20 lat przemian w informatyce ........................................ 94Od sierpa i m�ota do Internetu ......................................................................... 95Powolne zwyci�stwo u�yteczno�ci .................................................................. 96Szybciej, wi�cej, dalej ..................................................................................... 97Jako� szyta na miar� ...................................................................................... 98Samoobs�uga .................................................................................................... 99

3.3. W kryszta�owej kuli: in�ynieria oprogramowania za 10 lat ................................ 100Typowe b��dy przewidywania ....................................................................... 100Szybko i intuicyjnie ....................................................................................... 102Programowanie intencjonalne ........................................................................ 102Testowanie eksploracyjne .............................................................................. 103Spirale, iteracje, przyrost ............................................................................... 103

3.4. Szybko, zwinnie, ekstremalnie ........................................................................... 104J�zyki programowania ................................................................................... 104Architektury komponentowe ......................................................................... 105Sztuczna inteligencja i programy samoucz�ce si� ......................................... 105Podsumowanie: si�a czy inteligencja? ........................................................... 106

3.5. Drogowskaz do przysz�o�ci — m�dro� b�dzie na serwerach, czyli ASP .......... 106Babcia nie potrzebuje komputera ................................................................... 108Czego potrzebuje babcia autora? ................................................................... 109Szczegó�y rozwi�zania dla babci ................................................................... 109Z czym nam si� to kojarzy? ........................................................................... 112Kontrowersje ................................................................................................. 113Jeszcze troch� recenzji — walka ze spamem ................................................. 113Moc j�zyków ................................................................................................. 114Zako�czenie ................................................................................................... 115

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

Rozdzia� 4. Zarz�dzanie procesami ................................................................. 1194.1. Zarz�dzanie jako�ci� — w�adza i zgie�k ............................................................. 119

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

4.2. Znowu ten po�piech — jak szybko oceni jako� aplikacji? .............................. 125Po�piech w informatyce ................................................................................. 125Pomiary w po�piechu ..................................................................................... 126Precz z grzybami ........................................................................................... 127Grzybobranie ................................................................................................. 127Testowanie uwzgl�dniaj�ce ryzyko ............................................................... 129Jakie to �atwe... .............................................................................................. 129Bilet do Davos ............................................................................................... 130Jak spieszy si� powoli .................................................................................. 130

4.3. Po co mierzy? Miary w in�ynierii oprogramowania ......................................... 131Czego nie mo�na zmierzy, tego si� nie wie ................................................. 132Ksi��ka .......................................................................................................... 133

4.4. Mi�dzy biurokracj� a chaosem: ADP .................................................................... 134K�opot ............................................................................................................ 134Akcja i kontrakcja .......................................................................................... 135Metametody ci��kie: rezerwat le�nych dziadków .......................................... 136

Page 5: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

8 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

Rozdzia� 5. Socjologia i antropologia jako�ci .................................................. 1435.1. In�ynier jako�ci — to nie brzmi dumnie ............................................................. 143

Kariera testera ................................................................................................ 1445.2. Samotno� testera: organizacje i konferencje ..................................................... 144

Szkolenia i certyfikaty ................................................................................... 1455.3. Psychologia projektu .......................................................................................... 146

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

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

5.5. Psychologia jako�ci ............................................................................................ 172Psychologia i socjologia testowania .............................................................. 172Status tego rozdzia�u ...................................................................................... 172Dysonans poznawczy .................................................................................... 172Psychologia testowania .................................................................................. 172Praca konstruktywna i motywacja ................................................................. 173Bezpiecze�stwo, niepokój ............................................................................. 174Przegl�dy ....................................................................................................... 174Dynamika grupowa ........................................................................................ 175Studium komunikacji ..................................................................................... 175Hierarchia potrzeb wg Maslova ..................................................................... 176

Page 6: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Spis tre�ci 9

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

5.6. Czy warto si� SPIN-a? ...................................................................................... 178Organizacje zajmuj�ce si� jako�ci� w Polsce ................................................ 178Gdzie jest Forum Romanum? ........................................................................ 179Quo vadis, udoskonalanie procesów? ............................................................ 180

5.7. W poszukiwaniu idealnych pracowników i szefów ............................................ 181Jacy s� ludzie? ............................................................................................... 181Mierzenie ludzi .............................................................................................. 182THOMAS INTERNATIONAL ..................................................................... 184Zastosowanie THOMAS-a w praktyce .......................................................... 186Autystyczni testerzy ...................................................................................... 187

Rozdzia� 6. Interakcja, u�yteczno��, wygoda .................................................. 1916.1. Inwazja szale�ców .............................................................................................. 1916.2. Jak ulepszy �wiat? ............................................................................................. 193

Frustracja, poni�enie, agresja ......................................................................... 193Szale�cy rz�dz� domem wariatów ................................................................. 194Sze� grzechów g�ównych ............................................................................. 194Nie�wi�te przymierze .................................................................................... 195Pomoc nadci�ga ............................................................................................. 196

6.3. Psychologiczne podstawy u�yteczno�ci .............................................................. 196Stan obecny ................................................................................................... 196Lista kontrolna niektórych czynników u�yteczno�ci ..................................... 197

Rozdzia� 7. �ycie towarzyskie i uczuciowe ...................................................... 2017.1. Adwentowa gwiazda 2003 .................................................................................. 201

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

7.2. Kupuj�c wiedz�: przewodnik po szkoleniach ..................................................... 205Motto ............................................................................................................. 205Podstawy ....................................................................................................... 205Pi� z�otych zasad, jak znale� szkolenie testowe ......................................... 206

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

Page 7: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

10 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

SW Testing Practitioner Certificate ............................................................. 2277.5. ISTQB: certyfikaty mi�dzynarodowe .................................................................... 2287.6. To po prostu bzdura! ........................................................................................... 229

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

Rozdzia� 8. Metody i techniki ......................................................................... 2378.1. Sztuka, rzemios�o, nauka .................................................................................... 237

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

8.2. Szlachetna sztuka testowania oprogramowania .................................................. 241Nowa ksi��ka ................................................................................................. 241Klasyka od�wie�ona ...................................................................................... 242Nazewnictwo ................................................................................................. 243

8.3. eby banki ros�y w si��, a klienci �yli dostatniej ................................................ 244Praca �mudna, mozolna, ale za to jaka ja�owa! ............................................. 244Kontrola instalacji wodnej pod ci�nieniem .................................................... 245Poci�gi pod specjalnym nadzorem ................................................................. 246Szukanie dziury w ca�ym ............................................................................... 246Czego u�ytkownik nie lubi najbardziej? ........................................................ 247Jako� jest za darmo ...................................................................................... 247

8.4. Kra�cowo zwinne eksploracyjne piramidy ......................................................... 247Historia polityczna ......................................................................................... 247Ostrze�enie .................................................................................................... 248Nowa religia .................................................................................................. 249Zastosowanie eksploracji ............................................................................... 251

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

Page 8: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Spis tre�ci 11

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

Rozdzia� 9. Warsztat fachowca ....................................................................... 2599.1. Automatyzacja testów ......................................................................................... 259

Co to jest automatyzacja testowania? ............................................................ 260Co znajduje si� w skrzynce ze z�otem: po�ytki z automatyzacji .................... 260Gdzie rozmieszczone s� miny: niebezpiecze�stwa automatyzacji ................. 261Na zako�czenie .............................................................................................. 264

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

Rozdzia� 10. Bezpieczestwo informacji ............................................................ 27310.1. Bezpiecze�stwo informacji: historia i stan obecny ............................................. 273

Wprowadzenie — bezpiecze�stwo informacji dawniej ................................. 273Ochrona fizyczna i konstruowanie niezawodnego sprz�tu ............................ 276Zapewnienie jako�ci oprogramowania ........................................................... 277Zapewnienie bezpiecze�stwa oprogramowania ............................................. 278Zapewnienie bezpiecze�stwa systemów informatycznych ............................ 281Zarz�dzanie bezpiecze�stwem informacji ..................................................... 283Systemy zarz�dzania bezpiecze�stwem

informacji wed�ug norm ISO serii 27000 .................................................... 284Próba przewidywania przysz�o�ci .................................................................. 290Bibliografia .................................................................................................... 292

10.2. Walka z cieniem — zabezpieczenia i odporno� w praktyce .................................. 295Streszczenie ................................................................................................... 295Co to jest „bezpiecze�stwo”? ........................................................................ 295Definicje bezpiecze�stwa .............................................................................. 296Gdzie szuka b��dów zabezpieczenia? .......................................................... 297Testowanie zabezpiecze� ............................................................................... 298Ile testowa zabezpieczenia? ......................................................................... 298Wra�liwe cz��ci cia�a smoka ......................................................................... 299U�yteczno� ................................................................................................... 300Wykonanie ..................................................................................................... 301Aspekty organizacyjne ................................................................................... 301Proces testowania bezpiecze�stwa ................................................................. 302Monitoring w trakcie dzia�ania operacyjnego ................................................ 303Bibliografia .................................................................................................... 304Organizacje, firmy, us�ugi i normy ................................................................ 305Narz�dzia ....................................................................................................... 305

Page 9: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

12 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

10.3. Bezpiecze�stwo — praca u podstaw ................................................................... 306Du�o ha�asu o bezpiecze�stwo ...................................................................... 306Bezpiecze�stwo wielopoziomowe ................................................................. 306Trzy �wiaty bezpiecze�stwa .......................................................................... 307Normy, audyt, standardy ................................................................................ 307Policjanci ....................................................................................................... 307Testy penetracyjne ......................................................................................... 308Praca u podstaw ............................................................................................. 308In�ynieria wymaga� bezpiecze�stwa ............................................................. 308Mo�liwo�ci analizy statycznej ....................................................................... 309B��dy na poziomie kodowania: testy jednostkowe ........................................ 310Bezpiecze�stwo czy bezpiecze�stwo? ........................................................... 310Profits, stupid! ............................................................................................... 311Leczy czy zapobiega? ................................................................................ 312Praca �mudna, mozolna, za to — jaka ja�owa! .............................................. 312

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

Page 10: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4.

Zarz�dzanie procesami

4.1. Zarz�dzanie jako�ci�— w�adza i zgie�k

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

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

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

Jak opanowa� stado bezg�owych kur,czyli zarz�dzanie konfiguracj�

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

Page 11: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

120 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

numer czterna�cie feralnego modu�u. Tester poci si� i ��czy program ponownie, tymrazem z najnowsz� wersj�. Awaria nie pojawia si� wi�cej: dobrze. Niestety, po dwóchtygodniach powraca! Co si� sta�o? Po pó� dnia dochodze� udaje si� ustali, �e nowozatrudniony programista przez pomy�k�, ��cz�c program, znowu pos�u�y� si� star� wer-sj� feralnego modu�u…

Brzmi to znajomo? Oczywi�cie. Mamy tu do czynienia z klasycznymi symptomaminiedostatków zarz�dzania konfiguracj�.

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

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

Rozmawia�a g�� z prosi�ciem:raporty i �ledzenie b��dów

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

Ani w jednym, ani w drugim przypadku nie wystarczy, by ta wiedza pozosta�a w g�owietestera. Trzeba j� przekaza programi�cie, aby rozpocz�� poszukiwania przyczynyawarii, oraz kierownikowi projektu, aby móg� sporz�dzi statystyki b��dów i oszacowabie��c� jako� konstruowanego systemu. Nawet je�li projekt jest jednoosobowy, niezawsze daje si� wszystko zapami�ta i prowadzenie notatek na temat znajdowanychi usuwanych b��dów pozwala na unikni�cie pomy�ek.

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

Page 12: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 121

Niektóre traktuj�ce o testowaniu �ród�a (m.in. t�umaczona na j�zyk polski ksi��kaameryka�skiego autora Rona Pattona Testowanie oprogramowania1) po�wi�caj� wielemiejsca udzielaniu rad, jak powinien post�powa tester, aby dopilnowa, �eby znale-ziony b��d rzeczywi�cie zosta� potraktowany powa�nie i naprawiony. Takie podej�ciewydaje si� by stawianiem sprawy na g�owie. Po pierwsze, tester ma inne zaj�cia ni�zast�powanie — niefrasobliwego wida — kierownika projektu i �ciganie programistów.Po drugie, taka sytuacja stwarza realne zagro�enie sprowokowania konfliktów mi�dzytesterami a konstruktorami. Po trzecie wreszcie, tester nie musi mie i zwykle nie mape�nej wiedzy potrzebnej do prawid�owej oceny wagi znalezionego b��du. Do tegokonieczna jest — zale�nie od rodzaju b��du — jeszcze wiedza na temat struktury i prio-rytetów wymaga�, potrzeb klienta, architektury systemu. Nie jest wcale oczywiste, �eka�da awaria wymaga natychmiastowego rzucenia wszystkich dost�pnych �rodkóww celu jej rozbrojenia i usuni�cia! To zale�y mi�dzy innymi od zwi�zanego z ni� ryzyka.Do oszacowania ryzyka nie wystarczy zwykle jedna osoba: konieczna jest wspó�pracawielu uczestników projektu, któr� umo�liwiaj� w�a�ciwie wykorzystane raporty b��dów.

Zorganizowanie procedur zg�aszania i �ledzenia b��dów jest jednym z podstawowychzada� 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 najwi�ksze szanse poradzenia sobie z (niezaplanowan�) sytuacj� na polubitwy.

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

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

1 Nak�ad obecnie wyczerpany — wrzesie� 2008.

Page 13: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

122 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

Husaria kontra pruska piechota:jak nie straci� impetu, nie trac�c g�owy?

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

czas testowania(znormalizowany)

skumulowana liczbawykonanych zada�

testowych

zaplanowanafaktyczna

trudno�ci, spi�trzenieb��dów

naprawianie b��dówi testy regresji

nadrabianie start

szcz��liwy koniec

Rysunek 4.1.1. �ledzenie procesu przebiegu testów

Dostrzeg�szy niebezpieczne, narastaj�ce rozbie�no�ci mi�dzy planem a rzeczywisto-�ci�, kierownik testów ma do dyspozycji pi� typów �rodków zaradczych:

� Zmiana harmonogramu testów — odroczenie zako�czenia i terminu dostawydo klienta.

� Zmiana kryteriów jako�ci — obni�enie poprzeczki, dopuszczenie do u�ytku systemumniej przetestowanego albo maj�cego wi�ksz� ilo� nierozwi�zanych b��dów.

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

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

� Podniesienie wymaganej jako�ci dostaw do testu systemowego — to umo�liwisprawniejsze testowanie i przerzuci cz�� dzia�a� na ni�sze poziomy(testy komponentów, integracyjne).

� Ponadto cz�sto stosowanym �rodkiem jest — kiedy gwa�townie narasta ilo�zarejestrowanych zg�osze� b��dów — czasowe zawieszenie wykonywanianowych testów po to, by da programistom szans� na usuni�cie spi�trzenia

Page 14: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 123

i naprawienie jak najwi�kszej liczby b��dów. W tym czasie zespó� testowypo�wi�ca si� wy��cznie testowaniu powtarzalnemu dostaw zawieraj�cychkolejne poprawki.

Krajobraz po bitwie:czy mo�na wypu�ci� produkt ju� jutro?

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

Nie znaczy to jednak, �e testowa trzeba w niesko�czono�, bo z drugiej strony czaisi� przecie� ryzyko opó�nienia, kar umownych, niezadowolonych klientów, utratyudzia�ów w rynku na rzecz szybszych czy odwa�niejszych konkurentów. Analiza ry-zyka i podj�cie decyzji jest w 100% zadaniem dla kierownictwa lub sponsorów pro-jektu, ewentualnie dla dzia�u marketingu. Test ma natomiast za zadanie dostarczydecydentom jak najprecyzyjniejsze dane dotycz�ce ryzyka technicznego w oparciuo dotychczasowe wyniki testowania.

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

czas testowania(znormalizowany)

skumulowana liczbawykonanych zada�

testowych

zaplanowanafaktyczna

trudno�ci, spi�trzenieb��dów

naprawianie b��dówi testy regresji

nadrabianie start

szcz��liwy koniec

Rysunek 4.1.2. Szacowanie liczby pozosta�ych defektów

Oczywi�cie istotno� takich oszacowa� zale�y od liczby oraz jako�ci wykonanych te-stów. Do ich oceny s�u�� rozmaite miary pokrycia (np. wymaga�, funkcji, kodu).

Page 15: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

124 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

Obdzieranie poleg�ych,czyli jak by� m�drym po szkodzie

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

Bogatym �ród�em wiadomo�ci jest baza danych z raportami b��dów. Mo�na na przy-k�ad szczegó�owo zanalizowa pewn� liczb� losowo wybranych raportów i spróbowaodpowiedzie na pytanie, jaka by�a pierwsza przyczyna zaistnienia danego b��du? Czyby�y ni� niejasno sformu�owane wymagania, czy niedostateczna znajomo� j�zyka przezprogramistów, czy niedoci�gni�cia organizacyjne?

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

Ró�ne formy organizacji testowaniaNie zawsze jedyn� i najlepsz� form� organizacji testów jest stworzenie osobnego zespo�utestowego. Zale�nie od charakteru projektu, typu produktu, przyj�tej metodyki wytwa-rzania korzystne mo�e okaza si� zastosowanie innych rozwi�za� organizacyjnych.� Programi�ci sami testuj� w�asny kod. Metoda cz�sto stosowana w testach

modu�owych (jednostkowych, komponentów). Jej wady s� oczywiste.� Testowanie kole�e�skie (ang. buddy testing): programi�ci nawzajem testuj�

swój kod. Stosowane mi�dzy innymi w popularnym ostatnio „ProgramowaniuEkstremalnym” (XP, Extreme Programming).

� Tester (lub testerzy) s� cz�onkami zespo�u programistów, podlegaj� kierownikowizespo�u lub projektu.

� Osobny zespó� testuj�cy maj�cy w�asnego kierownika.� Osobny dzia� w przedsi�biorstwie zajmuj�cy si� pewnymi rodzajami testów.� Outsourcing testów do innego przedsi�biorstwa: stosowane wówczas, gdy

wymagana jest niezale�na certyfikacja systemu oraz gdy niezb�dne jestskomplikowane i kosztowne �rodowisko testowe (np. w testowaniu konfiguracji,testowaniu zgodno�ci z wymaganiami �rodowiskowymi itp.).

� Wybór w�a�ciwej organizacji testowania jest wa�nym zadaniem dla kierownikaprojektu. Warto pami�ta, �e w wi�kszych projektach kilka ró�nych formorganizacyjnych mo�e istnie jednocze�nie, na przyk�ad testowanie kole�e�skiena poziomie testów komponentów, odr�bny zespó� do testu systemowego,outsourcing w celu uzyskania niezale�nej certyfikacji.

Page 16: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 125

Kiedy zaczyna�, kiedy skoczy�?

Jak zwykle bywa — dobrze wiemy. Jak powinno by — zwi��le opisuje rysunek 4.1.3.Czynno�ci wykonywane przez zespó� testowy napisane s� t�ustym drukiem na jasno-szarym tle.

Specyfikacja wymaga�

Specyfikacja konstrukcji

Kodowanie Testy komponentów

Testy integracyjne

Test systemu

Test akceptacyjnyWalidacja wymaga�

Testowalno�� wymaga� Przegl�d

Przegl�d

Przygotowanie testów

Przygotowanie testów

Testowanie

Rysunek 4.1.3. Przegl�d modelu „V”

4.2. Znowu ten po�piech — jak szybkooceni� jako�� aplikacji?

Po�piech w informatyce

Zrobi cokolwiek szybko? Znowu ten po�piech. Znane jest przecie� porzekad�o: „conagle, to po diable” i niezliczone przyk�ady sytuacji, kiedy zabrak�o czasu i �rodków,aby co� wykona dobrze, ale znalaz�o si� potem i jedno, i drugie, aby to co� wielo-krotnie poprawia. Informatyka to bran�a cierpi�ca od swego powstania na syndromczarodziejskiej plasteliny. Kilkadziesi�t lat temu uda�o si� ludziom spe�ni swe odwiecznemarzenie 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 wbudowanyuk�ad steruj�cy do pralki automatycznej. Figurki lepione z naszej czarodziejskiej pla-steliny — instrukcji mikroprocesora — rzeczywi�cie mo�na tworzy zadziwiaj�co szybkow porównaniu z przedmiotami z drewna, metalu czy betonu, a ponadto mo�na je po-tem wzgl�dnie �atwo poprawia bez potrzeby burzenia ca�o�ci, je�li co� si� nie ca�-kiem uda. Ludzikowi z plasteliny mo�na nawet, kiedy ju� jest gotowy, oderwa nog�i zast�pi j� inn�, lepsz�, ale te� wygl�da on potem jak… ludzik z plasteliny.

Page 17: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

126 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

Mi�o jest sobie pozrz�dzi, ale z drugiej strony nie mo�na zaprzeczy, �e to dzi�kisystemom informatycznym dzisiejszy �wiat ogromnie przewy�sza ten sprzed lattrzydziestu i czterdziestu pod wzgl�dem mo�liwo�ci, dobrobytu, bezpiecze�stwa i or-ganizacji, cokolwiek na ten temat s�dz� rozmaici zwolennicy powrotu do jaski� czywr�cz na drzewa.

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

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

Pomiary w po�piechu

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

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

Page 18: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 127

mierzy przebyt� odleg�o�, kierunek, nachylenie terenu. W przemy�le informatycznymch�tnie udajemy kierowców Formu�y 1 oraz dzielnych przewodników, nie maj�c nie-zb�dnych po temu umiej�tno�ci mierzenia.

Brak umiej�tno�ci sprawnego mierzenia uniemo�liwia zarz�dzanie ryzykiem, zast�-puj�c je unikaniem ryzyka — lub bezsensown� brawur�. Unikanie ryzyka w in�ynieriioprogramowania rodzi projekty sztywne, zbiurokratyzowane, nieskuteczne, omijaj�cew�a�ciwe wyzwania. Bezsensowna brawura oznacza fanfaronad� przy wyznaczaniu ce-lów, �rodków i terminów, po czym… To, co zdarza si� potem, tak�e mo�na oczywi-�cie zmierzy. Odpowiedni� miar�, nie do ko�ca jeszcze uznan� przez fizyków, jest„och-nie-sekunda” (ang. oh-no-second), stosowana do okre�lenia czasu up�ywaj�cegood chwili, gdy si� zorientowali�my, �e pope�nili�my NAPRAWD� DUY B �D(np. klikaj�c „wy�lij do wszystkich” na koniec maila pe�nego wspomnie� z bardzogor�cej nocy).

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

Precz z grzybami

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

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

Grzybobranie

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

Page 19: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

128 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

Dobry grzybiarz szuka grzybów tam, gdzie spodziewa si� je znale�. Wykorzystuj�csobie tylko znane intuicje, wie gdzie zwykle rosn� ko�laki, gdzie rydze, a gdzie opie�ki,dzi�ki czemu przynosi ich pe�ne kosze. Tak samo do�wiadczony tester wykorzystujeswe wcze�niejsze do�wiadczenia, aby szuka b��dy ocenianej aplikacji tam, gdzie spo-dziewa si� je znale�. Jak rydze lubi� rosn� pod �wierkami, tak b��dy lubi� si� naprzyk�ad gromadzi w pobli�u warto�ci kra�cowych, na granicach przedzia�ów, i do-bry tester tam w�a�nie b�dzie ich szuka�. Dalej, b��dy ch�tnie dojrzewaj� w miejscachodludnych, których nikt od dawna nie testowa�, bo kod jest tak zawi�y, �e lepiej gonie rusza. Wiemy te�, �e obecno� kilku b��dów zwykle oznacza, �e jest ich tamo wiele wi�cej — wynikaj� bowiem z tych samych b��dów projektowania. Kolejn�regu�� streszcza powiedzenie „gdzie kucharek sze�…” — je�li kod by� wielokrotniezmieniany, je�li modyfikowa�o go wielu programistów — warto poszuka b��dów.Zasad jest wiele, a profesjonalni testerzy powinni je zna.

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

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

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

W �rodku lasu jest ostaniec — pionowa, kilkunastometrowa ska�a. Mo�e na jej szczyciete� rosn� jakie� grzyby, a który� z cz�onków Komisji uprawia sporty ekstremalne i tamsi� wdrapie? Mo�e, ale z drugiej strony, spenetrowanie wierzcho�ka ska�y wymaga�oby

Page 20: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 129

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

St�d wyp�ywa kolejny wniosek dla oceniania jako�ci aplikacji — je�li mamy ograniczonezasoby, a s�owo „szybko” oznacza, �e brakuje nam najcenniejszego z nich, czyli czasu— trzeba uwzgl�dni, na ile trudne i kosztowne s� pewne testy, tak �eby dost�pne �rodkirozdysponowa raczej równomiernie, a nie tylko w jednym, szczególnie zasoboch�onnymobszarze.

Testowanie uwzgl�dniaj�ce ryzyko

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

� Prawdopodobiestwo b��du — szkoda czasu, aby szuka b��dów tam,gdzie by mo�e ich nie ma.

� Konsekwencje awarii — przy ocenie jako�ci nale�y szuka raczej awariikatastrofalnych ni� niegro�nych, kosmetycznych.

� Prawdopodobiestwo zastosowania — trafniej ocenimy jako�, bior�c poduwag� przede wszystkim to, czym u�ytkownicy pos�uguj� 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 wik�ania si�w próby oceny tego, czego pomiar jest zbyt kosztowny i czasoch�onny.

Jakie to �atwe...

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

Page 21: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

130 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

Bilet do Davos

Ca�e kosze usuni�tych z lasu grzybów wywieziono daleko — czy mo�na spokojnieoczekiwa inspekcji? Czy mo�e mimo wszystko lepiej zarezerwowa dla siebie i ro-dziny miejsca w samolocie do Szwajcarii i skromny apartament w Davos, na wypadekgdyby Nadzwyczajna Komisja jaki� du�y grzyb jednak wykry�a?

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

W odniesieniu do oceny jako�ci aplikacji odpowiednikiem mapy jest model dzia�anialub struktury aplikacji, a odpowiednikiem dzielenia mapy na kwadraty — projekto-wanie testów z modelu za pomoc� algorytmu. To jest konieczne, aby móc oceni takzwane pokrycie testowe, a wi�c oszacowa niezawodno� wykonanych ocen, ale na toprzy ocenie szybkiej nie mamy zwykle czasu. Jedno jest wi�c pewne — ocena szybkajest zawsze mniej pewna ni� ocena spokojna, oczywi�cie pod warunkiem staranno�cijednakowej w obu przypadkach.

Jak spieszy� si� powoli

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

Pogodzi po�piech ze spokojn� systematyczno�ci� usi�uj� metodyki „systematycznegotestowania w po�piechu” (tak celnie okre�li� je dr Lucjan Stapp z Politechniki Warszaw-skiej w swym wyst�pieniu na jednym z zebra� Stowarzyszenia Jako�ci SystemówInformatycznych).

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

Page 22: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 131

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

Kilka lat temu g�o�no by�o o metodyce programowania ekstremalnego (ang. extremeprogramming), gdzie programi�ci pracuj� w parach, zamieniaj�c si� pisaniem kodui przygotowywaniem (automatycznych) testów dla tworzonego w�a�nie kodu. Progra-mowanie ekstremalne postuluje ponadto ograniczenie do minimum tradycyjnej, ci��-kiej dokumentacji, blisk� wspó�prac� programistów z przedstawicielami klienta, cz�ste— nawet kilka razy na dzie� — budowanie ca�ego systemu. Z jednej strony progra-mowanie ekstremalne obiecuje wprawdzie ni�sz� czasoch�onno� projektów, czym pasujedo naszego tematu; z drugiej strony — postuluje przygotowywanie testów oceniaj�-cych jako�, jeszcze zanim powstanie kod, co nie do ko�ca ju� zgadza si� z paradyg-matem „szybkiej oceny jako�ci aplikacji”.

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

4.3. Po co mierzy�?Miary w in�ynierii oprogramowania

Miary cz�sto 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 obiecuj�co, jak w s�owie bezmierny.

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

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

2 Józef Flawiusz, Staro�ytno�ci �ydowskie, I.2.2, wyd. polskie: Warszawa 1962, s. 105 — cytat wg prezentacji

Andrzeja Kobyli�skiego na Konferencji SJSI, Serock, maj 2005.

Page 23: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

132 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

Czego nie mo�na zmierzy�, tego si� nie wie

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

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

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

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

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

Page 24: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 133

Jak nauczy si� trudnej sztuki wykonywania pomiarów i analizy ich wyników? Jak nieda si� w przysz�o�ci zagada elokwentnym zwolennikom Jedynie S�usznej Drogi, czyb�dzie ni� czysty Brak Procedur, czy ISO 9000, czy CMM, czy cokolwiek innego, tylkodoj� samodzielnie do w�asnych wniosków, wybiera to, co rzeczywi�cie najlepsze dlanas i naszych firm?

Doskona�ym, praktycznym przewodnikiem jest wydana pod koniec ubieg�ego rokuksi��ka3 dr. Andrzeja Kobyli�skiego z SGH pod niezbyt chwytliwym marketingowotytu�em Modele jako�ci produktów i procesów programowych. Nazwa�bym j� ch�tniejInformatyk mierzy.

Ksi��ka

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

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

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

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

3 Andrzej Kobyli�ski Modele jako�ci produktów i procesów programowych, Szko�a G�ówna Handlowa

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

Page 25: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

134 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

Rysunek 4.3.1.Koszty zmiany w czasie

SKUTECZNO��I SPRAWNO��

CZAS

Stan pocz�tkowy

Analiza zmiany

Wdra�anie zmiany

Sukces

Niepowo-dzenie

Kl�ska

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

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

Cz�� czwarta ksi��ki po�wi�cona jest temu w�a�nie zagadnieniu uj�temu w unikalny,w�asny sposób autora.

Podsumowuj�c — ksi��ka Andrzeja Kobyli�skiego to pozycja, któr� ka�dy mened�erfirmy czy kierownik projektu informatycznego b�dzie czyta z du�ym zainteresowaniem,a nale�y j� tak�e poleci in�ynierom jako�ci oraz in�ynierom testów. Bo przecie�, �ebymówi o jako�ci, trzeba j� umie mierzy, test jest za� podstawowym sposobem pomiaru!

4.4. Mi�dzy biurokracj� a chaosem: ADP

K�opot

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

Page 26: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 135

Podobnie, cho nie a� tak �le, wygl�da�o tworzenie oprogramowania w pierwszychdwóch dekadach istnienia komputerów. Przedsi�wzi�cia informatyczne (ang. projects)by�y chaotyczne i nieplanowe, nie stosowano systematycznej in�ynierii wymaga� (ang.requirements engineering), kod tworzono bez uprzedniego projektowania (ang. design),wi�c produkt ko�cowy zwykle nie mia� trafnej funkcjonalno�ci, nie by� wygodnyw u�ytkowaniu ani �atwy w utrzymaniu.

W roku 1968 podczas konferencji in�ynierii oprogramowania NATO (NATO SoftwareEngineering Conference) termin in�ynieria oprogramowania po raz pierwszy pojawi�si� oficjalnie [1]. Doczeka�o si� uznania twierdzenie, �e tworzenie oprogramowaniato co� wi�cej ni� zgodne z regu�ami j�zyka programowania stawianie szeregu instrukcji;�e istniej� systematyczne, zdyscyplinowane i mierzalne metody wykonywania tegoprocesu.

Wkrótce — 7 pa�dziernika 2008 r. [2] — przyjdzie nam zatem obchodzi 40. rocznic�tego wydarzenia4. Gdzie in�ynieria oprogramowania znajduje si� dzisiaj?

Akcja i kontrakcjaNa poziomie kodowania (implementacji) i cz��ciowo tak�e projektowania zasz�y ogromnezmiany. Od paradygmatu GOTO, przez metody strukturalne, przez nieudane próby j�-zyków 4. generacji, przemys� informatyczny wszed� w er� metod i j�zyków obiektowych.

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

Mniej radykalne przemiany zachodzi�y na wy�szych poziomach procesu: projektowa-nia architektury, in�ynierii wymaga� oraz testowania, ale i tutaj mo�na bez w�tpieniawskaza wiele nowych metod, modeli oraz narz�dzi.

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

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

4 Esej napisany we wrze�niu 2007 roku.

Page 27: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

136 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

Metametody ci��kie: rezerwat le�nych dziadków

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

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

To imponuj�ca i gro�na lista skrótowców — ze szczegó�ami oraz praktyk� mo�na si�zapozna mi�dzy innymi na spotkaniach sieci SPIN (Software Process ImprovementNetwork, www.spin-pl.org) w Gda�sku, Krakowie, Szczecinie, Warszawie i weWroc�awiu5.

Metametody lekkie: rezerwat m�odych wilków

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

5 Od tego czasu dzia�alno� SPIN-ów zaktywizowa�a si� w Gda�sku i w Krakowie, a os�ab�a w innych

miastach (stan z sierpnia 2008 roku).

Page 28: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 137

Niedostatki rezerwatów

S�abo�ci metod i modeli ci��kich s� oczywiste: w wielu przypadkach ich z�o�ono�i koszty post�powania wed�ug ich wskaza� po prostu przewy�szaj� korzy�ci, tak jakkoszt instalacji linii robotów przemys�owych w ma�omiasteczkowym warsztacie sa-mochodowym.

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

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

Wyra�nie potrzebna jest trzecia droga — droga mi�dzy biurokracj� a chaosem.

ADP — nareszcie!

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

� skuteczne projektowanie oraz implementacj� kodu;

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

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

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

Page 29: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

138 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

ADP od �rodka

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

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

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

Zadowoleni ludzie

Dot�d sprawy psychologii, ludzkiego zadowolenia, motywacji i kreatywno�ci musia�ywdziera si� do in�ynierii oprogramowania albo chy�kiem, w aurze lekkiego skandalu,albo traktowane by�y instrumentalnie jako dowody na wy�szo� metod lekkich: XP jestod�wie�aj�cym, nowym podej�ciem. XP jest skuteczny, poniewa� k�adzie nacisk nazaanga�owanie klienta i promuje prac� zespo�ow�. A zatem jak by to mia�o dzia�a�?Najbardziej zadziwiaj�cym aspektem XP jest prostota regu� i procedur. Na pocz�tkuwydaj� si� niezr�czne i naiwne, ale wkrótce staj� si� mile widzian� odmian�. Kliencis� zadowoleni z bycia partnerami w procesie programowania, a programi�ci aktywnieuczestnicz� w tym procesie bez wzgl�du na do�wiadczenie [14].

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

ADP zdo�a�o wpisa czynnik ludzki w sam� metod�, nie tylko jako ozdobnik. Niemamy tu miejsca, aby opisa wiele, pos�u�� si� wi�c dwoma znamiennymi cytatami:osi�gni�cie równowagi pomi�dzy dyscyplin� i kreatywno�ci� jest trudne oraz zarównonadmierna nuda, jak i nadmierny niepokój czyni� ludzi mniej efektywnymi i bardziejsk�onnymi do b��du.

Tym niekorzystnym tendencjom ma zapobiega w�a�ciwie, elastycznie stosowane ADP.

Page 30: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 139

Wysoka jako�� produktu

Ten podstawowy cel metodyk ginie cz�sto w nawale szczegó�ów samej metody. ADPstawia go na drugim miejscu.

Organizacja: wy�sza produktywno��i sprawno�� w dzia�aniu

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

Proces nadzorowany, udoskonalanyi daj�cy si� utrzyma�

CMMI poziom 5 czy lepiej poziom 2? Formalne modelowanie wymaga� czy niepre-cyzyjny opis s�owny? Nie ma na te pytania jedynej s�usznej odpowiedzi, natomiastniezale�nie od tego, jak brzmi w konkretnym przypadku, op�aca si� wiedzie, co ro-bimy (proces nadzorowany), umie, je�li trzeba, poprawi procedury (proces udosko-nalany) oraz zachowa zdolno� do przestrzegania w rzeczywisto�ci tych praktyk, któreuznajemy za dla nas najlepsze (proces daj�cy si� utrzyma�) — oto sens ADP.

Przedsi�wzi�cie zarz�dzanepoprzez podejmowanie decyzji

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

Zapobieganie pomy�kom i b��dom

Oprogramowanie jest substancj� pozwalaj�c� — inaczej ni� kamie�, stal czy drewno— wzgl�dnie �atwo usuwa defekty w zbudowanych z niej produktach nawet wtedy,gdy produkt jest w pe�ni uko�czony. Ta cenna w�a�ciwo� ma jednak ogromnieniekorzystne skutki uboczne, promuje bowiem my�lenie krótkowzroczne, usuwa-nie defektów zamiast ich przyczyn, co powoduje chroniczn� zawodno� produktów

Page 31: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

140 In�ynieria oprogramowania. Jak zapewni� jako�� tworzonym aplikacjom

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

Zasady ADPZnajomo� podstawowych zasad ADP pozwala zrozumie skuteczno� i prostot� tejmetodyki.

� Stworzenie infrastruktury jednocz�cej ludzi i technologi�. Metody takie jakna przyk�ad CMMI mówi� wiele o tym, co nale�y zrobi, ale niewiele o tym,jak: nie podaj� szczegó�owych wskazówek wspomagaj�cych prze�o�enie zacnychza�o�e� w konkretn� praktyk� i projektowe korzy�ci. ADP przeciwnie — okre�la,jak za pomoc� narz�dzi u�atwi i usprawni rzeczywiste wdro�enie zalece�.

� Okre�lenie i zastosowanie dobrych praktyk — to normatywna cz�� ADP,a wi�c podobna nieco do metodyk i modeli tradycyjnych. To, czym ADPkorzystnie si� wyró�nia, to uznanie istnienia dobrych praktyk na wielu ró�nychpoziomach, od ogólnych zasad SQA po szczegó�owe wskazówki dotycz�ceimplementacji kodu.

� Dostosowanie dobrych praktyk — nie istnieje uniwersalny zbiór dobrychpraktyk; ka�da firma, dziedzina i projekt powinny ogólne dobre praktykimodyfikowa i uzupe�nia, gromadz�c w�asne, szczególne do�wiadczenia.A wi�c model czy metod� nie tyle si� wdra�a wed�ug z góry za�o�onegoskryptu, co projektuje, buduje i wdra�a jednocze�nie.

� Pomiary i monitorowanie statusu projektu — automatyczny systemgromadzenia i analizy stanu projektu pozwala zarówno na sprawne okre�leniejego statusu, jak i na identyfikacj� jego s�abych stron i mo�liwych usprawnie�.Stosowanie tej zasady pozwala — pos�uguj�c si� terminologi� CMMI— wdro�y elementy poziomu pi�tego CMMI nawet w organizacjachniespe�niaj�cych wszystkich formalnych jego wymogów!

� Automatyzacja — we�my do r�ki struktur� dowolnego du�ego modelu,na przyk�ad COBIT; przecie� niemo�liwe, nara�one na liczne pomy�kii pora�aj�co — nie bójmy si� tego s�owa! — nudne by�oby jego wdro�eniebez zakrojonej na szerok� skal� automatyzacji przestrzegania jego wytycznych!ADP k�adzie ogromny nacisk na automatyzacj� procedur, przez co ichprzestrzeganie staje si� mo�liwe bez nara�ania ludzi na konieczno� uci��liwego,r�cznego wprowadzania danych wymaganych przez procedury, odci��a ichod frustruj�cych, rutynowych zada�, ogranicza zagro�enie pomy�kami.

� Przyrostowe wdro�enie praktyk ADP. To zupe�na nowo� — dot�d nawetmetodyki zalecaj�ce przyrostowe tworzenie oprogramowania nie przewidywa�yprzyrostowego wdra�ania samych siebie! Istnieje szereg czynnikówpsychologicznych powoduj�cych opór przed zmianami. Liczne kursy„mi�kkie” usi�uj� nas nauczy, jak z tym oporem sobie radzi rozmaitymipsycho- i socjotechnikami, ale nikt jako� dot�d nie zaproponowa� oczywistegorozwi�zania (dobrze sk�din�d znanego politykom podwy�szaj�cym podatki)— stopniowo i krok po kroku!

Page 32: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

Rozdzia� 4. � Zarz�dzanie procesami 141

Who is who

Adam Kolawa [10], za�o�yciel w 1987 roku ameryka�skiej firmy Parasoft [11], którejjest prezesem, oraz Dorota Huizinga [12], profesor informatyki na Uniwersytecie Ful-lertona w Kalifornii, to osoby maj�ce szczególne kompetencje do stworzenia nowegoparadygmatu — ADP.

ADP nie poleca �adnych okre�lonych narz�dzi. Ksi��ka zawiera obszern� list� narz�dzi,zarówno komercyjnych, ogólnodost�pnych i open-source, mog�cych znale� zastoso-wanie we wdra�aniu metodyki.

Wi�cej danych na temat wydarze�, us�ug i szkole� na temat ADP mo�na znale�w Internecie6.

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 artyku�u powsta�a ADPQB — ADP Qualifications Board. Adres: www.adpqb.org.

Page 33: In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym ...pdf.helion.pl/iojak/iojak-4.pdf · Osobiste zainteresowania i cele (teoria Hollanda) ... Test na co dzie .....258 Rozdzia

142 In�ynieria 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