Załącznik nr 9 do swiz

Załącznik nr 9 do swiz 1. Opis przedmiotu zamówienia Struktura organizacyjna zamawiającego. Państwową Inspekcję Pracy (PIP) tworzy Główny Inspektorat Pracy (GIP), 16 okręgowych inspektoratów pracy (OIP) oraz działający w ramach terytorialnej właściwości - inspektorzy pracy. Każdy z okręgowych inspektoratów obejmuje zakresem swojej właściwości terytorialnej obszar jednego województwa. W strukturze okręgowych inspektoratów funkcjonują 43 oddziały (OOIP). Ponadto jednostkę organizacyjną Państwowej Inspekcji Pracy stanowi - Ośrodek Szkolenia we Wrocławiu. Środowisko informatyczne zamawiającego. System informatyczny zamawiającego obejmuje ok. 3000 szt. stacji roboczych z czego ponad połowa stanowią komputery przenośne typu laptop wykorzystywane przez inspektorów PIP pracujących w terenie. Pozostała część to nabiurkowe stacje robocze zainstalowane w jednostkach organizacyjnych PIP. Dodatkowo w jednostkach PIP pracuje ok. 160 serwerów, funkcjonują sieci LAN a wszystkie jednostki spięte są siecią WAN. Wymieniony wyżej sprzęt pochodzi od różnych producentów i występuje w różnej konfiguracji. Stacje robocie wyposażone są w systemy operacyjne firmy Microsoft a serwery pracują pod kontrolą systemów Microsoft i Linux w różnych wersjach oraz środowiska wirtualizacyjne: VMware+VSphere, HyperV, Xen. W środowisku PIP funkcjonują aplikacje własne oraz zewnętrznych producentów w oparciu o bazy danych pochodzące od różnych producentów. Na strukturze informatycznej PIP rozpięte są usługi katalogowe Active Directory wykonane zgodnie z zaleceniami producenta oraz inne usługi rozproszone różnych producentów m.in.: bazy Sybase oraz system poczty Novell GroupWise.. Do realizacji przedmiotowego projektu zamawiający udostępnia wykonawcy posiadany przez siebie, fabrycznie nowy sprzęt składający się z 19 szt. serwerów typu Dell R720 (prod. 2013)oraz 19 szt. licencji oprogramowania Windows Server 2012 Datacenter firmy Microsoft. Zamawiający posiada również 1250 licencji CAL do Widnows Server 2012 1. Opis przedmiotu zamówienia Przedmiotem zamówienia są dostawy i wdrożenie wyspecyfikowanego funkcjonalnie oprogramowania standardowego oraz zaprojektowanie i wdrożenie systemu zarządzania i monitorowania środowisk IT Państwowej Inspekcji Pracy opartego na tym oprogramowaniu. System musi zostać skonstruowany tak, aby można było można dowolnie zwiększać liczbę użytkowników bez wymiany systemu lub jego modyfikacji a jedynie poprzez dodanie kolejnych licencji zarządzanych środowisk. Zamawiający wymaga wykorzystania standardowego oprogramowania dostępnego powszechnie na rynku i zastosowania zaleceń wdrożeniowych publikowanych przez producenta oferowanego oprogramowania standardowego. Zamawiający wymaga oparcia wszystkich funkcji systemu o środowiska zbudowane w siedzibach Zamawiającego, z wyłączeniem usług uaktualniania oprogramowania standardowego i jego baz danych. 1 Zamawiający przekaże przedmiotowy sprzęt i oprogramowanie wykonawcy do realizacji umowy; sprzęt i oprogramowanie znajduje się w jednostkach organizacyjnych Państwowej Inspekcji Pracy, w których ma być zainstalowany. 1

