Permanentny kryzys

Tytułowe określenie pojawiło się w technologii informatycznej kilkadziesiąt lat temu. Czy jest nadal aktualne? Dziesięciolecia branżowych doświadczeń wskazują na bardziej precyzyjną, ale ciągle niejednoznaczną odpowiedź.

Tytułowe określenie pojawiło się w technologii informatycznej kilkadziesiąt lat temu. Czy jest nadal aktualne? Dziesięciolecia branżowych doświadczeń wskazują na bardziej precyzyjną, ale ciągle niejednoznaczną odpowiedź.

W medialnych doniesieniach, zarówno specjalistycznych, jak i przeznaczonych dla szerokiego ogółu odbiorców, można napotkać wiele pozytywów, dotyczących z sukcesem zakończonych projektów informatycznych. Niemało jest także informacji o klęskach na tym polu. Żartobliwie chciałoby się powiedzieć, że "jest dobrze, ale nie beznadziejnie". Pojęcie ciągłego kryzysu informatyki (permanent crisis of information technology) wyraziście zidentyfikowano na szczycie NATO w roku 1968, w znanej miłośnikom narciarstwa miejscowości Garmisch-Partenkirchen. Wówczas to postanowiono, aby projektowanie oprogramowania wyodrębnić jako samodzielną dziedzinę inżynierii. Od tego biurokratycznego zapisu minęło wiele lat. Z jaką sytuacją mamy do czynienia dziś?

Warto tu sięgnąć do cyklicznie przygotowywanych opracowań o wdzięcznej nazwie Chaos-Report autorstwa Standish Group Inc. (USA). Od z górą dziesięciu lat jej badacze przeanalizowali w setkach przedsiębiorstw tysiące projektów informatycznych, dzieląc je na trzy grupy:

  • sukces (successful) - projekt zakończono i wdrożono zgodnie z założeniami,
  • porażka (failed) - projekt przerwany bądź nie wdrożony,
  • wątpliwość (challenged) - projekt zakończono i wdrożono, nie zachowując założonych ram finansowych, czasowych bądź jakościowych.
Wieloletnie statystyki dają, zgrubnie, trójdzielny obraz: w każdej kategorii znajduje się ok. 1/3 projektów. Niemniej w określonych latach udział poszczególnych grup waha się nawet o 10 punktów procentowych - zainteresowanym szczegółami można polecić stosowną stronę internetową (www.standishgroup.com). Niezależnie od nich generalny wniosek jest jasny: większość projektów nie kończy się pełnym sukcesem. Cytowane raporty pośrednio odpowiadają też na przyczyny niepowodzeń, wskazując na pięć najważniejszych czynników sukcesu:

  • wsparcie kierownictwa (18%),
  • zaangażowanie użytkowników (16%),
  • doświadczenie wykonawców projektu (14%),
  • jasne cele biznesowe (12%),
  • minimalizacja zakresu projektu (10%).
Pozostałe 25% sukcesu to użycie standardów informatycznych, niezmienność podstawowych wymagań, formalna metodologia i wiarygodne oszacowania. 100-proc. całość zamyka 5% czynników kategoryzowanych jako "inne" (other criteria).

Magiczne figury

Dla wyspecyfikowania symptomów omawianego fenomenu należy zauważyć, że wdrażanie projektów informatycznych rozgrywa się w polu sił "magicznego" trójkąta, którego wierzchołki wyznaczają: czas, koszty i jakość (niekiedy mówi się o kwadracie, rozróżniając dodatkowo jakość i funkcjonalność). Powiążmy zatem z tymi elementami główne symptomy wymienionego kryzysu:

CZAS - długi czas projektowania, przekraczanie terminów odbioru projektu oraz realizacji jego poszczególnych faz, zbyt długie czasy związane z usuwaniem nieuzasadnionych błędów, błędy szacowania czasów, przecenianie technicznych aspektów zadania, źle zaplanowane szkolenia oraz testowanie systemu;

