Mam inne zdanie

W CW nr 31 (29 sierpnia) można przeczytać artykuł redaktora Mariana Łakomego pod dramatycznym tytułem "Czy narzędzia CASE mają przyszłość?" Zajmuję się narzędziami CASE na co dzień, toteż bardzo zdziwiło mnie postawienie tego pytania, a jeszcze bardziej zaskoczony jestem logiką wywodu Pana Redaktora, z którą niezupełnie się zgadzam. Może dodanie do artykułu słowa "tradycyjne" przed "narzędzia" nieco lepiej by mnie do niego usposobiło. Spieszę zatem z komentarzem, który, mam nadzieję, przedstawi tę problematykę w sposób bardziej obiektywny.

W CW nr 31 (29 sierpnia) można przeczytać artykuł redaktora Mariana Łakomego pod dramatycznym tytułem "Czy narzędzia CASE mają przyszłość?" Zajmuję się narzędziami CASE na co dzień, toteż bardzo zdziwiło mnie postawienie tego pytania, a jeszcze bardziej zaskoczony jestem logiką wywodu Pana Redaktora, z którą niezupełnie się zgadzam. Może dodanie do artykułu słowa "tradycyjne" przed "narzędzia" nieco lepiej by mnie do niego usposobiło. Spieszę zatem z komentarzem, który, mam nadzieję, przedstawi tę problematykę w sposób bardziej obiektywny.

Po pierwsze metodyka

Odróżniajmy narzędzia CASE od metodyki. Nie ma czegoś takiego jak "metodologia CASE". Istnieje bardzo wiele metodyk pracy nad systemami informatycznymi. Większość z nich może być wspomagana programami CASE. Niemniej jednak fakt, że jakaś metodyka może być wspomagana narzędziowo, nie decyduje o tym, że staje się ona jakąś "metodyką CASE".

Skoro zatem nie ma "metodyki CASE", to tym bardziej nie można o niej napisać, że charakterystyczne dla niej jest podejście top-down. Isnieją metody realizujące podejście top-down oraz bottom-up. Istnieją także metody realizujące podejście wyważone, łączące w sobie zalety obu poprzednich podejść i nie mające ich wad.

Pozwolę sobie zatem NIE zgodzić się z redaktorem Marianem Łakomym piszącym, że "W opracowywaniu aplikacji dla przedsiębiorstw dominują (...) dwie metody pracy. Jedna jest oparta na systematycznym wykorzystywaniu metodologii CASE (...). Jest to więc typowa metoda top-down".

Żeby podeprzeć się konkretami podaję przykłady jedynie czterch, spośród wielu innych cykli projektowych "metodyki CASE" firmy LBMS.

- Classic

- Incremental

- Rapid Delivery

- GUI & Client/Server.

Wśród wymienionych tylko cykl Classic ma "szkolną", wodospadową strukturę top-down. Wszystkie inne są schematami projektów o strukturze iteracyjnej, a cykle Rapid Delivery i GUI & C/S są w dużym stopniu oparte na bliskiej współpracy z użytkownikiem i prototypowaniu.

O co więc chodzi? Różnice w podejściach do realizacji dużych przedsięwzięć informatycznych biorą się stąd, że każdy problem rozwiązywany metodami informatyki jest inny.

Mamy więc projekty informatyczne o "typowym przebiegu" (Classic), które tym się charakteryzują, że praktycznie nie występują w przyrodzie. Dla problemów standardowych (np. "kolejny program f-k"), realizowanych przez doświadczony zespół, przyjmuje się metodę przyspieszoną, stosowaną zazwyczaj do projektów o małym ryzyku niepowodzenia (Express). Jeśli mamy bardzo doświadczoną brygadę SWAT (nie Special Weapons Advanced Tactics Specialists With Advanced Tools) i rozpoznajemy "bojem" nowy, nie zbadany obszar działalności firmy, najlepiej jest stosować iteracyjny cykl Rapid Delivery stosujący techniki i narzędzia Rapid Application Development. Wreszcie, kiedy tworzymy aplikację graficzną w środowisku Client/Server, najlepiej poprowadzić projekt opierając się na prototypowaniu, korzystając z iterakcyjnego wzorca GUI & C/S.

Wszystkie te cykle projektowe i jeszcze wiele innych, mogą być realizowane przy użyciu narzędzi CASE.

Jak zatem Pan Redaktor mógł napisać, że "W metodzie CASE zasadniczy kontakt z użytkownikiem ogranicza się do zadania mu pewnej liczby pytań?" A następnie podać przykład błędnie przeprowadzonego projektu i podsumować "Często tak utworzone modele na tyle odbiegają od faktycznego sposobu działania firmy, że zrealizowane na ich podstawie programy są odrzucane przez użytkowników" sugerując, że przyczyną tego jest jakaś zła "metoda CASE".

