Platforma wiedzy I konsultacji system wsparcia dialogu społecznego



Pobieranie 400,08 Kb.
Strona5/6
Data24.10.2017
Rozmiar400,08 Kb.
1   2   3   4   5   6

Licencje dostępowe do Serwera Portalu (licencja na użytkownika)


Licencje umożliwiające użytkownikom wykorzystanie opisanej funkcjonalności serwera portalu wielofunkcyjnego.

      1. Serwer Relacyjnej Bazy Danych (licencja na 2 rdzenie procesora)


System bazodanowy (SBD) musi spełniać następujące wymagania poprzez wbudowane mechanizmy:

  1. Możliwość wykorzystania SBD jako silnika relacyjnej bazy danych, analitycznej, wielowymiarowej bazy danych, platformy bazodanowej dla wielu aplikacji. Powinien zawierać serwer raportów, narzędzia do: definiowania raportów, wykonywania analiz, tworzenia procesów ETL.

  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.

  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:

  • bez specjalnego sprzętu (rozwiązanie tylko programowe oparte o sam SBD),

  • niezawodne powielanie danych w czasie rzeczywistym (potwierdzone transakcje bazodanowe),

  • klienci bazy danych automatycznie korzystają z bazy zapasowej w przypadku awarii bazy podstawowej bez zmian w aplikacjach,

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

  2. Możliwość zastosowania reguł bezpieczeństwa obowiązujących w przedsiębiorstwie - wsparcie dla zdefiniowanej w przedsiębiorstwie 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.

  3. 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ść.

  4. 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ń:

  • odczyt/zapis danych na dysku dla zapytań wykonywanych do baz danych (w celu wychwytywania zapytań znacząco obciążających system),

  • wykonanie zapytania lub procedury trwające dłużej niż zdefiniowany czas (wychwytywanie długo trwających zapytań lub procedur),

  • para zdarzeń zablokowanie/zwolnienie blokady na obiekcie bazy (w celu wychwytywania długotrwałych blokad obiektów bazy).

  1. 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 powinny zajmować minimalny obszar pamięci.

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

  3. Wsparcie dla technologii XML - SBD musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. W szczególności musi:

  • udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli,

  • udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD,

  • udostępniać język zapytań do struktur XML,

  • udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie i modyfikację zawartości struktur XML),

  • udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań.

  1. Wsparcie dla danych przestrzennych - SBD musi zapewniać wsparcie dla geometrycznych i geograficznych typów danych pozwalających w prosty sposób przechowywać i analizować informacje o lokalizacji obiektów, dróg i innych punktów orientacyjnych zlokalizowanych na kuli ziemskiej, a w szczególności:

  • zapewniać możliwość wykorzystywania szerokości i długości geograficznej do opisu lokalizacji obiektów,

  • oferować wiele metod, które pozwalają na łatwe operowanie kształtami czy bryłami, testowanie ich wzajemnego ułożenia w układach współrzędnych oraz dokonywanie obliczeń takich wielkości, jak pola figur, odległości do punktu na linii, itp.,

  • obsługa geometrycznych i geograficznych typów danych powinna być dostępna z poziomu języka zapytań do systemu SBD,

  • typy danych geograficznych powinny być konstruowane na podstawie obiektów wektorowych, określonych w formacie Well-Known Text (WKT) lub Well-Known Binary (WKB), (powinny być to m.in. takie typy obiektów jak: lokalizacja (punkt), seria punktów, seria punktów połączonych linią, zestaw wielokątów, itp.).

  1. 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 powinien umożliwiać tworzenie w tych językach m.in. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo powinien udostępniać środowisko do debuggowania.

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

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

  4. Raportowanie zależności między obiektami - SBD musi udostępniać informacje o wzajemnych zależnościach między obiektami bazy danych.

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

  6. System transformacji danych - SBD musi posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to powinno pozwalać na przygotowanie definicji transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub
    z asystą operatora. Transformacje powinny posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom. Powinna być także zapewniona możliwość tworzenia własnych transformacji. Środowisko tworzenia transformacji danych powinno udostępniać m.in.:

  • mechanizm debuggowania tworzonego rozwiązania,

  • mechanizm stawiania „pułapek” (breakpoints),

  • mechanizm logowania do pliku wykonywanych przez transformację operacji,

  • możliwość wznowienia wykonania transformacji od punktu, w którym przerwano jej wykonanie (np. w wyniku pojawienia się błędu),

  • możliwość cofania i ponawiania wprowadzonych przez użytkownika zmian podczas edycji transformacji (funkcja undo/redo)

  • 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),

  • mechanizm automatyzacji publikowania utworzonych transformacji na serwerze bazy danych (w szczególności tworzenia wersji instalacyjnej pozwalającej automatyzować proces publikacji na wielu serwerach),

  • 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,

  • mechanizm mapowania kolumn wykorzystujący ich nazwę i typ danych do automatycznego przemapowania kolumn w sytuacji podmiany źródła danych.

  1. Wbudowany system analityczny - SBD musi posiadać moduł pozwalający na tworzenie rozwiązań służących do analizy danych wielowymiarowych (kostki OLAP). Powinno być możliwe tworzenie: wymiarów, miar. Wymiary powinny mieć możliwość określania dodatkowych atrybutów będących dodatkowymi poziomami agregacji. Powinna być możliwość definiowania hierarchii w obrębie wymiaru. Przykład: wymiar Lokalizacja Geograficzna. Atrybuty: miasto, gmina, województwo. Hierarchia: Województwo->Gmina.

  2. 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 powinny 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 powinna być dostępna możliwość drążenia danych
    z kostki do poziomu rekordów szczegółowych z bazy relacyjnych (drill to detail).

  3. Wbudowany system analityczny musi pozwalać na dodanie akcji przypisanych do elementów kostek wielowymiarowych (np. pozwalających na przejście użytkownika do raportów kontekstowych lub stron www powiązanych z przeglądanym obszarem kostki).

  4. Wbudowany system analityczny powinien posiadać narzędzie do rejestracji i śledzenia zapytań wykonywanych do baz analitycznych.

  5. Wbudowany system analityczny powinien obsługiwać wielojęzyczność (tworzenie obiektów wielowymiarowych w wielu językach – w zależności od ustawień na komputerze klienta).

  6. Wbudowany system analityczny musi udostępniać rozwiązania Data Mining, m.in.: algorytmy reguł związków (Association Rules), szeregów czasowych (Time Series), drzew regresji (Regression Trees), sieci neuronowych (Neural Nets oraz Naive Bayes). Dodatkowo system powinien udostępniać narzędzia do wizualizacji danych z modelu Data Mining oraz język zapytań do odpytywania tych modeli.

  7. System analityczny powinien pozwalać na dodawanie własnych algorytmów oraz modułów wizualizacji modeli Data Mining.

  8. Tworzenie głównych wskaźników wydajności KPI (Key Performance Indicators - kluczowe czynniki sukcesu) - SBD musi udostępniać użytkownikom możliwość tworzenia wskaźników KPI (Key Performance Indicators) na podstawie danych zgromadzonych w strukturach wielowymiarowych. W szczególności powinien pozwalać na zdefiniowanie takich elementów, jak: wartość aktualna, cel, trend, symbol graficzny wskaźnika w zależności od stosunku wartości aktualnej do celu.

  9. System raportowania - SBD musi posiadać możliwość definiowania i generowania raportów. Narzędzie do tworzenia raportów powinno pozwalać na ich graficzną definicję. Raporty powinny być udostępnianie przez system protokołem HTTP (dostęp klienta za pomocą przeglądarki), bez konieczności stosowania dodatkowego oprogramowania po stronie serwera. Dodatkowo system raportowania powinien obsługiwać:

  • raporty parametryzowane,

  • cache raportów (generacja raportów bez dostępu do źródła danych),

  • cache raportów parametryzowanych (generacja raportów bez dostępu do źródła danych, z różnymi wartościami parametrów),

  • współdzielenie predefiniowanych zapytań do źródeł danych,

  • wizualizację danych analitycznych na mapach geograficznych (w tym import map
    w formacie ESRI Shape File),

  • możliwość opublikowania elementu raportu (wykresu, tabeli) we współdzielonej bibliotece, z której mogą korzystać inni użytkownicy tworzący nowy raport,

  • możliwość wizualizacji wskaźników KPI,

  • możliwość wizualizacji danych w postaci obiektów sparkline.

  1. Środowisko raportowania powinno być osadzone i administrowane z wykorzystaniem mechanizmu Web Serwisów (Web Services).

  2. 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 powinny być eksportowane w formacie Atom data feeds, które można będzie wykorzystać, jako źródło danych w innych aplikacjach.

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

  4. SBD musi umożliwiać wysyłkę raportów drogą mailową w wybranym formacie (subskrypcja).

  5. 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. Oprogramowanie zarządzania i monitoringu (licencja na 2 procesory)


