Rok 2000 obwieści swoje nadejście kryzysem, który dotknie praktycznie całą ludzkość. Jedni, bogatsi, odczują go w sposób bezpośredni - zostaną wyłączone telefony, błędnie naliczone odsetki bankowe, wreszcie zawiodą systemy sterowania i kontroli. Inni, biedniejsi, odczują go pośrednio, w wyniku przejściowego chaosu gospodarczego mogą nie zjeść codziennej miski ryżu, zapewnianej przez złożone, a chwilowo zdezorganizowane, powiązania gospodarcze.

Źródła problemu roku dwutysięcznego są jednak dużo głębsze niż banalna niefrasobliwość programistów oraz pesymistyczne (czy raczej optymistyczne?) przewidywania, co do krótkiego czasu "życia" ich produktów.

Prawdziwym źródłem tego problemu jest kryzys oprogramowania, którego ćwierć wieku będziemy "świętować" już za rok.

Symptomy kryzysu oprogramowania (soft-ware crisis) najlepiej ilustrują badania Standish Group, wykonane w roku 1995. Wynika z nich, że amerykańskie przedsiębiorstwa przeznaczają 81 mld USD rocznie na projekty, które zostały przerwane. Nie dokończonych pozostaje 31% wszystkich projektów. Ponad 50% projektów przekracza budżet więcej niż dwukrotnie, a jedynie 9% kończy się w terminie, przy założonych kosztach.

Inżynieria oprogramowania jest jedyną dziedziną inżynierii, w której kryzys jest tak głęboki i tak permanentny. W ankiecie przeprowadzonej w marcu br. na stronie internetowej Computerworld Online ok. 75% odwiedzających odpowiedziało twierdząco na pytanie: "Czy wraz z rozwojem oprogramowania jego jakość pogarsza się?". Abstrahując od pewnej tendencyjności pytania, a także umiarkowanej wiarygodności próbki, należy stwierdzić, że w powszechnym odczuciu jakość oprogramowania jest coraz gorsza.

Kryzys jest więc nie tylko trwały, ale także pogłębia się. Należy zastanowić się, jakie są jego źródła.

Opracowania na temat kryzysu oprogramowania często zawierają analizę jego przyczyn. Za zasadniczą przyczynę uważa się rosnącą wielkość i złożoność programów. Na przykład MS-DOS 1.0, napisany w roku 1981, zawierał ok. 4000 linii kodu. Windows NT 1.0, powstały kilkanaście lat później, zawierał już 5,6 mln linii kodu.

W podobnej proporcji rośnie liczebność zespołów informatyków. Zarządzanie pracą takich zespołów jest już dziś zadaniem równie skomplikowanym, jak pisanie programów. A o ile analiza, projektowanie i programowanie dopracowały się już otoczki metodologicznej, pozwalającej na podstawowe co najmniej planowanie i monitorowanie prac, o tyle skuteczne zarządzanie procesem informatycznym nadal pozostaje kwestią talentów i doświadczeń pojedynczych osób.

Niewątpliwie nie bez znaczenia jest ogromny wzrost zatrudnienia w przemyśle informatycznym. Nie sposób w ciągu jednego pokolenia wykształcić tak ogromnych mas, jakie dziś pracują przy tworzeniu systemów informatycznych. Proces przygotowania kompetentnych informatyków przez uczelnie jest czasochłonny i znacznie mniej wydajny niż oczekiwaliby pracodawcy. Należy uczciwie przyznać, że przemysł informatyczny żąda dziś od pracowników znacznie niższych kwalifikacji niż przed kilkunastu laty. Niestety, ma to przełożenie na jakość tworzonych przez nich programów.

Informatycy nadal za mało wysiłku wkładają w poznanie i rozwiązywanie potrzeb odbiorcy. Nie potrafią porozumiewać się z użytkownikami, spojrzeć na system z ich perspektywy. W efekcie wiele pracy poświęcają zapewnianiu wyimaginowanych bądź nieistotnych cech, pozostawiając jednocześnie na boku rzeczywiste potrzeby użytkownika. Producent samochodu nigdy nie skonstruowałby go tak, żeby do nalania benzyny potrzebne były śrubokręt, kombinerki i młotek. Ale przemysł informatyczny uważa za naturalne, że do codziennej obsługi niektórych programów jest potrzebna obszerna wiedza o systemie operacyjnym i bazach danych.

Niedojrzałość procesu produkcji oprogramowania przejawia się w archaicznych proporcjach czasu i zasobów poświęcanych na poszczególne fazy. Według badań, tylko ok. 10% czasu należy poświęcić na programowanie. Zdecydowana większość powinna obejmować zebranie wymagań, analizę, projektowanie i testowanie produktu. Wydaje się, że nadal wiele firm stosuje odwrotne proporcje, w szczególności w kraju leżącym nad Wisłą.

