Pozostałe założenia do wykonania Syriusz Broker

Transkrypt

1 Umowa na opracowanie opisu wymagań funkcjonalnych i technicznych dla SYRIUSZ_BROKER Produkt: Pozostałe założenia do wykonania Syriusz Broker 27 kwietnia 2010 wersja 1.1 Umowa zawarta w ramach projektu współfinansowanego ze środków EFS prowadzonego w ramach Programu Operacyjnego Kapitał Ludzki Implementacja i rozwój systemu informacyjnego publicznych służb zatrudnienia

2 2 Spis treści SPIS TREŚCI... 2 SŁOWNIK... 3 WSTĘP... 6 I ŚCIEŻKA PRZEJŚCIA PRZYJĘTE ZAŁOŻENIA PRACE PRZEPROWADZONE W RAMACH PROJEKTU Etap Analiza Realizacja Testy i naprawa błędów Wdrożenie Etap II Realizacja Testy i naprawa błędów Wdrożenie Rozwój PRODUKTY POSZCZEGÓLNYCH ETAPÓW HARMONOGRAM II WYMAGANIA ODNOŚNIE WYKONAWCÓW III WYMAGANIA (SLA) Dostępność biznesowa systemu Czasy reakcji i naprawy błędów Czasy reakcji i naprawy błędów aplikacji Czasy reakcji i naprawy infrastruktury i administracyjnych Warunki utrzymania IV WARUNKI WSPÓŁPRACY POMIĘDZY WYKONAWCAMI ROLE POSZCZEGÓLNYCH UCZESTNIKÓW PROJEKTU Umowa zawarta w ramach projektu współfinansowanego ze środków EFS prowadzonego w ramach Programu Operacyjnego Kapitał Ludzki Implementacja i rozwój systemu informacyjnego publicznych służb zatrudnienia

3 3 Słownik Aplikacje docelowe (klienckie) - aplikacje wchodzące w skład SI PSZ, będące jednocześnie aplikacjami wysyłającymi i odbierającymi komunikaty PWD. Aplikacje te będą wymieniały informacje za pomocą Systemu Syriusz Broker (SSB), podłączone za pośrednictwem węzła SBPx; Aplikacje dziedzinowe - aplikacje wchodzące w skład SI PSZ, użytkowane bezpośrednio w instytucjach obszaru PSZ w celu realizacji funkcji statutowych w/w instytucji, przykładem tych aplikacji jest Oprogramowanie aplikacyjne Syriusz Std ( Syriusz Std ) oraz aplikacja WUP-Viator; Centralna Baza Użytkowników i Węzłów (dalej: CBUiW) aplikacja stanowiąca komponent Systemu Syriusz Broker, zawierający informacje uwierzytelniające o wszystkich węzłach SB i SBPx; aplikacja ta może także zawierać informacje o użytkownikach SSB; szczegółowy opis CBUiW przedstawiony został w dokumencie Analiza obszaru Syriusz Broker ; Ministerstwo Pracy i Polityki Społecznej (dalej: MPiPS) - urząd obsługujący m.in. ministra właściwego do spraw pracy. Moduł Administracyjno Diagnostyczny (dalej: MAD) aplikacja stanowiąca komponent Systemu Syriusz Broker, dostarczający narzędzia diagnostyczne i pozwalające na realizację usług utrzymania systemu przez jego administratorów; szczegółowy opis MAD przedstawiony został w dokumencie Analiza obszaru Syriusz Broker ; Menadżer słowników (dalej: MS), aplikacja stanowiąca komponent Systemu Syriusz Broker, odpowiedzialny za dystrybucję słowników systemie; szczegółowy opis MS przedstawiony został w dokumencie Analiza obszaru Syriusz Broker ; Obszar Publicznych Służb Zatrudnienia (dalej: obszar PSZ) - obszar tworzą organy zatrudnienia, m.in.: powiatowe i wojewódzkie urzędy pracy, urząd obsługujący ministra właściwego do spraw pracy oraz urzędy wojewódzkie, realizujące zadania określone ustawą z dnia 20 kwietnia 2004 r. o promocji zatrudnienia i instytucjach rynku pracy (art. 6, ust. 2); funkcjonowanie obszaru PSZ wspiera SI PSZ; Obszar zabezpieczenia społecznego (dalej: obszar ZS) obszar tworzą instytucje, których zadania skupiają się na pomocy osobom w trudnej sytuacji materialnej i społecznej; zakres funkcjonowania tego obszaru określają następujące ustawy: o ustawa z 12 marca 2004 r. o pomocy społecznej (Dz. U z 2 lipca 2008 r. Nr 115 poz. 728 z późniejszymi zmianami), o ustawa z dnia 28 listopada 2003 r. o świadczeniach rodzinnych (Dz. U. Nr 228, poz z późniejszymi zmianami), o ustawa z dnia 7 września 2007 r. o pomocy osobom uprawnionym do alimentów (Dz. U. Nr 192, poz z późniejszymi zmianami);

