OPIS PRZEDMIOTU ZAMÓWIENIA

Znak sprawy: PK XF 261.3.2018 Załącznik nr 1 do SIWZ Załącznik nr 1 do Umowy

OPIS PRZEDMIOTU ZAMÓWIENIA

Dostawa produktów, zaprojektowanie i wdrożenie podsystemów technicznych tworzących Centralne Usługi Infrastrukturalne w ramach projektu „Rozwój Systemu Digitalizacji Akt Postępowań Przygotowawczych (iSDA)”

Spis treści

1. Ogólny Opis Przedmiotu Zamówienia 7

1.1 Kontekst postepowania 7

1.2 Przedmiot postępowania POS-2.2 8

2 Opis stanu aktualnego, udostępniane przez Zamawiającego zasoby 9

2.1 Struktura organizacyjna prokuratury 9

2.2 Struktura organizacyjna ośrodków przetwarzania danych w prokuraturze 11

2.3 Udostępniana infrastruktura Zamawiającego 13

2.3.1 Opis sieci WAN-PROK 13

2.3.1.1 Opis elementów Sieci Operatora 15

2.3.1.2 Opis Urządzeń Bezpieczeństwa B – Zamawiającego 16

2.3.1.3 Warianty instalacji urządzeń bezpieczeństwa 16

2.3.1.3.1 Wariant 1 instalacji urządzeń bezpieczeństwa 16

2.3.1.3.2 Wariant 2 instalacji urządzeń bezpieczeństwa 17

2.3.1.3.3 Wariant 3 instalacji urządzeń bezpieczeństwa 18

2.3.1.3.4 Wariant 4 instalacji urządzeń bezpieczeństwa 18

2.3.1.3.5 Wariant 5 instalacji urządzeń bezpieczeństwa 19

2.3.2 Dostęp do Internetu 20

2.4 Udostępniane zasoby w POPD 20

2.5 Udostępniane stacje robocze i stacje skanowania w Prokuraturze Krajowej, prokuraturach

regionalnych, okręgowych i rejonowych 24

2.5.1 Stacje robocze i stacje skanowania dostarczone w ramach Projektu SDA 24

2.5.1.1 Stacje robocze dostarczone w ramach Projektu SDA 24

2.5.1.2 Stacje skanowania dostarczone w ramach Projektu SDA 24

2.5.1.3 Laptopy 25

2.5.2 Pozostałe stacje robocze zainstalowane w jednostkach prokuratury 25

2.6 Interfejsy do wymiany danych z systemami finansowo-księgowymi 26

2.7 Eksploatowane systemy PKI 27

2.8 Eksploatowane Usługi Katalogowe 27

2.9 Eksploatowane Usługi Poczty Elektronicznej 28

2.10 Zegar 28

3 Szczegółowy opis przedmiotu zamówienia 29

3.1 Wymagania na komponenty zamówienia POS-2.1 29

3.1.1 Wygania w zakresie bezpieczeństwa dla wszystkich komponentów 29

3.1.2 Centralny System Zarządzania Tożsamością (SZT) 32

3.1.3 Centralne Usługi Katalogowe (CUK) 35

3.1.4 Centralna Poczta Elektroniczna (CPE) 37

3.1.5 Centrum Certyfikacji (CC) 40

3.1.6 Centralny Podsystem monitorowania i zarządzania ITS (PMiZ ITS) 42

3.1.7 Centralny Podsystem Wsparcia Eksploatacji i Help Desk (PWEiH) 44

3.2 Specyfikacja środowisk 47

3.3 Specyfikacja wymagań zarządczych 48

3.3.1 Realizacja zamówienia zgodnie z metodyką zarządzania projektem 48

3.3.2 Realizacja zamówienia w oparciu o planowanie prac 49

3.3.3 Realizacja zamówienia z uwzględnieniem procesu zarządzania ryzykiem 50

3.3.4 Realizacja zadań i raportowanie postępów prac 50

3.3.5 Realizacja zamówienia z uwzględnieniem zarządzania jakością 51

3.3.6 Realizacja zamówienia przy zastosowaniu sformalizowanej procedury zarządzania zmianą i obsługi zagadnień 52

3.3.7 Rozstrzyganie sporów związanych z realizacją zamówienia 53

3.3.8 Komunikacja pomiędzy Stronami Umowy 53

3.3.9 Wymagania dotyczące dokumentów 54

3.4 Specyfikacja produktów Specjalistycznych 56

3.4.1 Wykaz produktów 56

3.7 Odbiór końcowy Błąd! Nie zdefiniowano zakładki.

3.4.2 Dostarczenie sprzętu oraz licencji oprogramowania. Wykonanie projektów

technicznych i scenariuszy testów 62

3.4.2.1 Zadanie 1.1. Dostarczenie sprzętu i licencji oprogramowania 62

3.4.2.1.1 PK-01 Lista kontrolna zgodności parametrów dostarczanego sprzętu dla

Centralnych Usług Infrastrukturalnych 62

3.4.2.1.2 PK-02 Plan dostaw sprzętu i licencji dla Centralnych Usług Infrastrukturalnych

62

3.4.2.1.3 PK-03 Dostawa sprzętu i licencji dla Centralnych Usług Infrastrukturalnych 63

3.4.2.2 Zadanie 1.2. Wykonanie projektów technicznych Centralnych Usług

Infrastrukturalnych dla Środowiska Produkcyjnego i Testowego 63

3.4.2.2.1 PK-4 Projekt integracji Podsystemów Centralnych Usług Infrastrukturalnych 63

3.4.2.2.2 PK-5 Projekt infrastruktury techniczno-systemowej dla Centralnych Usług Infrastrukturalnych 65

3.4.2.2.3 PK-6 Projekt Centralnych Usług Katalogowych 66

3.4.2.2.4 PK-7 Projekt Centralnej Poczty 66

3.4.2.2.5 PK-8 Projekt Systemu Zarządzania Tożsamością 67

3.4.2.2.6 PK-9 Projekt Centrum Certyfikacji 68

3.4.2.2.7 PK-10 Projekt Centralnego Systemu Monitorowania i Zarządzania ITS 68

3.4.2.2.8 PK-11 Projekt Podsystemu Wsparcia eksploatacji i Help Desk 69

3.4.2.2.9 PK-12 Projekt Farmy Stacji Roboczych z uwzględnieniem dostaw sprzętu

realizowanego w ramach postępowania POS-2.1 71

3.4.2.2.10 PK-13 Procedura migracji stacji roboczych i stacji skanowania dostarczonych w ramach Projektu SDA do Farmy Stacji Roboczych i integracji z Centralnymi Usługami Infrastrukturalnymi 71

3.4.2.2.11 PK-14 Procedura migracji pozostałych stacji roboczych prokuratury do Farmy Stacji Roboczych i integracji z Centralnymi Usługami Infrastrukturalnymi 72

3.4.2.3 Zadanie 1.3. Wykonanie scenariuszy testów Centralnych Usług Infrastrukturalnych

72

3.4.2.3.1 Wymagania na scenariusze testów dla wszystkich rodzajów testów 72

3.4.2.3.2 Wymagania na Plan Testów dla wszystkich rodzajów testów 74

3.4.2.3.3 PK-15 Scenariusze testów Centralnych Usług Katalogowych 75

3.4.2.3.4 PK-16 Scenariusze testów Centralnej Poczty 75

3.4.2.3.5 PK-17 Scenariusze testów Systemu Zarządzania Tożsamością 76

3.4.2.3.6 PK-18 Scenariusze testów Centrum Certyfikacji 76

3.4.2.3.7 PK-19 Scenariusze testów Centralnego Systemu Monitorowania i Zarządzania ITS. 76

3.4.2.3.8 PK-20 Scenariusze testów Podsystemu Wsparcia eksploatacji i Help Desk 77

3.4.2.3.9 PK-21 Scenariusze testów integracji Podsystemów Centralnych Usług Infrastrukturalnych. 77

3.4.3 Wdrożenie Centralnych Usług Infrastrukturalnych w Środowisku Testowym 77

3.4.3.1 Zadanie 2.1. Konfiguracja i instalacja Centralnych Usług Infrastrukturalnych w Środowisku Testowym 78

3.4.3.1.1 PK-22 Plan testów Centralnych Usług Infrastrukturalnych wraz z integracją dla Środowiska Testowego 78

3.4.3.1.2 PK-23 Konfiguracja infrastruktury techniczno-systemowej Środowiska

Testowego Centralnych Usług Infrastrukturalnych 78

3.4.3.1.3 PK-24 Instalacja podsystemów wchodzących w skład Centralnych Usług

Infrastrukturalnych w Środowisku Testowym 78

3.4.3.1.4 PK-25 Przeprowadzenie testów Centralnych Usług Infrastrukturalnych w Środowisku Testowym 79

3.4.3.2 Zadanie 2.2. Opracowanie dokumentacji i procedur Centralnych Usług Infrastrukturalnych 79

3.4.3.2.1 PK-26 Dokumentacja administratora Usług Katalogowych 79

3.4.3.2.2 PK-27 Dokumentacja udostępniania Usług Katalogowych innym systemom 80

3.4.3.2.3 PK-28 Dokumentacja administratora Poczty 80

3.4.3.2.4 PK-29 Dokumentacja administratora Systemu Zarządzania Tożsamością 81

3.4.3.2.5 PK-30 Dokumentacja użytkowania Systemu Zarządzania Tożsamością dla komórek kadrowych 81

3.4.3.2.6 PK-31 Dokumentacja użytkownika Systemu Zarządzania Tożsamością 83

3.4.3.2.7 PK-32 Dokumentacja udostępniania usług Systemu Zarządzania Tożsamością dla innych systemów 84

3.4.3.2.8 PK-33 Procedury Systemu Zarządzania Tożsamością 84

3.4.3.2.9 PK-34 Dokumentacja administratora Centrum Certyfikacji 85

3.4.3.2.10 PK-35 Dokumentacja użytkownika Centrum Certyfikacji 85

3.4.3.2.11 PK-36 Dokumentacja udostępniania usług Centrum Certyfikacji dla innych systemów 86

3.4.3.2.12 PK-37 Procedury Centrum Certyfikacji 87

3.4.3.2.13 PK-38 Dokumentacja administratora Podsystemu Centralnego Monitorowania i Zarządzania87

3.4.3.2.14 PK-39 Dokumentacja użytkowa administratorów lokalnych Centralnego Podsystemu Monitorowania i Zarządzania 88

3.4.3.2.15 PK-40 Dokumentacja integracji Centralnego Podsystemu Monitorowania i

Zarządzania z innymi systemami 88

3.4.3.2.16 PK-41 Procedury Centralnego Monitorowania i Zarządzania 89

3.4.3.2.17 PK-42 Dokumentacja administratora Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk 89

3.4.3.2.18 PK-43 Dokumentacja użytkownika Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk 90

3.4.3.2.19 PK-44 Dokumentacja użytkownika Centralnego HelpDesk 91

3.4.3.2.20 PK-45 Dokumentacja integracji Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk z innymi systemami 92

3.4.3.2.21 PK-46 Procedury Podsystemu Wsparcia Eksploatacji i HelpDesk 93

3.4.4 Wdrożenie Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym 93

3.4.4.1 Zadanie 3.1. Opracowanie planu testów i wdrażania Centralnych Usług

Infrastrukturalnych w Środowisku Produkcyjnym 93

3.4.4.1.1 PK-47 Plan testów akceptacyjnych Centralnych Usług Infrastrukturalnych wraz z integracją na Środowisku Produkcyjnym 93

3.4.4.1.2 PK-48 Plan wdrożenia Centralnych Usług Infrastrukturalnych 93

3.4.4.2 Zadanie 3.2. Przygotowanie, instalacja i konfiguracja Centralnych Usług Infrastrukturalnych 94

3.4.4.2.1 PK-49 Konfiguracja ITS dla potrzeb Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym 94

3.4.4.2.2 PK-50 Instalacja i konfiguracja Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych na Środowisku Produkcyjnym 95

3.4.4.3 Zadanie 3.3. Testy Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym 95

3.4.4.3.1 PK-51 Testy akceptacyjne Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych na Środowisku Produkcyjnym 95

3.4.4.3.2 PK-52 Testy akceptacyjne integracji Podsystemów wchodzących w skład

Centralnych Usług Infrastrukturalnych 96

3.4.4.4 Zadanie 3.4. Wdrażanie Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym 96

3.4.4.4.1 PK-53 Wdrożenie produkcyjne Centralnych Usług Infrastrukturalnych. 96

3.4.4.5 Zadanie 3.5. Integracja stacji roboczych w Farmę Stacji Roboczych oraz z Usługami Infrastrukturalnymi 97

3.4.4.5.1 PK-54 Integracja dostarczanych w ramach postępowania POS-2.1 stacji roboczych i stacji Projektu SDA w Farmę Stacji Roboczych zintegrowanej z Centralnymi

Usługami Infrastrukturalnymi 97

3.4.4.6 Zadanie 3.6. Przeprowadzenie Pilotażu w Środowisku Produkcyjnym 97

3.4.4.6.1 PK-55 Plan przeprowadzenia Pilotażu 97

3.4.4.6.2 PK-56 Przeprowadzenie Pilotażu 98

3.4.4.7 Zadanie 3.7. Odbiór końcowy 98

3.4.4.7.1 PK-57 Dokumentacja powykonawcza integracji Podsystemów Centralnych Usług Infrastrukturalnych 98

3.4.4.7.2 PK-58 Dokumentacja powykonawcza infrastruktury techniczno-systemowej dla Centralnych Usług Infrastrukturalnych 99

3.4.4.7.3 PK-59 Dokumentacja powykonawcza Centralnych Usług Katalogowych 99

3.4.4.7.4 PK-60 Dokumentacja powykonawcza Centralnej Poczty 100

3.4.4.7.5 PK-61 Dokumentacja powykonawcza Systemu Zarządzania Tożsamością 100

3.4.4.7.6 PK-62 Dokumentacja powykonawcza Centrum Certyfikacji 100

3.4.4.7.7 PK-63 Dokumentacja powykonawcza Centralnego Systemu Monitorowania i

Zarządzania ITS 101

3.4.4.7.8 PK-64 Dokumentacja powykonawcza Podsystemu Wsparcia eksploatacji i Help Desk 101

3.4.4.7.9 PK-65 Dokumentacja powykonawcza Farmy Stacji Roboczych 102

4 Szkolenia 103

4.1 Zadania Wykonawcy 103

4.2 Założenia dla szkoleń stacjonarnych 104

4.2.1 Wymagania na materiały szkoleniowe 106

4.2.2 Wymagania w zakresie organizacji i realizacji szkolenia stacjonarnego. 107

4.3 Wymagania w zakresie szkolenia e-learningowego 110

4.3.1 Założenia na szkolenia e-learningowe 110

4.3.2 Wymagania merytoryczne na szkolenia e-learningowe 110

4.4 Vouchery szkoleniowe 111

5. Słownik 113

Spis rysunków 117

Spis tabel 117

1. Ogólny Opis Przedmiotu Zamówienia

1.1 Kontekst postepowania

Prokuratura Krajowa realizuje projekt „Rozwój Systemu Digitalizacji Akt Postępowań Przygotowawczych (iSDA)” współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Polska Cyfrowa, Oś priorytetowa nr 2 „E- Administracja i otwarty rząd”, Działanie 2.1.

W ramach Projektu zostanie uruchomionych pięć postępowań przetargowych:

1. POS-1 – Przedmiotem realizacji umowy jest zaprojektowanie, wykonanie, integracja komponentów i wdrożenie Systemu poprzez wykonanie następujących usług:

a. Zaprojektowanie, wykonanie nowych komponentów Systemu i integracja oraz wdrożenie z pozostałymi komponentami na szczeblu centralnym, a w szczególności

i. portalu zewnętrznego,

ii. podsystemu umożliwiającego przekazywanie zdigitalizowanych akt sprawy, danych o sprawach oraz innych dokumentów organom współpracującym z prokuraturą w prowadzeniu postępowań np. policja, sądy,

iii. centralnego podsystemu obsługującego procesy skanowania, przechowywania i wyszukiwania akt dla prokuratur rejonowych,

iv. centralnego archiwum zdigitalizowanych akt dostępnego dla wszystkich powszechnych jednostek organizacyjnych prokuratury,

v. portalu wewnętrznego umożliwiającego dostęp ze wszystkich jednostek prokuraturom i pracownikom prokuratury do usług Systemu świadczonych z poziomu centralnego poprzez sieć WAN-PROK.

b. Modernizacja i integracja z pozostałymi komponentami Systemu aktualnie eksploatowanych systemów w powszechnych jednostkach organizacyjnych prokuratury:

i. CBD-SIP-PK - system centralnej bazy danych i dostępu do rejestrów zewnętrznych, eksploatowany w POPD,

ii. SIP Libra-2 - system ewidencyjny, eksploatowany w powszechnych jednostkach organizacyjnych prokuratury,

iii. SDA – system digitalizacji eksploatowany w Prokuraturze Krajowej, oraz w jedenastu prokuraturach regionalnych i czterdziestu pięciu prokuraturach okręgowych.

c. Integracja wykonanych usług infrastrukturalnych w ramach postępowania POS-2.x z pozostałymi komponentami Systemu.

d. Skonfigurowanie i zintegrowanie na poziomie warstwy logicznej elementów Infrastruktury Techniczno-Systemowej posiadanej lub będącej w planach zakupów Zamawiającego dla potrzeb budowy Systemu. Pracami konfigurowania i integracji na poziomie warstwy logicznej będą objęte:

i. elementy Infrastruktury Techniczno-Systemowej dostarczonej w ramach postępowania POS-3.x,

ii. stacje robocze i drukarki dostarczane i skonfigurowane w ramach postępowania POS-2.x oraz już posiadane przez Zamawiającego,

iii. elementy Infrastruktury Techniczno-Systemowej będące na wyposażeniu OPDK, jedenastu OPDR oraz czterdziestu pięciu OPDO.

e. Przeprowadzenie szkoleń.

f. Świadczenie usług wynikających z gwarancji jakości.

2. POS-2 .1 – postępowanie przetargowe w ramach którego zostaną zakupione komputery stacjonarne oraz monitory komputerowe.

3. POS-2.2 – postępowanie przetargowe, opisane w niniejszym Opisie Przedmiotu Zamówienia. Szczegółowy opis przedmiotu postępowania określono w rozdziale 1.2.

4. POS-2.3 - postępowanie przetargowe w ramach którego zostaną zakupione drukarki, urządzenia wielofunkcyjne i skanery do digitalizacji akt

5. POS-3.1 – postępowanie przetargowe w ramach którego zostaną zakupione serwery, macierze oraz oprogramowanie niezbędne do uruchomienia Systemu będącego przedmiotem zamówienia POS-1.

6. POS-3.2 – postępowanie przetargowe w ramach którego zostanie zakupiona infrastruktura sieciowa oraz oprogramowanie niezbędne do uruchomienia Systemu będącego przedmiotem zamówienia POS-1.

Wykonawca realizujący umowę w ramach POS-1 wykorzysta i zintegruje na poziomie warstwy logicznej produkty dostarczone w ramach postępowań POS-3.1 oraz POS-3.2 w ramach Systemu.

1.2 Przedmiot postępowania POS-2.2

Postępowanie przetargowe POS-2.2 obejmuje:

1. Wykonanie projektów wykonawczych, realizację i wdrożenie Centralnych Usług Infrastrukturalnych realizowanych przez następujące Podsystemy zdefiniowane w ramach Projektu iSDA:

a.ASI.K.013 Zarządzanie_Tożsamością_Usługi_Katalogowe – w skład Podsystemu wchodzi:

i. Centralny System Zarządzania Tożsamością,

ii. Centralne Usługi Katalogowe,

iii. Centralna Poczta Elektroniczna,

b.ASI.K.014 Centrum_Certyfikacji_Zegar – w skład Podsystemu wchodzi:

i. Centrum Certyfikacji,

ii. Zegar.

c.ASI.K.040 Zarządzanie_i_monitorowanie_ITS,

i. Centralny System Zarządzania i Monitorowania Farmą Stacji Roboczych,

ii. Centralny System Zarządzania Oprogramowaniem Antywirusowym.

d.ASI.K.041 Podsystem_Wsparcia_Eksploatacji,

e.ASI.K.042 Podsystem_HelpDesk.

2. Wykonanie projektu wykonawczego integracji Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych oraz przeprowadzenie według projektu integracji i wdrożenia do eksploatacji Centralnych Usług Infrastrukturalnych.

3. Dostawę licencji oprogramowania dla realizacji pkt.1 określonych w OPZ.

4. Dostawę elementów infrastruktury technicznej dla realizacji pkt. 1 określonych w OPZ.

5. Integrację dostarczonych w ramach postępowania POS-2.1 stacji roboczych oraz posiadanych przez Zamawiającego stacji roboczych z Projektu SDA w jednorodną Farmę Stacji Roboczych. Wszystkie stacje robocze włączone w jednorodną Farmę Stacji Roboczych muszą mieć wdrożone Centralne Usługi Infrastrukturalne określone w punkcie 1.

6. Szkolenia.

7. Gwarancja.

8. Wykonawca realizujący umowę w ramach POS-1 wykona integrację Warstwy Logicznej ITS z Centralnymi Usługami Infrastrukturalnymi i Farmę Stacji Roboczych będące przedmiotem niniejszego postępowania POS-2.2.

2 Opis stanu aktualnego, udostępniane przez Zamawiającego zasoby

2.1 Struktura organizacyjna prokuratury

Prokuratura ma organizację hierarchiczną i zbudowana jest z czterech szczebli, które tworzą powszechne jednostki organizacyjne prokuratury:

1. Prokuratura Krajowa (PK) – 1 jednostka.

2. Prokuratury Regionalne (RP) – 11 jednostek.

3. Prokuratury Okręgowe (PO) – 45 jednostek.

4. Prokuratury Rejonowe (PR) – 357 jednostek.

Schemat organizacyjny Prokuratury przedstawiony jest na Rysunek 1. Na rysunku podano dla każdego szczebla ilość jednostek oraz ilość zatrudnionych pracowników.

Liczba

jednostek

1

Liczba

zatrudnionych

Prokuratura Krajowa

280

11

Prokuratura

Regionalna

Prokuratura

Regionalna

934

45

Prokuratura

Okręgowa

Prokuratura

Okręgowa

Prokuratura

Okręgowa

Prokuratura

Okręgowa

3.826

357

8.433

Razem

jednostek 414

Razem

zatrudnionych 13.473

Prokuratura Rejonowa

Prokuratura Rejonowa

Prokuratura Rejonowa

Prokuratura Rejonowa

Prokuratura Rejonowa

Prokuratura Rejonowa

Prokuratura Rejonowa

Prokuratura Rejonowa

Rysunek 1Struktura organizacyjna Prokuratury

Zgodnie z art. 2 ustawy – Prawo o prokuraturze, prokuratura wykonuje zadania w zakresie ścigania przestępstw oraz stoi na straży praworządności. Podstawowym zadaniem Prokuratury jest prowadzenie postępowań karnych i cywilnych oraz administracyjnych.

Należy podkreślić, że prowadzone postępowania na poszczególnych szczeblach różnią się istotnie w zakresie prowadzonego postępowania. Najbardziej złożone postępowania prowadzone są na szczeblu Prokuratury Krajowej i prokuratur regionalnych a najprostsze na szczeblu prokuratur rejonowych. Zakres prowadzonego postępowania przekłada się bezpośrednio na ilość gromadzonych materiałów (dokumentów) oraz na ilość osób i podmiotów uczestniczących i zaangażowanych w prowadzenie postępowania.

W ramach prokuratury występują następujące stanowiska:

1. Stanowiska orzecznicze – prokuratorzy, asesorzy.

2. Stanowiska urzędników.

3. Stanowiska innych pracowników.

zgodnie z Rozporządzeniem Ministra Sprawiedliwości z dnia 3 marca 2017 r. w sprawie stanowisk i szczegółowych zasad wynagradzania urzędników i innych pracowników sądów i prokuratury oraz odbywania stażu urzędniczego (Dz. U 2017 poz. 485).

Istotnym elementem chrakteryzującym organizację powszechnych jednostek organizacyjnych prokuratury jest wielkość zatrudnienia w poszczególnych prokuraturach. Tabela 1 przedstawia taką charakterystykę. Jednostki na poszczególnych szczeblach zostały podzielone na Typy, gdzie kryterium podziału przyjęto liczbę zatrudnionych. Podział jednostek na typy jest pomocny przy określaniu parametrów sprzętu ilości licencji oprogramowania dla danej grupy jednostek.

Tabela 1 Podział prokuratur ze względu na ilość zatrudnionych

Prokuratury Rejonowe
Lp.	Zatrudnienie ogółem [osoby]	Typ jednostki	Liczba Prokuratur danego typu
1	do 20	PR-TYP 1	192
2	21 - 50	PR-TYP 2	140
3	51 - 80	PR-Typ 3	21
4	pow. 80	PR-Typ 4	4
Ogółem Prokuratur Rejonowych			357
Prokuratury Okręgowe
Lp.	Zatrudnienie ogółem [osoby]	Typ jednostki	Liczba Prokuratur danego typu
1.	do 50	PO-TYP 1	14
2.	51 - 90	PO-TYP 2	19
3.	110 – 150	PO-TYP 3	5
4.	Pow. 150	PO-TYP 4	7
Ogółem Prokuratur Okręgowych			45
Prokuratury Regionalne

Lp.	Zatrudnienie ogółem [osoby]		Typ jednostki	Liczba Prokuratur danego typu
1.	do 90		RP-TYP 1	6
2.	91 – 120		RP-TYP 2	4
3.	pow. 120		RP-TYP 3	1
Ogółem Prokuratur Regionalnych				11
Prokuratura Krajowa
Lp.	Zatrudnienie ogółem [osoby]		Typ jednostki	Liczba Prokuratur danego typu
1.	280		PK-TYP 1	1
Ogółem				1

2.2 Struktura organizacyjna ośrodków przetwarzania danych w prokuraturze

Realizacja zadań związanych z informatyzacją prokuratury na wszystkich szczeblach realizowana jest w ośrodkach przetwarzania danych oraz na stacjach roboczych i stacjach skanowania. W ośrodkach przetwarzania danych zainstalowane są serwery, macierze dyskowe oraz sprzęt sieciowy. Ośrodki przetwarzania danych wyposażone są w klimatyzację oraz odpowiednie zasilanie energetyczne. Przetwarzanie danych występuje na szczeblu:

1. Centralnym – przetwarzane są dane na potrzeby jednostek prokuratury wszystkich szczebli, realizowany jest dostęp do instytucji zewnętrznych współdziałających z prokuraturą oraz dostęp z Internetu dla użytkowników zewnętrznych. Na szczeblu centralnym występują ośrodki:

a. Podstawowy Ośrodek Przetwarzania Danych (POPD),

b. Zapasowy Ośrodek Przetwarzania Danych (ZOPD) – planowany do budowy w przyszłości,

c. Testowy Ośrodek Przetwarzania Danych (TOPD),

2. Prokuratury Krajowej – zlokalizowany w Prokuraturze Krajowej. Przetwarzane są dane na potrzeby Prokuratury Krajowej. Na szczeblu Prokuratury Krajowej występuje:

a. Ośrodek Przetwarzania Danych Prokuratury Krajowej (OPDK),

b. Stacje Robocze Prokuratury Krajowej (SRPK),

3. Prokuratur Regionalnych – ośrodki przetwarzania danych zlokalizowane są w każdej prokuraturze regionalnej. W ośrodkach przetwarzane są dane na potrzeby prokuratury regionalnej oraz podległych jej jednostek prokuratur okręgowych i rejonowych. Na szczeblu prokuratur regionalnych występuje:

a. Ośrodek Przetwarzania Danych Prokuratury Regionalnej (OPDR),

b. Stacje Robocze Prokuratury Regionalnej (SRPR),

4. Prokuratur Okręgowych – ośrodki przetwarzania danych zlokalizowane są w każdej prokuraturze okręgowej. W ośrodkach przetwarzane są dane na potrzeby prokuratury okręgowej. Na szczeblu prokuratur okręgowych występuje:

a. Ośrodek Przetwarzania Danych Okręgu (OPDO),

b. Stacje Robocze Prokuratury Okręgowej (SRPO),

Ośrodek Przetwarzania

Danych Prokuratury Krajowej

OPDK

Stacje Robocze Prokuratury Krajowej SRPK

1 Prokuratura Krajowa

Ośrodek Przetwarzania

Danych Prokuratury Regionalnej

OPDR

Stacje Robocze Prokuratury

Regionalnej SRPR

11 Prokuratur Regionalnych

Ośrodek Przetwarzania

Danych Prokuratury Okręgowej

OPDO

Stacje Robocze Prokuratury Okręgowej SRPO

45 Prokuratur Okręgowych

357 Prokuratur Rejonowych

Stacje Robocze Prokuratury

Rejonowej SRPRJ

Testowy Ośrodek Przetwarzania Danych TOPD

Zapasowy Ośrodek Przetwarzania Danych ZOPD

Podstawowy Ośrodek Przetwarzania Danych POPD

Szczebel Centralny

Szczebel

Prokuratury Regionalnej

Szczebel

Prokuratury Krajowej

c. Prokuratur Rejonowych – nie występują ośrodki przetwarzania danych. W prokuraturach rejonowych występują jedynie - Stacje Robocze Prokuratury Rejonowej (SRPRJ).

Szczebel

Prokuratury Rejonowej

Szczebel

Prokuratury Okręgowej

Rysunek 2 Struktura organizacyjna ośrodków przetwarzania danych w prokuraturze

Wszystkie jednostki organizacyjne prokuratury połączone są dedykowaną siecią WAN-PROK dzierżawioną od operatora telekomunikacyjnego.

2.3 Udostępniana infrastruktura Zamawiającego

2.3.1 Opis sieci WAN-PROK

Sieć WAN-PROK umożliwia połączenie wszystkich powszechnych jednostek organizacyjnych prokuratury na terenie kraju dla wymiany danych pomiędzy nimi, jak również w celu połączenia z Prokuraturą Krajową w której uruchomione są centralne systemy informatyczne prokuratury.

Sieć WAN-PROK składa się z dwóch warstw:

1. Warstwa pierwsza jest Siecią Operatora w oparciu o którą wykreowano prywatną sieć WAN w technologii IP VPN MPLS dla połączenia powszechnych jednostek organizacyjnych prokuratury. Topologia zbudowanej sieci umożliwia realizację połączeń pomiędzy lokalizacjami każdy z każdym. Sieć Operatora składa się z następujących elementów:

a. routerów dostępowych CE, które instalowane są w lokalizacjach powszechnych jednostkach organizacyjnych prokuratury. Zainstalowany w jednej lokalizacji, jeden router CE może obsługiwać kilka jednostek prokuratury mieszczących się w tej lokalizacji. Routery dostępowe CE są własnością Operatora i zarządzane są przez Operatora,

b. routery brzegowe PE umieszczone są w węzłach sieci szkieletowej Operatora. Routery brzegowe PE są własnością Operatora i zarządzane przez Operatora,

c. łączy dostępowych, które łączą router CE zainstalowany w lokalizacji Zamawiającego z routerem PE zainstalowanym w najbliższym węźle sieci szkieletowej Operatora,

d. stacji monitorowania zainstalowanej w Prokuraturze Krajowej umożliwiającej kontrolę jakości usług świadczonych przez Operatora.

2. Warstwa druga, zapewnia bezpieczeństwo sieci WAN-PROK. Zbudowana jest w oparciu o Urządzenia Bezpieczeństwa umożliwiające połączenia przy zachowaniu wymaganego poziomu bezpieczeństwa sieci LAN lub VLAN danej jednostki prokuratury z routerem dostępowym CE.

Na Rysunku 3 przedstawiono ogólną architekturę sieci WAN-PROK.

Lokalizacja Prokuratury Krajowej

VLAN 1 VLAN N

WAN-PROK

Sieć Operatora

Urządzenie S

Przełącznik LAN Zamawiającego

Urządzenie S

Przełącznik LAN Zamawiającego

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie

Bezpieczeństwa B Zamawiającego

Routr CE

Operatora

Stacja

monitorowania sieci Operatora

Routr PE

Operatora

Sieć

Szkieletowa Operatora

Łącza dostępowe

IP VPN MPLS

Routr PE

Operatora

Routr PE

Operatora

Routr CE

Operatora

Routr CE

Operatora

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie S

Przełącznik LAN Zamawiającego

Urządzenie S

Przełącznik LAN Zamawiającego

VLAN 1

VLAN N

VLAN 1

VLAN N

Lokalizacja L1 Lokalizacja Ln

Rysunek 3 Schemat sieci WAN-PROK

W Tabela 2 przedstawiono dostępne przepustowości łączy sieci WAN-PROK dla prokuratur poszczególnych szczebli. Przepustowość łączy dopasowywana jest do aktualnych potrzeb jednostki prokuratury. Zamawiający przewiduje zwiększenie przepustowości łączy wskazanych w Tabela 2 od maja 2018 roku.

Tabela 2 Zestawienie przepustowości łączy sieci WAN-PROK dla poszczególnych szczebli prokuratury

Lp.	Prokuratury	Przepustowość Mbps
1.	Krajowa (OPDK)	512
2.	Regionalne (OPDR)	256 – 512
3.	Okręgowe (OPDO)	64 - 128

Lp.	Prokuratury	Przepustowość Mbps
4.	Rejonowe	16 - 96

2.3.1.1 Opis elementów Sieci Operatora

1. Routery PE

a. Łącza dostępowe od strony sieci szkieletowej Operatora zakończone są routerami PE (Provider Edge).

b. Routery PE są własnością Operatora, zarządzane z centrum zarządzania Operatora.

c. Routing pomiędzy routerami PE-CE jest zgodny z protokołem eBGP.

2. Routery CE

a. Łącze dostępowe od strony lokalizacji prokuratury zakończone jest routerem CE.

b. Routery CE są własnością Operatora, zarządzane z centrum zarządzania Operatora.

c. W przypadku, gdy dana lokalizacja jest siedzibą kilku jednostek organizacyjnych (np. prokuratury regionalnej i prokuratury okręgowej) wówczas w tej lokalizacji jest tylko jeden router CE do którego podłączonych jest kilka urządzeń bezpieczeństwa B.

3. Routing pomiędzy routerami CE a urządzeniami bezpieczeństwa B jest routingiem statycznym. Pomiędzy routerami CE a urządzeniem bezpieczeństwa B zastosowana jest przez Zamawiającego adresacja point-to-point. Szczegółowa adresacja zostanie przekazana Wykonawcy po podpisaniu umowy.

Jako routery CE w zależności od wielkości jednostki prokuratury, Operator zastosował następujące modele routerów

a. Juniper SRX-240,

b. SRX-220,

c. SRX-210,

d. J-2320.

Routery CE posiadają następującą ilość interfejsów przyłączeniowych:

a. cztery elektryczne interfejsy przyłączeniowe Eth 10/100/1000 dla lokalizacji Prokuratury Krajowej oraz lokalizacji Prokuratur Regionalnych i Okręgowych. W przypadku gdy Prokuratura Regionalna i Prokuratura Okręgowa znajdują się w jednej lokalizacji i jest zestawiane jedno łącze dostępowe i jedno urządzenie CE, jednostki posiadają co najmniej cztery elektryczne interfejsy przyłączeniowe Eth 10/100/1000),

b. dwa elektryczne interfejsy przyłączeniowe Eth 10/100/1000 dla pozostałych lokalizacji Zamawiającego.

4. Wszystkie routery CE podlegają wewnętrznej polityce bezpieczeństwa Operatora, która uwzględnia x.xx.:

a. bezpieczny dostęp przez konsolę,

b. bezpieczny dostęp przez VTY uwzględniający AAA + RSA (wyłącznie jeśli użytkownik ma mieć dostęp do CE),

c. enkrypcję haseł,

d. logowanie do bufferów i sysloga - zdalnej stacji,

e. wyłączanie niewykorzystywanych serwisów,

f. włączone snmp traps,

g. baner przy logowaniu,

h. włączony NTP w celu dokładnych korelacji wydarzeń.

2.3.1.2 Opis Urządzeń Bezpieczeństwa B – Zamawiającego

1. Warstwa druga sieci WAN-PROK zbudowana jest z urządzeń bezpieczeństwa i stanowi zasadniczy element zapewnienia bezpieczeństwa dla użytkowników sieci WAN-PROK.

2. Zastosowano urządzenia bezpieczeństwa typu UTM.

2.3.1.3 Warianty instalacji urządzeń bezpieczeństwa

1. Podstawowym elementem struktury organizacyjnej prokuratury jest „powszechna jednostka organizacyjna prokuratury”. Do powszechnych jednostek organizacyjnych prokuratury należy zarówno Prokuratura Krajowa, jak i prokuratury regionalne, prokuratury okręgowe i prokuratury rejonowe.

2. Powszechne jednostki organizacyjne prokuratury mieszczą się w obiektach fizycznych dalej nazywanymi „lokalizacjami”.

3. Ze względów organizacyjnych występują trzy przypadki umiejscowienia jednostek prokuratury w lokalizacjach:

a. jedna jednostka prokuratury mieści się w jednej lokalizacji,

b. dwie lub więcej jednostek prokuratury mieszczą się w jednej lokalizacji,

c. jedna jednostka prokuratury mieści się w dwóch lub więcej lokalizacjach.

4. Zgodnie z umową podpisaną pomiędzy Zamawiającym a Operatorem routery dostępowe CE zainstalowane są w każdej lokalizacji w której może być jedna lub kilka jednostek prokuratury.

W dalszej części przedstawionych zostanie pięć wariantów podłączenia urządzeń bezpieczeństwa do routerów CE. Zakłada się, że w wyjątkowych przypadkach mogą wystąpić odstępstwa od przedstawionych rozwiązań wariantowych.

2.3.1.3.1 Wariant 1 instalacji urządzeń bezpieczeństwa

1. W Wariancie 1 jedna Jednostka Prokuratury mieści się w jednej lokalizacji.

2. W tym przypadku do routera Operatora CE dołączone jest jedno urządzenie bezpieczeństwa do którego będzie podłączony jeden lub kilka przełączników LAN.

3. W jednostce prokuratury na przełącznikach LAN może być utworzonych kilka sieci VLAN. Do sieci VLAN podłączane są serwery oraz stacje robocze. Zakłada się, że nie będzie zmieniana adresacja urządzeń dołączonych do sieci LAN (VLAN).

Wariant 1

Lokalizacja Lx

Routr CE Operatora

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie S Przełącznik LAN Zamawiającego

Jednostka Prokuratury x

Rysunek 4 Wariant 1 instalacji urządzeń bezpieczeństwa

2.3.1.3.2 Wariant 2 instalacji urządzeń bezpieczeństwa

1. W Wariancie 2 dwie lub kilka jednostek prokuratury mieści się w jednej lokalizacji.

2. W tym przypadku do routera Operatora CE dołączone urządzenia bezpieczeństwa do których podłączone są jeden lub kilka przełączników LAN.

3. W każdej jednostce prokuratury na przełącznikach LAN może być utworzonych kilka sieci VLAN. Do sieci VLAN podłączane są serwery oraz stacje robocze. Zakłada się, że nie będzie zmieniana adresacja urządzeń dołączonych do sieci LAN (VLAN).

Lokalizacja Lx

Routr CE

Operatora

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie S

Przełącznik LAN Zamawiającego

Urządzenie S

Przełącznik LAN Zamawiającego

Jednostka Prokuratury x

Jednostka Prokuratury y

Wariant 2

Rysunek 5 Wariant 2 instalacji urządzeń bezpieczeństwa

2.3.1.3.3 Wariant 3 instalacji urządzeń bezpieczeństwa

1. W Wariancie 3 kilka Jednostek Prokuratury mieści się w jednej lokalizacji.

2. W tym przypadku do routera Operatora CE dołączone jest jedno urządzenie bezpieczeństwa zainstalowane w jednej z jednostek prokuratury. Do urządzenia bezpieczeństwa dołączone są przełączniki LAN, które zainstalowane są w jednostkach prokuratury znajdujące się w danej lokalizacji.

3. W każdej z jednostek prokuratury znajdującej się w danej lokalizacji na przełącznikach LAN mogą być utworzone kilka sieci VLAN. Do sieci VLAN podłączane są serwery oraz stacje robocze. Zakłada się, że nie będzie zmieniana adresacja urządzeń dołączonych do sieci LAN (VLAN).

Lokalizacja Lx

Routr CE Operatora

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie S Przełącznik LAN Zamawiającego

Urządzenie S

Przełącznik LAN Zamawiającego

Jednostka Prokuratury x

Jednostka Prokuratury y

Wariant 3

Rysunek 6 Wariant 3 instalacji urządzeń bezpieczeństwa

2.3.1.3.4 Wariant 4 instalacji urządzeń bezpieczeństwa

1. W Wariancie 4 dwie lub kilka jednostek prokuratury mieści się w jednej lokalizacji.

2. W tym przypadku do routera Operatora CE dołączone jest jedno urządzenie bezpieczeństwa, do którego będzie podłączony jeden lub kilka przełączników LAN obsługujących kilka jednostek prokuratury w danej lokalizacji.

3. Na przełącznikach LAN może być utworzonych kilka sieci VLAN obsługujących jednostki prokuratury w danej lokalizacji. Do sieci VLAN podłączane są serwery oraz stacje robocze. Zakłada się, że nie będzie zmieniana adresacja urządzeń dołączonych do sieci LAN (VLAN).

Lokalizacja Lx

Routr CE Operatora

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie S Przełącznik LAN Zamawiającego

Jednostka Prokuratury x

Jednostka Prokuratury y

Wariant 4

Rysunek 7 Wariant 4 instalacji urządzeń bezpieczeństwa

2.3.1.3.5 Wariant 5 instalacji urządzeń bezpieczeństwa

1. W Wariancie 5 jedna jednostka prokuratury rozlokowana jest w kilku lokalizacjach.

2. W tym przypadku w każdej lokalizacji znajduje się router Operatora CE do którego w każdej lokalizacji dołączone jest jedno urządzenie bezpieczeństwa, do którego będzie podłączony jeden lub kilka przełączników LAN.

3. W każdej lokalizacji zainstalowane są przełączniki LAN, które umożliwią utworzenie kilku sieci VLAN. Do sieci VLAN podłączane są serwery oraz stacje robocze. Zakłada się, że nie będzie zmieniana adresacja urządzeń dołączonych do sieci LAN (VLAN).

Wariant 5

Lokalizacja Ly

Routr CE Operatora

Urządzenie Bezpieczeństwa B Zamawiającego

Urządzenie S Przełącznik LAN Zamawiającego

Jednostka Prokuratury x

Lokalizacja Lx

Routr CE Operatora

Urządzenie

Bezpieczeństwa B Zamawiającego

Urządzenie S Przełącznik LAN Zamawiającego

Jednostka Prokuratury x

Rysunek 8 Wariant 5 instalacji urządzeń bezpieczeństwa

2.3.2 Dostęp do Internetu

Zamawiający zapewni dostęp do Internetu w POPD dwoma łączami o przepustowości minimum 512 Mb/s.

2.4 Udostępniane zasoby w POPD

W POPD zainstalowany jest sprzęt wraz z oprogramowaniem zestawiony w Tabela 3.

Tabela 3 Zestawienie sprzętu i oprogramowania systemowego i narzędziowego zainstalowanego w POPD

Lp.	Opis sprzętu	Ilość
1	Obudowa blade Fujitsu PY BX900 S2: - wszystkie sloty obsadzone Dwa przełączniki LAN 10Gbit. Umożliwiają redundantne wyprowadzenie 2 portów 10Gbit z każdego serwera, po 1 porcie LAN na każdy switch. Dwa przełączniki SAN FC 8Gb, każdy 8 portów zewnętrznych FC 8Gb. Każdy przełącznik posiada wszystkie porty aktywne. Przełączniki wyposażone w 8 wkładek FC 8Gb SFP+ (po 4 sztuki na przełącznik). Gwarancja – 4 lata i 1 miesiąc (49 miesięcy, tj. do 3.01.2020 r.)	1 sztuka

