Kuchnia architektury klient/serwer RDE

Architektura klient/serwer zaczyna naprawdę zadomawiać się na polskim rynku informatycznym! Do tego wniosku doszliśmy w InfoViDE przyglądając się temu jak kształtuje się popyt na realizowane przez naszą firmę szkolenia.

Architektura klient/serwer zaczyna naprawdę zadomawiać się na polskim rynku informatycznym! Do tego wniosku doszliśmy w InfoViDE przyglądając się temu jak kształtuje się popyt na realizowane przez naszą firmę szkolenia.

Kursy dotyczące projektowania systemów klient/serwer i aplikacji wykorzystujących graficzne techniki interakcji przestały być obiektem przypadkowego zainteresowania pionierów i hobbystów. Z pozycji kursów elitarnych przeszły do grupy szkoleń regularnie zamawianych przez organizacje i gęsto obsadzonych w ramach programu kursów otwartych. Również zdecydowana większość projektów jakie z perspektywy firmy konsultingowej mieliśmy okazję oglądać i współtworzyć w ciągu ostatniego roku, to przedsięwzięcia w których architektura klient/serwer stanowiła istotny element realizowanego rozwiązania biznesowego.

Fascynacja dostępnymi dziś możliwościami wizualnego programowania i wygodą konstruowania aplikacji nie powinna jednak usuwać z pola widzenia rozważnego kierownika zespołu problemów i wyzwań, stojących przed każdym poważniejszym projektem klient/serwer. Bezpieczeństwo projektu - pewność, że dotrze on, w ramach wyznaczonych harmonogramem i budżetem, do końcowej przystani spełnionych oczekiwań użytkownika - do pewnego tylko stopnia zależy od wygody pracy i wydajności konstruktorów. Bezpieczeństwo projektu wyznaczone jest przez solidną technologię implementacji a przede wszystkim, przez skuteczność zarządzania pracą zespołu projektowego realizującego rozproszony system biznesowy.

Projekty klient/serwer - wyzwania i strategie

Los projektów informatycznych, a zwłaszcza los wdrożeń systemów informacyjnych dziś bardziej niż kiedykolwiek leży w rękach użytkowników. W 1993 roku znacząca część wydatków na informatyzację dużych organizacji w Stanach Zjednoczonych (ponad połowa) nie przechodziła przez departamenty informatyki. Z drugiej strony średni czas funkcjonowania dyrektora departamentu informatyki to dziś 2-3 lata. Mniej więcej tyle czasu wystarcza aby spróbować przeprowadzić jakiś bardziej ambitny projekt informatyczny. Co te fakty oznaczają? Można je interpretować różnie, sądzę jednak, że następująca diagnoza nie będzie daleka od prawdy; W miarę, jak departamenty informatyki próbują zrealizować kolejne kompleksowe, zintegrowane systemy informatyczne, niecierpliwi użytkownicy informatyzują się sami. Mając pod ręką coraz lepsze i coraz sprawniej współdziałające oprogramowanie biurowe, pocztę elektroniczną, proste, bezobsługowe serwery danych i wsparcie lokalnych informatyków robią to w dodatku coraz skuteczniej.

Perspektywa departamentu (ośrodka, wydziału) informatyki jest perspektywą globalną, związaną z troską o standaryzację, troską o optymalne inwestycje, troską o spójną informatyzację całej organizacji. Tutaj decyzje podejmowane są dostojnie, wymagają przemyślenia, analizy, rozważenia opcji zakupu gotowych systemów. Taki stan rzeczy nie znajduje jednak zrozumienia u użytkowników, którzy uzbrojeni w proste w użyciu narzędzia potrafią sobie sami zmajstrować "cuda, cudeńka". Cóż z tego, że nie są to rozwiązania bezpieczne, wydajne, dające wsparcie na poziomie strategii i zarządzania całą organizacją. Użytkownik końcowy często nie jest zainteresowany strategiczną rolą systemu informatycznego, jeśli nie otrzyma konkretnego, doraźnego wsparcia w realizowanych na co dzień zadaniach.

