PDF, 797 KB - Centrum Systemów Informacyjnych Ochrony Zdrowia

Załącznik nr 1 do SIWZ
Opis przedmiotu zamówienia
1.
WPROWADZENIE ......................................................................................................... 3
2.
ZAKRES PRAC ............................................................................................................. 4
2.1.
Organizacja projektu............................................................................................................................ 4
2.2.
Analiza funkcjonalności Portalu CSIOZ ................................................................................................. 4
2.3.
Sposób i termin realizacji ..................................................................................................................... 5
2.4.
Koordynacja prac oraz sprawozdawczość ............................................................................................ 6
2.5.
Odbiory i harmonogram płatności ....................................................................................................... 6
2.6.
Wymagania funkcjonalne .................................................................................................................... 7
2.7.
Specyfikacja wymagań jakościowych Portalu CSIOZ .......................................................................... 18
2.8.
Charakterystyka użytkowników Portalu CSIOZ .................................................................................. 18
2.9.
Dostępność, estetyka, ergonomia. ..................................................................................................... 19
2.10.
Wydajność ......................................................................................................................................... 24
2.11.
Utrzymanie Portal CSIOZ.................................................................................................................... 25
2.12.
Świadczenie usług gwarancyjnych ..................................................................................................... 27
3.
DOKUMENTACJA ........................................................................................................28
3.1.
Dokumentacja powykonawcza .......................................................................................................... 28
3.2.
Dokumentacja użytkownika i administratora .................................................................................... 29
3.3.
Dostarczenie i aktualizacja dokumentacji .......................................................................................... 29
3.4.
Ograniczenia, założenia, zależności .................................................................................................... 30
4.
4.1.
BEZPIECZEŃSTWO .....................................................................................................30
Budowa Systemu ............................................................................................................................... 30
1
4.2.
Dostęp do kodów źródłowych ........................................................................................................... 31
4.3.
Kodowanie znaków............................................................................................................................ 31
4.4.
Generowanie treści............................................................................................................................ 31
4.5.
Optymalizacja dla wyszukiwarek ....................................................................................................... 31
4.6.
Obsługa Błędów ................................................................................................................................. 31
4.7.
Import i Export danych ...................................................................................................................... 32
4.8.
Bezpieczny dostęp ............................................................................................................................. 32
4.9.
Zabezpieczenie Systemu .................................................................................................................... 33
4.10.
Backup Systemu ................................................................................................................................ 35
4.11.
Audyt bezpieczeństwa ....................................................................................................................... 35
4.12.
Przegląd Systemu............................................................................................................................... 35
5. OPTYMALIZACJA
I
DORADZTWO
W
ZAKRESIE
OPTYMALIZACJI
I
POZYCJONOWANIA STRONY ...........................................................................................36
6.
SZKOLENIA .................................................................................................................36
6.1.
Wymagania dot. Szkoleń ................................................................................................................... 36
6.2.
Certyfikaty uczestnictwa w szkoleniu ................................................................................................ 37
7.
LICENCJONOWANIE ...................................................................................................37
8.
TESTY ..........................................................................................................................37
2
1. Wprowadzenie
Przedmiotem zamówienia jest świadczenie usługi rozwoju portalu Centrum Systemów
Informacyjnych Ochrony Zdrowia www.csioz.gov.pl,wsparcia technicznego oraz optymalizacji
i doradztwa w zakresie pozycjonowania strony, zwanej dalej Portalem CSIOZ Portalem lub
Stroną.
Za prace rozwojowe Portalu CSIOZ Zamawiający uważa przede wszystkim:
1.
2.
3.
4.
5.
Zmianę i ujednolicenie layout’ów podstron Portalu CSIOZ.
Zmianę i ujednolicenie sposobu prezentacji treści i ich wizualizacji.
Modernizację narzędzi dostępnych dla użytkowników Portalu.
Modernizację Panelu administracyjnego Portalu.
Modyfikację Portalu, pozwalającą na stosowanie oddzielnego Layout’u Portalu dla
urządzeń mobilnych zgodną z wytycznymi dotyczącymi ujednolicenia podstron Portalu
CSIOZ.
Poprzez świadczenie usług wsparcia technicznego, Zamawiający rozumie, co najmniej:
1. Analizę problemów i Błędów zgłaszanych przez użytkowników Portalu.
2. Asystę przy rozwiązywaniu zgłaszanych problemów i usuwaniu Błędów.
3. Asystę przy identyfikowaniu przyczyn Awarii, Błędów oraz Usterek oprogramowania
i identyfikacji elementu oprogramowania, który odpowiada za przyczynę Awarii, Błędów
oraz Usterek.
4. Usuwanie zidentyfikowanych przyczyn Awarii, Błędów oraz Usterek.
5. Usuwanie skutków Awarii, Błędów oraz Usterek.
6. Instalację i konfigurację nowych wersji oprogramowania Portalu CSIOZ oraz jego
elementów (w przypadku zmian, rozbudowy i aktualizacji) oraz wykonywanie związanych
z tym faktem aktualizacji dokumentacji Portalu CSIOZ a także przeszkolenia
administratorów i użytkowników Portalu.
Poprzez świadczenie usług optymalizacji strony i doradztwa w zakresie pozycjonowania
strony Zamawiający rozumie, co najmniej:
1. Optymalizację strony czyli zoptymalizowanie kodu, treści i grafik pod kątem opisanym w
Opisie Przedmiotu Zamówienia.
2. Wykonawca zobowiązany jest do wsparcia Zamawiającego w zakresie określania
obszarów w jakich Zamawiający może samodzielnie pracować nad optymalizacją i
pozycjonowaniem stron internetowych
3
Modernizacja strony jest konieczna z uwagi na fakt, iż obecna strona jest mało aktualna
pod kątem możliwości technologicznych. Strona wymaga dostosowania do standardów
WCAG oraz zastosowania nowych technologii w celu poprawy czytelności i odbioru treści
przez użytkowników strony. Dodatkowo jest konieczność poszerzenia wiedzy w zakresie
pozycjonowania strony przez pracowników Centrum w celu promocji projektów
realizowanych przez jednostkę, o których CSIOZ informuje na portalu.
2. Zakres Prac
2.1. Organizacja projektu
Wykonawca (na podstawie przedstawionego w ofercie szczegółowego harmonogramu oraz
propozycji zasad organizacji realizacji projektu) zobowiązany jest - we współpracy z
Zamawiającym - do opracowania zasad realizacji Projektu, obejmujących swoim zakresem,
co najmniej następujące elementy:
1. Zasady zarządzania projektem po stronie Wykonawcy:
a) Skład zespołu przewidzianego do realizacji projektu wraz z zakresem kompetencji i
odpowiedzialności jego członków,
b)Sposób raportowania postępów pracy,
c) Zasady tworzenia i nazewnictwo dokumentów projektowych,
d) Zasady i sposoby komunikacji pomiędzy Wykonawcą a Zamawiającym.
2. Opis przyjętych i stosowanych metodyk przy realizacji projektu.
W przypadku istotnych zastrzeżeń co do osób realizujących zadanie po stronie Wykonawcy,
Zamawiający może zarządzać ich zmiany. W takim przypadku w terminie do 7 dni od
zgłoszenia zastrzeżenia Wykonawca przedstawi do akceptacji Zamawiającego kandydatury
osób z odpowiednimi kwalifikacjami i zapewni sprawne przekazanie obowiązków przez
zmieniane osoby.
2.2. Analiza funkcjonalności Portalu CSIOZ
Wykonawca opracuje i przedstawi Zamawiającemu do akceptacji analizę funkcjonalności
realizowanego Portalu zawierająca minimum:
1. Słownik pojęć.
2. Szczegółowy opis wszystkich wymagań dotyczących CMS.
3. Architekturę logiczną Portalu (podział na moduły, zakres funkcjonalny modułów,
zależności pomiędzy modułami itp.)
4. Zakres danych przechowywanych i udostępnianych przez Portal.
5. Założenia i opis interfejsu użytkownika.
6. Listę uprawnień do poszczególnych funkcji CMS wraz z opisem.
7. Listę ról w Portalu i grupowanych przez nie uprawnień.
4
2.3. Sposób i termin realizacji
Zamawiający przewiduje realizację przedmiotu zamówienia w następujących etapach:

Etap I. Przygotowanie koncepcji rozwoju i instalacji testowej nowej odsłony
Portalu CSIOZ. Termin realizacji etapu I wynosi 30 dni kalendarzowych od dnia
podpisania umowy, z uwzględnieniem następujących kamieni milowych:
a) Opracowanie i zatwierdzenie koncepcji rozwoju Portalu,
b) Opracowanie i zatwierdzenie analizy funkcjonalności Portalu,
c) Opracowanie i zatwierdzenie projektu technicznego Portalu,
d) Opracowanie planu testów i scenariuszy testowych i przekazanie ich do
akceptacji Zamawiającemu,
e) Analiza z Zamawiającym wszystkich elementów funkcjonalnych i wizualnych
Portalu,
f) Opracowanie i wytworzenie środowiska testowego i przekazanie do akceptacji
Zamawiającemu.


Etap II. Wdrożenie produkcyjne zmian w Portalu CSIOZ. Termin realizacji etapu
wynosi 40 dni kalendarzowych od daty zakończenia etapu I czyli od daty przekazania
do akceptacji Zamawiającego opracowanego i wytworzonego środowiska testowego ,
z uwzględnieniem prac:
a) Uruchomienie środowiska testowego,
b) Sukcesywne testy realizowane zgodnie z zaakceptowanym przez Zamawiającego
planem testów,
c) Migracja danych w zakresie wskazanym przez Zamawiającego, ze starej wersji
do nowej,
d) Dostarczenie dokumentacji użytkownika, administratora i powykonawczej Portalu,
e) Szkolenie użytkowników Portalu (administratorów i redaktorów),
f) Uruchomienie produkcyjne.
Etap III. Utrzymanie nowego Portalu CSIOZ.
Termin realizacji etapu od dnia zakończenia etapu II czyli od daty podpisania
protokołu odbioru wspólnego dla Etapu I i II wnioskującego o rozliczenie finansowe
do dnia 30.11.2015.
Etap III składa się z :
a) Etap III a:



Bieżący nadzór (monitoring) nad prawidłową pracą Portalu oraz wsparcie
użytkowników w eksploatacji Portalu (helpdesk),
Usuwanie incydentów i nieprawidłowości w działaniu,
Świadczenie usług wsparcia m.in. w zakresie bieżącego aktualizowania do
nowszych wersji i dostarczania łat i innych uaktualnień dla dostarczonego
Portalu,
5
b) Etap III b: Zamówienie opcjonalne