Lp.	Opis sprzętu	Ilość
2	Serwer blade TYP 1 – Fujitsu PY BX2560 M1 Dual Server Blade: 2 x Intel Xeon E5-2620v3 6C/12T 2.40 GHz 192 GB RAM (12 sztuk pamięci 16GB DDR4 2133 MHz) 2 x Dysk SAS 6Gb 10krpm 600GB (skonfigurowane w Raid 1) 2 interfejsy LAN onboard typu 10 Gbit/s. Porty podłączone redundantnie poprzez backplane do switchy zainstalowanych w obudowie blade. 2 interfejsy FC 8Gbps podłączone poprzez backplane do switchy FC zainstalowanych w obudowie blade do obsługi zewnętrznego urządzenia pamięci masowej. Gwarancja – 4 lata i 1 miesiąc (49 miesięcy, tj. do 3.01.2020 r	2 sztuki
3	Serwer blade TYP 2 – Fujitsu PY BX2560 M1 Dual Server Blade: 2 x Intel Xeon E5-2670v3 12C/24T 2.30 GHz 256 GB RAM (16 sztuk pamięci 16GB DDR4 2133 MHz) 2 x Dysk SAS 6Gb 10krpm 600GB (skonfigurowane w Raid 1) 2 interfejsy LAN onboard typu 10 Gbit/s. Porty podłączone redundantnie poprzez backplane do switchy zainstalowanych w obudowie blade. 2 interfejsy FC 8Gbps podłączone poprzez backplane do switchy FC zainstalowanych w obudowie blade do obsługi zewnętrznego urządzenia pamięci masowej. Gwarancja – 4 lata i 1 miesiąc (49 miesięcy, tj. do 3.01.2020 r.)	8 sztuk
4	Serwer blade TYP 3 – Fujitsu PY BX2580 M1 Dual Server Blade: 2 x Intel Xeon E5-2630v4 10C/20T 2.20 GHz 512 GB RAM (16 sztuk pamięci 32GB DDR4 2400 MHz) 2 x Dysk SAS 6Gb 10krpm 600GB (skonfigurowane w Raid 1) 2 interfejsy LAN onboard typu 10 Gbit/s. Porty podłączone redundantnie poprzez backplane do switchy zainstalowanych w obudowie blade. 2 interfejsy FC 8Gbps podłączone poprzez backplane do switchy FC zainstalowanych w obudowie blade do obsługi zewnętrznego urządzenia pamięci masowej. Gwarancja – 3 lata (36 miesięcy, tj. do 15.12.2020 r.)	8 sztuk
5	Serwer rack – Fujitsu PY RX2540 M1 (2U): 2 x Procesor Intel Xeon E5-2630v3 8C/16T 2.40 GHz 128GB RAM typu DDR4 z korekcją błędów Advanced ECC, funkcje scrubbing i SDDC. Możliwość rozbudowy do 768 GB. 2 interfejsy sieciowe typu Ethernet 10/100/1000 nie zajmują slotów PCI Express 2 interfejsy FC 8Gb obsadzone modułami i gotowe do pracy 4 dyski 600GB typu HotPlug SAS 6Gb 10krpm. Możliwość instalacji 8 szt. dysków. Gwarancja – 4 lata i 1 miesiąc (49 miesięcy, tj. do 3.01.2020 r)	3 sztuki
6	Przełącznik SAN - Brocade FC Switch 6505: Przełącznik wyposażony w 24 fizyczne porty FC (sloty na moduły SFP). 16 portów aktywnych, wyposażonych we wkładki SFP SR 8Gb/s. Gwarancja – 4 lata i 1 miesiąc (49 miesięcy, tj. do 3.01.2020 r)	2 sztuki
7	Macierz dyskowa – Hitachi Data Systems VSP G400: • 41 dysków 1.2TB 2.5" o prędkości obr. 10 000 obr/min 6Gb SAS • 17 dysków NL-SAS 4TB 3.5" o prędkości obr. 7.200 obr/min 6Gb SAS Możliwość rozbudowy do 700 dysków bez wymiany lub dodawania kontrolerów. Macierz jest wyposażona w jedną parę (2 sztuki) redundantnych	1 sztuka

Lp.	Opis sprzętu	Ilość
	kontrolerów pracujących w układzie nadmiarowym typu active-active. Macierz jest wyposażona w 64 GB pamięci cache, ma możliwość rozbudowy do 128 GB cache bez wymiany lub dodawania kontrolerów cache jest zbudowany w oparciu o szybkie kości pamięci RAM. Macierz jest wyposażona w 8 portów FC 8Gb/s, z możliwością rozbudowy do 32 portów FC 8Gbps. Wszystkie porty FC są wyposażone we wkładki 8Gbps typu shortwave multimode. Gwarancja – 4 lata i 1 miesiąc (49 miesięcy, tj. do 3.01.2020 r.)
8	Szafa rack – Fujitsu PRIMECENTER M1 Rack	2 sztuki

Tabela 4 Zestawienie zbiorcze serwerów zainstalowanych w POPD

	Sprzęt Licencje	Ilość serweró w	Procesor	Liczba proces orów	Rdzeni/ procesor	RAM GB	Łączna ilość rdzeni w serwerze	Łączna ilość rdzeni we wszystkich serwerach	Łączny RAM GB
1.	Blade Typ-1	2	Intel Xeon E5-2620v3 6C/12T 2.40GHz	2	6	192	12	24	384
2.	Blade Typ-2	8	Intel Xeon E5-2670 v3 12C/24T 2.30 GHz	2	12	256	24	192	2048
3	Blade Typ-3	8	Intel Xeon E5-2630 v4 10C/20T 2.20 GHz	2	10	512	20	160	4096
4.	Rack	3	Intel Xeon E5-2630v3 8C/16T 2.40 GHz	2	8	128	16	48	384
	Razem							424	6912

W POPD na zestawionym w Tabela 3 sprzęcie zainstalowane są systemy informatyczne Zamawiającego wykorzystujące część tych zasobów.

W Tabela 5 podane są zasoby wykorzystywane przez te systemy. Zasoby te nie będą udostępnione Wykonawcy.

W Tabela 6 przedstawiono wykorzystane zasoby macierzy dyskowej wraz z określeniem zasobów do wykorzystania w ramach niniejszego postępowania

Tabela 5 Zestawienie wykorzystywanych zasobów w POPD przez zainstalowane systemy Zamawiającego

ŚRODOWISKA PRODUKCYJNE I NIEPRODUKCYJNE
Ilość serwerów	Ilość vCPU	Ilość RAM [GB]	HDD [GB]
21	203	786	11583

Tabela 6 Zestawienie zbiorcze wykorzystania macierzy dyskowej – Hitachi Data Systems VSP G400

Lp.	Typ dysków	Ilość	Hot Spare	Skonfigurowane grupy RAID	Pojemność ogółem	Pozostaje do wykorzystania
1	Dyski SAS 1.2TB 10krpm	41	1	5 X RAID 5 (7D+1P)	37,5 TB	30 TB
2	Dyski NL-SAS 4TB 7.2krpm	17	1	2 X RAID 6(6D+2P)	44 TB	33 TB

W Tabela 7 przedstawiony jest wykaz posiadanego przez Zamawiającego oprogramowania systemowego wraz z ilościami udostępnianymi do wykorzystania w ramach niniejszego postępowania.

Tabela 7 Wykaz posiadanego przez Zamawiającego oprogramowania systemowego

Opis oprogramowania	Ilość	Wykorzystane [ilość]	Udostępniane Wykonawcy [ilość]
Oprogramowanie do wirtualizacji - VMware vSphere 6 Standard, VMware vCenter Server 6 Standard dla vSpere 6: Licencje umożliwiają uruchamianie oprogramowania do wirtualizacji na serwerach fizycznych o łącznej liczbie 22 procesorów oraz jednej konsoli do zarządzania całym środowiskiem. Wszystkie licencje są dostarczone wraz z 3- letnim wsparciem (tj. do 3.12.2018 r.)	vCenter 1 sztuka vSphere - na 38 CPU	Środowisko częściowo skonfigurowane. Wykorzystuje 4 serwery fizyczne, czyli 8 licencji vSphere.	30 licencji vSphere
Windows Server Datacenter 2 Processor License Software License and Software Assurance (do 31.10.2018)	20 sztuk	6	14
Windows Server Standard 2 Processor License Software License and Software Assurance (do 31.10.2018)	17 sztuk	7	10
SQL Server Enterprise per Core 2 Licenses Software License and Software Assurance	8 sztuk	3	5
Microsoft Exchange Server 2016 Enterprise	14 sztuk	-	14

2.5 Udostępniane stacje robocze i stacje skanowania w Prokuraturze Krajowej, prokuraturach regionalnych, okręgowych i rejonowych

2.5.1 Stacje robocze i stacje skanowania dostarczone w ramach Projektu SDA

2.5.1.1 Stacje robocze dostarczone w ramach Projektu SDA

Stacje robocze dostarczone w ramach Projektu SDA (stacje robocze SDA) przeznaczone są dla systemu SDA. Stacje robocze SDA zainstalowane są w Prokuraturze Krajowej, jedenastu prokuraturach regionalnych i czterdziestu pięciu prokuraturach okręgowych. Wszystkie stacje robocze zostaną włączone do Farmy Stacji Roboczych. Podstawowe parametry stacji roboczych SDA zestawione są w Tabela 8 oraz Tabela 9.

Tabela 8 Stacje robocze dwumonitorowe dostarczone w ramach Projektu SDA

Lp.	Opis parametru	Parametr
	Typ	Dell OptiPlex 7010SF
1.	Ilość stacji roboczych	1492 szt.
2.	Procesor	Intel Core i5-3470
3.	RAM	8 GB
4.	Dysk twardy	750 GB
5.	Ilość monitorów	2
6.	Oprogramowanie	1. MS Windows 7 Professional PL 64 2. MS Office 2013 Home&Business
7.	Czytnik kart mikroprocesorowych	XXXXXX XXXXxxxx X0X

Tabela 9 Stacje robocze jednomonitorowe dostarczone w ramach Projektu SDA

Lp.	Opis parametru	Parametr
	Typ	Dell OptiPlex 7010SF
1.	Ilość stacji roboczych	113 szt.
2.	Procesor	Intel Core i5-3470
3.	RAM	8 GB
4.	Dysk twardy	750 GB
5.	Ilość monitorów	1
6.	Oprogramowanie	1. MS Windows 7 Professional PL 64 2. MS Office 2013 Home&Business
7.	Czytnik kart mikroprocesorowych	ATHENA ASEDrive V3C

2.5.1.2 Stacje skanowania dostarczone w ramach Projektu SDA

Stacje skanowania dostarczone w ramach Projektu SDA (stacje skanowania SDA) przeznaczone są do wykonywania skanów akt dla systemu SDA. Stacje skanowania zainstalowane są w Prokuraturze Krajowej, jedenastu prokuraturach regionalnych i czterdziestu pięciu prokuraturach okręgowych. Wszystkie stacje skanowania zostaną włączone do Farmy Stacji Roboczych.

Podstawowe parametry stacji skanowania zestawione są w Tabela 10.

Tabela 10 Parametry stacji skanowania dostarczonych w ramach Projektu SDA

Lp.	Opis parametru	Parametr
1.	Ilość stacji skanowania	113 szt.
2.	Procesor	Intel Core i5-3470
3.	RAM	8 GB
4.	Dysk twardy	1 TB
5.	Skaner A4	KODAK i2600
6.	Skaner A3	KODAK i3200
7.	Oprogramowanie	1. MS Windows 7 Professional PL 64 2. MS Office 2013 Home&Business
8.	Czytnik kart mikroprocesorowych	ATHENA ASEDrive V3C

2.5.1.3 Laptopy

Laptopy dostarczone w ramach Projektu SDA przeznaczone są do wykorzystania systemu SDA w trybie offline oraz do systemu transkrypcji mowy. Laptopy użytkowane są w Prokuraturze Krajowej, jedenastu prokuraturach regionalnych i czterdziestu pięciu prokuraturach okręgowych przez prokuratorów uczestniczących w rozprawach sądowych. Wszystkie laptopy zostaną włączone do Podsystemu Zarządzania i Monitorowania ITS.

Podstawowe parametry laptopów zestawione są w Tabela 11.

Tabela 11 Parametry laptopów dostarczonych w ramach Projektu SDA

Lp.	Opis parametru	Parametr
1.	Ilość stacji skanowania	1258 szt.
2.	Procesor	Intel Core i7-4710MQ
3.	RAM	16 GB
4.	Dysk twardy	1 TB
5.	Oprogramowanie	1. MS Windows 7 Professional PL 64 2. MS Office 2013 Home&Business

2.5.2 Pozostałe stacje robocze zainstalowane w jednostkach prokuratury

Poza stacjami roboczymi i stacjami skanowania w jednostkach prokuratury zainstalowane są stacje dostarczane z wcześniejszych postępowań przetargowych. Tymi stacjami roboczymi są komputery PC podłączone siecią lokalną w danej jednostce. Sieci lokalne poprzez urządzania bezpieczeństwa połączone są z siecią WAN-PROK. Podstawowe parametry stacji roboczych zestawione są w Tabela 12.

Tabela 12 Parametry stacji roboczych

Lp.	Opis parametru	Parametr
1.	Sumaryczna ilość stacji roboczych	Około 10.000
2.	Systemy operacyjne	MS Windows XP/7/8/8.1/10
3.	Oprogramowanie dodatkowe	MS Office lub MS Word
4.	Oprogramowanie antywirusowe	Kaspersky, ESET

2.6 Interfejsy do wymiany danych z systemami finansowo-księgowymi

Podsystemu Elektronicznego Wykazu Służbowego (Podsystem EWS), przeznaczony będzie do prowadzenia centralnego wykazu prokuratorów oraz pracowników prokuratury zatrudnionych we wszystkich jednostkach prokuratury na terenie kraju.

Podsystem EWS będzie zainstalowany w Podstawowym Ośrodku Przetwarzania Danych (POPD) zlokalizowanym w Prokuraturze Krajowej jako system centralny. Ogólny schemat rozwiązania Podsystemu EWS przedstawiony jest na rysunku poniżej.

Podstawowy Ośrodek Przetwarzania Danych

Centralne Usługi Infrastrukturalne

Projektu iSDA

Centrum

Certyfikacji

System

Zarządzania Tożsamością

Podsystem EWS

Help Desk

Usługi

katlogowe

Węzeł

Dostępowy Łączy Dedykowanych

Węzeł

Dostępowy WAN-PROK

System RPA

Systemy F-K

jednostek prokuratury

Stacje robocze

pracowników komórek kadrowych

Rysunek 9 Ogólny schemat Podsystemu EWS

Podsystem EWS będzie udostępniony:

1. Systemom F-K Prokuratury Krajowej (1 jednostka), prokuratur regionalnych (11 jednostek), prokuratur okręgowych (45 jednostek) oraz IPN (1 jednostka) w zakresie automatycznego (on-line) zasilenia danymi Centralnej Bazy Danych EWS. Dla prokuratur rejonowych dane kadrowe prowadzone są przez prokuratury okręgowye.

2. Pracownikom komórek kadrowych Prokuratury Krajowej, prokuratur regionalnych, prokuratur okręgowych oraz IPN w zakresie wprowadzania danych uzupełniających do Wykazu Służbowego, przeszukiwania bazy danych wg zadanych kryteriów oraz generowania raportów. Pracownicy danej jednostki prokuratury będą mieli dostęp jedynie do danych własnej jednostki. Pracownicy jednostki nadrzędnej będą mieli dostęp do danych jednostek podległych.

3. Systemowi Portal Radców Prawnych i Adwokatów (RPA) prowadzonemu przez Ministerstwo Sprawiedliwości, którego zadaniem jest miedzy innymi udostępnianie danych o prokuratorach pracownikom sądów. Dane o prokuratorach system RPA będzie pobierał w trybie on-line z Podsystemu EWS.

4. Systemowi Zarządzania Tożsamością (SZT) budowanego w ramach Centralnych Usług Infrastrukturalnych Projektu iSDA, którego zadaniem jest zarządzanie tożsamościami użytkowników systemów. Dane do SZT będą przesyłane w trybie on-line z Podsystemu EWS.

2.7 Eksploatowane systemy PKI

Aktualnie w prokuraturze eksploatowana jest Infrastruktura klucza publicznego (PKI) wyłącznie dla potrzeb systemu SDA. Architektura PKI jest dwuwarstwowa, składa się z uruchomionego w trybie offline Głównego Centrum Certyfikacji (Root CA), oraz jednego Pośredniczącego Centrum Certyfikacji (Subordinate CA) poświadczonego przez Root CA. Pośredniczące Centrum Certyfikacji stanowi punkt zaufania dla wszystkich certyfikatów wystawionych w ramach infrastruktury PKI. We wszystkich objętych projektem jednostkach Prokuratury uruchomiane są Urzędy Rejestracji, czyli oprogramowanie do zarządzania cyklem życia certyfikatów obudowane procedurami organizacyjnymi, które komunikują się z Pośredniczącym Centrum Certyfikacji.

Zadaniem Głównego Centrum Certyfikacji jest generowanie i autopoświadczanie własnego certyfikatu, generowanie listy CRL oraz generowanie i poświadczenie certyfikatu Pośredniczącego Centrum Certyfikacji. W przypadku kompromitacji certyfikatu Pośredniczącego Centrum Certyfikacji zadaniem Głównego Centrum Certyfikacji jest także jego unieważnienie. Zadaniem Pośredniczącego Centrum Certyfikacji jest obsługa pełnego cyklu życia certyfikatów wystawianych w ramach PKI, tj. generowanie, poświadczanie, odnawianie, unieważnianie certyfikatów, oraz generowanie list CRL. Generowanie i publikowanie list CRL Subordinate CA realizowane jest w sposób automatyczny poprzez cykliczne uruchamianie zdefiniowanych skryptów przez system. Urzędy Rejestracji znajdujące się we wszystkich jednostkach prokuratury objętych systemem SDA, stanowią punkt styku pomiędzy Subskrybentami a Subordinate CA. Urząd rejestracji jest dedykowaną aplikacją komunikującą się z kartami procesorowymi za pośrednictwem interfejsu PKCS#11, oraz z Subordinate CA i Repozytorium za pośrednictwem protokołu HTTP.

Do zadań Urzędów Rejestracji należy:

• realizacja procedury certyfikacji Subskrybentów,

• weryfikacja tożsamości Subskrybentów,

• przekazywanie certyfikatów Subskrybentom,

• zarządzanie stanem ważności certyfikatów Subskrybentów.

Wszystkie wydane certyfikaty dla potrzeb systemu SDA znajdują się w Prokuraturze Krajowej, w repozytorium Certyfikatów. Wszystkie certyfikaty podlegają migracji. Szacunkowa ilość certyfikatów do migracji wynosi – 1 000 sztuk.

2.8 Eksploatowane Usługi Katalogowe

Aktualne środowisko Zamawiającego zawiera rozproszone, niepołączone domeny Microsoft Active Directory na różnym poziomie funkcjonalności lasu (od poziomu Windows Server 2003 do poziomu Windows Server 2012) realizowane w Prokuraturze Krajowej oraz na obszarze prokuratur regionalnych (prokuratura regionalna i podległe jej prokuratury okręgowe) i/lub prokuratur okręgowych (prokuratura okręgowa i podległe jej prokuratury rejonowe).

2.9 Eksploatowane Usługi Poczty Elektronicznej

W chwili obecnej nie istnieje jeden spójny system pocztowy. Poszczególne prokuratury użytkują zarówno rozwiązania typu OpenSource jak również oprogramowanie Microsoft Exchange od wersji 2003 do wersji 2013. Obieg poczty elektronicznej występuje analogicznie jak w przypadku usług katalogowych w Prokuraturze Krajowej oraz na obszarze prokuratur regionalnych (prokuratura regionalna i podległe jej prokuratury okręgowe) i/lub prokuratur okręgowych (prokuratura okręgowa i podległe jej prokuratury rejonowe).

W Prokuraturze Krajowej utworzone są skrzynki pocztowe kierowników jednostek i sekretariatów poszczególnych powszechnych jednostek organizacyjnych prokuratury (od szczebla rejonowego do regionalnego).

2.10 Zegar

Zamawiający udostępni serwer czasu XXXXXXX XXX-0000.

3 Szczegółowy opis przedmiotu zamówienia

3.1 Wymagania na komponenty zamówienia POS-2.1

W ramach przedmiotowego postępowania Wykonawca musi zaprojektować i zbudować komponenty Systemu według architektury przedstawionej na Rysunek 9.

POPD

Usługi Infrastrukturalne

Serwer

MS AD

Serwer

Serwer Centrum

MS Exch Tozsamość Certyfikacji

Zarządzanie

Monitorowanie

System

Wsparcia HelpDesk

WAN-PROK

OPDK/OPDR/OPDO

Farma Stacji Roboczych

Lokalizacja

Lokalizacja

Lokalizacja

Rysunek 10 Schemat połączeń Farmy Stacji Roboczych z Centralnymi Usługami Infrastrukturalnymi

3.1.1 Wygania w zakresie bezpieczeństwa dla wszystkich komponentów

Wymagania w zakresie bezpieczeństwa dla wszystkich komponentów objętych niniejszym postępowanie przedstawia Tabela 13.

Tabela 13 Wymagania w zakresie bezpieczeństwa

Identyfikator wymagania	Opis wymagania
P2-BZP-OG-01	Podsystemy Centralnych Usług Infrastrukturalnych muszą zapewnić pełną ochronę przed nieuprawnionym dostępem osób i systemów do danych. W szczególności musi spełniać wymogi Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. 2004, nr 100, poz. 1024) oraz Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012r. w sprawie krajowych ram interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2016 poz. 113).
P2-BZP-OG-02	Podsystemy Centralnych Usług Infrastrukturalnych muszą spełniać wymogi ustawy o ochronie danych osobowych(Dz. U. z 2016, poz.922).
P2-BZP-OG-03	Wszystkie operacje wykonywane przez administratorów i użytkowników Podsystemów Centralnych Usług Infrastrukturalnych muszą być archiwizowane i musi istnieć funkcjonalność pozwalająca na ich analizę.
P2-BZP-OG-04	Podsystemy Centralnych Usług Infrastrukturalnych muszą zapewnić nadawanie uprawnień użytkownikom na poziomie dostępu do poszczególnych danych i funkcjonalności systemu według przyznanych uprawnień.
P2-BZP-OG-05	Serwery przeznaczone do bezpośredniej komunikacji z systemami zewnętrznymi oraz użytkownikami zewnętrznymi muszą znajdować się w strefie DMZ.
P2-BZP-OG-06	Dostęp użytkowników do danych osobowych będzie wymagał uwierzytelnienia.
P2-BZP-OG-07	Podsystemy Centralnych Usług Infrastrukturalnych muszą blokować sesje użytkowników po ustalonym w parametrach konfiguracyjnych czasie nieaktywności.
P2-BZP-OG-08	Zarówno serwery jak i pozostałe komputery muszą być zabezpieczone aktualizowanym na bieżąco oprogramowaniem antywirusowym.
P2-BZP-OG-09	Podsystemy Centralnych Usług Infrastrukturalnych muszą umożliwiać tworzenie i odtworzenie danych z kopii zapasowych w trybie online na zewnętrzne nośniki danych.
P2-BZP-OG-10	W POPD a w przyszłości również dla ZOPD dla Systemu będą zdefiniowane dwie strefy bezpieczeństwa: 1. Strefa Wewnętrzna – w strefie tej znajdować się będą wszystkie podsystemy związane z przetwarzaniem, przechowywaniem i udostępnianiem danych systemów informatycznych prokuratury. Strefa Wewnętrzna nie będzie miała styczności z Internetem. Połączenia z

Identyfikator wymagania

Opis wymagania

instytucjami zewnętrznymi (np. policja, sądy) będą realizowane przez bezpieczne interfejsy. 2. Strefa Zewnętrzna – w strefie tej będą znajdować się podsystemy związane z udostępnianiem danych przez Internet. Infrastruktura Techniczno-Systemowa Strefy Wewnętrznej i Zewnętrznej musi być rozdzielona na poziomie fizycznym. Interfejs wymiany danych pomiędzy strefami musi zapewnić pełne bezpieczeństwo przekazywania danych tylko w jednym kierunku – ze Strefy Wewnętrznej do Strefy Zewnętrznej. Rozwiązanie musi zapewnić monitorowanie wymiany danych pomiędzy strefami

3.1.2 Centralny System Zarządzania Tożsamością (SZT)

Identyfikator wymagania	Opis wymagania
P2-SZT-OG-01	Centralny System Zarządzania Tożsamością zlokalizowany będzie POPD a w przyszłości również w ZOPD.
P2-SZT-OG-02	Wszystkie elementy środowiska produkcyjnego SZT mają pracować w architekturze redundantnej w POPD. Docelowo musi istnieć możliwość uruchomienia środowiska SZT również w ZOPD.
P2-SZT-OG-03	SZT zbudowany będzie w oparciu o Oprogramowanie Gotowe, którego wymagania zostały określone w załączniku nr 1 do OPZ - specyfikacja Systemu Zarządzania Tożsamością.
P2-SZT-OG-04	Infrastrukturę serwerową dla instalacji SZT udostępni Zamawiający w oparciu o zasoby opisane w rozdziale 2.4.
P2-SZT-OG-05	SZT umożliwi zarządzanie tożsamościami 15.000 pracowników zatrudnionych w jednostkach prokuratury.
P2-SZT-OG-06	SZT musi zapewnić ładowanie inicjalne danymi z Podsystemu EWS zainstalowanego w Prokuraturze Krajowej.
P2-SZT-OG-07	W procesie zarządzania tożsamością źródłem informacji o tożsamościach użytkowników będą dane kadrowe. Dane te będą wprowadzane bezpośrednio w trybie on-lin z systemów finansowo-księgowych (moduł kadrowy) lub jeżeli zakres danych wymaganych przez SZT nie będzie dostępny w systemie finansowo-księgowym ze stacji roboczej zainstalowanej w komórce kadrowej i podłączonej do SZT poprzez portal.
P2-SZT-OG-08	Dane o tożsamościach prokuratorów/pracowników przechowywane w Centralnym Repozytorium Informacji o tożsamościach będą zawierały następujące grupy danych: 1. Dane osobowe, 2. Przebieg służby/pracy, 3. Zakończenie służby/pracy, 4. Kary dyscyplinarne, 5. Kwalifikacje, 6. Odznaczenia, nagrody. W Centralnym Repozytorium przechowywane i udostępniane będą dane o zmianach w poszczególnych grupach danych (historia zmian).
P2-SZT-OG-09	Użytkownikami SZT będą: 1. Pracownicy komórek kadrowych Prokuratury Krajowej, prokuratur regionalnych i okręgowych, 2. Przełożeni pracowników wszystkich szczebli, 3. Pracownicy prokuratury, 4. Prokuratorzy/Pracownicy IPN 5. Administratorzy Bezpieczeństwa Informacji, 6. Pracownicy komórek organizacyjnych odpowiedzialnych za nadawanie uprawnień dostępu do obiektów i pomieszczeń w jednostkach prokuratury. 7. Administratorzy ITS.
P2-SZT-OG-10	Wszyscy użytkownicy SZT połączeni będą za pomocą sieci WAN-PROK.
P2-SZT-OG-11	SZT będzie zintegrowany z Podsystemami realizowanymi w ramach przedmiotowego postępowania:

Identyfikator wymagania	Opis wymagania
	1. Centralna Usługa Katalogowa 2. Centralna Poczta Elektroniczna 3. Centrum Certyfikacji 4. Podsystem HelpDesk
P2-SZT-OG-12	SZT będzie zintegrowany z Podsystemami realizowanymi w ramach umowy POS-1.
P2-SZT-OG-13	SZT będzie zintegrowany z Podsystemem Elektronicznego Wykazu Służbowego (Podsystem EWS). Integracja oznacza przygotowanie konektora umożliwiającego komunikację poprzez interfejs programistyczny – API, umożliwiający automatyzację zadań związanych z: a) Importem danych o użytkownikach, rolach oraz przypisaniem ról do użytkowników do repozytorium SZT b) Odczytywaniem/nadawaniem/modyfikowaniem/usuwaniem ról
P2-SZT-OG-14	SZT będzie się składał z co najmniej dwóch rozdzielonych od siebie środowisk: a) Środowiska produkcyjnego, b) Środowiska nieprodukcyjnego.
P2-SZT-OG-15	Wymagania dla środowiska nieprodukcyjnego: a) musi odzwierciedlać środowisko produkcyjne, b) nie musi pracować w architekturze redundantnej, c) musi umożliwiać równoległą pracę co najmniej 20 użytkownikom, d) Wykonawca zaproponuje w Projekcie Technicznym sposób realizacji środowiska testowego na poziomie sprzętowym, systemowym i logicznym w oparciu o zasoby serwerowe opisane w rozdziale 2.4.
P2-SZT-OG-16	SZT będzie zarządzać uprawnieniami poprzez przypisanie do tożsamości: a) Ról technicznych b) Ról biznesowych c) Ról dostępowych do portalu samoobsługi SZT
P2-SZT-OG-17	SZT będzie realizować mieszany model zarządzania uprawnieniami, co oznacza dwoiste podejście do zarządzania, w zależności od potrzeb biznesowych: a) Zarządzanie w oparciu o strukturę organizacyjną – 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. b) Zarządzanie w oparciu o wnioski (Workflow) – nadawanie/modyfikowanie ról będzie realizowane po zaakceptowaniu właściwego wniosku elektronicznego w ramach SZT.
P2-SZT-OG-18	Nadawanie, modyfikowanie oraz odbieranie ról (Provisioning), dla systemów zintegrowanych z SZT będzie odbywać się w sposób automatyczny – poprzez konektory do systemu SZT.
P2-SZT-OG-19	SZT będzie spełniał następujące wymagania wydajnościowe dla użytkownika pracującego ze stacji roboczej:

Identyfikator wymagania	Opis wymagania
	a) Czas odpowiedzi systemu na dowolną akcję użytkownika podczas bieżących operacji transakcyjnych systemu poniżej 3 sekund b) Oczekiwanie na wyświetlanie formularza edycji atrybutów tożsamości – przy 100 użytkownikach pracujących równolegle 3 sek. c) Oczekiwanie na potwierdzenie akceptacji wybranego wniosku workflow - przy 100 użytkownikach pracujących równolegle 3 sek. d) Oczekiwanie na odpowiedź systemu na wysłanie formularza wniosku o przyznanie roli - przy 100 użytkownikach pracujących równolegle 3 sek. e) Oczekiwanie na raport systemowy - przy 100 użytkownikach pracujących równolegle 10 min.
P2-SZT-OG-20	Wykonawca zainstaluje i skonfiguruje systemy operacyjne zgodnie z Projektem Technicznym zatwierdzonym przez Zamawiającego dla środowiska produkcyjnego oraz testowego przy spełnieniu poniższych minimalnych w tym zakresie wymagań: a) system operacyjny musi być kompatybilny z dostarczonym systemem SZT, b) system operacyjny musi być aktualny na dzień jego instalacji zgodnie z zaleceniami producenta systemu operacyjnego, c) system operacyjny musi pracować w architekturze 64bit (x86-64), d) wersja językowa systemu operacyjnego: angielska lub inna za zgodą Zamawiającego.
P2-SZT-OG-21	Wymagania licencyjne: a) Wykonawca jest zobowiązany dostarczyć wszystkie wymagane licencje dla zapewnienia wysokiej dostępności zaproponowanego środowiska produkcyjnego (HA). b) Wykonawca zapewni licencje dla środowiska produkcyjnego i testowego. c) Licencje systemu operacyjnego MS Windows Server 2012 lub nowsze udostępni Zamawiający. Wykonawca dostarczy wszelkie inne licencje oprogramowania niezbędne do uruchomienia Podsystemu w tym licencje baz danych.
P2-SZT-OG-22	Wykonawca zdefiniuje za pomocą modułu raportującego (wymaganie P2- SZT-SP-98) 10 wzorców raportów których szablony poda Zamawiający po podpisaniu Umowy.
P2-SZT-OG-23	SZT zostanie włączony do systemu monitoringu eksploatowanego przez Zamawiającego System Center Operations Manager. Wykonawca dostarczy dedykowany management pack do monitorowania wdrażanego rozwiązania wraz z instrukcją instalacji oraz dokona odpowiedniej konfiguracji.

3.1.3 Centralne Usługi Katalogowe (CUK)

Identyfikator wymagania	Opis wymagania
P2-KAT-OG-01	Wykonawca przeprowadzi analizę środowiska Zamawiającego mającą za zadanie zapoznanie się ze specyfiką istniejącej infrastruktury sprzętowej i programowej w celu umożliwienia Wykonawcy wykonania przedmiotu zamówienia.
P2-KAT-OG-02	Wykonawca zweryfikuje w porozumieniu z Zamawiającym istniejące założenia techniczne usługi katalogowej określone w załączniku nr 2 do OPZ - Usługi Katalogowe i wprowadzi niezbędne zmiany w celu maksymalnego wykorzystania dostępnych funkcjonalności.
P2-KAT-OG-03	Wykonawca dokona wdrożenia CUK.
P2-KAT-OG-04	Centralne Usługi Katalogowe zlokalizowane będą w POPD oraz w OPDR a w przyszłości również w OPDO oraz ZOPD.
P2-KAT-OG-05	Kontrolery domen zostaną zainstalowane w POPD, OPDK oraz 11 lokalizacjach OPDR. Kontrolery domen z CUK połączone będą poprzez sieć WAN-PROK.
P2-KAT-OG-06	CUK będą budowane na bazie Microsoft Active Directory. Niezbędne licencje MS Windows Server 2012 lub nowsze oraz licencje CAL udostępni Zamawiający.
P2-KAT-OG-07	Infrastrukturę serwerową dla budowy CUK udostępni Zamawiający w oparciu o zasoby opisane w rozdziale 2.4.
P2-KAT-OG-08	Wykonawca skonfiguruje przy asyście Zamawiającego urządzenia sieciowe (urządzenia bezpieczeństwa, switche) w jednostkach prokuratury objętych wdrożeniem w celu zapewnienia dostępu do usługi oraz właściwego poziomu bezpieczeństwa środowiska pracy systemu.
P2-KAT-OG-9	CUK zostaną zintegrowane z pozostałymi Podsystemami tworzącymi Centralne Usługi Infrastrukturalne.
P2-KAT-OG-10	CUK będzie dostępny dla wszystkich użytkowników dołączonych do sieci WAN-PROK.
P2-KAT-OG-11	CUK będzie się składał z co najmniej dwóch rozdzielonych od siebie środowisk: a) Środowiska produkcyjnego, b) Środowiska nieprodukcyjnego.
P2-KAT-OG-12	Wymagania dla środowiska nieprodukcyjnego: a) musi odzwierciedlać środowisko produkcyjne, b) musi umożliwiać równoległą pracę co najmniej 100 użytkownikom, Wykonawca zaproponuje w Projekcie Technicznym sposób realizacji środowiska nieprodukcyjnego na poziomie sprzętowym, systemowym i logicznym.
P2-KAT-OG-13	System centralnej usługi katalogowej zostanie włączony do systemu monitoringu eksploatowanego przez Zamawiającego System Center Operations Manager. Wykonawca dostarczy dedykowany management pack do monitorowania wdrażanego rozwiązania wraz z instrukcją instalacji oraz dokona odpowiedniej konfiguracji.
P2-KAT-OG-14	Wykonawca zainstaluje i skonfiguruje systemy operacyjne zgodnie z Projektem Technicznym zatwierdzonym przez Zamawiającego dla

Identyfikator wymagania	Opis wymagania
	środowiska produkcyjnego oraz nieprodukcyjnego z systemem operacyjnym Windows Server 2012 lub wyższy (licencje dostarczane przez Zamawiającego). Zamawiający dostarczy system operacyjny aktualny na dzień jego instalacji z zainstalowanymi poprawkami, service packa-mi itp., pracujący w architekturze 64bit (x86-64), w wersji językowej angielskiej lub polskiej zgodnie z Projektem Technicznym.

3.1.4 Centralna Poczta Elektroniczna (CPE)

Identyfikator wymagania	Opis wymagania
P2-POC-OG-01	Wykonawca przeprowadzi analizę środowiska Zamawiającego mającą za zadanie zapoznanie się ze specyfiką infrastruktury sprzętowej i systemowej Zamawiającego oraz systemów pocztowych funkcjonujących we wszystkich jednostkach prokuratury.
P2-POC-OG-02	Centralna Poczta Elektroniczna zlokalizowana będzie w POPD a w przyszłości również w ZOPD.
P2-POC-OG-03	Wykonawca utworzy konta MS Exchange dla wszystkich pracowników prokuratury (około 15.000 użytkowników) z wykorzystaniem SZT.
P2-POC-OG-04	Wykonawca opracuje procedury wspomagające procesy migracji skrzynek pocztowych z funkcjonujących systemów pocztowych. Według opracowanych przez Wykonawcę procedur administratorzy ITS przeprowadzą proces migracji.
P2-POC-OG-05	Planowana ilość serwerów pocztowych wynosi 6 sztuk. Wszystkie krytyczne elementy systemu pocztowego muszą być zdublowane. Zamawiający wymaga przygotowania środowiska umożliwiającego uruchomienie w ZOPD.
P2-POC-OG-06	Rozwiązanie musi umożliwiać redundancję komponentów systemu, zapewniającą wysoką dostępność.
P2-POC-OG-07	Rozwiązanie musi umożliwiać automatyczne przełączanie zasobów w razie awarii jednego z komponentów systemu.
P2-POC-OG-08	Rozwiązanie musi umożliwiać skanowanie antywirusowe i antyspamowe poczty.
P2-POC-OG-09	Wymagania na oprogramowanie antyspamowe opisane są w załączniku nr 8 do OPZ - specyfikacja oprogramowania antywirusowego i antyspamowego.
P2-POC-OG-10	System poczty elektronicznej prokuratury będzie chroniony na 2 poziomach: a) Skaner antywirusowy na serwerach Exchange – zarówno dla wiadomości odbieranych jak i wysyłanych. b) Skaner antywirusowy na stacjach klienckich – zapewniający możliwość skanowania poczty. c) Funkcje antyspam będą realizowane w strefie DMZ środowiska serwerowego w połączeniu z funkcjami antywirusowymi. Wykonawca zainstaluje i skonfiguruje oprogramowanie antywirusowe/antyspamowe na serwerach organizacji Microsoft Exchange.
P2-POC-OG-11	Rozwiązanie musi umożliwiać odtwarzanie kopii zapasowych (Restore LUN) pojedynczej bazy danych oraz czynności naprawczych (typu defragmentacja bazy, naprawa w razie uszkodzenia danych).
P2-POC-OG-12	System musi być w stanie obsłużyć wiadomości mailowe z załącznikami co najmniej 50 MB
P2-POC-OG-13	Wykonawca założy skrzynki pocztowe dla wszystkich pracowników jednostek prokuratury. Skonfiguruje następujące profile pocztowe: 1. Typ-1 – 66,5% ilości użytkowników a. Rozmiar skrzynki: 2 GB

Identyfikator wymagania	Opis wymagania
	b. Ilość przesyłanych wiadomości dziennie - 50 c. Średnia wielkość wiadomości: 150KB 2. Typ-2 – 23% ilości użytkowników a. Rozmiar skrzynki: 4 GB b. Ilość przesyłanych wiadomości dziennie - 50 c. Średnia wielkość wiadomości: 300KB 3. Typ-3 - 7% ilości użytkowników a. Rozmiar skrzynki: 6 GB b. Ilość przesyłanych wiadomości dziennie - 100 c. Średnia wielkość wiadomości: 300KB 4. Typ-4 – 3,5% ilości użytkowników a. Rozmiar skrzynki: 8GB MB b. Ilość przesyłanych wiadomości dziennie - 100 Średnia wielkość wiadomości: 300KB
P2-POC-OG-14	Na wszystkich serwerach Exchange wymagana jest instalacja filtrów wyszukiwania (iFilter), które umożliwiają wyszukiwanie zawartości tekstowej w załącznikach o określonych typach. Możliwe będzie x.xx. wykorzystanie reguł transportowych wykonujących inspekcje załączników pod kątem zawartości. Instalacja powinna być wykonana dla: 1. Plików Microsoft Office 2. Plików Acrobat Portable Document Format (PDF)
P2-POC-OG-15	Serwery Exchange zostaną skonfigurowane do wykorzystania certyfikatów i mechanizmu „SMTP over TLS”. Umożliwi to zachowanie poufności transmisji danych przy wymianie poczty z ewentualnymi zewnętrznymi systemami. Wymiana komunikacji SMTP wewnątrz organizacji zostanie skonfigurowana tak, aby umożliwić dostęp jedynie autoryzowanym użytkownikom oraz wyznaczonym serwerom SMTP i aplikacjom wykorzystywanym w prokuraturach.
P2-POC-OG-16	Dostęp do usług Exchange jak Outlook Web Access, Outlook Anywhere, Autodiscover, OAB czy Active Sync będzie realizowany bez rozwiązania VPN. Wykonawca skonfiguruje publikacje odpowiednich usług w sieci WAN-PROK.
P2-POC-OG-17	CPE zostanie zaprojektowane i wykonane bez pojedynczego punktu awarii usługi poczty elektronicznej. Zaprojektowanie redundantnej usługi ma również umożliwić wykonywanie planowanych prac utrzymaniowych.
P2-POC-OG-18	Każda baza danych skrzynek pocztowych będzie posiadała co najmniej 1 dodatkową kopię. Uszkodzenie na poziomie bazy danych, np. awaria dysku, nie wpłynie na wszystkich użytkowników, których skrzynki pocztowe znajdują się w danej bazie danych – przełączeniu ulegnie pojedyncza baza danych.
P2-POC-OG-19	CPE zostanie skonfigurowane w sposób zabezpieczający przed utratą zawartości kolejek wiadomości..
P2-POC-OG-20	Wykonawca skonfiguruje przechowywanie usuniętych wiadomości przez 60 dni z wykorzystaniem natywnych mechanizmów systemu pocztowego
P2-POC-OG-21	Wykonawca zainstaluje i skonfiguruje systemy operacyjne zgodnie z Projektem Technicznym zatwierdzonym przez Xxxxxxxxxxxxx dla

Identyfikator wymagania	Opis wymagania
	środowiska produkcyjnego przy spełnieniu poniższych minimalnych w tym zakresie wymagań: a) system operacyjny Windows Server 2012 lub wyższy (licencje dostarczane przez Zamawiającego), b) system operacyjny musi być aktualny na dzień jego instalacji z zainstalowanymi poprawkami, service packa-mi itp., c) system operacyjny musi pracować w architekturze 64bit (x86- 64), d) wersja językowa systemu operacyjnego: angielska lub inna za zgodą Zamawiającego.
P2-POC-OG-22	Wykonawca dokona konfiguracji i wdrożenia środowiska CPE.
P2-POC-OG-23	Zamawiający udostępni posiadane licencje MS Exchange Server 2016 oraz licencje CAL. Zamawiający dostarczy system operacyjny MS Windows Server aktualny na dzień jego instalacji z zainstalowanymi poprawkami, service packa-mi itp., pracujący w architekturze 64bit (x86-64), w wersji językowej angielskiej lub polskiej zgodnie z Projektem Technicznym.
P2-POC-OG-24	Zamawiający posiada system monitorowania System Center Operations Manager. CPE zostanie włączony do systemu monitoringu na etapie budowy. Wykonawca dostarczy dedykowany management pack do monitorowania poczty wraz z instrukcją instalacji oraz dokona odpowiedniej konfiguracji.

3.1.5 Centrum Certyfikacji (CC)

Identyfikator wymagania	Opis wymagania
P2-CC-OG-01	Wykonawca dostarczy rozwiązanie Podsystemu Centrum Certyfikacji o funkcjonalnościach opisanych w załączniku nr 5 do OPZ
P2-CC-OG-02	Przeznaczenie Podsystemu
P2-CC-OG-02.1	Usługami świadczonymi przez Centrum Certyfikacji będą: 1. Wydawanie i unieważnianie certyfikatów niekwalifikowanych dla potrzeb prokuratury (usługa CA). 2. Publikacja list CRL oraz publikacja wydanych certyfikatów 3. Zarządzanie kartami mikroprocesorowymi (usługa CMS). 4. Synchronizacja czasu (usługa NTP). 5. Znakowanie czasem (usługa TSA). 6. Weryfikacja statusu certyfikatów online (usługa OCSP) 7. Składanie i weryfikacja podpisów (usługa VA). 8. Personalizacja kart mikroprocesorowych
P2-CC-OG-02.2	Wydawane przez CC certyfikaty będą przeznaczone dla: 1. Autoryzacji i uwierzytelniania dostępu do stacji roboczych oraz dostępu do usług Systemu realizowanego w ramach postępowania POS-1. 2. Szyfrowania danych. 3. Podpisywanie dokumentów i wiadomości pocztowych. 4. Autoryzacji serwerów i urządzeń sieciowych. 5. Zestawienia bezpiecznych połączeń (np. SSL, IPSec).
P2-CC-OG-03	Użytkownikami Podsystemu będą wszyscy użytkownicy systemów informatycznych prokuratury oraz personel techniczny Zamawiającego.
P2-CC-OG-04	Całość CC zlokalizowana będzie w POPD a w przyszłości również w ZOPD
P2-CC-OG-05	Infrastruktura
P2-CC-OG-05.01	Serwery wirtualne dla potrzeb CC udostępni Zamawiający w oparciu o udostępniane zasoby opisane w rozdziale 2.4.
P2-CC-OG-05.02	Wymagania licencyjne: a) Wykonawca jest zobowiązany dostarczyć wszystkie wymagane licencje dla zapewnienia wysokiej dostępności zaproponowanego środowiska produkcyjnego (HA). b) Wykonawca zapewni licencje dla środowiska produkcyjnego i testowego. Licencje systemu operacyjnego MS Windows Server 2012 lub nowsze udostępni Zamawiający. Wykonawca dostarczy wszelkie inne licencje oprogramowania niezbędne do uruchomienia Podsystemu w tym licencje baz danych.
P2-CC-OG-05.03	Konfigurację sieci LAN oraz WAN zgodnie z zaakceptowanym Projektem Technicznym przygotuje Zamawiający.
P2-CC-OG-05.04	Wykonawca dostarczy w ramach niniejszego postepowania: 1. Moduły HSM opisane w załączniku nr 4 do OPZ. 2. Drukarki do personalizacji kart opisane w załączniku nr 3 do OPZ

Identyfikator wymagania	Opis wymagania
	3. Drukarka do wydruku kopert z kodem PIN opisane w załączniku nr 3 do OPZ 4. Drukarka do wydruku etykiet samoprzylepnych opisane w załączniku nr 3 do OPZ 5. Karty mikroprocesorowe opisane w załączniku nr 3 do OPZ
P2-CC-OG-06	Wykonawca skonfiguruje całość rozwiązania oraz udostępni usługi świadczone przez CC użytkownikom Zamawiającego.
P2-CC-OG-07	Wykonawca skonfiguruje środowisko produkcyjne oraz nieprodukcyjne Podsystemu CC. Środowisko produkcyjne zostanie skonfigurowane w architekturze HA.
P2-CC-OG-08	Wymagania dla środowiska nieprodukcyjnego: 1. musi odzwierciedlać środowisko produkcyjne, 2. musi umożliwiać równoległą pracę co najmniej 20 użytkownikom, Wykonawca zaproponuje w Projekcie Technicznym sposób realizacji środowiska nieprodukcyjnego na poziomie sprzętowym, systemowym i logicznym.
P2-CC-OG-09	Zamawiający posiada system monitorowania System Center Operations Manager. CC zostanie włączone do systemu monitoringu na etapie budowy. Wykonawca dostarczy dedykowany management pack do monitorowania CC wraz z instrukcją instalacji oraz dokona odpowiedniej konfiguracji.

3.1.6 Centralny Podsystem monitorowania i zarządzania ITS (PMiZ ITS)

Identyfikator wymagania	Opis wymagania
P2-ZMO-OG-01	Centralny Podsystem monitorowania i zarządzania ITS zlokalizowany będzie w POPD a w przyszłości również w ZOPD.
P2-ZMO-OG-02	Serwery wirtualne dla instalacji PMiZ zostaną udostępnione przez Zamawiającego w oparciu o udostępnianą infrastrukturę opisaną w rozdziale 2.4.
P2-ZMO-OG-03	Zamawiający posiada system monitorowania System Center Operations Manager. PMiZ zostanie włączone do systemu monitoringu na etapie budowy. Wykonawca dostarczy dedykowany management pack do monitorowania PMiZ wraz z instrukcją instalacji oraz dokona odpowiedniej konfiguracji.
P2-ZMO-OG-04	PMiZ zbudowany zostanie w oparciu o Oprogramowanie Gotowe, którego wymagania opisane są w załączniku nr 6 do OPZ - specyfikacja Zarządzanie i Monitorowanie ITS.
P2-ZMO-OG-05	Licencje systemu operacyjnego MS Windows Server 2012 lub nowsze udostępni Zamawiający. Wykonawca dostarczy wszelkie inne licencje oprogramowania niezbędne do uruchomienia Podsystemu w tym licencje baz danych.
P2-ZMO-OG-06	Monitorowaniem i zarządzeniem objęte będą wszystkie stacje dostarczane w ramach postepowania POS-2.2, stacje dostarczone w ramach SDA oraz wszystkie stacje zainstalowane w prokuraturze.
P2-ZMO-OG-07	Wykonawca dokona wdrożenia infrastruktury oraz oprogramowania Podsystemu Zarządzania i Monitorowania ITS oraz udostępnienie konsoli administracyjnej dla wskazanych administratorów Zamawiającego
P2-ZMO-OG-08	Wykonawca dokona instalacji oprogramowania agentów Podsystemu Zarządzania i Monitorowania ITS na wszystkich stacjach roboczych włączonych w infrastrukturę Centralnych Usług Infrastrukturalnych.
P2-ZMO-OG-09	W ramach PMiZ Wykonawca zbuduje Centralny System Zarządzania Oprogramowaniem Antywirusowym w oparciu o Oprogramowanie Gotowe, którego wymagania opisane są w załączniku nr 8 do OPZ - specyfikacja oprogramowania antywirusowego i antyspamowego.
P2-ZMO-OG-10	Sprzęt serwerowy dla instalacji Systemu Scentralizowanego Zarzadzania Oprogramowaniem Antywirusowym zostanie udostępniony przez Zamawiającego w oparciu o udostępnianą infrastrukturę opisaną w rozdziale 2.4.
P2-ZMO-OG-11	Licencje systemu operacyjnego MS Windows Server 2012 lub nowsze udostępni Zamawiający. Wykonawca dostarczy wszelkie inne licencje oprogramowania niezbędne do uruchomienia Podsystemu w tym licencje baz danych.
P2-ZMO-OG-12	Systemem Scentralizowanego Zarzadzania Oprogramowaniem Antywirusowym objęte będą wszystkie stacje dostarczane w ramach postępowania POS-2.1.
P2-ZMO-OG-13	Wykonawca dokona wdrożenia infrastruktury oraz oprogramowania Systemu Scentralizowanego Zarzadzania Oprogramowaniem Antywirusowym.

3.1.7 Centralny Podsystem Wsparcia Eksploatacji i Help Desk (PWEiH)

Identyfikator wymagania	Opis wymagania
P2-WSP-OG-01	Centralny Podsystem Wsparcia Eksploatacji i HelpDesk zlokalizowany będzie w POPD a w przyszłości również w ZOPD
P2-WSP-OG-02	PWEiH zbudowany będzie w oparciu o Oprogramowanie Gotowe opisane w załączniku nr 7 do OPZ - specyfikacja Podsystem HelpDesk.
P2-WSP-OG-03	Serwery wirtualne dla instalacji PWEiH zostaną udostępnione przez Zamawiającego w oparciu o udostępnianą infrastrukturę opisaną w rozdziale 2.4.
P2-WSP-OG-04	Zamawiający posiada system monitorowania System Center Operations Manager. PWEiH zostanie włączone do systemu monitoringu na etapie budowy. Wykonawca dostarczy dedykowany management pack do monitorowania PWEiH wraz z instrukcją instalacji oraz dokona odpowiedniej konfiguracji.
P2-WSP-OG-05	Licencje systemu operacyjnego MS Windows Server 2012 lub nowsze udostępni Zamawiający. Wykonawca dostarczy wszelkie inne licencje oprogramowania niezbędne do uruchomienia Podsystemu w tym licencje baz danych.
P2-WSP-OG-06	PWEiH składał się będzie z następujących komponentów: 1. Komponent HelpDesk dla obsługi użytkowników wewnętrznych (dostępny w Strefie Wewnętrznej w ramach sieci WAN-PROK). 2. Komponent HelpDesk dla obsługi użytkowników zewnętrznych (dostępny w Strefie Zewnętrznej w ramach sieci Internet). 3. Komponent Wsparcia Eksploatacji obsługującego procedury utrzymania oraz zawierający bazę CMDB i Bazę Wiedzy.
P2-WSP-OG-07	Zamawiający wymaga, aby Wykonawca na podstawie dostarczonych przez Zamawiającego informacji sporządził analizę procesów zawierającą ocenę realizowanych w organizacji Zamawiającego procesów związanych z eksploatację systemów informatycznych i sprzętu komputerowego. Wynik analizy będzie częścią opracowywanego przez Wykonawcę Projektu Technicznego PK-19 Projekt Podsystemu Wsparcia Eksploatacji i Help Desk.
P2-WSP-OG-08	Wykonawca w ramach Projektu Technicznego PK-19 Projekt Podsystemu Wsparcia Eksploatacji i Help Desk, na podstawie przeprowadzonej analizy opracuje model funkcjonowania Podsystemu Wsparcia Eksploatacji i Help Desk w Prokuraturze. Zamawiający wymaga żeby model zawarty w Projekcie Technicznym PK- 19 zawierał co najmniej: a. katalog usług (katalog usług rozumiany przez Zamawiającego jako opisy usług objętych wsparciem obejmujące usługi centralne realizowane w ramach przedmiotowego zamówienia): i. szablon karty usługi oraz wytycznych do ich opisywania, ii. projekt katalogu usług wraz z opisem każdej usługi, zgodnie z wytycznymi biblioteki ITIL lub innego standardu /biblioteki/ metodyki równoważnej do biblioteki ITIL v 3.1,

Identyfikator wymagania	Opis wymagania
	b. szablony umów UIC, OLA. c. projekt procesów zarządzania poziomem usług (SLM) musi zawierać: i. Zdefiniowanie procesu SLM (opisanie czynności w ramach procesu i powiązań między nimi, zidentyfikowanie ról w procesie i powiązań między nimi, stworzenie schematu graficznego procesu, szczegółowe opisanie zakresu odpowiedzialności i uprawnień dla zidentyfikowanych ról), ii. Zdefiniowanie mechanizmów raportowania poziomu usług, iii. Zdefiniowanie kluczowych wskaźników realizacji procesu (KPI), iv. Opracowanie procedur dla procesu. d. Projekty procesów wspomagania eksploatacji: i. Zarządzanie zgłoszeniami z Help Desk ii. Zarządzanie incydentami iii. Zarządzanie problemami iv. Zarządzanie zasobami i konfiguracją v. Zarządzania zdarzeniami vi. Zarządzanie zmianą vii. Zarządzanie wydaniami i wdrożeniami
P2-WSP-OG-09	W zakresie zaprojektowania funkcji Help Desk 1. Zaprojektowanie funkcji Help Desk, działającej jako jeden punkt kontaktu wspierający wszystkie usługi oraz obsługujący wszystkie zgłoszenia od wszystkich Użytkowników. Funkcja Help Desk ma uwzględniać docelową organizację pracy, 2. opisanie czynności w ramach funkcji Help Desk i powiązań między nimi, 3. zidentyfikowanie ról w ramach funkcji Help Desk i powiązań między nimi, 4. stworzenie schematu graficznego funkcji, 5. szczegółowe opisanie zakresu odpowiedzialności i uprawnień dla zidentyfikowanych ról, w tym opracowanie procedur dla funkcji Help Desk, 6. zdefiniowanie KPI dla funkcji Help Desk.
P2-WSP-OG-10	W zakresie zbudowania procesu zarządzania incydentami: 1. Zdefiniowanie procesu zarządzania incydentami (opisanie czynności w ramach procesu i powiązań między nimi, zidentyfikowanie ról w procesie i powiązań między nimi, stworzenie schematu graficznego procesu, szczegółowe opisanie zakresu odpowiedzialności i uprawnień dla zidentyfikowanych ról), 2. Zdefiniowanie schematów zgłoszeń o kategorii incydent, klasyfikacji zgłoszeń, priorytetyzacji zgłoszeń, statusów zgłoszeń w pełnym

Identyfikator wymagania	Opis wymagania
	cyklu życia zgłoszenia o kategorii incydent, mechanizmów rejestrowania, rozwiązywania, zamykania, przekazywania, i obsługi reklamacji, 3. Zdefiniowanie mechanizmów eskalacji funkcjonalnej i hierarchicznej, 4. Zdefiniowanie KPI dla procesu, 5. Opracowanie procedur dla procesu.
P2-WSP-OG-11	W zakresie zbudowania procesu zarządzania problemami: 1. Zdefiniowanie procesu zarządzania problemami (opisanie czynności w ramach procesu i powiązań między nimi, zidentyfikowanie ról w procesie i powiązań między nimi, stworzenie schematu graficznego procesu, szczegółowe opisanie zakresu odpowiedzialności i uprawnień dla zidentyfikowanych ról), 2. Zdefiniowanie schematów kontroli problemu (identyfikacja problemu i utworzenie zapisu, klasyfikacja problemu, badania i diagnoza problemu, możliwe rozwiązanie i zamknięcie problemu), 3. Zdefiniowanie schematów klasyfikacji problemów: określania kategorii i priorytetów (pilności, wpływu biznesowego), zdefiniowanie mechanizmów eskalacji funkcjonalnej i hierarchicznej, 4. Zdefiniowanie działań w ramach reaktywnego oraz pro aktywnego zarządzania problemami (analiza trendów, ustalanie celów do działań prewencyjnych, dostarczanie informacji do organizacji), 5. Zdefiniowanie KPI dla procesu.
P2-WSP-OG-12	W zakresie zbudowania procesu zarządzania wiedzą: 1. Dostęp do danych zgromadzonych w Bazie Wiedzy będzie różny dla różnych grup użytkowników i realizowany za pośrednictwem zestawu stron WWW. 2. System Bazy Wiedzy w szczególności musi: a. umożliwiać tworzenie, modyfikację/edycję lub usuwanie pozycji i dokumentów wchodzących w skład bazy wiedzy w systemie wraz z zachowywaniem informacji o historii zmian, b. umożliwiać import dokumentów wiedzowych ze źródeł zewnętrznych, co najmniej takich jak dokumenty XML, c. zapewniać możliwość dołączania załączników (np. zdjęcia, rysunki, linki do stron www) do tworzonych dokumentów wiedzowych, d. udostępniać specjalistom narzędzie do przeglądania dokumentów wiedzowych oczekujących na akceptację, e. umożliwiać sortowanie i wyszukiwanie pozycji i dokumentów wchodzących w skład Bazy Wiedzy. 3. Opracowanie procedur dla procesu.

3.2 Specyfikacja środowisk

Identyfikator wymagania	Opis wymagania
P2-SRD-SP-01	Środowiska w ramach Projektu iSDA podzielone są na Środowiska Produkcyjne i Środowiska Nieprodukcyjne.
P2-SRD-SP-02	Środowiska Produkcyjne zainstalowane będą w POPD i w przyszłości w ZOPD.
P2-SRD-SP-03	W Środowisku Produkcyjnym będą zainstalowane: 1. Centralny System Zarządzania Tożsamością. 2. Centralne Usługi Katalogowe. 3. Centralna Poczta Elektroniczna. 4. Centrum Certyfikacji. 5. Centralny Zegar. 6. Centralny Podsystem monitorowania i zarządzania ITS. 7. Centralny Podsystem Wsparcia Eksploatacji i HelpDesk
P2-SRD-SP-04	W Środowisku Nieprodukcyjnym będą zainstalowane: 1. Centralny System Zarządzania Tożsamością. 2. Centralne Usługi Katalogowe. 3. Centrum Certyfikacji. 4. Centralny Podsystem monitorowania i zarządzania ITS. 5. Centralny Podsystem Wsparcia Eksploatacji i HelpDesk

3.3 Specyfikacja wymagań zarządczych

Opisane wymagania zarządcze zostały podzielone na następujące grupy:

1. Realizacja zamówienia zgodnie z metodyką zarządzania projektem.

2. Realizacja zamówienia w oparciu o planowanie prac.

3. Realizacja zamówienia z uwzględnieniem procesu zarządzania ryzykiem.

4. Realizacja zadań i raportowanie postępów prac.

5. Realizacja zamówienia z uwzględnieniem zarządzania jakością.

6. Realizacja zamówienia przy zastosowaniu sformalizowanej procedury zarządzania zmianą i obsługi zagadnień.

7. Rozstrzyganie sporów związanych z realizacją zamówienia.

8. Komunikacja pomiędzy Stronami Umowy.

9. Wymagania dotyczące dokumentów.

3.3.1 Realizacja zamówienia zgodnie z metodyką zarządzania projektem

Identyfikator wymagania	Opis wymagania
P2-MZP-OG-01	Zamówienie realizowane będzie w oparciu o zdefiniowaną metodykę zarządzania, obejmującą co najmniej zarządzanie organizacją zespołu, zarządzanie harmonogramem, zarządzanie zmianą, zarządzanie jakością, zarządzanie ryzykiem.
P2-MZP-OG-02	Wykonawca uwzględnia zasady wynikające z metodyki zarządzania projektem stosowane przez Zamawiającego oraz Wymagania zarządcze określone w OPZ.
P2-MZP-OG-03	Wykonawca w terminie 10 dni od dnia podpisania Umowy przygotuje, w uzgodnieniu z Zamawiającym, i przekaże Zamawiającemu Dokumentację Inicjującą Projekt, zawierającą co najmniej opis założeń projektu, opis produktów specjalistycznych i zarządczych, opis struktury organizacyjnej zespołu projektowego Wykonawcy z wyszczególnieniem ról projektowych i przypisaniem odpowiedzialności za ich pełnienie konkretnym osobom oraz opis procedur zarządzania wszystkimi aspektami realizacji projektu (zarządzanie jakością, zarządzanie zmianą, zarządzanie ryzykiem, harmonogram i zarządzanie czasem, zarządzanie komunikacją).
P2-MZP-OG-04	Zamawiający może zgłosić uwagi do treści Dokumentacji Inicjującej Projekt w terminie 4 dni od dnia przekazania dokumentu. Wykonawca uwzględnia przedstawione uwagi poprzez wprowadzenie odpowiednich zmian w treści dokumentu lub uzasadnia pisemnie brak takiego uwzględnienia w terminie 3 dni od dnia otrzymania uwag Zamawiającego, o których mowa w zd. 1.
P2-MZP-OG-05	Określając organizację zespołu projektowego Wykonawca uwzględnia co najmniej role wymagane przez Zamawiającego w SIWZ oraz określa szczegółowo zakres odpowiedzialności poszczególnych ról z uwzględnieniem wymagań określonych w SIWZ.

3.3.2 Realizacja zamówienia w oparciu o planowanie prac

Identyfikator wymagania	Opis wymagania
P2-PPC-SP-01	Wykonawca realizuje zamówienie planując prace zgodnie z zasadami przyjętej metodyki zarządzania projektem, z uwzględnieniem poniższych wymagań.
P2-PPC-SP-02	Planowanie prac uwzględnia kamienie milowe określone w § 3 ust 3 Umowy. Wykonawca realizuje Umowę w terminach określonych w Harmonogramie.
P2-PPC-SP-03	Wykonawca przygotowuje Harmonogram realizacji Umowy i przedstawia go Zamawiającemu w terminie do 7 dni od dnia podpisania umowy. Postanowienia dotyczące zgłaszania i obsługi uwag Zamawiającego dotyczące DIP stosuje się odpowiednio do Harmonogramu, przy czym Wykonawca uwzględnia uwagi wskazane przez Zamawiającego w przypadku, gdy są one związane z wykonywaniem czynności w siedzibie Zamawiającego, siedzibie jednostek organizacyjnych prokuratury lub wiążą się w jakikolwiek sposób z zaangażowaniem pracowników lub innych zasobów Zamawiającego.
P2-PPC-SP-04	Harmonogram jest przygotowany w formie wykresu Gantta przy użyciu oprogramowania MS Project lub równoważnego wraz z załącznikami.
P2-PPC-SP-05	Harmonogram jest dostarczany Zamawiającemu w formacie obsługiwanym przez oprogramowanie Microsoft Project 2016.
P2-PPC-SP-06	Harmonogram musi być kompletny tj. musi uwzględniać wszystkie zadania niezbędne do wytworzenia produktów, zadania muszą być powiązane z konkretnymi produktami, z zadaniami powiązane są zasoby Wykonawcy, wprowadza się powiązania między zadaniami, określać daty rozpoczęcia zadań wynikające z powiązania pomiędzy zadaniami.
P2-PPC-SP-07	Wykonawca nie może realizować zadań wymagających zaangażowania zasobów Zamawiającego bez uzyskania akceptacji Harmonogramu.
P2-PPC-SP-08	Harmonogram akceptowany jest przez Kierownika Projektu lub Zastępcę Kierownika Projektu Zamawiającego.
P2-PPC-SP-09	Wszelkie odstępstwa od założeń określonych w Harmonogramie rozpatrywane są w ramach procedury zarządzania Zmianą. W przypadku gdy zmiany nie dotyczą terminów określonych w Umowie Zamawiający może podjąć decyzję o odstąpieniu od stosowania procedury zarządzania Zmianą. Wówczas akceptacja nowej wersji Harmonogramu przez Kierownika Projektu lub Zastępcę Kierownika Projektu Zamawiającego oznacza akceptację wprowadzonych zmian w Harmonogramie.
P2-PPC-SP-10	Terminy określone w Harmonogramie nie mogą prowadzić do wydłużenia terminów określonych w treści Umowy.
P2-PPC-SP-11	W Harmonogramie Wykonawca określa produkty powiązane z poszczególnymi zadaniami, role zaangażowane w realizację zadań, osoby odpowiedzialne po stronie Wykonawcy za realizację zadań.
P2-PPC-SP-12	Wraz z Harmonogramem Wykonawca dostarcza Zamawiającemu szczegółowe opisy produktów, strukturę podziału produktów oraz diagram następstw produktów. Struktura podziału produktów oraz diagram następstw produktów muszą uwzględniać wszystkie produkty zewnętrzne niezbędne do realizacji zadań.

Identyfikator wymagania	Opis wymagania
P2-PPC-SP-13	Dla Harmonogramu Wykonawca przygotowuje opis niezbędnego zakresu współdziałania Zamawiającego w ramach Umowy, zgodnie z § 5 ust 3 Umowy wraz z określeniem dat przewidywanego zaangażowania zasobów Zamawiającego.
P2-PPC-SP-14	Każdy z Produktów wyodrębnionych w ramach Harmonogramu ma jasno określone kryteria pozwalające na weryfikację jego dostarczenia.

3.3.3 Realizacja zamówienia z uwzględnieniem procesu zarządzania ryzykiem

Identyfikator wymagania	Opis wymagania
P2-PZR-SP-01	Wykonawca realizuje zamówienie zarządzając ryzykiem oraz uczestnicząc w procesie zarządzania ryzykiem realizowanym przez Zamawiającego zgodnie z zasadami przyjętej metodyki zarządzania projektem, z uwzględnieniem poniższych wymagań.
P2-PZR-SP-02	Wykonawca zarządza ryzykiem w ramach wykonywania zadań, zgodnie z procedurą przyjętą w Dokumentacji Inicjującej Projekt.
P2-PZR-SP-03	Wykonawca prowadzi rejestr ryzyk, którego kopia jest przekazywana Zamawiającemu wraz z raportem okresowym z realizacji obowiązków.
P2-PZR-SP-04	W przypadku gdy zidentyfikowane ryzyko wymaga wdrożenia planu odpowiedzi na ryzyko Wykonawca informuje o tym Kierownika Projektu Zamawiającego lub Zastępcę Kierownika Projektu Zamawiającego, który w ciągu 1 dnia od dnia otrzymania informacji akceptuje plan odpowiedzi na ryzyko lub zgłasza uwagi do planu odpowiedzi na ryzyko. Brak działania ze strony Zamawiającego jest równoznaczny z akceptacją planu odpowiedzi na ryzyko.
P2-PZR-SP-05	Wykonawca jest zobowiązany przekazywać Zamawiającemu informacje o identyfikowanych ryzykach w terminie 3 dni od dnia otrzymania żądania Zamawiającego.
P2-PZR-SP-06	Brak lub nieprawidłowa identyfikacja ryzyka oraz brak lub niewłaściwie podjęte działania zaradcze w przypadku materializacji ryzyka są równoznaczne z niedochowaniem należytej staranności przez Wykonawcę i wykluczają możliwość powoływania się na daną okoliczność jako na okoliczność, za którą Wykonawca nie ponosi odpowiedzialności.

3.3.4 Realizacja zadań i raportowanie postępów prac

Identyfikator wymagania	Opis wymagania
P2-RPP-SP-01	Kierownik Zamawiającego lub Zastępca Kierownika Zamawiającego mogą kierować do Wykonawcy pisemne wytyczne i/lub uwagi co do sposobu realizacji zadań. Wykonawca stosuje się do wytycznych/ uwag Zamawiającego lub uzasadnia brak ich zastosowania w terminie do 3 dni od dnia ich otrzymania.

Identyfikator wymagania	Opis wymagania
P2-RPP-SP-02	Wykonawca monitoruje stan realizacji zadań względem założeń przyjętych w Harmonogramie, w szczególności poprzez prowadzenie dziennika Projektu
P2-RPP-SP-03	Wykonawca informuje Zamawiającego o wszelkich odchyleniach od założeń przyjętych w Harmonogramie niezwłocznie po ich wystąpieniu, to jest nie później niż w terminie 3 dni od dnia ich wystąpienia.
P2-RPP-SP-04	Wykonawca przygotowuje i przekazuje Zamawiającemu raport okresowy z realizacji obowiązków umownych w terminie do 5 każdego miesiąca za każdy zakończony miesiąc realizacji umowy.
P2-RPP-SP-05	Raport okresowy zawiera co najmniej określenie zrealizowanych zadań w okresie sprawozdawczym, określenie stanu zaawansowania prac nad Produktami Projektu, wyszczególnienie Produktów zrealizowanych w danym okresie sprawozdawczym, wskazanie okoliczności, które uniemożliwiły realizację zadań projektowych zgodnie z przyjętym Harmonogramem oraz aktualny rejestr ryzyk.
P2-RPP-SP-06	Brak wskazania w raporcie okresowym okoliczności uniemożliwiających realizację zamówienia, zgodnie z przyjętym Harmonogramem, uniemożliwia Wykonawcy powoływanie się na te okoliczności jako na okoliczności niezależne od Wykonawcy.
P2-RPP-SP-07	Raport okresowy podpisywany jest przez Kierownika Projektu Wykonawcy i przekazywany w formie pisemnej.
P2-RPP-SP-08	Wykonawca przygotowuje i przekazuje Zamawiającemu raport nadzwyczajny z realizacji obowiązków umownych w terminie do 7 dni od otrzymania stosownego żądania Zamawiającego. Zamawiający przedstawiając żądanie przygotowania raportu nadzwyczajnego określa jego zakres.

3.3.5 Realizacja zamówienia z uwzględnieniem zarządzania jakością

Identyfikator wymagania	Opis wymagania
P2-ZRJ-SP-01	Wymagania jakościowe dla Produktów formułuje się z uwzględnieniem Wymagań określonych w OPZ.
P2-ZRJ-SP-02	Wykonawca doprecyzowuje wymagania jakościowe dla Produktów w Kartach Produktów.
P2-ZRJ-SP-03	Wykonawca określa w odniesieniu do poszczególnych Produktów metody kontroli jakości, wskazując je w Karcie Produktu.
P2-ZRJ-SP-04	Wykonawca przedstawia Karty Produktów wraz z Harmonogramem.
P2-ZRJ-SP-05	Karty Produktów są akceptowane przez Zamawiającego wraz z Harmonogramem.
P2-ZRJ-SP-06	Zamawiający zgłasza a Wykonawca uwzględnia uwagi Zamawiającego na zasadach określonych dla zgłaszania uwag do Harmonogramu.
P2-ZRJ-SP-07	Przed przekazaniem Zamawiającemu Produktów do odbioru Wykonawca przeprowadza wewnętrzny przegląd jakości Produktu/ów.

Identyfikator wymagania	Opis wymagania
P2-ZRJ-SP-08	Wykonawca sporządza protokół z wewnętrznego przeglądu jakości i przekazuje go Zamawiającemu. Protokół z wewnętrznego przeglądu jakości podpisuje Kierownik Projektu Wykonawcy.
P2-ZRJ-SP-09	Wszelkie odstępstwa od założeń określonych w Kartach Produktów rozpatrywane są w ramach procedury zarządzania Zmianą. W przypadku gdy Zmiany nie dotyczą Wymagań określonych w Umowie lub OPZ Zamawiający może podjąć decyzję o odstąpieniu od stosowania procedury zarządzania Zmianą. Wówczas akceptacja nowej wersji Karty Produktu przez Kierownika Projektu lub Zastępcę Kierownika Projektu Zamawiającego oznacza akceptację wprowadzonych Zmian.

3.3.6 Realizacja zamówienia przy zastosowaniu sformalizowanej procedury zarządzania zmianą i obsługi zagadnień

Identyfikator wymagania	Opis wymagania
P2-PZZ-SP-01	Wnioski o zmiany w projekcie są obsługiwane w sposób formalny
P2-PZZ-SP-02	Z wnioskiem o Zmianę mogą wystąpić Kierownik Projektu Zamawiającego lub Kierownik Projektu Wykonawcy.
P2-PZZ-SP-03	Decyzję o wprowadzeniu Zmiany podejmuje Kierownik Projektu Strony, do której kierowany jest wniosek o Zmianę.
P2-PZZ-SP-04	Żądanie wprowadzenia zmiany powinno zawierać co najmniej: uzasadnienie celowości wprowadzenia zmiany, opis skutków zaniechania zmiany, opis zmiany, wpływ Zmiany na treść dokumentów projektowych ze wskazaniem fragmentów dokumentów, które podlegać będą modyfikacji na skutek wprowadzenia Zmiany.
P2-PZZ-SP-05	Kierownik Projektu do którego skierowany został wniosek o wprowadzenie zmiany podejmuje decyzję w tym zakresie w terminie 3 dni od dnia otrzymania wniosku o Zmianę.
P2-PZZ-SP-06	W przypadku braku akceptacji wniosku o Zmianę decyzja zawiera uzasadnienie.
P2-PZZ-SP-07	W przypadku gdy decyzja o wprowadzeniu Zmiany wykracza poza tolerancje przyznane Kierownikowi Projektu podejmuje on działania zmierzające do niezwłocznego uzyskania niezbędnych decyzji. O konieczności uzyskania niezbędnych decyzji informuje się niezwłocznie drugą Stronę. W takiej sytuacji decyzję w sprawie zmiany podejmuje się w terminie do 10 dni od dnia otrzymania wniosku o zmianę.
P2-PZZ-SP-08	W trybie wniosku o Zmianę nie mogą być wprowadzane Zmiany wymagające zmiany Umowy. Zmiana Umowy może być poprzedzona wnioskiem o Zmianę. Wówczas skuteczność wprowadzonej zmiany uzależniona jest od wprowadzenia odpowiednich Zmian w Umowie.
P2-PZZ-SP-09	Kierownicy Projektu Stron mogą zgłaszać zagadnienia inne niż wnioski o Zmianę.
P2-PZZ-SP-10	Zgłoszenie zagadnienia powinno zawierać co najmniej określenie istoty zagadnienia, wpływu zagadnienia na projekt oraz pilności zagadnienia.

Identyfikator wymagania	Opis wymagania
P2-PZZ-SP-11	Kierownicy projektu Stron określają i wdrażają odpowiednie działania dla rozwiązania zagadnienia. O podjętych działaniach informuje się drugą Stronę.

3.3.7 Rozstrzyganie sporów związanych z realizacją zamówienia

Identyfikator wymagania	Opis wymagania
P2-RZS-SP-01	Spory, związane z realizacją zamówienia, powstałe pomiędzy Wykonawcą a Zamawiającym rozstrzygane są w sposób formalny.
P2-RZS-SP-02	W przypadku wystąpienia kwestii spornej każda ze Stron Umowy może skierować do drugiej strony pisemne wezwanie do polubownego rozstrzygnięcia kwestii spornej. W wezwaniu do polubownego rozstrzygnięcia kwestii spornej określa się istotę sporu, konsekwencje braku jego rozstrzygnięcia oraz proponowane warianty rozwiązania kwestii spornej.
P2-RZS-SP-03	Strony podejmują próbę rozstrzygnięcia kwestii spornych na spotkaniu przedstawicieli Stron. Przebieg i ustalenia spotkania są protokołowane. Protokół podpisywany jest przez przedstawicieli Stron Umowy po zakończeniu spotkania. Każdy z przedstawicieli Stron może przed podpisaniem zgłosić uwagi do protokołu odnoszące się do jego treści.
P2-RZS-SP-04	W przypadku braku możliwości osiągnięcia porozumienia na spotkaniu przedstawicieli Stron Umowy kwestie sporne rozstrzygane są na zasadach określonych w § 17 Umowy.

3.3.8 Komunikacja pomiędzy Stronami Umowy

Identyfikator wymagania	Opis wymagania
P2-KOM-SP-01	Podstawową formą komunikacji między Stronami jest korespondencja mailowa.
P2-KOM-SP-02	Wykonawca przesyła korespondencję mailową na adres Biura Projektu Zamawiającego, wskazany przez Xxxxxxxxxxxxx oraz na adres mailowy Kierownika Projektu Zamawiającego oraz Zastępcy Kierownika Projektu Zamawiającego.
P2-KOM-SP-03	Wysłanie wiadomości e-mail uważa się za skuteczną formę złożenia oświadczenia w każdej sytuacji gdy Umowa lub OPZ nie wymaga złożenia oświadczenia w formie pisemnej. Wiadomość e- mail uznaje się za doręczoną jeśli została dostarczona do serwera poczty odbiorcy. Wiadomość e-mail uznaje się za doręczoną w danym dniu jeśli została dostarczona w Godzinach Roboczych. Wiadomość e-mail dostarczoną poza Godzinami Roboczymi uznaje się za doręczoną kolejnego Dnia Xxxxxxxxx.
P2-KOM-SP-04	Jeśli Umowa przewiduje formę pisemną złożenia oświadczenia drugiej Stronie pismo uznaje się za doręczone poprzez osobiste doręczenie Kierownikowi Projektu Strony, Zastępcy Kierownika Projektu Strony,

Identyfikator wymagania	Opis wymagania
	pracownikowi Biura Projektu Zamawiającego lub innemu pracownikowi Strony upoważnionemu do odbioru pisma przez Kierownika Projektu Strony lub poprzez dostarczenie pisma na adres do doręczeń Strony lub poprzez dostarczenie skanu zgodnie z Wymaganiami dotyczącymi korespondencji mailowej jeśli oryginał pisma zostanie doręczony w ciągu 3 dni od dnia przekazania skanu pisma do miejsca siedziby Strony. W przypadku osobistego doręczenia osoba otrzymująca pismo potwierdza jego doręczenie na kopii pisma wskazując datę jego otrzymania. Jako dzień otrzymania pisma uznaje się dzień potwierdzenia otrzymania pisma przez uprawnioną osobę, dzień dostarczenia pisma na adres do doręczeń lub dzień przekazania skanu pisma drogą mailową pod warunkiem że oryginał pisma zostanie doręczony drugiej Stronie w ciągu 3 dni od dnia przekazania skanu pisma.
P2-KOM-SP-05	Za adres do doręczeń uznaje się adres siedziby Xxxxxx wskazany w Umowie. Strony mogą poinformować pisemnie o zmianie adresu do doręczeń. Każda zmiana adresu Stron wymaga powiadomienia o tym Strony drugiej pod rygorem uznania korespondencji skierowanej pod adres dotychczasowy za doręczoną.
P2-KOM-SP-06	Strony podejmują ustalenia robocze oraz podejmują decyzje projektowe na spotkaniach roboczych odbywających się co najmniej raz w tygodniu w terminach uzgodnionych przez Strony. Kierownik Projektu Zamawiającego może zdecydować o rezygnacji ze spotkania roboczego. Ze spotkania roboczego przygotowuje się protokół, określający co najmniej ustalenia podjęte na spotkaniu. Protokół podpisywany jest przez przedstawicieli Stron Umowy po zakończeniu spotkania. Każdy z przedstawicieli Stron może przed podpisaniem zgłosić uwagi do protokołu odnoszące się do jego treści. W spotkaniach roboczych uczestniczą Kierownicy Projektów Stron lub Zastępcy Kierowników Projektów Stron lub osoby przez nich uprawnione do reprezentowania Strony na spotkaniu roboczym.
P2-KOM-SP-07	Zamawiający może zobowiązać Wykonawcę do korzystania z oprogramowania do obsługi procesów związanych z realizację projektu. W takiej sytuacji Xxxxxxxxxxx zapewnia licencje oprogramowania niezbędne do korzystania z oprogramowania przez Wykonawcę.
P2-KOM-SP-08	Wykonawca może wnioskować o korzystanie przez Zamawiającego z oprogramowania do obsługi procesów związanych z realizacją projektu. W przypadku wyrażenia zgody przez Xxxxxxxxxxxxx, Wykonawca zapewnia licencje oprogramowania niezbędne do korzystania z oprogramowania przez Zamawiającego oraz (jeśli jest to konieczne) przeszkolenie pracowników Zamawiającego w zakresie wykorzystywania wskazanego oprogramowania.

3.3.9 Wymagania dotyczące dokumentów

Identyfikator wymagania	Opis wymagania
P2-WDD-SP-01	Każdy Dokument przygotowany przez Wykonawcę musi posiadać metrykę wskazującą co najmniej: osobę ze strony Wykonawcy odpowiedzialną za treść Dokumentu, osobę ze strony Wykonawcy odpowiedzialną za weryfikację Dokumentu, numer wersji Dokumentu, opis dokonanych zmian poprzez wskazanie zmienionego fragmentu oraz opisanie dokonanej zmiany (dotyczy kolejnych wersji Dokumentu), powód wprowadzenia zmian (dotyczy kolejnych wersji Dokumentu), autora wprowadzonej zmiany (dotyczy kolejnej wersji Dokumentu). Jeżeli Dokument dotyczy konkretnej wersji Systemu (np. dokumentacja użytkownika) metryka winna zawierać określenie wersji systemu, którego dotyczy.
P2-WDD-SP-02	Każdy Dokument powinien posiadać słownik skrótów i pojęć w wersji alfabetycznej jeśli skróty i pojęcia wymagające wyjaśnienia były wykorzystywane w Dokumencie.
P2-WDD-SP-03	Każdy Dokument powinien mieć logiczną strukturę dopasowaną do treści. Dokumenty o objętości pow. 10 stron muszą być podzielone na jednostki redakcyjne (rozdziały, podrozdziały, sekcje).
P2-WDD-SP-04	Treści zawarte w Dokumentach muszą być niesprzeczne logicznie.
P2-WDD-SP-05	Dokumenty będą dostarczone Zamawiającemu w wersji edytowalnej (plik MS Word) a także w wersji Portable Document Format (zgodny z ISO 32000-1:2008). Na żądanie Zamawiającego lub jeśli wynika to z Umowy Wykonawca dostarczy dokument w wersji drukowanej (wydruk kolorowy) i/lub w wersji stanowiącej skan Dokumentu.
P2-WDD-SP-06	Jeśli dokument wprowadza zmiany w stosunku do poprzedniej wersji Wykonawca dostarczy na żądanie Zamawiającego wersję dokumentu w formacie MS Word z zarejestrowanymi zmianami. W przypadku, gdy przekazywany Dokument jest wynikiem eksportu z innego narzędzia, Zamawiający dopuszcza dostarczenie wersji różnicowej w innej formie pod warunkiem, że taka forma zostanie uprzednio przez niego zaakceptowana.
P2-WDD-SP-07	Dokumenty przygotowane w ramach Projektu oraz korespondencja pomiędzy Stronami muszą zawierać oznaczenia wskazujące na współfinansowanie projektu ze środków unijnych w ramach Programu Operacyjnego Polska Cyfrowa. Zamawiający przekaże Wykonawcy odpowiednie wzory oznaczeń po podpisaniu Umowy. Wymaganie nie ma zastosowania do korespondencji mailowej. Wymaganie nie ma zastosowania do wydruków Dokumentów z programów nie pozwalających na modyfikację obrazu Dokumentu. W odniesieniu do wydruków dokumentów z programów nie pozwalających na modyfikację obrazów dokumentu Wykonawca załącza stronę tytułową zawierającą oznaczenia wskazane w niniejszym Wymaganiu.
P2-WDD-SP-08	Wszystkie modele procesów muszą być zapisane w notacji BPMN z możliwością edycji w programie Sparx Enterprise Architect.

