dotyczący budowy internetowego portalu informacyjnego Ośrodka Wparcia Architektury Dostępnej (OWDA) wraz z usługą utrzymania, realizowanego w ramach projektu pn. „Ośrodek Wsparcia Architektury Dostępnej (OWDA) - kompleksowe usługi w zakresie...

OPIS PRZEDMIOTU ZAMÓWIENIA

dotyczący budowy internetowego portalu informacyjnego Ośrodka Wparcia Architektury Dostępnej (OWDA) wraz z usługą utrzymania, realizowanego w ramach projektu pn. „Ośrodek Wsparcia Architektury Dostępnej (OWDA) - kompleksowe usługi w zakresie dostępności architektonicznej dla podmiotów publicznych”

Załącznik nr 1

1.Wstęp

Celem niniejszego zamówienia jest zaprojektowanie, budowa, wdrożenie oraz utrzymanie i rozwój portalu informacyjnego (zwanego dalej „Portalem”) z systemem zarządzania treścią, wraz z wykonaniem zawartości startowej w oparciu o koncepcję graficzną, dostarczoną przez Zamawiającego oraz uzupełnianiem zawartości w trakcie trwania projektu.

Planowany do realizacji Portal dedykowany będzie do publikowania informacji o projekcie „Ośrodek Wsparcia Architektury Dostępnej (OWDA) - kompleksowe usługi w zakresie dostępności architektonicznej dla podmiotów publicznych” realizowanego w ramach Programu Operacyjnego Wiedza Edukacja Rozwój na lata 2014-2020, Oś Priorytetowa II. Efektywne polityki publiczne dla rynku pracy, gospodarki i edukacji, Działanie 2.19 Usprawnienie procesów inwestycyjno-budowlanych i planowania przestrzennego (zwanego dalej jako „Projekt”) oraz wszelkich treści niezbędnych do komunikowania i popularyzacji Projektu a także służących lepszemu poznaniu funkcjonalności Ośrodka Wsparcia Architektury Dostępnej (dalej jako „OWDA”) oraz form wsparcia realizowanych za pośrednictwem OWDA wśród jego Beneficjentów i Interesariuszy.

Odbiorcami treści Serwisu będą osoby zainteresowane realizacją Projektu, w tym wdrożeniem dostępności architektonicznej w podmiotach publicznych (dalej jako „PP”)

Główną grupą odbiorców będą PP, które pełnią usługi szczególnie istotne dla funkcjonowania osób ze szczególnymi potrzebami, w tym osób z niepełnosprawnościami (OzN), jak administracja, pomoc społeczna, ochrona zdrowia, edukacja, włączenie w rynek pracy, czy też transport. Do projektu włączone zostaną następujące rodzaje PP świadczących usługi publiczne:

• centralne i terenowe organy administracji państwowej;

• ministerstwa oraz urzędy wojewódzkie;

• jednostki Samorządu Terytorialnego – urzędy: marszałkowskie, miast i gmin, starostwa powiatowe;

• szkoły i uczelnie wyższe;

• oddziały Narodowego Funduszu Zdrowia, Samodzielne Publiczne Zakłady Opieki Zdrowotnej, w szczególności świadczące usługi w zakresie rehabilitacji;

• państwowe i samorządowe instytucje kultury, domy kultury, muzea, wypożyczalnie książek;

• obiekty transportu i komunikacji publicznej, lotniska, dworce autobusowe i kolejowe (o różnej wielkości i zasięgu świadczonych usług);

• oddziały Zakładu Usług Społecznych, Ośrodki Pomocy Społecznej, Powiatowe Centra Pomocy Rodzinie;

• Wojewódzkie i Powiatowe Urzędy Pracy.

Niniejszy dokument stanowi Opis Przedmiotu Zamówienia (OPZ) do postępowania o udzielenie zamówienia publicznego na budowę internetowego serwisu informacyjnego www OWDA wraz z usługą jego utrzymania i rozwoju.

W związku z tym, że zamówienie będzie finansowane ze środków unijnych z Programu Operacyjnego Wiedza Edukacja Rozwój na lata 2014-2020, każdy dokument oraz Serwis powinien zostać oznaczony zgodnie z wytycznymi Ministerstwa Funduszy i Polityki Regionalnej, zamieszczonymi na stronie internetowej xxxxx://xxx.xxxxxxxxxxxxxxxxxxx.xxx.xx/xxxxxx/x-xxxxxxxxxx/xxxxxxxxx/xxxxxxxxxx-xxxxxxxxxxxx-x-xxxxxxxxxxxx-xxxxxxxxx-xxxxxxxx-xxxxxxxxx-0000-0000-x-xxxxxxxx-xxxxxxxxxx-x-xxxxxxxx-xxx-xxxx-xxxxxxxxxxx-xx-0-xxxxxxxx-0000-x/ z późn. zm.

2.Zastosowane terminy i skróty.

Termin / skrót	Wyjaśnienie / opis
Administrator Systemu Informatycznego (ASI)	Osoba wyznaczona przez Gestora Systemu Teleinformatycznego i bezpośrednio nadzorującą funkcjonowanie określonego Systemu Teleinformatycznego w PFRON.
Błąd	Wada powodująca niepoprawne i niezgodne z instrukcją użytkownika działanie poszczególnych funkcji Serwisu.
Błąd Krytyczny	Wada powodująca całkowite zatrzymanie lub poważne zakłócenie pracy Serwisu lub poszczególnych jego części, dla której nie ma alternatywnej metody wykonania danej operacji w Serwisie, uniemożliwiająca korzystanie z podstawowych funkcji serwis przez jego Użytkowników tak, jak było to możliwe przed wystąpieniem Błędu Krytycznego.
Błąd Użytkownika	Wada powstała na skutek działania Użytkownika, której skutków nie można usunąć z poziomu interfejsu Użytkownika Serwisu.
Czas Naprawy	Czas liczony od momentu potwierdzenia przyjęcia przez Wykonawcę prawidłowego Zgłoszenia o Wadzie, do momentu Naprawy.
Czas Reakcji	Czas liczony od momentu dokonania prawidłowego Zgłoszenia przez Zamawiającego do momentu potwierdzenia przyjęcia Zgłoszenia przez Wykonawcę.
Dzień Roboczy	Każdy dzień tygodnia od poniedziałku do piątku, za wyjątkiem dni ustawowo wolnych od pracy w Rzeczypospolitej Polskiej.
Godziny Robocze	Godziny od 8:00 do 17:00 w Dni Robocze.
Odbiór	Czynności mające na celu potwierdzenie dostarczenia Zamawiającemu wyników Usług Utrzymania, Zlecenia i Produktów, powstałych w wyniku zobowiązań wynikających z realizacji Umowy.
Oprogramowanie	Oprogramowanie zapewniane przez Wykonawcę, tj. Oprogramowanie Dedykowane, Oprogramowanie Standardowe lub Oprogramowanie Open Source.
Oprogramowanie Dedykowane	Oprogramowanie wytworzone w ramach realizacji Umowy specjalnie dla Zamawiającego na potrzeby wykonania niniejszej Umowy, niezależnie od tego, czy stanowi nowy program komputerowy, czy jest modyfikacją, kastomizacją lub inną zmianą programistyczną Oprogramowania.
Oprogramowanie Standardowe/ Oprogramowanie Obce	Oprogramowanie dostarczone przez Wykonawcę inne niż Oprogramowanie Dedykowane lub Oprogramowanie Open Source, na którego użycie w procesach budowy, rozwoju, konfiguracji, instalacji lub użytkowania Serwisu Zamawiający wyraził zgodę. Wykonawca powinien uzyskać uprzednią zgodę Zamawiającego na użycie określonego Oprogramowania Standardowego/Obcego przed przystąpieniem do wszelkich prac.
Oprogramowanie Open Source	Oprogramowanie dystrybuowane na warunkach tzw. licencji otwartych lub wolnych, na którego użycie w procesach budowy, rozwoju, konfiguracji, instalacji lub użytkowania Serwisu Zamawiający wyraził zgodę.
Oprogramowanie Systemowe i Narzędziowe	Oprogramowanie wykorzystywane na potrzeby Serwisu, konieczne do poprawnego działania Serwisu, inne niż Oprogramowanie Zamawiającego. Wykonawca powinien uzyskać uprzednią zgodę Zamawiającego na użycie określonego Oprogramowania Systemowego i Narzędziowego przed przystąpieniem do wszelkich prac.
Oprogramowanie Zamawiającego	Oprogramowanie aktualnie wykorzystywane na potrzeby Serwisu, które zapewnia Zamawiający.
Portal Zgłoszeniowy (PZ)	System informatyczny wykorzystywany przez Zamawiającego (Jira) służący do ewidencji i obsługi Zgłoszeń, Zamówień, Protokołów, zapewniający niezbędny poziom wymiany informacji pomiędzy Zamawiającym a Wykonawcą.
Produkt	Serwis oraz wszelkie dokumenty, dokumentacje, materiały informacyjne, pliki konfiguracyjne, skrypty, kody źródłowe, makiety, projekt graficzny, procedury dostarczone przez Wykonawcę w trakcie realizacji Umowy w formie elektronicznej i papierowej.
Protokół Odbioru	Dokument przedstawiony przez Wykonawcę i zaakceptowany przez Zamawiającego, potwierdzający prawidłowość i zakres wykonania Usług Utrzymania, Usług Rozwoju i wszelkich Produktów powstałych w trakcie realizacji Przedmiotu Umowy.
Roboczogodzina	Jednostka miary pracochłonności wyrażająca normę ilościową pracy wykonanej przez jednego pracownika Wykonawcy w czasie jednej godziny zegarowej. Roboczogodziny są rozliczane w ramach puli Roboczogodzin.
Umowa	Niniejsza Umowa wraz ze wszystkimi aneksami i załącznikami do Umowy.
Usterka	Każda Wada niebędąca Błędem lub Błędem Krytycznym. Usterką jest w szczególności Wada powodująca zakłócenie pracy Serwisu mogąca mieć wpływ na jego funkcjonalność, natomiast nieograniczająca zdolności operacyjnych Serwisu.
Użytkownik	Xxxxx korzystająca z Serwisu, administrująca Serwisem lub redaktor Serwisu.
Wada	Wada Serwisu uniemożliwiająca niezakłócone korzystanie z wszystkich/ poszczególnych funkcjonalności Serwisu. Wady mogą mieć charakter Błędów, Błędów Użytkownika, Błędów Krytycznych oraz Usterek.
Zamówienie	Przekazanie Wykonawcy zapotrzebowania na wykonanie określonych Produktów lub innych prac w ramach Usługi Rozwoju
Zgłoszenie	Przekazanie Wykonawcy zawiadomienia o Wadzie lub złożenie zapotrzebowania na Konsultację w ramach świadczenia Usługi Utrzymania oraz zawiadomienie o Wadzie w okresie świadczenia gwarancji.
Konsultacja	Udzielenie fachowej porady na zapytanie Zamawiającego Zgłoszone w PZ.

3.Przedmiot zamówienia

Przedmiotem zamówienia jest stworzenie portalu internetowego OWDA. Koncepcja serwisu zakłada jego funkcjonowanie jako zdalnej płaszczyzny funkcjonowania OWDA, która umożliwi realizację celów projektu również w warunkach wzmożonego reżimu sanitarnego czy też lockdown-u. Oznacza to, że portal OWDA pozwoli na realizację zadań takich jak:

-Stworzenie repozytorium wiedzy. W repozytorium wiedzy przechowywane i prezentowane będą także case studies porad udzielanych PP.

-Stworzenie przestrzeni upowszechniania wiedzy o dostępności PP w Polsce i projektowaniu uniwersalnym.

W obrębie www OWDA znajdzie się sekcja dedykowana wymianie poglądów i organizacji wirtualnych spotkań. Niezbędne jest wyposażenie www OWDA w system umożliwiający prezentację materiałów audio i video, galerii fotografii, interaktywnych spotkań online w czasie rzeczywistym takich jak spotkania branżowe, wykłady, webinaria, panele dyskusyjne, transmisje na żywo online z opcją prowadzenia webinariów, realizacja wysyłek masowych.

Serwis internetowy OWDA musi być zaprojektowany z zachowaniem zasad dostępności cyfrowej (WCAG 2.1) oraz informacyjno-komunikacyjnej. Serwis powinien zapewniać dostępność cyfrową publikacji multimedialnych na stronie internetowej OWDA (audiodeskrypcja, napisy rozszerzone dla osób głuchych, tłumacz języka migowego, dokumenty cyfrowe powinny być zaadoptowane dla osób z niepełnosprawnościami). Dodatkowo – powinien zapewniać usługę tłumacza języka migowego on-line, który będzie świadczył pomoc w kontaktach zdalnych z osobami głuchymi oraz zakup usługi napisów na żywo, w celu zapewnienia dostępności dla osób głuchych.

W celu sprawnej realizacji projektu należy na portalu zapewnić osobny dostęp dla realizatorów i uczestników projektu.

W części dla realizatorów pracownicy OWDA powinni mieć dostęp do:

1. Danych PP,

2. Dokumentów rekrutacyjnych PP (formularz rekrutacyjny, ankieta w formacie docx lub pdf),

3. Dokumentów przygotowanych dla PP – wstępna diagnoza potrzeb, pogłębiona analiza potrzeb i zatwierdzona analiza potrzeb ze ścieżką wsparcia dla PP (wszystkie te etapy powinny mieć możliwość edycji przez realizatorów i zmiany ich statusu w systemie (proponowane statusy – do przygotowania/w przygotowaniu/zatwierdzony))

4. Wsparcie dla PP z podziałem na:

   1. Rodzaj usługi,

   2. Personel odpowiedzialny za obsługę konkretnego PP (dane osobowe i funkcja w projekcie – z możliwością edycji i zmiany osoby),

   3. Czas realizacji (z wyborem okresu wsparcia w oparciu o kalendarz),

   4. Status wsparcia (do wyboru z listy rozwijalnej: zaplanowano do realizacji, w realizacji, zrealizowano).

5. Raport z udzielonego wsparcia dla PP (z określeniem statusu – do przygotowania/ w przygotowaniu/ zatwierdzony).

W każdej chwili system powinien dać możliwość podglądu prac i wskazania osoby odpowiedzialnej za każdy etap prac w projekcie.

Zamawiający zakłada, że na każdym etapie prac w projekcie można uzyskać dane statystyczne na temat liczby podmiotów, którym udzielono wsparcia, z uwzględnieniem różnych kryteriów, określonych przez Zamawiającego (lokalizacja PP, etap inwestycji, rodzaj usługi, formy wsparcia i statusu PP w projekcie).

Ważnym też jest możliwość komunikacji wewnętrznej w ramach portalu – wysyłanie wiadomości pomiędzy personelem OWDA i PP.

W ramach istniejącego portalu Zamawiający chciałby też mieć możliwość integracji danych w serwisie z danymi pochodzącymi z aplikacji zewnętrznej (format pliku do uzgodnienia z Zamawiającym).

Etap I: Projekt Serwisu.

Faza 1: Projekt makiet funkcjonalnych z poprzedzającym spotkaniem konsultacyjno-analitycznym.

Etap zaprojektowania makiet funkcjonalnych poprzedzi spotkanie konsultacyjno-analityczne Zamawiającego z Wykonawcą (dalej jako „Spotkanie I”). Spotkanie I odbędzie się w terminie do 3 Dni Roboczych od daty podpisania Umowy. Zamawiający zastrzega sobie prawo do wydłużenia tego terminu jednak nie dłużej niż o 2 dni Robocze. Spotkanie odbędzie się w terminie wskazanym przez Xxxxxxxxxxxxx i potwierdzonym z Wykonawcą.

Spotkanie I, o którym mowa powyżej, odbędzie się w Warszawie w siedzibie Zamawiającego lub innej lokalizacji uzgodnionej z Zamawiającym. Zamawiający dopuszcza przeprowadzenie Spotkania I w sposób zdalny (np. z wykorzystaniem platformy Teams). Decyzję o sposobie prowadzenia Spotkania w sposób zdalny podejmuje Zamawiający. Prowadzącym Spotkanie I jest Wykonawca.

Podczas Spotkania I zostaną przedstawione przez Zamawiającego cele Serwisu oraz wstępna architektura informacji. Celem Spotkania I będzie wypracowanie przez Wykonawcę, bazując na jego wiedzy i doświadczeniu, ostatecznej wersji architektury informacji, ścieżek użytkownika oraz wykazu widoków przeznaczonych do wykonania makiet funkcjonalnych (przy założeniu, że wykaz będzie uwzględniał minimum widok: strony głównej, strony zwykłej informacyjnej, strony z listą aktualności, strony logowania do portalu, strony z informacjami o PP, strony błędu 404,).

