Dyskusja panelowa na temat:

Dyskusja panelowa na temat:

Narzędzia CASE: nadzieje i rzeczywistość

przeprowadzona na III Konferencji PLOUG w Zakopanem (23 października 1997 r.)

W dyskusji panelowej uczestniczyli pp.:
Gizela Skarżyńska (Oracle Polska),
Tomasz Traczyk (Politechnika Warszawska),
Maciej Matysiak (Politechnika Poznańska),
Krzysztof Leśny (Maxsoft),
oraz prowadzący dyskusję Tadeusz Morzy (Politechnika Poznańska).

Rozpoczynając dyskusję T. Morzy odwołał się do dyskusji panelowej, przeprowadzonej na II Jesiennej Szkole PLOUG w Zakopanem, poświęconej produkcji oprogramowania systemów baz danych. Ubiegłoroczna dyskusja skoncentrowała się głównie na zagadnieniach związanych z zarządzaniem projektami informatycznymi i próbami znalezienia odpowiedzi na pytanie, dlaczego tak wiele projektów informatycznych kończy się w Polsce niepowodzeniem? Zabrakło wówczas czasu na dyskusję o narzędziach wspomagających produkcję oprogramowania. Dzisiejsza dyskusja jest w jakimś stopniu kontynuacją ubiegłorocznej dyskusji panelowej.
Prowadzący dyskusję T. Morzy zaproponował, aby jej uczestnicy skoncentrowali się na dwóch problemach związanych z narzędziami CASE:

(1) narzędzia CASE jako oprogramowanie narzędziowe służące do wspomagania produkcji oprogramowania aplikacyjnego
i (2) narzędzia CASE jako element zarządzania projektem informatycznym.

Rozpoczynając dyskusję nad pierwszym z wymienionych problemów,
prowadzący zaproponował, aby jej uczestnicy spróbowali odpowiedzieć na następujące pytania:

  1. Jakie nadzieje wiązano z narzędziami CASE i na ile te oczekiwania sprawdziły się w praktyce?
  2. Jaki jest aktualny stan w zakresie narzędzi CASE i czego brakuje tym narzędziom z punktu widzenia projektantów i programistów aplikacji?
  3. Na ile korzystanie z narzędzi CASE stanowi dzisiaj w naszym kraju rutynową działalność w zakresie projektowania systemów informatycznych?


  Gizela Skarżyńska (Oracle Polska):

Uważam, że narzędzia CASE są dzisiaj niezbędne. Chociaż sądzę również, że nie wszystko nadaje się do wszystkiego. Designer 2000 jest bardzo dobrym narzędziem CASE, chociaż są takie sytuacje w projekcie, kiedy łatwiej jest zrobić coś ręcznie. Trzeba powiedzieć, że aby wykorzystać to narzędzie efektywnie, należy je dokładnie poznać. Główny problem to stosunek użytkowników do tego narzędzia, którzy rozumują tak: to jest proste, przejrzę parę ekranów a dalej to już samo poleci. To prawda, ekrany nie są skomplikowane, ale rzeczywisty problem, to to co użytkownik wpisze do tych ekranów, jak ułoży te klocki informacyjne. Jeżeli ułoży te klocki źle, np. źle zdefiniuje model danych, to uzyska nieciekawy efekt końcowy. Uważam, że użytkownicy „średnio” znają to narzędzie i w tym upatruję dzisiaj podstawowy problem. Jeżeli chodzi o oczekiwania jakie wiązano z narzędziami CASE, to rozczarowani są ci co oczekiwali, że za jednym naciśnięciem guzika uzyskają całą aplikację, oraz ci, którzy mając dobrego programistę, dysponującego własną biblioteką procedur PL/SQL-owych i wypracowaną metodykę produkcji aplikacji, stwierdzają, że produkuje on aplikacje znacznie szybciej niż z wykorzystaniem CASE-a. Nie zgadzam się z nimi. Uważam, że CASE jest niezbędny i, że jest on przydatny zarówno w fazie analizy i projektowania aplikacji, jak i później, gdy trzeba te aplikacje poprawiać i modyfikować. Nie wyobrażam sobie sytuacji, gdy firma produkująca oprogramowanie i wersjująca kolejne aplikacje w zależności od grupy klientów, nie trzyma tego w jednym repozytorium. Skąd oni wiedzą co i komu sprzedali? Nie twierdzę jednak, że każdą część aplikacji można wygenerować w oparciu o CASE. Są fragmenty oprogramowania klienckiego, które się nie generuje a pisze w inny sposób, np. w PL/SQL. Ale nawet jeżeli pisze się w te fragmenty w PL/SQL, to należy je przechowywać w Designer 2000, bo przynosi to później profit. Choćby to, że wiemy jakich tablic i jakich kolumn używają poszczególne fragmenty oprogramowania.

  Maciej Matysiak (Politechnika Poznańska):

Rozpocznę od postawienia fundamentalnego pytania: po co używać narzędzi CASE? Trzeba za nie sporo zapłacić, trzeba dysponować czy też zdobyć wiedzę jak nimi się posługiwać. Nie jest to tylko wiedza o narzędziu, ale również wiedza inżynierska i metodyczna. Rodzi się więc pytanie, czy praca wejścia i koszty z tym związane rzeczywiście się zwracają? Koszty te mogą się, na przykład, zwrócić poprzez skrócenie czasu realizacji projektu informatycznego. Stąd, rodzi się drugie pytanie: czy korzystając z narzędzi CASE można zrealizować projekt informatyczny krócej? A jeżeli nie krócej, to czy korzystanie z narzędzi CASE nie wpłynie na poprawę jakości naszego projektu?

  Tomasz Traczyk (Politechnika Warszawska):

