Darmowa prenumerata - tu i teraz!
Menu
  - Redakcyjne
  - Strefa NN
  - Net
  - Teksty poważne
  - Polemiki
  - Meritum
  - Filozofia
  - Szkoła
  - Nauka
  - Poezja
  - Opowiadania
  - Komputery
  - Muzyka
  - Wstępniak
  - Wywiad z Dariuszem Majgierem
  - Biologia a komputery, czyli porównanie wirusów biologicznych z komputerowymi
  - Desktop Publishing
  - Elektrostatyka
  - FORTH. Część I
  - Takie sobie bajdurzenie o komputerowym niczym...
  - Witaj w moim... Świętym Cesarstwie czyli o e-państwach
  - Przegląd stron - Psychologia
  - Historia DOS'a
  - Tęsknota Dziadka
  - Wirus tu, wirus tam, czyli krótka historia wirusów
  - Zawodność oprogramowania komputerowego
  - XML Link Language
  - XML Pointer Language
BezImienny - wersja online!
Serwery wirtualne - MySQL, PHP, CGI, SSH...
Poprzedni artykułNastępny artykuł Komputery  

Zawodność oprogramowania komputerowego


Grzegorz Gałęzowski

Błędy oprogramowania występują nawet w najlepiej sprawdzonych programach. Według badań IBM najczęściej występują błędy, które mogą wywołać awarię systemu raz na 5000 lat. Usuwanie takich błędów jest syzyfową pracą.

Większość z nas doświadczyła problemów związanych z wadliwym działaniem oprogramowania, takich jak zawieszenie się systemu operacyjnego.

Defekty oprogramowania wywołały na przykład serię przerw w pracy telefonów na znacznych obszarach Stanów Zjednoczonych. Wadliwy program mógł uniemożliwić rakietom Patriot trafienie irackiej rakiety Scud, która zabiła 28 żołnierzy amerykańskich podczas wojny w Zatoce Perskiej.

Podstawą problemu jest złożoność programów, która zwiększa prawdopodobieństwo zaistnienia błędów i pojawienia się ich w ostatecznej wersji. W tradycyjnym systemie produkcji dokonał się znaczny postęp w zrozumieniu i kontroli defektów. Chociaż błędy projektowe występują czasem w produktach nie zawierających komputerów, jednak względna prostota tych wyrobów zmniejsza znaczenie ich niezawodności w porównaniu z oprogramowaniem.

Osiągnięcie idealnego oprogramowania pozostaje tylko marzeniem. Pomimo rygorystycznego i systematycznego testowania większość dużych programów zawiera nie usunięte defekty od chwili, w której zaczynamy je stosować. Przyczyną tego jest złożoność ich kodów źródłowych. Program zbudowany z zaledwie kilku setek linijek może zawierać dziesiątki rozkazów umożliwiających wystąpienie tysięcy różnych sposobów wykonania. Programy kontrolujące krytyczne zastosowania zawierają od dziesiątków do milionów linii kodu źródłowego. Program taki może podjąć błędną decyzję, gdyż przypadkowy układ sygnałów, który do niej doprowadzi, nie został przetestowany w okresie usuwania błędów. Taki układ sygnałów wejściowych może być nawet źle zrozumiany lub nieprzewidziany. Programista mógł prawidłowo zaprojektować złą reakcję lub w ogóle nie przewiedzieć wystąpienia danej sytuacji. Ten typ defektu programu jest najtrudniejszy do całkowitego wyeliminowania.

      Niepowodzenia rakiet Patriot przy przechwytywaniu irackich rakiet Scud przypisano efektom nagromadzenia się niedokładności w pracy wewnętrznego zegara komputera. Przedtem komputer działał zgodnie z przyjętymi założeniami -przewidywano, że będzie on wyłączany i włączany dostatecznie często, by kumulacja błędu nie była nigdy niebezpieczna. Ponieważ został zastosowany w sposób pierwotnie nie przewidywany, niewielka niedokładność stała się poważnym problemem.

      Jeden błędny bit w programie kontrolującym lot rakiety Atlas, która wyniosła w przestrzeń kosmiczną pierwszą amerykańską sondę międzyplanetarną Mariner 1, spowodował jej zejście z właściwego kursu. W konsekwencji zarówno rakieta, jak i sonda uległy zniszczeniu wkrótce po starcie.

      Poza mimowolnie wprowadzonymi do programu błędami, zawiera on różnego rodzaju uproszenia będące skutkiem kompromisu, które mogą wywołać niemożliwe do akceptacji zachowanie się systemu.

      Przyjmując, że istnienie idealnego oprogramowania jest praktycznie niemożliwe, możemy zapytać jak stwierdzić, czy dany program jest już dostatecznie niezawodny?

