Załącznik nr 1 do Zapytania ofertowego nr 1/2014. Przebieg realizacji

Transkrypt

1 Warszawa, r. Pieczęć Zamawiającego Załącznik nr 1 do Zapytania ofertowego nr 1/2014 Przebieg realizacji Implementacja projektu będzie podzielona na 4 etapy, z czego pierwszy polega na przygotowaniu architektury systemu, dwa kolejne dostarczą funkcjonalności platformy aplikacyjnej i moduły funkcjonalne, 4-ty etap zaś dostarczy modułów procesowych. W czasie trwania projektu rozwijane będą również moduły pomocnicze. Projekt będzie realizowany w metodyce interacyjno- przyrostowej. Praca podzielona będzie na etapy które będą składały się z jednej lub więcej iteracji. Każda z iteracji kończyć będzie się gotowym i działającym fragmentem aplikacji (przyrostem). Prace będą realizowane w modelu ciągłej integracji (Continous Integration). Wnioskujący podzielił projekt na 4 etapy: Etap 1 (do r) Projekt platformy aplikacyjnej rozpoczęcie projektu. Na tym etapie powstanie dokładny projekt architektury fizycznej i logicznej, projekty głównych mechanizmów systemu oraz architektury bezpieczeństwa. Etap 2 (do r) Budowa platformy aplikacyjnej Wykonanie platformy aplikacyjnej. Będzie to bardzo złożony system klas Enterprise, prace nad nim wymagały będą dokładnego zaplanowania pod kątem technicznym, co zostanie wykonanie w etapie 1. Etap 3 (do r) Budowa modułów funkcjonalnych - Wykonanie modułów funkcjonalnych platformy. Moduły funkcjonalne platformy będą wykorzystywały podstawowe mechanizmy platformy aplikacyjnej i udostępniały funkcje bardziej wysokopoziomowe niż podstawowe mechanizmy wytworzone na etapie 2. Etap 4 (do r) Budowa modułów procesowych - Wykonanie modułów procesowych i pomocniczych oraz instalacja infrastruktury technicznej. Wynagrodzenie za wykonane w etapie prace będzie wypłacane Wykonawcy bezpośrednio po zakończeniu danego etapu. Wypłata wynagrodzenia poprzedzona zostanie spisaniem protokołu odbioru, potwierdzonym zrealizowanie prac. Strona 1 z 17

2 Podział prac na etapy umożliwi lepsze zarządzanie pracami. Zakres prac przewidzianych w ramach poszczególnych etapów oraz technologia: I. Etapy projektu: Etap 1 Projekt architektury systemu W etapie tym wykonany zostanie szczegółowy projekt architektury systemu, zarówno logicznej jak i fizycznej, w tym dokładne oszacowanie potrzebnej mocy obliczeniowej i zasobów dla systemu (capacity planning): Architektura logiczna wraz z projektami interfejsów miedzy modułami Architektura fizyczna wraz z rozmieszeniem komponentów na maszynach fizycznych oraz zaplanowaniem zakupu niezbędnej infrastruktury Projekt systemu na poziomie klas oraz interakcji wyrażony w notacji UML Zaprojektowana zostanie również architektura bezpieczeństwa przez co należy rozumieć w szczególności: Uprawnienia dla głównych funkcjonalności platformy Role grupujące uprawnienia Zaprojektowanie mechanizmów w module bezpieczeństwa z wykorzystaniem najnowszego dostępnego raportu organizacji OWASP Na tym etapie opisane zostaną również standardy kodowania, standardów integracyjnych oraz standardów GUI obowiązujące w projekcie. Opracowane i opisane zostaną również reguły poprawności architektonicznej. Na tym etapie należy uwzględnić wymagania w zakresie integracji z partnerami wskazanymi przez Zamawiającego. W ramach tego etapu utworzone zostaną również środowiska deweloperskie i testowe. Środowiska deweloperskie (IDE) wraz ze zbiorem pluginów: Do badania metryk kodu Do wyszukiwania potencjalnych błędów na podstawie analizy statycznej kodu Do testów jednostkowych i integracyjnych Środowiska deweloperskie zawierały będą również lokalne zainstalowane elementy niezbędne do testowania utworzonego kodu platformę Java, serwery aplikacji, kontenery portletów, systemy zarządzania relacyjną bazą danych. Strona 2 z 17

3 Utworzone zostaną również serwery testowe, prace te obejmować będą: Instalację sprzętu Instalację systemów operacyjnych Instalację platformy Java Instalację serwerów aplikacji WildFly / JBoss AS 7 Instalacje kontenera portletów Liferay Instalację serwera ciągłej integracji (Continous Integration) W systemach operacyjnych utworzone zostaną konta użytkowników na systemach operacyjnych. Etap 2 Budowa platformy aplikacyjnej Etap ten obejmował będzie utworzenie modułów dostarczających podstawową funkcjonalność, niezbędnych do pracy nad kolejnymi modułami. Dla każdego z modułów zostaną przeprowadzone testy funkcjonalne i integracyjne oprócz standardowo wykonywanych testów jednostokowych w obrębie modułu. Moduł bezpieczeństwa Moduł definiujący algorytmy i funkcjonalności związane z uwierzytelnieniem, autoryzacją. Umożliwi zarządzanie rolami oraz grupami uprawnień. Ważnym elementem będzie SSO (Single Sing On), ponieważ umożliwi modułową realizację systemu. Moduł będzie dostarczał funkcjonalności: Wtyczek do mechanizmów bezpieczeństwa serwera aplikacji Java Enterprise Edition, w standardzie JAAS (Java Authorization and Authentication Service). Bibliotekę klas pomocniczych dostarczających funkcjonalności bezpieczeństwa oraz funkcjonalności kryptograficznych (np. obliczanie skrótu, szyfrowanie komunikatu) Graficzny interfejs użytkownika dla funkcjonalności logowania Klasy filtrów w standardzie Java Enterprise Edition w celu realizacji zabezpieczeń przed atakami hakerów i cyber przestępców Moduł pamięci współdzielonej Moduł pamięci współdzielonej udostępni możliwość przechowywania dużej liczby danych w pamięci, przyspieszając znacznie dostęp do tych danych. Moduł będzie wykorzystywany jako pamięć podręczna dla operacji na bazie danych. Rozwiązanie klasy In-Memory Data Grid. Moduł oparty będzie o produkt JBoss Inifispan, i będzie mógł być wykorzystywany na dwa sposoby: poprzez bezpośrednią integracją z JBoss Inifinispan poprzez katalog usług JNDI udostępniany przez serwer WildFly / JBoss AS 7 Poprzez API zdefiniowane przez sam moduł. API definiować będzie funkcjonalności dodawania danych do pamięci współdzielonej, pobierania danych z pamięci współdzielonej, usuwania Strona 3 z 17

4 (ewikcji) danych z pamięci współdzielonej. Repozytorium danych Repozytorium danych oparte o bazę danych Microsoft SQL Server 2012 lub równoważną pod względem funkcjonalnym o ile zostaną spełnione wymagania dotyczące architektury systemu. Konfiguracja repozytorium obejmowała będzie utworzenie przestrzeni danych (bazy danych), zdefiniowanie użytkowników: Administracyjnego z uprawnienia do przeglądania i modyfikacji danych, jak również struktur danych oraz nadawania uprawnień, Aplikacyjnego z uprawnieniami do przeglądania i modyfikacji danych, Użytkownika zwykłego mogącego jedynie przeglądać dane. Moduł zarządzania tematami graficznymi Komponent odpowiedzialny za zarządzanie (dodawanie, modyfikację lub usunięcie) oraz udostępnienie tematów graficznych dla interfejsu użytkownika. Moduł będzie oparty o funkcjonalność portalu Liferay. Tematy graficzne będą pozwalały na modyfikację wyglądu strona dla poszczególnych organizacji. Moduł zarządzania słownikami Komponent odpowiedzialny za zarządzanie słownikami oraz udostępnianie słowników w ramach systemu. Komponent ten umożliwiał będzie dodawanie nowych słowników, edycję istniejących oraz ich usuwanie. Dla każdego ze słowników możliwe będzie dodawanie nowych wartości słownikowych, edycja istniejących wartości jak również usunięcie zapisanych wartości słownikowych. Wartości słownikowe będą danymi w dużej mierze statycznymi, więc będą mogły być przechowywane w pamięci współdzielonej. W przypadku modyfikacji wartości słownikowej będzie ona automatycznie usuwana z pamięci współdzielonej na całym klastrze, tak aby zachować spójność danych. Moduł komunikacji zdarzeniowej Komponent umożliwiający wykorzystanie architektury zdarzeniowej (z ang. EDA Event Driven Architecture). W szerokim zakresie będzie wykorzystywany w ramach systemu w celu zapewnienia luźnego powiązania między modułami. W powiązaniu z modułem integracyjnym może być wykorzystany w integracji z systemami zewnętrznymi. Moduł ten będzie udostępniał: kanał wejściowy dla zdarzeń, komponent przetwarzający zdarzenia którego zdarzeń, odpowiedzialny za ich ewentualną agregację i przekierowanie do odpowiedniego kanału wyjściowego, reguły przetwarzania zdarzeń zdefiniowane w formie wtyczek (klas implementujących odpowiedni interfejs oraz skonfigurowanych w module jako wtyczka dla danego typu zdarzenia) komponent kliencki umożliwiający wysłanie zdarzenia z dowolnego innego komponentu Moduł będzie definiował dwa fizyczne artefakty: Strona 4 z 17

5 Artefakt JAR dla modułu komunikacji zdarzeniowej definiował będzie komponenty nasłuchujące na kanale wejściowym oraz komponent przetwarzający żądania i reguły przekierowywania zdarzeń. Artefakt JAR komponentu klienckiego modułu komunikacji zdarzeniowej będzie to mała biblioteka definiująca klasy pomocnicze dla modułów chcących wysyłać zdarzenia bądź je odbierać Moduł zarządzania użytkownikami Komponent umożliwiający zarządzanie użytkownikami w systemie. Funkcjonalności modułu obejmować będą: Dodawanie konta użytkownika Edycja konta użytkownika Deaktywacja konta użytkownika Konfiguracja uprawnień dla użytkowników Konto użytkownika będzie identyfikowane przez unikalną nazwę użytkownika (login) oraz zabezpieczone hasłem. Moduł ten będzie udostępniał graficzny interfejs użytkownika i będzie korzystał z funkcjonalności portalu Liferay. Audyt i log zdarzeń Moduł realizuje funkcjonalność audytu, zbiera zdarzenia audytowe, zapisuje je oraz umożliwia ich przeglądanie i filtrowanie. Istotnym faktem jest, iż moduł ten będzie mógł przechwytywać nie tylko zdarzenia zmiany, ale każde zdarzenie jakie będzie miało miejsce w aplikacji. Od strony technicznej moduł audytu i logu zdarzeń zrealizowany będzie w technologii JMS (Java Message Service), gwarantującej brak utraty danych oraz minimalne obciążenie funkcjonalności biznesowej przez funkcjonalność audytu. Zdarzenia audytowe przekazywane będą w sposób asynchroniczny do kolejki agregującej, skąd będą pobierane i zapisywane w bazie danych. Moduł audytu i logu zdarzeń posiadał będzie graficzny interfejs użytkownika pozwalający na przeglądanie zdarzeń, wyszukiwanie wśród zdarzeń wg kryteriów takich jak: Login użytkownika inicjującego zdarzenie Imię i nazwisko użytkownika inicjującego zdarzenie Data zdarzenia Typ zdarzenia Moduł praktycznie nie będzie obciążał funkcjonalności biznesowych, dzięki asynchronicznemu trybowi działania, będzie on równie odporny na błędy które mogą powstać przy wykonaniu akcji która inicjuje zdarzenie. Będzie to osiągnięte dzięki rozdzieleniu transakcji modułu audytu i logu zdarzeń oraz transakcji modułów realizujących funkcjonalności biznesowe. Moduł wykorzystywał będzie funkcjonalności modułu komunikacji zdarzeniowej. Strona 5 z 17

6 Moduł komponentów biznesowych Moduł ten będzie biblioteką komponentów Java, w szczególności Enterprise Java Beans. Będzie on dostarczał funkcjonalności które będą wykorzystane do budowy logiki biznesowej komponentów innych modułów. Każdy moduł funkcjonalny składał się będzie z modułu www oraz modułu komponentów biznesowych, i wykonany będzie w architekturze trójwarstwowej. Moduł komponentów biznesowych wybranego modułu funkcjonalnego wykorzystywał będzie komponenty zdefiniowane w tym module, dzięki czemu nie zaistnieje duplikacja kodu. Moduł komponentów procesowych Moduł ten będzie biblioteką komponentów Java, wykorzystywanych w procesach biznesowych. Moduł komponentów procesowych będzie zawierał wykorzystywane w co najmniej dwóch procesach elementy programowe wymagające tworzenia kodu Java, dzięki czemu nie zaistnieje duplikacja kodu. Moduł komponentów GUI Moduł dostarcza reużywalne komponenty graficznego interfejsu użytkownika, które mogą być wykorzystane do budowy graficznego interfejsu użytkownika konkretnych procesów sprzedaży ubezpieczeń. Moduł ten będzie biblioteką klas i komponentów do tworzenia interfejsu użytkownika (tzw. tagów i kontrolek). Kontrolki udostępniane przez ten moduł obejmować będą: Pole wyboru daty Pole wyboru daty z czasem Pole hasła (nie wyświetlające znaków jawnym tekstem) Pole tekstowe Pole numeryczne, jako specjalizacja pola tekstowego pozwalająca na wprowadzenie jedynie cyfr Pole wielowierszowe edycji tekstu (tzw. rich text area) Lista pojedynczego i wielokrotnego wyboru Listy powiązane Tabela z funkcjonalnością wyświetlania podzbioru danych (stronicowaniem) Tabel wyświetlająca komplet danych Etap 3 Budowa modułów funkcjonalnych W etapie tym utworzone zostaną kolejne elementy platformy aplikacyjnej. Będą to moduły wyższego poziomu korzystające w usług modułów zbudowany w ramach drugiego etapu. Dla każdego z modułów zostaną przeprowadzone testy funkcjonalne i integracyjne oprócz standardowo wykonywanych testów jednostokowych w obrębie modułu. Moduł integracyjny Moduł zapewnia możliwości integracji z systemami zewnętrznymi wykorzystujący rozwiązanie klasy ESB Mule ESB oraz architekturę SOA. Pozwala to na wyniesienie logiki integracyjnej poza komponenty Strona 6 z 17

7 odpowiedzialne za realizację logiki biznesowej oraz ponowne użycie tejże logiki integracyjnej. Moduł stanowił będzie platformę integracyjną pozwalającą na dodawanie kolejnych komponentów z minimalnym nakładem prac. Podstawowe usługi oferowane przez moduł to: Transformacje komunikatów Przekierowanie (routing) komunikatów Obsługa błędów integracji Te bazowe usługi, w połączeniu z obsługą bardzo dużej liczby formatów i protokołów umożliwią budowę integracji związanych konkretnymi procesami biznesowymi. Moduł integracyjny wyróżniał będzie trzy warstwy: Kanały integracyjne warstwa usług udostępnianych przez moduł integracyjny Usługi integracyjne usługi skupiające reużywalną logikę integracyjna, np. agregację, mapowanie, transformację czy wzbogacanie komunikatów Adaptery integracyjne będzie to warstwa wywołująca usługi systemu zintegrowanego Tworzenie przepływów integracyjnych będzie wspierane przez zintegrowanie środowisko deweloperskie (IDE) z zainstalowaną wtyczką do tworzenia usług na magistrali Mule ESB. Moduł monitoringu procesów Moduł umożliwiał będzie przeglądanie definicji procesów oraz instancji uruchomionych, jak również ukończonych procesów. Funkcjonalność modułu udostępniona będzie w postaci aplikacji www udostępniającej graficzny interfejs użytkownika. Moduł ten będzie również pozawalał na raportowanie. Dostępne w ramach zakresu projektu raporty obejmowały będą: liczbę ukończonych zadań przez wybranego użytkownika w okresie wybranego miesiąca czas jaki zajmuje przetwarzania w podziale na zadania Będzie istniała możliwość dodania kolejnych raportów. Moduł obiegu dokumentów Moduł udostępniający i przechowujący dokumenty. Moduł będzie udostępniał takie funkcjonalności jak: Wersjonowanie dokumentów, możliwość przeglądania wersji i jej przywrócenia Katalogi dokumentów Przenoszenie dokumentów między folderami Dodawanie atrybutów do dokumentów, definiowanie typów dokumentów Wyszukiwanie pełno tekstowe Udostępnia dokumenty dla procesów, dostęp do dokumentów będzie możliwy poprzez API. Moduł przyczyni się znacznie do ograniczenia wykorzystania papierowej dokumentacji, szczególnie dzięki funkcjonalności wyszukiwania pełno tekstowego. Moduł zarządzania partnerami Komponent umożliwiający zarządzanie użytkownikami będącymi pracownikami partnerów EKU Sp. z o.o. systemu oraz ich uprawnieniami. Komponent będzie mógł importować użytkowników z formatów CSV i XML oraz z LDAP. Funkcjonalności modułu obejmować będą: Dodawanie konta organizacji Strona 7 z 17

8 Modyfikację konta organizacji Dodawanie konta użytkownika Edycja konta użytkownika Dezaktywacja konta użytkownika Przydzielania użytkownika do organizacji Konfiguracja uprawnień dla użytkowników Konto użytkownika będzie identyfikowane przez unikalną nazwę użytkownika (login) oraz zabezpieczone hasłem. Moduł ten będzie udostępniał graficzny interfejs użytkownika i będzie korzystał z funkcjonalności portalu Liferay. Moduł zarządzania procesami Moduł będzie pozwalał na definiowanie procesów w notacji BPMN 2.0. Dzięki wykorzystaniu standardu BPMN 2.0 możliwe będzie również tworzenie definicji procesów w innych narzędziach, jeżeli tylko będą one tworzyły definicje procesu w standardzie BPMN 2.0 i nie będą zawierały rozszerzeń tego standardu. Moduł będzie pozwala na konfigurację kroków procesów w zakresie m.in. zdefiniowania formularzy dla zadań, grup i użytkowników do który zostanie przydzielone zadanie, obsługi zdarzeń (w tym zdarzeń czasowych, np. zbyt długie oczekiwanie na dokument od partnera), kroki decyzyjne, kroki integracyjne oraz kroki usługowe pozwalające na wywołanie kodu Java lub kodu skryptu w języku Groovy. Moduł zarządzania produktami Moduł ten będzie pozwalał na definiowanie produktów ubezpieczeniowych oferowanych przez Wnioskodawcę. Każdy produkt posiadał będzie listę atrybutów, przy czym lista ta będzie otwarta. System udostępniał będzie szablon z bazowymi atrybutami. Produkt posiadał będzie również listę procesów powiązaną z danym produktem, listę dokumentów powiązaną z procesem. W module tym będzie również zarządzanie dostępnością produktu, czy dany produkt ma być aktywny, w jakim okresie i dla jakich klientów. Moduł definiował będzie definicje produktów, moduły procesowe korzystać będą z tej definicji, ale pracować będą na wystąpieniach (instancjach) danego produktu dla konkretnego wystąpienia (instancji) procesu. Moduł Raportów operacyjnych Moduł ten będzie składował i uruchamiał raporty operacyjne, czyli raporty z dowolnych danych biznesowych systemu. Raporty będą definiowane w specjalnym pliku definicji raportu który składowany będzie w module obiegu dokumentów, oraz zasilane wynikiem zapytania zdefiniowanego dla danego raportu. Każdy z raportów będzie role niezbędne dla uruchomienia tego raportu. Bez posiadania odpowiednich ról, raport nie zostanie udostępniony użytkownikowi. Raporty zostaną wykonane z wykorzystaniem sprawdzonej i popularnej technologii Jasper Reports. Moduł e-learningu Moduł ten będzie składował i udostępniał treści e-learingowe dla Partnerów, użytkowników systemu. Treści będą miały zdefiniowany termin ważności. Treścią będzie mogły być pliki lub hiperłącza do zewnętrznych systemów. Wykorzystanie pliku załączonego w tym module, jak również dokumentu Strona 8 z 17

9 dostępnego pod adresem wskazanym przez hiperłącze (będącym np. aplikacją Adobe Flash lub Java FX) będzie zależne od możliwości przeglądarki i systemu operacyjnego użytkownika i jest poza zakresem odpowiedzialności tego modułu. Etap 4 Budowa modułów procesowych W etapie tym zostaną wykonane moduły procesowe pozwalające na integracje z partnerami EKU Sp. z o.o. oraz aplikacje mobilne. Dla modułów zostaną przeprowadzone testy funkcjonalne, integracyjne, wydajnościowe, obciążeniowe oraz bezpieczeństwa. Testy jednostkowe będą oczywiście tworzone wraz z kodem przez deweloperów. Wykonane moduły pozwolą na realizację procesów biznesowych: 1. Proces obiegu dokumentów dotyczących przystąpienia do ubezpieczenia grupowego Budowana platforma B2B pozwoli na zautomatyzowanie wymiany dokumentów pomiędzy współpracującymi ze sobą przedsiębiorstwami. Wnioskujący będzie przekazywał za pomocą budowanego systemu do Partnerów zestaw dokumentów niezbędnych do zarejestrowania ubezpieczającego przystępującego do umowy grupowej, w formie dokumentów elektronicznych podpisanych bezpiecznym podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym. Wdrożenie elektronicznego systemu obiegu dokumentów pozwoli na osiągnięcie podstawowego celu realizowanego projektu, czyli automatyzacji. Rozwiązanie to zapewni również bezpieczeństwo przesyłanych danych oraz natychmiastowy dostęp do dokumentów. Wdrożony zostanie także kwalifikowany podpis elektroniczny 2. Proces obiegu dokumentów dotyczących zmiany Platforma B2B umożliwi zautomatyzowanie wymiany dokumentów pomiędzy współpracującymi ze sobą partnerami biznesowymi. Broker ubezpieczeniowy będzie przekazywał za pomocą budowanego systemu, do Partnera wszystkie dokumenty zmiany, w formie dokumentów elektronicznych podpisanych certyfikatem kwalifikowanym. Rozwiązanie to zapewni również bezpieczeństwo przesyłanych danych oraz natychmiastowy dostęp do dokumentów. System będzie również umożliwiał generowanie powiadomień mailowych o wysłaniu/otrzymaniu dokumentów. Dodatkową zaletą będzie zmniejszenie kosztów związanych z przesyłania dokumentów kurierem. 3. Proces aktualizacji danych Kolejnym ważnym, automatyzowanym procesem będzie aktualizacja bazy danych. System podczas wprowadzania/modyfikacji danych będzie je walidował i przekazywał partnerowi. System informatyczny będzie również wspierał pracowników Wnioskodawcy w zakresie kolejności działań wymuszając określone kroki procesu w ustalonej kolejności, co doprowadzi do eliminacji błędów. Dodatkowo system Strona 9 z 17

10 będzie wykonywał szereg czynności automatycznie, odciążając pracowników EKU Sp. z o.o. i zwiększając efektywność ich pracy o mniej więcej 30%. Liczba dokumentów drukowanych w celu weryfikacji znacznie spadnie, ponieważ ich przenoszenie między komórkami firmy będzie się odbywało automatycznie przez System. System będzie również posiadał zapis wykonywanych na nim operacji, co dodatkowo zwiększy bezpieczeństwo przechowywanych w nim danych oraz skalowalność w dostępie, w zależności od uprawnień. Pracownik Wnioskującego będzie otrzymywał komunikaty o wyniku weryfikacji. Aktualizacja danych klientów przez pracownika Wnioskującego w systemie EKU Sp. z o.o. będzie jednocześnie powodować aktualizację danych w systemie Partnera. 4. Proces obiegu dokumentów raportowych Po wprowadzeniu elektronicznego obiegu dokumentów B2B będzie można wyeliminować przesyłanie danych poufnych za pomocą poczty elektronicznej. Takie rozwiązanie pozwoli na uporządkowanie i zautomatyzowanie obiegu dokumentów, pełne bezpieczeństwo przesyłanych danych, szybki dostęp do przechowywanych danych i przesyłanych plików, jak również możliwość tworzenia różnego rodzaju raportów i analiz. System pozwoli na łatwą pracę z dokumentami elektronicznymi. System będzie również posiadał zapis wykonywanych na nim operacji, co dodatkowo zwiększy bezpieczeństwo przechowywanych w nim danych. W ramach zautomatyzowanego obiegu dokumentów zostanie również wdrożony kwalifikowany podpis elektroniczny, który pozwoli na uwiarygodnienie wszystkich przesyłanych dokumentów, tam, gdzie jest to niezbędne. Wdrożenie elektronicznego obiegu dokumentów pomoże w osiągnięciu wspólnego celu współpracującym przedsiębiorstwom, takich jak: szybki dostęp do dokumentów dla osób upoważnionych niezawodność i wysoki poziom bezpieczeństwa dokumentów usprawnienie procedur wewnętrznych sprawny obieg dokumentów oraz terminowość i kontrola załatwiania spraw eliminacja obiegu dokumentów za pomocą poczty elektronicznej. 5. Proces wysłania aneksów do umów i faktur Elektroniczny obieg dokumentów umożliwi przesyłanie dokumentów bezpiecznym kanałem elektronicznym. Zagwarantuje to bezpieczeństwo przesyłanych danych oraz szybki dostęp do przechowywanych danych i plików. Obie strony będą miały możliwość podpisywania dokumentów certyfikatem kwalifikowanym, który pozwoli na uwiarygodnienie wszystkich przesyłanych dokumentów, tam, gdzie jest to niezbędne. 6. Proces rozliczania prowizji i składek Platforma B2B rozwiąże problem przesyłania poufnych danych za pomocą poczty elektronicznej oraz pozwoli na uporządkowanie i zautomatyzowanie obiegu dokumentów. System Wnioskodawcy automatycznie będzie mógł pobierać i analizować dane z komunikatu. Zapewni to pełne bezpieczeństwo przesyłanych danych oraz szybki dostęp do przechowywanych danych i przesyłanych plików. Wyeliminowane zostanie przesyłanie potwierdzeń pocztą, gdyż dokumenty będą podpisywane Strona 10 z 17

11 elektronicznie. Elektroniczny obieg dokumentów pozwoli na zautomatyzowanie wymiany dokumentów pomiędzy współpracującymi ze sobą partnerami biznesowymi. Wnioskujący będzie przekazywał do partnerów rozliczenie składek od poszczególnych klientów w formie dokumentów elektronicznych. Wdrożenie elektronicznego systemu obiegu dokumentów pozwoli na osiągnięcie podstawowego celu realizowanego projektu, czyli automatyzacji. Rozwiązanie to zapewni również bezpieczeństwo przesyłanych danych oraz natychmiastowy dostęp do dokumentów Aplikacje mobilne realizowane w ramach etapu: Aplikacja mobilna będzie udostępniała partnerom i klientom EKU Sp. z o.o. funkcjonalności dostępne w systemie. Będzie dostępna w następujących wersjach: Dla platformy Android: podzbiór funkcjonalności zalogowanie, podgląd konta, podgląd dla listy polis ubezpieczeniowych i szczegółów wybranej polisy bez możliwości edycji Dla platformy ios: podzbiór funkcjonalności zalogowanie, podgląd konta, podgląd dla listy polis ubezpieczeniowych i szczegółów wybranej polisy bez możliwości edycji Dla platformy Windows Phone: podzbiór funkcjonalności zalogowanie, podgląd konta, podgląd dla listy polis ubezpieczeniowych i szczegółów wybranej polisy bez możliwości edycji Należ zauważyć, iż system utworzony w ramach projektu będzie aplikacją przeglądarkową, będzie więc również możliwość korzystania z niej z wbudowanej w dane urządzenie przeglądarki internetowej. W ramach etapu zostanie zrealizowana instalacja infrastruktury technicznej i oprogramowania: W celu uruchomienia platformy i bazującego na niej systemu wytworzonej w ramach projektu niezbędne będzie wykonanie wdrożenia: Konfiguracja ról i polityk bezpieczeństwa na środowisku produkcyjnym Utworzenie produkcyjnych schematów bazy danych Konfiguracja urządzeń sieciowych w zakresie reguł routowania i wydzielenia sieci DMZ Aktualizacja dokumentacji architektury systemu Instalacja i konfiguracja wszystkich modułów Testy dymne Testy akceptacyjne Otwarcie ruchu dla partnerów EKU Sp. z o.o. na poziomie sieci komputerowej Strona 11 z 17

12 II. Technologie informatyczne: Charakterystyka tworzonego systemu B2B Utworzony w ramach projektu system będzie aplikacją typu enterprise, wykonaną w technologii Java EE 6. Będzie to rozwiązanie modułowe. Do budowy systemu wykorzystane zostaną sprawdzone biblioteki i technologie, jednocześnie nie będą to rozwiązania wymagające zakupu licencji od dostawcy posiadającego monopol na danym rynku. Każdy z komponentów składowych systemu będzie mógł być wymieniony na inny, jak również zainstalowany w innym kontenerze o kompatybilnym interfejsie. Dzięki temu rozwiązanie nie będzie zależne od konkretnej biblioteki czy dostawcy. Główne technologie zastosowane w projekcie wymieniono poniżej: Apache HTTPD lub nowszy, Java SE 7, Java EE 6, Java Message Service (JMS) 1.1, WildFly / JBoss AS 7, Liferay 6 lub nowszy, Mule ESB 3.4 lub nowsza, JBoss Inifinispan 5.3 lub nowszy, Spring 3.2 lub nowszy; Z szeregu bibliotek dostarczanych przez Spring platforma korzystać będzie z następujących: o Spring Core biblioteka dostarczająca funkcjonalności kontenera IoC oraz pomocniczych takich ja walidacja, wsparcie dla tworzenia testów jednostkowych o Spring Portlet MVC biblioteka do tworzenia graficznego interfejsu użytkownika GUI o Spring Security biblioteka dostarczająca funkcjonalności związane z bezpieczeństwem o Spring Mobile biblioteka wspierająca tworzenie rozwiązań na urządzenia mobilne, Activiti, Java FX, Microsoft SQL Server 2012, JDBC 4 wraz z JPA 2. Skalowalność jako elastyczność rozbudowy integracji B2B: Dzięki zastosowaniu powyższych technologii powstanie platforma aplikacyjna pozwalająca na szybkie i łatwe dodawanie nowych modułów, a dzięki temu szybkie reagowanie na zmiany na rynku ubezpieczeń. Jest to szczególnie ważne, z uwagi na coraz bardziej zaawansowane systemy stosowanie po stronie ubezpieczycieli, tworzone nie tylko przez polskie, ale również zagraniczne firmy. Systemy te jako kluczowy aspekt architektury przedstawiają właśnie możliwość szybkiego dostosowania do zmian rynkowych. EKU Sp. z o.o. będzie musiała więc nadążyć za zmianami w tych systemach. Integracja z partnerami EKU Sp. z o.o. będzie możliwa z wykorzystaniem szerokiego zbioru protokołów, możliwe będzie również dopisanie nowych implementacji w razie potrzeby. Protokoły wspierane od razu przez platformę to: Strona 12 z 17

13 HTTP HTTPS FTP SFTP JDBC (integracja przez bazę danych) SMPT SMPTS IMAP JMS LDAP POP3 POP3S. Dzięki wydzieleniu logiki integracyjnej do osobnego modułu będzie możliwe uzyskanie lepszej, bardziej skalowalnej i niezawodnej architektury, a jednocześnie pozwoli uzyskać większe możliwości zarządzania, np. sterowania przepustowością. Moduł będzie wysoko dostępny, awaria jednego węzła będzie skutkować niedostępnością systemu dla partnerów EKU Sp. z o.o. Moduł będzie posiadał również wyższą kohezję i możliwości ponownego użycia komponentów, jako rozwiązanie opracowanie specyficznie w celu integracji. Moduł integracyjny zaimplementowany będzie w oparciu o Mule ESB, sprawdzoną i popularną magistralę usług. Formaty wymiany danych będą mogły być dostosowane do wymagań partnerów EKU Sp. z o.o., w szczególności będą mogły to być: EDIFACT SOAP 1.1 SOAP 1.2 JSON XML Usługi będą mogły być ponownie wykorzystane nie tylko w kolejnych procesach biznesowych, ale i dla kolejnych partnerów EKU Sp. z o.o., którzy wyrażą chęć integracji. Moduły procesowe zainstalowane na platformie będą wywoływać usługi modułu integracyjnego, opartego o magistralę usług. Moduł ten w zależności od adresata komunikatu wykona odpowiednie przetwarzanie, w szczególności: Do partnera A może wysłać komunikat w formacie EDIFACT Do partnera B może wysłać komunikat w formacie SOAP 1.2 Dzięki powyższym możliwościom technicznym modułu, dodanie kolejnej integracji B2B będzie wymagało utworzenia jedynie kilku elementów na magistrali usług. Skalowalność: System oparty o platformę aplikacyjną będzie skalowany zarówno pionowo jak i poziomo. Skalowanie pionowe będzie możliwe dzięki zastosowaniu nowych rozwiązań w zakresie zarządzania pamięcią, czyli Strona 13 z 17