To jest ważny problem: po co kupować drogie narzędzie, a potem uczyć się go w pocie czoła. Odpowiedzi jest kilka. O części z nich powiemy pewnie w drugiej części dyskusji. Jedna jest zasadnicza – projekt powinien być zdatny do zarządzania – powinna istnieć wiedza o całości projektu zgromadzona w jednym miejscu w formie nadającej się do użytku. Chciałbym jednak ten sam problem przedstawić nieco inaczej. Mówienie o nadziejach i realizacji tych nadziei w stosunku do narzędzi CASE jako całości wydaje mi się lekko podejrzane. Tak naprawdę, to są dwa różne narzędzia, używane przez dwie różne grupy osób, do różnych rzeczy. Jest tak zwany „upper-CASE” i „lower-CASE”. Ten pierwszy służy do modelowania, ten drugi jest narzędziem projektantów i programistów aplikacji. Często bywa tak, że grupy użytkowników obu narzędzi różnią się – bo przecież pełnią różne funkcje w projekcie, czasami nawet sprzeczne. Również ich oczekiwania względem narzędzi CASE są różne. Moje doświadczenia w stosunku do obu części CASE?a są drastycznie różne. Może dlatego, że ja miałem nadzieje zróżnicowane. Zawsze mi się wydawało, że ten tak zwany „upper-CASE” nie powinien się w ogóle nazywać „CASE” tylko „Computer-Aided-Drawing-and-Printing”. Korzystając z tego narzędzia robi się rysunki. Ja nie lubię rysować, ale ponieważ taka jest ogólnie przyjęta konwencja, to muszę to stosować. Ale ponieważ miałem do tego stosunek z góry lekko podejrzliwy, to
nie mogłem się na tym zawieść – co najwyżej mogłem być tylko przyjemnie
zaskoczony. Jeżeli chodzi o „lower-CASE”, to tu dla odmiany wiązałem z tym narzędziem duże nadzieje. Nie jest tak, że się zawiodłem. W znacznej części te nadzieje się spełniły. Oczywiście nie w 100%, bo nie wszystko daje się zrobić automatycznie. Poza tym, obowiązuje tutaj taka ogólna zasada dotycząca wszystkich nowoczesnych narzędzi informatycznych: jeżeli jest narzędzie odpowiednio wysokiej tzw. generacji, to ono fantastycznie służy do robienia tego, co twórca tego narzędzia sobie wyobrażał, że będzie nim robione. Natomiast, jak próbuje się nim zrobić coś innego, to jest to coś okropnego. To dotyczy ogólnie języków 4GL. Najbardziej uniwersalnie pisze się w asemblerze, ale wydajność wówczas jest słaba.

  Krzysztof Leśny (Maxsoft):

Ja znajduję się po środku, bo staram się tych narzędzi używać.
Uważam, że narzędzia CASE są w tej chwili niezbędne, zresztą my kładziemy bardzo duży nacisk na pracę z nimi. Jeśli mówimy o ORACLE’u to jest to pakiet Designer/2000, na temat którego moi dwaj współpracownicy mieli wykłady (zarówno o górnej, jak i dolnej części, oraz o dokumentowaniu, prowadzeniu, rozliczaniu aplikacji, całokształtu prac projektowych i wreszcie o konserwacji aplikacji). Jest jednak pewien problem: idea jest pierwszorzędna, całkowicie się z nią zgadzamy, a nawet nie wyobrażamy sobie pracy bez narzędzi CASE, natomiast ta konkretna implementacja tych narzędzi (Designer 2000) posiada pewne „dziury” i niedociągnięcia. Innym problemem, który wypłynął już w dyskusjach towarzyszących, jest zagadnienie styku między nauką i przemysłem. Rozmawiamy z absolwentami lub studentami V-tego roku informatyki i okazuje się, że oni nigdy w życiu nie widzieli CASE’a! Zarówno ja, jako szef firmy informatycznej, jak i państwo jako: projektanci aplikacji, dyrektorzy zakładowych ośrodków informatyki, oczekujemy, że uczelnie będą przygotowywały do zawodu. Natomiast ci absolwenci nie wiedzą, co to jest metodologia CASE, nie umieją modelować, nie wiedzą nic o procesach, nie znają normalizacji. I to jest mój problem jako szefa firmy. Uważam CASE za narzędzie niezbędne. Stosujemy to narzędzie we wszystkich naszych projektach. Wręcz, jeżeli jest dobrze zrobiona specyfikacja wymagań, to czasem nawet do przetargu stajemy z wygenerowanymi już wstępnie formatkami. Oczywiście, do aplikacji gotowego „chodzącego” systemu jest jeszcze bardzo daleko, niemniej jest to już jakiś konkret i klient może zobaczyć już choćby fragment aplikacji. Reasumując, nie wyobrażamy sobie już pracy bez tych narzędzi. Inna sprawa, że CASE nie pokrywa do końca wszystkich faz projektu.

  Tomasz Traczyk (Politechnika Warszawska):

Tradycyjnie kamyczek został wrzucony do ogródka wyższych uczelni, więc ja już tradycyjnie będę go odrzucał. Po pierwsze, radykalnie nie zgadzam się z tezą, że wyższe uczelnie powinny przygotowywać ludzi do zawodu. Ja, na przykład, z wykształcenia jestem odwracaczem macierzy i szczerze powiedziawszy, to odwracanie macierzy niespecjalnie mi się teraz przydaje w wykonywanym zawodzie. Natomiast, jeżeli chodzi o przygotowywanie przez uczelnie absolwentów w dziedzinie narzędzi CASE, to mamy tutaj do czynienia z trzema czynnikami, z których dwa są obiektywne, trzeci natomiast ma charakter subiektywny. Pierwszy, obiektywny, jest trywialny nie ma pieniędzy a oprogramowanie CASE jest drogie. Czynnik ten nie jest jednak najważniejszy. Drugi, znacznie ważniejszy jest następujący. Narzędzia CASE to bardzo rozległe i obszerne oprogramowanie, i nie bardzo można wyobrazić sobie sposób ich nauczania. Nie możemy robić przedmiotu pod tytułem Oracle Designer 2000. To jest sprzeczne z ideą uczelni wyższej. Jeżeli gdzieś na boku wspomnimy o tym narzędziu, to z tego nic nie wynika. Trzeci czynnik jest subiektywny – po pierwsze, nie mamy tradycji nauczania tego przedmiotu, po drugie, nie mamy od tego specjalistów.

  Krzysztof Leśny (Maxsoft):