1.1. Podstawowe wymagania wobec systemu Skalowalność, wydajność, dostępność Wydajność tworzonego systemu musi pozwalać na obsługę środowiska informatycznego PIP bez spadków wydajności usług działających obecnie. Podstawowym wyznacznikiem wskazującym zachowanie właściwej wydajności będzie ocena dokonana znanymi wskaźnikami statystycznymi (obecna liczba interakcji w ramach tradycyjnych kanałów dostępu, rozpowszechnienie usług elektronicznych w podobnych obszarach zastosowań) oraz ograniczeniami (przepustowość sieci, możliwości wykorzystywanych systemów zaplecza). Dostępność i odporność Wymagane jest zapewnienie wysokiej dostępności systemu w części centralnej, co oznacza że główna instancja systemu zainstalowana w GIP musi być odporna na pojedyncze awarie. Odtwarzanie po awariach W ramach dostawy wykonawca musi opracować szczegółowy, ścisły, w pełni przetestowany plan postępowania na wypadek awarii części centralnej systemu. Plan musi obejmować wszystkie możliwości od ponownego wczytania danych z dysków lub taśm zapasowych i szybką odbudowę serwera od zera. 1.2. Zakres funkcjonalny wdrożenia systemu Poniżej Zamawiający wyszczególnia minimalny zakres wdrożenia systemu obejmujący wymaganą architekturę oraz minimalne funkcjonalności uruchomione w ramach zamówienia. 1. Wymagane jest wdrożenie systemu zarządzania i monitorowania dla struktury 63 ośrodków (Główny Inspektorat Pracy, Okręgowe Inspektoraty Pracy, Oddziały Okręgowych Inspektoratów Pracy i Ośrodek Szkolenia Państwowej Inspekcji pracy. Lista lokalizacji znajduje się w załączniku nr 5 do siwz. 2. Zarządzanie zasobami IT musi być oparte o role, uwierzytelnianie i autoryzację w oparciu o usługi katalogowe Active Directory 2008R2 posiadane przez Zamawiającego. 3. Konsole administracyjne systemu mają być zainstalowane na maszynach klienckich Zamawiającego wyposażonych w system operacyjny Windows 7 Prof. lub nowszy. 4. Zamawiający udostępni 19 serwerów wraz z systemem operacyjnym Windows Server 2012 Datacenter oraz przestrzeń dyskową do przetrzymywania baz danych potrzebnych do działania systemu. 5. Dwa serwery zostaną zainstalowane w Głównym Inspektoracie Pracy (GIP) klaster HA. 6. Pozostałe 17 serwerów zostanie zainstalowane w Okręgowych Inspektoratach Pracy (OIP) oraz OSPIP położonych w całej Polsce. (Serwery, licencje na Windows Data Server 2012R2 są fizycznie w tych lokalizacjach) 7. W każdym z OIP-ów oraz w OSPIP zostanie zainstalowany 1 serwer. 8. Wszystkie systemy zakupione przez zamawiającego muszą zostać zainstalowane na udostępnionych przez Zamawiającego serwerach jako wirtualne maszyny z wykorzystaniem posiadanego przez Zamawiającego oprogramowania Windows Server Hyper-V w ramach posiadanej licencji Windows Server 2012 Datacenter. 2

9. Instalacja systemu operacyjnego, niezbędnych komponentów, instancji systemów wirtualnych wraz z dołączeniem serwerów do domeny należy do obowiązku dostarczającego system. 10. W Głównym Inspektoracie Pracy bazy danych dostarczonych rozwiązań muszą być spięte w klaster typu Active-Passive. 11. W Okręgowych Inspektoratach Pracy oraz Ośrodku Szkolenia PIP bazy danych dostarczanych rozwiązań będą przetrzymywane na przestrzeni dyskowej serwerów. Dodatkowo komponenty systemu muszą spełniać następujące wymagania: I. System do zarządzania infrastrukturą i oprogramowaniem A. Architektura 1. Ze względu na specyficzną architekturę usług katalogowych istniejącą w Urzędzie oraz uwarunkowań organizacyjnych wymagane jest by moduł systemu pracował: a. na poziomie centralnym (odpowiednik domeny pip.gov.pl) i zbierał informacje z inwentaryzacji sprzętu i oprogramowania z całej struktury Zamawiającego; b. na poziomie wojewódzkim (odpowiednik domen, np.: gip.pip.gov.pl, kr.pip.gov.pl 18 takich domen) i zbierał informacje z inwentaryzacji sprzętu i oprogramowania w ramach właściwości terytorialnych (z OIP i jego OOIPów, OSPIP, GIP); c. na poziomie lokalnym (OOIP) aby efektywnie wykorzystać sieć może zostać zlokalizowany element systemu w formie repozytorium paczek 2. Każda rola systemu ma zostać zainstalowana na osobnej instancji jako maszyna wirtualna a. w GIP na dwóch dedykowanych serwerach fizycznych ma zostać uruchomiony klaster HA elementów systemu z pkt 1a (całość) i 1b (w części dla Głównego Inspektoratu Pracy). b. w OIPach i OSPIP na serwerach dedykowanych do systemu (po jednym w każdej lokalizacji). 3. W OOIP zostanie wskazany zasób służący jako repozytorium paczek. 4. Na wszystkich pozostałych serwerach i stacjach roboczych w całej organizacji musi zostać zainstalowany agent tego systemu (zamawiający przewiduje nie więcej niż 160 serwerów i 3000 stacji roboczych). 5. Dla każdego z terytorialnych administratorów wykonawca musi stworzyć konto administratora do zarządzania odpowiednio podległymi serwerami i stacjami roboczymi. B. Zadania modułu 1. Inwentaryzacja zasobów serwera musi odbywać się przynajmniej raz w tygodniu w określonym czasie. 2. Inwentaryzacja musi odbywać się osobno dla sprzętu i osobno dla oprogramowania. 3. Inwentaryzacja sprzętu musi się odbywać przez pobieranie informacji z interfejsu WMI. 4. Inwentaryzacja sprzętu musi zbierać informację przynajmniej o: a. Dyskach twardych b. Procesorach c. Pamięci RAM 5. Inwentaryzacja oprogramowania musi zbierać informację przynajmniej o: a. Zainstalowanym systemie operacyjnym b. Zainstalowanych składnikach pakietu Office 3

c. Zainstalowanym oprogramowaniu standardowym (Java, Adobe FlashPlayer, Adobe Acrobat Reader,..). C. Kontrola zdalna 1. System musi umożliwiać pomoc użytkownikom stacji roboczych poprzez zdalną kontrolę. 2. System musi umożliwiać zdalne zrestartowanie stacji roboczej. 3. System musi umożliwiać na zdalny transfer plików do stacji roboczej. D. Dystrybucja oprogramowania i aktualizacji 1. System musi dostarczać wszystkie funkcje do przygotowania i dystrybucji pakietu instalacyjnego, który nie wymaga interakcji ze strony użytkownika. 2. Instalacja oprogramowania musi się dać przeprowadzić na dwa sposoby: a. kopiowanie pakietu instalacyjnego na stację roboczą i uruchomienie instalatora b. instalacja bezpośrednio ze wskazanego zasobu sieciowego 3. Pakiet instalacyjny musi być przechowywany na specjalnie wydzielonych zasobach sieciowych repozytoriach paczek punktach dystrybucyjnych. 4. Punkty dystrybucyjne muszą mieć możliwość synchronizacji pakietów instalacyjnych, po umieszczeniu pakietu w punkcie nadrzędnym musi on być transmitowany automatycznie do wszystkich podrzędnych. 5. Synchronizacja ta musi się odbywać w sposób przyrostowy, tzn. zmiana pojedynczego pliku w pakiecie instalacyjnym nie może pociągać za sobą konieczności ponownej transmisji całego pakietu. 6. Synchronizacja musi odbywać się w ustalonym czasie, np. codziennie o 4 rano. E. Raporty 1. System musi pozwalać na generowanie raportów na temat: a. Inwentaryzacji sprzętu, b. Inwentaryzacji oprogramowania, c. Systemów operacyjnych. 2. System musi umożliwiać budowanie stron z raportami w postaci tablic (tzw. dashboard), na których może znajdować się więcej niż jeden raport. II. System zarządzania komponentami A. Architektura 1. Ze względu na specyficzną architekturę usług katalogowych istniejącą w Urzędzie oraz uwarunkowań organizacyjnych wymagane jest by moduł systemu pracował: a. na poziomie centralnym (odpowiednik domeny pip.gov.pl) i zbierał informacje o stanie krytycznych usług tj. AD, poczty Novell GroupWise oraz baz Sybase z całej struktury Zamawiającego; b. na poziomie wojewódzkim (odpowiednik domen, np.: gip.pip.gov.pl, kr.pip.gov.pl 18 takich domen) w ramach właściwości terytorialnych (z OIP i jego OOIPów, OSPIP, GIP) i umożliwiał monitorowanie wskazanych serwerów; 4

2. Rola systemu ma zostać zainstalowana na osobnej instancji jako maszyna wirtualna a. w GIP na dwóch dedykowanych serwerach fizycznych pracujących w klastrze HA b. w OIPach i OSPIP na serwerze dedykowanym do systemu. 3. Na wszystkich pozostałych serwerach i stacjach roboczych w całej organizacji musi zostać zainstalowany agent tego systemu (zamawiający przewiduje nie więcej niż 200 serwerów i 3000 stacji roboczych). 4. Dla każdego z terytorialnych administratorów zostanie stworzone konto administratora dające możliwość monitoringu poprawności działania sondowanych systemów oraz monitoringu podległych serwerów. B. Zadania modułu 1. Zainstalowany na serwerach agent ma monitorować przynajmniej stan zdrowia podstawowych usług Systemu Windows, wydajność dysku twardego wraz z ilością wolnego miejsca oraz stopień wykorzystania pamięci RAM. 2. Zainstalowany na wskazanych przez GIP serwerze system do sondowania ma monitorować przynajmniej dostępność systemu poczty Novell GroupWise, baz danych Sybase o oraz dostępność Active Directory razem z raportami na temat dostępności usług oraz stanu ich zdrowia. 3. System musi mieć możliwość generowania raportów o monitorowanych obiektach. 4. System musi umożliwiać eksport tworzonych raportów przynajmniej do formatów: a. XML, b. CSV, c. TIFF, d. PDF, e. XLS, f. Web Archive. 5. System musi być zainstalowany tak, aby gwarantował przekazywanie zdarzeń z podległych klientów w czasie rzeczywistym (dopuszczalne opóźnienia mogą pochodzić z medium transportowego sieć, oraz komponentów zapisujących i odczytujących). 6. System musi gwarantować niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń przed wysłaniem, definicja schematu musi być w pliku XML z możliwością dodawania i modyfikacji. 7. Monitoring systemu musi odbywać się z poziomu webkonsoli dającej dostęp do podstawowych komponentów monitorujących z dowolnej stacji roboczej. 8. Konsola musi umożliwiać budowanie widoków tablicowych (tzw. dashboard) w celu prezentacji różnych widoków na tym samym ekranie. 9. Widoki muszą mieć możliwość: a. filtrowania informacji, jakie się na nich znajdą (po typie, ważności, typach obiektów, itp ), b. sortowania podobnych informacji, c. grupowania podobnych informacji, 5

d. definiowania kolumn, jakie mają się znaleźć na widokach kolumnowych. 10. Dla każdego z 36 administratorów wykonawca zainstaluje konsolę zdalną w postaci programu na stacji roboczej, obsługującej wszystkie funkcje systemu. 11. Konsola zdalna musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym: a. opcji definiowania ról użytkowników, b. opcji definiowania widoków, c. opcji definiowania i generowania raportów, d. opcji definiowania powiadomień, e. opcji tworzenia, konfiguracji i modyfikacji zestawów monitorujących, f. opcji instalacji/deinstalacji klienta. III. System zarządzania incydentami i problemami wraz z systemem do automatyzacji zarządzania środowisk IT A. Architektura 1. Systemy wykazują dużą korelację ze sobą więc muszą zostać ujęte jako jeden zbieżny system. 2. System musi być zainstalowany lokalnie w GIP, Okręgowych Inspektoratach Pracy OIP oraz w Ośrodku Szkolenia PIP(OSPIP), z podziałem na właściwości usług katalogowych. (j.w.) 3. System zostanie zainstalowany na wskazanym przez GIP klastrze jako osobna wirtualna maszyna. 4. System musi posiadać bazę wiedzy (CMDB) wraz ze wszystkimi tabelami i odpowiednimi relacjami. 5. Baza wiedzy musi zostać połączona z usługą katalogową i systemem do zarządzania desktopami. 6. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane i definiowane mechanizmy w ramach przyjętej metodyki (np. ITIL lub równoważnej) na zarządzanie incydentami i problemami oraz zarządzanie zmianą. 7. System automatyzacji zarządzania środowisk IT musi udostępniać bez skryptowe środowisko standaryzujące i automatyzujące zarządzanie środowiskiem IT na bazie najlepszych praktyk. 8. Dla każdego z terytorialnych administratorów zostanie stworzone konto administratora dające możliwość zarządzania incydentami i problemami podległych stacji roboczych i serwerów. B. Zadania modułu 1. Platforma musi być dostępna z przeglądarki internetowej wewnątrz organizacji. 2. Platforma musi dawać możliwość resetowania hasła dla użytkownika bezpośrednio z poziomu przeglądarki. 3. Reset taki może wykonać tylko uprawniona osoba/administrator. 4. Platforma musi umożliwiać dystrybucję aplikacji. 6 5. System musi wspomagać automatyzację procesów zarządzania zmianami konfiguracji środowisk IT.

6. System musi wspomagać planowanie i automatyzację wdrażania poprawek. 7. System musi udostępniać mechanizmy workflow automatyzujące zadania administracyjne wraz graficznym interfejsem projektowania, budowy i monitorowania workflow. 8. System musi umożliwiać również zarządzanie incydentami, problemami i zmianą dla aplikacji, w szczególności wytwarzanych w PIP, baza danych systemu powinna być posadowiona centralnie w GIP. IV. System zarządzania środowiskami wirtualnymi A. Architektura 1. System musi być zainstalowany lokalnie, w GIP, Okręgowych Inspektoratach Pracy OIP oraz w Ośrodku Szkolenia PIP(OSPIP), z podziałem na właściwości usług katalogowych. System zostanie zainstalowany na wskazanym przez GIP klastrze jako osobna wirtualna maszyna. 2. Na wszystkich pozostałych serwerach wirtualizacyjnych w całej organizacji musi zostać zainstalowany agent tego systemu (zamawiający przewiduje nie więcej niż: 160 serwerów). 3. Dla każdego z okręgowych administratorów wykonawca stworzy konto administratora dające możliwość zarządzania podległymi serwerami wirtualizacyjnymi. B. Konsola do zarządzania 1. Konsola musi umożliwiać wykonywanie codziennych zadań związanych z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny. 2. Widoki hostów i maszyn wirtualnych muszą mieć możliwość zakładania filtrów, pokazując tylko odfiltrowane elementy, np. maszyny wyłączone, maszyny z systemem operacyjnym X, itp... 3. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać co najmniej: a. Stan, b. Ilość alokowanej pamięci, c. Ilość alokowanego dysku twardego, d. System operacyjny, e. Platformę wirtualizacyjną, f. Stan ostatniego zadania, g. Wykres utylizacji procesora, h. Podgląd na pulpit. 4. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem zakończenia poszczególnych etapów i całych zadań. V. System tworzenia kopii zapasowych 1. System musi zostać zainstalowany we wszystkich Okręgowych Inspektoratach Pracy,Ośrodku Szkolenia PIP oraz w Głównym Inspektoracie Pracy, razem 18 jednostek. 7

2. System zostanie zainstalowany na wskazanych przez GIP serwerach jako osobna wirtualna maszyna. 1.3. Wymagany zakres dostaw i usług W ramach realizacji usług wdrożeniowych Zamawiający wymaga od wykonawcy dodatkowo: 1. Wykonania wstępnych projektów technicznych systemu uwzględniających jego funkcje wymagane w specyfikacji oraz harmonogramy poszczególnych działań i przekazanie ww dokumentów do zaakceptowania zamawiającemu przez rozpoczęciem właściwego wdrożenia. 2. Zainstalowanie całości oprogramowania standardowego, będącego przedmiotem dostaw w środowisku zamawiającego. 3. Konfigurację, uruchomienie i objęcie opieką serwisową następujących części funkcjonalnych systemu: a. Monitorowania i zarządzania serwerów objętych projektem: i. Serwerów wdrażanego systemu, ii. Serwerów systemu kadrowo-płacowego, b. Zarządzania stacjami roboczymi, c. Zarządzania wirtualizacją serwerów wykorzystywanych w projekcie, d. Zarządzania składowaniem danych (backup) dla serwerów systemu zainstalowanych w GIP, e. Konfiguracji i uruchomienia centralnej części help-desk z uruchomieniem mechanizmu zgłoszeń od użytkowników (ticket). 4. Przeprowadzenie szkoleń. 5. Objęcie systemu 36 miesięczną serwisową. 1.4. Dodatkowe wymagania techniczne Zamawiający wymaga, aby system monitorowania w części serwerowej opierał swoje repozytorium danych o silnik relacyjnej bazy danych spełniający następujące wymagania: 1. Możliwość wykorzystania systemu bazy danych (SBD), jako silnika relacyjnej bazy danych, platformy bazodanowej dla wielu aplikacji. 2. Zintegrowane narzędzia graficzne do zarządzania systemem SBD musi dostarczać zintegrowane narzędzia do zarządzania i konfiguracji wszystkich usług wchodzących w skład systemu (baza relacyjna, usługi analityczne, usługi raportowe, usługi transformacji danych). Narzędzia te muszą udostępniać możliwość tworzenia skryptów zarządzających systemem oraz automatyzacji ich wykonywania. 3. Zarządzanie serwerem za pomocą skryptów - SBD musi udostępniać mechanizm zarządzania systemem za pomocą uruchamianych z linii poleceń skryptów administracyjnych, które pozwolą zautomatyzować rutynowe czynności związane z zarządzaniem serwerem. 4. Dedykowana sesja administracyjna - SBD musi pozwalać na zdalne połączenie sesji administratora systemu bazy danych w sposób niezależny od normalnych sesji klientów. 5. Możliwość automatycznej aktualizacji systemu - SBD musi umożliwiać automatyczne ściąganie i instalację wszelkich poprawek producenta oprogramowania (redukowania zagrożeń powodowanych przez znane luki w zabezpieczeniach oprogramowania). 6. SBD musi umożliwiać tworzenie klastrów niezawodnościowych. 8

7. Wysoka dostępność - SBD musi posiadać mechanizm pozwalający na duplikację bazy danych między dwiema lokalizacjami (podstawowa i zapasowa) przy zachowaniu następujących cech: a) bez specjalnego sprzętu (rozwiązanie tylko programowe oparte o sam SBD), b) niezawodne powielanie danych w czasie rzeczywistym (potwierdzone transakcje bazodanowe), c) klienci bazy danych automatycznie korzystają z bazy zapasowej w przypadku awarii bazy podstawowej bez zmian w aplikacjach, 8. Kompresja kopii zapasowych - SBD musi pozwalać na kompresję kopii zapasowej danych (backup) w trakcie jej tworzenia. Powinna to być cecha SBD niezależna od funkcji systemu operacyjnego ani od sprzętowego rozwiązania archiwizacji danych. 9. Możliwość zastosowania reguł bezpieczeństwa obowiązujących w jednostkach organizacyjnych - wsparcie dla zdefiniowanej polityki bezpieczeństwa (np. automatyczne wymuszanie zmiany haseł użytkowników, zastosowanie mechanizmu weryfikacji dostatecznego poziomu komplikacji haseł wprowadzanych przez użytkowników), możliwość zintegrowania uwierzytelniania użytkowników z Active Directory. 10. Możliwość definiowania reguł administracyjnych dla serwera lub grupy serwerów - SBD musi mieć możliwość definiowania reguł wymuszanych przez system i zarządzania nimi. Przykładem takiej reguły jest uniemożliwienie użytkownikom tworzenia obiektów baz danych o zdefiniowanych przez administratora szablonach nazw. Dodatkowo wymagana jest możliwość rejestracji i raportowania niezgodności działającego systemu ze wskazanymi regułami, bez wpływu na jego funkcjonalność. 11. Rejestrowanie zdarzeń silnika bazy danych w czasie rzeczywistym - SBD musi posiadać możliwość rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych, bez ujemnego wpływu na wydajność rozwiązania, pozwalać na selektywne wybieranie rejestrowanych zdarzeń. Wymagana jest rejestracja zdarzeń: a) odczyt/zapis danych na dysku dla zapytań wykonywanych do baz danych (w celu wychwytywania zapytań znacząco obciążających system), b) wykonanie zapytania lub procedury trwające dłużej niż zdefiniowany czas (wychwytywanie długo trwających zapytań lub procedur), c) para zdarzeń zablokowanie/zwolnienie blokady na obiekcie bazy (w celu wychwytywania długotrwałych blokad obiektów bazy). 12. Zarządzanie pustymi wartościami w bazie danych - SBD musi efektywnie zarządzać pustymi wartościami przechowywanymi w bazie danych (NULL). W szczególności puste wartości wprowadzone do bazy danych musi zajmować minimalny obszar pamięci. 13. Definiowanie nowych typów danych - SBD musi umożliwiać definiowanie nowych typów danych wraz z definicją specyficznej dla tych typów danych logiki operacji. Jeśli np. zdefiniujemy typ do przechowywania danych hierarchicznych, to obiekty tego typu powinny udostępnić operacje dostępu do potomków obiektu, rodzica itp. Logika operacji nowego typu danych powinna być implementowana w zaproponowanym przez Dostawcę języku programowania. Nowe typy danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji. 14. Wsparcie dla technologii XML - SBD musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. W szczególności musi: 1) udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli, 2) udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD, 3) udostępniać język zapytań do struktur XML, 4) udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie i modyfikację zawartości struktur XML), 9

5) udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań. 15. Możliwość tworzenia funkcji i procedur w innych językach programowania - SBD musi umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania, niż standardowo obsługiwany język zapytań danego SBD. System musi umożliwiać tworzenie w tych językach m.in. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo powinien udostępniać środowisko do debugowania. 16. Możliwość tworzenia rekursywnych zapytań do bazy danych - SBD musi udostępniać wbudowany mechanizm umożlwiający tworzenie rekursywnych zapytań do bazy danych bez potrzeby pisania specjalnych procedur i wywoływania ich w sposób rekurencyjny. 17. Obsługa błędów w kodzie zapytań - język zapytań i procedur w SBD musi umożliwiać zastosowanie mechanizmu przechwytywania błędów wykonania procedury (na zasadzie bloku instrukcji TRY/CATCH) tak jak w klasycznych językach programowania. 18. Raportowanie zależności między obiektami - SBD musi udostępniać informacje o wzajemnych zależnościach między obiektami bazy danych. 19. Mechanizm zamrażania planów wykonania zapytań do bazy danych - SBD musi udostępniać mechanizm pozwalający na zamrożenie planu wykonania zapytania przez silnik bazy danych (w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam sposób). Mechanizm ten daje możliwość zapewnienia przewidywalnego czasu odpowiedzi na zapytanie po przeniesieniu systemu na inny serwer (środowisko testowe i produkcyjne), migracji do innych wersji SBD, wprowadzeniu zmian sprzętowych serwera. 20. System transformacji danych - SBD musi posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to musi pozwalać na przygotowanie definicji transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora. Transformacje muszą posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom. Musi być także zapewniona możliwość tworzenia własnych transformacji. Środowisko tworzenia transformacji danych musi udostępniać m.in.: a/ mechanizm debugowania tworzonego rozwiązania, b/ mechanizm stawiania pułapek (breakpoints), c/ mechanizm logowania do pliku wykonywanych przez transformację operacji, d/ możliwość wznowienia wykonania transformacji od punktu, w którym przerwano jej wykonanie (np. w wyniku pojawienia się błędu), e/ możliwość cofania i ponawiania wprowadzonych przez użytkownika zmian podczas edycji transformacji (funkcja undo/redo) f/ mechanizm analizy przetwarzanych danych (możliwość podglądu rekordów przetwarzanych w strumieniu danych oraz tworzenia statystyk, np. histogram wartości w przetwarzanych kolumnach tabeli), g/ mechanizm automatyzacji publikowania utworzonych transformacji na serwerze bazy danych (w szczególności tworzenia wersji instalacyjnej pozwalającej automatyzować proces publikacji na wielu serwerach), h/ mechanizm tworzenia parametrów zarówno na poziomie poszczególnych pakietów, jak też na poziomie całego projektu, parametry powinny umożliwiać uruchamianie pakietów podrzędnych i przesyłanie do nich wartości parametrów z pakietu nadrzędnego, i/mechanizm mapowania kolumn wykorzystujący ich nazwę i typ danych do automatycznego przemapowania kolumn w sytuacji podmiany źródła danych. 10

