Jeśli już mamy specyfikację, to trzeba zaimplementować ją w kodzie. Na ile trzeba standaryzować pracę programistów? Czy każdy może mieć swój styl?

W Japonii działa firma informatyczna, która opracowała system do wytwarzania oprogramowania dla banków. Pozostawia on programistom mało swobody, bowiem programowanie sprowadza się do wypełniania formularzy. Dzięki temu jednak utrzymywany jest jednolity standard otrzymywanego kodu. Oczywiście są tacy, którzy protestują, że nie jest to żadne programowanie.

To ekstremalny przykład, ale generalnie potrzebne są tutaj podobne standardy, jak chociażby w architekturze. Każdy dobry architekt ma swoje pomysły, ale jego projekty, rysunki są zrozumiałe dla każdego innego architekta. Umiejętność tworzenia odpowiednich, zrozumiałych dokumentów powinna być częścią profesji informatyka. Oczywiście, chodzi o dobre dokumenty, które muszą funkcjonować w kontekście standardów dotyczących produktów. Dlatego na przykład nie lubię metodologii CMM, w której liczy się produkowanie dokumentów, nie zaś ich jakość.

Jak tworzy się stabilne oprogramowanie? Na przykład to, które jest instalowane w urządzeniach elektronicznych powszechnego użytku.

To tylko złudne przekonanie, że w tym oprogramowaniu nie ma błędów. Jeśli urządzenie się dziwnie zachowuje, to wszyscy wolą wierzyć, że to normalne. Sam mam wbudowane oprogramowanie.

Elektroniczny stymulator serca. Ustala on tempo, w jakim bije serce, gdy człowiek nie podejmuje wysiłku, np. gdy położy się spać. Nie wiadomo dlaczego w zaszytym w nim oprogramowaniu przyjęto, że ta częstotliwość musi przyrastać co 10, czyli np. 50, 60, 70 razy/s. A przecież to nie jest naturalne. Lekarze nie byli w stanie tego wyjaśnić. To oczywisty błąd w specyfikacji. Rozmawiałem nawet z firmą, która wykonuje te stymulatory. Stwierdzili, że ta osoba, która opracowała to oprogramowanie, już u nich nie pracuje, nie mogą więc odpowiedzieć, dlaczego tak jest...

Nie boi się Pan zatem o swoje życie?

Owszem. Chcę zmienić to urządzenie, bo jest producent, do którego mam zaufanie.

Typowe oprogramowanie, jak to, które wykonuje Microsoft, na ogół też działa bez problemów. Kłopoty zaczynają się wtedy, gdy instalujemy coś nowego, używamy jakichś interfejsów czy kilku aplikacji naraz. To są sytuacje nietypowe, trudne do przetestowania. Tak samo jest w przypadku oprogramowania wbudowanego. Na szczęście w większości przypadków działa ono w środowisku o ściśle określonych parametrach, przy dokładnie wskazanych ograniczeniach. Nic się złego nie dzieje, co nie znaczy, że to oprogramowanie jest również pozbawione błędów. Szczerze mówiąc, nie ma na świecie większego fragmentu oprogramowania, który byłby ich pozbawiony.

Czy zatem powinniśmy polegać na oprogramowaniu, czy możemy być pewni czegokolwiek, czego funkcjonowanie zależy od pewnego rozwiązania informatycznego?

Najprościej byłoby odpowiedzieć, że nie. Mamy jednak do dyspozycji metody, które właściwie zastosowane sprawią, że oprogramowanie powinno być na tyle dobre, że statystycznie możemy na nim polegać.

Czy tworzenie oprogramowania z zastosowaniem tych metod jest istotnie droższe?

Oczywiście, jest. Ale jeśli jest, to np. oprogramowanie telefonu komórkowego, który zostanie sprzedany w kilku milionach egzemplarzy, to wliczając koszt oprogramowania, będzie on droższy o około dolar. Niestety, często okazuje się, że w biznesie ważniejszy jest ten dolar niż jakość oprogramowania. Ważne jest jedynie to, żeby oprogramowanie miało określoną funkcjonalność. Być może pewne wymogi powinny być narzucone przez prawo.

Ale na to nie zdecydował się chyba jeszcze żaden kraj?

Gdzieniegdzie, np. w Kanadzie określono już wymogi dotyczące tworzenia oprogramowania przeznaczonego dla elektrowni atomowych, w Stanach Zjednoczonych - wszystkich elementów, produkowanych na potrzeby przemysłu lotniczego i kontroli ruchu powietrznego. Ale przecież nie dotyczy to tylko oprogramowania. Nie ma chociażby prawnych uregulowań, dotyczących wytwarzania sprzętu medycznego.

Czy metody dowodzenia poprawności programów, tzn. posłużenia się formalizmem matematycznym, by udowodnić, że program działa poprawnie na mocy swojej konstrukcji, mają praktyczne znaczenie?

Oczywiście, metody, jakie zaproponował kiedyś C. A. R. Hoare, które są wykładane na uniwersyteckich kursach informatyki, to zabawa dla wąskich kręgów akademickich. Bardziej praktyczne prace pod tym względem prowadził np. IBM. Problem z dowodzeniem poprawności programów to głównie skłonienie odbiorcy, by zaczekał na rezultaty. Takie podejście do tworzenia oprogramowania musi bowiem zajmować sporo czasu. Praktyczne zastosowania to chociażby tworzenie kluczowych modułów do sterowania pracą elektrowni atomowej. Mam nadzieję, że w przyszłości takie metody będą stosowane bardziej rutynowo.

Tworzenie oprogramowania wymaga pracy. Na górę można wejść różnymi drogami, ale nie da się pójść takim skrótem, żeby nie trzeba było się wspinać.

--------------------------------------------------------------------------------

Prof. David L. Parnas przebywał w Polsce na początku czerwca br. Prowadził seminarium i warsztaty na temat "Wpływ dokumentacji na jakość i koszty tworzonego oprogramowania", zorganizowane przez MGG Conferences.