4 4 PSZ publiczne służby zatrudnienia; SLA (ang. Service Level Agreement) - umowa określająca warunki utrzymania i poprawy jakości realizowanego przez wykonawcę systemu informatycznego lub usługi, w ramach której pomiędzy stronami umowy zostaje uzgodniony poziom oczekiwanej jakości pracy systemu, mierzony poprzez maksymalną nieplanowaną niedostępność serwisu w danym okresie czasu oraz poprzez maksymalne czasy naprawy znalezionych w serwisie błędów. SOA (ang. Service-Oriented Architecture) - koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika; mianem usługi określa się tu każdy element oprogramowania, mogący działać niezależnie od innych oraz posiadający zdefiniowany interfejs, za pomocą którego udostępnia realizowane funkcje; System Syriusz Broker (dalej: SSB) - jest to system definiujący warstwę integracyjną w obszarze PSZ. Integracja zachodzi na dwóch płaszczyznach, tj. komunikacyjnej (wyznaczonej przez sieć węzłów SB i SBPx), i biznesowej, definiującej środowisko do tworzenie i wykonywania procesów biznesowych; Syriusz_Broker (dalej: SB) - węzeł mający za zadanie przesyłanie komunikatów pochodzących od węzłów SBPx do innych węzłów SBPx oraz SB. SB z punktu widzenia komunikacyjnego stanowi router nawigujący komunikaty między podłączonymi systemami; w systemie może występować jeden lub więcej połączonych ze sobą węzłów SB; w tej sytuacji poszczególne SB są również odpowiedzialne za znajdowanie drogi dla komunikatów z systemów podłączonych do różnych węzłów SB; Syriusz Broker Proxy (SBPx) - węzeł pośredniczący w komunikacji pomiędzy aplikacją docelową, a węzłem SB; głównym zadaniem Syriusz Broker Proxy jest zapewnienie komunikacji z jednym z węzłów SB, poprzez przekazywanie komunikatów z i do tego węzła; SBPx Adapter adapter stanowi część SBPx-a, budowaną na bazie dobrze udokumentowanego API; jest on tworzony, jako łącznik z aplikacją kliencką. W zależności od potrzeb istnieje możliwość stworzenia różnych adapterów do różnych systemów docelowych; Systemy Centralne aplikacje obszaru PSZ, dla których infrastruktura aplikacyjno-sprzętowa nie jest instalowana ani w powiatowym ani wojewódzkim urzędem pracy. Są to wszystkie te aplikacje, które istnieją tylko jako jedna instancja w całym obszarze praca. Przykładami takich aplikacji są: Aplikacja Centralna (dalej: AC), Krajowy System Monitoringu Rynku Pracy (dalej: KSMRP), Centralna Baza Ofert Pracy (dalej: CBOP), Rejestr Instytucji Szkoleniowych (dalej: RIS), Administracja SI SYRIUSZ, Krajowy Rejestr Agencji Zatrudnienia (dalej: KRAZ); System informacyjny publicznych służb zatrudnienia (dalej: SI PSZ) tworzą systemy informatyczne, oprogramowanie aplikacyjne oraz rejestry wspomagające funkcjonowanie obszaru PSZ; SI PSZ składa się z aplikacji dziedzinowych i systemów centralnych; inne kryterium kwalifikacji aplikacji

5 5 SI PSZ bazuje na wymianie i przetwarzaniu informacji na tej podstawie wyróżnia się aplikacje zasilające i zasilane; System typu Enterprise system oferujący wysoki poziom obsługi (usług), działający na dużych wolumenach danych, wspierający działalność dużych jednostek i organizacji; system typu Enterprise dostarcza technologię, która pozwala organizacjom integrować oraz koordynować ich procesy biznesowe.

6 6 Wstęp Niniejszy dokument przedstawia pozostałe wymagania, warunkujące wykonanie Systemu Syriusz Broker, tzn. ścieżkę przejścia, wymagania odnośnie wykonawców, wymagania SLA oraz warunki współpracy pomiędzy wykonawcami.

