wymagania techniczne - bip.wat.edu.pl · web viewoprogramowanie musi oferować gotowe do użytku...

Załącznik nr 3A do SIWZ

Wymagania techniczne na systemy infrastruktury i serwerownię

Spis treści

1 Zakres rozwiązania 3

2 Wymagania na komponenty serwerowni 5

2.1 Wymagania infrastruktury sprzętowej rozwiązania 5

2.1.1 Obudowa dla serwerów kasetowych 5

2.1.2 Przełączniki LAN instalowane wewnątrz obudowy 6

2.1.2.1 Wymagania na funkcjonalność warstwy L2 6

2.1.2.2 Wymagane funkcjonalności warstwy L3 7

2.1.2.3 Wymagane funkcjonalności z obszaru QoS 7

2.1.2.4 Wymagane funkcjonalności z obszaru zarządzania 7

2.1.3 Infrastruktura serwerów typu kasetowego – wymagania ogólne 8

2.1.4 System zarządzania środowiskiem serwerowym8

2.1.4.1 Oprogramowanie do systemu zarządzania serwerami kasetowymi 8

2.1.4.2 Konsola do systemu zarządzania serwerami kasetowymi 10

2.1.5 Szafy montażowe – rack 10

2.1.6 Pamięć Dyskowa 11

2.1.6.1 Wirtualizator pamięci dyskowych 11

2.1.6.2 Macierz dyskowa 11

2.1.6.3 Przełączniki SAN 12

2.1.6.4 Pamięć masowa typu flash 13

2.1.7 Pamięć taśmowa 14

2.1.7.1 Biblioteka taśmowa 14

2.1.8 Oprogramowanie do wirtualizacji zasobów serwerowych 15

2.2 System kopii zapasowych 16

2.2.1 Wymagania dla dedykowanego serwera systemu kopii zapasowych 16

2.2.2 Oprogramowanie systemu kopii zapasowych 17

2.3 Chmura Akademicka 20

2.3.1 Serwery chmury akademickiej 21

2.3.2 Oprogramowanie do zarządzania zasobami chmury akademickiej 22

2.3.3 Oprogramowanie udostępniane w Chmurze Akademickiej 24

2.3.3.1 System operacyjny 25

1 / 62


2.3.3.2 Serwer bazy danych 25

2.3.3.3 Serwer aplikacji 27

2.3.3.4 Oprogramowanie do projektowania procesów biznesowych i integracji 28

2.3.3.5 Silnik procesów biznesowych 30

2.3.3.6 Platforma integracyjna 32

2.3.3.7 Środowisko zarządzania cyklem wytwórczym oprogramowania (CWO) 34

2.3.3.8 Zintegrowana platforma analityczna 42

2.3.3.9 Środowisko do rozwiązywania problemów optymalizacji 43

2.3.3.10 Oprogramowanie do konfiguracji procesu projektowania system

informatycznego 44

2.3.3.11 Oprogramowanie do testowania zabezpieczeń aplikacji 45

2.4 Wirtualne desktopy 46

2.4.1 Serwer kasetowy x86 dla potrzeb chmury wirtualnych desktopów 46

2.4.2 Oprogramowanie do zarządzania wirtualnymi desktopami 47

2.5 High Performance Computing 49

2.5.1 Serwer kasetowy – Węzeł obliczeniowy x86 + GPU 49

2.5.2 Węzeł zarządzający / Serwer plików 50

2.5.3 Oprogramowanie zarządzające klastra HPC 51

2.5.3.1 Wymagania dotyczące dostępu do Oprogramowania Zarządzającego 52

2.5.3.2 Wymagania dotyczące Resource Scheduler’a 52

2.5.3.3 Wymagania funkcjonalne dla Oprogramowania Zarządzającego 52

2.5.4 Oprogramowanie systemu plików 53

3 Wymagania na systemy infrastruktury wyposażenia serwerowni 55

3.1 Podłoga techniczna oraz system zasilania gwarantowanego 55

3.2 Instalacja klimatyzacji 56

3.3 System sygnalizacji pożaru oraz gaszenia gazowego 56

4 Zakres prac wdrożeniowych uruchomienia funkcjonalnego serwerowni 58

4.1 Szkolenia 61

5 Wymagania gwarancyjne 64

2 / 62


1 Zakres rozwiązaniaCelem realizacji zamówienia jest zbudowanie kompletnego środowiska informatycznego wraz z adaptacją wskazanego pomieszczenia (sala 04 w budynku nr 65), gdzie znajdować się będzie infrastruktura informatyczna niezbędna do zbudowania rozwiązania.Rozwiązanie ma na celu dostarczenie następujących funkcjonalności: chmura akademicka, której celem jest dostarczanie infrastruktury oraz oprogramowania na

potrzeby zbudowania platformy pozwalającej na budowanie środowisk deweloperskich służących zarówno do prowadzenia aktywności dydaktycznej jak i badań naukowych. Chmura akademicka ma umożliwiać tworzenie co najmniej następujących środowisk:

Relacyjna baza danych (RBD), Platforma aplikacji Java (PAJ), Platforma integracyjna (PI), Modelowanie procesów biznesowych (MPB), Silnik procesów biznesowych (SPB), Środowisko zarządzania całym cyklem wytwórczym oprogramowania (CWO).

Szczegółowy opis funkcjonalności platformy chmury akademickiej oraz środowisk udostępnianych na niej został przedstawiony w dalszej części dokumentu.

chmura obliczeniowa, której zadaniem jest dostarczenie rozwiązań HPC (ang. High Performance Computing) dla potrzeb edukacyjnych jak i badań naukowych. Ze względu na różnorodność zadań, jakie będą realizowane przez wysoce specjalizowany sprzęt HPC, konieczne jest zapewnie oprogramowania zarządzającego środowiskiem HPC, umożliwiającego zarządzanie zadaniami realizowanymi w tym środowisku.

wirtualne desktopy umożliwiające dostęp do zasobów chmury akademickiej i obliczeniowej zarówno ze stanowisk znajdujących się w salach laboratoryjnych jak i z komputerów pracujących w sieci kampusu akademickiego.

W celu zapewniania możliwości instalacji sprzętu oraz oprogramowania wymagane będzie dostosowanie przestrzeni pomieszczenia serwerowni w zakresie: chłodzenia, zasilania, podłogi technicznej, gaszenia.Szczegółowe wymagania dotyczące systemów infrastruktury wyposażenia serwerowni wraz z modernizacją pomieszczenia serwerowni i zapewnienia odpowiedniego zasilania zostały przedstawione w dalszej części dokumentu.

Rozwiązanie musi składać się z następujących komponentów sprzętowej infrastruktury informatycznej: Sieć SAN (ang. Storage Area Network), Siec LAN (ang. Local Area Network), System kopii zapasowych, Pamięć masowa, Serwery sprzętowe.

3 / 62


Rysunek 1. Elementy składowe rozwiązania

4 / 62

Chmura AkademickaChmura

Obliczeniowa Wirtualne Desktopy

Sieć LAN 10 Gb

Komputery w salach laboratoryjnych i komputerystudentów i pracowników Uczelni

System kopii zapasowych

Sieć SAN

Pamięć Dyskowa Pamięć Taśmowa

Pamięć masowa


2 Wymagania na komponenty serwerowni

2.1 Wymagania infrastruktury sprzętowej rozwiązaniaJednym z celów projektu jest zbudowanie jak najbardziej jednolitego środowiska informatycznego realizującego zadania zarówno chmury akademickiej, obliczeniowej jak, wirtualnych desktopów oraz komponentów technicznych wykorzystywanych do zarządzania rozwiązaniem.Wymagane jest dostarczenie sprzętu i oprogramowania opisanych w niniejszym punkcie z 5 letnim okresem wsparcia technicznego świadczonego przez producenta sprzętu i oprogramowania.

2.1.1 Obudowa dla serwerów kasetowych

Nazwa elementu, parametru lub cechy

Opis

Liczba Zależna od liczby proponowanych serwerów kasetowych, jednak nie więcej niż 2 obudowy na szafę RACK.

Typ obudowy dla serwerów kasetowych

Do montażu w szafie RACK 19”

Wysokość obudowy Maksymalnie 10U

Liczba montowanych serwerów

Możliwość zainstalowania minimum: - 7 serwerów zawierających 4 układy procesorowe (socket), - 14 lub 28 serwerów zawierających 2 układy procesorowe (socket) umieszczonych w ramach jednej obudowy kasetowej. Wymagana możliwość równoczesnej instalacji serwerów 4 i 2 socketowych w ramach jednej obudowy.

Rodzaj obsługiwanych serwerów

Możliwość umieszczania w ramach jednej obudowy serwerów z procesorami architekturze x86 oraz RISC / EPIC.

Sposób agregacji/wyprowadzeń sygnałów LAN

W oparciu o min. 2 przełączniki 10Gb Ethernet opisane w punkcie 2.1.2

Sposób agregacji/wyprowadzeń sygnałów FC

W oparciu o min. 2 przełączniki 16Gb FCKażdy moduł FC instalowany w obudowie musi posiadać aktywne min. 48 portów FC 16Gb.Każdy moduł FC instalowany w obudowie musi posiadać min. 4 zewnętrzne porty obsadzone modułami SFP 16Gb FCW przypadku braku wymaganej liczby portów w przełącznikach montowanych w dostarczanych obudowach dopuszcza się zastosowanie dodatkowych przełączników FC zewnętrznych dla obudowy przy zachowaniu pełnej redundancji i funkcjonalności – tj. min. dwa moduły FC 16Gb montowane w obudowie wyprowadzające wszystkie porty FC dostępne w serwerach i min. dwa zewnętrzne przełączniki na każdą dostarczoną obudowę spełniające wymóg aktywnych min. 48 portów FC

Zasilanie i chłodzenie

Zasilacz o konstrukcji modularnej z możliwością dokładania i wymiany modułów na gorąco. System zasilania zainstalowany wewnątrz obudowy, zdolny do dostarczenia mocy, jaką może potrzebować obudowa w pełni obsadzona serwerami i wszystkimi możliwymi opcjami (serwery w pełni obsadzone opcjami). Gwarantujące instalacje

5 / 62


min. 14 serwerów, gdzie w każdym zainstalowane będą procesory o TDP równym 135W. Zasilanie typu hot-swap oraz redundancja typu N+N.

Zarządzanie Zdalne włączanie/wyłączanie/restart niezależnie dla każdego serwera. Zdalne udostępnianie napędu CD-ROM, FDD, obrazu ISO na potrzeby serwera z możliwością bootowania z w/w napędów. Zdalna identyfikacja fizycznego serwera i obudowy za pomocą sygnalizatora optycznego. Dostęp zdalny z poziomu przeglądarki internetowej bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Co najmniej, 2 moduły zarządzania w ramach obudowy w celu zapewnienia redundancji. W danym momencie musi być niezależny, równoległy dostęp do konsol tekstowych i graficznych wszystkich serwerów w ramach infrastruktury. Graficzna wizualizacja statusów komponentów.

Oprogramowanie zarządzające

Oprogramowanie pochodzące od producenta serwerów.

2.1.2 Przełączniki LAN instalowane wewnątrz obudowyWymagane jest dostarczenie min. 2 przełączników 10Gb Ethernet na każdą obudowę serwerów kasetowych.Urządzenia muszą umożliwić wyprowadzenie sygnału ze wszystkich fizycznych portów Ethernet w każdym serwerze dostarczanym wraz z obudową. Na każdą obudowę serwerową minimum 20 aktywnych portów zewnętrznych o przepustowości 10Gb Ethernet oraz min. 2 aktywne porty o przepustowości min. 40Gb Ethernet. W każdej obudowie zamontowane min. 10 modułów SFP+ 10Gb oraz min. 4 moduły RJ45 1Gb. Dla każdej dostarczonej pary przełączników LAN wymagane jest dostarczenie min. 2 kabli Twinax / DAC pozwalających na połączenie modułów LAN z przepustowością min. 40GbMożliwość rozbudowy każdego przełącznika agregującego do min. 56 fizycznych portów 10Gb Ethernet. bez konieczności wymiany urządzenia. Wsparcie w każdym dostarczonym urządzeniu sieciowym dla standardu Ethernet 40Gb.

2.1.2.1 Wymagania na funkcjonalność warstwy L2

Wymagania na funkcjonalność warstwy L2 (modelu OSI): Address Resolution Protocol (ARP) RFC 826 High availability/In-Service Software Upgrade—hardware-enabled IGMP v1/v2 Snooping MAC Learning and Aging Link Aggregation Control Protocol (LACP) IEEE 802.3ad/802.1AX Virtual Local Area Networks (VLANs) VLAN Encapsulation 802.1Q Private VLANs Edge loop detection (ELD) Per-VLAN Spanning Tree (PVST+/PVRST+) Rapid Spanning Tree Protocol (RSTP) 802.1w Multiple Spanning Tree Protocol (MSTP) 802.1s STP PortFast, BPDU Guard, BPDU Filter STP Root Guard Layer 2 Access Control Lists (ACLs) Pause Frames 802.3x Uni-Directional Link Detection (UDLD)

2.1.2.2 Wymagane funkcjonalności warstwy L3

Wymagania na funkcjonalność warstwy L3 (model OSI): Border Gateway Protocol (BGP),

6 / 62


DHCP Helper, Layer 3 ACLs, Multicast: PIM-SIM, OSPF, Static Routes, VRF Lite, VRF-aware OSPF, VRRP, static routes, VRRP-E, IPv4/IPv6 dual stack, IPv6 ACL packet filtering, IPv6 routing.

2.1.2.3 Wymagane funkcjonalności z obszaru QoS

Wymagania na funkcjonalność z obszaru QoS: ACL-based QoS, Eight priority levels for QoS, Class of Service (CoS) IEEE 802.1p, DSCP Trust, DSCP to Traffic Class Mutation, DSCP to CoS Mutation, DSCP to DSCP Mutation, Random Early Discard, Per-port QoS configuration, ACL-based Rate Limit, Dual-rate three color token bucket, ACL-based remarking of CoS/DSCP/Precedence, ACL-bases sFlow, Scheduling Strict Priority (SP), Deficit Weighted Round-Robin (DWRR), Hybrid Scheduling (Hybrid), Queue-based Shaping.

2.1.2.4 Wymagane funkcjonalności z obszaru zarządzania

Wymagania na funkcjonalność z obszaru zarządzania: IPv4/IPv6 management, Industry standard Command Line Interface, Netconf API, REST API with YANG data model, Integration with OpenStack, Link Layer Discovery Protocol (LLDP) IEEE 802.1AB, Logical chassis management, MIB II RFC 1213 MIB, Switch Beaconing, Switch Port Analyzer (SPAN), SNMPv3 (default) and SNMPv1, sFlow RFC 3176, Out-of-band management, Remote SPAN (RSPAN), RMON-1, RMON-2, NTP, Management Access Control Lists (ACLs), Role-Based Access Control (RBAC), Range CLI support, UDLD, OpenStack Neutron ML2 plugin.

7 / 62


W przypadku braku wymaganej liczby portów i wsparcia dla powyższych standardów komunikacyjnych w przełącznikach montowanych w dostarczanych obudowach dopuszcza się zastosowanie dodatkowych przełączników LAN zewnętrznych dla obudowy przy zachowaniu pełnej redundancji i funkcjonalności – tj. min. dwa moduły LAN montowane w obudowie wyprowadzające wszystkie porty Ethernet dostępne w serwerach i min. dwa zewnętrzne przełączniki na każdą dostarczoną obudowę spełniające wymóg rozbudowy do min. 56 portów oraz gwarantujące te same funkcjonalności warstwy L2, L3, QoS oraz zarządzania jak przełączniki montowane w obudowie.

2.1.3 Infrastruktura serwerów typu kasetowego – wymagania ogólneWymagania szczegółowe dla serwerów kasetowych realizujących poszczególne funkcje Platformy są opisane w dalszej części dokumentu

Wymaganie Opis

Globalne Urządzenia muszą być fabrycznie nowe i dostępne na rynku od co najmniej 3 miesięcy.

Normy Muszą być wyprodukowane zgodnie z normą jakości ISO 9001:2000 lub normą równoważną

Oznakowanie Urządzenia i ich komponenty muszą być oznakowane przez producentów w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta.

Dokumentacja Do każdego urządzenia musi być dostarczony komplet standardowej dokumentacji dla użytkownika w formie papierowej lub elektronicznej.

Certyfikaty Wszystkie serwery muszą posiadać Certyfikat „B” (dla obudowy) lub oznakowanie CE produktu albo spełniać normy równoważne.

Współpraca z siecią energetyczną

Wszystkie urządzenia muszą współpracować z siecią energetyczną o parametrach: 230 V ± 10%, 50 Hz.

2.1.4 System zarządzania środowiskiem serwerowymNależy dostarczyć sprzęt i oprogramowanie dla systemu zarządzania środowiskiem serwerowym w liczbie niezbędnej do zarządzania wszystkimi serwerami kasetowymi rozwiązania.

2.1.4.1 Oprogramowanie do systemu zarządzania serwerami kasetowymi

Poniżej opisano wymagania na oprogramowanie do systemu zarządzania serwerami kasetowymi.

Wymaganie Opis

Zarządzania warstwami

Rozwiązanie musi zostać wyposażone w jednolity interfejs do zarządzania dla poniższych warstw środowiska:- warstwa serwerów fizycznych- warstwa serwerów wirtualnych- warstwa sieci komunikacyjnej- warstwa macierzy dyskowej

Monitorowanie i zgłaszanie awarii

Monitorowanie sprzętu i automatyczne zgłaszanie problemów do jednostki serwisującej sprzęt. W szczególności podgląd do min. 4 obudów serwerowych i komponentów zainstalowanych w obudowie w czasie rzeczywistym z jednej konsoli zarządzającej

Dostępność Wymagana funkcjonalność dostępna z jednej konsoli zarządzającej dostarczanej przez producenta sprzętu:- statusy komponentów

8 / 62


- nazwy komponentów i ich adresy IP- numer seryjny i serwisowy- monitorowanie poziomu zainstalowanego mikrokodu- monitorowanie poziomu temperatury i pobory mocy poszczególnych elementów- automatyczne wykrywanie problemów w obudowie oraz automatyzacja akcji realizowanych w odpowiedzi na powstające problemy- monitorowanie komponentów pod kątem anomalii – system przedwczesnego wykrywania awarii- monitorowanie utylizacji poszczególnych elementów serwera typu: - wykorzystanie procesora, - wykorzystanie pamięci - wykorzystanie zasobów dyskowych- automatyczne wykrywanie fizycznych i wirtualnych serwerów- tworzenie inwentaryzacji sprzętu z możliwością eksportu do pliku- zarządzanie zasobami sieciowymi- zarządzanie przełącznikami sieciowymi zainstalowanymi w obudowie- monitoring stanu przełączników sieci SAN, LAN- tworzenie graficznych widoków topologii sieci LAN/ SAN- funkcja konfiguracji VLAN na dostarczonych przełącznikach sieciowych.- zarządzanie pamięciami masowymi- obsługa fizycznych i wirtualnych pamięci masowych- inwentarz fizycznej konfiguracji pamięci masowych - monitorowanie stanu macierzy- zarządzanie wolumenami wirtualnymi: tworzenie, wykrywanie, inwentaryzacja, modyfikacja, usuwanie

Zarządzanie zasobami zwirtualizowanymi

Wymagane funkcje z obszaru zarządzania zasobami zwirtualizowanymi:- integracja z oprogramowaniem wirtualizacyjnym min. 3 dostawców- tworzenie wirtualnych serwerów- modyfikacja serwerów wirtualnych- zarządzanie serwerami wirtualnymi- przenoszenie serwerów wirtualnych- wizualizacja serwerów wirtualnych w powiązaniu z fizycznymi

Zarządzanie zdalne Wymagane funkcje z obszaru zarządzania zdalnego:- zdalny dostęp do konsoli - zdalna klawiatura, mysz, video- montowanie zasobów wirtualnych takich jak CD/DVD/ISO/USB- funkcja włączenia/wyłączenia/restartu serwerów zdalnie- automatyczne wykrywanie problemów- powiadamianie o aktualnym poziomie mikrokodu- automatyczne powiadamianie serwisu w przypadku wykrycia awarii

2.1.4.2 Konsola do systemu zarządzania serwerami kasetowymi

Poniżej opisano wymagania na konsolę do systemu zarządzania serwerami kasetowymi.

Nazwa elementu,parametru lub cechy

Opis wymagań

Liczba 1 sztuka

Obudowa instalowana w obudowie opisanej w punkcie 2.1.1

9 / 62


Procesor W architekturze x86

Pamięć cache Min. 20 MB

Liczba układów procesorowych w każdym serwerze / rdzeni

min. 1

Pamięć RAM Min. 32GB

Dyski twarde Min. 2 x 200GB SSD oraz 1TB SATA HDD

Interfejs FC możliwość instalacji

Interfejsy sieciowe min. 2 interfejsy sieciowe 10Gb Ethernet z cechami typu:

Funkcje zarządzania Zgodne z opisem zawartym w punkcie 2.1.4.1

2.1.5 Szafy montażowe – rack Należy dostarczyć szafy montażowe spełniające poniższe wymagania.

Wymaganie Opis

Szafa rack Zamawiający wymaga dostarczenia min. 3 szaf RACK 19’’ o głębokości min. 1200 mm, szerokości do 800mm i wysokości min. 42U. Każda szafa musi być wyposażona w minimum 2 PDU z odpowiednią liczbą gniazd do połączenia oferowanych urządzeń. Każde z PDU musi być wyposażone w kabel zakończony wtyczką trójfazową IEC 309

Konsola LCD Zamawiający wymaga dostarczenia minimum 1 konsoli LCD do zainstalowania w szafie RACK (wysokość maksymalna 1U), z klawiaturą i urządzeniem wskazującym.

KVM (przełącznik: klawiatura, video, myszka)

Zamawiający wymaga dostarczenia minimum 1 urządzenia 16 portowego typu KVM z możliwością połączenia poprzez protokół IP.

2.1.6 Pamięć DyskowaW celu zapewnienia maksymalnego wykorzystania oraz elastycznego rekonfigurowania zasobów w zależności od potrzeb w środowisku chmury konieczne jest dostarczenie mechanizmów wirtualizacji pamięci dyskowej. Ze względu na przeznaczenie infrastruktury pod zastosowania wymagające różnych czasów odpowiedzi pamięci dyskowych rozwiązanie musi zapewnić komponenty sprzętowe typu flash, SDD jak i dyski obrotowe HDD.

2.1.6.1 Wirtualizator pamięci dyskowych

W celu efektywnego wykorzystania przestrzeni dyskowej i zbudowania dynamicznej infrastruktury IT umożliwiającej jej udostępnianie w modelu chmury konieczne jest zapewnienie mechanizmów pozwalających na wirtualizację przestrzeni dyskowej na poziomie sieci SAN. Proponowane rozwiązanie musi zapewnić: Wirtualizację pełnej oferowanej przestrzeni dyskowej i pamięci typu flash. Zaawansowane zarządzanie pamięciami masowymi, umożliwiające wirtualizację przestrzeni

dyskowej różnych producentów. Zarządzanie całą przestrzenią użyteczną pamięci dyskowej rozwiązania.

10 / 62


Wirtualizator musi mieć możliwość optymalizacji wykorzystania dysków SSD i HDD poprzez automatyczną identyfikacje najbardziej obciążonych fragmentów wolumenów, a następnie migrację tych fragmentów na szybszy nośnik. Pojedynczy wolumen musi mieć możliwość rozłożenia pomiędzy pamięć flash oraz trzema różnymi rodzajami dysków: SSD, HDD 15/10 k RPM i HDD 10/7,2 k RPM.

