Utrzymanie oraz modyfikacje systemu Portal Informacyjny Sądów Powszechnych

Załącznik nr 1 do Umowy Załącznik nr 1 do SWZ

Opis Przedmiotu Zamówienia

v.4

Utrzymanie oraz modyfikacje systemu Portal Informacyjny Sądów Powszechnych

Spis treści

1. Słownik pojęć 4

2. Wprowadzenie 7

3. Dokumentacja techniczna Systemu 7

4. Zobowiązania Wykonawcy 8

4.1. Zarządzanie Umową 8

4.2. Aktualizacja systemów operacyjnych 9

4.3. Przygotowanie i przeprowadzanie testów automatycznych 10

4.4. Dostosowanie REST API Systemu do standardu OpenAPI 10

4.5. Pakiety serwisowe serwerów bazodanowych 10

4.5.1. Pakiety serwisowe dla systemu operacyjnego 10

4.5.2. Pakiety serwisowe dla Urządzeń 11

4.7.

Zasady ogólne realizacji przez Wykonawcę na rzecz Zamawiającego usług związanych z

utrzymaniem Systemu 13

4.6. Pakiety serwisowe systemu bazodanowego 12

4.7.1. Zasady Instalacji nowej wersji Systemu 13

4.7.2. OOT 14

4.7.3. Inne 15

4.7.4. Rodzaje środowisk technologicznych 16

4.7.4.1. Środowisko developerskie do kompilacji kodów 17

4.7.4.2. Dostosowanie środowisk 18

4.8. Usługa wsparcia technicznego i serwisu Systemu 18

4.8.1. Zakres Usługi wsparcia technicznego i serwisu Systemu 18

4.8.1.1. Zobowiązania dodatkowe 18

4.8.1.2. Wymogi dotyczące bezpieczeństwa 22

4.8.2. Zasady realizacji Usługi wsparcia technicznego i serwisu 23

4.8.3. Rodzaje kwalifikacji Zgłoszeń oraz czas ich realizacji dla środowisk technologicznych

Zamawiającego 24

4.8.4. Procedura realizacji Zgłoszeń (Awaria, Błąd Krytyczny, Błąd Niekrytyczny, Konfiguracja,

Błąd importu danych źródłowych, Wniosek o informację) 28

4.8.5. Szczególna procedura realizacji zgłoszeń typu Błąd importu danych źródłowych w

Infrastrukturze systemowej (lokalnej) 30

4.8.6. Procedura zgłaszania Zamawiającemu konieczności zainstalowania poprawek i nowych

wersji oraz aktualizacji poszczególnych elementów Systemu dla środowisk technologicznych w

Infrastrukturze centralnej 31

4.8.7. Monitorowanie czasu dostępności Systemu 32

4.9. Usługa Modyfikacji Systemu 33

4.9.1. Zakres usługi Modyfikacje Systemu 33

4.9.2. Zasady realizacji usługi Modyfikacje Systemu 33

4.9.3. Procedura zlecania Modyfikacji 34

4.9.4. Procedura odbioru Modyfikacji 36

4.9.6. Procedura autoryzacji Modyfikacji wykonanych przez Zamawiającego lub osoby trzecie

działające w jego imieniu 39

4.9.5. Zasady tworzenia kodu źródłowego 38

4.10. Usługa realizacji szkoleń/warsztatów dla Administratorów Systemu 39

4.10.1. Zakres Usługi realizacji szkoleń/warsztatów dla Administratorów Systemu 39

4.10.2. Zgłaszanie potrzeby wykonania Usługi, kanały komunikacji 40

4.10.3. Miejsce wykonywania Usługi 40

4.10.4. Procedura realizacji Usług wraz z przygotowaniem materiałów szkoleniowych i ich odbiór 40

4.10.5. Wytyczne dotyczące realizacji Usługi 41

4.10.6. Rozliczenie usługi 43

4.11. Usługa wsparcia (UW) 43

4.12. Dokumentacja 44

4.12.1. Wymagania dotyczące Dokumentacji 44

4.12.2. Szczegółowe wymagania dotyczące poszczególnych Dokumentów 46

4.12.2.2. Dokumentacja utrzymaniowa, w tym procedury i instrukcje dla administratorów

lokalnych i centralnych oraz użytkowników końcowych 47

4.12.2.1. Dokumentacja systemowa, w tym Projekt Techniczny 46

4.12.2.3. Dokumentacja bezpieczeństwa 49

4.13. Usługa gwarancji i rękojmi 50

5. Zaplanowane Modyfikacje Systemu 50

1. Słownik pojęć

Pojęcie/skrót	Definicja
Portal Informacyjny/PI, Portal, System	System Portal Informacyjny Sądów Powszechnych
Administrator Systemu	Osoba wskazana przez Zamawiającego zajmująca się zarządzaniem Systemem i odpowiadająca za jego sprawne działanie.
Administrator Lokalny Systemu	Pracownik Użytkownika końcowego administrujący systemem, w tym bazami danych lub aplikacją.
Aplikacja Mobilna Portal Informacyjny/AM PI	Aplikacja Mobilna Portalu dostępna w sklepach Google Play oraz App Store.
Infrastruktura centralna	Infrastruktura Zamawiającego.
Infrastruktura lokalna	Infrastruktura Użytkownika końcowego.
Infrastruktura systemowa	Całokształt rozwiązań sprzętowo - programowych stanowiących podstawę wdrożenia i eksploatacji Systemu. Składa się z Infrastruktury centralnej i lokalnej.
Infrastruktura techniczna	Całość rozwiązań sprzętowych po stronie Zamawiającego lub Użytkownika końcowego, koniecznych do sprawnego działania Systemu, w tym serwery, pamięci masowe, osprzęt sieciowy, urządzenia archiwizacji danych, itp.
Modyfikacje	Zmiany w Systemie obejmujące zarówno zmiany w istniejących komponentach, jak i budowa nowych komponentów, projektowanie nowych procesów, budowa środowisk technologicznych.
MS	Ministerstwo Sprawiedliwości
Numer wersji Systemu	Numer Systemu posiadający następujący schemat: <major>.<minor>.<path> Major, minor oraz path to wartości liczbowe np. 1.23.7, gdzie: ▪ major to numer charakteryzujący wersję, która w porównaniu do poprzedniej posiada znaczące zmiany odnoszące się do ważnych aspektów działania Systemu, np. zmiana głównych jego funkcjonalności, zmiana wynikająca ze zmiany prawa, nowy sposób komunikacji, znacząca zmiana wyglądu interfejsu użytkownika, zmiana silnika bazy danych, itp., ▪ minor to numer określający wprowadzenie nowych elementów Systemu, niewpływających w znacznym stopniu na zmiany w strukturze Systemu, np. dodanie nowych przycisków, pól w formularzach, zmiana definicji procesu, nie wynikające z błędnego działania systemu, Path to numer określający wprowadzenie poprawki naprawiającej wykryte Błędy w danej wersji Systemu.
Obejście	Opis sposobu rozwiązania Błędu wraz z instrukcją jego wykonania przekazane w Zgłoszeniu przez Wykonawcę,

	które po wykonaniu tymczasowo (do czasu dostarczenia docelowego rozwiązania zgłoszenia) usuwa Błąd, skutki wystąpienia Błędów albo je kompensuje z zachowaniem funkcjonalności Systemu niezbędnych do realizacji procesów biznesowych Systemu. Stosowanie Obejścia nie może wiązać się z istotnym wzrostem wykorzystania Infrastruktury technicznej, dodatkowym, istotnym wzrostem obciążenia Użytkowników Systemu lub nie może powodować nieuprawnionej modyfikacji lub utraty danych i funkcjonalności Systemu.
Personel	Xxxxx, przy pomocy których Wykonawca wykonuje Umowę.
Personel Podstawowy	Osoby wskazane imiennie w oświadczeniach i dokumentach złożonych w postępowaniu, w wyniku którego zawarto Umowę, które zostały wyszczególnione imiennie w Załączniku nr 3 do Umowy.
Personel Pomocniczy	Inne niż Personel Podstawowy osoby wykonujące przedmiot Umowy, stanowiące pomoc Personelu Podstawowego.
Oprogramowanie	Oprogramowanie Systemu, w tym oprogramowanie systemowe i bazodanowe lub oprogramowanie aplikacji, do którego Zamawiający posiada autorskie prawa majątkowe.
Oprogramowanie Osób Trzecich (OOT)	Powszechnie dostępne oprogramowanie (w szczególności oprogramowanie systemowe, oprogramowanie serwerów aplikacyjnych i bazodanowych, oprogramowanie sterowników i firmware urządzeń, oprogramowanie komunikacyjne IP, oprogramowanie do wykonywania kopii bezpieczeństwa, etc.) inne niż będące własnością Zamawiającego, dostarczone przez Wykonawcę, konieczne do realizacji przedmiotu Umowy. Zwane też Oprogramowanie gotowym/narzędziowym/systemowym.
OPZ	Opis Przedmiotu Zamówienia w niniejszym postępowaniu.
Produkt	Rezultat realizacji przedmiotu Umowy, w szczególności: nowa wersja Systemu lub kolejna wersja Systemu z nowym Numerem wersji Systemu, wdrożone i działające Oprogramowanie (w tym kod źródłowy i wynikowy), Dokumentacja, inne Utwory powstałe w ramach realizacji Umowy.
System	Oprogramowanie, OOT oraz Infrastruktura systemowa umożliwiająca działanie Portalu Informacyjnego
SRB	Systemy repertoryjno – biurowe wdrożone i produkcyjnie uruchomione u Użytkownika końcowego.

Usługa	Usługa wsparcia technicznego i serwisu, Usługa Modyfikacji oraz Usługa realizacji szkoleń/warsztatów dla Administratorów Systemu.
Użytkownik końcowy	Jednostki sądów powszechnych zgodnie z ustawą z dnia 27 lipca 2001 r. Prawo o ustroju sądów powszechnych (tekst jednolity Dz. U. z 2020 r., poz. 2072 ze zm.).
Użytkownik	Osoba fizyczna korzystająca z Systemu. Wyróżnia się Użytkowników wewnętrznych oraz Użytkowników zewnętrznych.
Użytkownik wewnętrzny	Pracownicy Zamawiającego, MS oraz Użytkowników końcowych, osoby świadczące usługi na rzecz Zamawiającego/MS/Użytkowników końcowych na podstawie umów cywilno-prawnych lub odbywające praktykę/staż/aplikację, lub osoby zatrudnione w innych podmiotach jednostek organizacyjnych podległych MS lub przez niego nadzorowanych, którym zostały nadane przez Zamawiającego uprawnienia dostępu do Systemu.
Użytkownik zewnętrzny	Osoba korzystająca z funkcjonalności zaimplementowanych w Systemie dostępnych w Internecie niezaliczona do grupy Użytkowników wewnętrznych, w tym osoby fizyczne i osoby prawne, pracownicy innych instytucji i firm, które korzystają z Systemu na podstawie postanowień odrębnych umów zawartych przez Zamawiającego z tymi podmiotami lub na podstawie przepisów obowiązującego prawa.
Wada	Zdarzenie lub zakłócenie niebędące częścią standardowego działania Systemu bez względu na jego przyczynę.
WF	Wymagania funkcjonalne
WNF	Wymagania niefunkcjonalne
Zamawiający (SA Wrocław)	Sąd Apelacyjny we Wrocławiu

2. Wprowadzenie

Portal Informacyjny Sądów Powszechnych, będący własnością Zamawiającego, umożliwia dostęp uprawnionym lub upoważnionym podmiotom do informacji o sprawach toczących się przed sądami powszechnymi za pośrednictwem Internetu.

Zarejestrowany w Portalu Informacyjnym użytkownik otrzymuje dostęp do danych o sprawie obejmujących m. in.:

• stan sprawy, tzn. na jakim etapie procedowania znajduje się teraz proces sądowy,

• czynności wykonane przez sąd wraz z określeniem osoby odpowiedzialnej za jej wykonanie oraz daty (np. przekazanie akt biegłemu celem wydania opinii),

• wyznaczone terminy posiedzeń,

• dokumenty w sprawie wygenerowane przez sąd w postaci elektronicznej (pisma wychodzące, wyroki, postanowienia, uzasadnienia, protokoły z rozpraw),

• doręczenia dokumentów,

• dane dotyczące postępowania w niższej instancji o ile takie istnieją,

• protokół elektroniczny z możliwością odsłuchania.

Korzyściami, jakie płyną z funkcjonowania Portalu, jest m. in. oszczędność czasu i pieniędzy stron i pełnomocników oraz przyspieszenie pracy sądu przez odciążenie sekretariatów od obowiązku udzielania informacji i wydawania dokumentów uczestnikom postępowań.

Portal Informacyjny w obecnym kształcie realizuje ideę pojedynczego punktu dostępu do danych o sprawach na poziomie całej apelacji, co oznacza, że istnieje 11 instancji Portalu, z których każdy posiada odrębną bazę danych. Czas dostępności Systemu wynosi 24/7 (całą dobę przez 7 dni w tygodniu).

Jednym z głównych elementów Portalu Informacyjnego jest importer danych z systemów lokalnych znajdujących się w sądach. Zadaniem oprogramowania służącego do importu danych do Portalu Informacyjnego jest pobieranie danych o sprawach, doręczeń sądowych, dokumentów przeznaczonych do publikacji oraz nagrań e-protokołu z sądu do Infrastruktury centralnej i zasilanie nimi bazy danych Portalu. Celem jego działania jest kompletność, spójność i aktualność informacji dostępnych za pośrednictwem Portalu Informacyjnego. Źródłem pobieranych danych są bazy danych programów repertoryjno-biurowych zainstalowane w sądach oraz repozytoria e-protokołu.

Celem niniejszego zamówienia jest zapewnienie profesjonalnego utrzymania dla Systemu.

Wymagania względem Wykonawcy zostały opisane poniżej.

3. Dokumentacja techniczna Systemu

Dokumentacja techniczna Systemu stanowi Załącznik nr 1 do OPZ – Dokumentacja techniczna. oraz Załącznik nr 6 do OPZ – dokumentacja API. Dokumentacja na potrzeby postępowania została zanonimizowana oraz pozbawiona nieistotnych na etapie postępowania informacji. Kompletna dokumentacja techniczna zostanie przekazana Wykonawcy po zawarciu Umowy.

4. Zobowiązania Wykonawcy

4.1. Zarządzanie Umową

1. Wykonawca odpowiedzialny jest za zarządzanie i koordynację prac zespołu Wykonawcy oraz koordynację współdziałania swojego zespołu z zespołem Zamawiającego w realizacji zobowiązań umownych. Dobór metod i technik pracy właściwych dla efektywnej realizacji przedmiotu zamówienia leży po stronie Wykonawcy, przy czym podlega on akceptacji Zamawiającego.

2. Wykonawca zobowiązany jest do realizacji prac inicjujących projekt obejmujących co najmniej organizację spotkania otwierającego projekt w siedzibie Zamawiającego w terminie nie późniejszym niż 20 dni kalendarzowych od zawarcia Umowy – celem spotkania jest dokonanie niezbędnych uzgodnień realizacyjnych. W trakcie spotkania inicjującego przedstawi co najmniej:

a) skład personelu kluczowego do realizacji Umowy,

b) opis struktury organizacyjnej zespołu Wykonawcy,

c) plan komunikacji pomiędzy stronami, zawierający kanały komunikacji oraz wykaz osób do kontaktu w poszczególnych zakresach tematycznych,

d) rejestr wymagań względem Wykonawcy,

e) harmonogram realizacji prac objętych rygorem terminu,

f) zagadnienia do ustalenia pomiędzy stronami,

g) sposób realizacji kluczowych elementów umowy (monitorowanie, modyfikacje, wdrożenie zmian, zarządzanie jakością, testowanie, dokumentacja),

h) pytania do Zamawiającego.

Wykonawca sporządzi i przedstawi Zamawiającemu w terminie 2 Dni roboczych notatkę ze spotkania inicjującego (notatka powinna być utrwalona w formie dokumentowej zgodna z szablonem stanowiącym Załącznik nr 2 do OPZ). Jeżeli Umowa zostanie zawarta w okresie obowiązywania poprzedniej umowy utrzymaniowej na System przedstawiciele Wykonawcy są obowiązani uczestniczyć w spotkaniach związanych z transferem wiedzy realizowanym przez poprzedniego Wykonawcę na rzecz Zamawiającego.

3. Wykonawca zobowiązany jest do organizowania cyklicznych spotkań przedstawicieli Personelu Podstawowego z zespołem utrzymaniowym Zamawiającego (nie rzadziej niż raz na tydzień w wymiarze 1-2h) w drodze wideokonferencji przy wykorzystaniu systemu udostępnionego w tym celu Wykonawcy przez Zamawiającego. O konieczności wyznaczenia spotkania oraz o terminie decyduje Zamawiający. Zamawiający wskazuje Wykonawcy członków Personelu Podstawowego, którzy są zobowiązani do wzięcia udziału w danym spotkaniu. Zamawiający może odstąpić od wyznaczenia spotkania. Wykonawca może wnioskować o wyznaczenie, odwołanie spotkania lub zmianę terminu. Wykonawca sporządzi i dostarczy Zamawiającemu w ciągu - 2 Dni roboczych notatkę ze spotkania cyklicznego (notatka powinna być utrwalona w formie dokumentowej oraz zgodna z szablonem stanowiącym Załącznik nr 2 do OPZ).

4. Na 6 miesięcy przed końcem Umowy, a w wypadku rozwiązania Umowy przez Zamawiającego w trybie § 10 ust. 3 Umowy, najpóźniej w terminie 2 tygodni od dnia otrzymania przez Wykonawcę oświadczenia Zamawiającego o wypowiedzeniu Umowy, Wykonawca przygotuje i przekaże Zamawiającemu szczegółową agendę zagadnień koniecznych do transferu wiedzy z poszczególnych obszarów utrzymania Systemu.

5. W ostatnim miesiącu trwania Umowy Wykonawca zobowiązany jest do transferu wiedzy Zamawiającemu lub wskazanemu przez niego podmiotowi, polegającego na:

a. odbyciu maksymalnie dziesięciu spotkań w drodze wideokonferencji lub w siedzibie Zamawiającego (według wyboru Xxxxxxxxxxxxx, przy czym w siedzibie Zamawiającego nie więcej niż cztery spotkania), w terminach wskazanych przez Xxxxxxxxxxxxx, trwających według potrzeb Zamawiającego (nie dłużej jednak niż

8 godzin w ciągu dnia), z udziałem członków Personelu Podstawowego wskazanych przez Xxxxxxxxxxxxx;

b. udzielenia konsultacji i odpowiedzi na pytania lub zagadnienia przedstawione przez Zamawiającego lub przez wskazany przez niego podmiot, w terminie nie później niż dwóch Dni roboczych od dnia zgłoszenia za pośrednictwem wskazanego przez Xxxxxxxxxxxxx kanału takiego żądania przez Zamawiającego lub wskazany przez niego podmiot.

4.2. Aktualizacja systemów operacyjnych

Wykonawca dokona przeglądu systemów operacyjnych, w oparciu, o które funkcjonuje system i przeprowadzi ich aktualizację do najnowszej dostępnej wersji stabilnej dostępnej na oficjalnym kanale producenta (major).

Warunki przeprowadzenia aktualizacji:

1) Wykonanie przeglądu i przedstawienie raportu zawierającego:

a. serwer,

b. aktualna wersja,

c. najnowsza dostępna wersja,

d. uwagi i rekomendacje.

2) Analiza wpływu aktualizacji systemu operacyjnego na System. W przypadku, gdy aktualizacja systemu operacyjnego ma wpływ na oprogramowanie Systemu (w tym OOT), Wykonawca dostosuje Portal Informacyjny tak, aby funkcjonował poprawnie na zaktualizowanej wersji systemu operacyjnego.

3) Wykonanie aktualizacji systemu operacyjnego (przez podniesienie wersji lub instalacja nowego systemu operacyjnego i przeniesienie komponentów Systemu oraz konfiguracji).

