Sygnatura postępowania: DZZK/29/DST/2018 - bgk.pl · szczególności nieprawidłowości w...

Sygnatura postępowania: DZZK/29/DST/2018

1

Załącznik nr 2 do SIWZ

Opis przedmiotu zamówienia

(zwany dalej „OPZ”)

§ 1.

1. Przedmiotem zamówienia w części podstawowej jest:

a. zakup systemu informatycznego wspierającego zarządzanie projektami i portfelem projektów w

Banku Gospodarstwa Krajowego (dalej: System, spełniający łącznie wymagania określone w dalszej

części OPZ);

b. dostawa Systemu (rozwiązanie „z półki” w stabilnej, najnowszej wersji dostępnej na dzień składania

ofert) wraz z licencjami on-premises;

c. wdrożenie Systemu, w tym:

i. przygotowanie przy współudziale Zamawiającego i dostarczenie Zamawiającemu Analizy

Przedwdrożeniowej, zawierającej zakres projektu oraz uszczegółowiony zakres wymagań

funkcjonalnych Systemu (w szczególności dokument będzie zawierał opis wymagań i sposób

ich realizacji, opis procesów zarządzania projektem, w tym planowanie, uruchomienie,

realizacja, zamykanie i sposób ich realizacji, założenia do konfiguracji Systemu, opis potrzeb

raportowania, założenia do migracji i integracji);

ii. przygotowanie oraz dostarczenie Zamawiającemu Projektu Technicznego Wdrożenia Systemu

(w szczególności dokument będzie zawierał architekturę rozwiązania, konfigurację sprzętową

urządzeń, wersje oprogramowania wchodzące w skład rozwiązania, adresację sieciową,

konfigurację Systemu, harmonogram szczegółowy);

iii. instalację, migrację danych testowych, konfigurację, parametryzację Systemu na środowisku

testowym oraz przeprowadzenie testów integracyjnych, akceptacyjnych, wydajnościowych,

bezpieczeństwa;

iv. instalację, migrację danych produkcyjnych, konfigurację, parametryzację Systemu na

środowisku produkcyjnym oraz uruchomienie Systemu zgodnie z wymaganiami

Zamawiającego oraz przygotowanym przez Wykonawcę Projektem Technicznym Wdrożenia

Systemu;

v. zmiany i parametryzacja systemu opisana w pkt 1.c.iii oraz pkt. 1.c.iv zostanie przeprowadzona w sposób, który w przyszłości umożliwi Zamawiającemu łatwą aktualizację Systemu do nowszej(ych) wersji. Wykonawca zagwarantuje i potwierdzi Zamawiającemu możliwość aktualizacji systemu na etapie przygotowania Projektu Technicznego Wdrożenia Systemu. W przypadku odstępstw od standardowej parametryzacji Systemu Wykonawca przygotuje opis szczegółowy zmian i dołączy go do Projektu Technicznego Wdrożenia Systemu;

vi. przeprowadzenie warsztatowego przekazania wiedzy dla użytkowników wdrożonego

Systemu;


2

vii. wykonanie i dostarczenie dokumentacji powdrożeniowej, zgodnie z wytycznymi

Zamawiającego, opisanymi w załączniku nr 1 OPZ.

d. zapewnienie 24-miesięcznego serwisu Systemu, w tym coroczny przegląd Systemu wraz z

przekazywaniem wszelkich poprawek i aktualizacji Systemu, jak również nowych wersji Systemu, w

szczególności wprowadzających nowe lub zmienione jego funkcje, rozszerzające jego zakres

funkcjonalny, usuwające Awarie/Błędy/Usterki, zwiększające jego wydajnośc i bezpieczeństwo,

opracowane przez producenta Systemu.

2. W części opcjonalnej zamówienia:

a. Wykonawca w okresie obowiązywania Umowy, zobowiązuje się do zapewnienia gotowości

świadczenia realizacji usług stanowiących Prawo opcji Zamawiającego, na warunkach cenowych

określonych w Ofercie;

b. Zamawiający będzie mógł wielokrotnie korzystać z Prawa opcji w zakresie:

a. parametryzacji i modyfikacji Systemu na podstawie odrębnych zleceń składanych w

okresie obowiązywania Umowy, w wymiarze nieprzekraczającym łącznie 70

roboczogodzin,

b. przedłużenia usługi serwisowej o maksymalnie 21 miesięcy;

zgodnie z warunkami opisanymi szczegółowo w dalszej części OPZ. W celu skorzystania przez

Zamawiającego z prawa określonego w lit. a. powyżej, Zamawiający zobowiązany jest złożyć

pisemne zlecenie, a Wykonawca winien je zrealizować w terminie uzgodnionym przez Strony w

toku bieżących prac oraz na podstawie analizy przedstawionej przez Wykonawcę;

c. Procedura składania i odbioru zleceń dotyczących zamówienia usług parametryzacji i modyfikacji

Systemu w ramach realizacji Prawa opcji została opisana w załączniku nr 4 do OPZ.

3. Zamawiający ma prawo skorzystać z Prawa opcji do przedłużenia świadczenia usługi serwisowej dla

Systemu, które może być zlecone jednokrotnie na pełen okres 21 miesięcy lub dwukrotnie: na okres 12

miesięczny, a dalej na okres 9 miesięczny do łącznego wykorzystania maksymalnego okresu 21

miesięcy. Okres przedłużenia liczony będzie od dnia następnego po zakończeniu usług serwisu

świadczonych w ramach zamówienia podstawowego lub odpowiednio po zakończeniu usług serwisu

świadczonych w ramach zamówienia opcjonalnego w pierwszym okresie 12 miesięcy, zgodnie z

warunkami opisanymi szczegółowo w OPZ. W celu skorzystania przez Zamawiającego z niniejszego

prawa, Zamawiający obowiązany jest złożyć zamówienie nie później niż na 30 dni przed upływem

zakończenia terminu świadczenia usług serwisu. W celu uniknięcia wątpliwości Strony potwierdzają, iż

Wykonawca zobowiązany jest do świadczenia usług serwisu w przypadku złożenia przez

Zamawiającego oświadczenia woli o skorzystaniu z Prawa opcji w tym zakresie, przy czym Zamawiający

nie jest zobowiązany do złożenia takiego oświadczenia a jedynie uprawniony.


3

4. Skorzystanie z Prawa opcji w całości lub w części jest zastrzeżone do wyłącznej decyzji Zamawiającego.

Nieskorzystanie przez Zamawiającego z Prawa opcji nie rodzi po stronie Wykonawcy jakichkolwiek

roszczeń.

§ 2.

1. Główne wymagania dla Systemu:

a. Architektura Systemu musi być zgodna ze szczegółowymi wymaganiami określonymi w załączniku

nr 3 do OPZ;

b. Interfejs użytkownika Systemu oraz wszelkie jego aktualizacje muszą być w języku polskim;

c. System musi zapewniać zdalny dostęp przez przeglądarkę internetową (opisaną w załączniku nr 3)

służącą jako interfejs użytkownika i administratora;

d. System musi zapewnić pełen dostęp, tzn. dostęp do wszystkich opcji Systemu i możliwości pełnej

modyfikacji danych, dla 100 użytkowników (np. pracownicy PMO, Managerowie ds. Zarządzania

Projektem, Managerowie Biznesowi Projektów, pracownicy Wydziału strategii, Administrator) oraz