Taka sytuacja może być postrzegana jako przekleństwo dzisiejszych projektów informatycznych. Z drugiej jednak strony mamy dzisiaj wreszcie sytuację, kiedy komputer staje się naturalnym i pożądanym narzędziem codziennej pracy większości pracowników organizacji. Taki stan rzeczy daje unikalną możliwość stworzenia systemów informatycznych w naturalny sposób wkomponowanych w proces biznesowy. Zamiast dublować "zwykły" obieg informacji w systemie informatycznym wymagającym obsługi przez wyspecjalizowanych użytkowników możemy przechwytywać informację biznesową bezpośrednio w miejscu jej powstawania i udostępniać ją natychmiast tam gdzie jest potrzebna do podejmowania decyzji, w formie najlepiej dostosowanej do charakteru procesu w jakim jest stosowana. Zamiast narzekać na przemądrzałych użytkowników wykorzystajmy ich rosnące umiejętności dając im aplikacje dobrze wkomponowane w środowisko aplikacji biurowych i możliwość wykorzystania tych aplikacji jako budulca lokalnych, elastycznych i dobrze dopasowanych do zadań użytkowników rozwiązań.

Dla pomyślnego wykorzystania tej szansy potrzeba abyśmy mogli spełniać oczekiwania użytkowników co do szybkości tworzenia konkretnych, użytecznych rozwiązań przy jednoczesnym zachowaniu spójności, wydajności i bezpieczeństwa współdzielonego repozytorium danych i reguł biznesowych. Te postulaty są dzisiaj najskuteczniej realizowane przez zastosowanie idei przyspieszonego rozwoju aplikacji (Rapid Delivery Environment) wykorzystującej iteracyjne (spiralne) cykle projektowe, techniki wydajnej, twórczej współpracy z użytkownikami (Joint Application Development) i specyficzne środowisko narzędziowe. A zatem kilka nieco bardziej szczegółowych słów na temat każdego z powyższych zagadnień.

RDE, czyli idea stara jak OS 360

Architektura klient/serwer nie stanowi - koncepcyjnie - żadnego właściwie nowatorstwa. To realia rynku i dynamika rozwoju dzisiejszej przedsiębiorczości sprawiły, że stała się pożądanym i skutecznym rozwiązaniem architektonicznym systemów biznesowych. Właściwie do pewnego stopnia podobnie rzecz ma się z inną "nowością" - koncepcją przyspieszonego rozwoju aplikacji RDE - Rapid Delivery Environment. W legendarnym zbiorze esejów na temat inżynierii oprogramowania "The Mythical Man-Month" Fredericka Brooksa, esejów napisanych na bazie doświadczeń zebranych przez autora w czasie kierowania projektem OS 360 w firmie IBM można znaleźć pierwsze konkretne propozycje podniesienia wydajności realizacji dużego projektu poprzez podział zespołu na niewielkie, dobrze zorganizowane, wysoko wydajne zespoły.

Brooks zauważył fakt o którym warto pamiętać również dziś: o wydajności w realizacji systemów nie decydują jedynie kwalifikacje ani liczba członków zespołów projektowych. Przytaczane przez Brooksa dane (esej The Surgical Team z wyżej wymienionego zbioru) dowodzą, że dla dużego projektu nie ma jednoznacznej korelacji pomiędzy indywidualnymi umiejętnościami członków zespołu, wielkością zespołu a jego wydajnością. Jedynie właściwa organizacja pracy pozwala sensownie wykorzystać potencjał zespołu projektowego - zarówno intelektualny jak i czysto liczbowy.