21. Wbudowany system analityczny musi mieć możliwość wyliczania agregacji wartości miar dla zmieniających się elementów (członków) wymiarów i ich atrybutów. Agregacje muszą być składowane w jednym z wybranych modeli (MOLAP wyliczone gotowe agregacje rozłącznie w stosunku do danych źródłowych, ROLAP agregacje wyliczane w trakcie zapytania z danych źródłowych). Pojedyncza baza analityczna musi mieć możliwość mieszania modeli składowania, np. dane bieżące ROLAP, historyczne MOLAP w sposób przezroczysty dla wykonywanych zapytań. Dodatkowo musi być dostępna możliwość drążenia danych z kostki do poziomu rekordów szczegółowych z bazy relacyjnych. 22. Środowisko raportowania musi być osadzone i administrowane z wykorzystaniem mechanizmu Web Serwisów (Web Services). 23. Wymagane jest generowanie raportów w formatach: XML, PDF, Microsoft Excel (od wersji 1997 do 2010), Microsoft Word (od wersji 1997 do 2010), HTML, TIFF. Dodatkowo raporty muszą być eksportowane w formacie Atom data feeds, które można będzie wykorzystać jako źródło danych w innych aplikacjach. 24. SBD musi umożliwiać rozbudowę mechanizmów raportowania m.in. o dodatkowe formaty eksportu danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas generowania raportu (np. nowe funkcje agregujące), mechanizmy zabezpieczeń dostępu do raportów. 25. SBD musi umożliwiać wysyłkę raportów drogą mailową w wybranym formacie (subskrypcja). 26. Wbudowany system raportowania powinien posiadać rozszerzalną architekturę oraz otwarte interfejsy do osadzania raportów oraz do integrowania rozwiązania z różnorodnymi środowiskami IT. 1.5. Wymagania w zakresie dostaw oprogramowania standardowego Przedmiotem dostaw są licencje oprogramowania standardowego (produktów). Specyfikacja ilościowa przedmiotu zamówienia: Typ oprogramowania Oprogramowanie zarządzania stacjami klienckimi z prawem do uaktualniania (licencja na stację roboczą) Pakiet administrowania stacjami klienckimi z prawem do uaktualniania (licencja na stację roboczą) Oprogramowanie zarządzania i monitorowania serwerów z prawem do uaktualniania (licencja na 2 procesory) Licencje dostępowe do serwerowych systemów operacyjnych Microsoft Windows Server 2012 Datacenter (posiadanych przez zamawiającego) z prawem do uaktualniania (licencja na urządzenie) Tabela 1 specyfikacja ilościowa zamawianych produktów liczba Produktów 3000 3000 200 1700 11

