Senne marzenie

Skomputeryzowana organizacja planuje poprawić jej skuteczność na konkurencyjnym rynku. Skuteczność ta mierzona jest wartościami wskaźników określających dynamikę rozwoju, rentowność i wydajność. Wymagane zmiany wskaźników są analizowane przez doradczy system informatyczny, firmy, w których zmienić musi się obieg informacji, struktura informacyjna i polityka kadrowa. Analitycy szczebla zarządzania wprowadzają odpowiednie zmiany w dokumentacji (elektronicznej) obiegu danych i w strukturze informacji przedsiębiorstwa. Powoduje to automatyczną generację specyfikacji zmian w aplikacjach "operacyjnych". Specyfikacje przetwarzane są przez systemy automatycznie rekonstruujące "operacyjny" system informatyczny. W parę dni koncepcja wypracowana na szczeblu zarządzania, znajduje wsparcie w uaktualnionym systemie informatycznym. Wydajność i rentowność rosną, nasze akcje idą w górę, a konkurencja błaga o litość...

Mój znajomy analityk, zajmujący się od dwóch lat systemem informatycznym dla jednego z największych polskich dzienników ma... właśnie takie sny.

Niestety, zapewne długo jeszcze powyższy model pozostanie tylko jego marzeniem. Integracja procesu zarządzania i generacji systemów informatycznych to dziś tylko utopia. Najlepszymi mechanizmami produkcji systemów, jakie informatyka oferuje, pozostają metodyki strukturalne i pakiety wspomagania projektowania - CASE.

Po co ten ambaras?

Mówiąc o pakietach CASE, należy sobie zadać pytanie o sens wykorzystania tego typu kosztownych narzędzi. Stosunek wielu producentów oprogramowania do technologii CASE jest zwykle mieszaniną fascynacji, nadziei i sceptycyzmu. Zachwycamy się nowością rozwiązań, mamy nadzieję, że oto wreszcie odkryto panaceum na dzisiejsze bolączki informatyki, a jednocześnie sceptycznie patrzymy na koszty wdrożenia nowych rozwiązań. Niełatwo jest uzasadnić ekonomicznie koszty związane z wprowadzaniem technologii CASE w kraju, gdzie wciąż wiele poważnych systemów przetwarzania danych tworzy się prostymi narzędziami typu dBASE. Użytkownik nie wierzy, że system powinien być zaprojektowany, zespoły informatyczne są niewielkie, a płace programistów umiarkowane. Przyglądając się sytuacji w krajach, gdzie informatyka stoi na najwyższym poziomie można wysnuć wniosek, że stosowanie technologii CASE wymuszane jest zwykle następującymi czynnikami:

* Skalą projektów - projekty angażujące wiele osób przez wiele miesięcy, to niezmiernie złożone przedsięwzięcia organizacyjne, praktycznie nie do ogarnięcia bez metodycznego podejścia.

* Żądaniem poprawy jakości systemów związanych z potrzebą zapewnienia funkcjonalności systemów zgodnych z oczekiwaniami użytkowników.

* Koniecznością podniesienia jakości i efektywności pracy wymuszaną przez konkurencję. Wszystkie te czynniki wiążą się z przejściem od mniej lub bardziej chaotycznego procesu wytwarzania oprogramowania do sposobów pracy opartych na metodykce. Metodyki wprowadzają do projektów dyscyplinę, kontrolę jakości, standardy, metody zarządzania. Wymagają jednak tworzenia sporej liczby dokumentacji. Wreszcie, powstające specyfikacje pozwalają na zautomatyzowanie procesu konstrukcji, poprzez generację kodu. Zarządzanie dokumentacją projektu i generowanie systemów wymaga jednak odpowiednich narzędzi. Jeśli nawet dotychczas nie było w Polsce miejsca dla systemów CASE - problemy we wdrożeniach dużych, ważnych dla kraju systemów informatycznych zwiastują zmiany - oto nadchodzą duże projekty, duże zespoły i naprawdę duże kłopoty.

Paweł i Gaweł w jednym stali domu?

Bez wdawania się w akademickie definicje możemy przyjąć ogólnie uznany podział narzędzi typu CASE na pakiety wyokiego poziomu (Upper CASE) i niskiego poziomu (Lower CASE). Pakiety wysokiego poziomu są narzędziami wspomagającymi koncepcyjne etapy pracy nad systemem informatycznym - przede wszystkim etapy Strategii, An alizy i Projektowania. Zawierają mechanizmy do tworzenia i zarządzania dokumentacją projektową oraz narzędzia do utrzymywania i weryfikacji spójności powstającej specyfikacji. Pakiety niskiego poziomu to oprogramowanie do konstrukcji aplikacji, a więc narzędzia pozwalające zamienić logiczną specyfikację systemu na działający produkt. Mam tu na myśli różnego rodzaju generatory kodu, systemy języków czwartej generacji i "składacze" aplikacji w środowiskach graficznych.