Sądzę, że trzeba było zacząć od tego trzeciego czynnika. Nie mamy armat – jak u Napoleona. Sądzę, że jednak można nauczać tego przedmiotu. To tak jak z edytorem tekstu. Jeżeli znamy już jeden, to otwierając inny edytor potrafimy już napisać i sformatować prosty tekst. To samo dotyczy narzędzi CASE. Po pierwsze, to co Pan już powiedział, brakuje na uczelniach fachowców od tych narzędzi. Tutaj wyjątkiem jest Politechnika Poznańska i WAT. Uczelniom brakuje pieniędzy – tak, ale ci ludzie, którzy kończą Informatykę nie są fachowcami. Co oni potrafią? Napisać w Visual Basic’u, którego sami nauczyli się w domu, biblioteczki kaset video. Nie są przygotowali do udziału w realizacji dużych projektów. Nie znają zasad realizacji projektów, zarządzania takimi projektami, produkcji oprogramowania. To jest jedna z podstawowych przyczyn niepowodzeń projektów informatycznych w Polsce. My i również Państwo, pracownicy wyższych uczelni, jako podatnicy płacimy za niepowodzenia tych projektów.

  Tadeusz Morzy (Politechnika Poznańska):

Pan Krzysztof jak zwykle próbuje zrzucić winę na uczelnie. Do dyskusji o kształceniu kadr na uczelniach wrócimy za moment, natomiast teraz chciałbym powrócić do pytania: czy opłaca się kupować stosunkowo drogie oprogramowanie jakim są narzędzia CASE, i czy to oprogramowanie rzeczywiście zamortyzuje się w trakcie realizacji projektów informatycznych. Jeżeli Pan jako prezes firmy wydaje pieniądze na oprogramowanie, to rozumiem, że interesuje Pana kiedy te pieniądze się zwrócą. Czy ten zysk polega na tym, że projekt zostanie wykonany szybciej, że wyprodukowane oprogramowanie będzie bardziej stabilne, że cały proces projektowania i zarządzania projektem będzie łatwiejszy i prostszy? Inny bardzo ważny problem, o którym powiemy pewnie później, to uniezależnienie się od karuzeli osób przychodzących do projektu i odchodzących od niego, a zabierających ze sobą często całą wiedzę o konkretnym problemie. Czy można postawić tezę, że dzięki narzędziom CASE produkuje się oprogramowanie szybciej, lepiej i bezpieczniej?

  Gizela Skarżyńska (Oracle Polska):

Sądzę, że tak. Nic mi nie wiadomo o takich badaniach w Polsce, ale mam dane niemieckie. Politechnika w Monachium przeprowadziła ankietę na temat na ile Designer 2000 pomógł niemieckim firmom informatycznym w produkcji oprogramowania. Wyniki pokazują, że średnio o ok. 30% skrócono czas realizacji projektów. Uwzględniając oprogramowanie narzędziowe, towarzyszące Designer’owi 2000, w sumie korzystając z narzędzi CASE średnio udaje się zaoszczędzić ok. 20 osobotygodni. Nasi informatycy nie są gorsi, często są lepsi. U nas problem jest nieco inny – bardzo trudno jest zorganizować pracę w zespole. Trudno jest zachęcić ludzi do współpracy w grupie ponad 2-osobowej. A projektów informatycznych nie robi się solo. Stąd, moim zdaniem, problemy z realizacją projektów informatycznych wynikają u nas, po pierwsze, z istnienia małych zespołów realizatorów, a po drugie, z organizacji ich pracy. Moje doświadczenia z pracy z użytkownikami pokazują, że grupa 5-6 osobowa, z niewielkim doświadczeniem lub po kursie w zakresie Oracle’a, może, korzystając z Designer’a 2000, zrealizować całkiem przyzwoity prototyp (rzędu 400 modułów) w ciągu kilku miesięcy. Nie wyobrażam sobie, aby takie oprogramowanie taki zespół był w stanie zrealizować w inny sposób. Ponadto, jeżeli mamy wymianę załogi, tj. odchodzi zespół analityczny i zostają tylko 2-3 osoby, aby zapewnić ciągłość projektu, jeżeli nie mamy informacji analitycznych w repozytorium, to sytuacja może być niewesoła. Inną kwestią jest na ile szef projektu jest w stanie wymusić wpisywanie wszystkich informacji do repozytorium. Korzystanie z tego narzędzia wspomaga dyscyplinę projektu, ale samo narzędzie nie załatwi wszystkiego – musimy jeszcze się nauczyć umiejętnie z niego korzystać.

  Maciej Matysiak (Politechnika Poznańska):

Nie zgadzam się z Panią, jeżeli chodzi o czas realizacji projektu. Z naszych doświadczeń, jak i sygnałów, które do mnie docierają wynika, że firmy, które realizowały pewne projekty bez posługiwania się narzędziami typu „upper-CASE”, po zakupie tego narzędzia projekty podobnej skali realizowały mniej więcej w tym samym czasie. Natomiast, zdecydowanie na korzyść wypada jakość projektu i końcowy efekt, który się uzyskuje. Nie mówiąc o późniejszych zyskach związanych z utrzymywaniem wyprodukowanego oprogramowania. Reasumując, moim zdaniem, czas realizacji projektu nie ulega zasadniczo zmianie w przypadku korzystania z narzędzi CASE.

  Gizela Skarżyńska (Oracle Polska):

To zależy jeszcze od tego jak jest realizowany dany projekt. Jeżeli zaczynamy projekt od budowy bazy danych, pomijając fazę analizy i zakładając, że jeżeli konieczne będą modyfikacje, to ludzie posiedzą nieco dłużej i poprawią to co zrobili, to ma Pan rację. Nie wiem tylko, czy jest to dobra metoda. Przy dużych projektach nie można tak działać.

  Tomasz Traczyk (Politechnika Warszawska):

Jest jeszcze jeden problem, o którym chciałem wspomnieć. Czas
realizacji projektu jest inny przy pierwszym wdrażaniu technologii CASE i radykalnie różny przy następnych wdrożeniach. Stąd, problemy z technologią CASE najczęściej wynikają z faktu, że ten pierwszy próg, który trzeba pokonać jest znacznie wyższy niż przy tradycyjnej metodzie produkcji oprogramowania. Nieszczęście polega na tym, że każda firma, która przechodzi na tę technologię robi kiedyś ten pierwszy projekt i może się po prostu zniechęcić do nowej technologii. Następne projekty robi się, moim zdaniem, jednak szybciej niż innymi technikami. Ten pierwszy raz jest po prostu kosztowny. To powoduje często, że pakiety CASE są kupowane i później leżą na półkach. Nie jest to jednak tylko polska specyfika.

  Tadeusz Morzy (Politechnika Poznańska):

