OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 Załącznik nr 1 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Strona 1 z 72

2 Spis treści 1. Wprowadzenie Zastosowane skróty i pojęcia Przedmiot zamówienia Cel zamówienia Etapy realizacji Wykres Gantta Wymagania Wymagania w zakresie dostosowania oprogramowania aplikacyjnego Systemu epuap Wymagania funkcjonalne Wymagania w zakresie Portalu Interoperacyjności Schemat procesu publikacji Obiektu Interoperacyjności Opis schematu procesu publikacji Obiektu Interoperacyjności Metadane Obiektów Interoperacyjności Wymagania pozafunkcjonalne Wymagania w zakresie dostosowania oprogramowania aplikacyjnego Systemu epuap z wykorzystaniem produktów ergonomii Wymagania prawne Ograniczenia i zależności Wymagania w zakresie dokumentacji Wymagania w zakresie odbioru produktów Wymagania w zakresie zarządzania projektem Wymagania w zakresie zespołu projektowego Wymagania w zakresie gwarancji Strona 2 z 72

3 1. Wprowadzenie Niniejszy dokument stanowi Opis Przedmiotu Zamówienia w zakresie dostosowania oprogramowania aplikacyjnego platformy epuap oraz jego wdrożenia produkcyjnego na rozbudowanej infrastrukturze technicznej Zastosowane skróty i pojęcia Skrót / pojęcie Opis skrótu / pojęcia Administrator Użytkownik, który ma uprawnienia do zarządzania technicznymi komponentami Systemu epuap, w szczególności konfiguracją komponentów infrastruktury i oprogramowania. API (ang.) Application Programming Interface, interfejs programowania aplikacji sposób, rozumiany jako ściśle określony zestaw reguł i ich opisów, w jaki programy komunikują się między sobą Błąd kategorii A Błąd kategorii A dotyczy uniemożliwienia działania przynajmniej jednego z komponentów wytworzonych lub dostosowanych przez Wykonawcę, Zamawiający nie może korzystać z Systemu epuap i uzyskanie oczekiwanych efektów nie jest możliwe w inny sposób (obejście). Strona 3 z 72

4 Skrót / pojęcie Opis skrótu / pojęcia Błąd kategorii B Wystąpił problem polegający na co najmniej jednym z poniższych: główne komponenty Systemu epuap wytworzone bądź dostosowane przez Wykonawcę działają w sposób niezgodny z dokumentacją występują istotne ograniczenia w działaniu komponentów Systemu epuap wytworzonych bądź dostosowanych przez Wykonawcę (ale nie powodujące jego przeciążenia), nastąpiła awaria powodująca ograniczenie wydajności Systemu epuap lub jego komponentów wytworzonych bądź dostosowanych przez Wykonawcę, Zamawiający nie może korzystać z komponentów Systemu epuap wytworzonych bądź dostosowanych przez Wykonawcę, ale uzyskanie oczekiwanych efektów jest możliwe w inny sposób (obejście). Błąd kategorii B nie obejmuje sytuacji określonych błędem kategorii A. Błąd kategorii C Oznacza pojawienie się usterki komponentów Systemu epuap wytworzonych przez Wykonawcę o charakterze ergonomicznym nie mającej wpływu na wynik pracy użytkownika. Błąd kategorii C nie obejmuje sytuacji objętych błędem kategorii A i kategorii B. BPMN (ang. Business Process Modeling Notation) graficzna notacja służąca do modelowania procesów biznesowych. epuap Elektroniczna Platforma Usług Administracji Publicznej zbiór produktów projektu epuap-wkp rozwijanych w ramach projektu epuap2. Strona 4 z 72

