Inżynieria oprogramowania. Jak zapewnić jakość tworzonym aplikacjom

8/6/2019 Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom

1/33

Inynieria oprogramowania.Jak zapewni jakotworzonym aplikacjomAutorzy: Bogdan Bereza-Jarociski, Bolesaw Szomaski

ISBN: 978-83-246-1948-1

Format: 158235, stron: 328

Twrz rozwizania najwyszej jakoci!

Ile kosztuje najwysza jako?

Jak j zapewni?

Jakie znaczenie ma bezpieczestwo informacji?

Inynieria oprogramowania jest niezwykle obszern dziedzin wiedzy, zajmujc si

wszelkimi aspektami produkcji oprogramowania. Obejmuje zagadnienia takie, jak

analiza, projektowanie czy te wdroenie systemu informatycznego. Jeeli kiedykolwiek

spotkae si z oprogramowaniem miernej jakoci, niewtpliwie na ktrym z etapw

jego produkcji pojawi si problem. Jak temu zapobiec?

O tym wanie traktuje ta ksika. Dowiesz si z niej, jak unika bdw, tak aby

oprogramowanie, ktre wytworzysz, prezentowao najwysz jako! Poznasz podejcie

do kwestii jakoci w czasach wspczesnych oraz zobaczysz, jak temat ten by rozumiany

wczeniej. Zdobdziesz wiedz na temat miar uywanych w inynierii oprogramowania

oraz najefektywniejszych metod i technik jego wytwarzania. Autor przedstawi Ci

rwnie narzdzia, ktre sprawi, e Twoje rozwizania stan si jeszcze lepsze.

Ponadto zobaczysz, jak wane s tematy zwizane z bezpieczestwem informacji.

Warto podkreli, e styl tej ksiki czy lekko i przyjemno lektury z powan

tematyk poruszanych w niej zagadnie.

Jako integralna Zarzdzanie ryzykiem

Zarzdzanie procesami

Cena jakoci

Spojrzenie na jako wczoraj, dzi i jutro

Zarzdzanie jakoci

Socjologiczne i antropologiczne podejcie do jakoci

Certyfikacja w inynierii oprogramowania

Najlepsze metody oraz techniki

Dostpne narzdzia, automatyzacja testw

Istota bezpieczestwa informacjiSpraw, aby Twoje aplikacje byy najwyszej jakoci!
http://helion.pl/ksiazki/iojak.htmmailto:[email protected]://helion.pl/online.htmhttp://helion.pl/cennik.htmhttp://helion.pl/emaile.cgihttp://helion.pl/zakupy/add.cgi?id=iojakhttp://helion.pl/katalog.htmhttp://helion.pl/zamow_katalog.htmhttp://helion.pl/


2/33

Spis treci

Rozdzia 1. Rozwaania wstpne ...................................................................... 131.1. Nietypowa ksika: o jakoci na wesoo ...............................................................131.2. Jako integralna .................................................................................................. 131.3. Jako przedsiwzi ............................................................................................ 14

Przykad ........................................................................................................... 15Zarzdzanie projektami ...................................................................................15Zarzdzanie procesami .................................................................................... 15Zarzdzanie celami biznesowymi ....................................................................15Zarzdzanie jakoci ........................................................................................16

1.4. Podejmowanie decyzji i zarzdzanie ryzykiem .................................................... 17

Podejmowanie decyzji i zarzdzanie ryzykiem,czyli wykorzystanie intuicji i racjonalnoci ..................................................17Brakuje jednak podejcia integralnego ............................................................17Intuicji trzeba da szans! ................................................................................ 18Mona si nauczy, jak wykorzystywa w praktyce najlepsze rodki

z dwojga wiatw .......................................................................................... 181.5. Zintegrowane zarzdzanie celami biznesowymi ................................................... 19

Budowanie siy i powodzenia firmy na rynku .................................................19Elementy jakoci integralnej ............................................................................ 20

1.6. Zarzdzanie procesami ......................................................................................... 21Sukces w systematycznym doskonaleniu organizacji ...................................... 21

Na pocztku by chaos ..................................................................................... 22Opaca si praca dobrze zorganizowana ..........................................................22Drugi brat ........................................................................................................ 23Zarzdzanie procesem biznesowym ................................................................ 23

Rozdzia 2. Dialektyka jakoci .......................................................................... 252.1. Dlaczego jako si opaca? ................................................................................. 252.2. Komu bije jako? ................................................................................................ 26

Dwaj stolarze ................................................................................................... 26Gorsze jest lepsze? ........................................................................................... 27Czy stolarz zatrudni testera? ............................................................................ 28

Specjalno: testowanie programw ................................................................ 29Ju staroytni Grecy ....................................................................................29Miliardy, co z dymem poszy .......................................................................... 30

Nie trzeba katastrofy ........................................................................................ 30Jak to sprzeda? ............................................................................................... 31Komu bije jako? ........................................................................................... 32


3/33

6 Inynieria oprogramowania. Jak zapewni jako tworzonym aplikacjom

2.3. Pocaunek ycia transfuzja krwi dla informatyki ............................................. 32Myli przewodnie ............................................................................................ 32Testowanie wymaga celu ................................................................................. 33Skutek zaley od celu ...................................................................................... 33Fachowo moe zaciemnia gwne cele ....................................................... 33

Testujmy funkcje, a nie programy ...................................................................34Rozbiene cele mog spowodowa nieporozumienie ...................................... 34Sprzeczne miary jakoci .................................................................................. 34Weryfikowa czy aktualizowa? Test jest postaw mentaln ..........................35Jako produktu to tylko pocztek .............................................................. 35

Naturalna ewolucja tester perfekcyjny ........................................................ 35Testowanie w psychologii ............................................................................... 37Teorie testowania w socjologii: naukowa weryfikacja .................................... 37Kryteria normalnoci co jest normalne? .....................................................38Pomiary ludzi ................................................................................................... 39Jako w przemyle farmaceutycznym ............................................................ 39Testowanie w swataniu ....................................................................................42Audyt finansowy ............................................................................................. 44Testowanie w przemyle budowlanym ............................................................ 44Testowanie w przemyle samochodowym ....................................................... 46Testowanie w krawiectwie .............................................................................. 48Testowanie w sztuce ........................................................................................ 49ycie to testowanie .......................................................................................... 50Bibliografia ...................................................................................................... 53

2.4. Inynieria jakoci nauka czy szarlataneria? .....................................................54Reguy naukowego rozumowania ....................................................................54

Ludzkie poznanie ............................................................................................. 55Wano i weryfikacja wiedzy ........................................................................ 56Wybr waciwej metody weryfikacji .............................................................60Wykroczenia przeciw metodom naukowym .................................................... 61Rne populacje w badaniach QA ................................................................... 65Bdy obserwatora i skutki oczekiwania ..........................................................66Testowanie hipotez .......................................................................................... 66Wiele uczestniczcych zmiennych ..................................................................67Konsekwencje i moliwoci ............................................................................68Czy testowanie oprogramowania jest nauk? .................................................. 68Zalecenia ......................................................................................................... 69

Proces kontra jako produktu .........................................................................71Negatywne skutki systemw jakoci ...............................................................72Bibliografia ...................................................................................................... 73

Rozdzia 3. Jako wczoraj, dzisiaj i jutro ......................................................... 753.1. Historia podejcia do jakoci (od Hammurabiego do Gatesa) .............................. 75

Definicje jakoci ..............................................................................................75Jako we wsplnotach pierwotnych ............................................................... 76Jako w staroytnoci .....................................................................................77Jako w redniowieczu i w okresie odrodzenia .............................................. 81Jako w XIX wieku ........................................................................................ 84

Jako w XX wieku ......................................................................................... 85Zmiany w historii jakoci ................................................................................ 89Jako w informatyce ...................................................................................... 91Jak drog poszo oprogramowanie .................................................................92Bibliografia ...................................................................................................... 93


4/33

Spis treci 7

3.2. Pdzi parowz historii: 20 lat przemian w informatyce ........................................ 94Od sierpa i mota do Internetu .........................................................................95Powolne zwycistwo uytecznoci .................................................................. 96Szybciej, wicej, dalej .....................................................................................97Jako szyta na miar ...................................................................................... 98

Samoobsuga .................................................................................................... 993.3. W krysztaowej kuli: inynieria oprogramowania za 10 lat ................................ 100

Typowe bdy przewidywania ....................................................................... 100Szybko i intuicyjnie ....................................................................................... 102Programowanie intencjonalne ........................................................................ 102Testowanie eksploracyjne .............................................................................. 103Spirale, iteracje, przyrost ............................................................................... 103

3.4. Szybko, zwinnie, ekstremalnie ........................................................................... 104Jzyki programowania ...................................................................................104Architektury komponentowe ......................................................................... 105Sztuczna inteligencja i programy samouczce si ......................................... 105Podsumowanie: sia czy inteligencja? ........................................................... 106

3.5. Drogowskaz do przyszoci mdro bdzie na serwerach, czyli ASP .......... 106Babcia nie potrzebuje komputera ................................................................... 108Czego potrzebuje babcia autora? ...................................................................109Szczegy rozwizania dla babci ...................................................................109Z czym nam si to kojarzy? ...........................................................................112Kontrowersje .................................................................................................113Jeszcze troch recenzji walka ze spamem ................................................. 113Moc jzykw ................................................................................................. 114Zakoczenie ................................................................................................... 115

3.6. Y2K heca czy historia? Wspomnienia wiadka ............................................. 115Rozdzia 4. Zarzdzanie procesami ................................................................. 119