To mam jeszcze pytanie o kompletność narzędzi CASE. Czy ono zaspokaja potrzeby projektantów i programistów?

  Krzysztof Leśny (Maxsoft):

Jeżeli chodzi o „upper-CASE”, to on spełnia swoją rolę. Mówimy tutaj oczywiście o produkcie Designer 2000, bo jesteśmy na konferencji stowarzyszenia PLOUG. Jeżeli chodzi natomiast o „lower-CASE”, to ma on poważne luki, a przejście do następnego narzędzia (Developer) jest bardzo „siermiężne”. Kiedy po raz pierwszy korzystaliśmy z tego narzędzia, to był to poważny problem. Tutaj chciałbym wrzucić kamyczek do działu szkoleń firmy Oracle. Szkolenia w tym zakresie, mówiąc bardzo delikatnie, są „trochę niedopracowane”. Część materiałów szkoleniowych jest wyprodukowana w Stanach, część w Irlandii, i każda z nich jest na inny temat. Problem szkoleń jest ważny. To jest bardzo złożone narzędzie. Po pierwsze, trzeba wiedzieć co się chce z tym zrobić, po drugie, trzeba wiedzieć jeszcze jak to zrobić. Cykl szkoleń, które nie są najtańsze, jest chaotyczny i powyrywany z kontekstu. Brakuje dobrych szkoleń. Powtórzę jednak jeszcze raz, że nie wyobrażam sobie pracy w firmie bez tych narzędzi. Co więcej, porównując narzędzia CASE Oracle’a z podobnymi narzędziami innych firm, muszę powiedzieć, że te narzędzia są najbardziej kompletne, wspomagają praktycznie, lepiej lub gorzej, cały proces projektowania i produkcji oprogramowania, oraz pielęgnacji tego oprogramowania. To jest bardzo ważne w kontekście fluktuacji kadr w Polsce. Wchodzą firmy zachodnie i oni mają budżet na pensje zachodnie. My nie jesteśmy w stanie z nimi konkurować na tym polu. Mając CASE ja mam lepszą dokumentację, elektroniczną, oraz oprogramowanie lepszej jakości. Łatwiejsza jest pielęgnacja tego oprogramowania, wprowadzanie modyfikacji, nawet nie mając pod ręką twórcy tego oprogramowania. Z odejściem programistów trzeba się liczyć – a systemy żyją wiele lat, trzeba jest rozwijać, pielęgnować, dostosowywać do zewnętrznych warunków. Narzędzia CASE umożliwiają i ułatwiają cały ten proces. Uważam, że inwestycja w te narzędzia była dobrą inwestycją, która już się nam zwróciła.

  Tomasz Traczyk (Politechnika Warszawska):

Mój poprzednik powiedział, że jest zadowolony z „upper-CASE”, natomiast „lower-CASE” jest taki sobie. Moje odczucia są odwrotne. Uważam, że w tym „upper-CASE” wszystkiego brakuje, ale nie jest to wina Oracle’a, tylko metody strukturalnej, która została zaimplementowana. Jestem natomiast bardzo zadowolony z „lower-CASE”, z którego udało mi się wycisnąć prawie wszystko co chciałem. Chociaż kosztowało to czasami dużo zdrowia.

  Gizela Skarżyńska (Oracle Polska):

Ja pracuję z tym narzędziem (Designer 2000) już ładnych parę lat i jestem z niego bardzo zadowolona. Oczywiście, mógłby być nieco bardziej elastyczny, pewnie należałoby jeszcze go uzupełnić o coś dodatkowego, niemniej spełnia on swoją rolę. To może nie jest trudne oprogramowanie, ale bardzo rozległe – jak kałuża. Daje się to oprogramowanie w jakiś skończonym czasie opanować i zupełnie przyjemnie się z tego korzysta – przynajmniej ci, którzy nie lubią specjalnie kodowania.

  Głos z sali:

Bardzo mi się podoba Pani optymizm, jeżeli chodzi o to narzędzie. Pani korzysta z niego już kilka lat, ja natomiast korzystam z Designer’a 2000 ok. 1,5 roku. Jest parę elementów, których brakuje w tym narzędziu. Jestem ciekaw jak poradziłaby sobie Pani z jakimkolwiek algorytmem obliczeniowym, gdyby miała Pani do dyspozycji wyłącznie to narzędzie. Może ja nie umiem z niego korzystać?

  Gizela Skarżyńska (Oracle Polska):

Nigdy nie twierdziłam, że wszystko można zrobić korzystając wyłącznie z Designer’a 2000. Uważam natomiast, że jeżeli jesteśmy w stanie wygenerować 75% aplikacji, to jest to dobry wynik. Większość czasu możemy więc poświęcić tym 25%. Wszędzie obowiązuje reguła 80% – 20%. Chodzi o to, aby maksymalnie szybko zrealizować to 80%. Natomiast są takie fragmenty aplikacji, które np. trzeba napisać w Pro -C.

  Głos z sali:

W firmie „Otago” używamy narzędzi CASE Oracle’a już od wielu lat, poprzednio w wersji tekstowej, obecnie korzystamy z Designer’a 2000. To co nas najbardziej nurtuje, to problem konserwacji aplikacji. Mamy produkt, który wymaga konserwacji. Designer 2000, jak i wcześniejszy CASE, w naszej opinii wykazuje pewne braki. Przede wszystkim chodzi o wersjonowanie – profilowanie np. modułów pod kątem użytkowników. Mamy grupę użytkowników. Każdy z użytkowników może chcieć innej wersji danego modułu. Brakuje nam wersjonowania obiektów. Jest wersjonowanie aplikacji, natomiast nie ma wersjonowania obiektów.

  Gizela Skarżyńska (Oracle Polska):