1.5.1. Wymagania ogólne w zakresie dostaw oprogramowania 1. Zamawiający wymaga zapewnienia kompleksowej obsługi umowy licencyjnej oraz realizację usług zagwarantowanych w ramach dwuletniego programu licencyjnego. 2. Licencje muszą pozwalać na swobodne przenoszenie pomiędzy stacjami roboczymi i serwerami (np. w przypadku wymiany sprzętu) oraz z jednostki organizacyjnej do jednostki organizacyjnej funkcjonujących w ramach Państwowej Inspekcji Pracy. 3. Licencje muszą zawierać prawo do instalacji najnowszej wersji zakupionego oprogramowania dostępnej w trakcie minimum 36 miesięcy od podpisania umowy. 4. Licencjonowanie musi uwzględniać prawo (w okresie przynajmniej 5 lat) do instalacji udostępnianych przez producenta uaktualnień i poprawek krytycznych i opcjonalnych do zakupionej wersji oprogramowania. 5. Z uwagi na zakres funkcjonalny wdrożenia planowanego na bazie zamawianego oprogramowania, konieczności wprowadzenia jednolitych polityk bezpieczeństwa oraz konieczności minimalizacji kosztów związanych z wdrożeniem, szkoleniami i eksploatacją systemów, Zamawiający wymaga oferty zawierającej licencje pochodzące od jednego producenta, umożliwiające wykorzystanie wspólnych i jednolitych procedur masowej instalacji, uaktualniania, zarządzania i monitorowania. 6. Wymagane jest zapewnienie możliwości korzystania z wcześniejszych wersji zamawianego oprogramowania i korzystania z kopii zamiennych (możliwość kopiowania oprogramowania na wiele urządzeń przy wykorzystaniu jednego standardowego obrazu), z prawem do wielokrotnego użycia jednego obrazu dysku w procesie instalacji i tworzenia kopii zapasowych. 7. Wykonawca zapewni dostęp do strony producenta oferowanego oprogramowania (Producenta) pozwalającej upoważnionym osobom ze strony Zamawiającego na: a. Pobieranie zakupionego oprogramowania, b. Pobieranie kluczy aktywacyjnych do zakupionego oprogramowania, c. Sprawdzanie liczby zakupionych licencji w wykazie zakupionych produktów. 8. Zamawiający wymaga udzielenia uprawnień na stronie Producenta oraz dostępu do kodu zamawianego oprogramowania i kluczy licencyjnych w terminie do 90 dni roboczych od podpisania umowy. 1.5.2. Specyfikacja techniczno eksploatacyjna i cech użytkowych oprogramowania. W poniższej części przedstawione są wymagania funkcjonalne dotyczące zamawianego oprogramowania i usług. Z uwagi na to, że art. 30 ust. 5 ustawy Prawo zamówień publicznych wyraźnie wskazuje na Wykonawcę, jako tego, kto jest zobowiązany wykazać, że oferowane rozwiązania i produkty spełniają wymagania postawione przez Zamawiającego, Zamawiający zastrzega sobie, w przypadku jakichkolwiek wątpliwości, prawo sprawdzenia pełnej zgodności oferowanych produktów z wymogami specyfikacji istotnych warunków na etapie wyboru najkorzystniejszej oferty. Sprawdzenie to, będzie polegać na wielokrotnym przeprowadzeniu testów w warunkach produkcyjnych na sprzęcie zamawiającego, z użyciem urządzeń peryferyjnych zamawiającego, na arkuszach, bazach danych i plikach zamawiającego. W tym celu wykonawca na każde wezwanie zamawiającego dostarczy do siedziby zamawiającego w terminie 2 dni od daty otrzymania wezwania, po jednym egzemplarzu wskazanego w ofercie przedmiotu dostawy umożliwiającego przeprowadzenie ww. testów. W odniesieniu do oprogramowania mogą zostać dostarczone licencje tymczasowe, w pełni zgodne z oferowanymi. 12

