Załącznik nr 2 do SIWZ - Szczegółowy Opis …stat.gov.pl/cps/rde/xbcr/bip/BIP_60_sisp_pn_2012... · Web viewPortal Sprawozdawczy. Serwis internetowy GUS jest opracowywany w wersji

GłZałącznik nr 2 do SIWZ

Sprawa numer: 60/SISP/PN/2012

Opis Przedmiotu Zamówienia (OPZ)

Budowa Systemu Prezentacji Informacji (SPI) przez Portal Informacyjny GUS (PI GUS), w tym dostawa systemu zarządzania treścią (CMS) wraz z niezbędnymi komponentami i usługami związanymi z wdrożeniem.

Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego oraz ze środków budżetu państwa. 7. Oś Priorytetowa: Społeczeństwo informacyjne – budowa elektronicznej

administracji.1

Spis treści

1. Definicje...............................................................................................................................................4

2. Opis przedmiotu zamówienia.............................................................................................................10

2.1. Nazwa zamówienia 10

2.2. Ogólny przedmiot zamówienia 10

2.3. Opis stanu obecnego 10

2.3.1. Opis Funkcjonalny............................................................................................................10

2.3.2. Opis Architektury.............................................................................................................11

2.4. Infrastruktura techniczna Zamawiającego udostępniona do realizacji zamówienia 13

2.4.1. Infrastruktura sprzętowa..................................................................................................13

2.4.2. Infrastruktura sieciowa....................................................................................................14

2.4.1. Konfiguracja stacji roboczych...........................................................................................14

2.5. Ogólna koncepcja Systemu Prezentacji Informacji (SPI) 15

2.6. Zakres zadań 16

2.6.1. Analiza wymagań.............................................................................................................17

2.6.2. Projekt graficzny wyglądu SPI...........................................................................................17

2.6.3. Projekt techniczny SPI......................................................................................................18

2.6.4. Budowa i wdrożenie SPI / CMS........................................................................................19

2.6.5. Dokumentacja..................................................................................................................19

2.6.5.1. Dokumentacja administratorów i użytkowników.............................................................20

2.6.5.2. Dokumentacja powykonawcza SPI/CMS..........................................................................20

2.6.5.3. Dokumentacja komponentów i oprogramowania standardowego..................................20

2.6.6. Testowanie i odbiór systemu...........................................................................................20

2.6.7. Szkolenia..........................................................................................................................21

2.6.8. Asysta techniczna.............................................................................................................21

2.6.9. Gwarancja........................................................................................................................21

2.6.10. Pomoc techniczna............................................................................................................21Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego

oraz ze środków budżetu państwa. 7. Oś Priorytetowa: Społeczeństwo informacyjne – budowa elektronicznej administracji.

2

3. Asysta techniczna...............................................................................................................................21

4. Gwarancja..........................................................................................................................................23

5. Organizacja i zasady zarządzania Projektem......................................................................................28

6. Wymagania dotyczące SPI oraz CMS..................................................................................................31

6.1. Opis grup wymagań 31

6.2. Charakterystyka użytkowników CMS 31

6.3. Charakterystyka użytkowników portalu internetowego GUS 32

6.4. Ograniczenia, założenia i zależności 32

6.5. Interfejsy zewnętrzne 34

6.6. Wymagania funkcjonalne 35

6.7. Wymagania techniczne i bezpieczeństwa 68

6.8. Użyteczność, estetyka, ergonomia i dostępność 72

6.9. Wydajność i skalowalność 76

6.10. Szkolenia 77

6.11. Migracja danych 78

6.12. Testy 79


administracji.3

1. DefinicjeAdministrator techniczny

Upoważniony pracownik Zamawiającego posiadający uprawnienia do: dokonywania Zgłoszenia Serwisowego, odbioru naprawy, korzystania z usług „Hot Line”.

Asysta techniczna

Udział wykwalifikowanych pracowników wykonawcy w pracach związanych z użytkowaniem i rozwojem Systemu prowadzonych przez Zamawiającego.

BIPraktyki, metodyki, narzędzia, czy technologie informatyczne związane z analizą danych.

Captcha(ang. Completely Automated Public Turing Test to Tell Computers and Humans Apart) - rodzaj techniki stosowanej jako zabezpieczenie w formularzach na stronach WWW.

CMS

System zarządzania treścią (ang. Content Management System CMS) - aplikacja internetowa lub ich zestaw, pozwalająca na łatwe utworzenie serwisu WWW (jednego, bądź kilku) oraz jego późniejszą aktualizację i rozbudowę przez redakcyjny personel nietechniczny.

CSSKaskadowe arkusze stylów (ang. Cascading Style Sheets) - język służący do opisu formy prezentacji (wyświetlania) stron WWW, stworzony w celu odseparowania struktury dokumentu od formy jego prezentacji.

Czas Naprawy Czasokres (w godzinach lub dniach) liczony od czasu potwierdzenia Zgłoszenia Serwisowego do czasu usunięcia Wady, potwierdzony podpisaniem Protokołu Odbioru Naprawy. Czas naprawy jest różny dla poszczególnych kategorii Wad i wynosi odpowiednio:W1 - 5 godzin roboczych,W2 – 24 godziny robocze,W3 – 3 dni robocze.

Czas Reakcji Serwisu

Czasokres (w godzinach), w jakim wykonawca zobowiązany jest przystąpić do świadczenia usługi po dokonaniu przez Zamawiającego Zgłoszenia Wady. Czas ten jest różny dla poszczególnych Kategorii Wad i wynosi odpowiednio:W1 - 2 godziny robocze,W2 – 5 godzin roboczych,W3 – 24 godziny robocze.

Dział Patrz: Kategoria

Dzień Roboczy Każdy kolejno po sobie następujący dzień od poniedziałku do piątku, z wyłączeniem dni ustawowo wolnych od pracy.

DMZ (ang. Demilitarized zone) strefa zdemilitaryzowana - wydzielony na zaporze sieciowej (ang. firewall) obszar sieci komputerowej


administracji.4

nie należący ani do sieci wewnętrznej (tj. tej chronionej przez zaporę), ani do sieci zewnętrznej (w tym przypadku Internet).

Dokumentacja Systemu

Zbiór dokumentów będących wynikiem prac wykonawcy wykonywanych bezpośrednio w ramach realizacji przedmiotu Umowy.

Dostęp do zawartości statycznej

Funkcjonalność polegająca na wyświetlaniu statycznych tekstów, dokumentów i innego rodzaju zawartości multimedialnej.

Dostęp do zawartości dynamicznej

Funkcjonalność umożliwiająca prezentację zawartości tworzonej na bieżąco poprzez informacje pobierane z baz danych, generowane z każdym ich wywołaniem na podstawie zdefiniowanych reguł.

Godzina Robocza

Godziny od 8.15 do 16.15 w każdym Dniu Roboczym.

Gotowość Stan polegający na pozostawaniu wykonawcy w gotowości do przyjęcia Zgłoszenia Serwisowego; Gotowość obejmuje dni od poniedziałku do piątku, z wyłączeniem dni ustawowo wolnych od pracy, w godzinach 8.00 – 17.00.

Harmonogram prac

Aktualizowany harmonogram wskazujący terminy realizacji poszczególnych zadań wchodzących w zakres etapu.Zgodnie z ustaleniami Zamawiającego i wykonawcy Harmonogram stanowi instrument kontroli i monitorowania postępu prac. W Harmonogramie dopuszczalne są zmiany terminów wykonania poszczególnych zadań w zakresie etapu, z wyłączeniem terminów odbioru etapów.

Infrastruktura techniczna

Sprzęt, urządzenia aktywne i inne elementy infrastruktury teleinformatycznej Zamawiającego oraz wskazane licencje Oprogramowania.

Interwencja Wizyta serwisowa w miejscu instalacji Oprogramowania związana z naprawą wady i prac nie objętych bezpłatną gwarancją.

Javascript (JS) Obiektowy skryptowy język programowania, stosowany na stronach internetowych.

Karta Zgłoszenia Serwisowego

Dokument wypełniany przez Administratora technicznego służący do dokonywania Zgłoszenia Wady Systemu.

Kategoria

Służy do logicznego grupowania stron w ramach serwisu. Kategoria może zawierać kategorie podrzędne (podkatagorie) tworząc w ten sposób hierarchiczną strukturę zawartości serwisu. Kategoria może posiadać swoją stronę opartą o dowolny szablon lub w szczególności o szablon prezentujący listę podkategorii i/lub stron zawartych w danej kategorii.

Komponent Wydzielona, spójna i jednorodna technologicznie część Oprogramowania, niebędąca Modułem ani Podsystemem, wyróżniona z uwagi na jej istotność lub specyficzne cechy


administracji.5

techniczne Systemu.Komponenty mogą stanowić: usługi sieciowe, interfejsy, procedury, skrypty lub inne oprogramowanie konieczne do prawidłowego Wdrożenia i funkcjonowania Systemu, do których wykonawca posiada autorskie prawa majątkowe lub może udzielić licencji, sublicencji, w tym licencji na użytkowanie na prawach licencji GNU/GPL, BSD lub innej równoważnej.

Moduł Spójna i jednorodna przedmiotowo w zakresie funkcjonalności część Podsystemu, nazwana i będąca przedmiotem odrębnych działań wykonawcy w ramach realizacji zamówienia, np. w zakresie szkoleń, instalacji, odbioru itp.

MVC

(ang. Model-View-Controller) - architektoniczny wzorzec projektowy, którego głównym założeniem jest wyodrębnienie trzech podstawowych komponentów aplikacji: modelu danych, interfejsu użytkownika i logiki sterowania (tzw. logiki biznesowej), w taki sposób, aby modyfikacje jednego komponentu minimalnie wpływały na pozostałe.

Nadzór autorski

Zapewnienie kompatybilności Oprogramowania z nowym sprzętem komputerowym i sieciowym, uaktualnianymi systemami operacyjnymi i nowymi wersjami aplikacji, z którymi Oprogramowanie współpracuje oraz otoczeniem sieciowym. Usuwanie zauważonych błędów (poprawki, „łaty”) i przygotowywanie nowych wersji (upgrade’ów).

Newsletter Elektroniczna forma biuletynu rozsyłanego do prenumeratorów za pomocą poczty elektronicznej.

NTP (ang. Network Time Protocol) - protokół umożliwiający precyzyjną synchronizację czasu pomiędzy komputerami.

Obejście Tymczasowe rozwiązanie wady, które może być realizowane poprzez zmianę parametrów Systemu. Zastosowanie obejścia nie zwalnia wykonawcy od obowiązku dostarczenia rozwiązania końcowego i nie może powodować utraty lub zmniejszenia funkcjonalności Systemu.

Oprogramowanie Aplikacyjne

Oprogramowanie opracowane i dostarczone przez wykonawcę, do którego wykonawca posiada autorskie prawa majątkowe. Oprogramowanie Aplikacyjne obejmuje wszystkie moduły Systemu oraz opracowane przez wykonawcę komponenty i procedury techniczne (np. ładowania danych) mające jakąkolwiek postać kodu wykonywalnego lub skryptu.

Oprogramowanie Systemowe

Oprogramowanie zapewniające podstawowe funkcje systemowe umożliwiające funkcjonowanie Infrastruktury Technicznej Zamawiającego zgodnie z jej przeznaczeniem, np. system operacyjny: MS Windows 2008 Server, Unix lub inny równoważny.


administracji.6

PersonalizacjaDostosowanie zawartości i wyglądu (sposobu wyświetlania) serwisu do indywidualnych potrzeb użytkownika i/lub pełnionej przez niego roli w Systemie.

Podsystem Część Systemu składająca się z komponentów programistycznych oraz Modułów. Podsystem musi składać się minimum z jednego Modułu.

Pełnomocnik Strony

Osoba umocowana umową, odpowiedzialna za jej realizację oraz uprawniona do rozwiązywania i rozstrzygania problemów (sporów technicznych): z punktu widzenia zapisów umowy – dokumentu głównego mogą to być odpowiednio Kierownicy Projektu lub inne osoby wskazane przez Strony.

Produkt Dokumentacja, oprogramowanie i nośniki oprogramowania, dobra materialne w tym przede wszystkim urządzenia i sprzęt, wytworzone lub dostarczone w wyniku realizacji Umowy.

PI GUS Portal Informacyjny GUS.SE System Edukacyjny.

SISP System Informacyjny Statystyki Publicznej - system informacyjny GUS http://www.stat.gov.pl/cois/sisp.htm

SIWZ Niniejsza Specyfikacja Istotnych Warunków Zamówienia wraz z załącznikami, przygotowana przez Zamawiającego w ramach postępowania o udzielenie zamówienia publicznego, którego skutkiem jest zawarcie umowy.

SK Serwer Klasyfikacji.SMS System Metadanych Statystycznych.

SPBS System wspierający organizację i monitorowanie Projektowania i Prowadzenia Badań Statystycznych.

SPI System Prezentacji Informacji (System)

Stabilność Systemu

Zdolność do automatycznego przywrócenia poziomu usługi po przeciążeniu, podczas którego usługa była świadczona poza kryteriami dostępności.

SystemSystem teleinformatyczny spełniający wymagania określone w SIWZ i umowie, na który składa się sprzęt, oprogramowanie systemowe i aplikacyjne, realizujący po jego wdrożeniu funkcjonalności opisane w SIWZ i dokumentacji Systemu.

SWAiDSystem Wspomagania Analiz i Decyzji, budowany w ramach SISP. Zadaniem SWAiD jest rozbudowane raportowanie, wspomaganie wykonywania analiz oraz udostępnianie informacji statystycznych.

SzablonOpis wyglądu strony WWW, będący wzorcem wykonania strony na podstawie zdefiniowanych wcześniej schematów, służący do prezentacji artykułów na stronach o identycznym układzie graficznym, ale o innej zawartości.

Utwór Przedmiot prawa autorskiego w rozumieniu ustawy o prawie Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


7

http://www.stat.gov.pl/cois/sisp.htm

autorskim i prawach pokrewnych z dnia 4 lutego 1994 r. (Dz.U. 1994 Nr 24 poz. 83 z późn. zm.)

WAI

(ang. Web Accessibility Initiative) - prowadzona przez organizację W3C Inicjatywa Przystępnej Sieci mająca na celu zwiększenie szerokorozumianej dostępności stron WWW dla osób niepełnosprawnych. Działania w ramach WAI skupiają się na:

tworzeniu wytycznych odnośnie dostępności do Sieci (w tym WCAG);

zapewnianiu, że technologie sieciowe wspierają dostępność;

tworzeniu narzędzi do ewaluacji oraz ułatwiania dostępności;

prowadzeniu działań edukacyjnych; koordynowaniu prac badawczych i rozwoju.

Wada Nieprawidłowe działanie Systemu lub jego fragmentu, uniemożliwiające całkowicie lub w ograniczonym zakresie jego używanie zgodnie z przeznaczeniem, specyfikacją techniczną, projektem, za które odpowiada wykonawca, obejmujące także:

działanie niezgodne z dokumentacją użytkownika lub administratora,

pogorszenie wydajności utrudniające znacznie pracę użytkowników,

działanie niezgodne z oczekiwanymi, podstawowymi zasadami funkcjonowania systemów informatycznych,

brak dostępności Systemu dla jego użytkowników (z wyłączeniem okoliczności niezależnych od wykonawcy),

naruszenie bezpieczeństwa Systemu (dostęp do danych lub funkcji Systemu z pominięciem mechanizmów zabezpieczeń).

Wada o priorytecie krytycznym

Uniemożliwiająca pracę Systemu lub jego fragmentu. Ma kluczowe znaczenie dla poprawnego działania i użytkowania.

Wada o priorytecie istotnym

Zakłócenie działania Systemu lub jego fragmentu, polegające na nienależytym działaniu lub nie działaniu jednej z funkcji; istnieje obejście zakłócenia powodujące znaczne nakłady pracy, zaś cały system funkcjonuje.

Wada o priorytecie zwykłym

Każda wada inna niż o priorytecie krytycznym lub istotnym.

WCAG (ang. Web Content Accessibility Guidelines) - zbiór dokumentów opublikowany przez WAI zawierający zalecenia dotyczące tworzenia dostępnych serwisów internetowych, mający na celu zwiększenie szeroko rozumianej dostępności stron WWW dla osób niepełnosprawnych. Poszczególne polecenia mają przypisane trzy poziomy priorytetu w zależności od jego stopnia


administracji.8

oddziaływania na dostępność. Wypełnienie priorytetów danego poziomu określane jest odpowiednio zgodnością poziomu A, AA, AAA.

Wdrożenie Ciąg następujących po sobie lub występujących równolegle czynności takich, jak: instalacja, konfiguracja, szkolenie użytkowników i administratorów, przygotowanie danych testowych, wykonanie testów weryfikacyjnych i wydajnościowych oraz współudział w testach akceptacyjnych, przygotowanie szablonów oraz scenariuszy testowych, opracowanie i dostarczenie dokumentacji użytkownika oraz dokumentacji technicznej Systemu, przeprowadzenie migracji danych oraz świadczenie usług asysty technicznej na etapie uruchomienia poszczególnych Modułów Systemu w celu doprowadzenia do normalnej, prawidłowej eksploatacji Systemu.

Web ServiceUsługa sieciowa - komponent programowy niezależny od platformy i implementacji, dostarczający określonej funkcjonalności.

WersjonowanieMechanizm pozwalający na przywrócenie lub uzyskanie podglądu obiektu w stanie, w jakim był przed dokonaniem modyfikacji. W systemie jest rejestrowana i przechowywana historia zmian zawartości stron wraz z zawartością poszczególnych wersji.

Wsparcie Gwarantowana pomoc w eksploatacji oprogramowania, sprzętu komputerowego, jak też innych urządzeń, udzielana użytkownikowi przez producenta przy ich zakupie.

Wydajność CMS

Zdolność do wykonania odpowiednio dużej ilości zadań w określonym przedziale czasu. Miarą wydajności jest czas odpowiedzi Systemu (załadowania się żądanej strony), który nie może być dłuższy niż 8 sekund (dla połączenia LAN 100 Mb/s), przy obciążeniu docelową ilością Użytkowników, tj. 50 na sekundę (80% pobierających dynamicznie tworzone strony, 20% wyszukujących informacje na stronie), korzystających z systemu jednocześnie.

Umowa Oznacza umowę wraz z załącznikami do niej, zawartą w wyniku przeprowadzenia niniejszego postępowania przetargowego, której wzór stanowi Załącznik nr 6 do niniejszej SIWZ.

Zgłoszenie Serwisowe

Przekazanie wykonawcy przez Administratora technicznego zgłoszenia wady Systemu. Zgłoszenie serwisowe zawiera niezbędne a zarazem konieczne informacje wystarczające do podjęcia przez wykonawcę działań zmierzających do zdiagnozowania faktycznej przyczyny usterki Systemu (wady).


administracji.9

2. Opis przedmiotu zamówienia

2.1. Nazwa zamówieniaBudowa Systemu Prezentacji Informacji (SPI) przez Portal Informacyjny GUS (PI GUS), w tym dostawa systemu zarządzania treścią (CMS) wraz z niezbędnymi komponentami i usługami związanymi z wdrożeniem.

2.2. Ogólny przedmiot zamówieniaPrzedmiotem zamówienia jest zaprojektowanie, zbudowanie oraz wdrożenie Systemu Prezentacji Informacji, w szczególności:

1. Dokonanie Analizy Wymagań dla projektowanego i budowanego Systemu Prezentacji Informacji.

2. Zaprojektowanie funkcjonalnie i graficznie Systemu.3. Wykonanie Projektu Technicznego Systemu zarządzanego przez CMS.4. Dostarczenie dodatkowej, niezbędnej infrastruktury i oprogramowania w celu

wykonania przedmiotu zamówienia.5. Instalacja i konfiguracja infrastruktury przeznaczonej do realizacji projektu.6. Dostawa, instalacja i konfiguracja Oprogramowania CMS.7. Wytworzenie i dostarczenie brakujących funkcjonalności wynikających w wymagań

Zamawiającego.8. Przeniesienie danych z obecnie funkcjonującego Portalu Informacyjnego (PI) GUS

do nowego CMS.9. Połączenie SPI ze wskazanymi systemami Zamawiającego i optymalizacja SPI.10. Sporządzenie i dostarczenie dokumentacji administracyjnej i użytkowej.11. Opracowanie i wykonanie testów cząstkowych i akceptacyjnych.12. Przekazanie Zamawiającemu certyfikatów udzielenia licencji/sublicencji oraz

innych certyfikatów wymaganych przez Zamawiającego.13. Przekazanie Zamawiającemu kodów źródłowych wraz z opisem.14. Przeprowadzenie szkoleń dla użytkowników CMS w zakresie administracji oraz

obsługi Systemu.15. Produkcyjne uruchomienie SPI, w tym CMS.16. Świadczenie usług gwarancyjnych i serwisowych.17. Zapewnienie asysty technicznej.

Przedstawione rozwiązanie techniczne nie może stanowić systemu zamkniętego i winno uwzględniać możliwości rozwoju pod względem ilościowym i wydajnościowym.

2.3. Opis stanu obecnego2.3.1. Opis Funkcjonalny

Portal Informacyjny GUS jest głównym kanałem udostępniania wyników badań statystycznych. Za pośrednictwem portalu strony www i publiczne bazy danych odwiedza rocznie 5.700 tys. unikalnych użytkowników (osoba korzystająca z portalu liczona jest tylko jeden raz, niezależnie od liczby wejść). Osoby te wykonały w ubiegłym


administracji.10

roku 12.000 tys. połączeń z portalem i pobrały pliki (dokumenty) o łącznej wielkości 43500 GB.

Portal Informacyjny składa się z 22 oddzielnych projektów, powiązanych w jedną całość:

www.stat.gov.pl

www.stat.gov.pl/bip

www.stat.gov.pl/zws

www.stat.gov.pl/pts

www.stat.gov.pl/cis

www.stat.gov.pl/bip/dzienniki

www.stat.gov.pl/(US – 16 urzędów statystycznych).

Podczas redagowania treści w CMS można przełączać się pomiędzy poszczególnymi projektami bez potrzeby wylogowania się i ponownego zalogowania się.

Ponadto z Portalem Informacyjnym GUS związane są następujące wydzielone projekty:

www.statlibr.stat.gov.pl

www.stat.gov.pl/jachranka/

Portal Informacyjny współpracuje z następującymi aplikacjami:

Bank Danych Lokalnych http://www.stat.gov.pl/bdl/app/strona.html?p_name=indeks

Baza Demografia http://demografia.stat.gov.pl/bazademografia

system eREGON https://esp.stat.gov.pl

wyszukiwarka Regon http://www.stat.gov.pl/regon/

Baza Danych Handlu Zagranicznego http://hinex.stat.gov.pl/hinex/aspx/index.aspx.

Portal Sprawozdawczy.

Serwis internetowy GUS jest opracowywany w wersji polskiej i angielskiej. Obecnie zawiera ok. 100 tysięcy plików (m.in. w postaci HTML, MS Office, Acrobat Adobe, Adobe Flash) i 20 tysięcy stron html.

2.3.2. Opis ArchitekturyPI GUS ma architekturę trójwarstwową.

Na wejściu do PI znajduje się przełącznik Content Server Switch, (load balancer), do którego podłączone są 2 serwery Apache (2A i 2B) pełniące funkcję serwerów Proxy.

W strefie chronionej DMZ 2 umieszczone są:

2 serwery (3A i 3B) z RedDot LiveServer 2.3, TOMCAT 5 JRE 1.4 Windows 2003Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


11

http://hinex.stat.gov.pl/hinex/aspx/index.aspx

http://www.stat.gov.pl/regon/

https://esp.stat.gov.pl/

http://demografia.stat.gov.pl/bazademografia

http://www.stat.gov.pl/bdl/app/strona.html?p_name=indeks

http://www.stat.gov.pl/bdl/app/strona.html?p_name=indeks

http://www.stat.gov.pl/jachranka/

http://www.statlibr.stat.gov.pl/

http://www.stat.gov.pl/bip/dzienniki

http://www.stat.gov.pl/cis

http://www.stat.gov.pl/pts

http://www.stat.gov.pl/zws

http://www.stat.gov.pl/bip

http://www.stat.gov.pl/