4.1. Zarzdzanie jakoci wadza i zgiek ............................................................. 119Jak opanowa stado bezgowych kur, czyli zarzdzanie konfiguracj ........... 119Rozmawiaa g z prosiciem: raporty i ledzenie bdw ............................ 120Krajobraz przed bitw: planowanie testw, analiza ryzyka ........................... 121Husaria kontra pruska piechota: jak nie straci impetu, nie tracc gowy? ....... 122Krajobraz po bitwie: czy mona wypuci produkt ju jutro? ....................... 123Obdzieranie polegych, czyli jak by mdrym po szkodzie ........................... 124Rne formy organizacji testowania .............................................................. 124Kiedy zaczyna, kiedy skoczy? .................................................................. 125

4.2. Znowu ten popiech jak szybko oceni jako aplikacji? .............................. 125Popiech w informatyce ................................................................................. 125Pomiary w popiechu ..................................................................................... 126Precz z grzybami ...........................................................................................127Grzybobranie ................................................................................................. 127Testowanie uwzgldniajce ryzyko ............................................................... 129Jakie to atwe... .............................................................................................. 129Bilet do Davos ............................................................................................... 130Jak spieszy si powoli .................................................................................. 130

4.3. Po co mierzy? Miary w inynierii oprogramowania ......................................... 131

Czego nie mona zmierzy, tego si nie wie ................................................. 132Ksika .......................................................................................................... 1334.4. Midzy biurokracj a chaosem: ADP .................................................................... 134

Kopot ............................................................................................................ 134Akcja i kontrakcja .......................................................................................... 135Metametody cikie: rezerwat lenych dziadkw .......................................... 136


5/33


Metametody lekkie: rezerwat modych wilkw ............................................. 136Niedostatki rezerwatw ................................................................................. 137ADP nareszcie! ......................................................................................... 137ADP od rodka .............................................................................................. 138Zadowoleni ludzie ......................................................................................... 138

Wysoka jako produktu ................................................................................ 139Organizacja: wysza produktywno i sprawno w dziaaniu ...................... 139Proces nadzorowany, udoskonalany i dajcy si utrzyma ............................ 139Przedsiwzicie zarzdzane poprzez podejmowanie decyzji ......................... 139Zapobieganie pomykom i bdom ................................................................ 139Zasady ADP ................................................................................................... 140Who is who ....................................................................................................141Referencje ...................................................................................................... 141

Rozdzia 5. Socjologia i antropologia jakoci .................................................. 1435.1. Inynier jakoci to nie brzmi dumnie ............................................................. 143

Kariera testera ................................................................................................ 1445.2. Samotno testera: organizacje i konferencje ..................................................... 144Szkolenia i certyfikaty ................................................................................... 145

5.3. Psychologia projektu .......................................................................................... 146Przykad z projektu ........................................................................................ 147Co wynika z nieporozumie? ........................................................................ 148Kreatywno .................................................................................................. 149

Negocjacje ..................................................................................................... 149Asertywno ..................................................................................................150Wystpienia publiczne ................................................................................... 150Motywacja i zarzdzanie zespoem ............................................................... 151

Trening antystresowy i zarzdzanie emocjami ..............................................151Zarzdzanie ryzykiem i podejmowanie decyzji ............................................. 1525.4. Dobre decyzje: intuicja i racjonalno ................................................................ 153

Streszczenie ................................................................................................... 153Wprowadzenie ............................................................................................... 153

Na przystawk: trzy krtkie historie, aby skusi czytelnika .......................... 154Opowiadanie o wybieraniu metod testowania ...............................................155Opowiadanie na temat Czy jestemy gotowi podj decyzj? ................... 155Psychologia podejmowania decyzji ............................................................... 156

Nieprzechodnio preferencji ........................................................................ 156Preferencja czasowa i opniona gratyfikacja ............................................... 157

Percepcja prawdopodobiestwa ..................................................................... 158Co to jest testowanie uwzgldniajce ryzyko? ............................................... 164Statystyka: podejmowanie decyzji w warunkach niepewnoci ...................... 165Strategie decyzyjne ........................................................................................ 167Podejmowanie decyzji przy uyciu statystyki Bayesa ................................... 168Bibliografia .................................................................................................... 171

5.5. Psychologia jakoci ............................................................................................ 172Psychologia i socjologia testowania .............................................................. 172Status tego rozdziau ...................................................................................... 172Dysonans poznawczy ....................................................................................172Psychologia testowania .................................................................................. 172

Praca konstruktywna i motywacja .................................................................173Bezpieczestwo, niepokj ............................................................................. 174Przegldy ....................................................................................................... 174Dynamika grupowa ........................................................................................ 175Studium komunikacji ..................................................................................... 175Hierarchia potrzeb wg Maslova ..................................................................... 176


6/33

Spis treci 9

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

5.6. Czy warto si SPIN-a? ...................................................................................... 178Organizacje zajmujce si jakoci w Polsce ................................................ 178

Gdzie jest Forum Romanum? ........................................................................179Quo vadis, udoskonalanie procesw? ............................................................ 180

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

Rozdzia 6. Interakcja, uyteczno, wygoda .................................................. 1916.1. Inwazja szalecw ..............................................................................................191

6.2. Jak ulepszy wiat? .............................................................................................193Frustracja, ponienie, agresja ......................................................................... 193Szalecy rzdz domem wariatw ................................................................. 194Sze grzechw gwnych ............................................................................. 194

Niewite przymierze .................................................................................... 195Pomoc nadciga ............................................................................................. 196

6.3. Psychologiczne podstawy uytecznoci .............................................................. 196Stan obecny ................................................................................................... 196Lista kontrolna niektrych czynnikw uytecznoci ..................................... 197

Rozdzia 7. ycie towarzyskie i uczuciowe ...................................................... 201

7.1. Adwentowa gwiazda 2003 .................................................................................. 201Adwentowa gwiazda ...................................................................................... 201Albomy to jacy-tacy? ................................................................................... 202ycie towarzyskie i uczuciowe ...................................................................... 202Koniec wojny niemiecko-brytyjskiej ............................................................. 203O co tyle szumu? ........................................................................................... 203O chorobie wspuzalenienia .......................................................................204

7.2. Kupujc wiedz: przewodnik po szkoleniach ..................................................... 205Motto ............................................................................................................. 205Podstawy ....................................................................................................... 205Pi zotych zasad, jak znale szkolenie testowe ......................................... 206

7.3. Jak sprzedawa nietypowe szkolenia? Podrcznik cynicznego sprzedawcy ....... 209Wizja pocztki .......................................................................................... 209Przynta ......................................................................................................... 210Strategia ......................................................................................................... 211Motywacja nauczania = dochd z nauczania alternatywny zysk ................ 211Planowanie .................................................................................................... 212

Nauczyciele ................................................................................................... 212Czynic karier nauczyciela atrakcyjn ......................................................... 213Struktura pakietu szkoleniowego ................................................................... 214Praktyczne techniki szkoleniowe kontra teoria .............................................. 216wiadectwa i egzaminy .................................................................................217

Pakiety moduowy model kursu ................................................................ 217Wykonanie licz si praktyczne szczegy ............................................... 218Bg czy mamona? Zasady czy siy rynkowe? ...............................................220Konkurencja .................................................................................................. 221Do zapamitania ............................................................................................ 221


7/33


7.4. Papierki i wiadectwa. Certyfikacja w inynierii oprogramowania .................... 222Sens certyfikacji w przemyle informatycznym ............................................ 222Certyfikacja w dziedzinie zapewnienia jakoci i testowania ......................... 223Rodzaje certyfikatw ..................................................................................... 223Poytki z certyfikatw ................................................................................... 224

Zagroenia ..................................................................................................... 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 midzynarodowe .................................................................... 2287.6. To po prostu bzdura! ........................................................................................... 229

Wyznania sfrustrowanego trenera jakoci ..................................................... 229

Wedug ISEB i ISTQB .............................................................................. 230Jak wybiera si przypadki testowe w rzeczywistoci? ................................... 231Peny obraz .................................................................................................... 233W kocu: przykad ......................................................................................... 235

Rozdzia 8. Metody i techniki ......................................................................... 2378.1. Sztuka, rzemioso, nauka .................................................................................... 237

Powiedzmy, e zbliaj si wybory ............................................................... 237Grupa reprezentatywna ..................................................................................237

Na tym samym polega testowanie ................................................................. 238Sztuka ............................................................................................................ 238

Rzemioso ...................................................................................................... 239Nauka ............................................................................................................ 2408.2. Szlachetna sztuka testowania oprogramowania .................................................. 241

Nowa ksika ................................................................................................. 241Klasyka odwieona ...................................................................................... 242

Nazewnictwo ................................................................................................. 2438.3. eby banki rosy w si, a klienci yli dostatniej ................................................244

Praca mudna, mozolna, ale za to jaka jaowa! ............................................. 244Kontrola instalacji wodnej pod cinieniem .................................................... 245Pocigi pod specjalnym nadzorem ................................................................. 246Szukanie dziury w caym ............................................................................... 246

Czego uytkownik nie lubi najbardziej? ........................................................ 247Jako jest za darmo ...................................................................................... 2478.4. Kracowo zwinne eksploracyjne piramidy ......................................................... 247

Historia polityczna ......................................................................................... 247Ostrzeenie .................................................................................................... 248

Nowa religia .................................................................................................. 249Zastosowanie eksploracji ............................................................................... 251

8.5. Cyryl jak Cyryl, ale metody! .............................................................................. 251Nie warto marnowa czasu ............................................................................ 251Ryzyko jest zbyt due .................................................................................... 252Testowanie osobna specjalno? ............................................................... 252

Czy test moe si opaca? ............................................................................253Rachunek zyskw i strat ................................................................................253Kosmiczne pienidze .....................................................................................253Co przetestowa, a co zlekceway? ............................................................. 253Sztuka testowania .......................................................................................... 254Tester jako rzemielnik .................................................................................. 254


8/33

Spis treci 11

