Opis Przedmiotu Zamówienia Budowa Lokalnego Systemu Informatycznego na potrzeby obsługi wniosków o dofinansowanie w ramach POPC

Opis Przedmiotu Zamówienia Budowa Lokalnego Systemu Informatycznego na potrzeby obsługi wniosków o dofinansowanie w ramach POPC Wersja z dnia 4 grudnia 2014 r.

Spis treści 1 Zastosowane skróty i pojęcia... 3 2 Cel zamówienia... 8 3 Przedmiot zamówienia... 8 4 Ogólna koncepcja rozwiązania... 9 4.1. Realizacja zamówienia budowa LSI... 10 5 Wymagania... 13 5.1. Wymagania w zakresie planu budowy systemu... 13 5.2. Wymagania w zakresie Komponentu epuap... 13 5.3. Wymagania funkcjonalne LSI... 15 5.4. Wymagania pozafunkcjonalne... 34 5.4.1. Ergonomia systemu... 34 5.4.2. Architektura systemu... 35 5.4.3. Bezpieczeństwo... 35 5.4.4. Wydajność, pojemność i dostępność systemu... 36 5.4.5. Wymagania prawne... 37 5.4.6. Ograniczenia i zależności... 39 5.4.7. Wymagania w zakresie dokumentacji... 40 5.4.8. Wymagania w zakresie odbioru produktów... 43 5.5. Wymagania w zakresie szkolenia... 45 5.6. Wymagania w zakresie zarządzania projektem... 46 5.7. Wymagania w zakresie gwarancji... 49 6 Załączniki... 51 6.1. Uproszczony model procesów biznesowych,... 51 6.2. Wzór formularza wniosku o dofinansowanie,... 53 6.3. Bazowe powiązania pomiędzy obiektami Systemu dziedzinowego,... 53 6.4. SL2014... 54 6.5. EDOK,... 54

Wprowadzenie Niniejszy dokument stanowi Opis Przedmiotu Zamówienia (OPZ) w zakresie wytworzenia oraz wdrożenia Systemu dziedzinowego oraz Usług elektronicznych. 1 Zastosowane skróty i pojęcia Skrót/pojęcie Aktor Błąd kategorii A Błąd kategorii B Opis skrótu/pojęcia Użytkownik lub zewnętrzny system, z którym System dziedzinowy wchodzi w interakcje: Urzędnik, Komponent epuap. Wystąpił problem uniemożliwiający użytkowanie LSI lub dowolny problem związany z bezpieczeństwem Systemu dziedzinowego. Wystąpił problem, co najmniej jeden z poniższych problemów: LSI działa w sposób niezgodny z dokumentacją, występują istotne ograniczenia w działaniu LSI, nastąpiła awaria powodująca ograniczenie wydajności LSI, nie można korzystać z LSI, ale uzyskanie oczekiwanych efektów jest możliwe w inny sposób (obejście). Błąd kategorii B nie obejmuje sytuacji określonych, jako Błąd kategorii A. Błąd kategorii C CRD Oznacza pojawienie się usterki LSI o charakterze ergonomicznym niemającej wpływu na wynik pracy użytkownika. Błąd kategorii C nie obejmuje sytuacji objętych Błędem kategorii A i kategorii B. Centralne Repozytorium Wzorów Dokumentów Elektronicznych (CRD) 1 Miejsce zapewniające jednolite i bezpieczne źródło informacji o dokumentach elektronicznych administracji publicznej. Dostęp do CRD jest bezpłatny i umożliwia pobranie dowolnego, opublikowanego tam wzoru dokumentu elektronicznego. 1 URI: http://epuap.gov.pl/wps/portal/!ut/p/c1/04_sb8k8xllm9msszpy8xbz9cp0os3g3z4- gyg93qwmlrydxa89go2cxyennim9yvydbureanmdpzw!!/

Skrót/pojęcie Dokumentacja projektowa Dokumentacja powykonawcza epuap ESP GUI Komponent epuap KUP MAC Model Modyfikacja Oprogramowanie aplikacyjne Opis skrótu/pojęcia Oznacza dokumentację określoną w wymaganiu DOK.2 Oznacza dokumentację określoną w wymaganiu DOK.3 Elektroniczna Platforma Usług Administracji Publicznej system informatycznych dostępny pod adresem www.epuap.gov.pl; zbiór produktów projektu epuap-wkp rozwijanych w ramach projektu epuap2. Elektroniczna Skrzynka Podawcza Graficzny interfejs użytkownika Systemu dziedzinowego dostępny przez przeglądarkę WWW. Usługi elektroniczne (potocznie formularze interaktywne) na platformie epuap wraz z oprogramowaniem sterującym przepływem danych na platformie epuap i wysyłaniem danych do Systemu dziedzinowego oraz odbieraniem danych z Systemu dziedzinowego. Katalog Usług Publicznych Systemu epuap. Ministerstwo Administracji i Cyfryzacji Uproszczony obraz rzeczywistości. Prezentowany z pewnej perspektywy, na pewnym poziomie abstrakcji. Zmiana lub rozbudowa Oprogramowania aplikacyjnego Systemu dziedzinowego lub Usługi elektronicznej, w tym aktualizacja Dokumentacji projektowej i powykonawczej dokonana na podstawie dokumentu Wniosek o Zmianę (RfC). Modyfikacjami nie są zmiany dostosowujące System dziedzinowy lub Usługę do obowiązujących przepisów prawa, które Wykonawca jest zobowiązany realizować w ramach gwarancji. Oprogramowanie dostarczone przez Wykonawcę na potrzeby realizacji niniejszej umowy. Wykonawca: przekaże Zamawiającemu kody źródłowe

Skrót/pojęcie Opis skrótu/pojęcia Oprogramowania aplikacyjnego, W zakresie oprogramowania wytwarzanego przez Wykonawcę Wykonawca przeniesie na Zamawiającego autorskie prawa majątkowe do Oprogramowania aplikacyjnego. W zakresie oprogramowania typu open source dostarczanego przez Wykonawcę Wykonawca udzieli Zamawiającemu na Oprogramowanie aplikacyjne licencję wolnego i otwartego oprogramowania. Szczegóły dotyczące relacji prawno-autorskich pomiędzy Wykonawcą a Zamawiającym precyzuje zawarta Umowa. Oś / Oś priorytetowa Usługa / usługa elektroniczna LSI / Portal LSI PZP Repozytorium plików RfC (ang. Request for Change)/Wniosek o Zmianę) System dziedzinowy Środowisko Dziedzina wsparcia w ramach POPC. Osie określają dziedziny szczególnie ważne dla rozwoju Polski. Dzielą się one na działania, które wyznaczają szczegółowe zakresy projektów, objętych dofinansowaniem unijnym. Usługa elektroniczna, na którą składa się Oprogramowanie Aplikacyjne wraz z Dokumentacją. System informatyczny wspierający cykl życia wniosku o dofinansowanie. System ten pozwala na zgłaszanie informacji o wnioskach, a także na prezentacje informacji o aktualnym statusie danego wniosku. Na Portal LSI składają się: System dziedzinowy i Komponent epuap. Plan Zarządzania Projektem. Magazyn Systemu dziedzinowego służący do uporządkowanego przechowywania dokumentów XML, plików binarnych. Dokument opisujący zakres wprowadzanych przez Wykonawcę zmian ponad określone w wymaganiach zawartych w Opisie Przedmiotu Zamówienia oraz czynności związane z Modyfikacjami wykonywane przez Wykonawcę w ramach zleceń zgodnie z oczekiwaniami Zamawiającego oraz Użytkowników końcowych lub zlecenia wykonania usług konsultacyjnych. Dostarczone przez Wykonawcę w ramach niniejszego zamówienia Oprogramowanie aplikacyjne, spełniające wymagania niniejszego OPZ. Środowisko systemu epuap (www.epuap.gov.pl) dostarczone

Skrót/pojęcie produkcyjne Środowisko testowe UPO Urzędowe Poświadczenie Odbioru Opis skrótu/pojęcia przez Zamawiającego, działające w czasie rzeczywistym, obsługujące rzeczywistych użytkowników i rzeczywiste dane w określonym reżimie SLA. Środowisko systemu epuap (test.epuap.gov.pl) dostarczone przez Zamawiającego, działające w czasie rzeczywistym, obsługujące testowych użytkowników i testowe dane w określonym reżimie SLA. Dane elektroniczne dołączone do dokumentu elektronicznego doręczonego podmiotowi publicznemu lub połączone z tym dokumentem w taki sposób, że jakakolwiek późniejsza zmiana dokonana w tym dokumencie jest rozpoznawalna, określające: a. pełną nazwę podmiotu publicznego, któremu doręczono dokument elektroniczny, b. datę i godzinę doręczenia dokumentu elektronicznego rozumiane, jako data i czas wprowadzenia albo przeniesienia dokumentu elektronicznego do systemu teleinformatycznego podmiotu publicznego, c. datę i godzinę wytworzenia Urzędowego Poświadczenia Odbioru. Urzędowe Poświadczenie Odbioru (UPO) jest określone w Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 27 listopada 2006 r. w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych (Dz.U. 2006 nr 227 poz. 1664). UPO jest wspólnym określeniem dla Urzędowego Poświadczenia Przedłożenia (UPP) i Urzędowego Poświadczenia Doręczenia (UPD). Lokalizacja plików aktualnie obowiązującego wzoru UPO: Plik schematu: http://crd.gov.pl/xml/schematy/upo/2008/05/09/schematupo.xsd Plik wizualizacji: http://crd.gov.pl/xml/schematy/upo/2008/05/09/upo.xsl Plik wyróżnika: http://crd.gov.pl/xml/schematy/upo/2008/05/09/wyroznik.xml

Skrót/pojęcie UPP Urzędowe Poświadczenie Przedłożenia UPD Urzędowe Poświadczenie Doręczenia PND Poświadczenie Niedoręczenia Dokumentu Opis skrótu/pojęcia Zgodnie z rozporządzeniem Prezesa Rady Ministrów w sprawie warunków organizacyjno-technicznych doręczania dokumentów elektronicznych podmiotom publicznym (Dz.U. z 2005 Nr 200, poz. 1651) i rozporządzeniem Ministra Spraw Wewnętrznych i Administracji w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych (Dz.U. z 2006 Nr 227, poz. 1664) urzędowe poświadczenie odbioru (UPO) jest dowodem na doręczenie pisma. Z uwagi na stronę wystawiającą takie poświadczenie, zostały wprowadzone (w epuap) dwa rodzaje poświadczeń: 1. UPP gdy urząd (organ administracji) potwierdza odbiór pisma, 2. UPD gdy klient potwierdza odbiór pisma. Oba te rodzaje potwierdzeń opierają się na tym samym wzorze UPO. Podział ten wprowadza (w epuap) jedynie łatwiejsze i jednoznaczne określenie potwierdzenia (w zależności od strony potwierdzającej), ale nadal są to zgodne z prawem urzędowe potwierdzenia odbioru (UPO). Z tego samego powodu (łatwiejsze i jednoznaczne określenie potwierdzenia) dodatkowo wprowadzono (w epuap) pojęcie PND. Wzór dokumentu XML Definicja struktury dokumentu obejmująca określenie jego schematu (struktury), jego znaczenie oraz formy wizualizacji. Wzór dokumentu jest wystarczający dla jego prezentacji wizualnej oraz określenia znaczenia. Wniosek o dofinansowanie Beneficjent Formularz składany przez beneficjenta w celu uzyskania wsparcia ze środków dofinansowania ze środków POPC. Podmiot ubiegający się o dofinansowanie / składający wniosek POPC Program Operacyjny Polska Cyfrowa dla okresu 2014-2020 współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego, nazywany też dalej zamiennie Programem SL2014 SL2014 to aplikacja, której podstawowymi celami są: wsparcie bieżącego procesu zarządzania, monitorowania i oceny programów współfinansowanych z funduszy strukturalnych i Funduszu Spójności oraz programów realizowanych w ramach Europejskiej Współpracy Terytorialnej i Europejskiego Instrumentu Sąsiedztwa, dla których instytucja zarządzająca została ustanowiona na