. Negatywny wynik tego sprawdzenia skutkować będzie odrzuceniem oferty, na podstawie art. 89 ust. 1 pkt. 2 ustawy. Nie przedłożenie oferowanych produktów do przetestowania w ww. terminie zostanie potraktowane, jako negatywny wynik sprawdzenia. W testach mogą brać udział wszyscy zainteresowani Wykonawcy. Testy będą prowadzone 1.5.2.1. Oprogramowanie zarządzania stacjami klienckimi z prawem do uaktualniania (licencja na stację roboczą) Oprogramowanie klienckie do zarzadzania urządzeniami Licencje na oprogramowanie muszą być przypisane do każdego środowiska systemu operacyjnego lub każdego użytkownika i uprawniać do uruchomienia wymaganych serwerów zarządzających wraz z dedykowaną bazą danych. Oprogramowanie klienckie do zarzadzania urządzeniami musi składać się z dwóch podstawowych modułów: 1. Systemu zarządzania infrastrukturą kliencką i oprogramowaniem, 2. Systemu klienckiego zarządzania maszynami wirtualnymi. System zarządzania infrastrukturą kliencką i oprogramowaniem musi spełniać następujące wymagania poprzez natywne dla niego mechanizmy, bez użycia dodatkowych aplikacji. I. Architektura System zarządzania stacjami roboczymi musi udostępniać komponenty i funkcje pozwalające na budowę bezpiecznego i skalowalnego środowiska, a w tym: 1. System zarządzający musi mieć możliwość publikowania informacji o uruchomionych komponentach w usługach katalogowych (np. AD), informacje te muszą być dostępne dla klientów systemu w celu automatycznej konfiguracji 2. System zarządzający musi umożliwiać budowę infrastruktury drzewiastej (rodzicdzieckorodzic-dziecko) w następujący sposób: a/ dla większych lokalizacji i/lub lokalizacji, serwer typu dziecko powinien posiadać własną wydzieloną bazę danych z informacjami tylko o podległych stacjach roboczych b/ dla małych lokalizacji i/lub lokalizacji, serwer typu dziecko musi działać tylko, jako Proxy dla informacji przekazywanych przez stacje robocze do serwera nadrzędnego rodzic c/ dodatkowo musi być możliwość uruchomienia nadrzędnego centralnego serwera pozwalającego na stworzenie raportów dla całej infrastruktury drzewiastej. 3. Klient systemu musi mieć możliwość instalacji: - manualnej, wymuszonej przez administratora stacji roboczej - automatycznej, podczas startu systemu operacyjnego (skrypt logowania) - automatycznej, wymuszanej przez serwer zarządzający. 4. Instalacja typu automatycznego nie może wymagać zalogowania użytkownika, lub jeśli użytkownik jest zalogowany to nie może wymagać od niego posiadania uprawnień administratora stacji roboczej. 13

5. Dla szczególnie dużych instalacji system musi umożliwiać instalację i uruchomienie różnych komponentów systemu zarządzającego na różnych fizycznych maszynach, oraz możliwość uruchomienia kilku instancji tego samego komponentu w celu podziału i obsługi dużych grup stacji roboczych. 6. System musi wyszukiwać stacje robocze, które muszą być zarządzane w następujących repozytoriach: 1) Active Directory 2) Network Discovery (przy zadanym zakresie adresów IP). System musi umożliwiać wyszukiwanie użytkowników i grup użytkowników w powyższych repozytoriach. 7. Klient systemu musi mieć możliwość porozumiewania się z użytkownikiem końcowym w języku polskim. 8. System musi umożliwiać opcję rozszerzenia o moduł pozwalający na zarządzanie urządzeniami mobilnymi. II. Inwentaryzacja i zarządzanie zasobami: 1. Inwentaryzacja zasobów stacji roboczej musi się odbywać w określonych przez administratora systemu interwałach czasowych. System musi mieć możliwość odrębnego planowania inwentaryzacji sprzętu i oprogramowania 2. Inwentaryzacja sprzętu musi się odbywać przez pobieranie informacji z interfejsu WMI, komponent inwentaryzacyjny musi mieć możliwość konfiguracji w celu ustalenia informacji, o jakich podzespołach stacji roboczej będą przekazywane do systemu 3. Inwentaryzacja musi umożliwiać zasilanie bazy danych informacjami pochodzącymi z plików informacyjnych w standardach (MIF Management Information Format, MOF Management Object Format) przechowywanych na stacjach roboczych 4. Inwentaryzacja oprogramowania musi skanować zasoby dyskowe stacji roboczej przekazując dane o znalezionych plikach do systemu w celu identyfikacji oprogramowania oraz celów wyszukiwania i gromadzenia informacji o szczególnych typach plików (np. pliki multimedialne: wav, mp3, avi, xvid, itp ) 5. System musi posiadać własną bazę dostępnego na rynku komercyjnego oprogramowania, pozwalającą na identyfikację zainstalowanego i użytkowanego na stacjach roboczych oprogramowania System musi dawać możliwość aktualizacji tej bazy przy pomocy konsoli administratora oraz automatycznie przez aktualizacje ze stron producenta 6. System musi umożliwiać zbieranie ze stacji wskazanych przez administratora plików, np. konfiguracyjnych w celu ich archiwizacji i wersjonowania, z możliwością blokowania przy przekroczeniu przez plik określonej wielkości 7. Informacje inwentaryzacyjne muszą być przesyłane przy pomocy plików różnicowych w celu ograniczenia ruchu z klienta do serwera III. Użytkowane oprogramowanie pomiar wykorzystania 1. System musi mieć możliwość zliczania uruchomionego oprogramowania w celu śledzenia wykorzystania przez poszczególnych użytkowników 2. Reguły dotyczące monitorowanego oprogramowania muszą być tworzone automatycznie przez skanowanie oprogramowania uruchamianego na stacjach roboczych. IV. Zdalna kontrola i zdalna asysta: 1. W celu zapewnienia zdalnej pomocy użytkownikom stacji roboczych system musi udostępniać następujące narzędzia: 1) Zdalna kontrola 14