Usługa Rozwoju Portalu - 200 roboczogodzin
Przed przystąpieniem do realizacji dodatkowych modyfikacji zleconych przez
Zamawiającego w ramach Usługi Rozwoju Portalu, Wykonawca określi ile potrzebuje czasu
na wykonanie danego zlecenia i przedstawi do akceptacji przez Zamawiającego.
2.4. Koordynacja prac oraz sprawozdawczość
W ramach koordynacji prac odbywać się będą regularne - nie rzadziej niż raz na 2 tygodnie spotkania Wykonawcy z Zamawiającym. W razie potrzeby spotkania organizowane będą z
większą częstotliwością. Spotkania odbywać się będą w siedzibie Zamawiającego.
Pozostałe kontakty operacyjne Zamawiającego z Wykonawcą będą odbywać się przy użyciu
poczty elektronicznej oraz telefonicznie.
Wykonawca będzie przygotowywał raport po zakończeniu każdego z etapów. Raporty
podsumowujące etapy przekazywane będą Zamawiającemu w terminie do 7 dni roboczych
po zakończeniu danego etapu. Przy czym ostatni raport będzie połączony z końcowym
raportem podsumowującym realizację zadań.
Raporty przekazywane będą Zamawiającemu zarówno w postaci elektronicznej przy użyciu
poczty elektronicznej jak i postaci papierowej w dwóch egzemplarzach.
2.5. Odbiory i harmonogram płatności
Podstawą potwierdzenia zrealizowania przez Wykonawcę poszczególnych czynności
określonych w umowie i harmonogramie są protokoły odbioru podpisane przez
przedstawicieli Wykonawcy i Zamawiającego. Płatność za dany Etap (I-III a) może nastąpić
po zrealizowaniu wszystkich przewidzianych umową czynności i zadań danego etapu
i podpisaniu protokołu odbioru etapu.
Płatności za dodatkowe modyfikacje – w ramach Usługi Rozwoju Portalu (Etap III b) – mogą
nastąpić po zrealizowaniu zleconych, wycenionych i zaakceptowanych przez Zamawiającego
modyfikacji i podpisaniu protokołu odbioru tych prac przez przedstawicieli Wykonawcy
i Zamawiającego.
Dla Etapów od I do II płatność nastąpi po podpisaniu wspólnego protokołu odbioru
wnioskującego o rozliczenie finansowe.
Dla Etapu III a płatność nastąpi po podpisaniu protokołu odbioru wnioskującego o rozliczenie
finansowe za Etap IIIa.
6
Płatności za dodatkowe modyfikacje wykonywane w trakcie Etapu III b będą następowały na
podstawie faktur/rachunków wystawionych przez Wykonawcę.
2.6. Wymagania funkcjonalne
Zadaniem Wykonawcy będzie przebudowa Systemu CMS Portalu w celu umożliwienia
zarządzania informacjami w sposób ujednolicony i przyjazny dla osób odpowiedzialnych za
zadania w tym zakresie.
System CMS (dalej zwany System) powinien umożliwić samodzielne zarządzanie stroną, jej
wyglądem i zawartością przez Zamawiającego, bieżącą aktualizację, dodawanie, zmienianie
treści i grafiki, umożliwić rozbudowę strony, zarówno poprzez poszerzenie o dodatkowe
działy i podstrony, szybką zmianę szablonów graficznych, jak i poprzez dodawanie,
usuwanie, podmienianie załączników w postaci plików oraz materiałów graficznych
i multimedialnych.
2.6.1.
Zmiana i ujednolicenie layout’ów Portalu
Zamawiający przekaże Wykonawcy pliki graficzne w formie plików otwartych psd z pełnym
layout’em strony.
Wykonawca zobowiązany jest w pełni zaimportować grafiki do nowej strony wraz z ze
wszystkimi elementami funkcjonalnymi, które pojawiają się w layoucie.
Zamawiający przekaże również pliki graficzne opisujące jak dane elementy strony np.
przyciski mają w działać, w jaki sposób mają być animowane.
Zamawiający zastrzega sobie możliwość zmiany elementów graficznych bądź
merytorycznych na etapie postępowania.
Wykonawca przygotuje portal w sposób umożliwiający zarządzanie i modyfikację wszystkich
elementów strony tj. bannery, menu z poziomu administratora.
Zamawiający przekazuje w Załączniku nr 1 pliki poglądowe wraz opisem wybranych
zakładek na stronie.
2.6.2.
Odświeżenie sposobu prezentacji treści i ich wizualizacji
1. Podstawowe założenia:
a) uproszczenie i ujednolicenie menu strony głównej i menu podstron na Portalu
(zastosowanie menu rozwijalnego, prezentowanie treści w postaci boksów lub
linków),
b) możliwość opatrzenia materiałów tekstowych elementami graficznymi i zdjęciami,
c) zamieszczenie linkowalnych bannerów na stronie głównej, promujących wybrane
wydarzenia, akcje specjalne, programy,
d) rozszerzenie możliwości prezentacji zamieszczanych na portalu zasobów tj. pliki w
pdf, word w atrakcyjnej wizualnie formie książki z możliwością stronicowania za
pomocą myszki,
7
e) stworzenie dodatku pozwalającego na prezentowanie obrazów (np. belka górna
głównej strony) w formie 3D slide-show, z różnymi motywami przejścia między
obrazami. Zamawiający musi mieć możliwość w panelu administracyjnym
ustawienia dowolnych obrazków wraz z tekstem, które mogą być artykułem z
dowolnej zakładki strony,
f) wprowadzenie możliwości umieszczania elementów multimedialnych na Portalu
CSIOZ,
g) możliwość równoległej rozbudowy struktury Portalu CSIOZ w dwóch wersjach
językowych angielskiej i polskiej,
h) możliwość publikacji treści w dwóch wersjach językowych: polskiej i angielskiej,
i) możliwość projektowania, publikowania i zarządzania ankietami na Portalu, w tym
przeprowadzanie ankiet i publikowanie ich wyników na Portalu CSIOZ w czasie
rzeczywistym,
j) możliwość tworzenia repozytorium artykułów i dokumentów z logowaniem historii
ich publikacji. Wykonawca powinien stworzyć również archiwum do zakładki
aktualności oraz zamówień,
k) rozszerzenie o mechanizm obsługi forum. Forum powinno posiadać opcje
moderacji wypowiedzi z możliwością akceptacji każdego wpisu przed jego
publikacją, możliwość rejestracji użytkownika oraz przypisywania uprawnień
dostępu do określonych grup informacji dla wybranych grup użytkowników,
l) rozbudowę o możliwość obsługi czatu,
m) strona musi zawierać kanały RSS, wejścia na facebooka, youtube, twitter,
umieszczenie favicon przygotowanego przez Zamawiającego.
2. Wygląd Portalu CSIOZ (grafika, rozkład treści, typografia, itp.) musi być definiowany
w oparciu o System szablonów.
System musi umożliwiać definiowanie indywidualnych szablonów dla poszczególnych
kategorii portalu, dla poszczególnych artykułów, wyświetlać listę artykułów zawierających
początkowy fragment danego artykułu, z możliwością wyboru jak długi ma on być i
prezentacją w formie bloków, których, ilość oraz ułożenie można regulować z panelu
administracyjnego, bloków funkcjonalnych przy zachowaniu ogólnie przyjętego stylu dla
całości Portalu. Administrator merytoryczny musi mieć możliwość zmiany sposobu
prezentacji wszystkich elementów widocznych na stronie internetowej dla gości Portalu.
Definiowanie szablonów ma być możliwe dla przeszkolonego pracownika Zamawiającego
posiadającego odpowiednie uprawnienia. Domyślnie będzie to Administrator merytoryczny.
System musi umożliwiać wyłączanie poszczególnych bloków funkcjonalnych (jak. np.
wyszukiwarka, sonda, itp.) zdefiniowanych w ramach szablonu tak, aby nie były one
pokazywane w wybranych kategoriach Portalu CSIOZ.
System musi umożliwiać zmianę i modyfikacje szablonów portalu (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, lub modyfikacji treści Portalu.
8
Administrator merytoryczny musi mieć możliwość zarzadzania szablonami stron poprzez
możliwość ich tworzenia, edycji i modyfikacji i usuwania.
Położenie oraz zakres elementów nawigacji (tylko główne menu/tylko submenu/pełna
hierarchia menu, ścieżka nawigacji, itp.) definiowane są w szablonie strony. Każdorazowa
zmiana zawartości menu z poziomu panelu administracyjnego musi powodować
natychmiastową aktualizację elementów nawigacji w Portalu.
System musi umożliwiać dowolne przenoszenie pozycji menu (góra/dół) względem siebie w
danej kategorii oraz kategorii względem innych kategorii.
3. Prezentacja newsów na stronie głównej Portalu CSIOZ:
a) prezentowanie aktualności (newsów) w postaci siatki boksów lub listy – przełącznik
na stronie umożliwiający zmianę widoków w zależności od preferencji (boksy albo
lista),
b) stronicowanie wpisów na podstronach, wraz z możliwością zarządzania ilością
wyświetlanych newsów na pierwszej stronie, oraz możliwością przewijania
kolejnych stron z newsami do tyłu i do przodu,
c) oznaczanie treści aktualizowanej (w przypadku wprowadzenia zmiany po jej
publikacji),
d) przy długich artykułach możliwość dodania przycisku na końcu treści „góra” lub
„początek” (opcja dotyczy treści „rozwiniętych”),
e) możliwość dodawania filmów i multimediów w treści, zarówno plików
umieszczonych na serwerze na którym ma być umieszczony Portal CSIOZ, jak i z
innych źródeł jak na przykład portal youtube.com,
f) możliwość powiększania obrazów po kliknięciu na nie,
g) wprowadzenie automatycznie działającej funkcji dołączającej do artykułów: „lubię
to” (odnośnik do Facebooka), „poleć innym”(wysłanie powiadomienia e-mailem),
„pobierz PDF”, oraz drukuj.
4. Stopka:
a) dodanie nawigacji / linków dla minimum 5 zagadnień,
b) możliwość zarządzania tym elementem z poziomu panelu administracyjnego.
5. Możliwość podłączenia platform zewnętrznych np. platformy transmisji online, w
formie wbudowanego odtwarzacza .
6. Stworzenie mapy strony.
2.6.3.
Modernizacja narzędzi dostępnych dla użytkowników w Portalu CSIOZ
1. Forum:
a) ogólne forum dyskusyjne będzie dostępne dla wszystkich użytkowników Portalu
CSIOZ, ale jedynie w wersji podglądowej,
b) udział w dyskusji - możliwość komentowania i zakładania własnych wątków - tylko
dla zarejestrowanych użytkowników,
c) forum może być podzielone tematycznie,
d) forum będzie moderowane przez przydzieloną do tego osobę z redakcji,
e) możliwość zarządzania tym elementem z poziomu panelu administracyjnego.
9
2. Newsletter:
a) podczas rejestracji do Newsletter użytkownik zaznacza, jakimi kategoriami
informacji jest zainteresowany,
b) w każdej chwili może zrezygnować z subskrypcji Newslettera, a także zmienić jego
ustawienia,
c) dopasowanie szablonu – 3 różne propozycje wyglądu portalu bazujące na
wytycznych dostarczonych przez Zamawiającego,
d) narzędzia do zarządzania użytkownikami i prenumeratorami Newslettera,
statystykami, możliwością tworzenia szablonów wiadomości z walidowanych do
współpracy z najpopularniejszymi klientami poczty, tak programowymi (np. outlook)
jak i przeglądarkowymi (np. google mail),
e) zgodny z wymaganiami Ustawy o ochronie danych osobowych.
3. Opcje dla niepełnosprawnych:
a) zmiana na widok dla niepełnosprawnych i niedowidzących,
b) możliwość zmiany wielkości czcionki (3 rozmiary).
4. Wyszukiwarka:
a) rozbudowa
wyszukiwania
zaawansowanego
(m.in.
ostatnio
dodane,
zaktualizowane, data dodania, zakres dat, wg rodzajów plików (np. treści zawarte w
dokumentach PDF)),
b) wyszukiwanie zarówno po nazwie dokumentu zamieszczonego na Portalu CSIOZ
jak również po słowach kluczowych,
c) wyszukiwanie pełnotekstowe i po atrybutach informacji,
d) wyszukiwanie z uwzględnieniem fleksji języka polskiego – przypadków i odmian
gramatycznych danego słowa (np. ‘usług’ zamiast ‘usługi’, zdrobnień i skrótów),
e) mechanizm podpowiedzi po wpisaniu 3-4 liter słowa,
f) mechanizm proponowania zapytań w przypadku stwierdzonej literówki lub
proponowanie rezultatu pokrewnego do zapytania,
g) mechanizm wyszukiwania w dokumentach (minimum plików: pdf, rtf, Ms Word, Ms
Excel, OpenOffice Write, OpenOffice Calc, MS PowerPoint,.xml) załączonych na
stronie,
h) mechanizm prezentacji i sortowania rezultatów wg procentowej trafności, od
najnowszych/najstarszych lub wg wskazanego parametru,
i) wyszukiwanie uwzględniające wersje językowe tekstu – wyniki zwracane są
w zależności od wybranej wersji językowej Portalu CSIOZ,
j) System powinien zapewniać podświetlenie w wynikach wyszukiwania
odnalezionych słów kluczowych zadanych w zapytaniu, System musi również
umożliwiać wyszukiwanie metodą indeksową w oparciu o kategorie, słowa
kluczowe, czas publikacji, atrybuty artykułów.
k) 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 Portalu lub wybranych kategorii.
10
5. Tworzenie formularzy:
a) CMS musi umożliwiać tworzenie formularzy, pozwalając na umieszczenie ich w
dowolnych miejscach portalu oraz na przekierowanie wpisywanych odpowiedzi do
bazy danych np. Ms Excel, do plików XML (jednego lub wielu),
b) Mechanizm obsługujący formularz musi być odporny na ataki spamowe,
c) Wymagane typy pól, jakie maja być dostępne w formularzach:
 pole tekstowe jednolinijkowe i wielolinijkowe 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,
 przyciski „Wyczyść formularz”, „Wyślij formularz”, „Drukuj formularz”,
 Mechanizm zabezpieczeń przed spamem – np. captcha.
