Zadanie nr 53: Regionalna platforma komunikacji elektronicznej

Transkrypt

1 Zadanie nr 53: Regionalna platforma komunikacji elektronicznej Lp. Zwartość karty Opis 1 Specyfikacja techniczna / Zakres przedmiotu zamówienia obejmuje dostarczenie i wdrożenie Systemu Regionalna platforma komunikacji funkcjonalna przedmiotu zamówienia elektronicznej na warunkach określonych w niniejszej Karcie produktu oraz na warunkach określonych w Specyfikacji Istotnych Warunków Zamówienia. Regionalna platforma komunikacji elektronicznej musi spełniać następujące wymagania minimalne: Wymagania ogólne: System ma stanowić tzw. pojedynczy punkt kontaktowy (front-office) dla klientów (interesantów) jednostek samorządu terytorialnego województwa lubuskiego, pełniąc w powiązaniu z platformą epuap rolę systemu Elektronicznej Obsługi Obywatela (EOO). System musi umożliwiać bezpieczną i wiarygodną wymianę dokumentów elektronicznych między obywatelem / Interesantem oraz pomiędzy Urzędami za pośrednictwem powszechnie dostępnej sieci teleinformatycznej. System musi umożliwiać bezpieczne świadczenie interesantom usług publicznych drogą elektroniczną. System musi być zintegrowany z Elektroniczną Skrzynką Podawczą, która odpowiada za generowanie Urzędowego Poświadczenia Odbioru (UPO) dla dokumentów elektronicznych przesyłanych za pośrednictwem platformy regionalnej oraz pomiędzy systemami obiegu dokumentów Partnerów projektu. System musi być zintegrowany z Podsystemem Formularzy Elektronicznych, który będzie odpowiadał w szczególności za tworzenie, przechowywanie i udostępnianie repozytorium formularzy oraz wzorów dokumentów elektronicznych. Regionalna platforma komunikacji elektronicznej musi zawierać Regionalny Katalog Usług Publicznych (RKUP), który będzie gromadził i udostępniał opisy usług publicznych świadczonych przez podmioty publiczne (w szczególności samorządowe) z terenu województwa lubuskiego dla obywateli, podmiotów gospodarczych oraz organizacji. Przeznaczeniem Katalogu jest umożliwienie interesantom znalezienia najbardziej odpowiedniej usługi publicznej w kontekście ich problemu / sytuacji/potrzeby. Opisy usług w RKUP muszą być podzielone na część ogólną i cześć szczególną. Strona: 1

2 Cześć ogólna opisu usługi dla usług w RKUP realizowanych bezpośrednio na podstawie prawa powszechnego musi być jedna, wspólna dla wszystkich usług realizowanych w całym województwie (realizowanych na tej samej podstawie). Części szczególne opisów usługi oraz części ogólne opisu usługi w RKUP realizowanych na podstawie prawa lokalnego dostarczane będą przez podmioty publiczne usługodawców poszczególnych usług. W ramach interfejsu Użytkownik musi posiadać możliwość korzystania ze wszystkich funkcjonalności, które są dla niego udostępnione zgodnie z przypisanymi mu uprawnieniami. System musi wykorzystywać standard XML do wymiany danych, a także do opisu konfiguracji Systemu. Struktura dokumentów XML musi być definiowana zgodnie ze standardem XML Schema. System musi zapewniać szyfrowanie w stopniu uniemożliwiającym odczytanie przez osoby postronne wszystkich danych wymienianych między Urzędami oraz między Urzędem a Interesantem. System musi zapewniać bezpieczeństwo przesyłanych danych (przesyłanie danych z użyciem protokołu SSL). System do komunikacji musi wykorzystywać szynę integracyjną ESB. Skrytka Interesanta musi być spersonalizowanym, wymagającym uwierzytelniania, interfejsem dostępu Interesanta do usług publicznych e-urzędu przez przeglądarkę WWW (przynajmniej Internet Explorer 7.0, Firefox 3.0, Opera 9.0 lub nowsze). System musi zapewniać realizację pełnej ścieżki komunikacji Urząd <-> Interesant oraz Urząd <-> Urząd zgodnie z obowiązującymi przepisami prawa w tym zakresie. Komunikacja komponentu Elektroniczna Skrzynka Podawcza z urządzeniem HSM musi odbywać się za pomocą interfejsu zgodnego ze standardem PKCS#11. Dostarczona Elektroniczna Skrzynka Podawcza musi posiadać API do komunikacji z pozostałymi komponetami systemu. Interfejs użytkownika musi być w pełni polskojęzyczny (włączając w to menu, podmenu, formularze, pomoc kontekstową, teksty podpowiedzi, teksty komunikatów (również o błędach)). Wszelkie moduły systemu muszą korzystać ze standardowych notacji i języków w obszarach, w których istnieją powszechnie akceptowane otwarte standardy (w szczególności znajdujące się w rozporządzeniu o minimalnych wymaganiach dla systemów teleinformatycznych). Strona: 2