2) Zdalny reboot 3) Transfer plików 4) Zdalne wykonanie poleceń 5) Ping Test 2. W celu wykorzystania funkcji systemów operacyjnych, system musi mieć możliwość wykorzystania w celu zdalnej kontroli i pomocy wbudowanych cech systemów Windows, w tym usług: 1) Remote Desktop 2) Remote Assistance Usługi te muszą być konfigurowane z poziomu systemu zarządzania V. Dystrybucja oprogramowania, dystrybucja i zarządzanie aktualizacjami, instalacja/aktualizacja systemów operacyjnych: 1. System musi dostarczać wszystkie funkcje do przygotowania i dystrybucji pakietu instalacyjnego, który nie wymaga interakcji ze strony użytkownika lub można w pakiecie zawrzeć plik odpowiedzi dla instalatora. W innym przypadku dopuszcza się użycie narzędzi zewnętrznych do przygotowania pakietu instalacyjnego. Narzędzie, o którym jest mowa w zdaniu poprzednim musi zostać dostarczone wraz z systemem do każdej lokalizacji (GIP, OIP, OSPIP). 2. Pakiet instalacyjny musi mieć możliwość uruchomienia z opcjami, pozwalając zdefiniować parametry dla różnych grup komputerów bez konieczności duplikowania samego pakietu instalacyjnego, np. tylko dla platformy 32bitowej, tylko dla komputerów z określoną ilością RAM 3. Instalacja oprogramowania musi się dać przeprowadzić na dwa sposoby: a/ kopiowanie pakietu instalacyjnego na stację roboczą i uruchomienie instalatora b/ instalacja bezpośrednio ze wskazanego zasobu sieciowego 4. Pakiet instalacyjny musi być przechowywany na specjalnie wydzielonych zasobach sieciowych punktach dystrybucyjnych, punkty te muszą być zasobami sieciowymi lub wydzielonymi witrynami WWW lub wydzielonymi środowiskami dostarczanymi i utrzymywanymi przez producenta oprogramowania 5. Punkty dystrybucyjne muszą mieć możliwość synchronizacji pakietów instalacyjnych, po umieszczeniu pakietu w punkcie nadrzędnym musi on być transmitowany automatycznie do wszystkich podrzędnych. Synchronizacja ta musi się odbywać w sposób przyrostowy, tzn. zmiana pojedynczego pliku w pakiecie instalacyjnym nie może pociągać za sobą konieczności ponownej transmisji całego pakietu 6. Transmisja pakietów instalacyjnych przy pomocy protokołu http musi obejmować możliwość regulacji zużycia pasma po stronie stacji roboczej, np. przy pomocy protokołu BITS 7. System musi umożliwiać monitorowanie zadań dystrybucji oprogramowania (również w postaci raportów z wykresami czasowymi), oraz dawać możliwość zapisywania statusu instalacji do pliku MIF 8. System musi umożliwiać dystrybucją oprogramowania w trybie wymaganym, opcjonalnym lub na prośbę użytkownika 9. System musi umożliwiać funkcjonalność samoobsługowego portalu z katalogiem aplikacji do instalacji przez użytkownika 15

10. System musi dawać możliwość automatycznego restartu komputera, na którym była przeprowadzana instalacja oraz opcji do anulowania lub opóźnienia tego restartu przez użytkownika 11. System musi dawać możliwość integracji dostępnych zadań dystrybucji (pakietów instalacyjnych) z obsługą oprogramowania systemów Windows (dostępne do instalacji pakiety muszą się pojawiać w Panelu Sterowania w sekcji Dodaj/Usuń Programy, w części Dodaj Nowe Programy) 12. System musi posiadać narzędzia pozwalające na przeskanowanie stacji roboczych pod kątem zainstalowanych poprawek dla systemów operacyjnych Windows oraz dostarczać narzędzia dla innych producentów oprogramowania (ISVs) w celu przygotowania reguł skanujących i zestawów poprawek 13. System musi posiadać możliwość instalacji wielu poprawek jednocześnie bez konieczności restartu komputera w trakcie instalacji kolejnych poprawek 14. System musi udostępniać informacje o aktualizacjach systemów operacyjnych Windows dostępnych na stronach producenta (Windows Update) oraz informacje o postępie instalacji tych aktualizacji na stacjach roboczych (również w postaci raportów). System musi również umożliwiać skanowanie i inwentaryzację poprawek, które były już instalowane wcześniej niezależnie od źródła dystrybucji 15. System musi umożliwiać instalację lub aktualizację systemu operacyjnego ze zdefiniowanego wcześniej obrazu, wraz z przeniesieniem danych użytkownika (profil) 16. Przy przenoszeniu danych użytkownika, muszą one na czas migracji być składowane w specjalnym, chronionym (zaszyfrowanym) zasobie 17. System musi zawierać wszystkie narzędzia do sporządzenia, modyfikacji i dystrybucji obrazów na dowolny komputer, również taki, na którym nie ma żadnego systemu operacyjnego (bare metal) 18. System musi być zintegrowany z oprogramowaniem antywirusowym i być zarządzany przy pomocy jednej wspólnej konsoli do zarządzania. VI. Definiowanie i sprawdzanie standardu komputera: 1. System musi posiadać komponenty umożliwiające zdefiniowanie i okresowe sprawdzanie standardu komputera, standard ten musi być określony zestawem reguł sprawdzających definiowanych z poziomu konsoli administracyjnej, 2. Reguły muszą sprawdzać następujące elementy systemy komputerowego: a/ stan usługi (Windows Service) b/ obecność poprawek (Hotfix) c/ WMI d/ rejestr systemowy e/ system plików f/ Active Directory g/ SQL (query) h/ IIS Metabase 16

3. Dla reguł sprawdzających system musi dawać możliwość wprowadzenia wartości poprawnej, która byłaby wymuszana w przypadku odstępstwa lub wygenerowania alertu administracyjnego w sytuacji, kiedy naprawa nie jest możliwa. VII. Raportowanie, prezentacja danych: 1. System musi posiadać komponent raportujący oparty o technologie webową (wydzielony portal z raportami) i/lub 2. Wykorzystujący mechanizmy raportujące dostarczane wraz z silnikami bazodanowymi, np. SQL Reporting Services 3. System musi posiadać predefiniowane raport w następujących kategoriach: a/ Sprzęt (inwentaryzacja) b/ Oprogramowanie (inwentaryzacja) c/ Oprogramowanie (wykorzystanie) d/ Oprogramowanie (aktualizacje, w tym system operacyjny) 4. System musi umożliwiać budowanie stron z raportami w postaci tablic (dashboard), na których może znajdować się więcej niż jeden raport 5. System musi posiadać konsolę administratora, w postaci programu do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu 6. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym: a/konfigurację granic systemu zarządzania b/ konfigurację komponentów systemu zarządzania c/ konfigurację metod wykrywania stacji roboczych, użytkowników i grup d/ konfigurację metod instalacji klienta e/ konfiguracje komponentów klienta f/ grupowanie stacji roboczych (statyczne, dynamiczne na podstawie zinwentaryzowanych parametrów) g/ konfiguracje zadań dystrybucji, pakietów instalacyjnych, itp h/ konfigurację reguł wykorzystania oprogramowania i/ konfigurację zapytań (query) do bazy danych systemu j/ konfiguracje raportów k/ podgląd zdarzeń oraz zdrowia komponentów systemu. VIII. Analiza działania systemu, logi, komponenty 1. Konsola systemu musi dawać dostęp do podstawowych logów obrazujących pracę poszczególnych komponentów, wraz z oznaczaniem stanu (OK, ostrzeżenie, błąd) w przypadku znalezienia zdarzeń wskazujących na problemy 17 2. Konsola systemu musi umożliwiać podgląd na stan poszczególnych usług wraz z podstawowymi informacjami o stanie usługi, np. ilość wykorzystywanego miejsca na dysku twardym, itp...