W terminie do 2 Dni Roboczych po Spotkaniu I, Wykonawca przekaże wszystkie ustalenia ze Spotkania I w formie syntetycznego raportu. W terminie 2 Dni Xxxxxxxxx Zamawiający zaakceptuje raport lub wniesie do niego uwagi. Wykonawca ma obowiązek uwzględnić wszystkie uwagi Zamawiającego do raportu w terminie do 2 Dni Roboczych od dnia ich przekazania przez Zamawiającego. W przypadku nieuwzględnienia uwag, Zamawiający uzna za niewykonanie raportu w terminie oraz naliczy karę umowną.

Makiety funkcjonalne są prototypem, szkicem Serwisu. Zawierają układ, rozmieszczenie poszczególnych elementów (logo, menu, slider, treści, zdjęcia, formularze, wyszukiwarki, panele logowania/rejestracji, mapy, stopka, itp.) oraz definiują działanie Serwisu.

Przygotowana makieta funkcjonalna powinna bazować na założeniach i ustaleniach, które zostały spisane w zaakceptowanym przez Zamawiającego raporcie. Makieta funkcjonalna powinna być prototypem poszczególnych widoków, których zakres był ustalony na tym Spotkaniu I.

Makieta funkcjonalna powinna być klikalnym projektem, który pozwoli zweryfikować projektowane zależności pomiędzy częściami Serwisu.

Wykonawca wykona makietę w terminie do 5 Dni Roboczych od akceptacji raportu ze Spotkania I.

W terminie do 2 Dni Roboczych Zamawiający zaakceptuje makietę funkcjonalną lub wniesie do niej uwagi. Zamawiający zastrzega sobie prawo do wydłużenia terminu akceptacji, jednak nie dłużej niż o 3 Dni Robocze. Wykonawca w terminie do 2 Dni Roboczych ma obowiązek uwzględnić uwagi Zamawiającego w makiecie. W przypadku nieuwzględnienia uwag, Zamawiający uzna za niewykonanie makiety w terminie oraz naliczy karę umowną.

Faza 2: Projekt graficzny z poprzedzającym spotkaniem konsultacyjno-analitycznym

Po zaakceptowaniu makiety funkcjonalnej, Wykonawca przystąpi do realizacji projektów graficznych w oparciu o koncepcję graficzną, dostarczoną przez Zamawiającego.

Pracę nad projektem graficznym poprzedzi przekazanie Wykonawcy przez Zamawiającego koncepcji graficznej wraz z opisem wybranej kolorystyki oraz określeniem kolorów dla poszczególnych procesów/zakładek.

Następnie odbędzie się spotkanie konsultacyjno-analityczne Zamawiającego z Wykonawcą, które będzie miało miejsce w ciągu dwóch dni roboczych od przekazania koncepcji graficznej (dalej jako Spotkanie II). Zamawiający zastrzega sobie prawo do wydłużenia tego terminu jednak nie dłużej niż o 2 dni Robocze. Wykonawca podczas Spotkania II zaprezentuje pomysły/rozwiązania/dobre praktyki dla obszarów funkcjonalnych zaakceptowanych w makiecie, które chciałby uwzględnić w projektach graficznych Serwisu. Do tego celu może wykorzystać np. wcześniejsze realizacje Wykonawcy.

Zamawiający x.xx. na podstawie przedstawionej koncepcji graficznej, przedstawi Wykonawcy swoje oczekiwania w zakresie strony wizualnej Serwisu oraz uszczegółowione wymagania dotyczące szablonu graficznego Serwisu.

Celem Spotkania II będzie jak najwcześniejsze wykluczenie rozwiązań, które nie odpowiadają wizji Zamawiającego, a także zebranie niezbędnych wymagań bądź wytycznych w celu opracowania ostatecznej wersji projektu graficznego.

W ramach tej Fazy Wykonawca przedstawi Zamawiającemu trzy wersje projektu graficznego. Każda z wersji prezentować będzie odmienną formę przedstawienia graficznego Serwisu i nie będzie wariantem pozostałych wersji. Grafiki wykorzystane w projektach mogą być w postaci zdjęć lub rysunków – co zostanie uzgodnione z Zamawiającym podczas Spotkania II. Powinny być jednak przygotowane w sposób profesjonalny, z uwzględnieniem jakości, przejrzystości, czytelności. Jednocześnie Wykonawca zastosuje wyłącznie te grafiki, zdjęcia i rysunki, do których posiada i przekaże prawa autorskie lub są one dostępne do powszechnego użytku na zasadzie wolnej licencji.

W terminie do 2 Dni Roboczych po Spotkaniu II, Wykonawca przekaże wszystkie ustalenia ze spotkania w formie syntetycznego raportu. W terminie do 2 Dni Xxxxxxxxx Zamawiający zaakceptuje raport lub wniesie do niego uwagi. Wykonawca ma obowiązek uwzględnić wszystkie uwagi Zamawiającego do raportu w terminie do 2 Dni Roboczych od dnia ich przekazania przez Zamawiającego.

W terminie do 5 Dni Roboczych od akceptacji przez Zamawiającego raportu ze Spotkania II, Wykonawca przygotuje i przedstawi do odbioru 3 projekty graficzne Serwisu w formacie .pdf i formacie pliku źródłowego.

W terminie do 5 Dni Roboczych Zamawiający wybierze projekt graficzny Serwisu lub zgłosi uwagi. Zamawiający zastrzega sobie prawo do wydłużenia terminu akceptacji, jednak nie dłużej niż o 3 Dni Robocze. Wykonawca w terminie do 2 Dni Roboczych na obowiązek uwzględnić uwagi Zamawiającego.

Zamawiający może nie zatwierdzić żadnej z 3 propozycji Projektów graficznych, jeśli będą one niezgodne względem oczekiwań Zamawiającego lub niezgodne z założeniami OPZ i zaakceptowanym raporcie ze Spotkania II. W przypadku niezatwierdzenia żadnej z 3 propozycji projektów graficznych, od momentu poinformowania przez Zamawiającego, Wykonawca w terminie do 3 Dni Roboczych przedstawi mu kolejną propozycję trzech projektów graficznych aż do momentu zatwierdzenia propozycji projektów graficznych przez Zamawiającego

Sumaryczny czas na dopracowanie ostatecznej wersji projektu graficznego wynosi 30 dni liczonych od następnego dnia roboczego po odbiorze makiety. W tym czasie następuje doszczegółowienie wybranego projektu wiodącego, np. z wykorzystaniem pomysłów i rozwiązań zaproponowanych w dwóch pozostałych projektach graficznych. Liczba iteracji nie jest ograniczona z zastrzeżeniem, iż Wykonawca w terminie 2 dni roboczych na obowiązek nanieść uwagi Zamawiającego, a dopracowanie ostatecznej wersji projektu graficznego zakończy się w wyżej wymienionym terminie 30 dni.

Faza 3: Wykonawca w ramach Etapu I przygotuje i dostarczy Zamawiającemu dokument „Projekt techniczno-funkcjonalny Serwisu” (dalej jako „PTFS”) zawierający:

1. architekturę informacji Serwisu,

2. opis formularzy udostępnianych w Serwisie,

3. listę i opis przypadków użycia,

4. ścieżki Użytkownika,

5. wymagania sprzętowe warstwy serwerowej Serwisu, wraz z Oprogramowaniem Standardowym,

6. zatwierdzoną przez Zamawiającego makietę funkcjonalną Serwisu

7. zatwierdzony przez Xxxxxxxxxxxxx projekt graficzny Serwisu Wykonawca dostarczy Zamawiającemu w formacie .pdf oraz w wersji edytowalnej.

PTFS podlega Odbiorowi na zasadach opisanych w Projektowanych Postanowieniach Umowy.

Termin realizacji Etapu I.

Termin realizacji Etapu I w całości (Faza 1, Faza 2, Faza 3) - 60 dni kalendarzowych od dnia zawarcia Umowy.

Wymogiem koniecznym do rozpoczęcia prac w ramach Etapu II przez Wykonawcę jest dokonanie przez Xxxxxxxxxxxxx odbioru prac Xxxxx X.

Etap II: Budowa i Wdrożenie Serwisu

Wykonawca przystępuje do realizacji prac w ramach Etapu II po podpisaniu przez Zamawiającego bez zastrzeżeń Protokołu Odbioru Etapu I.

Prace programistyczne (wdrożenie makiety, projektu graficznego i poszczególnych funkcjonalności Serwisu).

W ramach prac programistycznych Wykonawca implementuje wymagania funkcjonalne zdefiniowane w OPZ i uszczegółowione w ramach Etapu I.

Prace Wykonawcy będą prowadzone na udostępnionym przez Zamawiającego serwerze znajdującym się na jego infrastrukturze. Po zakończeniu prac programistycznych, Wykonawca przygotuje środowisko testowe, na które przeniesie rezultaty prac programistycznych. Zamawiający przeprowadzi testy odbiorcze na środowisku testowym.

Wykonawca na każde żądanie Zamawiającego musi przedstawić najpóźniej w terminie 1 Dnia Roboczego informację dotyczące postępu prac programistycznych. W przypadku wskazania przez Xxxxxxxxxxxxx rozbieżności w stosunku do wcześniejszych ustaleń z Etapu I, Wykonawca ma obowiązek niezwłocznie je usunąć.

Umieszczenie treści w Serwisie.

Wykonawca, po zakończeniu prac programistycznych, a przed przekazaniem Zamawiającemu do Odbioru Xxxxx XX, umieści jednorazowo w Serwisie artykuły przekazane przez Zamawiającego. Artykuły mogą również zawierać treści multimedialne. Zamieszczone w Serwisie przez Wykonawcę materiały muszą spełniać zasady dostępności WCAG 2.1.

Testy wewnętrzne przed przekazaniem przez Wykonawcę Serwisu do Odbioru:

Wykonawca przed przekazaniem Serwisu do Odbioru przeprowadzi testy wewnętrzne na środowisku developerskim według przygotowanych przez siebie scenariuszy testowych. Wykonanie testów Wykonawca potwierdzi raportem zawierającym poszczególne scenariusze testowe oraz wynik testu dla każdego scenariusza osobno.

Po zakończeniu testów wewnętrznych Wykonawca zgłasza Zamawiającemu gotowość do Odbioru Xxxxx XX.

Przekazanie do Odbioru Serwisu.

1. Wykonawca na co najmniej 2 Dni Robocze przed planowanym przekazaniem Serwisu do Odbioru poinformuje Zamawiającego o gotowości do odbioru, chyba że Strony postanowią inaczej. W zgłoszeniu Wykonawca wskaże datę przekazania Serwisu do Odbioru.

2. Odbiór będzie miał charakter warsztatów odbiorczych przy udziale przedstawicieli Zamawiającego i Wykonawcy oraz samodzielnych testów prowadzonych przez Zamawiającego. Podczas Odbioru zostaną przeprowadzone testy wszystkich funkcjonalności opisanych w OPZ oraz uszczegółowionych w Etapie I. Testy będą realizowane na podstawie dostarczonych przez Wykonawcę Scenariuszy Testowych oraz na podstawie doświadczeń i wiedzy Zamawiającego, z wykorzystaniem dowolnych metod. Zamawiający zweryfikuje w szczególności:

1. mechanizmy uwierzytelniające i autoryzujące (role użytkowników),

2. funkcjonalności Serwisu oraz zastosowanego CMS-a,

3. bezpieczeństwo i wydajność Serwisu,

4. skuteczność procedur administratorskich, odtwarzania i wznawiania pracy w sytuacjach awaryjnych,

5. zgodność ze standardem W3C przy pomocy narzędzi:

   1. xxxxx://xxxxxxxxx.x0.xxx/xx/

   2. xxxxx://xxxxxx.x0.xxx/xxx-xxxxxxxxx/

6. dostępność zgodnie z WCAG 2.1 przy pomocy narzędzia do testów automatycznych posiadanego przez Zamawiającego - test Sortsite (do testu Sortsite strony nie mogą być zablokowane przez Robot Exclusion Standard (robots.txt)).

3. Warsztaty rozpoczną się następnego dnia po przekazaniu Serwisu do Odbioru i będą trwały łącznie do 2 Dni Roboczych.

Pierwszego dnia warsztatów Wykonawca zobowiązany będzie do zaprezentowania wszystkich funkcjonalności Serwisu i zastosowanego CMS-a (praktycznej prezentacji ich działania). Jeżeli w trakcie pierwszego dnia warsztatów ujawnią się błędy uniemożliwiające kontynuację warsztatów, warsztaty zostaną przerwane, a Wykonawca zobowiązany będzie w terminie 1 Dnia Roboczego do ich usunięcia. Raport z wykrytych błędów zostanie sporządzony przez Wykonawcę i przedstawiony do akceptacji Zamawiającego podczas warsztatów. Po usunięciu błędów przez Wykonawcę, Strony niezwłocznie przystąpią do kontynuacji warsztatów odbiorczych, z zastrzeżeniem, iż nie mogą one odbyć się później niż w terminie 4 Dni Roboczych liczonych od dnia następnego po dniu pierwotnego przekazania przez Wykonawcę Xxxxx XX do Odbioru.

Wykonawca zapewni dostęp z właściwymi uprawnieniami do Serwisu dla 10 przedstawicieli Zamawiającego.

Warsztaty, o których mowa powyżej, odbędą się:

1. w Warszawie w siedzibie Zamawiającego lub innej uzgodnionej z Zamawiającym lokalizacji w Warszawie. Zamawiający nie pokrywa kosztów dojazdu, wyżywienia i zakwaterowania pracowników Wykonawcy. Zamawiający udostępni niezbędny sprzęt informatyczny uczestnikom warsztatów i pomieszczenia na potrzeby warsztatów, lub

2. w sposób zdalny (np. z wykorzystaniem platformy Teams).

Decyzję o sposobie prowadzenia warsztatów odbiorczych (zdalny czy stacjonarny) podejmie jednostronnie Zamawiający, o czym poinformuje Wykonawcę z odpowiednim wyprzedzeniem.

Procedura Odbioru.

1. Zgłoszenie przedmiotu do Odbioru może mieć miejsce tylko w przypadku jego kompletnego i pełnego wykonania na dzień przekazania do Odbioru. Wykonawca przyjmuje do wiadomości, że przekazanie niekompletnego lub wadliwego przedmiotu Odbioru, może stanowić podstawę do naliczenia kar umownych z tytułu nienależytego wykonania przedmiot Odbioru, na zasadach określonych w Umowie.

2. Prawidłowa realizacja przedmiotu Odbioru zostanie potwierdzona pisemnym pod rygorem nieważności Protokołem Odbioru pozytywnego, podpisanym przez Zamawiającego bez zastrzeżeń. Podstawą Odbioru Etapu II będzie brak błędów funkcjonalnych Serwisu oraz zgodność Serwisu z wymogami określonymi przez Zamawiającego w OPZ i uszczegółowionymi podczas spotkań konsultacyjno-analitycznych (Spotkania I i II).

3. Celem uniknięcia wątpliwości, Strony potwierdzają, że Wykonawca nie jest uprawniony do wystawienia jednostronnego Protokołu potwierdzającego Odbiór. Odbiór stanowi jednostronną kompetencję Zamawiającego.

4. Zamawiający dokona Odbioru Etapu II w terminie 5 Dni Roboczych, liczonych od dnia następnego po dniu przekazania przez Wykonawcę Xxxxx XX do Odbioru. W termin ten wchodzą warsztaty odbiorcze, o których mowa powyżej. Zamawiający zastrzega sobie prawo do wydłużenia terminu wskazanego w zdaniu pierwszym, jednak nie dłużej niż o 3 Dni Robocze.

5. W przypadku ujawnienia błędów lub zastrzeżeń do przedstawionego Serwisu w trakcie Odbioru, Zamawiający zgłosi je Wykonawcy w terminie 2 dni roboczych.

6. Wykonawca zobowiązany jest uwzględnić zgłoszone błędy lub zastrzeżenia, o których mowa powyżej, w terminie uzgodnionym przez Strony, jednak nie dłuższym niż 2 Dni Xxxxxxx, liczone od następnego dnia od ich przekazania przez Zamawiającego. Powyższe Wykonawca dokonuje na własny koszt.