7 7 I Ścieżka przejścia Przedstawiona poniżej ścieżka obrazuje ewolucyjny model przejścia pomiędzy obecnie istniejącymi systemami a Systemem Syriusz Broker. Niniejszy rozdział prezentuje listę zadań i produkty poszczególnych prac, które doprowadzą do wdrożenia Systemu Syriusz Broker. 1. Przyjęte założenia Podstawowym warunkiem, mającym decydujący wpływ na kolejność zadań i cele wyznaczone w ramach każdego z nich, jest konieczność zapewnienia ciągłości zasilania systemów centralnych przez aplikacje dziedzinowe, co wiąże się bezpośrednio z nieprzerwanym funkcjonowaniem warstwy, odpowiedzialnej za komunikację w obszarze PSZ. Ponadto, wymagane jest także, aby na początku 2011 roku System Syriusz Broker realizował funkcjonalność na poziomie co najmniej równoważnym do aktualnie wykorzystywanego PWD. W celu sprostania tym wymogom przyjęte zostało założenie, iż projekt realizacji i wdrożenia Systemu Syriusz Broker wraz z komponentami powinien zostać zrealizowany w dwóch etapach, z których pierwszy zakończy się wdrożeniem, nieograniczającym funkcjonalności systemu w stosunku do jego obecnego kształtu, a drugi stanowić będzie jego uzupełnienie do pełnej planowanej funkcjonalności. Wdrożenia te dodatkowo będą różniły się między sobą zasięgiem terytorialnym, tzn. liczbą jednostek, które zostaną połączone z systemem komunikacyjnym. Jak pokazały przeprowadzone analizy, specyfika produktu, który ma powstać w rzeczywistości narzuca na wykonawcę konieczność zrealizowania i wdrożenia już w ramach pierwszego etapu pełnej funkcjonalności planowanego Systemu Syriusz Broker. Nie jest wymagane i wskazane natomiast, aby etap ten objął prace dostosowawcze wszystkich systemów centralnych, a co za tym idzie i podłączenie ich w ramach wdrożenia pilotażowego do SSB. W celu zapewnienia ciągłości funkcjonowania systemu podczas wdrożenia kończącego pierwszy etap prac (a także we wstępnej fazie Etapu II) wymagane jest, aby jednocześnie funkcjonowały oba systemy komunikacyjne PWD i SSB. Dzięki temu, z jednej strony jednostki nieobjęte wdrożeniem pilotażowym nie zostaną pozbawione środków komunikacji, a z drugiej, dotychczasowy system stanowił będzie zabezpieczenie dla urzędów uczestniczących w pilotażu w razie wystąpienia jakichkolwiek problemów z nowymi aplikacjami. Poniżej przedstawione zostały zadania, które muszą zostać zrealizowane w ramach każdego z etapów. Warto zauważyć, że w wyniku takiego podziału prac projektowych zakres funkcjonalność nowego systemu komunikacyjnego już na wstępie znacznie przekroczy poziom funkcjonalności wykorzystywanego do tej pory PWD. Przy czym, spełnienie warunku równoważności systemów komunikacyjnych jest uwarunkowane nie tylko wykonaniem samego Systemu Syriusz Broker, ale także wszystkich niezbędnych prac dostosowawczych w aplikacjach, które mają z nim zostać docelowo połączone.

8 8 Poprzez dostosowanie aplikacji dziedzinowych rozumie się wymianę fragmentu kodu zapewniającego komunikację z innymi systemami. W chwili obecnej zapewnienie komunikacji polega na tworzeniu i odczycie plików z odpowiednich katalogów. Dostosowanie aplikacji polega na wymianie tego mechanizmu i zastąpieniem go wywoływaniem odpowiednich metod z API SBPx (dołączonego, jako biblioteki). Zmiany te nie mają wpływu na wykonywane przez te aplikacje funkcje. Zmiany dostosowawcze powinny być wykonane przez twórców tych aplikacji. 2. Prace przeprowadzone w ramach projektu. Zgodnie z przyjętymi założeniami projekt realizacji i wdrożenia Systemu Syriusz Broker wraz z komponentami podzielony został na dwa etapy, w ramach których prace realizowane powinny być fazowo. Na potrzeby zobrazowania niniejszej ścieżki przejścia przyjęto, że etap składać się będzie z następujących faz: Analiza (tylko etap I); Realizacja; Testy i naprawa błędów; Wdrożenie. 2.1 Etap 1 Etap pierwszy powinien zakończyć się wdrożeniem pilotażowym zrealizowanych elementów systemu Analiza Analiza wykonana w etapie pierwszym powinna objąć wszystkie prace, które zostaną wykonane w ramach obu etapów. Dodatkowo, w tej fazie powinna powstać szczegółowa dokumentacja dla SBPx API Realizacja W pierwszym etapie muszą zostać zrealizowane wymienione poniżej elementy SSB. SB i SBPx; Edytor procesów biznesowych; Komponenty CBUiW, MAD, MS; Zdefiniowanie podstawowych procesów biznesowych; Integracja lub dostosowanie AC, jako komponentu SSB; Wykonanie PWD Bridge i modyfikacji PWD. W ramach tych prac przeprowadzone zostaną także testy i poprawione zostaną błędy.