System kliencki zarządzania maszynami wirtualnymi musi spełniać następujące wymagania: System zarządzania środowiskami wirtualnymi musi posiadać następujące cechy: I. Architektura 1. System zarządzania środowiskiem wirtualnym musi składać się z: a/ serwera zarządzającego, b/ relacyjnej bazy danych przechowującej informacje o zarządzanych elementach, c/ konsoli, instalowanej na komputerach operatorów, d/ portalu self-service (konsoli webowej) dla operatorów departamentowych, e/ biblioteki, przechowującej komponenty niezbędne do budowy maszyn wirtualnych, f/ agenta instalowanego na zarządzanych hostach wirtualizacyjnych, g/ konektora do systemu monitorującego pracę hostów i maszyn wirtualnych. 2. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu fail-over). II. Interfejs użytkownika 1. Konsola musi umożliwiać wykonywanie codziennych zadań związanych z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny. 2. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień poszczególnym operatorom do grup hostów. 3. Widoki hostów i desktopów wirtualnych musi mieć możliwość zakładania filtrów, pokazując tylko odfiltrowane elementy, np. maszyny wyłączone, maszyny z systemem operacyjnym X, itp... 4. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać stan, ilość alokowanej pamięci i dysku twardego, system operacyjny, platformę wirtualizacyjną, stan ostatniego zadania, oraz wykres utylizacji procesora i podgląd na pulpit. 5. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem zakończenia poszczególnych etapów i całych zadań. III. Scenariusze i zadania 1. Predefiniowane elementy muszą być przechowywane w bibliotece systemu zarządzania. 2. System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy zarządzanymi hostami: a/ w trybie migracji on-line bez przerywania pracy, b/ w trybie migracji off-line z zapisem stanu maszyny 3. System musi umożliwiać automatyczne, równomierne rozłożenie obciążenia pomiędzy zarządzanymi hostami. 4. System musi umożliwiać wyłączenie hosta, gdy jego zasoby nie są konieczne do pracy, w celu oszczędności energii. System powinien również umożliwiać ponowne włączenie takiego hosta. 18

5. System musi umożliwiać przełączenie wybranego hosta w tryb maintenance w przypadku wystąpienia awarii lub w celu przeprowadzenia planowanych prac serwisowych. Uruchomienie tego trybu musi skutkować migracją maszyn na inne hosty lub zapisaniem ich stanu. IV. Wymagania dodatkowe 1. System musi dawać operatorowi możliwość implementacji migracji on-line w sposób automatyczne bez potrzeby każdorazowego potwierdzania. 2. System musi kreować raporty z działania zarządzanego środowiska, w tym: a/ utylizacja poszczególnych hostów, b/ trend w utylizacji hostów, c/ alokacja zasobów na centra kosztów, 3. System musi umożliwiać skorzystanie z szablonów wirtualnych maszyn. 1.5.2.2. Pakiet administrowania stacjami klienckimi z prawem do uaktualniania (licencja na stację roboczą) Oprogramowanie do administrowania urządzeniami klienckimi Licencje na oprogramowanie muszą być przypisane do każdego środowiska systemu operacyjnego lub każdego użytkownika i uprawniać do uruchomienia wymaganych serwerów zarządzających wraz z dedykowaną bazą danych. System musi obejmować moduły: 1) System zarządzania incydentami i problemami 2) System monitorowania stacji roboczych 3) System tworzenia kopii zapasowych 4) System automatyzacji zadań administracyjnych. System zarządzania incydentami i problemami - musi spełniać następujące wymagania: 1. System musi posiadać rozwiązanie help-deskowe umożliwiające użytkownikom zgłaszanie problemów technicznych oraz zapotrzebowanie na zasoby IT (nowy komputer, nowa maszyna wirtualna, ) 2. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane i definiowane mechanizmy w ramach przyjętej metodyki (np. MOF czy ITIL) na zarządzanie incydentami i problemami oraz zarządzanie zmianą. 3. System musi posiadać bazę wiedzy (CMDB) automatycznie zasilaną z takich systemów jak: usługa katalogowa, system monitorujący, system do zarządzania desktopami. 4. System musi udostępniać narzędzia efektywnego zarządzania dostępnością usług, umożliwiających dostarczenie użytkownikom systemów SLA na wymaganym poziomie. 5. System, poprzez integrację z systemami zarządzania i monitorowania musi zapewniać: a/ Optymalizację procesów i ich prawidłową realizację poprzez predefiniowane scenariusze, zgodne z najlepszymi praktykami i założoną metodyką, 19

b/ Redukcję czasu rozwiązywania problemów z działaniem systemów poprzez zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego poziomu linii wsparcia, c/ Automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie zdarzeń w różnych komponentach systemu, d/ Wspomaganie procesów podejmowania decyzji poprzez integrację informacji i logikę ich powiązania, e/ Planowanie działań prewencyjnych poprzez kolekcjonowanie informacji o zachowaniach systemu w przypadku incydentów, f/ Raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz usprawnień procesów ich opieki serwisowej, g/ Tworzenie baz wiedzy na temat rozwiązywania problemów, h/ Automatyzację działań w przypadku znanych i opisanych problemów, i/ Wykrywanie odchyleń od założonych standardów ustalonych dla systemu. System monitorowania stacji roboczych I. Architektura 1. Serwery zarządzające muszą mieć możliwość publikowania informacji o uruchomionych komponentach w usługach katalogowych, informacje te muszą być odstępne dla klientów systemu w celu automatycznej konfiguracji. 2. Możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych grup komputerów/usług. 3. System uprawnień musi być oparty o role (role based security), użytkownicy i grupy użytkowników w poszczególnych rolach powinny być pobierane z usług katalogowych. 4. Możliwość definiowania użytkowników do wykonywania poszczególnych zadań na klientach i serwerze zarządzającym, w tym zdefiniowany użytkownik domyślny. 5. Możliwość uwierzytelnianie klientów na serwerze zarządzającym przy pomocy certyfikatów w standardzie X.509, z możliwością odrzucania połączeń od klientów niezaakceptowanych. 6. Kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym musi być szyfrowany. 7. Możliwość budowania systemu w oparciu o łącza publiczne - Internet (bez konieczności wydzielania kanałów VPN). 8. Wsparcie dla protokołu IPv6. 9. System musi udostępniać funkcje autodiagnostyczne, w tym: monitorowanie stanu klientów, możliwość automatycznego lub administracyjnego restartu klienta, możliwość reinstalacji klienta. II. Audyt zdarzeń bezpieczeństwa System musi udostępniać komponenty i funkcje pozwalające na zbudowanie systemu zbierającego zdarzenia związane z bezpieczeństwem monitorowanych systemów i gwarantować: 1. Przekazywanie zdarzeń z podległych klientów w czasie prawie rzeczywistym (dopuszczalne opóźnienia mogą pochodzić z medium transportowego sieć, oraz komponentów zapisujących i odczytujących). 2. Niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń przed wysłaniem, definicja schematu powinna być definiowana w pliku XML z możliwością dodawania i modyfikacji. 20 3. Obsługę co najmniej 2500 zdarzeń/sek w trybie ciągłym i 100000 zdarzeń/sek w trybie burst