Weryfikacja oprogramowania, zwłaszcza dokonywana na zlecenie konkretnego, potencjalnego nabywcy, wymaga na wstępie oceny narzędzi, jakimi posłużono się przy przygotowywaniu aplikacji i sprawdzenia formalnej poprawności oprogramowania, czyli jego zgodności z faktycznie funkcjonującymi aktami normatywno-prawnymi.

Warsztat na warsztat

Nakłady sił i środków na ocenę zastosowanych technologii i narzędzi informatycznych powinny być uzależnione nie tylko od skali i kosztów systemu informatycznego, ale również zadań, którym służy. Na przykład skala prac weryfikacyjnych właściwa dla softwere'u, od którego zależy bezpieczeństwo ludzi, nie ma żadnego uzasadnienia w przypadku oprogramowania komercyjnego dla tzw. typowych średnich i małych firm. Dogłębnej analizy warsztatu programistycznego należy więc oczekiwać np.w przypadku oprogramowania, którego zadaniem jest rozchodowanie leków o właściwościach narkotyków, ale już znacznie mniejsze wymagania stawia ocena programu dla hurtowni odzieży. Z reguły natomiast bardziej dogłębnie należy oceniać program wówczas, gdy ma on zapewnić współdziałanie kilku użytkowników w czasie rzeczywistym.

Do sprawy prawidłowej klasyfikacji programów wg wymaganego stopnia dokładności analizy narzędzi, jakimi się posłużono przy jego przygotowywaniu, powrócimy w dalszej cześci cyklu. Tu skoncentrujmy się na liście pytań, na które oceniając program z punktu widzenia zastosowanych narzędzi, powinniśmy otrzymać odpowiedź:

- czy oprogramowanie zostało wykonane zgodnie z istniejącymi normatywami lub zwyczajowo przyjętymi zasadami projektowania współczesnego software'u w określonych klasach zastosowań? (Po przeprowadzeniu takiej analizy można oczekiwać np. szybkiego wykrycia niestandardowego protokółu transmisji)

- czy zastosowana technologia i narzędzia zapewniają odpowiednią systemową jakość software'u? Nie chodzi tu tylko o stronę czysto informatyczną, ale przede wszystkim o stosowanie metod zapewniania jakości, określonych w pakiecie norm ISO 9000-9004, a w zczególności - ISO 9000-3. Okazać się może bowiem, że dysponując nawet "dobrymi" narzędziami programistycznymi, ale oszczędzając na wprowadzeniu kosztownych nieraz zasad sterowania jakością, producent "sknocił" aplikację.

Dodajmy, że w przypadku bardziej złożonych systemów formatycznych wykonanie niezawodnego software'u, bez zastosowania normatywnych metod sterowania jakością, jest nierealne.

- czy zastosowana technologia i narzędzia informatyczne zapewniają tempo adaptacji software'u odpowiednie do faktycznie występujących i przewidywanych zmian systemu informacyjnego, wynikających z restrukturyzacji czy zmian normatywno-prawnych w danej dziedzinie, np. wprowadzenia nowych zasad opodatkowania?

- czy zastosowane narzędzia programistyczne stwarzają oprogramowaniu perspektywy rozwojowe w sensie zmian środowiska eksploatacyjnego (nowy sprzęt komputerowy, rozwój współpracujących systemów informatycznych, wprowadzanie obligatoryjnych baz indeksowo-kodowych, np. jednolitego wykazu towarów i usług).

Najważniejsze sprawy formalne

Weryfikacja poprawności formalnej oprogramowania powinna umożliwić udzielenie odpowiedzi m.in. na następujące zasadnicze pytania:

- czy oprogramowanie posiada nakazane mechanizmy i (lub) nie posiada mechanizmów zakazanych prawem dla danej klasy systemów informatycznych? Przykładowo, w księgach rachunkowych niedopuszczalne jest wymazywanie błędnych zapisów. Należy je poprawiać przez nowy, dodatkowy zapis z pozostawieniem błędnego.

- czy oprogramowanie jest w pełni skompletowane w sensie technologicznym, tzn. posiada użyteczną dokumentację. Jakie są nośniki oprogramowania oraz niezbędnych zbiorów danych (lub tzw. zbiorów pustych). Czy wytępują inne elementy, istotne w danym obszarze zastosowań, np. ważny dokument homologacyjny lub atest?

- czy umowa licencyjna w sposób wystarczający zabezpiecza interesy obu stron?

