Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regio- nalnego w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego 2014-2020 oraz ze środków budżetu państwa

Mazowiecki Urząd Wojewódzki w Warszawie Xx.

Xxxxxxx 0/0 00-000 Xxxxxxxx

Opis Przedmiotu Zamówienia

Przedmiotem zamówienia jest zaprojektowanie, wykonanie i wdrożenie Platformy stanowiącej kompleksowe rozwiąza- nie informatyczne, zintegrowane z istniejącym systemem za- rządzania dokumentacją (EZD), pozwalające na udostępnie- nie wysokiej jakości e-usług przez Zamawiającego oraz pod- ległe Wojewodzie Mazowieckiemu jednostki administracji rządowej, wraz z wykonaniem Formularzy elektronicznych ePUAP, w ramach Projektu WiPER.

Opis Przedmiotu Zamówienia strona 2

Spis treści

Spis tabel 3 Spis

rysunków 3 1. Przyjęte

definicje 4 2. Wstęp

............................................................................................... 12 3. Przedmiot zamówienia

..................................................................... 13 3.1. Produkty przedmiotu zamówienia

............................................................ 18 4. Projekt harmonogramu realizacji przedmiotu zamówienia ............. 19 4.1. Wymagania w zakresie dokumentacji

...................................................... 20 5. Koncepcja Platformy

........................................................................ 25 5.1. Portal dostępowy

................................................................................... 26 5.2. Moduł komunikacji

................................................................................. 29 5.2.1. Interfejs zaawansowanej

pomocy tzw. wirtualny asystent ............... 29 5.2.2. Usługa tłumacza migowego online

................................................ 30 5.2.3. Czat z pracownikiem Zamawiającego

............................................. 31 5.2.4. Przekierowania do serwisów internetowych i

Biuletynu Informacji

Publicznej poszczególnych jednostek administracji rządowej ........... 31 5.2.5. Rezerwacja wizyt ......................................................................... 32 5.2.6. Otrzymywanie powiadomień

w formie SMS lub mail ....................... 32 5.3. Moduł Open Data

................................................................................... 33 5.4. Moduł usługowy

..................................................................................... 35 5.4.1. Katalog e-usług

............................................................................ 37 5.5. Moduł Administratora

............................................................................. 42 5.6. Szyna danych ESB

.................................................................................. 42 6. Wymagania w zakresie

Platformy .................................................... 43 6.1. Wymagania ogólne

................................................................................ 43 6.2. Wymagania funkcjonalne

........................................................................ 44 6.3. Wymagania w zakresie przepisów

prawa ................................................. 52 6.4. Wymagania w zakresie bezpieczeństwa przetwarzania danych .................. 53 6.5. Wymagania w zakresie integracji

............................................................ 55 6.6. Wymagania w zakresie zasilenia Platformy danymi ................................... 55 6.7. Wymagania w zakresie sposobu realizacji

................................................ 56 6.8. Wymagania w zakresie testów

................................................................ 58 6.9. Wymagania w zakresie Szkoleń i

Konferencji 61 7. Wymagania w zakresie infrastruktury

techniczno–systemowej ..... 65 7.1. Wymagania ogólne

................................................................................ 65 7.2. Struktura środowisk

infrastruktury techniczno–systemowej 66 8. Wymagania w zakresie

świadczenia hostingu i replikacji danych 68 9. Wymagania w zakresie poziomu

świadczenia usług w zakresie Platformy

................................................................................................. 72 10. Wymagania w

zakresie gwarancji, jakości, rozwoju Platformy i usług serwisowych

............................................................................................ 74 10.1. Gwarancja i Serwis

gwarancyjny ........................................................... 74 10.2. Usługi aktualizacji i rozwoju Platformy w ramach Nadzoru autorskiego Załączniki

......................................................................................... 74 11. 1. Załącznik nr 1.

Przykładowa e-usługa 74

Opis Przedmiotu Zamówienia strona 3

Spis tabel

Tabela 1. Terminy realizacji przedmiotu zamówienia 19 Tabela

2. Zakres wymaganej Dokumentacji dostarczanej przez Wykonawcę

systemu 21 Tabela 3. Wykaz e-usług, które

mają zostać udostępnione w wyniku wdrożenia ..38 Tabela 4. Wymagania ogólne

............................................................................43 Tabela 5. Wymagania funkcjonalne

...................................................................44 Tabela 6. Wymagania zgodności z

następującym aktami prawnymi w aktualnie

obowiązujących wersjach lub aktami je zastępującymi ...............................52 Tabela 7. Wymagania w zakresie bezpieczeństwa przetwarzania danych .............53 Tabela 8. Wymagania w zakresie integracji ........................................................55 Tabela 9. Ramowe parametry jakości świadczenia usług. 72

Spis rysunków

Rysunek 1. Model architektury Platformy 12 Rysunek

2. Model architektury Platformy ...........................................................25 Rysunek 3.

Schemat powiązań realizowanych za pomocą profilu użytkownika ......28 Rysunek 4. Schemat funkcjonowania usługi języka migowego online w ramach

Platformy 30

Opis Przedmiotu Zamówienia strona 4

1. Przyjęte definicje

1. Administrator – pracownik Zamawiającego posiadający konto o uprawnieniach Administratora Platformy, odpowiedzialny za wszystkie czynności związane z za- rządzaniem systemem, jak również umieszczanie danych w każdym Komponen- cie Platformy.

2. API – (ang. application programming interface) interfejs programistyczny apli- kacji, łączący Platformę z innymi systemami, w tym: EZD, ePUAP, Profil Zau- fany/jego następca.

3. Audyty – audyt bezpieczeństwa Platformy i audyt kodu źródłowego Platformy, które będą prowadzone przez osoby działające na zlecenie Zamawiającego.

4. Błąd Kategorii A – stan Platformy mający negatywny wpływ na jej prawidłowe funkcjonowanie rozumiany jako niedostępność Platformy w sposób uniemożli- wiający korzystanie z Platformy i uzyskanie oczekiwanych efektów nie jest moż- liwe w inny sposób (obejście).

5. Błąd Kategorii B – stan Platformy mający negatywny wpływ na jej prawidłowe funkcjonowanie, nieobejmujący sytuacji określonych Błędem Kategorii A, rozu- miany jako:

a) działanie Platformy w sposób niezgodny z Dokumentacją powykonaw- czą,

b) nastąpiła awaria powodująca ograniczenie w działaniu Platformy w tym ograniczenia jej wydajności,

c) Zamawiający nie może korzystać z Platformy wykonanej przez Wyko- nawcę, ale uzyskanie oczekiwanych efektów jest możliwe w inny spo- sób (obejście).

6. Błąd Kategorii C – stan Platformy mający negatywny wpływ na jej prawidłowe funkcjonowanie, nieobejmujący sytuacji określonych Błędem Kategorii A i Kate- gorii B, rozumiany jako:

a) drobne wady lub usterki niemające wpływu na dostępność Platformy ,

b) drobne wady lub usterki Platformy o charakterze ergonomicznym nie- mające wpływu na wynik pracy użytkownika.

7. CPD – Centrum Przetwarzania Danych – zasoby informatyczne Zamawiającego.

8. CRD – Centralne Repozytorium Dokumentów – Centralne repozytorium w rozu- mieniu art. 19 b) ustawy z dnia 10 stycznia 2014 r. o informatyzacji działalności

Opis Przedmiotu Zamówienia strona 5

podmiotów realizujących zadania publiczne oraz niektórych innych ustaw (Dz.U.2017.570 j.t.).

9. DIP - Dokument Inicjujący Projekt – element Dokumentacji dotyczący zarzą- dzania realizacją przedmiotu Umowy opracowany przez Wykonawcę, na podsta- wie Umowy i OPZ, opisujący standardy i procedury projektowe w zakresie nieu- regulowanym w Umowie, podlegający odbiorowi przez Xxxxxxxxxxxxx.

10. Dni Robocze – kolejne dni od poniedziałku do piątku w godzinach 08:00 – 16:00 za wyjątkiem dni wolnych, zgodnie z ustawą z dnia 18 stycznia 1951 r. o dniach wolnych od pracy (Dz.U.2015.90 j.t.).

11. Dokumentacja – wszelka dokumentacja wytworzona i dostarczana przez Wy- konawcę w ramach realizacji Umowy jak również informacje zapisane na innych nośnikach, w tym informatycznych nośnikach danych, w szczególności takie ele- menty jak: DIP, Projekt techniczny, projekt interfejsu graficznego, Dokumenta- cja powykonawcza, Dokumentacja Formularzy elektronicznych ePUAP, materiały szkoleniowe, Scenariusze testowe, dokumentacja powstała w wyniku realizacji wymagań odbiorów, dokumentacja powstała w wyniku realizacji wymagań za- rządzania projektem, dokumenty robocze wytworzone przez Wykonawcę w ra- mach realizacji Umowy; za Dokumentację uznaje się także wytworzenie i aktua- lizację Dokumentacji w ramach Zleceń oraz w okresie gwarancji i świadczenia Serwisu gwarancyjnego.

12. Dokumentacja Formularzy elektronicznych ePUAP - dokumentacja prze- kazana wraz z Formularzami elektronicznymi ePUAP, w zakresie i formie okre- ślonej w niniejszym OPZ.

13. Dokumentacja powykonawcza – dokumentacja Platformy przekazana w za- kresie i formie określonej w niniejszym OPZ.

14. e-usługa - usługa świadczona drogą elektroniczną przez sieć telekomunika- cyjną, będąca odzwierciedleniem sprawy realizowanej w sposób tradycyjny w MUW i JAR.

15. ePUAP - Elektroniczna Platforma Usług Administracji Publicznej, w aktualnej wersji.

16. ESB – szyna usług, (ang. Enterprise Service Bus), korporacyjna magistrala usług, dodatkowa warstwa pośrednia w wielowarstwowej architekturze syste- mów informatycznych umożliwiająca zastosowanie koncepcji SOA (ang. Service-

Oriented Architecture). Umożliwia dynamiczne przyłączenie

i odłączenie usług wchodzących w skład systemu informatycznego.

Opis Przedmiotu Zamówienia strona 6

17. Etap - część przedmiotu Umowy podlegająca odbiorowi Protokołem Odbioru Etapu.

18. EZD – system Elektronicznego Zarządzania Dokumentacją użytkowany w MUW autorstwa Podlaskiego Urzędu Wojewódzkiego.

19. Formularz elektroniczny ePUAP – element Oprogramowania Dedykowanego zbudowany na potrzeby publikacji przez Zamawiającego na ePUAP, zgodnie z obowiązującymi instrukcjami i standardem dokumentów ePUAP, służący do udo- stępnienia e-usług wskazanych w katalogu e-usług niniejszego OPZ, umożliwia- jący komunikację Zamawiającego z obywatelami poprzez wymianę dokumentów elektronicznych.

20. Formularz elektroniczny - element Platformy (Modułu usługowego), służący do udostępnienia e-usług wskazanych w katalogu e-usług niniejszego OPZ,

umożliwiający komunikację Zamawiającego z obywatelami poprzez wymianę do- kumentów elektronicznych.

21. Godziny Robocze – godziny od 08:00 do 16:00 w Dni Robocze.

22. JAR – Jednostki Administracji Rządowej, będące obok MUW beneficjentem przedmiotu Umowy.

23. JRWA – Jednolity Rzeczowy Wykaz Akt.

24. Kierownik Projektu Wykonawcy – osoba reprezentująca Wykonawcę

w ramach Umowy, posiadająca uprawnienia do podejmowania i komunikowania decyzji związanych z Umową w imieniu Wykonawcy.

25. Kierownik Projektu Zamawiającego – osoba reprezentująca Zamawiają-

cego w ramach Umowy, posiadająca uprawnienia do podejmowania i komuniko- wania decyzji związanych z Umową w imieniu Xxxxxxxxxxxxx.

26. Komponent – niezależnie wytworzony, skompilowany moduł programowy, sta- nowiący część oprogramowania dedykowanego, udostępniający swą funkcjonal-

ność za pomocą jednoznacznie zdefiniowanego interfejsu, zdolny do współdzia- łania z innymi Komponentami. W architekturze Platformy to: Portal dostępowy, Moduł komunikacji, Moduł Open Data, Moduł usługowy, Moduł Administratora, Szyna danych ESB umożliwiająca integrację rozwiązań.

27. Konferencja – oznacza Konferencję podczas której zaprezentowana zostanie Platforma, zgodnie z wymaganiami określonymi w niniejszym OPZ.

Opis Przedmiotu Zamówienia strona 7

28. Modyfikacja – zmiana lub rozbudowa Oprogramowania Dedykowanego lub wy- tworzenie, zmiana lub aktualizacja Dokumentacji dokonana w ramach Nadzoru Autorskiego i gwarancji oraz świadczenia Serwisu gwarancyjnego, zgodnie z wy- maganiami Umowy.

29. MUW – Mazowiecki Urząd Wojewódzki w Warszawie.

30. Nadzór Autorski – Modyfikacja Oprogramowania lub Dokumentacji Platformy dokonana na podstawie Zlecenia, szczegółowo opisanego w Umowie, z wyłącze- niem zmian określonych do realizacji w ramach gwarancji i świadczenia Serwisu gwarancyjnego oraz związanych ze zmianą przepisów prawa, zgodnie z wyma- ganiami Umowy.

31. Oprogramowanie – Oprogramowanie Dedykowane i Oprogramowanie Stan- dardowe.

32. Oprogramowanie Dedykowane – oznacza oprogramowanie w skład którego wchodzą Formularze elektroniczne ePUAP oraz Platforma i wszelkie inne opro- gramowanie, w tym API wytworzone przez Wykonawcę, z wyłączeniem Opro- gramowania Standardowego, wraz z kompletnymi kodami źródłowymi, wytwo- rzone i dostarczone przez Wykonawcę w ramach realizacji Umowy, wraz z Do- kumentacją i Modyfikacjami oraz Dokumentacją do Modyfikacji, do których Wy- konawca przeniesie autorskie prawa majątkowe na Zamawiającego na warun- kach i zasadach określonych w Umowie. Zamawiający za Oprogramowanie De- dykowane uznaje również oprogramowanie otrzymane przez Wykonawcę na ba- zie modyfikacji kodów źródłowych Oprogramowania Standardowego.

33. Oprogramowanie Standardowe – oznacza oprogramowanie powszechnie dostępne i eksploatowane na dzień złożenia oferty, którego producentem jest Wykonawca lub podmiot trzeci, w tym wyższe wersje (update/upgrade), patche i programy korekcji błędów Oprogramowania Standardowego.

1. Zamawiający dopuszcza zastosowanie Oprogramowania Standardowego w poniższych obszarach:

a) system operacyjny,

b) oprogramowanie bazodanowe,

c) oprogramowanie do tworzenia raportów,

d) oprogramowanie do tworzenia kopii bezpieczeństwa,

e) oprogramowanie antywirusowe,

f) oprogramowanie ETL (ang. Extract, Transform and Load),

g) komunikator (np. oparty o protokół XMPP),

h) oprogramowanie do wirtualizacji,

Opis Przedmiotu Zamówienia strona 8

i) oprogramowanie serwera pocztowego,

j) oprogramowanie serwera aplikacyjnego, kontener aplikacji (z wyłą- czeniem kodu aplikacji udostępnianej użytkownikowi), serwera WWW,

k) oprogramowanie narzędziowe do monitorowania i diagnozy Plat- formy,

l) system obsługi zgłoszeń serwisowych. 2. Zamawiający dopuszcza zastosowanie Oprogramowania Standardo- wego, którego producentem jest Wykonawca lub podmiot trzeci również w innych obszarach niż wskazane w pkt 1 pod warunkiem, że zastosowanie takiego oprogramowania nie ograniczy kompatybil- ności z innymi dostępnymi na rynku rozwiązaniami technicznymi oraz dalszej rozbudowy Platformy i świadczenia Serwisu gwaran- cyjnego przez inne podmioty niż Wykonawca lub podmiot trzeci, co wymaga uzyskania pisemnej zgody Zamawiającego. 3. Po otrzymaniu wniosku o wyrażenie zgody na zastosowanie Oprogra- mowania Standardowego w innym obszarze niż wskazane w pkt 1, Zamawiający może: a) wyrazić zgodę na zastosowanie Oprogramowania Standardowego w tym obszarze, pod warunkiem zapewnienia licencji dla Zama- wiającego na polach eksploatacji określonych w § 7 ust. 23 Umowy, jeżeli Wykonawca jest producentem Oprogramowania Standardowego lub w § 7 ust. 25 – 26 Umowy jeżeli Wykonawca nie jest producentem Oprogramowania Standardowego, b) wyrazić zgodę na zastosowanie Oprogramowania Standardowego w tym obszarze, pod warunkiem spełnienia następujących wyma- gań:

i. przekazania kodów źródłowych Oprogramowania Standardo-

wego, ii. udzielenia licencji na Zamawiającego, na polach eksploatacji określonych w

§ 7 ust. 24 Umowy oraz w zakresie dokonywa- nia zmian przez Zamawiającego, lub podmiot trzeci, w tym zmian w kodach źródłowych Oprogramowania Standardo- wego i jego Modyfikacji, tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian przy czym li- cencja obejmuje w tym przypadku również zezwolenie na wy- konywanie praw zależnych. c) nie wyrazić zgody, co jednoznaczne jest z koniecznością zastoso- wania Oprogramowania Dedykowanego w

obszarze, którego do- tyczył wniosek o wyrażenie zgody. 34. OPZ – Opis Przedmiotu Zamówienia.

35. Otwarty format - format plików, które w odróżnieniu od formatu zamkniętego, posiadają jawną, ogólnodostępną specyfikację oraz strukturę, która nie jest

Opis Przedmiotu Zamówienia strona 9

ograniczona w żaden sposób przez prawo związane z licencjonowaniem, paten- tami, znakami towarowymi lub w inny sposób powodując, że każdy może wyko- rzystać je bezpłatnie w dowolnym celu (DZ.U. z 16 maja 2012, poz. 526).

36. Plan Szkoleń – plan wszystkich Szkoleń koniecznych do przeprowadzenia, z podaniem szczegółowego harmonogramu i zakresów tematycznych Szkoleń.

37. Plan Testów Akceptacyjnych, PTA – element Dokumentacji opracowany

przez Wykonawcę zawierający opis organizacji i przeprowadzenia Testów Akcep- tacyjnych, odpowiadający wymaganiom określonym w OPZ i podlegający akcep- tacji Zamawiającego.

38. Plan wdrożenia – harmonogram realizacji Umowy wchodzący w skład DIP, określający harmonogram prac wykonywanych w ramach wdrożenia, w szcze- gólności terminy realizacji Etapów, wykonania i odbioru poszczególnych Produk- tów i innych działań określonych w OPZ.

39. Platforma – wykonany przez Wykonawcę wewnętrzny system teleinforma- tyczny Zamawiającego, składający się z Oprogramowania szczegółowo opisa- nego w niniejszym OPZ i w Projekcie technicznym, mający na celu udostępnienie i zarządzanie wysokiej jakości usługami publicznymi, świadczonymi drogą elek- troniczną przez Zamawiającego, zintegrowany z systemami EZD, ePUP, Profil Zaufany/jego następca, wraz z jego Dokumentacją, spełniający wszystkie wy- magania i obejmujący wszystkie Komponenty określone w niniejszym OPZ.

40. Produkt - wskazane w przedmiocie zamówienia świadczenie Wykonawcy pod- legające akceptacji i/lub odbiorowi przez Zamawiającego.

