Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00059 006196 12446881 na godz. na dobę w sumie
Inżynieria oprogramowania. Jak zapewnić jakość tworzonym aplikacjom - książka
Inżynieria oprogramowania. Jak zapewnić jakość tworzonym aplikacjom - książka
Autor: , Liczba stron: 328
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-1948-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Twórz rozwiązania najwyższej jakości!

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ń.

Spraw, aby Twoje aplikacje były najwyższej jakości!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

In¿ynieria oprogramowania. Jak zapewniæ jakoœæ tworzonym aplikacjom Autorzy: Bogdan Bereza-Jarociñski, Boles³aw Szomañski ISBN: 978-83-246-1948-1 Format: 158235, stron: 328 Twórz rozwi¹zania najwy¿szej jakoœci! • Ile kosztuje najwy¿sza jakoœæ? • Jak j¹ zapewniæ? • Jakie znaczenie ma bezpieczeñstwo informacji? In¿ynieria oprogramowania jest niezwykle obszern¹ dziedzin¹ wiedzy, zajmuj¹c¹ siê wszelkimi aspektami produkcji oprogramowania. Obejmuje zagadnienia takie, jak analiza, projektowanie czy te¿ wdro¿enie systemu informatycznego. Je¿eli kiedykolwiek spotka³eœ siê z oprogramowaniem miernej jakoœci, niew¹tpliwie na którymœ z etapów jego produkcji pojawi³ siê problem. Jak temu zapobiec? O tym w³aœnie traktuje ta ksi¹¿ka. Dowiesz siê z niej, jak unikaæ b³êdów, tak aby oprogramowanie, które wytworzysz, prezentowa³o najwy¿sz¹ jakoœæ! Poznasz podejœcie do kwestii jakoœci w czasach wspó³czesnych oraz zobaczysz, jak temat ten by³ rozumiany wczeœniej. Zdobêdziesz wiedzê na temat miar u¿ywanych w in¿ynierii oprogramowania oraz najefektywniejszych metod i technik jego wytwarzania. Autor przedstawi Ci równie¿ narzêdzia, które sprawi¹, ¿e Twoje rozwi¹zania stan¹ siê jeszcze lepsze. Ponadto zobaczysz, jak wa¿ne s¹ tematy zwi¹zane z bezpieczeñstwem informacji. Warto podkreœliæ, ¿e styl tej ksi¹¿ki ³¹czy lekkoœæ i przyjemnoœæ lektury z powa¿n¹ tematyk¹ poruszanych w niej zagadnieñ. • Jakoœæ integralna • Zarz¹dzanie ryzykiem • Zarz¹dzanie procesami • Cena jakoœci • Spojrzenie na jakoœæ wczoraj, dziœ i jutro • Zarz¹dzanie jakoœci¹ • Socjologiczne i antropologiczne podejœcie do jakoœci • Certyfikacja w in¿ynierii oprogramowania • Najlepsze metody oraz techniki • Dostêpne narzêdzia, automatyzacja testów • Istota bezpieczeñstwa informacji Spraw, aby Twoje aplikacje by³y najwy¿szej jakoœci! Spis treĈci Rozdziaä 1. RozwaĔania wstöpne ...................................................................... 13 1.1. Nietypowa ksiąĪka: o jakoĞci na wesoáo ............................................................... 13 1.2. JakoĞü integralna .................................................................................................. 13 1.3. JakoĞü przedsiĊwziĊü ............................................................................................ 14 Przykáad ........................................................................................................... 15 Zarządzanie projektami ................................................................................... 15 Zarządzanie procesami .................................................................................... 15 Zarządzanie celami biznesowymi .................................................................... 15 Zarządzanie jakoĞcią ........................................................................................ 16 1.4. Podejmowanie decyzji i zarządzanie ryzykiem .................................................... 17 Podejmowanie decyzji i zarządzanie ryzykiem, czyli wykorzystanie intuicji i racjonalnoĞci .................................................. 17 Brakuje jednak podejĞcia integralnego ............................................................ 17 Intuicji trzeba daü szansĊ! ................................................................................ 18 MoĪna siĊ nauczyü, jak wykorzystywaü w praktyce najlepsze Ğrodki z dwojga Ğwiatów .......................................................................................... 18 1.5. Zintegrowane zarządzanie celami biznesowymi ................................................... 19 Budowanie siáy i powodzenia firmy na rynku ................................................. 19 Elementy jakoĞci integralnej ............................................................................ 20 1.6. Zarządzanie procesami ......................................................................................... 21 Sukces w systematycznym doskonaleniu organizacji ...................................... 21 Na początku byá chaos ..................................................................................... 22 Opáaca siĊ praca dobrze zorganizowana .......................................................... 22 Drugi brat ........................................................................................................ 23 Zarządzanie procesem biznesowym ................................................................ 23 Rozdziaä 2. Dialektyka jakoĈci .......................................................................... 25 2.1. Dlaczego jakoĞü siĊ opáaca? ................................................................................. 25 2.2. Komu bije jakoĞü? ................................................................................................ 26 Dwaj stolarze ................................................................................................... 26 Gorsze jest lepsze? ........................................................................................... 27 Czy stolarz zatrudni testera? ............................................................................ 28 SpecjalnoĞü: testowanie programów ................................................................ 29 JuĪ staroĪytni Grecy… .................................................................................... 29 Miliardy, co z dymem poszáy .......................................................................... 30 Nie trzeba katastrofy ........................................................................................ 30 Jak to sprzedaü? ............................................................................................... 31 Komu bije jakoĞü? ........................................................................................... 32 6 InĔynieria oprogramowania. Jak zapewniè jakoĈè tworzonym aplikacjom 2.3. Pocaáunek Īycia — transfuzja krwi dla informatyki ............................................. 32 MyĞli przewodnie ............................................................................................ 32 Testowanie wymaga celu ................................................................................. 33 Skutek zaleĪy od celu ...................................................................................... 33 FachowoĞü moĪe zaciemniaü gáówne cele ....................................................... 33 Testujmy funkcje, a nie programy ................................................................... 34 RozbieĪne cele mogą spowodowaü nieporozumienie ...................................... 34 Sprzeczne miary jakoĞci .................................................................................. 34 Weryfikowaü czy aktualizowaü? Test jest postawą mentalną .......................... 35 JakoĞü produktu — to tylko początek .............................................................. 35 Naturalna ewolucja — tester perfekcyjny ........................................................ 35 Testowanie w psychologii ............................................................................... 37 Teorie testowania w socjologii: naukowa weryfikacja .................................... 37 Kryteria normalnoĞci — co jest normalne? ..................................................... 38 Pomiary ludzi ................................................................................................... 39 JakoĞü w przemyĞle farmaceutycznym ............................................................ 39 Testowanie w swataniu .................................................................................... 42 Audyt finansowy ............................................................................................. 44 Testowanie w przemyĞle budowlanym ............................................................ 44 Testowanie w przemyĞle samochodowym ....................................................... 46 Testowanie w krawiectwie .............................................................................. 48 Testowanie w sztuce ........................................................................................ 49 ĩycie to testowanie .......................................................................................... 50 Bibliografia ...................................................................................................... 53 2.4. InĪynieria jakoĞci — nauka czy szarlataneria? ..................................................... 54 Reguáy naukowego rozumowania .................................................................... 54 Ludzkie poznanie ............................................................................................. 55 WaĪnoĞü i weryfikacja wiedzy ........................................................................ 56 Wybór wáaĞciwej metody weryfikacji ............................................................. 60 Wykroczenia przeciw metodom naukowym .................................................... 61 RóĪne populacje w badaniach QA ................................................................... 65 BáĊdy obserwatora i skutki oczekiwania .......................................................... 66 Testowanie hipotez .......................................................................................... 66 Wiele uczestniczących zmiennych .................................................................. 67 Konsekwencje i moĪliwoĞci ............................................................................ 68 Czy testowanie oprogramowania jest nauką? .................................................. 68 Zalecenia ......................................................................................................... 69 Proces kontra jakoĞü produktu ......................................................................... 71 Negatywne skutki systemów jakoĞci ............................................................... 72 Bibliografia ...................................................................................................... 73 Rozdziaä 3. JakoĈè wczoraj, dzisiaj i jutro ......................................................... 75 3.1. Historia podejĞcia do jakoĞci (od Hammurabiego do Gatesa) .............................. 75 Definicje jakoĞci .............................................................................................. 75 JakoĞü we wspólnotach pierwotnych ............................................................... 76 JakoĞü w staroĪytnoĞci ..................................................................................... 77 JakoĞü w Ğredniowieczu i w okresie odrodzenia .............................................. 81 JakoĞü w XIX wieku ........................................................................................ 84 JakoĞü w XX wieku ......................................................................................... 85 Zmiany w historii jakoĞci ................................................................................ 89 JakoĞü w informatyce ...................................................................................... 91 Jaką drogą poszáo oprogramowanie ................................................................. 92 Bibliografia ...................................................................................................... 93 Spis treĈci 7 3.2. PĊdzi parowóz historii: 20 lat przemian w informatyce ........................................ 94 Od sierpa i máota do Internetu ......................................................................... 95 Powolne zwyciĊstwo uĪytecznoĞci .................................................................. 96 Szybciej, wiĊcej, dalej ..................................................................................... 97 JakoĞü szyta na miarĊ ...................................................................................... 98 Samoobsáuga .................................................................................................... 99 3.3. W krysztaáowej kuli: inĪynieria oprogramowania za 10 lat ................................ 100 Typowe báĊdy przewidywania ....................................................................... 100 Szybko i intuicyjnie ....................................................................................... 102 Programowanie intencjonalne ........................................................................ 102 Testowanie eksploracyjne .............................................................................. 103 Spirale, iteracje, przyrost ............................................................................... 103 3.4. Szybko, zwinnie, ekstremalnie ........................................................................... 104 JĊzyki programowania ................................................................................... 104 Architektury komponentowe ......................................................................... 105 Sztuczna inteligencja i programy samouczące siĊ ......................................... 105 Podsumowanie: siáa czy inteligencja? ........................................................... 106 3.5. Drogowskaz do przyszáoĞci — mądroĞü bĊdzie na serwerach, czyli ASP .......... 106 Babcia nie potrzebuje komputera ................................................................... 108 Czego potrzebuje babcia autora? ................................................................... 109 Szczegóáy rozwiązania dla babci ................................................................... 109 Z czym nam siĊ to kojarzy? ........................................................................... 112 Kontrowersje ................................................................................................. 113 Jeszcze trochĊ recenzji — walka ze spamem ................................................. 113 Moc jĊzyków ................................................................................................. 114 ZakoĔczenie ................................................................................................... 115 3.6. Y2K — heca czy historia? Wspomnienia Ğwiadka ............................................. 115 Rozdziaä 4. Zarzñdzanie procesami ................................................................. 119 4.1. Zarządzanie jakoĞcią — wáadza i zgieák ............................................................. 119 Jak opanowaü stado bezgáowych kur, czyli zarządzanie konfiguracją ........... 119 Rozmawiaáa gĊĞ z prosiĊciem: raporty i Ğledzenie báĊdów ............................ 120 Krajobraz przed bitwą: planowanie testów, analiza ryzyka ........................... 121 Husaria kontra pruska piechota: jak nie straciü impetu, nie tracąc gáowy? ....... 122 Krajobraz po bitwie: czy moĪna wypuĞciü produkt juĪ jutro? ....................... 123 Obdzieranie polegáych, czyli jak byü mądrym po szkodzie ........................... 124 RóĪne formy organizacji testowania .............................................................. 124 Kiedy zaczynaü, kiedy skoĔczyü? .................................................................. 125 4.2. Znowu ten poĞpiech — jak szybko oceniü jakoĞü aplikacji? .............................. 125 PoĞpiech w informatyce ................................................................................. 125 Pomiary w poĞpiechu ..................................................................................... 126 Precz z grzybami ........................................................................................... 127 Grzybobranie ................................................................................................. 127 Testowanie uwzglĊdniające ryzyko ............................................................... 129 Jakie to áatwe... .............................................................................................. 129 Bilet do Davos ............................................................................................... 130 Jak spieszyü siĊ powoli .................................................................................. 130 4.3. Po co mierzyü? Miary w inĪynierii oprogramowania ......................................... 131 Czego nie moĪna zmierzyü, tego siĊ nie wie ................................................. 132 KsiąĪka .......................................................................................................... 133 4.4. MiĊdzy biurokracją a chaosem: ADP .................................................................... 134 Káopot ............................................................................................................ 134 Akcja i kontrakcja .......................................................................................... 135 Metametody ciĊĪkie: rezerwat leĞnych dziadków .......................................... 136 8 InĔynieria oprogramowania. Jak zapewniè jakoĈè tworzonym aplikacjom Metametody lekkie: rezerwat máodych wilków ............................................. 136 Niedostatki rezerwatów ................................................................................. 137 ADP — nareszcie! ......................................................................................... 137 ADP od Ğrodka .............................................................................................. 138 Zadowoleni ludzie ......................................................................................... 138 Wysoka jakoĞü produktu ................................................................................ 139 Organizacja: wyĪsza produktywnoĞü i sprawnoĞü w dziaáaniu ...................... 139 Proces nadzorowany, udoskonalany i dający siĊ utrzymaü ............................ 139 PrzedsiĊwziĊcie zarządzane poprzez podejmowanie decyzji ......................... 139 Zapobieganie pomyákom i báĊdom ................................................................ 139 Zasady ADP ................................................................................................... 140 Who is who .................................................................................................... 141 Referencje ...................................................................................................... 141 Rozdziaä 5. Socjologia i antropologia jakoĈci .................................................. 143 5.1. InĪynier jakoĞci — to nie brzmi dumnie ............................................................. 143 Kariera testera ................................................................................................ 144 5.2. SamotnoĞü testera: organizacje i konferencje ..................................................... 144 Szkolenia i certyfikaty ................................................................................... 145 5.3. Psychologia projektu .......................................................................................... 146 Przykáad z projektu ........................................................................................ 147 Co wynika z nieporozumieĔ? ........................................................................ 148 KreatywnoĞü .................................................................................................. 149 Negocjacje ..................................................................................................... 149 AsertywnoĞü .................................................................................................. 150 Wystąpienia publiczne ................................................................................... 150 Motywacja i zarządzanie zespoáem ............................................................... 151 Trening antystresowy i zarządzanie emocjami .............................................. 151 Zarządzanie ryzykiem i podejmowanie decyzji ............................................. 152 5.4. Dobre decyzje: intuicja i racjonalnoĞü ................................................................ 153 Streszczenie ................................................................................................... 153 Wprowadzenie ............................................................................................... 153 Na przystawkĊ: trzy krótkie historie, aby skusiü czytelnika .......................... 154 Opowiadanie o wybieraniu metod testowania ............................................... 155 Opowiadanie na temat „Czy jesteĞmy gotowi podjąü decyzjĊ?” ................... 155 Psychologia podejmowania decyzji ............................................................... 156 NieprzechodnioĞü preferencji ........................................................................ 156 Preferencja czasowa i opóĨniona gratyfikacja ............................................... 157 Percepcja prawdopodobieĔstwa ..................................................................... 158 Co to jest testowanie uwzglĊdniające ryzyko? ............................................... 164 Statystyka: podejmowanie decyzji w warunkach niepewnoĞci ...................... 165 Strategie decyzyjne ........................................................................................ 167 Podejmowanie decyzji przy uĪyciu statystyki Bayesa ................................... 168 Bibliografia .................................................................................................... 171 5.5. Psychologia jakoĞci ............................................................................................ 172 Psychologia i socjologia testowania .............................................................. 172 Status tego rozdziaáu ...................................................................................... 172 Dysonans poznawczy .................................................................................... 172 Psychologia testowania .................................................................................. 172 Praca konstruktywna i motywacja ................................................................. 173 BezpieczeĔstwo, niepokój ............................................................................. 174 Przeglądy ....................................................................................................... 174 Dynamika grupowa ........................................................................................ 175 Studium komunikacji ..................................................................................... 175 Hierarchia potrzeb wg Maslova ..................................................................... 176 Spis treĈci 9 Osobiste zainteresowania i cele (teoria Hollanda) ......................................... 176 Wnioski ......................................................................................................... 177 Opis modelu Hackmana ................................................................................. 177 5.6. Czy warto siĊ SPIN-aü? ...................................................................................... 178 Organizacje zajmujące siĊ jakoĞcią w Polsce ................................................ 178 Gdzie jest Forum Romanum? ........................................................................ 179 Quo vadis, udoskonalanie procesów? ............................................................ 180 5.7. W poszukiwaniu idealnych pracowników i szefów ............................................ 181 Jacy są ludzie? ............................................................................................... 181 Mierzenie ludzi .............................................................................................. 182 THOMAS INTERNATIONAL ..................................................................... 184 Zastosowanie THOMAS-a w praktyce .......................................................... 186 Autystyczni testerzy ...................................................................................... 187 Rozdziaä 6. Interakcja, uĔytecznoĈè, wygoda .................................................. 191 6.1. Inwazja szaleĔców .............................................................................................. 191 6.2. Jak ulepszyü Ğwiat? ............................................................................................. 193 Frustracja, poniĪenie, agresja ......................................................................... 193 SzaleĔcy rządzą domem wariatów ................................................................. 194 SzeĞü grzechów gáównych ............................................................................. 194 NieĞwiĊte przymierze .................................................................................... 195 Pomoc nadciąga ............................................................................................. 196 6.3. Psychologiczne podstawy uĪytecznoĞci .............................................................. 196 Stan obecny ................................................................................................... 196 Lista kontrolna niektórych czynników uĪytecznoĞci ..................................... 197 Rozdziaä 7. ēycie towarzyskie i uczuciowe ...................................................... 201 7.1. Adwentowa gwiazda 2003 .................................................................................. 201 Adwentowa gwiazda ...................................................................................... 201 AlboĞmy to jacy-tacy? ................................................................................... 202 ĩycie towarzyskie i uczuciowe ...................................................................... 202 Koniec wojny niemiecko-brytyjskiej ............................................................. 203 O co tyle szumu? ........................................................................................... 203 O chorobie wspóáuzaleĪnienia ....................................................................... 204 7.2. Kupując wiedzĊ: przewodnik po szkoleniach ..................................................... 205 Motto ............................................................................................................. 205 Podstawy ....................................................................................................... 205 PiĊü záotych zasad, jak znaleĨü szkolenie testowe ......................................... 206 7.3. Jak sprzedawaü nietypowe szkolenia? PodrĊcznik cynicznego sprzedawcy ....... 209 Wizja — początki .......................................................................................... 209 PrzynĊta ......................................................................................................... 210 Strategia ......................................................................................................... 211 Motywacja nauczania = dochód z nauczania – alternatywny zysk ................ 211 Planowanie .................................................................................................... 212 Nauczyciele ................................................................................................... 212 Czyniąc karierĊ nauczyciela atrakcyjną ......................................................... 213 Struktura pakietu szkoleniowego ................................................................... 214 Praktyczne techniki szkoleniowe kontra teoria .............................................. 216 ĝwiadectwa i egzaminy ................................................................................. 217 Pakiety — moduáowy model kursu ................................................................ 217 Wykonanie — liczą siĊ praktyczne szczegóáy ............................................... 218 Bóg czy mamona? Zasady czy siáy rynkowe? ............................................... 220 Konkurencja .................................................................................................. 221 Do zapamiĊtania ............................................................................................ 221 10 InĔynieria oprogramowania. Jak zapewniè jakoĈè tworzonym aplikacjom 7.4. Papierki i Ğwiadectwa. Certyfikacja w inĪynierii oprogramowania .................... 222 Sens certyfikacji w przemyĞle informatycznym ............................................ 222 Certyfikacja w dziedzinie zapewnienia jakoĞci i testowania ......................... 223 Rodzaje certyfikatów ..................................................................................... 223 PoĪytki z certyfikatów ................................................................................... 224 ZagroĪenia ..................................................................................................... 224 ASQ Certified Reliability Engineer ............................................................... 225 IEEE Certified Software Development Professional ..................................... 226 QAI (Quality Assurance Institute) ................................................................. 227 Certified Quality Analyst ............................................................................... 227 Certified Software Test Engineer .................................................................. 227 BCS/ISEB: SW Testing Foundation Certificate, SW Testing Practitioner Certificate ............................................................. 227 7.5. ISTQB: certyfikaty miĊdzynarodowe .................................................................... 228 7.6. To po prostu bzdura! ........................................................................................... 229 Wyznania sfrustrowanego trenera jakoĞci ..................................................... 229 Wedáug ISEB i ISTQB… .............................................................................. 230 Jak wybiera siĊ przypadki testowe w rzeczywistoĞci? ................................... 231 Peány obraz .................................................................................................... 233 W koĔcu: przykáad ......................................................................................... 235 Rozdziaä 8. Metody i techniki ......................................................................... 237 8.1. Sztuka, rzemiosáo, nauka .................................................................................... 237 Powiedzmy, Īe zbliĪają siĊ wybory ............................................................... 237 Grupa reprezentatywna .................................................................................. 237 Na tym samym polega testowanie ................................................................. 238 Sztuka ............................................................................................................ 238 Rzemiosáo ...................................................................................................... 239 Nauka ............................................................................................................ 240 8.2. Szlachetna sztuka testowania oprogramowania .................................................. 241 Nowa ksiąĪka ................................................................................................. 241 Klasyka odĞwieĪona ...................................................................................... 242 Nazewnictwo ................................................................................................. 243 8.3. ĩeby banki rosáy w siáĊ, a klienci Īyli dostatniej ................................................ 244 Praca Īmudna, mozolna, ale za to jaka jaáowa! ............................................. 244 Kontrola instalacji wodnej pod ciĞnieniem .................................................... 245 Pociągi pod specjalnym nadzorem ................................................................. 246 Szukanie dziury w caáym ............................................................................... 246 Czego uĪytkownik nie lubi najbardziej? ........................................................ 247 JakoĞü jest za darmo ...................................................................................... 247 8.4. KraĔcowo zwinne eksploracyjne piramidy ......................................................... 247 Historia polityczna ......................................................................................... 247 OstrzeĪenie .................................................................................................... 248 Nowa religia .................................................................................................. 249 Zastosowanie eksploracji ............................................................................... 251 8.5. Cyryl jak Cyryl, ale metody! .............................................................................. 251 Nie warto marnowaü czasu ............................................................................ 251 Ryzyko jest zbyt duĪe .................................................................................... 252 Testowanie — osobna specjalnoĞü? ............................................................... 252 Czy test moĪe siĊ opáacaü? ............................................................................ 253 Rachunek zysków i strat ................................................................................ 253 Kosmiczne pieniądze ..................................................................................... 253 Co przetestowaü, a co zlekcewaĪyü? ............................................................. 253 Sztuka testowania .......................................................................................... 254 Tester jako rzemieĞlnik .................................................................................. 254 Spis treĈci 11 Metody formalne ........................................................................................... 255 Cháop Ğpi, a zboĪe samo roĞnie ...................................................................... 255 Kiedy testowaü? ............................................................................................. 255 Kto bĊdzie testerem? ..................................................................................... 256 Polowanie na pluskwy ................................................................................... 256 Schwytana pluskwa na uwiĊzi ....................................................................... 257 Zaplecze frontu, czyli logistyka testowania ................................................... 257 Test na co dzieĔ ............................................................................................. 258 Rozdziaä 9. Warsztat fachowca ....................................................................... 259 9.1. Automatyzacja testów ......................................................................................... 259 Co to jest automatyzacja testowania? ............................................................ 260 Co znajduje siĊ w skrzynce ze záotem: poĪytki z automatyzacji .................... 260 Gdzie rozmieszczone są miny: niebezpieczeĔstwa automatyzacji ................. 261 Na zakoĔczenie .............................................................................................. 264 9.2. Czy jakoĞü jest za darmo? OpáacalnoĞü automatyzacji ....................................... 264 Krótki poradnik dla szefów dziaáów informatyki .......................................... 264 Przekuwamy infrastrukturĊ na lemiesze ........................................................ 265 Cyryl jak Cyryl, ale metody! ......................................................................... 266 Przez namolnoĞü do pedagogicznego sukcesu ............................................... 266 JakoĞü jest za darmo? .................................................................................... 266 Prosta zasada záotego Ğrodka ......................................................................... 266 Kombajnem przez preriĊ ................................................................................ 267 Potrzeba, jak zwykle, fachowców .................................................................. 268 Sierpy, snopowiązaáki i kombajny ................................................................. 270 Gdzie szukaü dalej? ....................................................................................... 272 Rozdziaä 10. Bezpieczeþstwo informacji ............................................................ 273 10.1. BezpieczeĔstwo informacji: historia i stan obecny ............................................. 273 Wprowadzenie — bezpieczeĔstwo informacji dawniej ................................. 273 Ochrona fizyczna i konstruowanie niezawodnego sprzĊtu ............................ 276 Zapewnienie jakoĞci oprogramowania ........................................................... 277 Zapewnienie bezpieczeĔstwa oprogramowania ............................................. 278 Zapewnienie bezpieczeĔstwa systemów informatycznych ............................ 281 Zarządzanie bezpieczeĔstwem informacji ..................................................... 283 Systemy zarządzania bezpieczeĔstwem informacji wedáug norm ISO serii 27000 .................................................... 284 Próba przewidywania przyszáoĞci .................................................................. 290 Bibliografia .................................................................................................... 292 10.2. Walka z cieniem — zabezpieczenia i odpornoĞü w praktyce .................................. 295 Streszczenie ................................................................................................... 295 Co to jest „bezpieczeĔstwo”? ........................................................................ 295 Definicje bezpieczeĔstwa .............................................................................. 296 Gdzie szukaü báĊdów zabezpieczenia? .......................................................... 297 Testowanie zabezpieczeĔ ............................................................................... 298 Ile testowaü zabezpieczenia? ......................................................................... 298 WraĪliwe czĊĞci ciaáa smoka ......................................................................... 299 UĪytecznoĞü ................................................................................................... 300 Wykonanie ..................................................................................................... 301 Aspekty organizacyjne ................................................................................... 301 Proces testowania bezpieczeĔstwa ................................................................. 302 Monitoring w trakcie dziaáania operacyjnego ................................................ 303 Bibliografia .................................................................................................... 304 Organizacje, firmy, usáugi i normy ................................................................ 305 NarzĊdzia ....................................................................................................... 305 12 InĔynieria oprogramowania. Jak zapewniè jakoĈè tworzonym aplikacjom 10.3. BezpieczeĔstwo — praca u podstaw ................................................................... 306 DuĪo haáasu o bezpieczeĔstwo ...................................................................... 306 BezpieczeĔstwo wielopoziomowe ................................................................. 306 Trzy Ğwiaty bezpieczeĔstwa .......................................................................... 307 Normy, audyt, standardy ................................................................................ 307 Policjanci ....................................................................................................... 307 Testy penetracyjne ......................................................................................... 308 Praca u podstaw ............................................................................................. 308 InĪynieria wymagaĔ bezpieczeĔstwa ............................................................. 308 MoĪliwoĞci analizy statycznej ....................................................................... 309 BáĊdy na poziomie kodowania: testy jednostkowe ........................................ 310 BezpieczeĔstwo czy bezpieczeĔstwo? ........................................................... 310 Profits, stupid! ............................................................................................... 311 Leczyü czy zapobiegaü? ................................................................................ 312 Praca Īmudna, mozolna, za to — jaka jaáowa! .............................................. 312 Skorowidz .................................................................................... 313 Rozdziaä 4. Zarzñdzanie procesami 4.1. Zarzñdzanie jakoĈciñ — 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 ma siĊ wyáoniü Ona: aplikacja-marzenie. BezbáĊdna. Zaspokajająca wszystkie, nawet naj- skrytsze marzenia klienta. Idealna. WaĪną rolĊ w tym procesie odgrywa testowanie. To test powinien ostrzec: „Panowie, mieliĞmy budowaü Wenus, a na razie widzimy tutaj piĊciogáowego wielbáąda!”. Test przypomni, ze bogini piĊknoĞci powinna mieü dwie, nie zaĞ trzy nogi. Test policzy palce u rąk i zawoáa, Īe cztery palce uchodzą w komiksach, ale nie w rzeczywistoĞci. O ile nietrudno odróĪniü piĊciogáowego wielbáąda od Wenus, o tyle báĊdy oprogramo- wania nie zawsze są oczywiste i rzucające siĊ w oczy. Zdemaskowanie ich wymaga skrzĊtnej pracy, wspólnego wysiáku wielu osób, którymi ktoĞ musi zarządzaü i kierowaü. Jak? — o tym wáaĞnie bĊdzie mowa w dalszej czĊĞci rozdziaáu. Jak opanowaè stado bezgäowych kur, czyli zarzñdzanie konfiguracjñ Zgáoszenie báĊdu — dokáadny opis objawów i okolicznoĞci awarii, sporządzony przez testera sporym nakáadem pracy po to, by uáatwiü programiĞcie znalezienie i zlikwido- wanie przyczyny awarii. Programista bardzo siĊ dziwi: przecieĪ ten báąd zostaá usu- niĊty juĪ dwa tygodnie wczeĞniej! „Pewnie uĪyáeĞ záej wersji”—– powiada testerowi. „AleĪ skąd, gáówne okno dialogowe wyĞwietliáo numer najnowszej wersji, Z15” — opo- nuje tester. „Tak, ale to wersja programu gáównego. Ten moduá mógá mieü inną wersjĊ!”. Sprawdzają obaj. Okazuje siĊ, Īe adres 0xA1F0 zawiera wartoĞü 0xE, a wiĊc wersja 120 InĔynieria oprogramowania. Jak zapewniè jakoĈè tworzonym aplikacjom numer czternaĞcie feralnego moduáu. Tester poci siĊ i áączy program ponownie, tym razem z najnowszą wersją. Awaria nie pojawia siĊ wiĊcej: dobrze. Niestety, po dwóch tygodniach powraca! Co siĊ staáo? Po póá dnia dochodzeĔ udaje siĊ ustaliü, Īe nowo zatrudniony programista przez pomyákĊ, áącząc program, znowu posáuĪyá siĊ starą wer- sją feralnego moduáu… Brzmi to znajomo? OczywiĞcie. Mamy tu do czynienia z klasycznymi symptomami niedostatków zarządzania konfiguracją. No, ale co to ma wspólnego z zarządzaniem testami? Jak w opisanym przykáadzie — bardzo wiele. System czy program (zwáaszcza niezbyt skomplikowany) moĪe siĊ niekiedy udaü zbudowaü — kosztem pewnego czasocháonnego zamieszania — mimo braków w zarządzaniu konfiguracją. Natomiast zapewnienie jakoĞci bez dobrze funk- cjonującego zarządzania konfiguracją jest zwykle niemal bezuĪyteczne. Zidentyfikowane przez testerów awarie okazują siĊ albo dotyczyü nieaktualnej wersji, albo wymagają detektywistycznej pracy, aby 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, przez co test tylko w ograniczonym stopniu dostarcza swego najwaĪniejszego produktu: in- formacji pozwalającej na znajdowanie i usuwanie báĊdów. Z tego wáaĞnie powodu czĊsto zespóá testujący, a nie caáy projekt informatyczny, jest gorącym zwolennikiem uporządkowania Ĩle dziaáającego zarządzania konfiguracją. Nie jest to dobre rozwiązanie, ale o wiele lepsze niĪ dobrowolne oddanie siĊ w rĊce cha- osu, marnotrawstwa i baáaganu. Choü wiĊc nie chodzi tu o testowanie sensu stricto, niejednemu kierownikowi zespoáu testującego przyjdzie siĊ z tą problematyką zmierzyü i warto sobie z tego zdawaü sprawĊ. Jak konkretnie siĊ to robi: zarządzanie i kontrolĊ wersji, budowĊ konfiguracji podstawowych (baselines) — to są juĪ zagadnienia na osobny rozdziaá. Rozmawiaäa göĈ 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ąü go i w ten sposób podnieĞü jakoĞü programu. Ani w jednym, ani w drugim przypadku nie wystarczy, by ta wiedza pozostaáa w gáowie testera. Trzeba ją przekazaü programiĞcie, aby rozpocząá poszukiwania przyczyny awarii, oraz kierownikowi projektu, aby mógá sporządziü statystyki báĊdów i oszacowaü bieĪącą jakoĞü konstruowanego systemu. Nawet jeĞli projekt jest jednoosobowy, nie zawsze daje siĊ wszystko zapamiĊtaü i prowadzenie notatek na temat znajdowanych i usuwanych báĊdów pozwala na unikniĊcie pomyáek. Tym celom — przekazywaniu oraz gromadzeniu informacji o awariach i báĊdach — sáuĪą tak zwane raporty albo zgáoszenia báĊdów. Rozdziaä 4. i Zarzñdzanie procesami 121 Niektóre traktujące o testowaniu Ĩródáa (m.in. táumaczona na jĊzyk polski ksiąĪka amerykaĔskiego autora Rona Pattona Testowanie oprogramowania1) poĞwiĊcają wiele miejsca udzielaniu rad, jak powinien postĊpowaü tester, aby dopilnowaü, Īeby znale- ziony báąd rzeczywiĞcie zostaá potraktowany powaĪnie i naprawiony. Takie podejĞcie wydaje siĊ byü stawianiem sprawy na gáowie. Po pierwsze, tester ma inne zajĊcia niĪ zastĊpowanie — niefrasobliwego widaü — kierownika projektu i Ğciganie programistów. Po drugie, taka sytuacja stwarza realne zagroĪenie sprowokowania konfliktów miĊdzy testerami a konstruktorami. Po trzecie wreszcie, tester nie musi mieü i zwykle nie ma peánej wiedzy potrzebnej do prawidáowej oceny wagi znalezionego báĊdu. Do tego konieczna jest — zaleĪnie od rodzaju báĊdu — jeszcze wiedza na temat struktury i prio- rytetów wymagaĔ, potrzeb klienta, architektury systemu. Nie jest wcale oczywiste, Īe kaĪda awaria wymaga natychmiastowego rzucenia wszystkich dostĊpnych Ğrodków w celu jej rozbrojenia i usuniĊcia! To zaleĪy miĊdzy innymi od związanego z nią ryzyka. Do oszacowania ryzyka nie wystarczy zwykle jedna osoba: konieczna jest wspóápraca wielu uczestników projektu, którą umoĪliwiają wáaĞciwie wykorzystane raporty báĊdów. Zorganizowanie procedur zgáaszania i Ğledzenia báĊdów jest jednym z podstawowych zadaĔ kierownika testów. Krajobraz przed bitwñ: planowanie testów, analiza ryzyka Jak powiedziaá generaá, a póĨniej prezydent Eisenhower, wprawdzie planowany prze- bieg wydarzeĔ nigdy siĊ nie sprawdza, ale mimo to ten dowódca, który planowaá naj- staranniej, ma najwiĊksze szanse poradzenia sobie z (niezaplanowaną) sytuacją na polu bitwy. To samo dotyczy testowania. Wiadomo z góry, Īe dostawa do testu systemowego bĊ- dzie opóĨniona — w porównaniu z planem — o dwa miesiące, natomiast data dostawy do klienta nie ulegnie zmianie, przez co na test systemu, zamiast przewidzianych dzie- siĊciu, pozostaną ledwo dwa tygodnie. Wiadomo, Īe jakoĞü pierwszych dostaw bĊdzie taka, Īe wiĊkszoĞü czasu trzeba bĊdzie poĞwiĊciü na podnoszenie zawieszającego siĊ systemu, a nie na wykonywanie przypadków testowych. Oczywiste jest teĪ, Īe znaj- dowane báĊdy spowodują niezaplanowany wzrost iloĞci dostarczanych do testowania wersji programu, przez co czas poĞwiĊcony na ich instalacjĊ i konfigurowanie oraz na testy regresji wzroĞnie — w porównaniu z planem — dramatycznie. Wreszcie wia- domo, Īe proces odpluskwiania (ang. debugging) odciągnie pewną iloĞü testerów na pewien czas od testowania, a ponadto Ğrodowisko testowe bĊdzie — w niezaplanowa- nych wymiarach — zablokowane przez programistów usiáujących odtworzyü awariĊ i zlokalizowaü jej przyczynĊ. Planując, Īe wydarzą siĊ wszystkie te niezaplanowane historie, mamy realne podstawy, by poradziü sobie z wyzwaniem, jakim jest zarządzanie testami! 1 Nakáad obecnie wyczerpany — wrzesieĔ 2008. 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 przeciwnym razie moĪe nas sprowadziü na manowce. ĝledzimy liczbĊ wykonanych przypadków testowych i porównujemy z zaplanowanymi — w ten sposób ewentualne opóĨnienie wyjdzie na jaw od samego początku, a nie dopiero wtedy, kiedy naroĞnie do katastro- falnych rozmiarów. ĝledzimy liczbĊ otwartych, zgáoszonych báĊdów — w ten sposób moĪemy próbowaü oszacowaü iloĞü pozostaáych jeszcze báĊdów, które zapewne wy- száyby na jaw w trakcie dalszego testowania systemu, dziĊki czemu w kaĪdej chwili mamy do dyspozycji dane pozwalające odpowiedzieü na nieuniknione pytanie: co kierownik testów sądzi o tym, Īeby dostawa do klienta miaáa miejsce juĪ pojutrze? skumulowana liczba wykonanych zadaĔ testowych szczĊĞliwy koniec zaplanowana faktyczna nadrabianie start naprawianie báĊdów i testy regresji trudnoĞci, spiĊtrzenie báĊdów czas testowania (znormalizowany) 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 dostawy do klienta.  Zmiana kryteriów jakoĞci — obniĪenie poprzeczki, dopuszczenie do uĪytku systemu mniej przetestowanego albo mającego wiĊkszą iloĞü nierozwiązanych báĊdów.  Wykorzystanie do testowania wiĊkszej iloĞci osób, testowanie równolegáe.  Zamiana funkcjonalnoĞci — dostarczony system nie bĊdzie zawieraá wszystkich wczeĞniej planowanych funkcji.  Podniesienie wymaganej jakoĞci dostaw do testu systemowego — to umoĪliwi sprawniejsze testowanie i przerzuci czĊĞü dziaá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 wykonywania nowych testów po to, by daü programistom szansĊ na usuniĊcie spiĊtrzenia Rozdziaä 4. i Zarzñdzanie procesami 123 i naprawienie jak najwiĊkszej liczby báĊdów. W tym czasie zespóá testowy poĞwiĊca siĊ wyáącznie testowaniu powtarzalnemu dostaw zawierających kolejne poprawki. Krajobraz po bitwie: czy moĔna 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 czai siĊ przecieĪ ryzyko opóĨnienia, kar umownych, niezadowolonych klientów, utraty udziaáów w rynku na rzecz szybszych czy odwaĪniejszych konkurentów. Analiza ry- zyka i podjĊcie decyzji jest w 100 zadaniem dla kierownictwa lub sponsorów pro- jektu, ewentualnie dla dziaáu marketingu. Test ma natomiast za zadanie dostarczyü decydentom jak najprecyzyjniejsze dane dotyczące ryzyka technicznego w oparciu o dotychczasowe wyniki testowania. Istnieje wiele kryteriów oszacowania jakoĞci produktu w oparciu o rezultaty testów. Bierze siĊ na przykáad pod uwagĊ, jaki procent zadaĔ testowych zostaá dotychczas wykonany, 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 nieznanych báĊdów na podstawie funkcji najlepiej pasującej do krzywej okreĞlającej skumulowaną iloĞü dotychczas znalezionych báĊdów. WyjaĞnienie — na ilustracji poniĪej. skumulowana liczba wykonanych zadaĔ testowych szczĊĞliwy koniec zaplanowana faktyczna nadrabianie start naprawianie báĊdów i testy regresji trudnoĞci, spiĊtrzenie báĊdów czas testowania (znormalizowany) 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). 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, bo z 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 kolejne projekty 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óbowaü odpowiedzieü na pytanie, jaka byáa pierwsza przyczyna zaistnienia danego báĊdu? Czy byáy nią niejasno sformuáowane wymagania, czy niedostateczna znajomoĞü jĊzyka przez programistów, czy niedociągniĊcia organizacyjne? Warto teĪ przyjrzeü siĊ statystykom raportów báĊdów. Kiedy pojawiáo siĊ ich najwiĊcej? Jaki byá czas naprawy báĊdu? Ile raportów okazaáo siĊ faászywych? Odpowiedzi na te pytania niejednokrotnie pozwolą zidentyfikowaü sáabe punkty w procesach i procedu- rach projektów lub niedostatki organizacyjne w przedsiĊbiorstwie. RóĔne formy organizacji testowania Nie zawsze jedyną i najlepszą formą organizacji testów jest stworzenie osobnego zespoáu testowego. ZaleĪnie od charakteru projektu, typu produktu, przyjĊtej metodyki wytwa- rzania korzystne moĪe okazaü siĊ zastosowanie innych rozwią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 „Programowaniu Ekstremalnym” (XP, Extreme Programming).  Tester (lub testerzy) są czáonkami zespoáu programistów, podlegają kierownikowi zespoáu lub projektu.  Osobny zespóá testujący mający wáasnego kierownika.  Osobny dziaá w przedsiĊbiorstwie zajmujący siĊ pewnymi rodzajami testów.  Outsourcing testów do innego przedsiĊbiorstwa: stosowane wówczas, gdy wymagana jest niezaleĪna certyfikacja systemu oraz gdy niezbĊdne jest skomplikowane i kosztowne Ğrodowisko testowe (np. w testowaniu konfiguracji, testowaniu zgodnoĞci z wymaganiami Ğrodowiskowymi itp.).  Wybór wáaĞciwej organizacji testowania jest waĪnym zadaniem dla kierownika projektu. Warto pamiĊtaü, Īe w wiĊkszych projektach kilka róĪnych form organizacyjnych moĪe istnieü jednoczeĞnie, na przykáad testowanie koleĪeĔskie na poziomie testów komponentów, odrĊbny zespóá do testu systemowego, outsourcing w celu uzyskania niezaleĪnej certyfikacji. Rozdziaä 4. i Zarzñdzanie procesami 125 Kiedy zaczynaè, kiedy skoþczyè? 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. Walidacja wymagaĔ Specyfikacja wymagaĔ Przygotowanie testów Test akceptacyjny TestowalnoĞü wymagaĔ Przegląd Specyfikacja konstrukcji Test systemu Przygotowanie testów Testy integracyjne Testowanie Przegląd Kodowanie Testy komponentów Rysunek 4.1.3. Przegląd modelu „V” 4.2. Znowu ten poĈpiech — jak szybko oceniè jakoĈè aplikacji? PoĈpiech w informatyce Zrobiü cokolwiek szybko? Znowu ten poĞpiech. Znane jest przecieĪ porzekadáo: „co nagle, to po diable” i niezliczone przykáady sytuacji, kiedy zabrakáo czasu i Ğrodków, aby coĞ wykonaü dobrze, ale znalazáo siĊ potem i jedno, i drugie, aby to coĞ wielo- krotnie poprawiaü. Informatyka to branĪa cierpiąca od swego powstania na syndrom czarodziejskiej plasteliny. Kilkadziesiąt lat temu udaáo siĊ ludziom speániü swe odwieczne marzenie i znaleĨü substancjĊ, z której daje siĊ szybko i áatwo zbudowaü wiele najroz- maitszych rzeczy: a to system bazodanowy, a to telefoniĊ komórkową, a to wbudowany ukáad sterujący do pralki automatycznej. Figurki lepione z naszej czarodziejskiej pla- steliny — instrukcji mikroprocesora — rzeczywiĞcie moĪna tworzyü zadziwiająco szybko w porównaniu z przedmiotami z drewna, metalu czy betonu, a ponadto moĪna je po- tem wzglĊdnie áatwo poprawiaü bez potrzeby burzenia caáoĞci, jeĞli coĞ siĊ nie caá- kiem uda. Ludzikowi z plasteliny moĪna nawet, kiedy juĪ jest gotowy, oderwaü nogĊ i zastąpiü ją inną, lepszą, ale teĪ wygląda on potem jak… ludzik z plasteliny. 126 InĔynieria oprogramowania. Jak zapewniè jakoĈè tworzonym aplikacjom Programowanie naraĪone jest na nieustanną pokusĊ bylejakoĞci i poĞpiechu, których skutkiem jest bardzo czĊsto albo fatalna jakoĞü aplikacji, albo lekcewaĪenie uĪytkow- nika i jego potrzeb, przez co Ğwiat zapeániają zawodne i pokraczne, niewygodne w ob- sáudze twory z plasteliny. Po co zbieraü i analizowaü wymagania, skoro moĪna zacząü budowaü od razu, a potem, w razie czego, wszystko siĊ przerobi? Po co starannie pro- jektowaü system, skoro moĪna od razu zacząü kodowanie, a potem jakoĞ siĊ te, niepa- sujące do siebie, czĊĞci poskleja w caáoĞü? Po co dbaü o jakoĞü projektu, skoro w ba- áaganie teĪ daje siĊ pracowaü, i po co wysilaü siĊ na produkty dobrej jakoĞci, skoro czarodziejska plastelina pozwala na pozór bezkarnie poprawiaü, sztukowaü, zaizolowaü kawaákiem dĊtki, przymocowaü drutem? Miáo jest sobie pozrzĊdziü, ale z drugiej strony nie moĪna zaprzeczyü, Īe to dziĊki systemom informatycznym dzisiejszy Ğwiat ogromnie przewyĪsza ten sprzed lat trzydziestu i czterdziestu pod wzglĊdem moĪliwoĞci, dobrobytu, bezpieczeĔstwa i or- ganizacji, cokolwiek na ten temat sądzą rozmaici zwolennicy powrotu do jaskiĔ czy wrĊcz na drzewa. Ponadto, szydząc sobie z typowego projektu informatycznego: drwala, który nie ma czasu porządnie naostrzyü siekiery, bo tak bardzo siĊ spieszy z rąbaniem drewna, nie sposób przecieĪ zapomnieü o zagroĪeniach z przeciwnej strony: drwalach tak zajĊtych ostrzeniem siekiery, Īe nie mają czasu na Ğcinanie drzew. Czynniki psychologiczne po- wodują, Īe chĊtnie — uchylając siĊ przed naprawdĊ trudnymi wyzwaniami — ucie- kamy w rytualizacjĊ, mnoĪenie zbĊdnej dokumentacji, maniĊ 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 — to poĞpiech kontrolowany, gdzie umiejĊtnoĞü i wprawa pozwalają poruszaü siĊ szybko, lecz pewnie, a ĞcieĪki na skróty niekoniecznie prowadzą na manowce. Pomiary w 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 nie jest w informatyce sáowem lubianym — nawet poddany mi przez RedakcjĊ tytuá tego artykuáu omija je, zastĊpując niebudzącym lĊku sáowem ocena. Choü jako specjalista w branĪy nie raz spieraáem siĊ przy piwie, czy to testowanie, czy teĪ utrzymanie opro- gramowania jest bardziej niesáusznie lekcewaĪone w praktyce naszego przemysáu, wy- daje siĊ, Īe palma 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Ċki temu, Īe wprawa pozwala mu mierzyü bez przerywania jazdy. Przewodnik, na pozór bez wysiáku wyprowadzający przez gĊste krzaki wprost na zamierzony punkt, nie wlecze za sobą wielokilometrowej nici Ariadny tylko dlatego, Īe nieustannie podczas marszu Rozdziaä 4. i Zarzñdzanie procesami 127 mierzy przebytą odlegáoĞü, kierunek, nachylenie terenu. W przemyĞle informatycznym chĊtnie udajemy kierowców Formuáy 1 oraz dzielnych przewodników, nie mając nie- zbĊdnych po temu umiejĊtnoĞci mierzenia. Brak umiejĊtnoĞci sprawnego mierzenia uniemoĪliwia zarządzanie ryzykiem, zastĊ- pując je unikaniem ryzyka — lub bezsensowną brawurą. Unikanie ryzyka w inĪynierii oprogramowania rodzi projekty sztywne, zbiurokratyzowane, nieskuteczne, omijające wáaĞciwe wyzwania. Bezsensowna brawura oznacza fanfaronadĊ przy wyznaczaniu ce- lów, Ğrodków i terminów, po czym… To, co zdarza siĊ potem, takĪe moĪna oczywi- Ğcie zmierzyü. Odpowiednią miarą, nie do koĔca jeszcze uznaną przez fizyków, jest „och-nie-sekunda” (ang. oh-no-second), stosowana do okreĞlenia czasu upáywającego od chwili, gdy siĊ zorientowaliĞmy, Īe popeániliĞmy NAPRAWDĉ DUĩY BàĄD (np. klikając „wyĞlij do wszystkich” na koniec maila peánego wspomnieĔ z bardzo gorącej nocy). O zarządzaniu ryzykiem i o skutecznych pomiarach napiszĊ wkrótce, jak mi czas i Re- dakcja pozwolą. Na razie pora przejĞü do sedna: jak szybko oceniü jakoĞü produktu, czyli jak mierzyü w biegu? Precz z grzybami 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Ċ racjonalnej hodowli 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 seks
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

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

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: