Wdrażanie technologii CASE (część 1)

Zainteresowanie technologią opierającą się na metodach strukturalnych i narzędziach CASE wydaje się wyraźnie wzrastać. Powyższa obserwacja - jeśli odpowiada rzeczywistości - jest chyba dobrym znakiem świadczącym o tym, że nasz przemysł informatyczny poważnie traktuje wyzwania, jakie stawia przed nim polska gospodarka drugiej połowy lat 90. Przy tej okazji warto chyba powiedzieć parę słów na temat zjawisk i problemów, które wiążą się z wdrażaniem nowoczesnych metod analizy i projektowania systemów komputerowych.

Zainteresowanie technologią opierającą się na metodach strukturalnych i narzędziach CASE wydaje się wyraźnie wzrastać. Powyższa obserwacja - jeśli odpowiada rzeczywistości - jest chyba dobrym znakiem świadczącym o tym, że nasz przemysł informatyczny poważnie traktuje wyzwania, jakie stawia przed nim polska gospodarka drugiej połowy lat 90. Przy tej okazji warto chyba powiedzieć parę słów na temat zjawisk i problemów, które wiążą się z wdrażaniem nowoczesnych metod analizy i projektowania systemów komputerowych.

Doświadczenia autorów niniejszego artykułu wskazują na to, że coraz więcej producentów oprogramowania i organizacji, dla których zinformatyzowany przepływ informacji stanowi życiodajny krwiobieg rozważa zastosowanie rozwiązań wprowadzających do projektów informatycznych dyscyplinę, standardy dokumentacji, rzetelną analizę potrzeb użytkownika i automatyzację kodowania.

Zespoły projektowe rzadko składają się z informatycznych "nowicjuszy". Zwykle mamy do czynienia ze sprawnymi, znającymi swój fach programistami, którzy napisali już niejedną aplikację. Mogłoby się więc wydawać, że dla realizacji dużego przedsięwzięcia wystarczy zebrać tych ludzi w jedną grupę, nauczyć ich posługiwania się technikami analizy i projektowania, a w krótkim czasie będziemy mieli doświadczony i sprawny zespół projektowy.

Niestety, okazuje się, że takie działanie nie daje oczekiwanych rezultatów. Praca "nie idzie", ludzie mimo odbytych szkoleń nie korzystają z technik, kwestionując przydatność i efektywność pracy podlegającej formalnym rygorom. Kilka osób - lepiej rozumiejących istotę technik strukturalnych - pracuje w izolacji, nie dzieląc się swoimi wynikami z kolegami. W efekcie, pomimo formalnego stosowania metodyki projektowania, tworzona przez nich dokumentacja "nie trzymająca" standardów okazuje się nieprzydatna, zwłaszcza że większość osób wróciła do metod pracy opartych na "rozpoznaniu walką", czyli ewolucyjnym tworzeniu aplikacji, których zakres funkcjonalny zmienia się i rozpełza, jak ameba.

Trudno się dziwić, kiedy gorycz porażki przeżywana przez inicjatorów "nowego" zamienia się w nieufność wobec okrzyczanych zalet metodycznego podejścia do projektów informatycznych.

Dlaczego tak bywa? Dlaczego mierzalna poprawa jakości i efektywności pracy informatyków nie zawsze jest osiągana?

Powodów jest zapewne wiele. Oto te, które naszym zdaniem są najważniejsze.

Skalowanie problemów

Pierwszym z nich jest przecenianie roli doświadczenia posiadanego przez członków zespołu. Jeśli doświadczenie to zdobyte zostało przy realizacji zadań typowych dla przemijającej właśnie technologii "pecetowej" lat 80., to charakteryzują je prawdopodobnie:

* praca samodzielna lub uczestnictwo w niewielkich zespołach (dwie, trzy osoby) nie posiadających formalnej struktury

* stosunkowo niewielka i dobrze określona grupa użytkowników (najczęściej ludzi o podobnej specjalności i oczekiwaniach wobec systemu)

* umiarkowane wymagania co do poufności danych i autoryzacji dostępu

* niewielkie rozproszenie terytorialne aplikacji wielodostępnych