14 JBoss Inifinispan oraz G1 Garbage Collector, oraz odpowiedniej budowie aplikacji. Skalowanie poziome będzie możliwe poprzez zastosowanie klastra serwerów JBoss AS 7 z których każdy będzie aktywny oraz rozdzielania ruchu pomiędzy serwery w klastrze z wykorzystaniem sprzętowego urządzenia do równoważenia obciążenia (load balancer). Zastosowany zostanie algorytm równoważenia ruchu wykorzystujący mechanizm Sticky Session, dzięki czemu żądania pochodzące z przeglądarki użytkownika przekierowane na wybrany węzeł, będą przekierowywane na ten węzeł. Dzięki modułowej budowie oraz architekturze warstwowej możliwa będzie budowa klastra heterogenicznego usługowo, tzn. możliwe będzie zainstalowanie modułów bardziej obciążonych na większej liczbie serwerów, podczas gdy moduły mniej obciążone będą zainstalowane na mniejszej liczbie serwerów. Zastosowanie komunikacji zdarzeniowej pomiędzy modułami pozwala na jeszcze większe uniezależnienie modułów i podniesienie skalowalności i niezawodności rozwiązania. Komunikacja zdarzeniowa będzie asynchroniczna, dostarczenie komunikatu będzie mogło być gwarantowane. Komunikaty będą mogły być dostarczane do jednego odbiorcy, jak również rozgłaszane (dostarczane do wielu odbiorców). Technologie podpisu elektronicznego lub elektronicznej wymiany danych, eliminacja papierowego obiegu dokumentacji: W ramach projektu szeroko wykorzystywana będzie technologia podpisu elektronicznego oraz elektronicznej wymiany dokumentów. Technologia elektronicznej wymiany dokumentów wykorzystywana będzie w celu integracji z partnerami biznesowymi wskazanymi przez EKU Sp. z o.o. Wykorzystywane technologie i formaty wymiany danych będą ustandaryzowane. Wymiana komunikatów pomiędzy EKU Sp. z o.o. a partnerami będzie odbywać się w oparciu o standard XML lub SOAP. Wszystkie dokumenty wychodzące z systemu w ramach integracji B2B będą podpisane elektroniczne z wykorzystaniem ogólnie przyjętego standardu np. XML Digital Signature i certyfikatu kwalifikowanego. Podpis ten uniemożliwi nie zauważalne z punktu widzenia partnera zmodyfikowanie dokumentu. Wybór zastosowania formatu elektronicznej wymiany danych pomiędzy XML, SOAP lub EDIFACT będzie zależny od możliwości partnera EKU Sp. z o.o. System będzie wpierał podpisywanie dokumentów w każdym z wymienionych formatów. Dzięki temu możliwe będzie zintegrowanie systemu z wieloma partnerami biznesowymi. Wykorzystanie magistrali usług pozwoli nawet na transformację komunikatu do formatu zrozumiałego dla danego partnera już na magistrali, dzięki czemu system będzie mógł integrować się i wysyłać komunikaty do wielu partnerów wykorzystując tą samą usługę. Dzięki opisanej powyżej elastyczności i technologiom system będzie bardzo skalowany. Usługi będą mogły być ponownie wykorzystane nie tylko w kolejnych procesach biznesowych, ale i dla kolejnych partnerów EKU Sp. z o.o., którzy wyrażą chęć integracji. Moduły procesowe zainstalowane na platformie będą wywoływać usługi modułu integracyjnego, opartego o magistralę usług. Moduł ten w zależności od Strona 14 z 17

15 adresata komunikatu wykona odpowiednie przetwarzanie, w szczególności: Do partnera A może wysłać komunikat w formacie EDIFACT Do partnera B może wysłać komunikat w formacie SOAP 1.2 Wdrożenie elektronicznego obiegu dokumentów w bardzo dużym stopniu wyeliminuje konieczność obiegu dokumentacji w formie papierowej. Nie tylko możliwe będzie w niektórych przypadkach całkowite zaprzestanie wykorzystania papierowej formy dokumentów w wymianie dokumentów z partnerami EKU Sp. z o.o., ale również całkowite zaprzestanie wykorzystania papierowej formy dokumentów w obiegu wewnętrznym Dotyczy to np. drukowania dokumentów w celu weryfikacji czy papierowych opisów procesów. Jako urządzenie wykorzystywane do podpisywania dokumentów wykorzystywana będzie aplikacja w technologii Java FX uruchamiana na komputerze użytkownika lub dedykowane urządzenie dostarczone wraz certyfikatem. Certyfikaty nie będą więc przechowywane na serwerach EKU Sp. z o.o., ale na komputerze użytkownika który to komputer będzie znajdował się pod wyłączną kontrolą użytkownika. Ww. technologie znajdą zastosowanie w następujących procesach: 1. Proces obiegu dokumentów dotyczących przystąpienia do ubezpieczenia grupowego 2. Proces obiegu dokumentów dotyczących zmiany 3. Proces aktualizacji danych 4. Proces obiegu dokumentów raportowych 5. Proces wysłania aneksów do umów i faktur 6. Proces rozliczania prowizji i składek Usługi elektroniczne automatycznego przetwarzania danych lub w formule Software-as-a-Service: System utworzony w ramach projektu będzie udostępniał usługi dla partnerów EKU Sp. z o.o. Usługi będą umożliwiały zarządzanie przez partnerów produktami, które zostaną zakupione za pośrednictwem EKU Sp. z o.o. Usługi będą udostępnione poprzez sieć Internet i możliwe do wykorzystania na dwa sposoby: 1) Poprzez dostęp z wykorzystaniem przeglądarki internetowej bezpośrednio do aplikacji zainstalowanej na serwerze EKU Sp. z o.o. 2) Poprzez zainstalowanie specjalnego programu klienckiego zgodnego z protokołem WSRP, umożliwiającego osadzenie portletów udostępnianych, jako usług zdalne przez system EKU Sp. z o.o. Drugie z rozwiązań jest nowatorskie i bardzo zaawansowane technicznie. Dostęp do portletu odbywa się z wykorzystaniem protokołu SOAP, a przetwarzanie jest faktycznie wykonywane na serwerach EKU Sp. z o.o. Portal partnera biznesowego EKU Sp. z o.o. pobiera dane przekazywane przez portlet udostępniony przez system EKU Sp. z o.o. oraz przekazuje wszystkie akcje zainicjowane przez użytkownika do portletu również z wykorzystaniem protokołu SOAP. Dzięki takiemu rozwiązaniu portlet dostępny jest zdalnie, ale jest to całkowicie przezroczyste dla użytkownika. Faktem wartym podkreślenia jest to, że udostępniane są nie tylko dane z bazy danych, ale całego interfejsu użytkownika zdefiniowane przez portlet Strona 15 z 17