To prawda. Mogę polecić, jako wspomaganie wersjonowania obiektów, pakiet wykonany przez holenderskich konsultantów, który się nazywa Echo 2000. To trochę pomaga. Są przymiarki, aby następna wersja Designer’a 2000 miała już opcje wersjonowania obiektów. Poza tym mogę powiedzieć, że następna wersja Designer’a 2000 będzie posiadała pełny reverse modułów. Myślę, że to znacznie ułatwi sprawę. Ja też wolałabym, aby trigger’y opisywane do formatki były widziane z Designer’a 2000.

  Krzysztof Leśny (Maxsoft):

Czy mogę się dowiedzieć, kiedy będzie dostępna ta wspaniała wersja Designer’a 2000? Demo Designer’a 2000 w wersji. 2.0 była pokazywana na konferencji satelitarnej już w połowie stycznia. Od tego czasu zapadła cisza jak kamień w
kapustę.

  Mariusz Zabielski (Oracle Polska):

Nowa wersja ma być dostępna na początku przyszłego roku. Opóźnienie, które wystąpiło jest związane z pojawieniem się Oracle’a w wersji 8. Początkowo, nowe wersje Designer’a i Developer’a miały się pojawić na rynku przed Oracle 8, ale wówczas byłaby niekonsekwencja. Mielibyśmy sytuację, że nowo wprowadzony produkt (Designer 2000 wersja. 2.0) nie wspomagałby Oracle 8. Dlatego pojawiły się nowe wersje Developer’a i Designer’a, jako tzw. substytuty pewnej funkcjonalności wersji 2.0. Obecnie, wersje te zostaną zsynchronizowane i pojawią się na początku przyszłego roku. Nowe wersje maja już wspierać Oracle 8.

  Krzysztof Leśny (Maxsoft):

Czy mogę się dowiedzieć jakie są miłościwie nam panujące wersje
Developer’a i Designer’a?

  Mariusz Zabielski (Oracle Polska):

Aktualne wersje są następujące. Developer – wersja 1.5.1; Designer – 1.3.2 z patch’em, który pozwala generować aplikacje do wersji 1.5.1.

  Tadeusz Morzy (Politechnika Poznańska):

Może przejdźmy do drugiego z problemów wymienionych na początku, który zresztą już przewijał się w kilku wypowiedziach, a mianowicie, CASE jako element procesu zarządzania projektem. O jednym aspekcie tego zagadnienia już wspomnieliśmy, a mianowicie, ludzie przychodzą do projektu i odchodzą zabierając często z sobą całą wiedzę problemową o realizowanym fragmencie projektu. Stosowanie narzędzi CASE częściowo chroni firmę przed taką sytuacją. Innym aspektem, o którym już wspominała p. Gizela, jest kontrola postępów i wykonawstwa. Czy narzędzia CASE spełniają w praktyce również i tę rolę? Czy rola tych narzędzi jako elementu zarządzania projektem nie staje się często ważniejsza niż ta rola pierwotna? Czy można sobie wyobrazić realizację dużego projektu bez narzędzi CASE i co za tym idzie: autodokumentowania prac, prototypowania aplikacji, śledzenia postępów.

  Gizela Skarżyńska (Oracle Polska):

Dodałabym, poza problemami związanymi z ludźmi oraz wydajnością, jeszcze jedną rzecz, a mianowicie, użycie tych narzędzi dyscyplinuje projekt i pozwala na zrobienie normalnego planu projektu. Istnieje podział projektu na fazy, poszczególne części narzędzia wspierają te fazy (definicji, analizy, projektu, itd.), można określać elementy kluczowe projektu. Z Developerem 2000 została silnie powiązana metodyka Oracle’a (Custom Developement Method), którą nota bene sprzedaje się w postaci osobnego pakietu. Zarządzanie projektem metodą „na hura”, bez jakiegokolwiek wspomagania ze strony narzędzi CASE jest, w moim mniemaniu, niemożliwe. Można oczywiście zażyczyć sobie, aby Developer/2000 był powiązany z np. MS Project i generował automatycznie wykresy Ganta, ale MS Project nie jest produktem Oracle’a. Istnieją jednak narzędzia ABT zajmujące się planowaniem i estymacją czasochłonności projektu i z nimi Developer 2000 jest zintegrowany. Można poprzez te narzędzia wygenerować plan projektu wraz z podziałem na role. Oczywiście, plan ten będzie wymagał korekt, ale będzie to nanoszenie poprawek, a nie pisanie planu od podstaw.

  Maciej Matysiak (Politechnika Poznańska):

Chciałbym nawiązać do problemu dokumentacji. Upatruję tu jedną z podstawowych, kapitalnych korzyści płynących z zastosowania narzędzi CASE. Polega ona na zmuszeniu twórców aplikacji do jednoczesnego tworzenia oprogramowania i jego dokumentowania. Dokumentacja jest niezbędna w przypadku rotacji pracowników (komuś dochodzącemu do projektu znacznie łatwiej jest się w nim poruszać) oraz w przypadku utrzymywania aplikacji. Często zdarza się tak, że utrzymaniem zajmują się inni ludzie, niż twórcy systemu. Kompletna dokumentacja w postaci elektronicznej radykalnie obniża koszty zarówno wytworzenia, jak i utrzymania oprogramowania.

  Tomasz Traczyk (Politechnika Warszawska):