Na pierwszy rzut oka może się wydawać że pakiety niskiego i wysokiego poziomu wzajemnie się uzupełniają, a ich producenci powinni żyć w zgodnej współpracy. Tak jednak nie jest. Producenci systemów Upper i Lower CASE są trochę jak Paweł i Gaweł, co to niby w jednym stali domku, ale w gruncie rzeczy toczyli ze sobą niewypowiedzianą wojnę. Producenci pakietów wysokiego poziomu wydają się czasem sugerować, że strukturalna dokumentacja projektowa może zastąpić działający produkt. Z kolei twórcy systemów niskiego poziomu zdają się wyznawać zgubną zasadę, że wszystko jedno jak system powstanie - byle powstał szybko. Niewątpliwie na korzyść systemów niskiego poziomu, takich jak Magic, SQL Windows Gupty, czy PowerBuilder firmy Powersoft przemawia łatwy do wykazania wzrost wydajności pracy programistów. Za pomocą tych narzędzi rzeczywiście można w krótkim czasie skonstruować np. działający system księgowy. Program polega jednak na tym, że można tego dokonać wtedy, gdy wie się już jak system powinien wyglądać. Co więcej, program powstały za pomocą narzędzi niskiego poziomu, nie ma dokumentacji koncepcyjnej, a więc jest niemal równie trudny w utrzymaniu jak nieudokumentowany kod programu.

Tak więc w reczywistości konflikt między producentami narzędzi Lower CASE i Upper CASE jest niezasadny. Pytanie nie brzmi "Upper czy Lower CASE?". Każde z tych narzędzi dotyczy innej fazy cyklu projektowego. Jeśli wielkość projektu, niestałoość zespołu, czy perspektywa wieloletniej eksploatacji systemu skłania nas do zastosowania strukturalnych metod analizy i projektowania, naturalne będzie użycie narzędzi wysokiego poziomu, wspomagającym taki właśnie sposób pracy. Zupełnie osobną sprawą jest zastosowanie generatorów kodu lub składaczy aplikacji. W dużych projektach poprawa efektywności zapewniana przez generatory będzie zredukowana poprzez nieduży udział fazy konstrukcji w całkowitych "kosztach" projektu. Znacznie ważniejsza jest tu elastyczna metodyka i wygodne narzędzie do jej realizacji.

W małych projektach nie zawsze warto stosować pełne mechanizmy metodyk strukturalnych, a więc i zastosowanie pakietów Upper CASE może być problematyczne.

Zintegrowane środowiska projektowania systemów

Pakiety oferujące możliwości zarówno wysokiego, jak i niskiego poziomu określa się czasem mianem I- CASE (Integrated CASE), czyli zintegrowanych pakietów CASE. O czywiście terminologia jest rzeczą wtórną, istotna jest natomiast oferowana przez zintegrowane pakiety CASE możliwość przejścia od analizy wymagań użytkownika do działającego programu w środowisku gwarantującym zachowanie spójności projektu. Tym co decyduje o jakości tworzonego systemu jest bowiem w pierwszym rzędzie jakość pracy koncepcyjnej, a zwłaszcza identyfikacja i właściwe odwzorowanie wymagań użytkownika. Szczegółowa specyfikacja techniczna powstaje na podstawie projektu wykorzystującego efekty analizy. Zintegrowany system CASE zapewnia płynność przejścia od wymagań do działającej aplikacji. Co więcej, umożliwia analizę i wprowadzanie zmian dzięki dokumentom projektowym o wysokim poziomie. Dzięki temu dokumentacja projektowa zawsze nadąża za modyfikacjami produktu, a w gruncie rzeczy nawet je wyprzedza i determinuje. Jest to możliwość unikalna dla pakietów zintegrowanych, jako że w innych "kombinacjach" pakietów CASE wysokiego i niskiego poziomu spójność projektu i produktu nie jest narzucana przez narzędzia i zależy jedynie od dobrej woli i dyscypliny zespołu projektowego. Co za tym idzie - często bywa iluzoryczna.

Tak więc zintegrowane systemy CASE stanowią poważny krok w stronę realizacji marzenia mojego kolegi. Systemy CASE wyrosły dziś z chorób wieku dojrzewania. Pakiety takie jak: Systems Engineer for Client/Server firmy LBMS czy Foundation firmy Arthur Andersen to efektywne narzędzia oparte na elastycznych metodykach projektowania. Pozwalają na dobór sposobu realizacji systemu, konstrukcję opartą na dokumentach projektowych wysokiego poziomu i realnie wspomagają proces zarządzania projektem. Przykładem takiego wspomagania może być Process Hyperguide firmy LBMS, graficzne narzędzie łączące w sobie elektroniczny podręcznik metodyki Systems Engineering, mechanizmy do planowania projektów, opracowywania standardów i kontroli realizacji prac projektowych. Napisałem, że marzenie mojego kolegi, to dziś utopia. Jednakże jeszcze 50 lat temu nikt nie słyszał o komputerze, a dziś film "Park Jurajski" Stevena Spielberga przekonuje o fantastycznych możliwościach informatyki. Być może już wkrótce, kiedy skomputeryzowana organizacja zaplanuje zmiany mające poprawić jej skuteczność na konkurencyjnym rynku...