4) Zamawiający może odstąpić od aktualizacji danego systemu operacyjnego lub odłożyć ją w czasie z uwagi na uzasadnienie przedstawione przez Wykonawcę.

5) Wykonawca przeprowadzi aktualizację systemów operacyjnych zgodnie z przedstawionym przez niego harmonogramem zatwierdzonym przez Xxxxxxxxxxxxx.

6) Wykonawca w ramach aktualizacji przeprowadzi utwardzenie systemów operacyjnych i ich konfiguracji (hardening) w celu zapewnienia minimalizacji ryzyka ataku z zewnątrz i negatywnego wpływu złośliwego oprogramowania. Utwardzanie ma być zrealizowane w oparciu o standardy wydane przez Centrum zabezpieczeń internetowych (CIS) lub National Institute of Standards and Technology (NIST) lub inny równoważny po akceptacji przez Zamawiającego.

7) Wykonawca w ramach aktualizacji skonfiguruje wszystkie serwery, tak aby wykorzystywały serwer czasu Zamawiającego.

8) Maksymalny termin przeprowadzenia aktualizacji systemów operacyjnych: 6 miesięcy licząc od daty zawarcia Umowy (w przypadku wyjątku z pkt. 4 termin ten może być dłuższy i zostaje określony w drodze decyzji Zamawiającego, zmiana ta nie wymaga zmiany Umowy).

9) Wykonawca zaktualizuje odpowiednią Dokumentację.

4.3. Przygotowanie i przeprowadzanie testów automatycznych

Wykonawca zaimplementuje jednostkowe testy automatyczne modułu WEB PI, PA oraz AM pokrywające wszystkie przypadki użycia zgodnie z harmonogramem:

1) 30% kluczowych przypadków użycia w terminie do 6 miesięcy do dnia zawarcia Umowy,

2) 90% kluczowych przypadków użycia w terminie do 12 miesięcy od dnia zawarcia Umowy.

Testy automatyczne zostaną zrealizowane zgodnie z normą ISO/IEC/IEEE 29119 lub równoważną, tj. taką, która opisuje proces testowania na co najmniej tożsamym poziomie szczegółowości.

4.4. Dostosowanie REST API Systemu do standardu OpenAPI

Wykonawca dostosuje (zapewni zgodność) API Systemu w obszarze modułów WEB PI, PA, AM do standardu OpenAPI w wersji co najmniej 3.x (aktualnie obowiązującej na dzień zawarcia Umowy) tak aby, możliwym było zrozumienie możliwości usług bez dostępu do kodu źródłowego, dokumentacji lub poprzez inspekcję ruchu źródłowego Systemu.

Wykonawca dostosuje API Systemu w terminie 8 miesięcy od dnia zawarcia Umowy.

4.5. Pakiety serwisowe serwerów bazodanowych

4.5.1. Pakiety serwisowe dla systemu operacyjnego

Zamawiający jest w posiadaniu licencji dla SUSE Linux Enterprise Server for SAP Applications w wersji 12 w liczbie 4 sztuk (zainstalowanych na Urządzeniach opisanych w pkt. 4.5.2.) na potrzeby funkcjonowania systemu bazodanowego SAP HANA. Wykonawca dostarczy 4 pakiety serwisowe obejmujące co najmniej:

1) aktualizacje systemu operacyjnego,

2) nieograniczone wsparcie techniczne,

3) dostępne kanały: chat, telefon, web,

4) godziny dostępu: 24x7,

5) czas odpowiedzi:

a. 1 godzina dla istotności 1

b. 2 godziny dla istotności 2

c. 4 godziny dla istotności 3

d. kolejny dzień biznesowy dla istotności 4

lub równoważne o odpowiednich parametrach i możliwościach. W przypadku dostarczenia rozwiązania równoważnego, Wykonawca jest zobowiązany zapewnić kompatybilności z posiadanymi przez Zamawiającego licencjami lub wymienić posiadane przez Zamawiającego licencje na takie, które są kompatybilne i wspierane przez producenta systemu bazodanowego, który wykorzystuje System przy zachowaniu ciągłości pracy, wszystkich danych oraz wydajności systemu.

Termin obowiązywania pakietów serwisowych dla systemu operacyjnego: przez okres 48 miesięcy liczonych od pierwszego kalendarzowego dnia miesiąca następującego po dacie zawarcia Umowy, jednak nie wcześniej niż od 1.04.2022 r.

4.5.2. Pakiety serwisowe dla Urządzeń

Zamawiający jest w posiadaniu serwerów RH8100 V3 marki Huawei Technologies Co. wyposażonych w 4 procesory Intel® Xeon® CPU E7-8890 v4 @ 2.20GHz posiadające 24 rdzenie (dalej „Urządzenia”), o numerach seryjnych:

• 2102311QSG10J4000001,

• 2102311QSG10J4000002,

• 2102311QSG10J4000003,

• 2102311QSG10J4000004,

dla których Wykonawca zapewni Usługi wsparcia pogwarancyjnego spełniające poniższe wymagania:

1. Termin obowiązywania pakietów serwisowych dla Urządzeń (wsparcia pogwarancyjnego): przez okres 36 miesięcy liczony od 1.07.2023 r.

2. Usługi wsparcia pogwarancyjnego będą świadczone przez serwis producenta lub serwis autoryzowany (upoważniony) przez producenta.

3. Usługi będą świadczone w języku polskim.

4. Zgłoszenie awarii Urządzenia dokonywane całodobowo: 24 godziny na dobę, 7 dni w tygodniu, 000/000 xxx w roku.

5. Czas usunięcia zgłoszonej awarii Urządzenia: następny Dzień roboczy następujący po dniu zgłoszenia (NBD).

6. Naprawy i przeglądy będą dokonywane w miejscu eksploatacji Urządzeń praz pracowników serwisu producenta lub serwisu autoryzowanego (upoważnionego) przez producenta. W przypadku niemożności dokonania naprawy na miejscu i konieczności dostarczenia Urządzeń do punktu serwisowego, koszty dostarczenia uszkodzonego Urządzenia do punktu serwisowego oraz z punktu serwisowego do miejsca eksploatacji Urządzenia oraz jego ponownej instalacji i konfiguracji realizowane są w ramach wynagrodzenia za pakiet serwisowy. Zamawiający nie pokrywa żadnych dodatkowych kosztów.

7. W przypadku awarii dysku twardego lub innego nośnika danych, powodującej konieczność jego wymiany, uszkodzony nośnik pozostanie u Zamawiającego. Zamawiający nie ponosi żadnych kosztów wymiany nośników danych spowodowanych wystąpieniem awarii dysku twardego.

8. W okresie trwania Umowy Zamawiający ma prawo do instalowania, wymiany standardowych kart rozszerzeń i urządzeń (np. modemów, sterowników sieciowych, dysków twardych, itp.) oraz rozbudowy Urządzeń zgodnie z zasadami sztuki informatycznej i przez wykwalifikowany personel Zamawiającego, bez utraty wsparcia pogwarancyjnego.

9. W przypadku problemów technicznych, których nie można rozwiązać zdalnie, zapewniona zostanie u Zamawiającego naprawa, wymiana poszczególnych komponentów lub całego Urządzenia w zależności od stopnia złożoności zgłoszonej awarii Urządzenia.

10. Podczas usuwania zgłoszonej awarii Urządzenia, po konsultacjach z Zamawiającym, dokonana zostanie instalacja dostępnych i zalecanych w danym czasie ulepszeń technicznych w celu zapewnienia poprawnego działania Urządzenia oraz podwyższenia jego wydajności (zgodnie z zainstalowanymi częściami zamiennymi). Zainstalowane zostaną uaktualnienia oprogramowania wbudowanego (firmware) danego urządzenia wspierającego sprawne przeprowadzanie procesu usuwania usterek. Instalacja aktualizacji oprogramowania Urządzenia nie może naruszać praw autorskich producenta

oprogramowania Urządzenia. Dotyczy to tych uaktualnień, które nie są dostępne do samodzielnej instalacji przez użytkownika.

11. Dostarczone zostaną wszelkie części zamienne i materiały, które są niezbędne do utrzymania Urządzenia objętego Umową w należytym stanie technicznym oraz, które są wymagane w ramach dostępnych i zalecanych ulepszeń technicznych, w ramach wynagrodzenia określonego w Umowie.

12. Czas przeznaczony na instalację usprawnień technicznych czy aktualizacji oprogramowania wbudowanego (firmware) oraz na weryfikację naprawy (np. autotesty) wyłącza się z czasu naprawy.

13. W ramach wsparcia pogwarancyjnego zapewniony zostanie dostęp do portali internetowych producenta Urządzenia i oprogramowania Urządzenia zawierających narzędzia wsparcia elektronicznego. W szczególności narzędzia te muszą umożliwiać:

a. przeszukiwanie bazy wiedzy producenta dotyczącej Urządzenia i oprogramowania objętego wsparciem pogwarancyjnym,

b. pobieranie poprawek i nowych wersji oprogramowania wbudowanego (firmware) dla urządzeń objętych wsparciem pogwarancyjnym,

c. uzyskiwanie informacji o statusie Umowy w zakresie wsparcia pogwarancyjnego oraz o urządzeniach nią objętych,

d. uzyskiwanie informacji o zgłoszeniach i statusie napraw.

14. Najpóźniej w dniu rozpoczęcia świadczenia usług wsparcia pogwarancyjnego Wykonawca dostarcz w formie elektronicznej dokument „Procedura zgłaszania, obsługi i eskalacji zgłoszeń serwisowych", zawierający:

a. procedury zgłaszania awarii Urządzeń;

b. procedury eskalacyjne;

c. dane serwisu producenta lub serwisu autoryzowanego (upoważnionego) przez producenta świadczącego Usługi wsparcia pogwarancyjnego - adresy, numery telefonów, adresy poczty elektronicznej;

d. adresy stron internetowych producenta z odpowiednimi plikami do pobrania, zawierających poprawki, aktualizacje, nowe wersje oprogramowania - po ich udostępnieniu przez producenta oprogramowania, w okresie trwania umowy;

e. procedury śledzenia bieżącego statusu zgłoszenia serwisowego.

4.6. Pakiety serwisowe systemu bazodanowego

Wykonawca dostarczy pakiety serwisowe na poziomie Enterprise dla posiadanych przez Zamawiającego licencji SAP HANA 2.0 Base Edition w ilości 16 sztuk (16x64GB) zawierający w szczególności:

1) wsparcie dla rozwiązywania błędów technicznych – 24×7 dostęp do bazy znanych problemów SAP xSearch oraz SAP Notes,

2) dostęp do platformy SAP Service Marketplace oraz SAP Developer Network (SDN),

3) dostęp do wcześniej wspomnianej możliwości aktualizowania systemów SAP zarówno od strony technicznej jak i funkcjonalnej,

4) możliwość skorzystania z funkcjonalności dostarczanych w ramach SAP Solution Manager w przypadku instalacji systemu po stronie Klienta,

5) możliwość skorzystania ze standardowych sesji wsparcia ze strony SAP:

a. SAP EarlyWatch Alert Service,

b. TQC for Implementation,

c. TQC SAP GoingLive for Upgrade,

d. TQC SAP OS/DB Migration Check,

e. TQC Planning,

f. TQC SAP EarlyWatch Check,

g. TQC SAP GoingLive Support,

h. TQC Business Process Performance Optimization,

i. TQC Integration Validation,

j. TQC Data Volume Management,

k. TQC Business Process Analysis and Monitoring,

l. TQC Security Optimization,

m. TQC Technical Perf. Optimization Database,

n. TQC Solution Transition Assessment,

o. TQC Transport Execution Analysis,

p. TQC Upgrade Assessment,

q. TQC EHP Installation Check,

r. TQC Downtime Assessment,

6) wsparcie w rozwiązywaniu problemów w ramach trzeciej linii wsparcia dostarczanej przez SAP SE, z gwarantowanymi czasami wsparcia zapewnianymi w kooperacji przez SAP SE oraz Partnera. Wyróżnia się dwie istotne definicje:

a. IRT (Initial Response Time) oznaczający po prostu czas reakcji od momentu zgłoszenia problemu do jego aktywnego podjęcia i rozpoczęcia działań zmierzających w celu rozwiązania zagadnienia,

b. MPT (Maximum Processing Time) co wskazuje maksymalny czas realizacji po stronie SAP SE oraz Partnera, w którym dostarczony zostanie plan działań lub rozwiązanie problemu.

lub rozwiązanie równoważne o odpowiednich parametrach i możliwościach. W przypadku dostarczenia rozwiązania równoważnego, Wykonawca jest zobowiązany do zapewnienia kompatybilności z posiadanymi przez Zamawiającego licencjami lub wymienić posiadane przez Zamawiającego licencje oraz dostosować systemy informatyczne pracujące na systemie bazodanowym przy zachowaniu ciągłości pracy, wszystkich danych oraz wydajności systemu. Zamawiający posiada kompetencje związane z eksploatacją posiadanego systemu bazodanowego, jeżeli oferowanym rozwiązaniem wsparcia dla systemu bazodanowego będzie inna niż oferowane przez producenta SAP HANA, Wykonawca zobowiązany jest do zapewnienia w ramach oferty stosownych szkoleń dla administratorów Zamawiającego w lokalizacji centralnej tj. we Wrocławiu (nie mniej niż dla 5 osób i nie więcej niż dla 10 osób) z dostarczanego rozwiązania bazodanowego, w wymiarze nie mniejszym niż 80h szkoleń do wykorzystania na żądanie Zamawiającego w terminie obowiązywania Umowy.

Termin obowiązywania pakietów serwisowych dla licencji: przez okres 48 miesięcy liczony od pierwszego dnia miesiąca następującego po dacie zawarcia Umowy, nie wcześniej niż od 1.04.2022 r.

4.7. Zasady ogólne realizacji przez Wykonawcę na rzecz Zamawiającego usług związanych z utrzymaniem Systemu

4.7.1. Zasady Instalacji nowej wersji Systemu

1) Każdorazowo w przypadku powstania nowej wersji Systemu, jej instalacja na środowisku technologicznym następuje na zlecenie Zamawiającego na zasadach wskazanych w OPZ.

2) Wykonawca będzie prowadził ewidencję dostarczanych wersji Systemu, zawierającą:

a. nazwa podsystemu

b. numer wersji,

c. datę wydania wersji,

d. datę instalacji na środowiskach technologicznych,

e. skrótowy opis zmian, które wersja uwzględnia, z odwołaniem do Zlecenia lub Zgłoszenia,

f. ewentualne uwagi.

3) Wykonawca uzupełnia i przedstawia ewidencję, o której mowa w pkt 2 niezwłocznie po wydaniu nowej wersji (poprzez kanał uzgodniony w porozumieniu z Zamawiającym).

4) Na żądanie Zamawiającego Wykonawca przedstawi pakiet obejmujący kody źródłowe Systemu oraz instrukcję kompilacji i konsolidacji poszczególnych elementów Oprogramowania, a także wszystkie elementy dodatkowe służące kompilacji i konsolidacji, z uwzględnieniem wszystkich etapów tworzenia Oprogramowania na założonej linii technologicznej i udzieli odpowiedzi na ewentualne pytania Zamawiającego dotyczących sposobu kompilacji i uruchomienia przekazanych kodów.

5) Dystrybucja nowych wersji Systemu następuje według następującej procedury:

a. Wykonawca przekazuje kody źródłowe kanałem elektronicznym do repozytorium kodów źródłowych Zamawiającego lub jeżeli nie jest to możliwe w inny sposób zatwierdzony przez Zamawiającego,

b. Wykonawca każdorazowo w przypadku wydania nowej wersji przeprowadza ostateczną kompilację kodów na środowisku do kompilacji kodów Zamawiającego,

c. Wykonawca instaluje nową wersję Systemu skompilowaną zgodnie z pkt 5 lit. b na ustalonym środowisku technologicznym i w terminach ustalonych z Zamawiającym.

6) Wraz z nową wersją Wykonawca zobowiązany jest dostarczyć Dokumentację wynikającą ze zmian w Systemie zrealizowanych przez Wykonawcę (aktualizacja Dokumentacji).

4.7.2. OOT

1) W trakcie realizacji Usług, Wykonawca jest uprawniony do wykorzystywania OOT, w szczególności, gdy OOT staje się trwałym składnikiem Systemu, pod warunkiem, że Zamawiający wyraził na to zgodę, co zostało uwzględnione w treści Zlecenia lub w notatce ze spotkania inicjującego lub cyklicznego.

2) Wykonawca zobowiązuje się i gwarantuje, że udziela Zamawiającemu, o ile zajdzie taka potrzeba, licencji lub zgody na korzystanie na wszelkie elementy OOT zapewnione przez Wykonawcę w ramach realizacji Usług.

3) Wykonawca odpowiada za aktualizację OOT.

4) Wykonawca zobowiązuje się i gwarantuje, że udzielone Zamawiającemu/Użytkownikom końcowym licencje na używanie OOT będą obejmowały wszystkie konieczne do realizacji funkcji i celu OOT pola eksploatacji, w tym w szczególności: wprowadzanie i zapisywanie w pamięci komputerów i w sieciach

multimedialnych, instalowanie i deinstalowanie, przekazywanie, przechowywanie, utrwalanie, wyświetlanie, stosowanie.

5) Wykonawca, w celu wykonania niniejszej Umowy zobowiązuje się nabyć w imieniu i na rzecz Zamawiającego, w ramach wynagrodzenia umownego, stosowne licencje/sublicencje lub prawa do korzystania spełniające wymogi, o których mowa w pkt 4, udzielone przez podmioty trzecie w zakresie niezbędnym do eksploatacji przedmiotu Umowy. Zakres i warunki licencji nie mogą być gorsze od standardowych, oferowanych innym podmiotom przez osobę, której przysługują autorskie prawa majątkowe do OOT.

6) Licencje lub sublicencje, o których mowa powyżej, zostaną udzielone na czas nieoznaczony i będą miały charakter niewyłączny. Licencje powinny być udzielone dla nieograniczonej liczby użytkowników, chyba że zakres danej licencji został ograniczony do serwera lub podmiotu (Zamawiającego/Użytkownika końcowego).

7) Prawa do korzystania (typu SaaS) zostaną zapewnione Zamawiającemu na czas trwania Umowy.

8) Wykonawca w okresie trwania Umowy odpowiada za utrzymanie i aktualizację OOT wykorzystywanego w ramach Systemu na podstawie poprzednich umów wdrożeniowo

– utrzymaniowych. Lista OOT aktualna na dzień ogłoszenia niniejszego postępowania przetargowego zawarta jest w Dokumentacji technicznej Systemu.

9) Wykonawca nie może wymagać dodatkowych nakładów finansowych na utrzymanie OOT ze strony Zamawiającego podczas i po okresie trwania Umowy. Przeniesienie na Zamawiającego/Użytkownika końcowego licencji/sublicencji do OOT, udzielenie Zamawiającemu/Użytkownikowi końcowemu licencji lub ich zapewnienie, wraz z prawem do pobierania/otrzymywania poprawek i aktualizacji OOT, zapewnienie prawa do korzystania na innych zasadach (w tym IaaS, PaaS, SaaS, DaaS, FaaS, DBaaS, etc.) następuje w ramach wynagrodzenia wskazanego w Umowie a Zamawiający nie będzie zobowiązany do uiszczania dodatkowego wynagrodzenia lub jakichkolwiek opłat z tego tytułu na rzecz Wykonawcy lub jakiejkolwiek innej osoby, w tym producenta OOT.

4.7.3. Inne

1) Zamawiający zastrzega sobie prawo do dokonywania zmian w Systemie przez inne podmioty niż Wykonawca działające na zlecenie Zamawiającego lub MS. W wypadku, gdy nowa wersja Systemu powstała na skutek wprowadzenia zmian w Systemie przez podmiot inny niż Wykonawca, Wykonawca na polecenie Zamawiającego dokonuje dystrybucji wersji zgodnie z OPZ. Wykonawca nie odpowiada za Błędy spowodowane nieautoryzowanymi przez Wykonawcę, modyfikacjami lub konfiguracją wykonanymi przez Zamawiającego lub osoby trzecie działające w jego imieniu, zobowiązany jednak jest do ustalenia przyczyn wystąpienia Błędów i przedstawienia diagnozy Zamawiającemu. W razie sporu, co do przyczyn wystąpienia Błędów Zamawiający powoła biegłego, celem wiążącego ustalenia przyczyny wystąpienia Błędów. Koszty powołania biegłego i naprawy Błędów ponosi Strona ponosząca odpowiedzialność za powstanie Błędów. Wykonawca będzie usuwał błędy spowodowane działaniem podmiotów trzecich niezwłocznie na koszt Strony odpowiedzialnej za spowodowanie Błędu, przy czym rozliczenie nastąpi po ostatecznym rozstrzygnięciu wszystkich okoliczności faktycznych i prawnych w sprawie.

2) Wykonawca zobowiązuje się do informowania bez zbędnej zwłoki Zamawiającego, w formie dokumentowej, o wszelkich zagrożeniach, przeszkodach, czy utrudnieniach powstałych w toku wykonywania usług, które mogą mieć wpływ na realizację Umowy, oraz do poinformowania o proponowanych sposobach obsługi tych ryzyk.

3) Wykonawca zobowiązuje się do realizacji Usług w sposób zapobiegający utracie danych, w tym także tych, do których będzie miał dostęp w trakcie wykonywania tych usług. W przypadku, gdy wykonanie danej czynności przez Wykonawcę lub przez Zamawiającego w oparciu o rekomendację Wykonawcy wiąże się z ryzykiem utraty danych, Wykonawca zobowiązany jest poinformować o tym Zamawiającego przed przystąpieniem do wykonania takiej czynności lub z chwilą przekazania takiej rekomendacji Zamawiającemu.

4) Wszelkie zmiany w Systemie Wykonawca wykonuje wyłącznie na zlecenie Zamawiającego lub po uzyskaniu jego zgody.

4.7.4. Rodzaje środowisk technologicznych

Zamawiający przedstawia definicje środowisk technologicznych, jednakże nie wszystkie z tych środowisk muszą być wykorzystywane w niniejszej Umowie. Lista środowisk technologicznych może ulec poszerzeniu w wyniku realizacji Modyfikacji Systemu.

Nazwa środowiska technologiczne go	Rodzaj danych	Wersja aplikacji	Dla kogo i komu służy	Kto zapewnia infrastruktu rę	Kto może korzystać ze środowiska
Produkcyjne	Dane produkcyjne	Wersja produkcyjna	Użytkownicy	Zamawiający	Zamawiający i Wykonawca
Preprodukcyjne	Dane przeniesione z produkcji lub dane testowe	Wersja produkcyjna lub testowa	Wsparcie Użytkowników (środowisko do sprawdzania błędów na produkcji)	Zamawiający	Zamawiający i Wykonawca
Testowe (2 instancje)	Dane testowe lub przeniesione z produkcji	Wersja testowa lub produkcyjna	Wsparcie Użytkowników (służy do sprawdzenia nowych wersji aplikacji, która rozwiązuje zauważone błędy)	Zamawiający	Zamawiający i Wykonawca
Rozwojowe (w zależności od potrzeb Zamawiającego)	Dane testowe lub przeniesione z produkcji	Wersja testowa	Pracownicy Zamawiającego zajmujący się wdrażaniem nowych funkcjonalności/ projektów Systemu	Zamawiający	Zamawiający i Wykonawca
Developerskie Wykonawcy	Xxxx xxxxxxx	Xxxxxx implementow ana (programowa na) przez programistów	Pracownicy Wykonawcy	Wykonawca	Wykonawca

Developerskie do kompilacji kodów (w zależności od potrzeb Zamawiającego) Dane testowe Kod źródłowy gotowy do kompilacji i konsolidacji Pracownicy Zamawiającego, którzy kompilują kod Zamawiający Zamawiający oraz incydentalnie kiedy Zamawiający nie może skompilować kodu - Wykonawca

4.7.4.1. Środowisko developerskie do kompilacji kodów

Wykonawca zbuduje u Zamawiającego środowisko developerskie do kompilacji kodów. Kod systemu będzie zarządzany zgodnie z wzorcem ciągłej integracji (continuous integration) i ciągłego dostarczania (continuous delivery). Zamawiający dysponuje oprogramowaniem GitLab, które ma być wykorzystane do tego celu.

Środowisko developerskie do kompilacji kodów zapewniać ma możliwości:

1) repozytorium kodu,

2) automatyczne budowanie oprogramowania,

3) testy statyczne kodu źródłowego oraz weryfikację zgodności formatowania kodu w odniesieniu do przyjętej konwencji formatowania kodu,

4) testy automatyczne,

5) repozytorium kodu wynikowego. Środowisko ma spełniać następujące wymagania:

1) zostanie zainstalowane przez Wykonawcę w środowisku Zamawiającego na wskazanej przez niego Infrastrukturze zgodnie z wymaganiami sprzętowymi określonymi przez Wykonawcę w porozumieniu z Zamawiającym,

2) Wykonawca nie jest zobowiązany do dostarczenia sprzętu dla środowiska oraz może wykorzystać wirtualizację w formacie uzgodnionym z Zamawiającym,

3) Wykonawca dostarczy Zamawiającemu oprogramowanie niezbędne do istnienia środowiska obejmujące oprogramowanie narzędziowe, gotowe i systemowe (OOT) wraz niezbędnymi bibliotekami oraz licencjami w tym z wykorzystaniem ewentualnych sublicencji, konieczne do wytwarzania i kompilacji kodów źródłowych bez konieczności ponoszenia przez Zamawiającego dodatkowych kosztów,

4) Wykonawca będzie aktualizował środowisko w przypadku konieczności zastosowania nowych wersji komponentów, z których jest zbudowane oraz dostarczy niezbędne licencje o ile nowe wersje komponentów będą tego wymagały,

5) Wykonawca nie może wykorzystywać do przeprowadzenia kompilacji, zasobów zewnętrznych pobieranych przez sieć,

6) Wykonawca dostarczy dokumentację środowiska zawierającą opis elementów koniecznych do przeprowadzenia wytwarzania i kompilacji kodów i będzie ją aktualizował w okresie obowiązywania Umowy,

7) Wykonawca ponosi odpowiedzialność za wykonywane przez Zamawiającego kompilacje kodów źródłowych, jeżeli będą one wykonywane na podstawie przekazanych przez Wykonawcę procedur i instrukcji,

8) Środowisko developerskie do kompilacji kodów zostanie dostarczone i przekazane Zamawiającemu przez Wykonawcę w terminie 3 miesięcy liczonych od dnia zawarcia Umowy.

4.7.4.2. Dostosowanie środowisk

Wykonawca zrówna na poziomie funkcjonalnym 2 środowiska testowe Systemu ze środowiskiem preprodukcyjnym w terminie 4 miesięcy od dnia zawarcia Umowy. W ramach Usługi wsparcia technicznego i serwisu Wykonawca będzie aktualizował środowiska w przypadku wydawania nowych wersji wynikających z realizacji naprawy Wad oraz realizacji Modyfikacji zgodnie ze zleceniem. Wykonawca będzie wyrównywał środowiska do wskazanego przez Xxxxxxxxxxxxx na podstawie zlecenia Konfiguracji maksymalnie raz w miesiącu.

4.8. Usługa wsparcia technicznego i serwisu Systemu

Wykonawca świadczy usługę wsparcia technicznego i serwisu dla Zamawiającego oraz dla wszystkich Użytkowników końcowych Systemu.

4.8.1. Zakres Usługi wsparcia technicznego i serwisu Systemu

Usługa wsparcia technicznego i serwisu Systemu obejmuje:

1) zadania administracji wszystkimi komponentami Systemu w Infrastrukturze systemowej,

2) obsługę kopii zapasowych Systemu i ich odtwarzania zgodnie z procedurami tworzenia kopii zapasowych (backup),

3) usuwanie Wad Systemu oraz skutków Wad Systemu, a także wszelkich negatywnych skutków spowodowanych korzystaniem z wadliwie działających wersji Systemu we wszystkich lokalizacjach funkcjonowania Systemu,

4) realizację Konfiguracji Systemu we wszystkich lokalizacjach funkcjonowania Systemu,

5) odtworzenie Systemu i przywrócenie do pełnej funkcjonalności w tym po Katastrofie (pod pojęciem Katastrofy Zamawiający rozumie uszkodzenie lub zniszczenie komponentów istniejącej Infrastruktury systemowej, kiedy do przywrócenia sprawności Systemu niezbędne są działania związane z odtwarzaniem zniszczonych zasobów sprzętowych i danych w zakresie związanym z Systemem. Wykonawca nie jest zobowiązany do dostarczenia nowej Infrastruktury sprzętowej.),

6) monitorowanie i rekomendowanie Zamawiającemu konieczności zainstalowania poprawek i nowych wersji, na poszczególnych elementach Systemu dla środowisk technologicznych w Infrastrukturze centralnej,

7) obsługa zgłoszeń Użytkowników,

8) zapewnienie ciągłości importu danych od Użytkowników końcowych do Systemu.

4.8.1.1. Zobowiązania dodatkowe

1) Wykonawca w terminie 6 miesięcy od dnia zawarcia Umowy przygotuje i dostarczy Zamawiającemu Plan ciągłości działania Systemu obejmujący, co najmniej:

a. analizę BIA (Business Impact Analysis),

b. analizę ryzyka,

c. określenie działań,

d. procedury odtworzeniowe,

e. testy ciągłości działania,

f. procedurę wykonywania testów,

g. BCP (Business continuity planning).

2) Wykonawca przeprowadzi co 12 miesięcy test planu ciągłości działania Systemu, przy czym pierwszy test odbędzie się w terminie nie później niż 30 dni od dnia odebrania przez Zamawiającego Planu ciągłości działania, o którym mowa w pkt 1, a działania będą prowadzone w sposób minimalizujący wpływ testu na system produkcyjny.

3) Po przeprowadzeniu testu planu ciągłości działania wykonawca sporządzi raport podsumowujący, którego wnioski zostaną omówione z Zamawiającym oraz zostaną wprowadzone stosowne korekty do planu będące następstwem przedstawionych wniosków.

4) Wykonawca w terminie 3 miesięcy od dnia zawarcia Umowy zaktualizuje i dostarczy Zamawiającemu procedury backupu (kopii zapasowych) i odzyskiwania danych Systemu obejmującą, co najmniej:

a. cel i zakres procedury,

b. komponent Systemu,

c. odpowiedzialność,

d. częstotliwość wykonywania kopii zapasowej,

e. typ kopii zapasowej,

f. przechowywanie kopii zapasowej,

g. warunki uruchomienia procedury i oczekiwany rezultat jej wykonania,

h. czynności do wykonania w ramach procedury,

i. procedurę lub instrukcję odtwarzania z kopii bezpieczeństwa.

5) Wykonawca w terminie 6 miesięcy od dnia zawarcia Umowy jest zobowiązany do przeglądu kodów źródłowych Systemu oraz Dokumentacji Systemu i zgłoszenia Zamawiającemu ewentualnych nieprawidłowości, braków lub potrzeby wykonania refaktoryzacji kodu. W takim wypadku usunięcie nieprawidłowości lub uzupełnienie odbywać się będzie w oparciu o Zlecenie Modyfikacji i rozliczane będzie w ramach Roboczogodzin przeznaczonych na Modyfikacje. Po upływie 6 miesięcy wszelkie Wady w kodzie źródłowym lub w Dokumentacji (nawet jeżeli istniały na dzień zawarcia Umowy) będą realizowane w ramach Usługę wsparcia technicznego i serwisu, a Wykonawcy nie przysługuje żadnego roszczenie o dodatkowe wynagrodzenie z tego tytułu. Przegląd kodów źródłowych Systemu i Dokumentacji Systemu ma na celu zapewnienie spójności działania Systemu we wszystkich jego komponentach, a wszelkie wykryte odstępstwa wymagają Modyfikacji lub udokumentowania i akceptacji Zamawiającego.

6) Wykonawca w terminie 6 miesięcy od dnia zawarcia Umowy przygotuje i dostarczy Zamawiającemu plan testów wydajnościowych Systemu zgodny z poniższymi założeniami:

a. Testy odbędą się w środowisku produkcyjnym z poziomu sieci lokalnej Zamawiającego.

b. Przedmiotem testu będą symulowane operacje Użytkowników (np. logowanie, przejście przez określone widoki, pobieranie dokumentów).

c. Na test składały się będą skrypty automatyczne odzwierciedlające przejście przez wybrane moduły/podstrony systemu.

d. Zamawiający wskaże reprezentatywne moduły/podstrony wytworzonego systemu, które wejdą w skład testu.

e. W trakcie testu Użytkownicy, po zalogowaniu się, przechodzą między modułami wykonując operacje odczytu i zapisu do bazy.

f. Obciążenie Systemu symulowane będzie poprzez ustaloną w porozumieniu z Zamawiającym ilość równoczesnych sesji użytkowników w systemie.

g. Użytkownicy inicjowani będą stopniowo z użyciem losowego czasu reakcji pomiędzy transakcjami, aby warunki testu były jak najbardziej zbliżone do rzeczywistych.

h. Co X sekund loguje się kolejnych Y użytkowników. Łącznie ramp-up zajmuje X minut. Gdzie wartości X,Y,Z zostaną ustalone w porozumieniu z Zamawiającym.

i. Czas reakcji użytkownika przyjęto jako wartość losową z zakresu między 10, a 15 sekund.

j. Po przejściu ścieżki scenariusza użytkownicy powtarzają pełną ścieżkę scenariusza.

k. Test wydajności w oparciu o plan testów będzie wykonywany przez Wykonawcę raz na kwartał i jego wynik będzie przedstawiany Zamawiającemu w zestawieniu zawierającym poprzednie testy.

l. Pierwszy test będzie testem bazowym, względem którego badana będzie wydajność systemu.

7) Monitoring ciągłości działania Systemu 24 godziny na dobę w celu szybkiego wykrywania i reagowania na Awarie i Błędy krytyczne. Czas usunięcia Awarii i Błędu krytycznego liczy się od momentu jego wystąpienia ustalonego w oparciu o dane z systemu do monitorowania, logów, zgłoszeń Użytkowników. Zamawiający udostępni Wykonawcy system monitoringu Zabbix oraz Dynatrace i dopuści ich dowolną konfigurację w zakresie monitorowania komponentów Systemu.

Dostępność Systemu będzie mierzona i rozliczana przy pomocy usługi monitorowania dostępność Portali w Internecie, dostarczonej przez podmiot trzeci niezależny od Zamawiającego i Wykonawcy. Koszt usługi monitorowania ponosi Zamawiający. Obecnie wykorzystywana jest usługa dostarczana przez xxxx00x0.xxx

Wykonawca zobowiązany jest w ciągu 30 dni od podpisania Umowy oprogramować skrypt, który pozwoli usłudze monitorującej na logowania i otwierania wskazanych podstron w każdym z Portali. Niedostępność Systemu będzie liczona dla każdej instancji Portalu osobno. Niedostępność jednej aplikacji portalowej będzie traktowana jako niedostępność jednej ułamkowej części całości Systemu. W przypadku niedostępności wykazanej w monitoringu, a niezależnej od Wykonawcy Wykonawca nie ponosi odpowiedzialności za niedostępność, ale zobowiązany jest wskazać przyczyny tej niedostępności, wykazać prawidłowe działanie Systemu. Wykonawca wskaże adres mailowy na który będą wysyłane powiadomienia.

8) Lista komponentów, które będą monitorowane i za pomocą którego narzędzia, zostaną ustalone pomiędzy Stronami na spotkaniu inicjującym lub w toku dalszych ustaleń w trakcie realizacji Umowy. Wykonawca zobowiązany jest przedstawiać do 10 dnia następnego miesiąca Raport z monitorowania Systemu zgodny ze wzorem ustalonym między Stronami na spotkaniu inicjującym lub w toku dalszych ustaleń w trakcie realizacji Umowy. Raport z monitorowania Systemu powinien zawierać, co najmniej:

a. okres raportowania,

b. monitorowany komponent Systemu,

c. czas niedostępności/nieprawidłowego działania dla każdego wystąpienia takiego zdarzenia,

d. odniesienie do zgłoszenia w systemie zgłoszeniowym,

e. klasyfikacja Błędu,

f. podsumowanie miesięczne niedostępności/nieprawidłowego działania komponentu.

g. uwagi i rekomendacje.

Zamawiający zastrzega sobie prawo do instalowania w systemach operacyjnych Systemu dodatkowych komponentów monitorujących lub zarządzających (np. agent monitorujący sesje logowania, agent oprogramowania APM) po wcześniejszym poinformowaniu Wykonawcy. Instalacji dokonuje Zamawiający lub Wykonawca w zależności od ustaleń pomiędzy stronami. Komponenty zainstalowane w tym trybie nie podlegają utrzymaniu przez Wykonawcę.

9) Monitorowanie wszystkich certyfikatów SSL wykorzystywanych w Systemie pod kątem ich ważności i informowanie Zamawiającego o wygaśnięciu na 30 do 50 dni przed datą wygaśnięcia. W przypadku wygaśnięcia certyfikatu bez poinformowania Zamawiającego w ww. terminie, zdarzenie będzie odnotowane jako Błąd Krytyczny od momentu wygaśnięcia certyfikatu.

10) Wymiarowanie Systemu i przygotowywanie rekomendacji w celu uniknięcia spadku wydajności (w tym zakresie optymalizacji miejsca na Infrastrukturze centralnej Zamawiającego) oraz Błędów i Awarii, które Wykonawca uwzględnia w raporcie, o którym mowa w pkt 6 powyżej.

11) Wykonawca odpowiada za optymalizację baz danych.

12) W braku przeciwnych postanowień wynikających z Umowy lub Zlecenia czy Zgłoszenia, Wykonawca jest zobowiązany zapewnić wszelkie narzędzia bez odrębnego wynagrodzenia, w tym oprogramowanie i inne zasoby potrzebne mu do realizacji Umowy. O ile Umowa lub Zlecenie czy Zgłoszenie nie stanowi inaczej, Zamawiający nie ma obowiązku udostępniać Wykonawcy żadnego innego oprogramowania poza Systemem. Powyższe nie wyłącza zobowiązania Zamawiającego do współdziałania opisanego Umową i przepisami prawa.

13) Zamawiający zastrzega sobie prawo do korzystania w trakcie wykonywania Umowy z usług osób trzecich celem kontroli jakości i sposobu prowadzenia całości lub poszczególnych prac objętych Umową, jak również do przeprowadzania takich kontroli samodzielnie. Zamawiającemu lub osobom trzecim, posiadającym pisemne upoważnienie ze strony Zamawiającego, Wykonawca zobowiązany będzie udzielić niezwłocznie (nie później jednak niż w terminie 3 Dni roboczych od dnia otrzymania

żądania) wszelkich informacji, danych i wyjaśnień w żądanym zakresie, w tym przyczyn opóźnień lub przyczyn nienależytego wykonywania Usług oraz udostępnić i zaprezentować produkty (w tym także w postaci nieukończonej), jak również zapewnić możliwość ich kontroli.

14) Wykonawca będzie zarządzał kontami deweloperskimi w Google Play oraz App Store w obszarze Aplikacji Mobilnej Portalu Informacyjnego. Zarządzanie obejmuje:

1) Aktualizacje AM PI,

2) Stosowanie się do regulaminów i zasad panujących w sklepach,

3) Śledzenie komentarzy i przekazywanie Zamawiającemu istotnych wniosków użytkowników, odpowiadanie na istotne komentarze użytkowników.

Zamawiający przekaże Wykonawcy dostępy do sklepów. Wykonawca nie odpowiada za ponoszenie kosztów funkcjonowania kont deweloperskich w sklepach.

4.8.1.2. Wymogi dotyczące bezpieczeństwa

