Badania prowadzone za granicą wykazały, że zaledwie 5% dużych systemów informatycznych udało się wdrożyć zgodnie z wymaganiami użytkowników, w oznaczonym czasie i za określone z grubsza pieniądze. Ponad połowa systemów zostaje albo niedokończona, albo odrzucona przez użytkowników!

Komputery są dziś obecne w każdej dziedzinie ludzkiej działalności, od bankowości, administracji, przez sterowanie urządzeniami aż po rejestrację chrztów w parafiach i zapisy pielgrzymów udających się na Jasną Górę. Cywilizacja informatyczna stała się faktem, którego trudno nie dostrzegać.

Informatyk postrzegany jest często jako czarodziej, umiejący ujarzmić tajemniczą maszynę i zmusić ją do służenia człowiekowi. Jakby tylko na marginesie tych oszałamiających sukcesów pojawiają się różne "drobne" trudności. Każdy zapewne słyszał o olbrzymich rachunkach za rozmowy telefoniczne przeprowadzane (zapewne przez sam telefon) w czasie, gdy właściciel był na wakacjach. Od czasu do czasu można przeczytać doniesienia o katastrofach samolotów sterowanych niezawodnymi systemami kontroli lotu, czy o wystrzeleniu satelity nie wiadomo dokąd.

Dane statystyczne, dotyczące wyników dziedziny, szumnie zwanej inżynierią oprogramowania, mogą znacznie ostudzić entuzjazm wyznawców komputeryzacji. Badania prowadzone za granicą wykazały, że zaledwie 5% dużych systemów informatycznych udało się wdrożyć zgodnie z wymaganiami użytkowników w oznaczonym czasie i za określone z grubsza pieniądze. Co gorsza, ponad połowa systemów zostaje albo niedokończona, albo odrzucona przez użytkowników! Wreszcie, ŻADEN duży system nie jest wolny od błędów, a poważne firmy, zajmujące się tworzeniem oprogramowania, zatrudniają całe grupy ludzi odpowiedzialnych za serwis - co zwykle sprowadza się do pomagania użytkownikom w sytuacjach gdy system "pada". W świetle tych faktów zdumienie może budzić, że tak wiele zadań, kluczowych z punktu widzenia dzisiejszej cywilizacji, powierza się niedojrzałej i zawodnej technologii.

Jaki jest więc powód tego, że pomimo swych słabości, informatyka jest powszechnie uważana za konieczny składnik naszego codziennego życia? Najwyraźniej nawet te kilka procent stanowiące miarę sukcesu informatyków daje korzyści, dla których warto tracić czas, ryzykować przekroczenie budżetu i zszargane nerwy.

400% normy, czyli planowe przekraczanie planu

Każdego, kto zetknął się w praktyce z problemem realizacji i wdrożenia systemu komputerowego musi dziwić, a nawet irytować, niezdolność informatyków do określenia dwóch podstawowych parametrów podejmowanych zadań - mianowicie terminu i kosztów. Co więcej, gdy już zostaną one podane, to zwykle albo grubo przewyższają oczekiwania klienta, albo nie mają nic wspólnego z rzeczywistością. Jeśli nawet system pojawi się u klienta w terminie, to z dużą dozą prawdopodobieństwa można przyjąć, że jest to jedynie marnie działający prototyp, na udoskonalaniu którego zespół programistów spędzi jeszcze długie godziny, tygodnie lub miesiące. Żeby pozbawić użytkowników resztek złudzeń dodajmy, że standardy zachodnie określają błąd początkowego szacowania kosztów i czasu trwania projektu na średnio 400%.

Winny użytkownik?

Mniej więcej od lat 70., gdy informatycy oficjalnie ogłosili istnienie tzw. kryzysu oprogramowania, szuka się sposobów wyjścia z tej niemiłej sytuacji. Poza wysiłkami idącymi w kierunku poprawienia jakości procesu wytwarzania programów (bezpieczne języki programowania, narzędzia wspomagające wyszukiwanie błędów) szukano również słabych punktów w początkowych stadiach pracy nad systemami informatycznymi. Zmiany i modyfikacje dokonywane w systemie, gdy istnieje on tylko "na papierze" w postaci specyfikacji, są znacznie mniej kosztowne niż zmiany w istniejącym już produkcie. W dobrze pojętym interesie zarówno informatyków jak i użytkowników leży więc opracowywanie szczegółowych i jednoznacznych specyfikacji systemów. I tu, niestety, zaczynają się schody.

