System „Medyk”

1. System „Medyk” Założenia, historia, wynik prac i wnioski

2. 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.

3. 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

4. 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.

5. 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)

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

7. 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

8. 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ń

9. 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

10. 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

11. 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

12. 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)

13. 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

14. 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ą.

15. 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.

16. 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).

17. 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.

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

19. 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).

20. 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).

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

22. 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.