Opis przedmiotu zamówienia (zwany dalej OPZ )

Transkrypt

1 Załącznik nr 2 do SIWZ Opis przedmiotu zamówienia (zwany dalej OPZ ) 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 ii. iii. iv. 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); 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); instalację, migrację danych testowych, konfigurację, parametryzację Systemu na środowisku testowym oraz przeprowadzenie testów integracyjnych, akceptacyjnych, wydajnościowych, bezpieczeństwa; 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; 1

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

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ń 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 Awaria Błąd Usterka Czas Naprawy Do 2 dni roboczych Do 5 dni roboczych Do 10 dni roboczych Przy czym: 3

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; 4

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 Wykonawca zobowiązany jest do przekazania wiedzy dotyczącej obsługi Systemu użytkownikom wyznaczonym przez Zamawiającego: 5

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 Wykonawca zobowiązany jest przedstawić harmonogram realizacji wdrożenia Systemu uwzględniający: 6

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

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ą. 8

9 Załącznik nr 1 do OPZ Wymagania na dokumentację oprogramowania (dokumentacja powdrożeniowa) I. Wymagania ogólne 1. Język Dokumentacja powinna być dostarczona w języku polskim. 2. Postać i forma Dokumentacja powinna być pogrupowana tematycznie i zawierać spis i charakterystykę wszystkich składników dokumentacji oraz powinna być dostarczona: w postaci papierowej, w formie spiętych, zszytych lub zbindowanych egzemplarzy, 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 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 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 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 9

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 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 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 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; 10

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ć: opis architektury technicznej; 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), dla komponentów innych dostawców, należy dokładnie określić wykorzystywane i dopuszczalne wersje; Konfiguracja musi obejmować wszystkie urządzenia wdrożone, zainstalowane w ramach budowy systemu IT. 11. Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje: Serwery parametry sprzętowe (procesor, pamięć, dyski, karty sieciowe, zasilanie, itp.); sieć (adresacja IP, itp.), podsystem dyskowy (punkty montowania/litery dysków, wolumeny logiczne, grupy wolumenowe, zasoby dyskowe, RAID, itp.), system operacyjny (parametry jądra, moduły, usługi, stos TCP/IP, itp.), klaster (węzły fizyczne, paczki klastrowe, kolejność przełączania, itp.), listę zainstalowanego oprogramowania, itp.; Macierze parametry sprzętowe (cache, półki dyskowe, dyski, karty/porty fibre channel, itp.), grupy dyskowe, zasoby dyskowe, maskowanie, kopie biznesowe, replikacja, itp.; Infrastrukturę sieciową parametry sprzętowe (porty fibre channel, aktywne licencje, itp.), fabric, zonning, aliasy, itp. 12. Opis konfiguracji aplikacji/systemu 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.; 11

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

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 dokumentacja powykonawcza: zawiera szczegółowy opis wykonanych czynności instalacyjnych oraz konfiguracyjnych wszystkich komponentów systemu; 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; 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: 13

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ć: 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; 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; 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.; 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; 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; dokumentacja z testów bezpieczeństwa aplikacji wykonanych przez Wykonawcę lub wykonanych przez niezależną firmę specjalistyczną. 14

15 Załącznik nr 2 do OPZ 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; 15

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

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; 17

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

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

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

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 Minimalnym akceptowanym algorytmem symetrycznym jest AES Minimalnym akceptowanym standardem funkcji skrótu jest SHA-2. 21

22 Załącznik nr 3 do OPZ 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 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 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: 22

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

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