5 Skrót / pojęcie Opis skrótu / pojęcia Dokumentacja powykonawcza Dokumentacja zawierająca co najmniej cele i zakres przedmiotu Umowy, charakterystykę minimalnych wymagań sprzętowych i systemowych, opis architektury fizycznej oprogramowania aplikacyjnego Systemu epuap, diagram kontekstowy zaproponowanego rozwiązania i model zachowania, instrukcje bezpieczeństwa oraz politykę bezpieczeństwa, wyniki Testów Akceptacyjnych wraz z raportami, sporządzona przez Wykonawcę w zakresie i formie określonej szczegółowo w Wymaganiach w zakresie dokumentacji Dokumentacja projektowa Dokumentacja sporządzona przez Wykonawcę i dostarczona Zamawiającemu w ramach realizacji Umowy w zakresie i formie określonej szczegółowo w wymaganiach w zakresie dokumentacji Dostawa Oznacza sprzedaż i dostarczenie do siedziby Zamawiającego przez Wykonawcę oprogramowania aplikacyjnego Systemu epuap wraz z odpowiednią dokumentacją epuap2 Projekt, którego realizacja planowana jest na lata , stanowiący kolejny etap realizacji docelowej architektury Systemu epuap. epuap-wkp Projekt zrealizowany w latach , którego rezultatem była budowa elektronicznej Platformy Usług Administracji Publicznej, w celu udostępnienia obywatelom usług świadczonych drogą internetową przez jednostki administracji publicznej. Instalacja Oznacza czynność umieszczenia przez Wykonawcę komponentów oprogramowania aplikacyjnego na infrastrukturze technicznej Systemu epuap Konfiguracja Oznacza zintegrowanie oprogramowania aplikacyjnego Systemu epuap z oprogramowaniem standardowym i infrastrukturą techniczną Systemu epuap w celu realizacji założonych celów Umowy Model Uproszczony obraz rzeczywistości. Prezentowany z pewnej perspektywy, na pewnym poziomie abstrakcji. PZP Plan Zarządzania Projektem Strona 5 z 72

6 Skrót / pojęcie Opis skrótu / pojęcia RfC / Request for Change (pol. Prośba o Zmianę) Czynności polegające na wprowadzaniu przez Wykonawcę zmian funkcjonalnych ponad określone w wymaganiach zawartych w Opisie Przedmiotu Zamówienia oraz czynności związane z modyfikacjami wykonywane przez Wykonawcę w ramach zleceń zgodnie z oczekiwaniami Zamawiającego oraz Użytkowników końcowych lub zlecenia wykonania usług konsultacyjnych. Użytkownik Podmiot lub osoba korzystająca z Systemu epuap. UML (ang. Unified Modeling Language) - Znormalizowany język modelowania oparty na notacji graficznej. Katalogu Administracji Publicznej (KAP), Katalog Podmiotów Publicznych Repozytorium Procesów Administracji Publicznej (RPAP) Skrytka System epuap Migracja Modyfikacja Środowisko testowe Język formalny - wykorzystywany do modelowania różnego rodzaju systemów. Umożliwia modelowanie wszystkich aspektów modelowanego systemu tj.: funkcjonalności, struktury oraz zachowania tworzonego systemu. Zawiera opisy podmiotów publicznych, utworzony na podstawie rejestru REGON. Produkt, który zostanie wykonany w odrębnym postępowaniu. Komponent Systemu epuap pozwalający na przekazywanie dokumentów pomiędzy usługobiorcami i usługodawcami usług publicznych (w obie strony) wraz z wystawieniem odpowiednich poświadczeń. System teleinformatyczny udostępniający Elektroniczną Platformę Usług Administracji Publicznej Przeniesienie oprogramowania aplikacyjnego Systemu epuap lub danych z baz danych Systemu epuap do rozbudowanej infrastruktury technicznej Systemu epuap Oznacza zmianę lub rozbudowę oprogramowania aplikacyjnego Systemu epuap lub zlecenie wykonania usług konsultacyjnych oraz aktualizację Dokumentacji powykonawczej w wyniku Zlecenia Modyfikacji, dokonaną w ramach RfC Środowisko epuap dostarczone przez Zamawiającego działające w czasie rzeczywistym, obsługujące testowych użytkowników i testowe dane. Strona 6 z 72

7 Skrót / pojęcie Środowisko produkcyjne Wdrożenie Opis skrótu / pojęcia Środowisko epuap dostarczone przez Zamawiającego działające w czasie rzeczywistym, obsługujące rzeczywistych użytkowników i rzeczywiste dane w określonym reżimie SLA. Oddanie do użytku oprogramowania aplikacyjnego Systemu epuap w Środowisku produkcyjnym. Strona 7 z 72