41. Profil Xxxxxxx/jego następca - Profil Xxxxxxx, o którym mowa w art. 20 a)

ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U.2017.570 j.t.), to bezpłatne narzędzie identyfikacji, dzięki któremu można potwierdzać swoją tożsamość w elektronicznych systemach administracji (służy, jako podpis elektroniczny) / jego następca to nowe narzędzie identyfikacji, które

ma zastąpić Profil Zaufany (przedsięwzięcie przewidziane Planem Działań Mini- stra Cyfryzacji stanowiącym część Programu Zintegrowanej Informatyzacji Pań- stwa).

42. Projekt techniczny – element Dokumentacji projektowej opisujący sposób wy- konania, wdrożenia i właściwości Platformy. Szczegółowe wymagania dla Pro- jektu technicznego zostały określone w niniejszym OPZ.

43. Projekt WiPER - projekt pod nazwą „Wdrożenie i popularyzacja e-usług reali- zowanych przez administrację rządową w województwie mazowieckim (WiPER)”

Opis Przedmiotu Zamówienia strona 10

realizowany przez Zamawiającego w ramach Działania 2.1 „E-usługi” Regional- nego Programu Operacyjnego Województwa Mazowieckiego na lata 2014-2020.

44. Protokół Odbioru Etapu - oznacza dokument potwierdzający prawidłową re- alizację jednego z Etapów przedmiotu Umowy.

45. Protokół Odbioru Końcowego – oznacza dokument potwierdzający prawi- dłową realizację przedmiotu Umowy, który zostanie podpisany na podstawie podpisanych bez uwag Zamawiającego, Protokołów Odbioru poszczególnych Etapów przedmiotu Umowy.

46. Protokół Odbioru Zlecenia – dokument potwierdzający dokonanie odbioru Zlecenia.

47. Raport – raport ze stanu realizacji prac, opracowywany przez Wykonawcę i przekazywany Zamawiającemu do akceptacji raz w tygodniu, pierwszego Dnia Xxxxxxxxx po zakończeniu poprzedniego tygodnia.

48. Raport z Testów Wewnętrznych - dokument podsumowujący przeprowa- dzenie Testów Wewnętrznych Wykonawcy.

49. Raport z Testów Akceptacyjnych – dokument podsumowujący przeprowa- dzenia każdej iteracji Testów Akceptacyjnych, podlegający zatwierdzeniu przez Kierownika Projektu Zamawiającego.

50. Raport z wdrożenia Platformy – raport przygotowany przez Wykonawcę podsumowujący przebieg wykonania i wdrożenia Platformy.

51. Scenariusze testowe – zestaw scenariuszy szczegółowo opisujący jakie czyn- ności, w jakiej kolejności i przy użyciu jakich danych należy wykonać w celu przetestowania poprawności działania Platformy zgodnie z wymaganiami opisa- nymi w OPZ.

52. Serwis gwarancyjny - oznacza zespół działań Wykonawcy mających na celu realizację zobowiązań wynikających z Umowy w celu zapewnienia bezawaryj- nego i zgodnego z założeniami Umowy działania Platformy oraz udostępnianie i instalowanie przez Wykonawcę na rzecz Zamawiającego, wyższych wersji Opro-

gramowania Dedykowanego oraz update/upgrade, patche i programy korekcji błędów Oprogramowania Standardowego, wykonywanych na zasadach określo- nych w Umowie.

53. Sprawozdanie ze Szkoleń – dokument przygotowany przez Wykonawcę, za- wierający wszystkie informacje dotyczące przeprowadzonych Szkoleń określo- nych w Planie Szkoleń.

Opis Przedmiotu Zamówienia strona 11

54. Szkolenia - oznacza określone w Umowie Szkolenia, zgodnie z wymaganiami określonymi w niniejszym OPZ.

55. Testy Akceptacyjne – testy prowadzone przez Zamawiającego, na podsta- wie zaakceptowanych Scenariuszy testowych i PTA, na które składają się testy wszystkich wymagań funkcjonalnych i ogólnych, wydajnościowe, integracyjne.

56. Testy Wewnętrzne - testy przeprowadzone przez Wykonawcę, przed zgłosze- niem do Zamawiającego gotowości rozpoczęcia Testów Akceptacyjnych.

57. Umowa – Umowa zawarta pomiędzy Zamawiającym a Wykonawcą, na wyko- nanie i wdrożenie Platformy.

58. Użytkownik wewnętrzny – osoby wskazane przez Zamawiającego odpowie- dzialne za obsługę w szczególności: procesów biznesowych związanych z udo- stępnionymi e-usługami, aktualizację danych udostępnianych w każdym Kompo- nencie Platformy, komunikację z Użytkownikami zewnętrznymi poprzez prowa- dzenie chatu lub wideokonferencji z wykorzystaniem tłumacza migowego online.

59. Użytkownik zewnętrzny – klienci korzystający z Platformy.

60. W3C – (ang. World Wide Web Consortium) – organizacja, która zajmuje się ustanowieniem standardów pisania i przesyłu stron www.

61. WAI – (ang. Web Accessibility Initiative) – inicjatywa dostępności do sieci – inicjatywa W3C mająca na celu zwiększenie szeroko rozumianej dostępności stron www.

62. Wirtualny asystent - rodzaj zaawansowanej pomocy dla użytkowników Plat- formy.

63. Wykonawca – podmiot wybrany w postępowaniu na zaprojektowanie, budowę i wdrożenie Platformy.

64. WYSIWYG - (ang. what you see is what you get) akronim dla określenia metod, które pozwalają uzyskać wynik w publikacji identyczny lub bardzo zbliżony do

obrazu na ekranie.

65. Zamawiający – Mazowiecki Urząd Wojewódzki w Warszawie.

66. Zlecenie – Zlecenie Nadzoru Autorskiego.

Opis Przedmiotu Zamówienia strona 12

2. Wstęp

Koncepcja rozwiązania zakłada udostępnienie kompleksowego rozwiązania informa- tycznego umożliwiającego świadczenie e-usług publicznych, które zostanie złożone z następujących Komponentów:

1. Portalu dostępowego,

2. Modułu komunikacji,

3. Modułu Open Data,

4. Modułu usługowego,

5. Modułu Administratora,

6. Szyny danych ESB umożliwiającej integrację rozwiązań.

Propozycję architektury rozwiązania w podziale na warstwę dostępu, systemową, integracji oraz systemów wspierających przedstawiono na rysunku 1.

Rysunek 1. Model architektury Platformy

Opis Przedmiotu Zamówienia strona 13

3. Przedmiot zamówienia

Realizacja przedmiotu zamówienia obejmuje:

I. Etap I złożony z następujących zadań:

1. Opracowanie DIP - dokumentacji zarządzania realizacją Umowy wraz z Planem wdrożenia zawierającego szczegółowy plan zapro- jektowania, budowy i wdrożenia Platformy, w tym udostępnienia Formularzy elektronicznych i Formularzy elektronicznych ePUAP, zgodnie z wymaganiami zawartymi w niniejszym OPZ,

2. Opracowanie i dostarczenie Projektu Technicznego, zawierającego opis koncepcji funkcjonowania Platformy, uwzględniającego projekt interfejsu wybrany przez Zamawiającego z 3 propozycji przekaza- nych przez Wykonawcę, zgodnie z wymaganiami zawartymi w ni- niejszym OPZ,

3. Oznaczenie opracowanych dokumentów zgodnie z załącznikiem nr 4 do Umowy,

4. Przeniesienie autorskich praw majątkowych do Dokumentacji na za- sadach określonych w Umowie.

II. Etap II złożony z następujących zadań:

1. Wykonanie Formularzy elektronicznych ePUAP – wskazanych w ka- talogu e-usług od pkt 1 do pkt 44 (rozdziale 5.4.1 niniejszego OPZ), obejmujących następujące prace:

a) wykonanie Formularzy elektronicznych ePUAP, w formatach umożliwiających ich publikację na ePUAP, na koncie Zamawia-

Opis Przedmiotu Zamówienia strona 14

jącego (lokalne repozytorium), z wykorzystaniem wszelkich do- stępnych na tej platformie mechanizmów weryfikacji wprowa- dzanych danych: walidacja i podpowiedzi uzupełnienia danych (np. danych adresowych użytkownika systemu ePUAP),

b) opracowanie i przekazanie wzorów Formularzy elektronicznych ePUAP opisanych w ppkt. a) do przesłania przez Zamawiającego do CRD (Centralne Repozytorium Dokumentów), zgodnych z ob- owiązującymi przepisami,

c) zamieszczenie Formularzy elektronicznych ePUAP i ich wzorów opisanych w ppkt. a) i b), na testowej platformie ePUAP Zama- wiającego (w celu przeprowadzenia testów) oraz na platformie produkcyjnej ePUAP,

d) opracowanie Dokumentacji Formularzy elektronicznych ePUAP.

2. Oznaczenie Dokumentacji Formularzy Elektronicznych ePUAP zgod- nie z załącznikiem nr 4 do Umowy,

3. Przeniesienie autorskich praw majątkowych do Formularzy elektro- nicznych ePUAP oraz Dokumentacji Formularzy Elektronicznych ePUAP, na zasadach określonych w Umowie.

III. Etap III złożony z następujących zadań:

1. Wykonanie Formularzy elektronicznych ePUAP – wskazanych w ka- talogu e-usług od pkt 47 do pkt 78 (rozdziale 5.4.1 niniejszego OPZ), obejmujących następujące prace:

a) wykonanie Formularzy elektronicznych ePUAP, w formatach umożliwiających ich publikację na ePUAP, na koncie Zamawia- jącego (lokalne repozytorium), z wykorzystaniem wszelkich do- stępnych na tej platformie mechanizmów weryfikacji wprowa- dzanych danych: walidacja i podpowiedzi uzupełnienia danych

(np. danych adresowych użytkownika systemu ePUAP),

Opis Przedmiotu Zamówienia strona 15

d) opracowanie Dokumentacji Formularzy elektronicznych ePUAP.

2. Oznaczenie Dokumentacji Formularzy Elektronicznych ePUAP zgod- nie z załącznikiem nr 4 do Umowy,

3. Przeniesienie autorskich praw majątkowych do Formularzy elektro- nicznych ePUAP oraz Dokumentacji Formularzy Elektronicznych ePUAP, na zasadach określonych w Umowie.

IV. Etap IV złożony z następujących zadań:

1. Wykonanie Platformy obejmująca w szczególności:

a) opracowanie i wykonanie Platformy (wszystkich Komponentów) zgodnie z koncepcją opisaną w rozdziale 5 i z wymaganiami okre- ślonymi w rozdziale 6 niniejszego OPZ, oraz z Projektem Tech- nicznym dostarczonym przez Wykonawcę i zaakceptowanym przez Zamawiającego w Etapie I,

b) wykonanie Formularzy elektronicznych na Platformę, na podsta- wie przekazanego przez Zamawiającego katalogu e-usług (wykaz e-usług zawarty w rozdziale 5.4.1 niniejszego OPZ), spełniający wszystkie wymagania określone w niniejszym OPZ, w tym także udostępnienie niezbędnych API,

c) zasilenie modułu Open Data Platformy oraz Wirtualnego asy- stenta danymi,

d) przeprowadzenie Testów Wewnętrznych i udział w Testach Ak- ceptacyjnych Platformy, zgodnie z zasadami określonymi w roz-

dziale 6.8 niniejszego OPZ,

e) udostępnienie i zapewnienie na potrzeby realizacji przedmiotu Umowy środowiska testowego, wraz z narzędziami informatycz- nymi, spełniającego wymagania określone w rozdziale 7 niniej- szego OPZ, w tym zapewnienie działania usług: hostingu wraz z replikacją danych, płatności online i tłumacza migowego, na po- trzeby Testów Akceptacyjnych.

Opis Przedmiotu Zamówienia strona 16

2. Wdrożenie Platformy obejmujące w szczególności:

a) udostępnienie na potrzeby Platformy, środowiska produkcyj- nego, spełniającego wymagania określone w rozdziale 6 i 7 ni- niejszego OPZ,

b) instalacja, konfiguracja i uruchomienie Platformy w środowisku produkcyjnym w sposób określony w rozdziale 7 niniejszego OPZ,

c) utworzenie i konfiguracja kont użytkowników oraz implementacja uprawnień na Platformie,

d) opracowanie Dokumentacji powykonawczej zgodnie z wymaga- niami określonymi w rozdziale 4.1 niniejszego dokumentu i prze- niesienie autorskich praw majątkowych na polach eksploatacji określonych w Umowie,

e) przeniesienie autorskich praw majątkowych do Platformy i kodów źródłowych,

f) udzielenie licencji na Oprogramowanie Standardowe,

g) opracowanie i dostarczenie Raportu z wdrożenia Platformy.

3. Zorganizowanie i przeprowadzenie Szkoleń obejmujące w szczegól- ności:

a) opracowanie Planu Szkoleń oraz materiałów szkoleniowych, zgodnie z wymaganiami określonymi w rozdziale 4.1 i 6.9 niniej- szego OPZ,

b) udostępnienie środowiska szkoleniowego zgodnie z wymagania kreślonymi w rozdziale 7 niniejszego OPZ,

c) przeprowadzenie Szkoleń dla Użytkowników wewnętrznych i Ad- ministratorów, zgodnie z wymaganiami określonymi w rozdziale

6.9 niniejszego OPZ,

4. Przygotowanie i przeprowadzenie Konferencji, podczas której odbę- dzie się prezentacja Platformy, zgodnie z wymaganiami określonymi w rozdziale 6.9 niniejszego OPZ.

Opis Przedmiotu Zamówienia strona 17

V. Utrzymanie i rozwój

1. Świadczenie usługi hostingu wraz z zapewnieniem replikacji danych w okresie 12 miesięcy od dnia podpisania Protokołu Odbioru Końcowego, zgodnie z wymaganiami określonymi w rozdziale 8 niniejszego OPZ.

2. Świadczenie usługi płatności on-line i tłumacza migowego w okresie 12 miesięcy od dnia podpisania Protokołu Odbioru Końcowego, zgodnie z wymaganiami określonymi w rozdziałach 5 i 6 niniejszego OPZ.

3. Świadczenie usługi Serwisu gwarancyjnego w okresie 36 miesięcy od dnia podpisania Protokołu Odbioru Końcowego, zgodnie z wymaganiami określonymi w Umowie.

4. Świadczenie usług Nadzoru autorskiego na podstawie Zleceń, w wymia- rze do 300 osobogodzin w okresie 36 miesięcy od dnia podpisania Pro- tokołu Odbioru Końcowego, zgodnie z zasadami określonymi w Umowie.

Opis Przedmiotu Zamówienia strona 18

3.1. Produkty przedmiotu zamówienia

W ramach przedmiotu zamówienia wyspecyfikowane zostały co najmniej na- stępujące Produkty podlegające odbiorowi i akceptacji:

Etap I

1. DIP – procedura odbioru

a) Plan wdrożenia – procedura akceptacji

2. Projekt Techniczny – procedura odbioru

a) Projekt interfejsu (3 propozycje) - procedura akceptacji wybranej propozycji

Etap II

1. Formularze elektroniczne ePUAP wraz z Dokumentacją Formularzy elek- tronicznych ePUAP (poz. od 1 do 44 z katalogu e-usług) - procedura od-

bioru

Etap III

2. Formularze elektroniczne ePUAP wraz z Dokumentacją Formularzy elek- tronicznych ePUAP (poz. od 47 do 78 z katalogu e-usług) - procedura od-

bioru

Etap IV

1. Przetestowana Platforma (Testy Akceptacyjne Platformy) – procedura odbioru

a) Plan Testów Akceptacyjnych – procedura akceptacji

b) Scenariusze testowe – procedura akceptacji

c) Raport z Testów Akceptacyjnych – procedura akceptacji

2. Szkolenia – procedura odbioru

a) Plan Szkoleń – procedura akceptacji

b) Materiały szkoleniowe – procedura akceptacji

c) Sprawozdanie ze Szkoleń – procedura akceptacji

3. Konferencja z prezentacją Platformy – procedura odbioru

4. Dokumentacja powykonawcza - procedura odbioru

5. Raport z wdrożenia Platformy - procedura odbioru

Raporty (cotygodniowe Raporty ze stanu realizacji prac) - procedura akceptacji

4. Projekt harmonogramu realizacji przedmiotu zamówienia

1. Terminy realizacji przedmiotu zamówienia przedstawiono w tabeli 1.

Tabela 1. Terminy realizacji przedmiotu zamówienia

x.x Xxxxxxx Opis terminu realizacji

0 Podpisanie Umowy 1 Etap I 35 dni od dnia podpisania Umowy

- DIP i Plan wdrożenia (przekazanie) 7 dni od dnia podpisania Umowy - Projekt interfejsu (przekazanie) 7 dni od dnia podpisania Umowy - Projekt Techniczny (przekazanie) 21 dni od dnia podpisania Umowy 2 Etap II 45/50/51+ dni od dnia podpisania Umowy * (nie później niż 60 dni od podpisania Umowy) - Formularze elektroniczne ePUAP poz. od 1 do 44 (odbiór)

30 dni na dokonanie odbioru przez Zamawiają- cego od przekazania formularzy przez Wyko- nawcę 3 Etap III 70/80/81+ dni od dnia podpisania Umowy * (nie później niż 90 dni od podpisania Umowy) - Formularze elektroniczne ePUAP poz. od 47 do 78 (odbiór)

30 dni na dokonanie odbioru przez Zamawiają- cego od przekazania formularzy przez Wyko- nawcę 4 Etap IV 31.10./15.11./30.11.2018 *

- Testy Akceptacyjne Zgodnie z zapisami Umowy - Szkolenia Zgodnie z zapisami Umowy - Dokumentacja powykonawcza Zgodnie z zapisami Umowy - Konferencja Zgodnie z zapisami Umowy - Raport z wdrożenia

Platformy Zgodnie z zapisami Umowy 5 Utrzymanie i Rozwój

- hosting, płatności on-line, tłumacz mi- gowy

12 miesięcy od dnia podpisania Protokołu Od- bioru Końcowego - Serwis gwarancyjny 36 miesięcy od dnia podpisania Protokołu Od-

bioru Końcowego - Modyfikacje (Nadzór autorski) Okres Serwisu gwarancyjnego

* Ostateczne terminy realizacji wynikać będą z oferty Wykonawcy.

2. Zamawiający wymaga, aby Etapy były realizowane równolegle.

Opis Przedmiotu Zamówienia strona 19

Opis Przedmiotu Zamówienia strona 20

4.1. Wymagania w zakresie dokumentacji

1. W ramach realizacji Umowy wykonania Platformy, Wykonawca zobowiązany jest do dostarczenia Produktów stanowiących Dokumentacje, których odbiór będzie stanowił podstawę do zakończenia prac realizowanych w danych Eta- pach.

2. Terminy dostarczenia Dokumentacji powstałej w ramach realizacji Umowy zostaną umieszczone w Planie wdrożenia, określonym w DIP.

3. Wszystkie Produkty, stanowiące Dokumentację, powinny charakteryzować się wysoką jakością wykonania, na którą będą miały wpływ w szczególności następujące czynniki:

a) czytelna i zrozumiała struktura poszczególnych Produktów oraz całej do- kumentacji z wyodrębnieniem rozdziałów, podrozdziałów i sekcji;

b) stosowanie standardów, rozumianych jako zachowanie jednolitej i spój- nej struktury informacji, formy i sposobu prezentacji treści poszczegól- nych Produktów, ich fragmentów oraz całej dokumentacji;