ograniczony dostęp, tzn. dostęp tylko do wybranych opcji Systemu dla 600 użytkowników (np.

Zarząd Banku, Komitet Zmian, dyrektorzy zarządzający, dyrektorzy komórek organizacyjnych,

Kierownicy Zespołów Roboczych, członkowie zespołów projektowych);

e. Musi zostać zapewniona wydajna obsługa Systemu dla co najmniej 150 użytkowników

jednocześnie;

f. System musi zapewnić godziny pracy operacyjnej (godziny robocze): 7:00 – 19:00, 5 dni w tygodniu,

od poniedziałku do piątku;

g. System musi spełniać wymogi wykonywania kopii zapasowych: kopia raz dziennie np. o 24:00 (po

zakończeniu pracy operacyjnej);

h. Czas w jakim System musi zapewnić przywrócenie procesów po wystąpieniu Awarii (RTO) wynosi 2

dni robocze (16 godzin);

i. Czas w jakim system musi zapewnić akceptowalny poziom utraty danych wyrażony w czasie (RPO)

wnosi 1 dzień roboczy (12 godziny);

j. Wykonawca zobowiązany jest do usuwania Awarii, Błędów i Usterek z zachowaniem poniższych

zasad:

Kategoria Czas Naprawy

Awaria Do 2 dni roboczych

Błąd Do 5 dni roboczych

Usterka Do 10 dni roboczych

Przy czym:


4

Kategoria: Awaria, Błąd lub Usterka Systemu;

Czas Naprawy oznacza maksymalny czas przywrócenia funkcjonalności Systemu po wystąpieniu

Awarii/Błędu/Usterki, do stanu sprzed wystąpienia Awarii/Błędu/Usterki;

Awaria oznacza zatrzymanie lub poważne zakłócenie pracy Systemu spowodowane niedziałaniem lub

nienależytym działaniem Oprogramowania, niebędące Błędem ani Usterką, w szczególności

polegające na niemożności realizacji jednej z funkcji Oprogramowania, w wyniku czego System lub

jego część nie może prawidłowo i terminowo obsłużyć Krytycznych Procesów Biznesowych

Zamawiającego. Za Awarię uważane jest także jednoczesne wystąpienie szeregu Wad będących

Błędami lub Usterkami, w przypadku gdy można wykazać, że występujące jednocześnie Wady mają

ten sam skutek, co opisane powyżej Awarie. Awariami mogą być w szczególności częste,

nieprzewidywalne lub nieuniknione zatrzymania lub zakłócenia pracy Systemu, poważne

uszkodzenia bazy danych lub zasobu danych bądź też nieuzasadniona konieczność dodatkowego

ręcznego przetwarzania danych, przerwy w działaniu całego Systemu lub jego poszczególnych

elementów.

Błąd oznacza zakłócenia w pracy Systemu spowodowane niedziałaniem lub nienależytym działaniem

Oprogramowania, niebędące Awarią ani Usterką, w szczególności polegające na ograniczeniu

realizacji lub uciążliwości w realizacji jednej z funkcji Systemu. Błędami mogą być w szczególności

nieprawidłowe wyniki generowane przez aplikacje, pola danych, których poprawności nie da się

potwierdzić, lub które są wykorzystywane niezgodnie z przeznaczeniem, jak również błędy w

sprawozdaniach lub danych przedstawianych przez System.

Usterka oznacza zakłócenie pracy Systemu spowodowane niedziałaniem lub niepoprawnym

działaniem Oprogramowania, niebędące Awarią ani Błędem, mogące mieć wpływ na jego

funkcjonalność, natomiast nieograniczające zdolności operacyjnych Systemu. Usterki oznaczają

wszelkie odchylenia od specyfikacji technicznych Systemu, które nie mają istotnego wpływu na jego

zastosowanie, funkcjonowanie lub utrzymanie i dalszy rozwój Systemu. Usterkami mogą być w

szczególności nieprawidłowości w prezentacji graficznej, błędy ortograficzne, semantyczne i

składniowe, bądź też drobne niedokładności w ramach Systemu, które nie rodzą konieczności

znacznych dodatkowych nakładów pracy ze strony Zamawiającego w ramach jego bieżącej

działalności;

k. System musi umożliwiać wczytywanie i przetwarzanie danych z plików MS Excel (xls, xlsx) lub plików

płaskich csv czy txt z systemów źródłowych Zamawiającego a w szczególności z posiadanej przez

Zamawiającego Zarządczej Hurtowni Danych w zakresie np. planowanych (budżet) i wykonanych

(rozliczenia) wydatków w zakresie prowadzonych projektów Zamawiającego. Wszystkie szczegóły

techniczne związane z dostarczaniem plików dla Systemu zostaną ustalone z Wykonawcą podczas

trwania prac projektowych;


5

l. System musi umożliwiać eksport danych do plików w formacie MS Excel (xls, xlsx) lub plików

płaskich csv czy txt, w uzgodnionej podczas prac projektowych strukturze i stronie kodowej w celu

zaczytania danych przez Zarządczą Hurtownię Danych.

2. System musi integrować się z posiadanym przez Zamawiającego systemem JIRA w zakresie wymiany

zadań, odpowiedzialności oraz pracochłonności i czasochłonności prac oraz umożliwia generowanie

raportów na bazie wymienionych danych:

a. System umożliwia integrację z JIRA na poziomie Epic i User Story oraz komponentów i edycji.

Celem jest taka integracja, w której nie będzie konieczności ręcznego zmieniania parametrów

zadania w harmonogramie w Systemie, tylko zmieniać się ono będzie w momencie zmiany

powiązanych z nim zadań developerskich w JIRA (zmiana statusu, zmiana dat, zmiana

estymowanego czasu pracy).

b. Na poziomie JIRA Zamawiający definiuje i realizuje bardzo detaliczne zadania developerskie.

Zadania te grupowane są pod kątem konkretnych wymagań funkcjonalnych, które w JIRA

mapowane są na User Story. Każde User Story odpowiada jednemu wymaganiu funkcjonalnemu.

Czas realizacji tego wymagania, terminy, zasoby, etc., są funkcją czasów i terminów realizacji zadań

developerskich oraz ograniczeń biznesowych. Wymagania funkcjonalne w formie User Story

grupowane są na wyższym poziomie do wymagań biznesowych, które reprezentowane są w JIRA

przez Epiki (Epic). Każdemu wymaganiu biznesowemu odpowiada dokładnie jeden Epik. I tak jak

poprzednio terminy, czas i zasoby potrzebne do realizacji Epika są funkcją podpiętych do niego

User Story. Epiki składają się na cały projekt, który jest w JIRA reprezentowany jako Projekt. Na

poziomie strategicznego zarządzania projektem istotne są informacje do poziomu User Story.

Informacje te w JIRA zmieniają się dynamicznie w każdym momencie gdy zmieniają się podpięte na

samym dole zadania developerskie.

c. Integracja Systemu z JIRA powinna wyglądać w ten sposób, że System ma automatycznie pobierać

określone w §2 pkt. 2b informacje i wyświetlać powiadomienia do odpowiednich osób bez

automatycznej zmiany harmonogramów projektów. Informacje powinny płynąć w drugą stronę

przekazując do developerów, analityków i testerów ograniczenia biznesowe jakie na zadania