Metody formalne ........................................................................................... 255Chop pi, a zboe samo ronie ...................................................................... 255Kiedy testowa? ............................................................................................. 255Kto bdzie testerem? ..................................................................................... 256Polowanie na pluskwy ................................................................................... 256

Schwytana pluskwa na uwizi .......................................................................257Zaplecze frontu, czyli logistyka testowania ...................................................257Test na co dzie ............................................................................................. 258

Rozdzia 9. Warsztat fachowca ....................................................................... 2599.1. Automatyzacja testw ......................................................................................... 259

Co to jest automatyzacja testowania? ............................................................260Co znajduje si w skrzynce ze zotem: poytki z automatyzacji .................... 260Gdzie rozmieszczone s miny: niebezpieczestwa automatyzacji ................. 261

Na zakoczenie .............................................................................................. 2649.2. Czy jako jest za darmo? Opacalno automatyzacji .......................................264

Krtki poradnik dla szefw dziaw informatyki .......................................... 264Przekuwamy infrastruktur na lemiesze ........................................................265Cyryl jak Cyryl, ale metody! ......................................................................... 266Przez namolno do pedagogicznego sukcesu ...............................................266Jako jest za darmo? .................................................................................... 266Prosta zasada zotego rodka ......................................................................... 266Kombajnem przez preri ................................................................................ 267Potrzeba, jak zwykle, fachowcw .................................................................. 268Sierpy, snopowizaki i kombajny ................................................................. 270Gdzie szuka dalej? ....................................................................................... 272

Rozdzia 10. Bezpieczestwo informacji ............................................................ 27310.1. Bezpieczestwo informacji: historia i stan obecny ............................................. 273Wprowadzenie bezpieczestwo informacji dawniej ................................. 273Ochrona fizyczna i konstruowanie niezawodnego sprztu ............................ 276Zapewnienie jakoci oprogramowania ........................................................... 277Zapewnienie bezpieczestwa oprogramowania ............................................. 278Zapewnienie bezpieczestwa systemw informatycznych ............................ 281Zarzdzanie bezpieczestwem informacji .....................................................283Systemy zarzdzania bezpieczestwem

informacji wedug norm ISO serii 27000 .................................................... 284Prba przewidywania przyszoci .................................................................. 290

Bibliografia .................................................................................................... 29210.2. Walka z cieniem zabezpieczenia i odporno w praktyce .................................. 295Streszczenie ................................................................................................... 295Co to jest bezpieczestwo? ........................................................................295Definicje bezpieczestwa .............................................................................. 296Gdzie szuka bdw zabezpieczenia? .......................................................... 297Testowanie zabezpiecze ............................................................................... 298Ile testowa zabezpieczenia? .........................................................................298Wraliwe czci ciaa smoka ......................................................................... 299Uyteczno ................................................................................................... 300Wykonanie ..................................................................................................... 301

Aspekty organizacyjne ...................................................................................301Proces testowania bezpieczestwa .................................................................302Monitoring w trakcie dziaania operacyjnego ................................................ 303Bibliografia .................................................................................................... 304Organizacje, firmy, usugi i normy ................................................................ 305

Narzdzia ....................................................................................................... 305


9/33


10.3. Bezpieczestwo praca u podstaw ................................................................... 306Duo haasu o bezpieczestwo ...................................................................... 306Bezpieczestwo wielopoziomowe .................................................................306Trzy wiaty bezpieczestwa .......................................................................... 307

Normy, audyt, standardy ................................................................................ 307

Policjanci ....................................................................................................... 307Testy penetracyjne .........................................................................................308Praca u podstaw ............................................................................................. 308Inynieria wymaga bezpieczestwa ............................................................. 308Moliwoci analizy statycznej ....................................................................... 309Bdy na poziomie kodowania: testy jednostkowe ........................................ 310Bezpieczestwo czy bezpieczestwo? ........................................................... 310Profits, stupid! ............................................................................................... 311Leczy czy zapobiega? ................................................................................ 312Praca mudna, mozolna, za to jaka jaowa! .............................................. 312

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


10/33

Rozdzia 4.

Zarzdzanie procesami

4.1. Zarzdzanie jakoci wadza i zgiek

Tak jak Wenus podobno wyonia si z morskiej piany, tak z chaotycznej biega-niny, nerwowych zebra, nadgodzin programistw, rozpaczliwej krztaniny testerw,

zszarganych nerww kierownika projektu oraz grb zniecierpliwionego klienta masi wyoni Ona: aplikacja-marzenie. Bezbdna. Zaspokajajca wszystkie, nawet naj-skrytsze marzenia klienta. Idealna.

Wan rol w tym procesie odgrywa testowanie. To test powinien ostrzec: Panowie,mielimy budowa Wenus, a na razie widzimy tutaj piciogowego wielbda!. Testprzypomni, ze bogini piknoci powinna mie dwie, nie za trzy nogi. Test policzypalce u rk i zawoa, e cztery palce uchodz w komiksach, ale nie w rzeczywistoci.

O ile nietrudno odrni piciogowego wielbda od Wenus, o tyle bdy oprogramo-

wania nie zawsze s oczywiste i rzucajce si w oczy. Zdemaskowanie ich wymagaskrztnej pracy, wsplnego wysiku wielu osb, ktrymi kto musi zarzdza i kierowa.Jak? o tym wanie bdzie mowa w dalszej czci rozdziau.

Jak opanowa stado bezgowych kur,czyli zarzdzanie konfiguracj

Zgoszenie bdu dokadny opis objaww i okolicznoci awarii, sporzdzony przez

testera sporym nakadem pracy po to, by uatwi programicie znalezienie i zlikwido-wanie przyczyny awarii. Programista bardzo si dziwi: przecie ten bd zosta usu-nity ju dwa tygodnie wczeniej! Pewnie uye zej wersji powiada testerowi.Ale skd, gwne okno dialogowe wywietlio numer najnowszej wersji, Z15 opo-nuje tester. Tak, ale to wersja programu gwnego. Ten modu mg mie inn wersj!.Sprawdzaj obaj. Okazuje si, e adres 0xA1F0zawiera warto 0xE, a wic wersja


11/33


numer czternacie feralnego moduu. Tester poci si i czy program ponownie, tymrazem z najnowsz wersj. Awaria nie pojawia si wicej: dobrze. Niestety, po dwchtygodniach powraca! Co si stao? Po p dnia dochodze udaje si ustali, e nowozatrudniony programista przez pomyk, czc program, znowu posuy si star wer-

sj feralnego moduuBrzmi to znajomo? Oczywicie. Mamy tu do czynienia z klasycznymi symptomaminiedostatkw zarzdzania konfiguracj.

No, ale co to ma wsplnego z zarzdzaniem testami? Jak w opisanym przykadzie bardzo wiele. System czy program (zwaszcza niezbyt skomplikowany) moe siniekiedy uda zbudowa kosztem pewnego czasochonnego zamieszania mimobrakw w zarzdzaniu konfiguracj. Natomiast zapewnienie jakoci bez dobrze funk-cjonujcego zarzdzania konfiguracj jest zwykle niemal bezuyteczne. Zidentyfikowaneprzez testerw awarie okazuj si albo dotyczy nieaktualnej wersji, albo wymagajdetektywistycznej pracy, aby znale ich przyczyn w chaosie spltanych wersji po-szczeglnych moduw systemu. Marnuje si w ten sposb wiele czasu i wysiku, przezco test tylko w ograniczonym stopniu dostarcza swego najwaniejszego produktu: in-formacji pozwalajcej na znajdowanie i usuwanie bdw.

Z tego wanie powodu czsto zesp testujcy, a nie cay projekt informatyczny, jestgorcym zwolennikiem uporzdkowania le dziaajcego zarzdzania konfiguracj. Niejest to dobre rozwizanie, ale o wiele lepsze ni dobrowolne oddanie si w rce cha-osu, marnotrawstwa i baaganu. Cho wic nie chodzi tu o testowaniesensu stricto,niejednemu kierownikowi zespou testujcego przyjdzie si z t problematyk zmierzyi warto sobie z tego zdawa spraw. Jak konkretnie si to robi: zarzdzanie i kontrolwersji, budow konfiguracji podstawowych (baselines) to s ju zagadnienia naosobny rozdzia.

Rozmawiaa g z prosiciem:raporty i ledzenie bdw

Kiedy tester natknie si na awari bdc symptomem tkwicego w programie bdu,

fakt ten niesie w sobie dwa rodzaje informacji. Po pierwsze, ilo znajdujcych siw programie bdw jest podstawow miar jego jakoci, a wic kluczow wielkoci,ktr naley wzi pod uwag, dokonujc decyzji dotyczcych wdroenia, wprowadze-nia do produkcji czy dostarczenia klientom nowej wersji programu. Po drugie, zaobser-wowana awaria pozwala zwykle zidentyfikowa bdcy jej przyczyn bd, usun goi w ten sposb podnie jako programu.

Ani w jednym, ani w drugim przypadku nie wystarczy, by ta wiedza pozostaa w gowietestera. Trzeba j przekaza programicie, aby rozpocz poszukiwania przyczynyawarii, oraz kierownikowi projektu, aby mg sporzdzi statystyki bdw i oszacowa

biec jako konstruowanego systemu. Nawet jeli projekt jest jednoosobowy, niezawsze daje si wszystko zapamita i prowadzenie notatek na temat znajdowanychi usuwanych bdw pozwala na uniknicie pomyek.

Tym celom przekazywaniu oraz gromadzeniu informacji o awariach i bdach sutak zwaneraportyalbozgoszenia bdw.


12/33

Rozdzia 4. Zarzdzanie procesami 121