Wirtualizator musi optymalizować wykorzystanie dysków SSD/HDD, tak, aby w ramach tego samego rodzaju dysków (pojemności/prędkości) wszystkie dyski składowe były utylizowane w równym stopniu.

Dynamiczne alokowanie zasobów umożliwia nadalokację posiadanej przestrzeni dyskowej. Dynamiczna migracja zapewniająca nieprzerwaną dostępność aplikacji w trakcie przenoszenia

newralgicznych danych. Wykorzystanie kopii migawkowych. Zapewnienie funkcji synchronicznej lub asynchronicznej replikacji danych między systemami. Możliwość rozbudowy pamięci cache wirtualizatora do 512GB. Wirtualizator musi umożliwiać realizację kompresji „na bieżąco” (bez potrzeby zapisania

nieskompresowanych danych na dyskach). Kompresja musi być realizowana poprzez dedykowane zasoby sprzętowe przeznaczone do tego celu.

2.1.6.2 Macierz dyskowa

Łączna przestrzeń dysków w macierzy dyskowej musi być nie mniejsza niż 230TB.

Poniżej przedstawiono wymagania na pojedynczą macierz dyskową.

Wymaganie Opis

Interfejs hosta Minimum 16 portów FC8

Interfejs użytkownika Graficzny interfejs użytkownika

Kontroler pojedynczy/podwójny

Kontroler podwójny Dual-Active

Pamięć podręczna na kontroler

32 GB

Rozbudowa pamięci podręcznej na kontroler

32 GB

Typ napędu Dwuportowe dyski SAS 6 Gb lub SAS 12 Gb wymieniane podczas pracy

Dyski twarde Zainstalowane 50% liczby dysków SAS każdy o maks. pojemności 600 GB 10k rpm i 50% liczby dysków SAS każdy o min. pojemności 1,2TB 10k rpm.

Poziomy RAID RAID 0, 1, 5, 6 i 10

Wentylatory i zasilacze W pełni nadmiarowe, z możliwością wymiany podczas pracy

Obudowa pojedynczej półki dyskowej

O wysokości sumarycznej maksymalnie 2U, dedykowana do zamontowania w szafie RACK 19”

Zaawansowane właściwości

Wirtualizacja wewnętrzna, optymalizacja przydzielania pojemności, jednokierunkowa migracja danych i funkcje tworzenia kopii migawkowej

Zaawansowane właściwości

Macierz musi mieć możliwość optymalizacji wykorzystania dysków SSD i HDD poprzez automatyczną identyfikacje najbardziej obciążonych fragmentów wolumenów, a następnie migrację tych fragmentów na szybszy nośnik. Pojedynczy wolumen musi mieć możliwość rozłożenia pomiędzy 3 różnymi rodzajami dysków: SSD, HDD 15/10 k RPM i HDD 10/7,2 k RPM.Macierz musi optymalizować wykorzystanie dysków SSD/HDD, tak, aby w ramach

11 / 62


tego samego rodzaju dysków (pojemności/prędkości) wszystkie dyski składowe były utylizowane w równym stopniu

Pochodzenie Macierz musi pochodzić z autoryzowanego kanału dystrybucji producenta

Kompresja danych Macierz musi umożliwiać realizację kompresji „na bieżąco” (bez potrzeby zapisania nieskompresowanych danych na dyskach).Kompresja musi być realizowana poprzez dedykowane zasoby sprzętowe przeznaczone do tego celu.

W rozwiązaniu dopuszcza się zastosowanie maksymalnie 2 macierzy dyskowych.

2.1.6.3 Przełączniki SAN

Cecha / funkcja Opis wymogu

Obudowa

Obudowa o wysokości maksymalnie 1U, przeznaczona do montażu w szafie dystrybucyjnej 19". Razem z obudową należy dostarczyć szyny / blachy montażowe oraz wszelki osprzęt umożliwiający zainstalowanie w szafie, podłączenie do zasilania oraz do serwerów, macierzy dyskowych i bibliotek taśmowych.

Co najmniej 2 przełączniki 16Gb FC SAN lub wyższej przepustowości. Każdy przełącznik powinien posiadać minimum 12 aktywnych portów zewnętrznych.

Przełączniki muszą zapewniać funkcjonalność NPIV oraz Full Fabric.

Co najmniej 4 porty zewnętrzne na obudowę obsadzonych modułami SFP o przepustowości nie mniejszej niż 16Gb FC.

Urządzenia SAN agregujące ruch z każdej obudowy powinny mieć możliwość rozbudowy do min. 24 portów bez konieczności wymiany urządzenia.

Urządzenia powinny zapewniać możliwość wyprowadzenia sygnału ze wszystkich portów FC w każdym serwerze.

Porty 12 aktywne moduły SFP+ 16 Gb/s.

Liczba 2 sztuki

Agregacja portów (ang. trunking)

Przełącznik musi umożliwiać agregację, co najmniej 4 portów.

W przypadku braku wsparcia dla technologii 16Gb FC oraz funkcjonalności rozbudowy w przełącznikach montowanych w obudowie dopuszcza się zastosowanie dodatkowych przełączników zewnętrznych przy zachowaniu pełnej redundancji – tj. min. dwa moduły FC montowane w obudowie wyprowadzające wszystkie porty FC z każdego dostarczonego z obudową serwera i min. dwa na każdą dostarczoną obudowę zewnętrzne przełączniki spełniające wymóg rozbudowy do min. 24 portów i wsparcia dla technologii 16Gb FC.

2.1.6.4 Pamięć masowa typu flash

Parametry pamięci masowej typu flash: Katalogowa pojemność dostępna dla użytkownika nie powinna być mniejsza niż 20 TB. Minimalna katalogowa pojemność dostępna dla użytkownika, do jakiej musi być możliwość

rozbudowy pamięci masowej typu flash to 40 TB.

12 / 62


Zabezpieczenie RAID 5 dla każdej karty flash (wewnątrz karty) oraz dodatkowy RAID 5 pomiędzy kartami flash realizowany za pomocą bramek logicznych FPGA lub ASIC.

Karty flash typu eMLC lub SLC. Kontroler przestrzeni dyskowej zapewniający architekturę dual - active. Wsparcie dla funkcji globalnego hot spare. Brak pojedynczego punktu awarii. Automatyczne skanowanie mediów w celu kontroli spójności danych. Automatyczne monitorowania aktualnej wydajności urządzenia. Sumaryczna pamięć cache pamięci masowej, co najmniej 30 GB, podtrzymywana bateryjnie.

Możliwość rozbudowy pamięci cache pamięci masowej do 60GB. Podsystem dyskowy zapewniający katalogowo opóźnienia na poziomie 0,2 ms. Wsparcie dla protokołu FibreChannel (minimum 8 portów 16Gbit/s) lub InfiniBand (minimum 8

portów IB QDR) dla podłączania hostów. Wsparcie dla protokołu iSCSI i FCoE. Wsparcie dla szyfrowania danych z zastosowaniem klucza symetrycznego. Możliwość instalacji urządzenia w szafie teleinformatycznej 19”. Maksymalna wysokość rozwiązania: 2U.

2.1.7 Pamięć taśmowa

2.1.7.1 Biblioteka taśmowa

System pamięci taśmowej będzie wykorzystywany przez system kopii zapasowych. Podstawowym założeniem jest możliwość zabezpieczenia danych, w co najmniej 2 pełnych kopiach użytkowej przestrzeni dyskowej oferowanej w rozwiązaniu. Na przestrzeni taśmowej składowane będą zarówno dane użytkowników aplikacji jak i systemów udostępnianych w modelu chmury: Biblioteka taśmowa musi być wyposażona w 4 (cztery) napędy taśmowe LTO6. Biblioteka musi być wyposażona w taśmy RW (read-write) wraz z etykietami o sumarycznej

pojemności minimum 500 TB (bez kompresji). Biblioteka musi być wyposażona w minimum 200 slotów na taśmy. Biblioteka taśmowa posiada, 4 szt. taśm czyszczących. Biblioteka taśmowa musi być wyposażona w czytnik kodów kreskowych. Biblioteka posiada możliwość konfiguracji, co najmniej jednego tzw. „mail slot” umożliwiającego

wymianę pojedynczej taśmy bez konieczności wyjmowania z biblioteki całego magazynka z taśmami.

Biblioteka musi posiadać redundantne zasilacze. Każdy zainstalowany napęd taśmowy musi posiadać dwa natywne interfejsy Fibre Channel

minimum 8Gb.


Liczba 1 sztuka

Obudowa

Obudowa podstawowa o wysokości maksymalnie 5U, przeznaczona do montażu w szafie dystrybucyjnej 19". Razem z obudową należy dostarczyć szyny / blachy montażowe oraz wszelki osprzęt umożliwiający zainstalowanie w szafie, podłączenie do zasilania oraz do sieci SAN. Obudowa musi mieścić napędy taśmowe i kieszenie na taśmy. Wymaga się, aby obudowa była wyposażona w zdwojone zasilacze oraz panel LCD do komunikacji z biblioteką.Obudowa służąca do rozbudowy biblioteki musi mieć wysokość nie więcej niż 9U i mieć te same cechy, co obudowa podstawowa. Nie wymaga się dostarczenia obudowy wyposażonej w wyżej opisany panel LCD.

Napędy taśmoweBiblioteka musi rozbudowywać się, do co najmniej 16 napędów bez konieczności wymiany całego urządzenia, jedynie poprzez dokładanie obudów rozszerzeń.

13 / 62



PartycjonowanieBiblioteka musi umożliwiać partycjonowanie (podział na biblioteki logiczne). Licencje należy dostarczyć dla całej biblioteki.

Wielościeżkowość

Biblioteka musi obsługiwać wielościeżkowość (ang. multipathing) w obrębie połączeń Fibre Channel biblioteki i serwera (serwerów) backupu. Przełączenie sterowania w razie awarii musi następować automatycznie. W przypadku awarii karty HBA w serwerze, biblioteka musi mieć możliwość kontynuacji zadania backupu z wykorzystaniem zapasowej karty HBA. Licencje na tą funkcjonalność muszą zostać dostarczone wraz z biblioteką.

Porty komunikacyjneBiblioteka musi być wyposażona w co najmniej jeden port Ethernet do celów zarządzania.

ZarządzanieBiblioteka musi umożliwiać zarządzanie przy pomocy oprogramowania systemu kopii zapasowych.

Raportowanie

Biblioteka musi umożliwiać tworzenie raportów diagnostycznych oraz raportów umożliwiających analizę trendów w zakresie: wykorzystania napędów i nośników,wydajności napędów i nośników. Licencje na tą funkcjonalność muszą być dostarczone razem z biblioteką.

2.1.8 Oprogramowanie do wirtualizacji zasobów serwerowychNależy dostarczyć oprogramowanie do wirtualizacji zasobów serwerowych w liczbie licencji niezbędnej do zarządzania wszystkimi serwerami w ramach rozwiązania.Oprogramowanie do wirtualizacji zasobów serwerowych musi posiadać następujące cechy: Oprogramowanie musi umożliwiać uruchamianie wirtualizacji na serwerach fizycznych, opisanych w

punktach 2.3.1 oraz 2.4.1 w liczbie określonej w wymienionych punktach. Zarządzanie wszystkimi zwirtualizowanymi zasobami musi odbywać się przy użyciu jednej konsoli

do zarządzania całym środowiskiem. Oprogramowanie musi pozwalać na wydzielenie środowiska produkcyjnego, testowego i

deweloperskiego w warstwie wirtualnej z użyciem wirtualizatora Oprogramowanie musi pozwalać na integrację z oprogramowaniem do zarządzania chmurą

akademicką oraz wirtualnymi desktopami opisanymi w punktach 2.3.2 oraz 2.4.2, Oprogramowanie musi zapewnić możliwość obsługi wielu instancji systemów operacyjnych na

jednym serwerze fizycznym i musi się charakteryzować maksymalnym możliwym stopniem konsolidacji sprzętowej.

Oprogramowanie musi umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku wydajności i dostępności pozostałych wybranych usług,

Oprogramowanie musi w możliwie największym stopniu być niezależne od producenta platformy sprzętowej.

Oprogramowanie musi wspierać co najmniej następujące systemy operacyjne: Windows Server 2008 R2, Windows Server 2012,SLES 11, RHEL 5,

Oprogramowanie do wirtualizacji musi zapewnić możliwość wykonywania kopii zapasowych instancji systemów operacyjnych oraz ich odtworzenia w możliwie najkrótszym czasie.

Oprogramowanie musi umożliwiać zastosowanie w serwerach fizycznych procesorów o dowolnej liczbie rdzeni.

Oprogramowanie musi umożliwiać tworzenie standardowej konfiguracji dla hostów i zautomatyzowanie zgodności dla tych konfiguracji.

System musi mieć możliwość uruchamiania fizycznych serwerów z centralnie przygotowanego obrazu poprzez protokół PXE

Oprogramowanie musi mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi.

14 / 62


Oprogramowanie musi umożliwiać łatwe i szybkie ponowne uruchomienie systemów/usług w przypadku awarii poszczególnych elementów infrastruktury.

Oprogramowanie musi zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacji, hostowanych systemów operacyjnych (np. wgrywania patch-y) i aplikacji tak, aby zminimalizować ryzyko awarii systemu na skutek wprowadzenia zamiany.

Oprogramowanie musi zapewniać pracę bez przestojów dla wybranych maszyn wirtualnych, niezależnie od systemu operacyjnego oraz aplikacji, podczas awarii serwerów fizycznych, bez utraty danych i dostępności danych podczas awarii serwerów fizycznych.

Oprogramowanie musi umożliwiać automatyczne równoważenie obciążenia serwerów fizycznych pracujących jak platforma dla infrastruktury wirtualnej.

Oprogramowanie musi zapewniać RESTful API do integracji z systemami zewnętrznymi oraz SDK (ang. Software Developer Kit).

2.2 System kopii zapasowychRozwiązanie musi posiadać własny system kopii zapasowych, w którym składowane mają być dane przechowywane w pamięci dyskowej (opisanej w punkcie 2.1.6). System kopii zapasowych musi: wykorzystywać pamięć taśmową (opisaną w punkcie 2.1.7) do przechowywania kopii danych. wykorzystywać dedykowany serwer (opisany w punkcie 2.2.1). wykorzystywać dedykowane oprogramowanie (opisane w punkcie 2.2.2). Wymagane jest dostarczenie sprzętu i oprogramowania opisanych w niniejszym punkcie z 5 letnim okresem wsparcia technicznego świadczonego przez producenta sprzętu i oprogramowania.

2.2.1 Wymagania dla dedykowanego serwera systemu kopii zapasowych

Dedykowany serwer systemu kopii zapasowych musi spełniać poniższe wymagania:

Nazwa elementu,parametru lub cechy Opis wymagań

Liczba 1 sztuka

ObudowaO wysokości maksymalnie 2U, dedykowana do zamontowania w szafie rack 19" z zestawem szyn do mocowania w szafie i wysuwania do celów serwisowych.

Płyta głównaPłyta główna dedykowana do pracy w serwerach, wyprodukowana przez producenta serwera z możliwością zainstalowania dwóch procesorów.

WydajnośćZainstalowane dwa procesory osiągające w teście SPEC CPU2006 (dostępnym na stronie www.spec.org) wynik nie mniejszy niż 410 dla testu "SPECint_rate_base2006" dla oferowanego serwera

RAMMinimum 64 GB 1866MHz, z technologią ECC, możliwość rozszerzenia pamięci do minimum 768 GB.

Gniazda PCIMinimum 3 slotów PCIe 3.0, Wymagana możliwość zainstalowania dodatkowych 3 slotów PCIe 3.0, Wymagana możliwość konwersji minimum jednego slotu do slotu PCI-X

Interfejsy sieciowe

Wbudowane na płycie głównej 4 porty typu 1Gb Ethernet. Karty sieciowe muszą wspierać load balancing, failover i TCP/IP Offload Engine.Zainstalowana w dedykowanym slocie karta typu 10Gb Ethernet, wyposażona w 2 moduły optyczne typu SFP+ SR

Interfejsy FC Zainstalowane minimum 4 karty HBA typu FC8

15 / 62


Napęd optyczny Zainstalowany wewnętrzny napęd typu DVD+/-RW

KontrolerKontroler macierzowy SAS/SATA z 512MB pamięci cache, z podtrzymaniem bateryjnym, umożliwiający konfigurację dysków w RAID 0/1/5/6/10. Kontroler musi umożliwiać rozbudowę do minimum 2GB pamięci cache.

Dyski twarde Muszą zostać zainstalowane 2 dyski typu SSD o pojemności minimum 100GB każdy

Inne porty8 portów USB (2 z przodu, 4 z tyłu, 2 wewnątrz serwera).1 port szeregowy, 1 dedykowany port do zarządzania zdalnego.

Zasilacze Redundantne, Hot-Plug o mocy maksymalnie 900W każdy.

Zarządzanie

Proaktywne monitorowanie krytycznych komponentów serwera takich jak: Procesory, Dyski, Pamięć operacyjna, zasilacze, wentylatory, regulator napięcia i przesyłanie do systemu zarządzającego alertów przed wystąpieniem awariiWbudowany na froncie obudowy panel diagnostyczny umożliwiający łatwą identyfikację uszkodzonego elementu. Serwer zawiera zintegrowany moduł zarządzania, umożliwiający funkcje kontroli, monitorowania, oraz funkcje ostrzegania przed awarią. Jeżeli któryś z komponentów serwera ulegnie awarii, diody na płycie głównej zostaną włączone w celu zdiagnozowania problemu. Błąd jest rejestrowany w dzienniku zdarzeń, a administrator powiadamiany o problemie. Możliwość zdalnego dostępu do serwera poprzez protokoły: Intelligent Platform Management Interface (IPMI) Version 2.0, Simple Network Management Protocol (SNMP) Version 3, Common Information Model (CIM). Możliwość mapowania napędu CD/DVD/FDD/USB i obrazów ISO.

Dokumentacja użytkownika

Zamawiający wymaga dokumentacji w języku polskim lub angielskim.

System operacyjnyWymagane jest dostarczenie z serwerem, licencji na system operacyjny wspierany przez oprogramowanie systemu kopii zapasowych (opisany w punkcie 2.2.2).

2.2.2 Oprogramowanie systemu kopii zapasowychNależy dostarczyć oprogramowanie systemu kopii zapasowych w liczbie licencji niezbędnej do zabezpieczenia pełnej przestrzeni dyskowej rozwiązania.

Wymagania na oprogramowanie systemu zarządzania kopiami zapasowymi: Obsługa urządzeń taśmowych (opisanych w punkcie 2.1.7) i dyskowych (opisanych w punkcie

2.1.6) do przechowywania kopii zapasowych i archiwizacji danych. Przechowywanie konfiguracji polityk zabezpieczeń oraz informacji o wykonanych kopiach,

harmonogramach oraz nośnikach w relacyjnej bazie danych. Proces tworzenia kopii zapasowej oraz odtwarzania danych powinien być procesem transakcyjnym. Ze względów bezpieczeństwa system powinien mieć możliwość wykonania mirroring’u tej bazy danych, przynamniej na poziomie logów transakcyjnych. Jednocześnie musi istnieć możliwość wykonani kopii zapasowej na taśmy w trakcie pracy systemu bez konieczności ograniczania jego funkcjonalności.

System backupu musi w sposób automatyczny i bezobsługowy optymalizować parametry pracy swojej bazy danych.

Możliwość definiowania w sposób centralny polityki tworzenia kopii zapasowych, tj. określenia, jakie dane, kiedy i gdzie powinny być składowane (definiowanie harmonogramu kopii zapasowej).

Możliwość realizowania raz zdefiniowanej polityki backupu w sposób automatyczny, bez konieczności ingerencji operatora. System powinien umożliwić także wykonywanie określonej akcji (uruchomienie polecenia lub skryptu) na zabezpieczanym systemie, przed i po zadaniu backupowym (np. zatrzymanie procesów, wykonanie backupu i ponowne uruchomienie).

Wykonywanie kopii zapasowych w sposób przyrostowy – pierwsza kopia powinna być kopią całkowitą a kolejne powinny zawierać jedynie dane, które uległy modyfikacji.

16 / 62


Możliwość zdefiniowania czasu ważności kopii danych, tj. czasu, po którym kopie te zostaną automatycznie usunięte.

Możliwość jednoczesnego tworzenia kopii zapasowych na różnego rodzaju nośniki (taśmy, dyski). Możliwość definiowania maksymalnej liczby wersji zabezpieczanych plików. W razie przekroczenia

limitu z repozytorium powinny być usuwane wersje najstarsze. Możliwość jednoczesnego tworzenia kopii zapasowych z wielu klientów (zasobów) na urządzenia

dyskowe. System bez ingerencji operatora powinien przenieść dane z dysków na taśmy w przypadku osiągnięcia zdefiniowanego poziomu wypełnienia przestrzeni dyskowej serwera kopii zapasowych.

Możliwość tworzenie kopii zapasowych tzw. On-linie z serwerów baz i aplikacji dla minimum MSSQL, Oracle, DB2, Informix, SAP (z wykorzystaniem brtools) bez konieczności zatrzymywania pracy serwera bazy danych.

Dla integracji z SAP/brtools powinny być obsługiwane minimum następujące bazy danych: Oracle, DB2, SAP HANA.

Możliwość ciągłego zabezpieczenia danych ze stacji roboczych (tworzenia kopii zapasowej w momencie modyfikacji pliku).

Automatyczne optymalizowanie położenia danych na taśmach pod kątem wykorzystania nośników: system powinien zapewniać średnie wykorzystanie taśm magnetycznych dostępnych do przechowywania danych na poziomie min 70%.

Automatyczne defragmentowanie danych na taśmach. Możliwość włączenia automatycznego mechanizmu minimalizującego rozproszenie danych

pochodzących z określonego zasobu na nośnikach; możliwość stosowania tego mechanizmu dla następujących klas zasobów:

system plików wolumin dyskowy, host (klient systemu kopii zapasowych), grupa hostów.

Funkcja ta powinna gwarantować minimalną liczbę niezbędnych operacji montowania nośnika przy odzyskiwaniu danych z określonego zasobu.

Możliwość utworzenia dodatkowego obszaru składowania danych na wybranym urządzeniu (systemie dyskowym, bibliotece taśmowej lub wirtualnej bibliotece taśmowej - VTL), zawierającego wyłącznie aktualne (lub najnowsze) wersje istniejących plików na zabezpieczanych systemach. Proces uaktualniania tego dodatkowego składowiska kopii powinien odbywać się automatycznie, bez konieczności komunikacji pomiędzy serwerem backupów i systemem zabezpieczanym (korzystając z danych już zeskładowanych w systemie kopii zapasowych). W przypadku przechowywania danych na taśmach system powinien umożliwiać przeprowadzenie tego procesu bez konieczności wykorzystania (tymczasowego lub stałego) przestrzeni dyskowej.

Tworzenie dodatkowych instancji kopii w celu zabezpieczenia przed uszkodzeniem urządzenia dyskowego lub nośnika magnetycznego używanego do przechowywania kopii zapasowych.

System powinien umożliwiać wykorzystanie dodatkowych kopii do składowania off-site (poza lokalizacją chronionych systemów) i zarządzać rotacją nośników używanych w tym procesie.

Możliwość replikowania poprzez TCP/IP (LAN, WAN) danych z wybranych źródeł (klientów systemu kopii zapasowych) pomiędzy serwerami kopii zapasowych w trybie przyrostowym.

Automatyczne przełączanie klienta kopii zapasowych do serwera zawierającego replikę jego kopii w razie braku dostępności serwera głównego lub braku dostępu do kopii przez niego obsługiwanych.

Zarządzanie politykami retencji na poziomie grup systemów, pojedynczych systemów, systemów plików/woluminów dyskowych, katalogów, pojedynczych plików i obiektów, wzorców nazw plików i ścieżek dyskowych.