nakłada projekt (np. wynikające z ustawy terminy realizacji, inicjatywa strategiczna w ramach

której projekt jest realizowany etc.).

3. System musi spełniać wymagania bezpieczeństwa opisane w załączniku nr 2 do OPZ.

4. System musi spełniać wymagania funkcjonalne opisane w załączniku nr 5 do OPZ.

§ 3.

1. Wykonawca zobowiązany jest do przekazania wiedzy dotyczącej obsługi Systemu użytkownikom

wyznaczonym przez Zamawiającego:


6

a. warsztaty merytoryczno-techniczne w języku polskim będą polegały na przedstawieniu

funkcjonalności Systemu i dotyczących wszystkich funkcji administracyjnych, które są

przewidziane do wykonywania przez wyznaczonych pracowników Zamawiającego;

b. warsztaty będą miały charakter wykładu połączonego z warsztatem praktycznym,

przeprowadzanym na wersji szkoleniowej Systemu, o zakresie funkcjonalności identycznej z

wersją produkcyjną;

c. warsztaty powinny zostać podzielone tematycznie:

i. Ogólna architektura Systemu;

ii. Konfiguracja poszczególnych kont;

iii. Zarządzanie użytkownikami, kontami grupami;

iv. Raportowanie;

v. Administracja Systemu;

vi. Instalacja i konfiguracja;

vii. Obsługa funkcjonalna Systemu.

d. Zamawiający przewiduje, że warsztaty stacjonarne obejmą do 50 wyznaczonych przez

Zamawiającego pracowników;

e. Warsztaty odbędą się w siedzibie i godzinach pracy Zamawiającego;

f. Materiały na warsztaty szkoleniowe oraz środowisko szkoleniowe Systemu zapewni Wykonawca;

g. Wykonawca po warsztatach szkoleniowych przeprowadzi pisemną ankietę wśród jego

uczestników zawierającą ocenę warsztatów i przekaże wyniki Zamawiającemu;

h. W przypadku, gdy zdaniem Zamawiającego, ilość zgłoszonych uwag będzie świadczyła o brakach

w wiedzy odbiorców i konieczności powtórzenia warsztatów, Wykonawca przeprowadzi na własny

koszt dodatkowe warsztaty uwzględniające te uwagi;

i. Przekazanie wiedzy na temat funkcjonalności Systemu, poparte wynikami ankiet, będzie

potwierdzać podpisany bez zastrzeżeń przez Zamawiającego odpowiedni protokół. Warunkiem

podpisania Protokołu bez zastrzeżeń będzie otrzymanie minimum 50% ocen pozytywnych

(dobrych i bardzo dobrych) z przeprowadzonej ankiety;

j. W przypadku braku odbioru z przyczyn leżących po stronie Wykonawcy (np. negatywna ocena

przez uczestników, niedotrzymanie terminu, brak materiałów lub ich niska jakość negatywnie

oceniona przez uczestników), Zamawiający ma prawo żądać od Wykonawcy wyznaczenia nowego

terminu warsztatów dotyczących przekazania wiedzy.

§ 4.

1. Wykonawca zobowiązany jest przedstawić harmonogram realizacji wdrożenia Systemu

uwzględniający:


7

a. Wykonanie Analizy Przedwdrożeniowej i przygotowanie Projektu Technicznego Wdrożenia

Systemu;

b. Przygotowanie propozycji konfiguracji Systemu;

c. Prace implementacyjno-wdrożeniowe;

d. Instalację i konfigurację Systemu;

e. Zdefiniowanie ról dla użytkowników Systemu.

2. Wykonawca zobowiązany jest do przeprowadzenia optymalizacji samego Systemu oraz doboru

odpowiednich parametrów celem otrzymania najwydajniejszej i najbardziej bezpiecznej konfiguracji

Systemu.

3. Wykonawca serwisu musi posiadać autoryzowany certyfikat producenta do świadczenia serwisu dla

oferowanych rozwiązań.

4. Wykonawca zobowiązany jest do zapewnienia wsparcia technicznego i serwisu Systemu, w zakresie:

a. Dostępu do pomocy technicznej producenta Systemu;

b. Dostępu do aktualizacji, poprawek i nowych wersji Systemu;

c. Udzielenia lub zapewnienia udzielenia licencji przez producenta Systemu na użytkowanie

nowych wersji, aktualizacji i poprawek do Systemu;

d. Dostępu do dokumentacji użytkowej, administracyjnej, bezpieczeństwa i technicznej Systemu;

e. Dostępu do konta suportowego producenta Systemu, zawierającego dostęp do bazy wiedzy,

bibliotek dokumentacji, opisów produktów, specyfikacji, literatury technicznej i innych

materiałów;

f. Pomocy w analizie i rozwiązywaniu problemów z Systemem;

g. Doradztwa i pomocy w zakresie obsługi Systemu;

h. Niezwłocznego informowania o znanych problemach z Systemem i sposobach ich

rozwiązywania;

i. Wykonywania, za zgodą Zamawiającego, aktualizacji i modyfikacji Systemu, niezwłocznie po

pojawieniu się nowej rekomendowanej przez producenta wersji Systemu lub poprawki/patch’a

do oprogramowania składającego się na System.

5. Wykonawca zobowiązany jest do zapewnienia HotLine przez cały okres obowiązywania wsparcia

technicznego i serwisu:

a. Zapewnienia HotLine, dostępnego dla upoważnionych pracowników Zamawiającego, w dni

robocze od poniedziałku do piątku w godz. od 7:00 do 19:00 z wyjątkiem dni świątecznych i

ustawowo wolnych od pracy, spełniającego poniższe wymagania:

i. HotLine musi obejmować następujące kanały zgłoszeń: dedykowany system zgłoszeniowy

poprzez kanał internetowy, poczta elektroniczna, telefon;


8

ii. W ramach HotLine Wykonawca zapewnia dedykowany kanał dostępu przez Internet do

systemu zgłoszeniowego służący śledzeniu i aktualizacji zarejestrowanych zgłoszeń;

iii. W ramach HotLine Wykonawca zapewnienia możliwość automatycznego powiadamiania o

zbliżającym się czasie przeznaczonym na naprawę lub przekroczeniu SLA.

6. Zamawiający wymaga, aby okres 24 miesięcy wsparcia technicznego i serwisu był liczony od daty

podpisania Protokołu odbioru końcowego.

7. Wsparcie techniczne musi być świadczone w siedzibie Zamawiającego, Centrala - Al. Jerozolimskie 7

Warszawa, przez co najmniej jednego inżyniera Wykonawcy, posiadającego stosowne kompetencje,

potwierdzone certyfikatem z oferowanej technologii.

b. Wszelkie nośniki danych (w szczególności dyski twarde, karty pamięci), w przypadku awarii lub usterki

(po jej usunięciu) pozostają w siedzibie Zamawiającego. Koszt pozostawionych nośników danych

wliczony jest w opłatę serwisową.


9

Załącznik nr 1 do OPZ

Wymagania na dokumentację oprogramowania (dokumentacja powdrożeniowa)

I. Wymagania ogólne

1. Język.

1.1. Dokumentacja powinna być dostarczona w języku polskim.

2. Postać i forma.

2.1. Dokumentacja powinna być pogrupowana tematycznie i zawierać spis i charakterystykę

wszystkich składników dokumentacji oraz powinna być dostarczona:

2.1.1. w postaci papierowej, w formie spiętych, zszytych lub zbindowanych egzemplarzy,

2.1.2. w postaci elektronicznej – w formie plików w formacie PDF lub innego powszechnie

dostępnego formatu dokumentów elektronicznych (Word, HTML itp.);

2.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);

2.3. Suplementy do dokumentacji muszą być spisane w odrębnej liście (numer suplementu oraz

datę wydania i wersję aplikacji).

3. Spis dokumentów zewnętrznych.

3.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;

3.2. Procedury nie mogą zawierać sformułowań typu „zgodnie ze standardową

procedurą ...”;

3.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;

3.4. W przypadku, jeśli procedura wymaga wykonywania specjalizowanych skryptów

instalacyjnych (np. własne skrypty Wykonawcy systemu IT), skrypty muszą zostać dołączone

do dokumentacji.

4. Aktualizacja dokumentacji.

4.1. Aktualizacja dokumentacji w trakcie życia aplikacji/systemu nie może być opóźniona o więcej

niż 1 miesiąc od odbioru dostaw.

5. Zasady licencjonowania.

5.1. Dokumentacja zawiera pełną charakterystykę licencjonowania wszystkich elementów

aplikacji i środowiska;

5.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


10

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.).

6. Polityka rozwoju oprogramowania.

6.1. Dokumentacja powinna definiować politykę Wykonawcy w zakresie możliwości rozwoju

przez zamawiającego i firmy trzecie;

6.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.

7. Umowy i zobowiązania licencyjne.

7.1. lista zawartych i obowiązujących umów z krótką ich charakterystyką;

7.2. zakres potrzeb identyfikacji zakresu i sposobu zarządzania dostępem do dokumentacji;

7.3. charakterystyką usług serwisowych.

8. Ograniczenia.

8.1. spis wszelkich informacji o ograniczeniach w zakresie technologii, sprzętu, aplikacji;

8.2. dopuszczalnych wersji użytych komponentów;

II. Dokumentacja użytkownika

9. 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ć:

9.1. opis podstawowych ról użytkowników i zasad ich kreowania;

9.2. opis zarządzania uprawnieniami użytkownika i tworzenia profili;

9.3. opis zarządzania autoryzacją i autentykacją użytkowników;

9.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;

9.5. opis specyficznych elementów konfiguracji interfejsu użytkownika; (personalizacja interfejsu,

zasad dialogu) - jeśli takie występują;

9.6. instrukcje obsługi dla wszystkich zasadniczych funkcjonalności biznesowych;


11

9.7. opis procedur przetwarzania danych dostępnych dla użytkownika (opis procesów lub

diagramy procesów);

III. Dokumentacja eksploatacyjna oraz techniczna

10. 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ć:

10.1. opis architektury technicznej;

10.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),

10.1.2. dla komponentów innych dostawców, należy dokładnie określić wykorzystywane i

dopuszczalne wersje;

10.2. Konfiguracja musi obejmować wszystkie urządzenia wdrożone, zainstalowane w ramach

budowy systemu IT.

11. Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje:

11.1. Serwery – parametry sprzętowe (procesor, pamięć, dyski, karty sieciowe, zasilanie, itp.);

11.1.1. sieć (adresacja IP, itp.),

11.1.2. podsystem dyskowy (punkty montowania/litery dysków, wolumeny logiczne,

grupy wolumenowe, zasoby dyskowe, RAID, itp.),

11.1.3. system operacyjny (parametry jądra, moduły, usługi, stos TCP/IP, itp.),

11.1.4. klaster (węzły fizyczne, paczki klastrowe, kolejność przełączania, itp.),

11.1.5. listę zainstalowanego oprogramowania, itp.;

11.2. Macierze – parametry sprzętowe (cache, półki dyskowe, dyski, karty/porty fibre channel,

itp.), grupy dyskowe, zasoby dyskowe, maskowanie, kopie biznesowe, replikacja, itp.;

11.3. Infrastrukturę sieciową– parametry sprzętowe (porty fibre channel, aktywne licencje, itp.),

fabric, zonning, aliasy, itp.

12. Opis konfiguracji aplikacji/systemu.

12.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.;


12

12.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.

13. Opis architektury logicznej:

– schemat i opis powiązań logicznych poszczególnych komponentów i ich rolę w architekturze.

14. Mapa i opis Interface’ów.

14.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.

15. 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.

16. 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).

17. Procedury tworzenia środowisk pomocniczych.

Zasady i procedury tworzenia środowisk (testowych) oraz metod klonowania i animizacji

(depersonifikacji) danych przenoszonych pomiędzy środowiskami;

18. 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.

19. 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.

20. Procedury backupowe:


13

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.

21. 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.

22. Procedury standardowe:

opis możliwości stosowania standardowych procedur poprawnej eksploatacji dla rozwiązań

wspierających (sprzętowych lub aplikacyjnych).

23. 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.

24. 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).

25. Dokumentacja wdrożeniowa.

25.1. dokumentacja powykonawcza:

zawiera szczegółowy opis wykonanych czynności instalacyjnych oraz konfiguracyjnych wszystkich

komponentów systemu;

25.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;

25.3. dokumentacja uruchomieniowa:

opisuje wszystkie istotne kroki (czynności) wykonane w celu pierwszego uruchomienia

aplikacji/systemu, w tym opis migracji/konwersji danych, testy uruchomieniowe;

26. Dokumentacja szkoleniowa:


14

Materiały szkoleniowe dla użytkowników oraz administratorów (technicznych i bezpieczeństwa).

27. Wersjonowanie:

Opis zasad wersjonowania i sposobu patchowania aplikacji.

28. Historia:

Opis zasad zarządzania danymi historycznymi i archiwalnymi.

29. Zalecenia:

Opis zasad i zaleceń strojenia aplikacji.

IV. Dokumentacja administratora bezpieczeństwa

30. 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ć:

30.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;

30.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;

30.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.;

30.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;

30.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;

30.6. dokumentacja z testów bezpieczeństwa aplikacji wykonanych przez Wykonawcę lub

wykonanych przez niezależną firmę specjalistyczną.


15


Wymagania dotyczące bezpieczeństwa Systemu

I. Wymaganie bezpieczeństwa Systemu

1. System musi być tworzony zgodnie z zaleceniami standardu OWASP-ASVS poziom 2 (Open Web

Application Security Project).

2. System musi być tworzony zgodnie z zaleceniami standardu OWASP Testing Guide, a w

szczególności OWASP - TOP 10 (Open Web Application Security Project).

3. System musi w odpowiedni sposób weryfikować błędy tak aby użytkownikowi końcowemu nie

była prezentowana informacja o błędzie, zawierająca szczegóły techniczne wystąpienia tego

błędu, ujawniające zastosowanie oprogramowania i jego konfigurację. Powinien być generowany

standardowy, niezmienny komunikat o błędzie.

4. System nie może udostępniać poprzez aplikację/usługę plików/katalogów związanych z

konfiguracją czy administrowaniem daną usługą.

5. System musi mieć możliwość ograniczenia korzystania tylko do jednej sesji jednocześnie dla

danego użytkownika, chyba że używanie jednocześnie kilku lub więcej sesji dla danego

pojedynczego użytkownika jest niezbędne w celu wykonania przypisanych mu zadań.

