Nie taki średni problem

Śmiem twierdzić, że specyfikacja wymagań dla systemu informatycznego jest najistotniejszym etapem w całym projekcie. Ale, jakby na przekór zdrowemu rozsądkowi, często fazę tę traktuje się jak zło konieczne, ograniczając się do zdefiniowania jedynie kluczowych zasad, tak jakby zarówno producenci, jak i odbiorcy nie mogli doczekać się przejścia do etapów następnych. Gorączkowe traktowanie rozpoczętego projektu powoduje, że z przygotowanej pobieżnie papki przyrządza się produkt informatyczny, który okazuje się potem niestrawny dla odbiorców.

Śmiem twierdzić, że specyfikacja wymagań dla systemu informatycznego jest najistotniejszym etapem w całym projekcie. Ale, jakby na przekór zdrowemu rozsądkowi, często fazę tę traktuje się jak zło konieczne, ograniczając się do zdefiniowania jedynie kluczowych zasad, tak jakby zarówno producenci, jak i odbiorcy nie mogli doczekać się przejścia do etapów następnych. Gorączkowe traktowanie rozpoczętego projektu powoduje, że z przygotowanej pobieżnie papki przyrządza się produkt informatyczny, który okazuje się potem niestrawny dla odbiorców.

Zdarza się, że zaakceptowane założenia, które powinny precyzyjnie i jednoznacznie implikować postać końcową produktu, zostają opacznie zrozumiane przez stronę zamawiającą bądź wykonawców. Zapis ustaleń przedwykonawczych okazuje się przeważnie zbyt ogólny i dopuszczający daleko posuniętą dowolność interpretacyjną, co każda ze stron może w razie sporu zaliczać na swą korzyść. Ale co komu z tego? Niestety, wstępne założenia są określane często zbyt pobieżnie, a powinny stanowić przecież dokładny wykaz związków informacji, procesów jej przetwarzania z wyszczególnieniem stosownych algorytmów. Problem zazwyczaj tkwi w tym, że odbiorcy niechętnie angażują się w te procedury, jak również nie akceptują potencjalnych kosztów wynikających z fazy przygotowawczej. Koszty te niewątpliwie poniosą i tak, chociaż przesunięte w czasie na fazę wytwarzania. Najgorszy jednak scenariusz - przewracający nieraz wszystko do góry nogami - to zbyt późna refleksja, która przychodzi dopiero z chwilą rozpoczęcia wdrażania.

Zmorą projektów jest niezwykle mała precyzja, z jaką użytkownicy są w stanie wyartykułować konkretne potrzeby towarzyszące zastosowaniom oprogramowania. Zazwyczaj zadowalają się wypunktowaniem najważniejszych przesłanek, przemilczając - przez nieświadomość lub zapomnienie - istotne szczegóły. Jeśli ktoś zreflektuje się zawczasu, to jeszcze nie jest najgorzej. Często te, zdawałoby się drobne, niedomówienia zmieniają istotę całego projektu. Nieraz aby uzyskać niezbędne informacje, analitycy muszą klientów mocno ciągnąć za język, co przypominać może raczej śledztwo w sprawie aniżeli techniczne prace przygotowawcze. Nie wiadomo dlaczego użytkownicy zeznają czasami tak opornie, jakby siedzieli przed obliczem komisji sejmowej.

Na szczęście obecnie wiele zagadnień podlegających komputeryzacji jest dosyć dobrze standaryzowanych i nie trzeba bawić się w specyfikowanie założeń od podszewki. Ciągle jednak istnieje spora grupa zastosowań, gdzie gotowca wprost się nie zastosuje i trzeba go co najmniej przekonstruować lub wręcz stworzyć całkiem nowe rozwiązanie.

Tak prozaiczny zdawałoby się problem, jak wyliczanie średniej ocen studenta, może być dobrym przykładem na wieloznaczność interpretacyjną. Dla jednych będzie to średnia ze średnich semestralnych, dla innych średnia ze wszystkich ocen. Największy szkopuł w tym, że niektórym użytkownikom trzeba tłumaczyć różnicę pomiędzy tymi odmiennymi sposobami wyliczania.

Informatyka jest dziedziną niespotykanie precyzyjną. Działa z dokładnością do jednego bitu. I z tego wszyscy, a nie tylko informatycy, powinni zdawać sobie sprawę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200