Opis przedmiotu zamówienia (OPZ)

Sygnatura postępowania BZP/126/DB/2016
Załącznik nr 1 do SIWZ
Opis przedmiotu zamówienia (OPZ)
1. Definicje:
1.1. System IDM/System - System Zarządzania Tożsamością oparty na NetIQ w wersji 4.5. lub
wyższej wraz z interfejsem dla użytkowników tj. kompletem aplikacji użytkowników
(IDMProv, Dash, itd).
1.2. Ilekroć w niniejszym dokumencie pojawią się wskazane terminy będą one ZAWSZE
interpretowane zgodnie z poniższymi regułami. Stosunek powinności wymagań
przedstawionych w niniejszym dokumencie określony jest zgodnie z interpretacją
przedstawioną w RFC 2119:
1.2.1. Terminy MUSI, WYMAGANY lub NIE MOŻE, ZABRONIONE oznaczają, że treść
zapisu musi być bezwzględnie przestrzegana (RFC 2119: MUST, REQUIRED, SHALL).
2. Na wykonanie wdrożenia Zamawiający przeznacza następujące zasoby:
2.1. Infrastrukturalne:
REPORTING
USERAPP
IDM (NDS)
Komponent
Typ zasobu
Test
Produkcja
CPU
4 x vCPU
4 x vCPU
RAM
8 GB
8 GB
Dysk
40 GB
40 GB
CPU
4 x vCPU
4 x vCPU
RAM
8 GB
8 GB
Dysk
20 GB
20 GB
CPU
4 x vCPU
4 x vCPU
RAM
8 GB
8 GB
1
Dysk
10 GB
10 GB na dysku z możliwością rozwoju do 100GB
2.2. Systemy operacyjne
2.2.1. Red Hat Enterprise Linux dla środowisk testowych.
3. W przypadku gdy przeznaczone zasoby będą niewystarczające, Wykonawca, w ramach
wynagrodzenia za wdrożenie Systemu, rozbuduje lub dostarczy niezbędną infrastrukturę oraz
licencje wraz z licencjami utrzymaniowymi przy czym koniec okresu okres utrzymania dla
licencji MUSI przypadać na 06.czerwca w roku po zakończeniu wdrożenia Systemu opisanego
w pkt 4.1 – Zamawiający ma na celu wyrównanie terminów obowiązywania licencji na całe
oprogramowanie wchodzące w skład Systemu.
4. Przedmiot umowy:
4.1. Zaprojektowanie i wdrożenie Systemu Zarządzania Tożsamością zwanego dalej Systemem
opartego na oprogramowaniu NetIQ w wersji 4.5.x (lista posiadanych licencji stanowi
załącznik 1) wraz ze Wsparciem na okres 12 miesięcy (z możliwością przedłużenia
Wsparcia dwukrotnie o następne 12 miesięcy – w wyniku skorzystania przez
Zamawiającego z prawa opcji, opisanego szczegółowo w Załączniku nr 2 do SIWZ –
stanowiącym wzór umowy), zwanej dalej Usługą. W ramach realizacji przedmiotu
zamówienia Wykonawca zobowiązany będzie do wykonania następującego zakresu prac:
4.1.1. Wykonanie analizy bieżącego Systemu w zakresie funkcjonalności biznesowych
przenoszonych do nowego Systemu oraz opracowanie Projektu funkcjonalnego i
Projektu technicznego dla nowej instalacji uwzględniającej implementację modelu
RBAC (ang. role-based access control, kontrola dostępu oparta na rolach) do
zarządzania uprawnieniami do systemów informatycznych. Projekt funkcjonalny
obejmować musi architekturę logiczną Systemu i dokumentację funkcjonalności
biznesowej realizowanej w nowym Systemie. Projekt techniczny obejmować musi
architekturę techniczną Systemu oraz opis sposobu realizacji funkcjonalności
biznesowej opisanej w Projekcie Funkcjonalnym.
4.1.2. Przygotowanie w uzgodnieniu z Zamawiającym wymagań dotyczących konfiguracji
infrastruktury, na której zostaną zainstalowane środowisko testowe oraz
środowisko produkcyjne nowego systemu IDM (przy czym środowisko
produkcyjne MUSI zapewnić wysoką dostępność w oparciu o zwielokrotnienie
kluczowych komponentów systemu i wyeliminowanie pojedynczych punktów
awarii).
4.1.3. Przygotowanie w uzgodnieniu z Zamawiającym planu testów oraz propozycji
scenariuszy testowych
4.1.4. Wsparcie Zamawiającego przy instalacji oprogramowania systemu IDM w
środowisku testowym wraz z najnowszymi dostępnymi poprawkami producenta
oprogramowania,
4.1.5. Parametryzacja Systemu na środowisku testowym zgodnie z wymaganiami
Zamawiającego przedstawionymi w punkcie 5 oraz ustaleniami zapisanymi w
dokumentacji projektowej
4.1.6. Przygotowanie planu migracji danych z obecnego środowiska
2
4.2.
4.3.
4.4.
4.5.
4.1.7. Wykonanie pełnej inicjalizacji systemu oraz migracja danych z obecnego
środowiska na nowe środowisko testowe. Migracja obejmować MUSI:
4.1.7.1.
Skopiowanie wszystkich obiektów tożsamości, struktury organizacyjnej, grup,
ról i zasobów
4.1.7.2.
Utworzenie ról poziomu 10 dla zasobów nie przypisanych do ról i przypisanie
im właściwych zasobów oraz przeniesienie na nie danych zasobów (opis,
nazwa, właściciel itp.).
4.1.7.3.
Przeniesienie powiązań między obiektami. W przypadku przypisań
użytkownikom zasobów, które w starym systemie nie miały ról konwersja
relacji użytkownik – zasób na relację użytkownik rola.
4.1.8. Skopiowanie wszystkich obiektów tożsamości, struktury organizacyjnej, grup, ról i
zasobów
4.1.9. Wykonanie pełnych testów funkcjonalnych, integracyjnych i wydajnościowych
4.1.10. Przeprowadzenie instruktażu dla administratorów Systemu w formie warsztatów
w wymiarze co najmniej 5 dni roboczych (8 godzin zegarowych od poniedziałku do
piątku, z wyłączeniem dni wolnych, w godzinach 7:00-18:00), poza siedzibą
Zamawiającego, na terenie Warszawy.
4.1.11. Wsparcie Zamawiającego przy instalacji i konfiguracji środowiska produkcyjnego
zlokalizowanego w dwóch ośrodkach w Warszawie.
4.1.12. Wykonanie pełnej inicjalizacji Systemu i przeniesienia parametryzacji ze
środowiska testowego oraz migracja danych z obecnego środowiska
produkcyjnego na nowe środowisko produkcyjne.
4.1.13. Wykonanie i dostarczenie dokumentacji, o standardach określonych w załączniku
nr 2.
4.1.14. Objęcie Systemu 90 dniowym Okresem Stabilizacji – stanowiącym okres
monitoringu pracy Systemu przez Wykonawcę oraz Zamawiającego bezpośrednio
po wdrożeniu Produkcyjnym Systemu. W ramach którego, Zamawiający wraz z
Wykonawcą będzie badał działanie Systemu. W trakcie trwania Okresu Stabilizacji,
Wykonawca będzie ułatwiał użytkownikom oraz Administratorom wdrożenie się
do pracy w Systemie, udzielał informacji na temat działania Systemu oraz
infrastruktury a także usuwał nieprawidłowości w działaniu systemu.
Dostawa pakietów utrzymaniowych dla sterownika JDBC na okres do 06.06.2018 r.
zgodnie z obowiązującymi u producenta zasadami licencjonowania.
Dostawa innych licencji NetIQ wraz z licencjami utrzymaniowymi, jeśli Wykonawca uważa,
że są one konieczne do zrealizowania wymaganej funkcjonalności, przy czym koniec
okresu okres utrzymania dla licencji MUSI przypadać na 06.czerwca w roku po
zakończeniu wdrożenia Systemu opisanego w pkt 4.1.
Realizacja bieżących prac utrzymaniowych dla istniejącego Systemu Zarządzania
Tożsamością w wersji 4.0.x w wymiarze nie więcej niż 20 osobodni w okresie
obowiązywania Umowy, polegająca na usuwaniu zidentyfikowanych błędów w działaniu
aktualnie posiadanego przez Zamawiającego Systemu Zarządzania Tożsamością w
terminie do 5 Dni roboczych od chwili zgłoszenia przez Zamawiającego potrzeby wsparcia.
Termin wdrożenia Systemu zgodny będzie z zaoferowanym przez Wykonawcę w treści
złożonej przez niego oferty, z zastrzeżeniem, że nie może być krótszy niż 9 miesięcy ani
dłuższy niż 12 miesięcy.
3
5. Opis sposobu parametryzacji systemu:
5.1. W ramach wdrożenia Zamawiający wymaga dostarczenia wszystkich podstawowych
funkcji Systemu IDM dostępnych z tzw. ”pudełka” w ramach licencji NetIQ IDM 4.5
posiadanych przez Zamawiającego oraz odtworzenia funkcjonalności biznesowej i
integracji realizowanych przez obecnie eksploatowany Systemu Zarządzania Tożsamością
oparty o oprogramowanie NetIQ IDM w wersji 4.0.2.
5.2. Dodatkowo Zamawiający wymaga wdrożenia funkcjonalności wskazanych w pkt. 5.3 - 5.8,
przy czym procesy opisane w pkt. 5.4 MUSZĄ być obsługiwane przez System IDM i MUSZĄ
być inicjowane automatycznie w reakcji na zdarzenie pochodzące z systemu kadrowego
lub innego źródła informacji lub ręcznie przez uprawnionego operatora/użytkownika
Systemu IDM.
5.3. System MUSI zapewniać procesy sterowane danymi we wszystkich procesach
automatycznych i interaktywnych tj. sposób procedowania musi wynikać z danych
Systemu np. zmiana sposobu obsługi wniosku o nadanie uprawnienia A użytkownikowi B
wymagać powinna zmiany danych uprawnienia A lub danych użytkownika B zgodnie z
funkcjonalnością procesu.
5.4. Procesy cyklu życia tożsamości wymagane do zaimplementowania w Systemie Zarządzania
Tożsamością:
5.4.1. Zatrudnienie
5.4.1.1. System MUSI przechowywać historię pracowników.
5.4.1.2. W przypadku ponownego zatrudnienia System MUSI wykorzystywać istniejąca
tożsamość.
5.4.1.3. Proces zatrudnienia MUSI być realizowany w odpowiedni sposób w zależności
od typu tożsamości
5.4.1.3.1. Pracownik
5.4.1.3.1.1. System MUSI umożliwiać rejestrację pracownika z różnych źródeł:
system kadrowy, wprowadzenie danych ręcznie w interfejsie
użytkownika lub inny zintegrowany system informatyczny;
5.4.1.3.1.2. Niezależnie od źródła wprowadzenia zatrudnienia System MUSI
realizować taki sam proces inicjalnego nadania uprawnień oraz
przygotowania stanowiska pracy;
5.4.1.3.1.3. W przypadku ręcznej rejestracji pracownika System MUSI
pilnować
terminu
wygaśnięcia
umowy,
powiadamiać
zainteresowane osoby przed zwolnieniem oraz w dacie
zwolnienia, a także samoczynnie obsługiwać proces zwolnienia z
datą wygaśnięcia umowy.
5.4.1.3.1.4. Proces obsługi zatrudnienia MUSI nadawać automatycznie
uprawnienia standardowe (wynikające z przypisania pracownika w
strukturze organizacyjnej na konkretnym stanowisku) zgodnie z
danymi Systemu oraz umożliwiać wybór przez przełożonego
opcjonalnych uprawnień, charakterystycznych dla położenia
pracownika w strukturze organizacyjnej.
5.4.1.3.1.5. Proces akceptacji MUSI być zgodny z procesem organizacyjnym
Banku.
5.4.1.3.2. Umowa cywilnoprawna
4
5.4.1.3.2.1. System MUSI umożliwiać rejestrację współpracownika z różnych
źródeł: system kadrowy,
system ewidencji umów
cywilnoprawnych, wprowadzenie danych ręcznie w interfejsie
użytkownika lub przez inne wskazane źródła
5.4.1.3.2.2. Niezależnie od źródła wprowadzenia zatrudnienia System MUSI
realizować taki sam proces inicjalnego nadania uprawnień oraz
przygotowania stanowiska pracy;
5.4.1.3.2.3. W przypadku rejestracji ręcznej współpracownika System MUSI
pilnować
terminu
wygaśnięcia
umowy,
powiadamiać
zainteresowane osoby przed zwolnieniem oraz w dacie
zwolnienia, a także obsługiwać proces zwolnienia z datą
wygaśnięcia umowy.
5.4.1.3.2.4. Proces obsługi zatrudnienia MUSI umożliwiać wybór uprawnień
spośród uprawnień standardowych (wynikające z przypisania
współpracownika w strukturze organizacyjnej na konkretnym
stanowisku) oraz umożliwiać wybór przez przełożonego
opcjonalnych uprawnień, charakterystycznych dla położenia
pracownika w strukturze organizacyjnej.
5.4.1.3.2.5. Proces akceptacji MUSI być zgodny z procesem organizacyjnym
Banku.
5.4.1.3.3. Konsultanci zewnętrzni
5.4.1.3.3.1. System MUSI umożliwiać rejestrację konsultanta zewnętrznego;
5.4.1.3.3.2. System MUSI umożliwiać dowolnej osobie, posiadającej
adekwatne uprawnienia w Systemie, wnioskowanie o rejestrację
konsultanta zewnętrznego oraz umożliwiać pełną obsługę
uprawnień takiej osoby.
5.4.1.3.3.3. Proces obsługi rejestracji konsultanta zewnętrznego MUSI być zgodny
z procesem organizacyjnym Banku.
5.4.1.3.3.4. Pracownicy bez dostępu do zasobów informatycznych
5.4.1.3.3.5. System
MUSI
umożliwiać
przechowywanie
tożsamości
pracowników nie posiadających dostępu do systemów
informatycznych w sposób nie powodujący konsumowania
licencji;
5.4.1.3.4. Przywrócenie pracownika
5.4.1.3.4.1. System MUSI obsługiwać proces powrotu zwolnionego
pracownika, proces nadawania uprawnień MUSI być analogiczny
jak dla nowozatrudnionego pracownika.
5.4.1.3.4.2. Okres w jakim możliwe jest przywrócenie pracownika MUSI być
możliwy do konfiguracji przez administratora Systemu.
5.4.2. Zwolnienie
5.4.2.1. Standardowe zwolnienie
5.4.2.1.1. System MUSI obsługiwać proces zwolnienia pracownika.
5.4.2.1.2. System MUSI pobierać zdarzenie zwolnienie pracownika z systemu
kadrowego lub innych wskazanych źródeł oraz umożliwić ręczne
wprowadzanie takiego zdarzenia.
5
5.4.2.1.3.
W procesie zwolnienia pracownika System MUSI odebrać
użytkownikowi wszystkie uprawnienia oraz usunąć wskazane dane
kont z systemów zarządzanych.
5.4.2.1.4. System MUSI zarządzać właścicielstwem obiektów i zapobiegać ich
osieroceniu w przypadku odejścia pracownika (automatyczne
przepisanie własności obiektów i opieki na pracownikami spoza
systemu kadrowego na zastępcę lub wysłanie powiadomień w
przypadku braku zastępców)
5.4.2.1.5. System MUSI umożliwiać wprowadzanie przez administratora
konfiguracji, która spowoduje odebranie uprawnień z chwilą
zwolnienia lub po określonym czasie
5.4.2.2. Zwolnienie z wcześniejszym zakończeniem świadczenia pracy
5.4.2.2.1. System
MUSI
obsługiwać
zwolnienie
pracownika
z wcześniejszym zakończeniem świadczenia pracy.
5.4.2.2.2. W przypadku zwolnienia pracownika z obowiązku świadczenia pracy
System MUSI zablokować dostęp pracownika do wszystkich systemów
informatycznych Banku z chwilą zakończenia świadczenia pracy.
5.4.2.2.3. Po zakończeniu współpracy System MUSI w sposób automatyczny
odebrać użytkownikowi wszystkie uprawnienia oraz usunąć wskazane
dane kont z systemów zarządzanych.
5.4.2.2.4. System MUSI zarządzać właścicielstwem obiektów i zapobiegać ich
osieroceniu w przypadku odejścia pracownika (automatyczne
przepisanie własności obiektów i opieki na pracownikami spoza
systemu kadrowego na zastępcę a w przypadku braku zastępców
wysłanie powiadomień)
5.4.2.2.5. Odebranie uprawnień MUSI nastąpić z chwilą zwolnienia lub być
odroczone w czasie zgodnie z konfiguracją procesu zwolnienia
z wcześniejszym zakończeniem świadczenia pracy.
5.4.2.3. Zwolnienie natychmiastowe
5.4.2.3.1. System MUSI obsługiwać proces natychmiastowego zwolnienia
pracownika
(np.
zwolnienie
dyscyplinarne)
inicjowane
w Systemie lub pobierane z dowolnie wskazanego źródła.
5.4.2.3.2. W przypadku natychmiastowego zwolnienia pracownika (np.
zwolnienie dyscyplinarne) System MUSI bezzwłocznie zablokować
dostęp pracownika do wszystkich systemów informatycznych.
5.4.2.3.3. System MUSI zarządzać właścicielstwem obiektów i zapobiegać ich
osieroceniu w przypadku odejścia pracownika (automatyczne
przepisanie własności obiektów i opieki na pracownikami spoza
systemu kadrowego na zastępcę lub wysłanie powiadomień w
przypadku braku zastępców)
5.4.2.3.4. Po zakończeniu współpracy należy odebrać użytkownikowi wszystkie
uprawnienia
oraz
usunąć
wskazane
dane
kont
z systemów zarządzanych.
5.4.2.3.5. Odebranie uprawnień MUSI nastąpić z chwilą zwolnienia lub być
odroczone w czasie zgodnie z konfiguracją procesu zwolnienia
natychmiastowego.
6
5.4.3. Blokada pracownika
5.4.3.1. System MUSI obsługiwać proces natychmiastowego zablokowania pracownika
(np.
w
związku
z
podejrzeniem
fraudu)
inicjowane
w Systemie lub pobierane z dowolnie wskazanego źródła np. zintegrowanego
systemu SIEM.
5.4.3.2. W ramach procesu
System MUSI bezzwłocznie zablokować dostęp
pracownika do wszystkich systemów informatycznych oraz uniemożliwić
odblokowanie tożsamości pracownika (ręczne lub automatyczne) do czasu
zdjęcia blokady.
5.4.3.3. System MUSI zarządzać właścicielstwem obiektów i zapobiegać ich
osieroceniu w przypadku zablokowania pracownika (automatyczne
przepisanie własności obiektów i opieki na pracownikami spoza systemu
kadrowego na zastępcę lub wysłanie powiadomień w przypadku braku
zastępców)
5.4.3.4. Zdjęcie blokady MUSI być obsługiwane jako interaktywny proces akceptacyjny
zgodny z procesem organizacyjnym Zamawiającego.
5.4.4. Zmiana danych osobowych
5.4.4.1. System MUSI umożliwiać obsługę zmian danych osobowych w tym:
5.4.4.1.1. Automatyczną synchronizację zmian do systemów zintegrowanych w
trybie RW (odczyt i zapis).
5.4.4.1.2. Automatyczną aktualizację w systemach zarządzanych atrybutów
wyliczanych z atrybutów zmienionych np. po zmianie nazwiska
zmianie powinna ulec pełna nazwa w formie „Imię Nazwisko”
5.4.4.1.3. Powiadomienie administratora systemu zintegrowanego w trybie
tylko do odczytu o konieczności zmiany danych poprzez email, zadanie
manualne workflow lub zgłoszenie Service Desk (do ustalenia na
etapie realizacji)
5.4.5. Przesunięcie organizacyjne:
5.4.5.1. System MUSI obsługiwać przesunięcie organizacyjne pracownika rozumiane
jako zmianę jednostki organizacyjnej do której przynależy pracownik.
5.4.5.2. System MUSI jednakowo reagować na przesunięcie organizacyjne
wprowadzone ręcznie jak i pochodzące z systemu kadrowego lub innego
wskazanego źródła.
5.4.5.3. W wyniku zmiany jednostki System MUSI:
5.4.5.3.1. odebrać dotychczasowe uprawnienia nadane automatycznie
(wynikające ze stanowiska w ramach struktury organizacyjnej)
5.4.5.3.2. nadać automatycznie nowe uprawnienia standardowe (wynikające
z przypisania pracownika w strukturze organizacyjnej na konkretnym
stanowisku) zgodnie z danymi Systemu
5.4.5.3.3. umożliwić wybór przez przełożonego opcjonalnych uprawnień,
charakterystycznych dla położenia pracownika w strukturze
organizacyjnej
5.4.5.3.4. wymusić proces przeglądu uprawnień użytkownika nadanych na
podstawie wniosków zgodny z procedurami Banku
5.4.6. Awans
7
5.4.6.1. System MUSI obsługiwać awans rozumiany jako zmiana stanowiska
pracownika przy zachowaniu przypisania organizacyjnego
5.4.6.2. System MUSI jednakowo reagować na awans wprowadzony ręcznie jak i
pochodzący z systemu kadrowego lub innego wskazanego źródła.
5.4.6.3. Proces obsługi awansu obejmować MUSI:
5.4.6.3.1. aktualizację uprawnień nadanych automatycznie (wynikających ze
stanowiska w ramach struktury organizacyjnej)
5.4.6.3.2. proces przeglądu uprawnień użytkownika nadanych na podstawie
wniosków zgodny z procedurami Banku
5.4.7. Oddelegowanie
5.4.7.1. System MUSI obsługiwać oddelegowanie rozumiane jako tymczasowa
obecność pracownika w 2 jednostkach organizacyjnych.
5.4.7.2. System MUSI jednakowo reagować na oddelegowanie wprowadzone ręcznie
jak i pochodzące z systemu kadrowego lub innego wskazanego źródła.
5.4.7.3. W ramach obsługi oddelegowania System MUSI zapewnić następujące
funkcje:
5.4.7.3.1. osoba
oddelegowana
podlega
tymczasowo
przełożonemu
wynikającemu z oddelegowania
5.4.7.3.2. Osoba oddelegowana posiada dodatkowe uprawnienia wynikające z
obecnego miejsca pracy
5.4.7.3.3. Z końcem oddelegowania należy wykonać przegląd uprawnień
pracownika zgodnie z procedurami Banku
5.4.8. Nieobecność
5.4.8.1. System MUSI pobierać dane o nieobecności użytkownika z systemu
kadrowego lub innych wskazanych źródeł lub umożliwiać ręczne
wprowadzenie nieobecności.
5.4.8.2. System MUSI rozróżniać typ nieobecności pracownika (choroba, urlop,
nieobecność długotrwała itp.) na podstawie danych systemu kadrowego lub
innych źródeł a także umożliwić wprowadzenie tych danych ręcznie.
5.4.8.3. W przypadku długotrwałej nieobecności System MUSI zablokować dostępy
użytkownika.
5.4.8.4. Po zakończeniu długotrwałej nieobecności odblokowanie dostępów
użytkownika MUSI podlegać procesowi akceptacji zgodnie z procedurami
Banku.
5.4.9. Zastępstwo
5.4.9.1. System MUSI obsługiwać zastępstwa czyli wykonywanie obowiązków
pracownika podczas jego nieobecności przez inną osobę.
5.4.9.2. System MUSI umożliwiać wprowadzenie zastępstw ręcznie jak i pobranie
informacji z systemu kadrowego lub innego wskazanego źródła
5.4.9.3. Podczas zastępstwa System MUSI umożliwiać obsługę procesu zastępstwa w
formie czasowego przydziału części lub całości uprawnień biznesowych
zastępowanego pracownika zastępcy
5.5. Zarządzanie uprawnieniami
5.5.1. System MUSI posiadać zaimplementowany hierarchiczny model ról zgodny z
procedurami Banku.
8
5.5.2. System MUSI umożliwiać zarządzanie uprawnieniami w systemach nie
zintegrowanych na zasadzie obsługi procesów nadawania, odbierania i przeglądu
uprawnień i zlecania zadań realizacji wyników procesu do systemu Service Desk.
5.5.3. Nadanie uprawnień
5.5.3.1. System MUSI umożliwiać
automatyczne nadawanie uprawnień
w oparciu o zdefiniowane reguły organizacyjne jak i nadawanie uprawnień
poprzez wnioskowanie.
5.5.3.2. System MUSI posiadać możliwość tworzenia i modyfikacji przez administratora
reguł automatycznego przydziału uprawnień.
5.5.3.3. System MUSI umożliwiać wnioskowanie o nadanie uprawnień przez
użytkownika jak i uprawnione osoby dla użytkownika.
5.5.3.4. System MUSI umożliwiać wnioskowanie o nadanie uprawnień dla użytkownika
przez przełożonego innych niż wynikające z zakresu obowiązków w formie
wyjątków.
5.5.3.5. W przypadku nadawania uprawnień poprzez proces wnioskowania kroki
akceptacyjne procesu muszą być dostosowane do charakteru wnioskowanego
uprawnienia zgodnie z procedurami biznesowymi.
5.5.3.6. System MUSI umożliwiać prostą, administracyjną zmianę procesu
akceptacyjnego dla każdego z uprawnień poprzez modyfikację cech
uprawnienia lub użytkownika.
5.5.4. Odebranie uprawnień
5.5.4.1. System MUSI automatycznie odbierać uprawnienia nadane automatycznie po
wygaśnięciu kryteriów przypisania uprawnienia.
5.5.4.2. System MUSI umożliwiać wnioskowanie o odbieranie uprawnień przez
użytkownika jak i uprawnione osoby.
5.5.4.3. Proces akceptacji wniosku MUSI być zgodny z procesem organizacyjnym
Banku
5.5.5. Przegląd uprawnień
5.5.5.1. System MUSI realizować procesy przeglądu uprawnień zgodne
z procesem biznesowym Banku
5.5.5.2. Przegląd uprawnień MUSI być uruchamiany automatycznie okresowo oraz w
reakcji na zdarzenia kadrowe (np. awans, przesunięcie kadrowe)
5.5.6. Uprawnienia niestandardowe
5.5.6.1. System MUSI obsługiwać uprawnienia niestandardowe czyli uprawnienia
wymagające dodatkowych informacji do efektywnego wykorzystania (np.
limity kwotowe)
5.5.6.2. System MUSI obsługiwać nieaddytywne uprawnienia zawierające się w sobie
oraz przydzielać w systemach zarządzanych efektywne uprawnienie (np. dla
uprawnień nakładających restrykcje dla użytkownika)
5.5.6.3. System MUSI zapewnić obsługę uprawnień wymagających warunku
wstępnego np. dla otrzymania wybranych ról wymagane jest posiadanie
uprawnienia „Upoważnienie do przetwarzania danych osobowych”.
5.5.6.4. W przypadku wniosku o uprawnienie wymagające z innych uprawnień System
MUSI automatycznie inicjować wniosek o nadanie uprawnienia wymaganego,
przy czym proces ten musi być zgodny z obowiązującymi u Zamawiającego
9
zasadami nadawania uprawnień i kontynuować proces nadania uprawnienia
pierwotnie wnioskowanego po wypełnieniu wszystkich warunków wstępnych.
5.6. Zarządzanie strukturą organizacyjną
5.6.1. System MUSI zarządzać struktura organizacyjną w zakresie niezbędnym do
prawidłowego
działania
procesów
zarządzania
tożsamością
i uprawnieniami
5.6.2. Struktura
organizacyjna
w
Systemie
MUSI
być
przechowywana
z uwzględnieniem relacji hierarchicznych
5.6.3. Struktura organizacyjna MUSI być pobierana z systemu kadrowego, innego
wskazanego źródła oraz MUSI istnieć możliwość wprowadzania ręcznego
5.6.4. System MUSI kontrolować prawidłowość struktury organizacyjnej (np.
weryfikować czy przełożony jednostki istnieje i pracuje) i powiadamiać
o wykrytych nieprawidłowościach.
5.6.5. System MUSI powiadamiać wskazane osoby o zmianach struktury organizacyjnej
5.7. Integracja z systemami:
5.7.1. Integracja RO (tylko odczyt)
5.7.1.1. System MUSI zapewniać mechanizm integracji w trybie tylko do odczytu z
wykorzystaniem widoków dostarczanych przez systemy eksploatowane przez
Zamawiającego (przy wykorzystaniu licencji JDBC posiadanych przez
Zamawiającego) przy czym techniczna możliwość integracji zostanie
uzgodniona z Wykonawcą.
5.7.1.2. W ramach integracji System MUSI obsługiwać:
5.7.1.3. Pobieranie kont, katalogu uprawnień oraz powiązań uprawnień i kont
5.7.1.4. Automatyczne tworzenie katalogu ról poziomu 10 dla wskazanego zakresu
uprawnień integrowanego systemu
5.7.1.5. Zakres zarządzanych obiektów (kont i uprawnień) MUSI być konfigurowalny za
pomocą parametrów ustawianych przez Administratora Systemu IDM. Zmiana
konfiguracji NIE MOŻE powodować konieczności modyfikacji polityk
sterownika.
5.7.1.6. Przekazywanie do administratora/operatora systemu zleceń wykonania zmian
w przypadku konieczności modyfikacji kont/uprawnień w systemie
zintegrowanym
5.7.2. Integracja RW (zapis i odczyt)
5.7.2.1. System MUSI zapewniać integrację w trybie odczytu i zapisu z następującymi
systemami docelowymi
5.7.2.1.1. Active Directory wersja 2012 R2
5.7.2.1.2. Oracle Directory Server Enterprise Edition wersja. 11.1.1.7.
5.7.2.1.3. Ferryt Enterprise
5.7.2.1.4. Def3000/TR (po potwierdzeniu możliwości integracji z dostawcą
systemu Def3000/TR)
5.7.2.1.5. Systemem kadrowym (system aktualnie na etapie wdrażania „enova
wer. 11.5.0. baza MS SQL wersja 2014 ”)
5.7.2.2. W ramach integracji System MUSI obsługiwać
5.7.2.2.1. Pobieranie kont, katalogu uprawnień oraz powiązań uprawnień i kont
5.7.2.2.2. Automatyczne tworzenie katalogu ról poziomu 10 dla wskazanego
zakresu uprawnień integrowanego systemu
10
5.7.2.2.3.
5.7.2.2.4.
5.7.2.2.5.
5.7.2.2.6.
Tworzenie kont,
Modyfikację atrybutów kont po zmianie danych tożsamości
Nadawanie i odbieranie uprawnień
Zakres zarządzanych obiektów (kont i uprawnień) MUSI być
konfigurowalny za pomocą parametrów ustawianych przez
Administratora Systemu IDM. Zmiana konfiguracji NIE MOŻE
powodować konieczności modyfikacji polityk sterownika.
5.8. Pozostałe wymagania
5.8.1. System MUSI posiadać dedykowane procesy akceptacyjne umożliwiające
zarządzanie firmowymi kartami kredytowymi (przypisanie, blokada) z obsługą
dodatkowych parametrów karty (nr karty, limity, identyfikatory konta). Przebieg
procesu akceptacji musi być zgodny z procesem biznesowym Zamawiającego.
5.8.2. System MUSI posiadać skonfigurowane dedykowane formatki/procesy
umożliwiające uprawnionym osobom edycję danych przechowywanych w
Systemie, zakres edycji zostanie określony na etapie analizy przedwdrożeniowej:
5.8.3. System MUSI być przygotowany na obsługę zatrudnienia pracownika na
podstawie więcej niż jednej aktywnej umowy o pracę a w szczególności System
MUSI:
5.8.3.1. wykorzystywać pojedynczą tożsamość niezależnie od liczby równoległych
zatrudnień pracownika
5.8.3.2. Rejestrować wszystkie zatrudnienia pracownika wraz z ich danymi
organizacyjnymi
5.8.3.3. Zapewniać kontrolę nad danymi przekazywanymi do systemów zarządzanych
5.8.3.4. Umożliwiać przypisanie do jednej tożsamości uprawnień wynikających z więcej
niż tylko jednej formy zatrudnienia
z rozróżnieniem umowy, do której odnoszą się uprawnienia
5.8.4. System MUSI współpracować z istniejącym w Banku systemem ServiceDesk
(HPSM w wersji 9.34 i zapewnienie funkcjonowania mechanizmu po uaktualnieniu
HPSM do wersji 9.41) w zakresie wysyłania zleceń obsługi dla działań
niemożliwych do wykonania automatycznie (np. modyfikacja konta w systemie
niezintegrowanym)
5.8.5. Wdrożona konfiguracja MUSI spełniać następujące minimalne parametry
jakościowe:
5.8.5.1. Wszystkie parametry takie jak adresy, loginy techniczne, hasła, parametry
czasowe itp. MUSZĄ być zapisywane i przechowywane wyłącznie w
parametrach konfiguracyjnych Systemu. ZABRONIONE jest zapisywanie ww.
parametrów w sposób wymuszający aktualizację konfiguracji polityk, reguł
i/lub procesów.
5.8.5.2. Tożsamość w Systemie MUSI być obsługiwana jednakowo niezależnie od
źródła powstania.
5.8.5.3. Wszystkie procesy realizowane w Systemie muszą być sterowane danymi (np.
dane użytkownika, uprawnienia) i wartościami konfigurowanymi (np. czasy
powiadomień)
5.8.6. System MUSI realizować jednokrotne logowanie do interfejsu użytkownika w
oparciu o Kerberos
11
UWAGA
Zamawiający, zgodnie z dyspozycją art. 29 ust. 3a ustawy Pzp zastrzega, że:
1. Wymaga zatrudnienia przez wykonawcę lub podwykonawcę na podstawie umowy o pracę osób
wykonujących wskazane przez Zamawiającego czynności – w zakresie n/w funkcji w zespole
dedykowanym do realizacji zamówienia:
-
Kierownik projektu
-
Architekt bezpieczeństwa
-
Architekt rozwiązania
-
Specjalista systemów zarządzania tożsamością
polegające na wykonywaniu czynności w sposób określony w art. 22 §1 Kodeksu pracy.
2. W celu potwierdzenia spełniania powyższego wymagania, Wykonawca, którego oferta zostanie
wybrana jako najkorzystniejsza, zobowiązany jest przed zawarciem umowy ws zamówienia
publicznego do złożenia pisemnego oświadczenia, że członkowie zespołu dedykowanego do
realizacji zamówienia w funkcjach opisanych w pkt. 1 powyżej są zatrudnieni u Wykonawcy na
umowę o pracę od co najmniej 6 miesięcy liczonych wstecz od terminu wyznaczonego na
składanie ofert.
3. Zamawiający zastrzega sobie prawo do przeprowadzenia kontroli prawdziwości złożonego
oświadczenia oraz aktualności informacji o formie zatrudnienia osób dedykowanych do realizacji
zamówienia przez cały okres trwania umowy ws zamówienia publicznego, w szczególności
poprzez zwrócenie się do Państwowej Inspekcji Pracy, jako podmiotu uprawnionego, z wnioskiem
o przeprowadzenie kontroli w tym zakresie.
12
Załącznik nr 1
Wykaz posiadanych przez Zamawiającego licencji do systemu NetIQ
Produkt
NetIQ Identity Manager Advanced
Edition
NetIQ Identity Manager Integration
Module for Tools
NetIQ Identity Manager Advanced
Edition
Novell Identity Manager -pakiet
polonizacyjny
NetIQ Integration Module for
Database 4.5
Data ważności wsparcia
Ilość
06.06.2018
1492
06.06.2018
1400
06.06.2018
941
06.06.2018
1
30.04.2016
1500
13
Załącznik nr 2
Wymagania na dokumentację oprogramowania
I.
Słownik pojęć.
1. System IT– aplikacja i infrastruktura IT wraz z interfejsami.
2. Aplikacja informatyczna – oprogramowanie wykorzystywane w Banku do obsługi operacji
bankowych lub innych zadań o charakterze pomocniczym.
3. Infrastruktura IT – infrastruktura hardware’owa i infrastruktura software’owa.
4. Infrastruktura hardware’owa – ogół sprzętu wykorzystywanego w działaniu aplikacji. Do
infrastruktury hardware’owej zaliczamy:
4.1. Warstwa klienta – stacja PC, laptop, drukarka, czytnik kart, itp.,
4.2. Warstwa komunikacyjna – switch, router, firewall, itp.,
4.3. Warstwa przetwarzania danych – serwer, farma serwerów, itp.,
4.4. Warstwa składowania danych – macierz dyskowa, biblioteka taśmowa, itp.
Na potrzeby tego dokumentu, przyjęto założenie, że do infrastruktury hardware’owej należy także
najniższa warstwa oprogramowania w postaci: firmware, systemu operacyjnego, oprogramowania
wysokiej dostępności, oprogramowania wirtualizacyjnego, itp.
5. Infrastruktura software’owa – ogół oprogramowania wykorzystywanego przez działającą aplikację
wraz z oprogramowaniem dodatkowym. Do infrastruktury software’owej mogą należeć:
5.1. Warstwa klienta – przeglądarka, cienki klient, emulator terminala, itp.;
5.2. Warstwa prezentacyjna – serwery www, serwery usług terminalowych, itp.;
5.3. Warstwa logiki biznesowej – serwery aplikacji, itp.;
5.4. Warstwa danych – bazy danych, itp.
6. Oprogramowanie dodatkowe – serwery nazw, serwery usług katalogowych, serwery
uwierzytelnienia, itp.
7. Interfejsy – kanały komunikacji i wymiany danych pomiędzy aplikacją i elementami infrastruktury
IT oraz pomiędzy systemem IT a systemami zewnętrznymi.
II.
Wymagania ogólne
8. Język.
8.1. Dokumentacja powinna być dostarczona w języku polskim.
8.2. Dokumentacja dla developerów, dokumentacja standardowa komponentów producentów
zagranicznych do wykorzystania przez służby techniczne IT może być przyjęta w języku
angielskim.
9. Postać i forma.
9.1. Dokumentacja powinna być pogrupowana tematycznie i zawierać spis i charakterystykę
wszystkich składników dokumentacji oraz powinna być dostarczona:
9.1.1.
w postaci papierowej, w formie spiętych, zszytych lub zbindowanych egzemplarzy,
9.1.2.
w postaci elektronicznej – w formie plików w formacie PDF lub innego
powszechnie dostępnego formatu dokumentów elektronicznych (Word, HTML itp.);
9.2. Każdy egzemplarz oprócz tytułu powinien posiadać oznaczenie wersji identycznej jak
aktualna wersja aplikacji, którą opisuje (wraz z datą produkcji lub dostawy);
9.3. Suplementy do dokumentacji muszą być spisane w odrębnej liście (numer suplementu oraz
datę wydania i wersję aplikacji).
10. Spis dokumentów zewnętrznych.
14
11.
12.
13.
14.
15.
10.1. Jeżeli w dokumentacji występuje odwołanie do innych źródeł wymagany jest spis
wszystkich użytych dokumentów zewnętrznych i miejsce publikowania;
10.2. Procedury nie mogą zawierać sformułowań typu „zgodnie ze standardową
procedurą ...”;
10.3. W przypadku odniesień do zewnętrznej dokumentacji, zewnętrzna dokumentacja musi
zostać dołączona lub zostać bardzo precyzyjnie wskazana (dostarczona w postaci trwałej
kopii w przypadku dostępu do zasobów internetowych), a odwołanie musi wskazywać na
konkretną stronę/fragment dokumentacji zewnętrznej;
10.4. W przypadku, jeśli procedura wymaga wykonywania specjalizowanych skryptów
instalacyjnych (np. własne skrypty dostawcy systemu IT), skrypty muszą zostać dołączone do
dokumentacji.
Aktualizacja dokumentacji.
11.1. Aktualizacja dokumentacji w trakcie życia aplikacji/systemu nie może być opóźniona o
więcej niż 1 miesiąc od odbioru dostaw.
Zasady licencjonowania.
12.1. Dokumentacja zawiera pełną charakterystykę licencjonowania wszystkich elementów
aplikacji i środowiska;
12.2. Zamawiający musi dodatkowo posiadać prawo majątkowe do powielania i
rozpowszechniania dokumentacji w ramach grupy oraz wśród swoich klientów i firm trzecich
tworzących aplikacje powiązane lub modyfikacje na zlecenie Zamawiającego; powinien
posiadać prawo do tworzenia dokumentów pochodnych i ich rozpowszechniania zgodnie z
powyższym zakresem (w tym prezentacje, dokumentacje, instrukcje, projekty itp.).
Polityka rozwoju oprogramowania.
13.1. Dokumentacja powinna definiować politykę dostawcy w zakresie możliwości rozwoju
przez zamawiającego i firmy trzecie;
13.2. Dokumentacja powinna definiować zasady systematycznego dostosowywania
aplikacji/systemu do zmieniającej się technologii i rozwiązań; w szczególności aplikacja
powinna być w stanie korzystać z nowych wersji, wykorzystywanego oprogramowania i
narzędzi zastosowanych do budowy i eksploatacji aplikacji, najpóźniej w ciągu jednego roku
od dnia wprowadzenia nowej wersji i wspierać wersje do czasu wycofania jej przez
producenta.
Umowy i zobowiązania licencyjne.
14.1. lista zawartych i obowiązujących umów z krótką ich charakterystyką;
14.2. zakres potrzeb identyfikacji zakresu i sposobu zarządzania dostępem do dokumentacji;
14.3. charakterystyką usług serwisowych.
Ograniczenia.
15.1. spis wszelkich informacji o ograniczeniach w zakresie technologii, sprzętu, aplikacji;
15.2. dopuszczalnych wersji użytych komponentów;
15.3. liczba jednoczesności pracy użytkowników;
15.4. maksymalna liczba użytkowników itp.
III.
Dokumentacja użytkownika.
16. Dokumentacja powinna zawierać szczegółowy opis wszelkich funkcjonalności i właściwości
dostarczonego rozwiązania informatycznego, pozwalający na poprawną konfigurację i eksploatację
aplikacji (lub grupy aplikacji) zgodnie z jej przeznaczeniem. W szczególności dokumentacja
powinna zawierać:
15
16.1. opis podstawowych ról użytkowników i zasad ich kreowania;
16.2. opis zarządzania uprawnieniami użytkownika i tworzenia profili;
16.3. opis zarządzania autoryzacją i autentykacją użytkowników;
16.4. opis interfejsu użytkownika oraz opis zasad budowy dialogu z użytkownikiem; jeśli
stosowany jest interfejs wystandaryzowany (branżowy lub danej platformy) wystarczy
wskazać różnice lub odstępstwa od standardu; jeśli zastosowano specyficzny interfejs dla
rozwiązania to opis powinien być szczegółowy i precyzyjny;
16.5. opis specyficznych elementów konfiguracji interfejsu użytkownika; (personalizacja
interfejsu, zasad dialogu) - jeśli takie występują;
16.6. instrukcje obsługi dla wszystkich zasadniczych funkcjonalności biznesowych;
16.7. opis procedur przetwarzania danych dostępnych dla użytkownika (opis procesów lub
diagramy procesów);
16.8. opis zasad realizacji wymagań określonych w ustawie o rachunkowości w szczególności
opis struktury logicznej i fizycznej ksiąg oraz opis stosowanych procedur przetwarzania
danych, zgodnie z wymaganiami prawa;
16.9. dokumentacja może być podzielona wg zasadniczych grup ról wykorzystujących
aplikację/system w procesach biznesowych – np. oddzielna dla analityków a oddzielna dla
osób wprowadzających/rejestrujących dane (np. transakcje). Jeśli dokumentacja składa się z
kilku elementów to w każdym z nich powinno znaleźć się ich wyszczególnienie i istotne
odnośniki do powiązanych elementów.
IV.
Dokumentacja eksploatacyjna oraz techniczna.
17. W dokumentacji muszą być zawarte opisy wszelkich cech, właściwości i funkcjonalności
pozwalających na poprawną z punktu widzenia technicznego eksploatację aplikacji informatycznej.
W szczególności dokumentacja ta powinna zawierać:
17.1. opis architektury technicznej;
17.1.1. Wyszczególnienie oraz opis powiązań wszystkich komponentów sprzętowych,
systemowych i aplikacyjnych występujących lub wymaganych do poprawnej pracy
aplikacji zgodnie z wymaganiami wydajności, funkcjonalności i bezpieczeństwa
(minimalny, maksymalny, rekomendowany),
17.1.2. dla komponentów innych dostawców, należy dokładnie określić wykorzystywane i
dopuszczalne wersje;
17.2. Konfiguracja musi obejmować wszystkie urządzenia wdrożone, zainstalowane w ramach
budowy systemu IT.
18. Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje:
18.1. Serwery – parametry sprzętowe (procesor, pamięć, dyski, karty sieciowe, zasilanie, itp.);
18.1.1. sieć (adresacja IP, itp.),
18.1.2. podsystem dyskowy (punkty montowania/litery dysków, wolumeny logiczne,
grupy wolumenowe, zasoby dyskowe, RAID, itp.),
18.1.3. system operacyjny (parametry jądra, moduły, usługi, stos TCP/IP, itp.),
18.1.4. klaster (węzły fizyczne, paczki klastrowe, kolejność przełączania, itp.),
18.1.5. listę zainstalowanego oprogramowania, itp.;
18.2. Macierze – parametry sprzętowe (cache, półki dyskowe, dyski, karty/porty fibre channel,
itp.), grupy dyskowe, zasoby dyskowe, maskowanie, kopie biznesowe, replikacja, itp.;
18.3. Infrastrukturę sieciową– parametry sprzętowe (porty fibre channel, aktywne licencje, itp.),
fabric, zonning, aliasy, itp.
16
19. Opis konfiguracji aplikacji/systemu.
19.1. Opis musi obejmować ogół oprogramowania wdrożonego, zainstalowanego w ramach
budowy systemu IT.
Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje: wersję oprogramowania,
narzędzia, użytkowników i grupy systemowe, katalog instalacyjny, położenie plików konfiguracyjnych,
pierwotne parametry konfiguracyjne i zmodyfikowane w procesie instalacji, położenie plików logów,
położenie i opis innych kluczowych plików i katalogów, parametry instancji, itp.;
19.2. Konfiguracja musi obejmować wersję aplikacji, pełen zestaw parametrów
konfiguracyjnych aplikacji wraz z opisem użycia, katalogi instalacyjne, położenie plików
konfiguracyjnych, położenie plików logów, położenie i opis innych kluczowych plików i
katalogów, itp.
20. Opis architektury logicznej:
– schemat i opis powiązań logicznych poszczególnych komponentów i ich rolę w architekturze.
21. Mapa i opis Interface’ów.
21.1. Interfejsy muszą zawierać szczegółowy opis techniczny, w szczególności zawierać
informację o: typie interfejsu, wykorzystywanych protokołach, portach sieciowych, strukturze
interfejsu, itp. oraz o zakresie wymiany danych i sposobu kontroli prawidłowości działania.
22. Opis struktur danych.
Opis wykorzystywanych struktur danych musi w szczególności zawierać: listę tabel bazy danych
wraz z opisem pól, formaty danych, itp., kryteria walidacji danych wejściowych, opis zmiennych
konfiguracyjnych.
23. Opis wymagań sprzętowych, systemowych, sieciowych itp.
Wymagania dla poszczególnych komponentów architektury, odniesienia do oczekiwanych
wymagań wydajnościowych, funkcjonalnych i bezpieczeństwa (minimalny, maksymalny,
rekomendowany).
24. Procedury tworzenia środowisk pomocniczych.
Zasady i procedury tworzenia środowisk (testowych, rozwojowych, raportowych) oraz metod
klonowania i animizacji (depersonifikacji) danych przenoszonych pomiędzy środowiskami;
25. Procedury eksploatacji.
W szczególności dokumentacja zawiera procedury:
 tworzenia/odtwarzania kopii bezpieczeństwa operacyjnego i kopii zapasowych oraz