3.4 Specyfikacja produktów Specjalistycznych

1. Produkt Typu Dokument – jest to dokumentem opracowanym wg ustalonych szablonów.

2. Produkt Typu Oprogramowanie – jest Oprogramowaniem Gotowym i/lub Dedykowanym wykonywanym wg projektów zgodnie z przyjętymi zasadami. Do tego Typu Produktu zaliczane są również wszystkie skrypty oraz parametry konfiguracyjne oprogramowania.

3. Produkt Typu Usługa - usługa realizowana przez Wykonawcę (np. instalacja, konfiguracja) wykonywana wg projektów lub innych dokumentów zaakceptowanych przez Zamawiającego.

3.4.1 Wykaz produktów

Zadanie	Nazwa Produktu	Typ Produktu	Termin realizacji zgodnie z par 3 ust 3 Umowy
Dostarczenie Sprzętu i licencji Oprogramowania Gotowego	PK-01 Lista kontrolna zgodności parametrów dostarczonego sprzętu dla Centralnych Usług Infrastrukturalnych	Dokument	Wykonanie w terminie określonym w par 3 ust 3 lit a Umowy
	PK-02 Plan dostaw sprzętu i licencji dla Centralnych Usług Infrastrukturalnych	Dokument
	PK-03 Dostawa sprzętu i licencji dla Centralnych Usług Infrastrukturalnych	Usługa
Wykonanie projektów technicznych Centralnych Usług Infrastrukturalnych dla Środowiska Produkcyjnego i Testowego	PK-04 Projekt integracji Podsystemów Centralnych Usług Infrastrukturalnych	Dokument
	PK-05 Projekt infrastruktury techniczno-systemowej dla Centralnych Usług Infrastrukturalnych	Dokument
	PK-06 Projekt Centralnych Usług Katalogowych	Dokument
	PK-07 Projekt Centralnej Poczty	Dokument
	PK-08 Projekt Systemu Zarządzania Tożsamością	Dokument
	PK-09 Projekt Centrum Certyfikacji	Dokument
	PK-10 Projekt Centralnego Systemu Monitorowania i Zarządzania ITS	Dokument
	PK-11 Projekt Podsystemu Wsparcia eksploatacji i HelpDesk	Dokument
	PK-12 Projekt Farmy Stacji Roboczych z uwzględnieniem dostaw sprzętu realizowanego w ramach postępowania POS-2.1	Dokument
	PK-13 Procedura migracji stacji roboczych i stacji skanowania dostarczonych w ramach Projektu SDA do Farmy Stacji Roboczych i integracji z Centralnymi Usługami Infrastrukturalnymi	Dokument

	PK-14 Procedura migracji pozostałych stacji roboczych prokuratury do Farmy Stacji Roboczych i integracji z Centralnymi Usługami Infrastrukturalnymi	Dokument
Wykonanie scenariuszy testów Centralnych Usług Infrastrukturalnych	PK-15 Scenariusze testów Centralnych Usług Katalogowych	Dokument
	PK-16 Scenariusze testów Centralnej Poczty	Dokument
	PK-17 Scenariusze testów Systemu Zarządzania Tożsamością	Dokument
	PK-18 Scenariusze testów Centrum Certyfikacji	Dokument
	PK-19 Scenariusze testów Centralnego Systemu Monitorowania i Zarządzania ITS.	Dokument
	PK-20 Scenariusze testów Podsystemu Wsparcia eksploatacji i HelpDesk.	Dokument
	PK-21 Scenariusze testów integracji Podsystemów Centralnych Usług Infrastrukturalnych.	Dokument
Konfiguracja i instalacja Centralnych Usług Infrastrukturalnych w Środowisku Testowym	PK-22 Plan testów Centralnych Usług Infrastrukturalnych wraz z integracją dla Środowiska Testowego.	Dokument
	PK-23 Konfiguracja infrastruktury techniczno-systemowej Środowiska Testowego Centralnych Usług Infrastrukturalnych.	Usługa
	PK-24 Instalacja podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych w Środowisku Testowym.	Usługa
	PK-25 Przeprowadzenie testów Centralnych Usług Infrastrukturalnych w Środowisku Testowym	Usługa
Opracowanie dokumentacji i procedur Centralnych Usług Infrastrukturalnych	PK-26 Dokumentacja administratora Usług Katalogowych	Dokument	Wykonanie w terminie określonym w par 3 ust 3 lit b Umowy
	PK-27 Dokumentacja udostępniania Usług Katalogowych innym systemom.	Dokument

	PK-28 Dokumentacja administratora Poczty	Dokument
	PK-29 Dokumentacja administratora Systemu Zarządzania Tożsamością	Dokument
	PK-30 Dokumentacja użytkowania Systemu Zarządzania Tożsamością dla komórek kadrowych.	Dokument
	PK-31 Dokumentacja użytkownika Systemu Zarządzania Tożsamością	Dokument
	PK-32 Dokumentacja udostępniania usług Systemu Zarządzania Tożsamością dla innych systemów.	Dokument
	PK-33 Procedury Systemu Zarządzania Tożsamością	Dokument
	PK-34 Dokumentacja administratora Centrum Certyfikacji	Dokument
	PK-35 Dokumentacja użytkownika Centrum Certyfikacji	Dokument
	PK-36 Dokumentacja udostępniania usług Centrum Certyfikacji dla innych systemów.	Dokument
	PK-37 Procedury Centrum Certyfikacji	Dokument
	PK-38 Dokumentacja administratora Centralnego Podsystemu Monitorowania i Zarządzania	Dokument
	PK-39 Dokumentacja administratorów lokalnych Centralnego Monitorowania i Zarządzania	Dokument
	PK-40 Dokumentacja integracji Centralnego Podsystemu Monitorowania i Zarządzania z innymi systemami.	Dokument
	PK-41 Procedury Centralnego Monitorowania i Zarządzania.	Dokument
	PK-42 Dokumentacja administratora Centralnego Podsystemu Wsparcia Eksploatacji	Dokument
	PK-43 Dokumentacja użytkownika Centralnego Podsystemu Wsparcia Eksploatacji	Dokument

	PK-44 Dokumentacja użytkownika Centralnego HelpDesk	Dokument
	PK-45 Dokumentacja integracji Centralnego Podsystemu Wsparcia Eksploatacji z innymi systemami.	Dokument
	PK-46 Procedury Podsystemu Wsparcia Eksploatacji i HelpDesk	Dokument
Opracowanie planu testów i wdrażania Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym	PK-47 Plan testów akceptacyjnych Centralnych Usług Infrastrukturalnych wraz z integracją na Środowisku Produkcyjnym.	Dokument
	PK-48 Plan wdrożenia Centralnych Usług Infrastrukturalnych.	Dokument
Przygotowanie, instalacja i konfiguracja Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym	PK-49 Konfiguracja ITS dla potrzeb Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym.	Usługa
	PK-50 Instalacja i konfiguracja Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych na Środowisku Produkcyjnym.	Usługa
Testy Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym	PK-51 Testy akceptacyjne Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych na Środowisku Produkcyjnym.	Usługa
	PK-52 Testy akceptacyjne integracji Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych	Usługa
Wdrażanie Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym	PK-53 Wdrożenie produkcyjne Centralnych Usług Infrastrukturalnych.	Usługa
Przeprowadzenie Pilotażu w Środowisku Produkcyjnym	PK-55 Plan przeprowadzenia Pilotażu	Dokument
	PK-56 Przeprowadzenie Pilotażu	Usługa

Przygotowanie dokumentacji powykonawczej	PK-57 Dokumentacja powykonawcza integracji Podsystemów Centralnych Usług Infrastrukturalnych	Dokument
	PK-58 Dokumentacja powykonawcza infrastruktury techniczno-systemowej dla Centralnych Usług Infrastrukturalnych	Dokument
	PK-59 Dokumentacja powykonawcza Centralnych Usług Katalogowych	Dokument
	PK-60 Dokumentacja powykonawcza Centralnej Poczty	Dokument
	PK-61 Dokumentacja powykonawcza Systemu Zarządzania Tożsamością	Dokument
	PK-62 Dokumentacja powykonawcza Centrum Certyfikacji	Dokument
	PK-63 Dokumentacja powykonawcza Centralnego Systemu Monitorowania i Zarządzania ITS	Dokument
	PK-64 Dokumentacja powykonawcza Podsystemu Wsparcia eksploatacji i HeplDesk	Dokument
	PK-65 Dokumentacja powykonawcza Farmy Stacji Roboczych	Dokument
	PK-66 Dokonania integracji Stacji roboczych oraz stacji roboczych posiadanych przez Zamawiającego w Farmę Stacji Roboczych zintegrowaną z Centralnymi Usługami Infrastrukturalnymi	Usługa	Wykonanie w terminie określonym w par 3 ust 3 lit c Umowy
	PK-67 Przeprowadzenie szkoleń	Usługa

3.4.2 Dostarczenie sprzętu oraz licencji oprogramowania. Wykonanie projektów technicznych i scenariuszy testów

3.4.2.1 Zadanie 1.1. Dostarczenie sprzętu i licencji oprogramowania

3.4.2.1.1 PK-01 Lista kontrolna zgodności parametrów dostarczanego sprzętu dla Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-1	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-2	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-3	Wykonawca przygotuje listy kontrolne dla dostarczanego sprzętu przeznaczonego w ramach Umowy przeznaczonego do budowy Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-4	Przygotowane przez Wykonawcę listy kontrolne będą zawierać wykaz wszystkich wymagań wynikających z warunków Umowy oraz OPZ.
P2-PRO-SP-5	Przygotowane przez Wykonawcę listy kontrolne muszą umożliwić łatwą weryfikację sprawdzanych wymagań przez pracowników Zamawiającego.
P2-PRO-SP-6	Listy kontrolne będą podstawą przy przeprowadzanych odbiorach i zostaną dołączone jako załączniki do protokołów odbioru.

3.4.2.1.2 PK-02 Plan dostaw sprzętu i licencji dla Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-7	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-8	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-9	Plan dostawy musi zawierać szczegółową specyfikację dostaw realizowanych przez Wykonawcę w ramach Umowy przeznaczonego do budowy Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-10	Plan dostaw musi zawierać specyfikację dostaw umożliwiający w sposób automatyczny załadowania danych do bazy CMDB utworzonej w ramach Podsystemu Wsparcia Eksploatacji i Help Desk będącej przedmiotem niniejszego postępowania.
P2-PRO-SP-11	Plan dostaw musi zawierać dokładne rozliczenie dostarczanych licencji oprogramowania dla Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-12	Plan dostaw musi zawierać dokładny opis zasad licencjonowania dostarczanych licencji.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-13	W przypadku gdy licencja oprogramowania objęta jest opłatą okresowej opieki wówczas w Planie dostaw Wykonawca poda wszystkie dane umożliwiające przedłużenie czasu opieki przez Zamawiającego.
P2-PRO-SP-14	Plan dostawy musi zawierać szczegółowy harmonogram dostaw do miejsca wskazanego przez Zamawiającego.
P2-PRO-SP-15	Plan dostawy musi zawierać szczegółowy harmonogram dostaw do miejsca wskazanego przez Zamawiającego.
P2-PRO-SP-16	Plan dostaw musi zawierać szczegółową procedurę powiadamiania Zamawiającego o dostawie oraz procedurę umożliwiającą monitorowanie dostaw.
P2-PRO-SP-17	Plan dostaw musi zawierać procedurę dostawy ilościowej (dostawa paczek).
P2-PRO-SP-18	Plan dostaw musi zawierać procedurę odbioru jakościowego.
P2-PRO-SP-19	Plan dostaw musi zawierać procedurę zmian terminów w trakcie realizacji dostaw.
P2-PRO-SP-20	Plan dostaw musi zawierać procedurę obsługi uszkodzeń sprzętu w trakcie dostawy.
P2-PRO-SP-21	Plan dostaw musi zawierać specyfikację niezbędnych dokumentów i protokołów potwierdzających prawidłowość dostawy.

3.4.2.1.3 PK-03 Dostawa sprzętu i licencji dla Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-22	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-23	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-24	Usługa zostanie zrealizowana zgodnie z Produktem PK-06 Plan dostaw sprzętu dla Centralnych Usług Infrastrukturalnych.

3.4.2.2 Zadanie 1.2. Wykonanie projektów technicznych Centralnych Usług Infrastrukturalnych dla Środowiska Produkcyjnego i Testowego

3.4.2.2.1 PK-4 Projekt integracji Podsystemów Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-25	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-26	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-27	Projekt integracji musi zawierać architekturę wszystkich komponentów wchodzących w skład Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-28	Projekt w architekturze musi określać zasady współdziałania POPD oraz ZOPD.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-29	Projekt integracji musi określać zasady integracji Podsystemów, które umożliwią automatyzację procesów realizowane w ramach Centrum Usług Infrastrukturalnych np. wprowadzenie nowej tożsamości uruchamia proces założenia pozycji w Usługach Katalogowych, założenia konta w Poczcie oraz wydanie certyfikatu i karty mikroprocesorowej.
P2-PRO-SP-30	W projekcie integracji muszą być wyspecyfikowane wszystkie interfejsy Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-31	W projekcie integracji muszą być opisane wszystkie interfejsy do połączenia z systemami zewnętrznymi.
P2-PRO-SP-32	W projekcie integracji muszą być opisane zasady monitorowania poprawności pracy zintegrowanych Podsystemów oraz zasady lokalizacji przyczyn niewłaściwej pracy.
P2-PRO-SP-33	W projekcie Wykonawca w zakresie bezpieczeństwa opracuje: 1. Opis zastosowanych środków technicznych w celu zapewnienia poufności, integralności i rozliczalności przetwarzanych danych, 2. Opis struktury zbiorów danych wskazujący zawartość poszczególnych pól informacyjnych i powiązania między nimi, 3. Sposób przepływu danych pomiędzy poszczególnymi podsystemami POS – 2.1 oraz systemem POS – 1, 4. Wykaz środków technicznych niezbędnych dla zapewnienia poufności, integralności i rozliczalności przetwarzanych danych, 5. Procedury rejestrowania uprawnień w podsystemach, 6. Stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem, 7. Procedury rozpoczęcia, zawieszenia i zakończenia pracy przeznaczone dla użytkowników podsystemów, 8. Procedury tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi programowych służących do ich przetwarzania, 9. Sposób zabezpieczenia podsystemów przed działalnością oprogramowania, którego celem jest uzyskanie nieuprawnionego dostępu do systemu.
P2-PRO-SP-34	Wykonawca w ramach projektu opracuje podstawowe zasady w zakresie zarządzania bezpieczeństwem podsystemów informatycznych wdrożonych Centralnych Usług Infrastrukturalnych, obejmujące: 1. zarządzanie konfiguracją, 2. zarządzanie zmianami, 3. planowanie awaryjne i planowanie odtwarzania po katastrofach, 4. wybór i wdrożenie zabezpieczeń, 5. działania bieżące, w tym:

Identyfikator wymagania

Opis wymagania

a. obsługę, b. audyt bezpieczeństwa, c. monitorowanie, d. przeglądy, e. obsługę incydentów. Wykonawca przy opracowaniu Podstawowych zasad w zakresie zarządzania bezpieczeństwem podsystemów informatycznych wdrożonych Centralnych Usług Infrastrukturalnych, wykorzysta zalecenia następujących polskich norm: 1. PN – I – 13335 – 1:1999 Technika informatyczna – Wytyczne do zarządzania bezpieczeństwem systemów informatycznych – Pojęcia i modele bezpieczeństwa systemów informatycznych, 2. PN – ISO/IEC 27001:2014 – 12 Technika informatyczna – Techniki bezpieczeństwa – Systemy zarządzania bezpieczeństwem informacji – Wymagania.

3.4.2.2.2 PK-5 Projekt infrastruktury techniczno-systemowej dla Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-35	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-36	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-37	Projekt ITS musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD.
P2-PRO-SP-38	W Projekcie ITS Wykonawca zaprojektuje infrastrukturę dla Środowisk Produkcyjnych oraz dla Środowisk Testowych.
P2-PRO-SP-39	Dla projektowanej infrastruktury Wykonawca wykorzysta udostępniane zasoby przez Zamawiającego oraz zasoby dostarczone w ramach niniejszego postępowania.
P2-PRO-SP-40	Dla wszystkich środowisk Wykonawca opracuje architekturę Techniczno-Systemową określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego.
P2-PRO-SP-41	Projekt Infrastruktury Techniczno-Systemowej musi zawierać minimum: 1. Wykaz wykorzystanego sprzętu i licencji oprogramowania, 2. Przyjęte nazewnictwo elementów infrastruktury. 3. Plan ustawienia szaf w pomieszczeniach serwerowni, 4. Projekt sieci LAN i SAN w serwerowni, 5. Plan rozmieszczenia modułów w szafach, 6. Projekt zarządzania infrastrukturą w serwerowni.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-42	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy tj. co najmniej dla: 1. CUK 2. CPE 3. SZT 4. CC

3.4.2.2.3 PK-6 Projekt Centralnych Usług Katalogowych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-43	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-44	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-45	Projekt Centralnych Usług Katalogowych musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD.
P2-PRO-SP-46	W Projekcie Centralnych Usług Katalogowych Wykonawca zaprojektuje rozwiązanie dla Środowisk Produkcyjnych oraz dla Środowisk Nieprodukcyjnych.
P2-PRO-SP-47	Dla wszystkich środowisk Wykonawca opracuje architekturę określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego.
P2-PRO-SP-48	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy.
P2-PRO-SP-49	Projekt musi zawierać minimum: 1. Analizę Środowiska Zamawiającego 2. Architekturę Centralnych Usług Katalogowych. 3. Projekt nazewnictwa elementów. 4. Projekt struktury Lasu. 5. Projekt struktury domeny. 6. Projekt infrastruktury DNS. 7. Projekt topologii lokacji. 8. Projekt konfiguracji serwerów Usług Katalogowych. 9. Wykaz procedur dla zarządzania usługami katalogowymi. 10. Wykaz procedur administratora w zakresie utrzymania Usług Katalogowych.

3.4.2.2.4 PK-7 Projekt Centralnej Poczty

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-50	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-51	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-52	Projekt Centralnej Poczty musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD.
P2-PRO-SP-53	W Projekcie Centralnej Poczty Wykonawca zaprojektuje rozwiązanie dla Środowisk Produkcyjnych.
P2-PRO-SP-54	Dla wszystkich środowisk Wykonawca opracuje architekturę określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego.
P2-PRO-SP-55	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy.
P2-PRO-SP-56	Projekt musi zawierać minimum: 1. Analizę Środowiska Zamawiającego 2. Architekturę Centralnej Poczty. 3. Projekt nazewnictwa elementów. 4. Projekt struktury skrzynek pocztowych. 5. Projekt topologii lokacji. 6. Projekt konfiguracji serwerów Poczty. 7. Wykaz procedur dla zarządzania usługami Poczty. 8. Wykaz procedur administratora w zakresie utrzymania Poczty.

3.4.2.2.5 PK-8 Projekt Systemu Zarządzania Tożsamością

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-57	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-58	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-59	Projekt Systemu Zarządzania Tożsamością musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD.
P2-PRO-SP-60	W Projekcie Systemu Zarządzania Tożsamością Wykonawca opisze rozwiązanie dla Środowisk Produkcyjnych oraz dla Środowisk Nieprodukcyjnych.
P2-PRO-SP-61	Dla wszystkich środowisk Wykonawca opracuje architekturę określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego i Dedykowanego.
P2-PRO-SP-62	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy.
P2-PRO-SP-63	Projekt musi zawierać minimum: 1. Architekturę Systemu Zarządzania Tożsamością. 2. Projekt nazewnictwa elementów. 3. Projekt wszystkich elementów wchodzących w skład Systemu Zarządzania Tożsamością. 4. Projekt konfiguracji serwerów Systemu Zarządzania Tożsamością.

Identyfikator wymagania

Opis wymagania

5. Projekt połączenia Systemu Zarządzania Tożsamością z systemami finansowo-księgowymi wszystkich jednostek szczebla okręgowego, regionalnego i PK. 6. Procedurę inicjalnego ładowania danych z systemów finansowo- księgowych. 7. Projekty wszystkich procesów realizowanych przez System Zarządzania Tożsamością w notacji BPMN. 8. Wykaz procedur dla zarządzania usługami Systemu Zarządzania Tożsamością. 9. Wykaz procedur administratora w zakresie utrzymania SZT.

3.4.2.2.6 PK-9 Projekt Centrum Certyfikacji

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-64	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-65	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-66	Projekt Centrum Certyfikacji musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD.
P2-PRO-SP-67	W Projekcie Centrum Certyfikacji Wykonawca opisze rozwiązanie dla Środowisk Produkcyjnych oraz dla Środowisk Nieprodukcyjnych.
P2-PRO-SP-68	Dla wszystkich środowisk Wykonawca opracuje architekturę określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego.
P2-PRO-SP-69	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy.
P2-PRO-SP-70	Projekt musi zawierać minimum: 1. Analizę Środowiska Zamawiającego 2. Architekturę Centrum Certyfikacji. 3. Projekt nazewnictwa elementów. 4. Projekt wszystkich elementów wchodzących w skład Centrum Certyfikacji. 5. Projekt konfiguracji serwerów Centrum Certyfikacji. 6. Projekt połączenia Centrum Certyfikacji z innymi systemami . 7. Procedurę personalizacji i wydawania kart mikroprocesorowych. 8. Projekty wszystkich procesów realizowanych przez Centrum Certyfikacji w notacji BPMN. 9. Wykaz procedur dla zarządzania usługami Centrum Certyfikacji. 10. Wykaz procedur administratora w zakresie utrzymania Centrum Certyfikacji. 11. Projekt graficzny karty mikroprocesorowej.

3.4.2.2.7 PK-10 Projekt Centralnego Systemu Monitorowania i Zarządzania ITS

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-71	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-72	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-73	Projekt Centralnego Systemu Monitorowania i Zarządzania ITS musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD.
P2-PRO-SP-74	W Projekcie Wykonawca opisze rozwiązanie dla Środowisk Produkcyjnych oraz dla Środowisk Nieprodukcyjnych..
P2-PRO-SP-75	Dla wszystkich środowisk Wykonawca opracuje architekturę określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego.
P2-PRO-SP-76	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy.
P2-PRO-SP-77	Projekt musi zawierać minimum: 1. Architekturę Centralnego Systemu Monitorowania i Zarządzania ITS. 2. Projekt nazewnictwa elementów. 3. Projekt wszystkich elementów wchodzących w skład Centralnego Systemu Monitorowania i Zarządzania ITS. 4. Projekt konfiguracji serwerów Centralnego Systemu Monitorowania i Zarządzania ITS. 5. Projekty wszystkich procesów realizowanych przez System w notacji BPMN. 6. Wykaz procedur dla zarządzania usługami Centralnego Systemu Monitorowania i Zarządzania ITS. 7. Wykaz procedur administratora w zakresie utrzymania Centralnego Systemu Monitorowania i Zarządzania ITS.
P2-PRO-SP-78	Projekt musi zawierać opis Centralnego Systemu Zarządzania Oprogramowaniem Antywirusowym minimum w zakresie: 1. Architekturę Centralnego Systemu Zarządzania Oprogramowaniem Antywirusowym. 2. Projekt nazewnictwa elementów systemu. 3. Projekt wszystkich elementów wchodzących w skład Centralnego Systemu Zarządzania Oprogramowaniem Antywirusowym. 4. Projekt konfiguracji serwerów Centralnego Systemu Zarządzania Oprogramowaniem Antywirusowym. 5. Wykaz procedur dla zarządzania Centralnym Systemem Zarządzania Oprogramowaniem Antywirusowym. 6. Wykaz procedur administratora w zakresie utrzymania Centralnego Systemu Zarządzania Oprogramowaniem Antywirusowym.