3 System ma być zbudowany w architekturze SOA. Wymaga się od Wykonawcy stosowania jednolitej konwencji rozwiązań, w szczególności stosowania wzorców architektonicznych - komponenty tego samego typu muszą być implementowane w ten sam sposób (poprzez użycie wypracowanego na początku wzorca). System musi wspierać otwarte standardy, w szczególności opracowane przez W3C, OASIS, WAI, WfMC, co najmniej w zakresie określonym przez Rozporządzanie Rady Ministrów z 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych, jeśli wykorzystanie tych standardów jest niezbędne do realizacji wymagań funkcjonalnych systemu. Instrukcja obsługi musi być zintegrowana z interfejsem w formie pomocy kontekstowej odnoszącej się do zawartości okna wyświetlanego w danym czasie na ekranie użytkownika systemu. System musi uniemożliwiać wpisywanie nieprawidłowych danych, w szczególności system musi, tam gdzie jest to możliwe, weryfikować poprawność wprowadzonych danych w danym polu a także zależności pomiędzy innymi polami (poprawności pola PESEL i jego zgodności z polami płeć i data urodzenia). W przypadku wpisania niewłaściwych danych system powinien zaznaczać te dane i informować użytkownika o błędzie. Wykonane oprogramowanie aplikacyjne nie będzie ograniczało możliwości skalowalności infrastruktury sprzętowej. Centralne komponenty Systemu muszą pracować w trybie całodobowym, 7 dni w tygodniu, 365 dni w roku, z przewidywanym 3 godzinnym oknem serwisowym raz na tydzień. na przeprowadzenie niezbędnych zabiegów administracyjnych. Rozwiązanie musi umożliwiać wykonywanie kopii bezpieczeństwa wg określonego scenariusza, nie rzadziej niż raz dziennie, zgodnie z opracowaną przez Wykonawcę Polityką Bezpieczeństwa. Kopie bezpieczeństwa mają zapewnić możliwość niezwłocznego odzyskania danych i przywrócenia całego Systemu do stanu normalnej pracy po ewentualnej awarii sprzętowej lub programowej. Poufność danych w odniesieniu do komunikacji z użytkownikiem publicznym zapewniona będzie przez wykorzystanie protokołu SSL (HTTPS). Jedynie część informacyjna mająca charakter publiczny, może być obsługiwana poprzez protokół HTTP bez stosowania szyfrowania. System musi posiadać hierarchię uprawnień oraz granulację dostępu do zasobów systemu. Każdy użytkownik i klient Systemu musi dysponować indywidualnym identyfikatorem, który umożliwi korzystanie Strona: 3

4 z udostępnionych zasobów i usług. System e-urząd musi pozwalać na uwierzytelnianie interesantów, co najmniej w zakresie: o identyfikatora i hasła; o certyfikatu kwalifikowanego; o zaufanego profilu epuap; o nowego elektronicznego dowodu osobistego. System e-urząd musi pozwalać na uwierzytelnianie użytkowników, co najmniej w zakresie: o identyfikatora i hasła; o certyfikatu kwalifikowanego; o nowego elektronicznego dowodu osobistego. System musi rejestrować wszystkie próby uwierzytelniania oraz gromadzić i przechowywać następujące informacje: o pełną datę z godziną; o nazwę konta, które zostało poddane uwierzytelnianiu; o adres IP, z którego wykonane było uwierzytelnianie; o nazwę domenową adresu, z którego wykonane było uwierzytelnianie; o rezultat uwierzytelniania (powodzenie/niepowodzenie). System musi spełniać wymagania określone w rozporządzeniach wykonawczych do Ustawy z dnia 29 sierpnia 1997r. o ochronie danych osobowych. System musi mieć zaimplementowaną politykę zarządzania hasłami zgodną z Ustawą z dnia 29 sierpnia 1997r. o ochronie danych osobowych. System musi wykorzystywać mechanizm SSO, umożliwiający zalogowanym (uwierzytelnionym) użytkownikom (urzędnikom) uzyskanie dostępu do poszczególnych komponentów i zasobów systemu na podstawie przyznanych im uprawnień, bez konieczności ponownego logowania. Strona: 4

5 System musi pozwalać na współdzielenie informacji o tożsamości użytkowników interaktywnych (mechanizm SSO - Single Sign On) w odniesieniu do interesantów posiadających konto na platformie epuap. System musi umożliwiać odebranie wniosków złożonych do skrzynki podawczej dostępnej na platformie epuap. System musi umożliwiać uzyskanie przez interesanta informacji na temat etapu realizacji spraw, które zostały przez niego założone w urzędzie zarówno drogą elektroniczną jak i tradycyjną (papierową). System musi umożliwiać Interesantowi wgląd w stan sprawy na każdym poziomie jej procesowania w urzędzie. System musi umożliwiać Urzędnikowi kontakt z Interesantem celem wezwania go do uzupełnienia dokumentów niezbędnych do załatwienia sprawy. System musi umożliwiać Interesantowi wgląd w wydaną decyzję administracyjną. Zalogowany interesant musi mieć możliwość: o wypełnienia dowolnego spośród udostępnionych e-formularzy, dołączenia załączników i wysłania ich do urzędu; o odebrania dokumentu UPO potwierdzającego złożenie wniosku; o podpisania wysyłanych dokumentów podpisem elektronicznym weryfikowanym przez certyfikat kwalifikowany, przy pomocy zaufanego profilu epuap, podpisem elektronicznym nowego dowodu osobistego; o dokonania płatności elektronicznej dla składanego wniosku elektronicznego; o zachowania częściowo wypełnionego danymi formularza i powrotu do edycji w późniejszym czasie lub po ponownym zalogowaniu; o zarządzania ustawieniami skrzynki w zakresie: zmiana hasła, wprowadzanie i zmiana danych osobowych (dane będą wykorzystane do automatycznego wypełnienia pól formularzy wniosków), wprowadzenie i zmiana adresu poczty elektronicznej ( ); o uzyskania informacji o zdarzeniach, które zaszły w związku z jego wnioskami złożonymi w urzędach, pozwalających na śledzenie stanu realizacji sprawy, podgląd dokumentów wysłanych przez Urząd do interesanta; o odebrania dokumentów elektronicznych przesłanych przez Urząd poprzez potwierdzenie tożsamości Strona: 5