c) kompletność, rozumiana jako pełne, bez wyraźnych, ewidentnych bra- ków przedstawienie omawianego problemu, obejmujące całość z da-

nego zakresu rozpatrywanego zagadnienia – oznacza to w szczególności jednoznaczne i wyczerpujące przedstawienie wszystkich zagadnień w odniesieniu do systemu;

d) spójność i niesprzeczność, rozumiana jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w Dokumentacji, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych Produktach oraz we fragmen- tach tego samego Produktu.

4. W przypadku dokonania zmian w Platformie, Dokumentacja powykonawcza

zawierać będzie opis dokonanych zmian i aktualizacji.

5. Wykaz wymaganych przez Zamawiającego Produktów, które powinny po-

wstać w ramach realizacji przedmiotu zamówienia wraz z ich opisem, formą dostarczenia, został przedstawiony w tabeli 2.

Opis Przedmiotu Zamówienia strona 21

Tabela 2. Zakres wymaganej Dokumentacji dostarczanej przez Wykonawcę sys- temu

Lp. Dokument Opis Produktu Forma dostarczenia 1. DIP (Dokumenta-

cja zarządzania realizacją przed- miotu Umowy)

Dokumentacja, której celem jest uszczegółowienie zasad realizacji przedmiotu Umowy, w skład której powinny wejść, co najmniej następujące elementy:

• Struktura Organizacyjna zespołu Wyko- nawcy;

• Szczegółowy plan realizacji Umowy z har- monogramem realizacji Etapów, Produk- tów/usług w ramach wykonania Platformy (Plan wdrożenia);

• Produkty zarządcze i Produkty specjali- styczne

• Procedury odbiorowe;

• Standardy i procedury projektowe* i wdro- żeniowe.

Dokument w wersji papiero- wej – 1 sztuka oraz elektro- nicznej w for- mie pliku edy- towalnego MS Word i/lub MS Excel i/lub Pro- ject (1 płyta CD/DVD).

2. Plan wdrożenia Dokument zawierający szczegółowy plan zaprojekto- wania, budowy i wdrożenia Platformy, w tym,

co naj- mniej: • Szczegółowy harmonogram wdrożenia,

• Szczegółowy harmonogram zasilenia Plat- formy danymi,

• Szczegółowy harmonogramu przejścia na środowisko produkcyjne,

• Udział i obciążenie pracą komórek organi- zacyjnych jednostek MUW i JAR uczestni- czących w Projekcie,

• Udział i obciążenie pracą Wykonawcy.

Dokument w wersji papiero- wej – 1 sztuka oraz elektro- nicznej w for- mie pliku edy- towalnego MS Word i/lub MS Excel i/lub Pro- ject (1 płyta CD/DVD).

3 Projekt interfejsu Dokument zawierający proponowany model gra-

ficzny i funkcjonalny interfejsu użytkownika, przygotowany zgodnie z wymaganiami zapisa- nymi w niniejszym OPZ.

• Wykonawca przygotuje 3 różne propozycje Projektu interfejsu, dla urządzeń stacjonar- nych i dla urządzeń mobilnych,

• Propozycje mają różnić się między sobą nie tylko kolorystyką, ale i strukturą.

• Zamawiający wybierze jedną propozycję, która będzie uwzględniona w Projekcie technicznym.

Dokument w wersji papiero- wej – 1 sztuka oraz elektro- nicznej w for- mie pliku edy- towalnego apli- kacji, w której projekt został przygotowany, oraz w formie pliku zamknię- tego (pdf), (1 płyta CD/DVD). 4. Projekt

Techniczny

Projekt Techniczny powinien, co najmniej:

• w pełni odzwierciedlać architekturę Plat- formy oraz wszystkie funkcje przewidziane do realizowania przez Platformę, a także Administratorów i użytkowników,

• zawierać specyfikację przypadków użycia przez Administratorów i użytkowników,

• zawierać kompletny i szczegółowy opis przyjętych rozwiązań funkcjonalnych wraz z informacjami o parametrach i sposobie konfiguracji, parametrach konstrukcyjnych, użytkowych i sprzętowych, z wyspecyfikowa- niem asortymentowym i ilościowym wszyst- kich elementów składowych oraz oprogra- mowania,

• określać zasady i plany instalacji, urucho- mienia i wdrożenia Platformy,

Dokument w wersji papiero- wej – 1 sztuka oraz elektro- nicznej w for- mie pliku edy- towalnego MS Word i/lub MS Excel i/lub Pro- ject (1 płyta CD/DVD).

Opis Przedmiotu Zamówienia strona 22

Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regio- nalnego w ramach

Regionalnego Programu Operacyjnego Województwa Mazowieckiego 2014-2020 oraz ze środków budżetu państwa

• zawierać koncepcję realizacji integracji Platformy z innymi systemami wykorzysty- wanymi przez Zamawiającego,

• zawierać koncepcję i plan zasilenia Plat- formy danymi, koncepcję modelu danych, zawierać szczegółowy zakres udostępnio- nych danych w podziale na kategorie i spo- sób wprowadzenia danych,

• zawierać koncepcję uprawnień zawierającą wykaz ról z opisem i relacjami pomiędzy nimi,

• zawierać plan przejścia na środowisko pro- dukcyjne (w tym plan awaryjny), wskazywać punkty krytyczne i zagrożenia mające wpływ na niezawodne działanie Platformy,

• zawierać plany odtworzeniowe Platformy

• zawierać projekt interfejsu 5 Raport Raport ze stanu realizacji prac, opracowywany przez

Wykonawcę i przekazywany Zamawiającemu do ak- ceptacji co tydzień, pierwszego Dnia Xxxxxxxxx po zakończeniu poprzedniego tygodnia. Raport ma za- wierać, co najmniej:

• zadania zrealizowane w minionym tygodniu z określeniem pierwotnego i rzeczywistego terminu realizacji

• zadania realizowane w minionym tygodniu z podaniem % zaawansowania

• zadania zaległe

• zadania na kolejny tydzień

• zagrożenia/ryzyka

• zalecenia/uwagi 6. Plan Testów Ak- ceptacyjnych

Dokument w wersji papiero- wej – 1 sztuka oraz elektro- nicznej w for- mie pliku edy- towalnego MS Word i/lub MS Excel i/lub Pro- ject (1 płyta CD/DVD).

7. Scenariusze te- stowe

Dokument mający na celu organizację testów, zawie- rający, co najmniej następujące elementy:

• Zdefiniowany zakres i cele przeprowadze- nia testów;

• Zdefiniowane fazy i cykle testów;

• Harmonogram prowadzenia testów;

• Wykaz czynności niezbędnych do wykona- nia wraz z podziałem odpowiedzialności po- między Wykonawcę i Zamawiającego;

• Ustalone kryteria akceptacji testów;

• Opis klasyfikacji wykrytych Wad;

• Opis zasad naprawy wykrytych wad Plat- formy;

• Opis zasad sporządzenia raportu z przepro- wadzonych testów. Scenariusze testowe mają być wykorzystane naj-

Dokument w pierw przez zespól Wykonawcy do przeprowadzenia wersji papiero- Testów Wewnętrznych. Następnie wykorzystane

wej dla uczest- przez zespół Zamawiającego do przeprowadzenia Te- ników każdej z stów Akceptacyjnych.

iteracji testów Scenariusze testowe będą służyły do sprawdzenia oraz elektro- poprawności działania Platformy oraz jego zgodności nicznej w for- z wymaganiami, dlatego też powinny być opracowane

mie plików edy- w sposób jasny i zrozumiały, również dla użytkownika towalnych MS nieznającego wcześniej Platformy. Scenariusze te- Word i/lub MS stowe powinny składać się, co najmniej z:

Excel (1 płyta

• Opisu przypadków testowych; CD/DVD).

• Opisu kroków testowych;

• Opisu kryteriów poprawności danego przy- padku testowego.

Opis Przedmiotu Zamówienia strona 23

Dokument 8. Raport z Testów podsumowujący przeprowadzenie testów. Dokument w (Akceptacyjnych i

Celem Raportu z Testów Wewnętrznych Wykonawcy wersji papiero- Wewnętrznych)

jest wstępne testowanie w celu wyeliminowania błę-

wej oraz elek- dów przed przekazaniem Platformy do Testów Akcep- tronicznej w tacyjnych.

formie plików Celem Raportu z Testów Akceptacyjnych jest spraw- edytowalnych dzenie poprawności działania dostarczonej Platformy MS Word i/lub i wyeliminowanie błędów przed udostępnieniem Plat- MS Excel (1 formy do użytkowania produkcyjnego.

płyta CD/DVD). Raport z testów powinien zawierać, co najmniej:

• miejsce prowadzenia testów;

• wykaz osób przeprowadzających testy;

• terminy przeprowadzenia testów;

• opis przebiegu testów wraz z listą przetestowa- nych scenariuszy i przypadków testowych oraz wyniki ich przeprowadzenia;

• wykaz zgłoszonych Wad i Usterek;

• wnioski końcowe. Załącznik do raportu powinien zawierać wypełnione przez Zespół testujący Scenariusze testowe, podpi- sane przez uczestników testów. Każdy Scenariusz te- stowy powinien zawierać wynik testu oraz wykaz za-

rejestrowanych błędów. Celem raportu z testów jest dostarczenie opisu błędów, które powinny zostać wy- eliminowane przez Wykonawcę przed dostarczeniem Platformy, na którym rozpoczną pracę Użytkownicy wewnętrzni i Administratorzy. Raport z Testów Akcep- tacyjnych powinien zostać wykonany i przekazany po każdej iteracji testów, i zaakceptowany przez Kierow- nika Projektu Zamawiającego. 9. Plan Szkoleń Plan Szkoleń Administratorów i Użytkowników we-

wnętrznych powinien zawierać, co najmniej:

• wykaz planowanych Szkoleń oraz zakresy tema- tyczne Szkoleń,

• wykaz trenerów przypisaniem do obszaru szko- leniowego,

• harmonogram Szkoleń,

• agendę poszczególnych Szkoleń,

• wymagania niezbędne do prawidłowego prze- prowadzenia Szkolenia, określone przez Wyko- nawcę, które powinien spełnić Zamawiający.

Wymagane jest dostarczenie dokumentów w wersji papiero- wej (1 sztuka) oraz elektro- nicznej w for- mie plików edy- towalnych MS Word i/lub MS Project i/lub MS Excel (1 płyta DVD/CD). 10. Materiały szkole-

niowe

Dokument w wersji papiero- wej oraz elek- tronicznej w formie plików edytowalnych MS Word i/lub MS Excel i/lub Power Point (1 płyta CD/DVD).

11. Sprawozdanie ze Szkoleń

Materiały szkoleniowe powinny obejmować:

• materiały dla Administratorów;

• materiały dla Użytkowników wewnętrznych; oraz powinny co najmniej:

• zawierać podręczniki i procedury obejmujące za- kres merytoryczny odpowiadający szkoleniom na poziomie pozwalającym na rozpoczęcie pracy nowemu Użytkownikowi wewnętrznemu/Admini- stratorowi;

• zapewniać wizualizację treści przekazywanych na Szkoleniu;

• zawierać ćwiczenia,

• zostać przygotowane na bazie systemu po prze- prowadzonych Testach Akceptacyjnych. Materiały szkoleniowe muszą zostać dostosowane do potrzeb każdej z grup szkoleniowych, w taki spo- sób, aby korzystanie z nich było możliwe zarówno przed, w trakcie jak i po Szkoleniu. Dokument potwierdzający przeprowadzenie określo-

Wymagane jest nych w harmonogramie Szkoleń powinien zawierać dostarczenie co najmniej:

dokumentów w

Opis Przedmiotu Zamówienia strona 24

wersji papiero- wej (1 sztuka) oraz elektro- nicznej w for- mie plików edy- towalnych MS Word (1 płyta DVD/CD). 12

Dokumentacja

Formularzy elek- tronicznych ePUAP

• nazwę Szkolenia, datę i miejsce Szkolenia, na- zwisko trenera,

• program Szkolenia,

• informację o przekazaniu materiałów szkolenio- wych, Załącznikiem do Sprawozdania będą oryginały imien- nej listy obecności.

Dokumentacja musi zawierać co najmniej tabelę z wykazem pól wykorzystanych w formularzu, ich typ, sposób walidacji, wykaz zależności pomiędzy polami (jeśli wymagane).

Wymagane jest dostarczenie dokumentów w wersji papiero- wej (1 sztuka) oraz elektro- nicznej w for- mie plików edy- towalnych MS Word i/lub MS Excel (1 płyta DVD/CD) 13 Dokumentacja powykonawcza

Dokumentacja zawierająca opis wymagań funkcjo- nalnych i niefunkcjonalnych Platformy, pozwalający na poprawną obsługę przez Użytkowników wewnętrz- nych, zewnętrznych i Administratorów, opis właściwo- ści i parametrów dostarczonego rozwiązania informa- tycznego, pozwalający na poprawną konfigurację i eksploatację Platformy. Na dokumentację powyko- nawczą powinny złożyć się co najmniej następujące elementy:

• instrukcje użytkowania Platformy;

• instrukcje stanowiskowe;

• instrukcja Administratora Platformy;

• diagram kontekstowy zaproponowanego rozwią- zania i model zachowania;

• opis struktur bazy danych (opis tablic i pól oraz wzajemne powiązania);

• opis konfiguracji i parametryzacji systemu;

• opis rozszerzeń modyfikacji, dostosowań do po- trzeb Xxxxxxxxxxxxx;

• opis i specyfikę interfejsów międzymodułowych;

• opis sposobu i zasad integracji z systemami ze- wnętrznymi;

• opis sposobu i zasad uruchomienia środowiska produkcyjnego,

• opis kodów źródłowych Oprogramowania Dedy- kowanego;

• opis wymagań sprzętowych i programowych;

• opis polityki backupowej

• opis programowych zasad bezpieczeństwa i ochrony danych

Dokument w wersji papiero- wej oraz elek- tronicznej w formie plików edytowalnych MS Word i/lub PDF (1 płyta CD/DVD).

14. Raport z wdroże- nia Platformy

Dokument zawierający co najmniej:

• Podsumowanie przebiegu wykonania i wdroże- nia Platformy, w tym Założenia pierwotnych efektów wdrożenia,

• Przebieg realizacji Umowy,

• Potwierdzenie poprawnego działania i spełnia- nia wymagań przez replikacje danych w CPD Za- mawiającego opisanej w rozdziale 8 niniejszego dokumentu,

• Osiągnięcie końcowych efektów udostępnienia systemu,

• Zebrane doświadczenia.

Dokument w wersji papiero- wej oraz elek- tronicznej w formie plików edytowalnych MS Word i/lub PDF (1 płyta CD/DVD).

(*) – standardy projektowe muszą być zgodne z przyjętą metodyką zarządzania projektami Prince2.

Opis Przedmiotu Zamówienia strona 25

5. Koncepcja Platformy

Koncepcja rozwiązania zakłada udostępnienie Platformy złożonej z następujących Komponentów:

1. Portalu dostępowego,

2. Modułu komunikacji,

3. Modułu Open Data,

4. Modułu usługowego,

5. Modułu Administratora,

6. Szyny danych ESB umożliwiającej integrację rozwiązań.

Propozycję architektury rozwiązania w podziale na warstwę dostępu, systemową, integracji oraz systemów wspierających przedstawiono na rysunku 2.

Rysunek 2. Model architektury Platformy

Opis Przedmiotu Zamówienia strona 26

Użytkownikiem Platformy ma być każdy użytkownik Internetu bez ograniczeń. Obsługa Platformy ma być realizowana w języku polskim.

Osoby korzystające z Platformy dzielą się na grupy:

1. Administratorzy

2. Użytkownicy wewnętrzni

3. Użytkownicy zewnętrzni

5.1. Portal dostępowy

Portal dostępowy będzie funkcjonował jako jeden punkt dostępowy dla klientów Ma- zowieckiego Urzędu Wojewódzkiego w Warszawie oraz podległym Wojewodzie Ma- zowieckiemu jednostkom administracji rządowej i będzie dostępny z poziomu ich serwisów internetowych. Użytkownicy zewnętrzni będą mogli uzyskać dostęp do Platformy za pomocą strony internetowej. Ponadto w ramach Platformy zostanie uruchomiona wersja mobilna strony umożliwiająca jej wyświetlanie na urządzeniach mobilnych. W ramach przedmiotu zamówienia Wykonawca będzie zobowiązany do opracowania wersji mobilnej portalu dostępowego, która będzie miała za zadanie przygotowanie wersji interfejsu przystosowanego do urządzeń mobilnych poprzez zastosowanie dedykowanych mechanizmów lub rozbudowanego podejścia do tech- nologii responsywności stron internetowych istniejących serwisów w celu łatwiej- szego i szybszego przeglądania informacji na urządzeniach mobilnych, w szczegól- ności na telefonach komórkowych i smartfonach. Część dostępna informacji w por- talu powinna zostać zredukowana, a pliki graficzne powinny zostać przygotowane w wersji o ograniczonej wielkości. Jest to konieczne ze względu na ograniczenia zwią- zane przystosowaniem wyświetlania poszczególnych formatek interfejsu na urządze- niach o różniej wielkości ekranu i jego rozdzielczości.

Dostęp do Platformy będzie możliwy dla użytkowników sieci Internet

przy wykorzystaniu komputerów osobistych/ tabletów, urządzeń mo- bilnych opartych na systemach iOS i Android.

Portal dostępowy będzie zawierał katalog e-usług związanych z realizacją spraw urzędowych. Logowanie do Platformy będzie odbywało się z wykorzystaniem Profilu Zaufanego/jego następcy. Wykonawca zobowiązany jest do zaprojektowania i wy- konania Formularzy elektronicznych usług na Platformie. W ramach realizacji e-usług

Opis Przedmiotu Zamówienia strona 27

(wskazane w tabeli 3), Wykonawca wprowadzi szczegółowy opis realizacji e-usługi w zależności od wybranej opcji (Platforma, ePUAP, plik z kodem kreskowym) oraz opis realizacji w trybie tradycyjnym, wykona Formularze elektroniczne, Formularze elektroniczne ePUAP, umożliwiając załatwienie sprawy za pomocą obu rozwiązań. Formularz elektroniczny ma umożliwiać dodatkowo opcję wypełnienia danymi i zapi- sania pliku (pdf) oraz wydruku zawierającego kod kreskowy. Plik zawierający kod kreskowy ma zostać zapisany na serwerze w celu automatycznego zaczytania meta-

danych podczas rejestracji dokumentu do używanego przez Zamawiającego systemu EZD.

Dostęp do katalogu e-usług, do opisów e-usług, do dokumentów powiązanych z kar- tami usług, np. wniosków do pobrania, a także do Formularzy elektronicznych, które po wypełnieniu będzie można wydrukować z kodem kreskowym, możliwy będzie bez konieczności logowania do Platformy.

Platforma musi posiadać funkcję zaawansowanego wyszukiwania kontekstowego z możliwością tworzenia złożonych zapytań oraz funkcję wyszukiwania strukturalnego udostępnionych e-usług.

Portal dostępowy umożliwi dostęp do profilu użytkownika. Profil użytkownika będzie stanowił dedykowany i spersonalizowany obszar pozwalający na zarządzanie usłu- gami i danymi w kontekście zautoryzowanego i zidentyfikowanego interesanta. Na koncie użytkownik będzie mógł zarządzać dokumentami, informacjami i danymi po- wstającymi w wyniku komunikacji z MUW i JAR. Profil użytkownika powinien cecho- wać się w szczególności:

• W przypadku usług, dla których uwierzytelnienie przesyłanych dokumentów jest niezbędne do realizacji sprawy nastąpi logowanie przez Profil Xxx- xxxx/jego następcę;

• Logowanie do Platformy przez Administratora będzie możliwe zarówno przez wbudowany mechanizm uwierzytelniania wewnętrznego – system

kont lokalnych na Platformie jak i Profil Zaufany/jego następcę;

• Logowanie dla Administratorów i Użytkowników wewnętrznych Platformy powinno być realizowane przez mechanizm dwuskładnikowego uwierzytel- niania oraz wyłącznie z wyznaczonych adresów IP;

• Rozróżnieniem kont Użytkowników zewnętrznych na osoby fizyczne, osoby prawne i podmioty gospodarcze;

Opis Przedmiotu Zamówienia strona 28

• Możliwością przeglądania i zarządzania usługami i płatnościami powstają- cymi w komunikacji z Urzędem.

Schemat powiązań realizowanych za pomocą profilu użytkownika przedstawiono na rysunku 3.

Rysunek 3. Schemat powiązań realizowanych za pomocą profilu użytkownika

Interfejs użytkownika zostanie zaprojektowany w zgodzie z powszechnie przyjętymi standardami i szeroko pojętymi dobrymi praktykami w dziedzinie konstruowania in- tuicyjnego interfejsu użytkownika. Interfejsy graficzne zostaną zaprojektowane z uwzględnieniem wymagań standardu WCAG2.0 (zweryfikowane narzędziem online wskazanym przez Wykonawcę i zaakceptowanym przez Zamawiającego) z dostoso- waniem do specyficznych wymagań aplikacji mobilnych oraz najpopularniejszych platform sprzętowych.

Wykonawca określi w ramach koncepcji realizacji Projektu Technicznego propono- wany model graficzny i funkcjonalny interfejsu użytkownika (3 różne wersje), biorąc pod uwagę najnowsze trendy i najlepsze praktyki w tym obszarze. Przy projektowa- niu warstwy prezentacji i usług należy stosować projektowanie zorientowane na użytkownika (ang. User-Centered Design, UCS). Z uwzględnieniem zgodności z wi-

zualizacją strony xxxxxxxxxxx.xx oraz przekazanego przez Zamawiającego po podpi- saniu Umowy logotypu projektu.

Za pośrednictwem portalu użytkownicy uzyskają dostęp do funkcjonalności udostęp- nionych w ramach modułu komunikacji. Szczegółowe wymagania funkcjonalne

w zakresie Komponentu modelu architektury Platformy dotyczącego portalu dostę- powego przedstawiono w rozdziale 6 niniejszego opracowania.

Opis Przedmiotu Zamówienia strona 29

5.2. Moduł komunikacji

Za pośrednictwem modułu komunikacji użytkownicy uzyskają dostęp do następują- cych funkcjonalności.

5.2.1. Interfejs zaawansowanej pomocy tzw. wirtu- alny asystent

Wirtualny asystent będzie stanowił rodzaj zaawansowanej pomocy dla użytkowników Platformy. Użytkownik będzie miał możliwość skorzystania z funkcji Wirtualnego Asy- stenta również bez konieczności logowania się do Profilu użytkownika. Wirtualny Asystent będzie umożliwiał użytkownikowi poprzez symulację rozmowy w języku na- turalnym, uzyskanie interesujących go informacji dotyczących poszczególnych e- usług lub pomocy technicznej w zakresie działania Platformy. Platforma w obszarze Wirtualnego Asystenta powinna w szczególności:

• Komunikować się w języku polskim,

• Udzielać informacji o udostępnianych e-usługach,

• Udzielać informacji o jednostkach biorących udział w Projekcie,

• Potrafić utrzymywać wiele jednoczesnych sesji przy zachowaniu wyszukiwa- nia kontekstowego,

• Rozumieć polecenia i pytania użytkownika,

• Udzielać natychmiastowej odpowiedzi na zadawane pytania,

• Potrafić prowadzić logiczny ciąg rozmowy, który ma doprowadzić do okre- ślonego celu,

• Potrafić doprecyzować niejasne pytania oraz posiadać obsługę błędów w przypadku problemów z interpretacją zapytania.

• Komunikować się z użytkownikiem w języku polskim.

Wirtualny Asystent powinien zostać wyposażony w:

• mechanizm powitań rozumiany jako zdefiniowanie określonego zachowania Wirtualnego Doradcy w momencie rozpoczęcia konwersacji,

• mechanizm skryptów rozmów za pomocą, którego program przeprowadza rozmowę i staje się aktywnym jej uczestnikiem,

• mechanizm pytań doprecyzowujących – uruchamiany w sytuacji kiedy pyta- nie użytkownika nie jest jednoznaczne i wiele odpowiedzi pasuje do pytania.

Opis Przedmiotu Zamówienia strona 30

Wykonawca w ramach przedmiotu zamówienia będzie zobowiązany do przygotowa- nia bazy wiedzy dla Wirtualnego Asystenta. Administratorzy Platformy powinni mieć możliwość jej rozbudowy poprzez wprowadzanie do Platformy scenariuszy rozmów. Moduł Administratora powinien umożliwiać również bieżącą kontrolę pracy programu poprzez podgląd zapisu rozmów oraz raportowanie.

5.2.2. Usługa tłumacza migowego online

Schemat funkcjonowania usługi języka migowego online przedstawiono na rysunku 4.

Rysunek 4. Schemat funkcjonowania usługi języka migowego online w ramach

Platformy

Platforma musi zapewniać możliwość dostępu do usługi tłumacza migowego online dla niezalogowanych użytkowników. Użytkownik będzie mógł skorzystać z modelu ciągłego dostępu do usługi tłumacza migowego on-line w godzinach 09:00 – 15:00.

Opis Przedmiotu Zamówienia strona 31

Wykonawca w ramach świadczenia usługi języka migowego online zobowiązany bę- dzie do dysponowania co najmniej dwoma osobami/tłumaczami języka migowego dedykowanymi do obsługi konferencji znającymi Polski Język Migowy (PJM) oraz System Języka Migowego (SJM). Osoby te powinny wykazać się co najmniej 3 letnim doświadczeniem zawodowym w wykonywaniu czynności tłumaczeń na język migowy oraz posiadać potwierdzenie znajomości języka migowego wydane przez Polski Zwią- zek Głuchych lub przez Stowarzyszenie Tłumaczy Polskiego Języka Migowego (STPJM). Tłumacze w ramach świadczenia usługi muszą być przygotowani do tłu- maczenia podczas bezpośredniej transmisji online tzn. strój, fryzura, itp. muszą być odpowiednie do realizowanego zadania i muszą zachowywać się w sposób godny z powściągliwością i dyskretnie, a tłumaczenia muszą być wykonywane z najwyższą starannością.

5.2.3. Czat z pracownikiem Zamawiającego

Platforma powinna także umożliwiać prowadzenie rozmów czat w trybie Użytkownik zewnętrzny/Interesant (z aplikacji udostępnionej na portalu dostępowym) – Urzęd- nik. Użytkownik zewnętrzny odwiedzający portal dostępowy będzie posiadał możli- wość zainicjowania rozmowy z Urzędnikiem za pomocą komponentu z oknem do rozmowy zaimplementowanym na portalu. Jeżeli ilość zainteresowanych użytkowni- ków czatem przekracza możliwość obsługi Urzędników, Platforma powinna umieścić czat w kolejce oczekujących do momentu, gdy odpowiedni Urzędnik będzie wolny i poinformować o tym użytkownika. Nadejście nowej rozmowy powinno być sygnali- zowane pojawieniem się dodatkowego panelu bocznego zawierającego okno z roz- mową czat. W module Administratora, Platforma powinna umożliwiać podgląd histo- rii rozmów pod kątem daty i nazwy Użytkownika wewnętrznego przeprowadzającego rozmowę. Użytkownik wewnętrzny zalogowany do Platformy także powinien mieć podgląd historii swoich rozmów.

5.2.4. Przekierowania do serwisów internetowych i Biuletynu Informacji Publicznej poszczegól- nych jednostek administracji rządowej

Na portalu dostępowym zostaną umieszczone linki kierujące użytkownika do odpo- wiednich serwisów internetowych poszczególnych jednostek uczestniczących w rea- lizacji Umowy oraz Biuletynu Informacji Publicznej.

Opis Przedmiotu Zamówienia strona 32

5.2.5. Rezerwacja wizyt

Rezerwacji online terminu złożenia/odbioru dokumentów lub wizyty w urzędzie ma mieć możliwość integracji z kalendarzami Google, Xxxxxxx.xxx, Apple, MS Exchange, Caldav/iCal * (*Wszystkie nazwy użyte w dokumencie mają cel informacyjny).

Użytkownik z wykorzystaniem Modułu komunikacji będzie miał możliwość rezerwacji online terminu złożenia/odbioru dokumentów lub wizyty w urzędzie. Platforma musi:

• Umożliwiać rezerwacje wizyty w Urzędzie poprzez Profil użytkownika,

• Umożliwiać definiowanie poprzez administratora portalu wirtualnych kolejek do: urzędnika, grupy urzędników lub załatwienie wybranego rodzaju sprawy,

• Zostać zintegrowany z posiadanymi przez Zamawiającego systemami kolej- kowymi dla spraw obsługiwanych na bieżąco, gdzie tworzą się kolejki inte- resantów,

• Posiadać funkcjonalność modułu statystycznego umożliwiającą zbieranie in- formacji o ilości i rodzaju zaplanowanych i odbytych wizyt.

Obecnie Zamawiający posiada system kolejkowy w trzech lokalizacjach:

• Wydziale Spraw Cudzoziemców w Mazowieckim Urzędzie Wojewódzkim w Warszawie w lokalizacji L1 – Xxxxxxxx, xx. Xxxxxxxxxxxxx 0/0,

• Delegaturze Mazowieckiego Urzędu Wojewódzkiego w Warszawie w Płocku, Xxxxx, xx. Xxxxxxxxxx 00,

• Delegaturze Mazowieckiego Urzędu Wojewódzkiego w Warszawie w Rado- miu, Xxxxx, xx. Xxxxxxxxxxx 00.

Platforma powinna umożliwiać możliwość zintegrowania z dowolnym systemem ko- lejkowym za pomocą otwartego API, ponieważ Zamawiający planuje utworzenie

„Contact Center” Mazowieckiego Urzędu Wojewódzkiego w Warszawie w ramach, którego zostanie udostępniony system kolejkowy w pozostałych lokalizacjach.

5.2.6. Otrzymywanie powiadomień w formie SMS lub mail

Platforma powinna zostać wyposażona w funkcjonalność powiadomień (e-mail, sms).

Opis Przedmiotu Zamówienia strona 33

W ramach realizacji prac Wykonawca będzie zobowiązany do wytworzenia rozwiąza- nia obejmującego generowanie i przesyłanie automatycznych powiadomień i infor- macji z i do systemów wspierających. Obecnie używanym przez Zamawiającego sys- temem jest EZD, jednak opisane wyżej powiadomienia muszą mieć możliwość inte- gracji z innymi systemami poprzez API. Platforma musi umożliwiać informowanie użytkowników (dowolna i zdefiniowana słownikowo wiadomość tekstowa) o spra- wach związanych z realizowanymi e-usługami za pomocą:

• kont ePUAP,

• konta na Platformie

• wiadomości e-mail,

• wiadomości SMS.

Szczegółowe wymagania funkcjonalne w zakresie Komponentów modelu architek- tury Platformy dotyczących modułu komunikacji przedstawiono w rozdziale 6 niniej- szego opracowania.

5.3. Moduł Open Data

Elementem funkcjonalnym Platformy będzie portal danych otwartych, który umożliwi udostępnienie informacji sektora publicznego szero- kiemu gronu odbiorców.

W ramach realizacji Umowy zostanie wykonany moduł Open Data (otwartych da-

nych), dzięki czemu Użytkownik zewnętrzny będzie miał możliwość przeglądania da- nych udostępnionych. Przez otwarte dane należy rozumieć dane publiczne dostępne za pośrednictwem portalu dostępowego, udostępniane w Otwartych formatach, tj.

w formatach plików elektronicznych posiadających jawną strukturę, zgodnie z Za- łącznikiem nr 2 Dz.U. 2016 poz.113).

W ramach modułu Open Data udostępniane będą dane w oparciu o zasady:

Opis Przedmiotu Zamówienia strona 34

1. Dostępności – dane mają być osiągalne dla jak najszerszego grona użyt- kowników i będą mogły być wykorzystane w dowolnych celach, w tym biz- nesowych,

2. Aktualności – dane mają być udostępniane na tyle szybko, by nie traciły swojej wartości,

3. Kompletności – dane mają być upubliczniane w całym wskazanym zakre- sie,

4. Maszynowo odczytywalne – dane będą uporządkowane i będą mogły być przetwarzane automatycznie,

5. Udostępniane bez dyskryminacji – dane mają być dostępne dla każ- dego, bez wymogu rejestracji,

6. Udostępniane bez ograniczeń licencyjnych.

W ramach przedmiotu zamówienia obowiązkiem Wykonawcy będzie zaprojektowanie i wykonanie modułu Open Data. Moduł Open Data będzie udostępniać Użytkowni- kom zewnętrznym, dane publiczne zarówno w postaci zestawień statystycznych ge- nerowanych na żądanie jak również zautomatyzowanego dostępu do danych źródło- wych przygotowanych do ponownego wykorzystania.

Moduł Open Data będzie udostępniał dane z wykorzystaniem Portalu dostępowego. Zakres udostępnionych danych zostanie podzielony na kategorie uzgodnione w trak- cie przygotowywania Projektu Technicznego. Implementacja Platformy zostanie przeprowadzona w sposób, który zapewni kompatybilność Platformy z krajową plat- formą danych otwartych xxxxx://xxxxxxxxxxxxx.xxx.xx/, w szczególności w zakresie określonych tam kategorii danych i atrybutów danych.

Umieszczenie danych na portalu wraz z ich zarządzaniem będzie możliwe z wykorzy- staniem Modułu Administratora, dodatkowo elementem Platformy będzie repozyto- rium plików oczekujących na publikację. Dostęp do repozytorium będzie możliwy dla Użytkowników wewnętrznych, którzy będą posiadać odpowiednie konto dostępu

umożliwiające umieszczenie w repozytorium pliku z danymi. Pliki zamieszczane w repozytorium będą publikowane dla Użytkowników zewnętrznych dopiero po ich ak- ceptacji przez Użytkowników wewnętrznych z odpowiednim uprawnieniem. Poziomy uprawnień muszą dawać możliwość ich nadawania zgodnie z opisem powyżej.

Szczegółowe wymagania funkcjonalne w zakresie Komponentu modelu architektury Platformy dotyczącego modułu Open Data przedstawiono w rozdziale 6 niniejszego opracowania.

Opis Przedmiotu Zamówienia strona 35

5.4. Moduł usługowy

Wykonawca zobowiązany jest do zaprojektowania i wykonania For- mularzy elektronicznych usług na Platformie i Formularzy elektronicz- nych ePUAP na ePUAP. E-usługi, które mają zostać odwzorowane w ePUAP i na Platformie zostały wskazane w katalogu e-usług.

Moduł usługowy musi umożliwiać Użytkownikom Zewnętrznym, uruchomienie usługi i wypełnienie Formularza elektronicznego w ramach ustalonej procedury. Moduł bę- dzie umożliwiał dostęp do następujących funkcjonalności:

• Zapoznanie się z instrukcją realizacji sprawy:

o tradycyjnie (w urzędzie),

o za pomocą Platformy,

o za pomocą ePUAP,

• Możliwość wybrania sposobu komunikacji z urzędem,

• Wypełnienie udostępnionego Formularza elektronicznego, dołączenie za- łączników, walidacja formularza, weryfikacja załączenia dozwolonego typu pliku załącznika i wysłanie go do urzędu, otrzymując w odpowiedzi urzędowe poświadczenie przedłożenia. Wypełnienie Formularza elektronicznego i jego wydrukowanie bez podpisywania podpisem elektronicznym/Profilem Zaufa- nym/ich następcą. Formularz elektroniczny ma mieć opcję wypełnienia da- nymi i zapisania pliku (pdf) oraz wydruku zawierającego kod kreskowy,

• Podpisanie wysłanych dokumentów Profilem Zaufanym/podpisem kwalifiko- wanym/ich następcą,

• Możliwość podpisania jednego dokumentu przez kilka osób,

• Możliwość podpisania załączników oraz pliku formularza w formacie xml.

• Dostęp do wysyłanej korespondencji za pośrednictwem Platformy, do otrzy- mywanych powiadomień (również wysyłanych za pomocą SMS lub email), historii płatności,

• Otrzymanie decyzji lub postanowienia (na konto na Platformie i/lub ePUAP),

• Obsługę płatności za wybraną e-usługę,

Opis Przedmiotu Zamówienia strona 36

• Uzyskanie informacji o historii dokonywanych w skrzynce kontaktowej ope- racji,

W ramach realizacji Umowy wymagane jest także zaprojektowanie i wykonanie For- mularzy elektronicznych udostępnionych przez ePUAP na potrzeby świadczenia e- usług przez jednostki uczestniczące w projekcie. Wdrożone e-usługi muszą zapew- niać funkcjonalność pozwalającą na pełną obsługę realizowanych procedur związa- nych z nimi dokumentów i ewentualnych płatności.

Zarówno Użytkownik zewnętrzny (np. obywatel, przedsiębiorca) jak i Użytkownik wewnętrzny (np. pracownik jednostki Zamawiającego), musi posiadać możliwość ko- rzystania z udostępnionych mu danych i usług w zakresie zgodnym z posiadanymi uprawnieniami.

W ramach opracowywania Modułu usługowego Wykonawca zobo- wiązany jest do zapewnienia dostępu do Formularzy elektronicznych ePUAP wykonanych w ramach Etapu II i III.

Wykonawca zobowiązany jest do:

Przygotowania wszystkich elektronicznych dokumentów (zgodnych z właściwymi przepisami prawa) występujących w poszczególnych usługach. Dokumenty elektro- niczne powinny być zgodne ze standardem dokumentów ePUAP2, które oparte są o format XML. Format wzorów powinien być zgodny z formatem przyjętym dla Cen- tralnego Repozytorium Wzorów Dokumentów Elektronicznych.

Opracowania aplikacji tj. elektronicznych formularzy oraz akcji w nich zawartych, zgodnych z dokumentacją poszczególnych usług. Dodatkowo formularze muszą speł- niać poniższe warunki:

a. Formularze będą tworzone z wykorzystaniem technologii XForms. Instrukcja opisująca zawartość i strukturę formularzy XForms uruchamianych na plat- formie ePUAP2, opublikowana jest na portalu ePUAP2 .

b. Przy tworzeniu formularzy należy dążyć do maksymalnego wykorzystania słowników dostępnych na ePUAP.

c. Formularz musi zapewnić walidacje wprowadzanych danych po stronie klienta i serwera zgodnie z walidacją zawartą w schemacie dokumentu. Gdy wynik walidacji formularza będzie wskazywał błędy należy podać jasny opis błędu.

Opis Przedmiotu Zamówienia strona 37

d. W budowanych formularzach należy wykorzystać mechanizm ePUAP2 pobie- rania danych z profilu - celem uzupełniania danych o wnioskodawcy.

e. Formularz musi posiadać możliwość świadczenia odpowiedzi.

f. Układ graficzny wszystkich dostarczonych formularzy powinien być jednolity.

g. Do każdego Formularza elektronicznego należy stworzyć kartę usługi.