6. System musi wymuszać zakończenie sesji po określonym czasie braku aktywności użytkownika.

7. System musi w odpowiedni sposób weryfikować zawartość pól/formularzy aplikacji pod kątem

wprowadzanych znaków (zastosowanej walidacji oraz kontroli poprawności składni zapytań), w

celu zabezpieczenia przed atakami typu SQL Injection, CrossSiteScripting, itd.

8. Konfiguracja serwera webowego musi wymuszać ustawienie parametru httpOnly w cookies

wysyłanych do użytkownika.

9. System musi zapewniać możliwość separowania uprawnień poprzez mechanizm aplikacyjny

(logika aplikacji) uniemożliwiający realizację wybranych operacji przez jednego użytkownika.

10. System musi zapewniać udzielanie uprawnień użytkowników poprzez profile/role grupujące

pojedyncze uprawnienia.

11. System musi wspierać tryb pracy Mandatory Access Control (MAC) oparty na atrybutach

bezpieczeństwa i politykach (na podstawie atrybutów i polityki udziela się bądź odmawia dostępu

do obiektu).

12. System musi umożliwiać budowanie profili w oparciu o role użytkowników uwzględniające:

a) dostęp do wskazanych funkcji w systemie;


16

b) rozdzielenia ról administracyjnych od biznesowych;

c) administratora bezpieczeństwa/audytora jako oddzielnego profilu;

d) zarządzanie prawami dostępu do danych na poziomie read/write/update/delete;

e) możliwość stworzenia unikalności identyfikatorów użytkownika.

13. System musi w odpowiedni sposób weryfikować udostępnione przez daną aplikację usługi, tak aby

dostępne były tylko niezbędne dla użytkownika zasoby, katalogi i pliki.

14. System musi mieć zsynchronizowany czas w oparciu o wiarygodny wzorzec czasu.

15. System musi zapewniać pełną identyfikowalność i rozliczalność wszystkich czynności

użytkowników, administratorów Systemu:

a) udane/nieudane próby logowania z datą i czasem logowania/wylogowania, identyfikatorem

użytkownika, nazwą stacji i adresem IP z którego nastąpiło logowanie;

b) próby nieautoryzowanego wejścia do systemu/aplikacji;

c) zmiany ustawień zabezpieczeń;

d) śledzenie działań użytkowników lub administratorów, łącznie z śledzeniem działań na menu

systemu/aplikacji.

16. Logi muszą zawierać informację o modyfikacjach związanych z zarządzaniem kontami i

uprawnieniami, w szczególności dotyczące utworzenia, modyfikacji, zablokowania i usunięcia

konta/grupy użytkownika oraz zmiany uprawnień użytkownika.

17. System posiada możliwość przeglądania w systemie czynności z działań użytkowników i

administratorów oraz logów audytowych.

18. System musi zapewniać bezpieczny mechanizm przechowywania logów audytowych.

19. Dostęp do systemu musi być zabezpieczony kontem i hasłem. Hasła muszą spełniać poniższe

wymagania:

a) hasła stosowane w systemie powinny być przechowywane w systemie zawsze w formie

zaszyfrowanej, nie należy stosować haseł w postaci jawnej;

b) hasła muszą być budowane w sposób trudny do odgadnięcia i łatwy do zapamiętania, a

jednocześnie utrudniać odszyfrowanie haseł za pomocą narzędzi do łamania haseł;

20. W szczególności hasła:

a) nie mogą zawierać ciągów znaków tworzących wyrazy słownikowe (np. imion, nazw roślin,

zwierząt itp.);

b) nie mogą zawierać ciągów znaków wynikających z układu znaków na klawiaturze (np.

qwerty5, 2wsx#EDC, itd.);

c) nie mogą zawierać nazwy danego konta/loginu;

d) muszą się składać z co najmniej trzech grup znaków spośród następujących: wielkie litery A-Z,

małe litery a-z, cyfry 0-9, znaki specjalne(!@#$ itd.);


17

e) minimalna zalecana długość hasła użytkowników- 8 znaków;

f) minimalna zalecana długość hasła kont specjalnych, technicznych- 10 znaków;

g) hasła muszą być zmieniane okresowo.

21. Wymagana częstotliwość wymuszenia zmiany haseł użytkowników wynosi 30 dni - w tych

systemach, które posiadają taką funkcjonalność.

22. System musi pamiętać minimum 10 haseł wstecz, w tych systemach, które posiadają taką

funkcjonalność, w celu uniemożliwienia zmiany hasła ponownie na to samo.

23. Należy skonfigurować politykę blokowania kont (konto musi być zablokowane po max. 5

nieudanych próbach logowania). Czas trwania blokady konta - 15 minut.

24. System musi wymuszać zmianę hasła przy pierwszym logowaniu.

25. System musi wymuszać zmianę hasła przy pierwszym logowaniu oraz cyklicznie w trakcie

eksploatowania.

26. Logowanie do systemu musi się odbywać z wykorzystaniem bezpiecznych protokołów tj. min. TLS

1.2 przy użyciu silnych algorytmów szyfrowania minimum AES 256 bits i długości klucza RSA 2048

bits.

27. System musi posiadać dokumentację powykonawczą opisującą wszystkie zastosowane

mechanizmy bezpieczeństwa. Pozytywna ocena udokumentowanych mechanizmów

bezpieczeństwa będzie jednym z warunków dopuszczenia systemu do produkcji.

28. Zamawiający zastrzega sobie prawo do przeprowadzenia audytu bezpieczeństwa aplikacji

webowej przed jej produkcyjnym uruchomieniem. Warunkiem dopuszczenia systemu do działania

produkcyjnego będzie uzyskanie pozytywnych wyników audytu bezpieczeństwa.

29. Wszystkie elementy systemu (systemy operacyjny, baz danych jak i aplikacje) muszą posiadać

zainstalowane wszystkie dostępne poprawki bezpieczeństwa.

30. Środowiska produkcyjne, testowe, developerskie muszą się znajdować w odrębnych strefach

bezpieczeństwa odseparowanych poprzez firewall.

31. System musi umożliwiać przesyłanie informacji/logów/zdarzeń do zewnętrznego systemu

korelacji logów systemu SIEM (Splunk).

II. Dane osobowe

1. System musi zapewniać odnotowanie:

a) identyfikatora użytkownika wprowadzającego dane osobowe;

b) daty pierwszego wprowadzenia danych osobowych;

c) źródła danych, w przypadku zbierania danych nie od osoby, której one dotyczą;

d) zgody/ sprzeciwu dotyczącego przetwarzania danych w celu marketingowym;

e) nazwa i adres podmiotu któremu przekazano dane;

f) data udostępnienia danych;


18

g) zakres udostępnianych danych;

h) podstawa prawna udostępnienia;

i) nazwa komórki/jednostki udostępniającej dane;

j) numer pisma na podstawie którego nastąpiło udostępnienie;

k) imię i nazwisko osoby, która dane udostępniła;

l) nazwa aplikacji, z której udostępniono dane;

m) System musi zapewnić raportowanie dotyczące ustania zobowiązań oraz umożliwiać

odnotowanie daty wycofania zgodny na przetwarzanie Danych Osobowych;

n) numeru upoważnienia użytkownika do przetwarzania danych osobowych (numer

upoważnienia zostanie udostępniony z systemu IDM Zamawiającego ,przy wykorzystaniu

jednej z metod tj. webservice lub plik tekstowy), przy czym numer upoważnienia musi być