9 9 Dodatkowo konieczne jest zrealizowanie następujących zmian w systemach obszaru PSZ: Dostosowanie aplikacji Syriusz Standard do współpracy z SSB. Stworzenie adaptera plikowego dla aplikacji WUP Viator do współpracy z SSB. Szczegółowy opis koniecznych do wykonania prac zawarty został w dokumencie Założenia funkcjonalne i techniczne Syriusz Broker Testy i naprawa błędów Po zakończeniu etapu wykonania oprogramowania należy wykonać następujące testy: Testy integracyjne służące do weryfikacji działania Systemu Syriusz Broker oraz komponentów i aplikacji z nim współpracujących. Testy akceptacyjne inaczej odbiorcze, służące do sprawdzenia stanu faktycznego systemu w stosunku do specyfikacji funkcjonalno-technicznej. Jeśli testy przebiegną pomyślnie, możliwe będzie przejście do fazy wdrożenia Wdrożenie Celem wdrożenia pilotażowego jest dokonanie oceny merytorycznej wdrażanego systemu, a tym samym stwierdzenie, że we wdrożonym systemie i jego komponentach nie występują błędy uniemożliwiające jego wykorzystywanie, lub ograniczające wykonywanie zadań w jednostkach objętych wdrożeniem. Wdrożenie pilotażowe powinno objąć: 1) Uruchomienie Systemu Syriusz Broker wraz z komponentami, połączonego minimum z jednym wybranym systemem centralnym (zalecane jest, aby była to Aplikacja Centralna). 2) Podłączenie do systemu trzech Powiatowych Urzędów Pracy i jednego Wojewódzkiego Urzędu Pracy. Urzędy powinny stanowić reprezentatywną grupę pod względem wielkości. 3) Uruchomienie elementów, które umożliwią jednoczesne funkcjonowanie Systemu Syriusz Broker i dotychczasowego Podsystemu Wymiany Danych. Na wdrożenie składać się powinny następujące działania: 1) Uruchomienie węzła SB wraz z AC i komponentami, MS, CBUiW, MAD. 2) Uruchomienie "PWD Bridge". 3) Wdrożenie dostosowanej aplikacji Syriusz STD w 3 Powiatowych Urzędach Pracy. 4) Wdrożenie adaptera WUP Viator w jednym Wojewódzkim Urzędzie Pracy.

10 10 5) Monitoring oraz poprawa wykrytych błędów. 2.2 Etap II W ramach etapu drugiego powinny zostać wykonane wszystkie adaptery, umożliwiające połączenie pozostałych systemów centralnych z SSB. W wyniku wdrożenia SSB powinien objąć wszystkie urzędy pracy Realizacja W drugim etapie muszą zostać wykonane następujące elementy: 1) Adapter CBOP; 2) Adapter KSMRP; 3) Adapter Pesel; 4) Adapter Eures; 5) Adapter RIS; 6) Adapter EESSI; Dodatkowo konieczne jest: 1) Zdefiniowanie usług Eures i ich implementacja oraz dodanie wymaganych procesów; 2) Zdefiniowanie usług PESEL i ich implementacja przeniesienie dotychczasowego kodu z AC i zrobienie usług (zadanie będzie realizowane tylko w przypadku uruchomienia rejestru PESEL2); 3) Zmiany w AC aby korzystał z PESEL w usługach dodanie wywołania usług (zadanie będzie realizowane tylko w przypadku uruchomienia rejestru PESEL2); 4) Zdefiniowanie usług RIS i ich implementacja oraz dodanie wymaganych procesów; 5) Zdefiniowanie usług EESSI i ich implementacja oraz dodanie procesów obsługujących komunikaty z EESSI; 6) ASI Syriusz - zmiany do współpracy z MS; 7) Wykonanie zmian w ASI Syriusz, które umożliwią jego współpracę z MS; 8) Stworzenie procesu biznesowego wysyłającego oferty pracy do systemu Eures. Szczegółowy opis koniecznych do wykonania prac zawarty został w dokumencie Założenia funkcjonalne i techniczne Syriusz Broker.

11 Testy i naprawa błędów Po zakończeniu etapu wykonania oprogramowania należy wykonać następujące testy: Testy integracyjne służące do weryfikacji działania Systemu Syriusz Broker oraz komponentów i aplikacji z nim współpracujących. Testy akceptacyjne inaczej odbiorcze, służące do sprawdzenia stanu faktycznego systemu w stosunku do specyfikacji funkcjonalno-technicznej Wdrożenie W etapie tym wdrożenie musi objąć wszystkie Powiatowe i Wojewódzkie Urzędy Pracy. SSB natomiast powinien zostać połączony ze pozostałymi systemami centralnymi. W ramach etapu II powinny zostać wykonane następujące prace: 1) Uruchomienie zapasowego węzła SB. 2) Uruchomienie zapasowego CBUiW. 3) Podłączenie bazy PESEL do SSB (takie rozwiązanie będzie możliwe tylko w przypadku uruchomienia rejestru PESEL2) 4) Podłączenie RIS do SSB. 5) Podłączenie EESSI do SSB. 6) KSMRP podłączenie do SSB (adapter SQL). 7) CBOP podłączenie do SSB (adapter SQL). 8) Viator podłączenia do SSB 9) Odłączenie usługi wysyłającej oferty pracy z CBOP do Eures i jej przełączenie do SSB. Po wstępnym okresie przejściowym, w którym oba systemy komunikacyjne SI PSZ będą funkcjonowały jednocześnie, możliwe będzie usunięcie PWD Centralnego, oraz PWD Bridge. 2.3 Rozwój Po zakończeniu wymienionych powyżej etapów wdrożenia, udostępnione zostaną pełny zakres komunikacyjny SSB, dający wykonawcom poszczególnych aplikacji szerokie możliwości w realizacji zmian funkcjonalnych w istniejących aplikacjach.