Skrót/pojęcie Opis skrótu/pojęcia terytorium Rzeczypospolitej Polskiej; zachowanie odpowiedniego śladu audytowego; umożliwienie Beneficjentom rozliczania realizowanych przez nich projektów zgodnie z wymogami rozporządzenia ogólnego. WWPE edok Prototyp Władza Wdrażająca Programy Europejskie. System elektronicznego obiegu dokumentów. Oprogramowanie aplikacyjne będące interaktywnym modelem Elektronicznego formularza w postaci interfejsu graficznego. Prototyp podlega akceptacji Zamawiającego. 2 Cel zamówienia Celem zamówienia jest informatyczne wsparcie następujących zadań dotyczących wniosków o dofinansowanie ze środków POPC: 1. Złożenie wniosku o dofinansowanie na platformie epuap. 2. Złożenie korekty do wniosku o dofinansowanie na platformie epuap. 3. Prezentacja informacji o wnioskach w Systemie dziedzinowym. 4. Prezentacja i informacji z listy rankingowej. 5. Generowanie raportów, zestawień i umów. Zadanie zostanie osiągnięte poprzez wytworzenie oraz wdrożenie Systemu dziedzinowego oraz Usług elektronicznych dla LSI. 3 Przedmiot zamówienia Przedmiotem zamówienia jest wytworzenie oraz wdrożenie Systemu dziedzinowego oraz Usług elektronicznych dla LSI.

4 Ogólna koncepcja rozwiązania Główną rolą systemu będzie przechowywanie oraz prezentowanie w formie raportów danych dotyczących naborów wniosków o dofinansowanie i samych, zarejestrowanych w kontekście tych naborów, wniosków. Rysunek 1. Ogólne koncepcja rozwiązania Rysunek 1 przedstawia logiczną prezentację funkcjonalności gdzie: 1. Wnioskodawca wypełnia formularz wniosku o dofinansowanie na platformie epuap i wysyła go na skrytkę WWPE. 2. Formularz trafia do Systemu dziedzinowego gdzie tworzony jest wniosek o dofinansowanie z odpowiednim numerem. 3. Wniosek czeka w kolejce dokumentów, a następnie jest pobierany przez aplikację edok. 4. Wniosek jest procesowany, zgodnie z obwiązującymi instrukcjami i procedurami. 5. Zarejestrowane w systemie LSI dane służą do tworzenia raportów i zestawień. 6. Wnioski są przesyłane do systemu SL2014. 7. Użytkownicy Systemu dziedzinowego otrzymują powiadomienia mailowe.

4.1. Realizacja zamówienia budowa LSI Wykonawca zbuduje Lokalny System Informatyczny (LSI) wspierający cykl życia wniosku o dofinansowanie. System ten będzie umożliwiał złożenie wniosku o dofinansowanie, lub korekty wniosku, za pośrednictwem platformy epuap, wykorzystując dedykowana Usługę elektroniczną, a także na prezentacje, w Systemie dziedzinowym, informacji o wnioskach zgłoszonych w ramach naboru (w tym: dane wniosku, załączniki, status). Wśród aktorów LSI znajdują się: Beneficjent, który składa wniosek lub aktualizację wniosku o dofinansowanie; Urzędnik, który weryfikuje (pozytywnie lub negatywnie) poprawność i kompletność wniosku o dofinansowanie; Administrator Lokalny, który zrządza użytkownikami Systemu dziedzinowego w ramach jednego podmiotu; Administrator Systemu, który zarządza zaawansowanymi funkcjami systemu. Aktorami LSI po stronie Zamawiającego będą pracownicy podmiotów: Władzy Wdrażającej Programy Europejskie, Ministerstwa Administracji i Cyfryzacji, Ministerstwa Infrastruktury i Rozwoju,

Przedmiot zamówienia obejmuje: Etapy Przedmiot zamówienia Maksymalny czas wyznaczony do realizacji Etapu Etap 1 Etap 2 1) opracowanie i dostarczenie Zamawiającemu Dokumentacji Etapu 1, w szczególności: a) Dokumentacja Analityczna; b) Dokumentacja Technicznego; c) Plan Testów Akceptacyjnych; d) Planu Zarządzania Projektem; 2) przeniesienie na Zamawiającego autorskich praw majątkowych oraz prawa zezwalania na wykonywanie praw zależnych do Dokumentacji wytworzonej w ramach Etapu 1; 3) opracowanie i dostarczenie Zamawiającemu Dokumentacji Etapu 2, w szczególności: a) Panu Wdrożenia Systemu, b) Opisu Realizacji Szkoleń. 4) dostarczenie Oprogramowania aplikacyjnego Systemu dziedzinowego i Usługi elektronicznej wraz z dostawą, instalacją, konfiguracją i wdrożeniem w Środowisku testowym wraz z testami wewnętrznymi Wykonawcy. 5) wykonanie przez Wykonawcę wspólnie z Zamawiającym testów akceptacyjnych Systemu na wskazanym przez Zamawiającego środowisku, zgodnie z zatwierdzonym przez Zamawiającego Planem Testów Akceptacyjnych 6) przeprowadzenie wdrożenia produkcyjnego (instalacja, konfiguracja, testy integracyjne) Systemu zgodnie z Projektem Technicznym oraz Planem Wdrożenia Systemu; 7) przeniesienie na Zamawiającego autorskich praw majątkowych oraz prawa zezwalania 30 dni od dnia zawarcia Umowy 100 dni od dnia zawarcia Umowy,

Etap 3 Szkolenia Modyfikacje Gwarancja na wykonywanie praw zależnych do Oprogramowania Aplikacyjnego i Dokumentacji wytworzonej w ramach Etapu 2; 8) opracowanie i dostarczenie Zamawiającemu Dokumentacji Etapu 3, w szczególności: a) dokumentacji Powykonawczej, b) dokumentacji Eksploatacyjnej, c) dokumentacji Powdrożeniowej Systemu, 9) przeniesienie na Zamawiającego autorskich praw majątkowych oraz prawa zezwalania na wykonywanie praw zależnych do Dokumentacji wytworzonej w ramach Etapu 3; 10) przeprowadzenie przez Wykonawcę Szkoleń, dla łącznej ilości do 10 trenerów, realizowanych zgodnie z zatwierdzonym przez Zamawiającego Opisem Realizacji Szkoleń, udzielonych na podstawie Zlecenia Szkoleń; 11) wykonywanie Modyfikacji realizowanych na podstawie Zleceń, w wysokości 500 (słownie: pięćset) roboczogodzin, gdzie roboczogodzina oznacza 60 minut, w okresie 24 miesięcy od podpisania protokołu odbioru Etapu 1 umowy. 12) udzielenie gwarancji i świadczenie serwisu gwarancyjnego dla Systemu LSI w okresie 24 miesięcy. Termin rozpoczęcia gwarancji liczony jest od następnego dnia po upływie miesiąca bezawaryjnego działania Systemu LSI, w czasie operacyjnego funkcjonowania Systemu LSI. 13) udzielenie gwarancji i świadczenie serwisu gwarancyjnego dla Modyfikacji w okresie 24 miesięcy, licząc od dnia podpisania danego Protokołu Odbioru Zlecenia na podstawie, którego prace te są odbierane. 14) udzielenie gwarancji zgodnie z wymaganiami rozdziału 5.7. 130 dni od dnia zawarcia Umowy, do dnia końca gwarancji,

5 Wymagania 5.1. Wymagania w zakresie planu budowy systemu Kod WPBS.01 Wykonawca opracuje i dostarczy projekt techniczny wytworzenia Oprogramowania aplikacyjnego Systemu dziedzinowego zgodnie z wymaganiami zawartymi w niniejszym dokumencie. 5.2. Wymagania w zakresie Komponentu epuap Kod Usługa elektroniczna UEL.1. Wykonawca przygotuje do 10 aplikacji na platformie epuap umożliwiających świadczenie usług elektronicznych. UEL.2. UEL.3. UEL.3.1. W wyniku wytworzenia aplikacji powstaną Elektroniczne formularze umożliwiające Beneficjentom zgłaszanie wniosków o dofinansowanie. W ramach tworzenia Usług elektronicznych Wykonawca dokona pełnej konfiguracji, w Środowisku Testowym, obejmującej m. in. utworzenie kont, podmiotów, konfiguracja kont i skrytek, obsługa certyfikatów zgodnie z instrukcjami znajdującymi się na portalu epuap w lokalizacji: http://www.epuap.gov.pl w sekcji Pomoc > Integratorzy. Dla Środowiska Produkcyjnego Wykonawca przygotuje instrukcje instalacji obejmującą wszystkie czynności zrealizowane w ramach wymagania UEL.3 z uwzględnieniem specyfiki Środowiska Produkcyjnego. Przygotowanie interaktywnego Prototypu Elektronicznego formularza UEL.4. Wykonawca zobowiązany jest do stworzenia Prototypu w ramach każdej tworzonej Usługi. Prototyp powinien zawierać, w szczególności: układ pól i przycisków, rozmieszczenie nagłówków, tytułów, sekcji, walidacje, zależności między polami (aktywne, nieaktywne);

Przygotowanie oprogramowania umożliwiającego instalację Usługi na platformie epuap UEL.5. Wykonawca przygotuje wszystkie elektroniczne dokumenty (zgodnych z właściwymi przepisami prawa) występujące w poszczególnych usługach. Dokumenty elektroniczne powinny być zgodne ze standardem dokumentów epuap, które oparte są o format XML. Format wzorów powinien być zgodny z formatem przyjętym dla Centralnego Repozytorium Wzorów Dokumentów Elektronicznych, który opiera się na rekomendacjach opisanych i umieszczonych w portalu interoperacyjność epuap. UEL.6. UEL.6.1. UEL.6.1.1. UEL.6.1.2. UEL.6.1.2.1. Wykonawca opracuje Elektroniczne formularze oraz akcje w nich zawarte, zgodnie z analizą funkcjonalną zaakceptowaną przez Zamawiającego. Analizując dane wprowadzane do formularza należy dążyć do maksymalnego wykorzystania słowników dostępnych na epuap, jak i zbudowanych na potrzeby realizacji usługi. 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ć zwrotną informację. W budowanych formularzach należy wykorzystać mechanizm epuap pobierania danych z profilu celem uzupełniania danych o wnioskodawcy. Wszystkie opracowane formularze muszą działać dwóch trybach. W trybie podstawowym rozumianym, jako zgłoszenie wniosku o dofinansowanie, oraz w trybie aktualizacji rozumianym, jako wysłanie aktualizacji wniosku o dofinansowanie na prośbę WWPE. W trybie podstawowym Wykonawca wykona formularze zgodnie z pkt. UEL.6. W trybie aktualizacji Wykonawca wykona formularze zgodnie z pkt. UEL.6. Ponadto dla aktualizacji Wykonawca zapewni funkcjonalność pobierania danych wniosku na formularz. Formularz w trybie aktualizacji będzie umożliwiał Beneficjentowi wpisanie numery wniosku oraz wywołanie akcji pobierz dane wniosku. Po wywołaniu tej akcji na formularz zostaną przekazane dane odpowiadające wpisanemu numerowi wniosku. Formularz zostanie zasilony danymi z Systemu dziedzinowego. W ramach akcji pobierz dane wniosku formularz zostanie zasilony podstawowymi danymi o Beneficjencie oraz tymi danymi, które zostały odpowiednio oznaczone w Systemie dziedzinowym zgodnie z wymaganiem WF.12.9 i tylko te pola będą aktywne i będą podlegały