7. Po przekazaniu przez Wykonawcę do ponownego Odbioru Etapu II, zastosowanie znajduje procedura opisana \powyżej, w tym terminy, aż do stwierdzenia przez Zamawiającego, że wszystkie zastrzeżenia zostały uwzględnione oraz usunięto błędy przedmiotu Odbioru.

Opis procedury wdrożenia Serwisu.

Po dokonaniu Odbioru Serwisu przez Zamawiającego, Wykonawca przeniesie Serwis wraz z opublikowanymi treściami na serwer produkcyjny. Serwer produkcyjny będzie umieszczony na tym samym hostingu, co serwer testowy. Wykonawca w ramach prac wdrożeniowych skonfiguruje środowisko produkcyjne, w tym zainstaluje niezbędne Oprogramowanie Standardowe oraz skonfiguruje serwer bazodanowy i serwer aplikacyjny – zainstaluje między innymi certyfikat SSL przekazany przez Zamawiającego oraz adresy domenowe. Efektem prac wdrożeniowych będzie prawidłowo funkcjonujący Serwis zainstalowany na dwóch działających instancjach, produkcyjnej i testowej. Wykonawca będzie odpowiedzialny za utrzymanie obu środowisk. Po zakończeniu prac wdrożeniowych Wykonawca przekaże Zamawiającemu wszelkie dane dostępowe potrzebne do prowadzenia i utrzymania Serwisu, w tym dane do kont administratorów dla serwera aplikacyjnego, bazodanowego, silnika bazy danych oraz narzędzia CMS. Odbiór prac wdrożeniowych nastąpi na podstawie weryfikacji poprawności działania Serwisu na środowisku produkcyjnym i testowym i będzie potwierdzony stosownym Protokołem Odbioru.

Oświadczenie o dostępności Serwisu.

Wykonawca w ramach Etapu II przedstawi Zamawiającemu oświadczenie o dostępności Serwisu poprzez rejestr zgodności z każdą wytyczną WCAG 2.1 wskazaną w załączniku do ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych.

Termin realizacji Etapu II.

Termin realizacji Etapu II - 90 dni kalendarzowych od dnia zawarcia Umowy.

Etap III: Wymagania na dokumentację techniczną oraz użytkownika.

W ramach Etapu III, Wykonawca zobowiązany jest dostarczyć kompletną dokumentację obejmującą:

1. Dokumentację techniczną:

1. Specyfikacja Scenariuszy Testowych (SST). Wymagania na SST zawiera pkt Specyfikacja Scenariuszy Testowych(SST). poniżej,

2. Dokumentację powdrożeniową. Wymagania na dokumentację powdrożeniową zawiera pkt 2.3.2.2. poniżej.

2. Dokumentację użytkownika:

1. Podręcznik administratora Serwisu. Wymagania na podręcznik administratora Serwisu zawiera pkt 2.3.2.3. poniżej,

2. Podręcznik redaktora Serwisu zgodnie z wymogami pkt 2.3.2.4 poniżej,

3. Podręcznik administratora merytorycznego Serwisu zgodnie z wymogami pkt 2.3.2.5 poniżej.

Minimalne wymagania dla poszczególnych dokumentów przedstawiono poniżej:

Specyfikacja Scenariuszy Testowych (SST)

Wymagania:

1. SST przedstawia strukturę działań związanych z testowaniem Xxxxxxx, tj. zestawów testów, scenariuszy testowych.

2. Dokument SST musi zawierać następującą strukturę:

1. rozdział zawierający listę scenariuszy testowych. Każdy scenariusz testowy musi być opisany za pomocą następujących atrybutów:

1. identyfikator scenariusza wraz listą przypadków testowych, które są testowane w ramach danego scenariusza testowego,

2. opis danego scenariusza testowego,

3. wykaz warunków, jakie muszą być spełnione przed rozpoczęciem wykonania scenariusza testowego, włącznie ze wskazaniem specyficznych danych wejściowych dla danego scenariusza,

4. wykaz warunków, jakie muszą być spełnione po wykonaniu scenariusza testowego, przykładowo xxxx Xxxxxxx, jaki musi zostać pozostawiony po wykonaniu scenariusza testowego,

5. kryteria określające pozytywny rezultat danego scenariusza testowego,

6. szczegółowy opis konfiguracji środowiska testowego.

Dokumentacja powdrożeniowa

Wymagania:

1. Wszystkie wymagania zawarte w dokumentacji powdrożeniowej muszą być zgodne ze specyfikacją wymagań określonych w OPZ i Etapie I.

2. Dokumentacja powdrożeniowa musi odzwierciedlać następującą strukturę:

   1. Rozdział opisujący przyjęty sposób dokumentowania architektury Serwisu – w szczególności objaśnienie wykorzystanych perspektyw wraz z charakterystyką ich zawartości.

   2. Rozdział opisujący warstwę wdrożenia obejmującą lokalizacje oraz instancje Serwisu.

   3. Rozdział zawierający opis Serwisu uzupełniony diagramami z perspektywy Infrastruktury:

1. zestawienie infrastruktury programowej i sprzętowej wykorzystywanej przez Xxxxxx. Zestawienie infrastruktury programowej obejmuje Oprogramowanie Standardowe (np. system operacyjny, serwery aplikacji, oprogramowanie integracyjne, oprogramowanie baz danych itp.). Zestawienie zostanie opisane przez tabelę zawierającą:

1. nazwę oprogramowania, typ, wersję, producenta,

2. liczbę i rodzaj wykorzystywanych licencji;

2. lokalizacje, których używa Serwis wraz z usługami infrastruktury związanymi z konkretną lokalizacją. Usługi infrastruktury powinny odpowiadać usługom, które zostały użyte podczas opisu Komponentów Serwisu. Dla każdej lokalizacji należy opracować odrębny diagram wdrożenia;

3. opis Środowiska Produkcyjnego, Testowego, Deweloperskiego wraz z ich powiązaniami z konkretnymi lokalizacjami;

2. charakterystykę połączeń (w tym sieciowych) pomiędzy poszczególnymi elementami infrastruktury oraz pomiędzy usługami świadczonymi przez podmioty zewnętrzne.

Podręcznik administratora Serwisu

Wymagania:

1. Dokumentacja musi posiadać historię zmian oraz odniesienie do wersji Serwisu, którego dotyczy.

2. Dokumentacja musi odzwierciedlać następującą strukturę:

1. rozdział zawierający wykaz ról pełnionych przez osoby w realizacji zadań eksploatacyjnych, wymagane kwalifikacje oraz ich obciążenie dzienne/miesięczne;

2. rozdział zawierający pełną listę instrukcji wraz z określeniem kompetencji zespołu odpowiedzialnego za wykonywanie i przestrzeganie danej instrukcji w zakresie administrowania Serwisem. Rozdział powinien zawierać wytyczne do planu eksploatacji Serwisu proponując np. harmonogram wykonywanych okresowo działań związanych z konkretną instrukcją. W szczególności dokumentacja musi zawierać opis zadań administratora Serwisu, w sposób umożliwiający Zamawiającemu ich realizację bez udziału Wykonawcy:

   1. instrukcje konfiguracji i administracji Serwisu,

   2. opisy komunikatów o błędach Serwisu (np. występujących w logach czy wyświetlanych na ekranie) wraz z procedurami rozwiązania takich sytuacji;

3. rozdział zawierający opis instrukcji obsługi wszystkich elementów Serwisu (uwzględniając mechanizmy bezpieczeństwa przetwarzania danych) niezbędnych dla eksploatacji i utrzymania. Opis powinien zawierać informacje nt. zachowania się w przypadku wystąpienia awarii i konieczności odtworzenia Serwisu. Instrukcje administracyjne muszą dotyczyć co najmniej:

   1. oprogramowania (wraz z obsługą danych),

   2. wymaganej konfiguracji infrastruktury programowo – sprzętowej;

4. rozdział specyfikujący zadania eksploatacyjne wraz z pełnym opisem. Opis działań musi umożliwić Zamawiającemu realizację bez udziału Wykonawcy:

1. zadań cyklicznych (np. termin wykonania testów regresji, składowania danych, itp.) opisanych jako:

• nazwa zadania,

• wykaz ról uczestniczących w realizacji zadania,

• termin, kiedy zadanie jest wykonywane,

• określenie momentu zakończenia zadania – np. poprzez określenie czasu trwania lub czasu zakończenia,

• czynności wykonywane w ramach zadania, z określeniem tzw. roli, która wykonuje daną czynność, wykorzystywanych komponentów oprogramowania,

2. zadań jednorazowych (np. restart Systemu) wraz z określeniem zasad wykonania danego zadania eksploatacyjnego;

5. rozdział zawierający pełną charakterystykę stanowiska pracy osób pełniących opisane wyżej zadania w procesie eksploatacji, w tym:

1. wymagany sprzęt stanowiska pracy, np. minimalna konfiguracja komputera dla stanowiska pracy,

2. wymagane oprogramowanie stanowiska pracy, np. system operacyjny, przeglądarka, oprogramowanie biurowe, etc.,

3. wymagane wsparcie telekomunikacyjne,

4. wymagane materiały eksploatacyjne,

5. wymagania charakteryzujące bezpieczne monitorowanie Serwisu, np. umiejscowienie stanowiska, prace w pomieszczeniu o ograniczonym dostępie;

6. Rozdział zawierający koncepcję planu ciągłości działania Serwisu, w tym szczegółowy opis procedury odtworzenia Serwisu po awarii (Disaster Recovery) dla każdego ze środowisk, w tym:

1. procedurę i instrukcję wykonania kopii bezpieczeństwa środowiska (całego serwera) i ich odtworzenia,

2. procedury i instrukcje wykonanie backupu Serwisu i odtworzenia danych z backupu,

3. procedury i instrukcje bieżącego monitoringu oraz utrzymania Serwisu,

4. procedury i instrukcje aktualizacji i wdrażania łat i aktualizacji Serwisu i Oprogramowania Standardowego,

5. procedury i instrukcje bieżącej analizy oraz archiwizowania zapisów zabezpieczeń (logów);

7. Każda procedura powinna zawierać co najmniej następujące dane:

1. nazwa,

2. opis,

3. częstotliwość wykonywania,

4. kroki do realizacji w procedurze,

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

Podręcznik redaktora Serwisu

Wymagania:

1. Podręcznik musi posiadać historię zmian.

2. Podręcznik musi zawierać zasady świadczenia wsparcia technicznego dla redaktorów Serwisu.

3. Podręcznik musi odzwierciedlać następującą strukturę:

1. rozdział zawierający informacje ogólne opisujące, do czego służy Serwis oraz CMS, zasady nawigacji pomiędzy poszczególnymi funkcjami Serwisu oraz generalne zasady współpracy z CMSem oraz zasady świadczenia wsparcia technicznego,

2. rozdział zawierający opis ról i ich uprawnień dla redaktorów Serwisu, opis funkcjonalności oraz interfejsu użytkownika, zasady walidacji pól formularzy.

4. Dokument musi być skonstruowany w sposób pozwalający redaktorom korzystać tylko na jego podstawie ze wszystkich funkcjonalności CMSa i Serwisu.

Podręcznik administratora merytorycznego

Wymagania:

1. Dokument musi posiadać historię zmian.

2. Dokument musi zawierać zasady świadczenia wsparcia technicznego dla tej grupy Użytkowników.

3. Dokument musi odzwierciedlać następującą strukturę:

1. rozdział zawierający informacje ogólne opisujące, do czego służy Serwis, zasady nawigacji pomiędzy poszczególnymi funkcjami Serwisu i CMSa oraz generalne zasady współpracy z CMSem oraz zasady świadczenia wsparcia technicznego,

2. rozdział zawierający:

1. listę ról i ich typów uprawnień, które obsługuje CMS. Lista powinna dotyczyć wszystkich klas Użytkowników,

2. zasady zarządzania kontami Użytkowników,

3. zasady zarządzania hasłami Użytkowników,

4. opis funkcjonalności oraz interfejsu użytkownika administratora merytorycznego.

4. Dokument musi być skonstruowany w sposób pozwalający administratorom merytorycznym korzystać tylko na jego podstawie ze wszystkich funkcjonalności CMSa i Serwisu.

Termin realizacji Etapu III.

Termin realizacji Etapu III - 120 dni kalendarzowych od dnia zawarcia Umowy.

Etap IV: Wymagania na warsztaty powdrożeniowe dla redaktorów Serwisu i pracowników IT (dalej jako „Warsztaty”).

Wykonawca w ramach wynagrodzenia za realizację Etapu I-IV zapewni dla 10 (dziesięciu) wskazanych przez Zamawiającego osób przeszkolenie w zakresie:

a) umożliwiającym samodzielną pracę redakcyjną w Serwisie;

b) pozwalającym na samodzielną administrację, utrzymanie i rozwój Serwisu, w tym administracji i konfiguracji zaoferowanego systemu bazodanowego, obsługę narzędzi administratora, architekturę systemu, zagadnienia związane z zachowaniem bezpieczeństwa, integralności i zabezpieczenia przed utratą danych, przywracaniem danych po awarii.

Wykonawca przeprowadzi odrębne Warsztaty dla niżej wymienionych grup uczestników Warsztatów (osoby wskazane przez Zamawiającego):

Lp.	Grupy uczestników warsztatu	Ilość osób
1.	redaktorzy Serwisu	max. 5 os.
2.	pracownicy IT	max. 5 os.

Przez pracowników IT, Zamawiający rozumie x.xx. administratorów systemu operacyjnego i administratorów baz danych. Zamawiający dopuszcza udział tych samych osób zarówno w warsztacie dla redaktorów jak i pracowników IT.

Wykonawca przeprowadzi dwa dwudniowe niezależne Warsztaty (osobno dla redaktorów i pracowników IT) każde po 16 godzin. Łączne przerwy w trakcie jednego dnia Warsztatu nie mogą być dłuższe niż 1 godzina 15 min. W każdym przypadku drugi dzień Warsztatu odbędzie się w odstępie uzgodnionym z Zamawiającym, jednak nie krótszym niż 7 dni kalendarzowych i nie dłuższym niż 14 dni kalendarzowych, tak, aby uczestnicy mieli możliwość praktycznego wykorzystania wiedzy zdobytej podczas pierwszego dnia i zweryfikowania, które obszary wymagają dodatkowych wyjaśnień, doprecyzowania lub utrwalenia bądź stwierdzenia i zgłoszenia Wykonawcy do poprawy tych obszarów, które zostały opisane w podręczniku w sposób niewystarczający do wykorzystania w samodzielnej pracy.

Pierwszy dzień Warsztatów ma na celu zapewnienie uczestnikom wiedzy niezbędnej do samodzielnej pracy redaktorskiej/administratora IT Serwisu.

Drugi dzień Warsztatów ma na celu wyjaśnienie zagadnień, które pojawiły się podczas praktycznego korzystania z Serwisu i wykonywania na nim prac redaktorskich/ administratora IT Serwisu.

Przed drugim dniem Warsztatów, Wykonawca ma obowiązek zebrania od uczestników oczekiwań co do zakresu drugiego dnia Warsztatu. Sposób spełnienia powyższego wymogu ustalą Strony nie później niż na 2 Dni Robocze przed rozpoczęciem Warsztatów.

Warsztaty będą obejmować część teoretyczną, praktyczną oraz case studies. Warsztaty muszą zostać przeprowadzone przy założeniu, że redaktorzy Zamawiającego nie posiadają wykształcenia informatycznego.

Warsztaty, o których mowa powyżej, odbędą się:

1. w Warszawie w siedzibie Zamawiającego lub innej lokalizacji w Warszawie uzgodnionej z Zamawiającym. Zamawiający nie pokrywa kosztów dojazdu, wyżywienia i zakwaterowania pracowników Wykonawcy. Zamawiający udostępni niezbędny sprzęt informatyczny uczestnikom warsztatów i pomieszczenia na potrzeby warsztatów, lub

2. w sposób zdalny (np. z wykorzystaniem platformy Teams).

Decyzję o sposobie prowadzenia Warsztatów w sposób zdalny podejmuje Zamawiający.

Wykonawca odpowiada za zorganizowanie Warsztatów oraz pokrywa wszelkie koszty związane z ich organizacją i przeprowadzeniem, w tym koszty platformy szkoleniowej.

Warsztaty odbędą się w godzinach pracy Zamawiającego tj. 8:00 – 16:00 w uzgodnionych wcześniej z Zamawiającym terminach, z zastrzeżeniem, iż wszystkie Warsztaty muszą się odbyć w terminie realizacji Etapu IV.

