O dużych programach i projektach

Kilka tygodni temu dostałem pilną wiadomość od przyjaciela, zaczynającą się co najmniej niezrozumiałymi zdaniami: "Co wiesz o firmie Sterling? Mój zespół używa IEF. Czy to jest dobra wiadomość?"

Kilka tygodni temu dostałem pilną wiadomość od przyjaciela, zaczynającą się co najmniej niezrozumiałymi zdaniami: "Co wiesz o firmie Sterling? Mój zespół używa IEF. Czy to jest dobra wiadomość?"

Wkrótce zorientowałem się o co mu chodzi. Sterling Software właśnie poinformował, że kupuje oddział programistyczny firmy Texas Instruments, łącznie z narzędziem do opracowania aplikacji Composer, znany do niedawna pod oryginalną nazwą Information Engineering Facility, w skrócie IEF.

IEF było to główne mainframe'owe narzędzie programistyczne w firmie mego przyjaciela. Dobra wiadomość, zarówno dla niego, jak i innych zespołów to fakt, że Sterling Software zamierza rozwijać IEF po wycofaniu się Texas Instruments z działalności programistycznej.

Starszym programistom przypomina to historię z dawnych lat, gdy wielką nowością były narzędzia CASE, a "inżynieria programowania" robiła furorę.

Tak naprawdę, narzędzia CASE nigdy dobrze się nie przyjęły. Wiele z nich obiecywało dużo, a nie dostarczało wiele możliwości. Ale nawet te, które poprawnie działały - i stanowiły cenne uzupełnienie zestawu narzędziowego zespołów programistów - wymagały ogromnej zmiany w podejściu do tworzenia programów.

Idea główna inżynierii oprogramowania opiera się na analogii, że równie mało przypomina ona programowanie, jak inżynieria techniczna przypomina nitowanie lub zalewanie betonem. Inżynieria to analiza i projektowanie, czyli praca, którą trzeba wykonać, zanim zacznie się zalewać zbrojenie betonem lub pisać choć jedną linię kodu. Wymaga to dyscypliny i rygorystycznego podejścia do projektu. I szczerze mówiąc - wcale nie jest to zabawne.

Kodowanie - to jest frajda. Aby się o tym przekonać - zapytajcie dowolnego programistę. Dla prawdziwego miotacza kodu, analiza i projektowanie programu to nuda.

Nic dziwnego, że inżynieria oprogramowania nigdy naprawdę nie zadomowiła się w zespołach programistów. Zamiast niej programiści stosowali tradycyjne metody kodowania, aż do chwili, gdy pojawiła się nowa wielka idea: szybka ścieżka tworzenia aplikacji (Rapid Application Development - RAD) i narzędzia, takie jak Visual Basic czy PowerBuilder.

Narzędzia RAD mają wszystko, CASE nic. Są one modne, kolorowe i łatwo demonstruje się szefowi ich właściwości. Wprawdzie mają ograniczony zakres stosowania, ale szybko się amortyzują.

Problem w tym, że właśnie mają ograniczony zakres stosowania. Za ich pomocą szybko buduje się programy taktyczne, ale nie dają się łatwo skalować, aby przystosować je do potrzeb przedsiębiorstwa.

Tymczasem projekty muszą dać się łatwo skalować, ponieważ opóźniamy się z uaktualnieniem wielu aplikacji w firmie.

Prawda jest taka: od dawna mamy nadzieję, że ktoś wreszcie opracuje magiczne narzędzie o właściwościach pakietów RAD, nie wymagające inżynierii oprogramowania.

W efekcie od wielu lat zajmujemy się taktycznymi aplikacjami na biurko i narzędziami do nich, natomiast ważne aplikacje odkładamy na górną półkę.

Magiczne narzędzia nigdy się nie zmaterializowały. A już wkrótce trzeba będzie budować wielkie aplikacje, dające się skalować dla potrzeb całego przedsiębiorstwa. Oznacza to powrót do narzędzi inżynierii oprogramowania i ogromnego wysiłku, jaki trzeba w nie włożyć.

Nie da się niestety tej pracy wykonać za pomocą narzędzi typu RAD. Te wielkie projekty wymagają pracy inżynierskiej - prawdziwej analizy potrzeb funkcjonalnych firmy, odpowiedniego projektu i właściwych decyzji dotyczących infrastruktury. Będzie to niestety kosztowne i czasochłonne. Nie będzie łatwo o tym przekonać naszych szefów, którzy niewiele wiedzą o technice.

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

TOP 200