12 12 3. Produkty poszczególnych etapów Nazwa etapu i zakres prac do wykonania Produkty Etap I Analiza techniczna i funkcjonalna: Zapoznanie się z dokumentacją opisu wymagań funkcjonalnych i technicznych Syriusz Broker. Przeprowadzenie analizy technicznej i funkcjonalnej istniejących systemów. Specyfikacja techniczna Systemu Syriusz Broker i komponentów; Dokumentacja API SBPx; Dokumentacja techniczna SSB. Przygotowanie dokumentacji technicznej: API SBPx; Systemu Syriusz Broker. Realizacja Systemu Syriusz Broker, w tym: SB, SBPx; Edytor procesów biznesowych; System Syriusz Broker wraz komponentami; PWD Bridge. Komponenty (CBUiW, MS, MAD); PWD Bridge. Integracja lub dostosowanie AC, jako komponentu SSB Realizacja zmian zapewniających komunikację z systemami docelowymi: Dostosowanie aplikacji Syriusz Standard; Dostosowana Aplikacja Centralna Dostosowana aplikacja Syriusz Standard; Adapter plikowy. Adapter plikowy dla WUP Viator. Testy i naprawa błędów. Wdrożenie pilotażowe. Zaimplementowane poprawki. System Syriusz Broker w połączony z wybranymi aplikacjami i systemami centralnymi obszaru (zalecane AC). Etap II Umowa zawarta w ramach projektu współfinansowanego ze środków EFS prowadzonego w ramach Programu Operacyjnego Kapitał Ludzki Implementacja i rozwój systemu informacyjnego publicznych służb zatrudnienia

13 13 Nazwa etapu i zakres prac do wykonania Adapter KSMRP; Adapter CBOP; Produkty Przygotowane pozostałe adaptery. Adapter Pesel; Adapter Eures; Zdefiniowanie usług Eures i ich implementacja oraz dodanie wymaganych procesów zdefiniowanie usług PESEL i ich implementacja przeniesienie dotychczasowego kodu z AC i zrobienie usług (zadanie będzie realizowane tylko w przypadku uruchomienia rejestru PESEL2); Zmiany w AC, aby korzystała z PESEL w usługach dodanie wywołania usług (zadanie będzie realizowane tylko w przypadku uruchomienia rejestru PESEL2); Adapter RIS; zdefiniowanie usług RIS i ich implementacja oraz dodanie wymaganych procesów; Adapter EESSI; Zdefiniowanie usług EESSI i ich implementacja oraz dodanie procesów obsługujących komunikaty z EESSI. Testy i naprawa błędów. Wdrożenie. Zaimplementowane poprawki System Syriusz Broker wdrożony we wszystkich WUP i PUP.

14 14 4. Harmonogram

15 15 II Wymagania odnośnie wykonawców Przyszli wykonawcy systemu Syriusz Broker powinni posiadać niezbędną wiedzę oraz doświadczenie w zakresie prac podobnych do przedmiotu zamówienia. Powinni również dysponować potencjałem technicznym oraz osobami zdolnymi do wykonania zamówienia lub przedstawią pisemne zobowiązanie innych podmiotów do udostępnienia potencjału technicznego i osób zdolnych do wykonania zamówienia. W ramach usług wykonania, wdrożenia oraz eksploatacji wykonawca zobowiązany jest do prowadzenia kontroli poprawności oraz kompletności prac realizowanych przez innych wykonawców. W ramach usługi wdrożeniowej wykonawca zobowiązany jest do udzielenia wsparcia kadrze informatycznej w urzędach pracy w zakresie dostosowania do nowej specyfiki pracy związanej z nowym systemem Syriusz Broker. W ramach usługi eksploatacji wykonawca zobowiązany jest do prowadzenia nadzoru technicznego nad infrastrukturą obejmującą m.in. monitoring systemu Syriusz Broker, umożliwiający szybką reakcje na błędy oraz nieprawidłowości działania. Ponadto o udzielenie zamówienia mogą ubiegać się wykonawcy, którzy: w okresie ostatnich 3 lat przed dniem wszczęcia postępowania wykonali należycie: o minimum jedno wdrożenie rozwiązania klasy Enterprise w administracji publicznej za minimum PLN brutto. o minimum dwa wdrożenia systemów informatycznych zbudowanych w technologii wielowarstwowej wraz z integracją z kluczowymi systemami posiadanymi przez Klienta o wartości minimum PLN brutto; o minimum jedną usługę wykonania (lub rozwoju) i utrzymania systemu informatycznego zbudowanego w technologii wielowarstwowej za minimum PLN brutto;