Warsztaty będą prowadzone przez co najmniej 1 trenera Wykonawcy posiadającego wiedzę i doświadczenie pozwalające na skuteczne przekazanie wiedzy w zakresie wskazanym powyżej.

Przed przystąpieniem do Warsztatów, Wykonawca określi niezbędny wymiar przeszkolenia dla poszczególnych grup uczestników. W terminie najpóźniej do 10 Dni Roboczych przed planowanym rozpoczęciem Warsztatów, Wykonawca przekaże Zamawiającemu do akceptacji szczegółowy zakres Warsztatów i materiały szkoleniowe, w tym podręcznik. Zamawiający w terminie 3 Dni Roboczych od przedłożenia materiałów, o których mowa w zdaniu poprzednim, zaakceptuje je albo wniesie do nich uwagi. Wykonawca jest zobowiązany do uwzględnienia uwag Zamawiającego w terminie do 2 Dni Roboczych.

Warsztaty muszą zostać przeprowadzone na środowisku testowym Serwisu. Wykonawca nada uczestnikom Warsztatów wszelkie niezbędne dostępy umożliwiające pełne uczestnictwo w Warsztatach i najpóźniej 2 Dni Robocze przed Warsztatami zweryfikuje, czy działają one prawidłowo.

Potwierdzeniem odbytego Warsztatu jest przekazanie Zamawiającemu przez Wykonawcę imiennej listy uczestników potwierdzonej ich własnoręcznym podpisem (w przypadku formy zdalnej – podpisem elektronicznym).

Wykonawca przeprowadzi Warsztaty w języku polskim, zapewniając na swój koszt materiały warsztatowe, w tym podręcznik dla uczestników Warsztatów.

W celu weryfikacji jakości przeprowadzonego Warsztatu Zamawiający zastrzega sobie możliwość przeprowadzenia ankiety wśród uczestników Warsztatu dotyczącej ocen jakości przeprowadzonego Warsztatu (ocena w skali 1-6, w przypadku, kiedy średnia ocen z danego Warsztatu będzie poniżej 3, Zamawiający ma prawo żądać powtórzenia Warsztatu na koszt Wykonawcy).

Każdy uczestnik warsztatu otrzyma, w formie papierowej i elektronicznej, materiały warsztatowe, w tym podręcznik wraz z przykładami oraz case studies. W przypadku prowadzenia Warsztatów w formie zdalnej, Wykonawca dostarczy materiały warsztatowe, o których mowa w zdaniu poprzednim, w formie elektronicznej na wskazany przez Zamawiającego adres poczty elektronicznej.

Stopień szczegółowości materiałów powinien obejmować każdą czynność jednostkową wykonaną przez uczestników w trakcie Warsztatu.

Zamawiający oczekuje, że program Warsztatów zagwarantuje użytkownikom zapoznanie się z wszystkimi funkcjonalnościami Serwisu oraz systemu CMS.

Wykonawca dostarczy na adres poczty elektronicznej wskazanej przez Zamawiającego, certyfikaty potwierdzające uczestnictwo w Warsztatach, odrębne dla każdego uczestnika.

Certyfikaty potwierdzające ukończenie w Warsztatach zawierać będą, co najmniej następujące informacje:

• daty przeprowadzenia Warsztatu,

• imię i nazwisko trenera/trenerów prowadzących Warsztat,

• wymiar Warsztatu (ilość godzin),

• szczegółowy zakres tematyczny Warsztatu,

• zakres przyswojonej wiedzy przez osobę uczestniczącą w Warsztacie (redaktor, pracownik IT).

W związku z tym, że zamówienie będzie finansowane ze środków unijnych z Programu Operacyjnego Wiedza Edukacja Rozwój na lata 2014-2020, każdy dokument oraz Serwis powinien zostać oznaczony zgodnie z wytycznymi Ministerstwa Funduszy i Polityki Regionalnej, zamieszczonymi na stronie internetowej xxxxx://xxx.xxxxxxxxxxxxxxxxxxx.xxx.xx/xxxxxx/x-xxxxxxxxxx/xxxxxxxxx/xxxxxxxxxx-xxxxxxxxxxxx-x-xxxxxxxxxxxx-xxxxxxxxx-xxxxxxxx-xxxxxxxxx-0000-0000-x-xxxxxxxx-xxxxxxxxxx-x-xxxxxxxx-xxx-xxxx-xxxxxxxxxxx-xx-0-xxxxxxxx-0000-x/ z późn. zm.

Zakończenie tego Etapu zostanie potwierdzone przez Zamawiającego przez podpisanie Protokołu Odbioru Etapu IV.

Termin realizacji Etapu IV.

Termin realizacji Etapu IV - 150 dni kalendarzowych od dnia zawarcia Umowy, z zastrzeżeniem, że Wykonawca nie może przystąpić do realizacji Etapu IV przed podpisaniem przez Zamawiającego bez zastrzeżeń Protokołu Odbioru Xxxxx XX.

Etap V: Usługi Utrzymania i Rozwoju Serwisu

1. Wykonawca przystąpi do realizacji Etapu V następnego dnia po podpisaniu przez Xxxxxxxxxxxxx bez zastrzeżeń Protokołu Odbioru Xxxxx XX.

2. Usługi Utrzymania i Rozwoju będą świadczone do dnia 30 września 2023 r. w zakresie wyszczególnionym odpowiednio w pkt ”Świadczenie Usługi Utrzymania Serwisu” i „Świadczenie Usługi Rozwoju Serwisu”. poniżej.

Świadczenie Usługi Utrzymania Serwisu

1. Wykonawca zobowiązany jest do świadczenia Usługi Utrzymania w sposób niepowodujący obniżenia parametrów wydajnościowych Serwisu i Oprogramowania.

2. Usługa Utrzymania świadczona jest we wszystkie Dni Robocze w godzinach od 8:00 – 17:00 przez cały okres obowiązywania Umowy z uwzględnieniem okna serwisowego w godzinach 22:00 – 8:00, za wyjątkiem Błędów Krytycznych.

3. W ramach Usługi Utrzymania Wykonawca zapewni wsparcie w postaci konsultacji telefonicznych i e-mailowych dotyczące działania Serwisu oraz Oprogramowania, w tym systemu CMS przez 8 godzin dziennie 5 Dni Roboczych w tygodniu (od poniedziałku do piątku) w godzinach 8:00 – 16:00 pod podanym w umowie numerem telefonu i adresem e-mail w średnim miesięcznym wymiarze minimum 8 Roboczogodzin tygodniowo, przy czym 1 e-mail traktowany jest jak 15 min. rozmowy.

[Zasady obsługi Zgłoszeń dotyczących Wad]

1. Czas Reakcji na otrzymane Zgłoszenie nie może być dłuższy niż 2 godziny zegarowe. Brak potwierdzenia we wskazanym czasie oznacza, iż zgłoszenie zostało przyjęte i po upływie 2 godzin zegarowych od momentu Zgłoszenia rozpoczyna się bieg terminu skutecznej naprawy. Kwalifikacja usterek w momencie Zgłoszenia leży w gestii Zamawiającego.

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

3. Jeżeli Wada została wykryta przez Wykonawcę, to Wykonawca niezwłocznie poinformuje mailowo upoważnione osoby wskazane w Umowie po stronie Zamawiającego o wystąpieniu Wady, nada Wadzie odpowiednią kategorię oraz przystąpi do działań zmierzających do usunięcia Wady, z tym zastrzeżeniem, że ostateczna decyzja odnośnie kategorii Wady należy do Zamawiającego.

4. Obsługa Błędów Krytycznych odbywa się w dni kalendarzowe, w godzinach zegarowych. Czas na usunięcie Błędu Krytycznego rozpoczyna się w momencie Zgłoszenia niezależnie od okna serwisowego, Wykonawca ma obowiązek przystąpienia do usuwania Błędu Krytycznego niezwłocznie po otrzymaniu Zgłoszenia.

5. Czas na usunięcie Błędu lub Usterki rozpoczyna się w momencie skutecznego Zgłoszenia, w przypadku, gdy skuteczne Zgłoszenie ma miejsce w Godzinach Roboczych. W przypadku skutecznego Zgłoszenia po godzinie 17:00 w Dniu Roboczym, czas na usunięcie Błędu lub Usterki liczy się od godziny 8:00 następnego Dnia Roboczego. W przypadku skutecznego zawiadomienia przed godziną 8:00 w Dniu Roboczym, czas na usunięcie Błędu lub Usterki liczy się od godziny 8:00 tego Dnia Roboczego.

6. Przy poprawianiu Wad Oprogramowania i Serwisu oraz Usterek i udzielania konsultacji Wykonawca zobowiązany jest zachować następujący poziom wykonania Usługi Utrzymania:

Wada	Czas Reakcji	Czas Naprawy
Błąd Krytyczny	2 godziny zegarowe	8 godzin zegarowych
Błąd	2 Godziny Robocze	24 Godziny Robocze
Usterka	2 Godziny Robocze	96 Godzin Roboczych

Nazwa Zgłoszenia	Czas Reakcji	Czas realizacji
Konsultacja	1 Godzina Robocza	3 Godziny Robocze

7. Usunięcie Wady nie może prowadzić do naruszenia struktur i integralności danych, do utraty danych lub wpływać negatywnie na funkcjonowanie Oprogramowania lub innych składników infrastruktury Zamawiającego. Wykonawca zobowiązuje się również do usunięcia Wad w sposób zapobiegający utracie jakichkolwiek danych. W przypadku, gdy wykonanie usługi wiąże się z ryzykiem utraty danych, Wykonawca zobowiązany jest poinformować o tym Zamawiającego przed przystąpieniem do usunięcia Wady.

8. Naprawę Wady zatwierdza upoważniona osoba wskazana w Umowie ze Strony Zamawiającego po zainstalowaniu przez Wykonawcę poprawek.

9. Jeżeli Naprawa Wady nie jest możliwa w czasie przewidzianym dla danej kategorii Wady, Strony dopuszczają możliwość zastosowania Obejścia, przy czym zastosowanie Obejścia nie wyłącza zobowiązania Wykonawcy do Naprawy Wady.

10. Jeżeli Wykonawca nie dokona Naprawy/Obejścia w terminach, o których mowa powyżej, Zamawiający może:

    1. Wydłużyć termin usunięcia Wady na pisemną prośbę Wykonawcy zawierającą uzasadnienie;

    2. Obciążyć Wykonawcę karą umowną na zasadach opisanych w Umowie.

11. Usługa Utrzymania będzie realizowana za pomocą Portalu Zgłoszeniowego Zamawiającego oraz, w przypadku jego niedostępności, drogą elektroniczną (e-mail), telefoniczną.

12. Odbiór realizacji usług w ramach Usługi Utrzymania będzie następował w cyklach miesięcznych i będzie potwierdzany protokołami za dany okres.

[Zasady zapewnienia kontroli i ciągłości działania Serwisu oraz okresowych przeglądów]

13. Wykonawca zapewni ciągłe funkcjonowanie Serwisu przez 24 godziny na dobę, 7 dni w tygodniu, 000/000 xxx w roku z wyjątkiem okien serwisowych, przy założeniu, że w jednym czasie z Serwisu korzysta 500 Użytkowników w ciągu jednego Dnia Roboczego, z ustalonym punktem przesilenia w godzinach 8:00 - 16:00 oraz założeniu utrzymania minimum 1 000 sesji jednocześnie.

14. Zamawiający dopuszcza 4 Godziny Robocze Niedostępności Serwisu w miesiącu, poza oknami serwisowymi.

15. Wykonawca będzie prowadził działania prewencyjne mające na celu wydłużenie czasu bezawaryjnej pracy Serwisu, w tym będzie wykonywał optymalizacje Serwisu oraz przeglądy nie rzadziej niż raz na kwartał, a także na żądanie Zamawiającego. Wyniki przeglądu – po optymalizacji powinny być przekazywane przez Wykonawcę do Zamawiającego w formie notatki do 15 dnia miesiąca po zakończonym kwartale.

16. W przypadku konieczności wykonania prac mających na celu optymalizację działania Serwisu, Wykonawca bezzwłocznie poinformuje Zamawiającego o zakresie prac, jaki jest z tym związany.

17. Wszelkie planowane przerwy w działaniu Serwisu związane z wykonywaniem optymalizacji oraz ingerencje mogące spowodować Niedostępność Serwisu muszą być uzgodnione z Zamawiającym.

[Zasady realizacji prac związanych z utrzymaniem, konserwacją, administracją i aktualizacją systemów operacyjnych oraz oprogramowania firm trzecich]

18. W ramach przedmiotu zamówienia Wykonawca będzie realizował prace związane z utrzymaniem, konserwacją, administracją i aktualizacją systemów operacyjnych oraz oprogramowania firm trzecich (w tym w szczególności silników baz danych), które wykorzystywane są do prawidłowego działania oprogramowania dziedzinowego podlegające usłudze utrzymania, a w szczególności będzie realizował prace związane z:

    1. Monitorowaniem prawidłowości działania w/w systemów oraz oprogramowania firm trzecich. W przypadku zidentyfikowania niedostatecznej ilości zasobów Wykonawca zwróci się do Zamawiającego z wnioskiem o przydzielenie dodatkowych zasobów wraz ze wskazaniem ilości oraz określeniem powodu powstania w/w zapotrzebowania. Jeśli wskazane zasoby będą dostępne, Zamawiający przydzieli zasoby w terminie nie dłuższym niż 10 dni roboczych od prawidłowo przedłożonego zapotrzebowania. Za prawidłowo złożone zapotrzebowanie Zamawiający rozumie przekazanie za pośrednictwem kanału komunikacyjnego wskazanego w Umowie informacji zawierających parametr podlegający zmianie oraz powód zmiany. O zakończeniu realizacji wniosku Zamawiający poinformuje Wykonawcę w sposób analogiczny do w/w. Po przydzieleniu przez Zamawiającego dodatkowych zasobów w celu ich skutecznego wykorzystania Wykonawca dokona czynności rekonfiguracyjnych po stronie systemu operacyjnego, oprogramowania firm trzecich lub samego oprogramowania dziedzinowego. W/w czynności realizowane przez Wykonawcę muszą zostać zrealizowane w terminie nie dłuższym niż 10 Dni Roboczych od momentu poinformowania Wykonawcy o dostępności dodatkowych zasobów.

    2. Uaktualnianiem systemu operacyjnego oraz oprogramowania firm trzecich do wersji aktualnie wspieranej. Przez uaktualnienie do wersji aktualnie wspieranych Zamawiający rozumie czynności związane z podniesieniem wersji systemu operacyjnego lub oprogramowania firm trzecich (w tym w szczególności silnika bazy danych) do wersji stabilnych posiadających aktualne wsparcie producenta tzn. posiadających możliwość pobierania i aktualizowania oprogramowania ze stron lub z repozytoriów udostępnianych przez producenta oraz wprowadzania wszystkich zalecanych przez producenta uaktualnień, w szczególności uaktualnień dotyczących zabezpieczeń.

    3. Administrowanie systemem operacyjnym oraz oprogramowaniem firm trzecich, w tym w szczególności dostosowywanie w/w oprogramowania w zakresie zapewniania oczekiwanego poziomu optymalizacji działania Oprogramowania, administrowania lokalnymi użytkownikami systemów operacyjnych, przydzielanie lokalnych zasobów koniecznych do prawidłowego działania Oprogramowania.

    4. Okresowego analizowania oraz przygotowania wytycznych w zakresie możliwości rozwojowych, realizacji zmian technologicznych mających na celu optymalizację pracy Oprogramowania z jednoznacznym wskazaniem możliwości migracji do wskazanych przez Zamawiającego rozwiązań w tym w szczególności opis czynności do wykonania, przewidywaną pracochłonność oraz potencjalne występujące ryzyka.