Sugerowana przez Brooksa konstrukcja zespołu projektowego, opiera się na zapożyczonej od Harlana Millsa idei "zespołu chirurgicznego". Informatyczny "zespół chirurgiczny", to analogia do skoncentrowanej pracy niedużego zespołu specjalistów, których zadaniem jest wspieranie na różne sposoby pracy głównego aktora-chirurga odpowiedzialnego za plan przebieg i powodzenie operacji. Na tym zresztą analogia się kończy. Role w "zespole programisty wiodącego", bo tak był ten model organizacji nazywany w Polsce, wykraczają poza tradycyjnie pojmowany zespół lekarzy. Mamy tu więc "drugiego pilota" (copilot), "ślusarza" (toolsmith), "bibliotekarza" (librarian), "językoznawcę" (language lawyer) i innych.

Podział ról wyznaczony był między innymi przez fakt realizacji specyficznych projektów w konkretnym czasie, w konkretnym środowisku implementacji - chodziło wszak o realizację oprogramowania systemowego w latach 70. na skomplikowanych architektonicznie komputerach mainframe firmy IBM. Praca była w dużej mierze wsadowa, czas procesora drogi, praca wymagała archiwizowania ogromnej ilości wydruków z testami i listingami programów. Sądzę jednak, że podstawowe idee jakie stały u podstaw zespołu programisty wiodącego są aktualne również dziś. Są nimi jedność koncepcyjna systemu, jasna struktura odpowiedzialności i separacja funkcji w zespole oraz postulat bieżącego specyfikowania i dokumentowania wytwarzanych produktów. Podstawowa praca wykonywana w zespole to projektowanie i weryfikowanie założeń projektowych. Przełożenie koncepcji na program było działalnością rutynową.

Ważnym elementem środowiska RDE są spiralne, iteracyjne cykle projektowe. W cyklu spiralnym docelowy produkt powstaje w kilku iteracjach, z których każda daje produkt bliższy produktowi wymaganemu. Oczywiście iteracyjna realizacja projektu wymaga kontroli, zapewniającej "zbieżność" - w sensownym czasie - całego procesu wytwórczego do wymaganego produktu. Strategia zarządzania projektem spiralnym wypracowana została w latach 70. przez Barry Boehma, kierującego projektami realizowanymi przez jednego z dostawców Departamantu Obrony USA, firmę TRW. Strategia ta określana jest często mianem "kontroli ryzyka" (risk management) jako że podstawą do planowania kolejnych iteracji jest właśnie analiza i identyfikacja ryzykownych aspektów projektu. W dużym skrócie można tę strategię opisać w postaci następujących powtarzanych cyklicznie, czterech kroków:

- Wybierz najbardziej ryzykowny (technicznie, biznesowo) fragment aplikacji.

- Zaprojektuj sposób rozwiązania problemów zidentyfikowanych w wybranym fragmencie aplikacji (prototypowanie, symulacja, marketing projektu).

- Wykonaj zaplanowane działania.

- Oceń wyniki działań pod kątem dalszego przebiegu projektu.

Zgodnie z pomysłem Boehma, każda iteracja konstruktywnie weryfikuje pewną hipotezę projektową (koncepcję rozwiązania problemów projektu). W ten sposób ryzyko niepowodzenia realizacji całego przedsięwzięcia maleje wraz z upływem czasu. To oraz fakt, że zespół projektowy zdobywa z każdą iteracją coraz więcej doświadczenia powoduje stopniowy wzrost wydajności - kolejne iteracje mogą obejmować coraz większe obszary systemu, przy zachowanych ramach czasowych. W ten sposób, cały proces jest zbieżny.