3.4.2.2.8 PK-11 Projekt Podsystemu Wsparcia eksploatacji i Help Desk

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-79	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-80	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-81	Projekt Podsystemu Wsparcia Eksploatacji i Help Desk musi zawierać rozwiązania dla POPD i ZOPD. W ramach niniejszego postępowania budowane będzie jedynie POPD. Podsystem Wsparcia Eksploatacji i Help Desk składał się będzie z następujących komponentów: 1. Komponent HelpDesk dla obsługi użytkowników wewnętrznych (dostępny w Strefie Wewnętrznej w ramach sieci WAN-PROK). 2. Komponent HelpDesk dla obsługi użytkowników zewnętrznych (dostępny w Strefie Zewnętrznej w ramach sieci Internet). 3. Komponent Wsparcia Eksploatacji obsługującego procedury utrzymania oraz zawierający bazę CMDB i Bazę Wiedzy.
P2-PRO-SP-82	W Projekcie Wykonawca opisze rozwiązanie dla Środowisk Produkcyjnych oraz dla Środowisk Nieprodukcyjnych.
P2-PRO-SP-83	Dla wszystkich środowisk Wykonawca opracuje architekturę określającą wszystkie niezbędne elementy sprzętowe oraz licencje Oprogramowania Gotowego.
P2-PRO-SP-84	Dla krytycznych węzłów infrastruktury Wykonawca zastosuje rozwiązania redundantne zapewniające niezawodność pracy.
P2-PRO-SP-85	Projekt musi zawierać minimum: 1. Architekturę Podsystemu Wsparcia Eksploatacji i Help Desk. 2. Projekt nazewnictwa elementów. 3. Projekt wszystkich elementów wchodzących w skład Podsystemu Wsparcia Eksploatacji i Help Desk. 4. Projekt konfiguracji serwerów Podsystemu. 5. Projekt Bazy Wiedzy. 6. Projekt struktury bazy CMDB. 7. Projekt inicjalnego załadowania bazy CMDB. 8. Projekt katalogu usług, 9. Projekt zarządzania poziomem usług (SLM), 10. Projekty procesów realizowanych przez Podsystem w notacji BPMN w szczególności procesów: a. Zarządzanie zgłoszeniami z Help Desk b. Zarządzanie incydentami c. Zarządzanie problemami d. Zarządzanie zasobami i konfiguracją e. Zarządzania zdarzeniami f. Zarządzanie zmianą g. Zarządzanie wydaniami i wdrożeniami 11. Wykaz procedur dla zarządzania usługami Podsystemu Wsparcia Eksploatacji i Help Desk. 12. Wykaz procedur administratora w zakresie utrzymania Podsystemu Wsparcia Eksploatacji i Help Desk.

3.4.2.2.9 PK-12 Projekt Farmy Stacji Roboczych z uwzględnieniem dostaw sprzętu realizowanego w ramach postępowania POS-2.1

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-86	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-87	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-88	Projekt Farmy Stacji Roboczych musi zawierać rozwiązania umożliwiające dostęp ze Stacji Roboczych do POPD i ZOPD.
P2-PRO-SP-89	Projekt musi zawierać minimum: 1. Architekturę Farmy Stacji Roboczych. 2. Projekt nazewnictwa elementów. 3. Projekt wszystkich elementów wchodzących w skład Farmy Stacji Roboczych. 4. Projekt integracji Farmy Stacji Roboczych z Centralnymi Usługami Infrastrukturalnymi. 5. Plan prac związanych z uruchomieniem Farmy Stacji Roboczych oraz integracji z Centralnymi Usługami Infrastrukturalnymi. 6. Wykaz procedur dla zarządzania usługami Farmy Stacji Roboczych. 7. Wykaz procedur administratora w zakresie utrzymania Farmy Stacji Roboczych.

3.4.2.2.10 PK-13 Procedura migracji stacji roboczych i stacji skanowania dostarczonych w ramach Projektu SDA do Farmy Stacji Roboczych i integracji z Centralnymi Usługami Infrastrukturalnymi

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-90	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-91	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-92	Procedura migracji stacji roboczych i stacji skanowania dostarczonych w ramach projektu SDA musi zawierać co najmniej: 1. Szczegółową specyfikację Stacji Roboczych dostarczonych w ramach Projektu SDA. 2. Instrukcję konfiguracji Stacji Roboczej dla podłączenia do Centralnych Usług Infrastrukturalnych. 3. Instrukcję rekonfiguracji stacji roboczej po awariach np. uszkodzeniu dysku. 4. Instrukcję podłączenia Stacji Roboczej do sieci LAN. 5. Instrukcję uruchomienia testów lokalnych Stacji Roboczej. 6. Instrukcję podłączenia Stacji Roboczej do Centralnych Usług Infrastrukturalnych.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-93	W przypadku dostarczenia przez Wykonawcę skryptów dla konfiguracji lub rekonfiguracji Stacji Roboczej będą one podlegać odbiorowi zgodnie z Procedurą odbioru Kodów Źródłowych stanowiącą Załącznik nr 7 do Umowy.

3.4.2.2.11 PK-14 Procedura migracji pozostałych stacji roboczych prokuratury do Farmy Stacji Roboczych i integracji z Centralnymi Usługami Infrastrukturalnymi

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-94	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-95	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-96	Procedura migracji pozostałych stacji musi zawierać co najmniej: 1. Specyfikację Stacji Roboczych, 2. Instrukcję konfiguracji Stacji Roboczej dla podłączenia do Centralnych Usług Infrastrukturalnych. 3. Instrukcję rekonfiguracji stacji roboczej po awariach np. uszkodzeniu dysku. 4. Instrukcję podłączenia Stacji Roboczej do sieci LAN. 5. Instrukcję uruchomienia testów lokalnych Stacji Roboczej. 6. Instrukcję podłączenia Stacji Roboczej do Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-97	W przypadku dostarczenia przez Wykonawcę skryptów dla konfiguracji lub rekonfiguracji Stacji Roboczej będą one podlegać odbiorowi zgodnie z Procedurą odbioru Kodów Źródłowych stanowiącą Załącznik nr 7 do Umowy.

3.4.2.3 Zadanie 1.3. Wykonanie scenariuszy testów Centralnych Usług Infrastrukturalnych

3.4.2.3.1 Wymagania na scenariusze testów dla wszystkich rodzajów testów

Identyfikator wymagania

Opis wymagania

P2-PRO-SP-98

Zamawiający wymaga, aby dla testów zostały przygotowane i przedstawione do akceptacji scenariusze testowe obejmujące: 1. Testy Podsystemów: a. Scenariusze testów muszą być przygotowane dla każdego Podsystemu oddzielnie, 2. Testy Integracji: a. Scenariusze testów muszą umożliwiać przeprowadzenie testów integracji Podsystemów, 3. Testy Akceptacyjne: a. Scenariusze testów muszą uwzględniać przeprowadzenie testów wymagań funkcjonalnych i pozafunkcjonalnych wraz z przeprowadzeniem testów procedur eksploatacyjnych.

Identyfikator wymagania	Opis wymagania
	4. Za kompletność i spójność scenariuszy testowych w ramach Testów Podsystemów, Testów Integracji i Testów Akceptacyjnych odpowiada Wykonawca, 5. Scenariusze testów muszą być tak przygotowane, aby testy wg scenariuszy mogły być wykonane przez osoby spoza zespołu Wykonawcy.
P2-PRO-SP-99	Zastosowana metoda przygotowania scenariuszy testowych musi pozwolić na zweryfikowanie pokrycia wymagań przez zdefiniowane przypadki testowe. W szczególności: 1. Zidentyfikowania wymagań określonych w OPZ, raz Projekcie technicznym z określonym scenariuszem który weryfikuje te wymagania. 2. Kompletność pokrycia wszystkich wymagań przez przygotowane scenariusze testów musi być wykonana przy użyciu macierzy pokrycia.
P2-PRO-SP-100	Scenariusz testowy musi zawierać: 1. Numer scenariusza – umożliwiający jego łatwą i bezbłędną identyfikację. 2. Wskazanie testowanego zakresu oraz odniesienia do dokumentacji systemu, w szczególności listę weryfikowanych wymagań Zamawiającego oraz realizowanego przypadku użycia. 3. Warunki wejściowe – lista warunków, jakie muszą być spełnione, aby można było rozpocząć wykonanie scenariusza. 4. Wskazanie potrzebnego zakresu danych testowych. 5. Zestaw przypadków testowych składających się na scenariusz. Każdy przypadek testowy musi: a. zawierać opis działań osoby realizującej przypadek testowy w postaci kolejnych kroków, ze wskazaniem danych, których należy użyć. Opis powinien być wyrażony w sposób prosty, przystępny dla osoby w ograniczonym stopniu zapoznanej z systemem, b. umożliwiać realizację scenariusza testowego w krótkim czasie, bez konieczności zapoznawania się z dokumentacją Systemu, c. przedstawiać oczekiwany wynik wykonania – opis pozwalający na jednoznaczną ocenę, czy przypadek testowy zakończył się sukcesem lub czy błędem, d. jeżeli dla sprawdzenia wyniku przypadku testowego konieczne jest wykonanie pewnej sekwencji działań, to musi być ona również opisana w postaci kolejnych kroków, 6. Klasę błędu którą należy zgłosić w przypadku wystąpienia błędu ( gdy wykonanie przypadku testowego zakończy się niepowodzeniem).
P2-PRO-SP-101	Każdy scenariusz musi cechować: 1. Prostota opisu – scenariusz powinien być opisany w sposób prosty, zrozumiały dla osoby nie znającej systemu lub zapoznanej z nim w ograniczony sposób, 2. Powtarzalność – powinno być możliwe wielokrotne wykonanie scenariusza w identyczny sposób na podstawie jego opisu, 3. Jednoznaczność – scenariusz przy spełnieniu wymagań wejściowych oraz realizacji wg opisu przypadków testowych powinien mieć ten

Identyfikator wymagania	Opis wymagania
	sam przebieg oraz identyczny wynik (z dokładnością do istotnych elementów) przy powtórzeniach realizacji scenariusza na tej samej wersji systemu, 4. Możliwość automatyzacji – w przypadku scenariuszy, w których automatyzacja jest możliwa.

3.4.2.3.2 Wymagania na Plan Testów dla wszystkich rodzajów testów

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-102	Wykonawca opracuje dla każdego rodzaju testów Plan Testów który musi być zaakceptowany przez Zamawiającego
P2-PRO-SP-103	Plan testów musi zawierać listę komponentów, które mają być przekazane przez Wykonawcę do odbioru zgodnie z zatwierdzonym harmonogramem.
P2-PRO-SP-104	Wyłączenia – Zamawiający dopuszcza, aby testy nie obejmowały wybranych elementów w zakresie i obszarze testów, jednak w takiej sytuacji, fragmenty te musza być jasno i precyzyjnie określone wraz z podaniem przyczyny, dla którego następuje wyłączenie.
P2-PRO-SP-105	Zamawiający zatwierdza wyłączenia. Brak zgody Xxxxxxxxxxxxx skutkuje koniecznością przeprowadzenia całości testów.
P2-PRO-SP-106	Wykonawca przedstawi Zamawiającemu listę narzędzi testowych planowanych do wykorzystywania podczas testowania.
P2-PRO-SP-107	Wykonawca musi uzyskać zgodę Zamawiającego na użycie narzędzia w trakcie testów.
P2-PRO-SP-108	Plan Testów musi zawierać opis struktury organizacyjnej zespołów Zamawiającego i Wykonawcy z opisem ról poszczególnych członków zespołów.
P2-PRO-SP-109	Wykonawca przedstawi Zamawiającemu skrypty testowe wykorzystywane do automatyzacji testów.
P2-PRO-SP-110	Wykonawca zobowiązany jest do określenia warunków, których spełnienie pozwala na rozpoczęcie testów.
P2-PRO-SP-111	Plan Testów musi uwzględniać zasady i harmonogram przeprowadzenia testów automatycznych.
P2-PRO-SP-112	Plan Testów musi uwzględniać zasady i zakres przeprowadzanych testów regresji.
P2-PRO-SP-113	Plan Testów musi zawierać opis procedury zbierania błędów i uwag zgłaszanych przez testerów oraz procedury nanoszenia poprawek w testowanym Podsystemie.
P2-PRO-SP-114	Wykonawca zobowiązany jest do określenia zestawu kryteriów pozwalających uznać testy za zakończone z sukcesem. Zestaw kryteriów będzie opisany w Planie Testów i podlega akceptacji Zamawiającego.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-115	Plan testów zawiera harmonogram ich realizacji, z podaniem terminu: 1. Przekazania scenariuszy testów, skryptów testów automatycznych, danych testowych. 2. Przekazania Podsystemów do przeprowadzenia testów. 3. Rozpoczęcia i zakończenia zadań testowych.
P2-PRO-SP-116	Wykaz środowisk wykorzystywanych w trakcie testów: 1. Należy zawrzeć opis ich przeznaczenia w trakcie testów. 2. Wykorzystanie środowisk zostanie zawarte w harmonogramie testów.
P2-PRO-SP-117	Plan Testów musi zawierać określenie zakresu potrzebnych danych testowych. 1. Dane testowe muszą umożliwiać realizację zaplanowanych scenariuszy testowych. 2. Powinno być możliwe zrealizowanie testów integracyjnych oraz akceptacyjnych wydania w oparciu o dane testowe wykorzystywane w ramach testów akceptacyjnych podsystemów. 3. Opis danych testowych wraz ze skryptami je tworzącymi powinien umożliwiać ich odtworzenie w razie utraty.

3.4.2.3.3 PK-15 Scenariusze testów Centralnych Usług Katalogowych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-118	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-119	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-120	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2.
P2-PRO-SP-121	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.2.3.4 PK-16 Scenariusze testów Centralnej Poczty

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-122	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-123	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-124	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2.
P2-PRO-SP-125	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.2.3.5 PK-17 Scenariusze testów Systemu Zarządzania Tożsamością

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-126	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-127	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-128	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2..
P2-PRO-SP-129	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.2.3.6 PK-18 Scenariusze testów Centrum Certyfikacji

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-130	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-131	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-132	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2.
P2-PRO-SP-133	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.2.3.7 PK-19 Scenariusze testów Centralnego Systemu Monitorowania i Zarządzania ITS.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-134	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-135	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-136	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2.
P2-PRO-SP-137	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.2.3.8 PK-20 Scenariusze testów Podsystemu Wsparcia eksploatacji i Help Desk.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-138	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-139	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-140	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2.
P2-PRO-SP-141	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.2.3.9 PK-21 Scenariusze testów integracji Podsystemów Centralnych Usług Infrastrukturalnych.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-142	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-143	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-144	Scenariusze testów muszą być opracowane wg wymagań określonych w rozdziale 3.4.2.3.2.
P2-PRO-SP-145	Opracowane scenariusze muszą umożliwić sprawdzenie podczas testowania, czy Podsystem spełnia wszystkie wymagania funkcjonalne, pozafunkcjonalne oraz wynikające z Projektów technicznych poszczególnych Podsystemów.

3.4.3 Wdrożenie Centralnych Usług Infrastrukturalnych w Środowisku Testowym

3.4.3.1 Zadanie 2.1. Konfiguracja i instalacja Centralnych Usług Infrastrukturalnych w Środowisku Testowym

3.4.3.1.1 PK-22 Plan testów Centralnych Usług Infrastrukturalnych wraz z integracją dla Środowiska Testowego

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-146	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-147	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-148	Plan Testów akceptacyjnych Podsystemów i zintegrowanego Systemu wykonany będzie zgodnie z zasadami określonymi w rozdziale 3.4.2.3.2.
P2-PRO-SP-149	W Planie Testów Wykonawca określi wszystkie narzędzia niezbędne dla przeprowadzenia testów (np. symulatory, generatory danych testowych).

3.4.3.1.2 PK-23 Konfiguracja infrastruktury techniczno-systemowej Środowiska Testowego Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-150	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-151	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-152	Wykonawca skonfiguruje ITS Środowiska Testowego na podstawie zaakceptowanego Projektu Technicznego.
P2-PRO-SP-153	Wykonawca skonfiguruje na podstawie Projektu następujące elementy ITS Środowiska: 1. Utworzenie maszyn wirtualnych dla Podsystemów (w tym instalacja systemów operacyjnych, aktywacja systemów operacyjnych, wgranie aktualizacji, instalacja systemu baza danych itp.) 2. Przydział niezbędnych przestrzeni dyskowych dla maszyn wirtualnych, baz danych. 3. Utworzenie niezbędnych sieci VLAN. 4. Skonfigurowanie urządzeń bezpieczeństwa (np. FireWall, IPS). 5. Skonfigurowanie posiadanego Systemu System Center Operations Manager. 6. Systemu backup. 7. Systemu antywirusowego. 8. Stacje robocze.

3.4.3.1.3 PK-24 Instalacja podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych w Środowisku Testowym

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-154	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-155	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-156	Wykonawca zainstaluje i skonfiguruje wg Projektu Technicznego Oprogramowanie Gotowe i/lub Dedykowane dla którego licencje dostarczy Zamawiający i/lub Wykonawca.

3.4.3.1.4 PK-25 Przeprowadzenie testów Centralnych Usług Infrastrukturalnych w Środowisku Testowym

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-157	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-158	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-159	Testy Podsystemów będą wykonane przez Zamawiającego w asyście Wykonawcy, zgodnie z zaakceptowanym przez Zamawiającego Planem Testów i Scenariuszami Testów.
P2-PRO-SP-160	Przed przeprowadzeniem testów Wykonawca przeprowadzi instruktaż dla testerów Zamawiającego.
P2-PRO-SP-161	Z przeprowadzonych testów sporządzony będzie protokół którego wzór zostanie określony w Planie Testów.

3.4.3.2 Zadanie 2.2. Opracowanie dokumentacji i procedur Centralnych Usług Infrastrukturalnych

3.4.3.2.1 PK-26 Dokumentacja administratora Usług Katalogowych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-162	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-163	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.

Identyfikator wymagania

Opis wymagania

P2-PRO-SP-164

Dokumentacja Administratora musi zawierać co najmniej: 1. Opis zastosowanej instalacji, konfiguracji i parametryzacji CUK, w tym: a. zestawienie wersji zastosowanego oprogramowania, w tym Oprogramowania Gotowego i Dedykowanego, b. zestawienie wykorzystanej infrastruktury sprzętowej oraz sieciowej, c. opis modyfikacji parametrów systemu operacyjnego, d. opis parametrów oprogramowania z podaniem: i. opisu parametru i jego znaczenia, ii. zalecanej wartości parametru, iii. wartości minimalnej i maksymalnej parametru. 2. Procedury utrzymaniowe dla CUK. 3. Procedury obsługi awarii dla CUK. 4. Procedury administracyjne dla CUK.

3.4.3.2.2 PK-27 Dokumentacja udostępniania Usług Katalogowych innym systemom

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-165	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-166	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-167	Dokumentacja będzie zawierała opis wszystkich dostępnych interfejsów dla systemów zewnętrznych.
P2-PRO-SP-168	Dokumentacja będzie zawierała procedury bezpieczeństwa związane z udostępnianiem usług dla systemów zewnętrznych.

3.4.3.2.3 PK-28 Dokumentacja administratora Poczty

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-169	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-170	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.

Identyfikator wymagania

Opis wymagania

P2-PRO-SP-171

Dokumentacja Administratora musi zawierać co najmniej: 1. Opis zastosowanej instalacji, konfiguracji i parametryzacji aplikacji, w tym: a. zestawienie wersji zastosowanego oprogramowania, w tym Oprogramowania Gotowego i Dedykowanego, b. zestawienie wykorzystanej infrastruktury sprzętowej oraz sieciowej, c. opis modyfikacji parametrów systemu operacyjnego, d. opis parametrów oprogramowania z podaniem: i. opisu parametru i jego znaczenia, ii. zalecanej wartości parametru, iii. wartości minimalnej i maksymalnej parametru. 2. Procedury utrzymaniowe dla Poczty 3. Procedury obsługi awarii dla Poczty. 4. Procedury administracyjne dla Poczty. 5. Procedury administratora lokalnego dla Poczty.

3.4.3.2.4 PK-29 Dokumentacja administratora Systemu Zarządzania Tożsamością

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-172	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-173	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-174	Dokumentacja Administratora musi zawierać co najmniej: 1. Opis zastosowanej instalacji, konfiguracji i parametryzacji aplikacji, w tym: a. zestawienie wersji zastosowanego oprogramowania, w tym Oprogramowania Gotowego i Dedykowanego, b. zestawienie wykorzystanej infrastruktury sprzętowej oraz sieciowej, c. opis modyfikacji parametrów systemu operacyjnego, d. opis parametrów oprogramowania z podaniem: i. opisu parametru i jego znaczenia, ii. zalecanej wartości parametru, iii. wartości minimalnej i maksymalnej parametru. 2. Procedury utrzymaniowe dla SZT. 3. Procedury obsługi awarii dla SZT. 4. Procedury administracyjne dla SZT.

3.4.3.2.5 PK-30 Dokumentacja użytkowania Systemu Zarządzania Tożsamością dla komórek kadrowych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-175	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-176	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-177	Na dokumentację użytkową składają się: 1. Zbiór podręczników dedykowanych dla poszczególnych grup użytkowników, 2. Pomoc kontekstowa dostępna z poziomu systemu.
P2-PRO-SP-178	Pomoc kontekstowa musi być dostępna dla użytkownika wszędzie tam, gdzie może on mieć problem z obsługą systemu. Treść, która zostanie przedstawiona użytkownikowi w momencie użycia pomocy kontekstowej musi zależeć od : 1. Roli użytkownika w systemie, 2. Rodzaju funkcji systemu z jakich korzysta użytkownik w danym momencie. Niedopuszczalne jest, aby pomoc kontekstowa odsyłała użytkownika do dokumentacji użytkownika wyrażonej w postaci podręcznika, bez wskazania właściwego, użytecznego z punktu widzenia użytkownika treści.
P2-PRO-SP-179	Podręcznik składający się na dokumentację użytkownika musi: 1. przedstawiać, w przystępny dla użytkownika sposób, realizację wszystkich procesów biznesowych, które będzie mógł realizować użytkownik danego typu. Opis ten musi się składać co najmniej z: a. określenia celu procesu, b. określenia możliwych wyników końcowych procesu, c. określenia informacji, które musi posiadać użytkownik, aby móc zrealizować proces (np. karta identyfikacyjna), 2. przedstawiać, w przystępny dla użytkownika sposób, sposób wykorzystania wszystkich funkcji systemu dostępnych dla danego typu użytkownika, 3. zawierać przedstawienie istotnych formatek ekranowych, z którymi może mieć styczność użytkownik danego typu, wraz z wyjaśnieniem ich zawartości i przeznaczenia, 4. przedstawiać wszystkie możliwości konfiguracyjne dostępne dla danego typu użytkownika (np. konfiguracja częstotliwości wysyłanych powiadomień, liczby elementów wyświetlanych na listach), 5. przedstawiać sytuacje szczególne i awaryjne, na które może natrafić użytkownik podczas użytkowania systemu, wraz z informacjami na temat dalszych kroków postępowania.
P2-PRO-SP-180	Podręcznik składający się na dokumentację użytkownika musi umożliwiać samodzielne korzystanie z systemu użytkownikowi, dla którego dany produkt jest przeznaczony.
P2-PRO-SP-181	Wykonawca opracuje Dokumentację Użytkownika dla wszystkich szczebli prokuratury.

3.4.3.2.6 PK-31 Dokumentacja użytkownika Systemu Zarządzania Tożsamością

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-182	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-183	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-184	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-185	Na dokumentację użytkową składają się: 1. zbiór podręczników dedykowanych dla poszczególnych grup użytkowników, 2. pomoc kontekstowa dostępna z poziomu systemu.
P2-PRO-SP-186	Pomoc kontekstowa musi być dostępna dla użytkownika wszędzie tam, gdzie może on mieć problem z obsługą systemu. Treść, która zostanie przedstawiona użytkownikowi w momencie użycia pomocy kontekstowej musi zależeć od tego: 1. Roli użytkownika w systemie, 2. Rodzaju funkcji systemu z jakich korzysta użytkownik w danym momencie. Niedopuszczalne jest, aby pomoc kontekstowa odsyłała użytkownika do dokumentacji użytkownika wyrażonej w postaci podręcznika, bez wskazania właściwego, użytecznego z punktu widzenia użytkownika treści.
P2-PRO-SP-187	Podręcznik składający się na dokumentację użytkownika musi: 1. przedstawiać, w przystępny dla użytkownika sposób, realizację wszystkich procesów biznesowych, które będzie mógł realizować użytkownik danego typu. Opis ten musi się składać co najmniej z: a. określenia celu procesu, b. określenia możliwych wyników końcowych procesu, c. określenia informacji, które musi posiadać użytkownik, aby móc zrealizować proces (np. karta identyfikacyjna), 2. przedstawiać, w przystępny dla użytkownika sposób, sposób wykorzystania wszystkich funkcji systemu dostępnych dla danego typu użytkownika, 3. zawierać przedstawienie istotnych formatek ekranowych, z którymi może mieć styczność użytkownik danego typu, wraz z wyjaśnieniem ich zawartości i przeznaczenia, 4. przedstawiać wszystkie możliwości konfiguracyjne dostępne dla danego typu użytkownika (np. konfiguracja częstotliwości wysyłanych powiadomień, liczby elementów wyświetlanych na listach), 5. przedstawiać sytuacje szczególne i awaryjne, na które może natrafić użytkownik podczas użytkowania systemu, wraz z informacjami na temat dalszych kroków postępowania.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-188	Podręcznik składający się na dokumentację użytkownika musi umożliwiać samodzielne korzystanie z systemu użytkownikowi, dla którego dany produkt jest przeznaczony.
P2-PRO-SP-189	Wykonawca opracuje Dokumentację Użytkownika dla wszystkich szczebli prokuratury.

3.4.3.2.7 PK-32 Dokumentacja udostępniania usług Systemu Zarządzania Tożsamością dla innych systemów

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-190	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-191	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-192	Dokumentacja będzie zawierała opis wszystkich dostępnych interfejsów dla systemów zewnętrznych.
P2-PRO-SP-193	Dokumentacja będzie zawierała procedury bezpieczeństwa związane z udostępnianiem usług dla systemów zewnętrznych.