6 klienta podpisem elektronicznym; o zamówienia automatycznego przesłania powiadomienia o zmianie statusu sprawy na podany przez siebie adres . Wiedza o Systemie e-urząd zawarta w podręczniku administratora i dokumentacji technicznej musi pozwalać na rozszerzanie Systemu zarówno w odniesieniu do wydajności jak i pojemności oraz musi pozwalać na samodzielną konfigurację Systemu i wykrycie nieprawidłowości w celu zgłoszenia problemu do Wykonawcy. System uprawnień administracyjnych musi być hierarchiczny, tak by było możliwe powoływanie przez głównego administratora innych administratorów i nadawania im części posiadanych przez siebie uprawnień (z możliwością ograniczenia nadanego zakresu uprawnień do pojedynczej komórki urzędu). Wymagania w zakresie bezpieczeństwa: Zabezpieczenie transmisji danych użytkownika. System powinien posiadać zabezpieczenie transmisji danych poufnych pomiędzy portalem a przeglądarką użytkownika za pomocą protokołu SSL. Za dane poufne uważa się wszystkie informacje, które nie są publicznie dostępne na portalu dla użytkownika niezalogowanego (np. dane wyświetlane na formularzu edycji danych konta użytkownika). Wykonawca powinien wyposażyć system w certyfikat SSL dla serwera WWW oraz zabezpieczyć transmisję poufnych danych protokołem HTTPS. Zabezpieczenie wymiany danych z systemami zewnętrznymi. System powinien posiadać zabezpieczenie protokołem SSL transmisji pomiędzy działającymi w systemie komponentami wymiany danych a zewnętrznymi systemami. Transmisja może być niezaszyfrowana tylko w przypadkach, gdy wymieniane dane są publicznie dostępne dla anonimowych użytkowników. Wykonawca powinien zaprojektować komunikację z systemami zewnętrznymi tak, by wywołania zewnętrznych webserwisów odbywały się za pomocą protokołu HTTPS. Aplikacje webowe powinny być zabezpieczone przed atakami typu "SQL injection". Aplikacje webowe zapisujące dane w bazie muszą unieszkodliwiać niedozwolone znaki w danych wejściowych do bazy. Aplikacje webowe muszą być odporne na ataki Cross-site scripting (XSS) i Cross-site request forgery (XSRF). Wykonawca powinien zaprojektować aplikacje webowe tak by były odporne na takie ataki, czyli powinny spełniać następujące warunki: o nie można na stronie zamieszczać odnośników do skryptów znajdujących się na innych serwerach; o jeśli strona jest udostępniana po protokole HTTPS, to wszystkie jej komponenty zależne (obrazki, Strona: 6

7 skrypty, arkusze stylów, itp.) także; o ważne akcje zmiany danych w portalu (np. zapisanie danych) powinny wymagać dodatkowego potwierdzenia (np. captcha, ponowne zalogowanie się do portalu). Użytkownik powinien być uwierzytelniany w systemie za pomocą unikalnego identyfikatora i hasła. Formularz rejestracji nowego użytkownika powinien być zabezpieczony za pomocą mechanizmu CAPTCHA przed robotami rejestrującymi masowo konta. Rejestracja użytkownika wymaga podania adresu . System powinien być zaprojektowany tak, by daną wymaganą podczas rejestracji był ważny adres , na który zostanie wysłana wiadomość z linkiem aktywującym konto. Zaprojektowany system powinien posiadać ściśle określoną politykę haseł. Wykonawca zaprojektuje system tak, by hasło wprowadzone przez użytkownika podczas rejestracji spełniało wymagania definiowanej w systemie polityki haseł (minimalna długość, obecność w haśle określonych znaków duże i małe litery, cyfry, znaki specjalne). Przechowywanie hasła w postaci zaszyfrowanej. W systemie powinien być przechowywany skrót hasła wyliczony za pomocą bezpiecznej do zastosowań kryptograficznych jednokierunkowej funkcji mieszającej. Hasło użytkownika utrwalone w bazie danych nie może być zapisane otwartym tekstem. System powinien przechowywać postać hasła po przetworzeniu algorytmem bezpiecznej do zastosować kryptograficznych jednokierunkowej funkcji mieszającej (np.md5 lub SHA). Wykonawca powinien zabezpieczyć portal przed nieautoryzowanym definiowaniem uprawnień przez użytkowników. Tylko zalogowani administratorzy mogą definiować uprawnienia. Portal powinien posiadać mechanizm umożliwiający wygenerowanie nowego hasła i przypomnienie identyfikatora w przypadku, gdy użytkownik zagubi dane konta. Wykonawca powinien zaprojektować mechanizm przypomnij hasło i identyfikator wymagający podania adresu przypisanego do konta podczas rejestracji. z loginem i wygenerowanym nowym hasłem powinien dotrzeć na skrzynkę użytkownika. System powinien wymusić zmianę hasła po pierwszym zalogowaniu od momentu użycia mechanizmu "przypomnij login i hasło". Wykonawca powinien skonfigurować serwery aplikacji tak, by automatyczne zamykały sesję zalogowanego użytkownika po definiowalnym przez administratora czasie nieaktywności. Strona: 7

8 Wymagania w zakresie portalu Cyfrowy Urząd: Profil interesanta Dostęp do usług elektronicznych musi być możliwy dla niezalogowanych (na poziomie dostępu do informacji gromadzonej w Cyfrowym Urzędzie) oraz zalogowanych Interesantów (na poziomie załatwiania spraw urzędowych on - line). System powinien zostać wyposażony w Profil Interesanta, w którym przechowywane będą w szczególności: o dane dotyczące Interesanta posiadającego założone konto wczytane automatycznie z formularza rejestracyjnego lub wprowadzone ręcznie przez użytkownika samodzielnie; o dane dotyczące załatwianych przez niego spraw urzędowych; o dane dotyczące płatności; o dane pozwalające skorelować jego konto z kontem na platformie epuap. Po zalogowaniu się Interesanta do Cyfrowego Urzędu ma on mieć dostęp do pełnej funkcjonalności w tym: o do danych zgromadzonych w jego Profilu Interesanta; o do Skrytki Interesanta. Skrytka Interesanta musi umożliwiać dwukierunkową komunikację Interesanta z Urzędem. W zakresie funkcjonalności Skrytki Interesanta Interesant powinien przede wszystkim uzyskać możliwość: o udostępnienia informacji gromadzonych w Profilu Interesanta; o wypełnienia dowolnego spośród udostępnionych e-formularzy zgodnie z Instrukcjami opisanymi w RKUP; o nadania biegu sprawie urzędowej, tj. przesłania dokumentu elektronicznego wraz z załącznikami do Urzędu, otrzymując w odpowiedzi urzędowe potwierdzenie odbioru; o podpisania wysyłanych dokumentów podpisem elektronicznym weryfikowanym przez certyfikat kwalifikowany bądź profilem zaufanym, podpisem osobistym; o uiszczenia należnej opłaty; Strona: 8