1) Wykonawca zapewnia wysokie bezpieczeństwo danych przetwarzanych w Systemie stosując się do poniższych wymagań:

a. ograniczanie dostępu do informacji (funkcjonalności zapewniające możliwość ograniczenia dostępu do Systemu),

b. procedury bezpiecznego logowania,

c. dokumentowanie procedur eksploatacyjnych (Dokumentacja Systemu),

d. zarządzanie pojemnością (zapewnienie odpowiedniej wydajności Systemu i jej monitorowania),

e. oddzielanie środowisk technologicznych,

f. rejestrowanie zdarzeń (np. zapewnienie mechanizmów rejestrowania zdarzeń),

g. ochrona informacji w dziennikach zdarzeń (funkcjonalność zabezpieczenia logów Systemu),

h. rejestrowanie działań administratorów i operatorów (działania wykonywane administratorów i operatorów systemów muszą być rejestrowane, a logi zabezpieczone),

i. synchronizacja zegarów,

j. ochrona transakcji usług aplikacyjnych (zastosowanie mechanizmów zabezpieczających przed przerwaniem transmisji, nieuprawnionymi zmianami wiadomości, powieleniem itp.),

k. testowanie bezpieczeństwa Systemu,

l. ochrona danych testowych,

m. prywatność i ochrona danych identyfikujących osobę (w zakresie zapewnienia przez System zabezpieczeń danych osobowych zgodnych z wymogami prawnymi).

2) W przypadku powstania z winy Wykonawcy niedającego się usunąć uszkodzenia danych lub naruszenia ich spójności, lub wycieku danych Wykonawca jest zobowiązany do: usunięcia i naprawienia skutków uszkodzenia lub wycieku, lub pokrycia kosztów naprawy (według wyboru Zamawiającego), na zasadach i w terminach wskazanych przez Zamawiającego.

3) Wykonawca przeprowadzi wstępny audyt bezpieczeństwa Systemu w terminie do 4 miesięcy od momentu podpisania Umowy oraz przeprowadzi kolejne audyty raz na

12 miesięcy w terminie zleconym przez Xxxxxxxxxxxxx zgodnie z wymogami opisanymi w Załączniku nr 5 do OPZ – Wymagania audytu bezpieczeństwa.

4.8.2. Zasady realizacji Usługi wsparcia technicznego i serwisu

1) Realizacja Usługi wsparcia technicznego i serwisu będzie realizowana w trybie całodobowym, przy czym będzie wykonywana w sposób niezakłócający normalnego funkcjonowania Użytkownika końcowego pomiędzy godziną 6:00 a 22:00 w Dni robocze. Wszelkie planowe działania ograniczające dostępność, responsywność i funkcjonalność Systemu mogą być prowadzone w Dni robocze godzinach od 22:00 do 6:00 i w dni wolne po uprzednim wyznaczeniu przez Zamawiającego okna serwisowego. W szczególnych przypadkach Zamawiający może wyznaczyć inne okno serwisowe. W każdym przypadku okno serwisowe wyznacza się min. na 14 dni kalendarzowych przed planowanymi pracami. W szczególnych przypadkach Zamawiający może zaakceptować skrócenie czasu na wyznaczenie okna serwisowego.

2) Monitorowanie dostępności aktualizacji i nowych wersji komponentów Systemu oraz ich instalacja w Infrastrukturze centralnej.

3) Realizacja Usługi wsparcia technicznego i serwisu będzie wykonywana z należytą starannością, zgodnie z wytworzoną w ramach realizacji i utrzymania Systemu Dokumentacją oraz zasadami współczesnej wiedzy technicznej.

4) Realizacja dostępu do Infrastruktury centralnej lub do Infrastruktury lokalnej odbywać się będzie przez sieć VPN udostępnioną wskazanym członkom Personelu Wykonawcy przez Zamawiającego. Dla Infrastruktury centralnej, dostęp uprzywilejowany realizowany będzie za pośrednictwem narzędzia FUDO PAM (kontrola sesji zdalnych). Dostęp VPN wymaga, aby pracownik Wykonawcy posiadał telefonu do obsługi haseł oraz działania aplikacji do dwu-składnikowej autentykacji.

5) Wykonawca zapewnia obsługę niemożliwych do zdiagnozowania i usunięcia w sposób zdalny (za pośrednictwem łącza VPN lub telefonicznie) Wad na miejscu u Użytkownika Końcowego lub u Zamawiającego przez specjalistę ze strony Wykonawcy, za uprzednią zgodą Zamawiającego.

6) Wykonawca zobowiązany jest przedstawiać wraz z Protokołem odbioru wsparcia technicznego i serwisu za dany miesiąc Raport zawierający informację o zamkniętych w danym miesiącu zgłoszeniach wraz z wyjaśnieniem przekroczeń czasu ich realizacji (o ile dotyczy), zgodny ze wzorem ustalonym w porozumieniu z Zamawiającym w ciągu 30 dni od dnia zawarcia Umowy.

7) Do zgłaszania Wad na środowiskach technologicznych innych niż produkcyjne uprawniony jest wyłącznie Zamawiający.

8) Zamawiający informuję, że w okresie 03.2018 r. – 07.2021 r. liczba Zgłoszeń wyglądała w następujący sposób:

Dodatkowe informacje	wartość	uwagi
max liczba zgłoszeń w miesiącu (dane historyczne)	1337	kwi.19
min liczba zgłoszeń w miesiącu (dane hi storyczne)	321	maj.20
średnia liczba zgłoszeń w miesiącu (dane historyczne)	815
szacunkowa spodziewana liczba zgłoszeń rocznie	12225

Liczba zgłoszeń przekazanych do Wykonawcy (III linia wsparcia) w poszczególnych miesiącach.

1400

1200

1000

800

600

400

200

0

mar.18 maj.18 lip.18 wrz.18 lis.18 sty.19 mar.19 maj.19 lip.19 wrz.19 lis.19 sty.20 mar.20 maj.20 lip.20 wrz.20 lis.20 sty.21 mar.21 maj.21

lip.21

4.8.3. Rodzaje kwalifikacji Zgłoszeń oraz czas ich realizacji dla środowisk technologicznych Zamawiającego

Rodzaj problemu	Opis	Priorytet w Systemie Zgłoszeniowym	Czas na usunięcie Wady
Awaria	Zatrzymanie eksploatacji Systemu, brak dostępności lub miejsca na zasobie w Infrastrukturze centralnej, wyciek danych, utrata danych lub naruszenie ich spójności, w wyniku której niemożliwe jest prowadzenie bieżącej działalności Systemu. Za Awarie uznawane jest również jednoczesne wystąpienie szeregu Błędów Krytycznych w przypadku kiedy można wykazać, że ich wystąpienie ma ten sam skutek.	krytyczny	Do 4 godzin od wystąpienia Awarii, a w przypadku braku możliwości ustalenia czasu wystąpienia Awarii (w szczególności w oparciu o informacje pochodzące z monitoringu Wykonawcy lub Zamawiającego) od momentu zgłoszenia Awarii przez Zamawiającego lub Użytkownika Końcowego
	Szczególne przypadki Awarii:
	brak importów danych lub eProtokołu z 75% lokalizacji w pojedynczej apelacji w danym dniu,
	- brak importów danych lub eProtokołu ze 100 lub większej liczby sądów w danym dniu,
	- brak dostępności dokumentów lub eProtokołu z powodu niedostępności zasobów lub z nieprawidłowego zapisania ścieżek dostępu w bazie danych,

Rodzaj problemu	Opis	Priorytet w Systemie Zgłoszeniowym	Czas na usunięcie Wady
	- brak możliwości wykorzystania dowolnej metody uwierzytelniania w dowolnej apelacji w aplikacjach PI/AM/PA, - incydenty bezpieczeństwa wynikające z błędu Systemu lub pomyłki ludzkiej polegające na ujawnieniu dokumentu, sprawy lub innych danych osobie nieuprawnionej, wymagające reakcji polegającej na odebraniu dostępu lub anonimizacji ujawnionych treści.
Błąd Krytyczny	Błąd uniemożliwiający poprawne wykorzystanie Systemu lub jego istotnej funkcjonalności do realizacji procesów biznesowych. Zakłócenie pracy Systemu polegające na ograniczeniu realizacji lub uciążliwości w realizacji jednej z funkcji Systemu. Działanie Systemu prowadzące do otrzymywania błędnych wyników przetwarzania danych lub praca Systemu niezgodna z Dokumentacją. Po udostępnieniu rozwiązania czasowego pozwalającego na realizację błędnie działającej usługi (wdrożeniu Obejścia) Błąd Krytyczny staje się Błędem Niekrytycznym. Jako Błąd Krytyczny rozumiemy również błąd mogący powodować lub powodujący przełamanie zabezpieczeń związanych z poufnością, integralnością i dostępnością Systemu i danych oraz niezgodność z Dokumentacją bezpieczeństwa, w tym w szczególności SZBI Zamawiającego.	wysoki	Do 48 godzin od wystąpienia Błędu Krytycznego (w szczególności w oparciu o informacje pochodzące z monitoringu Wykonawcy lub Zamawiającego), a w przypadku braku możliwości ustalenia czasu wystąpienia Błędu Krytycznego od momentu zgłoszenia Błędu Krytycznego przez Zamawiającego lub Użytkownika Końcowego
Błąd Niekrytyczny	Zakłócenie pracy Systemu mogące mieć wpływ na jego funkcjonalność, natomiast nieograniczające zdolności operacyjnych Systemu w obrębie obsługi i wspomagania procesów biznesowych, niebędące Awarią, ani Błędem Krytycznym.	średni	Xx 0 Xxx xxxxxxxxx od daty zgłoszenia przez Zamawiającego lub Użytkownika Końcowego
	Błędy Niekrytyczne to w szczególności błędy drobne, błędy ergonomiczne lub błędy kosmetyczne, literówki błędy walidacji, błędy formatu pól i kontrolek ( konieczność zbędnych „kliknięć” w celu uzyskania pożądanego przez użytkownika rezultatu, błędy w interfejsie użytkownika dotyczące istniejących funkcjonalności biznesowych powodujące ograniczenie wydajności i ergonomii pracy użytkownika, zbyt mała lub duża długość pola, nieposortowane wartości list rozwijanych, błąd

Rodzaj problemu	Opis	Priorytet w Systemie Zgłoszeniowym	Czas na usunięcie Wady
	lub brak możliwości sortowania i filtrowania po istniejących atrybutach, błędne etykiety, błędne nazw atrybutów, błędne wartości słownikowe, złe linkowanie opcji w aplikacji, braki komunikatów, nadmiarowe komunikaty, błędne treści komunikatów, brak obsługi błędów wewnętrznych właściwym komunikatem.
Błąd importu danych źródłowych	Brak lub błąd importu danych z systemu źródłowego w szczególności wynikający z: - błędu, braku lub nieaktualnej wersji usługi uruchamiającej importy danych,	średni	Do 48 godzin od wystąpienia pierwszego ze zdarzeń : - zidentyfikowania braku lub błędu importu (za pomocą informacji pochodzących z monitoringu Wykonawcy lub Zamawiającego, logów lub istniejących narzędzi Systemu w tym w szczególności SMIPI) lub - daty zgłoszenia przez Zamawiającego lub Użytkownika Końcowego
	- braku uprawnień użytkownika systemowego do uruchamiania usługi uruchamiającej importy danych,
	- braku uprawnień użytkownika systemowego do zasobów dyskowych koniecznych do działania usługi uruchamiającej importy danych i samych importerów danych,
	- błędów, braku lub nieaktualnej wersji aplikacji importerów (np. Dossier, Eprotokół, SMIPI)
	- uszkodzeń lokalnych baz importerów lub API,
	- błędnych zmian lub ustawień w konfiguracji lokalnej lub centralnej,
	- ograniczenia lub braku dostępu do baz danych SRB i wspomagających sekretariaty sądowe (np. CAPE, CRCS/RCS), jeśli systemy te będą wykorzystywane do zasilania Systemu.
	- z ograniczenia lub braku dostępu do zasobów dyskowych z nagraniami i dokumentami.
	Naprawa błędów importerów lokalnych polega na pełnym przywróceniu ich funkcjonalności potwierdzonego dokonaniem skutecznego importu danych (nocny import przyrostowy). Wykonawca powinien usunąć błąd przy wykorzystaniu narzędzi zdalnego dostępu i diagnostyki zdalnej, a w przypadku nie uzyskania dostępów do zasobów serwerów lokalnych, gdzie uruchomiona jest usługa importu, naprawa polegać musi na precyzyjnym wskazaniu przyczyn wystąpienia błędu i wsparciu Administratora Lokalnego Systemu w jego rozwiązaniu za pośrednictwem systemu zgłoszeniowego, mailowo lub telefonicznie. Do diagnozy przyczyn błędu Wykonawcy powinny

Rodzaj problemu	Opis	Priorytet w Systemie Zgłoszeniowym	Czas na usunięcie Wady
	posłużyć pliki konfiguracyjne i logi (importera, systemowe lub inne) uzyskane: - samodzielnie przez Wykonawcę z Systemu za pomocą narzędzia SMIPI lub - przekazane Wykonawcy przez Administratora, Administratora Lokalnego Systemu lub pracownika linii wsparcia. Jeśli poziom logowania jest niewystarczający Wykonawca w ramach usługi utrzymania powinien wprowadzić konieczne zmiany do Systemu zwiększające poziom logowania. Szczegółowa procedura realizacji Zgłoszenia, którego źródło zidentyfikowane zostało po stronie Użytkownika Końcowego w lokalnej Infrastrukturze systemowej opisana jest w pkt. 4.8.41
Konfiguracja	1) Dostosowanie Systemu z uwagi na: a. zmiany organizacyjno - administracyjnych sądów, w tym w szczególności utworzenie nowego sądu, likwidacja sądu, utworzenie nowego wydziału, likwidacja wydziału, dodanie lub usunięcie repertorium/wykazu, zmiana zakresu publikacji, b. zmiany w środowisku teleinformatycznym Użytkownika Końcowego i Zamawiającego, c. zmiany w konfiguracji sieci WAN w oparciu, o którą funkcjonuje System, d. aktualizacje przeglądarek internetowych, prawidłowe wyświetlanie i funkcjonowanie na aktualnej stabilnej i jednej poprzedzającej ją wersji dla przeglądarek internetowych: Firefox, Opera, Safari, Chrome, Edge. e. zgodność z aktualną wersją WCAG lub zastosowanie odstępstwa po uwzględnieniu przez Zamawiającego uzasadnienia, f. przeprowadzone przez Zamawiającego audyty Systemu poprzez uwzględnienie ich wyników, g. potrzebę aktualizacji środowiska technologicznego.	niski	W terminie 5 Dni roboczych lub w wyjątkowych sytuacjach w innym terminie wnioskowanym przez Wykonawcę i potwierdzonym przez Zamawiającego. Liczba wydłużonych terminów konfiguracji powyżej 5 Dni roboczych nie może przekroczyć 5 w miesiącu.
	2) Instalacja poprawek i nowych wersji do środowiska technologicznego Systemu.

Rodzaj problemu	Opis	Priorytet w Systemie Zgłoszeniowym	Czas na usunięcie Wady
	3) Analiza i przeciwdziałanie zagrożeniom wynikającym z podatności komponentów Systemu lub systemów operacyjnych w Infrastrukturze Centralnej na cyberprzestępczość. 4) Optymalizacja funkcjonowania Systemu w uzgodnieniu z Zamawiającym, obejmująca optymalizację kodu źródłowego Systemu, systemu baz danych w Infrastrukturze Centralnej, serwerów aplikacyjnych. 5) Instalacja usług, konfigurację serwera i systemu operacyjnego, konfiguracja dostępu do lokalnych i sieciowych zasobów dyskowych, macierzy, baz danych. 6) Aktualizacja Dokumentacji i kodów źródłowych. 7) Migracja systemu SRB. 8) Wdrożenie u Użytkownika końcowego nowego regulaminu lub zarządzenia do regulaminu dotyczącego Portalu. Obejmuje działania wyłącznie zaplanowane lub związane z uruchomieniem nowych usług/modyfikacji oraz funkcjonalności. Nie obejmuje usług utrzymania i serwisu związanego z Wadami wynikającymi z nieprzewidzianych i nieuzgodnionych zmian środowiska i plików konfiguracyjnych po stronie lokalnej w systemach zintegrowanych, w sądach i po stronie centralnej, które powodują brak lub częściowy brak zasilania systemu danymi.
Wniosek o informację	Udzielenie informacji dotyczącej funkcjonowania Systemu lub dotyczącej realizacji przedmiotu Umowy	niski	W terminie 3 Dni roboczych lub innym terminie wskazanym przez Zamawiającego lub w terminie wnioskowanym przez Wykonawcę i potwierdzonym przez Zamawiającego.

4.8.4. Procedura realizacji Zgłoszeń (Awaria, Błąd Krytyczny, Błąd Niekrytyczny, Konfiguracja, Wniosek o informację)

1) Zamawiający przewiduje następujące kanały komunikacji - za pośrednictwem:

a. systemu zgłoszeniowego udostępnionego przez Zamawiającego (podstawowy), zwany dalej „Systemem Zgłoszeniowym”. W przypadku Zgłoszeń typu Awaria Zamawiający zastrzega sobie prawo dodatkowego

opcjonalnego zgłoszenia telefonicznego lub sms-owego na całodobowy numer wskazany przez Wykonawcę;

b. dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą w przypadku niedostępności kanału podstawowego;

c. Zamawiający zastrzega sobie możliwość zmiany Systemu Zgłoszeniowego w trakcie trwania Umowy.

2) Nazwy „Rodzajów problemów” i „Priorytety” mogą być podczas trwania Umowy dostosowywane do użytkowanego Systemu Zgłoszeniowego, ale nie będą powodowały zmian „Czasów usunięcia Wad” oraz określonych Opisem definicji poszczególnych rodzajów problemów.

3) Zamawiający kategoryzuje Zgłoszenia na formularzu zgłoszenia zgodnie z kwalifikacją określoną w tabeli zawierającej rodzaje kwalifikacji Zgłoszeń (pkt 4.6.3.). Zamawiający ma prawo dokonać korekty kwalifikacji każdego Zgłoszenia w celu dostosowania, zgodnie z rzeczywistym stanem faktycznym, kategorii Zgłoszenia według kwalifikacji określonej w tabeli zawierającej rodzaje kwalifikacji Zgłoszeń.

4) Po zmianie kategorii Zgłoszenia, jego sposób realizacji określany jest przez nową kategorię Zgłoszenia, a czas realizacji w przypadku zmiany kategorii na wyższą liczony jest od momentu poinformowania Wykonawcy o zmianie kategorii w Systemie Zgłoszeniowym.

5) Za realizację Zgłoszenia uważa się dostarczenie poprawki na środowisko technologiczne, którego dotyczy Wada, chyba, że Zamawiający w treści Zgłoszenia wskaże inne środowisko technologiczne lub Wykonawca wskaże, że wgranie poprawki wymaga okna serwisowego.

6) Wykonawca jest uprawniony do trzykrotnego zwrócenia się do Użytkownika Końcowego o udzielenie wyjaśnień. Czas odpowiedzi Użytkownika Końcowego nie jest w takim wypadku wliczany do czasu realizacji Zgłoszenia.

7) Prawidłowa realizacja Zgłoszenia, musi być odnotowana w Systemie Zgłoszeniowym. Zamawiającemu lub Użytkownikowi Końcowemu przysługuje prawo do zgłoszenia reklamacji prawidłowości rozwiązania. Czas poświęcony na weryfikację Zgłoszenia (od zamknięcia Zgłoszenia do otwarcia w wyniku reklamacji) nie jest wliczany w czas jego realizacji przez Wykonawcę. Reklamacje w zakresie prawidłowości rozwiązania Zgłoszenia mogą być zgłaszane w terminie 30 dni kalendarzowych od zamknięcia Zgłoszenia. W przypadku ponownego otwarcia Zgłoszenia w wyniku reklamacji Zamawiającego lub Użytkownika kary umowne w przypadku zwłoki Wykonawcy nalicza się w podwójnej wysokości.

8) Wykonawca zaktualizuje Dokumentację, jeżeli w wyniku realizacji zgłoszenia jest to wymagane w terminie, o którym mowa w pkt 4.12.1 pkt 5).

9) W sytuacji, kiedy rozwiązanie Zgłoszenia wymaga zainstalowania Modyfikacji Systemu, Strony ustalają w drodze porozumienia indywidualny termin realizacji Zgłoszenia. Nie dotyczy Awarii.

10) Uwagi zgłoszone przez Użytkowników Końcowych bezpośrednio do Wykonawcy, dotyczące funkcjonowania i funkcjonalności, a skutkujące Modyfikacjami Systemu, będą niezwłocznie, tj. nie później niż w ciągu 2 Dni roboczych przekazywane do Zamawiającego za pośrednictwem uzgodnionego między Stronami kanału komunikacyjnego.

4.8.41 Szczególna procedura realizacji zgłoszeń typu Błąd importu danych źródłowych w Infrastrukturze systemowej (lokalnej)

Procedura obsługi zgłoszeń dla Błędu importu danych źródłowych, których źródło zidentyfikowane zostało po stronie Użytkownika Końcowego w lokalnej Infrastrukturze systemowej.

1. Jeśli ze wstępnej analizy zgłoszenia w tym z logów pobranych za pomocą SMIPI wynika, że problem dotyczy części lokalnej infrastruktury systemowej (Użytkownik Końcowy - po stronie sądu), Wykonawca musi ciągu 2 godzin (w godzinach pracy sądu – Użytkownika Końcowego) wysłać za pomocą systemu zgłoszeniowego żądanie do Użytkownika Końcowego nawiązania kontaktu za pomocą narzędzia pomocy zdalnej i przekazania mu nr. kontaktowego wykorzystywanego do połączenia głosowego podczas sesji pomocy zdalnej.

2. Przekazanie zgłoszenia do Użytkownika Końcowego wstrzymuje bieg czasu realizacji Zgłoszenia po stronie Wykonawcy.

3. W przypadku braku odpowiedzi od Użytkownika Końcowego lub braku danych koniecznych do zestawienia połączenia zdalnego, Wykonawca po 24 godzinach musi przejąć zgłoszenie i przekazać zgłoszenie do II linii wsparcia, co wstrzymuje bieg czasu realizacji zgłoszenia po stronie Wykonawcy. Pozostawienie zgłoszenia przez Wykonawcę powyżej 24 godzin po stronie Użytkownika Końcowego wznawia bieg terminu realizacji zgłoszenia po stronie Wykonawcy.

4. Po ustaleniu terminu połączenia zadanego przez II linię wsparcia, zgłoszenie zostaje przekazane do Wykonawcy, który podejmując to zgłoszenie, ma prawo w oczekiwaniu na nawiązanie połączenia zdalnego przekazać zgłoszenie do Użytkownika Końcowego, co wstrzymuje czas realizacji zgłoszenia po stronie Wykonawcy.

5. Po zakończonej sesji połączenia zdalnego, Użytkownik Końcowy przekazuje zgłoszenie do Wykonawcy, a jeśli tego nie zrobi, Wykonawca sam przejmuje zgłoszenie na siebie. Zakończenie sesji połączenia zdalnego wznawia termin realizacji zgłoszenia dla Wykonawcy.

6. Wykonawca dołoży należytych starań, by minimalizować czas połączenia zdalnego, a bezczynność Wykonawcy podczas połączenia zdalnego powyżej 10 minut będzie traktowana jak zakończenie połączenia.

7. Podczas sesji nadzorowanego połączenia zdalnego, Wykonawcy musi asystować przedstawiciel Użytkownika Końcowego (administrator systemu), który będzie w ciągłym kontakcie telefonicznym z Wykonawcą.

8. Podczas sesji zadanej Wykonawca musi zebrać wszelkie wymagane do naprawy problemu informacje i/lub dokonać koniecznych napraw.

9. Wykonawca może dodatkowo trzykrotnie dopytać (także połączyć się zdalnie zgodnie ze wcześniejszymi krokami) Użytkownika Końcowego o informacje uzupełniające, konieczne do naprawy zgłoszenia zgodnie z zapisem 4.8.4 pkt. 6 lub może przekazać Użytkownikowi Końcowemu rozwiązanie problemu.

10. Trzy pierwsze pytania (w tym połączenia zdalne) kierowane w ramach obsługi zgłoszenia do Użytkownika Końcowego wstrzymują czas realizacji do chwili udzielenia odpowiedzi lub zakończenia połączenia zdalnego. Kolejne pytania (w tym połączenia zdalne) i czas udzielania odpowiedzi (realizacji połączenia) wliczają się czas realizacji zgłoszenia po stronie Wykonawcy.

11. Wykonawca zobowiązany jest po wdrożeniu rozwiązania problemu zweryfikować poprawność naprawianego Błędu importu i zamknąć zgłoszenie lub w szczególnych przypadkach przekazać je do II linii wsparcia, o ile takie było żądanie ze strony II linii wsparcia lub Zamawiającego.

Niedopuszczalna jest sytuacja przekazanie zgłoszenia bez dostarczenia finalnego rozwiązania tj. ujawnienia importowanych danych w Portalu Informacyjnym lub Panelu Administracyjnym.

a) W przypadku przekroczenia czasu 48 godzin przewidzianych umownie na realizację zgłoszenia (sumaryczny czas realizacji zgłoszenia, niezależnie od linii wsparcia, na której zgłoszeni przebywało), przed Zamknięciem zgłoszenia Wykonawca załącza w systemie zgłoszeniowym: a) Szczegółowy Raport Realizacji Zgłoszenia (SRRZ) zawierający, nr incydentu/zgłoszenia,

czasy skrajne poszczególnych działań/zdarzeń, czas trwania poszczególnych działań/zdarzeń, ewentualne uwagi oraz wykazuje ewentualny czas przekroczenia realizacji całości zgłoszenia. Zamknięcie zgłoszenia bez SRRZ będzie uważane za nieskuteczne do czasu zamieszczenia tego raportu. Format SRRZ (plik Excel) zostanie uzgodniony na spotkaniu inicjującym utrzymanie.

b) Raport konfiguracji SMIPI wykonany na serwerze w lokalnej infrastrukturze systemowej , gdzie zainstalowane są usługi importu danych, eProtokołu i SMIPI. Wszystkie usługi importu wg. raportu muszą być sprawne.

12. Narzędzie TeamViewer Corporate Edition dla Wykonawcy do obsługi połączeń zdalnych dostarcza Zamawiający. Użytkownik Końcowy korzysta z narzędzia TeamViewer QuickSupport. Ewentualna zmiana narzędzia nie wymaga aneksowania Umowy.

13. Kategoryczna odmowa udzielenia dostępu zdalnego Wykonawcy przez Użytkownika Końcowego do infrastruktury lokalnej systemu, nie zwalnia Wykonawcy z realizacji zgłoszenia, jednak priorytet zgłoszenia zostaje automatycznie obniżony do Błędu niekrytycznego (5 dni roboczych), o czym Wykonawca informuje Zamawiającego w treści zgłoszenia i w SRRZ wskazując zdarzenie odmowy dostępu zdalnego ze strony Użytkownika Końcowego. Raport SMIPI wykonuje z dedykowanej stacji przesiadkowej, a w szczególnych przypadkach po uzyskaniu zgody Zamawiającego z własnego komputera podłączonego poprzez VPN do sieci WAN MS sądów.

14. Wykonawca w celu rozwiązania zgłoszenia typu Błąd importu danych źródłowych musi świadczyć Użytkownikowi Końcowemu wsparcie w obrębie działania Systemu x.xx. z zakresu:

a) infrastruktury systemowej,

b) prawidłowej konfiguracji systemu Windows,

c) konfiguracji reguł zapory aplikacyjnej zainstalowanej na serwerze Windows, d) konfiguracji usługi importującej,

e) definiowania dostępu i nadawania uprawnień do zasobów lokalnych i zdalnych,

f) definiowania użytkowników wymaganych do działania oprogramowania importującego.

4.8.5. Procedura zgłaszania Zamawiającemu konieczności zainstalowania poprawek i nowych wersji oraz aktualizacji poszczególnych elementów Systemu dla środowisk technologicznych w Infrastrukturze centralnej

1) Systemy operacyjne oraz poprawki bezpieczeństwa:

1) Zamawiający wymaga, aby wersje (major) systemów operacyjnych były aktualizowane za uprzednią zgodą Zamawiającego, do najnowszych wydanych przez producenta w ciągu maksymalnie 5 miesięcy od daty wydania wersji stabilnej. Aktualizacja w przypadku systemów operacyjnych wymagających odpłatnych licencji komercyjnych, odbyć się może w ciągu maksymalnie 5

miesięcy od zatwierdzeniu takiej możliwości przez Zamawiającego. Wykonawca nie jest zobowiązany do dostarczania licencji systemów operacyjnych w ramach usługi wsparcia technicznego i serwisu.

Wykonawca informuje o wydaniu nowej wersji stabilnej (major) systemu operacyjnego Zamawiającego w terminie 2 tygodni od jej wydania.

2) Zamawiający wymaga, aby poprawki bezpieczeństwa systemów operacyjnych były instalowane w ciągu maksymalnie 7 dni od ich wydania przez producenta systemu operacyjnego.

2) Pozostałe komponenty Systemu:

1) Wykonawca monitoruje dostępne aktualizacje i nowe wersje OOT oprogramowania:

i) aplikacyjnego,

ii) bazodanowego,

iii) komunikacyjnego (o ile system zawiera tego typu oprogramowanie),

iv) do prezentacji treści,

v) oraz pozostałego oprogramowania technologicznego i narzędziowego Systemu.

2) Wykonawca przedstawia listę dostępnych poprawek i nowych wersji OOT do zainstalowania dla każdego środowiska technologicznego w cyklach kwartalnych. Zamawiający zawsze może żądać dodatkowego cyklu wykonania poprawek, lecz nie więcej niż dwa razy na kwartał.

3) Zamawiający w terminie 7 Dni roboczych od dnia dostarczenia listy poprawek do zainstalowania informuje Wykonawcę, które ze zgłoszonych poprawek będą podlegać realizacji.

4) Wykonawca przeprowadza wdrożenie poprawek podlegających realizacji w terminie 14 Dni roboczych od dnia przekazania zatwierdzenia ich przez Zamawiającego. W uzasadnionych przez Wykonawcę przypadkach, termin może zostać wydłużony przez Zamawiającego.

5) W uzasadnionych przez Wykonawcę przypadkach i po wcześniejszym powiadomieniu Zamawiającego, aktualizacja lub nowa wersja OOT może zostać wycofana do poprzedniej wersji.

6) Wykonawca zaktualizuje dokumentację Systemu wyszczególniając aktualnie zainstalowane wersje OOT.

4.8.6. Monitorowanie czasu dostępności Systemu

1) Wykonawca gwarantuje dostępność Systemu (rozumianą jako czas działania Systemu bez Awarii we wszystkich apelacjach jednocześnie) na poziomie co najmniej 99,98% w miesiącu kalendarzowym, z wyłączeniem okien serwisowych, na które Zamawiający wyraził zgodę.

2) Kalendarz dostępności dla Systemu - 24 godziny na dzień, 7 dni w tygodniu, 365 dni w roku (366 dni w roku przestępnym).

3) Komponenty objęte monitorowaniem:

i. Serwery aplikacyjne PI,

ii. Serwery aplikacyjne PA,

iii. Serwery SMIPI.

Do gwarantowanego poziomu dostępności Systemu nie jest wliczana jego niedostępność wynikająca z przyczyn leżących po stronie Zamawiającego polegających na zatrzymaniu lub zakłóceniu pracy Systemu w Infrastrukturze centralnej, spowodowanych działaniami Zamawiającego, w tym Awarią łączy teletransmisyjnych, awarią sprzętu komputerowego, awarią zasilania lub brakiem danych niezbędnych do odtworzenia Systemu.

Poziom dostępności Systemu obliczany jest wg wzoru:

(TD – Σ TN) / TD*100% [%]

gdzie:

TD – określony czas dostępności Systemu w okresie miesiąca kalendarzowego wynikający z Kalendarza dostępności Systemu po odjęciu uzgodnionych ograniczeń dostępności usługi (okien serwisowych) oraz niedostępności wynikających z przyczyn leżących po stronie Zamawiającego,

Σ TN – suma czasów niedostępności Systemu w okresie miesiąca kalendarzowego, gdzie czasem niedostępności Systemu jest czas, w którym w Systemie występuje Wada w kategorii: Awaria.

Wykonawca do 10 dnia każdego miesiąca dostarczy Zamawiającemu za poprzedni miesiąc Raport dostępności systemu uwzględniający:

• osiągnięty poziom dostępności systemu,

• wyszczególnienie okresów (data i czas od do) niedostępności systemu uwzględnionych w wliczanym poziomie dostępności systemu.

4.9. Usługa Modyfikacji Systemu

Szczegółowe zasady realizacji usługi Modyfikacji Systemu oraz przygotowania dokumentów analitycznych i innych dokumentów oraz projektów zmian w Systemie

4.9.1. Zakres usługi Modyfikacje Systemu

Maksymalna liczba roboczogodzin możliwych do zlecenia w ramach Modyfikacji wynosi 40 000, a minimalna liczba roboczogodzin jaka zostanie zlecona wynosi 5.000.

Usługa Modyfikacji Systemu obejmuje:

1) Modyfikacje Systemu;

2) przygotowywanie dokumentów analitycznych i innych dokumentów oraz projektów zmian w Systemie, w tym również aktualizacja Dokumentacji, przygotowywanie opinii na temat wykorzystania w Systemie nowych technologii lub sprzętu (dalej: „Prace analityczne”).

Zamawiający może zlecić w ramach puli Roboczogodzin przeznaczonych na Modyfikacje Systemu Prace analityczne. Procedury zlecenia i odbioru Modyfikacji Systemu stosuje się odpowiednio do zlecenia i odbioru Prac analitycznych.

4.9.2. Zasady realizacji usługi Modyfikacje Systemu

1) Realizacja Usługi Modyfikacje Systemu następuje na podstawie zleceń (dalej:

„Zlecenie”).

2) Dla Zlecenia i odbiór Prac analitycznych stosuje się odpowiednio zapisy dotyczące Modyfikacji.

3) Zamawiający może zlecić Wykonawcy Modyfikacje Systemu oraz Prace analityczne w okresie trwania Usługi wsparcia technicznego i serwisu. Termin

realizacji danego Zlecenia nie może wykraczać poza okres obowiązywania Umowy. Jeżeli w wyniku zwłoki Wykonawcy lub z innych przyczyn niezależnych od Wykonawcy lub Zamawiającego termin realizacji Zlecenia miałby ulec wydłużeniu i być dłuższy niż okres obowiązywania Umowy, Zamawiający dokonuje odbioru Zlecenia według stanu na ostatni dzień obowiązywania Umowy i dokonuje rozliczenia z Wykonawcą w oparciu o procentowany stan zaawansowania prac oraz nalicza kary umowne w przypadkach prawem przewidzianych. W przypadkach szczególnie uzasadnionych, w szczególności, gdy do wydłużenia terminu doszło z winy Zamawiającego lub wskutek działania Siły wyższej, lub zlecona usługa Modyfikacji ma istotne znaczenie dla Zamawiającego lub Użytkowników końcowych, odbiór Modyfikacji/Prac analitycznych może nastąpić po wygaśnięciu Umowy.

4) Dla każdej Modyfikacji Wykonawca przygotowuje projekt Modyfikacji zawierający elementy wskazane przez Zamawiającego, a w przypadku Modyfikacji o pracochłonności większej niż 400 Roboczogodzin dodatkowo harmonogram realizacji Modyfikacji.

5) Modyfikacja Systemu powoduje zmianę wartości major lub minor numeru wersji Systemu oraz konieczność instalacji nowej wersji Systemu zgodnie z procedurą opisaną w pkt 4.7.1. OPZ. Instalacja nowej wersji Systemu następuje na środowisku (lub środowiskach) wskazanym przez Zamawiającego w Zleceniu.

6) Do odbioru Modyfikacji Wykonawca zobowiązany jest przedstawić wszystkie wymagane przez Zamawiającego produkty, w tym zaktualizowaną Dokumentację.

7) Odbiór Modyfikacji/Prac analitycznych nastąpi Protokołem Odbioru Modyfikacji (wzór stanowi Załącznik nr 8 do Umowy).

4.9.3. Procedura zlecania Modyfikacji

1) Modyfikacje/Prace analityczne zlecane są za pośrednictwem wskazanego przez Zamawiającego Systemu Zgłoszeniowego (kanał podstawowy). Dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą tylko i wyłącznie w przypadku niedostępności kanału podstawowego.

2) Komunikacja Stron w zakresie realizacji Usługi Modyfikacja (dla Modyfikacji/Prac analitycznych) odbywa się w formie dokumentowej (w tym również oświadczenia Zamawiającego w zakresie akceptacji lub odrzucenia.

3) Procedura zgłaszania Zleceń Modyfikacji:

a. Zamawiający rejestruje w Systemie Zgłoszeniowym zgłoszenie wykonania usługi Modyfikacji wraz z podaniem wymagań oraz ewentualnie pożądanym terminem realizacji (dalej „Zlecenie”). Zamawiający w Zlecenie określa na jakim środowisku technologicznym nastąpi odbiór nowej wersji Systemu. Zamawiający może też wskazać szacowaną przez niego liczbę Roboczogodzin potrzebnych na realizację prac.

b. W ramach Zlecenia Modyfikacji Zamawiający może zażądać od Wykonawcy, co zostanie uwzględnione w treści Zlecenia, dodatkowo zestawu wymagań biznesowych oraz przypadków testowych z odpowiednią matrycą pokrycia wymagań przypadkami testowymi. Zarówno wymagania, jak i przypadki testowe zostaną dostarczone przez Wykonawcę w formacie umożliwiającym

ich import do narzędzia wskazanego przez Zamawiającego; testy manualne i automatyczne.

c. W odpowiedzi Wykonawca przedstawia Projekt Techniczny Modyfikacji (dalej „PTM”), w którym szczegółowo określa w szczególności termin realizacji Modyfikacji, szacowaną liczbę Roboczogodzin, zakres koniecznych zmian w Systemie oraz zakres niezbędnej Dokumentacji do wykonania/uzupełnienia. Wzór PTM stanowi Załącznik nr 3 do OPZ. W przypadku realizacji usługi Prace analityczne Wykonawca określa szacowaną liczbę Roboczogodzin oraz zakres niezbędnej Dokumentacji do wykonania/uzupełnienia.

d. Od momentu przedstawienia Zlecenia Wykonawca zobowiązany jest w terminie wskazanym przez Zamawiającego, nie krótszym niż 3 Dni robocze, przedstawić PTM, przy czym termin wykonania Modyfikacji powinien uwzględniać również czas potrzebny do przygotowania projektu Modyfikacji, harmonogramu realizacji Modyfikacji jeżeli jest wymagany, przeprowadzenia testów Modyfikacji oraz procedurę odbiorową. Zamawiający ma prawo wyznaczyć Wykonawcy ostateczny termin przedstawienia PTM, w przypadku naruszenia, którego, zostaną naliczone stosowne kary umowne zgodnie z postanowieniami Umowy.

e. Zamawiający zastrzega sobie prawo żądania szczegółowych wyjaśnień do przedstawionej wyceny pracochłonności oraz sposobu implementacji. Wykonawca zobowiązany jest do przedstawienia wyjaśnień w następnym Dniu Xxxxxxxx po otrzymaniu żądania. Na uzasadniony wniosek Wykonawcy termin ten może zostać wydłużony.