8 1.2. Przedmiot zamówienia Przedmiotem zamówienia jest: przeprowadzenie analizy i wykonanie dokumentacji projektowej dostosowywanego istniejącego oprogramowania aplikacyjnego Systemu epuap; dostosowanie istniejącego oprogramowania aplikacyjnego Systemu epuap wraz z dostawą, instalacją, konfiguracją i wdrożeniem dostosowanego oprogramowania aplikacyjnego w Środowisku testowym oraz uzupełnieniem dokumentacji projektowej i dostarczeniem jej przez Wykonawcę; dostawa, instalacja, konfiguracja i wdrożenie dostosowywanego oprogramowania aplikacyjnego Systemu epuap w Środowisku produkcyjnym wraz z zapewnieniem spójności danych Systemu epuap, opracowanie i dostarczenie dokumentacji powykonawczej modyfikacje powdrożeniowe oprogramowania aplikacyjnego w ramach RfC, w wymiarze 5000 roboczogodzin. przeniesienie majątkowych praw autorskich na dostosowywane oprogramowanie aplikacyjne Systemu epuap wraz z jego modyfikacjami; udzielenie licencji na oprogramowanie standardowe oraz jego aktualizacje, jeżeli zostanie ono dostarczone przez Wykonawcę; Świadczenie serwisu gwarancyjnego na dostarczone oprogramowane aplikacyjne Systemu epuap przez okres minimum 24 miesięcy licząc od dnia podpisania protokołu odbioru końcowego Cel zamówienia Celem zamówienia jest dostawa, instalacja, konfiguracja i wdrożenie oprogramowania aplikacyjnego na infrastrukturze technicznej Systemu epuap wraz z zapewnieniem modyfikacji oprogramowania aplikacyjnego w ramach RfC. Strona 8 z 72

9 2. Etapy realizacji Termin realizacji zamówienia nie później niż do dnia 16 grudnia 2013 roku. Wykonawca musi przeprowadzić prace w następujących etapach: Etap przygotowania przygotowanie, uzgodnienie i przekazanie PZP w terminie do 10 dni kalendarzowych od daty podpisania Umowy Etap I analiza i wykonanie dokumentacji projektowej dostosowywanego oprogramowania aplikacyjnego platformy epuap w terminie do 117 dni kalendarzowych od daty podpisania Umowy; Etap II dostosowanie i dostawa oprogramowania aplikacyjnego Systemu epuap wraz z instalacją, konfiguracją i wdrożeniem dostosowanego oprogramowania aplikacyjnego w Środowisku testowym wraz z testami wewnętrznymi Wykonawcy oraz uzupełnieniem dokumentacji projektowej i dostarczeniem jej przez Wykonawcę w terminie do 192 dni kalendarzowych od daty zaakceptowania Etapu I; przeniesienie majątkowych praw autorskich na dostosowywane oprogramowanie aplikacyjne Systemu epuap, udzielenie licencji na oprogramowanie standardowe, jeżeli zostanie ono dostarczone przez Wykonawcę; Etap III dostawa, instalacja, konfiguracja i wdrożenie produkcyjne dostosowywanego oprogramowania aplikacyjnego Systemu epuap w Środowisku produkcyjnym wraz z zapewnieniem spójności danych Systemu epuap, opracowanie i dostarczenie dokumentacji powykonawczej w terminie do 37 dni kalendarzowych od daty zaakceptowania Etapu II; Zapewnienie modyfikacji powdrożeniowych oprogramowania aplikacyjnego w ramach RfC, w wymiarze 5000 roboczogodzin, liczone od dnia zaakceptowania Etapu II do wyczerpania przyjętego limitu roboczogodzin jednak nie później niż do dnia r. Świadczenie serwisu gwarancyjnego na dostarczone oprogramowane aplikacyjne Systemu epuap przez okres minimum 24 miesięcy licząc od dnia podpisania protokołu odbioru końcowego Wykres Gantta Strona 9 z 72

10 3. Wymagania 3.1. Wymagania w zakresie dostosowania oprogramowania aplikacyjnego Systemu epuap Kod wymagania Opis wymagania W.01 Wykonawca musi dostosować aktualne oprogramowanie aplikacyjne epuap zgodnie z poniższymi wymaganiami, dla następujących komponentów: 1. Katalog Administracji Publicznej 2. Katalog Usług Publicznych 3. Centralne Repozytorium Wzorów Dokumentów Elektronicznych 4. Krajowy Katalog Serwisów Publicznych 5. Krajowa Szyna Usług 6. Skrytki 7. Elektroniczny Skład Dokumentów 8. Doręczyciel 9. Koordynator 10. Silnik Formularzy 11. Środowisko Budowy Aplikacji 12. Osobisty Skład Dokumentów 13. Walidator 14. Usługi TSL 15. Usługi bezpieczeństwa 16. Portal epuap 17. Portal Interoperacyjności Zamawiający dopuszcza w zakresie dostosowania aktualnego oprogramowania aplikacyjnego epuap rozbudowę istniejącego oprogramowania aplikacyjnego lub wytworzenie oprogramowania aplikacyjnego równoważnego funkcjonalnie z obecnym oprogramowaniem aplikacyjnym epuap oraz poniższymi wymaganiami. Zamawiający dopuszcza wykorzystanie oprogramowania standardowego jako oprogramowania dodatkowego, natomiast nie dopuszcza się realizacji ww. komponentów w całości opartych o oprogramowanie standardowe. Strona 10 z 72