9 o sprawdzenia stanu sprawy; o odebrania decyzji administracyjnej (jeżeli będzie wydana) lub pisma wystosowanego w realizowanej sprawie. Formularze elektroniczne System musi zapewniać możliwość tworzenia i modyfikacji formularzy za pomocą edytora formularzy. Edytor powinien umożliwiać w szczególności: o tworzenie e-formularzy, o dodawanie pól formularza metodą drag&drop, o import/eksport e-formularzy do i z pliku, o tworzenie list rozwijanych, pól wielokrotnego wyboru, o tworzenia list opartych na zestawach danych (słownikach) zdefiniowanych przez użytkownika, o tworzenie formularzy dynamicznych, których zawartość i wygląd może się zmieniać na podstawie danych wprowadzonych przez użytkownika wypełniającego formularz, o zamieszczanie dowolnych elementów tekstowych w warstwie prezentacji formularza, o dodawanie dowolnych treści pomocy kontekstowej w ramach e-formularza do każdego pola formularza, o umieszczanie przycisków pozwalających wnioskodawcy na dodawanie (usuwanie) określonego pola lub grupy pól (np. w celu dodania wielu adresów), o definiowanie reguł wyświetlania oraz reguł walidacji w ramach e-formularza, o definiowanie reguł walidacji poszczególnych pól formularza z uwzględnieniem powiązań pomiędzy polami, o zapis tworzonych e-formularzy w wersji roboczej, o podgląd, wypełnianie treścią i walidację e-formularza w celach testowych, o tworzenie nowych formularzy na podstawie już istniejących z zachowaniem wszystkich ich elementów (reguły wyświetlania, teksty, pola). Strona: 9

10 System musi umożliwiać wykorzystanie przez jednostki podległe formularzy przygotowanych przez podmiot nadrzędny. System powinien umożliwiać definiowanie formularzy referencyjnych, oraz tworzenie na ich podstawie formularzy prywatnych wykorzystywanych przez poszczególne jednostki. Jednostki powinny mieć możliwość uzupełnienia opisu referencyjnego usługi o dodatkowe informacje udostępniane przez poszczególne jednostki, definiowane przez administratorów lokalnych Elektroniczna Skrzynka Podawcza System musi być wyposażony w Elektroniczną Skrzynkę Podawczą (ESP). ESP musi generować Urzędowe Poświadczenie Odbioru (zgodnie z przepisami prawa) podpisywane przez sprzętowy moduł bezpieczeństwa HSM zgodny z normą FIPS co najmniej na poziomie 3. ESP musi obsługiwać całość korespondencji wymienianej za pośrednictwem e-urzędu. ESP musi obsługiwać zarówno korespondencję kierowaną do Partnera Projektu, jak i korespondencję wysyłaną przez Partnera Projektu. ESP musi obsługiwać korespondencję wymienianą pomiędzy Partnerami Projektu. System musi umożliwiać kontakt klientów urzędu także za pośrednictwem elektronicznej skrzynki podawczej systemu epuap. Dokumenty wpływające do urzędu za pośrednictwem skrzynki podawczej systemu epuap są obsługiwane w sposób jednorodny w stosunku do dokumentów wpływających za pośrednictwem skrzynki podawczej Cyfrowego Urzędu. Komunikacja z systemem EOD System musi zapewniać współpracę z systemem Elektronicznego Obiegu Dokumentów w zakresie przekazywania dokumentów elektronicznych oraz przekazywania do Interesanta wydanych decyzji / odpowiedzi. System musi udostępniać możliwość przesyłania informacji zwrotnej dotyczącej danej sprawy w postaci publikacji statusu sprawy automatycznie generowanego w systemie EOD na każdym etapie procesu Strona: 10