f. Strony ustalają w drodze porozumienia ostateczną pracochłonność i termin wykonania Modyfikacji. W przypadku braku porozumienia, po dwukrotnej nieudanej próbie uzgodnienia pomiędzy Stronami, Zamawiający ma prawo wybrać podmiot zewnętrzny, który dokona oceny pracochłonności z uwzględnieniem proponowanego terminu wykonania i zakresu Dokumentacji. Strony przyjmą tak określoną pracochłonność i termin, a koszty dokonania wyceny i opracowania opinii przez podmiot zewnętrzny pokryją w równych częściach Zamawiający i Wykonawca.

g. Zamawiający w terminie nie dłuższym niż 14 Dni roboczych potwierdza Zlecenie Modyfikacji lub rezygnuje z niego. Brak odpowiedzi Xxxxxxxxxxxxx uznać należy za bezterminowe zawieszenie realizacji Modyfikacji.

h. W przypadku rezygnacji ze Zlecenia Modyfikacji lub bezterminowego zawieszenia realizacji Modyfikacji za wykonane przez Wykonawcę czynności Strony rozliczają jak za usługę Prace analityczne, przy czym maksymalna kwota wynagrodzenia nie może być wyższa niż 20% szacowanej pracochłonności realizacji danej Modyfikacji.

i. Potwierdzenie Zlecenia Modyfikacji Systemu oznacza uzgodnienie przez Strony zakresu oraz terminu wykonania Modyfikacji, jej pracochłonności, wymaganej Dokumentacji oraz kryteriów jakościowych. Datą, od której jest liczony termin realizacji Modyfikacji jest data potwierdzenia Zlecenia w Systemie Zgłoszeniowym. Na uzasadniony wniosek Wykonawcy termin

realizacji Modyfikacji może zostać wydłużony. Zamawiający może również wstrzymać wykonanie Modyfikacji ze względu na pojawienie się innych priorytetowych Modyfikacji. Zamawiający może zrezygnować z dalszej realizacji Modyfikacji w przypadku ustania potrzeby wykonania tej Modyfikacji, a rozliczenie Modyfikacji nastąpi na podstawie wykonanych i odebranych prac.

j. Po potwierdzeniu Zlecenia przez Zamawiającego, ale przed przystąpieniem do wykonania Modyfikacji Systemu, Wykonawca przedstawia Zamawiającemu do akceptacji projekt Modyfikacji z elementami wskazanymi przez Xxxxxxxxxxxxx. Zamawiający dokona akceptacji projektu Modyfikacji lub zgłosi uwagi w terminie nie dłuższym niż 7 Dni roboczych od dnia przedstawienia projektu. W przypadku zgłoszenia uwag, Wykonawca przedstawi ponownie projekt do akceptacji w terminie nie dłuższym niż 2 Dni robocze.

k. W przypadku oszacowania Modyfikacji, której oszacowana pracochłonność przekraczająca 400 Roboczogodzin przed przystąpieniem do wykonania Modyfikacji Wykonawca oprócz projektu Modyfikacji przedstawia harmonogram realizacji Modyfikacji obejmujący wszystkie etapy realizacji z rozpisanymi zadaniami oraz wyszczególnionymi produktami i liczbą Roboczogodzin na poziomie zadań, który na żądanie Zamawiającego zostanie również przedstawiony za pomocą wykresu Gantta. W przypadku, gdy produkcyjne uruchomienie Modyfikacji będzie uzasadniało zwiększenie nakładów Wykonawcy na świadczenie Usługi wsparcia technicznego i serwisu Wykonawca przedkłada do Zamawiającego wniosek wraz z uzasadnieniem, przy czym jednorazowy wzrost miesięcznego ryczałtu nie może być wyższy niż 10% wartości Modyfikacji ustalonej między Stronami w Zleceniu. Zamawiający dokona akceptacji harmonogramu realizacji Modyfikacji lub zgłosi uwagi w terminie nie dłuższym niż 15 Dni roboczych od dnia przedstawienia harmonogramu. W przypadku zgłoszenia uwag, Wykonawca przedstawi ponownie harmonogram do akceptacji w terminie nie dłuższym niż 5 Dni Roboczych.

l. Na uzasadniony wniosek Wykonawcy terminy wskazane w lit. j-k mogą zostać wydłużone.

m. Wykonawca przystępuje do wykonania Modyfikacji po akceptacji przez Zamawiającego projektu Modyfikacji/ harmonogramu realizacji Modyfikacji. Projekt Modyfikacji/harmonogram realizacji Modyfikacji podlegają na bieżąco aktualizacji zgodnie z procedurą powyżej.

n. Na każdym etapie realizacji Strony mogą w drodze porozumienia dokonać stosownej aktualizacji Zlecenia w Systemie Zgłoszeniowym, w tym wydłużyć termin realizacji, zwiększyć ilość Roboczogodzin oraz zmienić kryteria jakościowe Modyfikacji.

4.9.4. Procedura odbioru Modyfikacji

1) Procedura odbioru Modyfikacji:

a. W przypadku usługi Prace analityczne, akceptacja przez Zamawiającego przygotowanych przez Wykonawcę dokumentów stanowi podstawę do odbioru i zamknięcia Zgłoszenia.

b. W przypadku wykonania Modyfikacji, Wykonawca przedstawia Zamawiającemu nową wersję Systemu wraz z Dokumentacją oraz Raport z testów Wykonawcy. Raport z testów Wykonawcy powinien zawierać co najmniej:

1. scenariusze testowe

2. rezultat przeprowadzonych testów:

1.1 manualnych,

1.2 automatycznych,

1.3 bezpieczeństwa.

3. data przeprowadzenia testów oraz imiona i nazwiska osób odpowiedzialnych za ich wykonanie,

4. data przeprowadzenia testów użyteczność interfejsu oraz imię i nazwisko osoby odpowiedzialnej za jego wykonanie,

5. analiza ryzyka pod kątem bezpieczeństwa zawierająca decyzję o ewentualnej konieczności wykonania audytu bezpieczeństwa całego modułu systemu, który był modyfikowany.

Scenariusze testowe muszą pokrywać wszystkie przypadki użycia rozwiązania oraz zawierać w każdym teście poza ścieżką podstawową co najmniej jedną ścieżkę alternatywną realizacji pracy. Scenariusze testowe zawierać będą co najmniej dane w zakresie:

i. Nr scenariusza

ii. Nr kroku testowego

iii. Opis czynności do wykonania

iv. Dane testowe

v. Użytkownik wykonujący (rola w systemie)

vi. Oczekiwany rezultat

vii. Odnotowanie uzyskanego w teście rezultatu

viii. Uwagi

Dodatkowo scenariusze testowe muszą być możliwe do zaimportowania w oprogramowaniu TestFLO Test Management for JIRA. Scenariusze testowe są elementem projektu Modyfikacji.

c. Zamawiający w terminie do 14 Dni roboczych weryfikuje przekazaną wersję sprawdzając, czy zostały uwzględnione wymagania określone w Zleceniu oraz w zaakceptowanym przez Zamawiającego projekcie Modyfikacji/harmonogramie realizacji Modyfikacji, a także czy przekazana wersja nie zawiera Wad, a Dokumentacja jest kompletna i spełnia kryteria jakościowe.

d. Wyniki weryfikacji Zamawiający przekazuje Wykonawcy drogą elektroniczną, w szczególności w postaci raportu z testowania wersji.

e. W przypadku zgłoszenia zastrzeżeń przez Zamawiającego względem dostarczonej Modyfikacji, Wykonawca dokona stosownych poprawek. Po ponownym dostarczeniu przez Wykonawcę Modyfikacji zostanie

przeprowadzony jej odbiór zgodnie z procedurą opisaną w lit. b – d. Terminowa realizacja Modyfikacji będzie dochowana pod warunkiem, że odbiór nastąpi w terminie ustalonym zgodnie z pkt 4.7.3. 3) lit. f.

f. W przypadku spełnienia warunków określonych w Zleceniu oraz braku Wad Zamawiający dokonuje odbioru Modyfikacji.

g. Prawidłowość wykonania Modyfikacji zostanie potwierdzona podpisanym bez zastrzeżeń przez obie Strony Protokołem Odbioru Modyfikacji.

h. W przypadku, gdy Modyfikacja została zainstalowana na innym środowisku niż produkcyjne na zlecenie Zamawiającego w terminie przez niego wskazanym Wykonawca dokona instalacji Modyfikacji na środowisku wskazanym przez Zamawiającego. W przypadku zwłoki Wykonawcy Zamawiający naliczy kary umowne jak za Błąd Niekrytyczny.

i. Wynagrodzenie Wykonawcy za wykonanie Modyfikacji lub za Prace analityczne będzie stanowić iloczyn faktycznie wykorzystanej liczby Roboczogodzin, potwierdzonej przez Zamawiającego, i wynagrodzenia brutto za jedną Roboczogodzinę Modyfikacji.

2) Po dokonaniu odbioru Modyfikacji Zamawiający zamyka Zgłoszenie w Systemie Zgłoszeniowym.

4.9.5. Zasady tworzenia kodu źródłowego

Kod źródłowy powstający w ramach Modyfikacji będzie spełniał następujące wymagania:

1) Kod źródłowy składa się z właściwego komentarza (opisu) zawierającego wyczerpującą zawartość informacyjną.

2) Opis należy sporządzać zgodnie z konwencją i najlepszymi praktykami w tym zakresie, dostosowując się do stosowanego języka oraz dedykowanego narzędzia.

3) Jako roboczą regułę wyznaczającą jakość opisu jest, aby komentować kod w taki sposób, jakiego tworzący komentarz programista sam by oczekiwał - co do zakresu, podejścia, zawartości, szczegółowości, konsekwencji w stylu, spójności konwencji itd. Minimalne wymagania to:

− Każda klasa (Systemu, formularzy, raportów itd.) musi zawierać kilkuzdaniowy komentarz opisujący, jakiego rodzaju obiekty generuje i jaka jest ich semantyka,

− Każdy atrybut każdej klasy musi zawierać komentarz opisujący jego znaczenie,

− Każda metoda każdej klasy musi zawierać komentarz opisujący, do czego metoda służy, jakie ma parametry (co one oznaczają) oraz jaką wartość zwraca,

− Każde wywołanie metody obiektu musi zawierać komentarz objaśniający czemu służy,

− Każde wykonanie instrukcji zapytania do bazy danych musi zawierać komentarz objaśniający czemu służy.

4) Brak komentarzy lub ich niska jakość traktowana będzie jako wada jakościowa kodu źródłowego, która zostanie krytycznie oceniona w trakcie dokonywania odbioru przez Zamawiającego, ze wstępnym wskazaniem rezultatu jako uwaga istotna, uniemożliwiająca odbiór produktu.

5) Powstały kod źródłowy posiada zaimplementowane lub zaktualizowane testy automatyczne.

4.9.6. Procedura autoryzacji Modyfikacji wykonanych przez Zamawiającego lub osoby trzecie działające w jego imieniu

1) Zamawiający przedstawia Wykonawcy propozycję wykonania modyfikacji przez Zamawiającego lub osoby trzecie działające w jego imieniu (dalej: „Modyfikacja Zewnętrzna” lub „MZ”).

2) Wykonawca ma prawo w terminie trzech Dni roboczych zgłosić uwagi do przedstawionej propozycji MZ.

3) Zamawiający może uwzględnić lub odrzucić uwagi Wykonawcy i zaproponowany sposób odbioru MZ.

4) Zamawiający lub osoby trzecie wykonują MZ.

5) Wykonawca instaluje MZ na środowisku testowym w terminie 1 Dnia roboczego od przedstawienia jej przez Zamawiającego.

6) Zamawiający przeprowadza testy odbiorowe.

7) Jeśli Wykonawca uzna, iż przeprowadzone przez Zamawiającego testy nie są wystarczające, wówczas przeprowadza własne testy weryfikujące (na swój koszt) w terminie do 14 Dni roboczych.

8) Pozytywny wynik weryfikacji jest równoznaczny z autoryzacją przez Wykonawcę MZ.

9) Jeśli wynik weryfikacji jest negatywny Wykonawca przedstawia Zamawiającemu Raport z testów MZ zawierający wszystkie istotne powody, które składają się na ten wynik w terminie 1 Dnia roboczego liczonym od dnia zakończenia testów weryfikujących przez Wykonawcę, o których mowa w pkt 7. Zamawiający ma prawo zadecydować czy MZ będzie wdrożona czy poprawiona. Zamawiający przekazuje Wykonawcy informację o podjętej decyzji. Polecenie wdrożenia MZ jest równoznaczne z autoryzacją przez Wykonawcę przedmiotowej MZ.

10) Wykonawca instaluje MZ na środowisku produkcyjnym w terminie wskazanym przez Zamawiającego.

4.10. Usługa realizacji szkoleń/warsztatów dla Administratorów Systemu

4.10.1. Zakres Usługi realizacji szkoleń/warsztatów dla Administratorów Systemu

1) W ramach puli Roboczogodzin przeznaczonych na Modyfikacje Zamawiający może zlecić Wykonawcy przygotowanie i zrealizowanie szkoleń/warsztatów oraz materiałów szkoleniowych dla Administratorów Systemu w zakresie dotyczącym obsługi Systemu (w szczególności w zakresie realizowanej Usługi wsparcia technicznego i serwisu lub związanym ze zleconymi Modyfikacjami/Pracami analitycznymi), wraz z zapewnieniem niezbędnego sprzętu i oprogramowania do przeprowadzenia szkolenia/warsztatu (opcjonalnie według Zlecenie).

2) Wykonawca realizuje szkolenia/warsztaty w Dni robocze w godzinach 7:30-16:30.

4.10.2. Zgłaszanie potrzeby wykonania Usługi, kanały komunikacji

1) Za pośrednictwem wykorzystywanego przez Zamawiającego Systemu Zgłoszeniowego.

2) Wskazanie Wykonawcy do realizacji Zlecenia w wykorzystywanym przez Zamawiającego systemie Zgłoszeniowym jest równoważne z przyjęciem przez Wykonawcę Zlecenia do realizacji.

4.10.3. Miejsce wykonywania Usługi

1) Wykonawca realizuje Zlecenie zdalnie lub w siedzibie Zamawiającego w zależności od decyzji Zamawiającego.

4.10.4. Procedura realizacji Usług wraz z przygotowaniem materiałów szkoleniowych i ich odbiór

1) Zamawiający rejestruje w Systemie Zgłoszeniowym Zlecenia potrzeby wykonania usługi z podanymi niezbędnymi elementami, m. in.:

a. liczba osób/grup do przeszkolenia;

b. adresaci szkolenia/warsztatu;

c. metoda szkolenia: prezentacje, ćwiczenia, praca w grupach, pytania i dyskusje itp.;

d. minimalna tematyka szkolenia/warsztatu;

e. zakres potrzebnej Dokumentacji szkoleniowej i jej formy np.: podręcznik, ćwiczenia, ankiety szkoleniowe;

f. miejsce szkolenia/warsztatu zapewniane przez Zamawiającego lub wskazanie platformy w przypadku szkolenia zdalnego;

g. liczba przerw i czas przeznaczony na przerwy w ramach szkolenia/warsztatu;

h. proponowana liczba godzin szkoleniowych;

i. proponowany termin planowanego szkolenia/warsztatu;

j. informacja czy Wykonawca ma zapewnić niezbędny sprzęt i oprogramowanie do przeprowadzenia szkolenia/warsztatu.

2) Wykonawca zobowiązany jest do przekazania Zamawiającemu, w terminie do 10 Dni roboczych od otrzymania Zlecenia liczonych, projektu szkolenia/warsztatu zawierającego:

x. xxxxxxxxxxx program szkolenia/warsztatu oraz imię i nazwisko wykładowcy,

b. listę niezbędnego sprzętu komputerowego wraz z jego istotnymi parametrami do realizacji szkolenia,

c. propozycje terminów szkoleń (dzień, miesiąc),

d. przewidywane ramy czasowe (godziny rozpoczęcia, zakończenia oraz wykaz przewidzianych w programie przerw),

e. inne elementy, które zostały przez Zamawiającego uznane za niezbędne do realizacji szkolenia/warsztatu a zostały przedstawione w Zgłoszeniu szkolenia

/ warsztatu.

3) Zamawiający analizuje przedstawiony projekt w ciągu 5 Dni roboczych, po czym:

a. akceptuje projekt szkolenia / warsztatu lub

b. zgłasza uwagi do projektu szkolenia/warsztatu.

4) W przypadku akceptacji Zamawiający przekazuje Zgłoszenie z akceptacją projektu do Wykonawcy.

5) W przypadku braku akceptacji projektu, Zamawiający przekaże Zgłoszenie z uwagami.

6) Wykonawca jest zobowiązany do uwzględnienia uwag i poprawienia projektu warsztatu/szkolenia oraz przekazania rozwiązania Zgłoszenia do Zamawiającego.

7) Po ponownym dostarczeniu przez Wykonawcę rozwiązania Zgłoszenia, Zamawiający dokona ponownej analizy projektu zgodnie z procedurą opisaną w pkt 3).

8) Wykonawca realizuje Usługę w terminie oraz zgodnie z zaakceptowanym przez Zamawiającego projektem szkolenia/warsztatu.

9) Wykonawca przedstawi do zatwierdzenia materiały szkoleniowe najpóźniej na 7 Dni roboczych przed rozpoczęciem poszczególnych szkoleń.

10) Zamawiający ma 2 Dni robocze na przekazanie uwag do przekazanego kompletnego materiału szkoleniowego.

11) W przypadku braku uwag w ciągu 2 Dni roboczych materiał szkoleniowy uznaje się za zaakceptowany. Nieuwzględnienie przez Wykonawcę uwag Zamawiającego do przekazanego kompletnego materiału szkoleniowego uniemożliwia przeprowadzenie szkolenia.

12) Materiały szkoleniowe zostaną przekazane osobom biorącym udział w szkoleniach najpóźniej w pierwszym dniu rozpoczęcia szkolenia danej grupy, jednocześnie jeden dodatkowy egzemplarz materiałów zostanie przekazany Zamawiającemu. Zamawiający decyduje czy materiały szkoleniowe mają mieć postać papierową czy też elektroniczną.

13) W celu potwierdzenia merytorycznego przeprowadzonego warsztatu/szkolenia zostaną przeprowadzone ankietowe badania jakości przeprowadzonego szkolenia/warsztatu przy zastosowaniu Ankiet szkoleniowych do wypełnienia.

14) Warunkiem odbioru wykonania usługi, jest przekazanie przez Wykonawcę Zamawiającemu podpisanego przez Wykonawcę protokołu odbioru szkolenia według wzoru określonego w Załączniku nr 9 do Umowy, wraz z:

a. listami obecności, dla każdej z grup szkoleniowych, potwierdzającymi obecność uczestników na szkoleniach;

b. listami potwierdzającymi odbiór materiałów szkoleniowych (o ile dotyczy);

c. ankietami szkoleniowymi w ilości odpowiadającej minimum 80 % uczestników szkoleń, których wzór określa Załącznik nr 4 do OPZ, potwierdzającymi spełnienie warunków jakościowych szkolenia;

15) Zamawiający akceptuje Protokół odbioru szkolenia/warsztatu i zamyka Zgłoszenie w Systemie.

4.10.5. Wytyczne dotyczące realizacji Usługi

1) Za jedną godzinę szkoleniową przyjmuje się 60 minut (jedna godzina zegarowa), bez wliczania czasu na przerwy, noclegi czy transport lub przygotowanie materiałów szkoleniowych.

2) Minimalna i maksymalna grupa szkoleniowa dla:

a. szkolenia - od 5 do 20 osób;

b. warsztatu - od 1 osoby do 10 osób;

3) Zamawiający może zgłaszać do realizacji więcej niż jedno szkolenie/warsztat w jednym terminie.

4) Szkolenie jest uznawane za niskiej jakości, jeśli zaistnieje, co najmniej jedna z następujących przesłanek:

a. Wykonawca dostarczył mniej niż 80% poprawnie wypełnionych ankiet szkoleniowych wypełnionych i podpisanych przez uczestników obecnych na szkoleniu;