h. Wizualizacja dokumentu elektronicznego powinna być zgodna z wyglądem formularza papierowego określonego we właściwym akcie normatywnym.

W przypadku, gdy dokument składany za pomocą ePUAP wymaga płatności, to jeśli jest taka możliwość, będzie ona realizowana przez system płatności zintegrowany z ePUAP. W związku z tym komponent musi obejmować także obsługę płatności za wybrane e-usługi z wykorzystaniem płatności elektronicznych.

Jeżeli jest taka możliwość, Wykonawca może korzystać przy opracowaniu (przygo- towaniu i uruchomieniu) Formularzy elektronicznych do opublikowania na ePUAP z gotowych, opublikowanych w CRD wzorów.

Szczegółowe wymagania funkcjonalne w zakresie Komponentu modelu architektury Platformy dotyczącego modułu usługowego przedstawiono w rozdziale 6 niniejszego opracowania.

5.4.1. Katalog e-usług

Wykaz e-usług udostępnionych w wyniku realizacji Umowy przedstawiono w tabeli

3. Dokumenty do jednej przykładowej e-usługi tj. opis e-usługi na ePUAP, opis e- usługi

na Platformę, formularz e-usługi, karta e-usługi, oraz zmapowany proces e-usługi, zamieszczono w załączniku nr 1 do OPZ.

Dokumenty do wszystkich e-usług, zostaną przekazane Wykonawcy po podpisaniu Umowy.

Zamawiający zastrzega sobie możliwość wprowadzania zmian w opisach e-usług i w poniższym wykazie (nie dotyczy ilości).

Usługi przedstawione w tabeli 3 o symbolach od MUW_03 do MUW_08, to usługi ogólne, które będą udostępnione na Platformie dla MUW i dla 12 JARów.

Zamawiający dopuszcza możliwość przesuwania usług między Etapami przez Wyko-

nawcę, jedynie za zgodą Zamawiającego.

Zamawiający wymaga, aby tworzenie formularzy elektronicznych e-usług przez Wy- konawcę odbywało się przy udziale i konsultacji z Zamawiającym. Wykonawca ma obowiązek przekazywać na bieżąco (w Raportach) wynik prac nad formularzami. Na spotkaniach omawiane będą efekty prac, w celu weryfikacji czy formularze tworzone są poprawnie.

Tabela 3. Wykaz e-usług, które mają zostać udostępnione w wyniku wdrożenia

Lp ID procesu Nazwa Publikacja na: Logowanie: ePUAP forma

Plat-

1 SPN_01

Profil Za- ufany/ jego na- stępca e-płat- ności

Wniosek o wydanie decyzji stwierdzającej nabycie z mocy prawa własności nieruchomości przez kościelna lub wyznaniową osobę prawną

X X X -

2 SPN_02

Wniosek o wydanie zaświadczenia o stanie postępowań administra- cyjnych dotyczących prawidłowości ich nabycia przez Skarb Państwa lub jednostkę samorządu terytorialnego

X X X X

3 SPN_03

Wniosek o wydanie decyzji o nabyciu przez Skarb Państwa lub jed- nostkę samorządu terytorialnego z mocy prawa z dniem 1 stycznia 1999 roku własności nieruchomości zajętej w dniu 31 grudnia 1998 roku pod drogę publiczną

X X X -

4 WBZK_01

Udzielenie przez Wojewodę dotacji z budżetu państwa na zadania związane z przeciwdziałaniem i usuwaniem skutków zdarzeń noszą- cych znamiona klęski żywiołowej

X X X -

5 WBZK_02

Udzielenie przez Wojewodę dotacji z budżetu państwa na zadania związane z usuwaniem skutków ruchów osuwiskowych ziemi lub przeciwdziałaniem tym zdarzeniom

X X X -

6 WBZK_03

Wniosek w sprawie powołania składu komisji do spraw szacowania szkód w gospodarstwach rolnych i działach specjalnych produkcji rolnej, w których wystąpiły szkody spowodowane przez niekorzystne zjawisko atmosferyczne

X X X -

7 WBZK_04

Sprawozdanie z wykorzystania dotacji podmiotowej z budżetu pań- stwa dla spółek wodnych i związków spółek wodnych z przeznacze- niem na bieżące utrzymanie wód i urządzeń melioracji wodnych szczegółowych

X X X -

8 WBZK_05

Wniosek o przyznanie dotacji podmiotowej z budżetu państwa dla spółek wodnych z przeznaczeniem na bieżące utrzymanie wód i urządzeń melioracji wodnych szczegółowych

X X X -

9 WBZK_06

Sprawozdanie z wykorzystania dotacji z rezerwy celowej budżetu państwa dla spółek wodnych i związków spółek wodnych z przezna- czeniem na bieżące utrzymanie wód i urządzeń melioracji wodnych szczegółowych

X X X -

10 WBZK_07 Pozwolenia na nabywanie, przechowywanie lub używanie materia-

łów wybuchowych przeznaczonych do użytku cywilnego X X X X

11 WBZK_08

Wniosek o przyznanie dotacji podmiotowej z budżetu państwa oraz dotacji z rezerwy celowej budżetu państwa dla związku spółek wod- nych z przeznaczeniem na bieżące utrzymanie wód i urządzeń melio- racji wodnych szczegółowych

X X X -

12 WBZK_09

Wniosek o udzielenie dotacji celowej z budżetu państwa z przezna- czeniem na realizację zadań z zakresu spraw obronnych i obrony cy- wilnej

X X X -

13 WIF_01 Wydawanie zgody na posiadanie w celach medycznych preparatów

zawierających środki odurzające lub substancje psychotropowe X X X X

14 WIF_02

Wniosek o zawieszenie postępowania administracyjnego prowadzo- nego przez Mazowieckiego Wojewódzkiego Inspektora Farmaceu- tycznego

X X X -

Opis Przedmiotu Zamówienia strona 38

15 WIF_04 Wydawanie zgody na uruchomienie apteki szpitalnej X X X -

16 WIF_05 Wydawanie zezwoleń na prowadzenie punktów aptecznych X X X X

17 WIF_06 Wydawanie zgody na uruchomienie działu farmacji X X X -

18 WIF_07 Wydawanie zezwoleń na prowadzenie apteki ogólnodostępnej X X X X

19 WINB_01

Odwołanie/zażalenie do Głównego Inspektora Nadzoru Budowla- nego od decyzji/postanowienia wydawanego przez wojewódzkiego inspektora nadzoru budowlanego

X X X -

20 WINB_03

Wniosek o przywrócenie terminu na złożenie odwołania/zażalenia na decyzję/postępowanie wydane przez powiatowego inspektora nadzoru budowlanego

X X X -

21 WINB_04

Wniosek o stwierdzenie nieważności decyzji lub postanowienia po- wiatowego inspektora nadzoru budowlanego nie badanych w trybie odwoławczym

X X X -

22 WINB_05 Wniosek o uchylenie lub zmianę decyzji ostatecznej wydanej przez

wojewódzkiego inspektora nadzoru budowlanego X X X - 23 WINB_06 Wniosek o uzupełnienie decyzji wojewódzkiego inspektora nadzoru

budowlanego X X X -

24 WINB_07

Wniosek o wznowienie postępowania administracyjnego w sprawie zakończonej ostateczną decyzją lub ostatecznym postanowieniem wojewódzkiego inspektora nadzoru budowlanego wydanym w I in- stancji

X X X -

25 WINB_08 Wniosek o zawieszenie postępowania administracyjnego prowadzo-

nego przez wojewódzkiego inspektora nadzoru budowlanego X X X -

26 WINB_09

Przyjęcie zawiadomienia o przeprowadzonej kontroli okresowej obiektu wielkopowierzchniowego (budynku o powierzchni zabu- dowy przekraczającej 200 m2 oraz innych obiektów budowalnych o powierzchni dachu przekraczającej 100 m2) dla których właściwym organem nadzoru budowlanego jest wojewódzki inspektor nadzoru budowlanego

X X X -

27 WINB_10 Wniosek o wstrzymanie wykonania decyzji X X X - 28 WIORIN_01 Cofnięcie upoważnienia do prowadzenia działalności w zakresie cer-

X X X X Wpis do „Rejestru przedsiębiorców wykonujących działalność w

tyfikacji w integrowanej produkcji roślin 29 WIORIN_02

za-

X X X X

kresie prowadzenia szkoleń w zakresie środków ochrony roślin”

30 WIORIN_03

Wpis do „Rejestru przedsiębiorców, wykonujących działalność w za- kresie potwierdzenia sprawności technicznej sprzętu przeznaczo- nego do stosowania środków ochrony roślin”

X X X X

31 WIORIN_04

Wpis do „Rejestru podmiotów niebędących przedsiębiorcami, pro- wadzących działalność w zakresie potwierdzania sprawności tech- nicznej sprzętu przeznaczonego do stosowania środków ochrony ro- ślin”

X X X X

Powołanie komisji egzaminacyjnej na szkolenia w zakresie środków

32 WIORIN_05

X X X - Upoważnienie do prowadzenia działalności w zakresie certyfikacji w

ochrony roślin 33 WIORIN_06

X X X X

integrowanej produkcji roślin

34 WIORIN_07

Wniosek o pozwolenie na zastosowanie konwencjonalnego mate- riału siewnego, nasion lub wegetatywnego materiału nasadzenio- wego w rolnictwie ekologicznym

X X X -

35 WIORIN_08 Wydawanie świadectw fitosanitarnych dla eksportu i reeksportu X X X X

Wpis do "Rejestru podmiotów niebędących przedsiębiorcami,

36 WIORIN_09 wadzących szkolenia w zakresie środków ochrony

pro-

roślin"

X X X X

37 WIORIN_10

Uzyskanie informacji na temat badania laboratoryjnego roślin/pro- duktów roślinnych/przedmiotów na obecność organizmów szkodli- wych

X X X -

38 WIORIN_11

Zgłoszenie prowadzenia działalności - wytwarzania, obrotu materia- łem siewnym i wpis do ewidencji przedsiębiorców, rolników, do- stawców

X X X -

Wpis do rejestru przedsiębiorców, prowadzonego przez Wojewódz-

39 WIORIN_13

kiego Inspektora Ochrony Roślin i Nasiennictwa X X X X

Opis Przedmiotu Zamówienia strona 39

40 WZ_01 Kurs w zakresie kwalifikowanej pierwszej pomocy X X X -

Nadanie lub odebranie uprawnień do tworzenia wniosków dotyczą-

41 WZ_02

cych zmian w księdze rejestrowej podmiotu leczniczego X X X -

42 WZ_03

Wyrażenie zgody na czasowe zaprzestanie wykonywania działalności leczniczej podmiotu leczniczego wykonującego działalność leczniczą w rodzaju stacjonarne i całodobowe świadczenia zdrowotne, w za- kresie świadczeń zdrowotnych finansowanych ze środków publicz- nych

X X X X

Wniosek o uzyskanie karty doskonalenia zawodowego dla ratownika

43 WZ_04

medycznego X X X - 44 WZ_05 Wniosek o uzyskanie karty doskonalenia zawodowego dla dyspozy-

tora medycznego X X X -

45 FIN_01

Zwrot z tytułu: - nadpłat za opłaty paszportowe, - rezygnacja z wydania dokumentu, - ukończone 70 lat, - obniżenie opłaty (zmiana danych, zmiana wyglądu, brak miejsc w paszporcie), - ulga (Karta Dużej Rodziny, dziecko objęte obowiązkiem szkolnym, emeryt, itp.).

- X X -

46 FIN_02

Zwrot opłaty z tytułu: zezwolenia na pracę dla cudzoziemca, wyda- nie karty pobytu, polskiego dokumentu podróży dla cudzoziemca, polskiego dokumentu tożsamości cudzoziemca

- X X -

Zwrot z tytułu:

47 FIN_03

X X X - Wniosek o ponowne wykorzystanie informacji sektora publicznego

- zwrot mylnej wpłaty na konto MUW 48 BKO_04

X X X - Zaświadczenie o niezaleganiu z płatnościami z

(ISP) 49 WIOS_03 Wniosek o podjęcie interwencji X X X - 50 WIOS_04

tytułu administracyj-

X X X X

nych kar pieniężnych za naruszanie warunków ochrony środowiska 51 WIOS_05 Wydawanie zaświadczeń, informacji i

opinii X X X -

Udostępnienie informacji o aktualnym stanie jakości

52 WIOS_06 Udostępnienie informacji o środowisku X X X - 53 WIOS_07

powietrza na

X X X - Zamówienie na pobranie próbek i wykonanie analizy fizykochemicz-

danym obszarze 54 WIOS_08

X X X - Wydawanie zaświadczeń potwierdzających wpis do rejestru zabyt-

nej lub wykonanie pomiarów 55 WUOZ_01 ków

X X X X

Wniosek o włączenie ruchomości do wojewódzkiej ewidencji zabyt-

56 WUOZ_02

X X X -

ków

57 WUOZ_03

Wydanie zaświadczeń czy obiekt jest użytkowany i konserwowany, zgodnie z przepisami ustawy o ochronie zabytków i opiece nad za- bytkami

X X X X

Zawiadomienie o podjęciu działań przy zabytku wpisanym do reje-

58 WUOZ_04

X X X -

stru zabytków

Wydanie decyzji dot. zmiany terminu zakończenia badań archeolo-

59 WUOZ_05

X X X X Edukacja zdrowotna. Deklaracja przystąpienia do programu, akcji,

gicznych 60 WSSE_01

X X X - Edukacja zdrowotna. Udzielenie informacji w zakresie działań eduka-

kampanii 61 WSSE_02

X X X - Opinia sanitarna o warunkach bezpieczeństwa i higieny dla placówki

cyjnych 62 WSSE_03

X X X -

opiekuńczo - wychowawczej

63 WSSE_04 Zgłoszenie interwencji X X X -

Informacja o użyciu czynnika biologicznego w środowisku pracy, na-

64 WSSE_06 leżącego do grupy zagrożenia 2-4

X X X -

65 WSSE_07

Opinia Państwowego Wojewódzkiego Inspektora Sanitarnego o do- puszczeniu statku żeglugi śródlądowej do eksploatacji pod wzglę- dem wymagań sanitarnych

X X X X

Opis Przedmiotu Zamówienia strona 40

66 WIJHARS_01 Dokonanie oceny jakości handlowej artykułów rolno-spożywczych X X X X

67 WIJHARS_02

Dokonanie oceny jakości handlowej artykułów rolno-spożywczych w związku z realizacją przedsięwzięcia przy udziale kredytu z linii Nowe Technologie (NT)

X X X X

68 WIJHARS_03

Przekazanie informacji o rozpoczęciu lub zaprzestaniu prowadzenia działalności w zakresie obrotu świeżymi owocami i warzywami obję- tymi normami handlowymi oraz o ilości owoców i warzyw wprowa- dzonych do obrotu.

X X X -

69 WIJHARS_04 Zgłoszenie działalności gospodarczej w zakresie produkcji, składowa-

nia, konfekcjonowania i obrotu artykułami rolno-spożywczymi X X X -

70 WPS_02

Wydawanie i cofanie zezwoleń na prowadzenie placówek opiekuń- czo – wychowawczych, regionalnych placówek opiekuńczo – tera- peutycznych i interwencyjnych ośrodków proadopcyjnych

X X X -

71 WPS_03

Zgłoszenie jednostki specjalistycznego poradnictwa do Rejestru jed- nostek specjalistycznego poradnictwa województwa mazowieckiego oraz zgłoszenie zmiany danych jednostek specjalistycznego porad- nictwa znajdujących się w aktualnym rejestrze X X X -

72 WIIH_01 Wniosek o rozpatrzenie sprawy przez Stały Sąd Polubowny w War-

szawie X X X - 73 WIIH_02 Wszczęcie postępowania w sprawie pozasądowego rozwiązywania

sporów konsumenckich X X X -

74 BO_01 Wniosek osoby związany z prawem do kontroli przetwarzanych jej

danych osobowych X X X -

75 WG_01 Dziennik praktyk zawodowych X X X X 76 WG_02 Nadzór nad działaniami geodety uprawnionego lub przedsiębiorcy w

zakresie przestrzegania przepisów w dziedzinie geodezji i kartografii X X X -

77 WI_01 Wpis do rejestru ośrodków doskonalenia techniki jazdy X X X X

78 WI_03 Zgłoszenie uwag i wniosków dot. nieprawidłowości w oznakowaniu

dróg X X X - 79 WI_02 Uzgadnianie czasu i trasy przemarszu pielgrzymki na terenie woje- wództwa - X X - 80 BKO_02 Udostępnienie dokumentacji przechowywanej w archiwum zakłado- wym Mazowieckiego Urzędu Województwa w Warszawie - X X -

81 BKO_03 Wydanie kopii dokumentacji płacowo – osobowej z archiwum zakła-

dowego MUW - X X -

82 WSC_01 Aplikacja elektronicznego wypełniania wniosku o udzielenie zezwo-

lenia na pobyt czasowy - X - X

83 WSC_02 Aplikacja elektronicznego wypełniania wniosku o udzielenie zezwo-

lenia na pobyt rezydenta długoterminowego UE - X - X

84 WSC_03 Aplikacja elektronicznego wypełniania wniosku o udzielenie zezwo-

lenia na pobyt stały - X - X 85 WSC_04 Aplikacja elektronicznego wypełniania wniosku o wymianę karty po-

bytu - X - X 86 WSC_05 Aplikacja elektronicznego wypełniania wniosku o wydanie/wymianę

karty członka rodziny obywatela UE - X - - 87 WSC_06 Aplikacja elektronicznego wypełniania wniosku o wydanie/wymianę

karty pobytu stałego członka rodziny obywatela UE - X - -

88 WSC_07 Aplikacja elektronicznego wypełniania wniosku o wymianę/wydanie

nowego zaświadczenia o zarejestrowaniu pobytu obywatela UE - X - - 89 WSC_08 Aplikacja elektronicznego wypełniania wniosku o zarejestrowanie

pobytu obywatela UE - X - - 90 WSC_09 Aplikacja elektronicznego wypełniania wniosków o przedłużenie

wizy krajowej przez Wojewodę Mazowieckiego - X - X 91 WSC_10 Aplikacja elektronicznego wypełnienia wniosków o przedłużenie

wizy Schengen przez Wojewodę Mazowieckiego - X - X 92 WSC_11 Aplikacja elektronicznego wypełniania wniosków o wpis do

rejestru

- X - X

zaproszeń prowadzonego przez Wojewodę Mazowieckiego

Opis Przedmiotu Zamówienia strona 41

Sprawdzenie stanu realizacji wniosku na podstawie jego identyfika-

93 WSO_01

- X - -

tora (np. wniosku paszportowego)

94 WSO_02 Wydanie dokumentu paszportowego - X - - 95 MUW_01 Rezerwacja terminu wizyty - X - -

96 MUW_02 Sprawdzenie statusu realizacji sprawy - X - -

97 MUW_03 Pismo ogólne - X X -

98 MUW_04 Uzupełnienie braków formalnych - X X -

99 MUW_05 Skarga - X X -

100 MUW_06 Wniosek o udostępnienie informacji publicznej - X X -

101 MUW_07 Wyznacz Pełnomocnika - X X X

102 MUW_08 Odwołaj Pełnomocnika - X X -

5.5. Moduł Administratora

Platforma będzie posiadała wspólny moduł administracyjny dla wszystkich modułów, do którego dostęp mogą mieć tylko uprawnieni użytkownicy w roli Administratora.