11 W.02 Wykonawca musi dostarczyć niezbędne komponenty Systemu epuap oraz zapewnić ich dostosowanie, konfigurację i wdrożenie w dwóch ośrodkach przetwarzania epuap wskazanych przez Zamawiającego, zlokalizowanych na terenie Warszawy, działających w trybie active-active. W.03 Wykonawca musi zapewnić 5000 roboczogodzin w ramach RfC na modyfikacje oprogramowania aplikacyjnego Systemu epuap do ich wyczerpania jednak nie później niż do dnia r. W.04 Wykonawca musi zapewnić przeniesienie i wdrożenie rozbudowanej wersji oprogramowania aplikacyjnego Systemu epuap na Środowisko produkcyjne z zachowaniem obowiązujących parametrów dostępności Systemu epuap i okien serwisowych. Zamawiający zastrzega, że dostęp do lokalizacji Systemu epuap może wymagać posiadania poświadczenia bezpieczeństwa dostępu do informacji niejawnych co najmniej na poziomie poufne. W.05 Wykonawca musi zapewnić poprawne działanie rozbudowanego oprogramowania aplikacyjnego z pozostałymi aktualnie działającymi modułami Wymagania funkcjonalne Kod wymagania WF.1 Opis wymagania Wykonawca musi dostosować oprogramowanie aplikacyjne Systemu epuap spełniając poniższe wymagania. 1. Wymagania w zakresie Katalogu Administracji Publicznej (KAP) WF.2 WF.3 WF.4 KAP musi przechowywać pozyskane z GUS (jako podzbiór REGON) informacje o podmiotach publicznych Identyfikatorem podmiotu w KAP musi być identyfikator nadany przez GUS (numer REGON) KAP musi zapewniać aktualizację pozyskanych z GUS (jako podzbiór REGON) informacji o podmiotach publicznych, w oparciu o udostępnione przez GUS API, służące do pozyskiwania informacji o danych z rejestru REGON. Strona 11 z 72

12 WF.5 WF.6 WF.7 WF.8 WF.9 WF.10 WF.11 WF.12 KAP musi udostępniać API (powszechnie dostępne) pozwalające na przepytywanie i pobieranie informacji z Katalogu Administracji Publicznej Aktualizacja może zachodzić w trybach przesyłania na żądanie pełnego zbioru (na nośniku danych) lub poprzez odpytywanie API GUS o konkretny numer REGON i porównywanie uzyskanych danych z danymi istniejącymi w KAP. KAP musi wykorzystywać API udostępnione przez GUS umożliwiające pobranie danych z rejestru REGON. KAP musi filtrować pobrane dane wg wskazanego algorytmu. KAP musi posiadać informację o dacie aktualizacji rejestru REGON KAP musi spełniać rolę danych referencyjnych dla innych produktów epuap KAP zapewnia mechanizmy umożliwiające aktualizację danych w innych produktach epuap. Produkty, które dublują w swojej architekturze dane z rejestru słownika podmiotów publicznych, a przeprojektowanie ich w celu zastosowania referencji jest niezasadne, muszą zostać rozbudowane o mechanizm aktualizacji. Aktualizacja musi być uruchamiana za każdym razem, gdy odebrana zostanie informacja o zaktualizowaniu słownika podmiotów publicznych. KAP musi posiadać tylko aktualnie udostępniane przez GUS dane o podmiotach publicznych. KAP musi pobierać z GUS słownik typów podmiotów publicznych, który może być rozszerzany w zakresie typów podmiotów publicznych oraz dla każdego podmiotu publicznego będzie istniała możliwość dodatkowego nadania odpowiedniego typu bądź typów. 2. Wymagania w zakresie Katalogu Usług Publicznych (KUP) WF.13 WF.14 KUP musi umożliwiać definiowanie dla każdego typu usługi sposobu jej opisu (szablonu). Dla usług, które zostały opisane w poprzedniej wersji szablonu musi istnieć możliwość uzupełnienia i zmiany opisu z wykorzystaniem szablonu obowiązującego. KUP musi informować właścicieli usług o konieczności dostosowania opisu usług do nowej wersji szablonu opisu usługi. Informacja musi być dostarczona za pomocą ESP. Strona 12 z 72