16 16 dysponują lub będą dysponowali zespołem składającym się z minimum: o Kierownik projektu minimum 8 lat doświadczenia w kierowaniu projektami informatycznymi. Certyfikat Prince 2 Practitioner lub równoważny. Udział w przynamniej jednym projekcie w charakterze kierownika projektów i w przynajmniej jednym projekcie wdrożenia systemu informatycznego zbudowanych w technologii wielowarstwowej wraz z integracją z kluczowymi systemami posiadanymi przez Klienta o wartości min PLN brutto. Wykształcenie wyższe. o Analityk minimum 3 lata doświadczenia w pełnieniu funkcji analityka, w co najmniej 3 projektach, odpowiedzialnego za: przeprowadzanie analiz procesów biznesowych dla potrzeb projektowania systemów informatycznych, analizę oraz weryfikację dokumentów i produktów związanych z procesem budowy, wdrożenia oraz rozwoju systemów informatycznych, o Architekt - posiada minimum 6 lat doświadczenia w zakresie projektowania systemów informatycznych. Posiada certyfikaty projektanta rozwiązań SOA wydany przez producenta rozwiązań SOA i TOGAF lub równoważny. Udział w przynamniej jednym projekcie w charakterze architekta wdrożenia systemu informatycznego zbudowanych w technologii wielowarstwowej wraz z integracją z kluczowymi systemami posiadanymi przez klienta o wartości min PLN brutto. o Programista - do wykonania systemu Syriusz Broker powinni zostać zaangażowani programiści mający minimum 5 letnie doświadczenie w tworzeniu systemów typu Enterprise; o Tester minimum 4 lata doświadczenia w zakresie testowania systemów informatycznych. Certyfikaty ISTQB lub równoważny. Udział w przynamniej jednym projekcie w charakterze testera wdrożenia systemu informatycznego zbudowanych w technologii wielowarstwowej wraz z integracją z kluczowymi systemami posiadanymi przez klienta o wartości min PLN brutto. Znajdują się w sytuacji ekonomicznej i finansowej zapewniającej wykonanie zamówienia, w tym posiadają środki lub zdolność kredytową na kwotę co najmniej równą kwocie ,00 zł.

17 17 W celu potwierdzenia, że oferowane usługi odpowiadają wymaganiom określonym przez zamawiającego, zamawiający wymaga, aby wykonawca posiadał wdrożony system zarządzania jakością zgodny z normą PN-ISO 9001 lub normą równoważną w zakresie realizacji lub wsparcia systemów informatycznych.

18 18 III Wymagania (SLA) Przedstawione w niniejszym rozdziale wymagania SLA (ang. Service Level Agreement) określają warunki utrzymania i poprawy jakości realizowanego przez wykonawcę systemu. W szczególności dotyczą one: Dostępności usług; Czasów reakcji na zgłoszenia awarii aplikacji lub infrastruktury; Czasów czynności diagnostycznych i usunięcia awarii aplikacji lub infrastruktury; Pozostałych warunków utrzymania. 1.1 Dostępność biznesowa systemu Biorąc pod uwagę założenie, iż informacje gromadzone przez urzędy mogą w przyszłości za pośrednictwem SSB być udostępniane innym instytucjom (np. Policji), zaleca się, aby system funkcjonował w trybie 7 dni w tygodniu, przez 24h na dobę. W tym czasie dopuszczalne jest realizowanie planowych przerw w funkcjonowaniu systemu, przewidzianych na wszelkie prace konserwacyjne lub aktualizacyjne. Czynności te jednak powinny być wykonywane w czasie, w którym Powiatowe i Wojewódzkie Urzędy pracy nie funkcjonują, np. w weekendy lub w dni robocze po godzinach pracy tych urzędów (z uwzględnionym marginesem 1 godziny przed rozpoczęciem i po zakończeniu działania urzędów). Dostępność procentowa aplikacji w skali roku (tzn. jej rzeczywista dostępność, do której zaliczane są też planowe przerwy) nie powinna być niższa niż 99,8%. 1.2 Czasy reakcji i naprawy błędów Czasy reakcji na błędy różnicowane powinny być w zależności od tego, jak duży wpływ mają na funkcjonowanie całości Systemu Syriusz Broker. Biorąc pod uwagę to kryterium, wszystkie awarie i błędy mające miejsce w SSB możemy podzielić na następujące kategorie: Błędy krytyczne błędy uniemożliwiające całkowicie pracę lub realizację najważniejszych funkcji systemu, mające wpływ na powstanie awarii w innych powiązanych systemach, oraz uniemożliwiające zastosowanie rozwiązania tymczasowego dla ich niwelacji. W przypadku Systemu Syriusz Broker, do grupy krytycznych zaliczać się powinny te nieprawidłowości, które poprzez problemy komunikacyjne uniemożliwiają pracę wszystkich aplikacji dziedzinowych urzędów i aplikacji centralnych. W grupie tej znaleźć się powinny awarie, które powodują niedostępność usług realizowanych przez węzły SB i komponent CBUiW, a także błędy w tych procesach biznesowych, które warunkują tą komunikacje. Błędy znaczące błędy uniemożliwiające realizację ważnych funkcji systemu, mimo istniejących rozwiązań tymczasowych pozwalających zniwelować skutki

