Programista jest tylko człowiekiem, czyli skąd się biorą błędy w oprogramowaniu


Skąd się biorą błędy w oprogramowaniu. Pod presją czasu

Największym wrogiem bezbłędnych programów jest czas. Winą za większość błędów obecnych w oprogramowaniu obarczyć można krótkodystansowe cele biznesowe. Manager projektu IT odpowiada bowiem za to, aby zamówione oprogramowanie było dostarczone na czas i za to, żeby działało, ale już niekoniecznie za to, aby było pozbawione błędów. Presja czasu sprawia, że testuje się tylko podstawowe funkcje aplikacji i nie przeprowadza gruntownych testów całego kodu. Skutek jest taki, że często nie zwraca się już uwagi na jakość kodu, a co za tym idzie zapomina się również o kwestiach związanych z utrzymaniem i rozwijaniem oprogramowania.

Co gorsza, im niższa jest jakość kodu, czyli im bardziej kod jest skomplikowany i nieczytelny tym więcej ma błędów i są one trudniejsze do wychwycenia podczas testów. Taki kod sprawia, że dużo łatwiej jest wprowadzić do niego nowe błędy, niż usunąć stare. Obecnie uważa się, że 80% błędów w oprogramowaniu występuje w 20% modułów – i to właśnie tych, które są najbardziej niechlujnie napisane. Presja czasu sprawia, że programiści często kopiują kodu z innych, podobnych programów bez sprawdzenia przydatności i spójności kodu.

Jedną z najgorszych praktyk sprzyjających powstawaniu błędów jest nadpisywanie nowego kodu na starej bazie. O tym jak duży jest to problem świadczyć mogą badania przeprowadzone w zeszłym roku przez firmę CAST. Specjaliści z tej firmy na celownik wzięli mobilne aplikacje bankowe przeznaczone na tablety i smartfony. Oczywiście banki twierdzą, że korzystanie z ich oprogramowania do mobilnej bankowości elektronicznej jest bezpieczne, tymczasem wg specjalistów z CAST narażamy się na różnego rodzaju zagrożenia związane z niską jakością tworzonego przez programistów kodu.

Analizie poddano 1316 bankowych aplikacji mobilnych i przeanalizowano łącznie 705 milionów linii kodu. Okazało się, że 70% aplikacji związanych z bankowością indywidualną oraz 69% programów do usług finansowych podatna jest na ataki pozwalające pozyskanie danych użytkowników. Co więcej, wg raportu CAST, sektor bankowy może się „pochwalić” najgorszej jakości kodem – mimo, że aplikacje tego typu nie są skomplikowane i długie. Jak twierdzą autorzy raportu, wynika to z narzucania nierealistycznych terminów projektów IT, na których cierpi właśnie jakość kodu.

Co ciekawe, w badaniach znalazły się też aplikacje finansowe przygotowywane przez programistów pracujących na potrzeby amerykańskich władz stanowych i federalnych. Tutaj 61% programów było wolnych od usterek, tymczasem wśród aplikacji komercyjnych odsetek ten wyniósł zaledwie 12%.

Skąd się biorą błędy w oprogramowaniu. Cena błędu

Programistyczne niedoróbki można mogą być niebezpieczne i kosztowne. Jest na to mnóstwo dowodów. Chyba najbardziej znanym przypadkiem błędów związanych z oprogramowaniem było rozbicie się o powierzchnie Marsa sondy NASA Mars Climate Orbiter. 23 września 1999 roku, po dziesięciu miesiącach lotu kosztująca blisko 700 mln dolarów sonda NASA Mars Climate Orbiter znalazła się w pobliżu Marsa. O godzinie 8:41 sonda rozpoczęła manewr wchodzenia na orbitę Czerwonej Planety. Zgodnie z planem o 9:04 Mars Climate Orbiter, zniknął za niewidoczną z Ziemi stroną planety. Sonda jednak nigdy już się nie ukazała oczom naukowców, a kontakt z nią nie został ponownie nawiązany. 25 września NASA przyznała się do niepowodzenia misji.

Przeprowadzone śledztwo wykazało, że sonda podeszła zbyt blisko powierzchni Czerwonej Planety i spłonęła w jej atmosferze. Bezpośrednią przyczyną katastrofy okazał się jednak fragment programu, napisanego w Anglii na zlecenie firmy Lockheed Martin. Bazował on bowiem w oparciu o angielskie jednostki miary, podczas gdy część oprogramowania przygotowana przez NASA w Stanach Zjednoczonych korzystała z jednostek metrycznych.

Programista jest tylko człowiekiem, czyli skąd się biorą błędy w oprogramowaniu

Mars Climate Orbiter - bezpośrednią przyczyną katastrofy okazał się fragment programu korzystający z innych jednostek miar niż reszta kodu [źródło: NASA]

Podczas testów wychwycono niespójność jednostek, ale alarm został zignorowany. W praktyce rozbieżności okazały się na tyle duże, że błąd ten spowodował nieprawidłową pracę silników hamujących sondy i konsekwencji zbyt bliskie podejście Mars Climate Orbitera do powierzchni planety i spłonięcie w jej atmosferze.