powiązany z zakresem uprawnień i ze zbiorem danych.

2. Jeżeli system przetwarza dane osobowe w więcej niż jednym celu, system musi umożliwiać

przyporządkowanie danym osobowym celu przetwarzania.

3. System musi umożliwiać konfigurację maksymalnego czasu przetwarzania danych osobowych dla

każdego celu przetwarzania.

4. System musi powiadamiać operatora o osiągnięciu maksymalnego czasu przetwarzania danych

osobowych dla każdej osoby, której dane są przetwarzane.

5. System musi powiadamiać operatora o zbliżaniu się maksymalnego czasu przetwarzania danych

osobowych dla każdej osoby, której dane są przetwarzane.

6. System powinien umożliwiać administratorowi konfigurację czasu powiadomienia o zbliżaniu się

maksymalnego czasu przetwarzania danych osobowych.

7. System musi umożliwiać eksport danych osobowych dotyczących osoby, której dane są w

systemie przetwarzane oraz informacji wynikających z art. 15 RODO w formie powszechnie i

jednoznacznie zrozumiałej dla tej osoby (np. w postaci PDF).

8. System musi umożliwiać eksport danych osobowych dotyczących każdej osoby, której dane są

w systemie przetwarzane, w powszechnie rozpoznawanym formacie (np. XML / XSD) –

w przypadkach, gdy jest to uzasadnione celem przetwarzania.

9. System musi umożliwiać usunięcie całości danych dotyczących osoby.

10. Jeżeli osoba, której dane dotyczą, samodzielnie wprowadza swoje dane osobowe do systemu,

system musi w szczególności wyświetlać informację o:

a) nazwy i danych kontaktowych organizacji;

b) danych kontaktowych inspektora ochrony danych;

c) celach przetwarzania danych osobowych;

d) kategoriach przetwarzanych danych osobowych;


19

e) podstawie prawnej przetwarzania danych osobowych - w przypadkach uzasadnionych przez

cel przetwarzania;

f) prawnie uzasadnionych interesach realizowanych przez administratora lub stronę trzecią - w

przypadkach uzasadnionych przez cel przetwarzania;

g) odbiorcach danych osobowych lub kategoriach odbiorców;

h) zamiarze przekazania danych do państwa trzeciego lub organizacji międzynarodowej oraz

informację o stosowanych zabezpieczeniach;

i) stwierdzeniu lub braku stwierdzenia przez Komisję Europejską odpowiedniego stopnia

ochrony - w przypadku przekazywania danych do państwa trzeciego lub organizacji

międzynarodowej;

j) możliwości uzyskania dostępu do danych zgodnie z art. 15 RODO;

k) okresie przechowywania danych lub kryteriach ustalania tego okresu;

l) prawie do żądania sprostowania, usunięcia, ograniczenia przetwarzania, wniesienia sprzeciwu

wobec przetwarzania oraz przenoszenia danych - w przypadkach uzasadnionych przez cel

przetwarzania;

m) prawie do wycofania zgody na przetwarzanie - w przypadku, gdy dane są przetwarzane na

podstawie zgody;

n) prawie wniesienia skargi do organu nadzorczego;

o) tym, że podanie danych jest wymogiem ustawowym lub umownym (lub warunkiem zawarcia

umowy), a także zobowiązanie do podania danych i konsekwencje ich niepodania;

p) jeżeli system przetwarza dane w zautomatyzowanym procesie decyzji, w tym poprzez

profilowanie: istotne informacje o zasadach podejmowania decyzji i efektach realizacji ww.

procesu;

q) jeżeli osoba, której dane dotyczą, samodzielnie wprowadza swoje dane, system musi

umożliwiać zapis danych wyłącznie po potwierdzeniu przez nią faktu zapoznania się z

powyższymi informacjami;

r) jeżeli osoba, której dane dotyczą, samodzielnie wprowadza swoje dane osobowe do systemu,

system musi umożliwiać zapis danych wyłącznie po potwierdzeniu zgody na ich

przetwarzanie.

11. System powinien umożliwiać wprowadzenie przez operatora informacji dotyczących w

szczególności:

a) cofnięcia zgody na przetwarzanie danych osobowych;

b) wpływu żądania usunięcia danych;

c) wpływu żądania sprostowania danych;

d) wpływu żądania ograniczenia przetwarzania;


20

e) wpływu żądania dostępu do danych;

f) wpływu sprzeciwu wobec przetwarzania;

g) wpływu żądania niepodlegania zautomatyzowanemu przetwarzaniu danych;

h) wpływu żądania przeniesienia danych.

12. System powinien rejestrować poniższe dane oraz udostępniać interfejs umożliwiający

komunikację z innym systemami w zakresie danych dotyczących poszczególnych osób,

w szczególności:

a) nazwa administratora danych;

b) cel przetwarzania;

c) zakres danych;

d) data wprowadzenia;

e) data importu danych oraz dane identyfikacyjne systemu źródłowego;

f) data i zakres eksportu danych oraz dane identyfikacyjne systemu docelowego;

g) data i zakres modyfikacji danych;

h) data wpływu żądania usunięcia danych;

i) data wpływu wycofania zgody na przetwarzanie;

j) data wpływu żądania sprostowania danych;

k) data i zakres sprostowania danych;

l) data wpływu żądania ograniczenia przetwarzania;

m) data i zakres ograniczenia przetwarzania;

n) data wpływu żądania dostępu do danych zgodnie z art. 15 RODO;

o) data realizacji żądania dostępu do danych zgodnie z art. 15 RODO;

p) data wpływu żądania przeniesienia danych;

q) data realizacji żądania przeniesienia danych;

r) dane podmiotu, do którego dane osobowe zostały przeniesione;

s) data wpływu żądania niepodlegania zautomatyzowanemu przetwarzaniu danych;

t) data realizacji żądania niepodlegania zautomatyzowanemu przetwarzaniu danych;

u) data i forma spełnienia obowiązków informacyjnych;

v) data wpływu sprzeciwu wobec przetwarzania danych;

w) data realizacji sprzeciwu wobec przetwarzania danych;

x) data cofnięcia zgody na przetwarzanie;

y) data wpływu i dane dotyczące skargi do organu nadzorczego;

z) data i zakres przekazania danych do państwa trzeciego lub organizacji międzynarodowej

(jeżeli ma zastosowanie);

aa) planowany termin usunięcia poszczególnych kategorii danych.


21

13. System powinien składować dane osobowe w postaci zaszyfrowanej.

14. System powinien zapewniać szyfrowanie transmisji danych.

15. Minimalnym akceptowanym algorytmem asymetrycznym jest RSA 2048.

16. Minimalnym akceptowanym algorytmem symetrycznym jest AES 128.

17. Minimalnym akceptowanym standardem funkcji skrótu jest SHA-2.


22


Wymagania dotyczące Architektury Systemu

1. Oferowane rozwiązanie musi posiadać trójwarstwową architekturę.

2. W warstwie prezentacji i Aplikacji oferowane rozwiązanie musi zapewniać:

a. możliwość pracy na platformie systemowej Microsoft Windows Server w wersji 2012 R2 (lub

nowszej);

b. możliwość pracy w środowisku wirtualnym opartym o VMware VSphere, 6.x (ESXi Server) lub