d) CMS musi umożliwiać dowolną zmianę układu i rozmieszczenia pól formularza na
stronie, oraz kolejność indeksowania,
e) CMS musi posiadać możliwość umieszczenia między polami formularza
dodatkowych opisów,
f) CMS musi umożliwiać oznaczenie pola, jako wymagalnego oraz umożliwiać
weryfikacje jego wypełnienia,
g) CMS musi posiadać możliwość walidacji pól typu: NIP, REGON, DATA, ADRES,
PESEL zarówno pod względem poprawności wprowadzenia danych (algorytm cyfr
kontrolnych), jaki ilości i dostępności znaków, – jeżeli pola tego typu będą
wykorzystywane,
h) każde pole musi posiadać mechanizm opcjonalnego określenia wartości domyślnej,
i) 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,
j) po wypełnieniu formularza System 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,
k) System musi posiadać możliwość opcjonalnego wysłania na podany przy
wypełnianiu formularza adres e-mail potwierdzenia jego wypełnienia, zgodnie z
wymaganiami Ustawy o ochronie danych osobowych. Musi istnieć możliwość
określenia adresu „reply to” takiego potwierdzenia.
2.6.4.
Modernizacja Panelu administracyjnego Portalu CSIOZ
11
1. Moduł statystyk odwiedzin Portalu:
a) możliwość wykonywania raportów z ruchu na stronie, w układzie zestawień
godzinowych, dziennych, tygodniowych, miesięcznych i rocznych,
b) funkcje pokazania raportu na wykresie,
c) widok liczby zalogowanych osób,
d) zakres prezentowanych danych to minimum: dzienny ruch na stronie, źródła ruchu,
średnie czasy spędzone przez użytkowników na stronie, geolokalizacja
użytkowników korzystających ze strony, liczba wejść na stronę, liczba unikalnych
Gości, liczbę powracających Gości, czas trwania odwiedzin, informacje skąd Gość
trafił na Portal CSIOZ (bezpośrednio, link na innej stronie, wyszukiwarka - ze
wskazaniem, jaka), słowa wyszukiwane na Portalu, ranking popularności
poszczególnych obszarów/kategorii/ Portalu z podziałem miesięcznym.
2. Administracja mailingiem:
a) wyświetlana lista adresatów,
b) dodawanie nowych grup mailingowych i aktualizowanie istniejących,
c) wprowadzenie stopki w mailu.
3. Administracja treści-Edytor treści:
a) jednakowe prezentowanie formatu treści za pośrednictwem różnych
przeglądarek,
b) właściwe skalowanie widoku w przeglądarkach ( zmniejszanie i powiększanie),
c) przygotowanie szablonu dla treści aktualności – treść z grafiką/ zdjęciem,
d) przygotowanie szablonu dla treści FAQ – odpowiedź pojawia się po kliknięciu na
pytanie (na stronie widoczne tylko pytania),
e) edytor pozwalający edytować treść bez znajomości znaczników służących do jej
formatowania i od razu prezentujący tę treść w postaci, w jakiej będzie ona
widoczna na stronie (również opcja podglądu w nowym oknie) na stronie CMSa
(umożliwienie edycji osobom bez przygotowania technicznego),
f) twórcy szablonów powinni mieć dostęp do bogatego w funkcje API
(umożliwiającego dostęp do treści i do struktury).
g) wbudowany prosty edytor szablonów posiadające min. funkcję tj.:








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 z Worda
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
12














Wstaw/edytuj grafikę, Wstaw/edytuj flash, Wstaw/edytuj audio, Wstaw/edytuj wideo,
Wstaw/edytuj hiper łącze, Usuń hiper łącze, Wstaw/edytuj kotwice
Wstaw/edytuj tabele, wstaw/usuń wiersz/kolumnę, podziel komórkę, scal komórki
wysokości szerokość wierszy oraz kolumn
Wstaw linie pozioma, 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
Osadź film Youtube
Narzędzie malarza formatów
Narzędzie ustawiania akapitów
Pomoc
Kod wstawiany przez edytor musi być zgodny minimum ze standardami XHTML
1.0 (Transitional) lub HTML5 i CSS 3
h) edytor musi zapewniać możliwość wklejania do dokumentów fragmentów plików
np. MS Word, OpenOffice.org Writer oraz MS Excel, OpenOffice.org Calc
zachowaniem formatowania tekstu oraz tabel. Wklejony tekst musi być
pozbawiony znaczników FONT oraz SPAN,
i) elementy graficzne dołączane do tekstów musza 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. Grafiki, w
których redaktor nie uzupełni tekstu alternatywnego, powinien pojawić się
komunikat o braku uzupełnionego pola,
j) przycisk „Czytaj więcej” pozwalający na podział artykułu na część widoczną, na
przykład po wejściu do kategorii danego artykułu, a po kliknięciu otwierający cały
artykuł do odczytu.
4. Administracja menu i nawigacja:
a) możliwość dodania nowego menu poziomego i pionowego z poziomu panelu
administracyjnego,
b) możliwość dodania do każdego poziomu menu przycisku „publikacja”, – który
umożliwi wystawienie menu do widoku na stronie lub ukrycia tego menu do
momentu jego pełnego skonfigurowania,
c) stosowanie przez Portal CSIOZ tak zwanych „Przyjaznych linków”, lub inaczej
„Prostych adresów”, które sprawiają że 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
Portalu.
13
d) System 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.
5. Administracja plikami:
a) jedno, to samo źródło dodawania obrazów i plików. Obecnie obrazy i pliki zasilane
są z dwóch miejsc:
 poprzez moduł administracja plikami,
 dodawanie obrazów z poziomu edytora tekstów z dysku poprzez pobranie
(upload),
b) możliwość dodawania wielu plików na raz, tworzenie galerii poprzez dodawanie
paczek obrazów. Pliki gromadzone będą w sposób umożliwiający swobodne ich
przeglądanie, katalogowanie (w katalogi, podkatalogi) i sortowanie przez
uprawnionych redaktorów,
c) stworzenie mechanizmu automatycznie tworzącego miniaturki plików graficznych
umieszczonych w galerii z możliwością określenia rozmiaru (maksymalna
szerokość x wysokość z zachowaniem proporcji skalowanego obrazu)
generowanych miniatur. Po kliknięciu kursorem na miniaturkę wyświetlany będzie
powiększony podgląd obrazu,
d) możliwość edytowania parametru „alt” dla plików graficznych,
e) możliwość modyfikacji plików graficznych po kątem takim jak : wielkość, obrócenie
pliku, zmiana kontrastu, zmiana na negatyw, możliwość przycinania. Wykonawca
powinien również zapewnić możliwość przycinania kilku plików graficznych
automatycznie w jednakowy sposób,
f) pliki graficzne umieszczane w repozytorium Portalu CSIOZ 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.
Nazwy tworzonych na serwerze plików powinny być zapisywane małymi literami
oraz do nazwy każdego z plików powinien być automatycznie dodany unikalny
identyfikator.
6. Administracja odtwarzaczem wideo/audio:
a) System musi posiadać dedykowany i zintegrowany odtwarzacz umożliwiający
odtworzenie bezpośrednio na stronie materiałów multimedialnych (audio, video),
oraz posiadać możliwość prezentowania na Portalu CSIOZ materiałów z innych
Portali i serwerów, np. youtube.com,
b) odtwarzacz musi opierać się na technologii Flash lub HTML5 oraz posiadać opcje
wyświetlania plików multimedialnych w trybie HTML5. System CMS będzie
automatycznie zapewniał generowanie plików wideo w dodatkowych formatach,
zapewniając kompatybilność z przeglądarkami obsługującymi HTML5 i różnych
formatów kodowania wideo i audio (MP4/WebM oraz MP3/ Vorbis),
14
c) System musi umożliwiać publikowanie odtwarzacza plików multimedialnych(audio,
video) w wybranych miejscach strony lub bezpośrednio w treści artykułów,
d) musi istnieć możliwość określenia czy materiał jest odtwarzany automatycznie po
załadowaniu strony, czy po wybraniu przez użytkownika przycisku play
odtwarzacza,
e) odtwarzacz musi prezentować czas 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
Portalu CSIOZ. Odtwarzacz musi mieć możliwość wyboru dla materiałów wideo
obrazu wyświetlanego przed rozpoczęciem odtwarzania pliku. Odtwarzać musi
posiadać możliwość umieszczenia tytułu materiału, krótkiego opisu oraz
opcjonalnego linku (adresu URL),
f) 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. System CMS musi przygotowywać taką listę dla
wszystkich materiałów wideo dodanych do Portalu. Musi istnieć możliwość
wykluczania prezentacji wybranych plików z powyższej listy,
g) System 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). Musi istnieć możliwość wykluczania
prezentacji wybranych plików na liście zajawek.
7. Administracja subskrypcjami:
a) aktywowanie i dezaktywowanie subskrybentów zgodnie z wymaganiami Ustawy
o ochronie danych osobowych,
b) dodawanie stopki w mailach w widoku „wyślij informację” oraz aktywację i
dezaktywację subskrypcji,
c) opcja wysyłki maila „do wszystkich” i do określonych grup subskrybentów,
d) możliwość raportowania wszystkich operacji wykonywanych w module subskrypcji.
8. Administracja artykułami:
a) 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 artykułów.
b) System musi zapewnić możliwość umieszczania w artykułach plików graficznych i
animacji w ogólnie dostępnych formatach (JPG, GIF, PNG, SWF, MPG, AVI,
WMV).
15
c) System musi zapewniać możliwość polecenia artykułu znajomym (np. na portalach
społecznościach), administrator powinien mieć możliwość wyłączenia tej opcji dla
danego artykułu.
9. Zarządzanie banerami:
a) System musi posiadać panel zarzadzania banerami i umożliwiać na umieszczanie
ich w dowolnych miejscach Portalu CSIOZ.
b) baner może mieć charakter informacyjny (bez odnośnika) lub być odnośnikiem do
innej strony w ramach portalu lub poza nim. Może mieć postać pliku graficznego,
lub animacji Flash.
c) System musi posiadać flash kreator, umożliwiający tworzenie banerów flashowych
przy wykorzystaniu ilustracji i obiektów SWF. Stworzony baner można zapisać na
dysku. Kreator musi mieć możliwość korzystania z polskich czcionek. Kreator
powinien posiadać animacje tekstu.
d) System musi umożliwiać określenie czasu ekspozycji dla konkretnego banera.
e) w ramach grup banerów musi być możliwość określania kolejności ich ułożenia,
ilości banerów wyświetlanych na raz w grupie oraz możliwość wskazania banerów,
które maja być wyświetlane losowo z pośród innych wybranych do wyświetlania w
tym trybie.
f) System musi zliczać wyświetlenia i kliknięcia w baner sumarycznie i z podziałem na
miesiące.
10. Zamówienia publiczne
Możliwość zamieszczania ogłoszeń o zamówieniach publicznych za pomocą
predefiniowanego szablonu z poziomu panelu administracyjnego. Aby dodać
ogłoszenie użytkownik z poziomu panelu wypełnia następujące dane:
 Tytuł – pole tekstowe
 Nr sprawy – pole tekstowe
 Rodzaj - pole listy rozwijanej (słownik) definiowanej z poziomu panelu
 Wartość - pole listy rozwijanej (słownik) definiowanej z poziomu panelu
 Finansowanie - pole listy rozwijanej (słownik) definiowanej z poziomu panelu
 Załączniki – możliwość dodawania i usuwania dowolnej ilości załączników w