Niektre traktujce o testowaniu rda (m.in. tumaczona na jzyk polski ksikaamerykaskiego autora Rona Pattona Testowanie oprogramowania1) powicaj wielemiejsca udzielaniu rad, jak powinien postpowa tester, aby dopilnowa, eby znale-ziony bd rzeczywicie zosta potraktowany powanie i naprawiony. Takie podejcie

wydaje si by stawianiem sprawy na gowie. Po pierwsze, tester ma inne zajcia nizastpowanie niefrasobliwego wida kierownika projektu i ciganie programistw.Po drugie, taka sytuacja stwarza realne zagroenie sprowokowania konfliktw midzytesterami a konstruktorami. Po trzecie wreszcie, tester nie musi mie i zwykle nie mapenej wiedzy potrzebnej do prawidowej oceny wagi znalezionego bdu. Do tegokonieczna jest zalenie od rodzaju bdu jeszcze wiedza na temat struktury i prio-rytetw wymaga, potrzeb klienta, architektury systemu. Nie jest wcale oczywiste, ekada awaria wymaga natychmiastowego rzucenia wszystkich dostpnych rodkww celu jej rozbrojenia i usunicia! To zaley midzy innymi od zwizanego z ni ryzyka.Do oszacowania ryzyka nie wystarczy zwykle jedna osoba: konieczna jest wsppraca

wielu uczestnikw projektu, ktr umoliwiaj waciwie wykorzystane raporty bdw.

Zorganizowanie procedur zgaszania i ledzenia bdw jest jednym z podstawowychzada kierownika testw.

Krajobraz przed bitw:planowanie testw, analiza ryzyka

Jak powiedzia genera, a pniej prezydent Eisenhower, wprawdzie planowany prze-bieg wydarze nigdy si nie sprawdza, ale mimo to ten dowdca, ktry planowa naj-staranniej, ma najwiksze szanse poradzenia sobie z (niezaplanowan) sytuacj na polubitwy.

To samo dotyczy testowania. Wiadomo z gry, e dostawa do testu systemowego b-dzie opniona w porwnaniu z planem o dwa miesice, natomiast data dostawydo klienta nie ulegnie zmianie, przez co na test systemu, zamiast przewidzianych dzie-siciu, pozostan ledwo dwa tygodnie. Wiadomo, e jako pierwszych dostaw bdzietaka, e wikszo czasu trzeba bdzie powici na podnoszenie zawieszajcego si

systemu, a nie na wykonywanie przypadkw testowych. Oczywiste jest te, e znaj-dowane bdy spowoduj niezaplanowany wzrost iloci dostarczanych do testowaniawersji programu, przez co czas powicony na ich instalacj i konfigurowanie oraz natesty regresji wzronie w porwnaniu z planem dramatycznie. Wreszcie wia-domo, e proces odpluskwiania (ang. debugging) odcignie pewn ilo testerw napewien czas od testowania, a ponadto rodowisko testowe bdzie w niezaplanowa-nych wymiarach zablokowane przez programistw usiujcych odtworzy awarii zlokalizowa jej przyczyn.

Planujc, e wydarz si wszystkie te niezaplanowane historie, mamy realne podstawy,

by poradzi sobie z wyzwaniem, jakim jest zarzdzanie testami!

1Nakad obecnie wyczerpany wrzesie 2008.


13/33


Husaria kontra pruska piechota:jak nie straci impetu, nie tracc gowy?

Impet jest w testowaniu wany, ale musi to by impet kontrolowany, w przeciwnymrazie moe nas sprowadzi na manowce. ledzimy liczb wykonanych przypadkwtestowych i porwnujemy z zaplanowanymi w ten sposb ewentualne opnieniewyjdzie na jaw od samego pocztku, a nie dopiero wtedy, kiedy naronie do katastro-falnych rozmiarw. ledzimy liczb otwartych, zgoszonych bdw w ten sposbmoemy prbowa oszacowa ilo pozostaych jeszcze bdw, ktre zapewne wy-szyby na jaw w trakcie dalszego testowania systemu, dziki czemu w kadej chwilimamy do dyspozycji dane pozwalajce odpowiedzie na nieuniknione pytanie: cokierownik testw sdzi o tym, eby dostawa do klienta miaa miejsce ju pojutrze?

czas testowania(znormalizowany)

skumulowana liczbawykonanych zadatestowych

zaplanowanafaktyczna

trudnoci, spitrzeniebdw

naprawianie bdwi testy regresji

nadrabianie start

szczliwy koniec

Rysunek 4.1.1. ledzenie procesu przebiegu testw

Dostrzegszy niebezpieczne, narastajce rozbienoci midzy planem a rzeczywisto-ci, kierownik testw ma do dyspozycji pi typw rodkw zaradczych:

Zmiana harmonogramu testw odroczenie zakoczenia i terminu dostawydo klienta.

Zmiana kryteriw jakoci obnienie poprzeczki, dopuszczenie do uytku systemumniej przetestowanego albo majcego wiksz ilo nierozwizanych bdw.

Wykorzystanie do testowania wikszej iloci osb, testowanie rwnolege.

Zamiana funkcjonalnoci dostarczony system nie bdzie zawierawszystkich wczeniej planowanych funkcji.

Podniesienie wymaganej jakoci dostaw do testu systemowego to umoliwi

sprawniejsze testowanie i przerzuci cz dziaa na nisze poziomy(testy komponentw, integracyjne).

Ponadto czsto stosowanym rodkiem jest kiedy gwatownie narasta ilozarejestrowanych zgosze bdw czasowe zawieszenie wykonywanianowych testw po to, by da programistom szans na usunicie spitrzenia


14/33


i naprawienie jak najwikszej liczby bdw. W tym czasie zesp testowypowica si wycznie testowaniu powtarzalnemu dostaw zawierajcychkolejne poprawki.

Krajobraz po bitwie:czy mona wypuci produkt ju jutro?

Decyzja o tym, czy mona ju zakoczy testowanie i wypuci, dostarczy albo roz-pocz wdraanie programu, jest de factodecyzj biznesow, nie techniczn. Stoso-wana w niektrych przedsibiorstwach zasada, e kierownik testw podpisuje zakocze-nie testw i niejako tym samym wasn gow gwarantuje dostateczn jako produktu,jest absurdem. Testowanie nie jest na dobr spraw zakoczone nigdy, zawsze pozo-staje z podpisem kierownika czy bez niego pewne ryzyko, e w programie po-

zostay niezauwaone bdy.

Nie znaczy to jednak, e testowa trzeba w nieskoczono, bo z drugiej strony czaisi przecie ryzyko opnienia, kar umownych, niezadowolonych klientw, utratyudziaw w rynku na rzecz szybszych czy odwaniejszych konkurentw. Analiza ry-zyka i podjcie decyzji jest w 100% zadaniem dla kierownictwa lub sponsorw pro-jektu, ewentualnie dla dziau marketingu. Test ma natomiast za zadanie dostarczydecydentom jak najprecyzyjniejsze dane dotyczce ryzyka technicznego w oparciuo dotychczasowe wyniki testowania.

Istnieje wiele kryteriw oszacowania jakoci produktu w oparciu o rezultaty testw.Bierze si na przykad pod uwag, jaki procent zada testowych zosta dotychczaswykonany, ile pozostao otwartych (nierozwizanych) zgosze bdw itd. Interesujcmetod jest technika oszacowania iloci pozostaych jeszcze w programie nieznanychbdw na podstawie funkcji najlepiej pasujcej do krzywej okrelajcej skumulowanilo dotychczas znalezionych bdw. Wyjanienie na ilustracji poniej.

czas testowania

(znormalizowany)

skumulowana liczbawykonanych zada

testowych

zaplanowanafaktyczna

trudnoci, spitrzeniebdw

naprawianie bdwi testy regresji

nadrabianie start

szczliwy koniec

Rysunek 4.1.2. Szacowanie liczby pozostaych defektw

Oczywicie istotno takich oszacowa zaley od liczby oraz jakoci wykonanych te-stw. Do ich oceny su rozmaite miary pokrycia(np. wymaga, funkcji, kodu).


15/33


Obdzieranie polegych,czyli jak by mdrym po szkodzie

Projekt zakoczony, produkt sprzedany, kod i dokumentacja zoone w archiwum i prze-kazane do dziau zajmujcego si serwisem czy to ju koniec pracy? Ot nie, boz danych uzyskanych w trakcie testowania mona jeszcze niejedn ciekaw informa-cj wycisn. Wprawdzie na popraw jakoci wytworzonego przez zakoczony pro-jekt produktu informatycznego ju za pno, nie da si take podwyszy jakoci de-cyzji, ktre ju zapady, ale mona uzyska wiedz pozwalajc by moe kolejneprojekty poprowadzi lepiej i sprawniej.

Bogatym rdem wiadomoci jest baza danych z raportami bdw. Mona na przy-kad szczegowo zanalizowa pewn liczb losowo wybranych raportw i sprbowaodpowiedzie na pytanie, jaka bya pierwsza przyczyna zaistnienia danego bdu? Czybyy ni niejasno sformuowane wymagania, czy niedostateczna znajomo jzyka przezprogramistw, czy niedocignicia organizacyjne?

Warto te przyjrze si statystykom raportw bdw. Kiedy pojawio si ich najwicej?Jaki by czas naprawy bdu? Ile raportw okazao si faszywych? Odpowiedzi na tepytania niejednokrotnie pozwol zidentyfikowa sabe punkty w procesach i procedu-rach projektw lub niedostatki organizacyjne w przedsibiorstwie.

Rne formy organizacji testowaniaNie zawsze jedyn i najlepsz form organizacji testw jest stworzenie osobnegozespoutestowego. Zalenie od charakteru projektu, typu produktu, przyjtej metodyki wytwa-rzania korzystne moe okaza si zastosowanie innych rozwiza organizacyjnych.

Programici sami testuj wasny kod. Metoda czsto stosowana w testachmoduowych (jednostkowych, komponentw). Jej wady s oczywiste.