Moduł Administratora będzie stanowił Komponent odpowiedzialny za konfigurację i nadzór nad Platformą oraz czynnościami wykonywanymi przez poszczególnych użyt- kowników. Moduł Administratora będzie pozwalał na samodzielne budowanie przez Zamawiającego w przyszłości kolejnych Formularzy elektronicznych e-usług, w spo- sób obiektowy, bez konieczności znajomości języka programowania, który wykorzy- stano do budowy Platformy.

Szczegółowe wymagania funkcjonalne w zakresie Komponentu modelu architektury Platformy dotyczącego modułu Administratora przedstawiono w rozdziale 6 niniej- szego opracowania.

5.6. Szyna danych ESB

Komunikacja pomiędzy poszczególnymi podsystemami/modułami realizowana bę- dzie za pośrednictwem szyny danych (ESB). Szczegółowe wymagania w zakresie szyny danych ESB zostały zaprezentowane w rozdziale 6 niniejszego opracowania.

Opis Przedmiotu Zamówienia strona 42

Opis Przedmiotu Zamówienia strona 43

6. Wymagania w zakresie Platformy

Przy realizacji Platformy, Wykonawca zobowiązany jest do spełniania wszystkich wymagań określonych w OPZ.

Wykonawca zobowiązany jest do spełniania poniższych wymagań w zakresie Plat- formy:

o ogólnych,

o funkcjonalnych,

o w zakresie przepisów prawa,

o w zakresie bezpieczeństwa przetwarzania danych,

o w zakresie integracji,

o w zakresie zasilenia Platformy danymi,

o w zakresie sposobu realizacji,

o w zakresie testów,

o w zakresie Szkoleń i Konferencji.

6.1. Wymagania ogólne

Tabela 4. Wymagania ogólne

Numer Opis wymagania

WYMAGANIA OGÓLNE WO.1 Platforma musi posiadać interfejs użytkownika w języku polskim. WO.2 Platforma musi być spójna wewnętrzne (poszczególne elementy Platformy muszą po-

prawnie współpracować w ramach Platformy). WO.3 Platforma musi zapewnić pomoc kontekstową w polskiej wersji językowej. WO.4 Platforma musi umożliwiać zarządzanie danymi słownikowymi, ich dodawanie i edy-

cję, aktywację i dezaktywację z zachowaniem pełnej historii zmian i niezmienności zgromadzonych danych historycznych. WO.5 Platforma musi umożliwiać zarządzanie wzorcami Formularzy elektronicznych i doku- mentów/raportów z poziomu uprawnionego użytkownika merytorycznego, za pomocą języka naturalnego i interfejsu graficznego, bez konieczności znajomości języka pro- gramowania, z zachowaniem historii wersji i niezmienności danych historycznych. WO.6 Platforma

musi umożliwiać definiowanie przebiegów procesu oraz definiowanie zależ- ności pomiędzy danymi z poziomu uprawnionego użytkownika merytorycznego, za po- mocą języka naturalnego i interfejsu graficznego, bez konieczności znajomości języka programowania, z zachowaniem historii wersji i niezmienności danych historycznych. WO.7 Platforma musi umożliwiać komunikację z użytkownikiem x.xx. poprzez definiowanie

alertów, które w zależności od kroku w procesie, upływu czasu itp. umożliwiają auto- matyczne wykonywanie akcji, np. wysłanie SMS, poczty elektronicznej o konfigurowal- nej treści. WO.8 Dostęp do wymagających autoryzacji użytkownika funkcjonalności i danych Platformy

musi być możliwy na podstawie jednokrotnego logowania. WO.9 Platforma, przy pomocy integracji z Profilem Zaufanym/jego następcą, musi zapewnić

możliwość ustawienia dodatkowej weryfikacji (poprzez kod przesłany w formie sms) zmian konfiguracyjnych w Platformie.

Opis Przedmiotu Zamówienia strona 44

WO.10 Platforma musi zapewnić zasadę jednokrotnego wprowadzania danych do Platformy.

WO.11 Platforma musi zapewnić mechanizmy kontroli dostępu użytkowników do danych i funkcjonalności. WO.12 Platforma musi zapewnić możliwość generowania wydruków w formie plików

PDF

wraz z sumą kontrolną z danych wprowadzonych i datą dokumentu widoczną na wy- druku. WO.13 Platforma musi mieć wspólny moduł administracyjny dla wszystkich modułów, do któ-

rego dostęp mogą mieć tylko uprawnieni użytkownicy w roli Administratora. WO.14 Platforma musi posiadać czytelne, jednoznaczne komunikaty o błędach w języku pol-

skim naturalnym (tj. bez nomenklatury technicznej, nieczytelnej dla użytkownika) WO.15 Platforma musi posiadać dokumentację użytkownika oraz Administratora w polskiej

wersji językowej WO.16 Platforma musi zapewnić narzędzia umożliwiające publikację treści w trybie

WYSIWYG (metody, które pozwalają uzyskać wynik w publikacji identyczny lub bardzo zbliżony do obrazu na ekranie) WO.17 Platforma musi zapewniać ciągłość sesji użytkowników i umożliwiać ograniczenie jej

trwania. WO.18 Platforma musi zapewniać definiowanie Formularzy elektronicznych w prosty sposób,

przez użytkowników nieposiadających umiejętności programistycznych (konieczne jest dostarczenia EDYTORA BUDOWANIA FORMULARZY W SPOSÓB OBIEKTOWY) WO.19 Platforma powinna

umożliwiać budowanie procesów w prosty sposób (forma wizualna realizacji procesu przedstawiająca poszczególne kroki w procesie w sposób obraz- kowo-opisowy),

przez użytkowników nieposiadających umiejętności programistycz- nych (konieczne jest

dostarczenia EDYTORA BUDOWANIA PROCESÓW) WO.20 Zamawiający musi zapewnić możliwość replikacji danych produkcyjnych do CPD Za- mawiającego danych serwerów produkcyjnych i baz danych w cyklu tygodniowym, w sposób automatyczny.

6.2. Wymagania funkcjonalne

Tabela 5. Wymagania funkcjonalne

Numer Opis wymagania

PORTAL DOSTĘPOWY Interfejs użytkownika WF.01 Dostęp do Platformy będzie możliwy dla Użytkowników zewnętrznych przy wykorzy- staniu wyłącznie sprzętu komputerowego połączonego z siecią internetową, w tym również urządzeń mobilnych opartych na systemach Android i iOS. WF.02 Oferowane rozwiązanie musi zapewniać, że interfejsy użytkownika zostały zaprojek-

towane w zgodzie z powszechnie przyjętymi standardami i szeroko pojętymi dobrymi praktykami w dziedzinie konstruowania intuicyjnego i ergonomicznego interfejsu użytkownika. WF.03 Platforma musi posiadać polskojęzyczny i anglojęzyczny interfejs użytkownika na

poziomie treści wyświetlanych Użytkownikom zewnętrznym. WF.04 Interfejsy użytkownika będą dostosowane do ekranów o rozdzielczości przynajmniej

1024x768, interfejs responsywny dostosowujący treści do ekranu wyświetlanego. WF.05 Oferowane rozwiązanie musi posiadać interfejs użytkownika końcowego poprawnie

interpretowany w szczególności następujących przeglądarkach:

• Microsoft Internet Explorer w wersji 9.0 i wyższych,

• Mozilla Firefox w wersji najnowszej oraz pięciu poprzednich wersjach,

• Google Chrome w wersji najnowszej oraz pięciu poprzednich wersjach,

• Opera w wersji najnowszej oraz trzech poprzednich wersjach,

• Safari w wersji najnowszej oraz trzech poprzednich wersjach. WF.06 Platforma musi zapewniać zgodność ze standardami W3C i WCAG 2.0 (co najmniej

poziom AA). Wymaganie zweryfikowane będzie narzędziem online wskazanym przez Wykonawcę i zaakceptowanym przez Xxxxxxxxxxxxx. WF.07 Należy przekazać 3 propozycje interfejsu do wyboru przez Xxxxxxxxxxxxx. Propozy-

cje mają różnić się między sobą nie tylko szatą graficzną, ale i ergonomią obsługi.

Opis Przedmiotu Zamówienia strona 45

WF.08 Szata graficzna musi być dostosowana do wyglądu strony Mazowieckiego Urzędu Wojewódzkiego, tzn. zgodnie z kolorystyką, stosowanymi symbolami, proporcjami, hierarchią, itp. Przy projektowaniu interfejsu należy uwzględnić także wymagania w zakresie informacji i promocji stanowiące Załącznik do Umowy oraz Strategię Infor- matyzacji autorstwa Ministra Cyfryzacji. Zamawiający musi mieć możliwość łatwej zmiany szaty graficznej Platformy, bez konieczności znajomości języka programowa- nia, w którym zbudowano Platformę.

WF.9 Poszczególne zakładki i widoki powinny posiadać przejrzyste i logiczne menu oraz logiczne przejścia pomiędzy ekranami. WF.10 Portal dostępowy musi zawierć katalog

udostępnionych usług publicznych, który bę-

dzie gromadził i udostępniał opis usług publicznych świadczonych przez Wojewodę Mazowieckiego i jednostki mu podległe dla obywateli, podmiotów gospodarczych oraz organizacji. Przeznaczeniem katalogu jest umożliwienie Użytkownikom ze- wnętrznym znalezienie najbardziej odpowiedniej usługi publicznej w kontekście ich wniosku/problemu/sytuacji/potrzeby. WF.11 Opisy usług w katalogu muszą pozwolić na ich podział na część ogólną i szczegó-