W III warstwie (LAN) znajdują się klaster baz danych(10A i 10B), serwery produkcyjne CMS(9A i 9B) i serwer publikacyjny CMS(6B). Serwer publikacyjny służy do opublikowania stron (opracowanych na serwerach produkcyjnych) na serwery prezentacyjne CMS(3A i 3B). Na serwerach bazodanowych oprócz baz danych portalowych, posadowione są również bazy współpracujące z portalem (uruchamiane z portalu, serwery aplikacyjne umieszczone w DMZ II).

Schemat blokowy architektury Portalu Informacyjnego WWW GUS

Stosowane narzędzia:

Podstawowym narzędziem jest CMS RedDot ver. 7.5 zainstalowany na:

3A, 3B zainstalowano oprogramowanie RedDot LiveServer 2.3, TOMCAT 5 JRE 1.4

9A, 9B,6B zainstalowano oprogramowanie RedDot Content Management Server 7.5

10A, 10B zainstalowano oprogramowanie Microsoft SQLServer 2005

GUS łącznie z US posiada 100 licencji CMS dla jednoczesnych użytkowników.

Serwery 3A i 3B korzystają z baz danych Fast Objects umieszczonych lokalnie. Do baz tych następuje równoległa publikacja przez serwer CMS (6B). Treści te przesyłają odpowiadając na żądania serwera 2B lub 2A.

Pomiędzy Internetem a DMZ oraz między DMZ i LAN jest firewall. Ruch pomiędzy strefami jest dozwolony jedynie w systemie serwer- serwer na określonych portach.


administracji.12

Do komunikacji wewnętrznej w CMS wykorzystywana jest poczta elektroniczna MS Exchange 2010.

Powyższy sprzęt i oprogramowanie przeznaczone jest do funkcjonowania, do czasu wdrożenia produkcyjnego SPI będącego przedmiotem niniejszego zamówienia.

2.4. Infrastruktura techniczna Zamawiającego udostępniona do realizacji zamówienia

2.4.1. Infrastruktura sprzętowaZamawiający dla realizacji projektu dedykował następującą infrastrukturę sprzętową:

Serwery rzeczywiste:

1. 2 serwery 2procesorowe 4-rdzeniowe Intel Xeon 2,83 16 GB RAM, 2x72 GB dyski, RHEL5.6

2. 2 serwery 2procesorowe 4-rdzeniowe Intel Xeon 2,83 16 GB RAM 2x72 GB dyski, Windows 2008

3. 2 serwery 2 procesorowe 4-rdzeniowe Intel Xeon 2,83 16 GB RAM 2x146 GB dyski, Windows 2008

4. 2 serwery 2 procesorowe 6-rdzeniowe Intel Xeon 2993, 64GB RAM,2x146 GB dyski, Windows EE

5. 2 serwery 4procesorowe 6-rdzeniowe Intel MP2,4 128 GB RAM, 2x 72 GB dyski, Windows 2008, MS SQL Server 2005 EE 64-bit (cluster active-passive), zasoby dyskowe z macierzy: 10 TB powierzchni surowej przed utworzeniem RAID.

W przypadku, gdy wykonawca będzie potrzebował dodatkowej infrastruktury sprzętowej i systemowej, to musi je dostarczyć w ramach zamówienia wraz z wdrożeniem w infrastrukturze Zamawiającego. Dodatkowe licencje systemów operacyjnych niezbędnych do wykonania infrastruktury projektu muszą być dostarczone w najnowszej dostępnej wersji z rocznym wsparciem producenta. Serwery rzeczywiste, infrastruktura środowiska zwirtualizowanego, dodatkowa przestrzeń dyskowa, zasilacze UPS, urządzenia sieciowe i inne, oraz oprogramowanie muszą być kompatybilne z posiadanym przez Zamawiającego sprzętem i zarządzane przez posiadane przez Zamawiającego oprogramowanie. Dodatkowy sprzęt i oprogramowanie muszą zostać wyszczególnione w Tabeli 1 i 2 Formularza Ofertowego stanowiącego załącznik nr 4 do SIWZ oraz muszą zostać ujęte w Formularzu cenowym stanowiącym załącznik nr 5 do SIWZ. Dostarczony sprzęt musi zostać objęty gwarancją dla dostarczonego sprzętu zgodnie z punktem 4 OPZ.

Backupy serwerów rzeczywistych i wirtualnych zapewnia Zamawiający.

Backupy baz danych z serwerów MSSQL wykonywane są poprzez oprogramowanie HP Data Protector lub przez zadania MSSQL do katalogów na dysku, a następnie te katalogi są backupowane na urządzenia zewnętrzne. Wykorzystywany jest do tego również HP Data Protector.


administracji.13

2.4.2. Infrastruktura sieciowaInfrastruktura sieciowa ośrodka przetwarzania Zamawiającego oparta jest o sieć ethernet, którego szkielet stanowią przełączniki CISCO 6509 oraz Nexus 5010 i 5548 z portami dostępowymi o przepustowości 1Gbps i 10Gbps.

Systemy dostępne z Internetu muszą być tak zaprojektowane przez wykonawcę aby były dostosowane do standardów sieciowych Zamawiającego.

System musi być zbudowany w architekturze trójwarstwowej, która spełnia następujące założenia:

1. Warstwa - warstwa prezentacji, w tej warstwie powinny się znaleźć jedynie serwery prezentujące użytkownikom treść wygenerowaną w niższych warstwach architektury.

2. Warstwa - w tej warstwie powinny znajdować się serwery przygotowujące wystawianą treść na podstawie danych przetwarzanych na serwerach w Warstwie 3.

3. Warstwa - strefa wewnętrzna GUS, w której umieszczone są serwery dedykowane dla baz danych oraz aplikacji wewnętrznych. W tej strefie powinny znaleźć się wszelkie elementy wymagające najwyższego stopnia ochrony w tym serwery aplikacyjne i bazodanowe.

Zamawiający przewiduje wykorzystanie własnych urządzeń typu firewall i IPS w celu zabezpieczenia ruchu z Internetu do strefy 1. Ruch pomiędzy strefą 1 a 2 i 2 a 3 przewidziany jest jedynie w systemie serwer-serwer na określonych w architekturze portach (które uzgodnione zostaną z Zamawiającym).

2.4.1. Konfiguracja stacji roboczychSystem ma wykorzystywać do pracy istniejące u Zamawiającego stacje robocze, które nie są przedmiotem niniejszego zamówienia.

Konfiguracja stacji roboczej, która będzie wykorzystywana do obsługi Systemu:

Lp. Nazwa komponenty Parametry minimalne

1 Procesor E6550 2,33 GHz

2 Pamięć RAM 1GB

3 Dysk twardy 250 GB

4 Karta sieciowa 100/1000

5 Karta graficzna Rozdzielczość: 1280:1024

6 Oprogramowanie systemowe Windows XP, Windows 7


administracji.14

System powinien pracować na komputerach o konfiguracji przedstawionej powyżej i lepszych (dotyczy także systemu operacyjnego).

2.5. Ogólna koncepcja Systemu Prezentacji Informacji (SPI) Główny Urząd Statystyczny realizuje obecnie projekt System Informacyjny Statystyki Publicznej (SISP), którego jednym z celów jest wspieranie zadań związanych z udostępnianiem użytkownikom zewnętrznym danych statystycznych o charakterze publicznym (opis projektu zawiera Załącznik Nr 1 do SIWZ).

Realizacja projektu jest odpowiedzią na m.in. zwiększające się zapotrzebowanie na dane statystyczne ze strony instytucjonalnych i indywidualnych użytkowników danych statystycznych.

W ramach projektu SISP realizowana będzie budowa Systemu Prezentacji Informacji (SPI), w tym dostawa nowoczesnego systemu do zarządzania treścią (CMS). Podjęte działania pozwolą na:

1. Zwiększenie dostępu do wynikowych informacji statystycznych oraz danych rejestrowych.

2. Zwiększenie przejrzystości prezentowanych danych.3. Poszerzenie zawartości portalu i pozyskanie nowych użytkowników.4. Zapewnienie wysokiej jakości usług świadczonych przez statystykę na rzecz

użytkowników zewnętrznych. 5. Zwiększenie liczby portali zewnętrznych i innych systemów kontaktujących się z

portalem informacyjnym.6. Promocja statystyki polskiej.7. Umożliwienie tworzenia nowych serwisów tematycznych.

System Prezentacji Informacji będzie jednolitą platformą informacyjną, dostępną w polskiej i angielskiej wersji językowej. SPI będzie wykorzystywany do prezentowania struktury i rodzaju dostępnych danych. System zapewni dostęp do interfejsów systemów informacyjnych, których zasoby i funkcje udostępnione są użytkownikom zewnętrznym.

SPI będzie wspierać proces wyszukiwania danych (zapewniona maksymalna łatwość i intuicyjność wyszukiwania). Wyszukiwarka będzie korzystać z metadanych opisujących prezentowane liczby, w tym słownika pojęć statystycznych. Opisywane funkcje będą realizowane poprzez ergonomiczny, graficzny interfejs użytkownika dostosowywany tak, aby ułatwiać wyszukiwanie np. poprzez filtrowanie typów dostępnych danych czy zagadnień tematycznych. Pozwoli to na wyszukiwanie informacji zarówno w trybie prostym z wykorzystaniem jednego kryterium wyszukiwania, jak i złożonym – wykorzystując więcej niż jedno kryterium.

System Prezentacji Informacji będzie umożliwiać dostęp między innymi do:

Systemu Wspomagania Analiz i Decyzji (SWAID), Systemu Metadanych Statystycznych (SMS), Serwera Klasyfikacji (SK),


administracji.15

Danych udostępnionych z rejestrów REGON i TERYT, Portalu Geostatystycznego.

Zarządzanie treścią SPI powinno odbywać się docelowo z wykorzystaniem nowoczesnego CMS, posiadającego elastyczną budowę modularną, umożliwiającego łatwe administrowanie i rozbudowę o nowe funkcjonalności. CMS ma w prosty sposób umożliwiać aktualizację i rozbudowę serwisu, mieć możliwość elastycznej i dynamicznej modyfikacji treści stron, jak i jego struktury.

CMS musi zapewnić możliwość dalszego rozwoju SPI, zarówno pod względem ilości publikowanych informacji, form dostępu do danych, jak też liczby równocześnie współpracujących redaktorów, przy jednoczesnym uproszczeniu i ułatwieniu administrowania systemem. Wymagać to będzie automatyzacji wybranych czynności (publikacja dokładnie na określony czas, powiadomienia o gotowości lub braku gotowości materiałów planowanych do publikacji, archiwizacja poprzednich wersji publikacji itp.) oraz zwiększenia poziomu bezpieczeństwa przy równoczesnej pracy wielu redaktorów na wzajemnie powiązanych elementach systemu.

Zamawiający oczekuje, że CMS zapewni mechanizmy gwarantujące realizację ustawowego obowiązku zapewnienia równoczesnego, równoprawnego i równorzędnego dostępu do danych statystycznych. Niedopuszczalne jest przedwczesne opublikowanie materiałów z ustawioną datą i godziną publikacji, a opóźnienie pomiędzy wyznaczonym czasem publikacji, a chwilą rzeczywistej dostępności materiałów dla użytkowników zewnętrznych nigdy nie powinno być większe niż 30 sekund (preferowane są systemy działające bez opóźnienia). Ważnym oczekiwaniem jest także łatwość obsługi CMS przez redaktorów niemających przygotowania informatycznego, ani doświadczenia w tworzeniu stron internetowych.

Układ, wygląd oraz funkcjonalność SPI powinny - w możliwie najlepszy sposób -odpowiadać potrzebom użytkowników, gdzie priorytetem jest łatwość znalezienia szukanej informacji oraz intuicyjny sposób nawigacji po stronach. Wykonawca powinien zaprojektować szablony stron internetowych SPI zgodnie z aktualną wiedzą psychologiczną o ludzkiej percepcji i wzorach zachowań internautów oraz dobrymi praktykami w zakresie tworzenia portali informacyjnych z dziedziny statystyki, np.: portali internetowych następujących instytucji prezentujących dane statystyczne: Eurostatu, OECD, ONZ oraz urzędów statystycznych Niemiec, Francji, Wielkiej Brytanii, Szwecji i Kanady.

2.6. Zakres zadań Szczegółowe wymagania dotyczące poszczególnych zadań znajdują się w

punkcie 6 niniejszego dokumentu - „Wymagania dotyczące SPI oraz CMS”.

Dokumentacja wytworzona w ramach realizacji poszczególnych zadań powinna zostać przekazana w formie papierowej (po 2 egzemplarze każdego rodzaju dokumentacji, z prawem tworzenia dowolnej ilości kopii tej dokumentacji na użytek własny) oraz w formie elektronicznej w formacie PDF (bez zabezpieczeń, z możliwością wyszukiwania).

Dokumentacja związana z przedmiotem dostawy Oprogramowania, do której wykonawca nie posiada autorskich praw majątkowych, powinna zostać


administracji.16

dostarczona zgodnie ze specyfikacją danego produktu określoną przez dystrybutora lub producenta przedmiotowego Oprogramowania.

Dokumentacja opracowana przez wykonawcę w wyniku realizacji niniejszego Zamówienia musi zostać sporządzona w języku polskim.

W okresie trwania gwarancji dokumentacja wymieniona w pkt 2.6.5-2.6.6 musi być aktualizowana po każdej modyfikacji/aktualizacji CMS lub SPI. Dokumentacja dotycząca czynności administracyjnych związanych z utrzymaniem Sytemu musi być dostarczana niezwłocznie wraz z nową wersją Systemu. Pozostała dokumentacja (podręcznik i wersja on-line) musi być dostarczona nie później niż w terminie 14 dni od daty przekazania nowej wersji systemu.

2.6.1. Analiza wymagań

Wykonawca opracuje i przedstawi Zamawiającemu do akceptacji analizę wymagań realizowanego Systemu Prezentacji Informacji zawierającą minimum:

1. Słownik pojęć.

2. Architekturę logiczną (podział na moduły, zakres funkcjonalny modułów, zależności pomiędzy modułami itp.).

3. Zakres danych przechowywanych i udostępnianych przez SPI.

4. Szczegółowy opis wszystkich wymagań dotyczących CMS.

5. Założenia i opis interfejsu użytkownika.

6. Listę uprawnień do poszczególnych funkcji CMS wraz z opisem.

7. Listę ról i grupowanych przez nie uprawnień.

2.6.2. Projekt graficzny wyglądu SPI

1. Wygląd stron musi odzwierciedlać rolę GUS jako Urzędu obsługującego Prezesa GUS - centralny organ administracji rządowej właściwy w sprawach statystyki publicznej. Powinien także odzwierciedlać międzynarodową pozycję statystyki polskiej jako części Europejskiego Systemu Statystycznego i globalnej sieci instytucji statystycznych. Wygląd serwisów musi cechować się innowacyjnością i dynamizmem, jednocześnie podkreślając rangę Urzędu.

2. Wykonawca, po uprzednich konsultacjach z przedstawicielami Zamawiającego, przedstawi po 3 odrębne koncepcyjnie (pod względem wyglądu, mechanizmów nawigacji itd.) projekty graficzne stron internetowych:

Systemu Prezentacji Informacji, Biuletynu Informacji Publicznej GUS (BIP GUS), urzędów statystycznych (3 przykłady dla jednego, wybranego urzędu) ,

oraz po 1 projekcie:

Biuletynu Informacji Publicznej urzędu statystycznego (BIP US), który będzie stosowany w każdym z 16 urzędów statystycznych,

Biuletynu Informacji Publicznej ZWS (BIP ZWS),Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


17

Zakładu Wydawnictw Statystycznych (ZWS), Polskiego Towarzystwa Statystycznego (PTS), Centrum Informatyki Statystycznej (CIS), Dzienników Urzędowych GUS (DU GUS), Centrum Badań i Edukacji Statystycznej GUS,

przy założeniu, że serwisy będą posiadały maksymalnie zbliżoną szatę graficzną, jednoznacznie rozpoznawalną jako wspólna dla całej polskiej statystyki publicznej.

3. Wykonawca zaimplementuje wybrane i zaakceptowane przez GUS projekty graficzne w dostarczonym CMS.

4. Dla każdego projektu graficznego muszą być zdefiniowane dodatkowo następujące warianty okolicznościowe: Dzień Statystyki Polskiej, żałoba.

5. Projekty graficzne wszystkich serwisów statystyki publicznej powinny zawierać logotypy UE i PO IG oraz logotyp SISP (logotyp SISP w wersji wektorowej zostanie dostarczony wykonawcy po podpisaniu umowy).

Dokładny opis znaków graficznych PO IG znajduje się w:

1. Księdze znaków: NARODOWA STRATEGIA SPÓJNOSCI – KSIEGA IDENTYFIKACJI WIZUALNEJ 2007http://www.funduszeeuropejskie.gov.pl/ZPFE/Documents/Zalacznik_1_Ksiega_identyfikacji_wizualnej.pdf

2. oraz w Przewodniku w zakresie promocji projektów finansowanych w ramach Programu Operacyjnego Innowacyjna Gospodarka, 2007-2013 dla Beneficjentów i Instytucji zaangażowanych we wdrażanie Programu http://www.poig.gov.pl/ZPFE/Documents/przewodnik_dla_benef_promocja_0412081.pdf

2.6.3. Projekt techniczny SPI

Na podstawie zatwierdzonej przez Zamawiającego analizy wymagań wykonawca wykona Projekt techniczny SPI, w tym CMS zawierający co najmniej:

1. Opis wszystkich funkcji dostarczanego SPI.

2. Opis wykorzystywanych w CMS struktur danych i modelu bazy danych portalowych .

3. Architekturę techniczną SPI, w tym CMS (moduły i powiązania pomiędzy nimi, zastosowane technologie itp.). W przypadku SPI należy wskazać sposób realizacji wszystkich jego funkcji w oparciu o architekturę portalu GUS.

4. Opis sposobu połączenia SPI z innymi systemami.

5. Projekt migracji danych z obecnego portalu do CMS.

6. Projekt zabezpieczeń na następujących poziomach: sieć, system operacyjny, baza danych, oprogramowanie narzędziowe i systemowe, backup danych.

7. Projekt instalacji i konfiguracji CMS.


administracji.18

http://www.poig.gov.pl/ZPFE/Documents/przewodnik_dla_benef_promocja_0412081.pdf

http://www.funduszeeuropejskie.gov.pl/ZPFE/Documents/Zalacznik_1_Ksiega_identyfikacji_wizualnej.pdf

http://www.funduszeeuropejskie.gov.pl/ZPFE/Documents/Zalacznik_1_Ksiega_identyfikacji_wizualnej.pdf

8. Scenariusze testowe do testów akceptacyjnych w zakresie funkcjonalności, bezpieczeństwa i wydajności Systemu będącego przedmiotem zamówienia.

Projekt techniczny podlega akceptacji i odbiorowi przez Zamawiającego. Projekt techniczny może podlegać rozwojowi i aktualizacji w trakcie prac wdrożeniowych. Każda zmiana w tym dokumencie (odnotowana w rejestrze zmian treści) musi zostać zatwierdzona przez Zamawiającego.

2.6.4. Budowa i wdrożenie SPI / CMS

1. Wykonawca zainstaluje i skonfiguruje infrastrukturę przeznaczoną do realizacji projektu.

2. Zamówienie musi być zrealizowane z wykorzystaniem udostępnionego do tego celu sprzętu komputerowego Zamawiającego oraz oprogramowania systemowego (z licencjami), którego opis zawiera pkt. 2.4.

3. Jeżeli do budowy środowiska wykonawca będzie potrzebował dodatkowych zasobów infrastruktury IT, to musi je dostarczyć w ramach tego zamówienia zgodnie z pkt 2.4 OPZ.

4. W ramach zamówienia wykonawca jest zobowiązany do dostarczenia następujących produktów i świadczenia następujących usług:

a. dostarczenie CMS, zapewnienie prawidłowej pracy tego systemu oraz spełnienie wymagań Zamawiającego. Zamawiający dopuszcza wykorzystanie licencji komercyjnych lub licencji „Open Source” pod warunkiem, że w przypadku zastosowania Oprogramowania „Open Source” wykonawca udzieli gwarancji oraz zapewni nadzór autorski nad CMS nie gorszy niż w przypadku porównywalnego oprogramowania komercyjnego, w okresie 3 lat od daty odbioru etapu III.

b. wdrożenie CMS, zgodnie z wymaganiami określonymi niniejszą SIWZ i projektem technicznym Systemu,

c. przeniesienie danych z obecnie eksploatowanego portalu do nowego CMS-a,

d. przygotowanie w ramach Portalu GUS strony lub komponentu z odpowiednio pogrupowanymi linkami do stron portalu Business Intelligence tworzonego w ramach SWAID. Strona ta powinna być zbudowana i działać zgodnie z najlepszymi praktykami budowania tego rodzaju interfejsów,

e. połączenie SPI ze wskazanymi systemami Zamawiającego i optymalizacja funkcjonowania SPI zgodnie z wymaganiami określonymi niniejszą SIWZ i projektem technicznym Systemu,

f. udzielenie lub przekazanie licencji lub sublicencji do Oprogramowania wytworzonego przez inne podmioty,

g. przekazanie autorskich praw majątkowych do Oprogramowania wytworzonego przez wykonawcę w ramach realizacji przedmiotu zamówienia.

2.6.5. Dokumentacja Wykonawca dostarczy następującą dokumentację:


administracji.19

2.6.5.1. Dokumentacja administratorów i użytkowników

W ramach wdrożenia wykonawca opracuje i dostarczy szczegółową instrukcję obsługi Sytemu dla redaktorów i administratorów CMS, zawierającą szczegółowy opis wszystkich funkcji i możliwości Systemu oraz przewodniki w formie How-to w postaci pytań, jak zrealizować określoną operację w Systemie i szczegółowych (krok po kroku wraz ze zrzutami z ekranu) odpowiedzi na nie.

CMS musi być wyposażony w dostępną z poziomu Systemu (dla administratorów i redaktorów) pomoc kontekstową.

2.6.5.2. Dokumentacja powykonawcza SPI/CMSW ramach wdrożenia wykonawca opracuje i dostarczy szczegółową dokumentację powykonawczą (m.in. instalacja, konfiguracja i parametryzacja systemu, struktura baz danych wraz z opisem przeznaczenia tabel i pól) oraz opis procedur i instrukcji eksploatacyjnych, a w szczególności procedury i instrukcje:

wykonania kopii Systemu i jej odtworzenia, bieżącego monitoringu oraz utrzymania Systemu, aktualizacji, postępowania w razie wystąpienia wad wraz z formularzami zgłoszeniowymi i

osobami kontaktowymi (nr telefonu, fax, e-mail) do konsultacji rozwiązywania zaistniałych problemów,

bieżącej analizy oraz archiwizowania zapisów systemów zabezpieczeń (logów).

2.6.5.3. Dokumentacja komponentów i oprogramowania standardowegoW ramach wdrożenia wykonawca dostarczy:

szczegółową dokumentację komponentów firm trzecich, jeżeli są używane w dostarczanym Systemie,

dokumentację oprogramowania standardowego, dostarczonego przez wykonawcę.

2.6.6. Testowanie i odbiór systemu W ramach zadania wykonawca:

1) Przygotuje i uzgodni z Zamawiającym Plan testów obejmujący co najmniej:a) zakres i harmonogram testów,b) wymagania dotyczące środowiska testowego,c) listę wraz z opisem proponowanych scenariuszy testowych,d) zbiory i dane testowe.

2) Przygotuje - przy współudziale Zamawiającego - środowisko testowe, które będzie wykorzystane również do przeprowadzenia testów akceptacyjnych i integracyjnych.

3) Przygotuje i przeprowadzi - przy współudziale Zamawiającego - testy akceptacyjne systemu zgodnie z uzgodnionymi scenariuszami testowymi.

4) Przygotuje i przeprowadzi - przy współudziale Zamawiającego - testy integracyjne systemu zgodnie z uzgodnionymi scenariuszami testowymi.

5) Dostarczy raporty z przeprowadzonych testów.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


20

2.6.7. Szkolenia

Szczegółowe wymagania dotyczące szkoleń znajdują się w punkcie 6.10 niniejszego dokumentu.

2.6.8. Asysta technicznaSzczegółowe wymagania dotyczące zasad świadczenia Asysty technicznej znajdują się w punkcie 3 niniejszego dokumentu.

2.6.9. Gwarancja Szczegółowe wymagania dotyczące zasad realizacji usług gwarancyjnych znajdują się w punkcie 4 niniejszego dokumentu.

2.6.10. Pomoc technicznaW okresie trwania gwarancji, w ramach wynagrodzenia określonego umową, wykonawca będzie udzielał pomocy Administratorom Technicznym Zamawiającego (Pomoc techniczna). Pomoc techniczna polegać będzie na odpowiadaniu na pytania Administratora Technicznego dotyczących problemów związanych z funkcjonowaniem, obsługą i eksploatacją Systemu. Pomoc udzielana będzie telefonicznie lub e-mailem Administratorom wskazanym na piśmie przez Zamawiającego.

3. Asysta technicznaWymagania w zakresie Asysty Technicznej:

1. Wykonawca będzie świadczył na rzecz Zamawiającego usługi Asysty Technicznej polegające na:

a) dostosowywaniu SPI do zmieniających się przepisów prawa,

b) dostosowywaniu SPI do zmieniającej się organizacji Zamawiającego,

c) rozwijaniu SPI o nowe funkcjonalności i modyfikacji Systemu,

d) wsparciu w zakresie utrzymania Systemu,

e) udzielaniu porad wskazanym pracownikom Zamawiającego.

2. Zamawiającemu przysługuje: a) pula usług w wysokości 200 roboczogodzin pracy pracowników wykonawcy w

okresie od daty podpisania Umowy do 30 listopada 2013 roku (Asysta Techniczna świadczona w okresie wdrożenia systemu),

b) pula usług w wysokości 1000 roboczogodzin pracy pracowników wykonawcy w okresie od daty podpisania Protokołu odbioru etapu III do 30 listopada 2015 r. (Asysta Techniczna świadczona po wdrożeniu Systemu).

3. Zamawiający będzie zlecał wykonawcy prace w ramach Asysty Technicznej w miarę potrzeb. Zamawiający będzie zlecał wykonawcy prace w ramach Asysty Technicznej określone w ust. 2 ppkt b) w przypadku dostępności środków budżetowych.

4. W przypadku nie wykorzystania przez Zamawiającego pełnych limitów godzin Asysty Technicznej, o których mowa w ust. 2, wartość umowy zostanie pomniejszona o


administracji.21

wartość niewykorzystanych godzin. Wykonawcy nie przysługuje z tego tytułu żadne roszczenia odszkodowawcze wobec Zamawiającego.

5. Rozliczenie usług Asysty Technicznej świadczonej:a) w okresie wdrożenia systemu nastąpi na dzień odbioru wykonania etapu III,b) po wdrożeniu systemu, będzie rozliczane w kolejnych okresach kwartalnych,

począwszy od dnia 1 grudnia 2013 r.6. Zamawiający wymaga, aby Asyście podlegały:

a) oprogramowanie wchodzące w skład Systemu, moduły, komponenty oraz mechanizmy integracji między nimi oraz z innymi systemami Zamawiającego,

b) konfiguracje, skrypty oraz autorskie rozwiązania wykonawcy stworzone bądź skonfigurowane w ramach oferty i modyfikowane za wiedzą i zgodą wykonawcy.

7. Wykonane przez wykonawcę w ramach asysty modyfikacje objęte są gwarancją na zasadach określonych dla przedmiotu zamówienia, w okresie świadczenia przez wykonawcę gwarancji dla wdrożonego Systemu.

8. Asysta będzie rozliczana z dokładnością do jednej roboczogodziny. Czas realizacji poszczególnych prac (realizowanych na podstawie odrębnych wniosków Zamawiającego) będzie zaokrąglany w górę z dokładnością do jednej roboczogodziny.

9. Asysta będzie świadczona w siedzibie Zamawiającego lub w miejscu wskazanym przez Zamawiającego.

10.Do obliczania wysokości wynagrodzenia dla wykonawcy za świadczenie usługi Asysty Technicznej stosowana będzie stawka za roboczogodzinę zgodnie z ceną podaną w ofercie.

11.W ramach usług w zakresie Asysty Technicznej do Zamawiającego zostanie przypisany dedykowany specjalista wykonawcy, który będzie odpowiedzialny za realizację usług w zakresie Asysty Technicznej dla Zamawiającego, a także za przekazywanie oraz otrzymywanie informacji i komentarzy zwrotnych dotyczących świadczonych usług.

12.W przypadku wystąpienia potrzeby skorzystania z Asysty Zamawiający skieruje do wykonawcy dokument „Wniosek o Asystę”. Wniosek taki zawierać będzie co najmniej: b) wymagane kwalifikacje pracowników wykonawcy, którzy będą realizowali Asystę, c) określenie proponowanego terminu i wymiaru godzin pełnienia Asysty.d) określenie miejsca wykonania usługi.a) proponowany zakres prac, b) wykaz pracowników wykonawcy, którzy będą uczestniczyli w pracach, wraz z

podaniem ich zakresu obowiązków, c) wycenę (w roboczogodzinach) pracochłonności, d) termin i wymiar godzin realizacji Asysty.

14.Wykonawca zrealizuje Asystę po otrzymaniu potwierdzenia „Propozycji Asysty” przez Zamawiającego. Nieprzedstawienie „Propozycji Asysty” w terminie 5 dni roboczych będzie traktowane jako zgoda na warunki zawarte we „Wniosku o Asystę” i możliwość realizacji asysty.

15.Po wykonaniu prac i uzyskaniu przez wykonawcę potwierdzenia ich wykonania przez Zamawiającego, wykonawca przedstawi dokument „Raport z Asysty”, zawierający co najmniej: b) liczbę godzin poświęconych na wykonanie prac,


administracji.22

c) całkowitą liczbę godzin Asysty zrealizowanych w ciągu trwania Asysty, których realizacja została potwierdzona przez Zamawiającego.

16.Realizacja Asysty na warunkach innych niż zaproponowane przez Zamawiającego we „Wniosku o Asystę” wymaga zatwierdzenia propozycji wykonawcy przez Zamawiającego.

17.Wykonawca ma prawo odmówić wykonania asysty, o ile:

a) Zamawiający wyczerpał przysługujący limit roboczogodzin lub zakończył się okres realizacji umowy,

b) realizacja Asysty w zaproponowanym zakresie spowodowałaby przekroczenie przysługującego Zamawiającemu limitu roboczogodzin Asysty,

c) realizacja usług Asysty wymagałaby złamania obowiązującego prawa.

18.Zamawiający umożliwi wykonawcy realizację usługi Asysty poprzez udostępnienie wymaganych zasobów technicznych oraz niezbędnych pracowników Zamawiającego.

19.W przypadku konieczności zmiany dokumentacji w wyniku wykonania usług Asysty wykonawca zobowiązany jest doręczyć zaktualizowaną dokumentację maksymalnie w dwa tygodnie po dostarczeniu przez wykonawcę „Raportu z Asysty”.

20.Po wykonaniu prac w danym kwartale trwania Asysty Technicznej i uzyskaniu przez wykonawcę potwierdzenia ich Wykonania przez Zamawiającego, wykonawca wystawi dokument „Kwartalny raport z Asysty” zawierający co najmniej:

a) opis wykonanych prac oraz osiągniętych rezultatów,

b) liczbę roboczogodzin poświęconych na wykonanie prac w danym kwartale z podziałem na poszczególne zlecenia,

c) liczbę roboczogodzin Asysty zrealizowanych dotychczas w ramach Asysty, których realizacja została potwierdzona przez Zamawiającego.

21.Każda nowa wersja SPI dostarczonego Zamawiającemu musi zawierać udokumentowany opis zmian w funkcjonalności w porównaniu z wersją poprzednią.

22.Wykonawca zobowiązuje się do wdrożenia aktualizacji lub nowych wersji SPI u Zamawiającego w sposób jak najmniej zakłócający bieżące użytkowanie.

4. Gwarancja1. Wykonawca zobowiązuje się do świadczenia usług gwarancyjnych przez okres

36 miesięcy od daty odbioru etapu III.

2. Zakres świadczeń obejmuje naprawę wszelkich wad Systemu, w szczególności: a) usuwanie wad Systemu, a w szczególności wad konfiguracji Systemu, b) odzyskiwanie informacji oraz programów komputerowych utraconych lub

uszkodzonych w wyniku wady Systemu, której przyczyna leżała po stronie działań oprogramowania dostarczonego lub skonfigurowanego przez wykonawcę


administracji.23

lub jakiegokolwiek innego komponentu oprogramowania, które było przedmiotem usług wykonawcy w zakresie parametryzacji i konfiguracji Systemu,

c) prowadzenie diagnostyki funkcjonowania Systemu, celem identyfikacji przyczyn powstawania wad Systemu przejawiających się w szczególności określoną wadą oprogramowania lub wadą konfiguracji Systemu.

3. Gwarancją nie są objęte wady spowodowane:a) obsługą Systemu przez Zamawiającego niezgodnie z dostarczoną dokumentacją,

w tym niezgodnie z procedurami administrowania systemem,b) stosowaniem Systemu przez Zamawiającego niezgodnie z wymaganiami

technicznymi określonymi w dokumentacji,c) użytkowaniem Systemu przez Zamawiającego do celów i w zakresie innym niż

określony w umowie.

4. Najpóźniej na 3 dni robocze przed planowanym terminem odbioru etapu III, Zamawiający i wykonawca wymienią się oświadczeniami zawierającymi aktualne listy odpowiednio Administratorów Technicznych, Pełnomocników, numerów telefonów, adresów poczty elektronicznej przeznaczonych do kierowania i przyjęcia Zgłoszenia Serwisowego. Od tego momentu Zamawiający i wykonawca zobowiązują się do bieżącego aktualizowania wymienionych oświadczeń w każdym przypadku wymagającym jakichkolwiek zmian. Jeżeli nie wymienią wskazanych powyżej oświadczeń obowiązujące są adresy do korespondencji wynikające z zapisów Umowy.

5. Szczegółowy opis Karty Zgłoszenia Serwisowego oraz opcjonalnie opis procedury zgłaszania i usuwania wad Systemu, uwzględniający wymagania zawarte w Umowie i niniejszym załączniku zostanie opracowany przez wykonawcę i przekazany Zamawiającemu do akceptacji, jako część opracowanego Projektu.

6. W przypadku nie zaakceptowania i nie wdrożenia przez Strony procedury zgłaszania i usuwania wad Systemu, Strony obowiązuje poniższa procedura:

a) Administrator techniczny lub osoba przez niego upoważniona powiadamia wykonawcę o wystąpieniu wady Systemu dokonując Zgłoszenia serwisowego.

b) Zgłoszenie serwisowe polega na przekazaniu do wykonawcy informacji o wadzie, jej zakresie, znanych przyczynach i skutkach. Przekazanie informacji może zostać dokonane za pośrednictwem poczty elektronicznej, z potwierdzeniem odczytania wiadomości.

7. Jeżeli w ciągu 30 minut od wysłania Zgłoszenia serwisowego wykonawca nie potwierdzi otrzymania Zgłoszenia serwisowego w taki sposób, jak zostało ono dokonane (informacja zwrotna) Zamawiający dokona powtórnego zgłoszenia telefonicznego. Brak reakcji ze strony wykonawcy w okresie 1 godziny roboczej od przesłania Zgłoszenia Serwisowego i przekazania – potwierdzenia takiego faktu telefonicznie nie zwalnia wykonawcy z obowiązku rozpoczęcia świadczeń, a dla Zamawiającego staje się skuteczny i wiążący tak samo jak potwierdzone przez wykonawcę Zgłoszenie Serwisowe.

8. W niezbędnych przypadkach, w interesie Zamawiającego, w szczególności dla bezpieczeństwa danych oraz utrzymania stabilności pracy Systemu, wykonawca przed rozpoczęciem świadczenia usługi w zakresie usuwania wady na etapie jej


administracji.24

diagnozowania, w tym diagnozowania zdalnego przez bezpieczne, tunelowane łącze z wykorzystaniem sieci Internet jest zobowiązany: a) uzyskać zgodę Administratora technicznego na wykonanie czynności związanych

z czynnym diagnozowaniem wady z wykorzystaniem sieci Internet,b) zwrócić się do Administratora technicznego o wykonanie czynności

zabezpieczających informacje.

9. Szczegółowe zasady umożliwiające zdalne diagnozowanie i naprawy wad winny być przedmiotem pisemnych ustaleń pomiędzy Zamawiającym i wykonawcą, w szczególności procedury postępowania i uwarunkowania techniczne.

10. Ostateczną decyzję o zabezpieczeniu informacji lub podjęciu innych czynności w celu zapewnienia stabilnej pracy Systemu podejmuje Administrator techniczny.

11. Po dokonaniu Zgłoszenia Serwisowego w opisany sposób, wykonawca przystępuje do zdiagnozowania i weryfikacji wady. W tym celu zabezpiecza rzeczywiste informacje mające bezpośredni związek z przyczyną Zgłoszenia Serwisowego oraz dokonuje uszczegółowienia opisu sytuacji przedstawionej przez Zamawiającego w Zgłoszeniu serwisowym. Na tej podstawie Administrator techniczny z wykonawcą uzgadniają ostateczną kwalifikację Wady. W przypadku nie uzgodnienia wspólnej, tej samej kwalifikacji wady w formie określonej Kategorii wady, przyjmuje się kwalifikację wady wskazaną przez Zamawiającego jako właściwą do podjęcia działań, a strony podejmują działania w zakresie ostatecznego rozstrzygnięcia kwestii sporu i polubownego rozwiązania problemu.

12. Jeżeli w trakcie świadczenia usług okaże się, że całkowite usunięcie wady, możliwe jest wyłącznie poprzez opracowanie poprawki do Systemu, wykonawca może wystąpić do Zamawiającego o zgodę na przesunięcie terminu naprawy wprowadzając jednocześnie jej obejście.

13. Usługi wykonawcy związane z usunięciem wady Systemu mogą być realizowane w siedzibie Zamawiającego lub zdalnie zgodnie z ustaloną procedurą.

14. Za utratę lub uszkodzenie Systemu podczas wykonywania czynności gwarancyjnych przez wykonawcę, odpowiedzialność ponosi wykonawca.

15. Czas usunięcia wady Systemu uznaje się za dotrzymany, jeżeli przed jego upływem Wada została usunięta lub wystąpiły warunki związane z zastosowaniem „obejścia” celem uzyskania rezultatu tożsamego usunięciu Wady lub czasowego wykluczenia występowania Wady Systemu.

16. Zastosowanie obejścia nie zwalnia wykonawcy z obowiązku skutecznego usunięcia wady.

17. Po dokonaniu naprawy wykonawca z Administratorem technicznym zobowiązani są do przygotowania i przeprowadzenia testów sprawdzających poprawność działania Systemu w zakresie przeprowadzonych modyfikacji. W przypadku uzyskania rezultatów potwierdzających poprawność wykonanej naprawy Strony przystępują do odbioru naprawy podpisując protokół odbioru w dwóch jednobrzmiących egzemplarzach, do których załączają wyniki z przeprowadzonych testów.


administracji.25

18. Zamawiający zobowiązuje się dołożyć należytych starań w celu umożliwienia wykonawcy świadczenia usług w zakresie usuwania wad Systemu, a w szczególności:a) udostępnić niezwłocznie możliwość korekty Systemu w zakresie Zgłoszenia

serwisowego, co w szczególności wiąże się z udostępnieniem Infrastruktury Technicznej oraz stanowisk komputerowych,

b) jeżeli jest to konieczne, udostępnić pomieszczenia, w których znajduje się Infrastruktura Techniczna, jeśli dostęp bezpośredni jest potrzebny do usunięcia wady Systemu,

c) zapewnić bezpośrednią obecność Administratora technicznego lub osoby przez niego upoważnionej posiadającej uprawnienie do podpisania protokołu naprawy,

d) w zależności od okoliczności, ograniczyć dostępność Systemu lub jego części dla użytkowników, celem uzyskania stabilnej pracy pozostałej części Systemu lub podjąć decyzję o czasowym zawieszeniu funkcjonowania Systemu na czas niezbędny do usunięcia wady.

19. W ramach świadczonych gwarancji wykonawca zobowiązany jest, nie rzadziej niż co 12 miesięcy, do przeprowadzenia przeglądu dostarczonego Systemu, w tym ostatni przegląd powinien nastąpić w ostatnim miesiącu obowiązywania gwarancji.

20. W przypadku jakichkolwiek rozbieżności stanowisk podczas realizacji niniejszej procedury, Strony powinny bez zwłoki poinformować Pełnomocników celem podjęcia przez nich czynności wyjaśniających, korygujących i ewentualnego przystąpienia do polubownego rozwiązania zaistniałego problemu (sporu).

21. Termin gwarancji ulega przedłużeniu o czas, w ciągu którego wskutek wady objętej gwarancją Zamawiający nie mógł korzystać z Systemu, nawet jeżeli dotyczyło to tylko części jego funkcjonalności.

22. W okresie gwarancji wykonawca zapewni aktualizację oprogramowania do najnowszej wersji. Nie jest dozwolona aktualizacja do wersji testowych.

Ogólne warunki gwarancji dla dostarczanego sprzętu1. Wykonawca gwarantuje, że dostarczony sprzęt jest zgodny z dokumentacją

techniczną, a warunki gwarancji są jednolite dla całej dostawy sprzętu.

2. Wykonawca gwarantuje poprawność działania sprzętu przez okres 36 miesięcy licząc od daty odbioru Etapu III.

3. Wykonawca jest zobowiązany do nieodpłatnych przeglądów i konserwacji sprzętu, jeśli są one wymagane przez producenta, oraz do napraw sprzętu poprzez oferowaną sieć serwisową, w siedzibie Zamawiającego. Nieodpłatność obejmuje zarówno robociznę, jak i uszkodzone lub zużyte części zamienne.

4. Zgłoszenia wad muszą być przyjmowane w dni robocze w godzinach 8-17, a zakończenie naprawy (względnie dostarczenie równoważnego sprzętu zastępczego) winno nastąpić najpóźniej w ciągu trzech dni roboczych od zgłoszenia wady. Czas naprawy, od zgłoszenia wady do jej zakończenia, jest wyłączony z okresu gwarancyjnego.


administracji.26

5. W sytuacji niemożliwości dokonania naprawy do końca następnego dnia roboczego od przyjęcia zgłoszenia wady, Zamawiający otrzyma urządzenie zastępcze o zbliżonych parametrach realizujące te same funkcje w Systemie.

6. W przypadku nie wywiązania się wykonawcy ze zobowiązań wynikających z ust. 3 Zamawiający może dokonać tych czynności we własnym zakresie, a kosztami obciążyć wykonawcę z wykorzystaniem kwoty zabezpieczenia należytego wykonania Umowy.

7. Gwarancja obejmuje bezpłatną aktualizację BIOS-u, oprogramowania sprzętowego oraz sterowników w czasie trwania okresu gwarancyjnego.

8. Zapisy karty gwarancyjnej, jeśli jest zastosowana, sprzeczne z niniejszymi postanowieniami i Umową są nieważne.

9. W przypadku uszkodzenia nośników danych, w sposób, który uniemożliwia dostęp do zawartych na nich danych, wykonawca zobowiązuje się do wymiany uszkodzonego nośnika na nowy. Uszkodzony nośnik danych pozostaje w siedzibie Zamawiającego.

10.Zasady dotyczące danych określone w ust. 9 dotyczą również naprawy sprzętu poza siedzibą użytkownika, niezależnie od tego, jakiego elementu urządzenia naprawa będzie dotyczyła.

11.Wykonawca zobowiązany jest do wymiany sprzętu na nowy, o nie gorszych parametrach, w przypadku nie wykonania naprawy w terminie 30 dni od zgłoszenia wady przez Zamawiającego oraz w przypadku ponownego wystąpienia wady po wykonaniu trzech napraw dotyczących tego samego sprzętu.


administracji.27

5. Organizacja i zasady zarządzania ProjektemZarządzanie projektem winno być wyłącznie w zakresie koniecznym do prawidłowego i terminowego wykonania zamówienia. Działania zarządcze wykonawca powinien opierać na przyjętych standardach jakościowych, dobrych praktykach i metodykach zarządzania projektem, przy czym wynikający z tego tytułu zakres zobowiązań Zamawiającego nie powinien przekraczać zakresu przewidzianego koniecznym jego współdziałaniem (w realizacji zamówienia) określonym w Umowie.

Organizacja i zasady zarządzania projektem powinny być oparte o metodykę opartą o następujące pryncypia:

1. Zachowanie ciągłości zasadności biznesowej Projektu.2. Zarządzanie poprzez zdefiniowane role i obowiązki struktur zarządczych

Projektu.3. Zarządzanie etapowe.4. Zarządzanie z wykorzystaniem tolerancji.5. Koncentracja na zdefiniowaniu i dostarczeniu produktów spełniających określone

dla nich wymagania jakościowe.

W celu zapewnienia sprawnej i prawidłowej realizacji zamówienia w ramach współdziałania stron, w terminie 7 dni licząc od daty podpisania Umowy, Zamawiający i wykonawca powołają struktury zarządcze Projektu, w szczególności Komitet Sterujący oraz Kierownika Projektu.

Do zadań Komitetu Sterującego w szczególności należy:

definiowanie celów realizowanego Projektu; okresowa i etapowa ocena stanu Projektu; ustalanie tolerancji dla każdego etapu oraz zatwierdzanie Planów etapów; zatwierdzanie Planów Nadzwyczajnych; zapewnianie, aby ryzyka podlegały monitorowaniu, były zarządzane

efektywnie; nadzorowanie prawidłowości dostarczenia wszystkich produktów Projektu; nadzorowanie spełnienia wszystkich kryteriów akceptacji.

W skład Komitetu wejdą:

1. Przewodniczący Komitetu Sterującego reprezentujący Zamawiającego, odpowiadający za:

monitorowanie i kontrolę postępu Projektu na poziomie strategicznym; zwoływanie i przewodniczenie obradom Komitetu Sterującego; podejmowanie decyzji dotyczących terminów i zasad przydzielania

wymaganych zasobów dla realizacji Projektu; rozstrzyganie kwestii spornych powstałych w ramach realizacji Projektu.

2. Główny Użytkownik reprezentujący Zamawiającego, w szczególności odpowiadający za:


administracji.28

dokonywanie przeglądu korzyści w celu monitorowania stopnia osiągnięcia założonych korzyści biznesowych;

zdefiniowanie wymagań funkcjonalnych i architektury korporacyjnej oraz innych parametrów technicznych, a także wyznaczenie ich zakresu organizacyjnego i merytorycznego;

bieżące monitorowanie postępów prac pod kątem zgodności realizacji Projektu z opracowanymi i przekazanymi do Głównego Dostawcy wymaganiami, przekazywanie informacji do Przewodniczącego w tym zakresie oraz przekładanie rekomendacji działań mających na celu zminimalizowanie powstania rozbieżności na każdym etapie realizacji Projektu;

przygotowanie założeń i wymagań poszczególnych zamówień realizowanych w ramach Projektu;

współpracę z użytkownikami instytucjonalnymi produktów Projektu na wszystkich etapach pracy, w tym zbieranie danych i informacji niezbędnych do jego realizacji;

zapewnienie specjalistycznych zasobów niezbędnych do specyfikowania potrzeb użytkowników Projektu;

monitorowanie realizacji Projektu, w tym, w zakresie poziomu zaspokojenia potrzeb użytkowników Projektu;

udział w przygotowaniu i przeprowadzeniu testów funkcjonalnych oraz akceptacyjnych wytworzonych produktów;

zapewnienie uruchomienia produkcyjnego produktów Projektu; zapewnienie rozwiązań organizacyjnych niezbędnych do utrzymania

i eksploatacji produktów Projektu.

3. Główny Dostawca reprezentujący wykonawcę, w szczególności odpowiadający za:

jakość i integralność podejścia specjalistycznego oraz produktów specjalistycznych wytwarzanych dla Projektu;

ocenę możliwości realizacji Projektu na podstawie wymagań zdefiniowanych przez Głównego Użytkownika, w szczególności w aspekcie aktualnych rozwiązań technologicznych oraz bezpieczeństwa systemów teleinformatycznych;

realizację Projektu na podstawie wymagań zdefiniowanych przez Głównego Użytkownika;

koordynację całości prac realizowanych w ramach Projektu, w szczególności w zakresie terminowej realizacji zadań wynikających z harmonogramu;

sygnalizowanie Komitetowi Sterującemu konieczności zmian harmonogramu; sporządzanie comiesięcznych sprawozdań z realizacji Projektu

dla Przewodniczącego Komitetu Sterującemu; zapewnienie uruchomienia do wykorzystania przez Kierownika i umożliwienie

wglądu dla Komitetu Sterującemu, elektronicznego repozytorium dokumentów projektowych;