Licencja oprogramowania zarządzania i monitoringu musi być przypisana do każdego procesora fizycznego na serwerze zarządzanym. Oprogramowanie musi być licencjonowane na minimum 2 fizyczne procesory serwera zarządzanego. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Każda licencja na 2 fizyczne procesory serwera musi uprawniać do zarządzania minimum 2 środowiskami systemu operacyjnego na tym serwerze.

Zarządzanie serwerem musi obejmować wszystkie funkcje zawarte w opisanych poniżej modułach:



  • System zarządzania infrastrukturą i oprogramowaniem

  • System zarządzania komponentami

  • System zarządzania środowiskami wirtualnym

  • System tworzenia kopii zapasowych

  • System automatyzacji zarządzania środowisk IT

  • System zarządzania incydentami i problemami

  • Ochrona antymalware


System zarządzania infrastrukturą i oprogramowaniem

System zarządzania infrastrukturą i oprogramowaniem musi spełniać następujące wymagania poprzez wbudowane mechanizmy, bez użycia dodatkowych aplikacji.



  1. Inwentaryzacja i zarządzanie zasobami:

  1. Inwentaryzacja zasobów serwera powinna się odbywać w określonych przez administratora systemu interwałach czasowych. System powinien mieć możliwość odrębnego planowania inwentaryzacji sprzętu i oprogramowania

  2. Inwentaryzacja sprzętu powinna się odbywać przez pobieranie informacji z interfejsu WMI, komponent inwentaryzacyjny powinien mieć możliwość konfiguracji w celu ustalenia informacji, o jakich podzespołach będą przekazywane do systemu

  3. Inwentaryzacja oprogramowania powinna skanować zasoby dyskowe 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…)

  4. System powinien posiadać własną bazę dostępnego na rynku komercyjnego oprogramowania, pozwalającą na identyfikację zainstalowanego i użytkowanego oprogramowania.
    System powinien dawać możliwość aktualizacji tej bazy przy pomocy konsoli administratora oraz automatycznie przez aktualizacje ze stron producenta

  5. Informacje inwentaryzacyjne powinny być przesyłane przy pomocy plików różnicowych w celu ograniczenia ruchu z agenta do serwera

  1. Użytkowane oprogramowanie – pomiar wykorzystania

  1. System powinien mieć możliwość zliczania uruchomionego oprogramowania w celu śledzenia wykorzystania

  2. Reguły dotyczące monitorowanego oprogramowania powinny być tworzone automatycznie przez skanowanie oprogramowania uruchamianego.

  1. System powinien dostarczać funkcje dystrybucji oprogramowania, dystrybucja i zarządzania aktualizacjami, instalacja/aktualizacja systemów operacyjnych.

  2. Definiowanie i sprawdzanie standardu serwera:

  1. System powinien posiadać komponenty umożliwiające zdefiniowanie i okresowe sprawdzanie standardu serwera, standard ten powinien być określony zestawem reguł sprawdzających definiowanych z poziomu konsoli administracyjnej,

  2. Reguły powinny sprawdzać następujące elementy systemy komputerowego:

  • stan usługi (Windows Service)

  • obecność poprawek (Hotfix)

  • WMI

  • rejestr systemowy

  • system plików

  • Active Directory

  • SQL (query)

  • Metabase

  1. Raportowanie, prezentacja danych:

  1. System powinien 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 powinien posiadać predefiniowane raport w następujących kategoriach:

  • Sprzęt (inwentaryzacja)

  • Oprogramowanie (inwentaryzacja)

  • Oprogramowanie (wykorzystanie)

  • Oprogramowanie (aktualizacje, w tym system operacyjny)

  1. System powinien umożliwiać budowanie stron z raportami w postaci tablic (dashboard), na których może znajdować się więcej niż jeden raport

  2. System powinien posiadać konsolę administratora, w postaci programu do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu

  1. Analiza działania systemu, logi, komponenty

  1. Konsola systemu powinna dawać dostęp do podstawowych logów obrazujących pracę poszczególnych komponentów, wraz z oznaczaniem stanu (OK, Warning, Error)
    w przypadku znalezienia zdarzeń wskazujących na problemy

  2. Konsola systemu powinna 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.