Moje doświadczenia są nieco nietypowe, ponieważ wszystkie projekty, w których uczestniczę mają jedną wspólną cechę: są realizowane przez bardzo małe zespoły (mimo, że same projekty wcale nie są takie małe). Poza tym, są to projekty, które będziemy robić do emerytury – nie dlatego, że pracujemy opieszale; taka jest po prostu rzeczywistość, którą próbujemy uchwycić. W naszej sytuacji pewne problemy związane z zarządzaniem projektem nie występują (np. rotacja pracowników). Zresztą nie wierzę w tę zarządzającą rolę repozytorium, bo problem i tak sprowadza się do dobrej woli – można całość dokumentacji pozostawić na papierze i nie zostawić nic w repozytorium. Dla mnie istotna jest powtarzalność działań. Moduły napisane przeze mnie dwa lata temu i te, które piszę dziś, pochodzą od tego samego twórcy i to po nich widać. Dawniej, gdy wszystko było pisane ręcznie, to programista albo się dopiero uczył, i kolejne moduły były coraz lepsze, albo miał już dosyć i kolejne moduły były pisane coraz bardziej „na odczepnego”. W rezultacie aplikacje nie były jednorodne. I druga związana z tym sprawa. Każda aplikacja o długim cyklu życiowym powinna być raz na jakiś czas poddawana kuracji wstrząsowej. Służy to zdrowiu psychicznemu twórców i jakości aplikacji. Dawniej wyrzucało się cały program i pisało się go od nowa, przy czym ten nowy był radykalnie lepszy. Niestety, przez dwa lata trzeba było nową wersję testować, użytkownicy narzekali („po co Pan wyrzucał ten program, przecież był świetny?”) i zadowolony był tylko twórca. Dzięki narzędziom CASE w dużym stopniu możemy takiej sytuacji uniknąć. Dwukrotnie już stawałem przed koniecznością usunięcia wszystkich modułów i ich ponownej generacji i przy dobrze prowadzonym projekcie nie stanowiło to problemu. W tradycyjnym podejściu taka radykalna kuracja w stosunku do programu prowadzi do poważnych perturbacji, podczas gdy przy użyciu narzędzi CASE jest w zasadzie niegroźna.

  Gizela Skarżyńska (Oracle Polska):

Chciałam poruszyć jeszcze jeden temat, a mianowicie kwestię standaryzacji oprogramowania. Dobrze jest, gdy wszystkie ekrany aplikacji wyglądają tak samo, wszystkie raporty mają tą samą główkę, stronę tytułową, stopkę i koniec. Generując aplikację możemy taki efekt uzyskać poprzez szablony. Oczywiście tworzenie szablonów jest bardzo czasochłonne i uciążliwe, tradycyjni programiści uważają to za zbędny wysiłek, ale po ich utworzeniu oszczędzamy sobie pracy związanej ze standaryzacją. Formatki i raporty wyglądają tak samo, można nawet ujednolicić formę i treść komunikatów! Osobną rzeczą są przeglądy jakości. Nie wyobrażam sobie testowania np. jakości bazy danych bez narzędzi CASE. Dobrze zrobiony diagram związków-encji i model tablic umożliwiają dokonanie kompletnego przeglądu jakości, a nawet zdalną ocenę fragmentu projektu. Wystarczy przesłać fragment repozytorium, obejrzeć i ocenić np. schemat bazy danych i odesłać to wraz z komentarzami.

  Tadeusz Morzy (Politechnika Poznańska):

Zanim przejdziemy do dyskusji o tym, dlaczego mając doskonały produkt w postaci narzędzi CASE i doskonałe firmy informatyczne nie mamy produktów wytworzonych przez te firmy tymi doskonałymi narzędziami, chciałbym na moment wrócić do postawionego pytania: dlaczego uczelnie nie kształcą studentów w zakresie metodyki i narzędzi CASE, albo dlaczego robią to tylko nieliczne uczelnie? Są tego dwa główne powody. Po pierwsze – pieniądze. Pan Krzysztof mówił o płaceniu podatków na szkoły. Panie Krzysztofie – płaci Pan za mało! Oprogramowanie w zakresie CASE my, Instytut Informatyki Politechniki Poznańskiej, musieliśmy kupić. Coraz droższe oprogramowanie wymaga coraz droższego sprzętu – potrzebujemy większych monitorów, szybszych komputerów, bardziej pojemnych dysków, itd., czyli zakup kolejnych wersji oprogramowania wymaga kolejnych inwestycji w sprzęt (powinniśmy co dwa lata wymieniać komputery w naszych laboratoriach) a to są wydatki przekraczające nasze możliwości. Drugim aspektem jest niepełne przygotowanie kadr dydaktycznych, jest on związany z problemem dysertabilności niektórych haseł (państwo związani ze szkolnictwem wyższym doskonale rozumieją, o czym mówię). Trudno jest się dysertabilitować z narzędzi CASE. Być może jakimś rozwiązaniem jest bliższe przyjrzenie się nowo przyjmowanym pracownikom.

  Tomasz Traczyk (Politechnika Warszawska):

Temu ma służyć kształcenie studentów z narzędzi CASE. Osobiście jestem przeciwnikiem uczenia studentów narzędzi, powinni się oni uczyć metodyki. U nas prowadzi się od lat takie wykłady i cieszą się one niską popularnością wśród studentów. Nie możemy zmuszać studentów do przychodzenia na te wykłady. Niska frekwencja jest też po części związana z okresowo panującymi modami, na które nie mamy wpływu. Osobiście nie rozumiem, dlaczego studenci nie pchają się drzwiami i oknami na wykłady o CASE, tłocząc się jednocześnie na wykładach z sieci komputerowych.

  Głos z sali:

Nie ma sensu sponsorowanie uczelni i dawanie im narzędzi CASE za darmo. W większości uczelni oprogramowanie to leży na półce i nie jest wykorzystywane.

  Tadeusz Morzy (Politechnika Poznańska):

To jest temat wykraczający poza dyskusję o narzędziach CASE. Krótka odpowiedź jest następująca: wina leży po oby stronach. Bardzo bym sobie życzył, aby zgłosił się do mnie ktokolwiek z branży przemysłowej i zamówił system. Oferujemy, jako uczelnia, wszystko: oprogramowanie, kursy, wiedzę, chodzimy od zakładu do zakładu i rozmawiamy z ludźmi, którzy po pierwsze nie wiedzą, czego chcą, a po drugie nie mają pieniędzy. Jak już znajdziemy kogoś, kto u nas coś zamawia, to zaczynamy szukać tego trzeciego, który za zamówienie zapłaci. Szczegółowo ta kwestia zostanie poruszona jutro w czasie dyskusji o kontraktacji usług informatycznych. Ja natomiast chciałbym wrócić do pytania o przydatność narzędzi CASE. Stosowanie narzędzi CASE czasem opóźnia realizację projektu. W szczególności, chodzi mi o tworzenie i przedstawianie do akceptacji użytkowników kolejnych schematów, formatek, itp. Część z Państwa tu siedzących to użytkownicy końcowi i ważne jest uświadomienie sobie, że zaakceptowany i podpisany schemat ma bardzo duże znaczenie, jeśli chodzi o jakość końcowego produktu. Dobrze wykonany schemat procentuje w późniejszym czasie wysokim poziomem aplikacji, natomiast błędy popełnione na tym etapie są kosztowne. Być może po tym ataku na uczelnie wyższe uda nam się zaatakować użytkowników końcowych?

  Gizela Skarżyńska (Oracle Polska):