monitorowanie przeszkód faktycznych i prawnych uniemożliwiających lub utrudniających realizację świadczonych usług w ramach Projektu.


administracji.29

Kierownik Projektu reprezentujący Zamawiającego, w szczególności odpowiada za:

kierowanie Projektem zgodnie z wytycznymi Komitetu Sterującego; zarządzanie Projektem zgodnie z przyjętą metodyką tak, aby projekt

wytworzył zdefiniowane produkty w ramach określonych tolerancji: czasu, kosztów, zakresu, jakości, ryzyka i korzyści;

to, aby Projekt spełniał założone korzyści biznesowe; przepływy informacji pomiędzy poziomem zarządzania strategicznego

i poziomem dostawczym lub wytwórczym Projektu; terminowe składanie Komitetowi Sterującemu produktów zarządczych; ustanawianie i zarządzanie mechanizmami sterowania Projektem.

W terminie 14 dni licząc od daty podpisania Umowy, Komitet Sterujący sporządzi i przyjmie do realizacji Plan Zarządzania Projektem zgodny z powyżej przedstawionymi pryncypiami, w szczególności:

1. Definiujący Strukturę zarządczą projektu, doprecyzuje role i obowiązki Komitetu Sterującego, Kierownika Projektu.

2. Określający zasady funkcjonowania Nadzoru Projektu, Obsługi Zmian, Wsparcia Projektu oraz powoływania Zespołów Wykonawczych.

3. Definiujący produkty zarządcze Projektu.


administracji.30

6. Wymagania dotyczące SPI oraz CMS6.1. Opis grup wymagań

Wymagania dotyczące SPI i CMS zostały podzielone na następujące grupy: OZ - ograniczenia, założenia i zależności, IZ - interfejsy zewnętrzne, F - wymagania funkcjonalne, B - wymagania techniczne i bezpieczeństwa, U - użyteczność, estetyka, ergonomia i dostępność, W - wydajność, SK - szkolenia, M - migracja danych, T - testy.

Każde wymaganie w ramach ww. grup posiada identyfikator (ID) jednoznacznie je identyfikujący, nazwę określającą ogólnie zagadnienie, którego dotyczy wymaganie oraz szczegółowy opis.ID składa się z dwóch członów:

litery oznaczającej obszar tematyczny, do której należy wymaganie, kolejnej liczby identyfikującej wymaganie w ramach danej grupy wymagań (F

1, F 2).Jeżeli wymaganie zostało uszczegółowione za pomocą punktów (1. … 2. …. 3. ….) odwołując się do nich należy do oznaczenia wymagania dodać numer danego punktu (np. F 5.1).

Uwaga:Jeżeli w dokumencie użyte zostaną określenia typu: o określonej porze, dla zdefiniowanej/wskazanej grupy/użytkownika itp. należy je rozumieć jako możliwe do ustawienia w systemie przez uprawionego Użytkownika.

6.2. Charakterystyka użytkowników CMSNazwa roli Charakterystyka

Administrator techniczny

Osoba zajmująca się zarządzaniem całością lub wydzieloną częścią Systemu, odpowiadająca za jego sprawne działanie, do której zadań należy instalacja i aktualizacja oprogramowania systemowego (system operacyjny), narzędziowego i użytkowego (w tym m.in. CMS), konfiguracja oprogramowania.

Administrator merytoryczny

Osoba posiadająca pełne uprawnienia administracyjne do CMS, w tym m.in. do dodawania i usuwania kont użytkowników, parametryzowania i pełnego zarządzania strukturą i wyglądem serwisu, zarządzania modułami tematycznymi, szablonami itp.

Redaktor Osoba merytorycznie przygotowująca dane do publikacji w serwisie. Zbiera, opracowuje i przygotowuje artykuły do publikacji w serwisie.


administracji.31

Redaktor Zatwierdzający

Osoba merytorycznie nadzorująca pracę wybranych redaktorów. Dokonuje ewentualnej modyfikacji i akceptuje materiały do publikacji.

Visitor Osoba mająca uprawnienia jedynie do podglądu w CMS przygotowanej strony.

Uwaga: osoba może pełnić jedną lub kilka ról w systemie.Prace związane z konfiguracją i nadzorowaniem pracy serwerów, dbaniem o bezpieczeństwo systemu, tworzeniem kopii zapasowych systemu, nadzorowaniem i eliminowaniem nieprawidłowości w jego działaniu wykonywać będzie Centrum Informatyki Statystycznej.

6.3. Charakterystyka użytkowników portalu internetowego GUSNazwa roli Charakterystyka

Użytkownik Każda osoba korzystająca z serwisu internetowego, nie posiadająca zarejestrowanego konta w serwisie.

Użytkownik zarejestrowany

Osoba korzystająca z serwisu internetowego, która zarejestrowała się zakładając konto w serwisie.Konto pozwala na zmianę danych osobowych, otrzymywanie np. newslettera, dostęp do wybranych fragmentów serwisu przeznaczonych dla zarejestrowanych użytkowników serwisu, personalizacje widoku wybranych stron internetowych.

6.4. Ograniczenia, założenia i zależnościID OZ 1. Nazwa Zgodność z obowiązującymi przepisami prawaOpis Dostarczony system (w szczególności serwisy BIP ) musi być zgodny

z obowiązującymi aktami prawnymi mającymi wpływ na jego działanie i realizowaną funkcjonalność:

1. Ustawa o dostępie do informacji publicznej (Dz. U. z 2001 r. Nr 112, poz. 1198, z późn. zm.).

2. Ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U.05.64.565) z późn. zm.

3. Ustawa o ogłaszaniu aktów normatywnych i niektórych innych aktów prawnych (Dz. U. z 2011 r. Nr 197, poz. 1172).

4. Ustawa o statystyce publicznej (Dz. U. z 2012 r. poz. 591).5. Ustawa o ochronie danych osobowych (Dz. U. z 2002 r. Nr 101,

poz. 926).6. Rozporządzenie Rady Ministrów w sprawie Krajowych Ram

Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2012 r. poz. 526)

7. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji w sprawie Biuletynu Informacji Publicznej (Dz. U. z 2007 Nr 10, poz. 68).


administracji.32

8. Rozporządzenie Prezesa Rady Ministrów w sprawie wymagań technicznych dla dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, dzienników urzędowych wydawanych w postaci elektronicznej oraz środków komunikacji elektronicznej i informatycznych nośników danych (Dz. U. z 2011 r. Nr 289, poz. 1699).

9. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do identyfikacji użytkowników (Dz. U. z 2011 r. Nr 93, poz. 545).

ID OZ 2. Nazwa Dostosowanie do zmian prawaOpis 1. Wykonawca zobowiązany jest do dostosowania systemu (w

szczególności serwisów BIP) do zmian aktów prawnych mających wpływ na dostarczony system i realizowaną przez niego funkcjonalność w ramach świadczonych usług asysty technicznej/serwisu, bez prawa do dodatkowego wynagrodzenia z tego tytułu.

2. System musi być dostosowany do zmian aktów prawnych przed ich wejściem w życie.

ID OZ 3. Nazwa Dostęp do Systemu przez przeglądarki Opis Pełna funkcjonalność systemu (dla redaktorów i administratorów) musi

być dostępna przez wiodące przeglądarki (Internet Explorer, Mozilla Firefox, Opera, Chrome od wersji najnowszej do trzech wersji wstecz1) bez potrzeby instalowania na stacji roboczej użytkownika jakiegokolwiek oprogramowania nie będącego częścią przeglądarki internetowej.

ID OZ 4. Nazwa Terminy prac instalacyjnych, konfiguracyjnych, serwisowych i gwarancyjnych

Opis 1. Wszystkie przeprowadzane przez wykonawcę prace instalacyjne, konfiguracyjne, serwisowe i gwarancyjne muszą odbywać się przy udziale lub nadzorze wyznaczonych pracowników Zamawiającego, w godzinach 8.15-16.15 w dni robocze.

2. Jeżeli niezbędne okażą się działania wymagające wyłączania urządzeń środowiska produkcyjnego z bieżącej pracy muszą być przeprowadzane po godz. 16.00. lub w dni wolne od pracy. Zaistnienie takiej sytuacji musi zostać uzgodnione i zaakceptowane przez Zamawiającego na co najmniej 2 dni robocze przed planowanym terminem z podaniem przyczyny, zakresu prac oraz

1 W przypadku Internet Explorer nie jest wymagane dostosowanie do wersji 6Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


33

listy osób wykonawcy wyznaczonych do ich przeprowadzenia.

6.5. Interfejsy zewnętrzneID IZ 1. Nazwa Integracja z systemem poczty elektronicznejOpis CMS musi zostać zintegrowany z posiadanym aktualnie przez GUS

systemem pocztowym korzystając ze standardowych protokołów POP3 i SMTP.

ID IZ 2. Nazwa Integracja z ActiveDirectoryOpis 1. CMS musi posiadać opcję integracji z funkcjonującą u

Zamawiającego usługą katalogową ActiveDirectory.2. CMS musi umożliwiać pobieranie danych o użytkownikach z bazy

ActiveDirectory i ich uwierzytelnianie w oparciu o hasło w niej przechowywane.

3. Administrator merytoryczny musi posiadać możliwość wskazania, którzy użytkownicy są uwierzytelniani w oparciu o ActiveDirectory, a którzy w oparciu o lokalną bazę haseł.

ID IZ 3. Nazwa Serwery DNS i NTPOpis 1. CMS musi korzystać z serwera DNS Zamawiającego.

2. CMS musi zapewniać synchronizację zegara systemowego ze źródłami czasu za pomocą protokołu NTP lub mechanizmów Active Directory w celu utrzymania wiarygodności logów systemowych.

ID IZ 4. Nazwa Korzystanie z innych źródeł danychOpis 1. CMS musi umożliwiać włączenie nowych źródeł informacji

dostępnych w formie elektronicznej poprzez zapewnienie obsługi Web Services zgodnie z protokołem SOAP.

2. CMS musi zapewniać obsługę źródeł danych z wykorzystaniem mechanizmów ODBC.

3. CMS musi zapewniać możliwość dołączenia nowych źródeł danych wraz z definiowaniem zasad ich technicznej obsługi (dostępu do danych).

4. W przypadku wymiany dokumentów w formacie XML system będzie używać standardu XSD do ich weryfikacji.

ID IZ 5. Nazwa Połączenie SPI z Systemem Edukacyjnym (SE)Opis SPI musi posiadać usługę sieciową dedykowaną dla SE (WebService

opisany za pomocą języka opisu usług sieciowych WSDL) służącą do pobierania informacji z SE. Szczegółowa specyfikacja tej usługi zostanie określona na etapie analizy funkcjonalności.


administracji.34

ID IZ 6. Nazwa Połączenie SPI z system SWAIDOpis 1. SPI musi zapewniać prawidłowe funkcjonowanie linków do

raportów udostępnionych w ramach SWAID.2. SPI musi wykrywać nieaktywne linki. 3. SPI musi zapewniać pobieranie danych (tytuły raportów

dynamicznych, słowa kluczowe) w formacie xml z systemu SWAiD.

ID IZ 7. Nazwa Połączenie SPI z systemami obsługującymi rejestry REGON i TERYT

Opis SPI musi umożliwiać prezentowanie informacji z rejestrów REGON i TERYT przy wykorzystaniu linków do stron internetowych zawierających interfejsy odpowiednich systemów, gdzie możliwe będzie przeglądanie tych rejestrów lub wyszukiwanie określonych danych.

ID IZ 8. Nazwa Połączenie SPI z systemem SMSOpis SPI musi zapewniać dostęp do informacji zgromadzonych systemie

SMS (np. klasyfikacji, definicji pojęć).

ID IZ 9. Nazwa Publikacja statusu sprawy w BIP Opis 1. CMS musi posiadać usługę sieciową dedykowaną dla BIP

(WebService opisany za pomocą języka opisu usług sieciowych WSDL), służącą do przesyłania metadanych i plików z innego systemu. Szczegółowa specyfikacja tej usługi zostanie określona na etapie analizy funkcjonalności.

2. Pobrane informacje muszą podlegać systemowi zatwierdzania publikacji i zmian oraz zapewniać wydzielony widok elementów wymagających zatwierdzenia.

ID IZ 10. Nazwa Prezentowanie widgetów Eurostatu w SPIOpis SPI musi umożliwiać wklejanie do kodu dowolnej strony w ramach SPI

kodu widgetu, co powinno umożliwić jego prawidłowe wyświetlanie i działanie.

6.6. Wymagania funkcjonalneID F 1. Nazwa Interfejs dostępu do dynamicznych raportów i grup

raportów udostępnianych przez portal SWAIDOpis 1. SPI musi utworzyć komponent w formie drzewa katalogów,

pozwalający na dodawanie w „liściach” drzewa linków do stron portalu SWAiD. Drzewo musi być pogrupowane w sposób czytelny i intuicyjny dla użytkownika zewnętrznego.


administracji.35

2. SPI powinien zapewniać administratorom łatwe dodawanie i usuwanie folderów w ramach drzewa oraz edycję ich nazw oraz słów kluczowych.

3. System musi umożliwiać dodawanie do danego katalogu wielu linków do portalu SWAID naraz.

4. SPI musi zapewniać administratorom łatwe przenoszenie linków do portalu SWAiD i folderów zawierających grupy linków w ramach drzewa (edycja metodą przeciągnij i upuść).

5. SPI musi umożliwiać tworzenie łączy do portalu SWAID z dowolnej strony w ramach CMS.

ID F 2. Nazwa Serwisy tematyczneOpis System musi zapewnić możliwość tworzenia i uruchamiania dowolnej

liczby niezależnych serwisów tematycznych, które uruchamiane będą na własnych adresach internetowych (domenach lub subdomenach). Serwisy muszą posiadać możliwość utworzenia własnej, niezależnej szaty graficznej i struktury kategorii strony.

ID F 3. Nazwa Szablony i wygląd serwisuOpis 1. Wygląd serwisu (grafika, rozkład treści, typografia itp.) musi być

definiowany w oparciu o system szablonów.2. CMS musi umożliwiać definiowanie indywidualnych szablonów dla

poszczególnych kategorii serwisu, artykułów, list i zajawek artykułów, bloków funkcjonalnych przy zachowaniu ogólnie przyjętego stylu dla całości serwisu. Administrator merytoryczny musi mieć możliwość zmiany sposobu prezentacji wszystkich elementów widocznych na stronie internetowej dla użytkowników serwisów.

3. CMS musi umożliwiać wyłączanie poszczególnych bloków funkcjonalnych (jak np. wyszukiwarka, sonda, itp.) zdefiniowanych w ramach szablonu tak, by nie były one pokazywane w wybranych kategoriach serwisu. System musi posiadać konfigurowalny układ logiczny i interfejs.

4. CMS musi umożliwiać zmianę i modyfikację szablonów serwisu (wygląd i nawigacja) bez ingerencji w publikowane treści, tj. zmiana wyglądu nie będzie pociągała za sobą konieczności odtwarzania treści serwisu. System musi mieć oddzieloną warstwę administracyjną od treści strony.

5. CMS musi umożliwiać zarządzanie szablonami stron (tworzenie, edycja i modyfikacja oraz usuwanie szablonów).

6. CMS musi umożliwiać tworzenie nowych pozycji menu oraz dowolne przenoszenie pozycji menu względem siebie w danej kategorii oraz kategorii względem innych kategorii.

7. CMS musi umożliwiać współdzielenie/rozpowszechnianie szablonów w całym systemie oraz umożliwiać upowszechnianie


administracji.36

zmian i modyfikacji wykonanych w szablonie źródłowym na serwisy współdzielące szablon.

ID F 4. Nazwa Publikacja tej samej treści w różnych serwisach i/lub kategoriach

Opis 1. CMS musi zapewniać możliwość publikowania tej samej treści w kilku serwisach i/lub kategoriach przy zachowaniu funkcjonalności, która pozwoli na edycję treści w jednym wybranym - jako źródłowym miejscu. Treść w innych miejscach będzie automatycznie aktualizowana na podstawie zmian wprowadzonych w treści źródłowej.

2. CMS musi posiadać funkcję automatycznego przenoszenia poprzednich wersji artykułów, publikacji, notatek, komunikatów itp. do archiwum po opublikowaniu nowszych wersji tychże publikacji. Do archiwum musi być przenoszona cała zawartość danej strony, włącznie np. z plikami do pobrania.

3. W przypadku często aktualizowanych informacji (w cyklu miesięcznym lub kwartalnym) archiwum powinno być podzielone na lata.

4. CMS musi zapewniać możliwość tworzenia w różnych serwisach odnośników.

ID F 5. Nazwa Repozytorium plikówOpis 1. CMS musi posiadać repozytorium plików (tekstowych, graficznych,

jak i multimedialnych wykorzystywanych przy budowie serwisów).Zasoby repozytorium będą mogły być wykorzystywane wielokrotnie w różnych miejscach serwisu tak, by zmiana ilustracji czy dokumentu dołączonego do wielu stron serwisu polegała tylko na zamianie pojedynczego pliku w repozytorium, a zawartość stron wykorzystujących dany plik musi podlegać ponownej weryfikacji i publikacji.

2. CMS musi umożliwiać dostęp do repozytorium plików lub jego części zgodnie z przyznanymi uprawnieniami w celu umieszczania plików na stronach serwisu, dodawania nowych oraz usuwania zbędnych. Pliki gromadzone będą w sposób umożliwiający swobodne ich przeglądanie, grupowanie (w katalogi, podkatalogi) i sortowanie przez uprawionych redaktorów.

3. Repozytorium musi umożliwiać uprawnionemu użytkownikowi co najmniej: tworzenie, kopiowanie, usuwanie katalogów i podkatalogów, dodawanie, kopiowanie, przenoszenie, podgląd oraz usuwanie

plików, dodawanie metadanych opisujących plik (m.in. „długi tytuł”, opis

pliku, słowa kluczowe), edytowanie parametru „alt” dla plików graficznych,


administracji.37

zmianę nazwy pliku, podmianę pliku na inną wersję, sortowanie wg nazwy, typu, wielkości, daty dodania, wyszukiwanie plików po nazwie pliku lub fragmencie nazwy.

4. CMS musi umożliwiać wgrywanie do repozytorium wielu plików naraz.

5. Pliki graficzne umieszczane w repozytorium serwisu muszą podlegać normalizacji zgodnie z konfiguracją w zakresie rozmiaru miniaturki oraz rozmiaru zdjęcia, tj. konwersji do określonego wymiaru i stopnia kompresji, zarówno dla miniaturki, jak i dla samego zdjęcia. System musi, w razie potrzeby, umożliwiać opublikowanie zdjęcia w oryginalnym rozmiarze.

6. CMS powinien umożliwiać automatyczne tworzenie linków (na podstawie nazwy plików, z możliwością późniejszej zmiany) do wgrywanych plików na aktualnie edytowanej stronie internetowej.

7. CMS musi umożliwiać wykrywanie plików, które nie są już używane (nie prowadzą do nich linki ani z aktualnych stron, ani z archiwum) i stwarzać administratorowi merytorycznemu wygodny interfejs do zarządzania takimi plikami.

8. CMS musi pokazywać użycie pliku: zbiorcze zestawienie miejsc, w których występuje dany plik z linkiem odsyłającym do danego miejsca w strukturze systemu.

ID F 6. Nazwa Odtwarzacz wideo/audioOpis 1. CMS musi posiadać dedykowany i zintegrowany odtwarzacz

umożliwiający odtworzenie bezpośrednio na stronie materiałów multimedialnych (audio, video). Odtwarzacz musi opierać się na technologii HTML 5.0 i obsługiwać co najmniej format AVI, FLV, WMV, MP3, MP4 (niezależnie od zastosowanych formatów kodowania plików).

2. CMS musi umożliwiać publikowanie odtwarzacza plików multimedialnych (audio, video) w wybranych miejscach strony lub bezpośrednio w treści artykułów.

3. Musi istnieć możliwość określenia, czy materiał jest odtwarzany automatycznie po załadowaniu strony, czy po wybraniu przez użytkownika przycisku „play” odtwarzacza.

4. Odtwarzacz musi prezentować długość (czas odtwarzania) materiału, stan wczytywania pliku multimedialnego, musi umożliwiać zatrzymanie i przewinięcie materiału oraz - dla materiałów wideo - odtwarzanie w trybie pełnego ekranu. Opcjonalnie musi być dostępna możliwość pobrania materiału multimedialnego na komputer użytkownika serwisu. Odtwarzacz musi mieć możliwość wyboru dla materiałów wideo obrazu (kadru z filmu lub zdjęcia) wyświetlanego przed rozpoczęciem odtwarzania pliku. Odtwarzacz


administracji.38

musi posiadać możliwość umieszczenia tytułu materiału, krótkiego opisu oraz opcjonalnego linku (adresu URL).

5. Odtwarzacz musi mieć możliwość pobierania listy innych plików multimedialnych i prezentować taką listę w postaci tytułów i miniatur graficznych na zakończenie odtwarzania pliku multimedialnego. CMS musi przygotowywać taką listę dla wszystkich materiałów wideo dodanych do serwisu.

6. CMS musi posiadać możliwość stworzenia bloku funkcjonalnego prezentującego najnowsze materiały wideo w postaci listy zajawek (zawierającej tytuł materiału, element graficzny oraz link do materiału).

ID F 7. Nazwa Galerie zdjęćOpis 1. CMS musi posiadać możliwość prezentowania załączników

graficznych (zdjęć, ilustracji, itp.) w postaci galerii.2. CMS musi mieć możliwość prezentacji galerii jako wydzielonych

stron serwisu oraz w ramach artykułów (np. działu aktualności).3. Galeria musi być prezentowana w postaci miniatur z możliwością

otworzenia powiększenia. 4. Z widoku powiększenia musi być możliwość przeglądania

kolejnych powiększeń zdjęć w galerii. 5. CMS musi posiadać możliwość otworzenia pliku powiększenia

zdjęcia przy wyłączonej w przeglądarce obsłudze JavaScript.6. Musi istnieć możliwość zamieszczania podpisów zdjęć, przy

rozdzieleniu podpisu od atrybutu „alt” przypisanego do pliku graficznego.

7. CMS musi posiadać możliwość stworzenia bloku funkcjonalnego prezentującego wybrane galerie zdjęć w postaci listy zajawek (zawierającej tytuł galerii, wybrany element graficzny oraz link do galerii).

8. CMS musi posiadać możliwość stworzenia bloku funkcjonalnego prezentującego najnowsze galerie zdjęć w postaci listy zajawek (zawierającej tytuł galerii, wybrany element graficzny oraz link do galerii).

9. Pliki graficzne zamieszczane w galerii muszą podlegać normalizacji zgodnie z konfiguracją w zakresie rozmiaru miniaturki oraz rozmiaru zdjęcia tj. konwersji do określonego wymiaru i stopnia kompresji, zarówno dla miniaturki, jak i dla samego zdjęcia.

10.CMS musi umożliwiać zaawansowaną edycję zdjęć bezpośrednio w systemie, m.in.: skalowanie, kadrowanie, obrót, dodawanie tekstu na obrazku.

ID F 8. Nazwa ArtykułOpis 1. Artykuł ma posiadać co najmniej następujące elementy:

a) tytuł artykułu,


administracji.39

b) tytuł alternatywny (po wpisaniu tytułu alternatywnego ma być on widoczny, a tytuł artykułu ma być wtedy niewidoczny),

c) część zasadniczą artykułu zawierającą możliwość wstawienia treści oraz obiektów multimedialnych (audio, video, grafika itp.) i stronicowania artykułu,

d) miejsce i datę,e) krótki opis (wykorzystywany w tabeli dokumentów

tematycznych),f) możliwość wskazania kategorii, w której powinien zostać

opublikowany, g) słowa kluczowe,h) przyjazny link (adres URL) do artykułu (tworzony automatycznie

na podstawie tytułu z możliwością modyfikacji),i) zajawkę,j) obraz,k) odsyłacz do archiwum,l) załącznik lub kilka załączników do pobrania.

2. Opcjonalnie musi istnieć możliwość dołączania do artykułów elementów multimedialnych w postaci odtwarzacza wideo/audio i galerii zdjęć, załączników w postaci plików do pobrania (pliki muszą mieć możliwość określenia nazwy oraz opisu) oraz linków (z możliwością określenia nazwy i adresu URL). Sposób prezentacji ma być określony za pomocą predefiniowanych szablonów. CMS musi pozwalać na wybór załączników i linków, które będą prezentowane w ramach zajawki na listach zajawek artykułów.