Możliwość odzyskania danych dostępnych na chronionym systemie w określonym punkcie w czasie (w zakresie polityki przechowywania kopii zapasowych).

Możliwość wznowienia przerwanego zadania odtwarzania z pominięciem już odtworzonych danych. System oprócz backupu i odtwarzania danych musi realizować funkcje archiwizacji danych –

tworzenia kopii przechowywanej przez określony czas niezależnie od zmian na systemie chronionym, z możliwością przeniesienia danych do systemu kopii zapasowych (skasowania danych na systemie chronionym po utworzeniu ich kopii archiwalnej w systemie kopii zapasowych).

Odtwarzanie danych na inny niż źródłowy system, katalog lub z nową nazwą pliku.

17 / 62


Tworzenie i odtwarzanie kopii zapasowych z wykorzystaniem SAN (Storage Area Network) – dane będą przesyłane do i z- serwera kopii zapasowych bez obciążania LAN (sieci TCP/IP).

Możliwość integracji z mechanizmami sprzętowego szyfrowania nośników taśmowych Możliwość nieodwracalnego usunięcia kopii danych z systemu przez zamazanie nośników

magnetycznych. Możliwość komunikacji z klientem systemu kopii zapasowych za pomocą protokołu SSL. Możliwość jednoczesnego zapisu i odczytu danych z dyskowych urządzeń składowania. Możliwość minimalizacji redundancji danych przesyłanych z klientów systemu kopii zapasowych

(twz. deduplikacja danych po stronie klienta systemu kopii zapasowych(system źródłowy)) – mechanizm musi być wbudowany w oprogramowanie

Możliwość automatycznej minimalizacji redundancji danych składowanych po stronie serwera (tzw. deduplikacja danych po stronie serwera kopii zapasowych) – mechanizm musi być wbudowany w oprogramowanie

Monitorowanie i raportowanie o zadaniach (harmonogramach) oraz o wykorzystaniu zasobów systemowych i zarządzanych pamięci masowych.

Możliwość definiowania kryteriów alarmów na podstawie dowolnych danych systemu backupu. Możliwość wykonywania kopii zapasowej danych zgromadzonych na serwerze kopii zapasowych i

możliwość odtworzenia z nich kompletnego środowiska w przypadku awarii serwera. Możliwość wykorzystania wielu strumieni zapisu podczas procesu tworzenia kopii zapasowej bazy

danych serwera kopii zapasowych. Możliwość automatycznego wykonywania uaktualnienia oprogramowania klienta backupu i

zarządzania tym procesem z centralnej konsoli. Możliwość zapisu danych podczas wykonywania kopii zapasowej, na co najmniej 2 urządzenia

(dwa obszary składowania danych).

18 / 62


2.3 Chmura AkademickaChmura akademicka musi zapewniać zarządzanie zasobami udostępnianymi użytkownikom w ramach rozwiązania. W tym celu musi zapewniać samoobsługowy portal pozwalający użytkownikom na zarządzanie we własnym zakresie środowiskiem wykorzystywanym w poszczególnych krokach procesu wytwarzania aplikacji i przygotowywania środowisk do zajęć laboratoryjnych i prac badawczych. Rozwiązanie musi obejmować dostarczenie systemu katalogowego lub integrację z istniejącym systemem katalogowym.Rysunek 2 przedstawia komponent chmury akademickiej oraz komponenty rozwiązania niezbędne do funkcjonowania komponentu chmury akademickiej: LAN, SAN, Pamięć dyskowa, System kopii zapasowych. Do uruchomienia chmury akademickiej wymagane są następujące dedykowane elementy: Serwery chmury akademickiej (wymagania opisane w punkcie 2.3.1), Oprogramowanie do zarządzania zasobami chmury akademickiej (wymagania opisane w punkcie

2.3.2), Oprogramowanie udostępniane w chmurze akademickiej (wymagania opisane w punkcie 2.3.3).Oprogramowanie do zarządzania zasobami chmury akademickiej musi zapewnić zarządzanie wszystkimi serwerami chmury akademickiej.

Rysunek 2. Komponenty funkcjonalne biorące udział w realizacji funkcjonalności Chmury Akademickiej

19 / 62


2.3.1 Serwery chmury akademickiejWymagane jest dostarczenie sprzętu i oprogramowania opisanych w niniejszym punkcie z 5 letnim okresem wsparcia technicznego świadczonego przez producenta sprzętu i oprogramowania.

Wymagania na serwery chmury akademickiej zostały przedstawione w tabeli poniżej.


Opis wymagań

Liczba 20 sztuk

Obudowa Kasetowa umożliwiająca zainstalowanie w obudowie opisanej w pkt. 2.1.1

Procesor Procesor wykonany w technologii x86, min. 8 rdzeni na układ procesorowy.Serwer wyposażony w min. 2 układy procesorowe pozwalające na osiągniecie wyniku min. 700 pkt w teście SPECint2006 Rates publikowanego na stronie www.spec.org

Pamięć cache Minimum 20 MB pamięci cache na układ procesorowy

Liczba układów procesorowych w każdym serwerze

Zainstalowane min. 2 układy procesorowe, wszystkie sloty procesorowe dostępne w serwerze musza być obsadzone układami procesorowymi

Pamięć RAM Min. 320GB RAM. Możliwość rozbudowy do min. 1TB RAM

Dyski twarde Zainstalowany min. 2 dyski typu SSD o pojemności 100GB każdy. Kontroler RAID na płycie głównej z możliwością konfiguracji RAID 1, 0

Interfejsy sieciowe Min. 2 interfejsy sieciowe 10Gb Ethernet o następujących cechach:- Wsparcie dla wielu interfejsów wirtualnych (vNIC)- Możliwość włączenia funkcjonalności iSCSI oraz FCoE za pomocą klucza licencyjnego bez konieczności wymiany elementów.

Wspierane systemy operacyjne

Microsoft Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, VMware ESX 4.1, VMware ESXi 4.1 VMware vSphere 5

Zarządzanie Serwer zawiera zintegrowany moduł zarządzania (procesor serwisowy), który łączy się z modułem zarządzania w obudowie. Połączenie takie zapewnia funkcje kontroli, monitorowania, oraz funkcje ostrzegania przed awarią. Jeżeli któryś z komponentów serwera ulegnie awarii, diody na płycie głównej zostaną włączone w celu zdiagnozowania problemu. Błąd jest rejestrowany w dzienniku zdarzeń, a administrator powiadamiany o problemie. Możliwość zdalnego dostępu do serwera poprzez protokoły: Intelligent Platform Management Interface (IPMI) Version 2.0, Simple Network Management Protocol (SNMP) Version 3, Common Information Model (CIM). Możliwość mapowania napędu CD/DVD/FDD/USB i obrazów ISO.

System operacyjnyWymagane jest dostarczenie z serwerem licencji na system operacyjny dla wszystkich serwerów chmury akademickiej.

Oprogramowanie do wirtualizacji

Wymagane jest dostarczenie oprogramowania do wirtualizacji wszystkich serwerów chmury akademickiej.

2.3.2 Oprogramowanie do zarządzania zasobami chmury akademickiejNależy dostarczyć oprogramowanie do zarządzania zasobami chmury akademickiej w liczbie licencji niezbędnej do zarządzania wszystkimi serwerami chmury akademickiej.

20 / 62


Wymagane jest dostarczenie sprzętu i oprogramowania opisanych w niniejszym punkcie z 5 letnim okresem wsparcia technicznego świadczonego przez producenta sprzętu i oprogramowania.

Oprogramowanie musi posiadać portal samoobsługowy spełniający następujące wymagania: Administrator może zmieniać wygląd portalu samoobsługowego oraz jego zawartość w trybie

graficznym. W szczególności musi mieć możliwością definiowania w trybie graficznym (poprzez układanie w trybie “przeciągnij i upuść” elementów wizualnych, z dostępnej palety) dowolnych formatek pozwalających na zaawansowaną interakcję z użytkownikiem, minimum: podawanie dodatkowych informacji związanych z usługą.

Portal jest dostępny po uprzednim uwierzytelnieniu. Dane użytkowników przechowywane są w centralnym repozytorium tożsamości i są definiowane przez administratora z poziomu konsoli administracyjnej. Mechanizm definiowania użytkowników oparty jest na rolach.

Administrator portalu musi posiadać do dyspozycji szablony ról odzwierciedlających typowe uprawnienia użytkowników portali dla klientów chmury

Portal musi pozwalać na wsparcie dla rożnych poziomów uprawnień, co najmniej: Administratorzy klienta: zamawianie usług, akceptacja składania zamówienia,

udostępnianie usługi użytkownikom; Użytkownicy klienta: aktywacja usług, podgląd stanu wykorzystania;

Portal musi pozwalać na monitorowanie procesu składania wniosków, ich stanu, długości trwania poszczególnych etapów oraz historii. Proces musi być w całości obsługiwany przez portal.

Portal musi pozwalać na definiowanie wzorców aplikacji złożonych składających się z różnych zasobów na potrzeby warstw aplikacji. Zdefiniowane wzorce aplikacji złożonych powinny być udostępniane przez portal samoobsługowy, w którym uprawnieni użytkownicy będą mogli wnioskować o automatyczne przygotowanie kompletnego środowiska aplikacji wg wzorca.

Portal musi pozwalać na osadzanie paczek (szablonów) z własnymi aplikacjami na przydzielanych zasobach oraz ich tymczasowe przechowywanie (w postaci skompilowanej).

Portal musi pozwalać na śledzenie danych związanych z wykorzystaniem zasobów chmury na potrzeby rozliczeń.

Portal musi pozwalać na prezentację dostępnych usług.

Oprogramowanie musi posiadać funkcjonalność zarządzania usługami i zasobami chmury akademickiej spełniającą następujące wymagania: Oprogramowanie musi pozwalać na definiowanie zasobów wchodzących w skład chmury, w tym w

szczególności: serwerów (CPU, rdzenie, RAM), przestrzeni dyskowej, sieci, wzorców systemów operacyjnych, pakietów oprogramowania.

Oprogramowanie musi pozwalać na definiowanie wydzielonych pól zasobów (środowisk) w celu separacji zasobów o różnych parametrach i charakterystyce niezawodnościowej (np. strefa z serwerami fizycznymi, strefa z serwerami wirtualnymi o podwyższonej dostępności)

Oprogramowanie musi pozwalać na przyporządkowanie wirtualnych zasobów do chmury, które są objęte co najmniej następującymi platformami wirtualizacyjnymi (hypervisors): VMware vSphere (ESX/ESXi), KVM.

Oprogramowanie musi wspierać przydzielanie zasobów dla klientów wirtualnych przy wykorzystaniu o systemy wirtualizacji zasobów, z możliwością definicji parametrów, w tym co najmniej: vCPU – liczba; RAM – ilość; przestrzeń dyskowa – ilość; typów pamięci dyskowej - liczba; VLAN - liczba;

Oprogramowanie zarządzające powinno realizować dostarczanie zasobów chmury akademickiej (ang. provisioning) przy wykorzystaniu o API OpenStack.

Oprogramowanie musi udostępniać web API (tzw. RESTful API) umożliwiające uruchamianie usług automatycznie,

Oprogramowanie musi pozwalać na udostępnianie obszaru zarządzania usługami w ramach puli usług klienta i zarządzanie użytkownikami,

Oprogramowanie musi umożliwiać importowanie szablonów aplikacji (gotowych konfiguracji oprogramowania wcześniej przygotowanego do osadzenia),

Oprogramowanie musi pozwalać na definiowanie usług na potrzeby katalogu usług zachowując pełny cykl życia usługi: rejestrację usługi; autoryzację usługi; zamawianie i akceptacja usługi; rezerwacja zasobów; uruchamianie usługi; modyfikacje parametrów; zarządzanie usługami;

21 / 62


rezygnacja z usługi; zwalnianie zasobów Oprogramowanie musi umożliwiać definiowanie dowolnego kształtu procesu dostarczania usługi

realizowanego przez zintegrowany silnik procesów. W ramach procesu dostarczania usługi musi być możliwość interakcji przez zdefiniowane formatki między rolami użytkowników zarządzających.

Oprogramowanie musi posiadać moduł rozliczania usług udostępnianych w chmurze akademickiej spełniający następujące wymagania: Moduł z obszaru płatności i bilingu musi posiadać możliwość generowania informacji bilingowych

dla użytkowników, System musi pozwalać na definiowanie centrów kosztów umożliwiających przypisanie do nich

konkretnych kosztów System musi umożliwiać generowanie raportów pokazujących wykorzystanie i strukturę płatności

dla: użytkownik; grupa użytkowników; zasób; grupa zasobów; ośrodek kosztów; standardowe jednostki kalendarza (dzień, tydzień, miesiąc, rok); dowolnie wybrany okres kalendarza (od-do).

Moduł musi mieć możliwość definiowania szablonów dla raportów kosztowych.

Wymagania na oprogramowanie do tworzenia środowisk wirtualnych: Oprogramowanie musi pozwalać na definiowanie procesów uruchamiania i tworzenia środowisk

wirtualnych przy pomocy interfejsu graficznego GUI. Środowiska wirtualne muszą bazować na zdefiniowanych wzorcach systemów Oprogramowanie musi pozwalać na automatyzację dystrybucji oprogramowania dla usług, dla co

najmniej: systemu operacyjnego, środowiska bazodanowego i serwera aplikacji (instalacje, parametryzacje, powiązanie z systemem zarządzania licencjami).

Wymagania na oprogramowanie do zarządzania dostępem: Oprogramowanie musi umożliwiać przyporządkowywanie zasobów dla klientów istniejących w

centralnym repozytorium tożsamości. Oprogramowanie musi pozwalać na definiowanie praw dostępu do zasobów wchodzących w skład

chmury dla ról/użytkowników. Definicje muszą obejmować, co najmniej: dostęp do specyficznych zasobów (np.: stref, sieci), maksymalne liczby poszczególnych typów zasobów (CPU, serwery, pamięć, przestrzeń dyskowa, usługi, np. backup).

Oprogramowanie musi pozwalać na przydzielanie zasobów. Oprogramowanie musi pozwalać na zarządzanie użytkownikami (min.: podgląd uprawnień,

dodawanie, zmiany uprawnień, usuwanie).

Wymagania na oprogramowanie do zarządzania/monitorowania bezpieczeństwem: Oprogramowanie musi posiadać pojedynczą konsolę do zarządzania i konfiguracji. Administrator musi mieć możliwość definiowania dostępu do poszczególnych zarządzanych

elementów infrastruktury w oparciu o role. Administrator musi mieć możliwość definiowania dostępu do poszczególnych elementów

funkcjonalnych interfejsu w oparciu o role Oprogramowanie musi mieć możliwość wykrywania nowych – wcześniej nie zarządzanych

elementów infrastruktury. Oprogramowanie musi mieć możliwość automatycznej klasyfikacji nowych elementów

infrastruktury. Oprogramowanie musi zapewniać dostęp przez API do informacji zgromadzonych w repozytorium

danych. Oprogramowanie musi mieć możliwość integracji z różnymi mechanizmami uwierzytelniającymi,

min.: LDAP lub Active Directory. Oprogramowanie musi zapewniać mechanizm do analizy zagrożeń i raportowania dostępny przez

przeglądarkę. Oprogramowanie musi zapewniać wewnętrzne mechanizmy wysokiej dostępności (ang. High

Availability) bez konieczności wykorzystywania rozwiązań firm trzecich. Oprogramowanie musi zapewnić ciągłość funkcjonowania w przypadku, jeśli któryś z komponentów

przestanie funkcjonować lub straci połączenie.

22 / 62


Oprogramowanie musi zapewniać automatyczny proces przywracania środowiska do działania w przypadku wystąpienia awarii.

Oprogramowanie musi posiadać wewnętrzny mechanizm monitorowania wydajności i dostępności poszczególnych jego komponentów wraz z możliwością powiadamiania administratorów o wystąpieniu problemów.

Oprogramowanie musi gromadzić i przechowywać informacje o wszystkich elementach infrastruktury wykrytych w rozwiązaniu. System musi mieć możliwość kategoryzacji wykrytych elementów infrastruktury przy wykorzystaniu zebranych danych (min.: otwarte porty, rodzaj ruchu sieciowego, podatności). Oprogramowanie musi zapewniać możliwość edytowania atrybutów charakteryzujących określony element infrastruktury.

Oprogramowanie musi umożliwiać przeszukiwanie bazy wykrytych elementów infrastruktury. Oprogramowanie musi umożliwiać kolekcję zdarzeń z poszczególnych komponentów rozwiązania. Oprogramowanie musi zapewniać mechanizm korelacji zdarzeń z całej infrastruktury rozwiązania. Oprogramowanie musi zapewniać możliwość definiowania własnego schematu nazewnictwa

poszczególnych zdarzeń. Oprogramowanie musi zapewniać mechanizm archiwizacji zdarzeń zarówno w krótkim przedziale

czasowym (do analizy w czasie rzeczywistym) oraz w długim przedziale czasowym (do analizy danych historycznych).

Oprogramowanie musi wykorzystywać silnik bazodanowy spełniający wymagania podane w rozdziale 2.3.3.1, oraz platformę aplikacyjną spełniającą wymagania podane w rozdziale 2.3.3.3.

2.3.3 Oprogramowanie udostępniane w Chmurze AkademickiejChmura akademicka ma umożliwiać udostępnianie następującego oprogramowania: System operacyjny (SO), Serwer bazy danych (SBD), Serwer aplikacji (SA), Platforma integracyjna (PI), projektowanie procesów biznesowych i integracji (MPB), Silnik procesów biznesowych (SPB), Środowisko zarządzania całym cyklem wytwórczym oprogramowania (CWO), Zintegrowana platforma analityczna (ZPA), Środowisko do rozwiązywania problemów optymalizacyjnych (SPO), Oprogramowanie do konfiguracji procesu projektowania systemu informatycznego (KPP). Oprogramowanie do testowania zabezpieczeń aplikacji (TZA).Wymagane jest dostarczenie licencji oprogramowania udostępnianego w chmurze akademickiej spełniającego wymagania, które zostały przedstawione poniżej.

Wymagane jest dostarczenie licencji oprogramowania udostępnianego w chmurze akademickiej z 3 letnim okresem wsparcia technicznego świadczonego przez producenta oprogramowania. Wsparcie techniczne musi umożliwiać aktualizację oprogramowania do najnowszej wersji oraz dawać możliwość zgłaszanie problemów technicznych do serwisu producenta oprogramowania.

2.3.3.1 System operacyjny

Oprogramowanie systemu operacyjnego musi spełniać następujące wymagania: Możliwość instalacji i uruchomienia na wszystkich rdzeniach procesorów serwerów chmury

akademickiej, Musi umożliwiać uruchamianie oprogramowania udostępnianego w chmurze akademickiej.

2.3.3.2 Serwer bazy danych

Oprogramowanie serwera bazy danych musi spełniać następujące wymagania: Możliwość instalacji i uruchomienia na minimum 5 rdzeniach procesora serwera chmury

akademickiej, Dostarczone licencje powinny umożliwiać pracę nieograniczonej liczby użytkowników.

23 / 62


Oprogramowanie bazy danych musi wspierać systemy operacyjne Linux i Windows oraz umożliwiać ewentualną zmianę platformy pomiędzy systemami w ramach dostarczonych licencji.

Oprogramowanie musi oferować pełne wsparcie techniczne dla technologii wirtualizacji zastosowanej w rozwiązaniu.

Oprogramowanie musi wspierać konfiguracje zapewniające wysoką niezawodność i dostępność bazy danych. Oprogramowanie powinno umożliwić utrzymywanie na bieżąco synchronicznej kopii bazy danych na serwerze zapasowym (baza zapasowa), bez możliwości utraty zatwierdzonych transakcji w momencie awarii bazy podstawowej. W przypadku awarii serwera podstawowego system powinien umożliwić szybkie przełączenie przetwarzania na serwer zapasowy. Utrzymywanie bazy zapasowej oraz przełączanie przetwarzania na bazę zapasową powinno być przeźroczyste dla aplikacji. Wyżej wymieniona funkcjonalność powinna być realizowana w warstwie oprogramowania bazy danych i nie może zależeć od mechanizmów replikacji realizowanych w warstwie systemu operacyjnego bądź systemu pamięci masowych.

Oprogramowanie powinno umożliwiać wykonywanie kopii zapasowych bazy danych bez ograniczania dostępności danych dla aplikacji (tzw. backup online) z wykorzystaniem systemu kopii zapasowych (opisanego w punkcie 2.1.8).

Oprogramowanie musi umożliwiać tworzenie kopii zapasowych bazy w postaci skompresowanej. Kompresja musi opierać się o mechanizm bazy danych, który na bieżąco kompresuje strumień danych.

Oprogramowanie powinno dawać możliwość przywrócenia bazy danych z kopii bezpieczeństwa na określony punkt w czasie.

Oprogramowanie powinno pozwalać na automatyczne wykonywanie kopii bezpieczeństwa całej bazy danych oraz kopii dzienników transakcji.

Oprogramowanie musi zapewnić możliwość, zbliżonego do liniowego, skalowania poziomego, względem: maksymalnego wolumenu obsługiwanych operacji w jednostce czasu, ilości przetwarzanych i zgromadzonych danych, liczby jednocześnie pracujących użytkowników.

Oprogramowanie musi umożliwiać skalowalność bazy danych przez pracę w klastrze wydajnościowym niewymagającym powielania danych.

Oprogramowanie bazy danych musi udostępniać mechanizmy zarządzania obciążeniem, w szczególności musi dawać możliwość automatycznego określania priorytetów wykonywanych w bazie danych zadań, co najmniej: na podstawie nazwy użytkownika, nazwy aplikacji, adresu IP komputera klienckiego, liczby czytanych wierszy, czasu wykorzystania procesora. Dla bardzo długo wykonujących się zadań musi istnieć możliwość automatycznego obniżenia priorytetu oraz zatrzymania zadania po upływie określonego czasu.

Mechanizm zarządzania obciążeniem powinien zabezpieczać przed nadmiernym zużyciem zasobów. W sytuacji uruchomienia bardzo dużej liczby obciążających zapytań SQL, zapytania powinny być automatycznie kolejkowane, aby nie doprowadzić do przekroczenia zużycia dostępnej pamięci operacyjnej i pogorszenia wydajności.

Oprogramowanie musi zapewniać możliwość równoległego wykonywania pojedynczego zapytania SQL na wielu procesorach.

Oprogramowanie musi zapewniać kolumnowe składowanie danych na dysku oraz w pamięci operacyjnej w celu przyspieszenia zapytań analitycznych. Czytanie danych z określonych kolumn tabeli nie może powodować czytania wartości z pozostałych kolumn tabeli.

Oprogramowanie musi zapewniać również mechanizm przetwarzania danych wyłącznie w pamięci operacyjnej w celu przyspieszenia analiz danych (rozwiązanie klasy ‘in-memory’). Oprogramowanie musi zapewnić pracę także w sytuacji, w której wielkość pamięci operacyjnej jest mniejsza od rozmiaru danych na dysku.

Oprogramowanie bazy danych musi zapewniać efektywne metody kompresji danych, pozwalające na zmniejszenie zajmowanej przestrzeni dyskowej. Kompresja danych musi być przezroczysta dla aplikacji, tzn. włączenie bądź wyłącznie kompresji nie może wymuszać modyfikacji aplikacji. Dane muszą być kompresowane zarówno podczas ładowania dużych porcji danych (ładowanie blokowe), jak i podczas wykonywania pojedynczych operacji wstawiania, bądź aktualizacji danych (instrukcje SQL INSERT, UPDATE). Dostarczone oprogramowanie bazy danych musi zawierać odpowiednie licencje na wykorzystanie kompresji.