Rolą szefa projektu jest takie ustalenie współpracy z użytkownikiem, aby stał się on współtwórcą programu. Wówczas użytkownik łatwiej identyfikuje się z systemem, traktując go jako (po części) swoje dziecko, nakłaniając współpracowników do korzystania z systemu. W grę wchodzą oczywiście i inne czynniki, takie jak choćby opór psychologiczny ludzi, którzy przyzwyczaili się do pracy ze starym programem lub do pracy bez pomocy komputera i nagle muszą się uczyć czegoś nowego, lub, co gorsza, zaczynają bać się utraty pracy. Przekonanie ludzi do zmian w tej dziedzinie jest bardzo trudne. Drugim zagadnieniem jest prezentowanie użytkownikowi zakresu informacyjnego i funkcjonalnego aplikacji. Użytkownicy podczas sesji zwrotnych muszą „strawić” model informacyjny oraz dokładnie dowiedzieć się, czego mogą się po aplikacji spodziewać. Współpraca z użytkownikami jest czasochłonna, ale nie wolno o niej zapominać, bo pod koniec projektu można usłyszeć zdanie: „Ależ proszę pana, to miało zupełnie inaczej wyglądać!”. Wszystko zasadza się na kwestiach organizacyjnych. Użytkownik oczywiście ma swoje zadania, ale obowiązkiem szefa projektu jest ustalenie płaszczyzny współpracy. Ideałem jest przekonanie szefa firmy, że oddelegowanie niektórych jego pracowników do projektu pozytywnie wpłynie na jakość produktu końcowego. Kilka razy spotkałam się z taką sytuacją.

  Maciej Matysiak (Politechnika Poznańska):

Państwo zdaje się nie doceniacie argumentu dotyczącego motywacji
przyszłych użytkowników. Przedsięwzięcie informatyczne jest finansowane z pewnych źródeł, bierze w nim udział jakiś wykonawca oraz użytkownicy, którzy powinni być za swoje zaangażowanie wynagradzani.
Motywacją nie jest wizja obiecanego systemu, bo trudno go sobie wyobrazić.
Motywacją powinna być również dodatkowa korzyść finansowa, wynikająca z dodatkowej pracy wykonanej przez użytkowników.

  Tadeusz Morzy (Politechnika Poznańska):

Dawniej sytuacja wyglądała następująco: analityk szedł do klienta z dyktafonem, odbywał dyskusję, rysował schemat pojęciowy, hierarchię funkcji, diagram przepływu danych, konstruował aplikację i w końcu dowiadywał się, że nie spełnia ona wymagań klienta. Narzędzia CASE umożliwiają przeprowadzanie wieloetapowej weryfikacji. Za pomocą hierarchii funkcji czy schematu pojęciowego można wiele spraw z użytkownikiem uzgodnić i w pewien sposób dyscyplinować użytkownika czyniąc go w jakiejś mierze odpowiedzialnym za produkt finalny: podpisałeś ten schemat pojęciowy, diagram funkcji – bierzesz więc odpowiedzialność za końcowy efekt. CASE stanowi narzędzie wspólnej komunikacji i w tym sensie mówimy o nim jako o elemencie zarządzania projektem. W jakim stopniu firmy korzystają z narzędzi CASE, na ile znają te narzędzia lub próbują poznać?

  Krzysztof Leśny (Maxsoft):

Ze swojej strony mogę zapewnić, że korzystamy z tych narzędzi i uważamy je za bardzo przydatne. W innych firmach rzecz ma się różnie; niektóre modelują bazę danych, a resztę pracy wykonują ręcznie, jeszcze inne całość produkcji aplikacji wykonują bez pomocy narzędzi CASE. Nas po prostu na taki system ręczny nie stać i staramy się dociągnąć każdy projekt jak najniżej się da w CASE po to, aby w Developerze/2000 pracować jak najmniej. Ręcznej obróbce podlega tylko strona wizualna, dopieszczanie poszczególnych ekranów, ewentualnie wprowadzanie formuł obliczeniowych, algorytmów, itp. W efekcie otrzymujemy spójną, jednolitą graficznie aplikację w krótszym czasie. Przestawienie się innych firm na tą technologię jest tylko kwestią czasu.

Następnie na sali rozpoczęła się dyskusja na temat przygotowania dokumentacji technicznej i użytkowej aplikacji. Pojawiły się głosy krytyczne stwierdzające bardzo często niską jakość i przydatność dokumentacji użytkowej i technicznej.

  Krzysztof Leśny (Maxsoft):

Stosujemy taką zasadę, że część dokumentacji technicznej drukujemy (np. hierarchię funkcji) i dostarczamy użytkownikom, pozostałą część dostarczamy w wersji elektronicznej.. Zrezygnowaliśmy z drukowania całości, gdyż całość zajęłaby 2 m półek, a i tak nikt by nie zajrzał do tej dokumentacji jak uczy nas doświadczenie.

  Głos z sali:

Uważam, że jeżeli chodzi o dokumentację techniczną aplikacji, to Designer 2000 jest bardzo dobrym narzędziem. Natomiast jeżeli chodzi o dokumentację użytkową to jest on nieprzydatny.

  Głos z sali:

Problem dokumentacji użytkowej nowych aplikacji rozwiązaliśmy w PKP w taki sposób, że dokumentacja jest przygotowywana przez użytkowników. Tworzymy zespoły użytkowników, które po przeszkoleniu przygotowują dokumentację użytkową.

  Tomasz Traczyk (Politechnika Warszawska):

Ja bym chciał w pełni solidaryzować się z tym podejściem. Nie ma nic gorszego niż dokumentacja napisana przez kogoś, kto pisał program. To jest tak samo jak testowanie prototypu przez jego twórcę W obecności twórcy prototyp zawsze działa. Podobnie dla autora programu jest on w pełni zrozumiały, więc do dokumentacji trafiają rzeczy albo zupełnie nieistotne dla użytkownika, albo rzeczy dla niego zbyt trudne. Rzeczy istotne nie zostają umieszczone w dokumentacji, gdyż dla autora programu są oczywiste i nudne. To podejście jest moim zdaniem trafne.

  Głos z sali (PKP):