* brak zaplanowanego budżetu i kontroli jego realizacji.

Tego typu doświadczenie nie ma, niestety, wielkiego zastosowania przy realizacji przedsięwzięć informatycznych obejmujących swoim zasięgiem duże zespoły użytkowników i twórców oprogramowania. Brak umiejętności pracy zespołowej, a zwłaszcza nieracjonalny stosunek do krytyki efektów własnej pracy, jest jedną z oważniejszych barier przy wdrożeniu technologii CASE, w naturalny sposób preferującej pracę zespołową. Krytyczna analiza dokumentacji tworzonej przez uczestników projektu jest podstawowym mechanizmem posuwającym do przodu prace projektowe. Projekt jest wspólną własnością zespołu - zarówno osób proponujących początkowe rozwiązania, jak i tych, którzy rozwiązania te uszczegółowiają i dopracowują poprzez konstruktywną krytykę. To banalne stwierdzenie pozostaje często jedynie sloganem - w praktyce próba krytycznej oceny wyników pracy członków zespołu odczytywana jest jako kwestionowanie ich zawodowych kompetencji.

Podejście hobbystyczne

Innym powodem jest niedocenienie faktu, że wdrożenie technologii CASE wymaga właściwego umiejscowienia służb informatycznych i spełnianych przez nie usług w macierzystej organizacji. Organizacja produkcji proponowana przez tę technologię przyjmuje za punkt wyjścia projektów informatycznych "biznesowy" punkt widzenia. Analiza każdego podejmowanego zadania zaczyna się od określenia wpływu jaki wywrzeć ma tworzony system na sposób funkcjonowania organizacji. Z tego też powodu, informatycy coraz częściej powinni zmuszać użytkowników do świadomego definiowania strategii organizacji, do określania aktualnych poziomów wydajności w różnych obszarach jej działania i precyzyjnego formułowania wymagań w kontekście konkretnych, wymiernych korzyści odnoszonych do strategii organizacji. Oczywiście tego rodzaju naciski zawsze spotkają się z nieufnością i mniej lub bardziej świadomym oporem indagowanych. Taka sytuacja - skutecznie blokująca realny postęp we wdrażaniu nowych metod pracy - trwać będzie dopóty, dopóki organizacja oficjalnie nie uzna nowej roli jaką informatyka zaczyna grać w jej życiu. Prawdziwie skuteczny program wdrożenia nowej technologii powinien zostać poprzedzony opracowaniem strategii działania służb informatycznych. Definicja tej strategii określi w szczególności docelową wizję organizacji zespołu informatycznego oraz plan stopniowego dochodzenia do tej wizji, nie okupionego wynikającym z opanowywania nowej technologii drastycznym spadkiem wydajności. Brak takiego planu grozi tym, że nowa technologia pozostanie w najlepszym wypadku "własnością" grupy hobbystów i nie wpłynie w znaczący sposób na poprawę jakości i wydajności funkcjonowania służb informatycznych.

Marketing projektu

Kolejny problem, to pewien schemat dotyczący relacji informatyk - użytkownik, funkcjonujący po obu stronach "barykady". Informatyk o użytkowniku: "nie wie sam czego chce, nie docenia elegancji i ogólności rozwiązań, zawraca głowę zbędnymi szczegółami, nie umie się dostosować do świetnych rozwiązań". Użytkownik o informatyku: "nie rozumie skomplikowanej rzeczywistości, oczekuje, że ktoś za niego wymyśli rozwiązanie, lubi zabawę w komputery, a tu trzeba pracować".