b. Wykonawca uzyskał wynik gorszy niż 60 punktów z wyliczenia średniej jakości szkolenia.

Szczegółowe zasady obliczania jakości szkolenia opisane zostały w pkt 6 ppkt a.-d.

5) Ankietę uznaje się za wypełnioną poprawnie o ile uczestnik szkolenia odpowie na wszystkie pytania punktowane od numeru 1 do 5 zamieszczone na ankiecie, wpisze swoje dane personalne (imię nazwisko) oraz złoży podpis na ankiecie.

6) Średnia jakości szkolenia jest obliczona w następujący sposób - należy:

a. podliczyć liczbę punktów z pytań punktowanych, dla każdej dostarczonej ankiety,

b. zsumować liczbę punktów z wszystkich dostarczonych ankiet,

c. policzyć liczbę dostarczonych ankiet szkoleniowych,

x. xxxxxxxxx wynik z punktu b przez wynik z punktu c,

7) Dostarczone ankiety zawierają pytania o opinie uczestników szkoleń/warsztatów.

8) Z tytułu wypełnionej jednej ankiety można uzyskać maksymalnie 4 punkty. Jedną ankietę może wypełnić tylko jeden uczestnik szkolenia.

9) Do oceny wykorzystuje się tylko ankiety dostarczone przez Wykonawcę. Wykonawca nie może zmienić pytań punktowanych na inne pytania. W przypadku stwierdzenia nieuprawnionej modyfikacji ankiety, liczba punktów za ankietę zostaje ustalona na 0 oraz ankieta będzie uwzględniona w obliczeniu średniej jakości szkolenia.

10) W przypadku stwierdzenia niskiej jakości szkolenia szkolenia/warsztatu usługa będzie uznana za nieprawidłowo wykonaną. Wykonawca w takim przypadku musi na własny koszt zorganizować szkolenie/warsztat w warunkach nie gorszych niż było wykonane szkolnie, w którym uczestniczy zdobędą stosowną wiedzę.

11) Wykonawca jest zobowiązany do:

a. pisemnego poinformowania Zamawiającego o wszelkich planowanych zmianach w terminie nie późniejszym niż na 5 Dni roboczych przed rozpoczęciem danego szkolenia wraz z podaniem przyczyn i uzasadnieniem proponowanych zmian. Wykonawca może dokonać zmian wyłącznie po akceptacji Zamawiającego;

b. w przypadku konieczności nagłego odwołania szkolenia z przyczyn losowych, nieleżących po stronie Wykonawcy, poinformowania Zamawiającego i uczestników szkolenia o tym zdarzeniu, nie później niż 2 Dni robocze przed jego planowanym rozpoczęciem, a gdy to nie będzie możliwe, w przeddzień szkolenia;

c. prowadzenia ewidencji osób przeszkolonych, w formie list obecności podpisywanych przez wszystkich uczestników każdego dnia szkolenia ze wskazaniem instytucji, imienia i nazwiska oraz stanowiska służbowego;

d. przedstawienia uczestnikom każdego szkolenia ankiet szkoleniowych do wypełnienia.

12) Wykonawca zapewnia wykwalifikowaną kadrę szkoleniową posiadającą praktyczną wiedzę w zakresie funkcjonalności i procesów realizowanych w Systemie.

13) W przypadku zgłoszenia potrzeby zapewnienia sprzętu komputerowego, Wykonawca jest zobowiązany zapewnić podłączenie do sieci komputerowych projektora lub rzutnika, sprzętu komputerowego wraz z zainstalowanym systemem szkoleniowym oraz innymi niezbędnymi elementami infrastruktury szkoleniowej niezbędnymi do wykonania szkolenia/warsztatu. Parametry szkoleniowe urządzeń niezbędnych do wykonania szkolenia określa Wykonawca z uwzględnieniem zachowania płynnej interakcji pomiędzy użytkownikiem, a wprowadzonym żądaniem na ekranie monitora w czasie nie dłuższym niż 0,5 sekundy.

14) Wykonawca ma obowiązek monitorowania na bieżąco przebiegu realizacji szkoleń, kontrolując przebieg realizacji poszczególnych działań. Jeśli w trakcie realizacji szkolenia pojawią się jakiekolwiek przeszkody, utrudnienia bądź inne czynniki mogące utrudniać lub uniemożliwiać osiągnięcie zakładanych rezultatów szkolenia/warsztatu w tym możliwość niskiej jakości szkolenia, Wykonawca ma obowiązek zawiadomienia Zamawiającego o tym fakcie oraz przedstawić propozycję podjęcia działań naprawczych.

15) Wykonawca zapewnia wszelkie niezbędne pomoce naukowe i materiały szkoleniowe w języku polskim, zawierające część teoretyczną wyczerpujące pełną tematykę szkoleniową oraz ćwiczenia pozwalające na aktywne zdobywanie wiedzy.

16) W przypadku zmian w Systemie wynikających z niniejszej Umowy w x.xx. zmiany i/lub dodanie: procesów biznesowych, ról użytkowników, instalacji Nowych wersji Systemu na skutek naprawy Błędów lub modyfikacji, Wykonawca każdorazowo dokona aktualizacji materiałów dla szkoleń/warsztatów bez potrzeby dodatkowego zgłaszania przez Zamawiającego.

4.10.6. Rozliczenie usługi

Wynagrodzenie Wykonawcy za realizację Zgłoszenia będzie iloczynem uzgodnionej liczby godzin, potwierdzonych przez Zamawiającego i wynagrodzenia brutto za jedną godzinę Modyfikacji.

4.11. Usługa wsparcia (UW)

4.11.1 Zakres Usługi wsparcia

1) Usługa realizowana w wymiarze ośmiu Roboczogodzin dziennie w Dni robocze przez Konsulta technicznego stacjonarnie w siedzibie Zamawiającego w godz. 7:30 – 15:30. Zmiana godziny rozpoczęcia i zakończenia lub częściowe

świadczenie usług w trybie zdalnym możliwa jest po uzgodnieniu z przedstawicielem Zamawiającym wskazanym w § 7 ust. 1 lit. a Umowy. Zmiana sposobu świadczenia Usługi wsparcia (zdalnie lub stacjonarnie) lub zmiana godziny rozpoczęcia i zakończenia świadczenia Usługi wsparcia nie stanowi zmiany Umowy i nie wymaga aneksu do Umowy.

2) Usługa realizowana jest przez cały okres trwania Umowy, przy czy po upływie pierwszych pełnych 6 miesięcy liczonych od pierwszego dnia kalendarzowego następnego miesiąca po zawarciu Umowy zamawiający może zrezygnować ze świadczenia Usługi wsparcia poprzez złożenie oświadczenia na koniec danego miesiąca ze skutkiem od następnego miesiąca. W przypadku rezygnacji Zamawiającego z Usługi wsparcia Wykonawcy nie przysługują żadne roszczenia wobec Zamawiającego.

3) Gotowość do zapewnienia udziału konsultanta - maks. dwa razy na kwartał w prace weekendowe (sobota - niedziela) w godz. 8:00 - 22:00.

4) Konsultant Usługi wsparcia jest członkiem Personelu podstawowego.

5) Usługa wsparcia obejmuje możliwość konsultacji i zlecania zadań przez Zamawiającego z obrębie działania Systemu. Konsultant Usługi wsparcia musi posiadać kompleksową wiedzę w zakresie sposobu funkcjonowania Systemu w celu udzielania informacji Zamawiającemu. Konsultant zapewnia profesjonalną komunikację pomiędzy Zamawiającym a pracownikami Wykonawcy z celu pozyskiwania informacji o Systemie, rozwiązywania Zgłoszeń oraz realizacji Modyfikacji. Konsultant usługi wsparcia musi posiadać:

a. podstawowe umiejętności w zakresie programowania systemów informatycznych,

b. podstawowe umiejętności analityczne w zakresie analizy systemów informatycznych,

c. podstawowe umiejętności w zakresie testowania systemów informatycznych, d. podstawowe umiejętności w zakresie zarządzania i programowania bazami

danych,

e. umiejętności utrzymywania i rozwoju aplikacji opartych o technologie WEB, f. podstawowa umiejętność administracji systemami Linux i Windows,

g. umiejętności projektowania i wdrażania modyfikacji i poprawek oraz uczestnictwa we wdrażaniu nowych narzędzi,

h. umiejętność tworzenia i prowadzenia dokumentacji technicznej i procedur, i. umiejętność komunikatywności.

4.11.2 Zasady rozliczeń Usługi wsparcia

1) Rozliczenie następuje w cyklach miesięcznych Protokołem odbioru Usługi wsparcia.

4.12. Dokumentacja

4.12.1. Wymagania dotyczące Dokumentacji

1) Wykonawca w miarę potrzeb przygotuje oraz stosownie zaktualizuje

następujące rodzaje Dokumentacji związanej z przedmiotem zamówienia:

a. Dokumentację systemowa, w tym Projekt Techniczny wraz z makietami, dokumentacją API PI i API PA, dokumentacją SMIPI, dokumentacją importerów.

b. Dokumentacja utrzymaniowa, w tym procedury i instrukcje dla Administratorów Lokalnych i Centralnych, Podręczniki Użytkowników końcowych i Użytkowników.

c. Dokumentacja bezpieczeństwa.

2) Wykonawca zobowiązuje się do opracowania i aktualizowania każdej z wymienionych wyżej kategorii Dokumentacji w języku polskim w wersji elektronicznej w formacie docx (jeden plik (wersja robocza) - w trybie edycji zmian, drugi plik (wersja finalna) po dokonaniu akceptacji przez Zamawiającego z wyczyszczonymi komentarzami). W wersji roboczej Wykonawca zobowiązany jest oznaczyć zmiany w Dokumentacji w komentarzach wraz z numerem Modyfikacji lub Wady oraz wskazać w formie tabelarycznej historię zmian. Wersja robocza sporządzana jest w trybie edycji zmian, chyba, że Zamawiający w danym przypadku zrezygnuje z tego wymogu.

3) Dokumentacja charakteryzowała się będzie wysoką jakością, na którą będą miały wpływ, takie czynniki jak:

a. czytelna i zrozumiała struktura zarówno poszczególnych dokumentów jak i całej Dokumentacji z podziałem na rozdziały, podrozdziały i sekcje, a także z nagłówkami (spis treści budowany na bazie nagłówków umożliwiający nawigacje po dokumencie),

b. zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie jednolitej i spójnej struktury, formy i sposobu prezentacji treści poszczególnych dokumentów oraz fragmentów tego samego dokumentu, jak również całej dokumentacji,

c. kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość opisu rozpatrywanego zagadnienia. Oznacza to w szczególności jednoznaczne i wyczerpujące przedstawienie wszystkich zagadnień w odniesieniu do Systemu,

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.

4) W Dokumentacji dotyczącej specyfikacji wymagań dla każdego wymagania nadanie unikalnej etykiety (xx.XX/XXX, symbol, numer porządkowy), tak aby w pozostałej części Dokumentacji jednoznacznie wskazywać sposób realizacji określonych wymagań, gwarantując również kompletność realizacji zdefiniowanych wymagań w projektowanym rozwiązaniu.

5) Każdy rodzaj Dokumentacji będzie aktualizowany przez Wykonawcę odpowiednio do zmian lub Modyfikacji wprowadzanych według Zleceń Zamawiającego w terminie realizacji produktu. W przypadku obsługi

zidentyfikowanej Wady w Systemie Dokumentacja zostanie zaktualizowana przez wykonawcę w terminie 7 Dni roboczych po wdrożeniu na systemie produkcyjnym.

6) Zamawiający wymaga, by zmiany wprowadzane w poszczególnych Dokumentach były analizowane przez Wykonawcę przez pryzmat ich wpływu na zapisy innych dokumentów, a w razie ich zidentyfikowania - Wykonawca zobowiązany jest do wprowadzenia wymaganych zmian we wszystkich Dokumentach powiązanych.

7) Cała Dokumentacja, o której mowa powyżej, podlegała będzie akceptacji Zamawiającego.

8) Wszystkie dokumenty wytworzone w ramach niniejszego projektu podlegają procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w terminie nie dłuższym niż 10 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych. Zamawiający dokona 4 przeglądów dokumentacji przygotowanej przez Wykonawcę w trybie śledzenia zmian i wprowadzania komentarzy. Dokumentacja będzie weryfikowana w następujących etapach zaawansowania prac nad poszczególnymi dokumentami:

a. 25% - struktura dokumentu wraz z opisem zawartości

b. 75% - dokument w trakcie realizacji, uzupełniony na szacunkowym poziomie 75%

c. 95% - kompletny dokument

d. 99% - wersja finalna zawierająca wszelkie uzupełnienia zgłaszane ze strony Zamawiającego

e. 100% - wersja zaakceptowana przez Zamawiającego

Zamawiający decyduje, czy dany etap zaawansowania prac został osiągnięty.

9) Wykonawca przekazuje Dokumentację w postaci elektronicznej kanałem uzgodnionym z Zamawiającym.

Wersja Data Autor zmian Opis zmian

10) W każdym dokumencie powinna być wypełniona metryka zgodnie z szablonem: Historia zmian

11) Wykonawca przeniesie na Zamawiającego całość majątkowych praw autorskich do stworzonej w toku Umowy Dokumentacji.

4.12.2. Szczegółowe wymagania dotyczące poszczególnych Dokumentów

4.12.2.1. Dokumentacja systemowa, w tym Projekt Techniczny

1) Dokumentacja systemowa musi zawierać co najmniej następujące informacje:

a. wprowadzenie opisujące cele i zakres,

b. przyjęte założenia/ograniczenia

c. zależności między komponentami/modułami/aplikacjami/systemami zewnętrznymi,

d. opis działania poszczególnych komponentów/modułów/usług/aplikacji (w tym PI, AM, PA, importerów, SMIPI),

e. diagramy relacji (w tym z systemami zewnętrznymi),

f. charakterystyka użytkowników,

g. diagramy przypadków użycia,

h. przypadki użycia,

i. diagramy procesów,

j. diagramy stanów,

k. architektura systemu,

l. specyfikacja ekranów/makiety,

m. model i wykaz uprawnień,

n. szczegółowy wykaz wykorzystywanych zasobów z opisem ich przeznaczenia,

o. wykaz zastosowanych technologii,

p. wykaz wykorzystywanego oprogramowania,

q. wykaz licencji komercyjnych,

r. makiety ekranów,

s. opis i szczegółową specyfikację interfejsów programistycznych API wew., API zew., API międzysystemowego (CRCS/RCS)

t. konwencje zapisu kodu źródłowego,

u. standardy jakości kodu źródłowego

v. wytworzone kody źródłowe.

4.12.2.2. Dokumentacja utrzymaniowa, w tym procedury i instrukcje dla administratorów lokalnych i centralnych oraz użytkowników końcowych

1) Dokumentacja utrzymaniowa, musi zawierać co najmniej: a. procedury administracyjne,

b. procedury zabezpieczeń (backup’owe), c. procedury awaryjne,

d. procedury odzyskiwania systemu po awarii

e. procedury testowania planów ciągłości działania

f. procedury uruchamiania, wyłączania i restartowania poszczególnych maszyn z uwzględnieniem zależności od działania innych zasobów,

g. procedury użytkownika,

h. procedury instalacji systemu,

i. procedury konfiguracji importu danych z SRB, j. procedury konfiguracji importu eProtokołu,

k. procedury migracji danych po zmianie systemów SRP,

l. listę maszyn wraz ze specyfikacją każdej maszyny zawierającą co najmniej: I. za co dana maszyna jest odpowiedzialna,

II. w jakim środowisku pracuje (preProd, TST,…)

III. nazwę maszyny (nazwa obrazu wirtualki, nazwa systemowa), IV. adresację maszyny

V. wersję systemu operacyjnego,

VI. parametry techniczne (CPU,RAM, Dyski, karty sieciowe) VII. jakie dane przetwarza, z których sądów/apelacji,

VIII. usługi są konieczne do prawidłowej pracy tej maszyny,

IX. zasoby dyskowe/macierzowe są konieczne do pracy tej maszyny, X. jakie inne maszyny/zasoby są konieczne do pracy tej maszyny,

XI. jaki ruch sieciowy należy otworzyć, by zapewnić prawidłową prace maszyny,

XII. jakie są źródła czasu dla tej maszyny,

XIII. jak jest monitorowana maszyna (jaki system i jakie metryki monitoruje)

XIV. Jak kreowana jest maszyna (ręcznie czy automatycznie np. Ansible). m. listę aplikacji/programów/skryptów/usług wykorzystywanych przez System z

uwzględnieniem

I. opisu realizowanych funkcji (co robi),

II. wymogów do działania (zasób, adresacja, porty..),

III. sposobu ich uruchamiania/zatrzymywania/restartowania IV. lokalizacji logów,

V. zależności od innych aplikacji,

VI. listy maszyn, na których działa dana aplikacja.

2) Każda z procedur wymienionych w ustępie a, musi zawierać, co najmniej następujące informacje:

a. identyfikator i nazwę procedury,

b. rodzaj procedury,

c. data utworzenia i zatwierdzenia oraz wersja procedury,

d. cel i zakres procedury,

e. warunki uruchomienia procedury i oczekiwany rezultat jej wykonania,

f. dane osób, które opracowały procedurę, sprawdziły, zaakceptowały i zatwierdziły,

g. działania, które występują jedno po drugim, jakie należy wykonać, aby osiągnąć postawiony cel, w tym informacja o osobie (zgodnie z zaproponowanymi rolami), która powinna wykonać dane czynności.

3) Instrukcje dla administratorów lokalnych i centralnych oraz użytkowników końcowych

a. Podręczniki opracowane zostaną przez Wykonawcę dla każdej z ról przewidzianych w Systemie.

b. Podręcznik zawiera zrzuty ekranów (opatrzone krótkimi opisami tekstowymi) demonstrujące oczekiwane stany Systemu.

c. Podręcznik dla użytkownika końcowego musi zostać przygotowany w sposób umożliwiający samodzielne i sprawne wykonywanie wszelkich operacji w Systemie.

d. W przypadku podręczników dla Administratora System (osobno dla Administratora lokalnego i Centralnego) dokument powinien zawierać następujące informacje:

i. konfiguracja stacji roboczej,

ii. konfiguracja serwerów fizycznych i wirtualnych,

iii. konfiguracja komponentów sieciowych,

iv. opis zabezpieczeń Systemu,

v. bieżące działania administracyjne,

vi. zasady bieżącego monitorowania i konserwacji Systemu (w tym okna

serwisowe),

vii. aktualizacja Systemu poprzez łatki,

viii. wgrywanie nowych wersji oprogramowania wykonywalnego,

ix. w przypadku wykrycia niepoprawnego działania systemu, po wgraniu nowej wersji systemu bądź łatki, opis jak to wykonać,

x. zasady tworzenia kopii zapasowych bazy danych oraz Systemu,

xi. harmonogram tworzenia kopii zapasowych,

xii. zakres Systemu podlegający tworzeniu kopii zapasowej,

xiii. zasady utrzymywania kopii zapasowych,

xiv. procedury odtworzenia systemu z kopii zapasowych,

xv. zasady postępowania na wypadek Awarii.

4.12.2.3. Dokumentacja bezpieczeństwa

Dokumentacja bezpieczeństwa musi zawierać co najmniej następujące elementy:

1) Wstęp;

2) Opis procesu zarządzania ryzykiem:

a. opis metodyki szacowania ryzyka,

b. identyfikacja zagrożeń dla poufności integralności oraz dostępności informacji przetwarzanych w systemach objętych zamówieniem;

3) Plany ciągłości działania;

4) Opis bezpieczeństwa fizycznego:

a. strefy bezpieczeństwa,

b. środki ochrony fizycznej,

c. zasilanie awaryjne i zapewnienie warunków środowiskowych,

d. alternatywne łącza;

5) Informacje o zastosowanych urządzeniach i narzędziach kryptograficznych;

6) Ochrona nośników;

7) Procedury:

a. administrowanie Systemem,

b. bezpieczeństwo urządzeń,