11 rozpatrywanej sprawy. System musi zapewniać możliwość przesłania dodatkowych dokumentów dotyczących danej sprawy. System musi umożliwiać dostęp Interesanta do informacji na temat statusu każdej realizowanej przez niego sprawy urzędowej na każdym etapie jej procesowania w EOD. Każda czynność wykonywana w systemie musi być zapisywana, tak aby możliwa była identyfikacja osoby wykonującej czynność, obiektów których dotyczyła czynność oraz czasu wykonania czynności. System elektronicznego obiegu oraz zarządzania dokumentami (Workflow) System musi mieć możliwość nadzorowania i rejestrowania obiegu korespondencji wewnętrznej pomiędzy pracownikami i komórkami organizacyjnymi. System musi umożliwiać obsługę wielu sekretariatów i rejestrować korespondencję wpływającą wraz z załącznikami oraz automatycznie ją numerować. System musi rejestrować wybrane czynności związane z poszczególnym dokumentem (np. dekretacji) w postaci historii, przypisując jednoznacznie odpowiedzialność za każdą czynność i dając możliwość szybkiego odczytania tych informacji. System musi zapamiętywać profile pracy poszczególnych użytkowników i udostępniać je po zalogowaniu na dowolnej stacji roboczej. System musi zapewniać definiowanie wyświetlanych kolumn dla widoków rejestrów dokumentów przychodzących i wychodzących. Mieć możliwość definiowania i zapamiętywania widoków. Widoki mogą być prywatne lub udostępnione wszystkim użytkownikom. System musi posiadać możliwość nadawania terminów realizacji związanych z daną dekretacją/zadaniem. System musi posiadać interfejs oparty na przeglądarce internetowej. Pełna obsługa musi być możliwa przy użyciu przeglądarki (przynajmniej Internet Explorer 7.0, Firefox 3.0, Opera 9.0 lub nowsze), łącznie z wprowadzaniem danych. System musi posiadać wbudowany moduł archiwalny, w pełni obsługujący wszystkie podstawowe procesy związane archiwizacją dokumentów (w tym: tworzenie spisów zdawczo-odbiorczych, brakowanie, przekazywanie Strona: 11

12 do Archiwum Państwowego). Wymagania w zakresie szyny integracyjnej ESB: Szyna ESB musi posiadać mechanizm definiowania, implementacji, wdrażania i zarządzania usługami realizującymi dostęp do integrowanych systemów. Usługi mogą być elementarne, tworzone jako konfiguracja pewnych modułów lub posiadać większą logikę integracyjną (np. sekwencja wywołań kilku usług). Szyna ESB zakłada istnienie usług prywatnych i publicznych. Usługi prywatne są dostępne jedynie w obrębie platformy integracyjnej i nie mogą być bezpośrednio wywoływane przez klientów systemu. Ich zadaniem jest realizowanie atomowych operacji, z których budowane są usługi publiczne. Usługi publiczne są widoczne dla klientów platformy integracyjnej poprzez: o punkt dostępu do usługi stanowiący adres sieciowy usług w ramach infrastruktury ESB; o punkt dostępu do definicji usługi (adres URL) - stanowiący adres sieciowy dokumentu WSDL opisującego usługę. Każda usługa publiczna realizuje konkretny scenariusz (proces) integracyjny. Wspólnym protokołem komunikacyjnym usług publicznych i prywatnych musi być SOAP, a protokołem transportowym HTTP lub HTTPS. W przypadku komunikacji asynchronicznej wspólnym protokołem transportowym musi być transport oparty o kolejki (np. JMS). Funkcjonalność tworzona w ramach szyny usług musi być udostępniana w postaci atomowych usług. Każda usługa zawiera: o unikalną nazwę; o definicję wejścia i wyjścia usługi; o implementację logiki realizowanej przez usługę; o metadane ją opisujące; o listę błędów zgłaszanych przez usługę; Strona: 12