walidacji. Zestaw podstawowych danych dotyczących Beneficjenta zostanie określony na etapie analizy i podlega akceptacji Zamawiającego. Formularze stosowane na epuap są tworzone z wykorzystaniem języka xforms, Adobe. Przykładowy, akceptowany przez system epuap formularz wykorzystujący język xforms opublikowany jest na portalu epuap, pod adresem http://www.epuap.gov.pl w sekcji Pomoc > integratorzy >podręczniki > Instrukcja administratora Struktura formularza XForms uruchamianego na platformie epuap. Przykładowy, akceptowany przez system epuap, szablon formularza tworzonego w technologii PDF spełniający wymagania w zakresie logotypów, opublikowany jest na portalu epuap w lokalizacji: http://www.epuap.gov.pl w sekcji Pomoc > Podmioty Publiczne > Licencje na formularze PDF punkt 4. Wizualizacja dokumentu elektronicznego nie musi być identyczna ze wzorem nieelektronicznym, ale musi zawierać dane w układzie niepozostawiającym wątpliwości, co do treści i kontekstu zapisanych informacji, w sposób zgodny z wzorem określonym we właściwym akcie normatywnym. Aplikacja ma być zgodna z architekturą biznesową epuap oraz architekturą systemu informatycznego epuap. Instrukcja budowy aplikacji znajduje się w Środowisku Budowy Aplikacji portalu epuap, pod adresem http://epuap.gov.pl/wps/wcm/connect/fec48a99-ed32-4a23-8b0c-ca41543021ab/budowa_formularzy_w_edytorze_sba_7.0.pdf?mod=ajperes. Proces instalacji aplikacji dla podmiotów publicznych należy o ile jest to konieczne przygotować z wykorzystaniem Instalatora Usług epuap. 5.3. Wymagania funkcjonalne LSI Kod Budowa systemu zgodnie z modelem procesów biznesowych WF.1 Oprogramowanie realizuje biznesowy model analityczny zamieszczony w basenie System dziedzinowy następujących modeli procesów: 1. Złożenie wniosku o dofinansowanie; 2. Aktualizacja wniosku o dofinansowanie; 3. Prezentacja i edycja informacji o wnioskach; 4. Prezentacja informacji z listy rankingowej. Uproszczone modele procesów stanowi załącznik 6.1 do OPZ.

Kod Komunikacja pomiędzy systemami, tworzenie i zapisywanie danych WF.2 WF.2.1 Komponent epuap komunikuje się z Systemem dziedzinowym przy wykorzystaniu standardu XML. Wykonawca jest zobowiązany zapewnić dwustronną komunikację pomiędzy Systemem dziedzinowym a Komponentem epuap. W Komponencie epuap dokumenty w postaci plików XML są tworzone na podstawie wzorów dokumentów CRD i formularzy zgłoszenia lub aktualizacji wniosku o dofinansowanie. WF.3 WF.3.1 Przedstawienie przykładowego zakresu oraz struktury danych formularzy stanowi załącznik 6.2 do OPZ. Wykonawca jest zobowiązany po stronie Systemu dziedzinowego wykonać mechanizm (np. Web-Service) przyjmowania danych z Komponentu epuap do Systemu dziedzinowego w ramach niniejszej umowy. System dziedzinowy przyjmuje pliki XML (z załącznikami binarnymi albo bez załączników binarnych) wysłane z Komponentu epuap. Pliki XML są tworzone w Komponencie epuap na podstawie wzorów dokumentów z CRD oraz treści z formularzy wypełnionych przez Beneficjenta. Dokumenty przekazywane z Komponentu epuap zawierają podpis Profilem Zaufanym lub Podpis Kwalifikowany. Na podstawie danych z Komponentu epuap System dziedzinowy będzie rejestrował wnioski o dofinansowanie lub dokonywał aktualizacji już istniejących, w Rejestrze Wniosków (WF.12). System dziedzinowy przyporządkuje wnioski do odpowiedniego naboru (WF.10.8.1). WF.3.2 WF.3.2.1 Mechanizm podpisu jest zapewniony przez Komponent epuap i nie jest w zakresie niniejszego zamówienia. System dziedzinowy po otrzymaniu wniosku o dofinansowanie każdorazowo odpytuje Rejestr Naborów i sprawdza czy dany wniosek można przyporządkować do odpowiedniego naboru zgodnie z wymaganiem WF.10.8.1. Jeśli nie ma takiej możliwości System dziedzinowy wyśle odpowiedni komunikat do Komponentu epuap, który Beneficjent otrzyma w odpowiedzi na próbę zgłoszenia takiego wniosku. System dziedzinowy, każemy otrzymanemu wnioskowi o dofinansowanie, otrzymanemu w postaci XML, nadaje unikalny

Kod numer wniosku o dofinansowanie. System dziedzinowy zapisze taki wniosek w rejestrze i przypisze do odpowiedniego naboru. Taki wniosek jest następnie umieszczany w kolejce wniosków do pobrania i oczekuje na pobranie go przez system edok. WF.4 WF.5 WF.4.1 Mechanizmy systemu edok nie są w zakresie niniejszego zamówienia. Wykonawca jest zobowiązany wykonać mechanizm przekazywania plików lub danych z Systemu dziedzinowego do Komponentu epuap. W komponencie epuap, z poziomu formularza jest możliwość podania numeru wniosku zgodnie z wymaganiem UEL.6.1.2. Dla poprawnie podanego numeru wniosku znajdującego się w Systemie dziedzinowym, System dziedzinowy przekaże dane wniosku do Komponentu epuap. Przekazane dane zasilą formularz, z którego wywołano funkcje pobrania danych. System edok komunikuje się z Systemem dziedzinowym. Wykonawca wykona implementację po stronie Systemu dziedzinowego usługi udostępniającej pliki XML (potocznie formularze) w technologii rozproszonych komponentów programowych, udostępnianych za pośrednictwem protokołu SOAP (Web Services). Udostępniona usługa musi umożliwiać pobrania jednego, wielu lub wszystkich formularzy z Systemu dziedzinowego do systemu edok. WF.5.1 WF.5.1.1 WF.5.1.2 Założenia komunikacji z edok stanowi załącznik 6.5 do OPZ. System edok korzystając z usługi Systemu dziedzinowego pobierze oryginalną treść formularza (lub formularzy) wysłaną z Komponentu epuap (ze skrytki) oraz dodatkowe meta dane (m. in. numer wniosku), których pełny zakres będzie określony w trakcie analizy. System dziedzinowy przekazuje plik XML (z załącznikami binarnymi albo bez załączników binarnych) otrzymane z Komponentu epuap do systemu edok wraz z nadanym numerem wniosku o dofinansowanie (WF.3.2.1) System dziedzinowy udostępniając pliki XML systemowi edok zapewni, iż Podpis Kwalifikowany lub podpis Profilem Zaufanym dokumentu nie zostanie zniszczony oraz zostanie przesłana informacja o nadawcy tj. o adresie skrytki Beneficjenta.

Kod WF.6 WF.6.1 WF.7 WF.7.1 Wszystkie pliki XML (z załącznikami binarnymi i bez załączników binarnych), o których mowa w wymaganiu WF.3.1, są przechowywane w Repozytorium plików Systemu dziedzinowego. Wszystkie pliki XML (z załącznikami binarnymi i bez załączników binarnych) muszą być powiązane z odpowiednimi obiektami z Rejestru Wniosków. Wykonawca jest zobowiązany wykonać mechanizm przekazywania plików lub danych z Systemu dziedzinowego do SL2014. System dziedzinowy umożliwi eksport danych do Centralnego Systemu Informatycznego SL2014 przygotowywanego przez Ministerstwo Infrastruktury i Rozwoju. Urzędnik Zarządzanie Danymi WF.8 WF.8.1 WF.8.2 Funkcja eksportu danych realizowana będzie na podstawie tzw. XML Schema, który zostanie przekazany Wykonawcy na etapie analizy. Dokumenty i specyfikacje dotyczące XML Schema dotyczące poprzedniej perspektywy (2007-2013) można pobrać ze strony: http://www.funduszeeuropejskie.gov.pl/ AnalizyRaportyPodsumowania/ Strony/ XML_shema_240310.aspx Schematy XML, które będą wykorzystywane do eksportu danych do SL2014 są jeszcze w trakcie opracowania przez Ministerstwo Infrastruktury i Rozwoju. Zakres eksportowanych danych zostanie Wykonawcy przekazany na etapie analizy. Zasady procedury dotyczące eksportu danych do SL2014 stanowią załącznik 6.4 do OPZ. System dziedzinowy będzie umożliwiał Urzędnikowi zarządzanie danymi z Rejestru Naborów, Rejestru Wniosków, Listy Rankingowej oraz generowanie Raportów i Umów. Zarządzanie danymi oraz plikami w Systemie dziedzinowym jest możliwe tylko dla użytkowników posiadających aktywne konto w Systemie dziedzinowym. Dostęp do Systemu dziedzinowego jest możliwy jedynie dla użytkowników po uwierzytelnieniu i autoryzacji w Systemie dziedzinowym. WF.8.2.1 System dziedzinowy wykorzystuje własny mechanizm uwierzytelniania i autoryzacji Urzędników.

Kod WF.8.2.2 Mechanizm uwierzytelniania i autoryzacji Systemu dziedzinowego zapewni następujące funkcjonalności: wysłanie informacji e-mail o założeniu nowego konta Urzędnika wraz linkiem aktywacyjnym resetowanie hasła wysłanie tymczasowego hasła na adres e-mail użytkownika wraz z wymuszeniem zmiany tego hasła przy pierwszym logowaniu po zresetowaniu hasła Urzędnik Rejestr Osi WF.9 System dziedzinowy pozwala Urzędnikowi na zarządzanie Rejestrem Osi. W Rejestrze osi przechowywane będą informacje dotyczące każdej z trzech osi. W szczególności w kontekście osi przechowywane będą następujące atrybuty: Nazwa Osi, Opis Osi oraz celów szczegółowy, Kwota dostępnej alokacji (EUR), Kwota dostępnej alokacji (PLN), Kwota przyznanego dofinansowania w ramach Osi (PLN), Pozostała kwota w ramach alokacji (PLN); WF.9.1 System dziedzinowy wylicza kwotę przyznanego dofinansowania (w ramach Osi) jako sumę kwot wniosków ze statusem przyznane dofinansowanie dla wniosków złożonych w ramach naboru dla danej Osi. Urzędnik Rejestr Naborów WF.10 System dziedzinowy pozwala Urzędnikowi na zarządzanie Rejestrem Naborów. W Rejestrze naborów przechowywane będą informacje dotyczące naborów. W szczególności w kontekście naboru przechowywane będą następujące atrybuty: Oś priorytetowa oraz cel szczegółowy, Rodzaj naboru (słownik), Instytucja ogłaszająca nabór (słownik), Numer naboru, Okres składania wniosków, Kwota dostępnej alokacji, Opis naboru,

Kod Opcje naboru, Dla każdego naboru System dziedzinowy będzie prezentował: Czas pozostały do rozpoczęcia naboru (dynamiczny licznik), Czas pozostały do zakończenia naboru (dynamiczny licznik), WF.10.1 System dziedzinowy umożliwia wyświetlenie, z widoku naboru: Listy rankingowej (WF.14) Listy rezerwowej (WF.15) Suplementów związanych z naborem (WF.11) WF.10.2 WF.10.3 WF.10.4 WF.10.5 WF.10.6 WF.10.7 WF.10.8 WF.10.8.1 System dziedzinowy umożliwia przeglądanie harmonogramu wszystkich naborów. Forma prezentowania harmonogramu będzie analogiczna do kalendarza MS Outlook. System dziedzinowy umożliwia przeglądanie rejestru naborów, w formie listy. Listę będzie można filtrować, stronicować i sortować. Listę naborów można zapisać w postaci pliku CSV i XML. System dziedzinowy umożliwia dodanie nowego naboru. W ramach definiowania naboru konieczne będzie wprowadzenie atrybutów określonych w wymaganiu WF.8. Tak wprowadzony nabór będzie miał status nieotwarty. W ramach nieotwartego naboru nie można składać wniosków o dofinansowanie. W celu otwarcia naboru konieczne będzie wywołanie funkcji Otwórz nabór. System dziedzinowy umożliwia przeglądanie szczegółów naboru, prezentując atrybuty naboru, w trybie do odczytu. System dziedzinowy umożliwia edytowanie atrybutów naboru. Edytować będzie można tylko te nabory, które są w statusie nieotwarty System dziedzinowy umożliwia usuwanie naboru. Usuwać będzie można tylko te nabory, które są w statusie nieotwarty. System dziedzinowy umożliwia otwarcie naboru. Otwartemu naborowi nadany będzie status otwarty. Wniosek o dofinansowanie będzie można przypisać do naboru wtedy i tylko wtedy, gdy nabór będzie w statusie otwarty.