Testowanie koleeskie (ang. buddy testing): programici nawzajem testujswj kod. Stosowane midzy innymi w popularnym ostatnio ProgramowaniuEkstremalnym (XP,Extreme Programming).

Tester (lub testerzy) s czonkami zespou programistw, podlegaj kierownikowizespou lub projektu.

Osobny zesp testujcy majcy wasnego kierownika.

Osobny dzia w przedsibiorstwie zajmujcy si pewnymi rodzajami testw.

Outsourcing testw do innego przedsibiorstwa: stosowane wwczas, gdywymagana jest niezalena certyfikacja systemu oraz gdy niezbdne jestskomplikowane i kosztowne rodowisko testowe (np. w testowaniu konfiguracji,testowaniu zgodnoci z wymaganiami rodowiskowymi itp.).

Wybr waciwej organizacji testowania jest wanym zadaniem dla kierownikaprojektu. Warto pamita, e w wikszych projektach kilka rnych formorganizacyjnych moe istnie jednoczenie, na przykad testowanie koleeskiena poziomie testw komponentw, odrbny zesp do testu systemowego,outsourcing w celu uzyskania niezalenej certyfikacji.


16/33


Kiedy zaczyna, kiedy skoczy?

Jak zwykle bywa dobrze wiemy. Jak powinno by zwile opisuje rysunek 4.1.3.Czynnoci wykonywane przez zesp testowy napisane s tustym drukiem na jasno-

szarym tle.

Specyfikacjawymaga

Specyfikacja

konstrukcji

Kodowanie Testy komponentw

Testy integracyjne

Test systemu

Test akceptacyjnyWalidacjawymaga

Testowalnowymaga Przegld

Przegld

Przygotowanietestw

Przygotowanietestw

Testowanie

Rysunek 4.1.3.Przegld modelu V

4.2. Znowu ten popiech jak szybkooceni jako aplikacji?

Popiech w informatyceZrobi cokolwiek szybko? Znowu ten popiech. Znane jest przecie porzekado: conagle, to po diable i niezliczone przykady sytuacji, kiedy zabrako czasu i rodkw,aby co wykona dobrze, ale znalazo si potem i jedno, i drugie, aby to co wielo-krotnie poprawia. Informatyka to brana cierpica od swego powstania na syndromczarodziejskiej plasteliny. Kilkadziesit lat temu udao si ludziom speni swe odwiecznemarzenie i znale substancj, z ktrej daje si szybko i atwo zbudowa wiele najroz-maitszych rzeczy: a to system bazodanowy, a to telefoni komrkow, a to wbudowanyukad sterujcy do pralki automatycznej. Figurki lepione z naszej czarodziejskiej pla-

steliny instrukcji mikroprocesora rzeczywicie mona tworzy zadziwiajco szybkow porwnaniu z przedmiotami z drewna, metalu czy betonu, a ponadto mona je po-tem wzgldnie atwo poprawia bez potrzeby burzenia caoci, jeli co si nie ca-kiem uda. Ludzikowi z plasteliny mona nawet, kiedy ju jest gotowy, oderwa nogi zastpi j inn, lepsz, ale te wyglda on potem jak ludzik z plasteliny.


17/33


Programowanie naraone jest na nieustann pokus bylejakoci i popiechu, ktrychskutkiem jest bardzo czsto albo fatalna jako aplikacji, albo lekcewaenie uytkow-nika i jego potrzeb, przez co wiat zapeniaj zawodne i pokraczne, niewygodne w ob-sudze twory z plasteliny. Po co zbiera i analizowa wymagania, skoro mona zacz

budowa od razu, a potem, w razie czego, wszystko si przerobi? Po co starannie pro-jektowa system, skoro mona od razu zacz kodowanie, a potem jako si te, niepa-sujce do siebie, czci poskleja w cao? Po co dba o jako projektu, skoro w ba-aganie te daje si pracowa, i po co wysila si na produkty dobrej jakoci, skoroczarodziejska plastelina pozwala na pozr bezkarnie poprawia, sztukowa, zaizolowakawakiem dtki, przymocowa drutem?

Mio jest sobie pozrzdzi, ale z drugiej strony nie mona zaprzeczy, e to dzikisystemom informatycznym dzisiejszy wiat ogromnie przewysza ten sprzed lattrzydziestui czterdziestu pod wzgldem moliwoci, dobrobytu, bezpieczestwa i or-

ganizacji, cokolwiek na ten temat sdz rozmaici zwolennicy powrotu do jaski czywrcz na drzewa.

Ponadto, szydzc sobie z typowego projektu informatycznego: drwala, ktry nie maczasu porzdnie naostrzy siekiery, bo tak bardzo si spieszy z rbaniem drewna, niesposb przecie zapomnie o zagroeniach z przeciwnej strony: drwalach tak zajtychostrzeniem siekiery, e nie maj czasu na cinanie drzew. Czynniki psychologiczne po-woduj, e chtnie uchylajc si przed naprawd trudnymi wyzwaniami ucie-kamy w rytualizacj, mnoenie zbdnej dokumentacji, mani zebra i posiedze, wiarw rzekomo uzdrowicielsk moc procedur, procesw, poziomw dojrzaoci i sprawnoci,duszcych prawdziw kreatywno i skuteczno.

Czy nie ma drogi poredniej midzy jedn a drug skrajnoci? Jest, oczywicie topopiech kontrolowany, gdzie umiejtno i wprawa pozwalaj porusza si szybko,lecz pewnie, a cieki na skrty niekoniecznie prowadz na manowce.

Pomiary w popiechu

Warunkiem skutecznego popiechu kontrolowanego jest umiejtno nadzoru w biegu,tak eby zakrt mc przej na piszczcych oponach, ale z niego nie wylecie, poko-nujc za na skrty bezdroa, orientowa si zrcznie za pomoc mapy, kompasu, ze-garka i bystrych oczu i nie zabdzi.

Nie jestemy w stanie kontrolowa tego, czego nie umiemy zmierzy. Alepomiarniejest w informatyce sowem lubianym nawet poddany mi przez Redakcj tytu tegoartykuu omija je, zastpujc niebudzcym lku sowem ocena. Cho jako specjalistaw brany nie raz spieraem si przy piwie, czy to testowanie, czy te utrzymanie opro-gramowania jest bardziej niesusznie lekcewaone w praktyce naszego przemysu, wy-

daje si, e palma pierwszestwa naley si jednak pomiarom. Dobry kierowca raj-dowy nie musi wysiada z samochodu i mierzy promienia skrtu tam tylko dzikitemu, e wprawa pozwala mu mierzy bez przerywania jazdy. Przewodnik, na pozrbez wysiku wyprowadzajcy przez gste krzaki wprost na zamierzony punkt, nie wleczeza sob wielokilometrowej nici Ariadny tylko dlatego, e nieustannie podczas marszu


18/33


mierzy przebyt odlego, kierunek, nachylenie terenu. W przemyle informatycznymchtnie udajemy kierowcw Formuy 1 oraz dzielnych przewodnikw, nie majc nie-zbdnych po temu umiejtnoci mierzenia.

Brak umiejtnoci sprawnego mierzenia uniemoliwia zarzdzanie ryzykiem, zast-pujc je unikaniem ryzyka lub bezsensown brawur. Unikanie ryzyka w inynieriioprogramowania rodzi projekty sztywne, zbiurokratyzowane, nieskuteczne, omijajcewaciwe wyzwania. Bezsensowna brawura oznacza fanfaronad przy wyznaczaniu ce-lw, rodkw i terminw, po czym To, co zdarza si potem, take mona oczywi-cie zmierzy. Odpowiedni miar, nie do koca jeszcze uznan przez fizykw, jestoch-nie-sekunda (ang. oh-no-second), stosowana do okrelenia czasu upywajcegood chwili, gdy si zorientowalimy, e popenilimy NAPRAWD DUY BD(np. klikajc wylij do wszystkich na koniec maila penego wspomnie z bardzogorcej nocy).

O zarzdzaniu ryzykiem i o skutecznych pomiarach napisz wkrtce, jak mi czas i Re-dakcja pozwol. Na razie pora przej do sedna: jak szybko oceni jako produktu,czylijak mierzy w biegu?

Precz z grzybami

Wyobramy sobie, e penimy funkcj Naczelnika Jakiej Jednostki Administracyjnej.Najnowsza polityka rzdu kadzie szczeglny nacisk na oczyszczanie lasw z grzybw.

Dlaczego niewane, ale nietrudno sobie wyobrazi Grzyby przecie bywajtrujce, a ludno musi by chroniona przed zagroeniami. Nastpnie jestemy nowo-czesnym europejskim krajem, a grzyby nie maj witamin, nie poddaj si racjonalnejhodowli i wzbudzaj jako pozbawione chlorofilu zastrzeenia wojujcych ro-dowisk wegetariaskich. Poza tym grzyby to pasoyty, co kci si z ideami solidary-zmu spoecznego (lub jest ich zoliw karykatur), a ich preferencje seksualne te s zdaje si nad wyraz nieprawomylne. Niech do grzybw ma wyranie ponad-partyjny charakter, wic lasy maj by odgrzybione, a za dwa dni przyjedzie o czymda nam cynk kolega z Ssiedniej Jednostki Administracyjnej Nadzwyczajna Komisja,eby sprawdzi stan odgrzybienia naszego lasu podmiejskiego. Tak wic mamy SZYBKOOCENI JAKO LASU!

Nie musz dodawa, e dotd w tej sprawie nie zrobiono nic. Gdyby las by ju wcze-niej systematycznie odgrzybiany, nie byoby paniki. Oczywicie identycznie jestz potrzeb szybkiej oceny jakoci aplikacji. Gdyby projekt by od pocztku prowa-dzony porzdnie, jako aplikacji byaby po prostu znana realizowana i mierzonacay czas. C, jednak wiat jest niedoskonay, wic idziemy mierzy w popiechu.