i. autoryzacja i dopuszczalne wykorzystanie zasobów,

ii. bezpieczeństwo serwerów,

iii. bezpieczeństwo komputerów stacjonarnych,

iv. bezpieczeństwo komputerów przenośnych,

v. bezpieczeństwo sieci,

vi. bezpieczeństwo haseł,

vii. bezpieczeństwo oprogramowania,

viii. kopie zapasowe danych,

ix. zasady serwisowania,

x. zasady modernizowania

xi. zasady wycofania elementów systemu,

xii. plany awaryjne,

xiii. monitorowanie systemu IT;

8) Audyt Systemu:

a. przygotowanie audytu,

b. przebieg audytu,

c. zakończenie audytu,

d. dokumentowanie działań audytowych;

9) Incydenty bezpieczeństwa:

a. przyjęcie zgłoszenia,

b. rejestracja zgłoszenia,

c. analiza zgłoszenia i propozycja działania,

d. nadzór realizacji obsługi zgłoszenia,

e. ocena realizacji obsługi zgłoszenia incydentu.

4.13. Usługa gwarancji i rękojmi

Zakres usługi gwarancji obejmuje wszystkie wykryte podczas eksploatacji Systemu Wady.

W zakresie klasyfikacji Błędów Systemu, ewidencji Zgłoszeń, procedur odbioru, czasu realizacji zgłoszeń, odbioru usług, naliczania kar umownych mają zastosowanie postanowienie OPZ i Umowy.

W przypadku zmian w Systemie wynikających z instalacji nowych wersji na skutek naprawy Błędów lub Modyfikacji, Wykonawca dokona na żądanie Zamawiającego aktualizacji Dokumentacji.

5. Zaplanowane Modyfikacje Systemu

Zamawiający informuje, że w okresie obowiązywania Umowy może zlecić (w zależności od potrzeb oraz analizy wykonalności) następujące Modyfikacje:

1) dokeryzacja i mikroserwisy dla części komponentów Systemu w środowisku zaprojektowanym we współpracy z Wykonawcą,

2) wdrożenie automatyzacji poprzez oprogramowanie Ansible dla elementów infrastruktury, dla których jeszcze nie zostało to zrealizowane,

3) integracja z systemem IDM (Sailpoint IIQ),

4) scalenie kont użytkowników w 11 instancji do jednej istniejącej już bazy (zawiera wyłącznie informacje unikalne),

5) obsługa mediatorów sądowych oraz procesu mediacji w zakresie komunikacji z sądem,

6) zmiany w interfejsie GUI,

7) zmiana identyfikatora logowania do Systemu,

8) Moduł Tożsamości (MT),

9) Moduł Usługa Centralnego Podpisu Elektronicznego (UCPE),

10) Centralny Rejestr Dokumentów (CRD),

11) Portal Rejestrów Sądowych (PRS),

12) inne wynikające z bieżących potrzeb, wniosków użytkowników, zmian przepisów prawa

Załącznik nr 2 do OPZ – wzór notatki Notatka ze spotkania z dnia dd.mm.rrrr

Metryka dokumentu

Przedmiot spotkania:
Kod Projektu:
Nazwa dokumentu:		Nr wersji :
Opracowany przez:		Data wersji:

Dane spotkania

Rodzaj spotkania:
Cel spotkania:
Data spotkania:		Godzina rozpoczęcia:		Godzina zakończenia:
Miejsce spotkania:

Uczestnicy spotkania

Imię i nazwisko Organizacja

Tematy (Przebieg spotkania)
Lp.	Opis Tematu	Uwagi

1.

2.

3.

4.

5.

6.

Ustalenia
Lp.	Opis Ustalenia	Osoba odpowiedzialna i termin
1.
2.

Uwagi
Lp.	Uwagi

Załącznik nr 3 do OPZ – wzór PTM

Projekt techniczny modyfikacji

Modyfikacja:

Nr modyfikacji

Nazwa modyfikacji

Metryczka:

L.p.	Nazwa	Wartość
1.	Kto utworzył opis modyfikacji
2.	Data utworzenia
3.	Numer umowy
4.	Osoba zgłaszająca modyfikację
5.	Analityk akceptujący modyfikację
6.	Projektant/Programista akceptujący modyfikację

Historia zmian:

L.p.	Imię i nazwisko	Data zmiany	Opis zmiany
1.
2.
3.
4.
5.
6.

1. Opis biznesowy modyfikacji

Zawiera wszelkie znane wymagania do realizacji modyfikacji

2. Opis analityczny

Zawiera x.xx.:

- diagram przypadków użycia z oznaczeniem nowe/zmienione/usunięte,

- przypadki użycia nowe/zmienione/usunięte (wystarczy wskazanie usuniętych)

- diagram procesów,

- diagramy stanów.

3. Projekt techniczny

a. Komponenty

Zawiera x.xx. diagram pokazujący wpływ modyfikacji na poszczególne komponenty systemu, diagram komponentów do integracji, diagram pokazujący wpływ modyfikacji na poszczególne moduły i aplikacje systemu

b. Ekrany

Zawiera projekty nowych lub modyfikowanych ekranów wraz z opisami.

c. Implementacja

Zawiera x.xx. opisy algorytmów, przyjęte propozycje rozwiązań, listę nowych/modyfikowanych/ usuwanych metod API, zmiany bazodanowe.

4. Podsumowanie modyfikacji

Tabela 1 Modyfikacja projektu technicznego

L.p.	Modyfikacja w zakresie	TAK/NIE
1	Konfiguracji
2	GUI
3	Kodu
4	Bazy danych

Tabela 2 Modyfikacja dokumentacji

L.p.	Modyfikacja w zakresie	TAK/NIE
1	Instrukcji użytkownika
2	Instrukcji administratora
3	Dokumentacji analitycznej i technicznej
4	Dokumentacja API
5	Dokumentacji testowej

5. Wycena

Tabela 3 Wycena modyfikacji

L.p.	Zakres prac	Pracochłonność (roboczogodzin)
1	Analiza i dokumentacja
2	Modyfikacja kodu
3	Testy i scenariusze testowe
4	Instalacja i konfiguracja
	Razem

Termin realizacji
Przekazanie projektu Modyfikacji Zamawiającemu
Wykonanie i wdrożenie Modyfikacji na środowisku Zamawiającego	.

6. Scenariusz testowy

a. Cel testu

b. Scenariusz testu

Scenariusze mogą być dostarczone w postaci dokumentów zewnętrznych, w tym również dostarczone w pliku w formacie zgodnym wykorzystywanym przez Xxxxxxxxxxxxx oprogramowaniem wspierającym prowadzenie testów.

Spis tabel

Załącznik nr 4 do OPZ – Ankieta szkoleniowa

Suma punktów ………………..

ANKIETA SZKOLENIOWA

Imię i Nazwisko uczestnika szkolenia ……...................................................................................

Jednostka …………………

Termin szkolenia …………………

1. Jak Pani/Pan ogólnie ocenia program i metody szkoleniowe:

o bardzo wysoko (4 punkty)

o wysoko (3 punkty)

o średnio (2 punkty)

o nisko (1 punkty)

o brak kompetencji (0 punktów)

Uwagi…………………………………………………………………………………………

………………………………………………………………………………………………………

…………………………………………………………………………

2. Jak Pani/Pan ocenia przygotowanie merytoryczne osób prowadzących szkolenie:

o bardzo wysoko (4 punkty)

o wysoko (3 punkty)

o średnio (3 punkty)

o nisko (1 punkt)

o brak kompetencji (0 punktów)

Uwagi…………………………………………………………………………………………

………………………………………………………………………………………………………

…………………………………………………………………………

3. Czy Pani/Pan zdaniem program szkolenia został zrealizowany w całości:

o w 100% (4 punkty)

o w 80% (3 punkty)

o w 60% (2 punkty)

o w 20% (1 punkt)

o w 0% (0 punktów)

Uwagi……………………………………………………………………………………………

………………………………………………………………………………………………………

……………………………………………………………………………

4. Czy Pani/Pan otrzymała/Otrzymał materiały szkoleniowe TAK/NIE. Jeżeli TAK to czy Pani/Pan zdaniem otrzymane materiały szkoleniowe były zgodne z programem szkolenia (wypełnić w przypadku otrzymania materiałów szkoleniowych):

o zgodność w 100% (4 punkty)

o zgodność w 80% (3 punkty)

o zgodność w 60% (2 punkty)

o zgodność w 20% (1 punkt)

o zgodność w 0% (0 punktów)

Uwagi……………………………………………………………………………………………

………………………………………………………………………………………………………

……………………………………………………………………………

5. Jak ocenia Pani/Pan rezultaty w zakresie przekazanej wiedzy:

o wyraźnie znaczący wzrost wiedzy i rozeznania w problematyce objętej szkoleniem (4 punkty)

o średni wzrost wiedzy i rozeznania w problematyce objętej szkoleniem (3 punkty)

o uzyskanej wiedzy nie da się zastosować w praktyce (2 punkty)

o zastosowanie w praktyce uzyskanej wiedzy napotka na znaczne trudności (1 punkt)

o uzyskana wiedza jest mało przydatna w warunkach panującej rzeczywistości (0 punktów)

Uwagi……………………………………………………………………………………………

………………………………………………………………………………………………………

……………………………………………………………………………

Załącznik nr 5 do OPZ – Wymagania audytu bezpieczeństwa

1. Usługę przeprowadzenia testów bezpieczeństwa/penetracyjnych dla usługi Portal Informacyjny Sądów Powszechnych obejmujących: aplikacje Web (aplikacja Portal Informacyjny [Internet] oraz aplikacja Panel Administracyjny [sieć WAN]), aplikacje mobilne (Android, iOS) i ich interfejsy API.

2. Zakres minimalny testów:

1. dla aplikacji Web / interfejsu API systemu:

Testy aplikacji WWW według standardu OWASP ASVS 4.0 Level 1 – Greybox (bez dostępu do systemu operacyjnego i kodu źródłowego):

1) Verify that user set passwords are at least 12 characters in length. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

2) Verify that there are no periodic credential rotation or password history requirements.

3) Verify that "paste" functionality, browser password helpers, and external password managers are permitted.

4) Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as native functionality.

5) Verify that passwords 64 characters or longer are permitted. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

6) Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

7) Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.

8) Verify users can change their password.

9) Verify that password change functionality requires the user's current and new password.

10) Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

11) Verify that a password strength meter is provided to help users set a stronger password.

12) Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

13) Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.

14) Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.

15) Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.

16) Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password.

17) Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.

([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

18) Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.

19) Verify password credential recovery does not reveal the current password in any way. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

20) Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").

21) Verify that if an authentication factor is changed or replaced, that the user is notified of this event.

22) Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as TOTP or other soft token, mobile push, or another offline recovery mechanism. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

23) Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.

24) Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.

25) Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.

26) Verify that the out of band authenticator and verifier communicates over a secure independent channel.

27) Verify that time-based OTPs have a defined lifetime before expiring.

28) Verify the application never reveals session tokens in URL parameters or error messages.

29) Verify the application generates a new session token on user authentication. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

30) Verify that session tokens possess at least 64 bits of entropy. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

31) Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.

32) Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

33) Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

34) Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

35) Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

36) Verify that cookie-based session tokens use " Host-" prefix (see references) to provide session cookie confidentiality.

37) Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

38) Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.

39) Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.

40) Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.

41) Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

42) Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.

([C7](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

43) Verify that access controls fail securely including when an exception occurs. ([C10](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxx ng))

44) Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.

45) Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.

46) Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.

47) Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db,

.DS_Store, .git or .svn folders.

48) Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).

49) Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

50) Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting). ([C5](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

51) Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

52) Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content.

53) Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

54) Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.

55) Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.

56) Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.

57) Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.

58) Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, use whitelisting of protocols, domains, paths and ports.

59) Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.

60) Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.

61) Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

62) Verify that the application protects against XPath injection or XML injection attacks. ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

63) Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx

g))

64) Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

65) Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

66) Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxxx

))

67) Verify that the application projects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, CSP bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

68) Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented. ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

69) Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

70) Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.

71) Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

72) Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XXE.

73) Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).

74) Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.

75) Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.

76) Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

77) Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

78) Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxx ng))

79) Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.

80) Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII.

81) Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.

82) Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.

83) Verify that users have a method to remove or export their data on demand.

84) Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.

85) Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

86) Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols.

([C8](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

87) Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.

88) Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as XXXx0, XXXx0, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.

89) Verify that if the application has a client or server auto-update feature, updates should be

obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.

90) Verify that the application employs integrity protections, such as code signing or sub-resource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.

91) Verify that the application has protection from sub-domain takeovers if the application relies upon DNS entries or DNS sub-domains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (xxxxxxx-xxxxxx-xx.xxxxx.xxxxxxx.xxx) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.

92) Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.

93) Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.

94) Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.

95) Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.

96) Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modelling or similar methodologies.

97) Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.

98) Verify that user-submitted filename metadata is not used directly with system or framework file and URL API to protect against path traversal.

99) Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).

100) Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files (RFI), which may also lead to SSRF.

101) Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.

102) Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.

103) Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.

104) Verify that files obtained from untrusted sources are scanned by antivirus scanners to

prevent upload of known malicious content.

105) Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g.

.bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.

106) Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.

107) Verify that the web or application server is configured with a whitelist of resources or systems to which the server can send requests or load data/files from.

108) Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.

109) Verify that access to administration and management functions is limited to authorized administrators.

110) Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.

111) Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.

112) Verify that JSON schema validation is in place and verified before accepting input.

113) Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: triple or double submit cookie pattern (see [references](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxx- Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)), CSRF nonces, or ORIGIN request header checks.

114) Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.

115) Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxxxxx_Xxxxxxxx#xxxxXxxxxx_Xxxxxxxx g))

116) Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.

117) Verify that if application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.

118) Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.

119) Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.

120) Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.

121) Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).

122) Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type).

123) Verify that a content security policy (CSPv2) is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.

124) Verify that all responses contain X-Content-Type-Options: nosniff.

125) Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.

126) Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin".

127) Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use for sites where content should not be embedded in a third-party site.

128) Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.

129) Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.

130) Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to match against and does not support the "null" origin.

2. Dla aplikacji mobilnej:

1) Zgodnie z OWASP Mobile Application Security Checklist w aktualnie opublikowanej wersji dla Androida i iOS, przy czym testy nie będą obejmowały zakresu Anti-Re - Android i Anti-RE – iOS.

3. Wymagania standardów i metodyk:

Wykonawca zobowiązany jest stosować co najmniej następujące metody i standardy lub inne odpowiednie do analizowanego elementu Systemu w porozumieniu z Zamawiającym:

a) Wykorzystanie baz danych o znanych podatnościach i słabościach bezpieczeństwa:

1. SAN Top 20 Critical Security Controls lub równoważne,

2. Common Vulnerabilities and Exposures lub równoważne,

3. WASC (Web Application Security Consortium) Threat Classifications lub równoważne,

Przy czym za równoważne Zamawiający uzna, takie bazy danych, które stanowią aktualne źródło informacji o lukach bezpieczeństwa:

b) są publikowane i utrzymywane przez którekolwiek państwo będące członkiem paktu NATO lub

c) są stworzone i utrzymywane przez organizacje, niezależnie od ich form (komercyjna, non- profit w tym zorganizowana społeczność internetowa) których celem działalności jest zapewnienie bezpieczeństwa systemów i rozwiązań informatycznych, Zamawiający nie dopuszcza zastosowania baz, których wiarygodność została podważona w zakresie ich wykorzystania przez administracje publiczną tych Państw, 2) Odpowiednio do zakresu, zastosowanie list kontrolnych udostępnianych przez organizacje pracujące na rzecz bezpieczeństwa systemów IT do projektowania i oceny bezpieczeństwa systemów operacyjnych, baz danych, tj.:

1. National Security Agency (NSA) lub równoważne,

2. Center for Internet Security (CIS) lub równoważne.

Przy czym za równoważne Zamawiający uzna, takie listy kontrolne, które opisują całość procesów audytu systemów oraz rozwiązań informatycznych w niemniejszym zakresie, z niemniejszą szczegółowością i systematyką wykonywania audytu.

4. Zastosowanie do testów bezpieczeństwa, odpowiednio do zakresu, jednego ze standardów:

a) OWASP (Open Web Application Security Project) ASVS 20141 lub równoważne,

b) OWASP Mobile Application Security lub równoważne,

c) Open Source Security Testing Methodology Manual (OSSTMM) lub równoważne,

d) Penetration Testing Execution Standard (PTES) lub równoważne.

Za równoważne Zamawiający uzna standardy opisujące cały przebieg procesu testowania bezpieczeństwa systemów IT oraz obszary systemowe, które muszą podlegać weryfikacji, w niemniejszym zakresie, z niemniejszą szczegółowością i systematyką wykonywania audytu niż wymienione.

5. Wymagania w zakresie realizacji audytu muszą zawierać co najmniej następujące czynności:

a) harmonogram audytu – nie dłużej niż 30 dni kalendarzowe;

b) ustalenie zakresu docelowego – ustalenie charakteru i zasięgu testów;

c) gromadzenie informacji – zbieranie informacji na temat obiektu testów;

d) mapowanie podatności – poszukiwanie podatności w elementach Systemu;

e) docelowe wykorzystanie podatności – stworzenie wektora inicjalizującego atak, który ma na celu ominąć zabezpieczenia w celu naruszenia poufności, integralności oraz dostępności danych osobowych, przejęcia systemów, odcięcia Systemu od sieci zewnętrznej, utraty danych; zatrzymania eksploatacji Systemu, itp.

f) eskalacja uprawnień – zwiększenie uprawnień w Systemie i przeniesienie kontroli na kolejne usługi lub systemy;

g) zapewnienie ciągłości uzyskanego dostępu wynikającego z przełamania zabezpieczeń, w tym weryfikacja możliwości zainstalowania oprogramowania typu „tylna furtka” lub rootkit-ów, lub innego złośliwego oprogramowania;

h) dokumentacja i raportowanie – raport powinien zawierać informacje o znalezionych podatnościach oraz zauważonych problemach;

i) realizacja retestów (ponowna próba odnalezionych podatności pod kątem ich występowania) w terminie wskazanym przez Zamawiającego oraz sporządzenie raportu z retestu.

Wykonawca będzie na bieżąco informował w trakcie prowadzonej oceny stanu o znalezionych podatnościach Systemu i poziomie ich krytyczności w celu podjęcia jak najszybszej reakcji niwelującej ryzyko. W przypadku podatności określonych jako krytyczne – nie dłużej niż w ciągu 2 godzin od ich rozpoznania.

6. Wymagania dotyczące produktów:

a) Raport przekazany zostanie w postaci elektronicznej.

b) Wykonawca dostarczy raport zawierający co najmniej informacje:

1. o wykonanym teście wraz z opisem (rodzaj, metodyka, itp.)

2. wyniki testu w odpowiedniej, przyjętej dla tego rodzaju testów, skali wraz z komentarzem i zaleceniami, tj. wyniki testu muszą zawierać zidentyfikowane podatności wraz z ich opisem, skalą zagrożenia (krytyczności) dla bezpieczeństwa testowanych usług oraz rekomendacjami w zakresie usunięcia lub zminimalizowania podatności. Minimalna zawartość raportu powinna zawierać:

1. Streszczenie menadżerskie, w tym ogólną opinię nt. bezpieczeństwa, zgodności z określonymi standardami i regulacjami wewnętrznymi i zewnętrznymi, zakres analizy lub koncepcji;

2. W części szczegółowej:

1. obserwacje z oceny stanu bezpieczeństwa;

2. wyniki testów i ich interpretacja;

3. listę wykrytych luk (w tym podatności) opatrzonych komentarzem audytora wraz z ich kwalifikacją w znaczeniu dla bezpieczeństwa (krytyczność) oraz sposobie ich odnalezienia przez audytora;

4. wnioski z oceny stanu bezpieczeństwa;

5. zalecenia i rekomendacje, w tym propozycja sposobu eliminacji podatności;

6. zakres czynności niezbędnych do weryfikacji i potwierdzenia luk (podatności) – o ile przedmiot oceny stanu bezpieczeństwa II tego dotyczy;

7. rekomendacje poaudytowe dla każdej obserwacji.