ID F 9. Nazwa Artykuł BIPOpis Artykuł BIP powinien posiadać co najmniej następujące elementy:

tytuł artykułu, tytuł alternatywny, słowa kluczowe, część zasadniczą artykułu zawierającą możliwość wstawienia

treści oraz obiektów multimedialnych (audio, video, grafika itp.) i stronicowania artykułu,

możliwość wskazania kategorii, w której powinien zostać opublikowany artykuł,

zajawkę, przyjazny link (adres URL) do artykułu (tworzony automatycznie

na podstawie tytułu z możliwością modyfikacji), załącznik do pobrania.

Artykuł (w wersji polskiej serwisu) powinien posiadać metrykę zmian treści, składającą się m.in. z pól: podmiot publikujący, osoba odpowiedzialna za treść informacji, osoba publikująca informację, data wytworzenia informacji, data publikacji informacji, data aktualizacji informacji.


administracji.40

ID F 10. Nazwa Oferta pracy BIPOpis Oferta pracy BIP powinna posiadać co najmniej następujące elementy:

tytuł oferty, tytuł alternatywny oferty, słowa kluczowe, określenie urzędu dokonującego rekrutacji (wybór z listy

jednostek statystyki publicznej), wymiar i miejsce pracy, opis stanowiska pracy, załączniki do pobrania (np. wzory oświadczeń wymagane w

procesie rekrutacyjnym).Oferta BIP powinna posiadać metrykę zmian treści, składającą się m.in. z pól: podmiot publikujący, osoba odpowiedzialna za treść informacji, osoba publikująca informację, data wytworzenia informacji, data publikacji informacji, data aktualizacji informacji.

ID F 11. Nazwa Lista kandydatów BIPOpis Lista kandydatów BIP powinna posiadać co najmniej następujące

elementy: tytuł listy kandydatów, tytuł alternatywny listy kandydatów, słowa kluczowe, określenie urzędu dokonującego rekrutacji (wybór z listy

jednostek statystyki publicznej), część zasadniczą z treścią/miejscem na tabelę z listą

kandydatów.Lista kandydatów BIP powinna posiadać metrykę zmian treści, składającą się m.in. z pól: podmiot publikujący, osoba odpowiedzialna za treść informacji, osoba publikująca informację, data wytworzenia informacji, data publikacji informacji, data aktualizacji informacji.

ID F 12. Nazwa Wynik naboru BIPOpis Wynik naboru BIP powinien posiadać co najmniej następujące

elementy: tytuł wyniku naboru, tytuł alternatywny wyniku naboru, słowa kluczowe, określenie urzędu dokonującego rekrutacji (wybór z listy

jednostek statystyki publicznej), część zasadniczą szablonu/miejscem na treść wyniku naboru.

Wynik naboru BIP powinien posiadać metrykę zmian treści, składającą się m.in. z pól: podmiot publikujący, osoba odpowiedzialna za treść informacji, osoba publikująca informację, data wytworzenia informacji,


administracji.41

data publikacji informacji, data aktualizacji informacji.

ID F 13. Nazwa Tabela BIP z listą ofert pracy, list kandydatów i wyników naboru

Opis Tabela z listą ofert pracy, list kandydatów i wyników naboru, możliwa do utworzenia dla poszczególnych jednostek statystyki publicznej, powinna posiadać co najmniej następujące elementy:

tytuł tabeli, słowa kluczowe, pliki do pobrania (np. wzory oświadczeń wymagane w procesie

rekrutacyjnym), miejsce dodania kolejnej oferty pracy, listy kandydatów do tej

oferty i wyniku naboru związanych z konkretną ofertą.

Tabela z listą ofert pracy, list kandydatów i wyników naboru powinna posiadać metrykę zmian treści, składającą się m.in. z pól: podmiot publikujący, osoba odpowiedzialna za treść informacji, osoba publikująca informację, data wytworzenia informacji, data publikacji informacji, data aktualizacji informacji.System powinien zapewniać przeniesienie informacji o zakończonym postępowaniu rekrutacyjnym do archiwum postępowań (podzielonego na lata).

ID F 14. Nazwa Tabela BIP z listą projektów aktów prawnychOpis Tabela z listą projektów aktów prawnych powinna posiadać co

najmniej następujące elementy: tytuł tabeli, słowa kluczowe, link do strony z Rządowym Procesem Legislacyjnym

http://legislacja.rcl.gov.pl/, opcję edycji/dodawania kolejnych projektów aktów prawnych, w

tym określania tytułu kolejnego aktu prawnego, długiego tytułu, załączenia pliku projektu, załączenia uzasadnienia do projektu, załączenia dokumentów związanych z projektem, linku do tego projektu na stronie RCL, określenia osoby odpowiedzialnej za projekt aktu prawnego w GUS, datę wytworzenia projektu, datę opublikowania projektu w BIP GUS. Projekty powinny być wyświetlane w kolejności od ostatnio dodanych do najstarszych. CMS powinien także umożliwić prezentację listy projektów aktów prawnych według ustalonych przez Zamawiającego grup projektów, np. dotyczące Programu Badań Statystycznych Statystyki Publicznej, dotyczące wzorów formularzy sprawozdawczych i inne.

Tabela z listą projektów aktów prawnych powinna posiadać metrykę


administracji.42

http://legislacja.rcl.gov.pl/

zmian treści, składającą się m.in. z pól: podmiot publikujący, osoba publikująca informację, data aktualizacji informacji.System powinien zapewniać utworzenie archiwum projektów aktów prawnych (w podziale na lata).

ID F 15. Nazwa Publikowanie zamówień publicznych w BIP GUS i BIP innych jednostek statystyki publicznej

Opis 1. System musi posiadać funkcjonalność umożliwiającą publikowanie dokumentów dotyczących postępowań o udzielenie zamówień publicznych.

2. Lista publikowanych zamówień musi zawierać co najmniej następujące informacje: nr postępowania, nazwa postępowania, lista dokumentów dotyczących postępowania, data zamieszczenia dokumentu w BIP.

3. W przypadku konkretnego zamówienia kolejne pliki powinny być publikowane w sposób chronologiczny odzwierciedlający przebieg procedury przetargowej.

4. Minimalny zestaw informacji dla listy dokumentów (plików) dotyczących postępowań o udzielenie zamówienia publicznego to:

a) rodzaj dokumentu (m.in. Ogłoszenie, SIWZ, Wniosek- wzór, Wyjaśnienia SIWZ, Modyfikacja SIWZ, Kopia odwołania, Wezwanie do przystąpienia do postępowania odwoławczego, Zawiadomienie o wyborze oferty, z możliwością dodawania nowych rodzajów lub wpisania własnego opisu rodzaju dokumentu),

b) data publikacji,c) link do pliku lub grupy (kilku) plików.

5. System musi umożliwiać przeniesienie zakończonych postępowań do archiwum (archiwum powinno obejmować dwa poprzednie lata).

ID F 16. Nazwa Lista nowości wydawniczych urzędów statystycznychOpis 1. CMS musi posiadać możliwość tworzenia strony na podstawie listy

stron określonej kategorii (tutaj kategoria „nowość wydawnicza”). Na stronie prezentowane są następujące elementy pobrane z każdej strony z listy:

a) nagłówek,b) obraz (powinna istnieć możliwość przeskalowania jego

wielkości),c) krótki opis,d) link do strony z publikacją.

2. CMS musi posiadać możliwość edytowania kolejności nowości na liście.

3. CMS powinien mieć możliwość definiowania ilości prezentowanych nowości na stronie. Pozostałe strony z listy powinny być dostępne


administracji.43

po wybraniu opcji „więcej nowości”.

ID F 17. Nazwa PublikacjaOpis 1. Publikacja ma posiadać co najmniej następujące elementy:

a) tytuł publikacji,b) tytuł alternatywny,c) słowa kluczowe,d) kontener na wersję PDF publikacji,e) kontener na wersję DOC,f) kontener na wersję XLS,g) kontener na wersję ZIP,h) kontener na odsyłacz (do nowej strony, strony z innego

projektu, adres URL),i) typ pola (ISSN, ISBN lub Brak),j) częstotliwość wydania,k) wersja językowa publikacji,l) data publikacji (upublicznienia),m) przekroje,n) część zasadnicza opisu zawierająca możliwość wstawienia

treści oraz obiektów multimedialnych (audio, video, grafika itp.) i stronicowania,

o) opis alternatywny,p) krótki opis (wykorzystywany w tabeli dokumentów

tematycznych),q) zajawka,r) obraz (wykorzystywany w aktualnościach),s) odsyłacz do archiwum.

Przy kontenerach plików (PDF, XLS, ZIP) powinna pojawić się informacja o rodzaju pliku wraz z ikoną prezentująca dany format oraz rozmiar danego pliku.

Opcjonalnie musi istnieć możliwość dołączania do artykułów elementów multimedialnych w postaci odtwarzacza wideo/audio i galerii zdjęć, załączników w postaci plików do pobrania (pliki muszą mieć możliwość określenia nazwy oraz opisu) oraz linków (z możliwością określenia nazwy i adresu URL). Sposób prezentacji ma być określony za pomocą predefiniowanych szablonów. System musi pozwalać na wybór załączników i linków, które będą prezentowane w ramach zajawki na listach zajawek publikacji.

ID F 18. Nazwa AktualnościOpis 1. Wiadomości są prezentowane na stronie z listą zawierającą datę

opublikowania, tytuł oraz zajawkę. Po kliknięciu w tytuł wiadomości lub link „więcej” CMS musi prezentować pełną treść wiadomości.


administracji.44

2. Publikacja aktualnych wiadomości musi być możliwa w dwóch odsłonach: - skrót informacji, - skrót informacji wraz z fotografią.

3. CMS musi umożliwiać zdefiniowanie czasu, po którym starsze aktualności zostaną przeniesione (automatycznie) do archiwum aktualności.

4. CMS musi posiadać możliwość określania położenia wiadomości względem innych na liście (wiadomość priorytetowa pokazywana jako pierwsza).

5. CMS musi umożliwiać prezentację zajawek wiadomości sortowanych według daty i godziny publikacji z możliwością ich edycji oraz ręcznego oznaczania kolejności zajawek.

6. CMS musi mieć możliwość definiowania ilości (pozycji na liście) zajawek wiadomości.

7. CMS musi mieć możliwość przekierowania z tytułu wiadomości/linku „więcej” na zewnętrzny adres URL lub do pliku.

8. CMS musi umożliwiać automatyczne (na życzenie redaktora) opublikowanie na liście zajawek, zajawki strony z dowolnej części serwisu. Jeżeli strona posiada datę końca publikacji, to po jej upłynięciu musi być automatycznie usunięta z listy.

9. CMS ma umożliwić publikację w aktualnościach informacji publikowanych w innych projektach (np. Dzienniki Urzędowe GUS).

10.CMS ma umożliwić wybór Aktualności z określonego miesiąca lub innego zakresu czasowego.

ID F 19. Nazwa Tabela dokumentów tematycznych „Tematy”Opis 1. Tabela dokumentów zawiera listę odsyłaczy/łącz do stron

(artykułów, notatek, publikacji) lub do dowolnego adresu URL.2. Pojedynczy rekord tabeli zawiera: liczbę porządkową, tytuł, krótki

opis (pobierany automatycznie ze strony, do której prowadzi odsyłacz), datę publikacji, odsyłacz do archiwum.

3. CMS powinien umożliwiać sortowanie tabeli według zdefiniowanych nagłówków.

4. CMS musi posiadać możliwość określania położenia odsyłacza/łącza względem innych na liście.

ID F 20. Nazwa Komunikaty i Obwieszczenia - szablonOpis 1. Szablon strony musi posiadać co najmniej następujące elementy:

a) nagłówek/tytuł,b) słowa kluczowe,c) typ publikacji (obwieszczenie/komunikat),d) zajawka,e) data publikacji,f) miejsce publikacji komunikatu lub obwieszczania,


administracji.45

g) część zasadnicza opisu zawierająca możliwość wstawienia treści,

h) obraz (wykorzystywany w aktualnościach).2. Głównym łączem dla komunikatów i obwieszczeń będzie Tabela

komunikatów i obwieszczeń - według przykładu: http://www.stat.gov.pl/gus/komunikaty_PLK_HTML.htm

ID F 21. Nazwa Tabela komunikatów i obwieszczeńOpis Tabela z listą komunikatów i obwieszczeń, będąca jednocześnie

harmonogramem ich publikacji.Tabela zawiera listę odsyłaczy/łącz do stron z obwieszczeniami i komunikatami, podzielonych według grup tematycznych. Pojedynczy rekord zawiera: liczbę porządkową, tytuł z opisem wskaźnika wyświetlającym się po wskazaniu myszą na dany tytuł oraz linkiem „podpiętym” pod tytuł prowadzący do opisu metodologicznego, okres jakiego dotyczy (np. miesiąc do poprzedniego miesiąca), datę publikacji (łącze do strony z daną informacją - komunikatem lub obwieszczeniem).CMS powinien umożliwiać:

sortowanie tabeli według zdefiniowanych nagłówków, określenie położenia odsyłacza/łącza względem innych na

liście, dodanie dodatkowej pozycji na liście w ramach danej grupy

tematycznej, automatyczne stworzenie archiwum komunikatów i

obwieszczeń z lat poprzednich.CMS powinien ułatwiać użytkownikom serwisu szybkie odnalezienie poszukiwanego komunikatu lub obwieszczenia.

ID F 22. Nazwa Tabela wyników wstępnychOpis 1. Tabela opatrzona nagłówkiem „wyniki wstępne”, będąca listą

artykułów i jednocześnie harmonogramem publikacji informacji.2. Dzień publikacji w tabeli ma być łączem do strony z daną

informacją - wynikiem wstępnym.3. CMS musi zapewniać mechanizm automatycznego tworzenia łącza

w tabeli wyników wstępnych w czasie edycji strony prezentującej dany wynik wstępny.

4. Łącze musi posiadać „dymek narzędziowy” w postaci tytułu „przejętego” ze strony, do której prowadzi.

ID F 23. Nazwa Publikacje A-ZOpis 1. CMS musi zapewniać możliwość wyświetlenia listy stron

(artykułów, publikacji) w porządku alfabetycznym zgodnie z Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


46

http://www.stat.gov.pl/gus/komunikaty_PLK_HTML.htm

alfabetem polskim.2. CMS musi zapewniać mechanizm umożliwiający przypisanie strony

do danej kategorii/słowa kluczowego - litery alfabetu.3. CMS musi zapewniać możliwość tworzenia dowolnej liczby

kategorii, np. kategorii [0-9] dla stron, gdzie tytuł zaczyna się od cyfry.

ID F 24. Nazwa Moduł „Na skróty”Opis CMS musi umożliwiać tworzenie działu „na skróty - lista odsyłaczy do

stron”, na podstawie statystyk najczęściej odwiedzanych stron serwisu z możliwością dodania i zakotwiczenia do działu „na skróty” artykułu lub linku przez administratora merytorycznego. Administrator może definiować liczbę odsyłaczy.

ID F 25. Nazwa Mapa interaktywnaOpis Moduł ten umożliwia prezentację danych statystycznych na mapie

Polski. Mapa musi być podzielona na województwa, powiaty lub gminy, a dodane miejscowości będą wyświetlane, pod warunkiem, że są do nich przypisane dane w postaci konkretnej wartości.Punkty na mapie muszą być w pełni edytowalne z poziomu panelu administracyjnego. Redaktor powinien mieć możliwość podania współrzędnych geograficznych danego punktu, a także możliwość ustalenia rodzaju oznaczenia miejscowości na mapie oraz jego kolor. Musi istnieć również możliwość zdefiniowania, czy wszystkie miejscowości mają być wyświetlane na widoku mapy Polski, czy dopiero po wybraniu konkretnego województwa, powiatu lub gminy.Mapa może być prezentowana w postaci: cała mapa Polski, mapa Polski z podziałem na województwa, mapa województwa, mapa województwa z podziałem na gminy, mapa gminy.

Do każdej mapy musi istnieć możliwość dodania i edycji legendy.

ID F 26. Nazwa Kalendarz publikacji/wydarzeńOpis Moduł do zamieszczenia na stronach głównych poszczególnych

projektów (według decyzji Zamawiającego), umożliwiający wprowadzanie informacji o publikacji istotnych komunikatów, obwieszczeń, wyników wstępnych, czy informacji o istotnych wydarzeniach, które będą miały miejsce w statystyce publicznej w określonych terminach.Systemu umożliwi wyróżnienie ważnej publikacji/wydarzenia w kalendarzu oraz przejście od pozycji w kalendarzu do stron ze szczegółowym opisem publikacji/wydarzenia.


administracji.47

ID F 27. Nazwa Edycja treściOpis 1. CMS musi posiadać pracujący w trybie on line edytor typu

WYSIWYG pozwalający na pracę z artykułami publikowanymi w serwisie przy założeniu braku znajomości kodu HTML przez redaktorów.Edytor musi zapewniać możliwość edytowania tekstów w sposób typowy dla popularnych pakietów biurowych tak, by użytkownicy bez trudu mogli edytować i zmieniać publikowane treści bez konieczności wymuszania otwierania nowych okien.

2. Edytor musi posiadać co najmniej takie funkcje, jak: pole format - zawierające predefiniowane elementy strukturalne

treści (p, h1, h2, h3, h4, h5); pole styl - zawierające predefiniowane style CSS; możliwość wyboru czcionki i jej rozmiaru; Wytnij, Kopiuj, Wklej, Wklej jako czysty tekst; Wklej sformatowaną zawartość z programu MS Office, Znajdź, Zamień, Zaznacz wszystko, Usuń formatowanie; Pogrubienie, Kursywa, Podkreślenie, Przekreślenie, Indeks

dolny, Indeks górny; Wstaw/usuń numerowanie listy, Wstaw/usuń wypunktowanie

listy; Zmniejsz wcięcie, Zwiększ wcięcie, Wyrównaj do lewej, środka,

prawej, lewej i prawej; Wstaw plik; Wstaw/edytuj grafikę, Wstaw flash, Wstaw/edytuj hiperłącze,

Usuń hiperłącze, Wstaw/edytuj kotwicę, Wstaw/edytuj tabelę, wstaw/usuń wiersz/kolumnę, podziel

komórkę, scal komórki, wysokość i szerokość wierszy oraz kolumn; kopiuj/wklej wybrany zakres komórek do tabeli;

Wstaw linię poziomą, Wstaw znak specjalny; Wstaw przypis, listę przypisów; Zmień kolor czcionki, Zmień kolor tła; Pokaż kod źródłowy, Podgląd strony (preview); Cofnij, Przywróć; Wyszukaj; Pomoc; Podział na strony (stronicowanie).

3. Kod wstawiany przez edytor musi być zgodny minimum ze standardami XHTML 1.0 (Transitional) i CSS 2.1.

4. Edytor musi posiadać możliwość ograniczenia dostępności wybranych opcji dla określonych grup użytkowników (co najmniej trzy poziomy).

5. Edytor musi posiadać funkcję "czyszczenia" kodu HTML tak, by treść dużych fragmentów tekstów kopiowanych z dowolnego edytora zewnętrznego (np. MS Word, OpenOffice.org Writer),


administracji.48

arkusza kalkulacyjnego (np. MS Excel, OpenOffice.org Calc) lub wprost z innej strony WWW pozbawiona była elementów utrudniających prawidłową edycję lub wyświetlanie artykułu.

6. CMS musi dodatkowo automatycznie filtrować zbędny kod wstawiany przy kopiowaniu z wyżej wymienionych programów przy zapisywaniu edytowanego materiału oraz zastępować wybrane ciągi znaków wskazanymi odpowiednikami.

7. W systemie musi istnieć możliwość konfigurowania zakresu filtrowanych i zastępowanych elementów.

8. Praca w edytorze musi odbywać się z poziomu przeglądarki internetowej bez potrzeby instalacji specjalnego oprogramowania klienckiego.

9. Edytor musi zawierać 3 tryby wyświetlania zawartości: zwykły tryb edycyjny (WYSIWYG), tryb HTML, tryb podglądu strony (preview),

10. Edytowany artykuł będzie mógł być wzbogacony przez - znajdujące się w repozytorium lub nowe (wgrane z dysku lokalnego użytkownika do repozytorium) pliki w tym w szczególności pliki graficzne.

11. Elementy graficzne dołączane do tekstów muszą mieć możliwość skalowania do dowolnych rozmiarów wstawiania tekstu "alt", definiowania sposobu wyświetlenia tj. miejsca położenia, wielkości, sposobu wyrównania tekstu, podpisu, możliwości otwarcia powiększonej ilustracji w nowym oknie lub w technice overlay (przed tekstem).

12. CMS musi umożliwiać podgląd strony/artykułu na każdym etapie redakcji oraz w całym procesie zatwierdzania i publikacji w układzie (szablonie), w jakim będzie on prezentowany w serwisie.

13. CMS musi umożliwiać konfigurację dostępności funkcji edytora dla danego w szablonie pola treści wykorzystującego Edytor (np. redaktor w czasie edycji ma możliwości tylko zmiany koloru czcionki).

14. Funkcja wstawiania Hiperłącza/Linku za pomocą edytora WYSIWYG do istniejącej strony w projekcie musi umożliwiać wybranie strony z listy stron lub wyszukanie takiej strony za pomocą tytułu, słowa kluczowego, fragmentu treści, nagłówka lub numeru ID strony, autora strony, data utworzenia strony i zakresu dat utworzenia strony.

15. W trybie HTML Edytor musi analizować poprawność kodu HTML.

16. Opcje edytora są konfigurowalne - przyciski i style kaskadowe CSS mogą być dodawane i usuwane w zależności od grupy do jakiej należy użytkownik lub/i od położenia strony w drzewie witryny.

17. Edytor musi zapewniać mechanizm sprawdzania pisowni.18. CMS musi posiadać możliwość edycji wybranych elementów

strony metodą „inline”.


administracji.49

ID F 28. Nazwa Akceptacja, zatwierdzanie i publikacja treści artykułówOpis 1. Każdy nowy artykuł wprowadzony przez redaktora, wprowadzone

poprawki lub usunięcie („odpublicznienie”) istniejącego artykułu, będzie musiało zostać zaakceptowane przez Redaktora Zatwierdzającego. Jednocześnie musi istnieć możliwość wyłączenia wymogu akceptacji zmian dla wybranych kategorii i/lub dla wybranych grup użytkowników.

2. Oczekiwanie na akceptację poprawionego artykułu nie może powodować przerwy w wyświetlaniu wersji poddanej aktualizacji (o ile nie została osiągnięta data końca publikacji danego artykułu).

3. Aktualizowany artykuł zostanie automatycznie opatrzony informacją o czasie, dacie i osobie aktualizującej. Informacja ta zostanie odnotowana w mechanizmie dziennika dokonywanych zmian, wersja przed zmianą zachowana będzie jako wersja archiwalna artykułu.

4. CMS musi umożliwiać określenie dla poszczególnych kategorii serwisów Redaktorów Zatwierdzających treści przed ich publikacją.

5. CMS musi wysyłać powiadomienia na zdefiniowane adresy e-mail redaktorów w sytuacji, gdy wymagana jest od nich jakakolwiek akcja w systemie (np. zatwierdzenie artykułu do publikacji, publikacja artykułu, odrzucenie artykułu do publikacji itp.).

6. CMS musi umożliwiać zatwierdzanie wielu artykułów naraz.7. CMS musi umożliwiać edycję artykułu przez Redaktora

Zatwierdzającego. Dotyczy to również wszystkich edytowanych treści na stronach www.

8. CMS musi posiadać narzędzie pozwalające na monitorowanie i koordynowanie przepływu artykułów zgodnie z założonym przepływem pracy. Narzędzie musi umożliwiać ustawienie kilkustopniowej ścieżki zatwierdzania artykułu/strony przed publikacją.

9. CMS musi umożliwiać prace wielu redaktorów nad zawartością strony. Stronę uwolnioną może edytować inny użytkownik. W danej chwili stronę może edytować tylko jeden użytkownik, dla innych użytkowników strona musi być blokowana z opcją sprawdzenia, kto w danej ją blokuje.

10. CMS musi mieć wbudowany mechanizm komunikacji (np. informacja o powodzie nie zatwierdzenia artykułu do publikacji wraz z powiadomieniem na e-mail) pomiędzy redaktorami (obsługujący proces edycja-zatwierdzenie-publikacja).