System zarządzania komponentami

System zarządzania komponentami musi udostępniać funkcje pozwalające na budowę bezpiecznych


i skalowalnych mechanizmów zarządzania komponentami IT spełniając następujące wymagania:

  1. Architektura

  1. Serwery zarządzające muszą mieć możliwość publikowania informacji o uruchomionych komponentach w usługach katalogowych, informacje te powinny 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. 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 powinien 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 powinien udostępniać funkcje autodiagnostyczne, w tym: monitorowanie stanu klientów, możliwość automatycznego lub administracyjnego restartu klienta, możliwość reinstalacji klienta.

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

  3. Obsługę co najmniej 2500 zdarzeń/sek w trybie ciągłym i 100000 zdarzeń/sek w trybie „burst” – chwilowy wzrost ilości zdarzeń, jeden kolektor zdarzeń powinien obsługiwać, co najmniej 100 kontrolerów domen (lub innych systemów autentykacji i usług katalogowych) lub 1000 serwerów.

  1. Konfiguracja i monitorowanie

System musi umożliwiać zbudowanie jednorodnego środowiska monitorującego, korzystając z takich samych zasad do monitorowania różnych komponentów, a w tym:

  1. Monitorowane obiekty powinny być grupowane (klasy) w oparciu o atrybuty, które można wykryć na klientach systemu w celu autokonfiguracji systemu. Powinny być wykrywane - co najmniej, atrybuty pobierane z:

  • rejestru

  • WMI

  • OLEDB

  • LDAP

  • skrypty (uruchamiane w celu wykrycia atrybutów obiektu),