Koncepcja RDE, zdefiniowana w bibliotece procesów (Process Library) dostępnej w ramach środowiska zarządzania procesami Process Engineer firmy LBMS, jest spadkobiercą obu przedstawionych wcześniej idei. Została zaprojektowana z myślą o kilkuosobowych zespołach projektowych (do 10 osób, nie licząc użytkowników), pracujących iteracyjnie. Podejście iteracyjne wykorzystywane jest zarówno w samym cyklu projektowym, jak i w niektórych jego fragmentach (iteracyjne projektowanie, prototypowanie i konstruowanie aplikacji). Wykorzystuje ona analizę ryzyka, strukturalną specyfikację zakresu, obiektowe modele aplikacji i warstwową strukturę systemu do efektywnego planowania i kontroli przebiegu projektu. Opiera się też na nowoczesnym "parku maszynowym" ułatwiającym konstruowanie aplikacji, dokumentowanie jej komponentów, zarządzanie obiektami i kontrolę zmian wprowadzanych w trakcie rozwoju systemu. Ten park maszynowy ma dziś swoją wyraźną specyfikę, określaną czasem jako - CASE dla architektury klient/serwer. Pakiet C/S CASE Systems Engineer, wraz z modułem zarządzania obiektami (Object Manager) i zintegrowanym środowiskiem konstrukcyjnym (PowerBuilder lub Visual Basic) pozwala realizować rozwój systemu szybko, ale jednocześnie z zachowaniem kontroli poprzez efektywne planowanie i kontrolę przebiegu projektu oraz pragmatyczne wykorzystanie specyfikacji.

Taka organizacja pracy pozwala na sprawną i efektywną pracę niedużego zespołu. Istnieje oczywiście wiele zagadnień, których kilkuosobowy zespół nie jest w stanie zrealizować w sensownym czasie, choćby był zespołem wiele razy wydajniejszym od przeciętnego. Nie oznacza to jednak, że RDE nie nadaje się do zagadnień kompleksowej informatyzacji procesu biznesowego. Idea przyrostowego tworzenia systemu i iteracyjnego podejścia do rozwoju jego aplikacji jest tu jak najbardziej na miejscu. Koordynacja rozwoju aplikacji - realizowanych w podobny sposób jak w cyklu RDE, stabilizowana jest tu jednak dwoma wątkami prac analityczno-projektowych - przeprojektowaniem procesu biznesowego, i zdefiniowaniem architektury technicznej. W pierwszym z nich powstaje wizja usprawnienia istniejącej organizacji pracy w ramach zakresu wyznaczonego przez cele i wymagania systemu. Nie chodzi tu o typową dla podejścia strukturalnego bardzo dogłębną analizę, jako że model funkcjonalny i informacyjny uszczegółowiany jest w trakcie modelowania zadań i obiektów objętych kolejnymi iteracjami. Wątek drugi, stwarza fundament technologiczny - architektura docelowa, środowisko sieciowe, standardy graficznej interakcji - stabilizujący iteracyjny rozwój aplikacji. Jest to kolejna istotna różnica w stosunku do klasycznego podejścia "kaskadowego", w którym aż do końca etapu projektowania logicznego w zasadzie abstrahuje się od środowiska implementacji. Takie traktowanie technologii byłoby ogromnie ryzykowne w projektach klient/serwer, w których z jednej strony istnieje ogromna rozmaitość możliwych do zastosowania rozwiązań i wariantów, z drugiej zaś każdy konkretny zestaw komponentów architektury charakteryzuje się innymi - niemożliwymi do przewidzenia a priori - cechami (stabilnością, wydajnością, elastycznością, łatwością skalowania itp.)

Opisany powyżej proces wytwórczy, wdrożony z powodzeniem w wielu organizacjach zdefiniowany jest również w bibliotece procesów pakietu Process Engineer, i to w kilku wariantach - podstawowym (cykl Client/Server), obiektowym (cykl Client/Server with Objects) i dostosowanym do środowiska konstrukcyjnego PowerBuilder firmy Powersoft (cykl PowerProcess).

Autor jest pracownikiem firmy InfoViDE - przedstawiciela Learmonth & Burchett Management Systems (LBMS), wiodącego twórcy metodyk i narzędzi CASE dla architektury klient/serwer. InfoViDE zajmuje się wdrażaniem systemów CASE, nauczaniem metod analizy i projektowania systemów (regularne szkolenia otwarte, obejmujące 22 rodzaje kursów odbywają się od września 1994 roku) i konsultingiem informatycznym ukierunkowanym na wdrażanie nowoczesnych technologii produkcji systemów informatycznych (zarządzanie projektami, prace analityczne i projektowe, audyt, wdrażanie architektury trójwarstwowej klient/serwer).

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

TOP 200