To nie jest tak, że użytkownik sam musi wszystko zrobić. Użytkownik jest prowadzony za rękę przez zespół projektowy – robi tę dokumentację w jakimś stopniu pod dyktando. To nie jest pomysł PKP. My przejęliśmy to podejście od Oracle’a, który nas w tym wspierał.

  Tadeusz Morzy (Politechnika Poznańska):

Wielu kolegów podkreślało wcześniej, że ważną cechą narzędzi CASE jest to, że równolegle z aplikacją powstaje dokumentacja tej aplikacji. Okazuje się jednak z naszej dyskusji, że powstająca dokumentacja jest gównie przeznaczona dla firmy przygotowującej oprogramowanie, natomiast jest mało przydatna, albo wcale, dla użytkownika. Jaką korzyść z tej dokumentacji ma użytkownik?

  Gizela Skarżyńska (Oracle Polska):

Wiele zależy od standardów, w jakich jest tworzona dokumentacja techniczna. Korzystanie z CASE’a ma tę zaletę, że informacje przechowywane w repozytorium stanowią wierne odbicie rzeczywistości, czyli aktualną dokumentację techniczną.. Unika się tym samym sytuacji, kiedy formatki są już czwartą wersją aplikacji, a na papierze mamy dopiero pierwszą wersję. Elementem każdego dobrze prowadzonego projektu jest dokumentowanie, którego zakres i stopień dokładności powinny być jasno ustalone w kontrakcie.

  Głos z sali (PKP):

Projekt potrzebuje trojakiej dokumentacji. Po pierwsze „projektowej”, czyli relacji z tego, co zrobił zespół programistów. Tutaj narzędzia CASE w pełni się sprawdzają, pod warunkiem wprowadzania do repozytorium informacji o wszystkich ręcznych zmianach. Drugim typem jest dokumentacja dla użytkownika końcowego. Trzecim elementem, o którym często się zapomina, jest dokumentacja eksploatacyjna, która dokładnie mówi, co musi zrobić zespół informatyczny firmy klienta, aby aplikacja mogła poprawnie działać. Powinien to być zbiór informacji dla administratora bazy danych dotyczących koniecznych działań, wykorzystywanych struktur bazy danych, parametrów konfiguracyjnych, itp. Prowadzący uśmiechnął się, gdy mówiliśmy o tym, że użytkownicy uczestniczą w przygotowaniu dokumentacji użytkowej. Musimy pamiętać o tym, że użytkownik jest autorem oprogramowania. Informatycy zbyt często zawłaszczają sobie prawa autorskie do produktu, należne użytkownikowi. To on specyfikuje wymagania programu, poświęca swój czas na sesje zwrotne i konsultacje.

  Tadeusz Morzy (Politechnika Poznańska):

Zgadzam się z tą tezą. Użytkownik oczywiście odgrywa podstawową rolę. Jego specyfikacja modelu danych i hierarchii funkcji jest podstawą dalszych prac. Z punktu widzenia użytkownika, projektant i programista są odpowiedzialni tylko za implementację, możliwie dokładnie spełniającą jego wymagania.

  Głos z sali:

Zgadza się, lecz w takim razie udział programisty to techniczna implementacja, a nie autorstwo. Nasze autorstwo może polegać na konstrukcji poprawnego modelu danych. Można przecież zbudować wadliwy model, za sprawą którego zapytania będą realizowane godzinami, a można zaprojektować bazę efektywnie, gdzie odpowiedzi systemu będą natychmiastowe. Jednak w typowych aplikacjach informacyjnych, księgowych, magazynowych, itp., autorska rola informatyka będzie maleć.

  Głos z sali:

Brałem kiedyś udział w projekcie w całości prowadzonym w asemblerze. Wówczas, a było to przed ośmiu laty, nie było żadnego CASE’a, natomiast zdumiała mnie metoda zwartego i bardzo zdyscyplinowanego przestrzegania prowadzenia projektu. Zarządzanie projektem jest najważniejszą kwestią. W stosunku do narzędzi CASE ma się oczekiwania znacznie przewyższające ich rzeczywiste możliwości i przeznaczenie. CASE zapewnia automatyzację pewnych procesów, spójność dokumentacji i możliwość powrotu do stanu wiedzy o systemie w dowolnym momencie, ale uporządkowanie pewnych zagadnień musi odbyć się ręcznie. Narzędzia CASE mają wciąż wiele wad i niedociągnięć, oczekujemy, że zostaną one wyeliminowane w następnych wersjach, ale najważniejsze już jest – porządkowanie zarządzania projektem. I jeszcze uwaga dotycząca udziału użytkowników w projektowaniu systemu. Mamy do czynienia z przełomem socjologicznym. Nowe pokolenie, młodzi pracownicy wszystkich szczebli są już od dziecka oswojeni z komputerami, ich świat zaczyna się od którejś tam wersji Windows i znajomość tych zagadnień staje się coraz bardziej powszechna. Problemy z użytkownikami, którzy nie chcą brać udziału w projekcie, to często są problemy pokoleniowe. Ten sam problem występuje wśród starszych informatyków, którzy przyzwyczaili się do starych narzędzi i zamiast nauczyć się Oracle’a, wolą dalej pracować w Clipperze.

  Gizela Skarżyńska (Oracle Polska):

Każde narzędzie jest na tyle dobre, na ile jest dobrze stosowane. Wszystko i tak sprowadza się do czynnika ludzkiego. Nawet posiadając najdoskonalsze narzędzie to człowiek wprowadza informacje i to człowiek tym wszystkim zarządza. Nigdy nie będziemy mieli tak doskonałego narzędzia CASE, że wystarczać będzie naciśnięcie jednego klawisza w celu zbudowania aplikacji, nadal pozostaje najważniejsze- człowiek.

Opracowanie: Tadeusz Morzy

Ze względu na słabą jakość zapisu magnetofonowego zabrakło kilku głosów z sali.