łową. WF.12 Portal dostępowy musi umożliwić każdemu użytkownikowi (bez potrzeby uwierzytel- nienia 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. WF.13 Platforma musi umożliwiać wielokryterialne wyszukiwanie danych. WF.14 Platforma powinna pozwalać na wyszukiwanie treści co najmniej: po nazwie usługi,

po symbolu JRWA, po numerze sprawy, po słowach kluczowych. WF.15 Platforma powinna pozwalać na pobranie dokumentów powiązanych z kartami

usług, np. wniosków do pobrania, wzorów zaświadczeń, bez potrzeby logowania. WF.16 Platforma musi być wyposażona, w konfigurowalne mechanizm uniemożliwiające

wpisanie nieprawidłowych danych, w szczególności, tam gdzie jest to możliwe, Plat- forma musi weryfikować poprawność wprowadzonych danych w danym polu, a także zależności pomiędzy polami. W przypadku wpisania niewłaściwych danych, Platforma musi zaznaczyć te dane i informować użytkownika o błędzie. WF.17 Platforma musi umożliwić uzyskanie przez wnioskodawcę (Użytkownika zewnętrz-

nego) informacji na temat etapu realizacji spraw, które zostały przez niego złożone w urzędzie zarówno drogą elektroniczną jak i tradycyjną (papierową). WF.18 Platforma ma zapewnić mechanizm umożliwiający wyświetlanie zaprojektowanej

przez Wykonawcę informacji o czasowej niedostępności serwisu z powodów tech- nicznych oraz uwzględnienie możliwości zdefiniowania własnej informacji. WF.19 Platforma musi udostępniać formularz zgłoszenia problemu dotyczącego Platformy

(np. imię, nazwisko, xxxx do kontaktu, treść pytania/opis problemu). WF.20 Platforma ma zapewnić automatyczne tworzenie mapy serwisu w zakresie obszaru

dostępnego publicznie MODUŁ KOMUNIKACJI Wirtualny asystent WF.21 Platforma ma zapewnić interfejs zaawansowanej pomocy w postaci wirtualnego asy-

stenta w języku polskim. WF.22 Wirtualny asystent ma zapewniać wsparcie i pomoc w zakresie funkcjonowania Plat-

formy oraz zagadnień merytorycznych związanych z udostępnionymi e-usługami w sekcji dla użytkowników zalogowanych i niezalogowanych. WF.23 Wirtualny asystent powinien zapewnić wsparcie użytkownika w wersji tekstowej i

dźwiękowej z wykorzystaniem mechanizmu syntezy mowy (pod kątem osób niedowi- dzących), przy czym powinno być możliwe włączenia funkcji dźwiękowej za pomocą udostępnionego

przycisku. WF.24 Wirtualny asystent ma być wizualizowany przy pomocy krótkich kilkusekundowych

filmów realnej osoby pokazujących np. zmiany mimiki twarzy, odtwarzanych auto- matycznie przy kolejnych odpowiedziach. WF.25 Postać wirtualnego asystenta powinna odpowiadać wizerunkowi profesjonalnemu, a jej propozycja będzie podlegała akceptacji Zamawiającego w trakcie trwania Umowy na etapie opracowywania Projektu Technicznego rozwiązania. WF.26 Wirtualny asystent powinien posiadać linki kierujące do odpowiednich stron Plat-

formy, zawierających szczegółowe informacje na dany temat. WF.27 Wirtualny asystent powinien posiadać zestaw odpowiedzi awaryjnych, stosowanych w przypadku gdy wypowiedzi użytkownika będą niezrozumiałe (nie daje się dopaso- wać do żadnego wątku w bazie wiedzy).

Opis Przedmiotu Zamówienia strona 46

WF.28 W przypadku niejednoznaczności pytań, wirtualny asystent powinien zgodnie z kon- figuracją bazy wiedzy zadać użytkownikowi pytanie uszczegóławiające. Pytanie po- winno zawierać listę możliwych odpowiedzi w formie linków do wyboru przez użyt- kownika. WF.29 Wirtualny asystent powinien potrafić kontynuować rozmowę na wcześniej określony

temat, np. „co to jest wniosek o pobyt”, „jak go złożyć”, itp. WF.30 Platforma powinna zostać wyposażona w mechanizm powitań rozumiany jako zdefi- niowanie określonego zachowania Wirtualnego Asystenta w momencie rozpoczęcia konwersacji. WF.31 Wykonawca w ramach zamówienia zobowiązany jest do opracowania inicjalnej po-

staci bazy wiedzy rozumianej jako przygotowanie i zaimplementowanie do Platformy co najmniej 200 wątków/scenariuszy rozmów (unikalnych odpowiedzi wirtualnego asystenta w zakresie funkcjonalności Platformy). WF.32 Baza wiedzy powinna zostać tak skonstruowana, aby Platforma potrafiła „dopytać”

o niezbędne informacje w zakresie przewidzianych scenariuszy. WF.33 Platforma powinna dobrze radzić sobie z obsługą literówek, braku polskich znaków

czy błędami ortograficznymi. WF.34 W przypadku gdy w bazie wiedzy zabraknie odpowiedzi na pytanie użytkownika, Wir- tualny asystent powinien zaproponować użytkownikowi rozpoczęcia czatu z Urzędni- kiem. WF.35 Platforma musi potrafić prowadzić jednocześnie rozmowy ze wszystkimi aktywnymi

użytkownikami Platformy. WF.36 Platforma powinna gromadzić w Module Administratora wszystkie parametry roz-

mowy: adresy IP, czas trwania rozmowy, liczbę zadanych pytań, zapis pytań i udzie- lonych odpowiedzi. WF.37 Moduł Administratora powinien umożliwiać zarówno bieżącą kontrolę pracy pro-

gramu poprzez podgląd zapisu rozmów oraz raportowanie, jak i umożliwić wprowa- dzenie korekt do bazy wiedzy (dodawanie, modyfikacja, usuwanie). Tłumacz języka migowego online WF.38 Platforma umożliwi połączenie wideofoniczne z tłumaczem języka migowego online. WF.39 Użytkownik będzie mógł skorzystać z modelu ciągłego dostępu do usługi tłumacza

migowego on-line w godzinach 09:00 – 15:00. WF.40 Usługa języka migowego online umożliwi organizację konferencji trójstronnej pomię-

dzy użytkownikiem – pracownikiem Zamawiającego a tłumaczem języka migowego z wykorzystaniem specjalnej aplikacji dostępnej na stronie internetowej Platformy. WF.41 Usługa tłumacza języka migowego online powinna być dostępna także na wersji mo-

bilnej Platformy. WF.42 W ramach usługi tłumacza języka migowego online dostępne będą następujące me-

tody komunikacji:

• PJM (polski język migowy),

• SJM (system językowo – migowy), Czat z pracownikiem Zamawiającego WF.43 Platforma umożliwi przeprowadzenie rozmowy w czasie rzeczywistym z pracowni-

kiem Zamawiającego (czat). WF.44 Rozmowa czat powinna być wywoływana za pomocą komponentu z oknem do roz-

mowy zaimplementowanym na Platformę dostępowym bez konieczności zalogowa- nia się do Platformy. WF.45 Jeżeli ilość zainteresowanych użytkowników czatem przekracza możliwość obsługi

Urzędników, Platforma powinna umieścić czat w kolejce oczekujących do momentu, gdy odpowiedni Urzędnik będzie wolny i poinformować o tym użytkownika. WF.46 Nadejście nowej rozmowy powinno być sygnalizowane pojawieniem się dodatko-

wego panelu bocznego zawierającego okno z rozmową czat. WF.47 W przypadku próby podjęcia rozmowy poza godzinami pracy Zamawiającego (08:00

– 16:00) Platforma powinna wyświetlić komunikat informujący o godzinach możli- wości przeprowadzenia czatu. Treść komunikatu oraz jego wygląd zostanie uzgod- niony z Wykonawcą na etapie opracowania Projektu Technicznego. WF.48 W module Administratora Platforma powinna umożliwiać podgląd historii rozmów

pod kątem daty i nazwy Użytkownika wewnętrznego przeprowadzającego rozmowę. Użytkownik wewnętrzny zalogowany do Platformy także powinien mieć podgląd hi- storii swoich rozmów.

Rezerwacja wizyty WF.49 Platforma umożliwi zarezerwowanie wizyty w urzędzie zarówno przez Użytkownika

zewnętrznego jak i wewnętrznego.

Opis Przedmiotu Zamówienia strona 47

WF.50 Mechanizm rezerwacji zapewni możliwość synchronizacji z kalendarzem pracowni- ków w systemie pocztowym Zamawiającego. WF.51 Platforma uniemożliwi dokonanie rezerwacji w

danym terminie, jeśli w kalendarzu ten termin jest zajęty. W takiej sytuacji, Platforma powinien

zaproponować najbliż- szy wolny termin. WF.52 Platforma umożliwi definiowanie poprzez administratora wirtualnych kolejek do:

• Instytucji,

• Wydziału/Biura/Oddziału,

• Załatwienia wybranego rodzaju sprawy. WF.53 Platforma powinna zostać zintegrowana z systemami kolejkowymi spraw obsługiwa-

nych na bieżąco, gdzie tworzą się kolejki interesantów w lokalizacjach Zamawiają- cego, w których tego rodzaju systemy funkcjonują. WF.54 Platforma musi posiadać moduł statystyczny zawierający informację o ilości i ro-

dzaju zaplanowanych, odbytych wizytach łącznie. WF.55 Wymagana jest integracja z funkcją powiadomień mail i SMS w celu przekazywania

informacji związanych z rezerwacją wizyt. WF.56 Platforma ma umożliwiać konfigurację i parametryzację kalendarza wizyt przez

uprawnionych Użytkowników wewnętrznych lub Administratorów, w tym: możliwość definiowania rodzaju kolejki, godzin przyjęć interesantów, czasu trwania wizyty, oznaczenie kolorem godzin przyjęć interesantów, terminów wolnych i zajętych. WF.57 Platforma musi umożliwiać

scentralizowane zarządzanie wszystkimi lokalizacjami jednostek Zamawiającego. - Wymagania w zakresie obsługi rezerwacji wizyt bez systemu kolejkowego:

WF.58 Platforma musi umożliwiać prezentację dla użytkowników kalendarzy zajętości ter- minów

wizyt ze wskazaniem godzin przyjęć interesantów, terminów wolnych i zaję- tych. WF.59 Platforma musi umożliwić wprowadzenie mechanizmu rezerwacji terminu wizyty, po-

danie celu wizyty lub rodzaju sprawy. WF.60 Platforma musi umożliwić prezentację uprawnionym Użytkownikom wewnętrznym

kalendarza zarezerwowanych wizyt z informacją kto, kiedy, w jakim celu zarezerwo- wał wizytę. WF.61 Platforma musi umożliwiać odwołanie wizyty lub zmiany jej terminu zarówno przez Użytkownika wewnętrznego i Użytkownika zewnętrznego poprzez konto na Platfor- mie. WF.62 Wysłanie powiadomień o rezerwacji, zmianie, odwołaniu wizyty poprzez przekazanie

informacji z wykorzystaniem funkcji powiadomień (mail, SMS). - Wymagania w zakresie obsługi wizyty w lokalizacjach z systemem kolejkowym: WF.63 Platforma musi umożliwiać definiowanie kolejek do obsługi różnych spraw w zależ-

ności od organizacji pracy jednostki Zamawiającego. WF.64 Platforma musi przekazywać informacje o rezerwacji terminu wizyty do systemu ko-

lejkowego. WF.65 Platforma musi umożliwiać rezygnację z zaplanowanej wizyty. WF.66 Platforma powinna wysyłać powiadomienie o rezerwacji wizyty lub zmianach związa-

nych z wizytą poprzez przekazanie informacji do modułu powiadomień mail i SMS. WF.67 Platforma powinna przesyłać powiadomienie SMS w dniu wizyty (o zdefiniowanym

wyprzedzeniu przed terminem). WF.68 Platforma powinna wysyłać powiadomienie SMS w dniu wizyty o lokalizacji i dokład-

nym miejscu wizyty, z uwzględnieniem np. wejścia i nr pokoju. WF.69 Platforma powinna umożliwić integrację z systemem poczty Zamawiającego w

szczególności MS Exchange, Google, Xxxxxxx.xxx, Apple, Caldav/iCal.*

(*Wszystkie nazwy użyte w dokumencie mają cel informacyjny)

Powiadomienia (SMS, e-mail) WF.70 Platforma musi umożliwiać informowanie użytkowników o sprawach ich dotyczących

za pomocą: (1) przesłania korespondencji na skrytkę ePUAP, (2) e-mail, (3) SMS (4) konto na Platformie. WF.71 Platforma musi umożliwiać konfigurowanie i wysłanie automatycznych powiadomień

SMS, e-mail. WF.72 Platforma zapewni możliwość przypominania o terminach wyznaczonych w syste- mie, np. o zarezerwowanej wizycie w urzędzie.

Opis Przedmiotu Zamówienia strona 48

WF.73 Platforma musi umożliwiać definiowanie odbiorców informacji na podstawie wska-

zanych dowolnych kryteriów - wysłania jednego/zbiorczego powiadomienia o odwo- łaniu wizyt do wszystkich osób, umówione w tym dniu, np. w przypadku awarii zasi- lania w siedzibie Zamawiającego lub innej nietypowej sytuacji.. WF.74 Platforma powinna składać się z dwóch zasadniczych części: bazy danych zawiera-

jącej i przechowującej informacje o użytkownikach, którzy posiadają Profil Zau- fany/jego następcę oraz zaawansowanego moduł komunikacji. WF.75 Dane przechowywane w bazie muszą być szyfrowane. WF.76 Platforma powinna w sposób w pełni zautomatyzowany pobierać wszystkie dane

osoby zgłaszającej się przy wykorzystaniu Formularza elektronicznego e-usługi opu- blikowanej na ePUAP (dotyczy formularzy budowanych do opublikowania w CRD). WF.77 Platforma powinna

w sposób w pełni zautomatyzowany pobierać z Profilu Xxxxx- nego/jego następcy wszystkie dane osoby zgłaszającej się przy wykorzystaniu For- mularza elektronicznego e-usługi opublikowanej na Platformie (dotyczy formularzy budowanych do

opublikowania na Platformie). WF.78 Formularz elektroniczny zamieszczony do wypełnienia za pomocą Platformy powi- nien zawierać zgodę na komunikację elektroniczną z obywatelem.

WF.79 W ramach Platformy będą wysyłane powiadomienia dotyczące określonych etapów obsługi złożonych wniosków. Platforma powinna umożliwiać definiowanie co naj- mniej następujących parametrów dla danego typu komunikatu:

• Tytuł,

• Podpis,

• Typ operacji, dla którego ma zostać wysłany komunikat zgodnie ze słowni- kiem,

• Treść opisowa,

• Data rozpoczęcia i zakończenia wysyłania,

• Załącznik wraz z parametrami jego wielkości i formatu pliku,

• Parametrów wysyłania. WF.80 Zarządzanie powiadomieniami, w tym ich podstawową konfiguracją, zarządzaniem

kontami i danymi użytkowników powinno odbywać z poziomu modułu Administra- tora.

Serwisy internetowe WF.81 Platforma zapewni dostęp do serwisów internetowych jednostek uczestniczących w

Projekcie. WF.82 Platforma umożliwi przejście do Biuletynu Informacji Publicznej Zamawiającego oraz jednostek podległych wojewodzie mazowieckiemu za pomocą kliknięcia w od- powiedni baner/link.

MODUŁ USŁUGOWY Wsparcie procesów biznesowych WF.83 Platforma zapewni mechanizm autoryzacji użytkownika z opcją powiązania z Profi-

xxx Xxxxxxxx/jego następcą. WF.84 Platforma ma umożliwiać realizację zdefiniowanych e-usług za pomocą wytworzo-

nych przez Wykonawcę Formularzy elektronicznych. WF.85 Platforma zapewni aktywną kontrolę poprawności danych, pobieranie danych z in-

nych systemów, przekazywanie do workflow systemu zarządzania dokumentami EZD przy pomocy API EZD. WF.86 Wysłanie formularza za pomocą Platformy powoduje przekierowanie wysyłki na

skrytkę ePUAP Zamawiającego. WF.87 Platforma musi umożliwiać monitorowanie przebiegu sprawy dla każdego użytkow-

nika zaangażowanego w proces, zgodnie z jego uprawnieniami. WF.88 Przepływ zadań ma być sterowany przez wizualnie konfigurowany proces obiegu

spraw (silnik procesowy) i może być inny dla każdego typu zadania i rodzaju sprawy globalnie i na poziomie każdej jednostki. WF.89 Platforma musi umożliwiać wprowadzanie zmian w zestawach danych opisowych i słownikowych dla rejestrów i kartotek, z zachowaniem historii zmian i nienaruszal- ności powiazań i dokumentów historycznych. WF.90 Platforma ma umożliwiać przeszukiwanie treści kart usług. WF.91 Platforma ma umożliwiać przeszukiwanie kart usług według struktury organizacyjnej

jednostek/urzędu WF.92 Platforma ma umożliwiać podział kart usług według JRWA właściwego dla Mazo-

wieckiego Urzędu Wojewódzkiego i jednostek podległych wojewodzie.

Opis Przedmiotu Zamówienia strona 49

WF.93 Platforma ma umożliwiać wyszukiwanie treści po opisie sprawy, po symbolu JRWA, po nazwie sprawy. WF.94 Platforma ma pozwalać na pobieranie bez konieczności logowania

dokumentów po-

wiązanych z kartami usług, np. wniosków do pobrania, wzorów formularzy. WF.95 Platforma ma umożliwiać udostępnienie informacji o prowadzonej sprawie w zakre-

sie: metryki sprawy zawierającej informacje: znak sprawy, statusu sprawy, tytuł sprawy, datę podjętej czynności, oznaczenie osoby podejmującej daną czynność, określenie podejmowanej czynności, identyfikator dokumentu w aktach sprawy, do którego odnosi się dana czynność.

WF.96 Platforma będzie zintegrowana z Profilem Zaufanym/jego następcą w zakresie ob- sługi Profilu Zaufanego/jego następcy. WF.97 Platforma musi umożliwiać definiowanie

wymagalności stosowania podpisu/profilu

dla każdego Formularza elektronicznego. WF.98 Platforma musi pozwalać na zasilanie Formularza elektronicznego danymi adreso-

wymi z konta klienta. WF.99 Platforma musi pozwalać na wypełnienie Formularza elektronicznego i zapisanie go

do kopii roboczych (formularz roboczy). WF.100 Platforma musi pozwalać na przypisanie Formularza roboczego do folderu robo-

czego. WF.101 Platforma ma umożliwiać usunięcie Formularza roboczego. WF.102 Platforma musi umożliwiać wygenerowanie pliku PDF z zapisanego Formularza elek-

tronicznego. WF.103 Platforma powinna pozwalać na podpisanie wypełnionego Formularza elektronicz- nego Profilem Zaufanym/podpisem kwalifikowanym/ich następcą, przez kilka osób. WF.104 Platforma ma

umożliwiać generowanie UPO zgodnie z ustawą z dnia 17 lutego

2005 r. o informatyzacji podmiotów realizujących zadania publiczne. WF.105 Platforma musi umożliwiać zarządzanie Formularzami elektronicznymi, w tym doda-

wanie, usuwanie, dodawanie kolejnych wersji, aktywowanie/dezaktywowanie, defi- niowanie kwoty opłaty w powiązaniu z systemem płatności elektronicznych. WF.106 Układ graficzny wszystkich Formularzy elektronicznych musi być jednolity. WF.107 Platforma musi zapewnić

usługi walidacji pól Formularzy elektronicznych, wskazy- wania pól obowiązkowych do wypełnienia przez Użytkownika zewnętrznego. WF.108 Platforma

musi zapewniać walidację typu danych oraz zakresu i spójności danych

podczas wprowadzania danych przez użytkownika w Formularzach elektronicznych. WF.109 Platforma musi umożliwiać dodawanie kart oraz opisów usług zgodnych ze standar-

dem ePUAP. WF.110 Platforma musi pozwalać na załączanie Formularzy elektronicznych w formacie zgodnym z Załącznikiem nr 2 Dz.U.2016 poz.113. WF.111 Platforma powinna umożliwić

łączenie karty i opisu usługi Formularzy elektronicz-

nych ePUAP z przekierowaniem do ePUAP. WF.112 Platforma musi zapewnić zgodność ze standardem ESP udostępnionym na ePUAP. WF.113 Platforma musi wykorzystywać mechanizmy uwierzytelnienia udostępnione przez

Profil Xxxxxxx/jego następcę. WF.114 Platforma powinien wyświetlać w formie kolejnych kroków poziom uzupełniania For-

mularzy elektronicznych /wypełniania wniosków i obsługi wniosku. Wraz z uzupeł- nieniem poszczególnych czynności przez użytkownika diagram w formie kolejnych kroków procesu składania wniosków powinien być automatycznie aktualizowany przez Platformę. Proces ten można na każdym kroku przerwać a później wznowić (od momentu przerwania) WF.115 Platforma musi umożliwiać Użytkownikom wewnętrznym kontakt z Użytkownikiem zewnętrznym celem wezwania go do uzupełnienia dokumentów niezbędnych do za- łatwienia sprawy. WF.116 Platforma musi umożliwiać Użytkownikom zewnętrznym wgląd w wysyłane i otrzymy-

wane dokumenty. Komunikacja z systemem EZD WF.117 Platforma musi zapewniać współpracę z wykorzystywanym u Zamawiającego syste-

mem Elektronicznego Zarządzania Dokumentacją (EZD) w zakresie przekazywania dokumentów elektronicznych oraz przekazywania do Interesanta wydanych decy- zji/odpowiedzi. WF.118 Platforma musi udostępniać możliwość przesyłania informacji zwrotnej dotyczącej danej sprawy w postaci publikacji statusu sprawy automatycznie generowanego w systemie EZD na każdym etapie procesu rozpatrywanej sprawy.

Opis Przedmiotu Zamówienia strona 50

WF.119 Platforma musi umożliwiać dostęp Użytkownikom zewnętrznym do informacji na te-

mat statusu każdej realizowanej przez niego na Platformie sprawy urzędowej na każdym etapie jej procesowania w EZD. Obsługa płatności za usługi WF.120 Platforma musi umożliwiać obsługę płatności za wybrane e-usługi z wykorzystaniem

płatności elektronicznych. WF.121 Platforma musi obsługiwać płatności online wraz z pełną obsługą informacyjną dla

użytkownika realizowaną poprzez email. WF.122 Użytkownik zewnętrzny po zalogowaniu się na własne konto w Platformie i uzyska- niu dostępu do danych musi posiadać informacje o zobowiązaniach i płatnościach przypisanych do jego konta oraz informacje o stanie realizowanych płatnościach.

WF.123 Platforma musi zapewnić możliwość wymiany informacji o dokonanych wpłatach z systemami dziedzinowymi, przy zobowiązaniach muszą znajdować się pełne i aktu- alne informacje dotyczące płatności bez względu na ty, z jakiej formy zapłaty skorzy- stał użytkownik.

WF.124 Tytuły opłaty muszą posiadać przypisane automatycznie ID operacji dla pojedynczej wpłaty/koszyka płatności pozwalające na prawidłową weryfikację płatności oraz umożliwiające

rozksięgowanie zobowiązań. WF.125 Dane do realizacji przelewu przy płatnościach internetowych

muszą być wypełniane

automatycznie bez możliwości ich edycji na etapie wykonywania płatności. WF.126 Operator płatności online powinien spełniać poniższe warunki:

• Umożliwić realizację płatności z wykorzystaniem: przelewów Pay-by-link, płatności automatyczne BLIK, karty płatnicze (VISA, MasterCard), szybkie przelewy dla banków nieposiadających płatności PBL;

• Min. 10 banków, z którymi posiadana jest umowa na obsługę przelewów elektronicznych,

• Minimalna wysokość opłaty za przelew z preferencyjną stawką dla admini- stracji publicznej,

• W przypadku niedostępności usługi, przywrócenie pełnej dostępności na- stąpi zgodnie z założeniami realizacji Błędu Kategorii A.

• Dostępność wsparcia serwisowego dla płacących oraz pracowników jedno- stek uczestniczących w Projekcie. WF.127 System płatności on-line powinien umożliwiać płatności poprzez funkcję

płatności

ePUAP.

MODUŁ OPEN DATA Zakres i udostępnianie danych WF.128 Dane umieszczone w Platformie będą miały przypisane przynajmniej poniższe atry-

buty: • Źródło,

• Kategoria,

• Częstotliwość aktualizacji,

• Ostatnia Modyfikacja,

• Utworzono,

• Liczba wyświetleń,

• Liczba pobrań,

• Typ API,

• Stopień otwartości danych według pięciogwiazdkowej skali Star Open Data. WF.129 Dane umieszczane na Platformie muszą mieć możliwość przypisania do nich słów

kluczowych. WF.130 Dane przetwarzane na Platformie będą objęte mechanizmem automatycznej archi- wizacji. Platforma będzie przechowywała historię danych. Ma to na celu zapewnie- nie dostępu

do wszystkich poprzednich wersji danych. WF.131 Moduł zostanie zbudowany na platformie przystosowanej do realizacji projektów

związanych z udostępnianiem Otwartych danych (DKAN lub porównywalnej), wypo- sażonej w takie funkcjonalności jak:

• Wbudowane API,

• Kompatybilność z xxxx.xxx,

• Podgląd danych,

• Generowanie wykresów, zestawień,

• Historię danych,

• Własny CMS.

Opis Przedmiotu Zamówienia strona 51

WF.132 Implementacja modułu Open Data w ramach Platformy zostanie przeprowadzona w sposób, który zapewni kompatybilność Platformy z krajową platformą danych otwar- tych xxxxx://xxxxxxxxxxxxx.xxx.xx, w szczególności w zakresie określonych ram ka- tegorii danych i atrybutów danych WF.133 Działania administracyjne będą możliwe do prowadzenia z wykorzystaniem Modułu

Administratora. WF.134 Działania redakcyjne będą możliwe do prowadzenia po nadaniu uprawnienia przez

Administratora. WF.135 Elementem Platformy będzie repozytorium plików oczekujących na publikację na

Platformie. Dostęp do repozytorium będzie możliwy dla Użytkowników wewnętrz- nych, którzy będą posiadać odpowiednie konto dostępu upoważniające do umiesz- czenia w repozytorium pliku z danymi. Pliki zamieszczane w repozytorium będą pu- blikowane na Platformie dopiero po ich akceptacji przez uprawnioną do tego osobę. Wyszukiwanie danych WF.136 Platforma musi zapewniać wielokryteriowe mechanizmy kontekstowego wyszukiwa- nia dostępne bez konieczności uwierzytelnienia w zakresie danych, które nie wyma- gają uwierzytelnienia. WF.137 Platforma musi zapewniać wielokryteriowe mechanizmy kontekstowego wyszukiwa-

nia dostępne za pośrednictwem interfejsu użytkownika na Platformie. WF.138 Platforma musi pozwalać na sortowanie listy danych według atrybutów, które je opi-

sują. WF.139 Platforma musi pozwalać na wyszukiwanie obiektów z repozytorium danych, w któ-

rych te obiekty się znajdują oraz musi pozwalać na swobodne przeglądanie danych. Swobodne przeglądanie danych powinno pozwalać x.xx. na zmianę kontekstu pre- zentowanych danych na inne prezentowane obiekty powiązane. Prezentacja danych WF.140 Platforma musi umożliwiać udostępnienie danych publicznych zarówno w postaci zestawień statystycznych (raportów) generowanych na żądanie jak również zauto- matyzowanego dostępu do danych źródłowych przygotowanych do ponownego wy- korzystania. WF.141 Platforma musi zapewnić możliwość prezentacji danych w formie tabelarycznej, z

możliwością ukrywania poszczególnych tabel, konfigurowania przez użytkownika przeglądającego dane sposobu sortowania i wyświetlania. WF.142 Platforma będzie udostępniała narzędzia do prezentacji danych w postaci tabel, wy-

kresów, map, obrazów bez konieczności ich pobierania. WF.143 Platforma musi posiadać funkcjonalność tworzenia zestawień ad-hoc pozwalających

na filtrowanie, grupowanie, sortowanie danych według różnych dostępnych kryte- riów. WF.144 Platforma musi umożliwiać odświeżanie raportów z wygenerowanych danych. WF.145 Platforma powinna umożliwiać eksportowanie danych do plików w szczególności

xml, csv, pdf, formatów pakietów biurowych takich jak MS Office, OpenOffice.

MODUŁ ADMINISTRATORA Wymagania ogólne WF.146 Platforma musi posiadać narzędzie do budowy ról i uprawnień dostępne dla Admini- stratora. Muszą być możliwe do utworzenia odrębne role dla różnych typów użytkow- ników Platformy zgodnie z przydzielonymi im kompetencjami. WF.147 Platforma musi zapisać i udostępniać historię wszystkich logowań, w tym nieuda-

nych. WF.148 Platforma musi umożliwiać generowanie na żądanie oraz w trybie automatycznym statystyk, w zakresie co najmniej: ilości założonych kont, ilości złożonych wniosków w postaci plików, ilości złożonych wniosków w postaci Formularzy elektronicznych, statystyk odwiedzin, popularności e-usług. WF.149 Platforma będzie umożliwiała dodawanie/edytowanie/usuwanie danych słowniko-

wych. WF.150 Platforma będzie umożliwiała definiowanie alertów, które w zależności od wartości określonych pól w zapisanym rekordzie umożliwiają automatyczne wykonywanie ak- cji, np.

wysłanie poczty elektronicznej o konfigurowalnej treści (zawierającej określe- nia będące wartościami pól). WF.151 Platforma musi umożliwić umieszczanie danych na Platformie i zarządzanie nimi. WF.152 Platforma musi zawierać mechanizmy wspierające proces przygotowania danych i

publikacji treści w Platformie. WF.153 Platforma musi umożliwiać hierarchiczne zarządzanie treścią.

Działanie na elemen-

cie nadrzędnym może opcjonalnie spowodować modyfikację elementu podrzędnego (np. po wyborze stosownej opcji).

Opis Przedmiotu Zamówienia strona 52

WF.154 Platforma musi udostępniać Administratorowi funkcjonalność zarządzana katalo-

giem w zakresie co najmniej ręcznego wprowadzania i konfigurowania usług, w tym zmiany nazw, opisów, załączników, jak również aktywowanie i usuwanie wybranych usług. WF.155 Platforma powinna umożliwiać wstawianie banerów o różnych rozmiarach i forma- tach w miejscach dostosowanych do graficznej kompozycji strony. Wymagane jest wsparcie dla formatów: GIF, TIFF, SVG oraz JPG i PNG. WF.156 Zasoby takie jak baza materiałów, grafiki, zdjęcia, animacje muszą być ujednolicone

(standaryzacja opisów, powiązanie z innymi materiałami, możliwość dodawania słów kluczowych i wiązania we wspólne grupy tematyczne). WF.157 Każda czynność wykonywana w Platformie musi być zapisywana, tak aby możliwa

była identyfikacja osoby wykonującej czynność, obiektów, których dotyczyła czyn- ność oraz czasu wykonania czynności. WF.158 Platforma powinna posiadać wbudowaną funkcjonalność prowadzenia statystyk za-

wierającą co najmniej możliwość wygenerowania raportów dotyczących:

1. Statystyki wejść odwiedzin (dzień, miesiąc, geolokalizacje, informację o ‘nowy’ lub ‘powracający’ użytkownik), 2. Czasu spędzonego na stronie głównej i podstronach, 3.

Przeglądania treści, pobrania plików, 4. Statystyk wewnętrznych dotyczących aktywności

Administratorów. WF. 158 Platforma, w zakresie bezpieczeństwa dostępu musi zapewnić możliwość konfigura-

cji źródła dostępu do Platformy użytkowników z uprawnieniami Administratora, po- przez definiowanie dopuszczalnych adresów IP i/lub podsieci. Funkcje specjalistyczne związane z modułem Open Data WF.160 Platforma musi umożliwić tworzenie kategorii danych i zarządzanie nimi w module

Open Data. WF.161 Podczas dodawania nowego zbioru danych Platforma ma mieć możliwość określe- nia sposobu ich udostępnienia (konieczność wskazania co najmniej jednego, możli- wość wyboru kilku wariantów w ramach jednej kategorii udostępniania, np. pliki do pobrania w kilku formatach) oraz określenia dla niego metadanych. WF.162 Platforma musi umożliwiać publikowanie danych

oraz artykułów. WF.163 Platforma musi umożliwić opisywanie danych za pomocą atrybutów zdefiniowanych

przez Zamawiającego. WF.164 Platforma powinna umożliwiać konfigurowanie sposobu prezentacji danych. WF.165 Platforma powinna umożliwić zarządzanie treścią. WF.166 Platforma powinna umożliwiać publikowanie informacji i komunikatów. WF.167 Platforma musi umożliwiać konfigurowanie mechanizmów automatycznej aktualiza-

cji danych. WF.168 Platforma ma umożliwiać budowanie ról i nadawanie uprawnień. WF.169 Platforma będzie posiadała zaawansowane narzędzia do importu danych w wielu

formatach. WF.170 Platforma będzie umożliwiała wygenerowanie przynajmniej następujących raportów zawierających dane za wskazany dzień lub za przedział

czasu:

• Liczbę pobrań danych – łącznie, dla zbioru, dla dokumentu,

• Liczbę odtworzeń danych – łącznie, dla zbioru, dla dokumentu,

• Liczbę wejść na stronę z danymi – łącznie, dla zbioru.

6.3. Wymagania w zakresie przepisów prawa

Tabela 6. Wymagania zgodności z następującym aktami prawnymi w aktualnie ob- owiązujących wersjach lub aktami je zastępującymi

Numer Opis wymagania

PRZEPISY PRAWA PP.01 Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizują-

cych zadania publiczne (Dz. U. z 2013 r. poz. 235, z późn. zm.). PP.02 Ustawa z dnia 29 sierpnia 1997 roku o ochronie danych osobowych (tekst jednolity:

Dz.U. 2016 poz. 922).

Opis Przedmiotu Zamówienia strona 53

PP.03 Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. Nr 128, poz. 1402, z późn. zm.). PP.04 Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz. U. z 2014