GrzybobranieZasada podstawowa nie da si trafnie oceni stanu zagrzybienia lasu, nie wysyajctam ludzi odpowiednio zmotywowanych, umiejcych szuka grzybw! Mona, rzeczprosta, wysa do lasu krtkowidza, ktry na grzybach si nie zna, dla cakowitej pew-noci mwic mu zowieszczym gosem: Mam nadziej, e przyniesie mi pan DOBRE


19/33


wiadomoci!. Wtedy ocena jakoci lasu bdzie wprawdzie odpowiednio szybka, alecakowicie nietrafna, a nie o to chyba nam chodzi. miejc si z takiej metody, niezapominajmy, e dokadnie tak odbywa si czsto prba szybkiej oceny jakoci apli-kacji jeli nie wykonuj jej fachowi testerzy, odpowiednio nagradzani za przyno-

szenie wieci o bdach, wynik pomiaru jest bezwartociowy.Dobry grzybiarz szuka grzybw tam, gdzie spodziewa si je znale. Wykorzystujcsobie tylko znane intuicje, wie gdzie zwykle rosn kolaki, gdzie rydze, a gdzie opieki,dziki czemu przynosi ich pene kosze. Tak samo dowiadczony tester wykorzystujeswe wczeniejsze dowiadczenia, aby szuka bdy ocenianej aplikacji tam, gdzie spo-dziewa si je znale. Jak rydze lubi rosn pod wierkami, tak bdy lubi si naprzykad gromadzi w pobliu wartoci kracowych, na granicach przedziaw, i do-bry tester tam wanie bdzie ich szuka. Dalej, bdy chtnie dojrzewaj w miejscachodludnych, ktrych nikt od dawna nie testowa, bo kod jest tak zawiy, e lepiej go

nie rusza. Wiemy te, e obecno kilku bdw zwykle oznacza, e jest ich tamo wiele wicej wynikaj bowiem z tych samych bdw projektowania. Kolejnregu streszcza powiedzenie gdzie kucharek sze jeli kod by wielokrotniezmieniany, jeli modyfikowao go wielu programistw warto poszuka bdw.Zasad jest wiele, a profesjonalni testerzy powinni je zna.

Wrmy do podmiejskiego lasu. Dowiadczony grzybiarz szuka grzybw tam, gdziezwykle rosn, ale niekoniecznie tam, gdzie bdzie ich szuka nasza NadzwyczajnaKomisja. Jeli czonkowie Komisji s agodnymi, leniwymi grubasami, zadowol sipobienym sprawdzeniem bezporedniej okolicy wygodnych cieek i tam wanie

wbrew instynktowi grzybiarza trzeba przeszuka teren szczeglnie starannie.Jeli w skad Komicji wchodz ambitne, mode wilki, bd si stara wykaza, szu-kajc w nietypowych miejscach nieche wic grzybiarze strwoonego NaczelnikaJednostki na wszelki wypadek przepatrz miejsca pod kamieniami, wrd gstych krza-kw czy w inne, do ktrych podejrzewamy, e chtnie skieruj si mode wilki.

Przenoszc si na chwil z powrotem w dziedzin oceny jakoci aplikacji, naley oce-nia przede wszystkim to, czym najczciej posuguj si uytkownicy kocowi. Skoronie ma si do dyspozycji dostatecznie dugiego czasu, aby oceni wszystko, warto skon-centrowa si na obszarach, gdzie z racji intensywnego uytkowania prawdopo-

dobiestwo awarii, jeli s tam bdy jest najwysze. Dziki temu jako aplikacji mierzona rednim czasem midzy awariami bdzie wysza, oczywicie przyzaoeniu, e znalezione podczas oceniania bdy bd te usuwane.

Grzyb grzybowi nierwny. Doniesiono Naczelnikowi Jednostki, e Komisja jest szcze-glnie uczulona na muchomory sromotnikowe, pewnie ze wzgldu na ich ksztat. Dla-tego naczelnik uczula swoich grzybiarzy, aby szukali wbrew swoim naturalnym,grzybiarskim instynktom wanie sromotnikw. Tak samo przy szybkiej ocenie ja-koci aplikacji koncentrujemy si na tych bdach, ktrych skutki z punktu widzeniauytkownikw s szczeglnie ze, a mniej czasu powicamy bdom, o ktrych wia-domo, e jeli nawet gdzie s nie bd dla uytkownikw zbyt dotkliwe.

W rodku lasu jest ostaniec pionowa, kilkunastometrowa skaa. Moe na jej szczyciete rosn jakie grzyby, a ktry z czonkw Komisji uprawia sporty ekstremalne i tamsi wdrapie? Moe, ale z drugiej strony, spenetrowanie wierzchoka skay wymagaoby


20/33


drabin, stray poarnej, kto wie, czy nie helikoptera, co pochonoby znaczn czrodkw dostpnych na szybk ocen jakoci lasu, przez co gorzej zostayby spene-trowane jego atwiej dostpne rejony. W tej sytuacji chyba rozsdniej jednak bdziezostawi w spokoju ska. Tumaczy si potem, e w lesie wprawdzie jest peno grzy-

bw, ale za to wolny od nich jest trudno dostpny ostaniec to nie bdzie brzmiaodobrze.

Std wypywa kolejny wniosek dla oceniania jakoci aplikacji jeli mamy ograniczonezasoby, a sowo szybko oznacza, e brakuje nam najcenniejszego z nich, czyli czasu trzeba uwzgldni, na ile trudne i kosztowne s pewne testy, tak eby dostpne rodkirozdysponowa raczej rwnomiernie, a nie tylko w jednym, szczeglnie zasobochonnymobszarze.

Testowanie uwzgldniajce ryzykoPowysze rozwaania s streszczeniem podejcia znanego jako testowanie uwzgldnia-jce ryzyko (ang. risk based testing). Jeli jako musimy oceni szybko, testujemy (oce-niamy, mierzymy) przede wszystkim to, co najwaniejsze, uwzgldniajc cztery klu-czowe parametry:

Prawdopodobiestwo bdu szkoda czasu, aby szuka bdw tam,gdzie by moe ich nie ma.

Konsekwencje awarii przy ocenie jakoci naley szuka raczej awariikatastrofalnych ni niegronych, kosmetycznych.

Prawdopodobiestwo zastosowania trafniej ocenimy jako, biorc poduwag przede wszystkim to, czym uytkownicy posuguj si na co dzie,ni to, z czego korzystaj raz do roku lub wcale.

atwo testowania przy szybkiej ocenie warto te wzi po uwag,by o ile nie chodzi o awarie katastrofalne raczej unika wikania siw prby oceny tego, czego pomiar jest zbyt kosztowny i czasochonny.

Jakie to atwe...

Warum einfach? Kompliziert geht es auch! powiadaj nasi zachodni ssiedzi. Po-peniam zdaje si bd, przedstawiajc atwo zrozumia przypowie o grzybach za-miast epatowania licznymi skomplikowanymi nazwami i trzyliterowymi skrtami. Prze-czytawszy wstpn wersj artykuu, kto powiedzia to cae testowanie jest w gruncierzeczy bardzo proste. Owszem, jeli wiemy, gdzie rosn grzyby (znamy si dobrzena informatyce, na testowaniu i na projektach informatycznych), jeli znamy dziedzinzastosowania (ocena czstoci zastosowania oraz konsekwencji awarii) oraz techno-logi testw (ocena atwoci testowania). Przydaje si te nieza znajomo technikpomiaru oraz analizy ich wynikw, troch statystyki POZA TYM caa reszta torzeczywicie odrobina zdrowego rozsdku.


21/33


Bilet do Davos

Cae kosze usunitych z lasu grzybw wywieziono daleko czy mona spokojnieoczekiwa inspekcji? Czy moe mimo wszystko lepiej zarezerwowa dla siebie i ro-

dziny miejsca w samolocie do Szwajcarii i skromny apartament w Davos, na wypadekgdyby Nadzwyczajna Komisja jaki duy grzyb jednak wykrya?

Trudno powiedzie testowanie uwzgldniajce ryzyko pozwala skutecznie znaj-dowa bdy, nawet w popiechu do trafnie oceni jako aplikacji, ale nigdy niewie si dokadnie, na ile jest ono dokadne: czy czasem mimo stara jakafunkcja nie zostaa pominita, jaka cz systemu zapomniana? eby t pewnouzyska, naleaoby wrmy do historii o lesie wzi dokadn map lasu, po-dzieli j na kwadraty i cay las systematycznie przeczesa. Wprawdzie wiele z miejsc zi-dentyfikowanych tym sposobem byoby zupenie bezsensownych, na przykad plaa,gdzie jako ywo grzyby nie rosn, lub rodek bagna, gdzie komisja nigdy nie dotrze,ale jest to koszt systematycznoci, cena za ubezpieczenie od skutkw przeoczenia lubzapomnienia.

W odniesieniu do oceny jakoci aplikacji odpowiednikiem mapy jest model dziaanialub struktury aplikacji, a odpowiednikiem dzielenia mapy na kwadraty projekto-wanie testw z modelu za pomoc algorytmu. To jest konieczne, aby mc oceni takzwane pokrycie testowe, a wic oszacowa niezawodno wykonanych ocen, ale na toprzy ocenie szybkiej nie mamy zwykle czasu. Jedno jest wic pewne ocena szybka

jest zawsze mniej pewna ni ocena spokojna, oczywicie pod warunkiem starannocijednakowej w obu przypadkach.

Jak spieszy si powoli

