NOTATKA ZE SPOTKANIA · Web viewZamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w...

Załącznik nr 1 do Umowy nr …… z dnia …………………….

Opis przedmiotu zamówienia

1. Wstęp

Przedsięwzięcie realizowane jest w ramach projektu „Poprawa zdolności administracyjnych sądów, w tym systemów informatycznych” współfinansowanego ze środków Norweskiego Mechanizmu Finansowego 2009 – 2014 w ramach Programu Operacyjnego „Budowanie potencjału instytucjonalnego i współpraca w obszarze wymiaru sprawiedliwości / Poprawa skuteczności wymiaru sprawiedliwości”.

Docelowo System Zarządzania Tożsamością będzie wspierał funkcjonowanie procesu zarządzania tożsamością we wszystkich jego elementach na rzecz Ministerstwa Sprawiedliwości i sądów powszechnych. System ten znacząco usprawni korzystanie z systemów informatycznych objętych integracją z SZT, w szczególności Zintegrowanego Systemu Rachunkowości i Kadr (ZSRK). Celem wdrożenia Systemu Zarządzania Tożsamością jest zapewnienie spójnych i bezpiecznych zasad zarządzania tożsamością użytkowników systemów informatycznych, w szczególności:

zapewnienie adekwatności przyznanych uprawnień do pełnionych obowiązków i funkcji oraz ich zgodności z obowiązującym prawem i regulacjami wewnętrznymi,

usprawnienie i przyspieszenie procesów związanych z cyklem życia tożsamości poprzez automatyzację i wykorzystanie do tego celu narzędzi informatycznych,

zapewnienie rozliczalności posiadanych przez użytkowników uprawnień i procesu ich przyznawania.

1.1. Skróty i definicje

Pojęcie Znaczenie

Konektor Oprogramowanie służące do wymiany informacji między centralnym repozytorium, a podłączonym systemem informatycznych

MS Ministerstwo Sprawiedliwości

Proces Zarządzania Tożsamością, PrZT

Proces zarządzania kontami użytkowników, prawami dostępu do zasobów informacyjnych oraz ich nadzorowania.

System Zarządzania Tożsamością

Ogół procesów, procedur i systemów informacyjnych biorących udział w procesie zarządzania tożsamością użytkowników systemów informatycznych.

SZT System Zarządzania Tożsamością

Program Operacyjny „Budowanie potencjału instytucjonalnego i współpraca w obszarze wymiaru sprawiedliwości / Poprawa skuteczności wymiaru sprawiedliwości” finansowanego z funduszy norweskich i środków krajowych

Strona 1 z 46

Tożsamość Podstawowy obiekt SZT definiujący pracownika organizacji, który posiada przypisane atrybuty oraz prawa dostępowe do Systemów Informatycznych.

Recertyfikacja Czynność polegająca na weryfikacji, czy przesłanki dotyczące przyznania uprawnień są zachowane, w szczególności czy istnieje potrzeba ich posiadania przez użytkownika oraz czy spełnia on minimalne wymagania na ich posiadanie (np. szkolenia, zgody itp.).

Rekoncyliacja Czynność polegająca na uzgodnieniu zapisów dotyczących tożsamości w SI z bazą SZT.

Rola Zestaw uprawnień w ramach jednego lub więcej SI, które powinny być przydzielone użytkownikowi. Użytkownik może być członkiem wielu ról, o ile nie jest to sprzeczne z zasadami podziału obowiązków. W takim przypadku użytkownik ma przydzielone uprawnienia będące sumą ról, których jest członkiem.

Rola techniczna Rola obejmująca zestaw uprawnień w ramach pojedynczego SI, niezbędnych do realizacji określonych zadań w SI dla tej roli.

Rola biznesowa Rola wynikająca z funkcji, stanowiska, działu lub innych atrybutów tożsamości użytkownika, na ogół obejmująca uprawnienia w więcej niż w jednym systemie informatycznym .

SI System Informatyczny objęty procesem zarządzania tożsamością.

Uprawnienie Czynność bądź niepodzielny zestaw czynności, które może wykonać użytkownik w SI. Lista uprawnień, do których użytkownik może być autoryzowany określona jest dla każdego SI.

Autentykacja Czynność, dzięki której SI może potwierdzić tożsamości użytkownika. Uwierzytelnienie dokonuje się na podstawie metody wybranej dla danego SI.

Użytkownik Osoba uprawniona do korzystania z Systemów Informatycznych, tj. pracownik Zamawiającego lub pracownicy sądów powszechnych. niezależnie od formy zatrudnienia, w rozumieniu art. 1 ustawy z dnia 27 lipca 2001 r. Prawo o ustroju


Strona 2 z 46

sądów powszechnych (Dz. U. z 2015 r. poz. 133 ze zm.).

Właściciel SI Osoba decyzyjna, w gestii której znajduje się dany SI.

Właściciel SZT Dyrektor komórki organizacyjnej odpowiedzialnej za utrzymanie SZT.

Właściciel Roli Osoba decyzyjna, w gestii której należy modyfikacja roli oraz przypisanie roli do użytkownika końcowego.

Właściciel Polityki Osoba decyzyjna, w gestii której leży utworzenie, modyfikacja oraz kontrola polityki audytu.

2. Zobowiązania WykonawcyZobowiązania Wykonawcy obejmują:

1. Dostawa Systemu Zarządzania Tożsamością wraz z infrastrukturą sprzętową, a także jego instalacja i konfiguracja, czego finalnym efektem będzie wdrożenie i produkcyjne uruchomienie Systemu w 73 sądach powszechnych wyszczególnionych w Liście Dystrybucyjnej (Załącznik nr 2 do Umowy).

2. Świadczenie usługi utrzymania i wsparcia technicznego przez okres 12 miesięcy.3. Szkolenie dla administratorów Systemu Zarządzania Tożsamością oraz przygotowanie

materiałów dla szkoleń e-learningowych,4. Opracowanie dokumentacji projektowej.

2.1. Dostawa Systemu Zarządzania Tożsamością wraz z infrastrukturą sprzętową2.1.1. Opis funkcjonalności SZT

System zarządzania tożsamością wspierał będzie funkcjonowanie procesu zarządzania tożsamością we wszystkich jego elementach na rzecz sądów powszechnych. Proces obejmie konta wszystkich użytkowników korzystających z systemów informatycznych objętych integracją z SZT.

Rysunek 1. Proces zarządzania tożsamością


Strona 3 z 46

System zarządzania tożsamością w szczególności wspierać musi następujące procedury wewnętrzne zdefiniowane w Ministerstwie Sprawiedliwości:

Tworzenie, przetwarzanie, przechowywanie, usuwanie informacji o tożsamościach użytkowników w oparciu o dane kadrowe z systemu HCM.

Blokowanie/odblokowywanie użytkowników. Ponowne ustawienie oraz dystrybucja hasła. Automatyczne nadawanie ról w oparciu o strukturę organizacyjną HCM. Wnioskowanie o role oraz nadawanie / modyfikacje ról poprzez portal samoobsługi

SZT. Tworzenie, przetwarzanie, przechowywanie, usuwanie informacji o uprawnieniach

w oparciu o role biznesowe. Nadawanie ról administracyjnych w sytuacjach kryzysowych. Wnioskowanie o

tego typu role musi odbywać się poprzez dodatkowy formularz. Przypisanie tego typu uprawnień jest ograniczone czasowo i musi być szczegółowo rejestrowane.

Audyt ról w systemie informatycznym. Przenoszenie ról pomiędzy użytkownikami w okresie czasowej nieobecności. Nadawanie oraz kontrolowanie ról dla użytkowników uprzywilejowanych.

Rysunek 2. Cykl życia tożsamości

Wyżej wymienione procedury zostaną udostępnione Wykonawcy w terminie do 7 dni po zawarciu Umowy.

Wykonawca zobowiązany będzie na etapie tworzenia Projektu Biznesowo-Technicznego do uszczegółowienia poszczególnych procedur, uzupełnienia o brakujące elementy oraz ew.


Strona 4 z 46

weryfikacji ich poprawności i wprowadzenia w uzgodnieniu z Zamawiającym zmian w ich przebiegu.

W SZT funkcjonować ma mieszany model zarządzania uprawnieniami, co oznacza dwoiste podejście do zarządzania, w zależności od potrzeb biznesowych:

Zarządzanie w oparciu o strukturę organizacyjną SAP HCM – nadawanie/modyfikowanie ról będzie realizowane przez SZT automatycznie, w wyniku przypisania użytkownika do odpowiedniego stanowiska, posiadającego powiązanie do odpowiednich ról biznesowych.

Zarządzanie w oparciu o wnioski (Workflow) – nadawanie/modyfikowanie ról będzie realizowane po zaakceptowaniu właściwego wniosku elektronicznego w ramach SZT.

Nadawanie, modyfikowanie oraz odbieranie ról (Provisioning), dla systemów umożliwiających pełną integrację z SZT będzie odbywać się w sposób automatyczny – poprzez konektory do systemu SZT.

SZT nie ma zarządzać zmianą uprawnień w SI. SZT dokonywać ma jedynie przypisania do tożsamości istniejących ról i uprawnień w SI, zarządzanie uprawnieniami odbywa się w SI.

SZT będzie zarządzać uprawnieniami poprzez przypisanie do tożsamości:

Ról technicznych

Ról biznesowych

Ról dostępowych do portalu samoobsługi SZT

Rola biznesowa umożliwia grupowanie istniejących ról technicznych w SI oraz ról dostępowych do portalu samoobsługi SZT.

W procesie zarządzania tożsamością autorytarnym źródłem informacji o tożsamościach użytkowników będzie moduł kadrowy systemu SAP HCM.

2.1.2.Opis wymagań dla środowiska pracy SZT2.1.2.1. Środowisko pracy SZTWykonawca musi uwzględnić w ofercie wszystkie elementy niezbędne do dostarczenia

SZT wg wymagań zawartych w niniejszym Opisie Przedmiotu Zamówienia. W szczególności dotyczy to:

Serwerów stanowiących podstawę wdrożenia i eksploatacji SZT Systemów operacyjnych Baz danych Aplikacji Oprogramowania narzędziowego

Pozostała platforma sprzętowa (urządzenia magazynujące, urządzenia sieciowe) zostaną dostarczone przez Zamawiającego. Aktualne środowisko zawiera:

Dwie lokalizacje przeznaczone do instalacji systemu SZT znajdujące się w lokalizacjach Sądu Apelacyjnego we Wrocławiu.

Zamawiający zagwarantuje urządzenia typu:o Routery w każdej z lokalizacji instalacji systemu.


Strona 5 z 46

o Rozwiązania Hardware Load Balancer, mające zostać wykorzystane do równoważenia połączeń klienckich do systemu SZT (BIG-IP 3900).

o Szafy typu Rack do instalacji serwerów.o Urządzenie pamięci masowej (macierz dyskowa).

Łącza WAN pomiędzy lokalizacjami przeznaczonymi dla serwerów SZT o przepustowości 1Gbps.

Łącza WAN pomiędzy lokalizacjami serwerów SZT a sądami podlegającymi wdrożeniu wynoszą od 2Mbps do 100Mbps.

SZT musi zostać dostarczony jako kompletne i w pełni funkcjonalne rozwiązanie (system pod klucz).

2.1.2.2. Architektura SZTSzczegółowa specyfikacja wszystkich elementów tworzących SZT musi zostać

zamieszczona przez Wykonawcę w dokumencie Projekt Biznesowo-Techniczny.

SZT musi zostać zaprojektowany oraz wdrożony przy spełnieniu następujących założeń:

SZT będzie się składał z co najmniej dwóch fizycznie rozdzielonych i niezależnych od siebie środowisk:◦ Środowiska PROD – środowisko produkcyjne,◦ Środowisko DEV/TEST– środowisko dewelopersko-testowe.

Oznacza to, że żaden z elementów (sprzęt, system operacyjny, baza danych, aplikacja) środowiska produkcyjnego (PROD) nie może być współdzielony ze środowiskiem dewelopersko-testowym (DEV/TEST).

Wszystkie elementy środowiska produkcyjnego SZT mają pracować w architekturze redundantnej (co najmniej dwa fizycznie rozdzielone urządzenia) oraz mają być rozmieszczone w dwóch centrach przetwarzania danych posiadanych przez Zamawiającego.

Wymagania dla środowiska dewelopersko/testowego:

musi odzwierciedlać środowisko produkcyjne,

nie musi pracować w architekturze redundantnej,

musi umożliwiać równoległą pracę co najmniej 20 użytkownikom,

Wykonawca zaproponuje w dokumencie Projekt Biznesowo-Techniczny sposób realizacji środowiska dewelopersko/testowego na poziomie sprzętowym, systemowym i logicznym.

Wykonawca dostarczy, zainstaluje i skonfiguruje sprzęt serwerowy dla systemu SZT w ośrodkach przetwarzania danych spełniając poniższe wymagania:

dostarczone serwery zostaną dobrane i wyskalowane tak, aby spełniać wymagania dla systemu SZT dostarczonego w ramach niniejszego Zamówienia,

dostarczone serwery muszą być kompatybilne z producentem dostarczonego w zamówieniu systemu operacyjnego,

liczba serwerów fizycznych - po dwa serwery w dwóch ośrodkach przetwarzania pracujących w trybie HA (wysokiej dostępności); Po przerwaniu pracy serwerów


Strona 6 z 46

podstawowych serwery zapasowe podejmują działanie w czasie nie dłuższym niż 2 minuty,

serwery zostaną podłączone przez Wykonawcę do zewnętrznego urządzenia magazynującego (macierz dyskowa), przy wykorzystaniu interfejsu w standardzie Fibre Channel, 8 Gbit/s,

rozmiar każdego z serwerów nie może przekraczać 2U,

instalacja zostanie przeprowadzona we wskazanych przez Zamawiającego szafach serwerowych typu Rack o szerokości 19".

Wykonawca dostarczy licencje systemów operacyjnych w ilościach wskazanych przez Wykonawcę w projekcie Biznesowo-Technicznym zatwierdzonym przez Zamawiającego, zainstaluje i skonfiguruje systemy operacyjne zgodnie z projektem Biznesowo-Technicznym Wykonawcy zatwierdzonym przez Zamawiającego, na dostarczonych przez Wykonawcę serwerach dla środowiska produkcyjnego oraz testowego przy spełnieniu poniższe minimalnych w tym zakresie wymagań:

system operacyjny musi być kompatybilny z dostarczonym systemem SZT,

system operacyjny musi być aktualny na dzień jego instalacji zgodnie z zaleceniami producenta systemu operacyjnego,

system operacyjny musi pracować w architekturze 64bit (x86-64),

wersja językowa systemu operacyjnego: angielska lub inna za zgodą Zamawiającego.

Pozostałe wymagania licencyjne:

Wykonawca jest zobowiązany dostarczyć wszystkie wymagane licencje dla rozwiązań wirtualizacyjnych, o ile takie zostaną zaproponowane Planie Projektu. Platforma wirtualizacyjna musi być kompatybilna z dostarczonym systemem operacyjnym oraz systemem SZT. Konfiguracja platformy wirtualizacyjnej oraz systemu operacyjnego musi zapewniać optymalne z punktu widzenia kosztów wykorzystanie licencji całego rozwiązania środowiska produkcyjnego SZT. Zamawiający posiada rozwiązania wirtualizacyjne Vmware (w wersjach 5.1 i 5.5) oraz Microsoft (w wersji 2012) oraz zasoby kompetencyjne w zakresie wskazanych systemów. Dostarczone licencje rozwiązań wirtualizacyjnych muszą stanowić rozbudowę posiadanych przez Zamawiającego środowisk.

Wykonawca jest zobowiązany dostarczyć wszystkie wymagane licencje dla zapewnienia wysokiej dostępności zaproponowanego środowiska produkcyjnego (HA).

Wykonawca dla realizacji zamówienia musi przewidzieć i dostarczyć wszelkie uprawnienia licencyjne, również firm trzecich, jeśli takie będą wymagane.

Wykonawca może wykorzystać posiadane przez Zamawiającego narzędzia raportujące SAP BusinessObjects BI Platform, SAP NetWeaver BW on HANA lub monitorujące SAP Solution Manager o ile uzna, że jest to uzasadnione, spełnia wymogi funkcjonalne oraz nie narusza zasad licencjonowania tych narzędzi.


Strona 7 z 46

2.1.3. Wymagania licencyjne SZT2.1.3.1. Licencje dostarczone w ramach zamówieniaZamawiający w ramach niniejszego zamówienia wymaga dostarczenia nieograniczonych

czasowo licencji SZT na liczbę 52500 użytkowników.

2.1.3.2. Dystrybucja licencjiDystrybucję licencji na poszczególne systemy informatyczne przedstawia Tabela 1.

Liczba użytkowników SI może ulec nieznacznym zmianom w trakcie realizacji zamówienia.

System InformatycznyIntegracja SZT z SI objęte niniejszym

zamówieniem

Zarządzanie użytkownikami w SI poprzez SZT objęte

niniejszym zamówieniem

Docelowa liczba użytkowników

SAP HCM TAK NIE 52 500

ESS/MSS/LSO TAK TAK 52 500

MS Exchange TAK TAK 52 500

AD TAK TAK 52 500PO NIE NIE 5 000ReCurt Services NIE NIE 40 000 (szacunek)Portal inf. NIE NIE 5 000Hurtownia Danych NIE NIE 2 000NKW NIE NIE 11 500RZ NIE NIE 200KRS NIE NIE 2 100ZSRK NIE NIE 52 500SIS NIE NIE 500CaSuS NIE NIE 52 500 HPSM NIE NIE 52 500Workflow NIE NIE 52 500Portal Sądownictwa Powszechnego

NIE NIE 5 000

Tabela 1. Zestawienie użytkowników

2.1.3.3. Liczba użytkowników w ramach wdrożeniaW ramach pierwszej fazy wdrożenia SZT (objętej niniejszym zamówieniem)

przewidziane jest uruchomienie usługi dla szacowanej grupy 8150 użytkowników końcowych.

2.1.4. Systemy Informatyczne objęte integracją z SZT

Podrozdział przedstawia krótką charakterystykę wszystkich Systemów Informatycznych objętych projektem wdrożenia SZT, a w szczególności zawiera podstawowe informacje nt. elementów istotnych z perspektywy integrowanych systemów:

Repozytoria użytkowników Identyfikatory kont użytkowników Role i uprawnienia

Integracja oznacza, że elementy składowe SI pozwalają na wykonanie z poziomu SZT czynności takich jak automatyczne zarządzanie kontami poprzez interfejs programistyczny tzw. API. Integracja oznacza również wykonywanie czynności związanych z odczytywaniem / nadawaniem / modyfikowaniem / usuwaniem ról bez udziału administratorów SI.


Strona 8 z 46

2.1.4.1. Środowisko objęte integracją z SZT w ramach zamówieniaW ramach pierwszej fazy wdrożenia Systemu Zarządzania Tożsamością w sądach

powszechnych, zakłada się integrację z SZT z poniższymi systemami:

ESS/MSS/LSO - Portal przeznaczony do Samoobsługi Pracowniczej i celów szkoleniowych

AD MS – domena Active Directory (ad.ms.gov.pl) MS Exchange – serwer pocztowy SAP HCM – moduł kadrowy

Integracja oznacza przygotowanie konektora umożliwiającego komunikację z SI poprzez interfejs programistyczny –API, umożliwiający automatyzację zadań związanych z:

Importem danych o użytkownikach, rolach oraz przypisaniem ról do użytkowników do repozytorium SZT

Tworzeniem/odczytywaniem/modyfikowaniem/usuwaniem kont użytkowników Odczytywaniem/nadawaniem/modyfikowaniem/usuwaniem ról.

Rysunek 3. Integracja SZT z Systemami Informatycznymi

Możliwa jest również komunikacja z SI do SZT w przypadku wykonywania:


Strona 9 z 46

inicjalnego ładowania definicji ról i użytkowników z SI do SZT

ładowania przyrostowego przypisania ról do użytkowników z SI do SZT)

System SZT będzie również musiał docelowo współpracować z niezależnymi od siebie systemami zarządzania domeną:

Integracja z domeną ad.ms.gov.pl (objęte niniejszym zamówieniem) Integracja z dodatkową domeną opartą o OpenLDAP oraz domeną AD sis.ms.gov.pl

(nie objęte niniejszym zamówieniem)Tabela 2 zawiera informacje nt. wykorzystanych domen w analizowanych systemach

oraz metodach implementacji mechanizmu autentykacji oraz autoryzacji dla poszczególnych systemów.

SystemAutentykacja Domena

Autoryzacja

Parametry generacji loginu

SAP HCM AD ad.ms.gov.pl AD imię, nazwisko, typ kontaESS/MSS/LSO AD ad.ms.gov.pl AD imię, nazwisko, typ konta

MS Exchange AD ad.ms.gov.pl AD

imię.nazwisko@domena , gdzie domena wynika z jednostki gospodarczej w SAP HCM

AD AD ad.ms.gov.pl ADImię, nazwisko, numer z sekwencji

Tabela 2. Repozytoria autentykacji i autoryzacji

2.1.4.2. Opis Systemów Informatycznych2.1.4.2.1. System ESS/MSS/LSO

Charakterystyka SystemuESS/MSS/LSO to system pozwalający na wykonywanie zadań związanych z samoobsługą pracowniczą oraz z obsługą tzw. e-learning’u. System oparty jest o technologię SAP Netweaver Portal i SAP HCM. Dostęp do systemu posiadają wszyscy pracownicy sądów powszechnych bez względu na formę zatrudnienia.

Repozytoria tożsamościŹródłem informacji o użytkownikach MSS/ESS/LSO jest baza UME zlokalizowana na systemie ZSRK, opartym o technologię SAP Netweaver ABAP. Zarządzanie użytkownikami odbywa się poprzez mechanizm CUA (Central User Administration) obsługiwany poprzez system centralny Solution Manager.

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie generowane są w oparciu o określony algorytm, którego parametrami są imię, nazwisko oraz typ konta.

Role i uprawnienia


Strona 10 z 46

System MSS/ESS/LSO przechowuje informację o przypisanych do użytkownikach rolach w systemie ZSRK. Zarządzanie uprawnieniami odbywa się poprzez mechanizm CUA.

2.1.4.2.2. System Microsoft Active Directory (ad.ms.gov.pl)

Charakterystyka SystemuMinisterstwo Sprawiedliwości wykorzystuje usługę Microsoft Active Directory (MS AD) do zarządzania kontami użytkowników oraz dostępem do zasobów Środowiska Informatycznego. Usługa ta będzie docelowo podstawowym repozytorium informacji o użytkownikach sądów powszechnych bez względu na formę zatrudnienia.. Na bazie Active Directory funkcjonują dodatkowe usługi PKI (uwierzytelnianie użytkowników za pomocą certyfikatów) i VPN (zdalny dostęp do SI). Active Directory stanowić ma również podstawę do zarządzania kontami pocztowymi Exchange. W sądach objętych wdrożeniem SZT prowadzone będzie jednoczesne wdrożenie centralnej domeny AD oraz usługi poczty centralnej.

Domena MS AD obsługiwana jest poprzez:

Centrala MS Warszawa (1 lokalizacja): dwa kontrolery domeny, Centrala MS Warszawa (2 lokalizacja): cztery kontrolery domeny na potrzeby

replikacji z innymi kontrolerami w lokalizacjach sądów powszechnych, do 11 wybranych lokalizacji sądów powszechnych - po jednym kontrolerze

domeny w każdym z sądów.

Repozytoria tożsamościCentralna usługa Active Directory wykorzystywana ma być docelowo jako podstawowe repozytorium, stanowiące źródło uwierzytelniania i autoryzacji dla użytkowników zasobów Środowiska Informatycznego w sądach powszechnych. W związku z tym przechowuje ona obiekty reprezentujące wszystkich użytkowników tej infrastruktury wraz z opisującymi ich atrybutami (typu imię, nazwisko, numer telefonu, przełożony, etc.). Wszyscy pracownicy sądów powszechnych posiadają założone konta w centralnej usłudze AD.

Usługa Active Directory nie jest uzależniona w tym względzie od innych systemów Ministerstwa Sprawiedliwości.

Identyfikatory użytkownikówUżytkownicy posiadają w usłudze Active Directory konta imienne. Identyfikatory tych kont generowane są na podstawie określonych reguł, które muszą być zachowane i uwzględnione na etapie projektowania SZT.

Role i uprawnieniaUsługa Active Directory nie posiada obecnie zdefiniowanych ról biznesowych. Część obiektów grup użytkowników wykorzystywanych jest przez systemy bazujące na AD do reprezentacji uprawnień, ale nie dotyczy to samej usługi katalogowej AD.

Wnioskowanie o konto w usłudze Active Directory realizowane jest według procesu na podstawie zdefiniowanego formularza.


Strona 11 z 46

2.1.4.2.3. System pocztowy Microsoft Exchange

Charakterystyka SystemuSystem Exchange wykorzystywany jest w Ministerstwie Sprawiedliwości do obsługi poczty elektronicznej oraz jako centralna, elektroniczna książka adresowa. System Exchange bazuje na głównej usłudze Active Directory Ministerstwa Sprawiedliwości (ad.ms.gov.pl) i jest z tą usługą ściśle zintegrowany.

Repozytoria tożsamościPodstawowym źródłem informacji o użytkownikach dla systemu jest główna usługa katalogowa Active Directory wykorzystywana w Ministerstwie Sprawiedliwości (ad.ms.gov.pl).

Identyfikatory użytkownikówZe względu na ścisłą integrację z usługą katalogową Active Directory, identyfikatorem użytkownika w systemie Exchange jest jego login domenowy.

Role i uprawnieniaSystem Exchange nie posiada zdefiniowanego systemu ról. System bazuje na kontach użytkowników tworzonych w Active Directory.

2.1.5. Planowana integracja z SZTZakłada się docelową możliwość integracji SZT z dodatkowymi systemami

informatycznymi. Obowiązkiem Wykonawcy w ramach niniejszego zamówienia nie jest integracja SZT z systemami SI wymienionymi w Tabeli nr 1. System SZT musi posiadać możliwość rozszerzenia o dodatkowe konektory umożliwiające integrację z systemami:

PO - Portal Orzeczeń ReCourt Services Portal Informacyjny NKW - Nowa Księga Wieczysta HANA – Hurtownia Danych RZ – Rejestr Zastawów KRS – Krajowy Rejestr Sądowy ZSRK – system SAP ERP SIS - System Informacyjny Schengen CaSuS HPSM – Service Desk Workflow Portal Sądownictwa PowszechnegoW ramach niniejszego zamówienia Wykonawca nie jest zobowiązany do dostarczenia

licencji na konektory do ww. systemów informatycznych. Wymagana jest dostępność lub możliwość rozwoju konektorów, zapewniających zgodność z mechanizmami autentykacji/autoryzacji przedstawionymi w Tabela 3.

System Autentykacja Domena AutoryzacjaProgram Operacyjny „Budowanie potencjału instytucjonalnego i współpraca w obszarze wymiaru sprawiedliwości / Poprawa skuteczności

wymiaru sprawiedliwości” finansowanego z funduszy norweskich i środków krajowych

Strona 12 z 46

PO openLDAP domena openLDAP openLDAPRecord Services AD ad.ms.gov.pl MSSQLPortal inf. PostgreSQL - PostgreSQLSAP BW AD ad.ms.gov.pl ADNKW AD ad.ms.gov.pl ADHANA AD ad.ms.gov.pl HANARZ AD dodatkowa domena ADKRS DB2 - DB2ZSRK AD ad.ms.gov.pl ADSIS AD sis.ms.gov.pl ADCaSuS AD ad.ms.gov.pl nieznanyHPSM AD ad.ms.gov.pl AD

WorkflowAD i PostgreSQL ad.ms.gov.pl PostgreSQL

Portal AD ad.ms.gov.pl ADTabela 3. Mechanizmy autentykacji i autoryzacji dla dodatkowych SI

2.1.5.1. Opis Systemów Informatycznych2.1.5.1.1. System PO – Portal Orzeczeń

Charakterystyka systemuPO to system za pomocą którego odbywa się bezwnioskowa publikacja treści orzeczeń wraz z uzasadnieniem wydawanych przez sądy powszechne. Orzeczenia dostępne są za darmo oraz bez potrzeby uprzedniej rejestracji użytkownika.

Repozytoria tożsamościŹródłem informacji o użytkownikach PO jest domena oparta o technologię OpenLDAP.

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie PO generowane są w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaSystem PO przechowuje informację o przypisanych do użytkownikach rolach w domenie OpenLDAP

2.1.5.1.2. System ReCourt Services

Charakterystyka systemuReCourt to system służący do cyfrowej rejestracji posiedzeń sądowych w postępowaniach cywilnych oraz wykroczeniowych. Wspomaga on również pracę sekretariatów w zakresie pracy z nagraniami oraz ich udostępniania podmiotom w sprawach.

Repozytoria tożsamościŹródłem informacji o użytkownikach ReCourt Services docelowo jest domena AD ad.ms.gov.pl.


Strona 13 z 46

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie ReCourt Services generowane są w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaSystem ReCourt Services przechowuje informację o przypisanych do użytkownikach rolach w lokalnej bazie danych MS SQL.

2.1.5.1.3. System Portal Informacyjny

Charakterystyka systemuPortal Informacyjny jest narzędziem pozwalającym uprawnionemu lub upoważnionemu podmiotowi na dostęp do informacji o sprawie toczącej się z jego udziałem.

Repozytoria tożsamościŹródłem informacji o użytkownikach Portalu informacyjnego jest lokalna baza danych oparta w technologii PostgreSQL.

Identyfikatory użytkownikówIdentyfikatory użytkowników w Portalu Informacyjnym zbudowane są z numeru PESEL.

Role i uprawnieniaSystem ReCourt Services przechowuje informację o przypisanych do użytkownikach rolach w lokalnej bazie danych PostgreSQL.

2.1.5.1.4. System NKW

Charakterystyka systemuNKW - Nowa Księga Wieczysta to modułowy system, który pozwala na realizację zadań związanych z przetwarzaniem informacji o Księgach Wieczystych. Dostęp do systemu posiadają pracownicy Ministerstwa Sprawiedliwości, Sądów, Ośrodków Migracyjnych, notariusze, komornicy, Ewidencja Gruntów i Budynków oraz Obywatele RP. System wykorzystywany jest w 348 Wydziałach Ksiąg Wieczystych na terenie RP oraz w 11 Ośrodkach Migracyjnych.

Repozytoria tożsamości

Podstawowym źródłem informacji o użytkownikach w systemie NKW jest usługa Active Directory firmy Microsoft. Jest to domena AD ad.ms.gov.pl

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie NKW generowane są w oparciu o określone algorytmy, które muszą być zachowane na etapie projektowania SZT. Parametrami algorytmu są imię oraz nazwisko.

Role i uprawnienia


Strona 14 z 46

System NKW wspiera mechanizmy ról i uprawnień. W celu uzyskania dostępu do aplikacji użytkownik zobligowany jest do posiadania konta w usłudze Active Directory (ad.ms.gov.pl).

2.1.5.1.5. Hurtownia danych

Charakterystyka systemuHurtowania danych SAP HANA jest systemem umożliwiającym dostęp do raportów.

Repozytoria tożsamościŹródłem informacji o użytkownikach Hurtowni Danych jest lokalna baza użytkowników przechowywana w SAP HANA.

Identyfikatory użytkownikówIdentyfikatory użytkowników w Hurtowni Danych generowane są w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaHurtowania danych HANA przechowuje informację o przypisanych do użytkownikach rolach w lokalnej bazie danych HANA.

2.1.5.1.6. System RZ

Charakterystyka systemuRejestr zastawów jest systemem umożliwiającym składanie i przesyłanie drogą elektroniczną wniosków, załączników i dokumentów do sądów rejestrowych lub Centralnej Informacji RZ;

Repozytoria tożsamościŹródłem informacji o użytkownikach RZ jest domena AD

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie Rejestr Zastawów generowane są w oparciu o określony algorytm, którego parametrami są identyfikator wydziału KRS oraz numer z sekwencji.

Role i uprawnieniaSystem RZ przechowuje informację o przypisanych do użytkownikach rolach w domenie AD

2.1.5.1.7. System KRS

Charakterystyka systemuKRS jest systemem umożliwiającym elektroniczny dostęp do zasobów Krajowego Rejestru Sądowego.

Repozytoria tożsamościŹródłem informacji o użytkownikach KRS jest lokalna baza danych DB2.


Strona 15 z 46

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie KRS generowane są w oparciu o określony algorytm, którego parametrami są identyfikator wydziału KRS oraz numer z sekwencji.

Role i uprawnieniaSystem KRS przechowuje informację o przypisanych do użytkownikach rolach lokalnej bazie danych DB2.

2.1.5.1.8. System ZSRK

Opis systemuZintegrowany System Rachunkowości i Kadr zbudowany w oparciu o rozwiązanie klasy ERP - system firmy SAP, ma zastąpić w sądach powszechnych wykorzystywane obecnie oprogramowanie finansowo – księgowe, wnosząc jednocześnie dodatkowe możliwości wynikające z jego modułowości. Zarządzanie systemem odbywać się będzie poprzez SAP CUA. Użytkownikami systemu są Ministerstwo Sprawiedliwości i sądy powszechne (wszystkie sądy apelacyjne, okręgowe i rejonowe).

Repozytoria tożsamościSystem ZSRK przechowuje informacje o użytkownikach we własnym repozytorium SAP ABAP. Integracja bazować powinna na komponencie SAP CUA.

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie ZSRK generowane są w oparciu o określony algorytm, którego parametrami są imię, nazwisko oraz typ konta.

Role i uprawnieniaSystem ZSRK bazuje na uprawnieniach ABAP, których przypisanie do użytkownika następuje poprzez komponent CUA.

2.1.5.1.9. System SIS

Charakterystyka systemuSIS jest Systemem Informatycznym umożliwiającym wprowadzenie Europejskiego Nakazu Aresztowania.

Repozytoria tożsamościŹródłem informacji o użytkownikach SIS jest domena AD sis.ms.gov.pl.

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie SIS generowane są w oparciu o określony algorytm, którego parametrami są imię, nazwisko oraz kod sądu.

Role i uprawnieniaSystem SIS przechowuje informację o przypisanych do użytkownikach rolach w domenie AD sis.ms.gov.pl


Strona 16 z 46

2.1.5.1.10. System CaSuS

Charakterystyka systemuCaSuS jest centralnym systemem repertoryjno-biurowym wspomagającym biurową obsługę spraw sądowych, który ma zostać dostarczony w perspektywie 4 lat.

Repozytoria tożsamościŹródłem informacji o użytkownikach systemu CaSuS będzie domena AD ad.ms.gov.pl

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie CaSuS generowane będą w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaDla systemu CaSuS nie jest obecnie znane miejsce przechowywania informacji o rolach przypisanych użytkownikom.

2.1.5.1.11. System Zgłoszeniowy Service Desk (ITSM)

Charakterystyka SystemuSystem zgłoszeniowy Service Desk (ITSM) zrealizowany na bazie HPSM, pozwala pracownikom Sądów i Ministerstwa Sprawiedliwości zgłaszać incydenty dotyczące pracy i funkcjonowania systemów informatycznych działający w obszarze resortu sprawiedliwości.

Repozytoria tożsamościPodstawowym źródłem informacji o użytkownikach w systemie jest domena AD (ad.ms.gov.pl).

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie ITSM generowane są w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaSystem zgłoszeniowy Service Desk (ITSM) wykorzystuje wewnętrzne system ról oraz uprawnień. Wnioskowanie o uprawnienia realizowane jest w oparciu o formularz oraz proces akceptacyjny uwzględniający dodatkowe akceptacje.

2.1.5.1.12. System Workflow

Charakterystyka systemuWorkflow jest systemem usprawniającym pracę sądownictwa powszechnego oraz obsługującym e-nominacje.

Repozytoria tożsamościŹródłem informacji o użytkownikach Workflow jest domena AD ad.ms.gov.pl lub lokalna baza danych PostgreSQL.


Strona 17 z 46

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie Workflow generowane są w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaSystem Workflow przechowuje informację o przypisanych do użytkownikach rolach w lokalnej bazie PostgreSQL.

2.1.5.1.13. Portal Sądownictwa Powszechnego

Charakterystyka systemuPortal jest ogólnodostępnym serwisem dostępowym do zasobów sądownictwa powszechnego. System oparty jest o technologię MS Sharepoint.

Repozytoria tożsamościŹródłem informacji o użytkownikach Portalu jest domena AD ad.ms.gov.pl

Identyfikatory użytkownikówIdentyfikatory użytkowników w systemie Portal generowane są w oparciu o określony algorytm, którego parametrami są imię oraz nazwisko.

Role i uprawnieniaPortal przechowuje informację o przypisanych do użytkownikach rolach w domenie AD ad.ms.gov.pl

2.1.6. Synchronizacja atrybutów HCMSystem SZT ma umożliwiać replikację danych kadrowych z systemu SAP HCM do

centralnego repozytorium SZT. Lisę atrybutów zawiera Tabela 4.

Lp. Atrybut

1 Status zatrudnienia

2 Nr osob.3 Jednostka gospodarcza4 Nazwa stanowiska finansowego5 Obszar kadrowy6 Podobszar kadrowy7 Grupa pracowników8 Podgrupa pracowników9 Stanowisko10 Jednostka organizacyjna11 Nazwisko12 Imię13 Funkcja14 Rodzaj komunikacji


Strona 18 z 46

15 PESEL16 Dł. ID/numer17 Data rozpoczęcia zatrudnienia18 Data zakończenia zatrudnienia

Tabela 4. Lista atrybutów HCM

Atrybuty HCM zreplikowane do repozytorium SZT podlegają dalszej replikacji do docelowych SI. Tabela 5 zawiera zestawienie atrybutów HCM podlegających replikacji do systemów objętych pierwszą fazą wdrożenia. Zadaniem systemu SZT jest też wygenerowanie loginów i adresów email użytkowników na podstawie dotychczas stosowanych algorytmów.

System informatyczny Lista atrybutów

AD imię, nazwisko, numer osobowy, email, jednostka gospodarcza, PESEL, numer telefonu, okres ważności konta, funkcja, stanowisko

Exchange imię, nazwisko, jednostka gospodarcza, emailESS/MSS/LSO imię, nazwisko, email, login, okres ważności konta

Tabela 5. Dystrybucja atrybutów do SI

Wszelkie zmiany w SI wynikające z uruchomienia SZT (m.in.: systemach SAP ERP, SAP NetWeaver BW, SAP NetWeaver PI, SAP BusinessObjects BI, AD, Exchange) muszą być zrealizowane przez Wykonawcę

2.2. Kategorie wymagań SZTNiniejszy rozdział opisuje kategorie wymagań dla systemu SZT. Zamawiający oczekuje,

iż przedstawione wymagania będą spełnione w ramach SZT.

2.2.1. Ogólne funkcjonalności dotyczące zarządzania tożsamości Zamawiający wymaga obsługę następujących scenariuszy poprzez system IDM:

L.p. Opis wymagania Poziom wymagalności

1.1 Zarządzanie cyklem życia tożsamości: tworzenie, modyfikacja, blokowanie kont Wymagane

1.2

Tworzenie/przechowywanie/usuwanie informacji o tożsamościach użytkowników w SZT na podstawie danych HCM i replikacja kont użytkowników do obligatoryjnych systemów AD, Exchange, ESS/MSS/LSO

Wymagane

1.3

Blokowanie kont i dezaktywacja uprawnień w przypadku wystąpienia odpowiedniego zdarzenia w systemie HCM oraz manualnie z poziomu portalu samoobsługi SZT. Blokowanie i dezaktywacja musi posiadać dodatkowy atrybut określający przyczynę wyłączenia konta.

Wymagane

1.4 Synchronizacja zmodyfikowanych atrybutów Wymagane


Strona 19 z 46


HCM do systemów informatycznych, np. zmiana nazwiska

1.5Możliwość centralnego resetu/zmiany hasła oraz dystrybucja hasła produkcyjnego do systemów informatycznych

Wymagane

1.6 Zarządzanie uprawnieniami w SI w oparciu o role Wymagane

1.7 Możliwość definiowania ról biznesowych grupujących role techniczne SI Wymagane

1.8Przyznanie podstawowych ról biznesowych dla MSS/LSO, AD, Exchange dla wszystkich użytkowników SZT

Wymagane

1.9 Obsługa procesu akceptacji workflow dla przypisania ról Wymagane

1.10 Obsługa procesu akceptacji workflow dla tworzenia i modyfikacji ról biznesowych Wymagane

1.11 Obsługa portalu samoobsługi do celów zarządzania tożsamością Wymagane

1.12 Dostęp do portalu samoobsługi poprzez przeglądarkę internetową Wymagane

1.13 Możliwość synchronizacji haseł pomiędzy SI Wymagane

1.14 Możliwość definiowania reguł wykluczających się uprawnień (tzw. Separation of Duties) Wymagane

1.15Możliwość uruchomienia zadania identyfikacji naruszeń Separation of Duties na poziomie użytkowników

Wymagane

1.16 Możliwość uruchomienia zadania identyfikacji naruszeń Separation of Duties na poziomie ról Wymagane

1.17Interfejs portalu samoobsługi SZT oraz systemu akceptacji dostępny w języku polskim i angielskim

Wymagane

1.18

Możliwość określenia właściciela roli, który kontroluje proces przypisania roli do użytkowników. Kontrola ta realizowana jest m.in. poprzez uczestnictwo właściciela w workflow w roli akceptującego przypisanie uprawnień lub roli

Wymagane


Strona 20 z 46


1.19 Możliwość weryfikacji przez właściciela roli, tożsamości do niej przypisanych Wymagane

1.20 Możliwość usunięcia przypisanie roli do użytkownika poprzez właściciela roli Wymagane

1.21

Możliwość kontroli uprawnień pracowników w ramach wybranej struktury organizacyjnej (raport musi obejmować zestawienie przypisanych systemów oraz uprawnień przypisanych użytkownikom, uprawnień technicznych, ról biznesowych, ról w SI))

Wymagane

1.22 Możliwość przypisania ryzyka do wybranej roli (wysokie, średnie, niskie) Opcjonalne

1.23 Możliwość wprowadzenia opisu dla każdej roli Opcjonalne

1.24 Możliwość czasowego przypisania roli Wymagane

1.25 Możliwość weryfikacji ról przypisanych użytkownikowi w repozytorium tożsamości Wymagane

1.26Możliwość porównania stanu przypisania ról do użytkownika w repozytorium tożsamości i systemie informatycznym

Wymagane

1.27Automatyczne nadawanie ról w oparciu o określone reguły lub stanowisko w strukturze HCM

Wymagane

1.28

Możliwość tworzenia kont dla użytkowników, którzy nie są zdefiniowani w systemie HCM np.: zewnętrznych konsultantów oraz użytkowników technicznych

Wymagane

1.29 Możliwość czasowego przenoszenia uprawnień pomiędzy użytkownikami Wymagane

1.30 Wsparcie procesu nadawania uprawnień administracyjnych w sytuacjach kryzysowych Wymagane

1.31 Możliwość weryfikacji czynności wykonanych przy użyciu uprawnień uprzywilejowanych Wymagane

1.32 Wsparcie procesu okresowej recertyfikacji uprawnień Wymagane

1.33 Blokowanie wybranych kanałów dostępu do systemu Exchange per użytkownik. Na przykład blokowanie dostępu z urządzeń

Opcjonalne


Strona 21 z 46


mobilnych lub wybranych komputerów.

1.34

System umożliwia zdefiniowanie automatycznego zadania usuwającego tożsamości z systemu, które spełniają określone kryteria wyboru, np. konta przedawnione

Wymagana

2.2.2. Funkcjonalność interfejsu aplikacji


2.1

Dostępność portalu samoobsługi w wersji desktop (zwany dalej Portal desktop) powinien być dostępny z poziomu przeglądarek internetowych. Wspierane najnowsze wersje przeglądarek: Chrome lub Firefox lub Internet Explorer.

Wymagane

2.2Dostępność wersji mobilnej portalu samoobsługi. Wspierane urządzenia: iOS, Android.

Opcjonalne

2.3 Możliwość personalizacji interfejsu portalu samoobsługi Wymagane

2.4Dostępność co najmniej dwóch wersji obszaru roboczego portalu dedykowanych dla użytkownika i administratora

Wymagane

2.5 Obsługa powiadomień sms dla systemu akceptacji Wymagane

2.6 Obsługa powiadomień email dla systemu akceptacji Wymagane

2.7 Konfigurowalne treści powiadomienia Opcjonalne

2.8 Obsługa autentykacji SSO do interfejsu aplikacji1 Wymagane

2.9 Możliwość wyświetlenie struktury organizacyjnej Wymagane

2.10Wysyłanie powiadomień o upływającym okresie ważności kont w SI (AD, Exchange, ESS/MSS/LSO)

Wymagane

1 Wymagane jest uruchomienie usługi SSO dla Portalu SZT oraz ESS/MSS/LSO w oparciu o autentykację domenową SPNEGO. Docelowy proces przedstawiony jest na Rysunek 4.


Strona 22 z 46

Rysunek 4. Single Sign On

2.2.3. Funkcjonalność interfejsu administratora portalu samoobsługi


3.1 Możliwość wyszukiwania tożsamości Wymagane

3.2 Możliwość tworzenia/usuwania tożsamości Wymagane

3.3 Możliwość blokowania/odblokowania tożsamości Wymagane

3.4 Możliwość tworzenia/edycji ról biznesowych Wymagane

3.5 Możliwość dodawania/usuwania ról dla wybranej tożsamości Wymagane

3.6 Możliwość centralnego resetu hasła Wymagane


Strona 23 z 46

3.7 Możliwość podglądu statusu procesów workflow Wymagane

3.8 Możliwość publikowania komunikatów i dokumentów dla użytkowników Opcjonalne

2.2.4.Funkcjonalność interfejsu użytkownika portalu samoobsługi


4.1 Możliwość edycji atrybutów własnej tożsamości Wymagane

4.2 Możliwość centralnego resetu hasła Wymagane

4.3 Możliwość wnioskowania o przyznanie ról biznesowych Wymagane

4.4 Możliwość weryfikacji statusu procesu workflow Wymagane

4.5 Możliwość akceptacji kroków workflow (dla managerów) Wymagane

4.6 Dostępność pomocy technicznej Wymagane

2.2.5. Funkcjonalności dotyczące konektorów


5.1 Dostępność konektora dla MS Active Directory Wymagane

5.2 Dostępność konektora dla MS Exchange Wymagane

5.3 Dostępność konektora dla OpenLdap Wymagane

5.3 Dostępność konektora dla PostgreSQL Wymagane

5.4 Dostępność konektora dla IBM DB2 Wymagane

5.6 Dostępność konektora dla MSSQL Wymagane

5.7Dostępność konektora dla SAP NW Portal poprzez mechanizm Central User Administration (CUA)

Wymagane

5.8 Dostępność konektora dla SAP Netweaver ABAP wykorzystującego SAP API Wymagane


Strona 24 z 46

5.9

Możliwość tworzenia nowego konektora w przypadku braku obecności standardowego wsparcia dla danego typu integrowanego systemu informatycznego

Wymagane

5.10Dostępność konektora dla SAP HCM - jako źródła tożsamości dla systemu zarządzania tożsamością

Wymagane

5.11 Możliwość obsługi błędów i konfliktów synchronizacji Wymagane

5.12 Obsługa powiadomień dla błędów synchronizacji pomiędzy systemami Wymagane

5.13

Możliwość przeglądu dziennika synchronizacji wraz z statusem rekordów (zreplikowany prawidłowo, zreplikowany z ostrzeżeniem, niezreplikowany)

Wymagane

5.14Możliwość modyfikacji atrybutów podlegających synchronizacji oraz kierunku synchronizacji (jedno, dwukierunkowa)

Wymagane

5.15 Możliwość replikacji struktury organizacyjnej HCM Wymagane

5.16 Możliwość inicjalnego załadowania do SZT użytkowników istniejących w SI Wymagane

5.17Możliwość inicjalnego załadowania do SZT ról istniejących w SI wraz z przypisaniem do użytkowników

Wymagane

5.18Możliwość dwukierunkowej synchronizacji przypisania ról do użytkowników pomiędzy SZT a SI

Wymagane

5.19 Możliwość dwukierunkowej synchronizacji kont użytkowników pomiędzy SZT a SI Wymagane

2.2.6. Funkcjonalność audytu systemowego


6.1

Możliwość definiowania polityk audytu pozwalających na przeszukiwanie repozytorium tożsamości w celu identyfikacji sytuacji stanowiących potencjalne zagrożenie

Wymagane

6.2 Możliwość określenia właściciela polityki audytu Opcjonalne


Strona 25 z 46

6.3 Możliwość powiadomienia właściciela polityki w przypadku wystąpienia odstępstw Opcjonalne

6.4Proces obsługi odnalezionych odstępstw audytowych poprzez czasową bądź stałą akceptację

Wymagane

6.5Definiowanie poziomów ryzyka dla poszczególnych zagrożeń weryfikowanych przez polityki audytu

Wymagane

2.2.7. Wymagania dotyczące architektury repozytorium tożsamości


7.1 Repozytorium tożsamości znajduje się w relacyjnej bazie danych lub usłudze LDAP Wymagane

7.2Repozytorium zapewnia możliwość transferu danych z środowiska produkcyjnego do testowego wraz z anonimizacją danych

Wymagane

7.3Repozytorium pozwala na przechowywanie danych (dokumenty doc, pdf, zdjęcia) w postaci BLOB (ang. binary large object)

Wymagane

7.4 Repozytorium pozwala na przechowanie struktury organizacyjnej Wymagane

7.5Repozytorium musi posiadać wydajność pozwalającą na obsługę co najmniej 52500 tożsamości użytkowników

Wymagane

2.2.8. Wymagania bezpieczeństwa


8.1System umożliwia uruchomienie mechanizmu szyfrowania protokołem SSL dla portalu samoobsługi SZT

Wymagane

8.2

Możliwość szyfrowania wybranych danych repozytorium tożsamości lub wszystkich (opcja konfiguracyjna wybierana przez Administratora)

Wymagane

8.3 Możliwość szyfrowanej komunikacji z systemami informatycznymi Wymagane

8.4Możliwość anonimizacji wybranych danych przy wykonywaniu kopii systemu produkcyjnego na system testowy

Wymagane


Strona 26 z 46

8.5 Szyfrowana transmisja pomiędzy warstwą aplikacji a repozytorium tożsamości Wymagane

8.6Warstwa aplikacji komunikując się z repozytorium sięga bezpośrednio do danych w bazie danych tożsamości

Wymagane

8.7

Możliwość odebrania uprawnień dla konta administratora bazy (konto z pełnymi uprawnieniami) oraz dystrybucji uprawnień do innych kont

Wymagane

2.2.9. Serwis/Wsparcie


9.1

Świadczący serwis posiada autoryzację Producenta do świadczenia serwisu dla oferowanego Systemu lub jest autoryzowanym partnerem Producenta oprogramowania SZT

Wymagane

9.2 Długość okresu gwarancyjnego 12 miesięcy Wymagane

9.3

Zapewnienie wsparcia powdrożeniowego w okresie 12 miesięcy oraz dodatkowo do 24 godzin w miesiącu do fakultatywnego wykorzystania w okresie świadczenia usługi wsparcia

Wymagane

9.4

Wykonawca zapewni dostęp do aktualizacji programów, poprawek i ostrzeżeń o zagrożeniach bezpieczeństwa udostępnianych przez Producenta Systemu

Wymagane

2.2.10. Wymagania licencyjne


10.1

Dostarczenie licencji do SZT pozwalających na połączenie 52500 użytkowników końcowych, do wszystkich systemów wymienionych w Tabela 2 wraz ze wsparciem na okres 3 lat

Wymagane

10.2 Dostarczenie licencji na wymagane konektory Wymagane

2.2.11. Wymagania infrastrukturalne


11.1 Dostarczenie sprzętu serwerowego Wymagane


Strona 27 z 46

11.2 Dostarczenie licencji na bazy danych Wymagane

11.3 Dostarczenie licencji na systemy operacyjne Wymagane

11.4 Dostarczenie licencji na rozwiązania wirtualizacyjne Opcjonalne

11.5 Dostarczenie licencji na rozwiązania wysokiej dostępności (HA) Opcjonalne

2.2.12. Wymagania wydajnościowe


12.1

Czas odpowiedzi systemu na dowolną akcję użytkownika podczas bieżących operacji transakcyjnych systemu poniżej 3 sekund zgodnie z wymaganiami testów wydajnościowych zwartych w Tabeli 8

Wymagane

12.2 Maksymalny czas generowania raportów poniżej 10 minut Wymagane

12.3 Maksymalny czas trwania procesu aktualizacji wszystkich tożsamości w SI poniżej 30 minut Wymagane

2.2.13. Wymagania niezawodnościowe


13.1 Praca systemu w trybie ciągłym 24h / dobę / 7 dni w tygodniu / 365 dni w roku Wymagane

13.2 Dostępność portalu samoobsługi 24h/ dobę / 7 dni w tygodniu / 365 dni w roku Wymagane

13.3 System umożliwia uruchomienie mechanizmu zapewniającego wysoką dostępność - HA Wymagane

2.2.14. Wymagania dotyczące narzędzi deweloperskich


14.1 Dostarczenie narzędzi deweloperskich do rozwoju konektorów Wymagane

14.2 Możliwość tworzenia konektorów w oparciu o język Java lub C lub C++ lub C# Opcjonalne

14.3 Dostarczenie narzędzi deweloperskich do rozwoju workflow Wymagane


Strona 28 z 46

14.4 Możliwość eksportu/importu workflow Opcjonalne

14.5 Dostępność narzędzi umożliwiających wersjonowanie kodu Opcjonalne

14.6 Możliwość modelowania workflow w trybie graficznym za pomocą obiektów graficznych Wymagane

2.2.15. Wymagania dotyczące systemu raportowego


15.1

Możliwość ekstrakcji danych raportowych do plików opartych o otwarte formaty danych (np. plik CSV) gwarantujących dalsze przetwarzanie tych danych w aplikacjach zewnętrznych, w tym oprogramowaniu MS Excel

Wymagane

15.2Możliwość tworzenia dowolnych raportów systemowych opartych na danych repozytorium tożsamości

Wymagane

15.3 Dostępność raportu procesów akceptacji (workflow) Wymagane

15.4 Dostępność raportu historii zmian na użytkowniku wraz z osobą wykonującą zmianę Wymagane

15.5 Dostępność raportu logowania do portalu samoobsługi Wymagane

15.6 Dostępność raportu zmian na roli biznesowej Wymagane

15.7 Dostępność raportu tożsamości posiadających wybraną rolę biznesową Wymagane

15.8 Dostępność raportu użytkowników uprzywilejowanych Wymagane

15.9Dostępność raportu kont na SI niezgodnych z stanem w SZT np.: przyznane niezgodne uprawnienia

Wymagane

15.10 Dostępność raportu użytkowników zablokowanych Wymagane

15.11

Dostępność raportów wydajnościowych kluczowych komponentów oraz raportów pokazujących dostępność Systemu w określonym zakresie czasu

Opcjonalne


Strona 29 z 46

2.2.16. Wymagania dotyczące skalowalności


16.1

System ma umożliwiać skalowalność rozwiązania do maksymalnej liczby 100 tys. użytkowników wraz z zachowaniem wskaźników wydajnościowych z pkt 13 zakładając że może to wymagać skalowania przez rozbudowę systemu o dodatkowe komponenty sprzętowe, programowe lub licencyjne

Wymagane

2.2.17. Wymagania dotyczące kopii zapasowych


17.1 Możliwość wykonania pełnej kopii zapasowej bazy danych tożsamości SZT Wymagane

17.2 Możliwość wykonania kopii przyrostowej bazy danych tożsamości SZT Wymagane

17.3 Możliwość odtworzenia bazy danych tożsamości SZT do wybranego punktu w czasie Wymagane

17.4 Możliwość szyfrowania kopii zapasowej bazy danych SZT Opcjonalne

2.2.18. Wymagania dotyczące monitorowania


18.1Dostępność powiadomień sms lub email do wybranych alarmów, ostrzeżeń, zdarzeń systemowych

Wymagane

18.2 Dostępność statusu podstawowych komponentów SZT Wymagane

18.3

System powinien posiadać możliwość zintegrowania z systemem monitoringu posiadanymi przez Zamawiającego tj. MS SCOM lub zapewniać własne narzędzia monitoringu

Wymagane

2.2.19. Wymagania dotyczące realizacji przedmiotu zamówieniaZamawiający wymaga by realizacja zawierała następujące etapy:

Przeprowadzenie szczegółowej analizy wymagań Zamawiającego oraz przygotowanie Projektu Biznesowo- Technicznego,


Strona 30 z 46

Wdrożenie przedprodukcyjne, Przeprowadzenie testów, Przygotowanie dokumentacji systemu, Opracowanie i przeprowadzenie szkoleń, Wdrożenie produkcyjne, Wsparcie po starcie produkcyjnym.

Przedstawione powyżej produkty realizowane w ramach etapu III zgodnie z Załącznikiem nr 3 – Harmonogram realizacji Umowy będą podlegały dodatkowemu odbiorowi przez Zamawiającego. Podstawą odbioru etapu III będzie również potwierdzenie bez zastrzeżeń odbioru tych produktów przez Zamawiającego.

Poniżej przedstawiono szczegółowe wymagania dla poszczególnych etapów.

2.2.19.1. Analiza wymagań i Projekt Biznesowo-TechnicznyPrzygotowanie założeń ogólnych projektu zawierających:

Cel projektu Zakres projektu Podejście do problemu Proponowane rozwiązania Planowany harmonogram wdrożenia Struktura zarządzania projektem Wymagane zasoby

Przygotowanie założeń szczegółowych w zakresie:

Budowy konektorów do wymaganych SI Mechanizmów szyfrowania danych Implementacji procesów biznesowych Struktury raportów oraz mechanizmów audytu Budowy interfejsu portalu samoobsługi

Projekt Biznesowo-Techniczny podlega 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ż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.

Zamawiający dokona 4 przeglądów Analizy wymagań i Projektu Biznesowo-Technicznego przygotowanego przez Wykonawcę w trybie śledzenia zmian i wprowadzania komentarzy. Dokumentacja będzie weryfikowana w następujących etapach zaawansowania prac nad dokumentem:

25% - struktura dokumentu i najważniejsze decyzje projektowe 75% - dokument zawierający wszystkie ogólne elementy projektu 95% - dokument zawierający szczegółowe założenia 99% - wersja finalna zawierająca wszelkie uzupełnienia zgłaszane ze strony

Zamawiającego


Strona 31 z 46

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

2.2.19.2. Wdrożenie przedprodukcyjne Etap obejmuje przeprowadzenie wdrożenia przedprodukcyjnego środowiska SZT, a w

szczególności:

Przygotowanie infrastruktury technicznej środowiska produkcyjnego, składające się z instalacji i konfiguracji serwerów.

Przygotowanie infrastruktury technicznej środowiska testowego, składające się z instalacji, konfiguracji systemów operacyjnych.

Przygotowanie infrastruktury oprogramowania SZT, a w szczególności: instalacji bazy danych systemu SZT, instalacji centralnego repozytorium tożsamości, instalacji portalu samoobsługi.

Wykonanie integracji z systemem SAP HCM poprzez przygotowanie ekstraktora danych HCM. Ekstraktor musi umożliwiać replikację danych HCM zawartych w Tabela 4 oraz umożliwiać obsługę błędów ekstrakcji.

Przygotowanie konektorów do systemów objętych pierwszą fazą wdrożenia: ESS/MSS/LSO , domeny AD i serwera pocztowego Exchange. Konektory muszą zapewniać replikację parametrów określony w Tabela 4. Lista atrybutów HCM.

Wykonanie inicjalnego ładowania wszystkich pracowników z systemu HCM do centralnego repozytorium tożsamości oraz powiązania ich z istniejącymi użytkownikami ESS/MSS/LSO , domeny AD i serwera pocztowego Exchange. Dane HCM dostępne na systemie DEV/TST muszą zostać poddane procesowi anonimizacji.

Wykonanie inicjalnego ładowania ról z SI oraz zbudowanie podstawowej roli biznesowej, nadawanej wszystkim pracownikom, składającej się z uprawnień dostępowych do:

ESS/MSS/LSO, oraz co najmniej 10 ról technicznych: Domeny AD Serwera poczty Exchange

Wykonanie konfiguracji portalu samoobsługi SZT oraz związanej z tym budowy katalogu ról dostępowych oraz użytkowników testowych.

Udostępnienie portalu samoobsługi dla sądów objętych wdrożeniem zgodnie z Listą Dystrybucyjną (Załącznik nr 2 do Umowy).

Implementacja mechanizmu SSO w postaci autentykacji domenowej SPNego dla systemów: portal samoobsługi SZT, portal ESS/MSS/LSO.

Konfiguracja mechanizmu raportowania oraz budowa raportów zgodnie z przeprowadzoną analizą wymagań.

Implementacja mechanizmu workflow dla co najmniej 5 procesów biznesowych. Wykonanie tzw. hardeningu wszystkich komponentów software’owych systemu, w

tym: systemów operacyjnych, baz danych, serwerów aplikacyjnych, aplikacji, konfiguracja mechanizmów szyfrowania.

Przeprowadzenie testów zgodnie z Planem Testów.


Strona 32 z 46

2.2.19.3. Scenariusze testówSzczegółowe Scenariusze testowe muszą zostać stworzone przez Wykonawcę SZT i

zaakceptowane przez Zamawiającego. Testy powinny obejmować następujące obszary:

Testy funkcjonalności Testy wydajności Testy niezawodności Testy bezpieczeństwa Testy procedur

Scenariusze testów podlegają procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje uwagi Wykonawcy niezwłocznie (jednak w terminie nie dłuższym niż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.

Zamawiający dokona 2 przeglądów projektu scenariuszy testów przygotowanego przez Wykonawcę w trybie śledzenia zmian i wprowadzania komentarzy. Dokumentacja będzie weryfikowana w następujących etapach zaawansowania prac:

50% - struktura dokumentu, zinwentaryzowane scenariusze testowe 100% - wersja finalna zawierająca wszelkie uzupełnienia zgłaszane ze strony

Zamawiającego

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

2.2.19.4. Wdrożenie produkcyjneEtap obejmuje przeprowadzenie wdrożenia produkcyjnego środowiska SZT, a w

szczególności:

Przygotowanie infrastruktury technicznej środowiska produkcyjnego, składające się z instalacji i konfiguracji serwerów.

Przygotowanie infrastruktury technicznej środowiska testowego, składające się z instalacji i konfiguracji systemów operacyjnych.

Przygotowanie infrastruktury oprogramowania SZT, a w szczególności: instalacji bazy danych systemu SZT, instalacji centralnego repozytorium tożsamości, instalacji portalu samoobsługi.

Wykonanie integracji z systemem SAP HCM poprzez przygotowanie ekstraktora danych HCM. Ekstraktor musi umożliwiać replikację danych HCM zawartych w Tabeli 3 oraz zapewniać narzędzie do obsługi błędów ekstrakcji.

Przygotowanie konektorów do systemów objętych pierwszą fazą wdrożenia: ESS/MSS/LSO, domeny AD i serwera pocztowego Exchange. Konektory muszą zapewniać replikację parametrów określony w Tabeli 4.

Wykonanie inicjalnego ładowania wszystkich pracowników z systemu HCM do centralnego repozytorium tożsamości oraz powiązania ich z istniejącymi użytkownikami ESS/MSS/LSO, domeny AD i serwera pocztowego Exchange. Wykonanie inicjalnego ładowania ról z SI oraz zbudowanie podstawowej roli biznesowej, nadawanej wszystkim pracownikom, składającej się z uprawnień dostępowych do:


Strona 33 z 46

ESS/MSS/LSO, oraz co najmniej 10 ról technicznych Domeny AD

Serwera poczty Exchange

Wykonanie konfiguracji portalu samoobsługi SZT oraz związanej z tym budowy katalogu ról dostępowych oraz użytkowników testowych.

Udostępnienie portalu samoobsługi dla sądów objętych wdrożeniem zgodnie z Listą Dystrybucyjną (Załącznik nr 2 do Umowy).

Implementacja mechanizmu SSO w postaci autentykacji domenowej SPNego dla systemów: portal samoobsługi SZT, portal ESS/MSS/LSO.

Implementacja mechanizmu wysokiej dostępności HA dla środowiska produkcyjnego.

Konfiguracja mechanizmu raportowania oraz budowa raportów zgodnie z przeprowadzoną analizą wymagań.

Implementacja mechanizmu workflow dla co najmniej 5 procesów biznesowych. Wykonanie tzw. hardeningu wszystkich komponentów software’owych systemu, w

tym: systemów operacyjnych, baz danych, serwerów aplikacyjnych, aplikacji, konfiguracja mechanizmów szyfrowania.

Przeprowadzenie testów zgodnych z Planem Testów.

2.2.20. Wymagania dotyczące dokumentacji projektowejDokumentacja projektowa powinna być prowadzona w postaci repozytorium

elektronicznego.

Po zakończeniu realizacji Projektu, Wykonawca ma obowiązek całą dokumentację zgromadzoną w repozytorium elektronicznym przekazać Zamawiającemu.

Dokumentacja projektowa powinna zawierać następujące elementy, sporządzone przez Wykonawcę i akceptowane przez Zamawiającego na poszczególnych etapach projektu:

Dokument analizy wymagań (w tym notatki ze spotkań)

Projekt Biznesowo - Techniczny

Plan testów

Dokumentacja powykonawcza

Dokumentacja użytkownika

Poniżej przedstawiono wymagania dla poszczególnych elementów dokumentacji:

2.2.20.1. Analiza wymagańW ramach przeprowadzonej analizy wymagań w dokumencie muszą być zawarte:

Wprowadzenie zawierające proponowanie rozwiązanie, szczegółowy harmonogram wdrożenia, strukturę zarządzania projektem.

Definicja wymagań, która zawiera: integrację pomiędzy komponentami SZT, integrację z poszczególnymi systemami informatycznymi, strukturę raportów, procesy biznesowe, elementy interfejsy użytkownika portalu samoobsługi SZT

Szczegółowe zestawienie systemów, procesów oraz grup użytkowników objętych projektem wdrożenia SZT


Strona 34 z 46

Lista członków zespołu projektowego Zamawiającego oraz Wykonawcy

2.2.20.2. Projekt Biznesowo-TechnicznyDokument projektu technicznego rozwiązania powinien zawierać:

Wprowadzenie zawierające podejście do rozwiązania problemu i wybrane rozwiązania

Architekturę systemu – szczegółowa specyfikacja wszystkich elementów tworzących SZT, w tym wszystkie elementy tworzące środowisko produkcyjne i dewelopersko/testowe, opis komponentów funkcjonalnych rozwiązania, ich wzajemne powiązania oraz kierunki przepływu informacji.

Konfigurację centralnego repozytorium tożsamości: informacje dotyczące modelu oraz struktury danych w repozytorium, w których będą przechowywane tożsamości oraz przechowywany atrybutów

Projekt ról biznesowych

Projekt konfiguracji portalu użytkownika

Projekt konfiguracji konektorów do poszczególnych systemów zintegrowanych z SZT

Projekt implementacji workflow

Projekt raportów

2.2.20.3. Plan Testów2.2.20.3.1. Zakres testów

Plan testów akceptacyjnych musi obejmować następujące obszary:

testy funkcjonalne – weryfikacja realizowanych funkcjonalności pod kątem wymagań opisanych w dokumencie analizy wymagań

testy niezawodności – potwierdzające zakładane parametry niezawodności (HA)

testy bezpieczeństwa – potwierdzające zakładany poziom bezpieczeństwa informacji

testy procedur – weryfikacja realizowanych funkcjonalności pod kątem procedur opisanych w dokumencie analizy wymagań

testy wydajnościowe – potwierdzające zakładane parametry wydajnościowe.

2.2.20.3.2. Podejście do testówTesty wydajnościowe zostaną przeprowadzone przy wykorzystaniu narzędzia testowego

pozwalającego na przeprowadzenie symulacji pracy realnych użytkowników końcowych na zasadach określony w Projekcie Biznesowo-Technicznym.

Wymaga się przeprowadzenie testów wg. wymagań określonych w Tabeli 6.

Scenariusz testowy Ilość iteracji

Warunki symulacji Maksymalny czas oczekiwania

Oczekiwanie na wyświetlanie formularza edycji atrybutów tożsamości

3 100 użytkowników równoległych

3 sekundy

500 użytkowników równoległych

3 sekundy

2000 użytkowników 5 sekund


Strona 35 z 46

równoległychOczekiwanie na wyświetlanie formularza resetu hasła


3 sekundy


3 sekundy


5 sekund

Oczekiwanie na wyświetlenie ekranu akceptacji wybranego wniosku workflow


3 sekundy


3 sekundy


5 sekund

Odpowiedź systemu na wysłanie formularza wniosku o przyznanie roli


3 sekundy


3 sekundy


5 sekund

Oczekiwanie na raport systemowy


10 minut


10 minut


20 minut

Oczekiwanie na replikację zmian wykonanych na atrybutach HCM do docelowego SI

3 100 wykonanych zmian atrybutów HCM

30 minut

500 wykonanych zmian atrybutów HCM

30 minut

2000 wykonanych zmian atrybutów HCM

45 minut

Tabela 6. Scenariusz testów wydajnościowych

2.2.20.3.3. Kryteria akceptacjiWynik testów funkcjonalnych uznaje się za pozytywny, gdy występuje zgodność opisu

oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę, z faktycznym stanem po zakończeniu danego przypadku testowego, w określonych w danym przypadku testowym warunkach.

Wynik testów funkcjonalnych uznaje się za negatywny, gdy którykolwiek ze składowych wyników rzeczywistych określonych w Scenariuszu testów stworzonym przez Wykonawcę różni się od oczekiwanego.

Wynik testów niezawodności uznaje się za pozytywny, gdy występuje zgodność oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę z faktycznym stanem po zakończeniu danego przypadku testowego.

Wynik testów procedur uznaje się za pozytywny, gdy występuje zgodność oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę z faktycznym stanem po zakończeniu danego przypadku testowego.


Strona 36 z 46

Wynik testów wydajnościowych uznaje się za pozytywny jeśli 100% odpowiedzi serwera aplikacyjnego jest poprawnych, a 95% odpowiedzi jest lepszych od progu akceptacji określonego w Tabeli 6 w kolumnie Maksymalny czas oczekiwania.

2.3.Gwarancja i serwis (serwis gwarancyjny)Wykonawca będzie świadczył na rzecz Zamawiającego usługi gwarancyjne i serwisowe, które muszą zapewniać Zamawiającemu w ramach wynagrodzenia umownego usuwanie awarii, usterek i wad dostarczonych urządzeń oraz awarii, błędów programistycznych w dostarczonym oprogramowaniu wg. warunków i ram czasowych określonych w Tabela 7:Zasady realizacji usług.

2.3.1.Procedura realizacji zgłoszeń (Awaria, Błąd, Konsultacja, Konserwacja)a. Zamawiający przewiduje następujące kanały komunikacji:

i. za pośrednictwem formatki ekranowej zgłoszenia w aplikacji Service Desk udostępnionej przez Zamawiającego,

ii. w przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie na numer wskazany przez Wykonawcę,

iii. w przypadku zgłoszeń typu Konsultacja, również telefonicznie na numer wskazany przez Wykonawcę.

b. Zgłoszenie przesłane przez Zamawiającego lub Użytkownika po godz. 16.30 w dniu roboczym Wykonawca przyjmuje do realizacji następnego dnia roboczego o godz. 7.30 z wyłączeniem Awarii, które przyjmuje się do realizacji niezwłocznie po zarejestrowaniu zgłoszenia.

c. Za moment zgłoszenia uznaje się datę i godzinę zarejestrowania zgłoszenia w aplikacji Service Desk.

d. Zamawiający kategoryzuje zgłoszenia na formularzu zgłoszenia zgodnie z kwalifikacją określoną w tabeli zawierającej rodzaje kwalifikacji zgłoszeń. Wykonawca może zmienić kategorię zgłoszenia za uprzednią zgodą Zamawiającego.

e. Zamawiający określa które Błędy powinny być realizowane w pierwszej kolejności. Określenie Zamawiającego jest wiążące dla Wykonawcy.

f. Prawidłowa realizacja zgłoszenia, musi być zweryfikowana i potwierdzona w testach akceptacyjnych przez Zamawiającego. Czas poświęcony na weryfikację zgłoszenia nie jest wliczany w czas jego realizacji przez Wykonawcę.

g. Wykonawca zobowiązuje się świadczyć usługi gwarancyjne względem urządzeń w miejscu ich użytkowania z możliwością naprawy w serwisie Wykonawcy, jeżeli naprawa urządzeń w miejscu użytkowania okaże się niemożliwa. W przypadku braku możliwości dokonania naprawy w miejscu użytkowania urządzeń i konieczności jego dostarczenia do punktu serwisowego wskazanego przez Wykonawcę, koszty dostarczenia uszkodzonego sprzętu do punktu serwisowego oraz z punktu serwisowego do miejsca użytkowania pokrywa Wykonawca. Pod pojęciem „urządzenia” lub „sprzęt” należy rozumieć komponenty sprzętowe wchodzące w skład Infrastruktury sprzętowej.

h. Wykonawca ponosi wszelkie koszty naprawy urządzeń, w tym kosztów transportu, instalacji i uruchomienia Sprzętu.

i. Nośniki informacji takie jak np. dyski twarde, pamięci flash, mogą być naprawiane jedynie w miejscu ich użytkowania, a w przypadku konieczności wymiany uszkodzonych nośników na nowe, wolne od wad, nośniki informacji nie podlegają zwrotowi do Wykonawcy. W przypadku konieczności dokonania naprawy sprzętu


Strona 37 z 46

wyposażonego w nośniki informacji poza miejscem użytkowania, nośniki pozostają w siedzibie Zamawiającego.

j. Wykonawca najpóźniej w dniu zawarcia umowy dostarczy Zamawiającemu dane niezbędne do autoryzacji na stronie producenta sprzętu w celu pobierania nowych wersji oprogramowania urządzeń, poprawek, korzystania z bazy wiedzy, instrukcji obsługi itp.

k. Wykonawca zobowiązuje się, że nie będzie dokonywał żadnych modyfikacji sprzętu bez wcześniejszego uzgodnienia ich z Zamawiającym. Zamawiający zastrzega sobie prawo do samodzielnej rozbudowy sprzętu i dokonywania zmian w konfiguracji.

l. W przypadku gdy przewidywany czas naprawy komponentów sprzętowych Infrastruktury informatycznej będzie dłuższy niż 24 godziny, Wykonawca najpóźniej następnego dnia po upływie tego czasu dostarczy na własny koszt zastępcze komponenty sprzętowe o co najmniej takich samych parametrach i funkcjach użytkowych jak komponent naprawiany.

m. W przypadku wystąpienia awarii tego samego elementu po wykonaniu 3 napraw w okresie obowiązywania umowy, Wykonawca zobowiązuje się na pisemne wezwanie Zamawiającego do wymiany tego elementu sprzętu na sprawny, tego samego producenta i tego samego typu o parametrach nie gorszych niż element wymieniany w terminie 30 dni od dnia otrzymania wezwania do wymiany.

n. Wykonawca jest zobowiązany do odbioru i utylizacji sprzętu podlegającego wymianie, z wyjątkiem nośników informacji, które w każdym przypadku pozostają u Zamawiającego.

o. Zamawiający ma prawo do wykonania rozbudowy lub relokacji urządzeń przez podmioty trzecie, posiadające stosowne uprawnienia producenta bez utraty prawa do usług gwarancyjnych oraz wsparcia eksperckiego dla urządzenia, z zastrzeżeniem, że Wykonawca nie ma obowiązku świadczenia usług serwisu dla dokonanej rozbudowy (taki obowiązek będzie ciążył na podmiocie trzecim, który ją wykonał).

2.3.2. Klasyfikacja zgłoszeń1. Awaria (błąd krytyczny) – oznacza sytuację, w której nie jest możliwe prawidłowe

używanie przez Zamawiającego SZT, zarówno z powodu uszkodzenia elementów sprzętowych, oprogramowania, jak również uszkodzenia lub utraty kodu programu, struktur danych oraz zawartości baz danych.Awaria to również usterka, która uniemożliwia użytkowanie SZT w zakresie jego podstawowej funkcjonalności, które prowadzi do:

zatrzymania eksploatacji SZT jako całości lub jego istotnej części, zatrzymania eksploatacji pojedynczego lub kilku elementów wchodzących w skład

SZT, utraty danych lub naruszenia ich spójności.

w wyniku czego niemożliwe jest prowadzenie przez Zamawiającego normalnej działalności z użyciem SZT, a w szczególności dokonywanie bieżącej obsługi zarządzania tożsamościami użytkowników przez Zamawiającego.

2. Błąd – oznacza działanie powtarzalne, pojawiające się w tym samym elemencie SZT (w urządzeniach lub oprogramowaniu), prowadzące w każdym przypadku do otrzymania błędnych lub niepełnych wyników działania; pomimo, iż SZT nadal funkcjonują to usunięcie Błędu wymaga ingerencji pracowników serwisu Wykonawcy.


Strona 38 z 46

3. Konsultacja – oznacza usługę świadczoną przez Wykonawcę polegającą na:a. bieżącym udzielaniu Zamawiającemu wyjaśnień (wskazówek) problemów

powstałych w związku z użytkowaniem SZT,b. bieżącej pomocy w rozwiązywaniu zaistniałych problemów, w czasie

umożliwiającym SZT poprawne i terminowe wykonywanie prac.

4. Konserwacja – oznacza usługę polegającą na dostępie Wykonawcy do SZT w celu wykonania zadań własnych i zleconych przez Zamawiającego, dotyczących elementów tworzących SZT – usługa ta, wraz z usługą Administracji świadczona za pomocą dedykowanego i zabezpieczonego łącza telekomunikacyjnego (zestawianego i utrzymywanego na koszt Wykonawcy), na warunkach ustalonych z Zamawiającym po zawarciu Umowy.

L.P. Pojęcie Ramy czasowe / Ilość

Uwagi

1. Przyjmowanie zgłoszeń: Pn-Pt (dni robocze)7:30-16:30

Wykonawca ma dostęp do aplikacji Service Desk 24/365.

A Awaria (błąd krytyczny) Incydent zgłoszony do godziny 12:00, powinien być poprawiony najpóźniej do godziny 17:00 tego samego dnia.Incydent zgłoszony po godzinie 12:00, powinien być poprawiony najpóźniej do godziny 12:00 następnego dnia. Po udostępnieniu rozwiązania czasowego pozwalającego na realizację błędnie działającej usługi (wdrożeniu obejścia) Awaria (błąd krytyczny) staje się Błędem.

Czas liczony od momentu przesłania przez Zamawiającego „Zgłoszenia Serwisowego” do momentu usunięcia/rozwiązania Awarii (błędu krytycznego).

B. Błąd 2 dni robocze Czas liczony w dniach roboczych od momentu przesłania przez Zamawiającego „Zgłoszenia Serwisowego” do momentu usunięcia błędu.

2. Konsultacja Pn-Pt (dni robocze)8:00-16:00Ilość: do poziomu 24 godzin w każdym miesiącu (godziny nie wykorzystane nie przechodzą na kolejny miesiąc)

Świadczone w trybie zdalnym lub bezpośrednim w siedzibie Zamawiającego na jego żądanie przez wykwalifikowany personel Wykonawcy według potrzeb zgłoszonych przez Zamawiającego w zleceniu konsultacji. Zlecenie konsultacji będzie wysyłane drogą elektroniczną na adres podany przez Wykonawcę lub za pośrednictwem aplikacji Service Desk;


Strona 39 z 46

3. Konserwacja 24/7/365 Usługa świadczona w trybie ciągłym w okresie od dnia podpisania przez Zamawiającego Końcowego Protokołu Odbioru Produktu do dnia, w którym upłynie 12 miesięcy od daty zakończenia realizacji Umowy.

Tabela 7: Zasady realizacji usług2.4.Szkolenia

2.4.1.Szkolenia dla administratorów1. Wykonawca zorganizuje i przeprowadzi 5-dniowe szkolenie stacjonarne, zwane dalej

"Szkoleniem", dla 10 uczestników – administratorów Systemu Zarządzania Tożsamością, dalej: SZT - tj. kadry informatycznej sądów. Uczestnikami szkoleń będą pracownicy sądów - administratorzy SZT skierowani przez kierowników oddziałów informatycznych na szkolenia. Łącznie wymaganych do przeszkolenia w trybie stacjonarnym jest 10 osób.

2. Szkolenie zostanie przeprowadzone w siedzibie Zamawiającego - Sądu Apelacyjnego we Wrocławiu (ul. Namysłowska 8, 50-304 Wrocław). Zamawiający udostępni Wykonawcy bez potrzeby ponoszenia dodatkowych opłat na potrzeby szkolenia sale konferencyjne o odpowiednich wymiarach wyposażone w rzutnik i ekran oraz miejsce dla Trenera, pozwalające przeprowadzić przedmiotowe Szkolenie. Zamawiający zapewni również przerwy kawowe w trakcie Szkolenia.

3. Szkolenie polegać ma na przeprowadzeniu wykładów oraz warsztatów dla Administratorów, uzupełnionych prezentacjami multimedialnymi, odpowiedziami na pytania uczestników sesji szkoleniowych. Szkolenie ma obejmować w szczególności przeprowadzenie wykładów teoretycznego dla Administratorów uzupełnionych prezentacjami multimedialnymi oraz przeprowadzeniu warsztatów praktycznych na SZT. Wykonawca zapewnieni każdemu uczestnikowi wyłączny dostępu do komputera z dostępem do SZT w konfiguracji takiej jak u Zamawiającego.

4. Wykonawca w porozumieniu z Zamawiającym ustali termin szkolenia, który przypadać będzie w lutym 2016 r. Termin Szkolenia ujęty zostanie w Planie Projektu. W razie wątpliwości dotyczących ustalenia kwestii, o których mowa powyżej, za wiążące uznaje się stanowisko Zamawiającego.

5. Zamawiający przedstawi Wykonawcy imienną listę osób uczestniczących w szkoleniu na 5 dni roboczych przed rozpoczęciem Szkolenia.

6. Wszystkie Szkolenia przeprowadzone mają być w języku polskim, oraz zapewnione mają być materiały szkoleniowe dla uczestników. Wykonawca przedstawi do akceptacji Zamawiającemu zakres merytoryczny Szkoleń w terminie do 60 dni od dnia zawarcia Umowy. Zamawiający w terminie 14 dni dokonuje akceptacji zakresu merytorycznego szkoleń, w szczególności warsztatów lub zgłasza do niego uwagi. Wykonawca zobowiązany jest do uwzględnienia uwag Zamawiającego w terminie 7 dni od dnia ich otrzymania.

7. Po szkoleniu zostanie sporządzona przez Wykonawcę lista obecności z podpisem każdego obecnego uczestnika szkolenia. Wzór listy obecności zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego w terminie 14 dni od zawarcia Umowy.

8. Wykonawca obowiązany jest do przedłożenia Zamawiającemu imiennej listy obecności obejmującej co najmniej imiona i nazwiska osób uczestniczących, datę i miejsce szkolenia, Sąd, do którego należą uczestnicy oraz podpis uczestników.


Strona 40 z 46

9. Lista obecności podpisana przez wszystkich obecnych na szkoleniu uczestników szkolenia jest jednym z warunków pozytywnego odbioru szkolenia i podpisania Protokołu Odbioru Etapu III przez Zamawiającego w zakresie Szkoleń.

10. Wykonawca odpowiada za zapewnienie 10 noclegów dla uczestników Szkolenia:a) Obiekt musi znajdować w granicach administracyjnych miasta Wrocław, w

odległości do 5 km w linii prostej od siedziby Zamawiającego (ul. Namysłowska 8, 50-304 Wrocław).

b) Obiekt nie może być w trakcie prac remontowych w czasie trwania szkolenia.c) Wykonawca zapewnia wszystkie miejsca noclegowe w sposób zapewniający

samodzielny pobyt w pokoju (Zamawiający dopuszcza zakwaterowanie samodzielne jednego uczestnika w pokoju dwuosobowym, przy czym cena noclegu w pokoju dwuosobowym jest równa cenie za nocleg w pokoju jednoosobowym),

d) Każdy z pokoi noclegowych z łazienką, TV, łącze internetowe (Wi-Fi) posiadających otwierane okna lub działającą klimatyzację.

e) Obiekt co najmniej *** (trzy gwiazdki), w rozumieniu przepisów § 2 ust. 2 pkt 1 rozporządzenia Ministra Gospodarki i Pracy z dnia 19 sierpnia 2004 r. w sprawie obiektów hotelarskich i innych obiektów, w których są świadczone usługi hotelarskie (Dz. U. z 2006 r., Nr 22, poz. 169 ze zm.). Na każde żądanie Zamawiającego Wykonawca obowiązany jest okazać kopię decyzji właściwego Marszałka Województwa o nadaniu kategorii hoteli na podstawie art. 38 ust.1 i art. 42 ustawy z dnia 29 sierpnia 1997 r. o usługach turystycznych (t.j. Dz. U. z 2014 r., poz. 196 ze zm.),

f) W koszt noclegu musi być wliczone śniadanie dla każdego z uczestników w formie stołu szwedzkiego.

11. Szkolenie powinno być przeprowadzone przez trenera posiadającego doświadczenie i kwalifikacje, we wskazanych poniżej tematach i zakresie czasowym:

Temat szkolenia Minimalna liczba dni Szkolenia

