System Medyk Założenia, historia, wynik prac i wnioski

Plan prezentacji Wprowadzenie w pierwszy projekt. Napotkane problemy. Założenia drugiego projektu. Napotkane problemy i sposób rozwiązania. Przyszłość projektu. Podsumowanie, możliwości kontynuacji tematu.

Wprowadzenie Zamawiający system – Instytut Matki i Dziecka (IMiD). Przyczyna zamówienia – udział w programie Hansa East sponsorowanym przez komisję UE. Biorący udział w programie: Rumunia, Słowacja, Węgry, Polska

Wprowadzenie Biorący udział w programie ze strony polskiej: –Optimus SA (od początku) –Grupa studentów SGH –Grupa studentów PJWSTK Wszystkie 3 zespoły działały niezależnie.

Pierwotne założenia projektu Zbudowanie systemu ADT oparty na middleware DHE (Distributed Healthcare Environment) Zbadanie przydatności DHE i jego zgodności z polskimi normami i wymaganiami Porównanie systemu opartego na DHE (PJWSTK) i opartego na technologiach tradycyjnych (SGH)

Wybrane technologie PJWSTK : Oracle + DHE + Visual Basic SGH : Oracle + Visual Basic Optimus : Oracle + DHE + Oracle Forms + Visual C

Charakterystyka DHE Middleware oparty na wytycznych standartu Health Information System Architecture (HISA) opracowany przez komisję UE Wersje dla systemów *nix i Windows, dla różnych platform bazodanowych Oparty na własnych protokołach komunikacyjnych

Wady DHE Bardzo skomplikowana instalacja i konfiguracja Bardzo utrudnione wprowadzanie zmian w modelu danych Nieczytelny model danych Słaba kontrola spójności bazy Niedostosowany do polskich wymagań

Produkt zamówiony i otrzymany Zamówiony System przyjęciowo-wypisowy (ADT) oparty na middleware DHE Wyniki: Optimus : Obsługa pracowni rentgenowskiej PJWSTK : lokalizacja włoskiej aplikacji ADT SGH : brak istotnych wyników

Pierwotny projekt marszem ku klęsce Ogromne ograniczenie czasowe (trzy miesiące) Brak znajomości technologii Wady dostarczonego produktu Brak zaplecza Słabe wsparcie ze strony GESI Próba zastąpienia brakującego czasu dodatkowymi osobami

Założenia nowego projektu Opracowanie systemu ADT opartego na nowoczesnych technologiach Wymagana łatwa modyfikacja modelu danych Dostosowanie do polskich wymagań i przepisów Łatwa przenaszalność i możliwość korzystania z dowolnej bazy danych

Wybór technologii CORBA – w celu pozbycia się problemów z komunikacją, oraz możliwości pisania zarówno serwera jak i klienta w wielu językach programowania. JAVA – łatwiejszy w użyciu od C++, przenaszalny, łatwiejszy w pielęgnacji, darmowa implementacja standartu CORBA dla Javy (dostarczana z JDK)

Plan prac Zapoznanie się z nowymi technologiami Równoległe prace analityczne i projektowe Zatwierdzenie analizy i projektu przez IMID Definicja interfejsów (IDL) Równoległe prace nad implementacją usług i aplikacją kliencką. Testowanie i akceptacja aplikacji

Rzeczywisty przebieg prac Zapoznanie się z nowymi technologiami tylko przez część zespołu w przewidzianym czasie. Problemy z przeprowadzeniem pełnej analizy Wyniki analizy zatwierdzane były wielokrotnie (mniej-więcej co tydzień). Wskutek zmian w wynikach analizy projekt i definicja interfejsu zmieniane był z równą częstotliwością.

Rzeczywisty przebieg prac Znaczne opóźnienie w rozpoczęciu prac nad aplikacją kliencką. Znaczące opóźnienie testowania wskutek poprzednich opóźnień. Zakończone prace tylko nad częścią aplikacji klienckiej.

Problemy na jakie napotkaliśmy podczas współpracy z klientem Częste zmiany wymagań wskutek zmian przepisów. Niezdecydowanie zamawiającego. Zmiana zakresu prac w czasie. O pewnych zmianach dowiadywaliśmy się w dziwnych sytuacjach. Konieczność stałego nadzoru nad testowaniem projektu i aplikacji przez zamawiającego (tendencja do odkładania pracy na później).

Problemy techniczne Implementacja CORBA zawarta w JDK 1.3 jest niepełna (brak implementacji większości services i facilities) i wadliwa (np. niezwalnianie pamięci po nie używanych obiektach). Problemy we współpracy z bazą danych Oracle Brak standartu obsługi pustych łańcuchów tekstowych w różnych bazach danych.

Zalety podejścia komponentowego Łatwa modyfikacja systemu Niezależne testowanie komponentów Łatwiejsze oprogramowanie komponentów Łatwiejsze korzystanie z udostępnianych usług

Najbliższa przyszłość Zintegrowanie z systemem Akson opracowanym przez Olafa Matyję z IPI PAN Zakończenie prac nad podstawowymi aplikacjami klienckimi. Rozproszenie i/lub scentralizowanie systemu (zależnie od decyzji klienta).

Możliwości rozwoju Zarządzanie zleceniami i zasobami. Przeniesienie systemu pod VisiBroker lub inną komercyjną implementację. Opracowanie aplikacji klienckich i rozszerzeń serwera dla zastosowań specjalistycznych (np. pracownia diagnostyki obrazowej).

Podsumowanie Udane stworzenie systemu konkurencyjnego wobec istniejących rozwiązań zagranicznych. Zdobyte doświadczenia zarówno czysto techniczne, jak i metodologiczne.

Możliwości kontynuacji tematu w ramach pracy magisterskiej Kontynuacja projektu, rozbudowa go o wskazane elementy. Prace teoretyczne oparte na naszych doświadczeniach z prac nad projektem w celu opracowania metodologii umożliwiającej unikanie popełnionych błędów.