Pierwszym kryterium są wymogi bezpieczeństwa, które zależą od przeznaczenia danego programu. Na przykład w USA wymaga się, aby nowy system kontroli lotów nie ulegał awariom dłuższym niż 3 sekundy w ciągu roku. W cywilnych liniach lotniczych prawdopodobieństwo pewnych niebezpiecznych awarii nie może przekraczać jednej miliardowej w ciągu jednej godziny.

Podobnie w planach samolotów w pełni sterowanych przez komputery, takich jak Airbus A320 czy Boeing 777, możliwość katastrofy spowodowanej błędem w oprogramowaniu musi być porównywana z możliwością przeciwdziałania nieszczęśliwemu wypadkowi wynikającemu z błędu pilota czy awarii któregoś z urządzeń.

      Niestety, takie podejście można stosować jedynie przy umiarkowanych wymaganiach niezawodności systemu, zakładających na przykład jedną awarię na kilka lat pracy. Przy ostrych kryteriach niezawodności zastosowania osiągnięcie odpowiedniego poziomu ufności, w którym możliwość awarii nie może przekroczyć jednej miliardowej na godzinę, wymagałoby badania programu przez miliardów godzin, czyli setki tysięcy lat. Jest to oczywiście niemożliwe. Przetestowanie programów w realnym czasie oznacza zmniejszenie poziomu bezpieczeństwa o wiele rzędów wielkości w stosunku do potrzeb.

      Zagadnienie to nazywa się prawem malejących efektów. Jeśli usuwamy błędy przez dłuższy czas, wówczas znajdujemy coraz mniej istotne błędy, których eliminacja nie ma praktycznie żadnego istotnego wpływu na ogólną niezawodność systemu.

      Jeżeli ktoś przekonuje nas o wyjątkowej niezawodności i bezpieczeństwie pojedynczego programu, możemy mu zarzucić po prostu brak dostatecznej wiedzy. W przypadku złożonych programów przykrą prawdą jest fakt ograniczonego zaufania, na które można sobie pozwolić. Sama obserwacja programu w trakcie jego działania nie daje gwarancji jego zachowania się za 100 000 lat.

      Powszechnie dziś stosowaną metodą prowadzącą do wysokiej niezawodności (na przykład w kontroli lotów i ruchu pociągów) jest tolerancja błędów lub metoda zabezpieczającej redundancji, czyli nadmiaru.

Typowym sposobem stosowania redundancji jest posiadanie różnych wersji oprogramowania opracowanych przez różne grupy programistów. Można przypuszczać, że w poszczególnych wersjach programu pojawią się różne błędy. Każda z wersji programu podaje własną "opinię" o prawidłowości wyniku. Następnie urządzenie rozstrzygające podejmuje ostateczną decyzję - prawidłową, jeśli przeważają wyniki poprawne.

      Istnieje wiele dowodów, że taki system prowadzi do wysokiej niezawodności, choć kosztuje drożej. Nie można jednak wykluczyć, że różne grupy programistów popełnią takie same błędy (na przykład z powodu wspólnej mentalności kulturowej) lub błędy różne, ale prowadzące do identycznych awarii. Urządzenie rozstrzygające w takim wypadku wybierze fałszywe rozwiązanie.

      Więc nie narzekaj użytkowniku, kiedy aplikacja której używasz nagle "padnie", zastanów się nad poziomem komplikacji takiego programu. Czym bardziej skomplikowany system tym większe szanse na występowanie awarii (dotyczy to nie tylko programów ale i urządzeń z których korzystamy).

Grzegorz Gałęzowski
poczta: gsgalezowski@poczta.onet.pl
Poprzedni artykułWstępNastępny artykuł