Kod WF.10.8.2 Jeśli Beneficjent będzie próbował zgłosić, za pomocą formularza (UEL.6.1), wniosek o dofinansowanie a w Systemie dziedzinowym: nabór będzie w statusie innym niż otwarty; data wpłynięcia wniosku nie będzie się zawierać w przedziale określonym przez Okres składania wniosków; to System dziedzinowy nie pozwoli na wykonanie takiego zgłoszenia informując Beneficjenta stosownym komunikatem. WF.10.9 System dziedzinowy umożliwia zamknięcie naboru. Funkcja będzie mogła być uruchomiona na żądanie użytkownika, jak również automatycznie, w dacie i godzinie zakończenia naboru. Urzędnik Rejestr Suplementów WF.11 System dziedzinowy pozwala Urzędnikowi na zarządzanie Rejestrem Suplementów. W Rejestrze suplementów przechowywane będą informacje dotyczące suplementów. W szczególności w kontekście suplementu przechowywane będą następujące atrybuty: Oś priorytetowa oraz cel szczegółowy, Nabór (referencja/odwołanie), Instytucja ogłaszająca nabór (słownik), Numer suplementu, Numer naboru, Kwota dostępnej alokacji, Opis suplementu, WF.11.1 System dziedzinowy pozwala Urzędnikowi na stworzenie suplementu, w ramach danego naboru będącego w statusie zamknięty. Suplement jest szczególnym rozszerzeniem naboru dedykowanym wnioskom z Listy rezerwowej. WF.11.1.1 WF.11.2 System dziedzinowy umożliwia dodanie nowego suplementu również z poziomu naboru. W ramach definiowania suplementu konieczne będzie wprowadzenie atrybutów określonych w wymaganiu WF.11. W przypadku tworzenie suplementu z poziomu naboru atrybuty związane z naborem uzupełniają się automatycznie. W ramach suplementu nie ma możliwość składanie wniosków o

Kod dofinansowanie oraz nie jest tworzona Lista rankingowa. WF.11.3 WF.11.4 W ramach suplementu System dziedzinowy umożliwia dołączenie (dodanie) do suplementu wniosków o dofinansowanie w postaci Listy rezerwowej. System dziedzinowy umożliwia przeglądanie rejestru suplementów, w formie listy. Listę będzie można filtrować, stronicować i sortować. Listę suplementów można zapisać w postaci pliku CSV i XML. Urzędnik Rejestr Wniosków WF.12 System dziedzinowy pozwala Urzędnikowi na zarządzanie Rejestrem Wniosków. W Rejestrze wniosków przechowywane będą informacje dotyczące wniosków o dofinansowanie pochodzących z Komponentu epuap. W kontekście wniosku o dofinansowanie przechowywane będą różne sekcje (w tym historia zmian), atrybuty i załączniki, w zależności od typu wniosku. W ramach niniejszej umowy powstanie do 10 typów wniosku (UEL.1). Pełna lista sekcji, atrybutów i dopuszczanych załączników zostanie określona na etapie analizy. WF.12.1 WF.12.1.1 WF.12.1.2 WF.12.1.3 WF.12.2 Przykładowy wniosek o dofinansowanie, pokazujący atrybuty danej sekcji, stanowi załącznik 6.2 do OPZ. System dziedzinowy będzie umożliwiał przeglądanie listy wniosków. Listę będzie można filtrować, sortować i stronicować. Listę wniosków można zapisać w postaci pliku CSV i XML. System dziedzinowy umożliwi wyszukanie wniosku na liście wniosków na podstawie m. in. identyfikatora wniosku, nazwy wniosku, daty złożenia wniosku (od-do). Pełny zakres możliwości wyszukiwania zostanie ustalony na etapie analizy. Wybranie dowolnego wniosku z listy spowoduje wyświetlenie szczegółów danego wniosku. System dziedzinowy umożliwi grupowe zaznaczanie wniosków z poziomu Listy wniosków (WF.12.1) i wysłanie (np. wywołanie funkcji wyślij do SL2014) tzw. paczki wniosków do systemu SL2014 zgodnie z wymaganiem WF.7. W ramach każdego wniosku będzie możliwość wywołania funkcji

Kod wysłania do SL2014 zgodnie z wymaganiem WF.7. Spowoduje to wysłanie pojedynczego wniosku do SL2014. WF.12.3 WF.12.4 WF.12.5 Każdy wniosek, którego dane zostały przesłane do systemu SL2014 zostanie oznaczony flagą (znacznikiem) oraz dla takiego wniosku zostanie zapisana data wyłania do SL2014 (data ustawienia znacznika). Wnioski juz raz wysłane do systemu SL2014 (oznaczone znacznikiem) nie będą ponownie wysyłane do SL2014 przy wywołaniu funkcji wysyłania do SL2014. W ramach wniosku Urzędnik będzie miał możliwość zmiany statusu wniosku o dofinansowanie. Minimalna lista statusów: zarejestrowany, w trakcie oceny formalnej, przekazany do oceny merytorycznej, w trakcie oceny merytorycznej I stopnia, w trakcie oceny merytorycznej II stopnia, odrzucony po ocenie formalnej, odrzucony po ocenie merytorycznej I stopnia, odrzucony po ocenie merytorycznej II stopnia, zatwierdzony ostatecznie (przed oznaczeniem tego statusu system wymusi wpisanie informacji o wyniku oceny liczba przyznanych punktów) przyznane dofinansowanie, złożony protest, protest rozpatrywany, przywrócony po proteście, protest odrzucony; WF.12.5.1 WF.12.6 Pełna lista statusów zostanie ustalona na etapie analizy. W ramach każdego statusu Wniosku o dofinansowanie Urzędnik będzie musiał podać powód nadania statusu. Będzie mógł również dodać załącznik w postaci pliku. W ramach każdego wniosku będzie można wygenerować: umowę o dofinansowanie, aneks do umowy o dofinansowanie, formularz oceny formalnej, formularz oceny merytorycznej I stopnia, formularz oceny merytorycznej II stopnia.

Kod Powyższe dokumenty generowane są w oparciu o zdefiniowane w Systemie dziedzinowym szablony (WF.19). Dokumenty będą generowane w postaci plików DOC i PDF. WF.12.7 WF.12.8 WF.12.9 W ramach każdego wniosku Urzędnik będzie mógł przeglądać i pobierać załączniki dołączone do wniosku. Nie ma możliwości usunięcia załączników dodanych przez Komponent epuap. W ramach każdego wniosku Urzędnik będzie mógł dodawać nowe załączniki stając się automatycznie ich właścicielem. Tylko właściciel będzie miał możliwość usunięcia załączników. Obostrzenie nie dotyczy Administratorów systemu. System dziedzinowy umożliwi Urzędnikowi oznaczenia każdego z pól wniosku flagą (znacznikiem) do poprawy. Pola zawierające podstawowe dane o Beneficjencie oraz pola oznaczone tym znacznikiem będą przekazywane do Komponentu epuap zgodnie z wymaganiem UEL.6.1.2.1. Zestaw podstawowych danych dotyczących Beneficjenta zostanie określony na etapie analizy i podlega akceptacji Zamawiającego. WF.12.10 WF.12.11 WF.12.11.1 Dodawanie załączników (WF.12.8) oraz oznaczenie pól wniosku flaga (znacznikiem) do poprawy (WF.12.9) będzie możliwe jedynie w trybie edycji wniosku. Dopiero wywołanie funkcji zapisz zatwierdzi i zapisze wprowadzone zmiany. Wywołanie funkcji anuluj spowoduje cofniecie wszystkich wprowadzonych zmian w trybie edycji. W ramach każdego wniosku będzie istniała Historia akcji. W historii będą zapisywane wszelki operacje jakie zostały wykonane w kontekście wniosku, zarówno te wykonane przez użytkownika jak i te wykonane przez Web-Service. Historia zmian będzie w postaci tabeli z następującymi kolumnami: Data, Użytkownik, Akcja, gdzie: Data data zarejestrowania zmiany,

Kod WF.12.11.2 WF.12.12 Urzędnik Raporty WF.13 WF.13.1 WF.13.2 WF.13.3 WF.13.4 Użytkownik dane użytkownika odpowiadające danym z jego konta w Systemie dziedzinowym, w przypadku zmian wynikających z aktualizacji wniosku przez Komponent epuap pole wskazuje Web- Service, jako użytkownika dokonującego zmian, Akcja jest to opis akcji w postaci: [nazwa akcji] [nazwa pola] z [poprzednia wartość] na [nowa wartość] w przypadku zmian pól lub [pobranie / dodanie / skasowanie] pliku [nazwa pliku] w przypadku operacji na załącznikach. System dziedzinowy umożliwi zapisanie (export) historii zmian w postaci pliku XML i CSV. System dziedzinowy umożliwi zapisanie (eksport) danych wniosku w postaci pliku XML, CSV, DOC, PDF. Export do pliku musi być możliwy z poziomu wniosku. Wykonawca wykona do 10 zdefiniowanych raportów. Raporty w Systemie dziedzinowym są w postaci tabelarycznej oraz graficznej (w postaci wykresów). Każdy raport musi posiadać zestaw filtrów służących do parametryzacji. Rodzaj i ilość filtrów w ramach każdego raportu zostanie ustalona na etapie analizy i podlega akceptacji Zamawiającego. System dziedzinowy umożliwia eksportowanie raportów w postaci plików CSV i XML. Raporty predefiniowane (przygotowane przez wykonawcę) nie mogą być usunięte przez Urzędnika. Urzędnik Lista rankingowa WF.14 WF.14.1 WF.14.2 System dziedzinowy tworzy Listę rankingową dla każdego Naboru. System dziedzinowy pozwala Urzędnikowi na zarządzanie Listami rankingowymi. System dziedzinowy będzie umożliwiał przeglądanie listy List rankingowych. Listę będzie można filtrować, sortować i stronicować. System dziedzinowy będzie umożliwiał zapisanie Listy rankingowej oraz export listy rankingowej do plików XML, CSV, DOC, PDF.

Kod WF.14.3 WF.14.4 WF.14.4.1 WF.14.4.2 WF.14.5 WF.14.5.1 WF.14.5.2 WF.14.5.3 WF.14.6 Każda Lista rankingowa posiada unikalną nazwę wskazującą na nabór, któremu jest przypisana. Konwencja nazewnicza zostanie opracowana na etapie analizy. Konwencja nazewnicza podlega akceptacji Zamawiającego. Lista rankingowa prezentuje informacje o kwocie alokacji dla danego naboru, kwocie przyznanego dofinansowania w ramach naboru oraz kwocie, jaka pozostała. Kwota przyznanego dofinansowanie to suma kwot wniosków oznaczonych flagą (znacznikiem) przyznane dofinansowanie (zgodnie z wymaganiem WF.14.5.3) dla wniosków złożonych w ramach danego naboru. Kwota przyznanego dofinansowania oraz kwota pozostała prezentowane są dynamicznie. Oznacza to, iż przy każdej zmianie flagi przyznane dofinansowanie dla dowolnego (każdego) wniosku na Liście kwota przyznanego dofinansowania oraz kwota pozostała zostanę ponownie wyliczone. Lista rankingowa prezentuje wszystkie wnioski o dofinansowanie dla danego naboru w statusie zatwierdzony ostatecznie. Każdy wniosek o dofinansowanie, któremu nadano status zatwierdzony ostatecznie automatycznie pojawia się na odpowiedniej Liście rankingowej. Listę rankingową można odświeżyć. W ramach odświeżenia System dziedzinowy zweryfikuje czy wszystkie wnioski znajdujące się na liście mają status zatwierdzony ostatecznie i jeśli nie to takie wnioski zostaną z listy usunięte. Każdy wiersz Listy odpowiada jednemu wnioskowi i prezentuje identyfikator wniosku (zgodnie z wymaganiem WF.12), ocenę czyli liczbę przyznanych punktów, kwotę dofinansowania oraz pole wyboru (ang. checkbox) flagi (znacznika) przyznane dofinansowani. Zaznaczenie pola wyboru jest równoznaczne z ustawieniem flagi (znacznika) przyznane dofinansowanie danemu wnioskowi o dofinansowanie. Wybranie dowolnego wniosku z listy spowoduje wyświetlenie szczegółów danego wniosku.