W definicjach klas powinny być również odzwierciedlone zależności pomiędzy nimi.

  1. Na podstawie wykrytych atrybutów system powinien dokonywać autokonfiguracji klientów, przez wysłanie odpowiadającego wykrytym obiektom zestawu monitorów, reguł, skryptów, zadań, itp.

  2. Wszystkie klasy obiektów, monitory, reguły, skrypty, zadania, itp. elementy służące konfiguracji systemu muszą być grupowane i dostarczane w postaci zestawów monitorujących, system powinien posiadać w standardzie zestawy monitorujące, co najmniej dla:

  • Windows Server 2003/2008/2008R2

  • Active Directory 2003/2008

  • Exchange 2003/2007/2010

  • Microsoft SharePoint 2003/2007/2010

  • Microsoft SharePoint Services 3.0

  • Microsoft SharePoint Foundation 2010

  • SQL 2005/2008/2008R2 (x86/x64/ia64)

  • Windows Client OS (XP/Vista/7)

  • Information Worker (Office, IExplorer, Outlook, itp…)

  • IIS 6.0/7.0/7.5

  • HP-UX 11i v2/v3

  • Sun Solaris 9 (SPARC) oraz Solaris 10 (SPARC i x86)

  • Red Hat Enterprise Linux 4/5/6 (x86/x64) Server

  • Novell SUSE Linux Enterprise Server 9/10SP1/11

  • IBM AIX v5.3 i v6.1/v7.1 (POWER)

  1. System powinien posiadać możliwość monitorowania za pomocą agenta lub bez niego.

  2. System musi pozwalać na wykrycie oraz monitorowanie urządzeń sieciowych (routery, przełączniki sieciowe, itp.) za pomocą SNMP v1, v2c oraz v3. System monitorowania
    w szczególności powinien mieć możliwość zbierania następujących informacji:

  • interfejsy sieciowe

  • porty

  • sieci wirtualne (VLAN)

  • grupy Hot Standby Router Protocol (HSRP)

  1. System zarządzania musi mieć możliwość czerpania informacji z następujących źródeł danych:

  • SNMP (trap, probe)

  • WMI Performance Counters

  • Log Files (text, text CSV)

  • Windows Events (logi systemowe)

  • Windows Services

  • Windows Performance Counters (perflib)

  • WMI Events

  • Scripts (wyniki skryptów, np.: WSH, JSH)

  • Unix/Linux Service

  • Unix/Linux Log

  1. Na podstawie uzyskanych informacji monitor powinien aktualizować status komponentu, powinna być możliwość łączenia i agregowania statusu wielu monitorów

  1. Tworzenie reguł

  1. w systemie zarządzania powinna mieć możliwość czerpania informacji z następujących źródeł danych:

  • Event based (text, text CSV, NT Event Log, SNMP Event, SNMP Trap, syslog, WMI Event)

  • Performance based (SNMP performance, WMI performance, Windows performance)

  • Probe based (scripts: event, performance)

  1. System musi umożliwiać przekazywanie zebranych przez reguły informacji do bazy danych w celu ich późniejszego wykorzystania w systemie, np. raporty dotyczące wydajności komponentów, alarmy mówiące o przekroczeniu wartości progowych czy wystąpieniu niepożądanego zdarzenia.

  2. Reguły zbierające dane wydajnościowe muszą mieć możliwość ustawiania tolerancji na zmiany, w celu ograniczenia ilości nieistotnych danych przechowywanych w systemie bazodanowym. Tolerancja powinna mieć, co najmniej dwie możliwości:

  • na ilość takich samych próbek o takiej samej wartości

  • na procentową zmianę od ostatniej wartości próbki.

  1. Monitory sprawdzające dane wydajnościowe w celu wyszukiwania wartości progowych muszą mieć możliwość – oprócz ustawiania progów statycznych, „uczenia” się monitorowanego parametru w zakresie przebiegu bazowego „baseline” w zadanym okresie czasu.

  2. System musi umożliwiać blokowanie modyfikacji zestawów monitorujących, oraz definiowanie wyjątków na grupy komponentów lub konkretne komponenty w celu ich odmiennej konfiguracji.

  3. System powinien posiadać narzędzia do konfiguracji monitorów dla aplikacji i usług, w tym:

  • ASP .Net Application

  • ASP .Net Web Service

  • OLE DB

  • TCP Port

  • Web Application

  • Windows Service

  • Unix/Linux Service

  • Process Monitoring