Taka postawa skutecznie uniemożliwia realizację jednego z najcenniejszych elementów dzisiejszych metodyk projektowania - wspólnego opracowania przez użytkowników i informatyków specyfikacji wymagań systemu prezentującej (wspomnianą już wyżej) "biznesową" perspektywę wymagań, jakie spełniać ma tworzony system informatyczny. Tylko taka forma rozpoczęcia i realizacji projektu zapewnia, że rozwiązania zastosowane przez informatyków będą dotyczyć istotnych potrzeb użytkownika. Przełamanie niechętnej do współpracy postawy obu stron nie zawsze jest łatwe. Wyeliminowanie stereotypów w zespole projektowym jest możliwe, jeśli jego członkowie dostrzegą szansę podniesienia własnych kwalifikacji i zdobycia specjalności analityka czy projektanta, która zapewne w ciągu najbliższych kilku lat wyznaczy nową, elitarną "kastę" w branży informatycznej. Do osiągnięcia pełnej współpracy potrzeba jeszcze przekonania użytkowników o celowości zastosowania nowych metod pracy i wynikających z nich korzyściach. Aby tego dokonać należy zadbać o dwie rzeczy: Po pierwsze, trzeba zdobyć dla nowych rozwiązań poparcie osoby należącej do "najwyższych gremiów" sponsora. Tylko takie poparcie uświadomi wszystkim strategiczną wagę, jaką kierownictwo przywiązuje do zastosowanych rozwiązań. Po drugie - należy systematycznie prowadzić promocję projektu wśród użytkowników. Taka promocja polega na atrakcyjnym i fachowym prezentowaniu metod oraz wyników pracy, z wyeksponowaniem faktu, że wszelkie sukcesy są wspólną "własnością" użytkowników i realizatorów projektu. Niezmiernie istotna jest też jakość dokumentacji projektowej. Musi ona być dobrze przygotowana zarówno pod względem merytorycznym jak i edytorskim. Należy świadomie kształtować jej zawartość w zależność od odbiorcy, jego stopnia znajomości przedmiotu, terminologii, ilości czasu

jaki może poświęcić na jej przestudiowanie oraz celu jaki dokument ma spełnić. Jeśli dokument ma być podstawą do podjęcia przez kierownictwo decyzji co do wyboru wariantów realizacji projektu, musimy na niewielu stronach przedstawić podstawowe różnice, wady i korzyści proponowanych rozwiązań. Znakomicie mogą temu służyć diagramy opisujące zakres wariantów systemu, ich podstawowe komponenty oraz zestawienie ilustrujące zakres istotnych problemów i wymagań rozwiązywanych przez każdy z wariantów, wraz z szacowaniem kosztów i korzyści. Z drugiej strony, dokumentacja stanowiąca produkt wejściowy do etapu projektowania systemu, to zwykle bardzo szczegółowy dokument, wyczerpująco przedstawiający wyniki przeprowadzonej analizy.

Kupą mości panowie, czyli dramat spadku wydajności

Od zaprzyjaźnionej firmy produkującej systemy informatyczne usłyszeliśmy kiedyś interesującą historię. Otóż, analizując sprzedaż produkowanych przez tę firmę systemów księgowych, stwierdzono, że odsetek bankructw w zbiorze nabywców jest wyższy niż wskazywałaby na to statystyka. Pytanie jakie natychmiast sobie zadano nie było przyjemne dla twórców systemu: Czy system jest tak nie przemyślany, że efektem wdrożenia jest upadłość wdrażającej go organizacji? Twórcy systemu, nie odbiegającego standardem od innych tego typu rozwiązań dostępnych na rynku, sformułowali inną hipotezę -naszym zdaniem słuszną i bardzo znamienną. Otóż czynnikiem sprawiającym ową fatalną korelację jest nie jakość oprogramowania, ale MOTYWACJA i OCZEKIWANIA użytkownika. Firma, która przestaje sobie radzić z zarządzaniem własnymi finansami, decyduje się na zakup systemu informatycznego, oczekując, że nabywa panaceum na bałagan organizacyjny. Być może zamiast kupować system księgowy, powinna zacząć od zatrudnienia kompetentnego księgowego, przeanalizowania przepływu gotówki, sensowności inwestycji, struktury zadłużenia itd. Tego wszystkiego można dokonać i bez systemu księgowego. Próba wdrożenia systemu - z natury wymagającego precyzyjnej informacji i dyscypliny pracy -zamiast poprawić sytuację mogła ją jeszcze skomplikować, jako że opanowanie obsługi skomplikowanego programu osłabiło i tak już marną wydajność istniejącego systemu finansowego firmy.