Oprogramowanie musi zapewniać kompresję tabel oraz indeksów. Oprogramowanie bazy danych musi zapewniać mechanizmy partycjonowania danych (tzw. table

24 / 62


partitioning), w szczególności partycjonowanie zakresowe (tzw. range partitioning) oraz partycjonowanie z wykorzystaniem funkcji mieszającej (tzw. hash partitioning).

Oprogramowanie musi zapewnić automatyczne zarządzanie przestrzenią dyskową bazy danych, w szczególności powiększanie rozmiaru obszarów bazy danych musi być wykonywane automatycznie.

Oprogramowanie musi dawać możliwość składowania danych na macierzach dyskowych o różnych parametrach wydajnościowych. Oprogramowanie musi dawać możliwość przenoszenia plików bazy danych pomiędzy macierzami bez ograniczenia dostępności bazy danych.

Oprogramowanie baz danych musi zapewniać przechowywanie wszystkich danych wrażliwych w bazie danych w sposób zaszyfrowany przy użyciu mechanizmów wbudowanych.

Oprogramowanie bazy danych musi zapewnić kontrolę dostępu na poziomie pojedynczego wiersza w taki sposób, by użytkownicy widzieli tylko te rekordy, do których mają uprawnienia. Musi istnieć także możliwość ukrywania wartości kolumn tabel, zależnie od nadanych uprawnień.

Oprogramowanie musi zapewniać możliwość składowania i obsługi danych w formacie XML. Baza musi obsługiwać natywny typ danych XML.

Oprogramowanie musi wspierać języki zapytań XQuery, XPath oraz SQL/XML. Oprogramowanie musi umożliwiać aktualizację fragmentu dokumentu XML bez konieczności

analizy syntaktycznej (ang. parsing) bądź przepisywania całości dokumentu XML. Oprogramowanie musi umożliwiać indeksowanie wybranych elementów / atrybutów dokumentu

XML, w tym także indeksowanie powtarzających się elementów / atrybutów. Oprogramowanie musi umożliwiać automatyczną dekompozycję wybranych elementów dokumentu

XML do postaci relacyjnej. Oprogramowanie musi umożliwiać tworzenie relacyjnych widoków na dokumentach XML. Oprogramowanie musi dostarczać silnik transformacji danych (ETL bądź ELT), oraz narzędzia

pozwalające na graficzne zaprojektowanie transformacji danych. Oprogramowanie powinno zawierać gotowe transformaty pozwalające na wykonywanie takich operacji jak agregacje danych, sortowanie, filtrowanie, złączenia, transformacje i publikowanie danych XML. Narzędzie powinno umożliwiać definiowanie logiki przetwarzania danych, włączając warunkowe wykonanie danej transformacji, wykonanie transformacji w pętli, równoległe wykonanie kilku transformacji, wykonanie zewnętrznego programu. Oprogramowanie musi udostępniać funkcjonalność harmonogramowania pozwalającą na wykonanie określonej sekwencji transformat w zadanym czasie. Oprogramowanie musi dostarczać narzędzie graficzne do monitorowania wykonywanych zadań.

Mechanizm transformacji ETL (ELT) powinien dawać możliwość automatycznej transformacji danych niestrukturalnych do postaci strukturalnej, tak by dane można było poddać następnie analizie.

Oprogramowanie musi udostępniać mechanizmy OLAP, pozwalające na realizację wielowymiarowych zapytań, odwołujących się bezpośrednio bądź pośrednio do danych w bazie danych.

Oprogramowanie musi dostarczać narzędzia do modelowania relacyjnych oraz wielowymiarowych struktur danych. Funkcjonalność narzędzia powinna pozwalać na analizę wpływu zmian w modelu na aktualnie wykorzystywane obiekty bazodanowe.

Oprogramowanie musi dostarczyć narzędzia do graficznego monitorowania wydajności bazy danych oraz narzędzia do zarządzania bazą danych.

2.3.3.3 Serwer aplikacji

Oprogramowanie serwera aplikacji musi spełniać następujące wymagania: możliwość instalacji i uruchomienia na minimum 5 rdzeniach procesora serwera chmury

akademickiej, oprogramowanie musi być posiadać certyfikaty zgodności ze standardami JEE5 i JEE6. oprogramowanie musi być zgodne wstecz z poprzednimi wersjami standardu JEE (1.4, 1.3, 1.2) oprogramowanie musi posiadać wsparcie dla co najmniej: WS-Atomic Transactions, WS-

Coordination, WS-Notification, WS-Business Activity. musi być zgodne z profilami interoperacyjności WS-I. musi być zgodne ze specyfikacją JSR 286 (portlety). posiadać wsparcie dla tworzenia aplikacji z użyciem modelu OSGi.

25 / 62


powinno umożliwiać uruchamianie kodu PHP, Groomy. powinno umożliwiać automatyczne odtwarzanie transakcji (ang. 2 Phase Commit) w przypadku

awarii. powinno posiadać narzędzia do analizy i odtwarzania transakcji w stanie „in-doubt”. posiadać udokumentowane kody błędów. posiadać narzędzia do analizy wykorzystania oraz odśmiecania pamięci (ang. garbage collection). powinno posiadać wsparcie dla wykrywania wycieków pamięci oraz podejmowania akcji

naprawczych. powinno posiadać narzędzia wspomagające podnoszenie wydajności systemu. musi posiadać mechanizm dla równoważenia obciążenia ruchu HTTP. musi wspierać przechowywanie sesji w pamięci i bazie danych oraz jej replikację między węzłami powinno wspierać klastrowanie EJB oraz JMS powinno wspierać restart klastra w sposób zapewniający ciągłość działania aplikacji musi wspierać testowanie i uruchamianie nowych wersji aplikacji z zachowaniem ciągłości działania

aplikacji musi posiadać wbudowaną konsole administracyjną (GUI) umożliwiająca zdalną administrację

serwerem musi umożliwiać uruchamianie wielu wersji tej samej aplikacji musi umożliwiać centralną administrację wieloma serwerami aplikacyjnymi musi umożliwiać administrację z linii poleceń. musi umożliwiać centralną administrację serwerami aplikacyjnymi w różnych wersjach powinno umożliwiać automatyczne dodawanie/usuwanie nowych serwerów aplikacyjnych z klastra

w zależności od obciążenia powinno posiadać wbudowaną obsługę priorytetyzacji oraz ograniczenia obciążenia dla zapytań

HTTP/JMS/IIOP. powinno posiadać wbudowane wsparcie dla monitorowania SLA i w przypadku ich przekroczenia

powiadamiania administratorów i podejmowania akcji naprawczych. musi zapewniać wsparcie dla zabezpieczania aplikacji webowych przy wykorzystaniu ról. musi posiadać zaszyfrowane połączenia między węzłami klastra a komponentem administrującym

całością. powinno posiadać wsparcie dla standardów Kerberos/SPNEGO (SSO). musi posiadać wbudowane wsparcie dla audytu i śledzenia akcji podejmowanych przez

administratorów. musi posiadać mechanizmy wsparcia zarządzania certyfikatami SSL.

2.3.3.4 Oprogramowanie do projektowania procesów biznesowych i integracji

Oprogramowanie do projektowania procesów biznesowych musi spełniać następujące wymagania: Możliwość instalacji i uruchomienia oprogramowania dla minimum 10 użytkowników, Oprogramowanie do projektowania procesów biznesowych musi spełniać następujące wymagania: Oprogramowanie musi umożliwiać modelowanie przepływów procesów zgodne z notacją BPMN:

Modelowanie przy wykorzystaniu torów pływackich (ang. swimlane) Modelowanie typów zadań (min.: manualne, automatyczne) oraz oznaczanie ich kolorami Modelowanie aspektów dynamicznych BPMN:

Zegary (modelowanie opóźnień w procesach i maksymalnych czasów wykonywania czynności)

Modelowanie zadań ad-hoc Modelowanie komunikatu zewnętrznego jako startera procesu Modelowanie komunikatu zewnętrznego dostarczanego do procesu w trakcie jego

działania Modelowanie obsługi wyjątków w zadaniach procesowych

Modelowanie zasobów ludzkich: Ilość zasobów Dostępność (kalendarze pracy)

Modelowanie danych: Budowanie modelu danych:

26 / 62


Typy proste Zawieranie obiektów z modelu jako atrybuty w innych obiektach Automatyczne aktualizowanie obiektów zależnych przy zmianie obiektu

bazowego Przypisywanie obiektów biznesowych do każdego elementu procesu biznesowego Import i eksport struktur danych w formacie XSD

Modelowanie pracochłonności: Stała pracochłonność Pracochłonność przypisywana losowo (według rozkładów statystycznych)

Modelowanie kosztów zasobów Modelowanie organizacji (definiowanie struktury organizacyjnej)

Możliwości symulacji procesów: Definiowanie parametrów symulacji Zapisywanie parametrów symulacji w celu ponownego wykorzystania, możliwość

zapisywania różnych zestawów parametrów symulacji dla każdego procesu Wykonywanie symulacji Analiza wyników symulacji:

Analiza wąskich gardeł Analiza porównawcza z innymi wersjami procesu Analiza porównawcza z innymi parametrami symulacji

Automatyczne przemodelowanie procesu w odpowiedzi na określone warunki obciążeniowe

Narzędzie musi umożliwiać bezpośrednie wykorzystanie zbudowanych modeli procesów do budowania aplikacji procesowych, bez kroków pośrednich.

Musi zapewniać wspólne narzędzie do modelowania procesów i uzupełniania modeli o szczegóły implementacyjne w celu przekształcenia modelu procesu w aplikację procesową – wspólny obszar roboczy dla analityków biznesowych oraz programistów IT.

Musi dostarczać kompleksowe i zintegrowane środowisko do budowy rozwiązań procesowych: Musi posiadać edytor procesów Musi posiadać edytor reguł biznesowych Musi posiadać edytor zadań manualnych Musi posiadać edytor integracji Musi posiadać mechanizm monitorowania procesów Musi posiadać narzędzia do modelowania interfejsu użytkownika:

umożliwiające edycję formatek, z którymi pracować będą uczestnicy procesu biznesowego. umożliwiające zdefiniowanie widoku prezentującego określony fragment modelu danych.

Zakres przekazywanych danych konfiguracyjnych do widoku musi obejmować minimum: zawartość tekstów, widoczność elementów, tryb wyświetlania pól, wartości elementów, konfiguracja przycisków widoku.

Umożliwiające tworzenie formatek bezpośrednio wykorzystywanych w systemie procesowym.

umożliwiające rozszerzalność interfejsu użytkownika: możliwość wszczepiania dowolnych wstawek wykonywanych po stronie przeglądarki; wsparcie modelu DOM (Document Object Model); dostęp do danych procesowych z poziomu tych rozszerzeń; wsparcie dla technologii AJAX. możliwość zagnieżdżania zewnętrznych aplikacji webowych. możliwość budowania własnych komponentów interfejsu użytkownika i możliwość

ponownego ich użycia. Musi posiadać narzędzia do modelowania czynności integracyjnych:

modelowanie wywołań zewnętrznych funkcjonalności typu Web Service, interakcja z bazą danych, systemem kolejek.

możliwość połączenia, w ramach jednego kroku procesu BPMN szeregu formatek i usług integracyjnych.

Integracja z e-mail, co najmniej: proces uruchamiany nadejściem maila na wskazany adres, wysyłanie maila z procesu.

27 / 62


Modelowanie w warstwie BPMN obsługi błędów integracyjnych: rozróżnienie błędów technicznych i biznesowych, różne sposoby obsługi różnych typów błędów.

Implementacja integracji z repozytorium dokumentów. Implementacja uprawnień/ról użytkowników w procesach Zapewnienie wielu metod przypisywania pracowników do zadań ludzkich, co najmniej:

Statyczne określanie praw dostępu pracowników do zadań, Grupy wyliczane regułami biznesowymi, Obsługa nieobecności pracowników w danym dniu roboczym.

Delegowanie zadań – możliwości przydzielania zadań ad-hoc (niezwiązanych z instancjami procesów biznesowych) – wykorzystanie platformy wykonawczej do komunikacji pomiędzy pracownikami i przekazywaniu zadań nie będących krokami wykonywanych procesów biznesowych).

Eskalowanie: eskalacja automatyczna w oparciu o kryteria zdefiniowane dla danego zadania, eskalacja ręczna.

Reguły biznesowe: wbudowany silnik reguł biznesowych, możliwość dynamicznego przedefiniowywania reguł w trakcie pracy systemu bez udziału IT (narzędzie dla menedżerów procesów).

rozszerzalność o dowolny kod aplikacyjny uruchamiany po stronie serwera. wsparcie dla języka polskiego (standardy kodowania znaków). możliwość wykorzystania bibliotek, biblioteki mogą zawierać wszystkie typy komponentów

(procesy, formularze, usługi, struktury danych): Aplikacje procesowe mogą wykorzystywać komponenty zgrupowane w bibliotekach Biblioteki są wersjonowane niezależnie od aplikacji procesowych Każda aplikacja procesowa ma możliwość bycia zależną od wskazanej,

niekoniecznie najnowszej, wersji biblioteki możliwość wersjonowanie wszystkich typów komponentów stanowiących aplikację

procesową przy pomocy jednej prostej operacji administracyjnej możliwość kopiowania/przenoszenia komponentów pomiędzy bibliotekami a

aplikacjami procesowymi, automatyczne uwzględnienie komponentów zależnych od przenoszonego (uniknięcie rozerwanych linków między komponentem podrzędnym i nadrzędnym przy przeniesieniu jednego z nich do/z biblioteki)

Możliwość dołączenia do instancji procesu dowolnych plików jako załączniki. Możliwość zdefiniowania wyzwalaczy ogólnych (niezależnych od procesu) oraz

dołączanych do konkretnego procesu. Możliwość uruchamiania procesów lub dostarczania danych do działających procesów

(korelacja: dostarczanie danych do właściwej podgrupy instancji działającego procesu) poprzez mechanizm wyzwalaczy.

Pełne udokumentowanie struktur danych silnika procesowego: Możliwość dostępu bezpośrednio na poziomie danych do silnika procesowego. Możliwość dostępu przez API do danych silnika procesowego. Możliwość programistycznego wykonywania działań na silniku procesowym w

zakresie: definicji procesów, instancji procesów, zadań, użytkowników, struktur danych procesów.

Wsparcie dla tworzenia rozwiązań przez wieloosobowe zespoły robocze: Wbudowane repozytorium aplikacji procesowych, bibliotek i komponentów

usługowych Wspólne rozwijanie aplikacji procesowych, Możliwość ograniczenia dostępu do

poszczególnych bibliotek i aplikacji poszczególnym członkom zespołu Wersjonowanie Możliwość zrównoleglenia ścieżek rozwoju aplikacji procesowych (mechanizm

rozgałęziania budowy kodu), możliwość kopiowania/przenoszenia komponentów pomiędzy wersjami aplikacji

Mechanizm oznaczania komponentów znacznikami (min. określającymi stan komponentu, autora, przeznaczenie): Predefiniowane znaczniki Dodawanie własnych znaczników Wyszukiwanie komponentów wg znaczników

28 / 62


Budowanie widoków pokazujących w jednym miejscu wszystkie komponenty opisane znacznikiem

Ustalenie reguł nadzoru aplikacji procesowych: Możliwość zdefiniowania procesów nadzorczych, Możliwość wymuszenia stosowania procesu nadzorczego dla określonej aplikacji

procesowej: Możliwość stosowania różnych procesów nadzorczych dla różnych aplikacji

procesowych Obsługa cyklu życia aplikacji procesowej, opisanego stanami (co najmniej:

projektowana, testowana, wdrożona, wycofana) Integracja z narzędziem do zarządzania wymaganiami (opisanym w punkcie 2.3.3.7)

Możliwość osadzenia w aplikacji procesowej łącz do wymagań zarządzanych systemem zarządzania wymaganiami

Możliwość dokumentowania wymagań bezpośrednio na poziomie komponentów procesowych

Dokumentowanie aplikacji procesowych Generowanie dokumentacji PDF lub HTML. Dokumentacja porównawcza (zestawiająca dwie wersje aplikacji procesowej,

pozwalająca na wgląd w różnice pomiędzy wersjami) Dokumentacja techniczna musi być powszechnie dostępna poprzez publiczne strony www. Dokumentacja musi zawierać instrukcje dla administratora oraz dla programisty /

projektanta.

2.3.3.5 Silnik procesów biznesowych

Oprogramowanie silnika procesów biznesowych musi spełniać następujące wymagania: możliwość instalacji i uruchomienia na minimum 2 rdzeniach procesora serwera chmury

akademickiej, musi posiadać wbudowaną aplikację internetową przeznaczoną dla użytkownika biznesowego

umożliwiającą: Uruchamianie procesów biznesowych Podgląd kolejki zadań Przenoszenie zadań z kolejek ogólnych (organizacji, działu) do kolejki użytkownika

(pobieranie zadań do wykonania) Wykonywanie zadań – praca z formularzami utworzonymi na etapie modelowania procesu Zarządzanie procesami biznesowymi:

Dynamiczna modyfikacja przepływu procesów biznesowych (dla procesów, których konstrukcja dopuszcza taką modyfikację)

Zarządzanie pracą działu (dla użytkowników z uprawnieniami kierownika działu) Dynamicznego (ad-hoc):

definiowania podzadań, wysyłania zapytań, oczekiwania przez proces na wykonanie dodatkowego zadania utworzonego w tym

procesie przez użytkownika. Pełna obsługa produkcyjnego systemu (aplikacji biznesowych) przez przeglądarkę – brak

konieczności instalacji na stacji roboczej użytkownika dedykowanego oprogramowania/bibliotek; wsparcie dla co najmniej następujących przeglądarek IE6, IE8 i następnych, FireFox 3.6 i następnych.

Możliwość integracji z systemami pocztowymi w zakresie usług pocztowych (wysyłanie powiadomień do użytkowników, inicjowanie procesu z maila), dostarczania kolejki zadań użytkowników bezpośrednio do ich programu pocztowego bez budowania w procesach funkcjonalności każdorazowego wysyłania mailem informacji o zadaniu.

Możliwość szczegółowego definiowania uprawnień do poszczególnych procesów biznesowych. Interfejs użytkownika dostępny na urządzeniach przenośnych, co najmniej dla systemów iOS i

Android. Wsparcie dla komunikacji między uczestnikami procesu – możliwość wysyłania powiadomień i

29 / 62


uzyskiwania wsparcia od innych osób w organizacji na etapie wykonywania poszczególnych zadań procesowych

Zadawanie pytań innym użytkownikom i uzyskiwanie odpowiedzi. Informacje o zadanych pytaniach i odpowiedziach widoczne bezpośrednio na ekranie prezentującym formatkę będącą treścią zadania procesowego.

Przekazanie uprawnień do formatki i wykonanie jej na wspólnym ekranie przez wykonawcę docelowego oraz wspomagającego eksperta

Możliwość określenia różnych grup administratorów dla poszczególnych aplikacji procesowych Wersjonowanie procesów Niezależne utrzymywanie wielu wersji każdego procesu Automatyczne wybieranie aktualnej wersji procesu przy próbie uruchomienia nowej instancji

procesu Możliwość definiowania wersji procesu, która zacznie obowiązywać w przyszłości Możliwość migrowania procesów z wersji aktualnej do kolejnej

Wyświetlanie listy instancji procesów w oparciu o daną postać procesu Graficzne narzędzie do migracji procesów Możliwość graficznego porównywania kolejnych wersji procesu biznesowego Platforma zapewnia poprawność wykonania migracji

Musi zapewniać ten sam interfejs użytkownika dla narzędzi developerskich dla: Procesów opartych o zapis BPMN Procesów opartych o standard BPEL Przebiegów integracyjnych szyny ESB Monitorowania procesów BAM

Środowisko musi wykorzystywać standardy branżowe: Wykorzystanie Eclipse jako fundamentu konstrukcyjnego narzędzi developerskich Wykorzystanie BPMN oraz BPEL w opisie procesów Możliwość modelowania procesów jako maszyn stanowych Wsparcie dla JEE (integracja przez co najmniej JMS, Web Services, HTTP(S), REST) Możliwość wykorzystania architektury komponentowej (ang. SCA - Service Component

Architecture) Integracja z LDAP

Dostępne konektory technologiczne, co najmniej: JDBC, e-mail, ftp, pliki płaskie, Wsparcie dla budowania aplikacji zawierających w jednym logicznym komponencie procesów

BPMN, BPEL oraz przebiegów integracyjnych warstwy ESB: Wykorzystania definicji procesów BPEL w procesach BPMN Wykorzystania definicji procesów BPMN w procesach BPEL i przebiegach integracyjnych Komunikacja pomiędzy procesami integracyjnymi (BPEL) oraz biznesowymi (BPMN)

Obsługa błędów z zastosowaniem mechanizmu obsługi wyjątków: Wielopoziomowa obsługa wyjątków Obsługa błędów może kończyć się powrotem do głównej ścieżki procesu

Wbudowany moduł testów: Definiowanie przebiegów i scenariuszy testowych oraz analiza statystyczna przebiegu

wykonania scenariusza testowego Zapisywanie przebiegów i scenariuszy testowych do późniejszego wykorzystania oraz

wczytywanie przebiegów/scenariuszy z zapisanego pliku Oprogramowanie musi posiadać architekturę trójwarstwowa:

bazę danych spełniającą wymagania podane w rozdziale 2.3.3.1 platformę aplikacyjną spełniającą wymagania podane w rozdziale 2.3.3.3

Wydajność i skalowalność Oprogramowanie musi mieć możliwość uruchomiona na platformie sprzętowej Chmury

Akademickiej (opisanej w punkcie 2.3.1) Platforma musi mieć wbudowane mechanizmy zapewniania wysokiej dostępności (ang.

High-Availability) bez konieczności wykorzystywania produktów trzecich. Oprogramowanie musi zapewniać możliwość definiowania klastrów, w których prawidłowo działa

przechwytywanie obciążenia przez pozostałe maszyny w razie awarii jednej z nich

30 / 62


Oprogramowanie musi zapewniać przechowywanie stanu procesów w sposób umożliwiający ich kontynuację po restarcie systemu

Oprogramowanie musi zapewniać mechanizm wdrażania nowych wersji procesów przy wykorzystaniu zdefiniowanego procesu nadzorczego, bez możliwości ominięcia tego procesu przez aplikację.

Monitorowanie elementów silnika procesowego w czasie rzeczywistym. Możliwości administrowania procesami w trakcie ich działania:

Uruchamianie Zatrzymywanie Przywracanie Zamykanie Pełen wgląd przez administratora do zmiennych procesu, możliwość modyfikowania

wartości zmiennych procesu Administracyjna zmiana uprawnień (własności) procesu i jego elementów Administrowanie datami wygaśnięcia zadań i całego procesu, długościami czasów

oczekiwania (zarządzanie ścieżką krytyczną)

2.3.3.6 Platforma integracyjna

Oprogramowanie platformy integracyjnej musi spełniać następujące wymagania: możliwość instalacji i uruchomienia na minimum 5 rdzeniach procesora serwera chmury

akademickiej Oprogramowanie musi mieć możliwość uruchomiona na platformie sprzętowej Chmury

Akademickiej (opisanej w punkcie 2.3.1), Dostarczone oprogramowanie komunikacyjne w zakresie bezpieczeństwa danych posiada pełne i

wbudowane wsparcie protokołu SSL. Oprogramowanie musi posiadać wbudowany system kolejkowy. System kolejkowy musi dostarczać komunikaty w trybie synchronicznym i asynchronicznym

(kolejkowanie komunikatów) z wykorzystaniem co najmniej JMS (ang. Java Message Service). System kolejkowy musi posiadać możliwość tworzenia definicji usług co najmniej przy