Zbawieniem, ale jednocześnie przekleństwem inżynierii oprogramowania jest prawo Moore'a. Pozwala ono bowiem zaniedbywać rygoryzm w optymalnym wykorzystaniu zasobów komputera (pamięci operacyjnej i masowej oraz mocy obliczeniowej) w nadziei, że kiedy program ujrzy światło dzienne, zasoby te będą na tyle duże, iż z powodzeniem pomieszczą nawet najbardziej niefrasobliwie pisany system. W wyniku tego, mimo ogromnego postępu w dziedzinie sprzętu, coraz lepsze parametry komputera są z nawiązką "konsumowane" przez wzrastające wymagania oprogramowania. Przy minimalnej poprawie funkcjonalności rozmiar programów znacząco zwiększa się, a ich jakość i wydajność maleją.

Na szczególną uwagę zasługuje jednak uległość odbiorców oprogramowania.

Programy, które instalujemy na naszych komputerach, zawierają coraz więcej usterek. Jednocześnie ich producenci starają się przerzucać na użytkowników część kosztów związanych z zapewnieniem jakości. I, co napawa zdumieniem, odbiorcy akceptują ten stan rzeczy.

Tradycją stało się już wprowadzanie na rynek tzw. wersji beta programów. De facto oznacza to, że producent wykorzystuje przyszłych odbiorców jako darmowych testerów, tym samym oszczędzając na weryfikacji produktu w obrębie swojego przedsiębiorstwa.

Pojęcie "produktu" w przypadku oprogramowania jest bardzo odległe od analogicznych pojęć z innych dziedzin inżynierii. Ktoś nawet złośliwie powiedział, że premiera danego oprogramowania to moment, kiedy producent przestaje udostępniać prototyp za darmo wybranym użytkownikom, a zaczyna je sprzedawać wszystkich chętnym.

Użytkownicy pokrywają największą część kosztów związanych z błędami w "produktach". Na podstawie dostarczanych przez odbiorców raportów o błędach pisane są uaktualnienia. Są one wprawdzie bezpłatne, ale koszty ich dystrybucji, instalacji i koniecznych zmian w środowisku odbiorcy są całkowicie pokrywane przez niego. Przypomina to sytuację, w której producent np. pralki wytwarza część zastępującą wadliwy element, ale każdy posiadacz feralnej pralki musi po nią przyjechać do fabryki i następnie ją samodzielnie wymienić (lub wynająć fachowca, którego opłaci).

Za rzecz normalną uważane są tzw. ograniczone gwarancje, które tak naprawdę oznaczają brak jakiejkolwiek gwarancji. Najcelniej ujął to felietonista w numerze 8/94 miesięcznika Wiedza i Życie: "To, za co producent leku czy samochodu odpowiada całym majątkiem, w przypadku producenta oprogramowania wyjęte jest poza nawias odpowiedzialności. Fakt, że społeczeństwo taki stan rzeczy toleruje, świadczy dobitnie jak mało poważnie traktuje ono cały ten infantylny "przemysł informatyczny", jak niewiele, poza rozrywką, po nim się spodziewa".

Można więc postawić tezę, że kryzys oprogramowania jest częściowo zawiniony przez jego odbiorców. Przez ich wyjątkową tolerancję niskiej jakości produktów software'owych i presję na wprowadzenie nowych wersji stworzyli wśród producentów swoiste poczucie komfortu. Poczucie to - w dłuższej perspektywie - ma jednak negatywne skutki dla wszystkich graczy na rynku.

Zarówno w każdej dziedzinie w stadium kryzysu, jak i informatyce pojawiają się jaskółki wiosny i fałszywi prorocy.

Co pewien czas świat inżynierii oprogramowania jest wstrząsany doniesieniem o rewolucyjnej technologii, metodologii bądź produkcie, który ma zmienić tę dziedzinę i zakończyć jej kryzys.

Technologia obiektowa miała automatycznie zapewnić ponowne użycie, stabilność i skalowalność tworzonych systemów. Dziesięć lat doświadczeń wskazuje jednak, że nie okazała się remedium na wszystkie bolączki, choć wiele pożytecznego stało się za jej sprawą.

Narzędzia CASE miały podwyższyć produktywność zespołów programistycznych i zapewnić automatyczną koordynację ich prac. Współczesne narzędzia CASE w znacznym stopniu pomagają zwizualizować myśli projektanta (co jest niewątpliwą pomocą dla osób będących wzrokowcami) i automatycznie dokumentują projekt, ale same z siebie nie wspomagają procesu myślenia.