19 19 błędu, utrudniające pracę użytkowników (np. udostępnienie przez system nieprawidłowych danych, nieprawidłowego ich widoku czy wydruku). Błędami znaczącymi Systemu Syriusz Broker będą błędy w komponentach MS czy AC, a także w procesach biznesowych nieodpowiadających za komunikację, które doprowadzą np. do nieprawidłowości danych wykorzystywanych przez instytucje. Błędy nieznaczące błędy uniemożliwiające realizację mniej istotnych funkcji systemu (tzn. niewpływających na wynik podstawowych operacji), stanowiące utrudnienia dla użytkowników, ale nieuniemożliwiające ich pracy. Błędami nieznaczącymi mogą być błędy komponentu MAD, czy błędy pojedynczego węzła dla aplikacji dziedzinowej. Pod pojęciem usunięcia błędu powinna być rozumiana taka poprawa funkcjonowania danego elementu systemu, która doprowadzi do stanu zgodnego z informacjami przedstawionymi w jego specyfikacji funkcjonalnej i technicznej. Lista błędów powinna zostać zdefiniowana na etapie przygotowania dokumentacji funkcjonalnej i technicznej systemu Czasy reakcji i naprawy błędów aplikacji Usługa, obejmująca reakcję na zgłoszenie i naprawę awarii powinna być dostępna w dni powszednie co najmniej w godzinach pracy Urzędów. Lp Usługa 1 Reakcja na awarię: krytyczną znaczącą nieznaczącą 2 Czynności diagnostyczne dla awarii: krytycznej znaczącej nieznaczącej 3 Czas usunięcia awarii: krytycznej znaczącej nieznaczącej Czas reakcji (od momentu zgłoszenia awarii) 2 h 4 h kolejny dzień roboczy 5 h 10 h 3 dni robocze 8 h 24 h 12 dni roboczych

20 Czasy reakcji i naprawy infrastruktury i administracyjnych Usługa, obejmująca reakcję na zgłoszenie i naprawę awarii powinna być dostępna 24h na dobę, przez 7 dni w tygodniu. Lp. Usługa Czas reakcji (od momentu zgłoszenia awarii) 1 Reakcja na awarię: krytyczną znaczącą nieznaczącą 2 Czynności diagnostyczne dla awarii: krytycznej znaczącej nieznaczącej 3 Usunięcie awarii: krytycznej znaczącej nieznaczącej 1 h 2 h kolejny dzień roboczy 2 h 4 h 2 dni robocze 8 h 16 h 9 dni roboczych 1.3 Warunki utrzymania Usługa utrzymania powinna dodatkowo zapewnić: ciągły monitoring pracy systemu; realizację usług zgodnie z jasno określonymi procedurami; możliwość dokonywania zgłoszenia awarii w trybie 24h na dobę przy pomocy dostępnego za pośrednictwem sieci Internet systemu zgłoszeń lub telefonu awaryjnego; realizację usług zgodnie z postanowieniami ustawy o ochronie danych osobowych i rozporządzeń wykonawczych do tej ustawy. utrzymanie poufności informacji i danych.

21 21 IV Warunki współpracy pomiędzy wykonawcami Wykonanie oraz wdrożenie systemu pomiędzy rozproszonymi aplikacjami klienckimi są zadaniami, które w pewnych etapach wymagają ścisłej współpracy pomiędzy wykonawcami systemu. Biorąc pod uwagę planowany czas oraz koszt projektu istotnym dla powodzenia projektu jest zapewnienie efektywnej wymiany informacji oraz dokumentów pomiędzy potencjalnymi wykonawcami systemu Syriusz Broker. Warunkami, które powinny zostać spełnione, są: Wykonawca systemu Syriusz Broker powinien otrzymać od innych wykonawców pełną dokumentację do istniejących systemów docelowych, które będą integrowane. MPiPS przy wsparciu wykonawcy Systemu Syriusz Broker powinien określać wytyczne, terminy oraz oceniać rezultaty wykonanych prac po stronie wykonawców integrowanych aplikacji. Wykonawcy poszczególnych aplikacji powinni realizować prace zgodnie z wytycznymi przekazanymi przez MPiPS przygotowanymi przy wsparciu wykonawcy Systemu Syriusz Broker; Głównym odbiorcą zmian w integrowanych aplikacjach, realizowanych po stronie wszystkich wykonawców jest MPiPS. Każda ze zmian wynikająca z porozumień pomiędzy wykonawcami powinna być konsultowana z MPiPS. Wszystkie finalne akceptacje oraz odbiór poszczególnych etapów projektu powinny być realizowane po stronie MPiPS oraz CRZL. MPiPS powinien pełnić rolę koordynatora projektu, monitorując efekty oraz postęp prac. Wszelkie kwestie sporne (w szczególności dotyczące wymagań biznesowych) powinno rozwiązywać MPiPS. Zalecanym jest, aby (szczególnie na etapie analizy i rozwoju) wykonawcy komunikowali się ze sobą bezpośrednio, a nie poprzez MPiPS (MPiPS powinno być informowane o ustaleniach). Taka forma komunikacji pozwoli na szybsze ustalenie jakie dokładnie usługi oraz dane potrzebne będą innym wykonawcom. Podmioty wykonujące poszczególne komponenty poza Systemem Syriusz Broker będą ze sobą ściśle współpracowały;