wykorzystaniu standardu WSDL. System kolejkowy musi wspierać rozwiązania klastra wydajnościowego zapewniającego

loadbalancing w ramach węzłów klastra. System kolejkowy musi wspierać rozwiązania klastra niezawodnościowego bez dodatkowego

oprogramowania. System kolejkowy musi posiadać graficzną konsolę administracyjną opartą o technologię Eclipse,

oraz posiadać administracyjną konsolę tekstową. System kolejkowy musi zapewniać funkcjonalność co najmniej serwera JMS bez konieczności

stosowania dodatkowych komponentów; System kolejkowy musi gwarantować doręczenie komunikatu pomiędzy dwoma, lub wieloma

aplikacjami z mechanizmem wyślij i zapomnij (ang. fire and forget). System kolejkowy musi zawierać mechanizmy pozwalające na niezawodne dostarczanie

komunikatów. Oprogramowanie musi posiadać wbudowaną szynę komunikacyjną. Szyna komunikacyjna musi umożliwiać logowanie komunikatów przepływających miedzy

integrowanymi aplikacjami w bazie danych Szyna komunikacyjna musi umożliwiać komunikację zgodnie ze standardami Web Services. Szyna komunikacyjna musi wspierać obsługę WSDL (ang. Web Services Definition Language). Szyna komunikacyjna musi wspierać standard SOAP (ang. Simple Object Access Protocol) Szyna komunikacyjna musi wspierać standard WS-Addressing Szyna komunikacyjna musi wspierać standard WS-Security Szyna komunikacyjna musi wspierać komunikację typu request-response oraz publish-subscribe Szyna komunikacyjna musi zapewniać ciągłość pracy w przypadku awarii węzła głównego

następuje automatyczne przełączenie na węzeł zapasowy. Szyna komunikacyjna musi mieć możliwość budowy środowiska o wysokiej dostępności (ang. High

Availability).

31 / 62


Szyna komunikacyjna musi wspierać mechanizm automatycznego przejęcia działania serwera głównego przez serwer zapasowy.

Szyna komunikacyjna musi wspierać walidację poprawności przepływających komunikatów co najmniej następującym zakresie:

Sprawdzania poprawności składni z założonym schematem XML. Lokalizacji błędu odstępstwa od założonego schematu. Notyfikacji aplikacji o błędzie

Szyna komunikacyjna musi posiadać narzędzia umożliwiające modelowanie definicji komunikatów w środowisku graficznym i z poziomu języka skryptowego, w co najmniej następującym zakresie:

Definicji reguł przepływów. Przetwarzania i zmiana formatu treści komunikatów. Definiowania formatów co najmniej w XML i C. Wspierania otwartego standardu DFDL (ang. Data Format Description Language).

Szyna komunikacyjna musi posiadać możliwość sterowania przepływem danych na podstawie wartości przesyłanych komunikatów.

Szyna komunikacyjna musi umożliwiać wzbogacanie transformacji danych zgodnie z warunkami logicznymi.

Szyna komunikacyjna musi posiadać graficzny debugger z możliwością krokowego śledzenia przetwarzania, z możliwością zmiany wartości zmiennych

Szyna komunikacyjna musi posiadać narzędzie deweloperskie wykorzystujące Eclipse Szyna komunikacyjna musi wspierać transformację przesyłanych danych za pomocą przynajmniej

wymienionych poniżej technik: arkuszy XSLT, języka JAVA, PHP, .Net. Szyna komunikacyjna musi wspierać tworzenie kodu integracyjnego wewnątrz przepływów dla

przynajmniej następujących języków: JAVA, PHP, .Net. Szyna komunikacyjna musi wspierać możliwość tworzenia dodatkowych węzłów zawierających

logikę obsługi komunikatów dla co najmniej następujących języków programowania: Java, C. Szyna komunikacyjna musi obsługiwać następujące protokoły: HTTP, HTTPS, SOAP, FTP, SFTP,

ODBC, CORBA, JDBC, TCP/IP, JMS, Pliki płaskie. Szyna komunikacyjna musi umożliwiać cykliczne uruchamianie przepływów oraz tworzenia

harmonogramów wykonań przepływów. Szyna komunikacyjna musi umożliwiać wywołanie wielu usług i agregacji ich odpowiedzi Szyna komunikacyjna musi posiadać możliwość określania liczby zdarzeń zewnętrznych

potrzebnych do uruchomienia usługi. Szyna komunikacyjna musi wspierać mechanizmy realizacji transakcji rozproszonych na wielu

bazach danych za pomocą połączeń ODBC i JDBC przez protokół XA Szyna komunikacyjna musi zapewniać mechanizmy bezpieczeństwa dla usług w szczególności:

Uwierzytelnianie Autoryzację Przechowywania kluczy i certyfikatów cyfrowych Obsługę wyjątków w zakresie bezpieczeństwa

Szyna komunikacyjna musi posiadać API dla co najmniej następujących języków programowania: C, C++, Java, C#, VisualBasic, .Net.

Szyna komunikacyjna musi umożliwiać definiowanie maksymalnej liczby wątków dla usługi. Szyna komunikacyjna musi pozwalać na zarządzanie SLA dla usług. Oprogramowanie musi posiadać obsługę wzorców projektowych. Oprogramowanie musi pozwalać definiować własne wzorce projektowe i generować na ich

podstawie kod. Szyna komunikacyjna musi pozwalać obsługiwać protokół telemetryczny MQTT (ang. Message

Queue Telemetry Transport). Szyna komunikacyjna musi posiadać konsolę administracyjną dostępną za pomocą przeglądarki Szyna komunikacyjna musi pozwalać w konsoli administracyjnej przeglądać co najmniej statystyki

dotyczące liczby wywołań, rozmiar komunikatów, czasu trwania przetwarzania dla konkretnych węzłów.

32 / 62


2.3.3.7 Środowisko zarządzania cyklem wytwórczym oprogramowania (CWO)

Wymagania na środowisko zarządzania cyklem wytwórczym oprogramowania: Musi zapewniać wspólne repozytorium wykorzystujące bazę danych. Musi zapewnić integrację narzędzi do Zarządzania Wymaganiami, Zarządzania Zmianą i

Zarządzania Jakością. obejmująca możliwość analizy wpływu (Impact Analysis) oraz pokrycia (Coverage Analysis)

Repozytorium danych dla platformy musi wykorzystywać bazę danych opisaną wymaganiami w rozdziale 2.3.3.1

Środowisko musi wykorzystywać platformę aplikacyjną spełniającą wymagania podane w rozdziale 2.3.3.3

Oprogramowanie musi umożliwiać dostosowanie narzędzi do przyjętej metodyki wytwarzania oprogramowania. Standardowo muszą być dostarczone konfiguracje dla co najmniej następujących metodyk: Scrum, Rational Unified Process, OpenUp

Oprogramowanie musi umożliwiać konfigurację ról i uprawnień. Oprogramowanie musi umożliwiać konfigurację wzorców wyglądów ekranów. Wszystkie narzędzia muszą być dostępne w polskiej wersji językowej. Oprogramowanie musi umożliwiać definiowanie i przekazywanie zadań w obszarze

wszystkich elementów platformy Oprogramowanie musi umożliwiać komunikację między użytkownikami narzędzi. Oprogramowanie musi udostępniać otwarte API do integracji z innymi rozwiązaniami. Oprogramowanie musi umożliwiać integrację z pocztą email. Oprogramowanie musi posiadać wbudowany silnik business inteligence pozwalający na

tworzenie rozbudowanych raportów dotyczących procesów wytwórczych oprogramowania. Zarządzanie Wymaganiami:

Możliwość instalacji i uruchomienia oprogramowania dla minimum 10 użytkowników, Oprogramowanie musi umożliwiać definiowanie wymagań/artefaktów w postaci:

Tekstu, Zbiorów wymagań, Szkiców interfejsu użytkownika, Projektów interfejsu użytkownika, Projektów przepływu sterowania między ekranami, Storyboard Diagramów procesów biznesowego, Diagramów przypadków użycia

Oprogramowanie musi umożliwiać definiowanie słowników wykorzystywanych do opisu wymagań.

Oprogramowanie musi umożliwiać definiowanie atrybutów wymagań Oprogramowanie musi umożliwiać prezentację historii zmian wymagań wraz z

informacjami kto, co i kiedy zmienił. Oprogramowanie musi umożliwiać tworzenie szablonów na podstawie już istniejących

szablonów wymagań lub dokumentów Oprogramowanie musi umożliwiać tworzenie artefaktów na podstawie dokumentu w

formacie co najmniej MS Word lub OpenOffice wraz z tworzeniem powiązań pomiędzy dokumentem, a powstałym artefaktem

Oprogramowanie musi umożliwiać organizowanie artefaktów w strukturę drzewiastą. Oprogramowanie musi umożliwiać przypisywanie do artefaktów znaczników (tzw. tagi) Oprogramowanie musi umożliwiać tworzenie kolekcji wymagań (grup) i dodawanie do nich

artefaktów. Oprogramowanie musi umożliwiać tworzenie i obsługa przeglądów/recenzji wymagań Oprogramowanie musi umożliwiać graficzne wyświetlanie zależności między artefaktami. Oprogramowanie musi umożliwiać tworzenie powiązań między artefaktami, co najmniej:

Zawiera - Zawarte, Dziecko - Rodzic, Powiązanie Do - Powiązanie Od, Synonim,

33 / 62


Implementowane przez, Śledzone przez, Testowane przez, Możliwość tworzenia własnych relacji pomiędzy artefaktami

Oprogramowanie musi umożliwiać dodawanie komentarzy do artefaktów, komentarze muszą być widoczne dla użytkowników oprogramowania.

Oprogramowanie musi umożliwiać filtrowanie wymagań co najmniej po: znacznikach, atrybutach, kolekcjach.

Oprogramowanie musi umożliwiać tworzenie i używanie migawek wymagań (ang. snapshot)

Oprogramowanie musi umożliwiać wykonywanie operacji dla wybranej grupy wymagań Oprogramowanie musi umożliwiać eksport do co najmniej następujących formatów: PDF,

Word Oprogramowanie musi umożliwiać eksport i import artefaktów do i z formatu CSV Oprogramowanie musi umożliwiać śledzenie zależności i zmian (ang. traceability). Oprogramowanie musi umożliwiać analizę wpływu zmiany wymagania na pozostałe

wymagania Oprogramowanie musi umożliwiać łączenie wymagania z zadaniami dla programistów Oprogramowanie musi umożliwiać łączenie wymagania z przypadkami testowymi oraz

planami testów Oprogramowanie musi umożliwiać definiowanie paneli kontrolnych dla każdego

użytkownika. Panele kontrolne powinny prezentować aktualne informacje z procesu inżynierii wymagań (co najmniej: aktualne zmiany, recenzje przypisane do użytkownika)

Oprogramowanie musi zapewniać mechanizm akceptacji recenzji i komentarzy Zarządzanie Zmianą:

Możliwość instalacji i uruchomienia oprogramowania dla minimum 10 użytkowników, Oprogramowanie musi umożliwiać obliczanie czasu poświęconego na realizacje zadań Oprogramowanie musi umożliwiać prezentację informacji nad czym aktualnie pracują

poszczególni członkowie zespołu. Oprogramowanie musi wspierać co najmniej następujące metodyki: Scrum, OpenUp Oprogramowanie musi umożliwiać adaptację narzędzi do wsparcia dowolnych procesów

tworzenia oprogramowania Oprogramowanie musi umożliwiać konfigurowanie dostępu do zasobów oraz akcji z

wykorzystaniem ról Oprogramowanie musi umożliwiać podział zespołu projektowego na podzespoły z

wydzielonymi uprawnieniami Oprogramowanie musi umożliwiać pomiar w czasie rzeczywistym aktywności zespołu Oprogramowanie musi umożliwiać informowanie zespołu o nowych wydarzeniach i

zadaniach, które zostały im zlecone Oprogramowanie musi umożliwiać przypisywanie zadań do osób lub ról Oprogramowanie musi posiadać wbudowany system zarządzania wersjami kodu

źródłowego Oprogramowanie musi umożliwiać przypisywania zmian w kodzie do zadań lub błędów. Oprogramowanie musi umożliwiać połączenie zmian w kodzie źródłowym z zadaniami Oprogramowanie musi umożliwiać tworzenie własnych typów zadań Oprogramowanie musi umożliwiać łączenie zadań ze sobą za pomocą powiązań Oprogramowanie musi umożliwiać prezentację historii zmian elementów Oprogramowanie musi umożliwiać definiowanie własnych przepływów prac Oprogramowanie musi umożliwiać tworzenie przeglądów zadań Oprogramowanie musi umożliwiać tworzenie planów realizacji zadań oraz defektów z

podziałem na role Oprogramowanie musi umożliwiać monitorowanie realizacji zadań z podziałem na role i

podzespoły. Oprogramowanie musi umożliwiać powiązanie zadań pomiędzy sobą, a także

wymaganiami, przypadkami testowymi oraz innymi artefaktami. Oprogramowanie musi posiadać wbudowany system raportowania postępu prac.

34 / 62


Oprogramowanie musi umożliwiać zdefiniowanie specyfikacji dnia pracy. Oprogramowanie musi umożliwiać grupową edycję atrybutów elementów

przechowywanych w ramach repozytorium.

Zarządzanie Jakością: Możliwość instalacji i uruchomienia oprogramowania dla minimum 10 użytkowników, Oprogramowanie musi umożliwiać tworzenie i zarządzanie planem testów:

Określenie celów testowania. Definiowanie przeglądów formalnych oraz procesu zatwierdzania. Przypisania do kolekcji wymagań. Oceny Ryzyka. Harmonogramy testowania. Szacowanie testowania. Środowiska testowe. Zespół testowy. Cele jakościowe. Pakiety testowe. Instrukcje testowania. Zasoby.

Oprogramowanie musi umożliwiać import/eksport planu testów Oprogramowanie musi umożliwiać wydruki planu testów. Oprogramowanie musi umożliwiać zarządzanie szablonami wydruku planu testów. Oprogramowanie musi umożliwiać tworzenie migawek planów testów oraz śledzenia

historii zmian planów Oprogramowanie musi umożliwiać tworzenie i zarządzanie przypadkami testowymi

Instrukcje testowania: Projekty instrukcji, Przeglądy formalne, Elementy projektowania, Powiązania wymagań, Ocena ryzyka, Warunek wstępny, Warunek końcowy, Wyniki oczekiwane, Skrypty testowe, Rekordy wykonania instrukcji testowania,

Oprogramowanie musi umożliwiać drukowanie przypadku testowego według istniejących szablonów

Oprogramowanie musi umożliwiać eksportowanie i importowanie przypadków testowych Oprogramowanie musi umożliwiać tworzenie migawek przypadków testów oraz śledzenie

historii zmian przypadków Oprogramowanie musi umożliwiać tworzenie i zarządzanie skryptami testowymi

Opis Kroki scenariusza Elementy projektowania, Właściciel Dane testowe Warunek wstępny, Warunek końcowy, Możliwość połączenia scenariusza z polami danych testowych

Oprogramowanie musi umożliwiać drukowanie scenariusza testowego według istniejących szablonów

Oprogramowanie musi umożliwiać eksportowanie i importowanie scenariuszy testowych Oprogramowanie musi umożliwiać tworzenie migawek scenariuszy testów oraz śledzenie

historii zmian scenariuszy Oprogramowanie musi umożliwiać definiowanie manualnych scenariuszy testowych, za

35 / 62


pomocą wbudowanego edytora tekstu. Oprogramowanie musi umożliwiać dodawanie jako skryptu plików narzędzi

automatyzujących testy. Oprogramowanie musi umożliwiać dodawanie skryptów wywoływanych z linii poleceń. Oprogramowanie musi umożliwiać przydzielanie zadań dla członków zespołu testowego Oprogramowanie musi umożliwiać definiowanie własnego procesu testowania Oprogramowanie musi umożliwiać definiowanie przebiegu procesu z uwzględnieniem

czasu projektu, dostępnych zasobów oraz ról Oprogramowanie musi umożliwiać zarządzanie danymi testowymi

Wersjonowanie Wiązanie danych testowych z planami testów, przypadkami testowymi oraz

scenariuszami Oprogramowanie musi umożliwiać zarządzanie środowiskami testowymi:

ewidencji środowisk testowych oraz dostępnych zasobów wyszukiwania i rezerwowania zasobów wsparcie dla środowisk fizycznych i wirtualnych

Oprogramowanie musi umożliwiać prezentację historii uruchomień testów Oprogramowanie musi umożliwiać rejestrację błędów z krokami scenariusza testowego. Oprogramowanie musi umożliwiać przydzielenie do błędu statusu, który uniemożliwia

dalsze uruchamianie przypadku testowego Oprogramowanie musi umożliwiać definiowanie szablonów raportów wspierających proces

testowania oprogramowania Oprogramowanie musi umożliwiać tworzenie rozbudowanych raportów Oprogramowanie musi zapewniać funkcjonalność zarządzania defektami Oprogramowanie musi zapewniać funkcjonalność zarządzania wymaganiami Oprogramowanie musi umożliwiać łączenie planów testowych z przypadkami testowymi Oprogramowanie musi umożliwiać łączenie przypadków testowych ze scenariuszami

testowymi Oprogramowanie musi umożliwiać definiowanie przeglądów planów testów Oprogramowanie musi umożliwiać grupowania przypadków scenariuszy testowych w

grupy i uruchamianie ich równolegle lub sekwencyjnie Oprogramowanie musi umożliwiać przegląd wyników realizowanych testów przez

programistów.

Zarządzanie testami funkcjonalnymi: Możliwość instalacji i uruchomienia oprogramowania dla minimum 5 użytkowników, Oprogramowanie musi umożliwiać zautomatyzowanie testów funkcjonalnych i regresyjnych Oprogramowanie musi umożliwiać testowanie aplikacji z co najmniej z interfejsem: WWW, .Net,

Java, SAP, Ajax, Adobe Flex, Dojo Toolkit. Oprogramowanie musi umożliwiać wizualizację i edycję testów. Oprogramowanie musi umożliwiać wykonywanie tej samej serii czynności na różnych zestawach

danych testowych w sposób automatyczny. Oprogramowanie musi umożliwiać automatyczne generowanie scenariuszy testowych. Oprogramowanie musi umożliwiać generowanie i edycję scenariuszy w co najmniej w językach:

Visual Basic, Java. Oprogramowanie musi umożliwiać generowanie raportów w co najmniej: HTML, TXT. Oprogramowanie musi posiadać wbudowany mechanizm debugowania skryptów testowych. Oprogramowanie musi umożliwiać uruchamianie nowych wersji aplikacji dla starej wersji skryptów. Oprogramowanie musi umożliwiać stosowanie testowania ukierunkowanego na dane. Oprogramowanie musi umożliwiać wygenerowanie skryptu testowego w postaci kroków aplikacji jak

i kodu skryptu Oprogramowanie musi umożliwiać uruchamianie skryptów przy użyciu centralnej konsoli do

zarządzania testami.Zarządzanie testami wydajnościowymi: Możliwość instalacji i uruchomienia oprogramowania dla minimum 1 użytkownika z obsługą

minimum 100 wirtualnych testerów,

36 / 62


Oprogramowanie musi pozwalać na nagrywanie i odtwarzanie skryptów dla zdefiniowanej puli wirtualnych użytkowników, w określonych odstępach czasowych.

Oprogramowanie musi umożliwiać edycję skryptów. Oprogramowanie musi pozwalać na parametryzację skryptów. Oprogramowanie musi pozwalać na wstawianie instrukcji warunkowych, pętli, punktów

weryfikacyjnych oraz synchronizacyjnych w ramach skryptu. Oprogramowanie musi pozwalać na wstawianie punktów kontrolnych umożliwiających weryfikację

czy został osiągnięty oczekiwany efekt. Oprogramowanie musi umożliwiać pobieranie danych do skryptów testowych Oprogramowanie musi umożliwiać generowanie raportów. Oprogramowanie musi umożliwiać monitorowanie czasu przetwarzania żądań. Oprogramowanie ma zapewniać wykonywanie testów wydajnościowych, obciążeniowych,

przeciążeniowych, akceptacyjnych, regresyjnych, integracyjnych. Weryfikowane aplikacje będą wykonywane w co najmniej następujących technologiach: WEB, SAP, JAVA, JavaScript, PHP, WebService.

Oprogramowanie musi umożliwiać stosowane wirtualnych testerów. Oprogramowanie musi umożliwiać integrację z systemami monitorowania infrastruktury. Oprogramowanie musi umożliwiać tworzenie testów bez konieczności pisania kodu i umiejętności

programowania. Oprogramowanie musi umożliwiać automatyzację testów z wykorzystaniem wariantów danych i

możliwość wstawiania własnego kodu Java w celu elastycznej adaptacji testów do zmian w aplikacji.

Oprogramowanie musi umożliwiać automatyczną identyfikację i obsługę dynamicznych odpowiedzi serwera.

Oprogramowanie musi umożliwiać pobieranie szczegółowych informacji na temat aplikacji działających na serwerze aplikacyjnym opisanym w punkcie 2.3.3.3.

Oprogramowanie musi umożliwiać tworzenie raportów pozwalających na prezentację danych dotyczących wydajności.

Zarządzanie testami integracyjnymi: Możliwość instalacji i uruchomienia oprogramowania dla minimum 5 użytkowników, Oprogramowanie musi zapewnić automatyczne mechanizmy przeprowadzenia testów

funkcjonalnych, regresyjnych, wydajnościowych na poziomie integracji poprzez porównywanie struktur i zawartości komunikatów z wartościami oczekiwanymi opisanymi na stałe, poprzez wyrażenia regularne, w zewnętrznych plików tekstowych lub bazach danych, dynamicznie tworzonymi za pomocą skryptów.

Oprogramowanie musi pozwalać na nagrywanie ruchu sieciowego i tworzenie z nich przypadków testowych dla co najmniej wymienionych protokołów: Protokoły komunikacyjne, ActiveMQ, BEA Tuxedo, Email (SMTP, IMAP), Files, HTTP/S, JMS (JBOSS), IBM WebSphere MQ, JBoss MQ, SAP IDoc, BAPI, RFC & XI/PI, Software AG’s IB & IS, Solace, Sonic MQ, TCP, TIBCO Rendezvous, Smart Sockets & EMS,

Oprogramowanie musi umożliwiać pobieranie dynamicznych danych do skryptów testowych z co najmniej baz danych, LDAP, plików XLS i plików CSV

Oprogramowanie musi umożliwiać tworzenie szczegółowych raportów oraz wykresów Oprogramowanie musi umożliwiać badanie czasu przetwarzania żądań przez co najmniej

następujące komponenty testowanej infrastruktury: serwer aplikacyjny, serwer bazy danych Oprogramowanie musi pozwalać zmianę obciążenia w sensie zmiany liczby transakcji

realizowanych w jednostce czasu podczas przeprowadzania testów integracyjnych Oprogramowanie musi umożliwiać integrację z systemami monitorowania infrastruktury w celu

uzyskania dodatkowych informacji dotyczących wydajnościowych testowanego środowiska Oprogramowanie musi umożliwiać tworzenie testów bez konieczności pisania kodu i umiejętności

programowania Oprogramowanie musi posiadać możliwość modelowania usług oraz zależności pomiędzy usługami

przy użyciu edytora graficznego Oprogramowanie musi posiadać możliwość migrowania przypadków testowych pomiędzy

37 / 62


środowiskami bez potrzeby ingerencji w strukturę przygotowanych przypadków testowych Oprogramowanie musi posiadać funkcjonalność informowania testera o zmianie interfejsu

testowanej usługi przed uruchomieniem przypadku testowego Oprogramowanie musi posiadać możliwość grupowania przypadków testowych w zestawy pakietów