Analiza wymagań jest działalnością czasochłonną, angażującą w ogromnym stopniu zarówno informatyka jak i użytkownika, przy czym tylko ten pierwszy bierze za to pieniądze. Zwykle dopiero po zakończeniu analizy da się w miarę rzetelnie określić koszty i czas trwania projektu (a w każdym razie jego najbliższych etapów). Na finansowanie takiej działalności godzą się zwykle nieliczni użytkownicy, uważając ją w najlepszym razie za nieopłacalną, a w najgorszym za próbę wyłudzenia pieniędzy. Firmy informatycznej nie stać z reguły na opłacanie kosztownej pracy eksperta-analityka, bez żadnej pewności, że zaowocuje ona korzystnym kontraktem. W rezultacie ktoś (z reguły użytkownik) ponosi znacznie większe koszty związane z przeróbkami i długotrwałym wdrażaniem źle zaprojektowanego systemu, nie spełniającego istotnych wymagań użytkownika.

Kolejnym problemem jest brak zrozumienia istotnych potrzeb i motywów wdrażania systemu przez samych użytkowników. Dobrze ilustruje ten fakt następująca anegdota: Na pytanie analityka, jaki jest strategiczny cel komputeryzacji w pewnej hucie metali kolorowych, jej właściciel wymienił minimalizację kosztów. Na to analityk: "Sprawa jest prosta. Zamknij pan interes, to koszty spadną do zera. Poproszę o moje honorarium..." Dwa tygodnie później celem komputeryzacji miała być już maksymalizacja zysków. Po wnikliwej analizie okazało się, że tak naprawdę system komputerowy potrzebny był po to, aby określać potrzebną wielkość i liczbę form odlewniczych.

Użytkownicy, którzy chcą, by system komputerowy rozwiązał wszystkie ich problemy z reguły sami proszą się o kłopoty. Rzadko kto zdaje sobie sprawę, ile nieformalnych rozwiązań, nielogiczności, sprzecznych kryteriów i niejasności kryje w sobie działalność większości organizacji. Komputer nigdy nie rozwiąże w sposób doskonały wszystkich problemów. Rozsądnie zaprojektowany system może jednak w sposób wielce satysfakcjonujący rozwiązywać niektóre z nich. Dlatego określenie obszaru działalności danej organizacji, który chcemy zautomatyzować, wymaga dużego zastanowienia. Jest to podstawowa i niezmiernie ważka decyzja podejmowana w projekcie informatycznym.

Programy na kilometry

Osobną sprawą związaną z kiepską efektywnością inżynierów od informatyki, jest sama złożoność materii, z jaką przychodzi im się zmagać. Można ją przedstawić obrazowo (i w dużym uproszczeniu) przeliczając programy na kilometry. Wydruk średniej wielkości systemu ma długość ok. kilometra i często jest jego jedyną rzetelną dokumentacją. Oznacza to konieczność przeczytania i zrozumienia wieluset metrów bieżących wydruku, gdy "gdzieś" pojawi się błąd. Oprogramowanie dla systemu wczesnego ostrzegania (system znany pod nazwą "Wojen Gwiezdnych") ma długość ponad 30 km! Słynne pomyłki tego systemu (np. uznanie wschodzącego Księżyca za nadlatujące eskadry radzieckich bombowców) mogą dzisiaj bawić, ale kto wie, co mogłoby się zdarzyć, gdyby nie nieufność jego użytkowników.

W tym szaleństwie nie ma metody