22 22 Do wykonania zaangażowani będą programiści mający co najmniej kilkuletnie doświadczenie w tworzeniu systemów typu Enterprise; 1. Role poszczególnych uczestników projektu Poniżej przedstawione zostały role jakie przewidziano na potrzeby realizacji projektu. MPiPS główny odbiorca systemu: podejmuje decyzje o odbiorze poszczególnych faz projektu; podejmuje decyzję w kwestiach spornych pomiędzy wykonawcami; jest odpowiedzialny za wyegzekwowanie od podmiotów trzecich ich zobowiązań do realizacji prac i zadań przewidzianych w zakresie projektu. Zarząd Projektu składa się z przedstawicieli wykonawców oraz zamawiającego, powołany w celu podejmowania decyzji strategicznych dotyczących projektu. Zarząd projektu w szczególności: sprawuje ogólny nadzór nad realizacją projektu; podejmuje decyzje w kluczowych kwestiach dotyczących systemu; opiniuje rozwiązania proponowane przez Zespół Projektowy; zatwierdza zmiany zakresu projektu. Kierownik Projektu ze Strony Zamawiającego do jego obowiązków należą w szczególności: zarządzanie kontaktami pomiędzy Zespołem Projektowym a odpowiednimi komórkami Zamawiającego; wspólnie z Kierownikiem Projektu ze strony wykonawcy zapewnienie właściwej organizacji projektu, jego planowanie oraz monitorowanie postępu prac; koordynacja prac i zadań przewidzianych w zakresie projektu wykonywanych przez wszystkie podmioty i komórki realizujące projekt; zapewnienie właściwego przepływu informacji pomiędzy podmiotami i komórkami zaangażowanymi do realizacji projektu; zapewnienie udostępnienia przez Zamawiającego zasobów niezbędnych dla realizacji projektu; wsparcie merytoryczne i organizacyjne projektu.

23 23 Kierownik Projektu ze strony wykonawcy - odpowiedzialny przed Zamawiającym za wykonywanie prac w projekcie na poziomie operacyjnym. Jest on w szczególności odpowiedzialny za: terminową i prawidłową realizację prac i zadań, planowanie i kontrolę projektu, przydzielanie zadań członkom Zespołu Projektowego Wykonawcy, zarządzanie harmonogramem i budżetem projektu w części należącej do zadań wykonawcy, uzgadnianie i realizację harmonogramu projektu z Zamawiającym, zarządzanie zakresem projektu (uzgadnianie zakresu z Zamawiającym), monitorowanie i zarządzanie ryzykiem projektowym, Kierownik Projektu ze Strony Wykonawcy odpowiada za terminowy przebieg projektu oraz reprezentuje wykonawcę projektu w czasie odbioru prac. Ponadto pełni on funkcję administratora projektu, to znaczy zarządza zmianami zakresu projektu, wykorzystując zdefiniowaną procedurę kontroli zmian. Zespół Projektowy - to grupa pracowników Zamawiającego, przedstawicieli wykonawcy oraz podmiotów trzecich, odpowiedzialna za wykonanie oraz wdrożenie systemu. Zadaniem członków tego zespołu jest prowadzenie prac projektowych, zgodnie z przyjętym harmonogramem. Pracami Zespołu Projektowego kierują bezpośrednio Kierownik Projektu ze Strony Zamawiającego (kieruje pracownikami Zamawiającego, oddelegowanymi do projektu) oraz Kierownik Projektu ze Strony Wykonawcy (kieruje pozostałymi członkami Zespołu Projektowego). Kierownik Projektu Zamawiającego koordynuje prace podmiotów trzecich zaangażowanych do realizacji Projektu. Członkowie Zespołu Projektowego, oddelegowani do niego przez Zamawiającego, opiniują od strony merytorycznej wszystkie powstające produkty projektowe.