11. CMS musi umożliwiać jednoczesną publikację wielu zatwierdzonych artykułów.

12. CMS musi umożliwiać czasowe wyłączenie strony (odpublicznienie, zmiana statusu publikacji na: NIE). W tym czasie strona jak i pliki dołączone do strony nie mogą być widoczne dla użytkowników z Internetu. Dostęp do plików nie może być również


administracji.50

możliwy przez podanie adresu bezwzględnego do pliku (wyjątkiem może być sytuacja jeżeli plik jest używany w kilku miejscach w serwisie).

13. CMS musi zapewniać możliwość podglądu strony przed publikacją.

14. System musi umożliwiać generowanie raportów z procesu publikacji (opublikowane strony, grafika, ewentualne błędy).

15. CMS musi umożliwiać wysyłanie zwrotnie informacji o opublikowaniu do innych systemów.

ID F 29. Nazwa Terminy publikacjiOpis 1. CMS musi umożliwiać opcjonalne ustalenie okresu publikacji (od-

do; z dokładnością minimum do godziny) dla wszystkich stron umieszczanych i publikowanych w systemie.

2. Czas upływający od opublikowania strony w CMS do jej publikacji na stronach WWW nie może być dłuższy niż 30 sekund; brak konieczności ręcznego czyszczenia cache serwera.

3. CMS musi automatycznie (bez potrzeby ingerencji redaktorów, bądź administratorów) publikować i usuwać z serwisu strony zgodnie z ustalonym okresem upublicznienia.

4. Po opublikowaniu system musi automatycznie: aktualizować odpowiednie kanały RSS/Atom. aktualizować informacje do powiadomień o nowościach, aktualizować inne powiązane strony, np.: listy stron w grupach

tematycznych czy publikacjach A-Z.

ID F 30. Nazwa Wersjonowanie stronOpis 1. CMS musi umożliwiać wersjonowanie tworzonych przez

redaktorów stron.2. Każda nowa strona tworzona w CMS może zostać w dowolnej

chwili zapisana jako wersja robocza. Taki niedokończony dokument musi być zapamiętywany w systemie, lecz nie powinien być kierowany do publikacji.

3. Każda zapisana przez dowolnego redaktora modyfikacja treści musi powodować stworzenie nowej wersji (roboczej) strony.

4. CMS musi jednoznacznie wskazywać aktualnie opublikowaną wersję strony. Do zatwierdzenia i opublikowania może zostać skierowana dowolna z wersji strony.

5. Publikacja strony lub jej nowej wersji możliwa jest wyłącznie po jej zatwierdzeniu przez Redaktora Zatwierdzającego.

6. CMS musi posiadać historię opublikowanych wersji stron.7. Wszystkie wersje robocze należące do danego redaktora muszą

być dostępne w jednym miejscu części administracyjnej Systemu.8. Każda strona stworzona w systemie może być wykorzystywana

wielokrotnie. Zmiana treści strony powoduje aktualizację wyświetlanej treści (po skierowaniu i zatwierdzeniu zmian) we


administracji.51

wszystkich miejscach, w których jest ona udostępniana.9. CMS musi umożliwiać porównywanie zmian między dwoma

wybranymi wersjami stron.10.Administrator merytoryczny powinien mieć możliwość

przeniesienia/usunięcia wybranych wersji obiektu do repozytorium zewnętrznego i z repozytorium zewnętrznego do CMS-a.

ID F 31. Nazwa Stronicowanie (paginacja)Opis 1. System musi umożliwiać dzielenie większej liczbę danych na

osobne strony (np. aktualności, archiwum aktualności, publikacje A-Z).

2. Artykuły mogą mieć nieograniczoną ilość stron wewnętrznych (stronic).

3. System musi posiadać możliwość dzielenia takich artykułów na pojedyncze wyświetlane stronice, wyświetlając jednocześnie na dole tekstu kolejne (będące jednocześnie aktywnymi odnośnikami) numery stronic oraz odnośniki typu: poprzedni/a, następny/a.

ID F 32. Nazwa Załączanie plików do pobraniaOpis Dla każdego artykułu/publikacji będzie zachowana możliwość

zdefiniowania listy plików do pobrania, znajdujących się w repozytorium systemu. Z poziomu dodawania plików z repozytorium musi istnieć możliwość załadowania nowego pliku w celu dołączenia do artykułu. Pliki te muszą być reprezentowane w postaci ikon (znaków charakterystycznych dla danego formatu), linku, definiowalnej przyjaznej nazwy linku oraz wielkości podanej w KB (kilobajtach) lub MB (megabajtach).

ID F 33. Nazwa Konwersja i drukowanie stronOpis CMS musi posiadać możliwość :

wydrukowania dowolnej strony, przygotowując specjalną wersję do druku opisaną i zdefiniowaną jako szablon;

konwersja dowolnej strony do formatu PDF według zdefiniowanych szablonów;

wysłania linku do dowolnej strony na podany adres e-mail (administrator merytoryczny będzie miał możliwości ustalenia treści wiadomości w panelu administracyjnym).

ID F 34. Nazwa Bloki funkcjonalne z listą zajawek artykułówOpis 1. CMS musi posiadać możliwość publikowania wielu bloków

funkcjonalnych zawierających listy zajawek artykułów (zarówno na stronie głównej, jak i innych podstronach serwisu). W ramach listy będą wyświetlane w dowolnie wybranym połączeniu (kombinacji) następujące elementy: temat, skrót treści, element graficzny, link do pełnej treści, data publikacji artykułu, oznaczenie,


administracji.52

że artykuł ma dołączony materiał wideo, materiał audio, galerię zdjęć, lista wybranych do prezentacji w zajawce załączników do artykułu, słowa kluczowe przypisane do artykułu. O szczegółowym umiejscowieniu list i ich wyglądzie decydować będą szablony serwisu.

2. CMS musi posiadać możliwość określania położenia wiadomości względem innych na liście (wiadomość priorytetowa, pokazywana jako pierwsza).

3. CMS musi umożliwiać prezentację zajawek artykułów sortowanych według daty i godziny publikacji z możliwością ich edycji oraz ręcznego oznaczania kolejności zajawek.

4. System musi mieć możliwość definiowania ilości (pozycji na liście) zajawek artykułów dla poszczególnych bloków.

5. CMS musi umożliwiać automatyczne (na życzenie redaktora) opublikowanie na liście zajawek artykułów informacji o artykule z dowolnej części serwisu. Jeżeli artykuł posiada datę końca publikacji, to po jej upłynięciu musi być automatycznie usunięty z listy.

6. Na liście zajawek musi istnieć możliwość publikacji linków wyświetlanych w sposób identyczny, jak inne artykuły na liście, ale prowadzących do wybranych adresów URL. System musi umożliwiać określenie zakresu czasowego publikacji linku.

7. CMS musi automatycznie uwidaczniać i usuwać z list zajawki artykułów i linki, których czas publikacji został zaplanowany w przyszłości lub minął.

ID F 35. Nazwa Wyszukiwanie informacji i zarządzanie zasobami w CMSOpis 1. CMS musi posiadać wyszukiwarkę przeznaczoną dla redaktorów

i administratorów merytorycznych, która pozwoli łatwo lokalizować zasoby w ramach całego systemu.

2. W szczególności wyszukiwarka musi umożliwiać: wygodne wyszukiwanie, przeglądanie i zarządzanie plikami, odnajdowanie i zarządzanie wszystkimi współzależnościami

pomiędzy stronami i plikami w ramach CMS, wyszukiwanie i zarządzanie łączami dynamicznymi z bazami

danych, odnajdowanie nieużywanych plików i łącz.

3. Powinna istnieć możliwość ograniczenia zasięgu wyszukiwania do określonego modułu lub kategorii serwisu, dowolnego atrybutu oraz możliwość określenia liczby wyników wyświetlanych na pojedynczej stronie.

4. CMS powinien pamiętać ostatnio używaną lokalizację (w przypadku administratorów), aby nie było konieczności każdorazowego zagłębiania się w drzewo katalogów od jego wierzchołka.

5. W przypadku redaktorów wyszukiwarka powinna domyślnie


administracji.53

pokazywać tylko strony i zasoby powiązane ze stronami, do których ma dostęp dany redaktor.

6. CMS powinien oferować pomoc dotyczącą sposobów wyszukiwania.

ID F 36. Nazwa Tworzenie nawigacjiOpis 1. CMS musi posiadać narzędzia służące do budowy i zarządzania

strukturą serwisu z możliwością samodzielnej budowy wielopoziomowego menu i jego modyfikacji oraz konfiguracji (np. sposobu wyświetlania).

2. Tytuł strony automatycznie staje się częścią linku do tej strony i musi mieć zachowaną możliwość zmiany takiej nazwy (bez równoczesnej zmiany tytułu strony) tak, by nawigacja zachowała swą przejrzystość i czytelność. Tak przygotowany link musi pojawić się (po opublikowaniu) w mapie serwisu.

3. CMS musi zawierać ścieżkę nawigacyjną tak, aby użytkownik w każdym momencie wiedział w jakim miejscu (głębokości) jego struktury się znajduje, z możliwością natychmiastowego powrotu do każdego z wyższych poziomów struktury.

4. W wybranych, kluczowych miejscach systemu należy umieścić linki poziome do sąsiednich gałęzi w drzewie, aby nie było konieczności każdorazowego powrotu do korzenia.

ID F 37. Nazwa Komponenty CMSOpis W ramach modułów CMS zaimplementowana będzie obsługa

komponentów (wydzielonych elementów zwanych też boxami), które pojawiać się będą tylko w wybranych częściach serwisu (przykładowe komponenty to: nagłówki RSS/Atom, rejestracja użytkownika, galerie, system banerów, komunikatów).

ID F 38. Nazwa Wyszukiwanie informacji w PI GUS Opis 1. Komponent „Wyszukiwarka” musi oferować użytkownikom

zewnętrznym mechanizm wyszukiwania we wszystkich zasobach.2. Komponent „Wyszukiwarka” musi umożliwiać stosowanie

operatorów logicznych i wyrażeń regularnych.3. Wyszukiwarka musi umożliwiać szukanie także w zawartości

dołączonych plików do pobrania (minimum plików: PDF, RTF, MS Word, MS Excel, OpenOffice Write, OpenOffice Calc, MS PowerPoint) oraz etykietach pól w bazach danych, z których pobierane są informacje do tworzenia dynamicznych prezentacji.

4. Komponent „Wyszukiwarka” powinien korzystać ze słownika pojęć statystycznych i metadanych opisujących prezentowane liczby. Powinien pozwalać także na wyszukiwanie za pomocą synonimów terminów z języka statystycznego zrozumiałych dla użytkowników.


administracji.54

5. Wyszukiwanie powinno rozpoczynać się w trakcie wpisywania (opcja z możliwością wyłączenia w panelu administracyjnym).

6. Wyszukiwarka musi proponować sugestię wyszukania innego wyrazu frazy w razie wyszukiwania wyrazów i fraz, dla których brak wyników lub gdy istnieją popularne wyrazy lub frazy o podobnym brzmieniu.

7. Wyszukiwarka musi mieć możliwość prezentowania sugerowanych linków dla wybranych wyszukiwań wyrazów lub fraz.

8. Bezpośrednio dla użytkownika ma być dostępne wyszukiwanie proste - pole tekstowe dostępne na głównej stronie serwisu oraz domyślnie we wszystkich działach i stronach - umożliwiające szybkie wyszukanie w całym serwisie po wybranym słowie lub kilku słowach, domyślnie łączonych spójnikiem „i”.

9. Wyszukiwarka musi udostępniać mechanizm wyszukiwania zaawansowanego umożliwiającego:

a. szukanie dowolnego słowa,b. szukanie wszystkich słów,c. szukanie dokładnego wyrażenia,d. szukanie wg daty i zakresów dat,e. szukanie we wskazanej kategorii lub grupie kategorii,f. szukanie we wskazanych serwisach,g. szukanie wg rodzajów plików (np. treści zawarte w

dokumentach PDF lub XLS),h. szukanie w bazach danych.

10. Wyniki wyszukiwania będą prezentowane w formie rankingu, z możliwością określenia następujących sposobów sortowania:

a. trafności wyszukania, b. od najnowszych/najstarszych,c. alfabetycznie,d. wg miejsca publikacji (kategorii serwisu).

11. Domyślnie wyniki wyświetlane będą według trafności wyszukania, która powinna uwzględniać statystyki popularność dla wyników oraz wybory z list wyników poprzednich wyszukiwań.

12. Dla wyszukanych artykułów podana zostanie kategoria, tytuł, data publikacji oraz stronicowana lista zawierająca fragment (ok. 240 znaków) artykułu z wyszukiwaną frazą lub początek artykułu (kontekst użycia).

13. Wyszukiwarka musi zapewniać możliwość grupowania wyników z wybranych kategorii serwisu (definiowanego przez Administratora merytorycznego). Przy grupie musi być możliwość zamieszczenia ilości wyników dla danej grupy.

14. Wyszukiwarka musi umożliwiać określenie liczby wyników prezentowanych na jednej stronie.

15. Wyszukiwarka musi również zapewniać możliwość zmiany domyślnego zakresu wyszukiwania w zależności od wybranych kategorii serwisu.

16. Wyszukiwarka musi również umożliwiać wyszukiwanie metodą Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


55

indeksową w oparciu o kategorie, słowa kluczowe, czas publikacji, atrybuty artykułów. W ramach tego typu wyszukiwania system ma posiadać tzw. chmurę tagów, pozwalającą na wybór z listy słów kluczowych prezentowanych w zależności od popularności wyszukiwań i/lub częstości występowania. Funkcjonalność powinna być dostępna dla całego serwisu lub wybranych projektów.

17. Powinna być możliwość podniesienia priorytetu trafności wyszukiwania poprzez dodanie „domyślnych ustawień”. Przykładowo słowo „ustawa” występuje w portalu w wielu miejscach i z różną częstością, ale wśród pierwszych wyników wyszukiwania powinna być widoczna „ustawa o statystyce publicznej”.

18. Wyniki wyszukiwań muszą umożliwiać zliczanie wejść na daną stronę przez zewnętrzne systemy rejestrowania statystyk serwisu (np. przez Google Analytics).

19. Wyszukiwarka powinna oferować pomoc dotyczącą sposobów wyszukiwania.

20. Wyszukiwarka powinna pamiętać wyniki poprzednich wyszukiwań w ramach danej sesji (od wejścia na dowolną stronę w ramach portalu do opuszczenia ostatniej oglądanej strony w ramach portalu).

21. SPI musi wspierać działanie Wyszukiwarki, tak aby w maksymalnym stopniu ułatwiać znajdowanie szukanych informacji także wśród raportów generowanych przez SWAID.

22. Minimalnym wymaganiem jest wyszukiwanie po nazwach raportów, a pożądanym jest stworzenie mechanizmu maksymalnie ułatwiającego dotarcie do odpowiedniego raportu na podstawie słów kluczowych związanych z raportami oraz ich synonimów.

ID F 39. Nazwa Powiadamianie o nowościach na stronie (newslettery)Opis 1. CMS musi posiadać możliwość przesyłania za pośrednictwem

poczty elektronicznej powiadomień o nowościach umieszczonych na stronie. Powiadomienia o nowościach muszą być tworzone w oparciu o predefiniowane szablony umożliwiające przesyłanie wiadomości graficznych (HTML) lub tekstowych.

2. CMS musi umożliwiać stosowanie wielu szablonów dla różnych zdefiniowanych wersji powiadomień.

3. CMS musi umożliwić automatyczne generowanie i wysyłanie powiadomień o nowościach dla wybranej (jednej lub kilku) kategorii serwisu, zawierającego informacje o nowych treściach, jakie się tam pojawiły.

4. Administrator merytoryczny musi mieć możliwość konfiguracji mechanizmu rozsyłania powiadomień, w tym m.in. konta, z którego są one wysyłane, ustalenia pory wysyłania (godziny).

5. W systemie musi być możliwość definiowania kategorii Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


56

wiadomości. 6. Użytkownicy muszą mieć możliwość rejestracji do wybranych

kategorii tematycznych.7. Użytkownicy powinni być automatycznie aktywowani po

zweryfikowaniu adresu e-mail.8. Zarejestrowani użytkownicy serwisu - na podstawie podanego

i zweryfikowanego w wymaganym okresie (np. do 24 godzin) adresu e-mail - będą mieli możliwość otrzymywania na podany adres e-mail powiadomień z nowościami z wybranych kategorii serwisu.

9. Po zweryfikowaniu adresu e-mail użytkownik serwisu będzie miał możliwość ustawienia hasła, za pomocą którego będzie mógł (w zależności od uprawnień jego grupy): zrezygnować z subskrypcji, zmienić adres e-mail, na który przesyłane są zasubskrybowane

informacje (każdorazowa zmiana adresu e-mail będzie wymagała weryfikacji),

zmienić hasło oraz inne dane podane przy rejestracji, zmienić listę kategorii, z których ma otrzymywać powiadomienia

o nowościach, zmienić częstotliwość otrzymywania zasubskrybowanych

informacji.Wszystkie te opcje muszą być również dostępne do zmian przez administratora merytorycznego.

10.Mechanizm subskrypcji newslettera musi posiadać możliwość zmiany zapomnianego hasła przez zarejestrowanego gościa.

11.CMS musi posiadać funkcjonalność zarządzania bazą osób otrzymujących e-maile (dodawanie, usuwanie, modyfikacja, grupowanie).

12.CMS umożliwi stworzenie statystyk ilości wysłanych e-maili, otrzymanych zwrotek, a także ilości kliknięć w linki znajdujące się w wiadomości.

ID F 40. Nazwa Dostęp użytkowników do serwisu internetowegoOpis 1. Dla serwisów obsługiwanych przez system musi istnieć możliwość

zakładania w systemie kont przez Użytkowników.2. System musi umożliwiać konfigurację formularza przeznaczonego

do zakładania konta przez Użytkownika oraz musi posiadać możliwość ustawienia oddzielnej polityki haseł dla tego typu kont. Domyślnie założenie konta powinno być możliwe tylko na podstawie podanego adresu e-mail.

3. System musi posiadać funkcjonalność „Aktywacji konta” zakładanego przez Użytkownika poprzez wysłanie na podany adres e-mail linku aktywującego założone konto.

4. Domyślnie Użytkownicy mają mieć możliwość korzystania z serwisu bez potrzeby logowania.


administracji.57

5. System musi umożliwiać włączenie logowania dla określonych grup Użytkowników w celu uzyskania dostępu do określonych kategorii, konkretnych stron czy też wybranych załączników do artykułów.

6. System musi posiadać funkcjonalność zarządzania kontami zarejestrowanych osób (dodawanie, usuwanie, modyfikacja, blokowanie).

7. Zarejestrowani Użytkownicy muszą mieć możliwość zmiany zapomnianego hasła.

ID F 41. Nazwa Dostęp użytkowników do CMSOpis 1. Osoby uprawnione do korzystania z aplikacji powinny mieć własną

nazwę logowania i hasło z kontrolą poziomu bezpieczeństwa. 2. Dla obsługiwanych serwisów System musi również zapewniać opcję

uwierzytelniania użytkowników z ActiveDirectory. 3. Użytkownik raz zalogowany musi mieć dostęp (bez konieczności

powtórnego logowania) do wszystkich projektów, do których został mu nadany dostęp przez Administratora merytorycznego.

4. Menu systemu musi zapewniać opcję przełączania między projektami/serwisami.

ID F 42. Nazwa Tworzenie formularzyOpis CMS musi umożliwiać tworzenie formularzy, pozwalać na

umieszczenie ich w dowolnych miejscach serwisu oraz na przekierowanie wpisywanych odpowiedzi zarówno do bazy danych, do plików XML (jednego lub wielu), jak i bezpośrednio na dowolne wskazane konta e-mail w treści wiadomości, w postaci załącznika w formacie XML lub w postaci tekstu. Kreator formularzy musi posiadać intuicyjny edytor graficzny z funkcjami Drag&Drop pozwalający łatwo dodawać i dopasowywać elementy formularza.

1. CMS musi posiadać możliwość włączenia w formularzu zabezpieczenia typu Captcha (lub równoważny), które zabezpieczy np. przed botami.

2. Wymagane typy pól, jakie mają być dostępne w formularzach: pole tekstowe jedno/wielowierszowe z możliwością określenia

długości oraz zestawu dostępnych w nim znaków do wprowadzenia (wielkie i małe litery, cyfry, wybrane znaki specjalne, maski wprowadzania itp.),

pole wyboru checkbox, pole typu radio button z możliwością ich grupowania, usunięcia

zaznaczenia i wyboru tylko jednej możliwości w grupie, pole typu lista wyboru rozwijana, pole typu lista wyboru wyświetlana w całości z możliwością

wyboru wielu pozycji, pole typu data z koniecznością walidacji daty pod względem

formatu jej wprowadzenia, jak i poprawności,Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


58

pole typu załącznik, z możliwością określenia typów plików, które można załączyć,

przyciski „Wyczyść formularz”, „Wyślij formularz”, „Drukuj formularz”.

3. CMS musi posiadać możliwość tworzenia grup pól formularza, oznaczonych graficznie i posiadających własny opis.

4. CMS musi umożliwiać dowolną zmianę układu i rozmieszczenia pól formularza na stronie oraz kolejność indeksowania.

5. CMS musi posiadać możliwość umieszczenia między polami formularza dodatkowych opisów.

6. CMS musi umożliwiać oznaczenie pola jako wymagalnego oraz umożliwiać weryfikację jego wypełnienia.

7. CMS musi posiadać możliwość walidacji pól typu: NIP, REGON, PESEL, zarówno pod względem poprawności wprowadzenia danych (algorytm cyfr kontrolnych), jak i ilości i dostępności znaków - jeżeli pola tego typu będą wykorzystywane.

8. Każde pole musi posiadać mechanizm opcjonalnego określenia wartości domyślnej.

9. Każde pole musi posiadać obsługę standardowych zdarzeń, np. onfocus, onblur, onclick, onchange z możliwością obsługi definiowanej funkcji dopisywanej automatycznie do nagłówka strony. Panel administratora powinien umożliwiać definiowanie funkcji JavaScript (edytor tekstowy), przypisywanej do standardowych akcji kontrolek.

10.Po wypełnieniu formularza CMS musi posiadać możliwość włączenia wyświetlenia (w trybie do odczytu) użytkownikowi wprowadzonych danych do weryfikacji z możliwością przesłania danych lub powrotu do ich edycji.

11.CMS musi posiadać opcję potwierdzania wysłania formularza.

ID F 43. Nazwa Mapa serwisuOpis CMS musi automatycznie generować aktualną mapę serwisu

umożliwiającą określenie poziomu zagłębienia w hierarchię kategorii i artykułów. O prezentacji poszczególnych kategorii na mapie serwisu decyduje administrator merytoryczny.

ID F 44. Nazwa Zarządzanie URL-amiOpis 1. CMS musi generować tzw. przyjazne adresy URL, np.:

„http://www.stat.gov.pl/wynagrodzenia/2010/wynagrodzenia.html”. Adres powinien zawierać informacje o kategorii/dziale strony i możliwą do modyfikowania indywidualną nazwę strony (domyślnie generowaną na podstawie tytułu strony).

2. CMS musi posiadać zaawansowane zarządzanie odnośnikami poprzez wewnętrzny system kontroli odnośników w przypadku zmian w strukturze serwisu tak, by po przeniesieniu dokumentu do


administracji.59

innej lokalizacji automatycznie modyfikowana była postać URL-ów na wszystkich dynamicznie generowanych stronach, które się do niego odwołują.

3. CMS zapewni funkcję zarządzania adresami URL, dla wskazanych stron i kategorii będzie istniała możliwość przypisania unikalnego identyfikatora (aliasu) tak, aby np. artykuł dostępny pod URL-em „http://www.stat.gov.pl/kat1/kat2/kat3/OGLOSZENIE/” mógł otrzymać alias "ogloszenie", tzn. być dostępny pod skróconym adresem URL „http://www.stat.gov.pl/ogloszenie”.

ID F 45. Nazwa Statystyki odwiedzinOpis 1. CMS musi posiadać moduł statystyk umożliwiający prowadzenie

szczegółowych statystyk odwiedzin dla każdej kategorii i podkategorii oraz każdej strony i każdego pobieranego pliku dla poszczególnych serwisów.

2. CMS musi umożliwiać rozdzielenie odwiedzin zewnętrznych (Internet) od wewnętrznych pochodzących z sieci wewnętrznej GUS.