Czy wobec tych wszystkich problemów warto sobie w ogóle zawracać głowę komputeryzacją? Otóż, jeśli uświadomimy sobie wszystkie ograniczenia nowej technologii, wiedza ta może stać się naszą bronią, pozwalającą na właściwe rozplanowanie środków i metodyczne przeprowadzenie całego przedsięwzięcia. Nie warto myśleć poważnie o komputeryzacji, jeżeli nie jesteśmy zdecydowani poświęcić czas (zwykle kilka tygodni) i środki na przeprowadzenie wnikliwej analizy wymagań i bieżącą weryfikację jej wyników. Trzeba być również przygotowanym na to, że czas jakiś musi upłynąć zanim zespół informatyków przetworzy wyniki analizy na projekt techniczny, bez którego uniknięcie bałaganu w tworzonym oprogramowaniu jest niemożliwe. Tylko tak może powstać produkt satysfakcjonujący pod względem użyteczności i jakości. Presja czasu i ograniczonych środków finansowych sprawia, że większość projektów w Polsce (i bardzo wiele poza Polską) powstaje w sposób mniej lub bardziej chaotyczny. Jednoczesne tworzenie oprogramowania, określanie zadań systemu, wprowadzanie bieżących poprawek i zaspokajanie rosnącego w miarę powstawania systemu apetytu użytkowników na nowe funkcje sprawia, że w pewnym momencie zespół informatyczny przestaje panować nad swoim dziełem. Efektem jest albo niska jakość powstałego produktu, albo niespełnianie przezeń istotnych wymagań, albo jedno i drugie. Jako reakcja na problemy związane z tworzeniem systemów, w ostatnim dziesięcioleciu powstało szereg metodyk pozwalających informatykom na organizację i poprawę jakości swojej pracy. Noszą one wspólną nazwę metodyk strukturalnych, pozwalają bowiem na opis systemu na różnych poziomach szczegółowości - od opisu "strategicznego", określającego zakres automatyzacji, po szczegółowy opis wszystkich funkcji nowego systemu. Postępując metodycznie możemy z dużą dokładnością szacować koszty i czas trwania najbliższych faz projektu. Jeśli zamiast żądać od zespołu informatycznego gotowego systemu robiącego wszystko "tak, żeby było dobrze", "na wczoraj", stworzy się warunki, a nawet zachęci, do pracy zgodnej ze sprawdzoną metodyką - takie działanie na pewno się opłaci w ostatecznym rozrachunku.

Diagramy, czyli pismo obrazkowe

Wspomniałem wyżej o konieczności weryfikowania efektów analizy. Czy jest jednak możliwe weryfikowanie pracy informatyków przez ludzi nie mających z informatyką nic wspólnego? Faktem jest, że istnieje wiele opartych o matematykę sposobów opisu systemów, są one jednak zwykle niezrozumiałe dla użytkowników, a często i dla przeciętnych informatyków. Siłą metodyk strukturalnych jest sposób prezentacji wyników pracy w postaci rysunków - diagramów. W tym wypadku potwierdza się hasło "rysunek wart tysiąca słów". Diagramy tworzone w trakcie analizy są proste, łatwo zrozumiałe dla nieinformatyków i, co najważniejsze, jednoznacznie opisują te elementy systemu, które mają znaczenie dla użytkowników i realizatorów projektu. Praktyka wskazuje, że na etapie analizy użytkownicy wnoszą realny, cenny wkład do projektu, podnosząc jego jakość i stopień dostosowania do wymagań danej organizacji. W największym chyba realizowanym obecnie projekcie informatycznym w Polsce, systemie dla restrukturyzowanych PKP, grupa użytkowników bierze aktywny udział w pracach projektowych współtworząc i weryfikując diagramy opisujące poszczególne elementy systemu.

CASE, czyli lekarzu lecz się sam

Informatycy tworzą narzędzia do wspomagania projektów plastycznych, architektonicznych, elektronicznych, inżynierskich, ale czy potrafią stworzyć narzędzia efektywnie wspomagające ich własną pracę? Oczywiście tak! Od kilku lat rośnie ilość systemów wspomagających projektowanie oprogramowania, tzw. systemów CASE (Computer Aided Software Engineering). Zwłaszcza firmy informatyczne tworzące średnie i duże systemy komputerowe, komputeryzujące organizacje takie jak: banki, administracja, wojsko, systemy przemysłowe, wykorzystują z pożytkiem tego rodzaju oprogramowanie. Wspomaga ono proces tworzenia dokumentacji projektowej, zapewnia spójność i poprawność projektu, umożliwia standardyzację i pozytywnie wpływa na jakość prac analityków i projektantów. Barierą powodującą słabe wykorzystanie tej technologii w naszym kraju jest wysoki koszt jej wdrożenia - systemy te są zwykle dość drogie, wymagają przeszkolenia i zmiany stylu pracy informatyków. Zmiana tego stylu nie jest dotychczas wymuszana przez użytkowników. Można się jednak spodziewać, że wraz z powstawaniem dużych systemów komputerowych, będziemy świadkami kilku spektakularnych niepowodzeń przy ich opracowywaniu i wdrażaniu. Wówczas zapewne zmieni się punkt widzenia użytkowników na to, co jest kluczem do udanej komputeryzacji. Nie jest nim na pewno deklarowana pochopnie przez informatyków szybkość wdrożenia i niska cena, ale profesjonalne, metodyczne podejście.

Presja czasu i ograniczonych środków finansowych sprawia, że większość projektów informatycznych powstaje w sposób mniej lub bardziej chaotyczny. Efektem jest albo niska jakość powstałego produktu, albo niespełnianie przezeń istotnych wymagań, albo jedno i drugie.