13 WF.15 Opis usługi podzielony jest na część ogólną i cześć szczegółową. W ramach części ogólnej opisu usługi ustalana jest opcja dostępności tej usługi na terenie całego kraju oraz definiowane są wymagane poziomy autoryzacji do zrealizowania usługi (Profil Zaufany, Klucz Publiczny, drogą elektroniczną, usługa realizowana wyłącznie osobiście, i inne) W ramach części szczegółowej usługi, tylko o ile opcja dostępności tej usługi na terenie całego kraju w części ogólnej jest włączona, ustawiona może być dostępność usługi na terenie całego kraju. Nie jest to jednak rozwiązanie domyślne. W ramach części szczegółowej usługi, domyślnym rozwiązaniem jest ustawienie dostępności usługi na terenie administracyjnym podmiotu publicznego, zdefiniowanego w TERYT. W ramach części szczegółowej usługi definiowane są poziomy autoryzacji (wymagane do zrealizowania tej usługi). Poziomy te są zgodne ze zdefiniowanymi w części ogólnej usługi. System weryfikuje i informuje użytkownika, czy definiowany poziom autoryzacji (w ramach usługi) jest zgodny z ustawieniami poziomu autoryzacji Skrytek podmiotu. W ramach części szczegółowej ustalenie poziomu świadczenia usługi publicznej zgodnego ze standardami SL zgodnymi z zaleceniami Komisji Europejskiej (1-informacja o usłudze; 2-jednokierukowa interakcja tzn. informacja wraz możliwością pobrania i wydruku formularzy do wykorzystania w obiegu papierowym; 3- dwukierunkowa interakcja tzn. dostępność formularzy online oraz możliwość zainicjowania sprawy drogą elektroniczną ; 4-możliwość załatwienia całej sprawy drogą elektroniczną; 5- personalizacja usługi tzn. możliwość automatycznego dostarczania konkretnych usług np. pełna integracja z rejestrami publicznymi); WF.16 Części szczególne opisów usługi oraz części ogólne opisu usługi realizowanych na podstawie prawa lokalnego muszą być dostarczane przez podmioty publiczne usługodawców poszczególnych usług.. WF.17 Opisy usług dostarczane przez podmioty publiczne dostarczane mogą być bezpośrednio z wykorzystaniem odpowiednich interaktywnych formularzy na epuap i/lub poprzez wskazanie jednego lub więcej systemów (URL-i) Strona 13 z 72

14 udostępniających tę informacje poprzez określone przez epuap API. WF.18 WF.19 WF.20 WF.21 Wykorzystywane w opisie usługi słowniki i reprezentacje informacji/wiedzy muszą być zgodne z ustanowionymi w tym zakresie standardami (udostępnianymi w repozytorium interoperacyjności). Jeden i ten sam system (URL) musi dostarczać informacje o usługach różnych podmiotów publicznych (może być wskazany jako źródło przez wiele różnych podmiotów), przy czym w uzyskanej z konkretnego systemu (URLa) ignorowane muszą być opisy usług podmiotów, które nie wskazały tego systemu jako źródła informacji o swoich usługach. Wszystkie opisy usług (części ogólne i szczególne) muszą być udostępniane poprzez publicznie dostępne API (bez autoryzacji, uwierzytelnienia, podpisów, itp.) umożliwiające pobieranie opisów z wykorzystaniem kryteriów bazujących na atrybutach i słownikach używanych w opisach usług dostarczanych przez podmioty publiczne. Wszystkie wskazane przez podmioty publiczne systemy, muszą być powiadamiane o zmianach w zakresie opisów realizowanych usług. WF.22 KUP musi umożliwiać każdemu użytkownikowi (bez potrzeby uwierzytelnienia i autoryzacji) przeglądanie i przeszukiwanie zgromadzonych w nim opisów usług z wykorzystaniem atrybutów i słowników wykorzystywanych przez podmioty publiczne w procesie dostarczania informacji o usługach, a w szczególności: Wyróżniane graficznie i tekstowo są usługi o zdefiniowanych różnych poziomach świadczenia SL. System będzie rozróżniał wizualnie usługi do realizacji za pomocą Profilu Zaufanego (PZ), klucza publicznego bądź usługi realizowane wyłącznie osobiście. Prezentacja poziomu świadczenia usług musi być widoczna także na poziomie kategorii życiowych systemu epuap. Portal umożliwia przeglądanie (w pierwszej kolejności) usług zgodnych z jego przynależnością terytorialną, w oparciu o obszar dostępności zdefiniowany w danych szczegółowych usługi. Prezentowanie graficznie poziomów świadczenia usług; Wyróżnianie graficznie określonych kategorii usług, w szczególności usług RPAP. Jeżeli usługa jest realizowana za pomocą procesu z RPAP, wówczas Strona 14 z 72