Narzędzia te powinny pozwalać na zbudowanie zestawu predefiniowanych monitorów dla wybranej aplikacji i przyporządkowanie ich do wykrytej/działającej aplikacji

  1. System musi posiadać narzędzia do budowania modeli aplikacji rozproszonych (składających się z wielu wykrytych obiektów), pozwalając na agregację stanu aplikacji oraz zagnieżdżanie aplikacji.

  2. Z każdym elementem monitorującym (monitor, reguła, alarm, itp…) powinna być skojarzona baza wiedzy, zawierająca informacje o potencjalnych przyczynach problemów oraz możliwościach jego rozwiązania (w tym możliwość uruchamiania zadań diagnostycznych z poziomu).

  3. System musi zbierać informacje udostępniane przez systemy operacyjne Windows o przyczynach krytycznych błędów (crash) udostępnianych potem do celów analitycznych.

  4. System musi umożliwiać budowanie obiektów SLO (Service Level Object) służących przedstawianiu informacji dotyczących zdefiniowanych poziomów SLA (Service Level Agreement) przynajmniej dla: monitora (dostepność), i licznika wydajności (z agregacją dla wartości – min, max, avg).

  1. Przechowywanie i dostęp do informacji

  1. Wszystkie informacje operacyjne (zdarzenia, liczniki wydajności, informacje o obiektach, alarmy, itp…) powinny być przechowywane w bazie danych operacyjnych.

  2. System musi mieć co najmniej jedną bazę danych z przeznaczeniem na hurtownię danych do celów historycznych i raportowych. Zdarzenia powinny być umieszczane w obu bazach jednocześnie, aby raporty mogłyby być generowane w oparciu o najświeższe dane.

  3. System musi mieć osobną bazę danych, do której będą zbierane informacje na temat zdarzeń security z możliwością ustawienia innych uprawnień dostępu do danych tam zawartych (tylko audytorzy).

  4. System powinien mieć zintegrowany silnik raportujący niewymagający do tworzenia raportów używania produktów firm trzecich. Produkty takie mogą być wykorzystanie w celu rozszerzenia tej funkcjonalności.

  5. System powinien mieć możliwość generowania raportów na życzenie oraz tworzenie zadań zaplanowanych.

  6. System powinien umożliwiać eksport stworzonych raportów przynajmniej do następujących formatów:

  • XML

  • CSV

  • TIFF

  • PDF

  • XLS

  • Web archive

  1. Konsola systemu zarządzania

  1. Konsola systemu musi umożliwiać pełny zdalny dostęp do serwerów zarządzających dając dostęp do zasobów zgodnych z rolą użytkownika korzystającego z konsoli.

  2. System powinien udostępniać dwa rodzaje konsoli:

  • w postaci programu do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu (konsola zdalna)

  • w postaci web’owej dla dostępu do podstawowych komponentów monitorujących
    z dowolnej stacji roboczej (konsola webowa).

  1. Konsola zdalna powinna umożliwiać definiowanie każdemu użytkownikowi własnych widoków, co najmniej w kategoriach:

  • Alerts

  • Events

  • State

  • Performance

  • Diagram

  • Task Status

  • Web Page (dla użytkowników, którzy potrzebują podglądu tylko wybranych elementów systemu).

  1. Konsola musi umożliwiać budowanie widoków tablicowych (dashboard) w celu prezentacji różnych widoków na tym samym ekranie.

  2. Widoki powinny mieć możliwość filtrowania informacji, jakie się na nich znajdą (po typie, ważności, typach obiektów, itp…), sortowania oraz grupowania podobnych informacji, wraz z możliwością definiowania kolumn, jakie mają się znaleźć na widokach „kolumnowych”.

  3. Z każdym widokiem (obiektem w tym widoku) powinno być skojarzone menu kontekstowe, z najczęstszymi operacjami dla danego typu widoku/obiektu.

  4. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym:

  • opcji definiowania ról użytkowników

  • opcji definiowania widoków

  • opcji definiowania i generowania raportów

  • opcji definiowania powiadomień

  • opcji tworzenia, konfiguracji i modyfikacji zestawów monitorujących

  • opcji instalacji/deinstalacji klienta

  1. Konsola musi pozwalać na pokazywanie obiektów SLO (Service Level Object) i raportów SLA (Service Level Agreement) bez potrzeby posiadania konsoli i dostępu do samego systemu monitorującego, na potrzeby użytkowników.

  1. Wymagania dodatkowe

  1. System musi dostarczać API lub inny system (web service, connector) z publicznie dostępną dokumentacją pozwalający m.in. na:

  • Budowanie konektorów do innych systemów, np. help-desk w celu przekazywania zdarzeń czy alarmów (dwukierunkowo),

  • Wykonywanie operacji w systemie z poziomu linii poleceń,

  • Podłączenie rozwiązań firm trzecich pozwalających na monitorowanie w jednolity sposób systemów informatycznych niewspieranych natywnie przez system zarządzania,

  • Podłączenie do aplikacji biurowych pozwalające na integrację statycznych modeli (np. diagramów Visio) z monitorowanymi obiektami, pozwalające na wyswietlanie ich stanu na diagramie,


System zarządzania środowiskami wirtualnym

System zarządzania środowiskami wirtualnymi musi posiadać następujące cechy:



  1. Architektura

  1. System zarządzania środowiskiem wirtualnym powinien składać się z:

  • serwera zarządzającego,

  • relacyjnej bazy danych przechowującej informacje o zarządzanych elementach,

  • konsoli, instalowanej na komputerach operatorów,

  • portalu self-service (konsoli webowej) dla operatorów „departamentowych”,

  • biblioteki, przechowującej komponenenty niezbędne do budowy maszyn wirtualnych,

  • agenta instalowanego na zarządzanych hostach wirtualizacyjnych,

  • „konektora” do systemu monitorującego pracę hostów i maszyn wirtualnych.

  1. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu fail-over).

  2. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi co najmniej trzech różnych dostawców.

  1. Interfejs użytkownika

  1. Konsola musi umożliwiać wykonywanie codziennych zadań związnych z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny.

  2. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień posczególnym operatorom do grup hostów.

  3. Widoki hostów i maszyn wirtualnych powinny 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ń.

  1. Scenariusze i zadania

  1. Tworzenie maszyn wirtualnych – system musi umożliwiać stworzenie maszyny wirtualnej w co najmniej dwóch trybach:

  1. Ad hoc – gdzie wszystkie elementy są wybierane przez operatora podczas tworzenia maszyny,

  2. Nadzorowany – gdzie operator tworzy maszynę korzystając z gotowego wzorca (template), a wzorzec składa się z przynajmniej 3-ech elementów składowych:

  • profilu sprzętowego,

  • profilu systemu operacyjnego,

  • przygotowanych dysków twardych,

  1. Predefiniowane elementy muszą być przechowywane w bibliotece systemu zarządzania.

  2. System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy zarządzanymi hostami:

  • w trybie migracji „on-line” – bez przerywania pracy,

  • w trybie migracji „off-line – z zapisem stanu maszyny

  1. System musi umożliwiać automatyczne, równomierne rozłożenie obciążenia pomiędzy zarządzanymi hostami.

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

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

  4. System musi posiadać możliwość konwersji maszyny fizycznej do wirtualnej.

  5. System misi posiadać (bez potrzeby instalowania dodatkowego oprogramowania) - możliwość wykrycia maszyny fizycznej w sieci i instalacje na niej systemu operacyjnego wraz z platformą do wirtualizacji.

  1. Wymagania dodatkowe

  1. System musi informować operatora o potrzebie migracji maszyn, jeśli wystąpią nieprawidłowe zdarzenia na hoście lub w innych maszynach wirtualnych mające wpływ na ich pracę, np. awarie sprzętu, nadmierna utylizacja współdzielonych zasobów przez jedną maszynę.

  2. System musi dawać operatorowi możliwość implementacji w/w migracji w sposób automatyczne bez potrzeby każdorazowego potwierdzania.

  3. System musi kreować raporty z działania zarządzanego środowiska, w tym:

  • utylizacja poszczególnych hostów,

  • trend w utylizacji hostów,

  • alokacja zasobów na centra kosztów,

  • utylizacja poszczególnych maszyn wirtualnych,

  • komputery-kandydaci do wirtualizacji

  1. System musi umożliwiać skorzystanie z szablonów:

  • wirtualnych maszyn

  • usług