Wydaje nam się, że przenosząc morał wynikający z powyższej historii na grunt wdrożeń technologii CASE można powiedzieć: jeśli masz niedostatecznie wyszkolony zespół, a chcesz szybko podnieść jego wydajność pracy, szybciej stworzyć system informatyczny, który "spalił" już kilka terminów, błyskawicznie zrealizować zintegrowany system informatyczny dla organizacji - zapomnij o systemach CASE! Czy oznacza to, że technologia CASE jest nieprzydatna? Absolutnie nie! Jesteśmy przekonani, że jest to technologia niezmiernie pożyteczna, a nawet niezbędna w realizacji poważnych przedsięwzięć informatycznych. Słowo, które budzi nasze wątpliwości brzmi: szybko. Owszem, CASE oznacza - w pewnej perspektywie - znaczący wzrost wydajności zespołów, poprawę jakości tworzonych systemów oraz lepszą skuteczność planowania i zarządzania projektami. Należy sobie jednak zdawać sprawę z tego, że wdrożenie technologii oznacza zmiany w organizacji pracy i konieczność przyswojenia sobie wielu nowych elementów wiedzy informatycznej. Tylko sensowna strategia wdrożenia może ograniczyć negatywne skutki objawiające się spadkiem wydajności pracy zespołów w okresie "zmian strukturalnych".

Dla zilustrowania skali problemu, pokazujemy wykres pochodzący z badań GARTNER GROUP, porównujący zmiany wydajności zespołów dla różnych odmian technologii CASE. Wynika z niego, że najbardziej atrakcyjna z punktu widzenia długofalowych korzyści mutacja - zintegrowane środowisko CASE (I-CASE) - powoduje najbardziej drastyczną "zapaść" wydajności w początkowym okresie. Nie jest to zapewne dobra nowina dla wielu organizacji przymierzających się do zmiany organizacji pracy zespołów informatycznych. Żeby jednak pocieszyć tych, którzy uznają, że rok pracy przy obniżonej wydajności to zbyt wysoka cena za potencjalne korzyści (mamy w końcu bezlitosną gospodarkę rynkową) wypada powiedzieć, że istnieją sposoby pozwalające ograniczyć zakres tego niebezpiecznego zjawiska. Najlepiej ugruntowanym jest Process Management - metodyka planowania rozwoju procesu produkcyjnego, oparta o model dojrzałości procesów (Process Capability Maturity Model) opracowany w Carnegie-Mellon University. Na temat Process Management napiszemy szerzej w jednym z kolejnych artykułów z tej serii.

Oczywiście nie bez szans są również "zdroworozsądkowe" metody radzenia sobie z nawałem zmian przynoszonych przez nowe metody pracy. Po pierwsze rezygnacja z monumentalnych kursów metodyki i aplikowanie wiedzy punktowo, w miarę potrzeb pojawiających się w realizowanym projekcie pilotażowym. Po drugie nie prowadzenie szkoleń "szeroką ławą", a zamiast tego wyodrębnienie zespołu wiodącego, który będzie stanowił zalążek własnej grupy ekspertów, pozwalających na uniezależnienie od zewnętrznych doradców.

Powyższe podejście wymaga jednak w początkowych etapach realizacji projektów pilotowych udziału co najmniej jednej osoby, która "wie o co chodzi", potrafi zaplanować przebieg pilotażu i przewidzieć kiedy, jakie grupy uczestników projektu będą wymagały przeszkolenia. Możliwe jest wykorzystanie do takiej asysty zewnętrznych konsultantów lub zatrudnienie osoby o odpowiednich kwalifikacjach. Przy naprawdę poważnych przedsięwzięciach może się nawet opłacać zatrudnienie bardzo wysokiej klasy specjalisty za (stosunkowo) duże pieniądze. Jeżeli taki ruch pozwoli nam wdrożyć nową technologię produkcji systemów bez zapaści wydajności - w sumie całe przedsięwzięcie może okazać się opłacalne.

Autorzy są pracownikami InfoViDE - przedstawiciela Learmonth & Burchett Management Systems (LBMS), brytyjskiego twórcy metodyk i narzędzi CASE. InfoViDE zajmuje się wdrażaniem systemów CASE, nauczaniem technik strukturalnych i konsultingiem informatycznym.

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

TOP 200