Trud tworzenia

Konstruowanie oprogramowania zawiera w sobie dwa istotne składniki trudności. Jeden związany jest ze sferą techniczną, a drugi z funkcjonalną.

Konstruowanie oprogramowania zawiera w sobie dwa istotne składniki trudności. Jeden związany jest ze sferą techniczną, a drugi z funkcjonalną.

O ile z pierwszym z nich doskonale zazwyczaj radzą sobie specjaliści zajmujący się programowaniem, o tyle z drugim jest problem, bo nie zależy on tylko od wykonawców. I jest to najczęściej główny powód, dla którego oprogramowanie nie spełnia pokładanych w nim nadziei użytkowników. Ale trudno za ten stan winić informatyków, chociaż gremialnie tak się czyni.

Specyfikacja wymagań dla systemu informatycznego wynika z wnikliwej pracy analityków i ich właściwej współpracy z przyszłymi użytkownikami. Nie chodzi tu bynajmniej tylko o poprawność kontaktów międzyludzkich, ale o właściwą interpretację założeń funkcjonalnych, które muszą być następnie przełożone na język algorytmów. Ileż to razy twórcy programów spotkali się ze zjawiskiem algorytmicznej nieokreśloności pewnych zdarzeń, które miały być ujęte w sztywne ramy programu, a użytkownicy zwyczajnie nie byli w stanie zwerbalizować tych zasad lub na etapie analizy problemu zapominali o istotnych wyjątkach, które mają miejsce w rzeczywiście zachodzących procesach.

Tych problemów nie rozwiążą najnowsze technologie, bazy danych i najwydajniejsze serwery. Sprawa bowiem utyka w fazie logiki funkcjonalnej.

Metody obchodzenia zdarzeń nierozwiązywalnych algorytmicznie bywają różne. Czasami daje się użytkownikom wolną rękę w działającym systemie, gdzie samemu można decydować w kwestii interpretacji pewnych zdarzeń i klasyfikować je według uznania oraz wiedzy operatora komputera. Nie zawsze jednak mamy do czynienia z tak szczęśliwymi przypadkami. Czasami też taka dowolność skutkuje zaburzeniami w późniejszym etapie użytkowania oprogramowania. Zbyt mało restrykcyjne zasady, dające użytkownikom dowolność, wprowadzają zaburzenia procesu, błędną interpretację zdarzeń, zniekształcenie danych.

Jedną z częstszych przyczyn takiego stanu rzeczy jest niejednoznaczność przepisów (prawnych, branżowych), nie pozwalających na klarowne ujęcie zagadnienia. Przykładów nie trzeba szukać daleko. We wrześniowej "Rzeczpospolitej" natknąłem się na dyskusję w sprawie nieodpłatnego przekazywania przez firmę towarów (prezentów). Otóż dla jednego obdarowanego wartość prezentów nie może przekraczać 100 zł rocznie, aby nie podlegało to opodatkowaniu VAT. Problem jest z nadwyżkami, bo nie wiadomo od jakiej kwoty naliczać podatek, gdy osoba od jednej firmy dostanie w roku trzy podarki, w kolejności za 40, 40 i 50 zł. Czy VAT wówczas naliczać od całości (130 zł) czy tylko od nadwyżki ponad 100 zł, czy tylko od ostatniej darowizny (50 zł), która przepełniła pulę. I znowu zaczynają się dywagacje: ten urząd skarbowy traktuje to tak, a tamten inaczej. I znowu też płatni interpretatorzy przepisów mają pole do popisu, a ludzie, którym te formuły narzucono, zachodzą w głowę jak je stosować. To jest tylko pierwszy z brzegu przykład treści, jakimi najeżone są nasze ustawy.

Żaden przepis (ustawa), którego nie da się wyrazić algorytmicznie, nie może być uznany za poprawny i powinien z miejsca wylądować w koszu. Wszystkim "wymądrzalskim" specom od interpretacji i tworzenia takowych zapisów proponuję skorzystać z funkcji umysłu zwanej logicznym myśleniem, a jeśli to niemożliwe, zająć się sprawami prostszej natury. Państwo będzie tanie i praworządne, jeśli zlikwiduje się tego typu wieloznaczności. Piszę o tym nie tylko w intencji pomniejszenia trudu twórców oprogramowania, ale generalnie ku pomyślności wszystkich obywateli. A poza tym proponuję - na wzór testerów oprogramowania - powołać funkcję testerów ustaw, zamiast testować je na użytkownikach końcowych.


TOP 200