Kod WF.14.7 WF.14.8 WF.14.9 WF.14.9.1 WF.14.9.2 WF.14.9.3 WF.14.9.4 Wnioski znajdujące się na liście rankingowej sortowane są względem oceny liczba przyznanych punktów danego wniosku. Pierwsza pozycję na liście zajmuje wniosek o największej liczbie punktów. Lista jest odświeżana (sortowana) każdorazowo w przypadku pojawienia się nowego wniosku na liście. System dziedzinowy będzie umożliwiał korygowanie Listy rankingowej. Funkcja koryguj będzie obejmowała wszystkie wnioski oznaczone flagą (znacznikiem) przyznane dofinansowanie. Wywołanie funkcji koryguj da Urzędnikowi możliwość wyboru jednego z trzech sposobów dokonania korekty. koryguj ostatni, koryguj wszystkie, koryguj ręcznie; W ramach funkcjonalności koryguj ostatni System dziedzinowy zmniejszy kwotę ostatniego wniosku na Liście rankingowej tak, aby suma kwot wniosków o dofinansowanie znajdujących się na Liście rankingowej oznaczonych flagą (znacznikiem) przyznane dofinansowanie była równa kwocie alokacji danego naboru. Jeśli kwota ostatniego wniosku na Liście rankingowej jest mniejsza niż różnica pomiędzy sumą kwot wniosków o dofinansowanie znajdujących się na Liście rankingowej oznaczonych flagą (znacznikiem) przyznane dofinansowanie a kwota alokacji danego naboru to przy próbie uruchomienia funkcjonalności koryguj ostatni System dziedzinowy poinformuje Urzędnika o takim stanie, stosownym komunikatem. W ramach funkcjonalności koryguj wszystkie System dziedzinowy zmniejszy proporcjonalnie kwotę wszystkich wniosków na Liście rankingowej tak aby suma kwot wniosków o dofinansowanie znajdujących się na Liście rankingowej oznaczonych flagą (znacznikiem) przyznane dofinansowanie była równa kwocie alokacji danego naboru. Zmniejszenie nastąpi zgodnie z algorytmem: kwota pozostała podzielona przez ilość wniosków z Listy rankingowej oznaczonych flagą przyznane dofinansowanie. Kwota otrzymana w wyniku tej

Kod operacji zostanie odjęta od kwoty każdego wniosku o dofinansowanie. WF.14.9.5 WF.14.10 WF.14.10.1 W ramach funkcjonalności koryguj ręcznie System dziedzinowy umożliwi Urzędnikowi edytowanie kwot wniosków z poziomu Listy rankingowej. Zapisanie Listy rankingowej spowoduje, iż wszystkim wnioskom z Listy rankingowej oznaczonym flagą (znacznikiem) przyznane dofinansowanie zostanie automatycznie nadany status przyznane dofinansowanie oraz kwoty wniosków o dofinansowanie zmienione w ramach korygowania (WF.14.9) Listy rankingowej zostaną zapisane we wnioskach. Wnioski nie oznaczone flagą (znacznikiem) przyznane dofinansowanie zostanę przeniesione z Listy rankingowej na Listę rezerwową (WF.15) Urzędnik Lista rezerwowa WF.15 WF.15.1 WF.15.2 WF.15.3 WF.15.4 WF.15.5 System dziedzinowy tworzy Listę rezerwową jeśli podczas zapisu Listy rankingowej na liście znajdują się wnioski o dofinansowanie nie oznaczone flagą (znacznikiem) przyznane dofinansowanie i nie mają statusu wniosku przyznane dofinansowanie. System dziedzinowy pozwala Urzędnikowi na zarządzanie Listami rezerwowymi. System dziedzinowy będzie umożliwiał przeglądanie listy List rezerwowych. Listę będzie można filtrować, sortować i stronicować. System dziedzinowy będzie umożliwiał zapisanie Listy rezerwowej oraz export listy rankingowej do plików XML, CSV, DOC, PDF. Każda Lista rezerwowa posiada unikalną nazwę wskazującą na nabór, któremu jest przypisana. Konwencja nazewnicza zostanie opracowana na etapie analizy. Konwencja nazewnicza podlega akceptacji Zamawiającego. Lista rezerwowa prezentuje informacje o kwocie alokacji dla danego suplementu, kwocie przyznanego dofinansowania w ramach suplementu oraz kwocie, jaka pozostała.

Kod WF.15.5.1 WF.15.6 WF.15.6.1 WF.15.7 WF.15.8 WF.15.9 WF.15.9.1 WF.15.10 WF.15.10.1 WF.15.10.2 Kwota przyznanego dofinansowanie to suma kwot wniosków oznaczonych flagą (znacznikiem) przyznane dofinansowanie (WF.15.6.1 oraz WF.14.5.2) dla wniosków złożonych w ramach danego naboru. Każdy wiersz Listy rezerwowej odpowiada jednemu wnioskowi i prezentuje identyfikator wniosku (zgodnie z wymaganiem WF.12), ocenę czyli liczbę przyznanych punktów, kwotę dofinansowania oraz pole wyboru (ang. checkbox) flagi (znacznika) przyznane dofinansowani. Zaznaczenie pola wyboru jest równoznaczne z ustawieniem flagi (znacznika) przyznane dofinansowanie danemu wnioskowi o dofinansowanie. Wybranie dowolnego wniosku z listy spowoduje wyświetlenie szczegółów danego wniosku. Wnioski znajdujące się na liście rezerwowej sortowane są względem oceny liczba przyznanych punktów danego wniosku. Pierwsza pozycję na liście zajmuje wniosek o największej liczbie punktów. Lista rezerwowa prezentuje tylko wnioski o dofinansowanie w statusie zatwierdzony ostatecznie. Listę rezerwową można odświeżyć. W ramach odświeżenia System dziedzinowy zweryfikuje czy wszystkie wnioski znajdujące się na liście mają status zatwierdzony ostatecznie i jeśli nie to takie wnioski zostaną z listy usunięte. System dziedzinowy będzie umożliwiał korygowanie Listy rezerwowej. Funkcja koryguj będzie obejmowała wszystkie wnioski oznaczone flagą (znacznikiem) przyznane dofinansowanie. Wywołanie funkcji koryguj da Urzędnikowi możliwość wyboru jednego z trzech sposobów dokonania korekty. koryguj ostatni, koryguj wszystkie, koryguj ręcznie; W ramach funkcjonalności koryguj ostatni System dziedzinowy zmniejszy kwotę ostatniego wniosku na Liście rezerwowej tak aby suma kwot wniosków o dofinansowanie znajdujących się na Liście

Kod rezerwowej oznaczonych flagą (znacznikiem) przyznane dofinansowanie była równa kwocie alokacji danego naboru. WF.15.10.3 WF.15.10.4 Jeśli kwota ostatniego wniosku na Liście rezerwowej jest mniejsza niż różnica pomiędzy sumą kwot wniosków o dofinansowanie znajdujących się na Liście rezerwowej oznaczonych flagą (znacznikiem) przyznane dofinansowanie a kwota alokacji danego naboru to przy próbie uruchomienia funkcjonalności koryguj ostatni System dziedzinowy poinformuje Urzędnika o takim stanie, stosownym komunikatem. W ramach funkcjonalności koryguj wszystkie System dziedzinowy zmniejszy proporcjonalnie kwotę wszystkich wniosków na Liście rezerwowej tak aby suma kwot wniosków o dofinansowanie znajdujących się na Liście rezerwowej oznaczonych flagą (znacznikiem) przyznane dofinansowanie była równa kwocie alokacji danego naboru. Zmniejszenie nastąpi zgodnie z algorytmem: kwota pozostała podzielona przez ilość wniosków z Listy rezerwowej oznaczonych flagą przyznane dofinansowanie. Kwota otrzymana w wyniku tej operacji zostanie odjęta od kwoty każdego wniosku o dofinansowanie. WF.15.10.5 WF.15.11 WF.15.11.1 W ramach funkcjonalności koryguj ręcznie System dziedzinowy umożliwi Urzędnikowi edytowanie kwot wniosków z poziomu Listy rezerwowej. Zapisanie Listy rezerwowej spowoduje, iż wszystkim wnioskom z Listy rezerwowej oznaczonym flagą (znacznikiem) przyznane dofinansowanie zostanie automatycznie nadany status przyznane dofinansowanie oraz kwoty wniosków o dofinansowanie zmienione w ramach korygowania (WF.15.10) Listy rankingowej zostaną zapisane we wnioskach. Wnioski nie oznaczone flagą (znacznikiem) przyznane dofinansowanie zostanę przeniesione z Listy rezerwowej na nową Listę rezerwową przypisaną do naboru. Panel Administratora WF.16 System dziedzinowy będzie posiadał panel Administratora, w

Kod ramach, którego Administrator Systemu będzie mógł zarządzać rejestrem użytkowników systemu dziedzinowego, szablonami umów i wiadomości e-mail, raportami, ustawieniami systemu (np. konfiguracja serwera e-mail), logiem systemowym. Dostarczenie serwera e-mail nie jest w zakresie niniejszego zamówienia. Administrator Lokalny będzie mógł zarządzać jedynie rejestrem użytkowników własnej organizacji. WF.17 System dziedzinowy będzie umożliwiał Administratorowi Systemu wykonanie operacji CRUD (ang. create, read, update and delete) tj. utwórz, odczytaj, aktualizuj i usuń dla każdego elementu w Systemie dziedzinowym. Administrator Lokalny / Systemu Rejestr Użytkowników WF.18 System dziedzinowy pozwala Administratorowi Lokalnemu i Administratorowi Systemu na zarządzanie Rejestrem Użytkowników. W rejestrze użytkowników przechowywane będą informacje o wszystkich aktywnych i nieaktywnych użytkownikach (Administratorach i Urzędnikach). W szczególności w kontekście użytkownika przechowywane będą następujące atrybuty: login, hasło (zaszyfrowane), adres e-mail, Imię i Nazwisko, Organizacja, Dodatkowe informacje; Administrator Lokalny może zrządzać użytkownikami, którzy należą do tej samej Organizacji, co Administrator Lokalny. Administrator Systemu może zarządzać wszystkimi użytkownikami Systemu dziedzinowego. WF.18.1 System dziedzinowy umożliwia Administratorowi Lokalnemu utworzenie nowego użytkownika w ramach jednej (swojej) organizacji. Ograniczenie nie dotyczy Administratora Systemu. Konto nowo utworzonego użytkownika (Administratora Lokalnego

Kod lub Urzędnika) jest w statusie nieaktywne. WF.18.1.1 Nowy użytkownik dodany do Systemu dziedzinowego pozostaje nieaktywny, do momentu aktywacji konta przez link aktywacyjny otrzymany na adres e-mail. WF.18.2 System dziedzinowy umożliwia Administratorowi Lokalnemu / Systemu zmianę konta aktywnego użytkownika na nieaktywne. W przypadku takiej zamiany użytkownik otrzyma e-mail z informacją o zmianie konta na nieaktywne. Użytkownik z nieaktywnym kontem nie będzie miał możliwości zalogowania się do Systemu dziedzinowego oraz nie będzie mógł skorzystać z funkcji przypominania hasła. W przypadku próby odzyskania hasła otrzyma e-mail z informacją, iż konto jest nieaktywne i należy się skontaktować z Administratorem. WF.18.3 System dziedzinowy umożliwia Administratorowi Lokalnemu wykonanie resetu hasła użytkownikowi z tej samej organizacji, co Administrator Lokalny. Ograniczenie nie dotyczy Administratora Systemu. Zresetowanie hasła spowoduje wysłanie tymczasowego hasła na adres e-mail użytkownika wraz z wymuszeniem zmiany tego hasła przy pierwszym logowaniu po zresetowaniu. Administrator Systemu Zarządzanie szablonami dokumentów WF.19 WF.19.1 WF.19.2 WF.19.3 WF.19.4 System dziedzinowy będzie umożliwiał Administratorowi Systemu na zarządzanie szablonami dokumentów wskazanych w wymaganiu WF.12.6 oraz zarządzanie szablonami wiadomości e-mail. W ramach niniejszego zamówienia Wykonawca wykona szablony dokumentów wskazanych w niniejszym dokumencie. System dziedzinowy będzie umożliwiał Administratorowi Systemu na dodawanie, edytowanie i usuwanie szablonów dokumentów. System dziedzinowy będzie umożliwiał Administratorowi Systemu podgląd szablonu oraz możliwość zapisu pustego szablonu do pliku DOC i PDF. System dziedzinowy będzie umożliwiał Administratorowi Systemu definiowanie etykiet (ang. token) dla pól szablonu. W momencie generowania dokumentu, pola oznaczone tokenami zostaną