nowszym;

c. pracę z wykorzystaniem jednego z serwerów aplikacyjnych: IIS 8 lub wyższej;

d. możliwość wykonywania kopii bezpieczeństwa online za pomocą Avamar 7.4.1 lub kopii image

z CBT;

e. skalowalność, w przypadku zwiększenia wydajności, poprzez zwiększenie liczby serwerów;

f. dostęp do funkcjonalności Systemu dla użytkowników za pośrednictwem standardowej

przeglądarki WWW (co najmniej MS Internet Explorer w wersji 11 lub nowszej, FireFox w

wersji 54 lub nowszej);

g. Możliwość pracy z klientem AV Symantec.

3. W warstwie bazy danych oferowane rozwiązanie musi zapewniać:

a. możliwość pracy na platformie bazy danych MS SQL 2016 lub nowszej;

b. możliwość pracy w środowisku wirtualnym opartym o VMware VSphere, 6.x (ESXi Server) lub

nowszym w przypadku platformy MS SQL;

c. możliwość wykonywania kopii bezpieczeństwa online za pomocą Avamar 7.4.1 lub kopii image

z CBT

d. eksport/import danych do/z plików MS Excel (xls, xslx) oraz plików płaskich (csv., txt) w

zdefiniowanej strukturze i stronie kodowej.

4. Wymagania biznesowe i wydajnościowe:

a. Użytkownicy aplikacji:

i. liczba całkowita użytkowników: zgodnie z główną częścią OPZ;

ii. liczba jednoczesnych użytkowników: zgodnie z główną częścią OPZ;

iii. akceptowalny czas odpowiedzi systemu (wyświetlenia strony dla użytkownika)

poniżej 3 sek.

b. Wymogi wykonywania kopii zapasowych: kopia raz dziennie np. o godzinie 24:00;

c. Dwa środowiska:

i. testowe (jeden serwer aplikacyjny i jeden serwer bazy danych);

ii. produkcyjne (jeden serwer aplikacyjny i jeden serwer bazy danych).

5. Zamawiający na potrzeby realizacji zamówienia może zapewnić następujące zasoby infrastruktury:


23

a. Licencje Microsoft na system operacyjny i bazę danych;

b. Przestrzeń dyskową w maksymalnym wymiarze 50 MB dla aplikacji oraz w maksymalnym

wymiarze 300 GB na bazę danych dla określonej przez Wykonawcę pojemności;

c. Po dwa serwery wirtualne na każde środowisko (testowe i produkcyjne), każdy o

parametrach: 2,8 GHz dual CPU, 128 GB HDD, 16 GB RAM.

6. Zamawiający wykona instalacje oprogramowania na podstawie dostarczonych instrukcji i przy

wsparciu Wykonawcy.

7. W przypadku, jeśli zasoby określone w pkt 5 powyżej udostępniane przez Zamawiającego będą

niewystarczające, Zamawiający wymaga, aby Wykonawca na potrzeby wdrożenia i poprawnej pracy

Systemu dostarczył w ramach wykonania przedmiotu zamówienia (wynagrodzenie zawarte w łącznej

wartości oferty) niezbędne dodatkowe zasoby infrastruktury. W przypadku dostarczenia przez

Wykonawcę infrastruktury sprzętowej Zamawiający wymaga, aby dostarczony sprzęt spełniał

następujące warunki:

a. wszystkie urządzenia muszą być fabrycznie nowe, data produkcji nie wcześniejsza niż rok

2017;

b. wszystkie oferowane urządzenia muszą pochodzić i być serwisowane przez jednego

producenta;

c. urządzenia muszą być wyprodukowane zgodnie z normą jakości ISO 9001:2000 lub normą

równoważną;

d. urządzenia i ich komponenty muszą być oznakowane przez producenta w taki sposób, aby

możliwa była identyfikacja zarówno produktu jak i producenta;

e. serwery muszą mieć możliwość podłączenia do wykorzystywanych urządzeń sieciowych

Zamawiającego N5KC5672UP – Nexus 5672UP Chassis wpięte do FEX N2KC2348UPQ10GE.

Wykonawca dostarczy kompletu wkładek, które muszą pracować z pełną prędkością dla

danego typu portu oraz być kompatybilne ze wskazanymi urządzeniami sieciowymi

Zamawiającego;

f. serwery muszą mieć możliwość bezkosztowego dołączenia do SAN Zamawiającego

zbudowanej w oparciu o posiadane switche HP SN6000B (FOS 7.4.x lub wyższy) i HP SAN

Switch 8Gb 40/40 (FOS 7.4.x lub wyższy);

g. wszystkie urządzenia muszą mieć możliwość zainstalowania w szafach Rack 19’’, a

Wykonawca dostarczy wszystkie elementy montażowe wymagane do ich zainstalowania;

h. wszystkie serwery i inne urządzenia muszą zajmować maksimum wysokość 10 U;

i. wszystkie serwery i inne urządzenia muszą posiadać dwa redundantne zasilacze;

j. każdy serwer musi dodatkowo spełniać następujące wymagania:


24

i. typ obudowy typu rack. Zamawiający dopuszcza serwery typu blade, wówczas serwer

musi mieć możliwość instalacji w obudowie cClass BladeSystem 7000 posiadanych przez

Zamawiającego;

ii. maksimum 2U (obudowa rack);

iii. procesor x86_64, najnowszej generacji na dzień składania oferty;

iv. minimum 1 procesor z szybkością minimum 3.0 GHz z minimum 4 rdzeni per CPU;

v. minimum 32 GB pamięci RAM z możliwością rozbudowy do 512 GB;

vi. dla serwerów rack kontroler dysków: RAID 0, 1 z minimum 2 dyskami SSD hotplug o

pojemności min. 300 GB każdy;

vii. minimum 2 porty 1 GbE każdy dla połączeń sieciowych;

viii. interfejsy Fibre Channel Min. 2 porty min. 8Gb/s każdy – redundantnie podłączone do

dwóch sieci fabric SAN. Dla serwerów blade interfejsy muszą być zgodne z modułami HP

Virtual Connect FlexFabric20/40 F8 Module for cClass BladeSystem posiadanymi przez

Zamawiającego;

ix. zarządzanie za pomoc zdalnej konsoli graficznej z możliwością mapowanie wirtualnych

mediów (CD/DVD/pliki *.iso), monitorowania mocy i poprawności pracy komponentów

serwera, włączenia/restartu/wyłączenia serwera;

x. obsługa Windows 2012 R2/2016 lub nowszych oraz VMware 6.0 i 6.5 lub wyższych.


25


Procedura składania i odbioru zleceń dotyczących zamówienia usług parametryzacji i modyfikacji

Systemu w ramach realizacji Prawa opcji

Zamawiający będzie zlecał Wykonawcy usługi za pośrednictwem poczty elektronicznej na adres

przedstawiciela wskazany w Umowie, zgodnie z następującymi zasadami:

1. Zamawiający przekaże krótki opis zakresu usługi, niezbędne kryteria jakościowe oraz oczekiwany

termin jej wykonania (zlecenie wstępne) i zwróci się do Wykonawcy o przedstawienie możliwości

realizacji usługi; kalkulacja i terminy mogą zostać doprecyzowane lub zmodyfikowane w trakcie

bezpośrednich uzgodnień Zamawiającego i Wykonawcy, przy czym stawka za roboczogodzinę nie