19. W ramach przedmiotu zamówienia Wykonawca będzie uczestniczył w procesach związanych z obsługą kopii bezpieczeństwa. Do czynności leżących po stronie Wykonawcy należało będzie w szczególności:

    1. Określenie wszystkich parametrów konfiguracyjnych polityk archiwizacji danych oprogramowania objętego Usługą Utrzymania ATiK umożliwiających odtworzenie danych i uruchomienie wszystkich komponentów Oprogramowania. Dostarczone parametry konfiguracyjne muszą uwzględniać minimalizację parametrów RPO (Recovery Point Objective) oraz RTO (Recovery Time Objective). Na podstawie uzyskanych informacji Zamawiający przygotuje nowe lub zmodyfikuje istniejące zadania archiwizacyjne, a Wykonawca zweryfikuje i potwierdzi poprawność ich konfiguracji oraz działania. W/w określenie parametrów nastąpi nie później niż w ciągu 21 dni od momentu zawarcia Umowy.

    2. Okresowe analizowanie i weryfikowanie prawidłowości działania wszystkich zadań archiwizacyjnych. Czynności te winny być prowadzone nie rzadziej niż raz na trzy miesiące lub po każdej zmianie/modyfikacji konfiguracji polityk archiwizacji danych. Na wniosek oraz w porozumieniu z Wykonawcą Zamawiający wskaże termin przeprowadzenia w/w prac. Nie może być on jednak dłuższy niż 21 dni od zgłoszenia przez Wykonawcę gotowości do dokonania w/w czynności. Każda weryfikacja musi zostać potwierdzona obustronnie zawartym protokołem odbioru bez uwag. Zamawiający w terminie 5 Dni Xxxxxxxxx od otrzymania protokołu zaakceptuje go lub zgłosi Uwagi. W terminie do 14 dni kalendarzowych Wykonawca zobligowany jest do usunięcia przyczyn powstania uwag wskazanych w Protokole Odbioru. Po usunięciu przyczyn powstania uwag proces odbioru zostanie powtórzony. Zamawiający dopuszcza dwukrotne powtórzenie czynności odbiorowych.

    3. Stworzenie dokumentacji zawierającej co najmniej opis zadań archiwizacji danych, procedury odzyskiwania systemu w przypadku awarii oraz scenariusze “Disaster recovery”.

    4. Okresowe przeprowadzanie testów procedur odzyskiwania Serwisu w tym testów scenariuszy “Disaster recovery”. Czynności te winny być prowadzone nie rzadziej niż raz na sześć miesięcy lub po każdej zmianie/modyfikacji konfiguracji polityk archiwizacji danych. Na wniosek oraz w porozumieniu z Wykonawcą Zamawiający wskaże termin przeprowadzenia w/w prac. Nie może być on jednak dłuższy niż 21 dni od zgłoszenia przez Wykonawcę gotowości do dokonania w/w czynności. Każda weryfikacja musi zostać potwierdzona obustronnie zawartym protokołem odbioru bez uwag. Zamawiający w terminie do 5 Dni Roboczych od otrzymania protokołu zaakceptuje go lub zgłosi Uwagi. W terminie do 14 dni kalendarzowych Wykonawca zobligowany jest do usunięcia przyczyn powstania uwag wskazanych w protokole odbioru. Po usunięciu przyczyn powstania uwag proces odbioru zostanie powtórzony. Zamawiający dopuszcza dwukrotne powtórzenie czynności odbiorowych.

[Zasady aktualizacji Oprogramowania]

20. Wykonawca będzie niezwłocznie informował Xxxxxxxxxxxxx o ukazaniu się nowych, stabilnych wersji Oprogramowania.

21. Wykonawca dokona aktualizacji systemu zarządzania treścią, do nowych stabilnych wersji, na życzenie Zamawiającego. Termin aktualizacji oprogramowania do nowszych wersji nie będzie przekraczał 7 Dni Roboczych od momentu zgłoszenia takiej usługi przez Zamawiającego.

22. Wykonawca nie odpowiada za nieprawidłowe działanie serwera Zamawiającego nie wynikające z działania systemu i nienależytego jego administrowania.

23. Jeśli aktualizacja Serwisu zmienia sposób postępowania przy obsłudze Serwisu przez użytkowników, Wykonawca dokona aktualizacji Dokumentacji.

[Postanowienia dodatkowe]

24. Na zakończenie każdego kwartału oraz w dniu zakończenia Umowy Wykonawca dostarczy Zamawiającemu w formie elektronicznej zaktualizowaną wersję Kodów Źródłowych Oprogramowania oraz wersję Dokumentacji aktualizującą jej części lub całość. Zmiany wprowadzane przez Wykonawcę do Dokumentacji będą oznaczone wyraźnie oraz w sposób umożliwiający Zamawiającemu ich zidentyfikowanie oraz wyszukanie w tekście, w szczególności poprzez zastosowanie trybu śledzenia zmian. Wykonawca będzie aktualizował Dokumentację oraz Kody Źródłowe w ramach wynagrodzenia, o którym mowa w Umowie, oraz w sposób umożliwiający weryfikację przez Zamawiającego wprowadzonych zmian.

25. Wykonawca ma obowiązek usuwania błędów i luk w serwisach, w oparciu o przedstawione przez Zamawiającego wyniki audytu pod kątem bezpieczeństwa teleinformatycznego w ramach usługi utrzymania przez cały okres trwania Umowy.

26. Wykonawca ma obowiązek usuwania błędów w oparciu o przedstawione przez Zamawiającego wyniki audytu pod kątem zgodności usług udostępnionych w Internecie z załącznikiem nr 4 do ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz. U. 2019 poz. 848 z późn. zm.) w zakresie dostępności dla osób niepełnosprawnych określonych przez standard Web Content Accessibility Guidelines 2.1 (WCAG) lub innych aktów prawnych obowiązujących na terenie Rzeczypospolitej Polskiej dotyczącej dostępności dla osób niepełnosprawnych systemów informatycznych, w tym serwisów internetowych, podmiotów wykonujących zadania publiczne w ramach usługi utrzymania Oprogramowania.

27. Wykonawca ma obowiązek wspierania Zamawiającego w publikowaniu treści z zachowaniem zasad WCAG 2.1, w szczególności każdorazowo weryfikuje i koryguje zamieszczone publikacje w czasie 8 Godzin Roboczych od zgłoszenia takiej potrzeby przez Zamawiającego.

Świadczenie Usługi Rozwoju Serwisu.

1. Do czasu wykorzystania limitu Roboczogodzin, o którym mowa w Umowie, Zamawiający ma prawo składać Wykonawcy wnioski i Zamówienia na Usługi Rozwoju Serwisu, a Wykonawca zobowiązany jest do ich realizacji.

2. Usługi Rozwoju mogą być zgłaszane w miarę potrzeb.

3. Zamawiający nie jest zobowiązany do wykorzystania w całości limitu Roboczogodzin oraz zastrzega sobie prawo wykorzystania dostępnych Roboczogodzin w dowolnym momencie trwania Umowy.

4. Tryb realizacji zmian może być równoległy, przy czym zakłada się, iż Wykonawca nie będzie realizował jednocześnie więcej niż 5 Zamówień.

[Sposób realizacji Usługi Rozwoju Serwisu]

5. Wsparcie bieżącej obsługi Serwisu obejmuje:

   1. prace powdrożeniowe - dodawanie nowych publikacji, dodawanie nowych funkcjonalności, modyfikacje istniejącej funkcjonalności Serwisu;

   2. przygotowywanie materiałów multimedialnych - grafiki ilustracyjne i banery wzbogacające zawartość Serwisu, prezentacje multimedialne, inne;

   3. wsparcie marketingowe - analizę danych statystycznych korzystania z Serwisu, konsulting związany ze sposobami i zakresem promocji Serwisu, tworzenie skutecznych newsletterów, inne.

6. Do momentu wykorzystania limitu Roboczogodzin, o którym mowa w Umowie, Zamawiający ma prawo składać Wykonawcy Zamówienia, a Wykonawca zobowiązany jest do ich realizacji.

7. Wykonawca nie może odmówić realizacji Zamówienia, poza przypadkami, gdy realizacja usługi spowoduje przekroczenie limitu Roboczogodzin.

8. W przypadku, gdy realizacja usługi spowoduje pojawienie się Wady Serwisu, Wykonawca zobowiązany jest do wstrzymania prac nad usługą, do czasu skutecznego usunięcia Wady.

9. Dokonywanie Zleceń i Zamówień dokonywane jest przez upoważnionych pracowników Zamawiającego wskazanych w Umowie.

10. Procedura realizacji zadań wsparcia bieżącej obsługi Serwisu składa się z faz:

Faza I – wycena,

Faza II - realizacja.

11. Faza I inicjowana jest przez Zamawiającego poprzez wysłanie Zlecenia do Wykonawcy przy pomocy poczty elektronicznej i za pomocą Portalu Serwisowego Zamawiającego (Jira: adres Xxxx.xxxxx.xxx.xx).

12. Zlecenie musi zawierać opis Zamówienia oraz proponowany termin realizacji Zadania.

13. W przypadku wątpliwości co do zakresu planowanych prac, Strony dokonują ustaleń w trybie roboczym.

14. Wycena, o której mowa w pkt 11, musi zawierać szacunkową liczbę Roboczogodzin niezbędną do realizacji Zadania oraz termin realizacji Zadania.

15. Zamawiający zobowiązany jest do przekazania Wykonawcy informacji o akceptacji lub odrzuceniu przedstawionego przez Wykonawcę wyniku Xxxx X.

16. Zamawiającemu przysługuje prawo weryfikacji i akceptacji sposobu oraz czasochłonności wykonania przez Wykonawcę usług, który został przedstawiony przez Wykonawcę, w tym prowadzenia w tej sprawie ewentualnych negocjacji z Wykonawcą.

17. Zamawiający ma prawo zrezygnować z realizacji Fazy II. Realizacja Fazy I nie powoduje skutków finansowych dla Zamawiającego.

18. Xxxx XX – realizacja inicjowana jest przez Zamawiającego po akceptacji Xxxx X.

19. Wykonawca przystępuje do realizacji usługi po otrzymaniu od Zamawiającego Zamówienia Xxxx XX.

20. Zakończenie realizacji Zadania potwierdzane jest przy pomocy poczty elektronicznej przez upoważnionego Pracownika Zamawiającego wskazanego w Umowie.

21. Zakończenie Zadania oznacza możliwość ujęcia Zadania w Protokole Odbioru wsparcia bieżącej obsługi Platformy oraz szkolenia, którego wzór zawiera Załącznika nr 2 do Umowy.

22. Warunkiem koniecznym do zaakceptowania przez Zamawiającego Protokołu Odbioru Zamówienia jest dostarczenie przez Wykonawcę zaktualizowanej kompletnej Dokumentacji oraz zaktualizowanej wersji Kodów Źródłowych Oprogramowania.

23. Odbiór odbywa się po zrealizowaniu usług na podstawie zaakceptowanego Protokołu Odbioru bez zastrzeżeń.

24. Zamknięcie Zamówienia w Portalu Serwisowym dokonywane jest przez upoważnione osoby wskazane przez Zamawiającego w Umowie, po podpisaniu Protokołu Odbioru bez zastrzeżeń.

25. Zaakceptowanie przez Zamawiającego Protokołu Odbioru Zamówienia bez zastrzeżeń jest podstawą do wystawienia przez Wykonawcę faktury.

26. Z datą potwierdzenia Protokołem Odbioru bez zastrzeżeń wykonania prac, Wykonawca obejmuje Produkty Usługą Utrzymania, o której mowa w punkcie „Świadczenie Usługi Utrzymania Serwisu” w ramach wynagrodzenia przysługującego z tytułu realizacji Umowy oraz przenosi lub potwierdza fakt wcześniejszego przeniesienia na Zamawiającego autorskich prawa majątkowe oraz zależnych praw do Produktu.

27. Protokół Odbioru zawierać będzie informację o liczbie Roboczogodzin, w ramach których Produkty zostały wykonane.

28. Podstawą do ustalenia wysokości wynagrodzenia z tytułu Usług Rozwoju Serwisu objętych danym Zamówieniem będzie liczba Roboczogodzin wskazana w Protokole Odbioru oraz stawka za Roboczogodzinę.

[Postanowienia dodatkowe]

29. Wszystkie wprowadzane zmiany wprowadzane do Serwisu muszą być zgodne z zasadami wynikającymi z załącznika do Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848 z xxxx.xx).

4.Wymagania dla System Zarządzania treścią (CMS), opis dodatkowych modułów i funkcjonalności CMS oraz Serwisu

Panel administracyjny

CMS musi być wyposażony w panel administracyjny dostępny dla administratorów i redaktorów serwisu, zawierający wszystkie funkcje administracyjne i redakcyjne CMS.

Funkcje administracyjne

Administrator merytoryczny musi posiadać pełne uprawnienia do wszelkich kategorii administracyjnych w CMS, w tym x.xx. do:

1. zarządzania profilami uprawnień (rolami),

2. zarządzania kontami użytkowników CMS, w tym: dodawania, usuwania, modyfikacji, nadawania uprawnień do określonych czynności w serwisie, jak tworzenie treści, edycja, usuwanie, publikowanie,

3. tworzenia grup użytkowników i nadawania uprawnień grupom,

4. 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). Wykonawca ustawi wymaganie początkowe - hasło musi zawierać: minimum 8 znaków, przynajmniej jedna małą literę, przynajmniej jedną dużą literę, przynajmniej jeden znak specjalny,

5. definiowania zakresu dostępu do danych i plików gromadzonych w systemie,

6. CMS musi umożliwiać nadawanie uprawnień redaktorom do określonych kategorii serwisu oraz jego poszczególnych części (działów). Uprawnienia muszą być dziedziczone kaskadowo,

7. CMS musi posiadać moduł autoryzacji użytkowników przy pomocy loginu i hasła oraz na tej podstawie identyfikować oraz określać zakres uprawnień użytkownika,

8. Dostęp do profili administracyjnych oraz logowania dla użytkowników musi zapewniać:

1. indywidualnie zdefiniowanie loginu i hasła dla użytkownika,

2. przechowywanie haseł dostępowych w sposób uniemożliwiający ich przedstawienie w formacie jawnego tekstu,

3. hasło dostępowe musi składać się z co najmniej 8 znaków oraz zawierać duże i małe litery, cyfry i znaki specjalne. Wykonawca włączy to wymaganie dla CMS zaraz po jego instalacji,

9. CMS musi weryfikować złożoność hasła,

10. CMS musi umożliwiać delegowanie uprawnień administracyjnych do wybranych fragmentów serwisu dla wskazanego użytkownika lub grupy użytkowników,

11. CMS będzie posiadał możliwość generowania statystyk pracy poszczególnych redaktorów stosując zadane kryteria (redaktor, przedział czasowy, dział serwisu, inne zaproponowane przez Wykonawcę).

12. Logowanie poprzez komponent SSO.

13. CMS musi mieć możliwość integracji z komponentami SSO wykorzystywanymi przez Zamawiającego, na przykład Keycloak.

14. CMS musi obsługiwać minimum jeden z protokołów komunikacji OpenAuth 2.0, OpenID, SAML 2.0.

15. Logowanie użytkowników do CMS powinno być możliwe zarówno przez komponent SSO jak również bezpośrednio przez mechanizmy wbudowane w CMS, przy czym dany użytkownik może logować się korzystając wyłącznie z jednego mechanizmu.

Historia operacji

1. CMS musi zapisywać i udostępniać historię wszystkich operacji włącznie z logowaniem.

2. Historia musi być dostępna dla administratora i pozwalać na wyszukiwanie oraz filtrowanie co najmniej takich atrybutów jak: data i czas operacji z dokładnością do minuty, nazwa użytkownika, rodzaj operacji, miejsce wykonania operacji lub nazwa pliku, na którym wykonano operację.

3. CMS musi zapisywać w dzienniku systemowym historię operacji wykonywanych automatycznie przez system, np. kopii bezpieczeństwa, wysyłki newsletterów i powiadomień.

4. CMS musi raportować błędy w działaniu systemu CMS, w tym także kody błędów HTTP (np. 404) wygenerowane przez system CMS.

Wersjonowanie (cofanie zmian)

Redaktor będzie miał możliwość cofania zmian wprowadzonych i zapisanych w edytowanych przez siebie materiałach.

Administrator merytoryczny musi mieć możliwość cofania zmian wykonanych przez innych redaktorów.

Najczęściej zadawane pytania – FAQ

CMS musi posiadać funkcjonalność umożliwiającą tworzenie bazy pytań i odpowiedzi na nie wraz z formularzem umożliwiającym zadawanie pytań oraz możliwością ich sortowania, filtrowania i wyszukiwania wg słów kluczowych.

Użytkownik zadający pytanie musi otrzymać e-mail z informacją o pojawieniu się odpowiedzi na zadane pytanie.

Optymalizacja dla wyszukiwarek

CMS musi posiadać możliwość optymalizacji każdej strony serwisu 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> i adresu URL strony.