oraz profili dla:

  • aplikacji

  • serwera SQL

  • hosta

  • sprzętu

  • systemu operacyjnego gościa

  1. System musi umożliwiać tworzenie chmur prywatnych na podstawie dostępnych zasobów (hosty, sieci, przestrzeń dyskowa, biblioteki zasobów).

  2. System musi posiadać możliwość przygotowania i instalacji zwirtualizowanej aplikacji serwerowej.

  3. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji (poprzez automatyczne dodanie wirtualnej maszyny z aplikacją)


System tworzenia kopii zapasowych

System tworzenia i odtwarzania kopii zapasowych danych (backup) wykorzystujący scenariusze tworzenia kopii na zasobach dyskowych lub taśmowych musi spełniać następujące wymagania:



  1. System musi składać się z:

  1. serwera zarządzającego kopiami zapasowymi i agentami kopii zapasowych

  2. agentów kopii zapasowych instalowanych na komputerach zdalnych

  3. konsoli zarządzającej

  4. relacyjnej bazy danych przechowującej informacje o zarządzanych elementach

  5. wbudowany mechanizm raportowania i notyfikacji poprzez pocztę elektroniczną

  6. System kopii zapasowych musi wykorzystywać mechanizm migawkowych kopii – VSS (Volume ShadowCopy Service)

  1. System kopii zapasowych musi umożliwiać:

  1. zapis danych na puli magazynowej złożonej z dysków twardych

  2. zapis danych na bibliotekach taśmowych

  1. System kopii zapasowych musi umożliwiać zdefiniowanie ochrony zasobów krótkookresowej
    i długookresowej.

  2. System kopii zapasowych musi posiadać kopie danych produkcyjnych w swojej puli magazynowej.

  3. Dane przechowywane w puli magazynowej muszą używać mechanizmów oszczędzających wykorzystane miejsce dyskowe, takie jak pojedyncza instancja przechowywania.

  4. System kopii zapasowych powinien w przypadku wykonywania pełnej kopii zapasowej kopiować jedynie te bloki, które uległy zmianie od ostatniej pełnej kopii.

  5. System kopii zapasowych powinien umożliwiać przywrócenie:

  1. danych plikowych

  2. danych aplikacyjnych

  3. stanu systemu (Systemstate)

  4. obrazu systemu operacyjnego (tzw. Bare Metal Restore)

  1. System kopii zapasowej podczas wykonywania pełnej kopii zapasowej musi uaktualniać chronione dane o dodatkowy punkt przywracania danych, minimalizując ilość przesyłanych danych

  2. System kopii zapasowych musi umożliwiać rozwiązanie automatycznego przenoszenia chronionych danych do zdalnej lokalizacji, wykorzystując przy tym mechanizm regulacji maksymalnej przepustowości

  3. Agenci systemu kopii zapasowych muszą posiadać konfiguracje dotyczącą zdefiniowania godzin pracy, a także dostępnej przepustowości w czasie godzin pracy i poza godzinami pracy

  4. System kopii zapasowych musi rozpoznawać aplikacje:

  1. ze względu na tworzone logi transakcyjne:

  • Microsoft Exchange Server

  • Microsoft Office Sharepoint Server

  • Microsoft SQL Server

  1. ze względu na zapewnienie nieprzerwalności pracy

  • Microsoft Virtual Server 2005

  • Microsoft Hyper-V server

  1. Komunikacja z serwerem kopii zapasowych musi odbywać się po jawnie zdefiniowanych portach

  2. Konsola powinna umożliwiać wykonywanie tworzenie określonych harmonogramów wykonywania kopii zapasowych na chronionych agentach

  3. Konsola powinna umożliwiać grupowanie chronionych zasobów ze względu na typy chronionych zasobów

  4. Zarządzanie agentami i zadaniami kopii zapasowych powinno być możliwe również za pomocą linii poleceń

  5. System kopii zapasowych musi umożliwiać odzyskanie chronionych zasobów plikowych przez użytkownika końcowego z poziomu zakładki „Poprzednie wersje”

  6. Konsola powinna posiadać mechanizm kontrolowania wykonywanych zadań kopii zapasowych

  7. Konsola powinna posiadać mechanizm notyfikacji administratorów odnośnie zdarzeń
    w systemie kopii zapasowych

  8. Konsola powinna posiadać wbudowany system raportujący (m.in. raporty dotyczące zużycia puli magazynowej, wykonania kopii zapasowych, itp.).

  9. System kopii zapasowych musi umożliwiać przechowywanie danych w puli magazynowej min. 1 rok

  10. System kopii zapasowych musi umożliwiać synchronizacje przechowywanych kopii zapasowych (kopie inkrementalne) z produkcyjnymi transakcyjnymi bazami danych (bazy danych, portale intranetowe) na poziomie poniżej 30 minut. Kopie te muszą być tworzone
    w ciągu godzin pracy, w niezauważalny dla użytkowników końcowych sposób.

  11. System kopii zapasowych musi umożliwiać odtworzenie dowolnego 30 minutowego kwantu czasu dla krytycznych aplikacji, takich jak bazy transakcyjne, portale intranetowe.

  12. System kopii zapasowych musi umożliwiać odtworzenie danych do:

  1. lokalizacji oryginalnej

  2. lokalizacji alternatywnej

  3. w przypadku drugiego serwera kopii zapasowych (w centrum zapasowym) do pierwszego serwera kopii zapasowych