testów oraz możliwość przekazywania danych pomiędzy nimi Oprogramowanie musi posiadać narzędzia pozwalające na obsługę graficznego zarządzania

komunikatami używanymi w przypadkach testowych dla co najmniej następujących standardów/protokołów: .Net Objects, Bytes, COBOL Copybook, ebXML, EDI, FIX, Fixed Width, HL7, IATA, Java Objects, MIME, OAG, SOAP, Software AG Broker Docs, SWIFT, TIBCO ActiveEnterprise, XML (DTD, XSD, WSDL), Autorskie (możliwość rozbudowy narzędzia)

Oprogramowanie musi posiadać możliwość tworzenia przypadków testowych na podstawie zaimportowanych sygnatur interfejsów

Oprogramowanie musi posiadać możliwość pobierania informacji na temat usług z rejestrów usług (UDDI) oraz magistral usług (ESB)

Oprogramowanie musi posiadać możliwość tworzenia ześlepek systemów, symulatorów działania, na podstawie nagranego ruchu sieciowego

Oprogramowanie musi posiadać możliwość tworzenia na podstawie nagranego ruchu sieciowego zaślepek baz danych w celu symulacji źródeł danych podczas przeprowadzania procedur testowych

Środowisko projektowania architektury i implementacji systemu informatycznego: Możliwość instalacji i uruchomienia oprogramowania dla minimum 10 użytkowników, Oprogramowanie musi zapewnić zintegrowane, interaktywne środowisko modelowania i

generowania kodu źródłowego z modeli zgodnie z dalej określonymi standardami. Oprogramowanie musi zapewniać możliwość graficznego modelowania zgodne z notacją UML 2

udostępniającego co najmniej: klasy, komunikaty, komponenty, struktury złożone, aktywności, sekwencje, stany, przypadki użycia, obiekty.

Oprogramowanie musi umożliwiać zarządzanie modelami co najmniej w zakresie: tworzenia połączeń logicznych, indeksowania, wyszukiwania wykorzystującego zapytania, weryfikacja poprawności modeli.

Oprogramowanie musi udostępniać wsparcie dla OCL (ang. Object Constraint Language) Oprogramowanie musi umożliwiać import i export plików w formacie XMI (ang. XML Metadata

Interchange) Oprogramowanie musi zapewnić możliwość śledzenia i analizę wpływu zmian wykonywanych w

projektowanych modelach. Oprogramowanie musi umożliwiać modelowanie mieszane, co najmniej w językach takich jak UML i

Java, UML i C++ Oprogramowanie musi wspierać ALF (ang Action Language for Foundational UML) Oprogramowanie musi umożliwiać połączenie oraz śledzenie wymagań zdefiniowanych w

modelach z wymaganiami obsługiwanymi przez oferowane narzędzie do zarządzania wymaganiami.

Oprogramowanie musi wspierać co najmniej następujące środowiska (ang framework): Spring, Windows Communication Foundation (Modeling Extension for Microsoft .NET), UPIA (ang. UML Profile-based Integrated Architecture modeling), DoDAF 1.x, DoDAF 2, wspracie dla DoDAF 2 PES dla wymiany danych

Oprogramowanie musi wspomagać co najmniej modelowanie dla SOA: SoaML, BPMN 2.0 Oprogramowanie musi umożliwiać automatyczne transformację co najmniej w następującym

zakresie: UML Activity do CSG (ang. Candidate Service SoaML Generation), UML do BPEL, UML do SCDL, UML do WSDL, WSDL do UML, UML do XSD, XSD do UML, Java (POJO) do Service Model, Session Bean do Service Model, UML do Open SCA, BPMN do BPEL

Oprogramowanie musi zapewniać co najmniej następujące wzorce do tworzenie oprogramowania oraz transformacji: UML do logicznego modelu danych (ang. Logical Data Model), UML do CORBA IDL, JAVA do UML, UML do Java, UML do JPA, JPA do UML, UML do EJB 3.x, EJB 3.x do UML, UML do C#, C# do UML, UML do WCF, WCF do UML, UML do Visual Basic .NET, Visual Basic .NET do UML

38 / 62


Oprogramowanie musi zapewniać wsparcie dla modelowania kodu źródłowego wytwarzanego w co najmniej następujących językach programowania: EJB 3.0 (UML notacja dla EJB), Java (UML modelowanie dla klas i interfejsów Java), JPA, DDL, C++

Oprogramowanie musi zapewniać mechanizmy do analizy statystycznej kodu źródłowego co najmniej dla języka programowania Java w co najmniej następującym zakresie: automatyczne rozpoznawanie wzorca, automatyczne rozpoznawanie niezgodności ze wzorcem, automatyczne rozpoznawanie architektury, analiza, tworzenie metryk, weryfikacja poziomu zgodności ze zdefiniowanymi zasadami architektonicznymi.

Oprogramowanie musi wspomagać proces planowania i wdrożenia w co najmniej następującym zakresie: tworzenia topologii logicznej i fizycznej, tworzenie szczegółowej topologii infrastruktury, tworzenie szablonów dla topologii w celu ich ponownego wykorzystania, tworzenie szczegółowego planu topologii implementacji,

Oprogramowanie musi wspomagać proces wdrożenia dla co najmniej serwerów aplikacyjnych i baz danych opisanych wymaganiami w punktach 2.3.3.1 i 2.3.3.3.

Oprogramowanie musi wspomagać projektowanie i wytwarzanie oprogramowania w języku Java EE, wsparcie dla co najmniej następujących wersji:

Java EE 1.2, 1.3, 1.4, wsparcie dla Java EE 5, Java EE 6, Servlet 2.3, 2.4, 2.5 i 3.0. JSP 2.1 EJB w wersji 1.1, 2.0, 2.1, 3.0, 3.1 JAXP 1.5 (Java 2 SE 6), JAX-RPC 1.1, JAXB 2.0, JAXB/JAX-WS 2.1, 2.2, JAX-RS 1.0, 1.1 SOAP 1.1, 1.2 JNDI 1.2.1 JMS (ang. Java Message Service) EJB Query Language JDBC 3.0 Pakietów JAR, EAR

Oprogramowanie musi wspomagać projektowanie i wytwarzanie oprogramowanie Web w co najmniej następującym zakresie:

Graficzne narzędzie do projektowania i edycji kodu źródłowego wytworzonego w co najmniej następujących językach programowanie: JSF, JSP, HTML

Zintegrowane graficzne narzędzie do projektowania stron Web, wspomagające technologie jak co najmniej Flash, Dojo, Facelets ( JSF 2.0)

Konwersja typów widżetów KreatorJSP, Servlet, JSF (ang. Java Server Faces) Integracja z blbliotekami JSF innych dostawców Wsparcie dla Struts w wersji 1.0, 1.1, 1.2, 1.3 Wsparcie dla SDO (ang. Service Data Object) Wsparcie dla HTML, DHTML, XHTML, CHTML, JavaScript, CSS

Oprogramowanie musi wspomagać projektowanie i wytwarzanie oprogramowanie Web 2.0 w co najmniej następującym zakresie:

Edycja i walidacja skryptów Java script Edycja i walidacja kodu źródłowego Dojo Wsparcie dla wersj Dojo 1.4, 1.7, 1.9 Kreator adapterów RPC do udostępniania metod EJB I POJO jako usług REST Tworzenie widżetów, klas DOJO Edycja JSON

Oprogramowanie musi wspomagać analizę kodu źródłowego Java, w co najmniej następującym zakresie: analiza Java EE oraz Java 2 SE względem najlepszych, zdefiniowanych praktyk, analiza Java 2 pod kątem bezpieczeństwa, wydajności.

Oprogramowanie musi wspomagać dynamiczną analizę (runtime) kodu Java w co najmniej następujących zakresach: diagram sekwencyjny, zaawansowana analiza wykorzystania pamięci, identyfikacja wycieków pamięci (ang. memory leak detection), wizualizacja interakcji poszczególnych wątków, gromadzenia danych z wielu środowisk wykonawczych, raportowanie i tworzenie metryk.

Oprogramowanie musi wspomagać tworzenie dokumentów w formacie XML w co najmniej

39 / 62


następującym zakresie: edycja, weryfikacja, edycja i weryfikacja schematu, generowanie dokumentacji, konwersja XML do XSD, DTD do XSD, XSD do DTD, edycja i weryfikacja DTD, edycja i weryfikacja XSLT.

Oprogramowanie musi wspomagać projektowanie co najmniej baz danych opisanych wymaganiami w punkcie 2.3.3.1

Oprogramowanie musi wspomagać projektowanie baz danych w co najmniej następującym zakresie:

Podgląd i tworzenie schematu baz danych Graficzne projektowanie zapytań SQL Tworzenie i testowanie plików DAD (ang. Document Access Definition) Projektowanie procedur składowanych Wsparcie dla SQLJ

Oprogramowanie musi wspomagać projektowanie i rozwój Web Services w co najmniej następującym zakresie:

Generowanie WS na podstawie modeli WSDL/WSIL, Java Beans, Rozpoznanie WS na podstawie plików JSF Edycja plików WSDL Tworzenie, detekcja i weryfikacja WS Integracja z UDDI

2.3.3.8 Zintegrowana platforma analityczna

Oprogramowanie musi posiadać następujące cechy: Możliwość instalacji i uruchomienia oprogramowania dla minimum 3 użytkowników na co najmniej 1

rdzeniu procesora serwera chmury akademickiej, Oprogramowanie musi zapewniać zintegrowane środowisko służące do przeprowadzania analiz

statystycznych, ekonometrycznych oraz procesów eksploracji danych (data mining). Narzędzie musi zapewniać graficzne interaktywne środowisko użytkownika do projektowania i

uruchamiania procesów analitycznych Oprogramowanie musi posiadać zbiór predefiniowanych gotowych procedur analitycznych

znajdujących zastosowanie na każdym etapie budowy modelu predykcyjnego zgodnie z metodologią CRISP-DM.

Oprogramowanie musi umożliwiać użytkownikowi skorzystanie zarówno z domyślnych ustawień dla wybranej procedury, jak i samodzielnie je modyfikować.

Oprogramowanie musi zapewniać realizację procesów analitycznych w trybie wsadowym, bez udziału użytkownika i bez włączonego graficznego interfejsu użytkownika.

Oprogramowanie musi posiadać interfejs użytkownika umożliwiający graficzne budowanie analiz predykcyjnych z wykorzystaniem predefiniowanych węzłów reprezentujących operacje wykonywane na danych.

Oprogramowanie musi umożliwiać odwzorowanie przepływów danych pomiędzy węzłami za pomocą definicji odpowiednich połączeń

Oprogramowanie musi zapewniać zbiór predefiniowanych procedur umożliwiający przygotowanie danych do analizy zarówno na poziomie:

rekordów: Selekcja, Losowanie, Sortowanie, Zrównoważenie, Powtórzenia, Agregacja, Łączenie, Dołączanie

zmiennych: Auto przygotowanie, Typy, Filtrowanie, Wypełnianie, Wyliczanie, Zespół, Rekodowanie, Kategoryzacja, Analiza RFM, Partycja, Flagowanie, Restrukturyzacja, Reorganizacja;

Oprogramowanie musi umożliwiać budowanie wykresów mających na celu ułatwienie interpretacji wyników przeprowadzanej analizy

Oprogramowanie musi zapewnić zbiór możliwych do wykorzystania w procesach analitycznych co najmniej następujących algorytmów:

Modele Liniowe, Drzewa C&RT, Drzewa CHAID, Drzewa Quest, Sztuczne Sieci Neuronowe;

Scoring Modelu: Drzewa C&RT, Drzewa CHAID, Drzewa Quest, Drzewa C 5.0, Modele

40 / 62


Liniowe, Sztuczne Sieci Neuronowe, Regresja Logistyczna, Modele Mieszane, Modele Uogólnione, Regresja Coxa, Maszyna wektorów nośnych (ang. Support Vector Machine), Sieci Bayesa, Grupowanie Dwustopniowe, Metoda K-najbliższych Sąsiadów, Analiza Dyskryminacji, Lista Decyzyjna, Analiza Anomalii, Analiza Asocjacji algorytmem Carma, Analiza Asocjacji algorytmem Apriori, Metoda K-średnich, Sieci Kohonena;

Oprogramowanie musi umożliwiać wykonanie operacji analitycznych bezpośrednio w źródłowej bazie danych.

Oprogramowanie musi umożliwiać wywoływanie procedur analitycznych z poziomu GUI, łączenia ich w diagram procesu przepływu danych, a także eksportu i edycji wygenerowanego przez nie kodu w edytorze skryptów.

Oprogramowanie musi zapewniać środowisko pozwalające na bezpośrednie przesyłanie danych między poszczególnymi narzędziami

Oprogramowanie musi zapewniać centralne repozytorium do przechowywania projektowanych procesów analitycznych,

Oprogramowanie musi umożliwiać automatyzację procesu uruchamiania, weryfikacji, monitorowania skuteczności procesów analitycznych oraz przekazywania ich wyników do systemów zewnętrznych.

Oprogramowanie musi zapewniać możliwość wykorzystania danych źródłowych pochodzących z co najmniej: systemów bazodanowych, plików w formacie csv, xls.

Oprogramowanie musi umożliwiać import danych z zewnętrznych źródeł oraz ich łączenie bez konieczności przygotowania struktur pośrednich.

Oprogramowanie musi zapewniać dedykowane środowisko dla projektantów procesów analitycznych.

Oprogramowanie musi zapewniać dedykowane środowisko uruchomieniowe procesów analitycznych.

Oprogramowanie musi zapewniać Interfejs użytkownika w języku polskim.

2.3.3.9 Środowisko do rozwiązywania problemów optymalizacji

Środowisko do rozwiązywania problemów optymalizacji musi posiadać następujące cechy: Możliwość instalacji i uruchomienia oprogramowania dla minimum 3 użytkowników na co najmniej 1

rdzeniu procesora serwera chmury akademickiej, Oprogramowanie musi umożliwiać modelowanie problemów matematycznych przy użyciu technik

programowania liniowego, mieszanego programowania całkowitoliczbowego, programowania kwadratowego i programowania kwadratowego z ograniczeniami

Oprogramowanie musi zapewniać metody oraz narzędzia do tworzenia i optymalizacji algorytmów planowania i układania harmonogramów.

Oprogramowanie zmusi zapewniać dedykowane narzędzia wspomagające tworzenie modeli. Oprogramowanie zmusi zapewniać dedykowane środowisko uruchomieniowe dla zbudowanych

modeli matematycznych. Oprogramowanie musi umożliwiać zarządzanie zdefiniowanymi ograniczeniami wykorzystywanymi

do opisu problemów do rozwiązania oraz automatycznie wskazywać potencjalne obszary zmian ograniczeń w celu uzyskania optymalnych rozwiązań

Oprogramowanie musi zapewniać możliwość przeprowadzenia analizy „co-jeśli”, oraz zarządzanie scenariuszami.

Oprogramowanie musi zapewniać narzędzia do przeprowadzenia porównania scenariuszy, pod kątem sposobu osiągnięcia wyznaczonych celów (ang. goals), kluczowych współczynników jakościowych (KPI), w celu wyboru optymalnego rozwiązania problemu spomiędzy zbioru alternatywnych scenariuszy

Oprogramowanie musi zapewniać możliwość przeprowadzenia analizy danych z wykorzystaniem analizy zstępującej,

Oprogramowanie musi zapewnić narzędzia do szczegółowej wizualizacji danych oraz scenariuszy. Oprogramowanie musi zapewniać zintegrowane środowisko do definiowania problemów

optymalizacyjnych, w szczególności: Tworzenie modeli optymalizacyjnych

41 / 62


Definiowanie wymagań (ang. requirements), zasad (ang. rules) i celów (ang. goals) Uruchamiana modeli w zintegrowanym środowisku Tworzenie, debugowanie i strojenie modelu Tworzenie widoków do prezentacji danych oraz scenariuszy w postaci wykresów Zarządzanie danymi wykorzystywanymi przez modele matematyczne Konfigurowania parametrów środowiska uruchomieniowego, co najmniej w zakresie metod

zasilania danymi, konfiguracji repozytorium oraz pracy grupowej, konfiguracji środowiska serwera uruchomieniowego, instalacji aplikacji w środowisku uruchomieniowym

Zapewnić możliwość tworzenia dedykowanych rozszerzeń za pomocą aplikacji tworzonych, co najmniej z wykorzystaniem języka Java, w zakresie tworzenia dedykowanych widoków, zadań, dedykowanych metod eksportu i importu danych

Oprogramowanie musi zapewniać mechanizmy zarządzania cyklem tworzenia aplikacji / modeli, co najmniej w następujących obszarach:

Definiowanie wymagań oraz zakresu analizy Tworzenie modeli danych Tworzenie interfejsów użytkowników Integracja danych Tworzenie algorytmów optymalizacji Tworzenie prototypów, weryfikacja efektów działania Implementacja aplikacji / metod w środowisku uruchomieniowym

Oprogramowanie musi zapewniać platformę do współpracy zespołów planistów nad wspólnymi scenariuszami rozwiązań dla zdefiniowanych problemów

Oprogramowanie musi posiadać centralne repozytorium do składowania tworzonych modeli, scenariuszy i raportów

Oprogramowanie musi zapewniać możliwość wymiany danych z co najmniej programami: MS Word, MS Excel.

Oprogramowanie musi umożliwiać definiowanie przepływów pracy pomiędzy członkami zespołu oraz zapewniać podział odpowiedzialności i uprawnień za pomocą ról

Oprogramowanie musi posiadać udokumentowanie API, co najmniej w formacie Rest API Oprogramowanie musi wykorzystywać serwer aplikacyjny oraz serwer bazy danych opisane w

punktach 2.3.3.1 i 2.3.3.3.

2.3.3.10 Oprogramowanie do konfiguracji procesu projektowania system informatycznego

Oprogramowanie do konfiguracji procesu projektowania systemu informatycznego musi posiadać następujące cechy: Możliwość instalacji i uruchomienia oprogramowania dla minimum 5 użytkowników, Narzędzie pozwala na definiowanie opisu metodyk wytwarzania oprogramowania przy użyciu

notacji SPEM 2.0 (Software & Systems Process Engineering Metamodel). Narzędzie powinno posiadać wbudowane opisy metodyk co najmniej takich jak Scrum, OpenUp,

Rational Unified Process. Narzędzie powinno pozwalać na generowanie dokumentu opisującego zdefiniowaną metodykę w

formatach co najmniej Microsoft Word, HTML. Narzędzie powinno pozwalać na definiowanie ról zaangażowanych w proces wytwarzania

oprogramowania. Narzędzie powinno pozwalać na definiowanie zadań wykonywanych w procesie wytwarzania

oprogramowania. Narzędzie powinno pozwalać na definiowanie narzędzi wykorzystywanych w procesie wytwarzania

oprogramowania. Narzędzie powinno pozwolić na rozszerzanie istniejących opisów metodyk bez potrzeby ich

kopiowania czy ingerencji w ich treść. Narzędzie powinno pozwalać na przenoszenie opisów ról oraz zadań co najmniej do narzędzia

zarządzania zmianami (ang. Change and Configuration Manamagent). Narzędzie jest "otwarte": umożliwia pisanie własnych autorskich rozszerzeń.

42 / 62


2.3.3.11 Oprogramowanie do testowania zabezpieczeń aplikacji

Oprogramowanie do testowania zabezpieczeń aplikacji musi posiadać następujące cechy: Możliwość instalacji i uruchomienia oprogramowania dla minimum 5 użytkowników, Oprogramowanie musi oferować minimum następujące techniki testowania: analizę dynamiczną,

statyczną, interaktywną. Oprogramowanie musi mieć funkcjonalność przeglądania serwisów WWW w poszukiwaniu

odsyłaczy do szkodliwych lub niepożądanych stron. Oprogramowanie musi posiadać funkcjonalność agregowania i korelacji wyników analizy statycznej

i dynamicznej w celu tworzenia raportów na temat słabych punktów zabezpieczeń. Oprogramowanie musi umożliwiać definiowanie strategii i szablonów skanowania sterujących

przebiegiem testów aplikacji. Oprogramowanie musi oferować gotowe do użytku raporty na temat zgodności ze standardami i

przepisami, dla m.in. ISO 27001, ISO 27002.

43 / 62


2.4 Wirtualne desktopyRozwiązanie udostępnia wirtualne stanowiska komputerowe (desktopy) w postaci usługi. Musi umożliwiać proste zarządzanie pojedynczymi instancjami systemów operacyjnych, aplikacji i profili użytkowników. Podstawowe cechy, jakie musi posiadać rozwiązanie: Mechanizmy kompresji przesyłanych przez sieć danych pomiędzy serwerem VDI a stacją końcową

w celu minimalizacji obciążenia sieci, Pojedynczy punkt zarządzania, który pozwala na konfigurowanie komputerów lub grup

komputerów, Możliwość szybkiego tworzenia obrazów komputerów z kopii wzorcowej, Obsługa portów USB, Obsługa uwierzytelniania użytkowników.

Wymagane jest dostarczenie sprzętu i oprogramowania opisanych w niniejszym punkcie z 5 letnim okresem wsparcia technicznego świadczonego przez producenta sprzętu i oprogramowania.

Rysunek 1 Komponenty funkcjonalne biorące udział w realizacji funkcji Wirtualnych desktopów

2.4.1 Serwer kasetowy x86 dla potrzeb chmury wirtualnych desktopów


Opis wymagań

Liczba 14 sztuk

Obudowa Obudowa kasetowa umożliwiająca zainstalowanie serwerów kasetowych opisana w pkt. 2.1.1

44 / 62


Procesor Procesor wykonany w technologii x86, min. 8 rdzeni na układ procesorowy.Serwer wyposażony w min. 2 układy procesorowe pozwalające na osiągniecie wyniku min. 700 punktów w teście SPECint2006 Rates publikowanego na stronie www.spec.org

Pamięć cache Minimum 20 MB pamięci cache na procesor


Każdy serwer musi mieć wypełnione wszystkie sloty procesorami, liczba układów procesorowych nie może być mniejsza niż 2 układy.

Pamięć RAM Min. 320GB RAM.Zakłada się, iż wirtualne desktopy będą posiadały średnie obciążenie, gdzie wielkość pamięci RAM przypadająca na jeden desktop wynosi 2,5 GB, Natomiast pojedynczy serwer obsługuje do 100 desktopów.

Dyski twarde Zainstalowane min. 2 dyski typu SSD o pojemności 100GB każdy

Interfejsy FC Min. 32 Gb/s przepustowości do podsystemu dyskowego realizowanego przez min. 2 porty pracujące w standardzie FC.

Interfejsy sieciowe Min. 2 interfejsy sieciowe 10Gb Ethernet o następujących cechach:- Wsparcie dla wielu interfejsów wirtualnych (vNIC)- Możliwość włączenia funkcjonalności iSCSI oraz FCoE za pomocą klucza licencyjnego bez konieczności wymiany elementów.



Zarządzanie Serwer musi zawierać zintegrowany moduł zarządzania (procesor serwisowy), który łączy się z modułem zarządzania w obudowie. Połączenie takie zapewnia funkcje kontroli, monitorowania, oraz funkcje ostrzegania przed awarią. Jeżeli któryś z komponentów serwera ulegnie awarii, diody na płycie głównej zostaną włączone w celu zdiagnozowania problemu. Błąd jest rejestrowany w dzienniku zdarzeń, a administrator powiadamiany o problemie. Możliwość zdalnego dostępu do serwera poprzez protokoły: Intelligent Platform Management Interface (IPMI) Version 2.0, Simple Network Management Protocol (SNMP) Version 3, Common Information Model (CIM). Możliwość mapowania napędu CD/DVD/FDD/USB i obrazów ISO.

System operacyjny Wymagane jest dostarczenie z serwerem licencji na system operacyjny.