3.4.3.2.8 PK-33 Procedury Systemu Zarządzania Tożsamością

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-194	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-195	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-196	Wykonawca opracuje co najmniej następujące procedury: 1. Zakładanie/aktualizacja tożsamości użytkowników 2. Cykl życia roli użytkownika oraz związanych z nią uprawnień 3. Wnioskowanie o uprawnienia oraz nadawanie / modyfikacje uprawnień 4. Nadawanie uprawnień w sytuacjach kryzysowych 5. Okresowa recertyfikacja uprawnień do systemu informatycznego 6. Audyt uprawnień w Środowisku informatycznym powszechnych jednostek prokuratury 7. Delegowanie uprawnień pomiędzy użytkownikami 8. Monitorowanie uprawnień w systemie informatycznym 9. Badanie zgodności posiadanych przez użytkowników systemu informatycznego uprawnień pod kątem spełnienia polityk obowiązujących w powszechnych jednostkach prokuratury. 10. Nadawanie oraz kontrolowanie uprawnień dla użytkowników uprzywilejowanych systemów informatycznych

Identyfikator wymagania	Opis wymagania
	11. Zmiany struktury organizacyjnej w powszechnych jednostkach prokuratury 12. Monitorowanie użycia uprawnień użytkowników w systemie informatycznym

3.4.3.2.9 PK-34 Dokumentacja administratora Centrum Certyfikacji

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-197	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-198	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-199	Dokumentacja Administratora musi zawierać co najmniej: 1. Opis zastosowanej instalacji, konfiguracji i parametryzacji aplikacji, w tym: a. zestawienie wersji zastosowanego oprogramowania, w tym Oprogramowania Gotowego i Dedykowanego, b. zestawienie wykorzystanej infrastruktury sprzętowej oraz sieciowej, c. opis modyfikacji parametrów systemu operacyjnego, d. opis parametrów oprogramowania z podaniem: i. opisu parametru i jego znaczenia, ii. zalecanej wartości parametru, iii. wartości minimalnej i maksymalnej parametru. 2. Procedury utrzymaniowe dla CC. 3. Procedury obsługi awarii dla CC. 4. Procedury administracyjne dla CC.

3.4.3.2.10 PK-35 Dokumentacja użytkownika Centrum Certyfikacji

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-200	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-201	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-202	Na dokumentację użytkową składają się: 1. zbiór podręczników dedykowanych dla poszczególnych grup użytkowników, 2. pomoc kontekstowa dostępna z poziomu systemu.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-203	Pomoc kontekstowa musi być dostępna dla użytkownika wszędzie tam, gdzie może on mieć problem z obsługą systemu. Treść, która zostanie przedstawiona użytkownikowi w momencie użycia pomocy kontekstowej musi zależeć od tego: 1. Roli użytkownika w systemie, 2. Rodzaju funkcji systemu z jakich korzysta użytkownik w danym momencie. Niedopuszczalne jest, aby pomoc kontekstowa odsyłała użytkownika do dokumentacji użytkownika wyrażonej w postaci podręcznika, bez wskazania właściwego, użytecznego z punktu widzenia użytkownika treści.
P2-PRO-SP-204	Podręcznik składający się na dokumentację użytkownika musi: 1. przedstawiać, w przystępny dla użytkownika sposób, realizację wszystkich procesów biznesowych, które będzie mógł realizować użytkownik danego typu. Opis ten musi się składać co najmniej z: a. określenia celu procesu, b. określenia możliwych wyników końcowych procesu, c. określenia informacji, które musi posiadać użytkownik, aby móc zrealizować proces (np. karta identyfikacyjna), 2. przedstawiać, w przystępny dla użytkownika sposób, sposób wykorzystania wszystkich funkcji systemu dostępnych dla danego typu użytkownika, 3. zawierać przedstawienie istotnych formatek ekranowych, z którymi może mieć styczność użytkownik danego typu, wraz z wyjaśnieniem ich zawartości i przeznaczenia, 4. przedstawiać wszystkie możliwości konfiguracyjne dostępne dla danego typu użytkownika (np. konfiguracja częstotliwości wysyłanych powiadomień, liczby elementów wyświetlanych na listach), 5. przedstawiać sytuacje szczególne i awaryjne, na które może natrafić użytkownik podczas użytkowania systemu, wraz z informacjami na temat dalszych kroków postępowania.
P2-PRO-SP-205	Podręcznik składający się na dokumentację użytkownika musi umożliwiać samodzielne korzystanie z systemu użytkownikowi, dla którego dany produkt jest przeznaczony.
P2-PRO-SP-206	Wykonawca opracuje Dokumentację Użytkownika dla wszystkich szczebli prokuratury.

3.4.3.2.11 PK-36 Dokumentacja udostępniania usług Centrum Certyfikacji dla innych systemów

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-207	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-208	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-209	Dokumentacja będzie zawierała opis wszystkich dostępnych interfejsów dla systemów zewnętrznych.
P2-PRO-SP-210	Dokumentacja będzie zawierała procedury bezpieczeństwa związane z udostępnianiem usług dla systemów zewnętrznych.

3.4.3.2.12 PK-37 Procedury Centrum Certyfikacji

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-211	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-212	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-213	Wykonawca opracuje minimum następujące procedury: 1. Politykę certyfikacji. 2. Procedury eksploatacyjne. 3. Procedury utrzymaniowe.

3.4.3.2.13 PK-38 Dokumentacja administratora Podsystemu Centralnego Monitorowania i Zarządzania

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-214	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-215	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.

Identyfikator wymagania

Opis wymagania

P2-PRO-SP-216

Dokumentacja Administratora musi zawierać co najmniej: 1. Opis zastosowanej instalacji, konfiguracji i parametryzacji aplikacji, w tym: a. zestawienie wersji zastosowanego oprogramowania, w tym Oprogramowania Gotowego i Dedykowanego, b. zestawienie wykorzystanej infrastruktury sprzętowej oraz sieciowej, c. opis modyfikacji parametrów systemu operacyjnego, d. opis parametrów oprogramowania z podaniem: i. opisu parametru i jego znaczenia, ii. zalecanej wartości parametru, iii. wartości minimalnej i maksymalnej parametru. 2. Procedury utrzymaniowe dla Podsystemu Centralnego Monitorowania i Zarządzania 3. Procedury obsługi awarii dla Podsystemu Centralnego Monitorowania i Zarządzania 4. Procedury administracyjne dla Podsystemu Centralnego Monitorowania i Zarządzania

3.4.3.2.14 PK-39 Dokumentacja użytkowa administratorów lokalnych Centralnego Podsystemu Monitorowania i Zarządzania

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-217	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-218	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-219	Dokumentacja użytkowa administratora lokalnego musi zawierać co najmniej: 1. Instrukcja dostępu do informacji zgromadzonej w CMDB dla podległych administratorowi jednostek prokuratury. 2. Instrukcję zdalnego dostępu do stacji roboczych. 3. Procedury administracyjne Podsystemu Centralnego Monitorowania i Zarządzania.

3.4.3.2.15 PK-40 Dokumentacja integracji Centralnego Podsystemu Monitorowania i Zarządzania z innymi systemami

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-220	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-221	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-222	Dokumentacja będzie zawierała opis wszystkich dostępnych interfejsów dla systemów zewnętrznych.
P2-PRO-SP-223	Dokumentacja będzie zawierała procedury bezpieczeństwa związane z udostępnianiem usług dla systemów zewnętrznych.

3.4.3.2.16 PK-41 Procedury Centralnego Monitorowania i Zarządzania

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-224	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-225	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-226	Wykonawca opracuje co najmniej następujące procedury: 1. Procedurę automatycznej inwentaryzacji sprzętu. 2. Procedurę automatycznej inwentaryzacji oprogramowania. 3. Procedurę automatycznej dystrybucji oprogramowania. 4. Procedurę zdalnej konfiguracji stacji roboczych. 5. Procedurę zdalnego dostępu do stacji roboczych.

3.4.3.2.17 PK-42 Dokumentacja administratora Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-227	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-228	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.

Identyfikator wymagania

Opis wymagania

P2-PRO-SP-229

Dokumentacja Administratora musi zawierać co najmniej: 1. Opis zastosowanej instalacji, konfiguracji i parametryzacji aplikacji, w tym: a. zestawienie wersji zastosowanego oprogramowania, w tym Oprogramowania Gotowego i Dedykowanego, b. zestawienie wykorzystanej infrastruktury sprzętowej oraz sieciowej, c. opis modyfikacji parametrów systemu operacyjnego, d. opis parametrów oprogramowania z podaniem: i. opisu parametru i jego znaczenia, ii. zalecanej wartości parametru, iii. wartości minimalnej i maksymalnej parametru. 2. Procedury utrzymaniowe dla Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk. 3. Procedury obsługi awarii dla Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk 4. Procedury administracyjne dla Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk.

3.4.3.2.18 PK-43 Dokumentacja użytkownika Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-230	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-231	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-232	Na dokumentację użytkową składają się: 1. zbiór podręczników dedykowanych dla poszczególnych grup użytkowników, 2. pomoc kontekstowa dostępna z poziomu systemu.
P2-PRO-SP-233	Pomoc kontekstowa musi być dostępna dla użytkownika wszędzie tam, gdzie może on mieć problem z obsługą systemu. Treść, która zostanie przedstawiona użytkownikowi w momencie użycia pomocy kontekstowej musi zależeć od tego: 1. Roli użytkownika w systemie, 2. Rodzaju funkcji systemu z jakich korzysta użytkownik w danym momencie. Niedopuszczalne jest, aby pomoc kontekstowa odsyłała użytkownika do dokumentacji użytkownika wyrażonej w postaci podręcznika, bez wskazania właściwego, użytecznego z punktu widzenia użytkownika treści.
P2-PRO-SP-234	Podręcznik składający się na dokumentację użytkownika musi:

Identyfikator wymagania	Opis wymagania
	1. przedstawiać, w przystępny dla użytkownika sposób, realizację wszystkich procesów biznesowych, które będzie mógł realizować użytkownik danego typu. Opis ten musi się składać co najmniej z: a. określenia celu procesu, b. określenia możliwych wyników końcowych procesu, c. określenia informacji, które musi posiadać użytkownik, aby móc zrealizować proces (np. karta identyfikacyjna), 2. przedstawiać, w przystępny dla użytkownika sposób, sposób wykorzystania wszystkich funkcji systemu dostępnych dla danego typu użytkownika, 3. zawierać przedstawienie istotnych formatek ekranowych, z którymi może mieć styczność użytkownik danego typu, wraz z wyjaśnieniem ich zawartości i przeznaczenia, 4. przedstawiać wszystkie możliwości konfiguracyjne dostępne dla danego typu użytkownika (np. konfiguracja częstotliwości wysyłanych powiadomień, liczby elementów wyświetlanych na listach), 5. przedstawiać sytuacje szczególne i awaryjne, na które może natrafić użytkownik podczas użytkowania systemu, wraz z informacjami na temat dalszych kroków postępowania.
P2-PRO-SP-235	Podręcznik składający się na dokumentację użytkownika musi umożliwiać samodzielne korzystanie z systemu użytkownikowi, dla którego dany produkt jest przeznaczony.
P2-PRO-SP-236	Wykonawca opracuje Dokumentację Użytkownika dla wszystkich szczebli prokuratury.

3.4.3.2.19 PK-44 Dokumentacja użytkownika Centralnego HelpDesk

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-237	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-238	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-239	Na dokumentację użytkową składają się: 1. zbiór podręczników dedykowanych dla poszczególnych grup użytkowników, 2. pomoc kontekstowa dostępna z poziomu systemu.
P2-PRO-SP-240	Pomoc kontekstowa musi być dostępna dla użytkownika wszędzie tam, gdzie może on mieć problem z obsługą systemu. Treść, która zostanie przedstawiona użytkownikowi w momencie użycia pomocy kontekstowej musi zależeć od tego: 1. Roli użytkownika w systemie, 2. Rodzaju funkcji systemu z jakich korzysta użytkownik w danym momencie.

Identyfikator wymagania	Opis wymagania
	Niedopuszczalne jest, aby pomoc kontekstowa odsyłała użytkownika do dokumentacji użytkownika wyrażonej w postaci podręcznika, bez wskazania właściwego, użytecznego z punktu widzenia użytkownika treści.
P2-PRO-SP-241	Podręcznik składający się na dokumentację użytkownika musi: 1. przedstawiać, w przystępny dla użytkownika sposób, realizację wszystkich procesów biznesowych, które będzie mógł realizować użytkownik danego typu. Opis ten musi się składać co najmniej z: a. określenia celu procesu, b. określenia możliwych wyników końcowych procesu, c. określenia informacji, które musi posiadać użytkownik, aby móc zrealizować proces (np. karta identyfikacyjna), 2. przedstawiać, w przystępny dla użytkownika sposób, sposób wykorzystania wszystkich funkcji systemu dostępnych dla danego typu użytkownika, 3. zawierać przedstawienie istotnych formatek ekranowych, z którymi może mieć styczność użytkownik danego typu, wraz z wyjaśnieniem ich zawartości i przeznaczenia, 4. przedstawiać wszystkie możliwości konfiguracyjne dostępne dla danego typu użytkownika (np. konfiguracja częstotliwości wysyłanych powiadomień, liczby elementów wyświetlanych na listach), 5. przedstawiać sytuacje szczególne i awaryjne, na które może natrafić użytkownik podczas użytkowania systemu, wraz z informacjami na temat dalszych kroków postępowania.
P2-PRO-SP-242	Podręcznik składający się na dokumentację użytkownika musi umożliwiać samodzielne korzystanie z systemu użytkownikowi, dla którego dany produkt jest przeznaczony.
P2-PRO-SP-243	Wykonawca opracuje Dokumentację Użytkownika dla wszystkich szczebli prokuratury.

3.4.3.2.20 PK-45 Dokumentacja integracji Centralnego Podsystemu Wsparcia Eksploatacji i Help Desk z innymi systemami

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-244	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-245	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-246	Dokumentacja będzie zawierała opis wszystkich dostępnych interfejsów dla systemów zewnętrznych.
P2-PRO-SP-247	Dokumentacja będzie zawierała procedury bezpieczeństwa związane z udostępnianiem usług dla systemów zewnętrznych.

3.4.3.2.21 PK-46 Procedury Podsystemu Wsparcia Eksploatacji i HelpDesk

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-248	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-249	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-250	Wykonawca opracuje minimum następujące procedury: 1. Zarządzanie zgłoszeniami z Help Desk 2. Zarządzanie incydentami 3. Zarządzanie problemami 4. Zarządzanie zasobami i konfiguracją 5. Zarządzania zdarzeniami 6. Zarządzanie zmianą 7. Zarządzanie wydaniami i wdrożeniami

3.4.4 Wdrożenie Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym

3.4.4.1 Zadanie 3.1. Opracowanie planu testów i wdrażania Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym

3.4.4.1.1 PK-47 Plan testów akceptacyjnych Centralnych Usług Infrastrukturalnych wraz z integracją na Środowisku Produkcyjnym

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-251	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-252	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-253	Plan Testów akceptacyjnych Podsystemów i zintegrowanego Systemu wykonany będzie zgodnie z zasadami określonymi w rozdziale 3.4.2.3.2.
P2-PRO-SP-254	Plan Testów będzie obejmował zasady przygotowania do przeprowadzenia testów.
P2-PRO-SP-255	W Planie Testów Wykonawca określi wszystkie narzędzia niezbędne dla przeprowadzenia testów (np. symulatory, generatory danych testowych).

3.4.4.1.2 PK-48 Plan wdrożenia Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-256	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-257	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-258	Wykonawca opracuje Plan Wdrożenia który musi być zaakceptowany przez Zamawiającego. Wdrożenie polega na zainstalowaniu i uruchomieniu w Środowisku Produkcyjnym wszystkich komponentów Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-259	Wykonawca przedstawi Zamawiającemu listę narzędzi planowanych do wykorzystywania podczas wdrożenia.
P2-PRO-SP-260	Wykonawca musi uzyskać zgodę Zamawiającego na użycie narzędzia w trakcie Wdrożenia.
P2-PRO-SP-261	Plan Wdrożenia musi zawierać opis struktury organizacyjnej zespołów Zamawiającego i Wykonawcy z opisem ról poszczególnych członków zespołów.
P2-PRO-SP-262	Wykonawca przedstawi Zamawiającemu skrypty wykorzystywane do automatyzacji procesu Wdrożenia.
P2-PRO-SP-263	Wykonawca zobowiązany jest do określenia warunków, których spełnienie pozwala na rozpoczęcie Wdrożenia.
P2-PRO-SP-264	Plan Wdrożenia Systemu musi uwzględniać zasady i harmonogram przeprowadzenia procesu Wdrożenia.

3.4.4.2 Zadanie 3.2. Przygotowanie, instalacja i konfiguracja Centralnych Usług Infrastrukturalnych

3.4.4.2.1 PK-49 Konfiguracja ITS dla potrzeb Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-265	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-266	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-267	Wykonawca skonfiguruje ITS Środowiska Produkcyjnego na podstawie zaakceptowanego Projektu Technicznego.

Identyfikator wymagania

Opis wymagania

P2-PRO-SP-268

Wykonawca skonfiguruje na podstawie Projektu następujące elementy ITS Środowiska: 1. Utworzenie maszyn wirtualnych dla Podsystemów (w tym instalacja systemów operacyjnych, aktywacja systemów operacyjnych, wgranie aktualizacji, instalacja systemu baza danych itp.) 2. Przydział niezbędnych przestrzeni dyskowych dla maszyn wirtualnych, baz danych. 3. Utworzenie niezbędnych sieci VLAN. 4. Skonfigurowanie urządzeń bezpieczeństwa (np. FireWall, IPS). 5. Skonfigurowanie posiadanego Systemu System Center Operations Manager. 6. Systemu backup. 7. Systemu antywirusowego. 8. Stacje robocze.

3.4.4.2.2 PK-50 Instalacja i konfiguracja Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych na Środowisku Produkcyjnym

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-269	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-270	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-271	Wykonawca zainstaluje i skonfiguruje wg Projektu Technicznego Oprogramowanie Gotowe i Dedykowane dla którego licencje dostarczy Zamawiający oraz Wykonawca.

3.4.4.3 Zadanie 3.3. Testy Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym

3.4.4.3.1 PK-51 Testy akceptacyjne Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych na Środowisku Produkcyjnym

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-272	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-273	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-274	Testy Podsystemów będą wykonane przez Zamawiającego w asyście Wykonawcy, zgodnie z zaakceptowanym przez Zamawiającego Planem Testów i Scenariuszami Testów.
P2-PRO-SP-275	Przed przeprowadzeniem testów Wykonawca przeprowadzi instruktaż dla testerów Zamawiającego.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-276	Z przeprowadzonych testów sporządzony będzie protokół którego wzór zostanie określony w Planie Testów.

3.4.4.3.2 PK-52 Testy akceptacyjne integracji Podsystemów wchodzących w skład Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-277	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-278	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-279	Testy Podsystemów będą wykonane przez Zamawiającego zgodnie z zaakceptowanym przez Zamawiającego Planem Testów i Scenariuszami Testów.
P2-PRO-SP-280	Przed przeprowadzeniem testów Wykonawca przeprowadzi instruktaż dla testerów Zamawiającego.
P2-PRO-SP-281	Z przeprowadzonych testów sporządzony będzie protokół którego wzór zostanie określony w Planie Testów.

3.4.4.4 Zadanie 3.4. Wdrażanie Centralnych Usług Infrastrukturalnych w Środowisku Produkcyjnym

3.4.4.4.1 PK-53 Wdrożenie produkcyjne Centralnych Usług Infrastrukturalnych.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-282	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-283	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-284	Wdrożenie produkcyjne Centralnych Usług Infrastrukturalnych przeprowadzi Wykonawca w oparciu o zatwierdzony przez Zamawiającego Plan Wdrożenia PK-56.
P2-PRO-SP-285	Wdrożenie będzie nadzorowane przez Zamawiającego.
P2-PRO-SP-286	Wykonawca przeprowadzi Wdrożenie wersji produkcyjnej we wszystkich ośrodkach POPD, OPDK, OPDR oraz OPDO wraz z przyłączonymi stacjami roboczymi i stacjami skanowania. W ramach wdrożenia Wykonawca wykona: 1. Instalację wszystkich Podsystemów w Środowisku Produkcyjnym. 2. Wprowadzenia danych konfiguracyjnych umożliwiających rozpoczęcie eksploatacji w Środowisku Produkcyjnym oraz stacjach roboczych i stacjach skanowania.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-287	Wykonawca zobowiązany będzie do szczegółowego monitorowania Zamawiającemu procesu wdrożeniowego.

3.4.4.5 Zadanie 3.5. Integracja stacji roboczych w Farmę Stacji Roboczych oraz z Usługami Infrastrukturalnymi

3.4.4.5.1 PK-54 Integracja dostarczanych w ramach postępowania POS-2.1 stacji roboczych i stacji Projektu SDA w Farmę Stacji Roboczych zintegrowanej z Centralnymi Usługami Infrastrukturalnymi

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-288	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-289	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-290	Wykonawca przeprowadzi integrację dostarczonych stacji roboczych w ramach niniejszego postepowanie oraz stacje robocze i stacje skanowania dostarczone w ramach Projekt SDA z Centralnymi Usługami Infrastrukturalnymi.
P2-PRO-SP-291	W ramach integracji nastąpi inicjalne załadowanie danymi Systemu Zarządzania Tożsamością z systemów finansowo-księgowych szczebla Prokuratury Krajowej, Prokuratur Regionalnych i Okręgowych.
P2-PRO-SP-292	W ramach zintegrowanych Centralnych Usług Infrastrukturalnych automatycznie zostaną założone konta dla każdego pracownika w Usługach Katalogowych i Centralnej Poczcie oraz zostaną wydane certyfikaty i karty mikroprocesorowe.
P2-PRO-SP-293	W ramach zintegrowanych Centralnych Usług Infrastrukturalnych Podsystem Monitorowania i Zarządzania ITS przeprowadzi automatycznie inwentaryzację dostarczonych stacji roboczych oraz stacji roboczych dostarczonych w ramach Projektu SDA. Podsystem Monitorowania i Zarządzania ITS automatycznie zasili danymi bazę CMDB Podsystemu Wspomagania Eksploatacji.

3.4.4.6 Zadanie 3.6. Przeprowadzenie Pilotażu w Środowisku Produkcyjnym

3.4.4.6.1 PK-55 Plan przeprowadzenia Pilotażu

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-294	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-295	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-296	Pilotaż zostanie przeprowadzony w jednym wybranym przez Zamawiającego regionie. Pilotażem zostaną objęte wszystkie jednostki wybranego regionu.
P2-PRO-SP-297	Pilotaż zostanie przeprowadzony na Środowisku Produkcyjnym Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-298	Podczas Pilotażu przeprowadzone będą testy wszystkich Centralnych Usług Infrastrukturalnych.
P2-PRO-SP-299	Plan przeprowadzenia Pilotażu będzie zawierał strukturę organizacyjną zespołów prowadzących Pilotaż oraz szczegółowy harmonogram.
P2-PRO-SP-300	Po przeprowadzeniu Pilotażu Wykonawca usunie wszystkie dane testowe ze Środowiska Produkcyjnego.

3.4.4.6.2 PK-56 Przeprowadzenie Pilotażu

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-301	Produkt Typu Usługa. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-302	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-303	Pilotaż zostanie przeprowadzony zgodnie z Planem przeprowadzenia Pilotażu.

3.4.4.7 Zadanie 3.7. Odbiór końcowy

3.4.4.7.1 PK-57 Dokumentacja powykonawcza integracji Podsystemów Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-304	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-305	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-306	Dokumentacja powykonawcza powinna spełniać wszystkie wymagania nałożone na Projekt Techniczny.
P2-PRO-SP-307	Projekt Techniczny Podsystemu powinien zostać zaktualizowany do postaci dokumentacji powykonawczej podsystemu w chwili przekazywania podsystemu Zamawiającemu do akceptacji.
P2-PRO-SP-308	Dokumentacja administracyjna oraz użytkowa musi być spójna z dokumentacją powykonawczą.

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-309	W szczególności dokumentacja administracyjna oraz użytkowa musi być uzgodniona w zakresie procedur i polityki bezpieczeństwa przedstawionej w dokumentacji powykonawczej.

3.4.4.7.2 PK-58 Dokumentacja powykonawcza infrastruktury techniczno-systemowej dla Centralnych Usług Infrastrukturalnych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-310	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-311	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-312	Dokumentacja powykonawcza powinna spełniać wszystkie wymagania nałożone na Projekt Techniczny.
P2-PRO-SP-313	Projekt Techniczny Podsystemu powinien zostać zaktualizowany do postaci dokumentacji powykonawczej podsystemu w chwili przekazywania podsystemu Zamawiającemu do akceptacji.
P2-PRO-SP-314	Dokumentacja administracyjna oraz użytkowa musi być spójna z dokumentacją powykonawczą.
P2-PRO-SP-315	W szczególności dokumentacja administracyjna oraz użytkowa musi być uzgodniona w zakresie procedur i polityki bezpieczeństwa przedstawionej w dokumentacji powykonawczej.

3.4.4.7.3 PK-59 Dokumentacja powykonawcza Centralnych Usług Katalogowych

Identyfikator wymagania	Opis wymagania
P2-PRO-SP-316	Produkt Typu Dokument, opracowany zgodnie z przyjętymi szablonami określonymi w DIP. Produkt podlega procedurze akceptacji opisanej w § 7 Umowy.
P2-PRO-SP-317	Wykonawca dla Produktu opracuje Kartę Produktu wg wzoru, który zostanie załączony do DIP.
P2-PRO-SP-318	Dokumentacja powykonawcza powinna spełniać wszystkie wymagania nałożone na Projekt Techniczny.
P2-PRO-SP-319	Projekt Techniczny Podsystemu powinien zostać zaktualizowany do postaci dokumentacji powykonawczej podsystemu w chwili przekazywania podsystemu Zamawiającemu do akceptacji.
P2-PRO-SP-320	Dokumentacja administracyjna oraz użytkowa musi być spójna z dokumentacją powykonawczą.
P2-PRO-SP-321	W szczególności dokumentacja administracyjna oraz użytkowa musi być uzgodniona w zakresie procedur i polityki bezpieczeństwa przedstawionej w dokumentacji powykonawczej.