Internet miał umożliwić współpracę zespołów pracujących w oddaleniu geograficznym, a także ułatwić dystrybucję nowych wersji oprogramowania. Niestety, zespół informatyczny to nie tylko rozmowa on-line czy poczta elektroniczna, lecz także organizacja pracy, jej atmosfera, wspólna baza kulturowa i aktywność pozazawodowa. Prace nad jednym projektem w różnych miejscach są trudne do przeprowadzenia. A niska, skuteczna przepustowość łączy, a także słabe zaawansowanie technologii płatności internetowych bardzo utrudniają dystrybucję programów w sieci.

Języki "wyższego" poziomu, czyli programowanie deklaratywne, graficzne, podobnie jak narzędzia CASE, pozwalają znacząco podnieść wydajność fazy "ręcznej", ale nie zastąpią ani nawet istotnie nie wspomogą procesu myślenia. Ponadto w praktyce komercyjnego tworzenia systemów trzeba momentami panować nad najdrobniejszymi szczegółami implementacyjnymi, np. procedur krytycznych czasowo. Podniesienie poziomu abstrakcji języka programowania daje efekt uboczny w postaci utraty nad nimi kontroli. A to one mogą przesądzać o jakości produktu.

"Budowa" programu zamiast jego "pisania", czyli tworzenie go z gotowych modułów (komponentów), daje obiecujące wyniki. Jednak jest to dziedzina zbyt młoda, by można ją było ocenić jednoznacznie pozytywnie.

Reasumując, należałoby powtórzyć to, co powiedział przed dziesięcioma laty Frederick P. Brooks w klasycznym eseju No Silver Bullet: "Nie istnieje żadna technologia (informatyczna) czy technika zarządzania, która sama z siebie dawałaby nadzieję na poprawę produktywności, bezpieczeństwa i prostoty nawet o rząd wielkości w ciągu dekady".

Czy jesteśmy skazani na kryzys oprogramowania?

W krótkiej perspektywie raczej tak. Można przypuszczać, że pogłębiać go będzie zjawisko natury demograficznej, tj. przejmowanie pałeczki przez pokolenie, które wyrosło w kryzysie oprogramowania i niska jakość systemów jest dla nich normalnością. Będzie ono tworzyć słabe programy, bo po prostu nigdy nie poznało programów dobrych.

Prof. Władysław M. Turski porównał poszukiwania sposobu zakończenia kryzysu oprogramowania do prób uzyskania kamienia filozoficznego przez średniowiecznych alchemików. I choć kamienia filozoficznego wtedy nie znaleziono, to jednak przy okazji stworzono podstawy chemii, a więc położono podwaliny pod dzisiejsze sukcesy tej dziedziny. Można więc per analogiam przypuszczać, że także dzisiejsze wysiłki w celu przezwyciężenia kryzysu oprogramowania mogą w dalekiej przyszłości przynieść efekty. Nie w postaci jednorazowej rewolucji jakościowej, ale raczej przez "pracę organiczną".

I choć nie pojawiają się jeszcze widoczne skutki, to widać pewne pozytywne zjawiska: przedsiębiorstwa i osoby przestają postrzegać systemy informatyczne jako "gustowne cacka", pozwalające "unowocześnić" firmę i zabłysnąć w mediach. Zaczęły liczyć konkretne korzyści (bądź straty), które przynosi wdrożenie systemów.

Gremia tzw. think tanks informatyki uznały kwestię jakości za kluczową w dzisiejszym stadium rozwoju tej nauki. Świadomość ta zwiększy nakłady, a nakłady - rozwiązania. W dalszej perspektywie można więc spodziewać się pewnych istotnych zmian.

Rządy zaczynają dostrzegać patologię związaną z brakiem odpowiedzialności producentów oprogramowania za tworzone przez nich produkty. Problem roku 2000 jest znakomitą okazją, aby uświadomić ją społeczeństwu. Powoli pojawiają się uregulowania prawne, które nie pozwalają na całkowite zdjęcie odpowiedzialności w tzw. ograniczonych gwarancjach. Zmuszą one producentów do przeznaczenia większych środków na kwestie jakości i niezawodności.

Dzięki technologii obiektowej i budowie systemów na bazie komponentów rośnie proporcja kodu ponownie użytego do nowo napisanego. Mając standardowe składniki znanej jakości, łatwiej będzie zapewnić jakość końcowego produktu.

Przetrwamy więc najbliższego sylwestra, przetrwamy i kryzys oprogramowania, choć przed nami jeszcze niejeden taki ponury jubileusz. Obyśmy tylko dożyli czasów, kiedy systemy informatyczne będzie tworzyć się w przewidywalnym czasie po określonych kosztach i określonej, wysokiej jakości. Mimo wszystko należy być optymistą.