2.4.2 Oprogramowanie do zarządzania wirtualnymi desktopamiOprogramowanie musi umożliwiać świadczenie usługi dostępu zdalnego do

wirtualnych stacji roboczych (VDI). Oprogramowanie musi pozwolić na jednoczesne uruchomienie min. 500 wirtualnych stacji roboczych.

Oprogramowanie musi być zainstalowane jako maszyny wirtualne na wydzielonych serwerach (opisanych w punkcie 2.4.1). Oprogramowanie musi być skonfigurowany w sposób redundantny, aby w przypadku awarii serwera sprzętowego istniała możliwość świadczenia usługi przez serwer redundantny.

Zarządzanie wirtualnymi stacjami roboczymi i aplikacjami, ich przypisywanie do użytkowników i konfigurowanie dostępne musi być z poziomu wydzielonej konsoli graficznej, dostępnej przez przeglądarkę WWW.

45 / 62


W zależności od wymagań konkretnego laboratorium dla studentów, stacje robocze muszą być dostępne w różnych modelach pracy: dedykowana stacja wirtualna z zainstalowanymi aplikacjami i danymi oraz uniwersalna stacja wirtualna, do której przypisuje się portfolio aplikacji.

Oprogramowanie musi umożliwiać wirtualizację aplikacji i przypisywanie ich do konkretnych użytkowników lub stacji roboczych. Mechanizm wirtualizacji aplikacji musi zapewniać wersjonowanie aplikacji.

Licencje dla wyżej określonego oprogramowania muszą być licencjami na czas nieokreślony z możliwością uaktualnienia do najnowszej wersji w okresie 5 lat.

W ramach oprogramowania do wirtualizacji stacji roboczych konieczne będzie dostarczenie dla dwóch serwerów dwuprocesorowych licencji na serwerowy system operacyjny, umożliwiający uruchamianie na tym samym serwerze fizycznym dowolnej liczby instancji maszyn wirtualnych z tym samym systemem operacyjnym, wspierającym natywnie użycie usługi katalogowej zgodnej z dostarczonym systemem do wirtualizacji stacji roboczych. System operacyjny powinien być wspierany przez okres minimum 5 lat.

W ramach dostarczenia oprogramowania do wirtualizacji stacji roboczych wymagane będzie dostarczenie najnowszych dostępnych wersji licencji klienckiego systemu operacyjnego, w pełni wspieranego przez producenta oprogramowania do wirtualizacji stacji roboczych, pozwalających na uruchamianie jednoczesne minimum 500 wirtualnych stacji oraz dostęp do nich z urządzeń końcowych przez okres minimum 5 lat.

2.5 High Performance ComputingWymagane jest dostarczenie sprzętu i oprogramowania opisanych w niniejszym punkcie z 5 letnim okresem wsparcia technicznego świadczonego przez producenta sprzętu i oprogramowania.

46 / 62


Rysunek 2 Komponenty funkcjonalne biorące udział w realizacji funkcji Chmury HPC

2.5.1 Serwer kasetowy – Węzeł obliczeniowy x86 + GPU


Opis wymagań

Liczba 5 sztuk

Obudowa Kasetowa umożliwiająca zainstalowanie w obudowie opisanej w pkt. 3.1.1

Procesor Procesor wykonany w technologii x86, min. 8 rdzeni na układ procesorowy.Serwer wyposażony w min. 2 układy procesorowe pozwalające na osiągniecie wyniku min. 700 pkt w teście SPECint2006 Rates publikowanego na stronie www.spec.org

Pamięć cache Minimum 20 MB pamięci cache na układ procesorowy


Zainstalowane min. 2 układy procesorowe, wszystkie sloty procesorowe dostępne w serwerze musza być obsadzone układami procesorowymi

47 / 62


Pamięć RAM Min. 320GB RAM. Możliwość rozbudowy do minimum 1TB RAM.

Dyski twarde Zainstalowany min. 2 dyski typu SSD o pojemności minimum 100GB każdy. Kontroler RAID na płycie głównej z możliwością konfiguracji RAID 1, 0

Interfejsy sieciowe Min. 2 interfejsy sieciowe 10Gb Ethernet o następujących cechach:a) Wsparcie dla wielu interfejsów wirtualnych (vNIC)b) Możliwość włączenia funkcjonalności iSCSI oraz FCoE za pomocą klucza

licencyjnego bez konieczności wymiany elementów.

Akcelerator GPU Zainstalowany w serwerze minimum 1 akcelerator GPU, zgodny z architekturą CUDA, o wydajności minimalnej 1,1 TFLOPS dla obliczeń zmiennoprzecinkowych podwójnej precyzji



Zarządzanie Serwer zawiera zintegrowany moduł zarządzania (procesor serwisowy), który łączy się z modułem zarządzania w obudowie. Połączenie takie zapewnia funkcje kontroli, monitorowania, oraz funkcje ostrzegania przed awarią. Jeżeli któryś z komponentów serwera ulegnie awarii, diody na płycie głównej zostaną włączone w celu zdiagnozowania problemu. Błąd jest rejestrowany w dzienniku zdarzeń, a administrator powiadamiany o problemie. Możliwość zdalnego dostępu do serwera poprzez protokoły: Intelligent Platform Management Interface (IPMI) Version 2.0, Simple Network Management Protocol (SNMP) Version 3, Common Information Model (CIM). Możliwość mapowania napędu CD/DVD/FDD/USB i obrazów ISO.

System operacyjnyWymagane dostarczenie z serwerem licencja na system operacyjny typu Linux dla HPC

2.5.2 Węzeł zarządzający / Serwer plików

Nazwa elementu,parametru lub cechy

Opis wymagań

Liczba 2 sztuki

ObudowaO wysokości maksymalnie 2U, dedykowana do zamontowania w szafie RACK 19" z zestawem szyn do mocowania w szafie i wysuwania do celów serwisowych.

Płyta głównaPłyta główna dedykowana do pracy w serwerach, wyprodukowana przez producenta serwera z możliwością zainstalowania dwóch procesorów.

WydajnośćZainstalowane dwa procesory osiągające w teście SPEC CPU2006 (dostępnym na stronie www.spec.org) wynik nie mniejszy niż 410 dla testu "SPECint_rate_base2006" dla oferowanego serwera

RAMMinimum 128 GB 1866MHz, z technologią ECC, możliwość rozszerzenia pamięci do minimum 768 GB.

Gniazda PCIMinimum 3 slotów PCIe 3.0, wymagana możliwość zainstalowania dodatkowych 3 slotów PCIe 3.0, wymagana możliwość konwersji minimum jednego slotu do slotu PCI-X

Interfejsy sieciowe

Wbudowane na płycie głównej 4 porty typu 1Gb Ethernet. Karty sieciowe muszą wspierać load balancing, failover i TCP/IP Offload Engine.Zainstalowana w dedykowanym slocie karta typu 10Gb Ethernet, wyposażona w 2 moduły optyczne typu SFP+ SR

48 / 62


Interfejsy FC Zainstalowane minimum 2 karty HBA typu FC8

Napęd optyczny Zainstalowany wewnętrzny napęd typu DVD+/-RW

Kontroler

Kontroler macierzowy SAS/SATA z 512MB pamięci cache, z podtrzymaniem bateryjnym, umożliwiający konfigurację dysków w RAID 0/1/10/5/50. Kontroler musi umożliwiać rozbudowę do minimum 2GB pamięci cache oraz obsługę RAID 6.

Dyski twarde Zainstalowane 2 dyski typu SSD o pojemności 100GB każdy

Zasilacze Redundantne. Hot-Plug o mocy maksymalnie 900W każdy

Zarządzanie

Proaktywne monitorowanie krytycznych komponentów serwera takich jak: Procesory, Dyski, Pamięć operacyjna, zasilacze, wentylatory, regulator napięcia i przesyłanie do systemu zarządzającego alertów przed wystąpieniem awariiWbudowany na froncie obudowy panel diagnostyczny umożliwiający łatwą identyfikację uszkodzonego elementu. Serwer zawiera zintegrowany moduł zarządzania, umożliwiający funkcje kontroli, monitorowania, oraz funkcje ostrzegania przed awarią. Jeżeli któryś z komponentów serwera ulegnie awarii, diody na płycie głównej zostaną włączone w celu zdiagnozowania problemu. Błąd jest rejestrowany w dzienniku zdarzeń, a administrator powiadamiany o problemie. Możliwość zdalnego dostępu do serwera poprzez protokoły: Intelligent Platform Management Interface (IPMI) Version 2.0, Simple Network Management Protocol (SNMP) Version 3, Common Information Model (CIM). Możliwość mapowania napędu CD/DVD/FDD/USB i obrazów ISO.

Dokumentacja użytkownika

Zamawiający wymaga dokumentacji w języku polskim lub angielskim.

System operacyjnyWymagane dostarczenie z serwerem licencja na system Red Hat Enterprise Linux for HPC Head Node.

2.5.3 Oprogramowanie zarządzające klastra HPCZamawiający wymaga dostarczenia licencji oprogramowania zarządzającego dla wszystkich oferowanych serwerów x86 przeznaczonych dla środowiska HPC

Wymagania funkcjonalne, jakie musi spełniać oprogramowanie zarządzające dla chmury HPC: Klaster HPC – rozwiązanie łączące sprzęt i oprogramowanie, przeznaczone do wykonywania

obliczeń, Oprogramowanie Zarządzające – funkcjonalna część klastra HPC opisana poniżej, Resource Scheduler – część Oprogramowania Zarządzającego dedykowana do monitorowania i

kolejkowania zadań wykorzystujących zasoby programowe oraz sprzętowe Klastra HPC, Aplikacje – oprogramowanie wykonujące zadania obliczeniowe zlecane przez użytkowników (np.

Aplikacje CAD/CAE), Aplikacje nie wchodzą w skład Oprogramowania Zarządzającego, Zamawiający nie wymaga dostarczenia Aplikacji w ramach oferowanego rozwiązania

Wymagania dotyczące Oprogramowania Zarządzającego, dostarczanego wraz z oferowanym rozwiązaniem, bez konieczności zakupu dodatkowych licencji: Wysokopoziomowe monitorowanie zasobów, Instalacja oprogramowania na węzłach klastra, Przydzielanie zasobów, Implementacja MPI, Integracja z Aplikacjami firm trzecich,

49 / 62


2.5.3.1 Wymagania dotyczące dostępu do Oprogramowania Zarządzającego

Pojedynczy, jednolity dostęp poprzez przeglądarkę. Ten sam portal powinien być wykorzystywany przez użytkowników końcowych oraz do zadań administracyjnych (używając uprawnień administratora). Portal powinien zapewniać zarządzanie, monitorowanie oraz wizualizację przynajmniej:

zadań użytkowników (także wstrzymywanie i wznawianie zadań), zajętości zasobów, niskopoziomowych metryk sprzętowych, wprowadzania zadań i otrzymywania wyników zadań użytkowników końcowych, Portal musi zapewniać możliwość do wprowadzania zadań przynajmniej z następujących

Aplikacji: NWCHEM, NASTRAN, MATLAB, LS-DYNA, HMMER, FLUENT, Schlumberger ECLISPE, CMGL_STARS, ClustalW, CFX, BLAST, ANSYS, ABAQUS, VASP, MEDEA, MATERIALS STUDIO.

Oprogramowanie Zarządzające musi zapewniać możliwość generowania ogólnych oraz szczegółowych raportów z wykorzystania zasobów i wykonywanych zadań.

2.5.3.2 Wymagania dotyczące Resource Scheduler’a

Resource Scheduler musi wspierać architekturę klastrową oraz gridową Standardowo po instalacji powinna być zapewniona przynajmniej jedna implementacja MPI Scheduler lub wbudowana implementacja MPI musi posiadać wsparcie dla restartu oraz

wykonywania punktów kontrolnych zadań Resource Scheduler musi wspierać kilka poziomów delegacji praw administracyjnych Resource Scheduler musi wspierać wysoką dostępność o poziomie N+1 Resource Scheduler rmusi posiadać wbudowaną możliwość rozpoznawania odmiennych

konfiguracji sprzętowych poszczególnych węzłów i przydzielania zadań w sposób maksymalnie efektywny

2.5.3.3 Wymagania funkcjonalne dla Oprogramowania Zarządzającego

Oprogramowanie Zarządzające musi zapewniać instalację systemów operacyjnych, Aplikacji oraz oprogramowania systemowego zgodnie z zadaniami przydzielanymi do Resource Scheduler’a

Oprogramowanie Zarządzające musi wspierać następujące techniki instalacji oprogramowania na węzłach obliczeniowych:

Wykorzystanie standardowych narzędzi systemu Linux (minimum: YaST, yum) Część serwerowa Oprogramowania Zarządzającego musi wspierać architekturę HA w trybie

active/passive Resource Scheduler musi posiadać wbudowane wsparcie dla urządzeń GPU i GPGPU. W

szczególności musi monitować i przydzielać zadania dla zasobów GPU i GPGPU jak dla pozostałych zasobów, wraz z pamięcią operacyjną, procesorami i zasobami dyskowymi.

Resource Scheduler musi standardowo zapewniać kolejkowanie: zadań bazujących na procesach zadań bazujących na wątkach zadań mieszanych wykorzystujących procesy i wątki zadań mieszanych dla zasobów x86+GP(GPU)

Oprogramowanie Zarządzające musi posiadać możliwość instalacji oraz wsparcie dla następujących dystrybucji systemów operacyjnych:

RHEL (najnowsza stabilna dystrybucja), SLES (najnowsza stabilna dystrybucja), Scientific Linux (najnowsza stabilna dystrybucja), CentOS (najnowsza stabilna dystrybucja), Windows HPC Server 2008 R2.

Oprogramowanie Zarządzające musi wspierać następujące implementacje MPI: MPICH, MVAPICH, OpenMPI, Intel MPI.

50 / 62


2.5.4 Oprogramowanie systemu plikówZamawiający wymaga dostarczenia licencji oprogramowania systemu plików dla wszystkich oferowanych serwerów x86 (licencje typu serwer należy przewidzieć dla węzłów zarządzających/serwerach plików). Wymagania dotyczące oprogramowania systemu plików: Oprogramowanie realizujące wydajny, skalowalny i zdolny do pracy w reżimie wysokiej dostępności

(High Availability - HA) równoległy system plików. Oprogramowanie musi składać się z części serwerowej, serwującej równoległe systemy plików z

danymi udostępnianymi z pamięci masowej, oraz części klienckiej umożliwiającej użycie tych zasobów na węzłach obliczeniowych i zarządzających klastra.

Zainstalowane na każdym serwerze plików dostarczonym przez oferenta, musi: zapewniać pojedynczemu serwerowi plików dostęp do wszystkich fizycznych

udostępnionych nośników danych pamięci masowej, zapewniać, w sposób przeźroczysty dla użytkownika, możliwość podziału tego samego

pliku na fragmenty i ich równoczesnego zapisu na dowolną liczbę urządzeń blokowych zdefiniowanych i zarządzanych przez wszystkie serwery plików

działać w reżimie wysokiej dostępności - jeżeli jeden z serwerów plików zostanie wyłączony lub ulegnie awarii pozostały (e) serwer(y) plików

przejąć świadczenie wszystkich wymaganych usług równoległego systemu plików bez utraty dostępu do danych serwowanych przez pozostałe serwery plików oraz bez potrzeby ingerencji administratora systemu w celu zapewnienia ciągłości pracy w chwili awarii,

umożliwiać utworzenie pojedynczego systemu plików wielkości, co najmniej 4 PB, musi umożliwiać utworzenie, co najmniej 256 systemów plików,

umożliwiać jednoczesne serwowanie dowolnego równoległego systemu plików przez wszystkie dostarczone przez Wykonawcę serwery plików w ramach jednej, wspólnej przestrzeni nazw dla plików i katalogów,

umożliwiać wykonanie co najmniej 256 kopii migawkowych (snapshot) każdego z utworzonych równoległych systemów plików,

umożliwiać replikację danych – automatyczne, przeźroczyste dla użytkownika kopiowanie wszystkich danych, w ramach pojedynczego systemu plików, pomiędzy zdefiniowanymi grupami dysków,

umożliwiać ustalanie limitów dyskowych (quota), niezależnie dla każdego użytkownika oraz niezależnie dla każdej grupy użytkowników, na dowolnym równoległym systemie plików,

zapewniać wymagane licencje, w liczbie niezbędnej dla pełnego wykorzystania wymaganych funkcji serwerów równoległego systemu plików na wszystkich dostarczonych przez Wykonawcę serwerach plików.

Licencja musi umożliwiać udostępnianie plików poprzez Network File System (NFS), Common Internet File System (CIFS), File Transfer Protocol (FTP) oraz Hypertext Transfer Protocol (HTTP). System plików musi zapewniać kontrolę dostepu na podstawie Access Control List (ACL) oraz tworzenie sum kontrolnych (ECC).

Oprogramowanie klienckie musi: umożliwiać połączenie z dowolnym dostarczonym przez oferenta serwerem plików, umożliwiać użycie na wszystkich serwerach Zamawiającego równoległego systemu plików

serwowanego przez serwery plików w ramach jednej, wspólnej przestrzeni nazw dla plików i katalogów,

umożliwiać automatyczne, bez ingerencji administratora, wznawianie połączenia do serwera plików, jeżeli w wyniku awarii serwera plików zostanie utracone z nim połączenie,

oprogramowanie klienckie musi połączyć się w sposób automatyczny, bez ingerencji administratora, z innym serwerem plików oferującym ten sam równoległy system plików gwarantując dostęp do tych samych danych i zapewniając ciągłość pracy w chwili awarii,

być w pełni wspierane pod systemem Linux : dystrybucje RHEL 6.x , RHEL 5.x, SLES 11, SLES 10

51 / 62


Debian 6.0.3 komunikacja do i z serwerów plików musi odbywać się przy użyciu protokołu TCP/IP i Infiniband

RDMA, umożliwiać zapis i odczyt danych, w ramach równoległego systemu plików, w przypadku utraty

bezpośredniego połączenia z urządzeniami blokowymi z pamięci masowej oprogramowanie klienckie musi w sposób automatyczny przekierować zapis i odczyt danych na

równoległy system plików do dostępnych w sieci serwerów plików zapewniając ciągłość pracy w chwili awarii,

zapewniać licencje, w liczbie niezbędnej dla pełnego wykorzystania funkcji klientów równoległego systemu plików na dostarczanych węzłach klastra obliczeniowego.

52 / 62


3 Wymagania na systemy infrastruktury wyposażenia serwerowni

3.1 Podłoga techniczna oraz system zasilania gwarantowanegoW pomieszczeniu technicznym przeznaczonym na serwerownię należy dostarczyć oraz zainstalować system zasilania gwarantowanego przeznaczony do zasilania dostarczonego sprzętu serwerowego oraz teletechnicznego. W ramach dostawy oraz wdrożenia systemu zasilania gwarantowanego należy zaprojektować oraz zainstalować niezbędną rozdzielnię elektryczną wraz z wyposażeniem, zgodnie z obowiązującymi przepisami prawa oraz normami. Wybudowaną rozdzielnię elektryczną należy zasilić obwodem WLZ z rozdzielni głównej budynku. Przydział mocy na budynek, w której znajdować się ma serwerownia jest wystarczający. Przed przystąpieniem do prac należy wykonać oraz przedłożyć zamawiającemu do akceptacji projekt wykonawczy instalacji elektrycznej wewnątrz pomieszczenia serwerowni.Dodatkowo w pomieszczeniu należy zainstalować podłogę techniczną o wysokości od 15cm do 20cm zgodnie z obowiązującymi przepisami PPOŻ.W serwerowni musi zostać zainstalowanych minimum 3 szt. szaf RACK 19” (plus 1 szt. Szafy RACK 19’’ już zainstalowana). W serwerowni muszą zostać zainstalowane urządzenia klimatyzujące o łącznej mocy, co najmniej 18kW. Instalację należy zaprojektować tak, aby każdej z szaf zagwarantować przydział mocy na poziomie 10kW z obwodów zasilania gwarantowanego. Dodatkowo pod obwód zasilania gwarantowanego należy podłączyć jedną jednostkę wewnętrzną systemu klimatyzacji. Dostarczone urządzenie UPS musi spełniać poniższe założenia: Oferowane urządzenie do bezprzerwowego zasilania urządzeń komputerowych zwane dalej

urządzeniem ma być fabrycznie nowe i ma pochodzić z seryjnej produkcji. Data jego wyprodukowania nie może być wcześniejsza niż 6 miesięcy przed terminem złożenia ofert.

Producent oferowanego urządzenia powinien spełniać wymagania międzynarodowego standardu jakości ISO 9001, co powinno być potwierdzone ważnym certyfikatem.

Znamionowa moc wyjściowa urządzenia, co najmniej 70kVA (współczynnik mocy 0,9). Możliwość zwiększenia mocy wyjściowej urządzenia poprzez dołożenie kolejnych modułów

bateryjnych, do co najmniej 90kVA. Pojedynczy moduł bateryjny musi pozwalać na zwiększenie mocy całego zestawy, o co najmniej

10kVA oraz zajmować maksymalnie 2U w powierzchni szafy RACK. Częstotliwość napięcia pracy: 50/60Hz Ilość faz 3/3 - trzy fazy wejściowe i trzy fazy wyjściowe Napięcie wejściowe – wyjściowe 3x400 V zgodne z wartościami zapisanymi w Polskiej Normie PN-

IEC 60038 w zakresie, co najmniej -27% do +20%. Sprawność urządzenia, co najmniej 96% Urządzenie powinno posiadać:

Wejście trójfazowe 5-cio przewodowe (TN-S) Wyjście trójfazowe 5-cio przewodowe (TN-S)

Dopuszczalne przeciążenie przez producenta: 110% - 10 minut, 125% - 1 minuta, 1000% - jeden cykl

Zakres temperaturowy pracy: co najmniej -10st. C. do +40st. C. Maksymalna ilość wytwarzanego ciepła: 1200BTU/h na 10kVA mocy urządzenia Urządzenie przeznaczone do montażu w szafie RACK, dostarczone w obudowie RACK 42U/80”.

Masa modułu podstawowego (bez modułu bateryjnego) maksymalnie 200kg. Poziom generowanego hałasu nie więcej niż 60dB w odległości 1,5m przy pełnym obciążeniu

urządzenia. Możliwość pracy w modelu redundancji N+1. Wbudowane obejście (ang. bypass). Urządzenie powinno zapewnić ciągłe bezprzerwowe zasilanie w trybie TRUE ON-LINE z podwójną

konwersją przy zupełnych lub chwilowych zanikach napięcia i wahaniach częstotliwości w sieci elektrycznej przez cały czas pracy urządzenia.

Wymagany certyfikat bezpieczeństwa: CE Urządzenie musi posiadać panel komunikacyjny, w którym powinny być zainstalowana karta

53 / 62


sieciowa 10/100 Base-T RJ-45 (Web/SNMP). Wbudowany czujnik temperatury powietrza. Wsparcie na co najmniej 60 miesięcy na elektronikę i baterie. Po zakończonej instalacji należy przeszkolić pracowników Zamawiającego w zakresie obsługi instalacji oraz urządzeń. Jednodniowe szkolenie musi być przeprowadzone dla min. 3 pracowników Zamawiającego.

3.2 Instalacja klimatyzacjiDo pomieszczenia serwerowni należy dostarczyć oraz zainstalować system klimatyzacji typu