System automatyzacji zarządzania środowisk IT

System automatyzacji zarządzania środowisk IT musi udostępniać bezskryptowe środowisko standaryzujące i automatyzujące zarządzanie środowiskiem IT na bazie najlepszych praktyk.



  1. System musi umożliwiać testowanie sytuacji krytycznych i występowanie różnych incydentów w systemie.

  2. System musi wspomagać automatyzację procesów zarządzania zmianami konfiguracji środowisk IT.

  3. System musi wspomagać planowanie i automatyzację wdrażania poprawek.

  4. System musi umożliwiać zarządzanie życiem środowisk wirtualnych.

  5. System musi udostępniać mechanizmy workflow automatyzujące zadania administracyjne wraz graficznym interfejsem projektowania, budowy i monitorowania worklow.

  6. Wbudowane konektory zapewniające integrację narzędzi Microsoft System Center, HP OpenView, IBM Tivoli i BMC Patrol do zarządzania oprogramowaniem i sprzętem.

  7. Wbudowane (gotowe) workflow, takie jak:

  • Active Directory Password Reset

  • Microsoft Cluster Patching

  • Microsoft SQL Server Cluster Patching

  • Microsoft SQL: Server Dump Copy Load

  • Operations Manager Event Remediation

  • Operations Manager Event Remediation and Enrichment

  • Operations Manager Service Alert Testing

  • VM Provisioning

  • Working with FTP

  • Operations Manager Tool Integration

  • Operations Manager: Manager of Managers

  • Operations Manager: Maintenance Windows

  • Active Directory: New Employee Onboarding

  • Operations Manager: Multi-Service Desk Integration


System zarządzania incydentami i problemami