KOSZTY - zbyt wysokie koszty projektu, przekraczanie planowanego pułapu kosztów, niewystarczająca wiedza członków zespołu, nierealistyczna ocena kosztów ze względów pozamerytorycznych, źle wykorzystane środki sprzętowe i pomocnicze, brak kontroli kosztów, błędy w metodach planowania;

JAKOŚĆ - zawodność, nieergonomiczność, ograniczona funkcjonalność, słaba wydajność, system słabo rozszerzalny i niestandaryzowany, niewystarczająca specyfikacja wymagań użytkownika, złe praktyki testowania i odbioru, niekorzystanie z technik zarządzania jakością, brak dokumentacji.

Niekiedy wydaje się, że pakiety software'owe wręcz wymykają się spod kontroli ich twórców, którzy pod presją wymagań rynkowych, za wszelką (dosłownie) cenę chcą wprowadzić do użytku nową wersję produktu, licząc na zyskanie przewagi nad konkurencją. Czy jest to zdanie uzasadnione? Wyobraźmy sobie, że u wybranego dilera chcemy kupić nowy samochód. Godzimy się na cenę 50 tys. zł i miesięczny termin dostawy. Dodatkowo, jako klienci, żądamy, aby nasze cacko miało akurat zielony lakier w pomarańczowe gwiazdki. Co się dzieje dalej?

Samochód możemy odebrać dopiero po trzech miesiącach (urlop już dawno minął!). W zamian za to płacimy dwa razy drożej. Z gwiazdek rezygnujemy, bo musiałoby jeszcze drożej kosztować, o czasie ich realizacji nie wspominając. Razem z nowym autem dostajemy też pokaźną listę wad "dostrzeżonych w toku produkcji". Wytwórca "gratuluje udanego zakupu", stwierdzając w instrukcji obsługi wyraźnie: "w przypadku nieprawidłowej pracy silnika, należy zjechać z drogi, zatrzymać auto i chwilę odczekać, po czym można kontynuować jazdę". Tak więc, w praktyce, kilka razy dziennie: zjeżdżamy, zatrzymujemy i kontynuujemy. I nie jest to czysto fikcyjny opis motoryzacyjnego bubla. Owszem, takich samochodów się dziś nie produkuje, ale wystarczy przyłożyć prezentowany przykład do cech współczesnego oprogramowania, żeby przekonać się, czy zawsze jest on tak bardzo odległy od rzeczywistości.

Nowy program i stare błędy

Najgorzej jest oczywiście z oprogramowaniem specjalistycznym, przeznaczonymdla profesjonalistów, gdyż jego producent zakłada, iż:

  • użytkownikami jest wąska grupa osób, a liczba instalacji niewielka,
  • większa wiedza informatyczna odbiorcy prowokuje niższą jakość produktu,
  • ludzie z branży szybciej wybaczają kolegom błędy, które sami popełniają,
  • informatycy lubią walczyć z komputerami, bo to jest ich praca,
  • decyzje o zakupie podejmują menedżerowie, a nie specjaliści od oprogramowania.
Ale nawet aplikacje, które masowo instalowane są na tysiącach konfiguracji, nie są wolne od "chorób wieku dziecięcego". Dotyczy to zarówno całych kombajnów software'owych dużego kalibru, jak i oprogramowania biurkowego, przeznaczonego dla szarych zjadaczy bitów i bajtów.

Przejawem "grzeczności" ze strony renomowanych firm jest dostarczanie, bez żenady, swoich pakietów wraz z pokaźnymi listami zlokalizowanych błędów (bugs). W przypadku problemów eksperci serwisowi doradzają jak najszybsze przejście na nową wersję programu, która jest oczywiście pozbawiona starych błędów, ma za to całą masę nowych. A może nawet mechanizm ten bardziej jeszcze zbliżony jest do bezwzględnego prawa Murphy'ego: "stary program to stare błędy, nowy program to nowe i stare błędy". Żadna bowiem aplikacja nie działa samotnie, a tak się dziwnie składa, że współpraca różnych programów potrafi zaowocować bezsensownym komunikatem o błędzie typu "Error-Setup 01234, za mało pamięci operacyjnej - potrzeba 2,5 MB, do dyspozycji jest tylko 3,7 MB, czy przydzielić więcej pamięci?". Po braku reakcji na 4 proponowane odpowiedzi: "tak", "nie", "nie wiem", "cancel", nie pozostaje nam nic innego, jak użyć "małpiego chwytu", czyli wiadomej kombinacji klawiszy: CTRL+ALT+DEL.