postaci plików
Przy każdym z ogłoszeń musi widnieć data dodania oraz data ostatniej modyfikacji.
Musi istnieć możliwość aktywacji/dezaktywacji ogłoszenia.
11. Praca
16
Możliwość zamieszczania ogłoszeń o pracę za pomocą predefiniowanego szablonu z
poziomu panelu administracyjnego. Aby dodać ogłoszenie użytkownik z poziomu
panelu wypełnia następujące dane:
 Tytuł ogłoszenia o pracę (pole tekstowe)
 Data publikacji ogłoszenia wraz terminem możliwości składania aplikacji.
 Możliwość złożenia aplikacji bezpośrednio ze strony CSIOZ poprzez ikonę
„aplikuj”, tj. możliwość załączenia CV oraz listu motywacyjnego.
 Ilość etatów (pole tekstowe)
 Załącznik - możliwość dodawania i usuwania załącznika w postaci pliku
Wykonawca umieści aktywny formularz, kwestionariusz, który umożliwi kandydatom
złożenie zgłoszenia na praktyki studenckie bezpośrednio ze strony CSIOZ.
2.6.5.
Uruchomienie interfejsu na urządzenia mobilne
Należy przygotować osobny, uproszczony interfejs dla urządzeń mobilnych. Wersja
mobilna może mieć ograniczoną funkcjonalność w stosunku do standardowego interfejsu
(ograniczenia te muszą zostać zaakceptowane przez Zamawiającego) i powinna być
dostępna pod osobnym adresem domenowym (powinno następować automatyczne
przekierowanie ze strony głównej witryny). Wersja mobilna musi być zgodna z
następującymi standardami i wytycznymi W3C:
 XHTML for mobile
 CSS Mobile
 Mobile Web Applications
 Mobile Web Authoring
Podstawowe wytyczne dla interfejsu na urządzenia mobilne:
 elementy dynamiczne nie mogą stanowić głównej części wersji mobilnej (np.
strona, jako animacja Flash). Elementy dynamiczne powinny być zastępowalne
zgodnymi z wbudowanymi przeglądarkami wskazanych urządzeń mobilnych
elementami statycznymi, dostarczając podobną funkcjonalność,
 urządzenia mobilne powinny być automatycznie rozpoznawane. Należy wskazać
katalog urządzeń mobilnych, z którymi będzie zgodny interfejs,
 powinna być zminimalizowana ilość prezentowanej grafiki, która nie może być
w rozmiarach większych niż te ustalone z Zamawiającym,
 paski przewijania powinny być dobrze widoczne,
 aplikacja powinna zostać uproszczona do podstawowych funkcjonalności,
 ikony nie mogą zostać wprowadzone kosztem zrozumiałości ich znaczenia.
Użytkownik powinien zawsze wiedzieć, do czego dana ikona służy,
 należy rozważyć możliwość zapamiętywania danych o logowaniu w plikach
ciasteczek przechowywanych na urządzeniach w celu uniknięcia konieczności
ponownego logowania do witryny, Wykonawca musi umieścić na stronie baner z
informacją, że strona wykorzystuje ciasteczka (cookie),
17

należy kompresować wysyłane materiały do użytkownika ze względu na niską moc
obliczeniową urządzeń oraz prędkość transferu,
 należy minimalizować konieczność komunikacji aplikacji z systemami
zewnętrznymi,
 należy ograniczać przetwarzanie danych po stronie klienta na rzecz przetwarzania
po stronie serwera,
 możliwość zarządzania interfejsem z poziomu panelu administracyjnego,
 powinna następować automatyczna synchronizacja treści wyświetlanych