System zarządzania incydentami i problemami musi spełniać następujące wymagania:



  1. System powinien posiadać rozwiązanie help-deskowe umożliwiające użytkownikom zgłaszanie problemów technicznych oraz zapotrzebowanie na zasoby IT (np. 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 powinien 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ć:

  • Optymalizację procesów i ich prawidłową realizację poprzez predefiniowane scenariusze, zgodne z najlepszymi praktykami i założoną metodyką,

  • Redukcję czasu rozwiązywania problemów z działaniem systemów poprzez zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego poziomu linii wsparcia,

  • Automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie zdarzeń
    w różnych komponentach systemu,

  • Wspomaganie procesów podejmowania decyzji poprzez integrację informacji i logikę ich powiązania,

  • Planowanie działań prewencyjnych poprzez kolekcjonowanie informacji o zachowaniach systemu w przypadku incydentów,

  • Raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz usprawnień procesów ich opieki serwisowej,

  • Tworzenie baz wiedzy na temat rozwiązywania problemów,

  • Automatyzację działań w przypadku znanych i opisanych problemów,

  • Wykrywanie odchyleń od założonych standardów ustalonych dla systemu.


Ochrona antymalware

Oprogramowanie antymalware musi spełniać następujące wymagania:



  1. Ochrona przed zagrożeniami typu wirusy, robaki, Trojany, rootkity, ataki typu phishing czy exploity zero-day.

  2. Centralne zarządzanie ochroną serwerów poprzez konsolę System zarządzania infrastrukturą i oprogramowaniem

  3. Centralne zarządzanie politykami ochrony.

  4. Automatyzacja wdrożenia i wymiany dotychczasowych agentów ochrony.

  5. Mechanizmy wspomagające masową instalację.

  6. Pakiet ma wykorzystywać platformę skanowania, dzięki której dostawcy zabezpieczeń stosować mogą technologię „minifiltrów”, skanujących w czasie rzeczywistym
    w poszukiwaniu złośliwego oprogramowania. Dzięki użyciu technologii minifiltrów, system ma wykrywać wirusy, oprogramowanie szpiegowskie i inne pliki przed ich uruchomieniem, dając dzięki temu wydajną ochronę przed wieloma zagrożeniami, a jednocześnie minimalizując zaangażowanie użytkownika końcowego.

  7. Aparat ochrony przed złośliwym oprogramowaniem ma używać zaawansowanych technologii wykrywania, takich jak analiza statyczna, emulacja, heurystyka i tunelowanie w celu identyfikacji złośliwego oprogramowania i ochrony systemu. Ponieważ zagrożenia stają się coraz bardziej złożone, ważne jest, aby zapewnić nie tylko oczyszczenie systemu, ale również poprawne jego funkcjonowanie po usunięciu złośliwego oprogramowania. Aparat ochrony przed złośliwym oprogramowaniem w systemie ma zawierać zaawansowane technologie oczyszczania, pomagające przywrócić poprawny stan systemu po usunięciu złośliwego oprogramowania.

  8. Generowanie alertów dla ważnych zdarzeń, takich jak atak złośliwego oprogramowania czy niepowodzenie próby usunięcia zagrożenia.

  9. Tworzenie szczegółowych raportów zabezpieczeń systemów IT o określonych priorytetach, dzięki którym użytkownik może wykrywać i kontrolować zagrożenia lub słabe punkty zabezpieczeń. Raporty mają obejmować nie tylko takie informacje, jak ilość ataków wirusów, ale wszystkie aspekty infrastruktury IT, które mogą wpłynąć na bezpieczeństwo firmy (np. ilość komputerów z wygasającymi hasłami, ilość maszyn, na których jest zainstalowane konto „gościa”, itd.).

  10. Pakiet ma umożliwiać zdefiniowanie jednej zasady konfigurującej technologie antyszpiegowskie, antywirusowe i technologie monitorowania stanu jednego lub wielu chronionych komputerów. Zasady obejmują również ustawienia poziomów alertów, które można konfigurować, aby określić rodzaje alertów i zdarzeń generowanych przez różne grupy chronionych komputerów oraz warunki ich zgłaszania.

  11. System ochrony musi być zoptymalizowany pod kątem konfiguracji ustawień agenta zabezpieczeń przy użyciu Zasad Grupy usługi katalogowej oraz dystrybucji aktualizacji definicji.


Usługa portalu on-line musi realizować następujące funkcje i wymagania poprzez wbudowane mechanizmy:

  1. Publikację dokumentów, treści i materiałów multimedialnych na witrynach wewnętrznych,

  2. Zarządzanie strukturą portalu i treściami www,

  3. Uczestnictwo użytkowników w forach dyskusyjnych, ocenie materiałów, publikacji własnych treści,

  4. Udostępnianie spersonalizowanych witryn i przestrzeni roboczych dla poszczególnych ról
    w systemie wraz z określaniem praw dostępu na bazie usługi katalogowej,

  5. Tworzenie repozytoriów wzorów dokumentów,

  6. Tworzenie repozytoriów dokumentów,

  7. Wspólną, bezpieczną pracę nad dokumentami,

  8. Wersjonowanie dokumentów (dla wersji roboczych),

  9. Organizację pracy grupowej,

  10. Wyszukiwanie treści,

  11. Dostęp do danych w relacyjnych bazach danych,

  12. Serwery portali muszą udostępniać możliwość zaprojektowania struktury portalu tak, by mogła stanowić zbiór wielu niezależnych portali, które w zależności od nadanych uprawnień mogą być zarządzane niezależnie.

  13. Portale muszą udostępniać mechanizmy współpracy między działami/zespołami, udostępnić funkcje zarządzania zawartością, zaimplementować procesy przepływu dokumentów i spraw oraz zapewnić dostęp do informacji niezbędnych do realizacji założonych celów i procesów.

Serwery portali muszą posiadać następujące cechy dostępne bezpośrednio, jako wbudowane właściwości produktu:

  1. Interfejs użytkownika:

  1. Możliwość pracy z dokumentami typu XML w oparciu schematy XML przechowywane
    w repozytoriach portalu bezpośrednio z aplikacji w specyfikacji pakietu biurowego (otwieranie/zapisywanie dokumentów, podgląd wersji, mechanizmy ewidencjonowania i wyewidencjonowania dokumentów, edycja metryki dokumentu).

  2. Wbudowane zasady realizujące wytyczne dotyczące ułatwień w dostępie do publikowanych treści zgodne z WCAG 2.0

    1. Praca bezpośrednio z aplikacji pakietu biurowego z portalowymi rejestrami informacji typu kalendarze oraz bazy kontaktów

    2. Tworzenie witryn w ramach portalu bezpośrednio z aplikacji pakietu biurowego

    3. Umożliwienie uruchomienia prezentacji stron w wersji pełnej oraz w wersji dedykowanej i zoptymalizowanej dla użytkowników urządzeń mobilnych PDA, telefon komórkowy).

  1. Projektowanie stron

    1. Wbudowane intuicyjne narzędzia projektowania wyglądu stron,

    2. Wsparcie dla narzędzi typu Adobe Dreamweaver, Microsoft Expression Web
      i edytorów HTML,

    3. Wsparcie dla ASP.NET, Apache, C#, Java i PHP,

    4. Możliwość osadzania elementów iFrame w polach HTML na stronie.

  2. Integracja z pozostałymi modułami rozwiązania oraz innymi systemami:

    1. Wykorzystanie poczty elektronicznej do rozsyłania przez system wiadomości, powiadomień, alertów do użytkowników portalu w postaci maili

    2. Integracja z usługą katalogową w zakresie prezentacji informacji o pracownikach. Dane typu: imię, nazwisko, stanowisko, telefon, adres, miejsce w strukturze organizacyjnej mają stanowić źródło dla systemu portalowego

    3. Wsparcie dla standardu wymiany danych z innymi systemami w postaci XML,
      z wykorzystaniem komunikacji poprzez XML Web Services

    4. Mechanizm jednokrotnej identyfikacji (single sign-on) pozwalający na autoryzację użytkowników portalu i dostęp do danych w innych systemach, niezintegrowanych
      z systemem LDAP.

    5. Przechowywanie całej zawartości portalu (strony, dokumenty, konfiguracja) we wspólnym dla całego serwisu podsystemie bazodanowym z możliwością wydzielenia danych.


1   2   3   4   5   6


©operacji.org 2017
wyślij wiadomość

    Strona główna