Jak dotąd udało nam się scharakteryzować kryzysowe zjawiska w projektach IT i ich symptomy. Nadal jednak niewiele wiemy o samych przyczynach choroby. Dlaczego łatwiej w ciągu trzech miesięcy zbudować wykończony dom i w nim zamieszkać niż planowo skonstruować system informatyczny? Poszukajmy zatem odpowiedzi na pytanie w samej specyfice informatyki. Przede wszystkim rezultatem większości (zwłaszcza dużych) projektów informatycznych jest wersja oprogramowania o numerze 1.0.

Szklane domy

Domy buduje się według typowych, wielokrotnie sprawdzonych w praktyce, projektów. Ale nawet gdy projekt jest indywidualny, to istnieje minimum gwarancji, że standaryzowana jest sama procedura projektowa. Wiadomo jak liczyć statykę i zapotrzebowanie materiałowe, wiadomo jak przejść do rysunków wykonawczych i nie ma wątpliwości, ile czasu potrzeba na zastosowanie określonej technologii. Nawet duże i spektakularne projekty budowlane realizuje się na czas - jeśli zaś "padają", to z przyczyn pozabranżowych, np. losowych czy finansowych. Tu nie dobudowuje się piwnic na strychach. W informatyce: i owszem.

Każdy nowy projekt informatyczny jest nowym wyzwaniem i ryzykiem, a jego indywidualność przeważa z reguły nad elementami typowości. Nasuwa się tu nieodparcie skojarzenie z modelem deterministycznego chaosu. Tym bardziej nieprzypadkowe, że dotyczy ono systemów złożonych, a takimi są właśnie informatyczne. W każdym razie ich złożoność przewyższa kompleksowość skojarzonych z nimi podsystemów materialnych.

Kolejną różnicą jest analogowość wymiaru materialnego (przynajmniej w makroświecie) i dyskretność (cyfrowość) narzędzi informatycznych i ich tworów. Wprawdzie wzbogacamy się o programy korzystające z logiki rozmytej (fuzzy logic), niemniej nadal dominującym jest paradygmat zerojedynkowy. A to oznacza zmniejszoną, w relacji do świata analogowego, elastyczność. Wprawdzie budowlaniec może teoretycznie policzyć optymalny skład zaprawy murarskiej, ale w praktyce nie ma większego znaczenia, czy na trzy łopaty piachu dorzucimy czwartą, mniej lub bardziej kopiastą. Zaprawa zwiąże cegły. Tymczasem jeden znak postawiony lub opuszczony w programie może być przyczyną, dosłownie, katastrofalnych skutków. Błąd konwersji 64-bitowej liczby zmiennoprzecinkowej na 16-bitową liczbę całkowitą wstrząsnął dżunglą Gujany podczas eksplozji rakiety Ariane V, w dniu 4 czerwca 1996 r. Koszt błędu: miliard dolarów. Przykłady można mnożyć.

I wreszcie rzecz najważniejsza: syndrom wieży Babel. Projekt informatyczny jest z definicji interdyscyplinarny. Informacja ma charakter dyfuzyjny i jako czynnik integrujący wiąże swoim przepływem inne obszary projektowe. To z kolei oznacza konieczność współpracy specjalistów z różnych dziedzin. Ci zaś mówią o tych samych sprawach różnymi językami. Z punktu widzenia informatyka wygląda to tak, że użytkownik nie bardzo wie czego chce, ale za to, po wdrożeniu projektu, bardzo dokładnie wie... czego nie chce.

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

TOP 200