Chcemy zwrócić szczególną uwagę na ten ostatni problem. Dochodzi tu bowiem do wielu nieporozumień. Standardowe umowy licencyjne wystarczają, jeżeli kupuje się standardowe oprogramowanie. Z reguły bowiem typowy arkusz kalkulacyjny jednego producenta może współpracować z edytorami, czy pakietami prezentacyjnymi wielu innych firm. Jednak w przypadku kupna pakietu lub modułów systemu informatycznego, wspomagającego zarządzanie naszej firmy, wiążemy się najczęściej na stałe z jednym producentem. Obie strony powinny mieć więc świadomość, że nie chodzi tu o jednostkowy kontrakt wartości np. 10 mln zł, ale o początek wspólnego przedsięwzięcia za co najmniej 100 mln zł. Istota wdrożenia kompleksowego systemu informatycznego jest inna, niż jednostkowego zakupu jakiegokolwiek innego dobra, np. drogiego samochodu. Wystarczy tylko wziąć pod uwagę nakłady kupującego i sprzedającego na szkolenie personelu, konserwację i usuwanie awarii, przewidzieć rozwój oprogramowania, itp. Dlatego też niezrozumiałym jest zawieranie transakcji software'owych, niekiedy za kilkaset mln zł, opartych na umowach, w których obowiązki i uprawnienia stron, sposób i plan wdrożenia, koszty oraz zasady serwisu spisane są na dwóch niepełnych kartkach.

Praktyczne wzorce i normy odniesienia - czyli na bezrybiu i rak ryba.

Omawiane procedury weryfikacyjne można prowadzić na zasadzie "badania czarnej skrzynki" w cybernetycznym tego pojęcia rozumieniu. Oznacza to, że bada się reakcję obiektu na konkretne bodźce, sprawdza, jakie określone posunięcie "na wejściu", daje skutek "na wyjściu". Chodzi więc o szczegółowe testowanie programu i wychwytywanie jego braków. Metoda ta jest oczywiście bardzo pracochłonna.

Lepszym rozwiązaniem byłoby przeprowadzenie ocen, szczególnie poprawności formalnej, na podstawie dokumentacji projektowej oprogramowania.

W wielu przypadkach udostępnienie tej dokumentacji lub jej fragmentów potencjalnemu klientowi, czy też określonej instytucji jest obowiązkowe. Na przykład oprogramowaniu wspomagającemu prowadzenie ksiąg rachunkowych, należy zapewnić pełną ich sprawdzalność przez - cytuję: "skompletowanie dokumentacji systemu przetwarzania danych, dającej pełny wgląd w budowę i przebieg stosowanego sposobu przetwarzania (programu)" (Rozp. Min. Finansów nr 11 z dn. 15.01.1991 r.).

W praktyce jednak nakaz ten respektowany jest częściowo, a niekiedy całkowicie ignorowany. Trudno się temu dziwić. Wobec dość powszechnego lekceważenia tajemnicy handlowej i obecnego poziomu informatycznej kultury prawnej, firmy które dołączyłyby do "pudełka" np. kod źródłowy, czy dokumentację projektową, narażane są na duże ryzyko. Producenci na dorobku lub o mniejszym potencjale (nie tylko polscy) i tak już bezlitośnie łupieni "dzięki" lukom prawa, nie mogą sobie pozwolić na faktyczne ujawnienie szczegółów konstrukcji wyrobów, w które zainwestowali co najmniej kilkaset mln zł.

Z tych też względów jeszcze zapewne długo typowym będzie wariant badań prowadzonych metodą "czarnej skrzynki", oznaczający potrzebę przeprowadzenia kompleksowych testów oprogramowania.

Nieprzypadkowo również na początku artykułu użyliśmy określenia "faktycznie funkcjonujące akty normatywno-prawne" zamiast "obowiązujące". Naszym zdaniem nieprędko znajdziemy się w naszym kraju w takiej sytuacji, w której szef zespołu weryfikacyjnego rozdzieli jego członkom, odpowiednie do obszaru zastosowania danego programu, ustawy, rozporządzenia oraz normy i postawi jedno zadanie: sprawdźcie czy software spełnia te wymagania.

Polskich dokumentów, które można by uznać za podstawę odniesienia, jest obecnie bardzo niewiele. Dlatego jednym z najpoważniejszych problemów zespołu oceniającego oprogramowanie staje się ustalenie normatywnej bazy weryfikacji. Praktyka wskazuje, że bazy takiej, ścisłej oraz spójnej w sensie prawnym i techniczno-technologicznym utworzyć się aktualnie na podstawie polskich dokumentów nie da. Korzystać trzeba zatem z normatywów zagranicznych, które zapewne kiedyś i u nas wejdą w życie.

Obok takich norm można też uwzględnić doświadczenia lub konkretne rozwiązania wiodących producentów światowych, które często stają się faktycznymi standardami informatycznymi, zanim jakiekolwiek organizacje normalizacyjne zdołają formalnie nadać im taki status.

Podsumowując należy zauważyć, że wobec istotnego braku swoistych "papierków lakmusowych", ułatwiających stosowanie omówionych tu wstępnych procedur weryfikacyjnych rosną ich koszty. Jasnym staje się, że naszego umownego "typowego" klienta w pojedynkę na taki wydatek nie będzie stać. Sądzimy, iż jest to jasna wskazówka co do potrzeby rozszerzenia instytucjonalnych form homologacji i atestacji oprogramowania w naszym kraju.