CMS musi umożliwiać indywidualne wypełnianie atrybutów „Alt” grafik używanych w serwisie.

Obsługa błędów

CMS musi posiadać mechanizm obsługi błędów poprzez możliwość dostosowania stron błędów (np. 404) dla każdego z bloków tematycznych w ramach Serwisu.

CMS musi generować prawidłowe kody błędów http (prawidłowo rozpoznawane przez wyszukiwarki internetowe) dla nieistniejących, przeniesionych lub ukrytych elementów serwisu (plików, kategorii, artykułów).

Technologia budowy interfejsu

Wszystkie strony serwisów muszą być co najmniej zgodne ze standardem HTML 5 i CSS 3.

Wymagana jest prawidłowa walidacja tworzonego przez CMS kodu HTML i CSS za pomocą udostępnionego na stronach W3C walidatora xxxxx://xxxxxxxxx.x0.xxx/xx/

System oraz udostępniane za jego pomocą serwisy muszą być oparte na stylach CSS do formatowania prezentowanych treści, a struktura dokumentu musi zapewniać poprawność semantyczną oraz oddzielenie wyglądu od treści.

Dostępność w przeglądarkach internetowych

Serwis i CMS muszą poprawnie realizować założone funkcjonalności co najmniej w następujących przeglądarkach: Firefox 90.x i wyższe, Chrome 85.x i wyższe, Edge 82.x i wyższe, Opera 70.x i wyższe, Safari 12.x i wyższe. Jeśli wykorzystywany będzie kod JavaScript, on także musi prawidłowo działać w wymienionych wyżej przeglądarkach.

Poczta e-mail

CMS musi współpracować z serwerem poczty elektronicznej obsługującym konta w domenie wskazanej przez Zamawiającego, w której będzie działać serwis.

Na potrzeby realizacji zadania, Zamawiający udostępni serwer poczty elektronicznej oraz założy konta i aliasy umożliwiające x.xx. rozsyłanie newsletterów, powiadomień oraz wiadomości e-mail.

Zatwierdzanie i publikacja treści artykułów

CMS musi zapewniać możliwość ustawienia przez administratora opcji wymagania lub niewymagania akceptacji nowych artykułów w ramach wybranych kategorii tematycznych.

Administrator musi mieć możliwość ustawienia opcji wymagania lub niewymagania zatwierdzenia treści artykułów redagowanych przez określonych użytkowników CMS.

CMS musi umożliwiać określenie dla poszczególnych kategorii tematycznych administratorów lub redaktorów zatwierdzających treści przed ich publikacją.

CMS musi zapewniać możliwość edycji artykułu przez użytkownika uprawnionego do zatwierdzenia treści artykułu.

Załączanie plików do pobrania

Dla każdego artykułu będzie możliwe zdefiniowanie listy plików do pobrania, znajdujących się w repozytorium CMS. Z poziomu repozytorium musi istnieć możliwość dodania nowego pliku w celu dołączenia do artykułu.

Pliki do pobrania

Muszą być prezentowane w postaci ikon charakterystycznych dla danego formatu (ikony będą posiadały treść (np. pdf) i będą częścią linku), odnośnika, definiowalnej przyjaznej nazwy odnośnika, formatu pliku oraz wielkości podanej w kB (kilobajtach) lub MB (megabajtach).

Zawartość artykułu

Artykuł musi posiadać co najmniej następujące elementy:

1. Tytuł artykułu (wypełnienie wymagane),

2. Część nagłówkowa zawierająca początek artykułu lub jego skrót z możliwością wstawienia elementu graficznego (wypełnienie opcjonalne) oraz datę publikacji i datę modyfikacji artykułu (wypełnienie wymagane, wyświetlanie opcjonalne),

3. Część główna artykułu posiadająca możliwość wstawienia treści oraz materiałów multimedialnych (audio, wideo, grafika, itp.) oraz stronicowania artykułu (wypełnienie wymagane, stronicowanie opcjonalne),

4. Stopka artykułu zawierająca co najmniej informacje takie jak: imię i nazwisko autora, nazwa jednostki organizacyjnej (wypełnienie wymagane, wyświetlanie opcjonalne),,

5. Kategorie, w których powinien zostać opublikowany artykuł (wypełnienie wymagane)

6. Możliwość wskazania więcej niż jednej kategorii, o której mowa w punkcie powyżej,

7. Słowa kluczowe artykułu (wypełnienie wymagane),

8. Przyjazny link (adres URL) do artykułu tworzony automatycznie na podstawie tytułu z możliwością modyfikacji (wypełnienie wymagane),

9. Informacja w RSS i/lub powiadomieniach o nowościach: Tak/Nie – domyślnie „Tak” (wypełnienie wymagane),

10. Odtwarzacz multimedialny (zgodny z wymaganiami WCAG 2.1),