Spieszc si, nie trzeba rezygnowa z mylenia. Nie chodzi przecie o to, by wyko-nywa mnstwo szybkich, nerwowych ruchw, gono krzycze przez kilka na raztelefonw i pracowa nieefektywnie po dwadziecia godzin na dob, tylko o to,by mimo popiechu pozosta skutecznym i skoncentrowanym na celu.

Pogodzi popiech ze spokojn systematycznoci usiuj metodyki systematycznegotestowania w popiechu (tak celnie okreli je dr Lucjan Stapp z Politechniki Warszaw-skiej w swym wystpieniu na jednym z zebra Stowarzyszenia Jakoci SystemwInformatycznych).

Jedna z nich to testowanie eksploracyjne (ang. exploratory testing): zesp technikwspomagajcych testerw w sytuacji na pozr beznadziejnej, kiedy jednoczenie trzebauczy si aplikacji, wykonywa testy i projektowa nowe zadania testowe. Za pomocszeregu kreatywnychsposobw przydatnych take wwczas, gdy popiech niejest a tak wielki projektuje si nowe testy na podstawie obserwacji i analizy wy-nikw testw wanie wykonywanych. Jednym sowem, podejcie eksploracyjne po-prawia skuteczno testw wtedy, gdy nie ma czasu, by je starannie zaplanowa, tylkotrzeba strzaem z biodra szybko oceni jako aplikacji.


22/33


Czciowo odmienne podejcie prezentuje testowanie zwinne(ang. agile testing). Jegopodstawa to zasada testowania parami: testerzy pracuj w dwuosobowych zespoach,testy wykonuj wsplnie. Takie podejcie budzi uzasadnione wtpliwoci, czy nie jestpo prostu dublowaniem kosztw, ale praktyczne dowiadczenia sugeruj, e faktycz-

nie pozwala na wiksz skuteczno.Kilka lat temu gono byo o metodyce programowania ekstremalnego (ang. extremeprogramming), gdzie programici pracuj w parach, zamieniajc si pisaniem kodui przygotowywaniem (automatycznych) testw dla tworzonego wanie kodu. Progra-mowanie ekstremalne postuluje ponadto ograniczenie do minimum tradycyjnej, ci-kiej dokumentacji, blisk wspprac programistw z przedstawicielami klienta, czste nawet kilka razy na dzie budowanie caego systemu. Z jednej strony progra-mowanie ekstremalne obiecuje wprawdzie nisz czasochonno projektw, czym pasujedo naszego tematu; z drugiej strony postuluje przygotowywanie testw oceniaj-

cych jako, jeszcze zanim powstanie kod, co nie do koca ju zgadza si z paradyg-matem szybkiej oceny jakoci aplikacji.

Wszystkim, ktrzy szukaj cudownych drg na skrty i sposobw, jak szybko wy-kona to, co najlepiej wykonywa spokojnie, dobrze w tym miejscu przypomniebajk o wiu i o zajcu.

4.3. Po co mierzy?

Miary w inynierii oprogramowaniaMiary czsto kojarz nam si z czym pozytywnym; mwi si: umiarkowany, miar-kowa,zna miar, na miar, miarowo.

Z drugiej strony, brak miary te chwilami brzmi obiecujco, jak w sowie bezmierny.

Miary s niebezpieczne dla tych, ktrzy usiuj co ukry, wol mtniactwo i niejed-noznaczno od precyzji. Miary trzeba dobrze rozumie, tak wic niektrym ludziomwydaj si one niebezpieczne; wedug Flawiusza to Kain wynalaz miary i wagi,zmieni ow niewinn i szlachetn prostot, w jakiej yli ludzie, pki ich nie znali,w ycie pene oszustwa2.

Miary, ktre znamy na co dzie, wydaj si oczywiste, ale nie ma nic oczywistego w tym,aby od prostego zimno, rednio i ciepo przej do skal, gdzie wartoci liczboweprzypisywane temperaturze powietrza odnoszone s do dugoci supka rtci zamknitejw szklanej rurce. Fakt, e istniej trzy rne, powszechnie stosowane skale tempera-tury: Fahrenheita, Celsjusza i Kelvina, z ktrych kada ma punkt zerowy przy innejtemperaturze, a dwie pierwsze rni si rozmiarem jednostki skali, wskazuje, e miarynie s niczym oczywistym, e s przyjmowanym czciowo arbitralnie sposobem od-wzorowania natenia pewnych atrybutw rzeczywistoci oj, to brzmi bardzo na-ukowo, ale ma konkretny, praktyczny sens.

2Jzef Flawiusz, Staroytnoci ydowskie,I.2.2, wyd. polskie: Warszawa 1962, s. 105 cytat wg prezentacji

Andrzeja Kobyliskiego na Konferencji SJSI, Serock, maj 2005.


23/33


Inynieria zestaw zdefiniowanych, powtarzalnych technik projektowania, wytwa-rzania i utrzymania rozmaitych rzeczy nie moe istnie bez pomiarw. Trudnowyobrazi sobie inyniera, ktry nie umie mierzy dugoci, ciaru, napicia czynatenia, albo lekarza bez termometru i narzdzi do precyzyjnego pomiaru chemicz-

nego skadu krwi. Jedynie inynieria oprogramowania choruje na brak umiejtnocipomiaru nie tylko wasnych procesw, ale nawet produktw!

Czego nie mona zmierzy, tego si nie wie

Zapyta kto jakie to ma znaczenie? Czy to kolejna z wielu md, kolejne goosownetwierdzenie, jakoby co bardzo zego dziao si z przemysem informatycznym, pod-czas gdy goym okiem wida, e dzieje si cakiem dobrze?

Dobrze zaley w odniesieniu do czego. W porwnaniu z przemysem elektronicznymprzyrost wydajnoci w produkcji oprogramowania jest od wielu lat skromny. Produktyprogramistyczne czsto okazuj si zawodne, a ich spektakularne niepowodzenia jakna przykad osawione dwuletnie opnienie oddania do uytku lotniska w Denverw 1995 roku z powodu przekroczenia terminu dostawy oprogramowania systemu ba-gaowego przechodz do legendy. Wielkie jest zrnicowanie produktywnoci pro-gramistw w rnych firmach i projektach wedug niektrych danych rnice wy-nosz nawet 600:1 (szeset do jednego, to nie jest bd w druku).

Jednoczenie tu akurat brana informatyczna niczym specjalnym si nie wyrnia

goosowne twierdzenia i slogany wystpuj masowo. Nasze najnowsze technikigwarantuj 100% wzrostu produktywnoci, uycie narzdzi pozwoli skrci testo-wanie o przykady mona mnoy. Czego nam brakuje, by mc przeciwstawiwiedz prbom manipulacji? Systematycznego stosowania pomiarw i dostpu do ichwynikw.

Planowanie projektw informatycznych okazuje si w praktyce niejednokrotnie zwy-kym wreniem z fusw. Jak oszacowa pracochonno projektu produkcji opro-gramowania, ktrego wymagania s opisem sowno-muzycznym? Nieatwo na takiejpodstawie oszacowa wielko produktu, na przykad w formie liczby wierszy kodu,

a nawet majc do dyspozycji takie oszacowanie, nie ma prostej i godnej zaufania metody,aby przeoy je na liczb koniecznych osobodni.

Brak umiejtnoci mierzenia powoduje, e jakiekolwiek dyskusje porwnujce zaletyi wady rnych metod, technik, jzykw programowania i modelowania cierpi na chro-niczn dowolno, na odwoywanie si do anegdotycznych, statystycznie nieistotnychprzykadw. Nie umiejc mierzy przebiegu projektw, nie potrafimy na dobr spra-w nimi zarzdza. Intuicja, objawienia, i-cing wszystko to bardzo ciekawe metodypod warunkiem, e uzupeniajproces decyzyjny i przewidywania oparte na pomia-rach, a nie usiuj jezastpowa.Zarzdzanie ryzykiem staje si fikcj, jeli ani nie

potrafimy zagroe zidentyfikowa, ani oszacowa kosztw zapobiegania, ani oceniich prawdopodobiestwa. W opublikowanym niedawno artykule napisaem, e w prze-myle informatycznym chtnie udajemy kierowcw Formuy 1 oraz dzielnych prze-wodnikw, nie majc niezbdnych ku temu umiejtnoci mierzenia.


24/33


Jak nauczy si trudnej sztuki wykonywania pomiarw i analizy ich wynikw? Jak nieda si w przyszoci zagada elokwentnym zwolennikom Jedynie Susznej Drogi, czybdzie ni czysty Brak Procedur, czy ISO 9000, czy CMM, czy cokolwiek innego, tylkodoj samodzielnie do wasnych wnioskw, wybiera to, co rzeczywicie najlepsze dla

nas i naszych firm?Doskonaym, praktycznym przewodnikiem jest wydana pod koniec ubiegego rokuksika3dr. Andrzeja Kobyliskiego z SGH pod niezbyt chwytliwym marketingowotytuem Modele jakoci produktw i procesw programowych. Nazwabym j chtniejInformatyk mierzy.

Ksika

Pierwsza, podstawowa zaleta omawianej ksiki dla praktykw informatyki to jej przy-stpno. Cho jest to pozycja naukowa, akademicka, jednak zarwno jej jzyk, jaki zorientowany na praktyczne potrzeby tryb wykadu umoliwiaj skuteczn lekturtake osobom majcym gwnie praktyczne dowiadczenia informatyczne.

Jakoto pojcie kluczowe dla praktyki informatycznej, a mimo to niebezpiecznieniejednoznaczne. Cho definicji jakoci jest wiele, a kada zasuguje na osobn mo-nografi, istnieje przecie dua, niezaspokojona potrzeba jednoznacznego okreleniajakoci tak, by mc j mierzy, ocenia, porwnywa, zapisywa w kontraktach i wy-maganiach. W jaki sposb jako wpisuje si w praktyk projektu informatycznego totematyka pierwszej czci ksiki.