Split o łącznej mocy chłodniczej, co najmniej 53kW (około 180.800,00BTU/h). System musi się składać, z co najmniej czterech niezależnych zestawów jednostka wewnętrzna – jednostka zewnętrzna. Jednostki zewnętrzne zostaną zainstalowane na zewnątrz budynku. Obwody zasilające system klimatyzacji należy wyprowadzić z projektowanej rozdzielni elektrycznej. Przed przystąpieniem do montażu urządzeń systemu klimatyzacji należy przygotować branżową dokumentację wykonawczą maksymalnie optymalizującą rozmieszczenie jednostek wewnętrznych oraz przedłożyć Zamawiającemu celem akceptacji. Najważniejsze minimalne parametry techniczne urządzeń systemu klimatyzacji: Minimalna moc chłodnicza pojedynczej jednostki: 13kW Maksymalny pobór prądu podczas chłodzenia: 4,5kW Zakres temperaturowy pracy, co najmniej od -15 st. C d +46 st. C Praca jednostki zewnętrznej w układnie 3-fazowym Gwarancja, co najmniej 5 lata Płynna regulacja wydajności (Inverter) Autorestart w przypadku chwilowego zaniku napięcia, Cicha praca jednostki zewnętrznej: maksymalnie 53 dB ciśnienia akustycznego Długość odcinka instalacji pomiędzy jednostką zewnętrzną a wewnętrzną, co najmniej 35mb.

Po zakończonej instalacji należy przeszkolić pracowników Zamawiającego w zakresie obsługi instalacji oraz urządzeń. Jednodniowe szkolenie musi być przeprowadzone dla min. 3 pracowników Zamawiającego.

3.3 System sygnalizacji pożaru oraz gaszenia gazowegoPomieszczenie techniczne przeznaczone na serwerownię należy wyposażyć w system

sygnalizacji pożaru oraz gaszenia gazowego gazem FM-200. Przed przystąpieniem do prac należy przygotować, zgodną z przepisami oraz normami, branżową dokumentację wykonawczą instalacji systemu ppoż. oraz gaszenia gazem wraz z rozmieszczeniem elementów oraz przedłożyć Zamawiającemu do akceptacji opatrzoną pozytywną opinią uprawnionego rzeczoznawcy do spraw ppoż. z wykazem i specyfikacją zamontowanych urządzeń (typ urządzenia, ilość). Po zakończonej instalacji należy przeszkolić pracowników Zamawiającego w zakresie obsługi instalacji i urządzeń oraz przekaże instrukcję obsługi w języku polskim. Parametry techniczne pomieszczenie objętego systemem gaszenia gazem: długość 6,93 m, szerokość 6,17 m, wysokość 3,00 m, kubatura 128,27 m3.Parametry techniczno-użytkowe.Samoczynne instalacje gaśnicze wykorzystujące, jako środek gaśniczy różnego rodzaju gazy, takie jak dwutlenek węgla, mieszaniny gazów obojętnych (np. Inergen) i gazy chemiczne (np. FM 200), służyć będą do umożliwienia automatycznego wykrycia i sygnalizacji pożaru oraz rozpoczęcia akcji gaśniczej w chronionej strefie.Skuteczność stałego urządzenia gaśniczego gazowego zależy od projektu, który należy dostosować do wymagań pomieszczenia serwerowni. Parametry dysz, rurociągów, reduktorów ciśnienia oraz pozostałych elementów powinny zostać dobrane w taki sposób, aby w przypadku wystąpienia pożaru i uruchomienia instalacji gaśniczej umożliwiły wypełnienie chronionego obszaru gazem gaśniczym o odpowiednim stężeniu w zakładanym czasie.Pomieszczenie serwerowni należy tak przystosować do systemu gaszenia gazem tak, aby stężenie gaśnicze mogło się utrzymywać odpowiednio długo.

54 / 62


Elementy składowe jednostrefowej instalacji gaśniczej: butle ze środkiem gaśniczym FM200, wyzwalacz zaworu butli pilotowej, kolektor zbiorczy i rurociągi rozprowadzające, reduktory ciśnienia, czujniki przepływu, zawory, węże przyłączeniowe i sterujące, dysze gaśnicze, centrala sterowania gaszeniem, linie dozorowe, czujki pożarowe, przyciski ręcznego uruchomienia („START”), zatrzymania lub wstrzymania gaszenia ("STOP"), sygnalizatory akustyczne i optyczne, itp.Zainstalowany systemu musi umożliwiać: szybkie powiadomienia personelu dozorującego obiekt oraz użytkowników o zaistniałym zagrożeniu

pożarowym, poprzez wywołanie akustycznego i optycznego alarmu pożarowego, identyfikacji czujek sygnalizujących alarm pożarowy, chronologicznego zapisu wydarzeń w pamięci

centralki. Centralka powinna umożliwiać rejestrację wszystkich zdarzeń zachodzących w systemie z

określeniem lokalizacji i czasu zdarzenia sterowanie innymi instalacjami w przypadku wystąpienia stanu alarmowego,

Instalacja sygnalizacji pożaru, w przypadku zaistnienia sytuacji, określonej przez parametry systemu, jako alarm pożarowy, lub poprzez świadome działanie ludzkie, spowoduje: powstanie akustycznego i optycznego alarmu na zewnątrz budynku i w miejscu instalacji centrali

sygnalizacji pożaru, przesłanie liniami sterującymi kryterium „alarm pożarowy” do instalacji.Powyższe funkcje, mają służyć bezpiecznej ewakuacji osób oraz umożliwić podjęcie akcji przeciwpożarowej we wczesnej jej fazie. Wszystkie zastosowane do budowy elementy instalacji (przewody, kable, urządzenia), powinny posiadać ważne certyfikaty zgodności dopuszczające do stosowania w ochronie przeciwpożarowej, wydawane przez Centrum Naukowo-Badawcze Ochrony Przeciwpożarowej.

W ramach realizacji zadania wykonawca zobowiązany jest do: opracowania dokumentacji technicznej, dostawy materiałów i urządzeń dostosowania pomieszczeń do wymogów parametrów technicznych montowanej instalacji, montażu i uruchomienia instalacji gaszenia gazem, wykonania po montażowych robót budowlanych, dostawy, montaż oraz programowanie centrali systemu p. poż. przeszkolenie pracowników Zamawiającego w zakresie użytkowania systemu. Jednodniowe

szkolenie musi być przeprowadzone dla min. 3 pracowników Zamawiającego.

55 / 62


4 Zakres prac wdrożeniowych uruchomienia funkcjonalnego serwerowni

Zadania Opis zadania Maksymalny czas realizacji zadania

1 Opracowanie i dostarczenie Zamawiającemu Dokumentacji rozbudowy Serwerowni, w szczególności: Plan Zarządzania Projektem (PZP) Projekt Techniczny Serwerowni;

Do 15 dni od daty podpisania umowy

2 Wykonanie prac związanych z rozbudową serwerowni zgodnie z Projektem Technicznym SerwerowniPrzeprowadzenie odbioru prac związanych z rozbudową serwerowni


3 Opracowanie i dostarczenie Zamawiającemu Dokumentacji Systemu, w szczególności: Projektu Wdrożenia Sytemu, Projektu Technicznego Systemu.


4 Dostawę urządzeń i oprogramowania standardowego, Instalację oraz uruchomienie urządzeń w serwerowni, Przeprowadzenie testów uruchomieniowych (ang. sanity test).


5 Konfigurację oraz uruchomienie urządzeń, oprogramowania standardowego oraz oprogramowania dedykowanego (jeśli dotyczy) zgodnie z Projektem Technicznym Systemu, w szczególności: przeprowadzenie wdrożenia produkcyjnego Systemu

zgodnie z Projektem Technicznym Systemu; Przeprowadzenie testów akceptacyjnych Systemu, zgodnie

z zatwierdzonym przez Zamawiającego Planem Testów Akceptacyjnych;

Opracowanie i dostarczenie Zamawiającemu Dokumentacji Systemu w szczególności: Dokumentacji Powykonawczej, Dokumentacji Eksploatacyjnej,


6 Opracowanie harmonogramu szkoleńPrzeprowadzenie szkoleń zgodnie z przyjętym harmonogramemDopuszcza się wystawienie vouchera szkoleniowego na realizację części szkoleń po okresie zakończenia realizacji umowy.


7 Udzielenie gwarancji i świadczenie usługi serwisu gwarancyjnego dla rozwiązaniaData rozpoczęcia świadczenia usług gwarancji rozpoczyna się z datą podpisania Protokołu odbioru końcowego – bez uwag.

Od daty podpisania Protokołu odbioru końcowego.

Wymagania dotyczące dokumentacji projektowej

Opis WymaganiaZamawiający wymaga, aby Wykonawca przygotował, zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania, następujące rodzaje Dokumentacji bezpośrednio związanej z przedmiotem zamówienia.Wykonawca opracuje i dostarczy Projekt Techniczny Serwerowni zawierający co najmniej następujące elementy:

56 / 62


Opracowanie szczegółowych wymagań Zamawiającego z zakresie Serwerowni Opracowanie wysokopoziomowej architektury rozwiązania Opis realizacji wymagań, Opracowanie niskopoziomowej architektury rozwiązania Projekt Infrastruktury Fizycznej Plan Testów Akceptacyjnych Przypadki Testów Akceptacyjnych Szczegółowy wykaz Urządzeń (zawierający m.in. producenta, nazwę produktu, typ i model

produktu, numer seryjny produktu, szczegółowy wykaz podzespołów produktu, kategoria produktu, szczegółowy wykaz licencji produktu, typ licencji, ilość licencji),

Opis zadań do wykonania przez Zamawiającego niezbędnych do realizacji projektu.Wykonawca opracuje i dostarczy Projekt Techniczny Systemu zawierający co najmniej następujące elementy: Opracowanie szczegółowych wymagań Zamawiającego z zakresie konfiguracji Systemu Opracowanie wysokopoziomowej architektury rozwiązania (zawierający w szczególności model

przypadków użycia wraz z ich specyfikacją). Opis realizacji wymagań, Opracowanie niskopoziomowej architektury rozwiązania Projekt Infrastruktury Fizycznej Systemu Plan Testów Akceptacyjnych Przypadki Testów Akceptacyjnych Projekt konfiguracji usług stacji roboczych udostępnianych na platformie Wirtualny Desktop, dla co

najmniej 30 wzorców. Projekt konfiguracji chmury akademickiej, wzorcowych konfiguracji oprogramowania opisanego w

rozdziale 2.3.3 oraz dla co najmniej 30 wzorcowych konfiguracji do obsługi oprogramowania będącego w posiadaniu Zamawiającego (między innymi: Mathlab, Mathematica, Statistica). Lista oprogramowania zostanie dostarczona na etapie przygotowywania Projektu Technicznego Systemu.

Szczegółowy wykaz Oprogramowania Standardowego (zawierający m.in. producenta, nazwę produktu, wykaz komponentów produktu, typ produktu, typ licencji, liczbę licencji,

Szczegółowy wykaz Urządzeń (zawierający m.in. producenta, nazwę produktu, typ i model produktu, numer seryjny produktu, szczegółowy wykaz podzespołów produktu, kategoria produktu, szczegółowy wykaz licencji produktu, typ licencji, liczba licencji),

Opis zadań do wykonania przez Zamawiającego niezbędnych do realizacji projektu.Wykonawca opracuje i dostarczy Plan Wdrożenia Systemu składający się z co najmniej następujących elementów: opis czynności wymaganych do realizacji przez Wykonawcę w ramach wdrożenia poszczególnych

komponentów Systemu, harmonogram wdrożenia, zależności pomiędzy poszczególnymi krokami i analizę ryzyka.Plan Testów Akceptacyjnych (PTA) - dokument PTA musi być przygotowany przez Wykonawcę.Wykonawca opracuje i dostarczy Plan Zarządzania Projektem składający się co najmniej z następujących elementów: sposób zarządzania projektem, w tym proces kontroli postępu prac w zakresie kosztów,

pracochłonności i zgodności z harmonogramem, a także częstotliwości punktów kontrolnych, raportowanie o postępach w realizacji projektu oraz sposób zarządzania problemami w realizacji projektu,

proces przygotowania planu realizacji przedsięwzięcia w tym planu zapewnienia jakości przedsięwzięcia,

analizę ryzyka przed rozpoczęciem projektu i zarządzanie ryzykiem w trakcie jego realizacji, sposób zarządzania konfiguracją, w tym identyfikacja elementów konfiguracji, kontrola wersji,

informowanie o zmianach, sposób zarządzania zmianami, w tym rodzaje modyfikacji (poprawki, aktualizacje, rozbudowa,

udoskonalenia) oraz procedury kontroli zmian.Wykonawca opracuje i dostarczy Dokumentację Powykonawczą która będzie zawierać co najmniej następujące informacje:

57 / 62


Wprowadzenie opisujące cele i zakres przedmiotu zamówienia, Diagram kontekstowy zaproponowanego rozwiązania i model zachowania, Ograniczenia rozwiązania, założenia i zależności Opis wymagań funkcjonalnych i pozafunkcjonalnych Systemu, Opis wysokopoziomowej architektury rozwiązania Opis niskopoziomowej architektury rozwiązania Opis infrastruktury fizycznej systemu Opis wydajności, skalowalności i niezawodności Systemu Raport z przebiegu testów akceptacyjnych.Wykonawca opracuje i dostarczy Dokumentację Eksploatacyjną która będzie zawierać co najmniej następujące informacje: procedury administracyjne Systemem, co najmniej uruchomienie, zatrzymanie środowiska,

weryfikacja poprawności funkcjonowania Systemu, zarządzanie poprawkami, zarządzanie zmianą, zarządzanie użytkownikami, zarządzanie usługami udostępnianymi przez System

procedury wykonania zabezpieczenia danych przetwarzanych przez System, oraz dane poszczególnych komponentów Systemu

procedury konserwacji wdrożonego Systemu, procedury awaryjne, procedury kontroli bezpieczeństwa Systemu (Audyt), procedura identyfikacji i kwalifikacji Błędu, procedury kwalifikacji zgłoszeń serwisowych, procedury eskalacji zgłoszeń serwisowych.Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się wysoką jakością, na którą będą miały wpływ, takie czynniki jak: Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i

sekcje, w czytelny i zrozumiały sposób. Zachowanie standardów, w tym notacji UML, a także sposób pisania, rozumianych jako

zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu.

Zachowanie standardów Zamawiającego w zakresie oznaczeń dokumentów wersjonowania, metryk,

Kompletność dokumentu rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia.

Spójność i niesprzeczność dokumentu rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.

Cała Dokumentacja, podlega akceptacji Zamawiającego i zostanie dostarczona w języku polskim, w wersji elektronicznej w niezabezpieczonym/edytowalnym formacie MS Word i niezabezpieczonym formacie PDF (na płycie CD/DVD lub innym równoważnym nośniku danych) i drukowanej, co najmniej w 1 egzemplarzu (dopuszcza się inne formaty zapisu dokumentacji np. diagramy UML lub formaty wektorowe jak DWG, DXF, należy jednak dołączyć przeglądarkę obsługującą wykorzystane formaty). Diagramy UML sporządzone za pomocą narzędzi CASE muszą być dostarczone w formacie EAP. Dostarczone wykresy Gantta muszą być dostarczone w formacie MPP lub w formacie XLS umożliwiającym import do MS Project.Wymagane jest, aby w ramach Dokumentacji Wykonawca przekazał Zamawiającemu pliki źródłowe zastosowanych w niej obrazów, w tym m.in. schematów, rysunków, topologii oraz wykresów, w formacie niezabezpieczonym i edytowalnym.Wymagane jest, aby w ramach Dokumentacji Wykonawca przekazał Zamawiającemu wszystkie dokumenty robocze wytworzone w takcie realizacji niniejszego zamówienia, w szczególności analizy, arkusze kalkulacyjne, materiały robocze, w formacie elektronicznym, niezabezpieczonym i edytowalnym.Wszystkie Dokumenty przekazane w formie elektronicznej (pliki) muszą: być posegregowane w folderach odpowiadających nazwą produktów oraz nazwą, wersją i

58 / 62


podwersją przekazywanego modułu (dotyczy kodów źródłowych), być posegregowane w folderach zgodnie ze strukturą Dokumentacji, posiadać nazwy plików (razem ze ścieżką) krótsze niż 200 znaków,W przypadku kolejnych wersji Dokumentacji wymagane jest, aby Wykonawca dostarczał elektroniczne wersje Dokumentacji, które zawierają wyróżnione różnice pomiędzy kolejnymi wersjami Dokumentacji (w trybie rejestracji zmian).

Wymagania dotyczące zarządzania projektem

Opis WymaganiaWymaga się od Wykonawcy aby: organizacja przedsięwzięcia związanego z przedmiotem zamówienia, procesy kierujące przedsięwzięciem, struktura i zawartość planów projektu, techniki zarządzania projektem, zestaw elementów sterujących zarządzaniem i jakością, w tym cała tworzona dokumentacja, zostały oparte o ogólnie znaną metodykę projektową lub własną uwzględniającą konkretne techniki,

narzędzia i notacje, a także zapewniającą osiągnięcie zamierzonych celów jakościowych przy jednoczesnej minimalizacji możliwości niepowodzenia przedsięwzięcia.

W przypadku wykorzystywania przez Wykonawcę własnej metodyki zarządzania przedsięwzięciem, wymaga się, aby uwzględniała ona co najmniej następujące elementy: sposób zarządzania projektem, w tym proces kontroli postępu prac w zakresie kosztów,

pracochłonności i zgodności z harmonogramem, a także częstotliwości punktów kontrolnych, raportowanie o postępach w realizacji projektu oraz sposób zarządzania problemami w realizacji projektu,

proces przygotowania planu realizacji przedsięwzięcia w tym planu zapewnienia jakości przedsięwzięcia

analizę ryzyka przed rozpoczęciem projektu i zarządzanie ryzykiem w trakcie jego realizacji, sposób zarządzania konfiguracją, w tym identyfikacja elementów konfiguracji, kontrola wersji,

informowanie o zmianach, sposób zarządzania zmianami, w tym rodzaje modyfikacji (poprawki, aktualizacje, rozbudowa,

udoskonalenia) oraz procedury kontroli zmian.

4.1 SzkoleniaPrzedmiotem zakupu jest organizacja i przeprowadzenie certyfikowanych przez producentów sprzętu i oprogramowania szkoleń w zakresie proponowanych przez Oferenta rozwiązań w poszczególnych obszarach funkcjonalnych z zakresu administracji i wytwarzania specjalistycznych rozwiązań informatycznych, zgodnie z poniższym zestawieniem: W zakresie proponowanej platformy sprzętowej – szkolenia z zakresu administracji w liczbie co

najmniej 12 dni dla 4 osób. W zakresie proponowanego rozwiązania do zarządzania chmurą akademicką – szkolenia z zakresu

administracji w liczbie, co najmniej 12 dni dla 4 osób. W zakresie proponowanych systemów operacyjnych – szkolenia z zakresu administracji w liczbie

co najmniej 5 dni dla 4 osób. W zakresie proponowanego oprogramowania bazodanowego – szkolenia z zakresu administracji w

liczbie co najmniej 12 dni dla 4 osób. W zakresie proponowanego oprogramowania serwerów aplikacyjnych – szkolenia z zakresu

administracji w liczbie co najmniej 5 dni dla 4 osób. W zakresie proponowanego rozwiązania kopii zapasowych – szkolenia z zakresu administracji w

liczbie co najmniej 12 dni dla 4 osób. W zakresie proponowanej zintegrowanej platformy analitycznej – szkolenia z zakresu analityki i

przygotowania danych w liczbie co najmniej 12 dni dla 10 osób.

59 / 62


W zakresie proponowanego środowiska do rozwiązywania problemów optymalizacji – szkolenia z zakresu analityki i wytwarzania w liczbie co najmniej 12 dni dla 10 osób.

W zakresie proponowanego środowiska projektowania architektury i implementacji środowiska informatycznego – szkolenia z zakresu analityki i wytwarzania w liczbie co najmniej 18 dni dla 10 osób.

W zakresie proponowanego środowiska do automatyzacji testów funkcjonalnych, wydajnościowych i integracyjnych – w liczbie co najmniej 6 dni dla 10 osób.

W zakresie proponowanego środowiska do zarządzania wymaganiami wytwarzania oprogramowania - w liczbie co najmniej 6 dni dla 10 osób.

W zakresie proponowanego środowiska do zarządzania zmianą wytwarzania oprogramowania - w liczbie co najmniej 6 dni dla 10 osób.

W zakresie proponowanego środowiska do zarządzania jakością - w liczbie co najmniej 6 dni dla 10 osób.

W zakresie proponowanego środowiska do zarządzania cyklem wytwórczym oprogramowania - w liczbie co najmniej 6 dni dla 10 osób.

Miejscem szkoleń powinny być obiekty w granicach administracyjnych Warszawy wraz z zapewnieniem cateringu.

Wykonawca zobowiązuje się do dostarczenia materiałów szkoleniowych w zakresie objętym przedmiotem szkolenia.

Wykonawca zobowiązuje się, że szkolenia zostaną przeprowadzone przez Wykładowców posiadających odpowiednią wiedzę merytoryczną i doświadczenie w zakresie objętym przedmiotem szkolenia z wykorzystaniem sprzętu Wykonawcy.

Szkolenia, obejmujące wykłady i ćwiczenia, zostaną przeprowadzone w salach wyposażonych w stanowiska komputerowe umożliwiające każdemu uczestnikowi samodzielny dostęp do przygotowanego na potrzeby szkolenia środowiska.

Wykonawca przeprowadzi szkolenia w języku polskim, obejmujące wykłady teoretyczne oraz warsztaty praktyczne w zakresie administrowania dostarczonych rozwiązań w niniejszym zamówieniu (w tym wykonanie wybranych przez Zamawiającego procedur dostarczanych w ramach niniejszego zamówienia).

Wykonawca w ramach Etapu 1 opracuje i dostarczy Zamawiającemu Opis Realizacji Szkoleń zawierający:

cel i projektowany zakres szkoleń, metodę i formę szkoleń, podział na dzienne bloki tematyczne szkoleń, opis dziennych bloków tematycznych wykaz pożądanych kwalifikacji osób skierowanych na warsztaty, lokalizację lub lokalizacje realizacji szkoleń,

Opis realizacji szkoleń Wykonawca przedstawi do akceptacji Zamawiającego.Wykonawca zobowiązany jest do przeprowadzenia szkoleń każdorazowo zgodnie ze Zleceniem Szkoleń na podstawie zatwierdzonego przez Zamawiającego opisu realizacji szkoleń.Wykonawca dostarczy Zamawiającemu materiały szkoleniowe w postaci zapisu na płycie CD/DVD (lub innym równoważnym nośniku). Materiały szkoleniowe będą w formie elektronicznej niezabezpieczonej (w formacie .pdf, .doc, .docx, .pps).

Uczestnicy szkoleń otrzymają zaświadczenie ukończenia szkoleń, potwierdzające ich udział w warsztatach w poszczególnych blokach tematycznych (dyplom).

Przeprowadzenie szkoleń zostanie potwierdzone protokołem sporządzonym w dwóch jednobrzmiących egzemplarzach, po jednym dla Zamawiającego i Wykonawcy, zawierającym:

nazwę i tematykę i czas trwania szkoleń,

60 / 62


datę i miejsce szkoleń, imienną listę osób podpisaną przez uczestniczących w szkoleniu, imię i nazwisko oraz specjalizację osób prowadzących szkolenia.

61 / 62


5 Wymagania gwarancyjneWymagania gwarancyjne i serwisowe na sprzęt i oprogramowanie: Przyjmowanie zgłoszeń w trybie 24/7/365, Minimum 60 miesięcy gwarancji na sprzęt, Minimum 60 miesięcy serwisu realizowanego przez producenta sprzętu z gwarantowanym czasem

reakcji w ciągu 4 godzin. Wsparcie gwarancyjne musi być świadczone w języku polskim.

62 / 62

wymagania techniczne - bip.wat.edu.pl · web viewoprogramowanie musi oferować gotowe do użytku...

Documents