r. poz. 782). PP.05 Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów telein- formatycznych (Dz.U. 2012 poz. 526). PP.06 Rozporządzenie Ministra Finansów z dnia 24 grudnia 2012 r. w sprawie sposobu

przesyłania deklaracji i podań oraz rodzajów podpisu elektronicznego, którymi po- winny być opatrzone (tekst jednolity: Dz.U. 2015 poz. 2362 ). PP.07 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 paździer-

nika 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elek- tronicznymi (Dz.U. 2006 nr 206 poz. 1518). PP.08 Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie spo-

rządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektro- nicznych (tekst jednolity: Dz.U. 2015 poz. 971). PP.09 Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, za-

kresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. 2005 nr 205 poz. 1692). PP.10 Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005

r. w

sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i wery- fikacji tego badania (Dz.U. 2005 nr 217 poz. 1836). PP.11 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 paździer-

nika 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicz- nych (Dz.U. 2006 nr 206 poz. 1517). PP.12 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/680 z dnia 27 kwietnia

2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych oso- bowych przez właściwe organy do celów zapobiegania przestępczości, prowadzenia postępowań przygotowawczych, wykrywania i ścigania czynów zabronionych i wyko- nywania kar, w sprawie swobodnego przepływu takich danych oraz uchylająca decy- zję ramową Rady 2008/977/WSiSW i Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochro- nie danych) (Dz.U.UE L z dnia 4 maja 2016 r.) –

RODO. 6.4. Wymagania w zakresie bezpieczeństwa przetwarzania danych

Tabela 7. Wymagania w zakresie bezpieczeństwa przetwarzania danych

Numer Opis wymagania BEZPIECZEŃSTWO PRZETWARZANIA DANYCH BZ.1 Wszystkie rozwiązania aplikacyjne powinny spełniać wymogi w zakresie bezpieczeństwa

przetwarzania danych zgodnie z normą ISO 27001 oraz wytyczne bezpieczeństwa wyni- kające z Dyrektywy RODO. BZ.2 Wszystkie wytworzone e-usługi będą zapewniały bezpieczeństwo przetwarzania i prze-

chowywania danych zgodnie z zasadami przetwarzania informacji wskazanymi w obowią- zujących przepisach BZ.3 Przesyłanie danych w sieci publicznej odbywać się będzie bezpiecznymi

kanałami, które

będą szyfrowane i chronione przed nieuprawnionym odczytem. Dane przechowywane na Platformie i wszystkich jego modułach muszą być szyfrowane. Szyfrowane muszą być również wszelkie kopie zapasowe Platformy. BZ.4 Wszystkie dane, które będą udostępnione na Platformie będą chronione przed nieupraw-

nionym odczytem poprzez mechanizmy logowania z wykorzystaniem unikalnego identyfi- katora oraz hasła (w przypadku Administratorów) lub poprzez mechanizmy Profilu Xxxxx- nego/jego następcy. BZ.5 Dostęp dla nieuwierzytelnionego użytkownika będzie możliwy jedynie do danych, które

będą ogólnie dostępne i umieszczone na Platformie.

Opis Przedmiotu Zamówienia strona 54

BZ.6 Platforma zapewni mechanizm weryfikujący maksymalny okres ważności hasła – usta-

lony zostanie maksymalny limit dni, podczas których hasło będzie przyjmowane. Po upły- wie tego czasu wymagana będzie zmiana hasła. BZ.7 Platforma zapewni minimalny wymagany poziom złożoności hasła – ustalona zostanie

minimalna liczba znaków oraz wymagania kombinacja cyfr i znaków specjalnych, małych i dużych liter. BZ.8 Platforma zapewni automatyczne rozłączenie sesji (wylogowanie) aplikacji po zadanym czasie nieaktywności użytkownika. W wypadku automatycznego rozłączenia sesji ele- menty modyfikowane przez użytkowników powinny zostać zapisane w postaci wersji ro- boczych tak, aby nie utracili wykonywanych modyfikacji. BZ.9 Wszystkie operacje pobierania danych wykonywane przez niezalogowanego użytkownika

muszą być zabezpieczone przy użyciu funkcji CAPTCHA. BZ.10 Platforma musi zapewniać przesyłanie zaszyfrowanych danych pomiędzy serwerem, a

stacją kliencką. BZ.11 Platforma zawierająca e-usługi musi zapewniać uwierzytelnianie użytkowników przy po-

mocy Profilu Zaufanego/jego następcy BZ.12 Platforma musi posiadać zabezpieczenia w szczególności przed:

• Atakami typu:

o DoS (Denial of Service), o XSS (Cross Site Scripting), o Directory traversal, o Buffer overrun. o Cross-Site Request Forgery, o MITM (Man in the Middle), o Broken Authentication and Session Management, o Authorization Bypass (próby dostępu do zasobów bez uwierzytelnienia

użytkownika), o Code Execution (próby wykonania wrogiego kodu na serwerze),

• Atakami semantycznymi na adres URL,

• Atakami związanymi z ładowaniem plików,

• Information Leakage (próby detekcji wycieku istotnych informacji – technicz- nych i biznesowych),

• Insecure Communications (dostęp do istotnych danych w wyniku braku lub nie- odpowiedniego poziomu szyfrowania),

• Source Disclosure (próby prowadzące do ujawnienia kodów źródłowych wyko- rzystanego oprogramowania),

• File Inclusion (załączanie plików lub do ich zawartości złośliwej zawartości),

• Open Redirection (próby nieautoryzowanego przekierowania),

• Fałszowanie żądania http,

• Response Splitting (brak prawidłowej walidacji nagłówków http)

• Ujawnienie danych przechowywanych w bazie,

• Wstrzykiwanie kodu wykonywalnego innych języków programowania (Code in- jection i SQL injection) BZ.13 Możliwość audytowania wszystkich prób dostania się do Platformy w logach: opis zdarze-

nia (próby udane i nieudane), nazwa użytkownika, nazwa hosta, data zdarzenia. BZ.14 Platforma musi uniemożliwiać zalogowanie się na dwóch oddzielnych instancjach tego

samego użytkownika. BZ.15 Platforma musi umożliwiać identyfikację użytkownika i czasu wykonania każdej zmiany w

bazie (wstawienie, aktualizacja, kasowanie, aktywacja, dezaktywacja). BZ.16 Platforma musi umożliwiać tworzenie kopii bezpieczeństwa na żądanie. BZ.17 Logowanie dla Administratorów i Użytkowników wewnętrznych Platformy powinno być re- alizowane przez mechanizm dwuskładnikowego uwierzytelniania oraz wyłącznie z wyzna- czonych adresów IP BZ.18 Platforma musi umożliwiać monitorowanie i rejestrować stany niesprawności systemu i

ich przyczyn w logach: data zdarzenia, identyfikator błędu, opis błędu itp. BZ.19 Platforma musi posiadać mechanizmy umożliwiające szybkie przywrócenie stanu normal-

nej pracy Platformy po awarii. BZ.20 Wykonawca zobowiązany jest do przygotowania procedur naprawczych na wypadek wy-

stąpienia awarii poszczególnych elementów Platformy i umożliwiających przywrócenie stanu z chwili tuż przed awarią w porozumieniu z Zamawiającym.

Opis Przedmiotu Zamówienia strona 55

6.5. Wymagania w zakresie integracji

Tabela 8. Wymagania w zakresie integracji

Numer Opis wymagania

INTEGRACJA WI.1 Komunikacja pomiędzy poszczególnymi Komponentami architektury musi opierać się o

szynę usług (ESB). WI.2 Architektura powinna zapewniać transparentność lokalizacji usług, uniezależniająca kon-

sumenta usług od ich lokalizacji realizowana np. poprzez rejestr usług i możliwość roz- praszania usług (wiele instancji tej samej usługi). WI.3 Architektura musi posiadać możliwość budowy środowiska: developerskiego, testowego,

szkoleniowego i produkcyjnego. WI.4 Platforma będzie skalowalna; obciążenie Platformy będzie podlegało monitorowaniu. WI.5 Platforma musi posiadać ustandaryzowane interfejsy, obejmujące udostępnianie usług

integracyjnych (x.xx. wymiany danych) Platformy, systemom zewnętrznym poprzez usługi Web Services (w oparciu o standardy SOAP 1.2, WSDL co najmniej 1.1). WI.6 Platforma musi zapewniać możliwość komunikacji z wykorzystaniem plików XML zlokali-

zowanych w strukturach plikowych jednostki, zgodność ze standardami XML 1.0 i XSD 1.1. WI.7 Platforma musi zapewniać usługi JMS (Java Message Service). WI.8 Platforma musi umożliwiać Administratorom tworzenie nowych oraz zarządzanie udo-

stępnianymi usługami i interfejsami poprzez przyjazny w obsłudze interfejs. WI.9 Platforma musi umożliwiać wdrożenie nowych interfejsów poprzez import konfiguracji,

określającej standardy komunikacji z danym systemem, oraz serię kroków wykonywa- nych poprzez interfejs graficzny. WI.10 Platforma musi dla danych pozyskiwanych z systemu zewnętrznego, umożliwiać Admini-

stratorowi skonfigurowanie transformat oraz automatycznego przesyłania uzyskanych danych jako jednego lub wielu dokumentów do użytkownika lub użytkowników. WI.11 Platforma musi zapewniać mechanizm kontroli dostępu do usług pozwalający na dostęp do danej usługi ze względu na użytkownika oraz/lub grupę (jednostkę organizacyjną), do której należy. WI.12 Platforma musi umożliwiać rejestrację wszystkich czynności dostępu do usług i zasobów

w systemie, w zakresie dostępu zarówno przez użytkowników jak i wszelkie aplikacje współpracujące. WI.13 Platforma musi umożliwiać integrację z systemem EZD poprzez API EZD, WI.14 Pełna specyfikacja API EZD zostanie przekazana Wykonawcy po rozstrzygnięciu postępo-

wania przetargowego, po podpisaniu stosownych umów. 6.6. Wymagania w zakresie zasilenia Plat-

formy danymi

1. Wykonawca zaplanuje, zorganizuje i przeprowadzi czynności polegające na zasileniu Platformy danymi w zakresie wskazanym przez Zamawiającego i uzgodnionym na etapie opracowywania Projektu Technicznego.

2. Zasilenie Platformy danymi będzie dokonane w zakresie modułu Open Data.

3. Zamawiający przewiduje, iż dane zostaną zasilone za pomocą wypełnionych przez Zamawiającego arkuszy migracyjnych, natomiast część danych zosta- nie wprowadzona ręcznie przez przedstawicieli Zamawiającego do Plat- formy.

Opis Przedmiotu Zamówienia strona 56

4. Wymagane jest, aby na etapie tworzenia Projektu Technicznego Wykonawca opracował plan zasilenia danymi Platformy, zawierający uzgodnienia doty- czące szczegółowego zakresu i sposobu wprowadzenia danych oraz obowią- zujący harmonogram migracji.

5. Wymagane jest zasilenie Platformy danymi umożliwiającymi wygenerowanie co najmniej po jednym raporcie w danej kategorii danych publicznych udo- stępnianych w module Open Data.

6. Wykonawca jest zobowiązany poprawić wszystkie błędy wynikające ze złego zasilenia Platformy danymi.

6.7. Wymagania w zakresie sposobu reali- zacji

1. Wykonawca oświadcza, że przedmiot zamówienia zostanie zrealizowany z zachowaniem najwyższej profesjonalnej staranności, wymaganej od pod- miotu profesjonalnie wykonującego usługi w obszarze IT.

2. Wykonawca oświadcza, że posiada niezbędną wiedzę, doświadczenie, po- tencjał techniczny i ekonomiczny oraz odpowiedni personel do realizacji przedmiotu zamówienia w zakresie i terminach określonych w OPZ.

3. Wszystkie prace oraz Produkty/usługi będą wykonywane przez doświadczo- nych specjalistów Wykonawcy, którzy zostaną wskazani w Wykazie osób skierowanych przez Wykonawcę do realizacji zamówienia, stanowiącym ele- ment jego oferty. Zmiana osób realizujących przedmiot Umowy wymaga pi- semnej zgody Zamawiającego.

4. Przedmiot zamówienia będzie realizowany zgodnie z metodyką zarządzania projektami Prince2.

5. Wykonawca zobowiązany jest opracować DIP na podstawie Umowy i OPZ,

opisujący standardy i procedury projektowe, według których będzie realizo- wany przedmiot Umowy. Między innymi zarządzanie komunikacją, konfigu- racją, zmianą, ryzykiem, jakością.

6. W ramach realizacji przedmiotu Umowy prowadzona będzie dokumentacja projektowa, ustalona w DIP, w skład której będą wchodziły między innymi: wzory raportów, notatek, protokołów przekazania i odbioru Produktów/Eta- pów/Platformy, rejestr ryzyk.

Opis Przedmiotu Zamówienia strona 57

7. Wszystkie prace oraz Produkty/usługi będą wykonywane zgodnie ze stan- dardami i metodyką określonymi w DIP oraz zgodnie z zapisami Umowy i OPZ.

8. Zamawiający będzie współpracował z Wykonawcą przy realizacji przedmiotu Umowy w zakresie określonym w Umowie.

9. Kierowanie bieżącą realizacją przedmiotu Umowy i koordynacja współpracy między Zamawiającym i Wykonawcą będzie realizowana przez Kierownika Projektu po stronie Zamawiającego.

10. Kierowanie zespołem Wykonawcy będzie realizowane przez Kierownika Pro- jektu Wykonawcy. Odpowiada on za realizację i dostarczanie Zamawiają- cemu Produktów/usług oraz za ich jakość.

11. Wykonawca, w okresie realizacji przedmiotu Umowy, zobowiązany jest do opracowywania i przedstawiania Zamawiającemu do akceptacji cotygodnio- wych Raportów ze stanu realizacji prac. Raport będzie przekazywany pierw- szego Dnia Roboczego po zakończeniu poprzedniego tygodnia. Wykonawca będzie też zobowiązany do opracowania Raportu na każde wezwanie Zama- wiającego, w terminie do trzech (3) dni roboczych od wezwania. Wzór Ra- portu zostanie ustalony w DIP, zgodnie z wymaganiami zawartymi w roz- dziale 4.1 dokumentu OPZ.

12. W okresie realizacji przedmiotu Umowy Zamawiający jest zobowiązany do organizacji regularnych spotkań z zespołem projektowym Wykonawcy. W spotkaniu wymagany jest udział Kierownika Projektu Wykonawcy i jeżeli jest potrzeba udział specjalistów Wykonawcy odpowiedzialnych za realizację po- szczególnych obszarów prac.

13. Podczas każdego spotkania powinna zostać sporządzona notatka zatwier- dzona przez uczestników. Wzór notatki i procedura zatwierdzania zostanie określona w DIP.

Document Metadata

Table of Contents

Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regio- nalnego w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego 2014-2020 oraz ze środków budżetu państwa

Document Metadata