odtwarzania/kreowania z kopii wszystkich komponentów aplikacji i środowiska (bazy
danych, komponenty serwera aplikacji, klienta itp.),
 odtworzenia systemu po katastrofie (disaster recovery); Procedury muszą opisywać
kolejne kroki pozwalające na bezpieczne zatrzymanie/uruchomienie elementu
infrastruktury hardware’owej oraz aplikacji i elementów infrastruktury software’owej.
26. Procedury lub instrukcje instalacji, reinstalacji, deinstalacji oraz aktualizacji.
Szczegółowy opis postępowania w przypadku tworzenia lub zmian w środowisku; jeśli
wykorzystywane są procedury innych dostawców dla standardowych komponentów (np. baz danych)
wystarczy wskazać w dokumentacji szczegółowe odniesienie do procedur standardowych właściwych dla
tych komponentów.
27. Procedury backupowe:
zalecany tryb backupu aplikacji i elementów infrastruktury software’owe, oraz zakres danych
podlegających backupowi. Procedury odtworzeniowe, muszą w szczególności opisywać sposób
odtworzenia funkcjonalności aplikacji i elementów infrastruktury software’owej w przypadku błędu lub
awarii.
17
28. Dokumentacja administracyjna związanych z poprawną eksploatacją
Opis (w postaci procedur lub instrukcji) wszystkich rutynowych czynności administracyjnych dla
aplikacji i systemu informatycznego (dziennych, tygodniowych, miesięcznych itp.) oraz działań
pozwalających na utrzymanie wymaganej dostępności, wydajności i bezpieczeństwa. Wymagane jest
dostarczenie poprawnych inicjalnych sekwencji realizowanych czynności administracyjnych
i utrzymaniowych i zasad ich aktualizacji i budowy; opis zasad pielęgnacji i utrzymania aplikacji. Procedury
administracyjne powinny w szczególności zawierać informacje o okresowych zadaniach, które muszą być
wykonane przez administratora, np. weryfikacja zajętości przestrzeni tabel, konieczność wykonywania
analizy tabel, czyszczenia logów, itp.
29. Procedury standardowe:
opis możliwości stosowania standardowych procedur poprawnej eksploatacji dla rozwiązań
wspierających (sprzętowych lub aplikacyjnych).
30. Dokumentacja procesu parametryzacji:
wyszczególnienie wszystkich parametryzowanych elementów systemu wraz z opisem ich
znaczenia i dopuszczalnych wartości oraz stosowanych wartości domyślnych.
31. Dokumenty z testów:
plan testów, scenariusze testowe i protokoły z testów akceptacyjnych, wydajnościowych, testów
operacji administratora technicznego oraz testów bezpieczeństwa w tym ciągłości działania (przełączanie,
odtwarzanie, weryfikacja poprawności).
32. Dokumentacja wdrożeniowa.
32.1. dokumentacja powykonawcza:
zawiera szczegółowy opis wykonanych czynności instalacyjnych oraz konfiguracyjnych wszystkich
komponentów systemu;
32.2. dokumentacja parametryzacji:
wyszczególnienie wartości wszystkich ustawionych parametrów użytkowych zarówno samej
aplikacji jak i pozostałych komponentów systemu, parametry systemu operacyjnego oraz parametry
sprzętu;
32.3. dokumentacja uruchomieniowa:
opisuje wszystkie istotne kroki (czynności) wykonane w celu pierwszego uruchomienia
aplikacji/systemu, w tym opis migracji/konwersji danych, testy uruchomieniowe;
32.4. dokumentacja pilotażowa:
jeśli był stosowany w trakcie wdrożenia pilotaż jako element stabilizacji i testów.
33. Dokumentacja szkoleniowa:
Materiały szkoleniowe dla użytkowników oraz administratorów (technicznych i bezpieczeństwa).
34. Wersjonowanie:
Opis zasad wersjonowania i sposobu patchowania aplikacji.
35. Historia:
Opis zasad zarządzania danymi historycznymi i archiwalnymi.
36. Zalecenia:
Opis zasad i zaleceń strojenia aplikacji.
V.
Dokumentacja administratora bezpieczeństwa.
37. Zestaw dokumentacji szczegółowo opisującej zastosowane rozwiązania dotyczące spełniania
wymagań ogólnych (zgodnie z wymaganiami prawa) oraz specyficznych zamawiającego
dotyczących bezpiecznej eksploatacji. Dokumentacja, w szczególności, powinna zawierać:
18
37.1. opis zastosowanych mechanizmów ochrony przed naruszeniem zasad dostępu
(poufności), integralności, niezaprzeczalności, wiarygodności oraz opis mechanizmów
udostępniania, autoryzacji w tym autoryzacji operacji szczególnych;
37.2. opis zastosowanych mechanizmów logowania zdarzeń, śladu audytowego oraz kontroli i
monitorowania działań w aplikacji/systemie w tym wszelkich prób naruszenia zasad
bezpieczeństwa;
37.3. dokumentacja administratora aplikacji i administratora środowiska systemu opisująca
szczegółowo funkcjonalności, interfejs oraz zasady zarządzania kontami (użytkownikami) oraz
uprawnieniami poszczególnych ról, profili, użytkowników itp.;
37.4. dokumentacja opisująca sposób realizacji wymagań wynikających z przepisów ustawy z
dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2014 r. poz. 1182,
z późn. zm.), w tym sposób realizacji wymagań wynikających z rozporządzania Ministra
Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji
przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim
powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych
osobowych (Dz. U. Nr 100, poz. 1024), jeśli aplikacja przetwarza dane osobowe;
37.5. opis zabezpieczeń interfejsów oraz opis metod zapewnienia poufności i kontrolowalności
tych kanałów przepływu informacji jeśli aplikacja wykorzystuje jakiekolwiek mechanizmy
wymiany informacji z innymi systemami;
37.6. dokumentacja z testów bezpieczeństwa aplikacji wykonanych przez dostawcę lub
wykonanych przez niezależną firmę specjalistyczną.
VI.
Dokumentacja technologiczna.
Zawiera opis wszystkich właściwości, cech i funkcjonalności pozwalających na ocenę sposobu i
jakości wykonania a także zapewniający możliwości dalszego niezależnego rozwoju aplikacji
informatycznej. Dokumentacja taka dzieli się na część obligatoryjną oraz opcjonalną.
38. Dokumentacja obligatoryjna.
38.1. określenie lub opis zastosowanej technologii informatycznej wykorzystanej do
projektowania, wytwarzania i testowania aplikacji, jeśli zastosowano technologie
standardowe wystarczy wskazanie na źródło ogólnie dostępnej dokumentacji, jeśli jest to
technologia własna lub niestandardowa należy dostarczyć adekwatna dokumentację tej
technologii;
38.2. opis architektury logicznej aplikacji zawierający wyszczególnienie i opis wszystkich
wykorzystanych oddzielnych komponentów;
38.3. opis przepływu danych, wywołań i interakcji pomiędzy wszystkimi oddzielnymi
komponentami aplikacyjnymi (modułami), w szczególności komponentami innych
dostawców (wymagane jest podanie nazwy dostawcy, produktu, wersji oraz dostarczenie
pełnej dokumentacji tego komponentu);
38.3.1. opis dostępnych interfejsów programistycznych (API, SDK) jeśli są dostarczane,
38.3.2. wyszczególnienie i opis interfejsów lub mechanizmów interfejsów pozwalających
na integrację danych lub procesów powiązanych z innymi aplikacjami lub systemami w
tym z platformą systemową i sprzętową,
38.3.3. jeśli aplikacja została wykonana na zamówienie Banku wymagane jest
dostarczenie szczegółowej dokumentacji wykonawczej – projekt techniczny oraz
dokumentacja powykonawcza.
39. Dokumentacja na zamówienie.
19
39.1. dokumentacja opisująca zasady i sposób budowy środowiska developerskiego oraz
testowego;
39.2. projekt techniczny (model) zgodnie z konwencją metodyki strukturalnej lub obiektowej:
39.2.1. w przypadku metodyk modelowania strukturalnego wymagany jest minimalny
diagram związków encji (ERD) oraz diagram przepływu danych (DFD),
39.2.2. w przypadku metodyk obiektowych wymagany w UML jest co najmniej diagram
przypadków użycia, diagram struktur, diagram zachowań;
39.3. opis możliwości rozwojowych i usługi wymiany danych z aplikacjami zewnętrznymi;
39.4. opis skalowalności aplikacji i systemu;
39.5. możliwość zastosowania innych narzędzi lub technologii programistycznych;
39.6. szczegółowa dokumentacja udostępnionych interfejsów programistycznych (API, SDK);
39.7. dokumentacja szkoleniowa dla developerów.
20