może być wyższa, niż zadeklarowana przez Wykonawcę w ofercie;

2. W terminie 5 dni od otrzymania zlecenia wstępnego Wykonawca przekaże Zamawiającemu analizę

prac, w której określi możliwości realizacji usługi podając pracochłonność (liczbę roboczogodzin) oraz

szacowany termin rozpoczęcia i zakończenia prac. Terminy i pracochłonność zadeklarowane przez

Wykonawcę będą podlegały uzgodnieniu i akceptacji przez Zamawiającego;

3. Zamawiający najpóźniej w terminie 10 dni kalendarzowych licząc od dnia otrzymania analizy zlecenia

wstępnego:

a) poinformuje pisemnie Wykonawcę o udzieleniu mu zlecenia (dalej „Zlecenie”),

b) zobowiąże Wykonawcę do uzupełnienia lub poprawienia analizy Zlecenia w terminie 3 dni

kalendarzowych i ponownie rozpatrzy ją zgodnie w opisaną procedurą, albo

c) poinformuje Wykonawcę o nieudzieleniu mu Zlecenia.

4. Jeżeli w terminie 10 dni kalendarzowych licząc od dnia otrzymania analizy zlecenia wstępnego

Zamawiający nie udzieli Wykonawcy odpowiedzi, Strony przyjmują, że Zamawiający zrezygnował z

realizacji Zlecenia. Realizacja przez Wykonawcę Zlecenia bez wyraźnej akceptacji zamówienia przez

Zamawiającego następuje wyłącznie na koszt i ryzyko Wykonawcy.

5. Osobą uprawnioną ze strony Zamawiającego do zawarcia i podpisania Zlecenia na usługi modyfikacji

Systemu jest osoba posiadająca stosowne pełnomocnictwa, zgodne z przedmiotem i wartością

danego zamówienia.

6. Wynagrodzenie z tytułu zrealizowanych usług płatne będzie na podstawie faktury VAT, po odebraniu

przez Zamawiającego danych rezultatów prac Wykonawcy. Warunkiem wystawienia przez

Wykonawcę faktury VAT jest podpisanie – z zastrzeżeniem pkt. 7 poniżej - przez Zamawiającego bez

uwag odpowiedniego Protokołu Odbioru Modyfikacji oraz udzieleniu Zamawiającemu licencji wraz z

opisem i Dokumentacją dotyczących nowej funkcjonalności.

7. W szczególnie uzasadnionych przypadkach, uzgodnionych pomiędzy Stronami w toku bieżących prac,

Zamawiający może podjąć decyzję o warunkowym odbiorze danej usługi, dla której podczas odbioru

zidentyfikowane zostały jedynie drobne nieprawidłowości. W takim przypadku w Protokole Odbioru


26

Modyfikacji zostanie dodane zobowiązanie Wykonawcy do usunięcia stwierdzonych usterek, o

następującej treści: „odbiór dokonywany jest warunkowo”, oraz że „Wykonawca zobowiązany jest do

usunięcia stwierdzonych nieprawidłowości w nieprzekraczalnym terminie …… dni, uzgodnionym

przez Strony”;

8. W Protokole Odbioru Modyfikacji zostaną wskazane:

a) opis wykonanych prac;

b) liczba roboczogodzin poświęconych na wdrożenie rozwiązania, z zastrzeżeniem iż nie może być

ona wyższa, niż wynikająca ze Zlecenia;

c) w przypadku usług realizowanych w ramach Prawa opcji wskazana zostanie także liczba

roboczogodzin pozostałych do wykorzystania w ramach limitu określonego w Umowie.

9. Osobą upoważnioną do podpisywania Protokołów Odbioru Modyfikacji lub zgłaszania uwag ze strony

Zamawiającego będzie przedstawiciel określony w Umowie. Zamawiający zastrzega sobie prawo do

dopuszczenia do udziału w czynnościach odbiorczych osób trzecich w postaci ekspertów, specjalistów

lub biegłych.

10. Po wykonaniu przez Wykonawcę usług modyfikacji zlecanych przez Zamawiającego w Zleceniu i po

stwierdzeniu prawidłowości funkcjonowania całego wdrożonego rozwiązania (wykonanie testów

przez Zamawiającego) Strony podpiszą Protokół Odbioru Modyfikacji. W razie stwierdzenia

nieprawidłowości w funkcjonowaniu wdrożonego rozwiązania lub zastrzeżeń do Dokumentacji,

Zamawiający określi listę zastrzeżeń wobec przedmiotu odbioru w ciągu 5 dni liczonych od dnia

zgłoszenia przez Wykonawcę Zamawiającemu zrealizowania modyfikacji;

11. Wykonawca w ciągu 5 dni po otrzymaniu listy zastrzeżeń, o której mowa w pkt 10 powyżej, usunie je i

zgłosi gotowość do ponownego odbioru, wówczas ponownie rozpoczyna się procedura określona w

pkt 10 powyżej. Procedurze ponownego odbioru rozwiązania podlega całość wdrożonej modyfikacji,

a w szczególności zastrzeżenia wyszczególnione na liście zastrzeżeń przekazanej przez Zamawiającego

po zgłoszeniu przez Wykonawcę gotowości do dokonania odbioru modyfikacji oraz inne zastrzeżenia

powstałe podczas usuwania zgłoszonych głównych zastrzeżeń, chyba że Strony pisemnie, pod

rygorem nieważności, postanowią inaczej. Procedura ponownego odbioru może zostać powtórzona

nie więcej niż 3 razy, a w przypadku przekroczenia liczby powtórzeń odbioru Zamawiający ma prawo

do rezygnacji z realizacji zleconej modyfikacji lub wypowiedzenia Umowy w części jeszcze

niewykonanej (w takim wypadku Wykonawcy nie przysługuje wynagrodzenie za prace, które nie

zostały odebrane przez Zamawiającego z uwagi na zgłoszone zastrzeżenia).

12. Protokoły Odbioru Modyfikacji wystawiane i podpisywane będą przez Strony w 2 jednobrzmiących

egzemplarzach, po jednym dla każdej Strony. Kopia protokołu odbioru będzie dołączana przez

Wykonawcę do wystawionej faktury.

I. Dokumentacja dotycząca nowych funkcjonalności systemu


27

Zamawiający wymaga, aby po wdrożeniu każdej nowej funkcjonalności (wytworzonej w ramach realizacji

Prawa opcji) Wykonawca sporządził oraz dostarczył zaktualizowaną dokumentację Systemu.

II. Wymagania dotyczące przekazania wiedzy związanej z rozbudową systemu

1. Zamawiający, w ramach wynagrodzenia, oczekuje przekazania wiedzy przez Wykonawcę wskazanym

przez Zamawiającego użytkownikom i administratorom dotyczącej wprowadzanych zmian w

Systemie, która polegać będzie na przeprowadzeniu prezentacji opisujących działanie nowych

funkcjonalności Systemu.

2. Przekazanie wiedzy odbędzie się w siedzibie Zamawiającego w terminie ustalonym przez Strony po

wykonaniu Zlecenia.

Sygnatura postępowania: DZZK/29/DST/2018 - bgk.pl · szczególności nieprawidłowości w...

Documents

Transcript of Sygnatura postępowania: DZZK/29/DST/2018 - bgk.pl · szczególności nieprawidłowości w...