w interfejsie standardowym i mobilnym.
Grafika powinna być zgodna z projektem graficznym przygotowanym przez
Zamawiającego.
2.7. Specyfikacja wymagań jakościowych Portalu CSIOZ
1.
2.
3.
4.
5.
6.
7.
Struktura Portalu nie powinna narzucać ograniczeń dla przygotowywanych stron
informacyjnych zarówno w zakresie ilościowym jak i pojemnościowym przewidując
możliwość publikowania tekstów wzbogaconych elementami graficznymi oraz
multimedialnymi.
Portal CSIOZ powinien być dostępny 24 godziny na dobę przez 7 dni w tygodniu (w
zakresie funkcjonalnym wymagającym takiej dostępności).
Wykonawca zapewni możliwość równoczesnej pracy przynajmniej przez 50
nazwanych użytkowników Zamawiającego redagujących Portal.
Wykonawca zapewni możliwość równoczesnej pracy przynajmniej takiej ilości
użytkowników zewnętrznych przeszukujących zasoby Portalu CSIOZ (z możliwością
zwiększenia w ramach potrzeb), którą określi Zamawiający po testach
akceptacyjnych.
Wykonawca zapewni bezproblemową obsługę Portalu CSIOZ w systemach
operacyjnych MSWindows, OS Mac, Linux.
Portal CSIOZ wykonany zostanie zgodnie z rekomendacjami wypracowanymi przez
W3C
(w
szczególności
w dokumencie
WCAG
2.0
http://www.fdc.org.pl/wcag2/index.html ).
Oprogramowanie, narzędzia i usługi wykonane lub użyte w trakcie tworzenia Portalu
CSIOZ spełniać będą wszystkie obowiązujące wymogi zawarte w prawie polskim oraz
odpowiednich dyrektywach UE. Oprogramowanie i narzędzia wykorzystywane na
Portalu CSIOZ muszą być w j. polskim.
2.8. Charakterystyka użytkowników Portalu CSIOZ
Nazwa roli
Charakterystyka
Administrator Osoba zajmująca się zarzadzaniem całością lub wydzieloną częścią
techniczny Systemu odpowiadająca za jego sprawne działanie, do której zadań
18
należy:
− konfiguracja i nadzorowanie pracy serwera/ów,
− instalacja i aktualizacja oprogramowania systemowego (system
operacyjny), narzędziowego i użytkowego,
− dbanie o bezpieczeństwo systemu, tworzenie kopii zapasowych
Systemu, nadzorowanie i eliminowanie nieprawidłowości w jego
działaniu.
Administrator Osoba posiadająca pełne uprawnienia administracyjne do Portalu w tym
merytoryczny m.in. do dodawania i usuwania kont użytkowników, parametryzowania i
pełnego zarządzania strukturą i wyglądem systemu, zarządzania
modułami tematycznymi, szablonami itp.
Redaktor Osoba nadzorująca merytorycznie prace wybranych redaktorów.
Zatwierdzający Dokonuje ewentualnej modyfikacji i akceptuje materiały do publikacji.
Redaktor Osoba publikująca w Systemie zatwierdzone materiały.
Gość Każda osoba odwiedzająca Portal CSIOZ.
Użytkownik Każda osoba korzystająca w jakikolwiek sposób z Portalu CSIOZ.
2.9. Dostępność, estetyka, ergonomia.
2.9.1.
Interfejs użytkownika
1. Portal CSIOZ musi zostać zoptymalizowany do wyświetlania w rozdzielczości
1024x768 i wyższych oraz 24 bitowej palety kolorów– dla wersji „desktop” . Wersje
dla tabletów i telefonów komórkowych muszą być dostosowane do obsługi
najpopularniejszych urządzeń mobilnych (tablety i telefony z systemem Android, iOS,
Opera Mini, Opera Mobile, Windows Phone 7-10, NokiaBrowser).
2. Wykonawca projektując stronę powinien stosować się do koncepcji responsive web
design
3. Zaimplementowane projekty graficzne muszą charakteryzować się lekkością;
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.
4. Portal CSIOZ powinien być zaprojektowany w sposób przejrzysty i funkcjonalny
zgodnie z dobrymi praktykami w tym zakresie.
5. Wykonawca przy tworzeniu portalu powinien stosować czcionkę Arial.
6. Do budowy strony Wykonawca powinien użyć techniki skrolowania (scroll).
2.9.2.
Komunikacja Redaktorów z Portalem CSIOZ
1. Pokazywanie statusu Portalu CSIOZ. Portal musi zawsze informować użytkownika,
co się dzieje poprzez odpowiednie potwierdzenie wykonywanych operacji oraz
komunikaty o wykonywanych operacjach.
19
2. Zgodność pomiędzy Portalem a rzeczywistością. Portal 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 na Portalu CSIOZ
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 go nie interesuje bez zniszczenia lub
modyfikacji danych).
4. Standaryzacja i zachowanie spójności. Te same słowa, symbole, kolory, sytuacje i
działania powinny być stosowane w jednakowy sposób w całym Portalu, 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 Portalu i użyć
jej w innej otrzymując podobny rezultat.
5. Stosowanie list wyboru. Stosowanie wszędzie gdzie jest to możliwe na Portalu list
wyboru oraz wartości słownikowych tak, aby działania użytkownika były wynikiem
wyboru z listy, wszystkie potrzebne w danej sytuacji informacje i instrukcje powinny
być cały czas widoczne na ekranie.
6. 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ć typ problemu i sposób jego rozwiązania.
7. Pomoc Systemowa. Powinna ona umożliwiać szybkie odnalezienie żądanej
informacji, a instrukcje rozwiazywania problemów powinny być zwięzłe i dotyczyć
zadań użytkownika.
8. Czas reakcji Systemu. Czas odpowiedzi na zlecenie wykonania operacji przez
użytkownika musi być krótszy niż 5 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 informacje o zajętości i informować o rodzaju
wykonywanej operacji oraz ewentualnie o szacowanym czasie zakończenia jej
wykonywania.
9. Przerywanie operacji. System ma umożliwić przerywanie operacji, jeżeli użytkownik
stwierdzi, że dana operacja trwa zbyt długo.
10. Wraz z Systemem Wykonawca musi zostać dostarczyć nieograniczoną liczbę kont
dostępowych dla redaktorów i administratorów Systemu, a w bazie Systemu może
być ich zarejestrowana dowolna ilość.
2.9.3.
Technologia budowy interfejsu
1. Portal CSIOZ musi być, co najmniej zgodny ze standardem XHTML1.0 Transitional
lub z HTML 5 i CSS 3.
2. Wymagana jest prawidłowa walidacja tworzonego przez CMS kodu HTMLi CSS za
pomocą udostępnianego na stronach W3C walidatora (http://validator.w3.org/).
3. System musi być oparty na stylach framework CSS, rozwijanych przez programistów
zawierający zestaw przydatnych narzędzi ułatwiających tworzenie interfejsu
20
graficznego stron oraz aplikacji internetowych bazując głównie na gotowych
rozwiązaniach HTML oraz CSS i może być stosowana do stylizacji takich elementów
jak teksty, formularze, przyciski, wykresy, nawigacje i innych komponentów
wyświetlanych na stronie.
2.9.4.
Dostępność w przeglądarkach internetowych
1. Portal CSIOZ musi poprawnie realizować założone funkcjonalności, co najmniej w
następujących przeglądarkach: Microsoft Internet Explorer 6 i najnowszych, Mozilla
FireFox 25.0 i najnowszych, Opera 9, Safari i najnowszych oraz Chrome 3.0 i
najnowszych. W przypadku korzystania ze starszych wersji przeglądarek niż wyżej
wymienione lub innych przeglądarek, do których portal nie jest dostosowany, zostanie
wyświetlony komunikat o sposobie poprawnego wyświetlania Strony.
2. Moduł redakcyjno-administracyjny musi prawidłowo działać, co najmniej w
przeglądarkach: Internet Explorer 6 i najnowszych, Mozilla Firefox 25.0, Safari i
najnowszych, Chrome 3.0 i najnowszych.
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.
2.9.5.
Dostępność w przeglądarkach internetowych dla tabletów i telefonów
komórkowych
Wersje dla tabletów i telefonów komórkowych, realizując koncepcje responsive we design,
muszą być prawidłowo obsługiwane przez przeglądarki używane w najpopularniejszych
urządzeniach mobilnych (tablety i telefony z systemem Android, iOS Opera Mini, Opera
Mobile, Windows Phone 7, Nokia Browser).
2.9.6.
Dostępność
1. System musi być zgodny z określonymi w ramach Wytycznych Dotyczących
Dostępności Treści Internetowych (WCAG 2.0) na poziomie AA na podstawie
zapisów określonych w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. w
sprawie Krajowych Ram Interoperacyjności.
2. System musi posiadać wersję tekstową strony z możliwością włączenia opcji 3
rodzajów wysokiego kontrastu spełniającego wymagania WCAG na poziomie AA.
3. System musi zapewnić prawidłowe funkcjonowanie strony w urządzeniach i
oprogramowaniu wspomagającym osoby niepełnosprawne w korzystaniu z
komputera takich jak czytnik NVDA ,VoiceOver, ZoomText.
4. Treści multimedialne muszą być dostępne z poziomu klawiatury i oprogramowania
dla osób niepełnosprawnych. Multimedia, które nie mogą być z przyczyn
technicznych tak zbudowane, by uczynić je dostępnymi dla wszystkich użytkowników
muszą posiadać alternatywny opis tekstowy, który wyjaśnia ich cel i funkcje
zastosowania na stronie.
5. Treści multimedialne są bezpośrednio dostępne lub jest udostępniona ich alternatywa
w postaci tekstowej;
21
6. Na każdej podstronie, gdzie publikowane są dokumenty w formacie pdf, powinien być
dodany automatycznie, odnośnik do pobrania programu, który umożliwia jego
odczytanie.
7. Maksymalna zgodność ze standardami HTML i CSS całego Portalu CSIOZ (zarówno
szablonów, jak i kodu generowanego z edytora treści).
8. Wykonawca podczas migracji danych przeniesie cześć artykułów z działu aktualności
i ogłoszeń dot. postępowań wskazanych przez Zamawiającego do archiwum.
Wskazane artykuły nie będą dostosowane do standardów WCAG 2.0.
9. Wykonawca zobowiązany jest do umieszczenia na portalu oświadczenia o
dostępności. W tekście oświadczenia powinny zostać wskazane, iż ww. artykuły nie
będą dostosowane do standardu. Jednakże, reszta materiałów na stronie spełnia
wszelkie wymagania WCAG.
10. Wykonawca zobowiązany jest do uzyskania certyfikatu potwierdzającego dostępność
nowego portalu do standardu WCAG 2.0.
11. Certyfikat zostanie wydany na podstawie przeprowadzonego audytu przez
zewnętrznych audytorów, posiadający w swoim dorobku przeprowadzonych min. 500
audytów.
12. Audyt powinien przeprowadzić ekspert ds. WCAG oraz osoby niepełnosprawne
(niewidomi, niedowidzący i głusi).
2.9.7.
Nawigacja
1. Nawigacja musi być czytelna, spójna i logiczna w całym Portalu CSIOZ.
2. Wszystkie poziomy nawigacji muszą być dostępne przy użyciu samej klawiatury i
czytników ekranu. Do wszystkich odnośników, pól formularzy, przycisków, które
znajdują się na stronie istnieje dostęp za pomocą klawiatury przy jednoczesnym
oznaczeniu miejsca, w którym użytkownik się znajduje, tzw. fokusu.
3. Nawigacja musi zawierać odnośniki do mapy strony, spisu treści lub dostępnej
wyszukiwarki wewnętrznej Systemu.
4. Na każdej stronie muszą znajdować się elementy nawigacyjne przedstawiające
aktualną lokalizację użytkownika w Systemie.
5. Przycisk „dalej/wstecz” w przeglądarce nie może być blokowany i musi wykonywać
akcje zgodne z oczekiwaniem użytkownika: tj. przenosić go na stronę poprzednią lub
następną.
6. Jeżeli są stronicowane artykuły, to oprócz przycisków z numerami kolejnych stron
muszą być przyciski „na początek” oraz „na koniec” (do pierwszej, do ostatniej).
2.9.8.
Wizualny fokus oraz kolejność elementów
1. Kolejność przechodzenia przy użyciu klawisza [Tab] z odnośnika na odnośnik lub z
pola formularza na kolejne powinna być logiczna i zrozumiała. Powinna
odzwierciedlać to, w jaki sposób użytkownik widzący korzysta ze strony. Przyjmuje
się, że użytkownik widzący skanuje stronę wzrokiem od lewej do prawej strony i od
góry do dołu. Użytkownik potrafi przewidzieć, na jakim linku znajdzie się fokus.
22
2. Na stronie musi być widoczny fokus (widoczna ramka wokół linku, zaznaczenie pola
formularza) na elementach aktywowanych przy pomocy klawiatury.
3. System nie może mieć elementów przejmujących fokus.
4. Kontrolki odtwarzaczy video czy galerii zdjęć (np. przyciski play, stop) muszą mieć
dostęp z poziomu klawiatury.
2.9.9.
Odnośniki
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 portalu 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. Informacja o otwieraniu w nowym oknie
może być np. ukryta za pomocą technik CSS. Jednak należy pamiętać o tym, by nie
można było stosować techniki {display: none}, która ukrywa treści także dla czytników
ekranu.
5. Serwis powinien mieć odnośnik „przejdź do treści” (skip to content) pozwalające
użytkownikom technologii wspomagającym przejść bezpośrednio do głównej treści
strony. Odnośnik pozwala przeskoczyć powtarzającą się na wszystkich podstronach
nawigację.
6. Odnośniki obrazkowe i przyciski mają atrybut alt, który opisuje ich funkcje.
7. Odnośniki do treści nie-HTML (np. pliki PDF, Excel czy Word) zawierają nazwę typu
dokumentu oraz jego objętość.
8. Linki powinny być odpowiednio opisane.
9. W linkach nie powinno się stosować skrótów niezrozumiałych dla przeciętnego
użytkownika.
2.9.10.
Relatywne parametry wielkości
1. Relatywne parametry wielkości tekstu pozwalają użytkownikom zmienić wielkość
tekstu zgodnie z ich potrzebami przy użyciu narzędzi przeglądarki. Dzięki
poprawnemu wdrożeniu relatywnych parametrów wielkości tekstu niektórzy
użytkownicy nie muszą być uzależnieni od specjalnych narzędzi powiększających.
2. Użytkownik może zwiększyć wielkość tekstu (włączając obrazki do 200%) za pomocą
narzędzi przeglądarki (np. skrótu CTRL +) lub usprawnień powiększających
osadzonych na stronie internetowej.
3. Strona powiększona za pomocą tych technik pozostaje czytelna i żadne treści nie
stają się niewidoczne. Grafika przy powiększaniu nie powinna zmieniać swojego
pierwotnego kształtu, tylko proporcjonalne powiększać się razem z całą stroną.
4. Powiększenie musi obejmować cała stronę, a nie tylko jej główną cześć (np. tekst
artykułu). Powiększenie nie może działać tylko w obrębie pojedynczej podstrony,
23
dlatego po przejściu na inną stronę nie powinno być potrzeby ponownego
powiększania tekstu.
2.9.11.
Kontrast kolorystyczny
1. Kontrast kolorystyczny miedzy tłem a tekstem musi być zgodny z zaleceniami WCAG
2.0.
2. System musi zapewnić możliwość przełączenia się do wersji wysoki kontrast, będącej
odwzorowaniem oryginalnej szaty graficznej w kontrastowej kolorystyce.
3. Kontrast musi mieć stosunek jasności 4,5 do 1. Jeśli tekst ma wielkość minimum18
pkt lub 14 pkt dla tekstu pogrubionego stosunek jasności może mieć minimum 3 do1.
4. Zalecane jest zachowanie kontrastu w stosunku jasności między tłem i tekstem na
poziomie 7 do 1. Jeśli tekst ma wielkość minimum 18 pkt lub 14 pkt dla tekstu
pogrubionego stosunek jasności powinien być na poziomie 4,5 do 1.
2.10.
Wydajność
2.10.1.
Analizy wydajności
1. Wykonawca zobowiązany jest do przeprowadzania analizy wydajności Systemu.
Testy wydajnościowe powinny zidentyfikować obszary Systemu, dla których czas
odpowiedzi przekracza założone maksimum. Jeżeli Wykonawca nie będzie korzystał
z dotychczasowego systemu jest zobowiązany do migracji danych w zakresie
wskazanym przez Zamawiającego do nowego Systemu.
2. W ramach testów wydajnościowych System musi być obciążany docelową ilością
Gości tj. 300 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 dla co
najmniej 90% wszystkich żądań) nie może być dłuższy niż 5 sekund(dla połączeń
LAN).
3. Wykonawca musi dokonać pomiarów i przedstawić w dokumentacji następujące
parametry Systemu:
a. Maksymalna liczba użytkowników na sekundę korzystających z portalu, przy której
System spełnia jeszcze wymagania dot. czasu odpowiedzi (tj. 5 sekund).
b. 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 dot.
czasu odpowiedzi dla każdego roku?
4. W celu zwiększenia wydajności Wykonawca zobowiązany jest do kompresji zasobów
przy użyciu algorytmu gzip lub deflate oraz optymalizacji CSS.
24
2.10.2.
Stabilność pracy CMS
System musi zapewniać stabilność pracy serwera rozumiana jako zdolność do
automatycznego przywrócenia poziomu usługi po przeciążeniu, podczas którego usługa była
świadczona poza kryteriami dostępności. Po osiągnieciu 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.
2.11.
Utrzymanie Portal CSIOZ
Wykonawca zobowiązany jest do utrzymania istniejącego Portalu CSIOZ – od dnia
zakończenia etapu II do 11 grudnia 2015.
W ramach utrzymania Wykonawca zobowiązany jest do:
1. Bieżący nadzór (monitoring) nad prawidłową pracą Portalu oraz wsparcie
użytkowników w eksploatacji Portalu (helpdesk),
2. Świadczenie usług wsparcia technicznego w zakresie:
a) bieżącego aktualizowania do nowszych wersji i dostarczania łat i innych
uaktualnień dla dostarczonego Portalu,
b) usuwania incydentów i nieprawidłowości w działaniu Portalu.
Wsparcie techniczne może odbywać się za pośrednictwem:




Kontaktu telefonicznego
Kontaktu e-mailowego
Faksu
Na piśmie
Definicje incydentów:
Awaria – to wada oprogramowania uniemożliwiająca działanie Portalu tj. korzystanie z
części, lub całości, funkcjonalności Systemu.
Podatność – to wada oprogramowania wpływająca na jego bezpieczeństwo. Wada ta może
nie być znana w momencie produkcji Systemu.
Błąd –oznacza nieprawidłowość działania Systemu, która wpływa w istotny sposób na wyniki
pracy, ogranicza funkcjonalność Systemu, w wyniku czego praca z Systemem jest
25
utrudniona, ale możliwa i nie stwarza zagrożenia dla Zamawiającego w zakresie naruszenia
przepisów prawa.
Usterka – to dysfunkcje, czy uciążliwości utrudniające działanie Portalu.
Aktualizacja - poprawka lub dodatek do Systemu, których celem jest ulepszenie,
naprawienie lub przywrócenie funkcjonalności Systemu, nie stanowią cenowej wersji, w
szczególności niepowodujące nowych funkcjonalności Systemu.
Asysta - zdalna pomoc udzielana użytkownikom lub Administratorom Systemu w
rozwiazywaniu problemów związanych z funkcjonowaniem Systemu lub przy użytkowaniu
Portalu za pośrednictwem telefonu, poczty elektronicznej lub innego środka komunikacji.
Błąd krytyczny - wada uniemożliwiająca użytkownikom korzystanie z Systemu lub jego
fragmentu oraz naruszenie bezpieczeństwa Systemu (dostęp do danych lub funkcji Systemu
z pominięciem mechanizmów zabezpieczeń).
Interwencja - wizyta serwisowa w miejscu instalacji Systemu związana z naprawą Awarii
- pracami nieobjętych bezpłatną gwarancją.
Zgłoszenie - dokonane przez Użytkownika udokumentowane powiadomienie (telefonicznie,
faxem, mailem) o problemie związanym z nieprawidłowym funkcjonowaniem Systemu.
Czas Reakcji Serwisu - czas liczony od chwili zgłoszenia do reakcji serwisu, obejmującej co
najmniej kontakt zwrotny z Zamawiającym, potwierdzenie przyjęcia zgłoszenia, wstępną
analizę problemu i przedstawienie planu dalszych działań.
Czas naprawy –czas liczony od chwili przyjęcia zgłoszenia incydentu przez Wykonawcę do
czasu przywrócenia zgodnego, oczekiwanego z dokumentacją działania Systemu.
a)
b)
c)
d)
Czas reakcji na incydenty i ich naprawa:
Wykonawca zobowiązany jest podjąć niezwłocznie po przyjęciu zgłoszenia
czynności zmierzające do jego zdiagnozowania oraz podjęcia naprawy.
O rozpoczęciu diagnozy, wyniku diagnozy incydentu oraz podjęciu czynności
zmierzających do naprawy Błędu Wykonawca powiadomi Zamawiającego drogą
elektroniczną z uwzględnieniem czasów wskazanych w tabeli 1.
W przypadku sporu co do zaistnienia incydentu lub odmowy jego usunięcia przez
Wykonawcę, Zamawiający może wystąpić z wnioskiem o przeprowadzenie
niezależnej ekspertyzy przez uzgodnionego przez Strony eksperta. Jeśli ekspertyza
potwierdzi roszczenia Zamawiającego, koszt związany z jej przeprowadzeniem
ponosi Wykonawca.
Wykonawca w zakresie monitoringu Portalu powinien na bieżąco sprawdzać stronę
pod kątem problemów technicznych.
26
Tabela 1. Wymagania na świadczenie usług asysty technicznej.
Kategoria
zgłoszenia
Awaria
Błąd Krytyczny
Błąd
Usterka
Podatność
Maksymalny Czas
Reakcji Serwisu
Maksymalny Czas naprawy
2 godziny
2 godziny
2 godziny
2 godziny
2 godziny
1 dzień roboczy
2 godzin robocze
2 dni robocze
4 dni robocze
4 dni robocze
Zgłaszanie incydentów - osoby kontaktowe:
Wykonawca przekaże Zamawiającemu listę osób kontaktowych z danymi kontaktowymi oraz
określi sposób kontaktu umożliwiający zgłoszenie incydentów przez całą dobę i we wszystkie
dni tygodnia. Niezbędne jest zapewnienie co najmniej kontaktu telefonicznego i faksowego,
aktywnego przez całą dobę i we wszystkie dni tygodnia.
2.12.
Świadczenie usług gwarancyjnych
Gwarancja obejmie wszystkie elementy oprogramowania i usługi dostarczone przez
Wykonawcę. W ramach udzielonej gwarancji Wykonawca zobowiązuje się bezpłatnie
usuwać wykryte incydenty zgodnie z definicjami przedstawionymi w rozdziale 2.11.
2.12.1.
Warunki gwarancji
a) Wykonawca udzieli minimum 24 miesięcznej gwarancji na prawidłowe, wolne od wad i
nieprzerwane działanie dostarczonego Systemu. Gwarancja obejmuje wszystkie
elementy Systemu dostarczone przez Wykonawcę oraz modyfikacje, aktualizacje
Systemu realizowane przez Wykonawcę w ramach gwarancji, oraz modyfikacje
wykonane przez Zamawiającego, o ile zostały wcześniej autoryzowane (wyrażona
zgoda) przez Wykonawcę.
b) Termin rozpoczęcia gwarancji liczony jest od dnia po podpisaniu protokołu odbioru etapu
III a wnioskując o rozliczenie finansowe .
c) Gwarancja świadczona będzie przez cała dobę i we wszystkie dni tygodnia łącznie ze
świętami.
d) W ramach udzielonej gwarancji Wykonawca zobowiązuje się bezpłatnie do:
 administrowania portalem (administrator techniczny),
 analizy problemów zgłaszanych przez użytkowników Systemu oraz dostarczenia i
zaimplementowania
docelowego
rozwiązania
zgłaszanych
problemów.
Implementacja rozwiązania wymaga zgody Zamawiającego. Wymagane jest też
dostarczenie zaktualizowanej dokumentacji po dokonaniu zmian,
27

asysty przy określaniu i usuwaniu przyczyn oraz skutków Awarii Systemu i
identyfikacji elementu Systemu, który jest tego przyczyną,
 dostarczania, instalacji (po uzyskaniu zgody Zamawiającego) i konfiguracji łatek i
poprawek dla dostarczonego Systemu oraz związanych z tym aktualizacji
dostarczonej dokumentacji i przekazanych kodów źródłowych,
 dostosowania Systemu do zmian aktów prawnych mających wpływ na dostarczony
System i realizowana przez niego funkcjonalność,
 dokonywanie okresowych (nie rzadziej niż co 12 m-cy) przeglądów dostarczonego
Systemu.
2.12.2.
Z każdej czynności realizowanej w Systemie (instalacja, konfiguracja,
modyfikacja itp.) Wykonawca sporządzi protokół zawierający m.in. powód
przeprowadzonych prac, ich szczegółowy zakres oraz czas trwania.
2.12.3.
Termin każdej instalacji musi zostać uzgodniony z Zamawiającym minimum na
3 dni robocze przed planowanym rozpoczęciem prac (termin nie dotyczy czynności
wynikających z naprawy Awarii, Usterki, Podatności, Błędu i Błędu krytycznego).
2.12.4.
W ramach asysty Wykonawca zobowiązuje się do świadczenia bezpłatnej
Interwencji na żądanie Zamawiającego w wymiarze 8 godzin miesięcznie przez cały
czas trwania gwarancji. Do czasu prac naprawczych nie wlicza się dojazdu do
miejsca naprawy.
2.12.5.
Czas Reakcji Serwisu na otrzymane zgłoszenie nie może być dłuższy niż 2
godziny. Brak potwierdzenia we wskazanym czasie oznacza automatycznie
rozpoczęcie biegu terminu skutecznej naprawy. Wykonawca niezwłocznie po
otrzymaniu zgłoszenia przystąpi do analizy zaistniałej sytuacji i podejmie działania
zmierzające do usunięcia zgłoszonych nieprawidłowości w działaniu Systemu.
2.12.6.
Maksymalny Czas naprawy Błędu krytycznego - 2 godziny.
2.12.7.
Maksymalny Czas naprawy Awarii to 1 dzień roboczy.
2.12.8.
Maksymalny Czas naprawy Błędu to 2 dni robocze.
2.12.9.
Maksymalny Czas naprawy Usterki to 4 dni robocze.
2.12.10.
Maksymalny Czas naprawy Podatności to 4 dni robocze. W przypadku, w
którym z przyczyn niezależnych od Wykonawcy naprawa Podatności nie będzie w
danym czasie możliwa, Wykonawca za pisemną zgodą Zamawiającego może
przedłużyć czas naprawy. W sytuacjach awaryjnych, za pisemną zgodą
Zamawiającego przewiduje się możliwość stosowania na uzgodniony okres
rozwiązań doraźnych (np. wyłączenie podatnego modułu).
3. Dokumentacja
Zamawiający udostępni Wykonawcy dokumentacje dot. strony internetowej , z której
Wykonawca może skorzystać przy tworzeniu Portalu CSIOZ.
3.1. Dokumentacja powykonawcza
28
a) Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji
projektu charakteryzowały się wysoką jakością, a w szczególności:
 Czytelną i zrozumiałą strukturę zarówno poszczególnych dokumentów jak i
całej dokumentacji z podziałem na rozdziały, podrozdziały i sekcje.
 Zachowanie standardów oraz sposobu pisania, rozumianych jako zachowanie