Kod wypełnione danymi z wniosku, dla którego dany szablon jest generowany. Administrator Systemu Zarządzanie Raportami WF.20 WF.20.1 WF.20.1.1 WF.20.2 WF.20.2.1 WF.20.2.2 WF.20.2.3 System dziedzinowy umożliwia Administratorowi Systemu na zarządzanie raportami. System dziedzinowy umożliwia Administratorowi Systemu umożliwia przeglądanie raportów w formie listy. Listę będzie można filtrować, stronicować i sortować. Wybranie dowolnego raportu z listy spowoduje wyświetlenie szczegółów danego raportu. W szczególności daty utworzenia raportu, autora raportu, daty ostatniej modyfikacji, treść zapytania SQL, dodatkowe informacje. System dziedzinowy umożliwia Administratorowi Systemu tworzenie, edytowanie i usuwanie raportów. Nowe raporty można budować w oparciu o dane znajdujące się w Systemie dziedzinowym. Każdy utworzony raport zawiera informacje o dacie utworzenia, autorze raportu na podstawie danych konta użytkownika oraz opis raportu. Opis raportu jest wymagany do zapisana raportu. Raporty predefiniowane (przygotowane przez Wykonawcę) nie mogą być usunięte ani nadpisane/aktualizowane przez edycję. Przy próbie zapisu po edycji takiego raportu istnieje tylko możliwość zapisu pod postacią nowego raportu. System dziedzinowy umożliwia Administratorowi Systemu stworzenie nowego raportu w oparciu w zapytanie SQL lub edytowanie zapytań SQL już istniejących raportów. Log systemowy, WF.21 WF.21.1 Wszystkie działania Systemu dziedzinowego na danych w tym wszystkie działania Urzędnika, Administratora Lokalnego i Administratora Systemu są składowane w logu systemowym Systemu dziedzinowego, do którego ma dostęp tylko Administrator Systemu dziedzinowego. Log systemowy zawiera wszystkie dane techniczne pracy Systemu

Kod dziedzinowego, a w szczególności: 1. datę i czas działania na danych, 2. zakres działania na danych, 3. precyzyjne oznaczenie użytkownika lub systemu dokonującego działania na danych, 4. wszystkie inne informacje zapewniające pełną rozliczalność (integralność i niezaprzeczalność) pracy systemu. WF.21.2 WF.21.3 Log systemowy musi zapewnić realizację wymagań Ustawy o ochronie danych osobowych. W szczególności oznacza to poziom bezpieczeństwa zapewniający możliwość użycia logu systemowego, jako dowodu w przypadku sporów sądowych (log musi być integralny). Log systemowy jest dostępny tylko Administratorowi Systemu z poziomu GUI Systemu dziedzinowego w Panelu Administratora i może być przeglądany (w trybie tylko do odczytu. System dziedzinowy umożliwia Administratorowi Systemu pobranie logu zdarzeń w formacie XML i CSV. Wykonawca w uzgodnieniu z Zamawiającym przedstawi strukturę i zawartość logu zdarzeń. 5.4. Wymagania pozafunkcjonalne 5.4.1. Ergonomia systemu Kod WP.ERG.1 WP.ERG.2 Wykonawca przygotuje statyczne makiety interfejsu użytkownika zapisane w postaci plików PNG. Makiety podlegają akceptacji Zamawiającego. Wykonawca przygotuje projekt graficzny interfejsu użytkownika w wersji domyślnej i w wersji wysokokontrastowej. Projekt graficzny będzie zgodny z Web Content Accessibility Guidelines (WCAG 2.0) z uwzględnieniem co najmniej poziomu AA. Zamawiający może zweryfikować system pod kątem spełniania wymogów WCAG także z wykorzystaniem audytu zewnętrznego. WP.ERG.3 Wykonawca przygotuję księgę komunikatów Systemu dziedzinowego,

zawierającą w szczególności: a. Rodzaje komunikatów (typ, opis, typowe zastosowania, ikona). b. Prototyp układ komunikatu. c. Sposoby wyświetlania komunikatów, w tym: a. podział komunikatów ze względu na lokalizację na stronie: komunikaty modalne, komunikaty nagłówkowe, komunikaty w treści. b. podział komunikatów ze względu na przekazywaną informację: komunikaty błędów, potwierdzenia, informacje o sukcesie, informacje inne (np. neutralna, oczekiwanie na działanie), d. Opis konstrukcji i miejsca wyświetlania w systemie komunikatów, e. Prototypy, przyciski i ikony dla komunikatów, f. Treść komunikatów. Księga monitów podlega akceptacji Zamawiającego. 5.4.2. Architektura systemu Wymaganie WP.A.1 WP.A.2 WP.A.3 System dziedzinowy musi działać w architekturze wielowarstwowej. Oprogramowanie aplikacyjne ma być wykonane w architekturze opartej na usługi (SOA ang. Service-Oriented Architecture). Wszystkie interfejsy zewnętrzne systemu (w tym komunikacja z Komponentem epuap), muszą zostać zrealizowane jako WebServices. 5.4.3. Bezpieczeństwo Wymaganie WP.B.1 WP.B.2 System dziedzinowy musi zapewniać ochronę poufności i integralności przesyłanych informacji pomiędzy współpracującymi komponentami. System dziedzinowy musi zapewniać ochronę poufności i integralności przesyłanych informacji zarówno pomiędzy współpracującymi komponentami, które się na niego składają, jak i Komponentem epuap.

WP.B.3 WP.B.4 WP.B.5 WP.B.6 WP.B.7 WP.B.8 WP.B.9 WP.B.10 System dziedzinowy musi posiadać swoją bazę autoryzacji. Komunikacja w zakresie uwierzytelnienia między przeglądarką WWW użytkownika korzystającego z Systemu Dziedzinowego, a infrastrukturą serwerową musi odbywać się z wykorzystaniem protokołu SSL. System dziedzinowy musi zapewnić automatyczne wylogowanie użytkownika po upływie zdefiniowanego (parametr konfiguracyjny) czasu pracy. System dziedzinowy musi wymuszać by hasła były zgodne z rozporządzeniem MSWIA z dnia 29 kwietnia 2014 (Dz. U. z 2004 r. Nr 100, poz. 1024) hasło składa się co najmniej z 8 znaków, zawiera małe i wielkie litery oraz cyfry lub znaki specjalne. System dziedzinowy musi wymuszać zmianę hasła co 30 dni. Nowe hasło nie może być takie same jak hasło poprzednie. Hasła w bazie danych będą przechowywane w postaci hashowanej z wykorzystaniem mechanizmu soli (salt) - np. bcrypt. Do rozważenia dodanie mechanizmu pieprzu - pepper. System dziedzinowy powinien zapewniać bezpieczeństwo przechowywanych danych i być wykonany z naciskiem na odporność na najczęstsze typy ataków (np. SQL Injection). System dziedzinowy powinien zablokować czasowo dostęp do konta (30 minut) po 5 nieudanych próbach zalogowania oraz wyświetlić odpowiedni komunikat. Administrator Systemu musi mieć możliwość zdjęcia blokady. 5.4.4. Wydajność, pojemność i dostępność systemu Wymaganie WP.W.1 Wydajność Systemu dziedzinowego: zapewnia obsługę bieżących, ustabilizowanych potrzeb produkcyjnych systemu (obsługa użytkowników, obsługa usług wspólnych i infrastrukturalnych, procesów własnych systemu), uwzględnia potencjalne przejściowe wzrosty obciążenia związane z przejściowymi wzrostami aktywności użytkowników. Wymaganie to powinno być spełnione zarówno dla całego Systemu

dziedzinowego, jak i dla każdego z komponentów oddzielnie. WP.W.2 System dziedzinowy, musi obsłużyć: 1. 1000 wniosków rocznie (wniosek wraz z załącznikami binarnymi nie przekroczy objętości 3,5 MB, przy czym dla każdego wniosku system generuje także odpowiedź), 2. konieczności przechowywania wszystkich dokumentów dotyczących danego wniosku do 10 lata licząc od daty złożenia wniosku. WP.W.3 WP.W.4 WP.W.5 System dziedzinowy pracuje w reżimie 24 godzinnym przez 365 dni w roku. Jako wyjściowy parametr niezawodnościowy zakłada się, że potrzebna i wystarczająca dostępność systemu (SLA) wynosi 99 % w skali miesiąca tzn. łączny czas awarii w ciągu miesiąca wynosi do ok. 7 godzin (nie wlicza się tutaj planowych przerw na okna serwisowe). Dostępność poszczególnych komponentów oprogramowania aplikacyjnego Systemu dziedzinowego powinna być na tyle wysoka, by zapewnić poziom 99 % dla całego Systemu dziedzinowego. System Dziedzinowy ma zapewnić wydajność umożliwiającą równoległe przyjęcie i zarejestrowanie do 40 wniosków o dofinansowanie przesłanych do Systemu Dziedzinowego jednocześnie. Należy założyć, że każdy wniosek zawiera maksymalny rozmiar wszystkich załączników oraz pełny zestaw danych formularza. Rozmiar przesyłanego pliku (wniosek lub aktualizacja wniosku o dofinansowanie) nie może być większy niż 3,5 MB. Czas wczytania dowolnej strony Systemu Dziedzinowego przez przeglądarkę Aktora nie może być dłuższy niż 3 sekund. 5.4.5. Wymagania prawne Wykonany i dostarczony przez Wykonawcę System dziedzinowy musi zapewnić zgodność z wymaganiami prawnymi: Wymaganie WPR.1 Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2013, poz. 235).

WPR.2 WPR.3 WPR.4 WPR.5 WPR.6 WPR.7 WPR.8 WPR.9 WPR.10 WPR.11 Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. z 2011, Nr 206, poz. 1216) Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U z 2012, poz. 526) Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania.(dz.u. z 2005, Nr 217, poz. 1836) Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz.U. z 2013, poz. 267) Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym. (Dz.U. z 2013, poz. 262) Rozporządzenie Rady Ministrów w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego (Dz.U. z 2002 r. Nr 128, poz.1094) Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. z 2002 r, Nr 144, poz. 1204 z późn. zm.). Ustawa z dnia 10 grudnia 2003 r. o czasie urzędowym na obszarze Rzeczypospolitej Polskiej (Dz.U. z 2004 r. Nr 16, poz. 144). Ustawa z 6 września 2001 r. o dostępie do informacji publicznej (Dz.U. z 2001 nr 112 poz. 1198 z późn. zm.). Ustawa z dnia 23 kwietnia 1964 r. Kodeks cywilny (Dz.U. z 1964 Nr 16, poz. 93).

WPR.12 WPR.13 Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. z 2002, Nr 101, poz. 926 z późn. zm.). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 Nr 100, poz.1024). 5.4.6. Ograniczenia i zależności Wymaganie WO.1 WO.2 WO.3 Wykonawca musi przenieść na Zamawiającego majątkowe prawa autorskie na polach eksploatacji wymienionych w Umowie do wszelkich produktów wytworzonych w ramach niniejszego zamówienia, w szczególności do Systemu dziedzinowego oraz jego Modyfikacji. Minimalne wersje przeglądarek internetowych, pozwalających na realizację wszystkich wymagań wobec Systemu dziedzinowego, to: Mozilla Firefox w wersji 28.x i nowszych, Internet Explorer w wersji 9.0 i nowszych, Opera w wersji 25.x i nowszych, Google Chrome w wersji 34.x i nowszych. Wszystkie wymagania funkcjonalne i pozafunkcjonalne muszą być w pełni realizowalne na w/w typach przeglądarek internetowych oraz w ramach tych przeglądarek i ich najnowszych, stabilnych wersji wydawanych na 7 dni przed odbiorem Systemu dziedzinowego. Wszelkie prace związane z instalacją, konfiguracja i wdrożeniem LSI muszą odbyć się w sposób niezakłócający ciągłości działania systemu epuap.

