Najpierw myśleć czy działać

Wiele razy obserwuję sytuację, gdy wdrożenie jakiegoś programu ma uzdrowić działanie pewnej struktury: firmy czy instytucji państwowej. Program traktowany jest jak swego rodzaju uniwersalne lekarstwo, swoisty antybiotyk. Możemy nie rozumieć jego działania, ale wystarczy go zastosować i organizm zdrowieje, staje się silny i sprawny

Wiele razy obserwuję sytuację, gdy wdrożenie jakiegoś programu ma uzdrowić działanie pewnej struktury: firmy czy instytucji państwowej. Program traktowany jest jak swego rodzaju uniwersalne lekarstwo, swoisty antybiotyk. Możemy nie rozumieć jego działania, ale wystarczy go zastosować i organizm zdrowieje, staje się silny i sprawny.

Niestety, nawet w medycynie nie istnieje uniwersalne lekarstwo i wszelkie nie kontrolowane, amatorskie próby stosowania "uniwersalnych" lekarstw w ostatecznym rachunku przynoszą negatywne skutki. W inżynierii takie podejście nie ma żadnego uzasadnienia. Inżynieria z samej definicji oznacza świadome kształtowanie otoczenia dla osiągnięcia zamierzonych efektów. Świadome, tzn. mając na uwadze, co chcemy osiągnąć i wiedząc, jakie skutki przyniesie zastosowanie naszego rozwiązania, włączając w to również skutki uboczne.

Z takiego podejścia wynikają ważne wnioski. Po pierwsze - zanim zdecydujemy się na program, powinniśmy uświadomić sobie zadania, jakie przed nim postawimy. Celem każdego systemu informatycznego jest dostarczenie jego użytkownikowi informacji. Pomijam tu anormalną - moim zdaniem - sytuację, gdy celem posiadania systemu jest zwiększenie splendoru posiadacza czy przekonanie zwierzchników lub wyborców o naszej operatywności (przy cichym założeniu ich indolencji), choć oczywiście mercedesa można mieć też nie do jeżdżenia, a do pokazywania kontrahentom i przyjaciołom. Celem systemu informatycznego nie powinno być rejestrowanie, przechowywanie czy przetwarzanie informacji, podobnie jak przeznaczeniem samochodu nie może być spalanie benzyny. Te czynności są w istocie kosztem działania systemu; samochód nie może jeździć bez dostarczenia mu z zewnątrz energii, a system informatyczny nie będzie dostarczał informacji, jeżeli wcześniej nie będzie tymi informacjami zasilony. Klasyczne komputery nie zwrócą większej ilości informacji niż włożono do nich, aczkolwiek mogą to zrobić w innej, czytelniejszej dla człowieka postaci (zastrzec tu muszę, że być może w przyszłości pojawią się komputery kojarzące, oparte np. na sieciach neuronowych, które będą mogły informacje syntetyzować, ale będzie to już inna jakość w porównaniu z komputerami współczesnymi). Podstawową trudnością, jaką napotykamy przy próbie opisania własnych potrzeb informacyjnych, jest ułomność czy też - jak chcą humaniści - bogactwo języka naturalnego. Takim językiem łatwo można podawać nieprecyzyjny opis naszych wymagań. Co ciekawe, opis ten prawie nigdy nie budzi oporu innych osób, natomiast okazuje się niewystarczający (niepełny) lub często przy bliższej analizie wręcz wewnętrznie sprzeczny - stąd chyba przysłowie "Diabeł tkwi w szczegółach".

Gdy wiemy już, jakie informacje są nam potrzebne, powinniśmy zlokalizować ich źródło. Może się zdarzyć, iż producent zapisze te informacje w programie - przykład samochodu, który ma wielki bak benzyny napełniony fabrycznie, wystarczający na cały okres eksploatacji. Częściej mamy jednak do czynienia z sytuacją, gdy dane do systemu będzie wprowadzał sam użytkownik. Oczywiście, pojęcia użytkownika nie należy koniecznie rozumieć jako pojedynczej osoby, równie dobrze może być to grupa ludzi, grupa firm lub instytucji - mamy wówczas do czynienia z pracą grupową. W takim przypadku informacja wprowadzana przez jednych może trafiać do innych. Taki przepływ może być prosty - jedni wpisują, inni czytają w takiej samej postaci. Może też być bardziej skomplikowany, gdy informacja podczas przepływu od dostawcy do odbiorcy zmienia formę lub jest łączona z innym strumieniem danych.

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

TOP 200