jednolitej i spójnej struktury, formy i sposobu prezentacji treści
poszczególnych dokumentów oraz fragmentów tego samego dokumentu jak
również całej dokumentacji.
b) W ramach wdrożenia Wykonawca opracuje i dostarczy szczegółową
dokumentacje powykonawczą (instalacja, konfiguracja i parametryzacja Systemu,
struktura baz danych wraz z opisem przeznaczenia tabel i pól) wraz z opisem
procedur i instrukcji eksploatacyjnych, a w szczególności:
 procedury i instrukcje wykonania kopii bezpieczeństwa środowiska (całego
serwera) i ich odtworzenia,
 procedury i instrukcje wykonanie backupu Systemu i odtworzenia danych z
backupu,
 procedury i instrukcje bieżącego monitoringu oraz utrzymania Systemu,
 procedury i instrukcje aktualizacji i wdrażania łat i aktualizacji,
 procedury postępowania w razie wystąpienia Błędów lub Awarii wraz z
formularzami zgłoszeniowymi i osobami kontaktowymi (nr tel., fax, e-mail) do
konsultacji rozwiazywania zaistniałych problemów,
 procedury i instrukcje bieżącej analizy oraz archiwizowania zapisów
Systemów zabezpieczeń (logów),
c) Każda procedura powinna zawierać co najmniej następujące dane:
 nazwa,
 opis,
 częstotliwość wykonywania,
 kroki do realizacji w procedurze,
 informacje (o ile są znane, jeśli jest ich dużo podać przykłady lub wzorce) na
jakie należy zwrócić uwagę w trakcie wykonywania procedury.
3.2. Dokumentacja użytkownika i administratora
W ramach wdrożenia Wykonawca opracuje i dostarczy szczegółową instrukcję obsługi
Systemu dla jego użytkowników, redaktorów i administratorów, 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.
3.3. Dostarczenie i aktualizacja dokumentacji
29
Dokumentacja musi być aktualizowana po każdej modyfikacji/aktualizacji Systemu.
Dokumentacja zostanie dostarczona w wersji elektronicznej w postaci plików w formacie
PDF (bez zabezpieczeń z możliwością wyszukiwania) na nośniku danych (płyta CD/DVD)
oraz w postaci wydruku po 2 egzemplarze każdego rodzaju dokumentacji z prawem do
tworzenia dowolnej ilości kopii tej dokumentacji na użytek własny. Zamawiający wymaga,
aby cała dokumentacja, o której mowa powyżej, podlegała jego akceptacji.
3.4. Ograniczenia, założenia, zależności
3.4.1.
Dostęp do funkcji Systemu
Pełna funkcjonalność Systemu (dla redaktorów i administratorów) musi być dostępna przez
przeglądarkę internetową bez potrzeby instalowania na stacji roboczej użytkownika
jakiegokolwiek oprogramowania niebędącego częścią przeglądarki internetowej. Dopuszcza
się użycie technologii Flash, lub Java do prezentacji danych (wykresów statystyk itp.), nie
może jednak ono blokować możliwości korzystania z podstawowych funkcji Systemu.
3.4.2.
Prace instalacyjne, konfiguracyjne, gwarancyjne
a) Wszystkie przeprowadzane przez Wykonawcę prace instalacyjne, konfiguracyjne,
gwarancyjne nie mogące zostać wykonane zdalnie, lub wymagające fizycznego dostępu
do serwerów będą odbywać się przy udziale wyznaczonych pracowników
Zamawiającego (w godzinach 8:00-16:00 w dni robocze).
b) Jeżeli niezbędne okażą się działania wymagające wyłączania urządzeń 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,
planowanego czasu niezbędnego do przeprowadzenia prac, oraz listy osób Wykonawcy
wyznaczonych do ich przeprowadzenia.
4. Bezpieczeństwo
4.1. Budowa Systemu
a) CMS musi być wykonany zgodnie z wzorcem projektowym MVC (model–widok–
kontroler) zakładającymi oddzielenie danych od części biznesowej i interfejsu
użytkownika.
b) CMS musi być wykonany w architekturze opartej na usługach (SOA).
c) CMS musi być oparty o relacyjną oraz komercyjną bazę danych w standardzie SQL
wraz z supportem obejmującym okres pięciu lat od czasu zakończenia realizacji
umowy.
d) Konstrukcja Systemu musi zapewniać redundancje poszczególnych elementów, tak
aby Awaria któregokolwiek z nich nie powodowała braku dostępu do całego Systemu.
e) System musi posiadać konstrukcję modułową, umożliwiającą niezależne, stopniowe
uruchamianie różnych funkcjonalności.
30
System musi uniemożliwiać dostęp do funkcji i zgromadzonych w nim danych z
pominięciem jego mechanizmów bezpieczeństwa.
g) System musi filtrować i walidować wszystkie dane wejściowe (np. wprowadzone
przez użytkowników) w celu zminimalizowania ryzyka naruszenia integralności
Systemu baz danych.
f)
4.2. Dostęp do kodów źródłowych
a) Wykonawca przekaże Zamawiającemu udokumentowane kody źródłowe i binarne
oprogramowania CMS.
b) Każda modyfikacja lub aktualizacja Systemu przez Wykonawcę musi skutkować
przekazaniem Zamawiającemu aktualnej udokumentowanej wersji kodów źródłowych
aplikacji.
c) Wykonanie prac w Etapie III b przez Wykonawcę musi skutkować przekazaniem
Zamawiającemu aktualnej udokumentowanej wersji kodów źródłowych aplikacji.
d) Wykonawca przekaże Zamawiającemu kody źródłowe nie później niż w dniu
podpisania protokołu odbioru etapu II wnioskującego o rozliczenie finansowe.
4.3. Kodowanie znaków
a) System musi kodować znaki w standardzie Unicode UTF-8 wersja 3.0.
b) Wszelkie treści umieszczane przez redaktorów Portalu powinny być automatycznie
konwertowane do tego zestawu znaków.
4.4. Generowanie treści
CMS musi posiadać system tworzenia statycznych kopi treści generowanych dynamicznie
(caching). System musi minimalizować ilość odwołań do bazy danych oraz obciążenia
serwera związane z generowaniem treści. System musi posiadać zabezpieczenia na
wypadek nagłego wzrostu ruchu na stronie, który wyłączy funkcjonalności portalu generujące
największe obciążenia serwera i łącza.
4.5. Optymalizacja dla wyszukiwarek
a) CMS musi posiadać możliwość optymalizacji każdej strony portalu pod kątem
wyszukiwania (SEO – Search Engine Optimization), w tym przypisywania
indywidualnych słów kluczowych i opisu w ramach pól „meta”, tytułów strony w
znaczniku <title>, adresu URL strony.
b) System musi umożliwiać indywidualne wypełnianie atrybutów alt grafik używanych na
portalu.
4.6. Obsługa Błędów
31
a) System musi posiadać mechanizm obsługi Błędów poprzez możliwość dostosowania
stron Błędów (np. 404) w ramach Systemu.
b) System musi generować prawidłowe kody Błędów HTTP (prawidłowo rozpoznawane
przez wyszukiwarki internetowe) dla nieistniejących, przeniesionych lub
odpublicznionych elementów Systemu (plików, kategorii, artykułów).
c) Należy dostarczyć mechanizm przenoszący użytkownika na stworzoną przez
Wykonawcę stronę informacji o Błędzie (ERROR 404) w przypadku podania nie
prawidłowego adresu podstrony portalu. Na stronie będzie wyświetlana informacja o
braku strony o takim adresie, link do strony głównej portalu oraz pole wyszukiwarki.
d) Mechanizm umożliwiający wyświetlanie zaprojektowanej przez Wykonawcę strony
zawierającej informacje o czasowej niedostępności Systemu z powodów
technicznych.
4.7. Import i Export danych
a) CMS musi posiadać mechanizmy importu i eksportu wybranego zakresu kategorii,
stron, artykułów z/do plików XML o zdefiniowanej strukturze.
b) Strukturę zdefiniuje i szczegółowo opisze w dokumentacji sytemu Wykonawca.
4.8. Bezpieczny dostęp
a) System musi spełniać wymogi bezpieczeństwa w zakresie dostępu użytkowników do
zasobów Systemu poprzez zapewnienie bezpiecznego kanału dostępu i
zastosowanie mechanizmów uwierzytelniania i autentykacji użytkownika.
b) System musi zapewniać bezpieczeństwo i poufność zgromadzonych dokumentów,
danych przed nieautoryzowanymi zmianami.
c) Komunikacja użytkownika z Systemem musi odbywać się za pomocą bezpiecznego
połączenia szyfrowanego SSL z kluczem o długości co najmniej 128 bitów dla
wszystkich administratorów i redaktorów portalu.
d) Administrator merytoryczny musi mieć możliwość z poziomu panelu
administracyjnego CMS, włączenia bezpiecznego połączenia SSL dla określonych
działów czy artykułów na portalu.
e) 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.
f) Hasła użytkowników nie mogą być przechowywane w bazie Systemu w postaci
jawnej, lecz z wykorzystaniem bezpiecznej funkcji skrótu (np. SHA).
g) System musi umożliwiać ustawienie przez administratora technicznego bądź
merytorycznego czasu bezczynności w Systemie, po którym redaktor zostanie
automatycznie wylogowany z Systemu.
h) System musi umożliwiać włączenie mechanizmu blokowania kilkukrotnego
jednoczesnego logowania się tego samego użytkownika.
32
System musi czasowo blokować konto (z możliwością ręcznego odblokowania przez
uprawnionego administratora) przy wielokrotnej próbie zalogowania niewłaściwym
hasłem – ilość prób musi być możliwa do ustalania przez administratora.
j) System musi rejestrować udane i nieudane próby logowania do sytemu CMS
(obejmując między innymi adres IP komputera, z którego dokonywano logowania –
wykaz dostępny dla administratora).
k) Portal CSIOZ będzie gromadził dane osobowe użytkowników, w związku z czym
konieczne jest zapewnienie przez Wykonawcę zgodności Systemu informatycznego
Portalu z aktualnymi aktami prawnymi obowiązującymi w tym zakresie.
l) Zapewnione będzie bezpieczeństwo wszystkich danych zgromadzonych w bazie
danych Portalu poprzez wbudowany mechanizm wykonywania kopii zapasowych tych
danych wraz z możliwością ich odtwarzania po Awarii.
m) Wykonawca opracuje procedury backupu i przywracania danych, które przedłoży do
akceptacji Zamawiającego.
n) System musi spełniać wymagania określone w Ustawie o ochronie danych
osobowych (Dz.U.2002.101.926) oraz wewnętrznych przepisach Zamawiającego
wynikających z ww. ustawy.
i)
4.9. Zabezpieczenie Systemu
a) System musi być zgodny z wytycznymi zawartymi w OWASP ASVS oraz być
wolnym od podatności zawartych w dokumencie OWASP TOP. Wykonawca
zapewni zgodność CMS z wytycznymi OWASP. Wykonawca stosować będzie
aktualną na dzień zawarcia umowy wersję OWASP ASVS oraz OWASP-TOP 10.
Wykonawca przeprowadzi przy udziale Zamawiającego audyt oraz analizę
wymaganych dla potwierdzenia zgodności z powyższymi dokumentami testów
bezpieczeństwa. Wykonawca przedstawi raport oraz analizę z audytu.
System musi być odporny na znane techniki ataku i włamań typowych dla technologii,
w której został wykonany w tym m.in. na:
 SQL Injection,- „Błędy Wstrzyknięcia” : Wykonawca weźmie pod uwagę Błędy takie