5.4.7. Wymagania w zakresie dokumentacji Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji przedmiotu zamówienia charakteryzowały się wysoką jakością i spełniały poniższe wymagania: Kod DOK.1 DOK.2 DOK.2.1 DOK.2.2 Wykonawca musi dokonać analizy wymagań zawartych w opisie przedmiotu zamówienia i na jej podstawie opracować Dokumentację projektową i Dokumentację powykonawczą, które przedstawi do akceptacji Zamawiającego. Zamawiający wymaga, aby Wykonawca przygotował zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania następujące rodzaje Dokumentacji projektowej bezpośrednio związane z przedmiotem zamówienia: a. Dokumentacja analityczna. b. Dokumentacja techniczna. c. Plan Testów Akceptacyjnych. d. Plan Wdrożenia Systemu. e. Opis Realizacji Szkoleń. Dokumentacja analityczna zawiera co najmniej następujące elementy: a. Analiza wymagań funkcjonalnych. b. Analiza wymagań pozafunkcjonalnych. c. Biznesowa koncepcja rozwiązania, w tym: aktorzy, model procesów, reguły biznesowe, logiczny model danych, cykl życia danych, integracja z innymi systemami. d. Model przypadków użycia, w tym: macierz pokrycia wymagań przez przypadki użycia. e. Produkty ergonomii Systemu Dziedzinowego o których mowa w punkcie 5.4.1 f. Inne ograniczenia, założenia i zależności Systemu dziedzinowego. Dokumentacja techniczna zawiera co najmniej następujące elementy: a. Techniczna koncepcja rozwiązania, w tym: architektura techniczna, technologia wykonania podsystemów, architektura logiczna podsystemów, fizyczny model danych. b. Opis zagadnień bezpieczeństwa rozwiązania. c. Opis i specyfikacja interfejsów: interfejsy Systemu dziedzinowego, interfejsy dostarczane przez inne systemy. d. Wykorzystane Oprogramowanie standardowe (lista

Kod oprogramowania wraz z opisem przeznaczenia do wykorzystania). e. Wykorzystane Oprogramowanie aplikacyjne (lista oprogramowania wraz z opisem przeznaczenia do wykorzystania). f. Opis wymagań sprzętowych i programowych Oprogramowania standardowego i Oprogramowania aplikacyjnego. g. Wymiarowanie infrastruktury sprzętowej, h. Diagram wdrożenia opisujący konfigurację węzłów systemu (jaki sprzęt w danym węźle, jakie oprogramowanie na nim zainstalowano, jakich interfejsów i protokołów używa do komunikacji z innymi węzłami systemu, w jakiej znajduje się strefie sieciowej). DOK.2.3 DOK.2.4 Z Dokumentacji technicznej jednoznacznie wynika sposób działania Oprogramowania aplikacyjnego zarówno w skali globalnej, jak i sposób funkcjonowania poszczególnych jego komponentów oraz opis sposobu komunikacji pomiędzy poszczególnymi komponentami. Wykonawca uwzględni w dokumentacji technicznej infrastrukturę sprzętową, posiadaną przez Zamawiającego. Na podstawia analizy infrastruktury technicznej Zamawiającego, Wykonawca określi możliwość wykorzystania tej infrastruktury w części lub w całości na potrzeby niniejszego zamówienia. Plan Testów Akceptacyjnych zawierający co najmniej następujące elementy: a. Strategia testów akceptacyjnych: i. założenia do przeprowadzenia testów: warunki przeprowadzenia testów, rodzaje testów akceptacyjnych, kryteria akceptacji produktów, ii. organizacja testów: zasoby osobowe i organizacyjne, procedury testowe, klasyfikacja błędów, iii. środowisko testowe: architektura logiczna środowiska testowego, zainstalowane oprogramowanie, stanowiska testowe, konfiguracja sieciowa, dane testowe, iv. harmonogram testów, v. rodzaje testów: wewnętrzne, scenariuszowe, automatyczne, integracyjne, swobodne, regresji, pozafunkcjonalne, bezpieczeństwa, wydajności, weryfikacja i odbiór kodu źródłowego, testy niezawodnościowe i dostępności, b. Plan testów:

Kod DOK.3 DOK.4 DOK.5 i. sekwencja realizacji testów, ii. przypadki testowe, iii. dane testowe, iv. scenariusze testowe: specyfikacja scenariuszy testowych, mapowanie wymagań na model funkcjonalny, mapowanie modelu funkcjonalnego na scenariusze testowe. c. Raport z testów. Zamawiający wymaga, aby Wykonawca w ramach Dokumentacji powykonawczej, zaktualizował zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania - Dokumentację projektową, po wdrożeniu Systemu dziedzinowego. Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji umowy charakteryzowały się wysoką jakością, na którą będą miały wpływ, takie czynniki jak: a. Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób, b. Zachowanie standardów, w tym notacji UML, a także sposób pisania, rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu, c. Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia, d. Spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu. Zamawiający wymaga, aby cała dokumentacja, o której mowa powyżej, podlegała jego akceptacji, a także, aby została dostarczona w języku polskim, w wersji elektronicznej w niezabezpieczonym/edytowalnym formacie Word, PDF oraz HTML (na płycie CD-ROM lub innym równoważnym nośniku danych) i drukowanej 1 egzemplarz. Diagramy UML sporządzone za pomocą narzędzi CASE powinny być dostarczone w formacie EAP. Dostarczone wykresy Gantta powinny być dostarczone w formacie MPP lub w formacie XLS umożliwiającym import do MS

Kod Project (dopuszcza się inne formaty zapisu dokumentacji, Wykonawca wówczas zobowiązany jest dostarczyć Zamawiającemu oprogramowanie, które umożliwia co najmniej przeglądanie wykorzystanych formatów). DOK.6 Do Dokumentacji oraz jej modyfikacji w ramach RfC zostaną przeniesione przez Wykonawcę majątkowe prawa autorskie na polach eksploatacji określonych w umowie. 5.4.8. Wymagania w zakresie odbioru produktów Wymaganie OD.01 OD.03 Wszystkie dostarczone w ramach Umowy produkty i świadczone usługi będą podlegały procedurom w zakresie testów akceptacyjnych, odbioru ilościowego i jakościowego. Do protokołu odbioru końcowego dołączone będą: wykaz oprogramowania wraz z rodzajem i liczbą, dokumentacja projektowa i powykonawcza wraz z niezbędnymi instrukcjami, zgodnie z wymaganiami Zamawiającego, wyniki przeprowadzonych testów, protokoły odbioru poszczególnych etapów. OD.05 OD.05.01 OD.05.02 OD.05.03 O gotowości do przekazania każdego z etapów przedmiotu zamówienia do odbioru Wykonawca powiadomi Zamawiającego (Kierownika Umowy) na co najmniej 3 dni robocze przed jego przekazaniem, przesyłając informację pisemnie, faksem lub pocztą e-mail. Zamawiający przeprowadzi procedurę odbiorczą i przyjmie przedstawiony przedmiot zamówienia albo zgłosi ewentualne uwagi lub zastrzeżenia najpóźniej w terminie do 15 dni roboczych od dnia zgłoszenia przez Wykonawcę gotowości do przekazania przedmiotu zamówienia. Wykonawca uwzględni wszystkie uwagi Zamawiającego do przedmiotu zamówienia najpóźniej w terminie do 5 dni roboczych. Wszystkie czynności związane z dokonaniem odbioru muszą zakończyć

się w terminie wykonania etapu i Umowy. OD.05.04 OD.06 Wykonawca musi przedstawić szczegółowy harmonogram odbiorów każdego z produktów Umowy, tak aby zapewnić odpowiedni czas Zamawiającemu na weryfikację produktu. Zamawiający wymaga, aby Wykonawca przygotował Plan Testów Akceptacyjnych, podlegający zaakceptowaniu przez Zamawiającego zgodnego z szablonem PTA, stanowiącym załącznik do Umowy. Zamawiający zastrzega sobie prawo do rezygnacji z części zapisów zawartych w PTA, dotyczących rodzaju testów. OD.07 Plan Testów Akceptacyjnych musi zostać przygotowany z uwzględnieniem: opisu sposobu organizacji testów, opisu przypadków testowych oraz kryteriów akceptacji, scenariuszy testowych uwzględniających przebieg podstawowy dla usługi i przebiegi alternatywne. OD.08 Przed przeprowadzeniem testów integracyjnych i akceptacyjnych Wykonawca przeprowadzi testy wewnętrzne i przekaże Zamawiającemu raport z testów wewnętrznych zawierający także opis metody przeprowadzenia testów wewnętrznych. Zamawiający zastrzega sobie prawo do udziału w prowadzonych przez Wykonawcę testach wewnętrznych. OD.09 OD.10 Zamawiający przeprowadzi na podstawie dostarczonych przez Wykonawcę narzędzi testy integracyjne, bezpieczeństwa, wydajności oraz testy akceptacyjne z udziałem Wykonawcy. Warunki ogólne niezbędne do przeprowadzenia testów każdego typu, to m.in.: 1. Warunki rozpoczęcia pierwszej iteracji testów zaakceptowana dokumentacja testowa, zaakceptowany harmonogram testów, przeprowadzone testy wewnętrzne Wykonawcy i przekazany Zamawiającemu raport z testów wewnętrznych. 2. Warunki rozpoczęcia kolejnych iteracji testów Naprawione błędy wykryte podczas poprzedniej iteracji, Modyfikacja dokumentacji testowej w zakresie wynikającym z poprzedniej iteracji testów

5.5. Wymagania w zakresie szkolenia Poniższa tabela przedstawia minimalne wymagania wobec Wykonawcy związane ze szkoleniem: Wymaganie EDU.1 Wykonawca przeprowadzi maksymalnie dwudniowe szkolenie w języku polskim dla maksymalnie 10 (dziesięciu) trenerów Zamawiającego. Celem szkolenia jest przygotowanie trenerów Zamawiającego do prowadzenia szkoleń wewnętrznych z zakresu funkcjonalności Systemu LSI. EDU.2 EDU.3 Zamawiający zastrzega możliwość przeprowadzenia dwóch szkoleń trwających maksymalnie 2 dni dla maksymalnie 5 pracowników na każdym ze szkoleń. Zakres szkolenia obejmować będzie obsługę Systemu dziedzinowego przez pracowników Zamawiającego, o których mowa w sekcji 5.3. Wymagania funkcjonalne LSI. Wykonawca zaprezentuje proces składania wniosków o dofinansowanie w Komponencie epuap o którym mowa w sekcji 5. Wymagania w zakresie Komponentu epuap. W ramach szkolenia zostaną w szczególności zrealizowane warsztaty realizacji przez trenerów Zamawiającego w Środowisku produkcyjnym wszystkich kroków procesów wskazanych w załączniku 6.1 do OPZ wspieranych przez System dziedzinowy. EDU.4 EDU.5 EDU.6 W przypadku szkolenia dwudniowego szkolenie zostanie zrealizowane w czasie następujących po sobie dwóch dni roboczych. Szkolenie musi zostać uwzględnione w harmonogramie projektu. Każdy dzień szkolenia będzie trwał 8 godzin zegarowych. Każdy dzień szkolenia Wykonawca musi zaplanować tak, aby uwzględnić: czas na dydaktykę 6 (sześć) godzin zegarowych; jedną przerwę obiadową 1 (jedna) godzina zegarowa; cztery przerwy kawowe 15 (piętnaście) minut każda. EDU.7 Wykonawca materiały szkoleniowe w wersji elektronicznej dostarczy Zamawiającemu zapisane na przenośnej pamięci flash (lub innym równoważnym nośniku).