Po pierwsze nie ma "metody CASE". Po drugie, faktycznie w każdym projekcie informatycznym "zasadniczy kontakt z użytkownikiem ogranicza się do zadania mu pewnej liczby pytań". Jeżeli jednak pytania są zadawane jedynie na początku współpracy i na tym się kończy, to rzeczywiście projekt musi zakończyć się katastrofą. Oczywiście było bardzo wiele nieumiejętnie przeprowadzonych przedsięwzięć informatycznych stosujących narzędzia CASE, ale nie oznacza to, że powodem ich niepowodzenia była jakaś "metoda CASE" a nie zwyczajna ludzka niekompetencja.

Użytkownik przede wszystkim

Przypuśćmy, że opracowujemy system informatyczny dla dużego banku i myślimy jedynie o realizacji życzeń przyszłych użytkowników tego systemu. Ale kto właściwie będzie użytkownikiem systemu prezes banku czy "panienka z okienka"? Oczywiście oboje, chociaż prezes żadanego programu nigdy na oczy nie zobaczy.

Czy wymagania stawiane przez operatorkę komputera nie są sprzeczne z wymaganiami prezesa? Być może ta pierwsza chciałaby wpisywać "do komputera" bardzo mało danych o klientach, ograniczając w ten sposób ilość wykonywanej przez siebie pracy. Prezes chciałby mieć tych danych "w komputerze" jak najwięcej, żeby pozostali pracownicy banku mogli poddać je analizie i wyciągnąć wnioski o wielkości rynku, który bank może jeszcze zająć.

Zatem jedno chce mieć więcej informacji a drugie mniej pracy. Tak się jednak składa, że zaspokojenie ambicji prezesa wymaga znacznego wysiłku ze strony "panienki" i vice versa - mniej pracy "panienki" to mniej informacji dla prezesa.

Czy prezes będzie chciał zapłacić za system, który nie realizuje jego strategicznych potrzeb, za to jest efektowny, łatwy w obsłudze i bezstresowy dla operatorów?

Czy RAD jest odpowiedzią na wszystkie problemy?

Mam nadzieję, że przykład podany w poprzednim punkcie przekonuje, że prototypowanie nie jest techniką, która sama z siebie gwarantuje sukces przedsięwzięcia informatycznego, ponieważ wiąże się on z intensywnym uczestnictwem operatorów programów, a nie jego rzeczywistych użytkowników.

Kolejne zgrzyty pojawiają się, kiedy pomyślimy o dużym projekcie informatycznym. Przypuśćmy, że projekt taki postanowiliśmy wykonać technikami RAD (Rapiel Application Developm), czyli bottom-up. Czy jest to możliwe? Prawdopodobnie nie, ponieważ duży, intensywnie prototypujący zespół programistów szybko zamieni się w zespół chaotycznie kodujących i testujących programy indywiduów, o ile działalność ta nie będzie zorganizowana przez sensownie dobraną metodykę.

Jaki z tego wniosek? Oczywiście taki, że owszem RAD jest bardzo przydatną techniką pracy w pewnych fazach wykonania projektu informatycznego, ale:

* nie zastąpi sensownego zadawania pytań

* nie zastąpi umiejętnego opracowywania modeli działania firmy

* nie zastąpi planowania, podziału i właściwej organizacji pracy.

Natomiast bywa niezastąpiony jako:

* sposób opracowywania zasad komunikacji z użytkownikiem

* sposób zbierania niektórych wymagań funkcjonalnych

* sposób weryfikacji sensowności różnych rozwiązań informatycznych

* technika stosowania do systemów obiektowych i architektury GUI oraz klient/serwer.

Wracając na koniec do przewrotnego pytania postawionego przez redaktora Łakomego - oczywiście, że systemy CASE mają przyszłość. Ich byt nie jest jednak samoistny, toteż nie mogą być przyczyną problemów lub też panaceum na bolączki inżynierii oprogramowania. Systemy CASE opierają się na metodach pracy i będą ewoluowały wraz z nimi. Nigdy ich jednak nie zastąpią.

Od autora: Cieszę się z tego komentarza do mojego artykułu, który pisałem z zamiarem wywołania dyskusji na temat metod opracowywania aplikacji. Jednakże materiał p. Jacka Królika potwierdza moją tezę, że współczesne narzędzia CASE i metody pracy nad systemami informatycznymi są przystosowane raczej do idei wymyślonych w laboratoriach naukowców niż do potrzeb rzeczywistych użytkowników. Co zaś do prezesa instytucji używającej CASE, to chyba powinien płacić za system, który przede wszystkim jest bezstresowy dla operatorów i łatwy w obsłudze, a także realizuje wszystkie założone cele. "Panienka z okienka" jest równie ważnym użytkownikiem systemu, jak pan prezes.

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

TOP 200