13 o dokumentację. Oprogramowanie szyny usług musi posiadać mechanizm umożliwiający planowe i cykliczne uruchamianie usług platformy. Zarządzanie planowanymi do uruchomienia usługami musi odbywać się w sposób spójny z jednego miejsca platformy na zasadzie definiowania harmonogramu wywołań. ESB musi zapewniać pełne wsparcie obsługi dokumentów XML. W ramach obsługi dokumentów XML, ESB ma wspierać możliwość: o tworzenia i parsowania komunikatów XML, o walidacji komunikatów na podstawie definicji XMLSchema i DTD, o obsługi dużych dokumentów XML oraz określić czy istnieją jakieś ograniczenia w obsłudze dużych dokumentów, o transformacji komunikatów dokument XML na inny dokument XML oraz pomiędzy dokumentem XML i innym formatem (w obie strony), o poprawnej obsługi stron kodowych obsługujących polskie znaki. W ramach obsługi protokołu SOAP i webservices dla usług konsumowanych jak i udostępnianych ESB musi zapewniać: o możliwość konsumowania oraz udostępniania usług w standardzie webservices (WSDL 1.1, SOAP 1.1 i 1.2); o standard WS-Security; o standard WS-Policy; o pożądane jest, aby platforma wspierała inne standardy WS określone specyfikacjami konsorcjum OASIS ( ESB musi dostarczać usługi transformacji komunikatów XML w modelach jeden do wielu i wiele do jednego, co najmniej przy wykorzystaniu języka XSLT 1.0 (XSL Transformations, Extensible Stylesheet Language Transformations). ESB musi dostarczać usługi translacji danych. Strona: 13

14 ESB musi dostarczać usługi translacji protokołów. ESB musi umożliwiać routing komunikatów, oparty na treści dokumentów XML i regułach biznesowych. ESB musi umożliwiać filtrowanie komunikatów na podstawie zawartości, przy wykorzystaniu parametrów definiowanych przez użytkownika. ESB musi umożliwiać realizację procesów integracyjnych w oparciu o model synchroniczny i asynchroniczny. ESB musi umożliwiać trwałe przechowywanie komunikatów. ESB musi umożliwiać tworzenie architektury wyjątków, która może przechwytywać wyjątki, generować transakcje kompensacyjne i generować raporty o błędach. ESB musi posiadać mechanizmy programowego klastrowania krytycznych elementów architektury ESB. ESB musi umożliwiać odtworzenie stanu systemu sprzed awarii. ESB musi posiadać mechanizmy load-balancing wykorzystywane w sytuacjach zwiększonego obciążenia. ESB musi umożliwiać skalowanie, rekonfigurację, osadzanie nowych usług bez zakłócania pracy innych aplikacji czy realizowanych operacji biznesowych. ESB musi umożliwiać integrację relacyjnych baz danych na poziomie danych i wywoływania procedur bazodanowych (musi posiadać wsparcie dla standardu JDBC - Java Database Connectivity). ESB musi umożliwiać integrację aplikacji zbudowanych w technologiach J2EE,.Net. ESB musi wspierać orkiestrację usług przy wykorzystaniu języka BPEL, w oparciu o silnik procesów biznesowych. ESB musi wspierać co najmniej następujące standardy komunikacji: SOAP, JMS, JCA, HTTP, HTTPS, FTP. ESB musi umożliwiać zarządzanie transakcjami w procesach biznesowych. Warstwa komunikacyjna ESB musi umożliwiać zachowanie integralności, niezaprzeczalności, poufności i autentyczności komunikacji. ESB musi umożliwiać raportowanie informacji o incydentach w zakresie bezpieczeństwa w Systemie Monitorowania. Strona: 14

15 Bezpieczeństwo usług zbudowanych w oparciu o technologię Web Services musi bazować na standardzie OASIS WS-S (Web Services Security). ESB musi umożliwiać szyfrowanie i podpisywanie komunikatów XML zgodnie z obowiązującymi przepisami. ESB musi umożliwiać podpisywanie komunikatów XML zgodnie ze standardem Advanced Electronic Signature (XAdES). Minimalna długość klucza szyfrującego w przypadku zastosowania algorytmów symetrycznych musi wynosić 128 bitów, natomiast w przypadku zastosowania algorytmów asymetrycznych 1024 bity. ESB musi umożliwiać weryfikację statusu unieważnienia certyfikatu poprzez mechanizm CRL. W ramach szyny usług przewiduje się realizację co najmniej następujących usług umożliwiających integrację z modułami systemu i systemami obcymi: o integracja z front-office e-urzędu; o integracja z systemami obiegu dokumentów dostarczanymi w ramach realizacji systemu; o opracowanie i uruchomienie uniwersalnych usług umożliwiających komunikację z innymi systemami obiegu dokumentów; o komunikację z modułem obsługi płatności; o integrację z platformą epuap w zakresie: publikowania Regionalnego Katalogu Usług, wnoszenia opłat za pomocą mechanizmów udostępnianych przez epuap, generowania urzędowych poświadczeń za pomocą mechanizmów udostępnianych przez epuap, komunikację z ESP, uwierzytelniania Interesanta we front-office e-urzędu przez epuap przy wykorzystaniu SSO (Single Sign On) i SAML (Security Assertion Markup Language), współpracy z Krajowym Katalogiem Serwisów Publicznych na platformie epuap, Strona: 15

16 współpracy z CRD; o integracja z Centrami Certyfikacji w zakresie: weryfikacji ważności certyfikatów kwalifikowanych wystawionych przez centrum, cyklicznej aktualizacji list CRL. Wymagania w zakresie Podsystemu ewidencji opłat i płatności: Zapisanie informacji o wysokości opłat należnych z tytułu rozpatrzenia poszczególnych typów wniosków oraz wydania wnioskowanych dokumentów (decyzji, zezwoleń). Pobranie informacji o wysokości opłat przez pozostałe komponenty systemu poprzez udostępnione interfejsy. Zarejestrowanie faktu pojawienia się należności w systemie poprzez udostępnione interfejsy oraz poprzez dostępny w Podsystemie interfejs użytkownika. Przekazanie do innych komponentów systemu informacji o istnieniu należności, o jej stanie rozliczenia poprzez udostępnione interfejsy. Zarejestrowanie faktu dokonania wpłaty poprzez udostępnione interfejsy oraz poprzez dostępny w Podsystemie interfejs użytkownika. Zarejestrowanie wpłat na podstawie wskazanego wyciągu bankowego. Łączenie należności i wpłaty oraz propagacja informacji o rozliczeniu należności do pozostałych komponentów systemu. Możliwość dokonania płatności jednocześnie ze składanym wnioskiem. Integracja z usługą PayByNet w zakresie dokonania płatności oraz odebrania dokumentu EPO wygenerowanego przez tę usługę. Wspomaganie płatności dokonywanych przelewem. Udostępnienie użytkownikowi portalu eformularzy (Interesantowi) informacji o oczekujących do zapłaty należnościach. Możliwość dokonania płatności za wskazaną przez użytkownika należność widoczną na jego koncie jako Strona: 16

17 oczekująca do zapłacenia. Udostępnienie użytkownikowi portalu eformularzy (Interesantowi) informacji o odebranych dokumentach EPO. Udostępnienie użytkownikowi portalu eformularzy (Interesantowi) informacji o stanie rozliczenia należności. Wykorzystanie usługi płatności elektronicznych udostępnianej na platformie epuap. Moduł płatności wraz z zintegrowanym systemem płatności powinien realizować funkcjonalność polegającą na tym, że petent / klient może na wskazany przez siebie przesłać wygenerowany link do płatności. System powinien umożliwiać ograniczenie czasowe płatności, tzn. określić datę, po której wymaganie wniesienia opłaty wygaśnie. Informacja o wygaśnięciu wymagania opłaty powinna być przekazywana do EOD, a sprawa której dotyczy opłata powinna być w takim wypadku zawieszona do czasu wyjaśnienia 2 Ilość Wykonawca zobowiązany jest udzielić Zamawiającemu niewyłącznej Licencji na korzystanie z Oprogramowania oraz niezbędnego do jego działania Oprogramowania Narzędziowego. Licencja musi być udzielona na czas nieokreślony dla nieograniczonej liczby urzędników i administratorów z prawem udzielania dalszych licencji na warunkach określonych w Projekcie Umowy wyłącznie na terytorium województwa Lubuskiego w stosunku do Partnerów projektu, podległych im jednostek organizacyjnych oraz innych Organów administracji publicznej. 3 Prace wdrożeniowe Wykonawca przeprowadzi prace wdrożeniowe w podziale na sześć etapów: 1. analiza przedwdrożeniowa, 2. budowa, 3. instalacja, 4. konfiguracja oraz parametryzacja systemu, 5. odbiory, 6. szkolenia. I etap: Analiza przedwdrożeniowa - będzie obejmować: Cyfrowy Urząd zawierający formularze elektroniczne oraz ESP Strona: 17

18 o Dostarczenie przez Zamawiającego obowiązujących wzorów formularzy wniosków elektronicznych, które zostaną udostępnione na lokalnej platformie wykonanej i wdrożonej w ramach postępowania. o Analiza zakresu informacyjnego dostarczonych formularzy wniosków. Identyfikacja poszczególnych atrybutów. Określenie typów dla poszczególnych atrybutów. Identyfikacja atrybutów wspólnych dla wszystkich formularzy wniosków. Określenie reguł walidacyjnych dla poszczególnych atrybutów formualrzy wniosków. o Opracowanie metastandardu dokumentów elektronicznych generowanych przez system w wyniku wypełnienia formularza elektronicznego na potrzeby formularzy elektronicznych, które zostaną udostępnione na platformie wykonanej i wdrożonej w ramach postępowania. Metastandard powienien zawierać. Definicję struktury dokumentów elektronicznych. Definicję typów, które zostaną wykorzystane do zdefiniowania zakresu informacyjnego poszczególnych dokumentów elektronicznych, w części wspólnej dla wszystkich dokumentów elektronicznych. Diefinicję typów, które zostaną wykorzystane do zdefiniowania zakresu informacyjnego poszczeólnych dokumentów elektronicznych w części specyficznej dla poszczególnych obszarów tematycznych, w ramach których zostaną przygotowane dokumenty elektroniczne. o Zaprojektowanie 50 wzorcowych formularzy wniosków elektronicznych dla poszczególnych rodzajów spraw. Formularze te staną się formularzami wzorcowymi dla wszystkich Partnerów projektu. o Zaprojektowanie portalu eformularzy, na którym zostaną osadzone formularze wniosków elektronicznych. o Zaprojektowanie funkcjonalności profilu interesanta dostępnego na portalu eformularzy. o Zaprojektowanie narzędzia do definiowania formularzy wniosków elektronicznych. Szyna integracyjna ESB o Wykonanie projektu usług integracyjnych realizujących komunikację pomiędzy komponentami systemu zainstalowanymi u Partnera. o Wykonanie projektu usług integracyjnych realizujących komunikację pomiędzy komponentami systemu zainstalowanymi w centrali i u Partnerów. Strona: 18

19 o Wykonanie projektu usług uwierzytelniania użytkowników. Podsystem komunikacji z EOD o Wykonanie projektu usług integracyjnych realizujących komunikację pomiędzy EOD, ESP dostarczoną w ramach projektu oraz epuap. o Wykonanie projektu usług integracyjnych realizujących komunikację pomiędzy instancjami EOD zainstalowanymi u poszczególnych Partnerów. Podsystem ewidencji opłat i płatności o Dostarczenie przez Zamawiającego wykazu opłat obowiązujacych w sprawach, dla których w ramach projektu zostaną przygotowane formularze wniosków elektronicznych. o Zaprojektowanie funkcjonalności Podsystemu ewidencji opłat i płatności. o Opracowanie zawartości słownika opłat występujących w Podsystemu ewidencji opłat i płatności Definicje opłat. Powiązanie opłat z rodzajami spraw i pism (w tym wniosków elektronicznych). Powiązanie opłat z kontami bankowymi Partnerów. II etap: Budowa - będzie obejmować: Cyfrowy Urząd zawierający formularze elektroniczne oraz ESP o Wykonanie formularzy wniosków elektronicznych, które będą udostępnione na platformie wykonanej i wdrożonej w ramach postępowania, z uwzględnieniem metastandardu opracowanego na etapie Analizy przewdrożeniowej. o Wykonanie portalu eformualarzy wraz z funkcjonalnością profilu interesanta. o Wykonanie narzędzia do definiowania formularzy wniosków elektronicznych. Szyna integracyjna ESB o Wykonanie usług integracyjnych realizujących komunikację pomiędzy komponentami systemu zainstalowanymi u Partnera. o Wykonanie usług integracyjnych realizujących komunikację pomiędzy komponentami systemu zainstalowanymi w centrali i u Partnerów. Strona: 19

20 o Wykonanie usług uwierzytelniania użytkowników. Podsystem komunikacji z EOD o Wykonanie usług integracyjnych realizujących komunikację pomiędzy EOD, ESP dostarczoną w ramach projektu oraz epuap. o Wykonanie usług integracyjnych realizujących komunikację pomiędzy instancjami EOD zainstalowanymi u poszczególnych Partnerów. Podsystem ewidencji opłat i płatności o Wykonanie Podsystemu ewidencji opłat i płatności. o Wykonanie skryptów do zasilenia słownika opłat dla poszczególnych Partnerów. III etap: Instalacja - będzie obejmować: Iinstalację rozwiązania na poziomie regionalnym w Centrum przetwarzania danych (Data Center) na sprzęcie dostarczanym w ramach Zadania nr 49 oraz 50, IV etap: Konfiguracja oraz parametryzacja Systemu będzie obejmować: Wprowadzenie globalnych danych konfiguracyjnych. Wprowadzenie danych konfiguracyjnych dla Partnerów. Wprowadzenie danych konfiguracyjnych dla Użytkowników końcowych. V etap: Odbiory obejmować będą: Sprawdzenie przez Zamawiającego zainstalowanego Systemu pod względem jego zgodności z wymaganiami SIWZ oraz jego poprawności działania, w tym jego poprawności działania w zakresie wykonanych procesów integracyjnych. Sprawdzenie przez Partnerów projektu poprawności wprowadzonych danych konfiguracyjnych dla Partnera i Użytkowników końcowych oraz prawidłowości działania wykonanych formularzy wniosków elektronicznych. Strona: 20

21 VI etap: Szkolenia obejmować będą: Szkolenia administratorów: o Liczba grup: 1 o Liczba osób: 5 (osoby ze strony Zamawiającego) o Czas trwania szkolenia: 16 godzin dydaktycznych o Forma szkolenia: wykłady oraz warsztaty praktyczne o Oczekiwany efekt: pozyskanie wiedzy teoretycznej oraz praktycznej pozwalającej na samodzielną konfigurację oraz administrowanie Regionalną platformą komunikacji elektronicznej w zakresie jej pełnej funkcjonalności Szkolenia administratorów lokalnych (JST): o Liczba grup: 10 o Liczba osób: 95 (po 1 osobie od każdego z Partnerów (JST)) o Czas trwania szkolenia: 12 godzin dydaktycznych o Forma szkolenia: wykłady oraz warsztaty praktyczne o Oczekiwany efekt: pozyskanie wiedzy teoretycznej oraz praktycznej pozwalającej na samodzielną konfigurację oraz administrowanie Regionalną platformą komunikacji elektronicznej w zakresie współpracy z JST Szkolenia użytkowników merytorycznych: o Liczba grup: 10 o Liczba osób: 95 (od każdego z Partnera wydelegowana 1 osoba) o Czas trwania szkolenia: 16 godzin dydaktycznych o Forma szkolenia: wykłady oraz warsztaty praktyczne o Oczekiwany efekt: pozyskanie wiedzy teoretycznej i praktycznej pozwalającej na samodzielne przygotowanie dedykowanych dla Partnerów formularzy wniosków elektronicznych, na podstawie wykonanych w ramach projektu wzorców oraz przy wykorzystaniu narzędzia do budowy formularzy wniosków elektronicznych dostarczonego w ramach projektu. Strona: 21

22 4 Specyficzne warunki dostaw / prac wdrożeniowych Zamawiający wymaga przeprowadzenia wdrożenia Regionalnej platformy komunikacji elektronicznej w następujących terminach: Etap Etap wdrożenia Termin 1. Analiza przedwdrożeniowa 4 miesiące od daty podpisania umowy 2. Dostawa licencji Oprogramowania oraz Oprogramowania Narzędziowego 7 miesięcy od daty podpisania umowy 3. Instalacja 7 miesięcy od daty podpisania umowy 4. Przeprowadzenie szkoleń 11 miesięcy od daty podpisania umowy 5. Odbiory 12 miesięcy od daty podpisania umowy Zamawiający wymaga, aby przed etapem instalacji Systemu spełnione były następujące warunki: zainstalowana, uruchomiona i skonfigurowana infrastruktura sprzętowa oraz Oprogramowanie systemowe Przed przystąpieniem do przeprowadzenia szkoleń Wykonawca zobowiązany jest do: przygotowania i przekazania: o Dokumentacji Technicznej, o Dokumentacji Wdrożeniowej, o Dokumentacji Szkoleniowej. Strona: 22

23 5 Warunki serwisu gwarancyjnego przygotowania i przekazania Dokumentacji Użytkowej dla: o administratorów, o redaktorów. Dokumentacja powinna być dostarczona w formie elektronicznej oraz po 1 egzemplarzu w wersji papierowej Serwis gwarancyjny Wykonawca udzieli gwarancji na dostarczone Oprogramowanie na okres 60 miesięcy licząc od daty wdrożenia Systemu (odbioru końcowego realizacji zadania) zapewniając jednocześnie serwis gwarancyjny. Wszelkie koszty gwarancji wraz z serwisem gwarancyjnym są w pełni włączone do ceny ofertowej. Koszt udzielania gwarancji wliczony jest do wynagrodzenia jakie otrzyma Wykonawca za realizację umowy. W okresie gwarancji wszelkie koszty usuwania wad i awarii oraz zmian ponoszone są przez Wykonawcę, których przyczyna leży po jego stronie ponosi Wykonawca. Wsparcie użytkowników Help Desk W okresie trwania gwarancji Wykonawca zapewnieni usługę Help Desk. Asysta techniczna Wykonawca zobowiązany jest świadczyć bezpłatną asystę techniczną przez okres 12 miesięcy. Okres i zakres asysty technicznej rozpoczyna się z dniem wdrożenie Systemu (odbioru końcowego realizacji zadania). 6 Etapy realizacji dostaw oraz prac wdrożeniowych podlegające formalnym odbiorom Świadczenie serwisu gwarancyjnego, wsparcia użytkowników Help Desk oraz Asysty technicznej ma być realizowane na zasadach określonych w Załączniku nr 6 do SIWZ. 1. Dostawa licencji: Formalnemu odbiorowi podlega dostawa licencji oraz nośników instalacyjnych do Zamawiającego w ilościach określonych w treści oferty zgodnie z procedurą określoną w Załączniku nr 2 do SIWZ, Podpisany przez Zamawiającego protokół odbioru dostawy w ramach zadania stanowi podstawę płatności za dostawę dla zadania. 2. Prace wdrożeniowe: Formalnemu odbiorowi podlegają następujące etapy prac wdrożeniowych: o opracowanie koncepcji graficznej, o instalacja, Strona: 23

24 o szkolenia, o wdrożenie Systemu (odbiór końcowy realizacji zadania). Odbiory prac wdrożeniowych odbywają się godnie z procedurą określoną w Załączniku nr 2 do SIWZ, Podpisany przez Zamawiającego protokół odbioru etapu wdrożenia potwierdzający zrealizowanie bez uwag wszystkich prac wdrożeniowych etapu stanowi podstawę płatności: o opracowanie koncepcji graficznej 10% wartości wynagrodzenia za prace wdrożeniowe zadania, o instalacja 20% wartości wynagrodzenia za prace wdrożeniowe zadania, o szkolenia 20% wartości wynagrodzenia za prace wdrożeniowe zadania, o wdrożenie Systemu (odbiór końcowy realizacji zadania) 50% wartości wynagrodzenia za prace wdrożeniowe zadania. 7 Wymagania odnośnie treści oferty Na potwierdzenie, że oferowana Regionalna platforma komunikacji elektronicznej spełnia wymagania określone przez Zamawiającego Wykonawca zobowiązany jest dołączyć do oferty następujące dokumenty: opis proponowanego rozwiązania potwierdzający, że oferowana Regionalna platforma komunikacji elektronicznej spełnia wymagania określone przez Zamawiającego. Wykonawca zobowiązany jest do wskazania producenta oraz nazwy oraz wersji oferowanego Oprogramowania oraz Oprogramowania narzędziowego oraz sposobu jego licencjonowania wraz ze wszystkimi niezbędnymi komponentami dla spełnienia oczekiwanych wymagań (wg Załącznik nr 14 do SIWZ) Strona: 24