3. Statystyki muszą posiadać możliwość prezentacji w układzie zestawień godzinowych, dziennych, tygodniowych, miesięcznych i rocznych.

4. System musi zapewniać możliwość podglądu statystyk - zarówno dla całego serwisu, jak i poszczególnych jego składowych - zawierających minimum następujące informacje:

a. liczba wejść na stronę,b. liczba unikalnych Użytkowników,c. liczba powracających Użytkowników,d. czas trwania odwiedzin,e. informacje, skąd Użytkownik trafił do serwisu (bezpośrednio,

link na innej stronie, wyszukiwarka - ze wskazaniem jaka),f. słowa wyszukiwane w serwisie,g. statystyki i historia zapytań,h. rodzaj używanej przeglądarki,i. rodzaj używanego systemu operacyjnego,j. lokalizacja Użytkowników na podstawie adresu IP lub

informacja, że jest to adres znanej usługi lub operatora,k. ranking popularności poszczególnych obszarów, kategorii,

stron serwisu z podziałem miesięcznym,l. liczba wejść na stronę główną SPI, zawierającą drzewo

katalogów grupujących linki do raportów dynamicznych na najwyższym poziomie agregacji,

m. liczba wejść do każdego z poszczególnych katalogów,n. liczba wejść do każdego z raportów dynamicznych lub grup

raportów na poziomie linku do SWAID,o. liczba unikalnych Użytkowników PI GUS (we wszystkich

powyższych podziałach – strona główna SPI, katalogi, linki),


administracji.60

p. liczba powracających Użytkowników PI,q. czas trwania odwiedzin (we wszystkich powyższych

podziałach),r. słowa wpisywane w okno wyszukiwarki i prowadzące do

raportów lub grup raportów SWAID,s. liczba wejść, unikalnych Użytkowników PI i czas trwania

wizyt na stronach będących interfejsami REGON, TERYT i SMS.

5. System musi umożliwiać wykorzystanie zewnętrznych narzędzi do tworzenia statystyk (np. Google Analytics itp.).

6. System statystyki musi pozwalać na oddzielenie ruchu oglądanego od ruchu generowanego przez boty.

ID F 46. Nazwa Wersje językoweOpis 1. System musi umożliwiać dodanie w dowolnym momencie kolejnej

wersji językowej serwisu bez potrzeby wykonywania jakichkolwiek prac programistycznych, czy też zakupu dodatkowych licencji z tego powodu.

2. CMS musi umożliwiać delegowanie uprawnień do określonej wersji językowej dla wskazanych redaktorów. Domyślnie redaktor strony polskojęzycznej może także redagować wersję angielską.

3. Serwis w określonej wersji językowej ma prezentować tylko te kategorie, strony i artykuły, które zostały przetłumaczone na dany język i przeszły proces zatwierdzania i publikacji.

4. Tłumaczenia dla wersji językowej muszą uwzględniać wszystkie elementy interfejsu strony (wyszukiwarkę, galerię zdjęć itd.).

5. Wymagana jest internacjonalizacja CMS-a przynajmniej w zakresie 2 języków - polskiego i angielskiego. Wszystkie funkcje systemu generujące automatycznie określone informacje, np. linki, pozycje w archiwum, kalendarzu itp. powinny działać poprawnie i generować opisy w obu wersjach językowych.

6. System musi posiadać funkcję automatycznego wykrywania/zaznaczania nieprzetłumaczonych fragmentów.

7. Dla użytkownika zewnętrznego zmiana wersji językowej strony musi powodować przejście na stronę, która jest odpowiednikiem strony, z której następuje przełączenie.

ID F 47. Nazwa Panel administracyjnyOpis CMS musi być wyposażony w Panel administracyjny zawierający

wszystkie funkcje administracyjne i redakcyjne systemu, dostępny dla wybranych/zdefiniowanych użytkowników systemu.

ID F 48. Nazwa Funkcje administracyjne Opis 1. Administrator merytoryczny musi posiadać uprawnienia do

wszelkich kategorii administracyjnych w serwisie, w tym m.in. do:


administracji.61

zarządzania kontami użytkowników systemu (redaktorów itp.), w tym: dodawanie, usuwanie, modyfikacja, nadawanie uprawnień do określonych czynności w serwisie, w tym m.in. czynności redakcyjnych (tworzenie treści, edycja, usuwanie, korygowanie menu, zatwierdzanie, publikowanie itp.),

zarządzania profilami uprawnień (rolami), tworzenia grup użytkowników i nadawania uprawnień grupom, tworzenia i zarządzania polityką haseł (reguły dot. budowy

hasła, jego długości i złożoności, wymuszania zmiany przy następnym logowaniu),

definiowania zakresu dostępu do danych i plików gromadzonych w systemie.

2. CMS musi umożliwiać nadawanie uprawnień redaktorom do określonych wersji językowych, kategorii, stron, elementów serwisu, funkcjonalności (modułów, aplikacji) oraz folderów plików.

3. Uprawnienia muszą być dziedziczone kaskadowo, jednakże za zgodą Administratora merytorycznego będzie można uzyskać dostęp do innych zasobów treści, niż wynikające z dziedziczenia uprawnień.

4. CMS musi posiadać moduł autoryzacji użytkowników przy pomocy loginu i hasła i na tej podstawie identyfikować oraz określać zakres uprawnień konkretnego redaktora.

5. System musi umożliwiać delegowanie uprawnień administracyjnych do wybranych fragmentów serwisu dla wskazanej osoby lub grupy osób.

6. System musi umożliwiać eksport wybranych danych użytkowników do pliku .csv.

7. System musi umożliwiać wysłanie powiadomienia do wszystkich zalogowanych użytkowników CMS’a.

8. System musi udostępniać opcję wylogowania innego użytkownika przez administratora.

9. System musi udostępniać administratorowi opcję „uwolnienia” strony blokowanej przez innego użytkownika.

10. System musi umożliwiać dostęp do logów zdarzeń systemowych z poziomu interfejsu administracyjnego oraz zapewniać możliwość ich eksportu co najmniej do formatu TXT.

11. System musi umożliwiać dostęp do logów zdarzeń tylko administratorowi. Musi być zapewniona wiarygodność i bezpieczeństwo logów.

12. System musi umożliwiać odnotowanie daty wykonania każdej operacji oraz identyfikatora wykonującego operację.

13. System musi posiadać mechanizmy uniemożliwiające edycję i usuwanie plików zawierające logi zdarzeń systemowych oraz chroniące przed możliwością ich przepełnienia.

ID F 49. Nazwa Kosz i zakładki


administracji.62

Opis 1. CMS musi posiadać następujące funkcjonalności do wykorzystania przez redaktorów:

możliwość usunięcia wybranych elementów (stron, artykułów) do tzw. „kosza”,

komunikat ostrzegający przy próbie skasowania dowolnego elementu serwisu,

możliwość przywrócenia usuniętych elementów. 2. CMS musi umożliwiać tworzenie zakładek (tzw. ulubione) do

najczęściej używanych sekcji modułu administracyjnego.3. CMS musi umożliwiać przeglądanie, filtrowanie i sortowanie

elementów w koszu (wg daty usunięcia, lokalizacji, osoby usuwającej, kategorii).

ID F 50. Nazwa SchowekOpis CMS musi posiadać następujące funkcjonalności do wykorzystania

przez administratorów merytorycznych: możliwość dodania skrótu do wybranych stron, elementów

struktury serwisu, kopiowanie, przenoszenie wybranych stron, elementów treści, czyszczenia zawartości schowka.

ID F 51. Nazwa Historia operacjiOpis 1. CMS musi zapisywać i udostępniać historię wszystkich operacji

(włączenie z logowaniem) wykonywanych przez: administratorów i redaktorów w module redakcyjno-

administracyjnym, użytkowników zarejestrowanych w serwisie, dostępną do wglądu dla uprawionej osoby, z możliwością wyszukiwania i filtrowania, z wykorzystaniem co najmniej następujących atrybutów: data i czas operacji (z dokładnością do minuty), użytkownik, rodzaj operacji, miejsce wykonania operacji lub obiekt (dział, strona, plik itp.), na którym wykonano operację.

2. CMS musi także zapisywać w dzienniku systemowym operacje wykonywane automatycznie przez system, związane z publikowaniem treści (np. upublicznianie stron, „odpublicznianie” stron itp.)

3. System musi raportować błędy w działaniu CMS, w tym także kody błędów HTTP (np. 404 itp.) wygenerowane przez CMS.

4. System powinien umożliwiać konfigurowanie okresu przechowywania historii z czyszczeniem zawartości po upływie tego okresu.

ID F 52. Nazwa RSS 2.0, Atom 1.0Opis 1. CMS musi umożliwiać tworzenie kanałów informacyjnych w

formacie RSS i Atom (do wyboru) dla dowolnie zdefiniowanych


administracji.63

obszarów serwisu (kategoria, grupa kategorii itp.).2. System musi umożliwiać nadanie nazwy kanału oraz określenie

ilości treści i sposobu ich udostępniania (cała treść lub tytuł z nagłówkiem).

3. CMS musi umożliwiać wyświetlenie statystyk wywołań dla poszczególnych kanałów umieszczonych w serwisie.

ID F 53. Nazwa SondaOpis 1. CMS musi umożliwiać tworzenie sond.

2. Mechanizm tworzenia sond musi umożliwiać co najmniej: publikację pytań i list możliwych odpowiedzi z opcją wyboru

jednej z nich, podgląd aktualnych wyników sondaży w postaci graficznej

(wykres do wyboru: słupkowy poziomy, pionowy, kołowy) wraz z danymi liczbowymi,

określenie czasu trwania sondy (od-do) z dokładnością do godziny,

eksport wyników sondy (przez uprawionego redaktora) do XML lub MS Excel (plik CSV),

wydruk wyniku sondy.3. CMS musi posiadać mechanizm umożliwiający blokowanie

kilkukrotnego uczestnictwa w tej samej sondzie. 4. Wyniki sondy są gromadzone w bazie CMS.

ID F 54. Nazwa Zarządzanie baneramiOpis 1. CMS musi posiadać panel zarządzania banerami i umożliwiać

umieszczanie ich w dowolnych miejscach serwisów.2. Baner może mieć charakter informacyjny (bez odnośnika) lub być

odnośnikiem do innej strony w ramach serwisu lub poza nim. Może mieć postać pliku graficznego lub animacji Flash (plik SWF).

3. CMS musi umożliwiać określenie czasu ekspozycji konkretnego banera.

4. W ramach grup banerów musi być możliwość określania kolejności ich ułożenia, ilości banerów wyświetlanych jednocześnie w grupie oraz możliwość wskazania banerów, które mają być wyświetlane losowo spośród innych wybranych do wyświetlania w tym trybie.

5. System musi zliczać wyświetlenia i kliknięcia w baner sumarycznie i z podziałem na miesiące.

ID F 55. Nazwa Najczęściej zadawane pytania – FAQOpis System musi posiadać funkcjonalność umożliwiającą tworzenie bazy

pytań i odpowiedzi na nie (wraz z formularzem umożliwiającym zadawanie pytań oraz możliwość przesłania odpowiedzi bezpośrednio z panelu administracyjnego do zainteresowanej osoby), sortowania, filtrowania i wyszukiwania wg tematu, słów kluczowych. Musi istnieć


administracji.64

możliwość wyłączenia formularza oraz budowania bazy pytań i odpowiedzi bezpośrednio w panelu administracyjnym przez samych redaktorów witryny.

ID F 56. Nazwa Czas publikacji i współpraca wielu redaktorówOpis 1. CMS musi zapewniać publikację opracowanego zestawu stron

jednocześnie dokładnie o ustalonym czasie (albo zgodnie z terminem publikacji z kalendarza albo ustawionym przez redaktora), np. notatka „Budownictwo mieszkaniowe w okresie I-III 2012 r.” występuje w swoim dziale tematycznym, w wynikach wstępnych, w angielskiej wersji językowej i przez pewien czas po publikacji także na stronie głównej w dziale aktualności. We wszystkich tych miejscach gotowa publikacja powinna zostać opublikowana w tym samym czasie (zgodnym z kalendarzem publikacji).

2. Przygotowana, lecz czekająca na opublikowanie informacja nie może zostać opublikowana przed wyznaczonym czasem publikacji.

3. Publikacja innej powiązanej informacji po przygotowaniu strony czekającej na publikację nie może spowodować ani przedwczesnej publikacji strony oczekującej, ani opóźnienia publikacji. CMS musi zapewniać bezpieczną współpracę wielu redaktorów, których strony odwołują się do tych samych miejsc w portalu (działu tematycznego, strony głównej, archiwum).

4. CMS musi zapewniać dla użytkownika mającego prawo publikowania możliwość automatycznego uwalniania strony zgodnie z ustawionym czasem publikacji.

5. System musi zapewniać możliwość wewnętrznej komunikacji redaktorów.

ID F 57. Nazwa Rejestr zmian treści w projekcie BIP Opis CMS musi umożliwić stworzenie na każdej stronie BIP (w wersji

polskiej) metryki rejestru zmian treści, składającej się m.in. z pól: podmiot publikujący, osoba odpowiedzialna za treść informacji, osoba publikująca informację, data wytworzenia informacji, data publikacji informacji, data aktualizacji informacji.

ID F 58. Nazwa Moduł dziennika zmian treści BIP Opis CMS musi również umożliwić stworzenie (w oparciu o rejestr zmian

treści BIP) i wprowadzenie do BIP modułu „dziennika zmian”, umożliwiającego wyszukanie wszystkich zmian dokonanych w całym projekcie BIP (w obrębie stron i dokumentów w wersji polskiej) w określonym przedziale czasowym (od-do).

ID F 59. Nazwa Dzienniki Urzędowe GUSProjekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


65

Opis Serwis wykonany zgodnie z wytycznymi zawartymi w Ustawie o ogłaszaniu aktów normatywnych i niektórych innych aktów prawnych (Dz.U.2000.62.718) oraz Rozporządzeniu Prezesa Rady Ministrów z dnia 27 grudnia 2011 r. w sprawie wymagań technicznych dla dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, dzienników urzędowych wydawanych w postaci elektronicznej oraz środków komunikacji elektronicznej i informatycznych nośników danych (Dz. U. 2011.289.1699).

CMS musi umożliwić wyszukiwanie w module według następujących kryteriów: rok, pozycja, tytuł, data opublikowania.

ID F 60. Nazwa Moduł sklepu internetowego Zakładu Wydawnictw Statystycznych (ZWS) - asortyment, zarządzanie magazynem

Opis Zamawiający dopuszcza zakupienie gotowego modułu sklepu internetowego i zintegrowanie go z CMS i modułem sprzedaży. Baza publikacji pobierana z istniejącego modułu sprzedaży z możliwością częstej aktualizacji.Możliwość rozbudowy bazy - wstawianie dodatkowych pól. Zarządzanie produktami, ich stanem magazynowym, w tym:

aktualizacja, sygnalizowanie stanu, dowolna ilość cech produktów, filtrowanie, sortowanie produktów.

ID F 61. Nazwa Moduł sklepu internetowego ZWS – organizacja magazynu

Opis 1. Moduł szacowania kosztów dostawy (różne parametry - waga, wymiary itp.)

2. Moduł wspomagający logistykę magazynu.

ID F 62. Nazwa Moduł sklepu internetowego ZWS – interfejs klientaOpis 1. Czytelny, przyjazny, intuicyjny interfejs.

2. Zakupy dla osób zarejestrowanych oraz możliwość zakupów jednorazowych (bez rejestracji).

3. Czytelny formularz do składania zamówienia.4. Katalog publikacji w podziale na grupy tematyczne (zgodnie z

planem wydawniczym), rok wydania i formę wydawniczą (papier, CD).

5. Własna wyszukiwarka publikacji.6. Historia zamówień oraz dane klienta (dla klientów

zarejestrowanych).7. Specyfikacja produktu, warianty (książka, CD, rodzaj oprawy).8. Zapowiedzi, nowości.


administracji.66

9. Opis publikacji (tzw. zajawka). 10.Podgląd i edycja koszyka.11.Sprawdzenie stanu zamówienia (potwierdzone, wysłane itp.).12.Atrakcyjna grafika: możliwość umieszczania przez administratora merytorycznego

elementów graficznych np. tła, logotypy, okładki publikacji itp., możliwość powiększenia zdjęcia po najechaniu kursorem.

13.Wybór formy płatności. 14.Wybór formy dostawy.15. Wyświetlanie produktów powiązanych z danym produktem.

ID F 63. Nazwa Moduł sklepu internetowego ZWS - zamówienia i obsługa klienta

Opis 1. Możliwość dodawania, usuwania oraz edycji produktów w zamówieniu.

2. Filtrowanie, sortowanie zamówień (np. data złożenia, dane klienta itp.).

3. Lista zamówień z podglądem szczegółów. 4. Czas realizacji i status zamówienia.5. Zwroty i reklamacje.6. E-mailowe powiadomienia o złożeniu i zmianie statusu zamówienia.7. Zapewnione bezpieczeństwo danych.8. Baza klientów (przeniesienie z obecnego systemu) i wygodne

zarządzanie bazą: lista klientów (dane adresowe i inne, możliwość tworzenia

nowych pól), edycja danych klientów, statystyki zakupów, grupy rabatowe, zaawansowane wyszukiwanie użytkowników.

9. Możliwość tworzenia nowych pól formularzy.

ID F 64. Nazwa Moduł sklepu internetowego ZWS - raporty i fakturyOpis 1. Możliwość wysyłania reklam, powiadomień (nowości) do własnej

bazy klientów.2. Tworzenie faktur proforma.3. Statystyki sprzedaży - raporty.

ID F 65. Nazwa Moduł sklepu internetowego ZWS - płatności Opis 1. Różne formy płatności:

a. przelew,b. płatność kartą,c. PayPal,d. PayU,e. możliwość dodawania i usuwania różnych sposobów płatności,f. możliwość wyboru, które formy płatności są widoczne dla


administracji.67

Klienta.2. Potwierdzenie płatności. 3. Bezpieczeństwo.

ID F 66. Nazwa Moduł sklepu internetowego ZWS - dostawaOpis 1. Przesłanie pocztą:

koszty według taryfikatora Poczty Polskiej, możliwość wprowadzenia innych parametrów.

2. Odbiór osobisty3. Przesyłki kurierskie.4. Możliwość dodawania i usuwania różnych form dostawy.

ID F 67. Nazwa Moduł sklepu internetowego ZWS - zarządzanie treściąOpis 1. Łatwe dodawanie zawartości, aktualizacja.

2. Łatwe dodawanie stron informacyjnych (np. regulamin, jak kupować).

ID F 68. Nazwa Pomoc kontekstowaOpis System musi być wyposażony w dostępną z poziomu Systemu (dla

administratorów i redaktorów) pomoc kontekstową, odnoszącą się do zawartości okna wyświetlanego w danym czasie na ekranie użytkownika.

ID F 69. Nazwa Kody 2 D (fotokody)Opis CMS musi umożliwiać generowanie kodów 2D dla wybranych

rodzajów treści, np. odsyłaczy, danych kontaktowych, wybranych fragmentów treści.

6.7. Wymagania techniczne i bezpieczeństwaID B 1. Nazwa Budowa systemuOpis 1. Interfejs użytkownika dostarczonego systemu musi być dostępny

na dzień składania ofert w całości w języku polskim.2. CMS musi być wykonany zgodnie z wzorcem projektowym MVC

(model-widok-kontroler) zakładającym oddzielenie danych od części biznesowej i interfejsu użytkownika.

3. CMS musi być wykonany w architekturze opartej na usługach (SOA).

4. CMS musi być oparty o relacyjną bazę danych w standardzie SQL (lub równoważnym). Baza danych musi być przystosowana do pełnego wykorzystania sprzętu w przypadku dużego obciążenia/wzmożonych operacji na bazie.

5. CMS musi być wykonany w technologii ASP.NET lub równoważnej tj. takiej, która umożliwia wykorzystanie usług i funkcji (IIS, NET.Framework) zintegrowanych z system operacyjnym.


administracji.68

ID B 2. Nazwa Kodowanie znaków (łącznie z bazami danych)Opis 1. CMS musi kodować znaki i zapewniać pełne wsparcie standardu

Unicode UTF-8 wersja 3.0.2. Wszelkie treści umieszczane przez redaktorów serwisu powinny

być automatycznie konwertowane do tego zestawu znaków.

ID B 3. Nazwa Generowanie treści (cachowanie)Opis CMS musi posiadać system tworzenia statycznych kopii treści

generowanych dynamicznie (caching). System musi minimalizować ilość odwołań do bazy danych oraz obciążenia serwera związane z generowaniem treści.CMS musi posiadać zabezpieczenia na wypadek nagłego wzrostu ruchu na stronie, który wyłączy funkcjonalności serwisu generujące największe obciążenia serwera i łącza.

ID B 4. Nazwa Optymalizacja dla wyszukiwarekOpis 1. CMS musi posiadać możliwość optymalizacji każdej strony serwisu

pod kątem wyszukiwania (SEO – Search Engine Optimization).2. System musi umożliwiać indywidualne wypełnianie atrybutów alt

grafik używanych w serwisach.

ID B 5. Nazwa Obsługa błędówOpis 1. CMS musi posiadać mechanizm obsługi błędów poprzez

możliwość dostosowania stron błędów (np. 404) dla każdego z serwisów tematycznych w ramach systemu.

2. System musi generować prawidłowe kody błędów HTTP (prawidłowo rozpoznawane przez wyszukiwarki internetowe) dla nieistniejących, przeniesionych lub „odpublicznionych” elementów serwisu (plików, kategorii, artykułów).

ID B 6. Nazwa Import i export danychOpis 1. CMS musi posiadać mechanizmy importu i eksportu wybranego

zakresu kategorii, stron, artykułów, notatek, publikacji z/do plików XML o zdefiniowanej strukturze.

2. Strukturę zdefiniuje i szczegółowo opisze w dokumentacji sytemu wykonawca.

ID B 7. Nazwa Bezpieczny dostępOpis 1. Dostęp do systemu musi odbywać się za pomocą bezpiecznego

połączenia SSL z kluczem o długości co najmniej 128 bitów dla wszystkich administratorów i redaktorów serwisu.

2. System musi umożliwiać ograniczenia dostępu do części administracyjnej serwisu tylko z określonych adresów, bądź puli adresów IP.

3. Administrator merytoryczny musi mieć możliwość - z poziomu Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


69

panelu administracyjnego CMS - włączenia bezpiecznego połączenia SSL dla określonych działów, czy artykułów w serwisie.

4. System musi umożliwiać uwierzytelnienie administratorów i redaktorów w oparciu o bazę ActiveDirectory.

5. System musi umożliwiać uwierzytelnianie użytkowników na podstawie unikatowego identyfikatora i niejawnego hasła.

6. System musi umożliwiać wskazanie, czy dany redaktor ma być uwierzytelniany w oparciu o ActiveDirectory czy wewnętrzną bazę haseł systemu.

7. System musi umożliwiać tworzenie i zmianę reguł dotyczących długości oraz stopnia skomplikowania haseł przechowywanych w bazie systemu, a także umożliwiać określenie czasu, po którym konieczna będzie zmiana hasła.

8. Hasła użytkowników nie mogą być przechowywane w bazie systemu w postaci jawnej, lecz z wykorzystaniem bezpiecznej funkcji skrótu (np. SHA)

9. System musi umożliwiać ustawienie przez administratora czasu bezczynności w systemie, po którym redaktor zostanie automatycznie wylogowany z systemu.

10. System musi umożliwiać włączenie mechanizmu blokowania kilkukrotnego jednoczesnego logowania się tego samego użytkownika.

11. System musi czasowo blokować konto (z możliwością ręcznego odblokowania przez uprawionego administratora) przy wielokrotnej próbie zalogowania niewłaściwym hasłem - ilość prób musi być możliwa do ustalania przez administratora.

ID B 8. Nazwa Zabezpieczenie systemuOpis 1. System musi uniemożliwiać dostęp do udostępnianych funkcji i

zgromadzonych w nim danych z pominięciem mechanizmów bezpieczeństwa.

2. System musi być odporny na znane techniki ataku i włamań, w tym m.in. na:

SQL Injection, penetrację niepublicznych zasobów serwera ("path

traversal", "Google hacking"), wstrzykiwanie kodu ("code injection"), przejmowanie serwera przez dostęp z poziomu kodu do

„shell", wstrzykiwanie komend systemowych, narzucenie sesji - ataki "session fixation", "session adoption", kradzież sesji za pomocą "cross-site scripting" (XSS), nieautoryzowane operacje w aplikacji - ataki "cross-site

request forgery" (CSRF).W przypadku pojawienia się nowych, nieznanych wcześniej, technik włamań wykonawca zobowiązany jest do ich analizy i dostarczenia


administracji.70

niezbędnych poprawek i uaktualnień eliminujących podatności dostarczonego CMS.3. System musi filtrować i walidować wszystkie dane wejściowe, np.

wprowadzane przez użytkowników do udostępnionych formularzy, w celu zminimalizowania ryzyka naruszenia integralności systemu, bądź danych.

ID B 9. Nazwa Audyt bezpieczeństwa platformy sprzętowo-programowej i CMS

Opis 1. Wykonawca przeprowadzi audyt bezpieczeństwa dostarczonego Systemu zainstalowanego i skonfigurowanego na docelowej platformie sprzętowej.

2. Wykonawca przeprowadzi skanowanie skanerami podatności środowiska systemowego (system operacyjny, baza danych, serwer aplikacyjny, serwer WWW, itp.) i CMS na próby włamań oraz przeprowadzi symulacje i próby włamań.

3. Z przeprowadzonego audytu bezpieczeństwa wykonawca przedstawi szczegółowy raport zawierający specyfikację i opis przeprowadzonych testów oraz uzyskanych wyników wraz z rekomendacją działań zapobiegających powstawaniu zidentyfikowanych incydentów.

4. W przypadku wykrycia jakiejkolwiek podatności wykonawca przystąpi do niezwłocznego usunięcia jej przyczyny.

5. Audyt musi zostać przeprowadzony w ramach wdrożenia (etap II) oraz okresowo nie rzadziej niż co 12 miesięcy w ramach gwarancji.

ID B 10. Nazwa Dodatkowy audyt bezpieczeństwaOpis Zamawiający zastrzega sobie możliwość przeprowadzenia (w

dowolnym czasie w trakcie trwania okresu gwarancyjnego) dodatkowego audytu bezpieczeństwa osobiście lub przez wybraną firmę trzecią. wykonawca zobowiązany jest do uwzględnienie uwag i wniosków z takich testów i wprowadzenia niezbędnych zmian i poprawek w dostarczanym systemie.

ID B 11. Nazwa Przegląd SystemuOpis 1. W ramach świadczonych gwarancji wykonawca zobowiązany jest,

nie rzadziej niż co 12 miesięcy, do przeprowadzenia przeglądu dostarczonego Systemu, w tym ostatni przegląd powinien nastąpić w ostatnim miesiącu obowiązywania gwarancji. Minimalny zakres prac wykonywanych w ramach przeglądu musi obejmować: weryfikację poprawności konfiguracji całego Systemu wraz

z ewentualną aktualizacją konfiguracji do stanu zalecanego, weryfikację aktualności i poprawności działania procedur i

instrukcji eksploatacyjnych wraz z ich ewentualną aktualizacją,


administracji.71

weryfikację poprawności pracy poszczególnych komponentów składających się na System, wraz z usunięciem ewentualnych nieprawidłowości w ich funkcjonowaniu.

2. Przeglądy odbywać się będą w terminie uzgodnionym z Zamawiającym.

3. Przed przystąpieniem do przeglądu wykonawca przedstawi do zatwierdzenia szczegółowy plan Przeglądu Systemu.

6.8. Użyteczność, estetyka, ergonomia i dostępnośćID U 1. Nazwa Interfejs użytkownika Opis 1. Wszystkie tworzone w trakcie wdrożenia serwisy muszą zostać

zoptymalizowane do wyświetlania na monitorach komputerowych w rozdzielczości 1024x768 i wyższych oraz przy 32 bitowej palecie kolorów.

2. Serwisy powinny się prawidłowo wyświetlać na urządzeniach mobilnych (smartfonach, tabletach, netbookach).

3. Preferowane jest dynamiczne dostosowanie zawartości i wielkości elementów na stronach internetowych do wielkości i rozdzielczości ekranu (Responsive Web Design).

4. Serwisy powinny posiadać dedykowane profile z ograniczoną funkcjonalnością i szatą graficzną dostosowaną do ograniczonej wielkości ekranu.

5. Dostępność serwisu dla urządzeń mobilnych może być zapewniona poprzez osobną wersje strony (analogicznie do wersji WAI).

6. Wszystkie elementy mające wpływ na szybkość ładowania stron (kod HTML, arkusze styli CSS, plik JavaScript, pliki graficzne) muszą zostać zoptymalizowane pod tym kątem.

7. Serwis powinien być zaprojektowany w sposób przejrzysty i funkcjonalny, w tym zakresie.

ID U 2. Nazwa Komunikacja Redaktorów z SystememOpis 1. Pokazywanie statusu Systemu. CMS musi zawsze informować

użytkownika co się dzieje poprzez odpowiednie potwierdzenie wykonywanych operacji oraz komunikaty o wykonywanych operacjach.

2. Zgodność pomiędzy systemem a rzeczywistością. System musi używać do komunikacji z użytkownikiem zrozumiałego języka i posługiwać się zrozumiałymi analogiami zaczerpniętymi z rzeczywistości.

3. Użytkownik musi posiadać pełną kontrolę nad wykonywanymi w systemie działaniami. Użytkownicy często wybierają błędne opcje i dlatego powinni mieć zapewnione “wyjście awaryjne”, np. za pomocą funkcji “cofnij” i “powtórz”, „anuluj” itp. (wydostanie się z części systemu, która nie interesuje użytkownika bez zniszczenia lub modyfikacji danych).

4. Standaryzacja i zachowanie spójności. Te same słowa, Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


72

symbole, kolory, sytuacje i działania powinny być stosowane w jednakowy sposób w całym systemie, w zgodzie z zasadami przyjętymi dla danego środowiska, platformy czy systemu (użytkownicy powinni być w stanie nauczyć się kolejności czynności w jednej części systemu i użyć jej w innej otrzymując podobny rezultat).

5. Zapobieganie błędom. Dopracowanie dialogu z użytkownikiem w taki sposób, aby wybranie dowolnych opcji dostępnych w interfejsie użytkownika nie prowadziło do nieprawidłowego działania systemu.

6. Stosowanie list wyboru. Stosowanie wszędzie, gdzie to jest możliwe w systemie, list wyboru oraz wartości słownikowych tak, aby działania użytkownika były wynikiem wyboru z listy, a nie przywoływania z pamięci; wszystkie potrzebne w danej sytuacji informacje i instrukcje powinny być cały czas widoczne na ekranie, aby nie obciążać pamięci użytkownika.

7. Zapewnienie elastyczność i efektywność. Użytkownicy powinni mieć możliwość dopasowywania sposobu wykonywania typowych zadań oraz dostępu “na skróty” do potrzebnych funkcji czy obszarów systemu (ulubione; najczęściej wykonywane operacje w systemie; pamięć ścieżki do ostatnio używanego folderu; dane do których powinien mieć dostęp na bieżąco; takie skróty pozwalają zaawansowanym użytkownikom na pomijanie dialogów i komunikatów informacyjnych, których nie potrzebują).

8. Interfejs graficzny. Oszczędny („lekki”) i czytelny interfejs użytkownika. Eliminacja zbędnych elementów graficznych.

9. Obsługa błędów. Komunikaty o błędach powinny być sformułowane prostym i zrozumiałym dla przeciętnego użytkownika systemu językiem oraz powinny wskazywać: kod błędu oraz typ problemu, opis błędu oraz sposób jego rozwiązania (w przypadku znanych/standardowych błędów serwisu).

10.Pomoc systemowa powinna umożliwiać szybkie odnalezienie żądanej informacji, a instrukcje rozwiązywania problemów powinny być zwięzłe i dotyczyć zadań użytkownika, dostępne w języku polskim.

11.Czas reakcji systemu. Czas odpowiedzi na zlecenie wykonania operacji przez użytkownika musi być krótszy niż 8 sek. W przypadku operacji, których wykonanie ze względu na ich charakter będzie dłuższe, niż wskazany czas odpowiedzi, system musi prezentować użytkownikowi informację o zajętości i informować o rodzaju wykonywanej operacji oraz ewentualnie o szacowanym czasie zakończenia jej wykonywania.

12.Walidacja danych. CMS musi być zdolny do weryfikowania wprowadzanych danych do formularzy, tj. muszą istnieć słowniki systemowe oraz reguły na podstawie których będą


administracji.73

weryfikowane dane wprowadzane do formularzy, np. dane adresowe, wartości tekstowe, liczbowe, słowniki, maski wprowadzania danych itp.

13.Podwójne kliknięcie. System musi być odporny na tzw. podwójne kliknięcie w link lub przycisk na interfejsie. Operacja taka wywołana przez użytkownika nie może powodować nieprawidłowego działania systemu.

14.Oznaczanie pól wymagalnych. CMS musi oznaczać pola, których wypełnienie jest wymagane oraz weryfikować, czy takie pola zostały wypełnione przez użytkownika.

15.Sortowanie. Liczby muszą być sortowane jak liczby, a nie jak tekst; tekst musi być sortowany zgodnie z alfabetem polskim.

16.Formatowanie dat. Format daty w polach powinien być możliwy do ustawienia przez Administratora merytorycznego. Sortowanie dat rosnąco i malejąco powinno być niezależne od formatu daty wyświetlanej.

ID U 3. Nazwa Technologia budowy interfejsuOpis 1. Wszystkie strony serwisów muszą być zgodne co najmniej ze

standardem XHTML 1.0 Transitional i CSS2.1. 2. Wymagana jest prawidłowa walidacja tworzonego przez CMS kodu

HTML i CSS za pomocą udostępnianego na stronach W3C walidatora (http://validator.w3.org/).

3. System oraz udostępniane za jego pomocą serwisy muszą być oparte na stylach CSS do formatowania prezentowanych treści, a struktura dokumentu zapewniać poprawność semantyczną oraz oddzielenie wyglądu od treści .

ID U 4. Nazwa Dostępność w przeglądarkach internetowychOpis 1. Serwis musi poprawnie realizować założone funkcjonalności co

najmniej w następujących przeglądarkach: Internet Explorer, Mozilla Firefox, Opera, Chrome od wersji najnowszej do trzech wersji wstecz2).

2. Moduł redakcyjno-administracyjny musi prawidłowo działać co najmniej w przeglądarkach: Internet Explorer, Mozilla Firefox, Opera, Chrome od wersji najnowszej do trzech wersji wstecz2).

3. Jeśli w CMS wykorzystany będzie kod JavaScript, on także musi prawidłowo działać w wymienionych w pkt.1 przeglądarkach.

ID U 5. Nazwa DostępnośćOpis 1. System musi być zgodny z punktami kontrolnymi o priorytecie 1 i 2

(Podwójne-A), określonymi w ramach Wytycznych Dotyczących Dostępności Treści Internetowych 1.0 (WCAG 2.0) Inicjatywy

2 W przypadku Internet Explorer nie jest wymagane dostosowanie do wersji 6Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


74

Przystępnej Sieci (WAI) opracowanej przez World Wide Web Consortium (W3C).

2. System musi być wyposażony w mechanizmy ułatwiające przeglądanie treści przez osoby niedowidzące: tekst alternatywny, zmiana wielkości czcionki bez odnoszenia się bezpośrednio do ustawień przeglądarki.

3. System musi posiadać wersję tekstową strony z możliwością włączenia opcji „wysoki kontrast” spełniającej wymagania WCAG na poziomie AA.

4. W przypadku wykresów lub map system powinien przekierować czytnik ekranowy osoby niewidomej do źródła danych (tabeli). W efekcie zamiast suchej informacji o obiekcie graficznym, użytkownik otrzyma, np. taki komunikat: „Mapa <tytuł>, <pierwszy region> <wartość>, <drugi region>, <wartość>...”. Po pierwszych pięciu regionach użytkownik powinien zostać poinformowany o liczbie pozostałych regionów i zapytany, czy chce kontynuować odczytywanie zawartości mapy, czy przejść do kolejnego elementu na stronie.

5. Dla zapewnienia dostępności dla osób korzystających wyłącznie z klawiatury system musi zapewniać wsparcie dla skrótów klawiaturowych oraz klawiszy przejścia [tab]. Skróty klawiaturowe muszą być przypisane do wskazanych działów i opcji serwisu związanych z dostępem do treści, z możliwością modyfikacji. Skróty klawiaturowe nie mogą interferować ze sposobem wpisywania polskich znaków oraz standardowymi poleceniami obsługi przeglądarki.

6. System musi zawierać stronę z informacją o dostępności serwisu dla osób niepełnosprawnych zawierającą m.in. listę skrótów klawiaturowych wraz z informacją o ich używaniu w różnych przeglądarkach internetowych (przykład takiej strony: (http://www.niepelnosprawni.gov.pl/dostepnosc).

ID U 6. Nazwa Nawigacja Opis 1. Na każdej stronie muszą znajdować się elementy nawigacyjne

przedstawiające aktualną lokalizację użytkownika w serwisie.2. Komponenty widoczne na wielu stronach, takie jak np. menu,

powinny znajdować się zawsze w tym samym miejscu i nie mogą znacząco różnić się wyglądem.

3. Przycisk „dalej/wstecz” w przeglądarce nie może być blokowany i musi wykonywać akcje zgodne z oczekiwaniem użytkownika: przenosić go na stronę poprzednią lub następną.

4. Jeżeli są stronicowane artykuły, to oprócz przycisków z numerami kolejnymi stron muszą być przyciski „na początek” oraz „na koniec” (do pierwszej, do ostatniej).


administracji.75

ID U 7. Nazwa OdnośnikiOpis 1. Odnośniki na stronie muszą być odpowiednio wyróżnione graficznie

(np. podkreślone, zaznaczone innym kolorem itp.).2. Odnośniki muszą być domyślnie budowane bez użycia kodu

JavaScript. W przypadku wystąpienia takiej konieczności parametr „href” musi zostać wypełniony.

3. Wszystkie odnośniki wskazujące na strony w ramach serwisu muszą być domyślnie otwierane w tym samym okienku przeglądarki.

4. Wszystkie odnośniki wskazujące na strony poza serwisem muszą być domyślnie otwierane w nowym okienku przeglądarki.

6.9. Wydajność i skalowalnośćID W 1. Nazwa Analizy wydajnościOpis Wykonawca zobowiązany jest do przeprowadzania analizy wydajności

Systemu po migracji do niego danych z obecnych serwisów Zamawiającego. W ramach testów wydajnościowych System musi być obciążany docelową ilością Użytkowników, tj. 50 na sekundę (80% pobierających dynamicznie tworzone strony, 20% wyszukujących informacje na stronie), korzystających z systemu jednocześnie. Przy takim założeniu czas odpowiedzi systemu (załadowania się żądanej strony) nie może być dłuższy niż 8 sekund (dla połączenia LAN 100Mb/s).

Ponadto wykonawca musi dokonać pomiarów i przedstawić w dokumentacji następujące parametry Systemu:1. Maksymalna liczba użytkowników na sekundę korzystających

jednocześnie z serwisów, przy której System spełnia jeszcze wymagania dotyczące czasu odpowiedzi (tj. 8 sekund).

2. Symulowany poziom wydajności systemu dla kolejnych 5 lat przy założeniu, że co roku ilość danych w systemie rośnie o połowę, przyjmując za początkową wartość ilość danych zaimportowanych w trakcie wdrożenia. Symulacja musi dać odpowiedź co najmniej na następujące pytania:Czy czas odpowiedzi systemu mieści się w założonej wcześniej granicy?Jaka może być maksymalna liczba użytkowników na sekundę obsługiwanych jednocześnie przez System, przy których System spełnia jeszcze wymagania dotyczące czasu odpowiedzi?

ID W 2. Nazwa Stabilność pracy CMSOpis System musi zapewniać stabilność pracy serwera rozumianą jako

zdolność do automatycznego przywrócenia poziomu usługi po przeciążeniu, podczas którego usługa była świadczona poza


administracji.76

kryteriami dostępności. Po osiągnięciu krytycznych wartości odpowiedzi i błędów po przeciążeniu, serwer musi powracać do stabilnej pracy umożliwiającej powtórzenie testów wydajnościowych z porównywalnymi wynikami.

ID W 3. Nazwa Dodatkowe testy wydajnościoweOpis Zamawiający zastrzega sobie możliwość przeprowadzenia (w

dowolnym czasie, w trakcie trwania okresu gwarancyjnego) dodatkowych testów wydajnościowych osobiście lub przez wybraną firmę trzecią. Wykonawca zobowiązany jest do uwzględnienie uwag i wniosków z takich testów i wprowadzenia niezbędnych zmian i poprawek w dostarczanym systemie.

ID W 4. Nazwa SkalowalnosćOpis 1. System zapewni skalowalność gwarantującą rozszerzenie ilości

obsługiwanych użytkowników (stanowisk) oraz pracę w środowisku rozproszonym.

2. System musi sprawnie funkcjonować w warunkach rosnącej liczby użytkowników, objętości przetwarzania danych lub/i rozwoju sieci komputerowej.

3. Liniowy wzrost liczby i rozmiaru danych przechowywanych w ramach Systemu nie może zwiększać czasu wyszukiwania bardziej niż liniowo.

4. System musi zapewnić skalowalność systemu w zakresie rozbudowy sprzętu komputerowego.

6.10. SzkoleniaID SK 1. Nazwa Wymagania dotyczące szkoleń Opis 1. W ramach wdrożenia, wykonawca przeprowadzi cykl szkoleń

dotyczących wdrażanego Systemu.2. Szkolenie musi zostać przeprowadzone na wersji sytemu

przygotowanej na potrzeby szkoleń przez wykonawcę na swoim serwerze.

3. Szkolenia zostaną przeprowadzone w siedzibie Zamawiającego w terminach uzgodnionych wcześniej z Zamawiającym.

4. Szkolenia odbędą się w godzinach pracy Zamawiającego.5. Wykonawca określi niezbędny wymiar szkoleń dla poszczególnych

grup użytkowników, przy czym minimalny efektywny czas trwania szkolenia to 10 godzin zegarowych, przy założeniu że czas przerw nie jest wliczany w czas szkolenia.

6. Grupa szkoleniowa nie może liczyć więcej niż 20 osób. 7. Każde ze szkoleń musi być prowadzone przez co najmniej 2

trenerów ze strony wykonawcy.8. Przed rozpoczęciem szkoleń wykonawca przedstawi

Zamawiającemu do zatwierdzenia zakres szkoleń i materiały Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego


77

szkoleniowe dla poszczególnych rodzajów szkolonych grup.9. Wykonawca przeszkoli nie więcej niż 60 osób.10.Wykonawca zapewni uczestnikom szkoleń spoza Warszawy (35

osób) zakwaterowanie wraz z wyżywieniem (śniadanie).11.Przed rozpoczęciem szkolenia wykonawca przygotuje stanowiska

komputerowe udostępnione przez Zamawiającego do przeprowadzenia szkolenia.

12.Środowisko szkoleniowe dla administratorów musi zostać przygotowane w postaci obrazu VMWare.

ID SK 2. Nazwa Certyfikaty uczestnictwa w szkoleniuOpis Uczestnicy szkoleń otrzymają certyfikaty uczestnictwa w szkoleniu

zawierające co najmniej następujące informacje: data i miejsce przeprowadzenia szkolenia, imię i nazwisko trenera/trenerów prowadzących szkolenie, wymiar szkolenia (ilość godzin), szczegółowy zakres tematyczny szkolenia, poziom przyswojonej wiedzy przez osobę uczestniczącą w

szkoleniu.

6.11. Migracja danychID M 1. Nazwa Przeniesienie danych z serwisu www.stat.gov.plOpis Wykonawca dokona przeniesienia wszystkich danych (strony, pliki itp.)

z serwisu www.stat.gov.pl do nowych szablonów w nowobudowanym serwisie, opartym o dostarczony i skonfigurowany CMS. Potwierdzeniem wykonania migracji będzie raport z migracji.

ID M 2. Nazwa Przeniesienie danych z serwisu www.stat.gov.pl/bipOpis Wykonawca dokona przeniesienia wszystkich danych (strony, pliki itp.)

z serwisu www.stat.gov.pl/bip do nowych szablonów w nowym serwisie opartym o dostarczony i skonfigurowany CMS. Potwierdzeniem wykonania migracji będzie raport z migracji.


administracji.78





ID M 3. Nazwa Przeniesienie danych z pozostałych serwisów statystyki publicznej

Opis Wykonawca dokona przeniesienia wszystkich danych (strony, pliki itp.) z serwisów:

16 urzędów statystycznych, Zakładu Wydawnictw Statystycznych, Polskiego Towarzystwa Statystycznego, Centrum Informatyki Statystycznej, Dzienniki Urzędowe GUS,

do nowych szablonów w nowych serwisach opartych o dostarczony i skonfigurowany CMS.Potwierdzeniem wykonania migracji będzie raport z migracji.Migracji podlegać będzie ok. 100 tysięcy plików (m.in. w postaci HTML, MS Office, Acrobat Adobe, Adobe Flash) i 20 tysięcy stron html (informacje dotyczą stron GUS, BIP GUS i pozostałych jednostek statystyki publicznej);

6.12. TestyID T 1. Nazwa Testy cząstkoweOpis 1. Organizowane przez wykonawcę testy poszczególnych

komponentów i funkcjonalności odbędą się z udziałem wyznaczonych przedstawicieli Zamawiającego.

2. Wykonawca jest odpowiedzialny za: przygotowanie danych testowych, przygotowanie scenariuszy testów, przygotowanie środowiska testowego, konfigurację środowiska testowego, ładowanie danych testowych.

Prace przygotowawcze wymagają akceptacji Zamawiającego.3. Testy mają zapewnić użytkownikom końcowym możliwość oceny

funkcjonalności przygotowanego Systemu, wykrycia w nim błędów na jak najwcześniejszym etapie i zgłoszenie ewentualnych uwag, zmian i uzupełnień do założonej funkcjonalności.

ID T 2. Nazwa Testy akceptacyjneCelem testów akceptacyjnych jest potwierdzenie spełnienia przez System kryteriów jakościowych oraz potwierdzenie, że funkcjonalność jest zgodna z wymaganiami Zamawiającego.Wynikiem testów akceptacyjnych jest raport z testów, stanowiący podstawę sporządzenia protokołu odbioru systemu.Na testy akceptacyjne składają się następujące rodzaje testów:

testy funkcjonalności - weryfikujące implementację


administracji.79

funkcjonalności z podaną w specyfikacji. Podczas testów system jest traktowany jak czarna skrzynka, na wejściu której podajemy przygotowane dane wejściowe sprawdzamy, czy otrzymane wyniki zgadzają się z oczekiwanymi;

testy modułów - testy funkcjonalne określonego fragmentu systemu, sprawdzające czy określony fragment systemu spełnia wyspecyfikowane mu wymagania. Weryfikują, czy możliwe jest zrealizowanie wszystkich dopuszczalnych akcji oraz niemożliwa jest realizacji sytuacji wyjątkowych (akcje zabronione);

testy interfejsu użytkownika - weryfikacja poprawności i kompletności nawigacji w systemie, sprawdzenie poprawności implementacji i działania interfejsu użytkownika;

testy administracyjne - testy funkcji i procedur administracyjnych dla systemu;

testy instalacji i konfiguracji - sprawdzenie kompletności instalacji i zgodności jej przebiegu z instrukcjami i dokumentacją oraz sprawdzenie poprawności uzyskanej konfiguracji;

testy integracyjne - testy poprawności współpracy poszczególnych modułów systemu; sprawdzają czy funkcjonalności, w których bierze udział kilka modułów systemu są realizowane prawidłowo;

testy wydajnościowe - testowanie wydajności i czasów reakcji systemu przy obciążaniu go zgodnie z zadanymi warunkami, przy symulowanych (zbliżonych do realnych) lub innych wymaganych warunkach pracy testowanego systemu;

testy bezpieczeństwa - testujące zabezpieczenia przed utratą danych i nieupoważnionym dostępu do danych i funkcji systemu, zarządzanie uprawnieniami, zakres dostępu do danych i funkcji systemu, reakcje systemu na pojawienie się nieoczekiwanych danych.

Wykonawca odpowiedzialny jest za: przygotowanie środowiska testowego, dostarczenie uzgodnionych i zatwierdzonych przez

Zamawiającego scenariuszy testowych wraz z danymi testowymi.


administracji.80