15 istnieje bezpośrednie wskazanie w portalu epuap do procesu z RPAP (możliwość przejrzenia podglądu Bazowego Procesu Biznesowego na poziomie Opisu Usługi albo podglądu Właściwego Procesu Biznesowego na poziomie Karty Usług) oraz prezentowane są pozostałe możliwe do uzyskania informacje zdefiniowane w RPAP (np. usługi poprzednie wymagane do realizacji, usługi następne kolejne do realizacji wynikające z procesu, powiązane dokumenty elektroniczne, powiązane role odpowiadające do wykonanie usługi); Prezentowane akty prawne, na mocy których ustalono opis usługi, są aktywnymi linkami odnoszącymi się do ISAP (Internetowego Systemu Aktów Prawnych ) bądź do innego ogólnie dostępnego systemu aktów prawnych; WF.23 KUP musi umożliwiać przeglądanie i wyszukiwanie usług z wykorzystaniem metod, atrybutów, pojęć i słowników zorientowanych na klienta, a w szczególności: Umożliwia przeszukiwanie usług według wymaganego poziomu autoryzacji zdefiniowanego na poziomie ogólnym oraz na poziomie szczegółowym usługi. Umożliwia przeszukiwanie usług według posiadanego, przez klienta, poziomu autoryzacji (jeżeli obywatel posiada PZ, wówczas w pierwszej kolejności wskazywane są usługi, które może zrealizować za pomocą posiadanego poziomu autoryzacji w systemie epuap. Udostępnienie wyszukiwania usług podmiotów publicznych po klasyfikacji terytorialnej urzędu oraz po klasyfikacji terytorialnej usługi. Wpisywanie fraz wyszukiwania powinno być oparte o autouzupełnianie teksty, podpowiedzi w oparciu o znane i często wykorzystywane frazy. Wyniki wyszukiwania należy sortować od najbardziej trafnych do najmniej trafnych. Umożliwia wyszukiwanie wg podmiotów publicznych udostępniających usługi (nazwa i adres), wg zasady wiem, w którym urzędzie jest usługa, z której potrzebuję skorzystać. Umożliwia wyszukiwanie na podstawie poziomu dojrzałości usługi (SL). Umożliwia wyszukiwanie w oparciu o występujące w opisie usługi Strona 15 z 72

16 identyfikatory aktów prawnych stanowiących podstawę doświadczenia usługi. WF.24 WF.25 WF.26 WF.27 WF.28 KUP musi posiadać mechanizm umożliwiający wyszukiwanie usługi na podstawie atrybutów i pojęć zorientowanych na klienta na podstawie opisów w standardowej strukturze przekazywanej przez podmioty publiczne. Mechanizmy wyszukiwania usług muszą mieć możliwość zarządzania konfiguracją sposobów wyszukiwania. KUP musi posiadać narzędzia zestawiające zgromadzone opisy usług z wykazem podmiotów publicznych z KAP, służące monitorowaniu wywiązywania się podmiotów z obowiązków dostarczania do SSDIP informacji o usługach publicznych. Dokumenty elektroniczne muszą być weryfikowane pod kątem zgodności ze wzorem dokumentu zawartym w Centralnym Repozytorium Wzorów Dokumentów Elektronicznych (CRWDE), zanim zostaną wysłane. Przez 5 lat od wejścia w życie nowego rozporządzenia dotyczącego dokumentów elektronicznych, KUP musi dopuszczać możliwość weryfikacji zgodności ze wzorem dokumentu z Lokalnego Repozytorium Wzorów Dokumentów (LRWD). Wzory dokumentów opublikowane w lokalnych repozytoriach przed dniem wejścia w życie rozporządzenia udostępnia się w tych repozytoriach do czasu umieszczenia ich w CRWDE. WF.29 W części szczegółowej usługi mogą być realizowane za pomocą dedykowanych formularzy z Silnika Formularzy. Formularze te przeznaczone są do utworzenia dokumentu elektronicznego, którego szablon znajduje się w CRWDE: Formularz prezentowany do realizacji usługi musi zawierać nazwę usługi, dla której został zdefiniowany. WF.30 KUP musi dostarczać informacje związane z wykonaniem określonego etapu prac nad definicją usługi. Informacje te muszą być dostarczone do właściwych ról w procesie po stronie Podmiotu Publicznego opracowującego opis usługi oraz Administratora KUP. Notyfikacje podlegają dostarczaniu za pośrednictwem ESP i są związane ze zdarzeniami: zakończenia przygotowywania opisu usługi przez podmioty publiczne, Strona 16 z 72

17 odmowy opublikowania usługi po weryfikacji Administratora KUP, akceptacji opisu usługi i publikacji opisu przez Administratora KUP. WF.31 KUP musi udostępniać mechanizm statystyk wykorzystania katalogu usług przez użytkowników. System dostarcza monitor statystyk dla administratora Katalogu Usług lub innego użytkownika, któremu zostaną nadane odpowiednie uprawnienia. System udostępnia statystyki z podziałem na wszelkie kategorie występujące w katalogu. System umożliwia generowanie statystyk w określonych zakresach dat. System umożliwia generowanie statystyk dla dowolnie wybranych usług. System umożliwia definiowania zapytań do bazy danych w celu ich użycia w przyszłości już bez potrzeby ponownego ich definiowania. System umożliwia parametryzację zdefiniowanych zapytań z poziomu interfejsu użytkownika. System umożliwia śledzenie ścieżek poruszania się użytkowników w katalogu usług. System umożliwia definiowanie celów, których zrealizowanie w katalogu usług przez użytkownika jest raportowane. 3. Wymagania w zakresie Centralnego Repozytorium Wzorów Dokumentów Elektronicznych (CRWDE) WF.32 WF.33 CRWDE musi udostępniać zestandaryzowane API, pozwalające zewnętrznym aplikacjom na wyszukiwanie oraz pobranie wzoru dokumentów. CRWDE musi udostępniać graficzny interfejsu użytkownika umożliwiający wizualizację wzoru dokumentu. CRWDE musi umożliwiać zaprezentowanie wizualne części dokumentu, dla których złożono podpis bądź kilka podpisów. WF.34 WF.35 CRWDE musi zapewniać możliwość poprawnej obsługi przechowywanych wzorów W3C (nawet gdy W3C przestanie udostępniać schematy). CRWDE musi weryfikować zgodność dokumentów elektronicznych ze wzorami dokumentów w nim zawartymi i udostępniać tę usługę innym produktom i systemom. Strona 17 z 72

18 WF.36 WF.37 CRWDE musi weryfikować aktualność użytego wzoru dokumentu. W przypadku wygaśnięcia wzoru dokument elektroniczny może być wysłany najpóźniej 6 m-cy od daty wygaśnięcia wzoru dokumentu CRWDE musi udostępniać zewnętrzne oprogramowanie aplikacyjne, ogólnie dostępne dla użytkowników systemu, umożliwiające wizualizację dokumentu elektronicznego zapisanego lokalnie na dysku. Pobrany pakiet zapisanego dokumentu elektronicznego musi zawierać przynajmniej: Właściwy dokument elektroniczny; Schemat wizualizacji. Oprogramowanie musi umożliwiać prezentacje dokumentu dostarczonego wraz z jego wizualizacją oraz prezentować dokument elektroniczny w sposób umożliwiający użytkownikowi jego odczytanie również w trybie offline. WF.38 WF.39 CRWDE musi dopuszczać zapisywanie załączników w formatach: doc, docx, gif, jpg, (jpeg), ods, odt, pdf, png, rtf, svg, tif, (tiff), txt, xls, xlsx, xml. CRWDE musi przechowywać wzory specjalne takie jak UPO, UPP, UPD, UPN, które analogicznie do pozostałych wzorów są dostępne pod adresem URL. 4. Wymagania w zakresie Krajowego Katalogu Serwisów Publicznych (KKSP) WF.40 Krajowy Katalog Serwisów Publicznych musi umożliwiać prowadzenie ewidencji definicji serwisów usług w postaci katalogowej: umożliwia wyszukiwanie definicji serwisów w katalogu, umożliwia pobranie definicji wskazanego serwisu usługi, definicja serwisu obejmuje opis danych wejściowych i wyjściowych serwisu, sposobu jego uruchamiania wraz z właściwymi parametrami technicznymi dla komunikacji z systemem obsługujący serwis. WF.41 WF.42 Krajowy Katalog Serwisów Publicznych musi udostępniać graficzny interfejs użytkownika umożliwiający konfigurowanie platform regionalnych i dziedzinowych, których katalogi serwisów publicznych będzie wykorzystywał. Definicje serwisów muszą być udostępniane w standardzie umożliwiającym wykorzystanie ich przy wytwarzaniu aplikacji z użyciem popularnych aplikacji deweloperskich. WF.43 Krajowy Katalog Serwisów Publicznych musi umożliwiać subskrypcję regionalnych i dziedzinowych katalogów serwisów publicznych prowadzone Strona 18 z 72

19 przez platformy dziedzinowe i regionalne. WF.44 Krajowy Katalog Serwisów Publicznych musi udostępniać możliwość subskrypcji katalogu. Dla zewnętrznych klientów subskrypcja jest udostępniana w postaci kanału RSS. WF.45 Krajowy Katalog Serwisów Publicznych musi udostępniać funkcjonalności zarządzania katalogiem przez jego administratora: typu ręczne wprowadzanie i konfigurowanie usług systemów nie wspierających standardów Krajowej Szyny Usług, wykrywanie konfliktów, niejednoznaczności w katalogu (np. z danych dostarczanych przez systemy wynika, że jedna instytucja ma dwie ogólne skrzynki podawcze). 5. Wymagania w zakresie Krajowej Szyny Usług (KSU) WF.46 WF.47 WF.48 WF.49 WF.50 WF.51 KSU musi udostępniać jednolity i ustandaryzowany dostęp do usług publicznych dla wszystkich stron komunikacji. KSU musi udostępniać usługi zdefiniowane w KKSP, w oparciu o zawarte tam definicje. KSU musi mieć możliwość dokonywania konwersji metody transportu dla dostosowania się do interfejsu usług. KSU musi zapewniać automatyczną identyfikację adresu usługi obsługi dokumentu na podstawie właściwości przekazywanych dokumentów elektronicznych (np. ustala właściwość miejscową urzędu) i automatyczne skierowanie dokumentu na właściwy adres. KSU musi mieć możliwość udostępniania usług działających zarówno synchronicznie jak i asynchronicznie. KSU musi pozwalać na określenie dla poszczególnych usług ich sposobu realizacji (synchroniczne lub asynchroniczne). WF.52 KSU musi pozwalać na ustalanie sposobu realizacji usługi (synchroniczne/asynchroniczne) po wywołaniu usługi. WF.53 KSU musi posługiwać się w komunikacji następującym protokołem komunikacji: każde wywołanie usługi poprzez KSU zawiera w sobie URL adresu zwrotnego, na który należy przekazać asynchroniczną odpowiedź usługi, Strona 19 z 72

20 KSU przekazuje ten adres zwrotny do usługi, usługa realizowana synchronicznie odsyła w odpowiedzi znacznik, że została zrealizowana synchronicznie, usługa realizowana asynchronicznie odsyła w odpowiedzi na wywołanie informację, że realizacja odbędzie się asynchronicznie, jeśli usługa realizowana asynchronicznie zostanie wywołana z pustym lub błędnym URL adresu zwrotnego, w odpowiedzi na wywołanie zwraca komunikat o błędzie i nie zostaje uruchomiona, odpowiedź asynchroniczna usługi zostaje przez usługę wysłana bezpośrednio na przekazany adres zwrotny, bez wywoływania usług KSU. WF.54 KSU musi umożliwiać za swoim pośrednictwem korzystanie z innych usług epuap: uwierzytelnienie wywołującego usługę za pomocą Usług bezpieczeństwa, walidację podpisów pod dokumentami. WF.55 KSU musi dostarczać funkcje inteligentnej obsługi zapytań rejestrowych, polegającej na: przyjmowaniu zapytań rejestrowych zapisanych za pomocą ustalonego języka, identyfikacji właściwych rejestrów zawierających niezbędne informacje, tworzeniu dokumentów zapytań do rejestrów o potrzebne informacje i przesyłaniu ich do właściwych usług rejestrowych, przyjmowaniu odpowiedzi z rejestrów, korelacji i łączeniu odpowiedzi z rejestrów w wynik zadanego zapytania. WF.56 WF.57 WF.58 WF.59 W obsłudze zapytań rejestrowych KSU musi korzystać z usług realizowanych w trybie synchronicznym. KSU musi umożliwiać tworzenie tymczasowych, jednorazowych skrytek zwrotnych służących odebraniu odpowiedzi asynchronicznej od usługi klientom, których systemy nie dają takiej możliwości. Utworzenie Skrytki Zwrotnej nie wymaga posiadania konta na epuap. Skrytka Zwrotna musi być tworzona na określony w konfiguracji KSU czas. Strona 20 z 72