EDU.8 Wykonawca opracuje i przedstawi do akceptacji Zamawiającego agendę szkolenia zawierającą: cel i zakres szkolenia, metodę i formę szkolenia. EDU.9 EDU.10 EDU.11 Wykonawca zapewni prowadzenie szkolenia przez wykwalifikowaną kadrę posiadającą wiedzę teoretyczną i praktyczną z zakresu szkolenia, o którym mowa w EDU.3. Przeszkoleni trenerzy Zamawiającego otrzymają potwierdzenie ukończenia szkolenia w postaci zaświadczenia o uczestnictwie. Przeprowadzenie szkolenia zostanie potwierdzone protokołem sporządzonym w dwóch jednobrzmiących egzemplarzach, po jednym dla Zamawiającego i Wykonawcy, zawierającym: nazwę i tematykę ze szkolenia, datę i miejsce przeprowadzenia szkolenia, czas trwania szkolenia, imienną listę osób uczestniczących w szkoleniu, imię i nazwisko oraz specjalizację osób prowadzących szkolenie. EDU.12 Protokół z przeprowadzonych szkolenia podlegać będzie zatwierdzeniu przez Zamawiającego. 5.6. Wymagania w zakresie zarządzania projektem Wymaganie ZP.01 Wymaga się od Wykonawcy, aby: organizacja przedsięwzięcia związanego z przedmiotem zamówienia i jego etapów, procesy kierujące przedsięwzięciem, struktura i zawartość planów projektu, techniki zarządzania projektem, zestaw elementów sterujących zarządzaniem i jakością, w tym cała tworzona dokumentacja, były oparte o ogólnie znaną metodykę projektową (PRINCE2 albo PMBoK) lub inną zaproponowaną przez Wykonawcę i zaakceptowaną przez Zamawiającego, uwzględniającą konkretne techniki, narzędzia i notacje, a także zapewniającą osiągnięcie zamierzonych celów

jakościowych przy jednoczesnej minimalizacji możliwości niepowodzenia projektu. ZP.02 W przypadku wykorzystywania przez Wykonawcę innej metodyki zarządzania projektem niż PRINCE2 czy PMBoK wymaga się, aby uwzględniała ona co najmniej następujące elementy: sposób zarządzania projektem, w tym proces kontroli postępu prac w zakresie kosztów, pracochłonności i zgodności z harmonogramem projektu, a także częstotliwość punktów kontrolnych, raportowanie o postępach w realizacji projektu oraz sposób zarządzania problemami w realizacji projektu, proces przygotowania planu realizacji projektu i planu jakości projektu, analizę ryzyka przed rozpoczęciem projektu i zarządzanie ryzykiem w trakcie jego realizacji, politykę jakości projektu zawierającą wymagania jakościowe oraz kryteria jakości (np. związane z testowaniem), kontrolę jakości, w tym audyty wewnętrzne i zewnętrzne projektu oraz przeglądy projektu, sposób zarządzania konfiguracją, w tym identyfikacja elementów konfiguracji, kontrola wersji, informowanie uczestników projektu o zmianach, sposób zarządzania zmianami, w tym rodzaje modyfikacji (poprawki, aktualizacje, rozbudowa, udoskonalenia) oraz procedury kontroli zmian, bezpieczeństwo realizacji projektu, w tym poufność dokumenty wrażliwe, deklaracje poufności dla uczestników projektu oraz sposób rejestracji dostępu do dokumentów wrażliwych. ZP.03 ZP.04 W przypadku wykorzystywania przez Wykonawcę innej metodyki zarządzania projektem niż PRINCE2 czy PMBoK, Wykonawca jest zobowiązany dostarczyć Zamawiającemu wraz z ofertą opis metodyki w języku polskim, w wersji elektronicznej, w formacie PDF (dopuszcza się inne formaty zapisu należy jednak dołączyć przeglądarkę obsługującą wykorzystane formaty), na płycie CD-ROM lub innym równoważnym nośniku danych i drukowanej, w co najmniej 3 (trzech) egzemplarzach. W przypadku wykorzystywania przez Wykonawcę innej metodyki zarządzania projektem niż PRINCE2 czy PMBoK, Wykonawca jest zobowiązany przewidzieć w harmonogramie projektu czas (nie krótszy niż 5 dni roboczych) potrzebny Zamawiającemu na zapoznanie się

z przedstawioną metodyką. ZP.05 Wykonawca przedstawi do akceptacji Zamawiającego ustanowione i udokumentowane działania, jakie należy wykonać w celu osiągnięcia zamierzonych celów zamówienia w terminie, przy określonych kosztach, wymaganej jakości i poziomie wykonania. Wymaga się, aby działania te, podobnie jak wszystkie pozostałe zadania realizowane w niniejszym zamówieniu, zostały podzielone na etapy, które występują jeden po drugim i pozwolą lepiej sterować projektem oraz ograniczyć ryzyko niepowodzenia projektu. Ponadto wymaga się, aby dla każdego etapu Wykonawca przedstawił do akceptacji Zamawiającego udokumentowane procedury zapewniające, że: postępowanie ze wszystkimi zagadnieniami i ryzykami projektowymi, szczególnie w zakresie wprowadzanych zmian, będzie pod kontrolą, na każdym etapie realizacji przedmiotu zamówienia będą dokonywane sprawdzenia w zakresie jakości wykonywanych prac, na podstawie ustanowionych i udokumentowanych procedur sterowania i weryfikacji, w celu spełnienia postawionych wymagań, przy czym procedury sterowania i weryfikacji, w tym przyjęta metodyka prowadzenia projektu, powinny być regularnie poddawane ocenie na podstawie obiektywnych kryteriów, niniejsze postępowanie będzie prowadzone w sposób skuteczny i efektywny, a wszystkie zmiany będą przed ich wprowadzeniem zidentyfikowane, udokumentowane, poddane przeglądom i zatwierdzone przez Zamawiającego. ZP.06 ZP.07 Wykonawca przygotuje i dostarczy, w nieprzekraczalnym terminie 7 Dni Roboczych od dnia podpisania Umowy, do zatwierdzenia przez Zamawiającego Plan Zarządzania Projektem. Wzór Planu Zarządzania projektem stanowi załącznik do Umowy wzór Planu Zarządzania Projektem. Wykonawca przygotuje i dostarczy łącznie z Planem Zarządzania Projektem do zatwierdzenia przez Zamawiającego harmonogram bazowy projektu. Harmonogram bazowy projektu musi uwzględniać m.in.: Wyznaczenie prac, które będą wykonywane w ramach niniejszego zamówienia przez Wykonawcę. Wskazanie zakresu prac realizowanych w poszczególnych etapach określonych przez Zamawiającego w OPZ.

Wyznaczenie punktów kontrolnych. Zaplanowanie prac dotyczących realizacji, kontroli (Raporty ze stanu realizacji projektu) i odbioru każdego z etapów Umowy. Inne ograniczenia projektu uwzględnione w Opisie Przedmiotu Zamówienia. 5.7. Wymagania w zakresie gwarancji Wymaganie GW.01 GW.02 GW.03 GW.04 GW.05 GW.06 W trakcie trwania gwarancji Wykonawca zapewni wsparcie techniczne polegające na stałym kontakcie, w celu udzielania konsultacji Zamawiającemu lub innym osobom wskazanym przez Zamawiającego), w dni robocze w godz. 8-16. Wykonawca zapewni Elektroniczny System Zgłoszeniowy (narzędzie typu bug-tracker) do zgłaszania błędów i komunikacji na linii Zamawiający (WWPE) - Wykonawca. Narzędzie będzie uruchomione w zasobach Wykonawcy. Wykonawca zapewni przyjmowanie zgłoszeń gwarancyjnych w trybie 24/7/365 (24 godz. na dobę, 7 dni w tygodniu, 365 dni w roku); zgłoszenia mogą być dokonywane: faksem, telefonicznie, e-mailem, poprzez Elektroniczny System Zgłoszeniowy dostarczony przez Wykonawcę. Wykonawca zarejestruje wszystkie zgłoszenia w Elektronicznym Systemie Zgłoszeniowym. Szczegółowe tryby i kanały komunikacji Wykonawca uzgodni z Zamawiającym w PZP. Wykonawca zapewni czasy obsługi zgłoszeń gwarancyjnych: dla błędów kategorii A 8 godzin, dla błędów kategorii B 2 dni kalendarzowe, dla błędów kategorii C 14 dni kalendarzowe. Wykonawca zapewni aktualizacji Systemu dziedzinowego oraz jego Modyfikacji, w celu zapewnienia poprawnego funkcjonowania w kolejnych pełnych wersjach przeglądarek wskazanych w wymaganiu WO.2 W ramach gwarancji Wykonawca zapewni utrzymanie i aktualizację przygotowanych Usług elektronicznych, przez co rozumie się wprowadzanie niezbędnych zmian dowolnego elementu Usługi w celu

zapewnienia zgodności z obowiązującym stanem prawnym, a także zmianami technicznymi związanymi z rozwojem platformy epuap. Wykonawca jest zobowiązany do wprowadzenia niezbędnych zmian w zakresie utrzymania i aktualizacji Usług elektronicznych na pisemne żądanie Zamawiającego, w terminie wskazanym w żądaniu. GW.07 GW.08 GW.09 W przypadku wprowadzenia przez Wykonawcę zmian lub aktualizacji Oprogramowania Aplikacyjnego, Wykonawca każdorazowo dostarczy, niezwłocznie, jednak nie później niż w ciągu 3 Dni roboczych od dokonania aktualizacji, Zamawiającemu zaktualizowaną wersję kodów źródłowych Oprogramowania Aplikacyjnego wraz z odnoszącą się do niego Dokumentacją oraz zestawieniem wykonanych zmian. Na koniec okresu świadczenia usługi serwisu gwarancyjnego, jednak nie później niż w ciągu 3 Dni roboczych od jego zakończenia, Wykonawca dostarczy Zamawiającemu zaktualizowaną wersję kodów źródłowych Oprogramowania Aplikacyjnego wraz z odnoszącą się do niego Dokumentacją. Wykonawca nie może odmówić wykonania czynności objętych gwarancją jakości z uwagi na wysokość związanych z tym kosztów. Dokonanie zmian oprogramowania w ramach instalacji oprogramowania przez Zamawiającego lub osoby przez niego wskazanej, nie powoduje utraty gwarancji.

6 Załączniki 6.1. Uproszczony model procesów biznesowych, Rysunek 2. Złożenie wniosku o dofinansowanie.

Rysunek 3. Aktualizacja wniosku o dofinansowanie. Rysunek 4. Prezentacja i edycja danych o wniosku

Rysunek 4.1. Przeglądanie danych o wniosku. 6.2. Wzór formularza wniosku o dofinansowanie, Załącznik 6.2 Wzór Formularza.docx 6.3. Bazowe powiązania pomiędzy obiektami Systemu dziedzinowego, class Domain Model Oś Nabór 3 0..* 1..* 0..* Wniosek Lista Rankingowa 1 1 1 0..* Lista Rezerwowa

6.4. SL2014 Załącznik 6.4 - Wytyczne w zakresie warunków gromadzenia i przekazywania danych w postaci elektronicznej.pdf 6.5. EDOK, W celu integracji edok z Systemem dziedzinowym zaleca się implementację po stronie Systemu usługi udostępniającej formularze w technologii rozproszonych komponentów programowych udostępnianych za pośrednictwem protokołu SOAP (Web Services). Aby maksymalnie skrócić czas integracji pomiędzy edok i Systemem dziedzinowym pożądanym kierunkiem byłaby implementacja usługi, o której mowa wyżej w sposób maksymalnie zbliżony do usługi epuap służącej pobieraniu dokumentów ze skrytki epuap opisanej w pull.wsdl. Szczegóły tej usługi są zawarte w dokumencie udostępnianym pod adresem http://www.epuap.gov.pl/wps/wcm/connect/7018e500-a8e1-4a69-89bd- 112bc2f4af14/Instrukcja+użytkownika_Współpraca+z+systemami+zewnętrznymi_8.2.pdf?M OD=AJPERES na stronach 22 i 23.