11. Sekcje oparte na zasadzie pokaż / ukryj (dobra praktyka projektowania tego typu funkcjonalności znajduje się na stronie W3C xxxxx://xxx.x0.xxx/XX/xxx-xxxx-xxxxxxxxx-0.0/#xxxxxxxxx).

Edycja treści

CMS musi posiadać pracujący w trybie on-line edytor 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 oraz wklejania tekstów z zachowaniem formatowania przyjętego w edytorze tekstu.

Edytor musi posiadać co najmniej takie funkcje jak:

1. Pole format zawierające predefiniowane elementy strukturalne treści (P, X0, X0, X0, X0),

2. Xxxx styl – zawierające predefiniowane style CSS,

3. Możliwość wyboru czcionki i jej rozmiaru oraz predefiniowania domyślnej zgodnie z rekomendacjami. Opcje: Wytnij, Kopiuj, Wklej, Wklej jako czysty tekst, Wklej z Worda,

4. Opcje: Znajdź, Zamień, Zaznacz wszystko, Usuń formatowanie,

5. Opcje: Pogrubienie, Kursywa, Podkreślenie, Przekreślenie, Indeks dolny, Indeks górny,

6. Opcje: Wstaw/Usuń numerowanie listy, Wstaw/Usuń wypunktowanie listy,

7. Opcje: Zmniejsz/Zwiększ wcięcie, Wyrównaj do lewej, środka, prawej,

8. Opcje: Wstaw/Edytuj/Usuń załącznik, grafikę, hiperłącze, kotwicę,

9. Opcje: embedowanie treści z serwisu YouTube oraz mapy google,

10. Opcje: Wstaw/Edytuj tabelę,

11. Opcje: Zmień kolor czcionki, Zmień kolor tła,

12. Opcje: Pokaż/Edytuj kod źródłowy,

13. Podgląd strony,

14. Podział strony (stronicowanie),

15. Mechanizm tworzenia/oznaczania w tekście fraz, które dostaną wyjaśnienia w formie dymka (np. wyjaśnienia używanych skrótowców),

16. Mechanizm wstawiania linków w treści artykułu do plików znajdujących się w repozytorium lub załączonych do artykułu z automatycznym wstawianiem danych załącznika (typ pliku, rozmiar),

17. Ustawianie języka dla wybranego fragmentu,

18. Tworzenie treści w znaczniku <abbr>,

19. Tworzenie listy definicji / opisu,

20. Ustawianie odrębnej treści dla podpisu, alt i title zdjęcia,

21. Budowanie wielokrotnie zagnieżdżonych list uporządkowanych z możliwością zdefiniowania różnych form numeracji dla każdego poziomu.

Kod wstawiany przez edytor musi być zgodny minimum ze standardami HTML 5 i CSS 3.

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

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

Edytowany artykuł będzie mógł być wzbogacony przez pliki pobierane z repozytorium. Łącza do plików powinny być automatycznie uzupełniane o dodatkowe dane zgodnie z wzorcem: tekst przykładowego łącza do pliku (format pliku, rozmiar pliku).

Elementy graficzne dołączane do tekstów muszą mieć możliwość skalowania do dowolnych rozmiarów (z możliwością skalowania proporcjonalnego), wstawiania tekstu „Alt”, definiowania miejsca położenia, wielkości, sposobu wyrównania tekstu i otwarcia w nowym oknie lub w technice „overlay” (przed tekstem).

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

Tworzenie menu nawigacyjnego

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 sposobu wyświetlania.

Tytuł strony automatycznie staje się częścią odnośnika do tej strony i musi mieć możliwość zmiany nazwy strony bez równoczesnej zmiany tytułu strony. Tak przygotowany odnośnik musi automatycznie po opublikowaniu strony pojawić się w mapie serwisu.

Redaktor musi mieć możliwość indywidulanego definiowania zawartości atrybutu metatag Title, niezależnie od tytułu redakcyjnego.

CMS musi zawierać ścieżkę nawigacyjną tak, aby Użytkownik w każdym momencie wiedział, w jakim miejscu w strukturze serwisu się znajduje i miał możliwość powrotu do wyższych poziomów struktury serwisu.

CMS musi posiadać mechanizm „śledzenia” linków wewnętrznych (eliminowanie powstawania błędnych linków wewnętrznych np. w wyniku zmian w strukturze działów).

CMS musi posiadać funkcjonalność pozwalającą na tworzenie archiwów dla wybranych działów i jego intuicyjne przeglądanie przez Użytkownika witryny.

Mapa serwisu

System musi automatycznie generować aktualną mapę serwisu umożliwiającą określenie poziomu zagłębienia w hierarchię kategorii i artykułów.

Zarządzanie URL-ami

System musi generować tzw. „czyste” adresy URL, adres powinien zawierać informacje o kategorii/dziale strony i możliwą do zidentyfikowania indywidualną nazwę strony domyślnie generowaną na podstawie tytułu artykułu.

Statystyki odwiedzin

System musi umożliwiać wykorzystanie zewnętrznych narzędzi do tworzenia statystyk, np. Google Analytics.

System musi odfiltrowywać odwiedziny generowane przez roboty wyszukiwarek internetowych.

Wyszukiwanie informacji

System musi posiadać mechanizm wyszukiwania pełnotekstowego.

Bezpośrednio dostępne musi być wyszukiwanie proste poprzez pole tekstowe widoczne na stronie głównej serwisu oraz domyślnie we wszystkich działach i stronach. Musi ono umożliwiać szybkie wyszukanie w całym serwisie po wybranym słowie lub kilku słowach domyślnie połączonych spójnikiem „i”.

CMS musi udostępniać mechanizm wyszukiwania zaawansowanego umożliwiającego:

1. Szukanie dowolnego słowa,

2. Szukanie wszystkich słów,

3. Szukanie dokładnego wyrażenia,

4. Szukanie wg zakresów i dat,

5. Szukanie we wskazanej kategorii.

Wyniki wyszukiwania wyświetlane będą wg trafności wyszukiwania.

Administrator serwisu musi mieć możliwość zdefiniowana działów, które będą traktowana priorytetowo do wyników wyszukiwania.

Dla wyszukanych artykułów podana zostanie co najmniej: ilość znalezionych lub brak znalezionych, kategoria, tytuły i data publikacji.

Wyniki wyszukiwań muszą umożliwiać zliczanie przez zewnętrzne systemy rejestrowania statystyk serwisu, np. przez Google Analytics.

Moduł Slider

Moduł Slider – możliwość ręcznego sortowania pozycji. Różne źródła zaciągania zawartości i odsyłaczy (Aktualności, wybrane artykuły, inne dowolne tworzone ręcznie). Prezentacja slajdów będzie odbywała się automatycznie. Administrator będzie mógł ustawić interwał ich przełączania. Użytkownik Serwisu będzie mógł zatrzymać i wznowić animację przełączania slajdów poprzez przycisk „zatrzymaj/wznów”.

Tworzenie formularzy

CMS musi umożliwiać:

1. tworzenie formularzy i pozwalać na ich umieszczenie w dowolnych miejscach serwisu,

2. przekierowywanie wprowadzanych odpowiedzi do bazy danych oraz na wskazane konta e-mail w treści wiadomości w postaci tekstu,

3. zabezpieczenia formularza za pomocą „Captcha” w wersji logicznej (matematycznej). Niedopuszczalne jest rozwiązanie dotyczące weryfikacji kodu ukrytego w obrazku.

Wymagane typy pól, które muszą być dostępne w formularzach:

1. pole dot. wyrażenia zgody na przetwarzanie danych osobowych,

2. pole tekstowe jednolinijkowe i wielolinijkowe z możliwością określenia długości oraz zestawu dostępnych do wprowadzenia znaków,

3. pole wyboru typu „checkbox”,

4. pole wyboru typu „radio button”,

5. pole typu lista wyboru rozwijana,

6. pole typu lista wyboru wyświetlana w całości z możliwością wyboru wielu pozycji,

7. pole typu data z koniecznością walidacji daty pod względem formatu i poprawności,

8. przyciski „Wyślij formularz”, „Drukuj formularz”.

CMS musi:

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

2. umożliwiać dowolną zmianę układu i rozmieszczenia pól formularza na stronie,

3. umożliwiać oznaczenie pola jako wymagalnego i weryfikować jego wypełnienie,

4. posiadać możliwość walidacji pól typu: NIP, REGON, PESEL,

5. posiadać możliwość przypisania do każdego pola wartości domyślnej.

Po wypełnieniu formularza system musi posiadać możliwość wyświetlenia wprowadzonych danych w celu ich weryfikacji, ponownej edycji lub wysłania.

CMS musi posiadać możliwość opcjonalnego wysłania na podany adres e-mail potwierdzenia jego wypełnienia.

Moduł musi posiadać możliwość zapisywania rekordów formularzy do bazy oraz ich oraz publikacji na stronie www a także możliwość wysyłki zawartości formularzy na adres e-mail.

Warianty graficzne

System powinien pozwalać na definiowanie własnych nagłówków strony (dodawanie własnych elementów graficznych (motywy świąteczne, narodowe, inne).

Szablony i wygląd serwisu

Wygląd serwisu (grafika, rozkład treści, typografia, itp.) musi być zdefiniowany w oparciu o system szablonów.

System musi umożliwiać definiowanie indywidualnych szablonów dla poszczególnych kategorii serwisu, dla poszczególnych artykułów, list artykułów i bloków funkcjonalnych przy zachowaniu ogólnie przyjętego stylu dla całości serwisu.

Definiowanie szablonów musi być dostępne dla Administratora systemu. System 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. Administrator musi mieć możliwość zmiany sposobu prezentacji wszystkich elementów widocznych na stronach internetowych dostępnych dla gości serwisu.

System musi umożliwiać wyłączanie poszczególnych bloków funkcjonalnych (np. wyszukiwarka) zdefiniowanych w ramach szablonu tak, aby nie były one pokazywane w wybranych kategoriach serwisu.

W szablonie strony będą definiowane położenie oraz zakres elementów nawigacji (główne menu, submenu, ścieżka nawigacji, itp.). Każdorazowa zmiana zawartości menu z poziomu panelu administracyjnego musi powodować natychmiastową aktualizację elementów nawigacyjnych na stronach serwisu.

System musi umożliwiać dowolne przenoszenie pozycji menu (góra/dół) względem siebie w danej kategorii oraz jednej kategorii względem innych kategorii.

Repozytorium plików

CMS musi posiadać repozytorium plików: graficznych, multimedialnych, tekstowych, PDF, itp.

CMS musi umożliwiać dostęp do repozytorium plików lub jego części, zgodnie z przyznanymi uprawnieniami, w celu dodawania nowych plików, zamiany wersji plików oraz usuwania zbędnych. Pliki gromadzone będą w sposób umożliwiający ich swobodne przeglądanie, katalogowanie i sortowanie.

Repozytorium plików musi umożliwiać co najmniej:

1. tworzenie, kopiowanie, usuwanie katalogów i podkatalogów przez użytkownika posiadającego odpowiednie uprawnienia,

2. dodawanie, usuwanie i plików,

3. możliwość przenoszenia plików między katalogami, zmiany nazwy pliku, bez utraty linkowania w Serwisie,

4. dodawanie opisu do pliku,

5. edytowanie parametru „Title” oraz „Alt” dla plików graficznych,

6. sortowanie wg nazwy, typu, wielkości, daty dodania,

7. CMS musi umożliwiać dodawanie do repozytorium wielu plików na raz.

8. Pliki graficzne umieszczane w repozytorium serwisu muszą podlegać normalizacji zgodnie z konfiguracją dot. rozmiaru miniaturki oraz rozmiaru zdjęcia tzn. konwersji do określonego wymiaru i stopnia kompresji, zarówno dla miniaturki jak i dla właściwego zdjęcia.

9. CMS musi umożliwiać opublikowanie zdjęcia w oryginalnym rozmiarze.

Do przeglądania plików w formacie Adobe™ PDF wymagana jest funkcjonalność umożliwiająca:

1. wysłanie maila z linkiem do publikacji,

2. udostępnienie publikacji na kilkudziesięciu serwisach społecznościowych,

3. skopiowanie i wklejenie linka do publikacji na swojej stronie lub blogu,

4. opublikowanie dokumentu w atrakcyjnej formie w treści artykułu,

5. wydrukowanie, pobranie, skomentowanie oraz ocenienie.

Repozytorium powinno zapewniać możliwość tworzenia tagów dla załączników.

Galerie zdjęć, filmy z tłumaczeniem na język migowy

CMS musi posiadać możliwość prezentowania załączników graficznych w postaci galerii, w tym udostępnienia galerii zdjęć jako wydzielonych stron serwisu oraz w ramach artykułów.

Galeria musi być prezentowana w postaci miniatur z możliwością powiększenia ich do ustalonego rozmiaru i pełnego oryginalnego rozmiaru.

Otwieranie widoku powiększenia nie może być blokowane przez systemy blokujące okna typu „pop-up” przeglądarek i musi być zgodne z zasadami WCAG dla wyświetlanych okien na warstwie. Przykład wzorcowy W3C - xxxxx://xxx.x0.xxx/XX/xxx-xxxx-xxxxxxxxx-0.0/#xxxxxx_xxxxx).

CMS musi posiadać możliwość otworzenia pliku powiększenia przy wyłączonej w przeglądarce obsłudze JavaScript.

Musi istnieć możliwość zamieszczania podpisów zdjęć przy rozdzieleniu podpisu od atrybutu „Alt” przypisanego do pliku graficznego.

Pliki graficzne umieszczane w galerii muszą podlegać normalizacji zgodnie z konfiguracją dot. rozmiaru miniaturki oraz rozmiaru zdjęcia tzn. konwersji do określonego wymiaru i stopnia kompresji, zarówno dla miniaturki jak i dla właściwego zdjęcia.

Funkcjonalność dodawania filmów z tłumaczeniem na język migowy (automatyczne oznaczanie strony odpowiednim piktogramem wraz z przejściem po jego naciśnięciu do punktu/kotwicy na końcu artykułu, gdzie jest osadzony film z tłumaczeniem (analogicznie jak np. na stronie xxxxx.xxx.xx).

Newsletter

Funkcjonalność newslettera musi być dostępna dla użytkowników, którzy wypełnili formularz rejestracyjny i wyrazili zgodę na przetwarzanie danych osobowych (zgodnie z wymaganiami RODO) będą mieli możliwość dostosowania zawartości newslettera poprzez wybór informacji według wybranych przez subskrybenta kryteriów.

System musi posiadać możliwość przesyłania za pośrednictwem poczty elektronicznej powiadomień o nowościach w serwisie oraz newsletterów.

Powiadomienia i newslettery muszą być tworzone w oparciu o predefiniowane szablony umożliwiające wysyłanie wiadomości tekstowych lub w formacie HTML.

CMS musi umożliwiać:

1. stosowanie wielu szablonów dla różnych zdefiniowanych wersji powiadomień i newslettera,

2. automatyczne generowanie listy zawierającej informacje o nowych artykułach z opcją wyłączenia niektórych artykułów z listy przed wysłaniem newslettera,

3. konfigurowanie mechanizmu rozsyłania powiadomień, w tym adresu nadawcy, grupy subskrybentów, pory wysyłania, wysyłania na żądanie (ad hoc), wysyłania automatycznego,

4. edycji treści newslettera przed wysłaniem,

5. definiowania grup odbiorców.

Zarejestrowani użytkownicy na podstawie podanego i zweryfikowanego w zadanym okresie czasu adresu e-mail będą mieli możliwość otrzymywania na podany adres e-mail powiadomienia dot. wybranych kategorii tematycznych serwisu oraz newsletterów.

Po zweryfikowaniu adresu e-mail zarejestrowany użytkownik będzie mógł:

1. zrezygnować z subskrypcji,

2. zmienić adres e-mail, na który przesyłane będą subskrybowane informacje (każdorazowa zmiana adresu e-mail będzie wymagała weryfikacji),

3. xxxxxxx hasło,

4. zmienić listę kategorii, z których chce otrzymywać powiadomienia.

CMS musi posiadać funkcjonalność zarządzania bazą danych osób otrzymujących wiadomości e-mail, tzn.: dodawanie, usuwanie i modyfikację danych.

CMS musi zapisywać historię wysyłanych powiadomień i newsletterów w postaci: odbiorcy, daty i treści.

RSS 2.0, Atom 1.0

CMS musi umożliwiać tworzenie kanałów informacyjnych w formacie RSS i Atom dla dowolnie zdefiniowanych obszarów serwisu, np. kategorii.

CMS musi pozwalać na nadanie nazwy kanału, określenie ilości treści oraz sposobu udostępniania (cała treść lub tytuł z nagłówkiem).

CMS musi umożliwiać wyświetlenie statystyk wywołań dla poszczególnych kanałów umieszczonych w serwisie.

CMS musi umożliwiać publikowanie informacji o dostępnych w Serwisie kanałach informacyjnych oraz subskrybowanie kanałów RSS z wszystkimi wiadomościami lub ograniczonymi do wybranego działu.

Zabezpieczenie CMS

Wymagania bezpieczeństwa. Serwis musi być odpowiednio zabezpieczony przed atakami na systemy informatyczne, w szczególności poprzez:

1. zapewnienie zgodności kodu stron z rekomendacją HTML 5 opublikowaną przez World Wide Web Consortium (W3C). Weryfikacja zgodności kodu z rekomendacją W3C będzie przeprowadzona przy pomocy narzędzi udostępnianych przez W3C pod adresami: xxxx://xxxxxxxxx.x0.xxx i xxxx://xxxxxx. x0.xxx/xxx-xxxxxxxxx/;

2. zapewnienie odporności kodu źródłowego na próby uzyskania dostępu do zasobów serwera poprzez znane formy włamań;

3. zapewnienie odporności kodu źródłowego na zmiany treści za pomocą specjalnych skryptów i manipulacji:

4. ataki semantyczne na adres URL,

5. ataki związane z ładowaniem plików,

6. ataki typu cross-site scripting,

7. ataki typu CSRF,

8. podrabianie zatwierdzenia formularza,

9. sfałszowanie żądania HTTP,

10. ujawnienie uwierzytelnień dostępu,

11. wstrzykiwanie kodu SQL,

12. ujawnienie danych przechowywanych w bazie,

13. kradzież cookies,

14. przechwytywanie sesji,

15. wstrzykiwanie sesji,

16. zafiksowanie sesji,

17. trawersowanie katalogów,

18. wstrzykiwanie poleceń systemowych,

19. ujawnianie kodu źródłowego np. plików .inc, „template” itp.

20. zabezpieczenie transmisji danych pomiędzy urządzeniem końcowym, a Serwisem za pomocą protokołu SSL (ang. Secure Socket Layer)

21. wprowadzenie dodatkowych mechanizmów bezpieczeństwa w komunikatach HTTP/HTTPS poprzez:

22. Zdefiniowanie nagłówka X-Frame-Options: sameorigin,

23. Zdefiniowanie nagłówka Strict-Transport-Security: max-age=…,

24. Zdefiniowanie nagłówka X-XSS-Protection,

25. Zdefiniowanie nagłówka X-Content-Type-Options: nosniff

26. zastosowanie mechanizmu definiującego flagę Secure dla ciasteczek zawierających identyfikatory sesji użytkowników aplikacji, w celu zwiększenia poziomu ich bezpieczeństwa.

27. zapewnieniu mechanizmów zapobiegających możliwości wprowadzenia i uruchomienia złośliwego kodu.

W przypadku pojawienia się nowych nie znanych wcześniej technik włamań, Wykonawca jest zobowiązany do ich analizy oraz dostarczenia niezbędnych poprawek i uaktualnień eliminujących podatności dostarczonego CMS w ramach świadczonej Usługi Utrzymania.

Serwis musi filtrować i walidować wszystkie dane wejściowe (np. z formularzy) w celu zminimalizowania ryzyka naruszenia integralności systemu bądź danych.

Warstwa kodowa Serwisu oraz CMS muszą być jawne i dostarczone w takiej postaci, aby Zamawiający mógł w pełni prześledzić ich działanie, w związku z czym zabronione jest korzystanie z mechanizmów szyfrujących typu ioncube i podobnych.

5.Wytyczne w zakresie dostępności

Wymagania prawne

Serwis musi być całkowicie dostępny cyfrowo dla Użytkowników ze szczególnymi potrzebami, w tym z wszelkimi niepełnosprawnościami, dla seniorów i wszystkich innych użytkowników Internetu. Ze względu na rolę, jaką pełnić będzie OWDA, strona www powinna być wzorcowa w zakresie dostępności.

Wymóg dostępności strony wynika z:

1. Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848),

2. Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. 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. 2017 poz. 2247).

Zgodnie z ustawą serwisy internetowe podmiotów realizujących zadania publiczne muszą być zgodne z WCAG 2.1 na poziomie A i AA.

Zatem Wykonawca Serwisu jest zobowiązany do dostarczenia serwisu, który jest bezbłędny pod względem jakości kodu, zgodności z WCAG 2.1 i rzeczywistej dostępności dla wszelkich grup narażonych na wykluczenie cyfrowe.

Najważniejsze wymagania techniczne w zakresie dostępności

Najważniejszą referencją dla Wykonawcy są dokumenty:

1. WCAG 2.1 (oficjalne tłumaczenie na język polski),

2. Techniques for WCAG 2.1 — jest to obszerny dokument on-line, który zawiera setki przydatnych fragmentów kodu i przykładów zastosowania kryteriów WCAG 2.1.

W trakcie realizacji konkretne aspekty dostępności będą także analizowane przez zespół projektowy, w ramach którego będzie pracował ekspert ds. dostępności Zamawiającego.

Zgodność składni z walidatorem HTML

Wszystkie strony serwisu www OWDA muszą być bezbłędne pod względem jakości kodu HTML z walidatorem xxxxx://xxxxxxxxx.x0.xxx/xx/.

W trakcie wdrożenia mogą się pojawić sytuacje, w których z jakichś przyczyn Zamawiający może zaakceptować błędy HTML. Muszą to być jednak udokumentowane i uzasadnione przypadki, które będą związane z niestabilnością specyfikacji HTML5 i będą działać np. na rzecz dostępności.

Uwaga: poza zgodnością z walidatorem samych szablonów serwisu, także treści zapisane przy użyciu edytora wizualnego WYSIWYG nie mogą powodować problemów. Dlatego edytor wizualny powinien generować prawidłowy kod HTML.

Jakość semantyczna kodu HTML

Podstawowym warunkiem dostępności jest prawidłowe — adekwatne stosowanie znaczników HTML. Najprościej rzecz ujmując, serwis ma być realizowany w pełnej zgodności ze specyfikacją HTML5.

Przykłady poprawności semantycznej:

1. Linki powinny być wykonane za pomocą znacznika <a>.

2. Nagłówki powinny być wykonane za pomocą znaczników <h1>...<h6>.

3. Przyciski powinny być wykonane za pomocą znaczników <button> lub <input type="button">.

4. Listy powinny być wykonane za pomocą znaczników <ul> / <ol> i <li> dla poszczególnych elementów.

5. Rozwijane listy formularzy powinny być wykonane za pomocą znaczników <select> / <option>.

Przykłady błędów semantycznych:

1. Link wykonany za pomocą <span> (oskryptowany JavaScript).

2. Nagłówek w formie <p class="heading">.

3. Lista rozwijana w formularzu wykonana za pomocą znaczników listy <ul> / <li>.

Uzupełnienia semantyczne za pomocą ARIA

Atrybuty ARIA muszą stanowić uzupełnienie semantyki HTML. Ta technologia jest przeznaczona przede wszystkim dla użytkowników czytników ekranu. Szczególnie ważne jest jej zastosowanie w komponentach stron internetowych, które opierają się na rozbudowanej interakcji JavaScript.

Stosowanie atrybutów ARIA można podzielić na dwie części:

1. Uzupełnienie głównych bloków serwisu o punkty orientacyjne. (proste),

2. Dodatki do formularzy lub takich komponentów stron, jak np. karuzele, zakładki (tabs), menu rozwijane, bloki rozwijane, okna modalne, alerty, slidery. (trudne).

Głównym źródłem informacji na temat stosowania ARIA powinna być dokumentacja Aria Techniques for WCAG 2.2. (xxxxx://xxx.x0.xxx/XXX/XXXX00/Xxxxxxxxxx/).

Niestety, nie jest to w niektórych przypadkach wystarczające źródło wiedzy. Nie ma jednego miejsca w Internecie zawierającego aktualną, pewną i gotową do stosowania wiedzę w zakresie ARIA. W tym przypadku, w ramach monitoringu wdrożenia, ekspert ds. dostępności pracujący w ramach zespołu projektowego będzie testować rozwiązania i ew. rekomendować kierunki zmian.

Tytuły stron serwisu

Wszystkie tytuły stron serwisu muszą być automatycznie generowane na podstawie informacji, które pozwolą Użytkownikowi dowiedzieć się, co jest treścią danej strony.

Przykłady:

Strona główna Serwisu powinna mieć tytuł —
„Serwis Ośrodka Wsparcia Architektury Dostępnej”.

Strona „Kontakt” powinna mieć tytuł —
„Kontakt – Serwis Ośrodka Wsparcia Architektury Dostępnej”.

Wszystkie strony mają mieć tytuł wg zasady „od szczegółu do ogółu”.

Do uzgodnień w trakcie ustaleń z Wykonawcą pozostanie kwestia, ile elementów ścieżki ma być widocznych w tytule:

tytuł strony + nazwa serwisu lub

tytuł stron + nazwa działu + np. nazwa nadrzędnego działu + nazwa serwisu.

Zgodnie z Wymagania dla System Zarządzania treścią (CMS), opis dodatkowych modułów i funkcjonalności CMS oraz Systemu Serwisu - Redaktor musi mieć możliwość indywidulanego definiowania zawartości atrybutu metatag Title, niezależnie od tytułu redakcyjnego.

Oznaczenie języka strony i treści

Język naturalny treści na stronie powinien być zawsze oznaczony odpowiednim atrybutem lang. W założeniu wszystkie strony serwisu będą miały atrybut lang o treści "pl".

Dodatkowo redaktorzy serwisu powinni mieć w edytorze WYSIWYG możliwość oznaczenia takim atrybutem dowolnego ciągu znaków.

Nagłówki stałe

W Serwisie będą stałe bloki treści i bloki funkcjonalne. Powinny one być oznaczone nagłówkami na odpowiednim poziomie.

Nagłówki dla redaktorów

Redaktorzy powinni mieć możliwość ustawiania odpowiedniej struktury nagłówkowej stron. Nagłówki dostępne dla redaktora powinny się zawierać od h2 do h6. Nagłówek h1 powinien być zarezerwowany dla nazwy - tytułu strony.

Linki

W serwisie OWDA wszystkie linki powinny być zrozumiałe poza kontekstem tekstowym bądź wizualnym. W stałych częściach serwisu może oznaczać to potrzebę uzupełniania krótkich linków o treści uzupełniające.

Przykłady linków, które będzie można uzupełnić o dodatkową treść, to np.: zamknij, przewiń, następny, poprzedni, więcej, pobierz itp.

Opisy alternatywne

Wszystkie grafiki zamieszczone w szablonach za pomocą znacznika <img> powinny mieć atrybut alt.

W przypadku, gdy grafika nie będzie przekazywać żadnej treści (grafiki dekoracyjne), powinny być umieszczane za pomocą CSS, czyli stosując właściwość background-image. Inną metodą jest dodanie do <img> - pustego alt— zapis alt lub alt="".

Jeśli grafika będzie przekazywać treść, alt powinien być uzupełniony o adekwatny opis.

Jeśli grafika będzie linkiem, to opis alternatywny powinien przekazywać funkcję linku, tak jakby to był link tekstowy.

Formularze — semantyka

Budowa formularzy pod względem dostępności musi się opierać o dobre praktyki HTML5. Trzeba uwzględnić, że formularze mogą być używane przez osoby niewidome, niepełnosprawne ruchowo czy głucho-niewidome.

Programiści serwisu powinni rozumieć, jakie są popularne sposoby użycia formularzy, np. bez użycia myszki czy bez patrzenia na ekran.

W większości przypadków jako podstawy semantyki HTML dla formularzy rozumie się:

1. użycie etykiet do wszystkich pól,

2. zrozumiałość etykiet,

3. dostęp do wszelkich wskazówek bez konieczności patrzenia na ekran, np. za pośrednictwem czytnika ekranu (wskazówki, komunikat do obiektów formularzy powinny być powiązane semantycznie z tym obiektem, np. poprzez aria-describedby),

4. kolejność treści i pól formularzy wspierająca użyteczność i zrozumiałość.

Formularze — wsparcie Użytkownika i informacja o błędach

Większym wyzwaniem w przypadku formularzy jest właściwa dostępność informacji o tym, w jaki sposób wypełnić pola oraz informacji o błędach.

W tym przypadku programiści powinni kierować się następującym podejściem:

1. wszystko, co możliwe, jest wykonane za pomocą podstawowych elementów HTML + JavaScript — im dalej będzie sięgać wsteczna kompatybilność, tym lepiej,

2. jeśli formularz będzie tego wymagał, mogą zostać zastosowane atrybuty ARIA.

Kolejność w powyższym wypunktowaniu jest ważna - Użytkownicy mogą korzystać z przestarzałego oprogramowania. Dlatego warto zagwarantować wsteczną kompatybilność w jak największym stopniu.

Tabele.

W przypadku tabel kluczowe jest stosowanie odpowiedniej składni i semantyki HTML. Czytniki ekranu wspierają obsługę tabel bardzo dobrze.

Wskazówki w zakresie tworzenie dostępnych tabel: xxxxx://xxx.x0.xxx/XXX/xxxxxxxxx/xxxxxx/.

Działanie Serwisu za pomocą klawiatury

Jakkolwiek prawidłowe zastosowanie semantyki HTML powinno gwarantować dostępność za pomocą klawiatury — należy zadbać o to na etapie wdrożenia, zapewniając bezbłędne działanie.

Programiści muszą stosować zarządzanie fokusem przez JavaScript w taki sposób, aby nie stworzyć tzw. pułapki klawiaturowej. Taki błąd powoduje utrudnienia dla Użytkowników z niepełnosprawnością ruchu oraz korzystających z czytników ekranu.

Kolejność fokusu

Fokus klawiatury powinien mieć kolejność wedle reguły od lewej do prawej oraz od góry do dołu. Przykładowo, po przejściu fokusem menu głównego, powinien on trafić do głównego bloku treści lub lewej kolumny.

Ukrywanie treści

W niektórych przypadkach, np. w linkach, może być konieczne stosowanie ukrytej treści. Takie rozwiązanie wspiera korzystanie z Serwisu przez Użytkowników niewidomych.

Polecamy artykuł opisujący techniki ukrywania treści: xxxx://xxxxxx.xxx/xxxxxxxxxx/xxx/xxxxxxxxxxxxxxxx/ (techniki ukrywania treści).

Poza tymi obszarami, w których Wykonawca zaproponuje użycie techniki ukrywania, w ramach monitoringu wdrożenia, ekspert ds. dostępności pracujący w ramach zespołu projektowego będzie rekomendować miejsca, w których warto dodatkowo zastosować tę technikę.

Zabezpieczenie formularzy

Niezwykle ważne będzie, by formularze zabezpieczone były w taki sposób, który nie stwarza barier oraz niewygód dla Użytkownika Serwisu.

W tym przypadku trzeba będzie uważać z rozwiązaniami typu CAPTCHA. Tego typu zabezpieczenia najczęściej nie są w stanie zapewnić dostępności dla wszystkich odbiorców.

W miarę możliwości filtrowanie spamu i działań niepożądanych należy pozostawić po stronie serwera lub w sposób niewidoczny dla Użytkownika. Jeśli wykonawca będzie proponował rozwiązanie typu CAPTCHA, to będzie ono bardzo dokładnie testowane pod kątem dostępności dla wszystkich Użytkowników.

Działanie filtrów / przeładowanie

Wszelkie działania związane z przeładowaniem widoku takie jak:

1. filtrowanie,

2. sortowanie,

3. wyszukiwanie,

muszą być dobrze przetestowane z czytnikami ekranu. W takich sytuacjach kluczowy będzie komfort w obsłudze bezwzrokowej. Użytkownik powinien zawsze mieć pełną wiedzę na temat działania interfejsu i świadomość tego, że treść strony została zaktualizowana.

Należy także przyjąć ogólną zasadę, że zmiany treści strony bez przeładowania stosowane są tylko w uzasadnionych sytuacjach.

W niektórych przypadkach, po zmianie przefiltrowania może być też konieczna automatyczna zmiana tytułu strony <title>.

Działanie w trybie wysokiego kontrastu (WINDOWS)

Serwis www OWDA powinien bezproblemowo działać w trybie wysokiego kontrastu Windows. Wykonawca powinien prowadzić takie testy na bieżąco w trakcie wdrożenia.

Typowe problemy w takim trybie mogą być związane z użyciem CSS-owego zastępowania tekstu grafiką. Dlatego w niektórych przypadkach zamiast użycia takiej techniki, będzie konieczne zastosowanie typowych linków graficznych <a><img></a>.

Skip linki

Na każdej stronie serwisu powinien działać link „Przejdź do wyszukiwania”, „Przejdź do głównej treści”, które pomagają przeskoczyć fokusem bezpośrednio do głównej funkcjonalności danej strony. Najczęściej będzie to oznaczać przeskoczenie bloku nagłówkowego wraz z „okruszkami”. Po przeskoczeniu fokus najczęściej powinien zaczynać się w okolicy nagłówka <h2> - treść strony.

[Inne wymagania techniczne]

Szybkość działania Serwisu

Serwis powinien być maksymalnie zoptymalizowany do szybkiego działania. Lekkość serwisu wpływa pozytywnie na działanie z oprogramowaniem wspomagającym, takim jak np. czytnik ekranu. Takie działanie powoduje również komfortową obsługę w urządzeniach mobilnych. W ramach optymalizacji pod kątem szybkości działania trzeba będzie zwrócić uwagę na następujące kwestie:

1. brak nadmiarowego kodu HTML / CSS / JS,

2. nieobciążanie serwisu zbędnymi dodatkami JS,

3. dobrą optymalizację grafiki,

4. minimalizację liczby plików pobieranych wraz z unikalną stroną,

5. cache serwisu, który zminimalizuje zapytania do bazy danych.

Responsywność (RWD)

Serwis powinien być zbudowany z myślą o urządzeniach mobilnych, które coraz częściej pełnią ważniejszą rolę w odbiorze treści internetowych.

Serwis powinien być zbudowany w oparciu o najlepsze i aktualne praktyki tworzenia serwisów responsywnych.

Wykonawca powinien przygotować wszystkie projekty graficzne z zastosowaniem skoków responsywnych szerokości w odniesieniu do typów urządzeń (standardów):

smartfon – z rozdzielczością 360x640 (wartość średnia) w wersji pionowej oraz poziomej (z uwzględnieniem wartości minimalnej 320 px).

tablet - z rozdzielczością 768x1024 w wersji pionowej oraz poziomej,

monitor komputerowy - z rozdzielczością 1366x768 (wartość średnia), z uwzględnieniem wartości minimalnej – 900 px oraz wartości maksymalnej - 1920 px.

Podczas realizacji należy zwrócić uwagę, aby w szczególności w wartościach minimalnych obiekty nie zachodziły na siebie i nie przykrywały treści bądź funkcjonalności.

Projektując widoki mobilne należy uwzględnić minimalną wielkość fontów – 16 px. Jest to wartość ważna podczas analizy czytelności strony.

Możliwości edytora WYSIWYG

W edytorze wizualnym poza standardowymi funkcjami, potrzebne będzie udostępnienie redaktorom kilku dodatkowych narzędzi. Dokonując wyboru WYSIWYGa trzeba będzie sprawdzić, czy rozwiązanie obsługuje dane funkcje natywnie, np. na podstawie pluginów.

Wstępna rekomendacja na rozwiązanie WYSIWYG to TinyMCE. W trakcie produkcji systemu trzeba będzie dokonać wyboru, która wersja edytora powinna być dostępna dla redaktorów www OWDA

Działanie z oprogramowaniem wspomagającym

Działanie serwisu www OWDA będzie analizowane przy użyciu:

1. popularnych czytników ekranu — NVDA, Jaws,

2. powiększalników takich jak ZoomText,

3. trybu wysokiego kontrastu Windows,

4. urządzeń typu switch,

5. urządzeń mobilnych z systemami Android / iOS, a w tych systemach z:

6. czytnikami ekranu,

7. rozwiązaniami typu switch,

8. powiększaniem ekranu i tekstu.

Testy zostaną przeprowadzone zarówno przez ekspertów jak i z Użytkownikami z niepełnosprawnościami.

Kontrast treści

Kontrast między kolorem tekstu a kolorem tła, na jakim jest on prezentowany, musi wynosić minimum 7:1.

W przypadku treści drugorzędnych (np. informacje normatywne w stopce serwisu) kontrast ten może wynosić 4,5:1.

Prostym narzędziem do analizy poziomu kontrastu jest Color Contrast Analyzer.

Między innymi tym narzędziem będzie wykonywana weryfikacja zgodność projektu graficznego z zapisami zamówienia.

W związku z wymogami dotyczącymi kontrastu, nie powinny być w serwisie stosowane elementy prezentujące tekst na tle niejednorodnym, np. bezpośrednio na tle zdjęcia.

Stosowanie kolorystyki mniej kontrastowej jest dopuszczalne tylko w zakresie graficznych elementów dekoracyjnych w serwisie.

Identyfikacja linków

Linki tekstowe muszą być jasno identyfikowalne przez wszystkich Użytkowników serwisu.

Oznacza to, że muszą odróżniać się od tekstu zarówno kolorem jak i podkreśleniem.

Podkreślenie powinno być użyte w projekcie graficznym wyłącznie do oznaczenia linków. To samo dotyczy koloru linków. Kolor ten nie może być powtórzony na żadnym elemencie nieklikalnym. Kolor ten musi również spełniać wymogi wskazane w punkcie “Kontrast treści”.

Po oznaczeniu linku kursorem myszy (hover) podkreślenie linku ma znikać, a kolor linku zmieniać się na kolor o wyższym wskaźniku kontrastu do tła niż przy kolorze bazowym linku.

Formularze

Wymóg widoczności dotyczy również formularzy stosowanych w serwisie. W szczególności odnosi się to do widoczności ramek pól, etykiet pól oraz przycisków.

Wszystkie elementy formularzy muszą spełniać wymóg kontrastu w stosunku do tła na poziomie minimum 3:1.

Analogicznie jak w przypadku linków, także przyciski formularzy, po oznaczeniu kurosem myszy muszą stawać się bardziej widoczne dla Użytkowników (zwiększenie kontrastu między kolorem przycisku a kolorem tekstu przycisku).

Etykiety pól powinny być widoczne i prezentowane bezpośrednio obok pola. W niektórych przypadkach etykieta może być ukryta, na przykład w funkcji wyszukiwarki.

Informacje o błędach powinny być prezentowane tekstowo, bezpośrednio obok pól (dodatkowo powiązane z polem poprzez aria), których dotyczą oraz pod nagłówkiem rozpoczynającym blok z formularzem.

Fokus klawiatury

Cały serwis i każda jego funkcjonalność będą dostępne przy nawigacji za pomocą samej klawiatury.

Fokus klawiatury powinien mieć formę wzmocnioną w stosunku do fokusu domyślnego przeglądarki i być widoczny przy nawigacji za pomocą klawiatury w formie ramki, wokół aktualnie wybranego elementu.

Kolor ramki fokusu powinien być dobrany do schematu kolorystycznego serwisu, a jednocześnie bardzo dobrze widoczny na każdym oznaczonym elemencie (minimalny kontrast – 3:1).

Przykład dobrze widocznego fokusu można znaleźć w serwisie xxx.xxxxx.xxx.xx - wystarczy zacząć nawigację w serwisie za pomocą przycisku TAB.

Do rozróżnienia fokusa klawiatury i myszki można wykorzystać bibliotekę dostępną na stronie: xxxxx://xxxxxx.xxx/xxx0xxxxx/xxxx-xxxxx

Typografia

Czcionka(i) użyta w serwisie powinna być bezszeryfowa oraz zachowująca wysoki poziom czytelności także przy dużym powiększeniu. Przykładami tego typu czcionek są np. Lato, Open Sans czy PT Sans.

Liczba czcionek (kroju i wielkości) powinna zostać ograniczona w projekcie graficznym serwisu do niezbędnego minimum.

Spójna identyfikacja

Zamawiający zakłada zachowanie spójności pomiędzy system iPFRON+ oraz Serwisu. Dlatego Zamawiający zaleca takie budowanie szablonów w oparciu o CSS, aby była możliwa bezkolizyjna i prosta zmiana podstawowych kolorów.

W ramach projektu powinny zostać zaplanowane i zaprezentowane widoki takich tekstowych elementów semantycznych jak:

1. nagłówek poziomu 1,

2. nagłówek poziomu 2,

3. nagłówek poziomu 3,

4. nagłówek poziomu 4,

5. nagłówek poziomu 5,

6. nagłówek poziomu 6,

7. lista numerowana (uporządkowana),

8. lista wypunktowana (nieuporządkowana),

9. listy obu typów wielokrotnie zagnieżdżone,

10. link,

11. tekst podstawowy,

12. tekst podstawowy wyróżniony,

13. przycisk (3 schematy dla różnych funkcjonalności),

14. listy rozwijane (select),

15. przyciski typu radio,

16. pola wyboru,

17. pole edycyjne.

Wielkość czcionek użytych w poszczególnych stylach powinna odpowiadać hierarchii tych styli względem siebie. Zalecamy przyjęcie zasady, iż nagłówek poziomu 6 powinien być co najmniej wielkości czcionki podstawowej, tylko pogrubionej.

Minimalna wielkość czcionki dopuszczalnej w projekcie graficznym to 12 px., przy czym treść podstawowa powinna mieć wielkość minimum 16 px.

Dla treści nie powinno być stosowane formatowanie wersaliki.

Odstępy między wierszami w akapitach powinny wynosić przynajmniej 1,3-1,5 wysokości linii, a odległość między akapitami powinna być przynajmniej 1,5 razy większa niż ta pomiędzy wierszami.

W jednym wersie powinno być prezentowane maksymalnie 85 znaków.

Żadna treść w projekcie graficznym nie powinna być justowana (równocześnie wyrównana do lewej i prawej). Dopuszczalne jest tylko wyrównanie do lewej, a w uzasadnionych sytuacjach wyśrodkowanie tekstu.

Tam, gdzie tylko to możliwe, treść powinna być prezentowana w formie tekstu, a nie grafiki tekstu. Do osiągnięcia pożądanego wyglądu powinny być użyte odpowiednie style CSS.

Tabele

Tabele z danymi prezentowane w projekcie graficznym powinny uwzględniać wyraźnie odróżniające się od reszty komórek wersy/kolumny nagłówkowe.

Możliwość swobodnej zmiany wielkości widoku

Koncepcja serwisu zakłada możliwość swobodnej zmiany wielkości strony (Ctrl ++ oraz Ctrl + -). Przy każdej szerokości ekranu/poziomie powiększenia (nie tylko dedykowanej dla tabletów i smartfonów) wszystkie treści i funkcje Serwisu powinny być dostępne w czytelnej formie. Projekt graficzny musi umożliwiać zaprogramowanie w ten sposób Serwisu.

Elementy ruchome

Elementy ruchome w serwisie są dopuszczalne, ale tylko w połączeniu z przyciskiem umożliwiającym Użytkownikowi zatrzymanie tego ruchu i ponowne uruchomienie.

Żaden element serwisu nie może migać.

Multimedia

Materiały wideo powinny być prezentowane za pomocą standardowego odtwarzacza YouTube. Projekt graficzny powinien uwzględniać zamieszczanie bezpośrednio pod materiałem wideo linku do transkrypcji tekstowej materiału.

Kolorystyka serwisu

Kolorystyka serwisu www OWDA będzie realizowana na podstawie koncepcji graficznej dostarczonej Wykonawcy przez Zamawiającego. Koncepcja ta będzie spełniać wymagania dotyczące minimalnego kontrastu treści do tła oraz wymagania w 2.7. Spójna identyfikacja.

54