Cz druga dotyczy jakoci produktu. Omawia atrybuty jakoci produktw, zale-noci midzy nimi oraz sposoby ich pomiarw. To tematyka o duym znaczeniu dlawszystkich udziaowcw projektu informatycznego. Niedostatki wiedzy na ten tematpowoduj, e klienci niejasno i niepoprawnie okrelaj swoje wymagania, analitycysystemowi sporzdzaj niepene modele, inynierowie jakoci maj problemy z jed-noznaczn ocen jakoci gotowego lub budowanego wanie produktu.

Jeli w projektach zdarzaj si kopoty, prbuje si je rozwizywa, usprawniajc pro-cesy i procedury. Jest wiele rnych modeli, jak postpowa, aby okreli i wdroyusprawnienia, a kady z nich ma swoich zwolennikw i przeciwnikw. Czym si odsiebie rni, ktry najlepiej pasuje do naszych potrzeb? Nie jest to pytanie teoretyczne.Zmienia si rodowisko, w ktrym firmom przychodzi dziaa i konkurowa, wicfirmy musz take si zmienia, by sprosta nowym wyzwaniom. Rne s przyczynyi cele zmian, a udoskonalenie sposobu pracy jest jednym z waniejszych. Prba udo-skonalenia moe zakoczy si trojako:

3Andrzej Kobyliski Modele jakoci produktw i procesw programowych, Szkoa Gwna Handlowa

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


25/33


Rysunek 4.3.1.Koszty zmiany w czasie

SKUTECZNOI SPRAWNO

CZAS

Stanpocztkowy

Analizazmiany

Wdraaniezmiany

Sukces

Niepowo-dzenie

Klska

Aby zmniejszy ryzyko niepowodzenia, trzeba sprawnie przeprowadzi analiz mo-liwej zmiany oraz skutecznie zrealizowa jej wdroenie. Jak posi niezbdn do tegocelu wiedz? Czytajc cz trzeci ksiki, gdzie znajdziemy zarwno przegld ist-niejcych, znanych metod oceny i doskonalenia procesw, jak i porwnanie wynika-jcych z nich korzyci oraz zagroe.

Tematyka budzca spore emocje, a przy tym znaczca dla powodzenia projektw orazfirm, to kwestia relacji midzy udoskonalaniem procesw a jakoci produktw. Kadypewnie sysza sarkastyczne historyjki o wdroeniach certyfikatw ISO 9000, wyma-gajcych jakoby jedynie naklejenia karteczek z nazw na wszystkie znajdujce si w fir-

mie przedmioty, mnocych zbdn papierologi i nieprzekadajcych si w aden sposbna jako produktw. Na przykad synny Tom DeMarco jest sceptycznie usposobionydo korzyci pyncych z osigania wyszych poziomw CMM, twierdzc, e prowadzito wycznie do polepszenia chwilowej sprawnoci kosztem zmniejszenia elastycznocii utraty strategicznej efektywnoci.

Cz czwarta ksiki powicona jest temu wanie zagadnieniu ujtemu w unikalny,wasny sposb autora.

Podsumowujc ksika Andrzeja Kobyliskiego to pozycja, ktr kady meneder

firmy czy kierownik projektu informatycznego bdzie czyta z duym zainteresowaniem,a naley j take poleci inynierom jakoci oraz inynierom testw. Bo przecie, ebymwi o jakoci, trzeba j umie mierzy, test jest za podstawowym sposobem pomiaru!

4.4. Midzy biurokracj a chaosem: ADP

KopotKiedy byem dzieckiem, przeyem okres fascynacji robieniem na drutach. Opanowawszysztuk zaptlania kilku rodzajw oczek, stworzyem co na ksztat dugiego na metr,nierwnego szalika skadajcego si z bezadnej mieszanki wzorw i oczek. Nie daosi tego do niczego uywa i zaraz potem porzuciem krtkotrwae zamiowanie.


26/33


Podobnie, cho nie a tak le, wygldao tworzenie oprogramowania w pierwszychdwch dekadach istnienia komputerw. Przedsiwzicia informatyczne (ang. projects)byy chaotyczne i nieplanowe, nie stosowano systematycznej inynierii wymaga (ang.requirements engineering), kod tworzono bez uprzedniego projektowania (ang. design),

wic produkt kocowy zwykle nie mia trafnej funkcjonalnoci, nie by wygodnyw uytkowaniu ani atwy w utrzymaniu.

W roku 1968 podczas konferencji inynierii oprogramowania NATO (NATO SoftwareEngineering Conference) termin inynieria oprogramowania po raz pierwszy pojawisi oficjalnie [1]. Doczekao si uznania twierdzenie, e tworzenie oprogramowaniato co wicej ni zgodne z reguami jzyka programowania stawianie szeregu instrukcji;e istniej systematyczne, zdyscyplinowane i mierzalne metody wykonywania tegoprocesu.

Wkrtce 7 padziernika 2008 r. [2] przyjdzie nam zatem obchodzi 40. rocznictego wydarzenia4. Gdzie inynieria oprogramowania znajduje si dzisiaj?

Akcja i kontrakcja

Na poziomie kodowania (implementacji) i czciowo take projektowania zaszy ogromnezmiany. Od paradygmatu GOTO, przez metody strukturalne, przez nieudane prby j-zykw 4. generacji, przemys informatyczny wszed w er metod i jzykw obiektowych.

Od tworzenia kadej aplikacji niemal od zera, przez biblioteki funkcji, dotarlimydo hierarchii klas, bibliotek czonych dynamicznie [3] i wielojzykowej platformyCORBA [4]. Od niewydarzonego, topornego interfejsu wierszowego [5] przeszlimydo znacznie wygodniejszych interfejsw graficznych [6]; zaczto te coraz systema-tyczniej uprawia inynieri interakcji [7].

Mniej radykalne przemiany zachodziy na wyszych poziomach procesu: projektowa-nia architektury, inynierii wymaga oraz testowania, ale i tutaj mona bez wtpieniawskaza wiele nowych metod, modeli oraz narzdzi.

Dzi w porwnaniu z sytuacj sprzed 40 lat mamy wic do dyspozycji o wielewicej znacznie potniejszych sposobw pracy, dziki ktrym daje si tworzy pro-dukty coraz bardziej zoone coraz szybciej.

W tyle za rosnc skutecznoci i sprawnoci metod technicznych pozostawaa i po-zostaje nauka o zarzdzaniu przedsiwziciami. Nasza wiedza o tym, jak optymalnieorganizowa przedsiwzicia informatyczne, jak dobiera oraz wiza ze sob metodyi narzdzia, uwzgldniajc rodzaj produktu, wymagania niezawodnoci oraz szereg czyn-nikw ludzkich, wci pozostaje w powijakach. Pojawio si i zyskao krtkotrwasaw wiele nowoci: gono byo raz o TQM, kiedy indziej o clean-room softwareengineering, o technikach przyrostowych, o daily build, o modelowaniu obiektowym,o RUP nazwy mona mnoy. Narastajca zoono i ociao modeli proceswwytwarzania oprogramowania spowodowaa kontrakcj: od okoo 15 lat coraz wikszpopularnoci ciesz si metodyki lekkie i zwinne (ang. agile[8]).

4Esej napisany we wrzeniu 2007 roku.


27/33


Procesy zarwno cikie, jak i zwinne nie s jednak dane raz na zawsze, po-winny si zmienia. Jak mierzy i ocenia, a w miar potrzeby zmienia, udoskonala,usprawnia nasze procesy? Powsta szereg metametodyk (metodyk usprawniania metodyk),ktre mona podzieli na dwie wielkie stronnictwa: metametody cikie i metametody

lekkie (terminologia wasna autora artykuu).

Metametody cikie: rezerwat lenych dziadkw

Cikich, rozbudowanych metod mierzenia i udoskonalania procesw jest wiele; wy-mieniamy je poniej. Pozwalam sobie w odniesieniu do nich uywa zoliwego okre-lenia rezerwat lenych dziadkwze wzgldu na ich skonno do odrywania nadbudowyod bazy (samemu bdc niewtpliwym lenym dziadkiem, mam jak wida skonnodo uywania terminologii z minionych epok, nie tylko w informatyce). Cikie metody

postuluj budow i utrzymywanie ogromnego aparatu nadzorujcego, przez co wyma-gaj znacznych zasobw i nakadw, a ich stosowanie w praktyce przedsiwzi in-formatycznych powoduje due spowolnienie procesu i niech jego uczestnikw. Stdsyndrom rezerwatu: ambitne, rozbudowane metodyki yj yciem niezalenym odrealiw projektw.

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

To imponujca i grona lista skrtowcw ze szczegami oraz praktyk mona sizapozna midzy innymi na spotkaniach sieci SPIN (Software Process ImprovementNetwork, www.spin-pl.org) w Gdasku, Krakowie, Szczecinie, Warszawie i weWrocawiu5.

Metametody lekkie: rezerwat modych wilkw

Metody lekkie mona podsumowa naraajc si na zarzut niejakiej przesady jakominimalizowanie wszelkich dziaa oprcz czysto konstrukcyjnych. Czyli w pewnymstopniu nastpuje odwrcenie sytuacji: zamiast rezerwatu lenych dziadkw mamyrezerwat modych wilkw, ktre z bogosawiestwem swoich prorokw biuro-kracji metod cikich przeciwstawiaj zorientowane na skuteczno konkretnego pro-jektu podejcie na skrty. Przykady takich metod to XP (eXtreme Programming), me-todykiAgile (np. Agile SCRUM), metody ewolucyjne (iteracyjne), prototypowanie, dailybuild, RAD (ang.Rapid Application Dev

Documents

Inżynieria oprogramowania. Jak zapewnić jakość tworzonym aplikacjom