16 zainstalowany na serwerach EKU Sp. z o.o. Usługi systemu zbudowane w ramach projektu udostępniane będą również w postaci m.in. usług SOAP Web Services. Możliwe będzie udostępnienie usług w postaci XML Web Services, RESTful Web Services, SFTP, SMPT i innych wg potrzeb i standardów partnera EKU Sp. z o.o. Sposób implementacji modułu integracji pozwoli na łatwe dodawanie nowych kanałów dla partnerów. Wydzielenie kanałów integracyjnych dla poszczególnych partnerów pozwoli też na realizację funkcjonalności takich jak: Uwierzytelnianie metodą uzgodnioną z danym partnerem (X.509 Security Token Profile, Twoway SSL, Username Token Profile i inne) Dostosowanie formatu i protokołu do integracji z danym partnerem poprzez odpowiednie transformacje i zastosowanie wewnętrznego formatu i protokołu danych dla systemu Kontrolę dostępu, w tym ewentualne zliczanie liczby wywołań Dostosowanie kanału do wymów integracji z partnerem znacząco ograniczy koszty po stronie partnera i ułatwi wykorzystanie usług udostępnianych przez system EKU Sp. z o.o. Jeżeli partner EKU Sp. z o.o. udostępnia już usługi w określony sposób, wówczas system wnioskodawcy, czyli EKU Sp. z o.o., zintegruje się z systemem partnera z wykorzystaniem protokołu i formatu już obsługiwanego przez partnera. Dodatkowo elektem SaaS będzie wprowadzenie modułu statystycznego z zastosowanie elementów big data (w skali roku są to tysiące ubezpieczonych osób), co znacznie wpłynie na efektywność pracy partnera. Dodatkowo, system EKU Sp. z o.o. dostarczy partnerom dużo dodatkowych informacji w postaci bardzo zaawansowanych statystyk, dotyczących wieku, płci, stanu zdrowia oraz składek ubezpieczonych w przetworzonej formie raportów. Na dzień dzisiejszy partnerzy tworzą takie dokumenty ręcznie, we własnym zakresie. Dodatkowo usługi będą w wysokim stopniu reużywalne. W obrębie modułu integracyjnego zastosowane zostaną zaawansowane mechanizmy transformacji dokumentów XML (wewnętrzny format systemu EKU Sp. z o.o.). Moduł integracyjny będzie mógł również wysyłać zdarzenia, które mogą startować procesy lub być przetwarzanie przez inne komponenty systemu zbudowane w ramach projektu. Zastosowanie tego modelu gwarantować będzie jednocześnie wysoką dostępność i wysoki poziom zabezpieczeń: Bezpieczeństwo: dla bardzo istotnych usług i partnerów możliwe będzie wykorzystanie zaawansowanych metod uwierzytelniania. Metoda uwierzytelniania będzie mogła być dostosowana do wymagań i możliwości systemu partnera. Dostępność: możliwe będzie zastosowanie buforowania komunikatów w module integracyjnym i ukrycie chwilowych niedostępności systemu EKU Sp. z o.o., poprzez zastosowanie buforów w warstwie usług integracyjnych lub warstwie kanałów integracyjnych. Możliwe będzie również utworzenie klastra udostępniającego dodatkowe instalacje modułu integracyjnego dla tej usługi. System będzie rozwiązaniem dedykowanym ale jednocześnie udostępniać będzie moduły usługowe w modelu Software-as-a-Service. W efekcie wykonania projektu zbudowana zostanie więc nie tylko Strona 16 z 17

17 aplikacja, ale również platforma aplikacyjna umożliwiająca uruchamianie nowych modułów i jednocześnie udostępniająca wiele usług dla tych nowych modułów. Od strony technicznej rozwiązanie więc będzie posiadało również pewne cechy rozwiązania Platform-as-a-Service (PaaS). Usługi wykorzystywane jako zdalnie uruchamiane portlety, jak również usługi wywoływane poprzez moduł integracyjny będą wykraczały poza wymianę danych, dostęp do bazy danych, obsługę relacji handlowych lub dostęp do narzędzi koordynujących współpracę między przedsiębiorcami z uwagi na zaawansowane mechanizmy bezpośredniego dostępu do usług na GUI systemu partnera (zastosowanie WSPR Web Services Report Portlets) oraz zaawansowane architektonicznie i technicznie rozwiązania w zakresie integracji (wysoka dostępność, ukrywanie niedostępności, wykorzystanie możliwie najlepszych metod zabezpieczeń). Zatwierdzam. Strona 17 z 17