1. Zarządzanie użytkownikami oraz rolami2. Zarządzanie strukturą organizacyjną

2

4. Obsługa konektorów do systemów podłączonych5. Wykorzystanie narzędzi developerskich do tworzenia /

modyfikowania procesów6. Rekoncyliacja danych z zewnętrznych źródeł

2

8. Czynności utrzymaniowe systemu zarządzania tożsamością

9. Rozwiązywanie problemów związanych z funkcjonowaniem systemu zarządzania tożsamością

1

Tabela 8: Tematyka i zakres czasowy szkoleń

12. Wymagania szczegółowe dotyczące Szkolenia: a) Szkolenie 5-dniowe dla administratorów Systemu SZT w siedzibie Zamawiającego,


Strona 41 z 46

b) Liczba godzin szkolenia: 6 godzin szkoleniowych dziennie (1 godz. szkoleniowa – 45 min), przy czym część praktyczna (tzw. warsztaty) nie może być krótsza, niż 3 godziny dziennie;

c) Szkolenia odbywa się w godzinach: 9.00-15.30 (wraz z 2 przerwami kawowymi po 15 min. każda; godziny przerw ustalane indywidualnie pomiędzy Trenerem i uczestnikami Szkolenia)

d) Termin realizacji szkolenia: luty 2016r., dokładny termin Szkolenia zostanie ustalony z Zamawiającym i ujęty w Planie Projektu;

e) Zakres szkolenia powinien zawierać, co najmniej zagadnienia opisane w tabeli powyżej tj.: Zarządzanie użytkownikami oraz rolami; Zarządzanie strukturą organizacyjną; Obsługa konektorów do systemów podłączonych; Wykorzystanie narzędzi developerskich do tworzenia / modyfikowania procesów; Rekoncyliacja danych z zewnętrznych źródeł; Czynności utrzymaniowe systemu zarządzania tożsamością; Rozwiązywanie problemów związanych z funkcjonowaniem systemu zarządzania

tożsamością;

13. Po zakończeniu szkolenia Wykonawca przygotuje i następnie rozda uczestnikom do wypełnienia imienne ankiety ewaluacyjne. Ankieta powinna zawierać minimum następujące elementy:

a) imię i nazwisko,b) program szkolenia,c) ocenę zastosowanych metod szkoleniowych, d) ocenę wiedzy zdobytej przez uczestnika, e) ocenę przydatności szkolenia, f) ocenę kompetencji Wykładowcy/Trenera, g) ocenę stopnia realizacji programu, h) inne elementy wpływające na jakość szkolenia,i) uwagi dotyczące szkolenia.

Wszystkie oceny w skali szkolnej od 1 do 6, przy czym 1 – ocena niedostateczna, 6 – ocena celująca.

Wzór ankiety zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego przed rozpoczęciem szkoleń (nie później niż na 14 dni roboczych przed szkoleniem). W terminie 7 dni od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. Wykonawca przedstawi także raport ewaluacyjny zawierający pełną analizę ocen przeprowadzonego szkolenia przez uczestników nie później niż 10 dni roboczych po przeprowadzeniu szkolenia. Raport ewaluacyjny ze średnią ocen ze wszystkich ankiet równą lub wyższą od 4.0 (liczone następującym sposobem: A = suma punktów z pytań punktowych dla każdej ankiety; B = suma liczby punktów z wszystkich ankiet; C = liczba ankiet; D = średnia ocen ze wszystkich ankiet liczona zgodnie z równaniem B/C=D)jest jednym z warunków odbioru pozytywnego szkolenia. Załącznikiem do raportu ewaluacyjnego są oryginały ankiet ewaluacyjnych wypełnione przez uczestników szkoleń.


Strona 42 z 46

14. Przedmiot zamówienia obejmuje także wyposażenie uczestników szkolenia w odpowiednie materiały szkoleniowe, które po zakończeniu Szkolenia przejdą na ich własność. Na materiały szkoleniowe składają się: drukowane materiały edukacyjne obejmujące co najmniej slajdy z prezentacji multimedialnych wyświetlanych w trakcie szkolenia, długopisy i notesy po jednym dla każdego uczestnika.

15. Wykonawca wyda uczestnikom szkoleń imienne zaświadczenia potwierdzające uczestnictwo w szkoleniach. Zaświadczenie będzie obejmowało: nazwę szkolenia, datę szkolenia i miejsce szkolenia. Projekt zaświadczenia zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego przed rozpoczęciem szkoleń (nie później niż na 14 dni przed datą szkolenia). W terminie 7 dni od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. W razie wątpliwości dotyczących ustalenia kwestii, o których mowa powyżej, za wiążące uznaje się stanowisko Zamawiającego.

16. Odbiór Zaświadczenia oraz materiałów szkoleniowych zostanie potwierdzony przez uczestników Szkoleń na protokole odbioru materiałów szkoleniowych i protokole odbioru zaświadczenia. Oba protokoły będą zawierały minimum: imię i nazwisko uczestnika, datę szkolenia, miejsce i tytuł szkolenia oraz własnoręczne podpisy uczestników szkolenia potwierdzające odbiór poszczególnych produktów. Oryginały obu Protokołów Odbioru Wykonawca przekaże Zamawiającemu wraz z Raportem Ewaluacyjnym.

17. Wszystkie materiały przygotowane przez Wykonawcę (w tym: listy obecności, protokoły odbiorów, programy, zaświadczenia, prezentacje multimedialne, drukowane materiały szkoleniowe) będą oznaczone co najmniej: logotypami NMF, MS oraz projektu w układzie:

a także adresami stron internetowych: www.norwaygrants.org, www.nmf.ms.gov.pl. 18. Wykonawca zapewni także osobę do koordynacji szkoleń odpowiadającą za przygotowanie

szkolenia, która będzie pozostawała w kontakcie telefonicznym i mailowym co najmniej na 14 dni roboczych przed szkoleniem, w trakcie jego trwania i do momentu odbioru usługi Szkolenia. Wykonawca jest odpowiedzialny za zapewnienie Trenerowi noclegu i wyżywienia. Wykonawca jest zobowiązany do przygotowania, powielenia i dystrybucji pomiędzy uczestników materiałów szkoleniowych wraz z przyborami biurowymi (długopis, notes).

19. Brak pozytywnego odbioru szkolenia poprzez: nieuzyskanie w raporcie ewaluacyjnym średniej co najmniej 4.0 ze wszystkich ankiet ewaluacyjnych, brakiem dostarczenia lub dostarczeniem nieprawidłowo wypełnionych: listy obecności, protokołu odbioru materiałów szkoleniowych i protokołu odbioru zaświadczeń oraz oryginałów ankiet ewaluacyjnych skutkuje powtórzeniem Szkolenia na koszt Wykonawcy. Wykonawca z tego tytułu nie będzie sobie rościł praw do dodatkowego wynagrodzenia. Termin powtórnego szkolenia zostanie ustalony z Zamawiającym.

2.4.2.Materiały na potrzeby szkoleń e-learningowych


Strona 43 z 46

1. Wykonawca zobowiązany jest do przygotowania materiałów szkoleniowych dla użytkowników końcowych i administratorów SZT w formie szkoleń e-learning na platformie SAP LSO.

2. Materiały szkolenia e-learningowego wykonane mają być w języku polskim w postaci elektronicznej w formacie SCORM 2004/4.

3. Dla szkoleń e-learningowych Wykonawca zapewni profesjonalne Materiały szkoleniowe, zawierające część teoretyczną oraz ćwiczenia pozwalające na aktywne zdobywanie wiedzy w zakresie:

praca z portalem użytkownika, obsługa wniosków i formularzy, delegowanie zadań i uprawnień, monitorowanie statusu zadań, czynności wykonywane przez administratorów lokalnych (sądów powszechnych).

4. Materiały szkoleniowe muszą być dostępne w polskiej wersji językowej w postaci elektronicznej.

5. Wykonawca z terminie 30 dni od zawarcia Umowy przedstawi Zamawiającemu do akceptacji projekt Materiałów szkoleniowych. W terminie 14 dni od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. W terminie 7 dni od dnia zgłoszenia uwag przez Zamawiającego, Wykonawca poprawi projekt Materiałów szkoleniowych. Wykonawca zobowiązany jest do uwzględnienia uwag Zamawiającego. Warunkiem przystąpienia do realizacji Materiałów szkoleniowych jest akceptacja projektu przez Zamawiającego.

6. Projekt powinien zawierać co najmniej:a. informacje o sposobie przekazania wiedzy, b. plan szkolenia, c. podział na bloki tematyczne, d. informacje o formie sprawdzenia i utrwalenia wiedzy, e. informacje o wykorzystanych funkcjach i dodatkach (np. zdjęcia, zapisy audio

lub audio-wideo), które mają przyczynić się do uatrakcyjnienia szkolenia, f. informacje o formie sprawdzenia nabytej wiedzy, g. informacje o sposobie stylizacji slajdów, h. projekt wizualno-funkcjonalny szkolenia w postaci reprezentatywnych ekranów

szkolenia (prototyp szkolenia zawierający do kilkunastu ekranów szkolenia ujmujący wszystkie typy ekranów i formy dydaktyczne zaplanowane w szkoleniu oraz umożliwiające prezentację nawigacji i narracji),

i. wkład merytoryczny (wszelkie treści dydaktyczne, które będą składały się na przygotowane szkolenia w postaci tekstowej gotowe do przetworzenia na postać szkolenia e-learningowego).

7. W przypadku zmian w Systemie wynikających z instalacji nowych wersji na skutek naprawy błędów, Wykonawca dokona aktualizacji materiałów dla usługi szkoleń e-learningowych, każdorazowo w terminie 30 dni kalendarzowych od wprowadzenia jakichkolwiek zmian.

8. Wszystkie materiały przygotowane przez Wykonawcę w ramach szkoleń e-learningowych (w szczególności: treści dydaktyczne, ekrany szkoleniowe) będą oznaczone co najmniej: logotypami NMF, MS oraz projektu, a także adresami stron internetowych: www.norwaygrants.org, www.nmf.ms.gov.pl.


Strona 44 z 46

2.5.Dokumentacja2.5.1. Dokumentacja powykonawcza

Wykonawca zaktualizuje dokumentację zgodnie z zaakceptowanymi przez Zamawiającego standardami w dziedzinie dokumentowania określonymi w Planie Projektu.

Wykonawca zobowiązuje się do opracowania dokumentacji w języku polskim w jednym wydrukowanym egzemplarzu oraz w wersji elektronicznej w formacie DOC i formacie PDF w przypadku dokumentów tekstowych oraz innych formatach w przypadku diagramów oraz schematów drogą elektroniczną.

Wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się będą wysoką jakością, na którą będą miały wpływ, takie czynniki jak:

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

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.

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

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.

Dokumentacja musi być przekazana w formatach umożliwiających jej późniejszą edycję.

W przypadku zmian w Systemie wynikających z instalacji nowych wersji lub na skutek naprawy błędów, których konsekwencją jest konieczność aktualizacji dokumentacji, Wykonawca dokona aktualizacji dokumentacji Systemu.

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

Dokumentacja powykonawcza projektu SZT musi zawierać obszary:

Architekturę systemu: opis poszczególnych komponentów technicznych, logicznych oraz aspekty niezawodnościowe

Opis ról biznesowych Opis konfiguracji portalu użytkownika Opis konfiguracji konektorów do poszczególnych systemów zintegrowanych z SZT Opis implementacji workflow Opis raportów Procedury eksploatacyjne Procedury awaryjne


Strona 45 z 46

2.5.2.Dokumentacja użytkownika

Dokumentacja użytkownika projektu SZT musi zawierać obszary:

Opis interfejsu portalu samoobsługi SZT

Opis przebiegu poszczególnych procesów akceptacyjnych

Dokumentacja powykonawcza oraz użytkownika podlega 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ż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.

Zamawiający dokona 2 przeglądów projektu dokumentacji przygotowanego przez Wykonawcę w trybie śledzenia zmian i wprowadzania komentarzy. Dokumentacja będzie weryfikowana w następujących etapach zaawansowania prac:

50% - struktura dokumentu, projekty wszystkich obszarów dokumentacji, 100% - wersja finalna zawierająca wszelkie uzupełnienia zgłaszane ze strony

Zamawiającego


Strona 46 z 46

NOTATKA ZE SPOTKANIA · Web viewZamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w...

Documents

Transcript of NOTATKA ZE SPOTKANIA · Web viewZamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w...