jak: SQL, OS shell, LDAP, XPath Injection. Wykonawca dodatkowo zabezpieczy
CMS przed możliwością wysyłania spreparowanych danych do interpretera, jako
części zapytania lub polecenia. Dodatkowo Wykonawca zabezpieczy CMS w
system filtrujący,
 Broken Authentication and Session Management, - “Niepoprawna obsługa
uwierzytelnienia I sesji” : Wykonawca zabezpieczy CMS przed możliwością
przeprowadzenia ataków osobom nie upoważnionym takich jak : ujawnienie haseł
(w zależności od struktury serwisu), kluczy, tokenów sesji lub wykonania poleceń
na prawach zalogowanego użytkownika.− Cross-Site Scripting (XSS), - „Skrypty
między serwisowe”. Wykonawca zabezpieczy CMS w rozwiązania nie
dopuszczające do przechwycenia sesji zalogowanego poprawnie użytkownika,
33














Insecure Direct Object References – „Niezabezpieczone bezpośrednie odwołanie
do obiektu”,
Security Misconfiguration, - „Zła Konfiguracja” : Wykonawca zabezpieczy CMS,
framework, web serwer, serwer aplikacji, platformę, w odpowiednie ustawienia
mające wpływ na bezpieczeństwo. Wszelkie ustawienia powinny zostać
zdefiniowane, zaimplementowane oraz utrzymywane przez cały czas trwania
umowy,
Sensitive Data Exposure – „Ochrona danych wrażliwych” Wykonawca zabezpieczy
CMS zgodnie z normami GIODO,
Missing Function Level Access Control – „Utracenie poziomu kontroli dostępu”,
Cross-Site Request Forgery, - “Fałszowanie żądań ”,
Using Components with Known Vulnerabilities,
Unvalidated Redirects and Forwards “Brak walidacji przekierowań” Wykonawca
zabezpieczy CMS w rozwiązanie nie pozwalające na przelinkowanie użytkownika w
inne miejsce niż jest możliwe do wyboru z poziomu CMS,
penetracja niepublicznych zasobów serwera ("pathtraversal", "Google hacking"),
wstrzykiwanie kodu ("codeinjection",
przejmowanie serwera przez dostęp z poziomu kodu do „shell",
wstrzykiwanie komend systemowych,
narzucenie sesji - ataki "sessionfixation", "sessionadoption",
W przypadku pojawienia się nowych nieznanych wcześniej technik włamań,
Wykonawca zobowiązany jest do ich analizy i dostarczenia niezbędnych poprawek
i uaktualnień eliminujących podatności dostarczonego CMS.
b) System musi generować wynik funkcji skrótu dla każdego artykułu/wiadomości w
momencie ich tworzenia.
b) System musi weryfikować wartość funkcji skrótu artykułu wyświetlanego z
wartością funkcji skrótu artykułu utworzonego. W przypadku różnicy w
wartościach system musi generować stosowny alert dla administratora.
c) Wykonawca zakupi, dostarczy i zainstaluje, oraz skonfiguruje oprogramowanie
antywirusowe, dedykowane dla środowiska systemowego, na którym powstanie
portal. Wraz z niezbędnymi licencjami zapewniającymi działanie, możliwość
aktualizacji, oraz wsparcie producenta oprogramowania antywirusowego na okres
5 lat, od momentu zakończenia etapu II. Konfiguracja w szczególności ma
zawierać odpowiednie w kontekście bezpieczeństwa polityki automatycznej
aktualizacji oprogramowania antywirusowego z zewnętrznego repozytorium
(repozytorium producenta oprogramowania), oraz polityki skanowania/wykrywania
i usuwania zagrożeń, przy jednoczesnym zapewnieniu odpowiedniej wydajności
środowiska, oraz raportowania wpływu jaki mają podjęte przez program
antywirusowy działania na zawartość portalu.
34
4.10.
Backup Systemu
a) System ma umożliwiać tworzenie backupu wszystkich elementów składających się na
system (baza danych, aplikacje, pliki) z częstotliwością określoną przez
administratora technicznego.
b) System musi dawać możliwość ustalenia (przez Administratora technicznego)
miejsca przechowywania kopii bezpieczeństwa (co najmniej katalog na serwerze i/lub
lokalizacja ftp).
4.11.
Audyt bezpieczeństwa
a) Wykonawca przeprowadzi audyt bezpieczeństwa dostarczonego Systemu
zainstalowanego i skonfigurowanego na docelowej platformie sprzętowej.
b) Wykonawca przeprowadzi skanowanie skanerami podatności środowiska
systemowego (system operacyjny, baza danych, serwer aplikacyjny, serwer WWW,
itp.) i Systemu CMS na próby włamań oraz przeprowadzi symulacje i próby włamań.
c) 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 z
identyfikowanych incydentów.
d) W przypadku wykrycia jakiejkolwiek podatności Wykonawca przystąpi do
niezwłocznego usunięcia jej przyczyny.
e) Audyt musi zostać przeprowadzony w ramach wdrożenia Etapu II oraz okresowo w
ramach świadczonych usług gwarancyjnych (1- po 12 miesiącach, 2 – po 22
miesiącach od zakończenia Etapu II).
f) Zamawiający zastrzega sobie możliwość przeprowadzenia audytu bezpieczeństwa
Systemu, przez wybraną firmę trzecią oraz samodzielnego przeprowadzenia testów.
Wykonawca zobowiązany jest do uwzględnienia wyników audytu i naprawy
wszystkich zidentyfikowanych luk w bezpieczeństwie Systemu.
4.12.
Przegląd Systemu
a) W ramach świadczonych usług wsparcia Wykonawca zobowiązany jest nie rzadziej
niż co 12 miesięcy do przeprowadzenia przeglądu dostarczonego Systemu.
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ą
35
− 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.
b) Przeglądy odbywać się będą w terminie uzgodnionym z Zamawiającym.
c) Przed przystąpieniem do przeglądu Wykonawca przedstawi do zatwierdzenia
szczegółowy plan Przeglądu Systemu.
5. Optymalizacja i Doradztwo w zakresie optymalizacji i pozycjonowania
strony
a) Wykonawca zobowiązany jest do bieżącego konsultingu i doradztwa w zakresie
optymalizacji i pozycjonowania stron w terminie trwania umowy.
b) Wykonawca przygotuje audyt dot. pozycjonowania obecnej strony oraz przygotuje
raport z wykazem działań, które Zamawiający może wykonać we własnym zakresie w
celu polepszenia pozycji strony. Działania te nie mogą wymagać od Zamawiającego
ponoszenia kosztów np. system reklamowy Google . Powinny być one dostosowane
do specyfiki strony i potrzeb Zamawiającego.
c) Wykonawca powinien po przygotowaniu raportu przeprowadzić szkolenie dla
pracowników Zamawiającego dot. ww działań. Realizacja szkolenia zgodnie z
punktem 6.
d) Wykonawca do projektowania strony powinien wykorzystać przyjazne adresy
podstron.
6. Szkolenia
6.1. Wymagania dot. Szkoleń
a) W ramach wdrożenia, Wykonawca przeprowadzi szkolenia dot. wdrażanego Systemu
(dla administratorów i redaktorów).
b) Szkolenie przeprowadzone zostanie w siedzibie Zamawiającego.
c) Szkolenie w siedzibie CSIOZ w Warszawie, ma odbywać się w godzinach pracy
Zamawiającego tj. 8:00 – 16:00 w uzgodnionych wcześniej z Zamawiającym
terminach.
d) Szkolenie musi być prowadzone przez co najmniej 1 trenera Wykonawcy.
e) Grupa szkoleniowa będzie liczyć nie więcej niż 10 osób.
f) Wykonawca określi niezbędny wymiar szkolenia dla poszczególnych grup
użytkowników.
g) Przed przystąpieniem do szkolenia, Wykonawca przedstawi Zamawiającemu do
akceptacji zakres szkolenia i materiały szkoleniowe.
h) Szkolenie musi zostać przeprowadzone na szkoleniowej wersji Sytemu
przygotowanej na potrzeby szkolenia przez Wykonawcę na swoim serwerze.
36
Przed rozpoczęciem szkolenia Wykonawca przygotuje stanowiska komputerowe
udostępnione przez Zamawiającego do przeprowadzenia szkolenia.
j) Środowisko szkoleniowe dla administratorów musi zostać przygotowane w postaci
obrazu VMWare.
k) Potwierdzeniem odbytego szkolenia jest przekazanie Zamawiającemu przez
prowadzącego szkolenie imiennej listy uczestników potwierdzonej ich własnoręcznym
podpisem.
l) Wykonawca przeprowadzi szkolenia w języku polskim, zapewniając na swój koszt
materiały szkoleniowe dla uczestników szkolenia.
m) W celu weryfikacji jakości przeprowadzonego szkolenia Zamawiający zastrzega sobie
możliwość przeprowadzenia ankiety wśród uczestników szkolenia dotyczącej ocen
jakości przeprowadzonego szkolenia (ocena w skali 1-6 w przypadku kiedy średnia
ocen z danego szkolenia będzie poniżej 3, Zamawiający ma prawo żądać
powtórzenia szkolenia).
i)
6.2. Certyfikaty uczestnictwa w szkoleniu
Uczestnicy otrzymają certyfikaty potwierdzające ukończenie szkolenia 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 (np. redaktor,
administrator merytoryczny).
7. Licencjonowanie
1. Wykonawca dostarczy wszystkie niezbędne do pracy Systemu (niewyłączne,
bezterminowe,
bez
prawa
przekazywania,
niepodlegające
odrębnemu
sublicencjonowaniu) licencje (bazodanowe, narzędziowe itp.) dla każdej z
przewidzianych instalacji CMS.
2. Wszystkie licencje ewentualnych firm trzecich muszą być dostarczone ze wsparciem
ich producentów przez cały okres wdrożenia i serwisu wraz z dostępem do nowych
wersji oprogramowania będącego przedmiotem licencji.
8. Testy
a) Wykonawca przygotuje i przedstawi do akceptacji Zamawiającego plan i scenariusze
testów składające się w szczególności z: testów funkcjonalności, testów wydajności,
testów bezpieczeństwa, testów regresji i testów integracji.
37
b) Wykonawca zrealizuje testy zgodnie z planem i scenariuszami zaakceptowanymi
przez Zamawiającego.
c) Wykonawca jest odpowiedzialny za:
 przygotowanie scenariuszy testowych,
 przygotowanie danych testowych,
 przygotowanie środowiska testowego,
 konfiguracje środowiska testowego,
 ładowanie danych testowych.
d) Prace przygotowawcze wymagają akceptacji Zamawiającego.
e) Testy te 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.
f) Wykonawca zobowiązany jest do powtórzenia testów wydajności oraz
bezpieczeństwa na środowisku Zamawiającego.
g) Wykonawca po zakończeniu testów zobowiązany jest do przekazania raportu do
akceptacji Zamawiającego. W przypadku odrzucenia raportu Zamawiający zastrzega
sobie prawo do przeprowadzenia testów na swoim środowisku. Wykonawca jest
zobowiązany do uwzględnienia przekazanych przez Zamawiającego uwag.
38