Contract

Zapytanie o wycenę szacunkową wartości zamówienia na usługę Asysty Technicznej i Konserwacji, Modyfikacje i Rozwój Systemu Pwind

Nazwa i adres Zamawiającego

Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych

Xx. Xxxx Xxxxx XX 00, 00-000 Xxxxxxxx

Adres strony internetowej: xxx.xxxxx.xxx.xx

Przedmiotem szacowania wartości zamówienia jest świadczenie:

1. Przedmiotem zamówienia będą:

1. Usługi Asysty Technicznej i Konserwacji dla Systemu Pwind.

2. Modyfikacje i Rozwój Systemu Pwind.

3. Usługa dostosowania Systemu Pwind do wymagań WCAG 2.1 AA.

2. Szczegółowy opis przedmiotu wyceny zawiera Załącznik nr 1.

3. Kod określony we Wspólnym Słowniku Zamówień (CPV):

1. 72267000-4 usługi w zakresie konserwacji i naprawy oprogramowania,

2. 72250000-5 usługi w zakresie konserwacji i wsparcia systemu,

3. 72262000-9 usługi rozbudowy oprogramowania,

4. 72260000-5 usługi w zakresie oprogramowania,

5. 22471000-2 instrukcje komputerowe.

Termin realizacji zamówienia

1. Termin realizacji zamówienia – maksymalnie 48 miesięcy od dnia zawarcia Umowy.

2. Pozostałe terminy realizacji przedmioty zamówienia zostały określone w załączniku nr 1 do OPZ.

Termin i sposób złożenia informacji na temat szacunkowej wartości zamówienia

1. Szacunkową wycenę dla w/w usług, prac przygotowaną wg wzoru stanowiącego Załącznik nr 2 do niniejszego zapytania należy przesłać na adres xxxxxxxxx@xxxxx.xxx.xx do dnia 2024-07-12.

Informacje o możliwości zadawania pytań

Wykonawcy mają możliwość zdawania pytań do treści zapytania o wycenę. Odpowiedź na pytanie wykonawcy przekazuje się wszystkim wykonawcom analogicznie do wysłania zapytania, bez podawania informacji o wykonawcy zadającym pytanie. Zamawiający zastrzega sobie prawo do pozostawienia pytań bez odpowiedzi. Pytania dotyczące wyceny szacunkowej proszę kierować na adres poczty elektronicznej wskazany wyżej.

Pozostałe informacje

1. Wycena powinna obejmować pełny zakres prac określonych w zapytaniu oraz uwzględniać wszystkie koszty związane z należytą realizacją przedmiotu zamówienia.

2. Wycena powinna być złożona na poniższym formularzu szacunkowej wyceny zamówienia stanowiącym załącznik nr 2 do niniejszego zapytania.

3. W Załączniku nr 2 szacowanie kosztów Wykonawca wpisuje ceny jednostkowe netto
   i brutto za poszczególne usługi składające się na przedmiot zamówienia.

4. Wycena powinna być wyrażona w złotych polskich z uwzględnieniem należnego podatku VAT. Wycenę należy podać z dokładnością do dwóch miejsc po przecinku (zł/gr).

5. Zamawiający zastrzega sobie prawo do unieważnienia zapytania bez podania przyczyny oraz możliwość prowadzenia korespondencji celem doprecyzowania/wyjaśnienia treści złożonych odpowiedzi.

6. Przy wycenie należy uwzględnić ww. informacje jak również to, że w przyszłym zamówieniu w przypadku nienależytego wykonania przedmiotu zamówienia lub jakiejkolwiek jego części, Zamawiający zawrze zapisy dotyczące możliwości żądania od Wykonawcy zapłaty kary umownej, której wysokość zostanie określona
   w projektowanych postanowieniach umowy;

7. Niniejsze zapytanie nie stanowi oferty w rozumieniu kodeksu cywilnego. Złożenie zapytania o szacunkową wartość, jak też otrzymanie w jego wyniku odpowiedzi nie jest równoznaczne z udzieleniem zamówienia przez Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych (nie rodzi skutków w postaci zawarcia umowy).

8. Niniejsze zapytanie o wartość szacunkową zamówienia nie stanowi także zapytania ofertowego, ani ogłoszenia w rozumieniu ustawy z dnia z dnia 11 września 2019 r. Prawo Zamówień Publicznych (Dz. U. z 2023 r. poz. 1605 ze zmianami). Prowadzone jest tylko w celu dokonania właściwego określenia wartości docelowego zamówienia.

Klauzula informacyjna

Działając na podstawie art. 13 i 14 rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz. Urz. UE
L 119 z 04.05.2016, str. 1), dalej „RODO”, w związku z zapytaniem o szacunkową wartość zamówienia, dalej: „Zapytanie”, Zamawiający przekazuje poniżej informacje dotyczące przetwarzania danych osobowych.

Tożsamość administratora

Administratorem danych osobowych jest Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych (PFRON) z siedzibą w Warszawie 00-828, przy xx. Xxxx Xxxxx XX 00.

Dane kontaktowe administratora

Z administratorem można skontaktować się poprzez adres e-mail: xxxxxxxxxx@xxxxx.xxx.xx, telefonicznie pod numerem x00 00 00 00 000 lub pisemnie na adres siedziby administratora.

Dane kontaktowe Inspektora Ochrony Danych

Administrator wyznaczył inspektora ochrony danych, z którym można skontaktować się poprzez e-mail: xxx@xxxxx.xxx.xx we wszystkich sprawach dotyczących przetwarzania danych osobowych oraz korzystania z praw związanych z przetwarzaniem.

Cele przetwarzania

Celem przetwarzania danych osobowych jest przeprowadzenie Zapytania oraz archiwizacja dokumentacji zgromadzonej w jego wyniku. Dane osobowe mogą być przetwarzane w celu realizacji przez administratora jego uzasadnionego interesu, w tym ustalenia, dochodzenia lub obrony roszczeń.

Podstawa prawna przetwarzania

Podstawą prawną przetwarzania danych osobowych jest art. 6 ust. 1 lit. c RODO (realizacja przez administratora obowiązku prawnego). W przypadku przetwarzania danych osobowych w celu realizacji przez administratora jest prawnie uzasadnionego interesu podstawą prawną przetwarzania jest art. 6 ust. 1 lit. f RODO.

Źródło danych osobowych

Administrator może pozyskiwać dane osobowe przedstawicieli podmiotu uczestniczącego
w Zapytaniu za jego pośrednictwem.

Kategorie danych osobowych

Zakres danych dotyczących przedstawicieli podmiotu uczestniczącego w Zapytaniu obejmuje dane osobowe przedstawione w odpowiedzi na Zapytanie, w szczególności imię, nazwisko, stanowisko, adres poczty elektronicznej lub numer telefonu.

Okres, przez który dane będą przechowywane

Dane osobowe będą przetwarzane przez okres niezbędny do realizacji celu przetwarzania, zgodnie z zasadami archiwizacji dokumentacji obowiązującymi u administratora.

Podmioty, którym będą udostępniane dane osobowe

Dostęp do danych osobowych mogą mieć podmioty świadczące na rzecz administratora usługi doradcze, z zakresu pomocy prawnej, pocztowe, dostawy lub utrzymania systemów informatycznych. Dane osobowe mogą być udostępniane przez administratora podmiotom uprawnionym do ich otrzymania na mocy obowiązujących przepisów, np. organom publicznym.

Prawa podmiotów danych

Osobom fizycznym, których dotyczą dane osobowe przetwarzane przez administratora, przysługuje prawo:

1. na podstawie art. 15 RODO – prawo dostępu do danych osobowych i uzyskania ich kopii;

2. na podstawie art. 16 RODO – prawo do sprostowania i uzupełnienia danych osobowych;

3. na podstawie art. 17 RODO – prawo do usunięcia danych osobowych, z zastrzeżeniem wyjątków przewidzianych w art. 17 ust. 3 lit. b, d oraz e RODO;

4. na podstawie art. 18 RODO – prawo żądania od administratora ograniczenia przetwarzania danych;

5. na podstawie art. 21 RODO – prawo do wniesienia sprzeciwu wobec przetwarzania danych osobowych na podstawie art. 6 ust. 1 lit. f RODO.

Prawo wniesienia skargi do organu nadzorczego

Osobom fizycznym, których dotyczą dane osobowe przetwarzane przez administratora, przysługuje prawo wniesienia skargi do organu nadzorczego, tj. Prezesa Urzędu Ochrony Danych Osobowych, xx. Xxxxxx 0, 00 - 000 Xxxxxxxx, na niezgodne z prawem przetwarzanie danych osobowych przez administratora.

Informacja o dowolności lub obowiązku podania danych oraz o ewentualnych konsekwencjach niepodania danych

Podanie danych osobowych jest dobrowolne, ale konieczne dla uczestniczenia w Zapytaniu.

Informacja o zautomatyzowanym podejmowaniu decyzji

Administrator nie będzie podejmował decyzji opartych na zautomatyzowanym przetwarzaniu danych osobowych.

Realizacja obowiązku informacyjnego w imieniu administratora

Podmiot uczestniczący w Zapytaniu jest zobowiązany do przekazania informacji o przetwarzaniu danych osobowych przez administratora osobom, których dane zawarte są w odpowiedzi na Zapytanie.

Załączniki

1. Załącznik nr 1 – Opis Przedmiotu Zamówienia

2. Załącznik nr 1 do OPZ – Wymagania wydajnościowe

3. Załącznik nr 2 do OPZ – Wymagania w zakresie WCAG

4. Załącznik nr 3 do OPZ - Poziom świadczenia usługi (SLA)

5. Załącznik nr 4 do OPZ - Wymagania dotyczące testów

6. Załącznik nr 5 do OPZ – Kryteria zgodności dokumentów z dostępnością cyfrową

7. Załącznik nr 6 do OPZ – Zgodność aplikacji z wymaganiami WCAG, kryteria

8. Załącznik nr 2 – Formularz wyceny szacunkowej

Załącznik nr 1 Opis przedmiotu zamówienia

1. Zastosowane definicje

Strony nadają terminom używanym w dalszej treści Umowy następujące znaczenie:

Termin	Definicja
Awaria	Wada inna niż Błąd i Usterka, powodująca całkowite zatrzymanie lub poważne zakłócenie pracy Systemu lub poszczególnych jego części, dla której nie ma alternatywnej metody wykonania danej operacji w Systemie, uniemożliwiająca korzystanie z funkcji Systemu przez jego Użytkowników tak jak było to możliwe przed wystąpieniem Awarii lub uniemożliwienie wywiązania się przez Zamawiającego z nałożonych na niego obowiązków/zadań wynikających z przepisów prawa lub wysokiego ryzyka powstania sytuacji, w której nie będzie możliwe wywiązanie się przez Zamawiającego z nałożonych na niego obowiązków/zadań wynikających z przepisów prawa.
Analiza Wstępna	Dostarczony w ramach realizacji Analizy i Projektu Produkt zawierający co najmniej: harmonogram realizacji Modyfikacji zawierający terminy realizacji wszystkich zadań z nią związanych (x.xx. analiza, implementacja, testowanie, szkolenia, wdrożenia), wycenę (kwota i liczba Roboczogodzin) opartą o szacunki realizacji wszystkich zadań i podzadań, o których mowa powyżej, wykaz obszarów Systemu, których dotyczy Modyfikacja wraz z opisem wpływu zmian na poszczególne obszary i funkcje Systemu, opis konsekwencji dla dostępności, wydajności, ergonomii, bezpieczeństwa technicznego Systemu oraz bezpieczeństwa w zakresie gromadzenia oraz przetwarzania danych osobowych (w postaci zgodnej z RODO analizy ryzyka) jakie spowoduje realizacja Modyfikacji, wykaz oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Obcego koniecznego do wykorzystania w ramach realizacji Modyfikacji, opis oraz zakres zmian wprowadzonych przez zgłoszenie, opis szkoleń (opcjonalnie), schemat uprawnień po zmianach (opcjonalnie)
Błąd	Wada inna niż Awaria i Usterka, powodująca istotne zakłócenia pracy Systemu lub poszczególnych jego części, która jednak nie uniemożliwia Użytkownikom korzystania z funkcji Systemu, i nie stwarza ryzyka powstania sytuacji, w której nie będzie możliwe wywiązanie się przez Zamawiającego z nałożonych na niego obowiązków/zadań wynikających z przepisów prawa, polegająca w szczególności na ograniczeniu realizacji lub uciążliwości w realizacji co najmniej jednej z funkcji Systemu.
Błąd dostępności	Wada Portalu internetowego lub jego poszczególnych części, która wynika z niezgodności ze wskazanym kryterium z Załącznika do ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych oraz Załącznika nr 2 do niniejszego OPZ Dobre praktyki WCAG 2.1 w zamówieniach publicznych.
Czas Naprawy	Czas liczony od momentu dokonania Zgłoszenia Wady przez Zamawiającego do chwili udostępnienia Zamawiającemu Naprawy na Środowisku Produkcyjnym.
Czas Obejścia	Czas liczony od momentu dokonania Zgłoszenia Wady przez Zamawiającego do chwili dokonania Obejścia na Środowisku Produkcyjnym.
Dokumentacja Systemu	Wszelka dokumentacja opisująca System i Kody Źródłowe Systemu (w tym również zmiany oraz modyfikacje takiej dokumentacji), dotycząca aspektów technicznych, funkcjonalnych i użytkowych związanych z korzystaniem z Systemu, jego działaniem i rozwojem, w tym dokumentacja systemu w wersji papierowej oraz elektronicznej. Dokumentacją Systemu jest istniejąca Dokumentacja Systemu, będąca w posiadaniu Zamawiającego na dzień podpisania Umowy, jak również Dokumentacja Systemu, którą Wykonawca zobowiązany jest zaktualizować, dostosować, wytworzyć i dostarczyć zgodnie z Umową.
Dzień Roboczy	Każdy dzień tygodnia od poniedziałku do piątku, za wyjątkiem dni ustawowo wolnych od pracy w Rzeczpospolitej Polskiej.
Godziny Robocze	Godziny od 7:00 do 17:00 w Dni Robocze.
Informacje Poufne	Wszelkie informacje, dokumenty oraz materiały dotyczące działalności jednej ze Stron, do których druga Strona Umowy uzyskała dostęp w związku z wykonywaniem niniejszej Umowy. Informacjami Poufnymi są w szczególności dane zawarte w dokumentach przekazywanych lub przetwarzanych za pośrednictwem Systemu, wszelkie informacje finansowe, organizacyjne, technologiczne, dane osobowe oraz inne informacje o działalności jednej ze Stron, które posiadają wartość gospodarczą lub zostały udostępnione drugiej Stronie z zastrzeżeniem poufności.
Kierownik Projektu	Osoba kontaktowa lub podejmująca decyzje dotyczące realizacji Umowy w ramach kompetencji przyznanych w Umowie, wyznaczona przez Zamawiającego/Wykonawcę, odpowiedzialna za prawidłowe wykonywanie zobowiązań wynikających z Umowy oraz bieżący przepływ informacji pomiędzy Stronami.
Kody Źródłowe	Zestaw plików w formie czytelnej dla człowieka zawierających nieskompilowany kod oprogramowania napisany języku programowania, wynikającym z przyjętej technologii rozwiązania normalnie używanej dla umożliwienia wprowadzania modyfikacji, (w tym również komentarze oraz kody proceduralne, takie jak skrypty w języku opisu prac i skrypty do sterowania kompilacją i instalowaniem), jak również dokumentacja niezbędna do użycia takiego kodu.
Modyfikacja i Rozwój	Zamówione przez Zamawiającego prace w ramach Modyfikacji i Rozwoju systemu Pwind.
Naprawa	Trwałe usunięcie Xxxx poprzez usunięcie przyczyn powstania Wady skutkujące przywróceniem pełnej sprawności Systemu, w tym również zakończenie innych działań naprawczych.
Niedostępność Systemu	Awaria Systemu lub obniżenie parametrów wydajnościowych Systemu, opisanych w Umowie i załącznikach do Umowy.
Obejście	Zapewnienie funkcjonowania Systemu poprzez zminimalizowanie uciążliwości Wady i doprowadzenie Systemu do działania bez usuwania przyczyny wystąpienia Wady. Obejście nie stanowi Naprawy, jednak pozwala korzystać nieprzerwanie z wszystkich funkcjonalności Systemu.
Odbiór	Czynności mające na celu potwierdzenie dostarczenia Zamawiającemu usług i Produktów, powstałych w wyniku zobowiązań wynikających z Umowy.
Okno Serwisowe	Czas pomiędzy godziną 18:00 a 06:00 przeznaczony na wykonywanie wszelkich niezbędnych prac serwisowych, przeglądów, aktualizacji Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego oraz Systemu, a także wgrywania nowych wersji Systemu na Środowisko Produkcyjne i Środowiska Testowe.
Opis Modelu Systemu EA	Opis Systemu uwzględniający w szczególności dziedzinę, architekturę oraz strukturę logiczną i fizyczną baz stworzony narzędziem Sparx Enterprise Architekt w wersji co najmniej 14.
Oprogramowanie Standardowe/Oprogramowanie Obce	Oprogramowanie dostarczone przez Wykonawcę, nie wytworzone w toku prac nad realizacją Systemu, stanowiące jego składnik, na którego użycie w procesach budowy, rozwoju, konfiguracji, instalacji lub użytkowania Systemu Zamawiający wyraził zgodę. Wykonawca powinien uzyskać zgodę Zamawiającego na użycie określonego Oprogramowania Standardowego/Obcego przed przystąpieniem do wszelkich prac, których efektem może być modyfikacja lub rekonfiguracja Systemu.
Oprogramowanie Systemowe i Narzędziowe	Oprogramowanie wykorzystywane na potrzeby Systemu, konieczne do poprawnego działania Systemu, inne niż Oprogramowanie Zamawiającego. Wykonawca powinien uzyskać zgodę Zamawiającego na użycie określonego Oprogramowania Systemowego i Narzędziowego przed przystąpieniem do wszelkich prac, których efektem może być modyfikacja lub rekonfiguracja Systemu.
Oprogramowanie Zamawiającego	Oprogramowanie aktualnie wykorzystywane na potrzeby Systemu, które zapewnia Zamawiający.
Pakiet Aktualizacji	Przygotowane do instalacji uaktualnienie Systemu, służące usunięciu nieprawidłowości, usprawnieniu pracy Systemu, wdrożeniu zmian.
Podwykonawca	Każdy podmiot inny niż: pracownik Wykonawcy, osoba fizyczna prowadząca działalność gospodarczą czy osoba fizyczna, z którą Wykonawca ma zawartą umowę cywilnoprawną (np. umowa o współpracy).
Portal Serwisowy	System informatyczny wykorzystywany przez Zamawiającego (JIRA) służący do ewidencji i obsługi Zgłoszeń, wniosków i Zamówień zapewniający niezbędny poziom wymiany informacji pomiędzy Zamawiającym a Wykonawcą.
Produkt	Wszelkie programy komputerowe, dokumentacja i inne utwory, które powstają w toku wykonywania Umowy w wyniku prac Wykonawcy, w tym także wszelkie modyfikacje i opracowania innych utworów, a także materiały i informacje niepodlegające ochronie prawa autorskiego, stworzone lub dostarczone Zamawiającemu przez Wykonawcę w wyniku wykonania zobowiązań wynikających z Umowy.
Protokół Odbioru	Dokument przedstawiony przez Wykonawcę i zaakceptowany przez Zamawiającego, potwierdzający prawidłowość i zakres wykonania konkretnych usług i Produktów.
Przypadki Szczególne	To takie, w których Użytkownik pomimo spełnienia wymogów określonych dla Systemu, dotyczących zainstalowanego środowiska oraz mimo wsparcia konsultantów, nie może skorzystać z dowolnej funkcji Systemu przewidzianej jako jedna z dostępnych możliwości.
Pytania (Konsultacje)	Pytania (Konsultacje) dotyczące działania Systemu w ramach świadczenia Usługi Asysty Technicznej i Konserwacji.
Repozytorium Projektu	Narzędzie służące do rejestracji i rozliczania pracy osób realizujących Umowę po stronie Wykonawcy, środowisko skonfigurowane we wskazany przez Zamawiającego sposób, na wskazanej przez Xxxxxxxxxxxxx infrastrukturze z wykorzystaniem wskazanego przez Zamawiającego środowiska systemu kontroli wersji (GIT), narzędziu typu case-tracker (JIRA, Microsoft Teams), lub systemie DMS (Sharepoint).
Roboczogodzina (RBH)	Jednostka miary pracochłonności wyrażająca normę ilościową pracy wykonanej przez jednego pracownika Wykonawcy w czasie jednej godziny.
RTO	Recovery Time Objective – czas niezbędny do przywrócenia Systemu po Awarii w ramach Usługi Asysty Technicznej i Konserwacji ( ATiK).
RPO	Recovery Point Objective – punkt w czasie, do którego jest przywrócony System po Awarii.
SLA	Service Level Agreement - Poziom świadczenia usług i sposób jego pomiaru, określony w Załączniku nr 4 do OPZ
Sprzęt	Urządzenia, w szczególności sprzęt komputerowy i infrastruktura teleinformatyczna znajdująca się w posiadaniu Zamawiającego, na których działa System w okresie realizacji Umowy.
System	System Pwind, chyba że w treści Umowy wprost wskazano inaczej.
System Pwind/Pwind	Oprogramowanie informatyczne wspierające realizację zadań w obszarze windykacji należności oraz stanowi pomocniczą księgę rachunkową ewidencjonującą operacje windykacyjne. W skład Systemu wchodzi: kod w postaci wykonywalnej, kody źródłowe Systemu, Oprogramowanie Standardowe/Obce, Oprogramowanie Systemowe i Narzędziowe niezbędne do prawidłowej pracy Systemu (systemy operacyjne, serwery aplikacji, bazy danych, szyny danych), infrastruktura sieciowa i serwerowa, na której posadowione i użytkowane jest oprogramowanie (w tym Środowisko Produkcyjne oraz Środowisko Testowe) oraz dokumentacja dotycząca wszelkich aspektów procesów budowy, rozwoju instalacji, odtwarzania, konfiguracji, użytkowania, rozwoju i utrzymania Systemu.
Środowisko Produkcyjne	Środowisko informatyczne, na którym działa System.
Środowisko Testowe	Środowisko informatyczne Zamawiającego zapewniające pełne odwzorowanie warstwy funkcji Systemu posadowionego na Środowisku Produkcyjnym, analogiczne do Środowiska Produkcyjnego w zakresie systemów operacyjnych, systemów bazodanowych oraz oprogramowania aplikacyjnego mogące się różnić od Środowiska Produkcyjnego mocą obliczeniową (liczba procesorów i RAM) oraz sposobem wirtualizacji.
Umowa	Umowa zawarta między Zamawiającym a Wykonawcą wraz ze wszystkimi aneksami i Załącznikami do Umowy.
Upoważniony Pracownik Zamawiającego	Pracownik Zamawiającego związany z realizacją przedmiotowej Umowy.
Usługa Asysty Technicznej i Konserwacji (ATiK)	Wszelkie usługi związane z zapewnieniem bezawaryjnego działania Systemu, realizowane przez Wykonawcę w zakresie opisanym w Umowie.
Usterka	Xxxx niebędąca Awarią ani Błędem, powodująca zakłócenie pracy Systemu lub poszczególnych jego części mogąca mieć wpływ na jego funkcjonalność, natomiast nieograniczająca możliwości operacyjnych Systemu w sposób mogący mieć negatywny wpływ na jakość i terminowość realizacji zadań PFRON.
Użytkownik	Osoba korzystająca z Systemu lub jego poszczególnych części. Użytkownik wewnętrzny (operator - pracownik PFRON).
Wada	Jakiekolwiek zaburzenie pracy Systemu objawiające się poprzez jego działanie w sposób odmienny od spodziewanego, przez co należy rozumieć między innymi: 1. działanie odmienne od sposobu opisanego w Dokumentacji Systemu; 2. działanie odmienne od standardów lub zwyczajów wynikających z praktyki ustalonej w toku bieżącej eksploatacji i administracji Systemu; 3. działanie odmienne od sposobu ustalonego na mocy wszelkich innych dokumentów lub ustaleń Stron. Wada może dotyczyć wszelkich możliwych nieprawidłowości w działaniu wszystkich komponentów Systemu, może dotyczyć jego dostępności, wydajności i reaktywności, cech mających wpływ na bezpieczeństwo i ciągłość działania oraz wszystkich innych cech funkcjonalnych i pozafunkcjonalnych. Wady mogą mieć charakter Awarii, Błędu lub Usterki.
WCAG	Minimalne wymagania zapisane w załączniku do ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych wraz z WCAG 2.1 – Web Content Accessibility Guidelines oraz wymagania zawarte w załączniku nr 2 do niniejszego OPZ – Dobre praktyki WCAG 2.1 w zamówieniach publicznych
Załącznik	Każdy tekst, materiał graficzny lub też inny przedmiot, odnoszący się do treści głównego dokumentu, dołączony do niego w celu uzupełnienia bądź uprawomocnienia jego treści.
Zamówienie	Przekazanie Wykonawcy zapotrzebowania na wykonanie określonych Produktów lub innych prac w ramach Modyfikacji i Rozwoju
Zgłoszenie	Przekazanie Wykonawcy zawiadomienia o Wadzie, złożenie pytań w ramach świadczenia Usługi Asysty Technicznej i Konserwacji oraz w okresie gwarancji.

2. Ogólny opis zamówienia

   1. Przedmiotem zamówienia jest świadczenie przez Wykonawcę na rzecz Zamawiającego:

      1. Usługi Asysty Technicznej i Konserwacji Systemu Pwind przez okres 48 miesięcy, w tym:

         1. w ramach zamówienia gwarantowanego 24 miesiące,

         2. w ramach opcji – maksymalnie 24 miesiące;

      2. Modyfikacji i Rozwoju Systemu Pwind w ramach maksymalnego limitu 40 000 Roboczogodzin, w tym:

         1. w ramach zamówienia gwarantowanego 20 000 Roboczogodzin,

         2. w ramach opcji – maksymalnie do 20 000 Roboczogodzin;

      3. Dostosowanie Systemu Pwind do wymagań w zakresie WCAG 2.1 AA, wymagania Zamawiającego zawiera Załącznik nr 1 do OPZ. Termin realizacji 24 miesiące od dnia podpisania Umowy.

3. Gwarancja i rękojmia.

Wykonawca udzieli Zamawiającemu gwarancji na okres 6 miesięcy liczonych od dnia zakończenia Umowy. Gwarancja wygasa przed upływem terminu wskazanego w zdaniu poprzednim w przypadku złożenia przez Zamawiającego Wykonawcy oświadczenia
o przejęciu ATiK-u Systemu, MR przez podmiot trzeci i zwolni Wykonawcę ze świadczenia usług gwarancyjnych. Gwarancja będzie świadczona z takimi samymi parametrami jak Usługa Asysty Technicznej i Konserwacji. Szczegóły dotyczące gwarancji i rękojmi będą zawarte w Umowie.

4. Prawa własności intelektualnej.

Szczegóły i zasady dotyczące przeniesienia autorskich majątkowych praw do Produktów oraz praw zależnych, a także udzielania i zapewniania licencji będą określone w Umowie.

5. Licencje.

Wykonawca zobowiązuje się zapewnić Zamawiającemu licencje na korzystanie
z Produktów, na warunkach i zasadach, które będą szczegółowo opisane w Umowie.

6. Inne zobowiązania.

Wykonawca zobowiązuje się wykonać inne zobowiązania na rzecz Zamawiającego, określone w Umowie i OPZ

7. Szczegółowe zasady realizacji zobowiązań Wykonawcy.

Niniejszy OPZ stanowi zestawienie ramowych wymagań niezbędnych do zrealizowania celu zamówienia. Lista wymagań zawarta w dokumencie stanowi opis zakresu zamówienia przedstawiony w sposób umożliwiający skalkulowanie wyceny przez Wykonawcę. Szczegółowe zasady realizacji zobowiązań Wykonawcy w ramach Przedmiotu Zamówienia, w tym zasady świadczenia usług/prac oraz kary umowne będzie określać Umowa.

8. Zobowiązanie do stosowania regulacji wewnętrznych PFRON.

Wykonawca zobowiązany jest do stosowania regulacji wewnętrznych PFRON w zakresie utrzymania i rozwoju systemów informatycznych PFRON. Dokumenty zawierające regulacje wewnętrzne PFRON zostaną przekazane Wykonawcy po zawarciu Umowy.

9. Wymagania dotyczące Usługi Asysty Technicznej i Konserwacji Systemu Pwind.

[Wymagania ogólne]

W ramach Usług Asysty Technicznej i Konserwacji Wykonawca zobowiązany jest do:

1. Zapewnienia ciągłości działania Systemu przez 24 godzin 7 dni w tygodniu 365 dni
   w roku („24/7/365”) przez cały okres obowiązywania Umowy z wyłączeniem Okna Serwisowego, pod warunkiem, że w ramach Okna Serwisowego realizowane są prace serwisowe wymagające wyłączenia Systemu lub powodujące tymczasową niedostępność Systemu i poszczególnych jego funkcjonalności. Zamawiający dopuszcza 10 godzin Niedostępności Systemu w miesiącu w Dniach i Godzinach Roboczych.

2. Utrzymania i administracji Sytemu w tym Oprogramowania Systemowego
   i Narzędziowego oraz Oprogramowania Standardowego/Obcego.

3. Utrzymania wartości parametrów związanych z Usługą Asysty Technicznej
   i Konserwacji na warunkach opisanych w Załączniku „Poziom świadczenia usług SLA” do Opisu Przedmiotu Zamówienia.

4. Zapewnienia wysokiego poziomu bezpieczeństwa Systemu i danych w nim przetwarzanych, między innymi poprzez instalowanie poprawek bezpieczeństwa dla Systemu, w tym do Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego w terminie 3 Dni Roboczych od dnia wydania ich przez producenta, wprowadzanie zmian konfiguracyjnych w Systemie, mających na celu zwiększenie poziomu bezpieczeństwa, zapewnienia zgodności
   z wymaganiami ujętymi w rozporządzeniu KRI, oraz dokumentach wewnętrznych Funduszu - Polityce Bezpieczeństwa Teleinformatycznego, Polityce Przetwarzania Danych Osobowych i Polityce Bezpieczeństwa Informacji. W szczególnych przypadkach, Zamawiający dopuszcza możliwość wydłużenia terminu wskazanego
   w zdaniu poprzednim, pod warunkiem przedstawienia przez Wykonawcę uzasadnienia. Na zmianę terminu musi wyrazić zgodę Zamawiający. Jeżeli realizacja w/w dostosowania Systemu będzie wymagała jego czasowego wyłączenia, wówczas na ten czas zawieszany jest ATK-01.

5. Przyjmowania Zgłoszeń i Naprawy Wad Systemu wraz z wyczerpującym uzasadnieniem przyczyn powstałej Wady.

6. Usuwania Wad Systemu wszystkich kategorii zgodnie z wymaganiami opisanymi
   w [Zasady obsługi zgłoszeń] Opisu Przedmiotu Zamówienia.

7. Wydawania rekomendacji dotyczących przeprowadzania zmian, aktualizacji
   i modernizacji Systemu.

8. Realizacja Zgłoszeń dotyczących zaleceń powstałych w wyniku audytu bezpieczeństwa teleinformatycznego. Jeżeli realizacja w/w zaleceń będzie wymagała czasowego wyłączenia Systemu, wówczas na ten czas zawieszany jest ATK-01.

9. Zapewnienia stałej opieki co najmniej jednego konsultanta do wsparcia przy rozwiązywaniu bieżących problemów związanych z funkcjonowaniem Systemu.

10. Bieżącej aktualizacji Dokumentacji Systemu oraz Kodów Źródłowych Systemu, przechowywanych w Repozytorium Projektu. Wykonawca ma obowiązek wraz
    z Protokołem Odbioru usługi dostarczyć zaktualizowaną Dokumentację Systemu
    i Kody Źródłowe oraz wskazać zmiany, jakie zostały wprowadzone w ramach Usługi Asysty Technicznej i Konserwacji w okresie, za który przedstawia Protokół Odbioru.

11. Zrealizowania raz na kwartał przeglądu i aktualizacji Kodów Źródłowych oraz Dokumentacji Systemu.

12. Realizacji Zgłoszeń dotyczących naprawy Wad, które dotyczą niespełniania standardu dostępności WCAG oraz zaleceń powstałych w wyniku audytu WCAG oraz dostosowanie Systemu do wymagań opisanych w Załączniku nr 3 do Opisu Przedmiotu Zamówienia, przez cały okres trwania Umowy. Jeżeli realizacja w/w zaleceń będzie wymagała czasowego wyłączenia Systemu, wówczas na ten czas zawieszany jest ATK-01.

13. Aktualizacji warstw Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego nie później niż miesiąc po udostępnieniu przez producentów danego oprogramowania nowej, stabilnej jego wersji po wcześniejszym uzgodnieniu z Zamawiający i w terminie na jaki wyrazi zgodę Zamawiający. Wyżej wymieniony termin może zostać w szczególnych przypadkach zmieniony przez Zamawiającego na dłuższy. W przypadku krytycznych poprawek bezpieczeństwa wymaga się ich niezwłocznej instalacji. Wymóg nie dotyczy aktualizacji, do których instalacji konieczne będzie poniesienie przez Wykonawcę dodatkowych kosztów z tytułu zakupu licencji – wówczas koszty i decyzję o instalacji ponosi Zamawiający. Na czas instalacji w/w poprawek zawieszone jest ATK-01. Jeżeli aktualizacja Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego będzie wymagała zmian w Kodzie Źródłowym Systemu Pwind Zamawiający może zlecić ją w ramach Rozwoju. W każdym takim przypadku Wykonawca zobowiązany jest przedstawić Zamawiającemu szczegółową analizę
    i dowody potwierdzające konieczność zmian Kodu Źródłowego Systemu.

14. Instalowania na Środowisku Produkcyjnym i Testowym, w czasie Okna Serwisowego, o ile Strony nie uzgodnią inaczej, Pakietów Aktualizacyjnych usuwających Wady mając na uwadze, że na czas instalacji zawieszone jest ATK-01. W przypadku błędów związanych z bezpieczeństwem Systemu, termin instalacji Pakietu Aktualizacyjnego musi zostać uzgodniony niezwłocznie. Instalacja takiego Pakietu może być wykonana poza Oknem Serwisowym.

15. Instalacji Pakietu Aktualizacji w ramach Rozwoju, z zastrzeżeniem wymagań dotyczących Oprogramowania Obcego lub Narzędziowego, realizowana będzie
    w terminie uzgodnionym z Zamawiającym, w czasie Okna Serwisowego, o ile Strony nie uzgodnią inaczej.

16. W Dni Robocze w Godzinach Roboczych Wykonawca musi realizować usługi od ATK-01 do ATK-12. Ponadto, Wykonawca na każde żądanie Zamawiającego zobowiązany jest do realizacji usługi opisanej w XXX-00, XXX-00.

17. W Dni Robocze pomiędzy Godzinami Roboczymi a Oknem Serwisowym Wykonawca musi realizować usługi od XXX-00, XXX-00, XXX-00, XXX-0, XXX-00, XXX-00. Ponadto, Wykonawca na każde żądanie Zamawiającego zobowiązany jest do realizacji usługi opisanej w XXX-00, XXX-00.

18. W Dni Robocze w Oknie Serwisowym Wykonawca musi realizować usługi XXX-00, XXX-00, XXX-00, XXX-0, XXX-00, XXX-00, XXX-0, XXX-00, XXX-00, ATK -15.

[Zasady obsługi zgłoszeń]

19. Zgłoszenie dokonywane jest za pośrednictwem Portalu Serwisowego przez upoważnionych Pracowników Wykonawcy oraz Zamawiającego.

20. Wszystkie Zgłoszenia muszą być przez Strony rejestrowane i prezentowane
    w Portalu Serwisowym, w sposób pozwalający na archiwizację danych o czasie
    i treści Zgłoszeń oraz Obejścia i Naprawy Wad.

21. Jeżeli Wada została wykryta przez Wykonawcę, Wykonawca niezwłocznie poinformuje Zamawiającego o wystąpieniu Wady, zarejestruje Zgłoszenie, 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.

22. Zgłoszenie Wady musi zawierać:

1. opis funkcjonalności Systemu, której dotyczy Wada;

2. opis zauważonych nieprawidłowości w działaniu Systemu, jeśli jest to możliwe, ilustrowanych zrzutami ekranów Systemu oraz krótkim scenariuszem sposobu uzyskania nieprawidłowości;

3. kategorię Wady;

4. informację o wersji Systemu;

5. informację, którego środowiska dotyczy Zgłoszenie.

23. W przypadku, gdy Zgłoszenie zostanie uznane przez Wykonawcę za niezasadne lub w przypadku uznania, iż Zamawiający w sposób nieprawidłowy określił kategorię Wady, Wykonawca zobowiązany jest do poinformowania Zamawiającego o wyniku analizy Zgłoszenia, przy czym ostateczna decyzja, co do realizacji oraz co do kwalifikacji określonej Wady należy do Zamawiającego.

24. Przyjmuje się, że do skutecznego Zgłoszenia Wady dochodzi z chwilą zarejestrowania Wady w Portalu Serwisowym i zaadresowanie jej do Wykonawcy.

25. W wyjątkowych sytuacjach, gdy Portal Serwisowy jest niedostępny, Zamawiający dopuszcza możliwość przekazania Zgłoszenia drogą telefoniczną lub mailową, na adres wskazany do komunikacji pomiędzy Stronami oraz w ten sam sposób zatwierdzenie Zgłoszenia i jego dalsze procedowanie. W chwili przywrócenia dostępności Portalu Serwisowego, Wykonawca jest zobowiązany do niezwłocznego uzupełnienia Zgłoszenia w Portalu Serwisowym. W sytuacji opisanej w zdaniu pierwszym, przyjmuje się, że do skutecznego Zgłoszenia Wady dochodzi z chwilą przekazania Wykonawcy Zgłoszenia drogą telefoniczną lub mailową, na adres wskazany do komunikacji pomiędzy Stronami.

26. Po otrzymaniu Zgłoszenia Wykonawca potwierdzi istnienie i kategorię Wady oraz przystąpi do jej Naprawy.

27. Jeśli Wykonawca stwierdzi w trakcie działań naprawczych, że dla dokonania usunięcia Xxxx niezbędne jest podjęcie przez Zamawiającego określonych czynności lub uzyskania dodatkowych wyjaśnień od Zamawiającego, Wykonawca niezwłocznie zwróci się do Zamawiającego z żądaniem wykonania odpowiednich działań. Czas na dokonanie odpowiednich działań przez Zamawiającego nie będzie wliczany do Czasu Naprawy Wady.

28. Usunięcie Wady nie może prowadzić do naruszenia struktur i integralności danych, do utraty danych lub wpływać negatywnie na funkcjonowanie Systemu 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.

29. Usunięcie Wady nie może powodować braku zgodności z zaleceniami WCAG.

30. Wykonawca przed zainstalowaniem Pakietu Aktualizacji na Środowisku Testowym wykona testy wewnętrzne zgodnie z Załącznikiem nr 6 do Opisu Przedmiotu Zamówienia.

31. Zainstalowanie przez Wykonawcę Pakietu Aktualizacji usuwającego Wadę na Środowisku Testowym uznaje się za zgłoszenie przez Wykonawcę gotowości do Odbioru Pakietu Aktualizacji. Zainstalowanie przez Wykonawcę Pakietu Aktualizacji usuwającego Wadę na Środowisku Produkcyjnym może się odbyć wyłącznie za zgodą Zamawiającego. W wyjątkowych sytuacjach za zgodą Zamawiającego Wykonawca może zainstalować Pakiet Aktualizacji bezpośrednio na Środowisku Produkcyjnym.

32. Po zgłoszeniu gotowości Odbioru Pakietu Aktualizacji Zamawiający przystąpi niezwłocznie do jego weryfikacji.

33. Zamawiający ma prawo do weryfikacji należytego wykonania usługi dowolną metodą. Zamawiający ma w szczególności prawo przeprowadzić testy za pomocą samodzielnie zdefiniowanych scenariuszy testowych lub przez zaangażowanie podmiotu trzeciego działającego w imieniu Xxxxxxxxxxxxx.

34. W przypadku, gdy Pakiet Aktualizacji nie usunie zgłoszonej Wady lub spowoduje pojawienie się nowej Wady w Systemie, Zgłoszenie uznaje się za niezakończone.

35. Do Czasu Naprawy Zgłoszenia nie są wliczane okresy potwierdzania przez Zamawiającego skuteczności dostarczonych poprawek oraz za zgodą Zamawiającego czas pomiędzy odbiorem przez Zamawiającego Pakietu Aktualizacji na Środowisku Testowym a zainstalowaniem Pakietu Aktualizacji na Środowisku Produkcyjnym.

36. Wykonawca zobowiązany jest do zainstalowania Pakietu Aktualizacji najpóźniej
    w najbliższym Oknie Serwisowym po dokonaniu odbioru przez Zamawiającego Pakietu Aktualizacji, chyba że Zamawiający postanowi inaczej.

37. Jeżeli Wykonawca nie dokona Naprawy / Obejścia w terminach, o których mowa
    w Załączniku nr 5 Opisu Przedmiotu Zamówienia (Poziom świadczenia usług SLA), Zamawiający może:

1. zawiadamiając uprzednio Wykonawcę, usunąć Wadę we własnym zakresie lub powierzyć jej usunięcie innemu podmiotowi trzeciemu na koszt Wykonawcy, co nie spowoduje utraty przysługujących Zamawiającemu uprawnień z tytułu gwarancji - przy czym koszty poniesione przez Zamawiającego przy usunięciu Wady będą potrącone z wynagrodzenia przysługującego Wykonawcy lub
   z zabezpieczenia należytego wykonania Umowy;

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

38. Zakończenie instalacji Pakietu Aktualizacji na Środowisku Produkcyjnym kończy obsługę Zgłoszenia.

39. Zamknięcie Zgłoszenia w Portalu Serwisowym dokonywane jest po instalacji Pakietu Aktualizacji na Środowisku Produkcyjnym, przez upoważnionych Pracowników Zamawiającego.

40. Wykonawca zobowiązany jest do uzupełnienia Zgłoszenia w Portalu Serwisowym
    o informacje na temat przyczyn wystąpienia Wady oraz szczegółowego opisu sposobu jej usunięcia z Systemu. Zamawiający dopiero po uzyskaniu powyższych informacji przystąpi do zamknięcia Zgłoszenia.

41. W przypadku nieuzupełnienia Zgłoszenia o wymagane w punkcie ATK-40 informacje Zamawiający nie podpisze Protokołu Odbioru Usługi Asysty Technicznej
    i Konserwacji za dany okres rozliczeniowy.

42. Po zamknięciu Zgłoszenia Wykonawca dostarcza zaktualizowaną Dokumentacje Systemu oraz zaktualizowaną wersje Kodów Źródłowych zgodnie z zasadami opisanymi w Pkt.15 Opisu Przedmiotu Zamówienia.

[Zasady udzielania stałych konsultacji]

43. Konsultacje zgłaszane są w formie Pytań za pośrednictwem Portalu Serwisowego przez upoważnionych Pracowników Zamawiającego wskazanych w Umowie.

44. W wyjątkowych sytuacjach, gdy Portal Serwisowy jest niedostępny, Zamawiający dopuszcza możliwość przekazania Pytań drogą telefoniczną lub mailową, na adres wskazany do komunikacji pomiędzy Stronami oraz w ten sam sposób zatwierdzenie Pytań i ich dalsze procedowanie. W chwili przywrócenia dostępności Portalu Serwisowego, Wykonawca jest zobowiązany do niezwłocznego uzupełnienia Pytań w Portalu Serwisowym.

45. Konsultacje udzielane są za pośrednictwem Portalu Serwisowego przez upoważnionych pracowników Wykonawcy.

46. Wszystkie materiały z konsultacji muszą być przez Xxxxxx rejestrowane
    i prezentowane w Portalu Serwisowym w sposób pozwalający na archiwizację danych o czasie i treści konsultacji (zapytań i odpowiedzi).

47. Przyjmuje się, że do skutecznego zawiadomienia dochodzi z chwilą zarejestrowania
    i zaadresowania Zgłoszenia Pytań w Portalu Serwisowym.

48. Jeżeli Wykonawca nie będzie w stanie udzielić odpowiedzi w czasie określonym
    w Załączniku nr 5 do Opisu Przedmiotu Zamówienia, jest zobowiązany powiadomić o tym fakcie Zamawiającego, z którym zostanie ustalony nowy termin udzielenia odpowiedzi.

49. Jeżeli udzielenie odpowiedzi będzie wymagało przez Wykonawcę kontaktu
    z podmiotem trzecim (Użytkownikiem zewnętrznym), w szczególności za pośrednictwem poczty elektronicznej, telefonicznie, Wykonawca niezwłocznie poinformuje o tym fakcie Zamawiającego i uzyska jego zgodę.

50. W ramach udzielonych odpowiedzi dotyczących Przypadków Szczególnych, Wykonawca opracuje i udostępni Zamawiającemu instrukcję opisującą rozwiązanie danego Przypadku Szczególnego.

[Zasady aktualizacji Systemu]

51. Aktualizacja Systemu realizowana jest dla: nowych wersji Systemu wytworzonych
    w związku ze zmianami Sprzętu i Oprogramowania Systemowego i Narzędziowego; nowych wersji lub aktualizacji Systemu lub jego poszczególnych części w ramach wersji głównej Systemu lub części Systemu, utworzonych z własnej inicjatywy przez Wykonawcę z uwzględnieniem zapisów poniżej, jako kolejne wersje Systemu lub części Systemu, zawierające usprawnienia w porównaniu z poprzednimi wersjami Sytemu lub części Sytemu; dostosowania Systemu do bezwzględnie obowiązujących przepisów prawa wpływających na sposób funkcjonowania oraz funkcjonalności Systemu, w tym również określających minimalne wymagania techniczne dla systemów informatycznych eksploatowanych przez Zamawiającego.

52. Jeżeli Wykonawca opracuje samodzielnie, niezależnie od zobowiązań wynikających
    z zamówienia jakiekolwiek aktualizacje polegające na uaktualnieniu Systemu, służące do usunięcia stwierdzonych nieprawidłowości pracy Systemu, dodania nowych funkcjonalności lub uwzględnienia zmian w przepisach prawa - Wykonawca zobowiązany jest niezwłocznie do poinformowania Zamawiającego o fakcie opracowania powyższych aktualizacji oraz ich przedstawienia. Wykonawca zobowiązany jest również poinformować Zamawiającego o ewentualnych skutkach zainstalowania Pakietu Aktualizacji, w szczególności ich wpływie na sposób jego funkcjonowania oraz sposób korzystania z Systemu.

53. Zasady aktualizacji Systemu obejmują również aktualizację Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego.

54. Aktualizacja Systemu przez Wykonawcę obejmuje w szczególności:

1. przygotowanie i uzgodnienie z Zamawiającym planu wdrożenia wersji Systemu, aby Zamawiający z odpowiednim wyprzedzeniem mógł poinformować Użytkowników o przerwie w działaniu Systemu i planowanym zakresie aktualizacji;

2. dostarczenie aktualizacji;

3. instalację aktualizacji na Środowisku Testowym;

4. testy Systemu na Środowisku Testowym;

5. instalację aktualizacji na pozostałych środowiskach;

6. wsparcie przy uruchamianiu Systemu na wyżej wymienionych środowiskach;

7. aktualizacje Dokumentacji Systemu oraz Kodów Źródłowych w formie elektronicznej;

8. podniesienie numeru wersji Systemu.

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

55. W ramach Przedmiotu Zamówienia Wykonawca będzie realizował prace związane
    z utrzymaniem, konserwacją, administracją i aktualizacją systemów operacyjnych oraz oprogramowania podmiotów trzecich (w tym w szczególności silników baz danych, serwerów aplikacyjnych oraz bibliotek programistycznych i narzędzi), które wykorzystywane są do prawidłowego działania Systemu podlegające Usłudze ATiK,
    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 podmiotów 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. Zamawiający zastrzega sobie prawo do wydłużenia terminu, o którym mowa
   w zdaniu poprzednim za wcześniejszym poinformowaniem Wykonawcy. 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 (muszą one zawierać się w zamkniętym katalogu parametrów konfiguracyjnych maszyn wirtualnych właściwym dla wirtualizatora). 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 Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego oraz Systemu. W/w czynności realizowane przez Wykonawcę muszą zostać zrealizowane w terminie nie dłuższym niż 5 Dni Roboczych od momentu poinformowania Wykonawcy o dostępności dodatkowych zasobów.
   W uzasadnionych przypadkach termin wskazany w zdaniu poprzednim może zostać wydłużony za zgodą Zamawiającego jednak o nie więcej niż 5 Dni Roboczych;

2. uaktualnianiem Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego oraz Systemu do wersji aktualnie wspieranej. Przez uaktualnienie do wersji aktualnie wspieranych Zamawiający rozumie czynności związane
   z podniesieniem wersji Oprogramowania Systemowego i Narzędziowego, Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego, Systemu oraz wykonanie testów na Środowiskach Produkcyjnym i Testowym, 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. instalowaniem poprawek i łat bezpieczeństwa dla Oprogramowania Systemowego i Narzędziowego, Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego oraz Systemu,

4. zarządzaniem konfiguracją poszczególnych elementów Systemu oraz wersji Oprogramowania Systemowego i Narzędziowego, Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego w celu optymalizowania działania i zapewnienia ciągłości działania Systemu;

5. administrowaniem Oprogramowaniem Systemowym i Narzędziowym, Oprogramowaniem Standardowym/Obcym, Oprogramowaniem Zamawiającego oraz Systemem, w tym w szczególności dostosowywanie w/w oprogramowania w zakresie zapewniania oczekiwanego poziomu optymalizacji działania wyżej wskazanego oprogramowania;

6. analizowaniem oraz przygotowaniem wytycznych w zakresie możliwości rozwojowych, realizacji zmian technologicznych mających na celu optymalizację pracy Oprogramowania Systemowego i Narzędziowego, Oprogramowania Standardowego/Obcego, Oprogramowania Zamawiającego oraz Systemu z jednoznacznym wskazaniem możliwości migracji do wskazanych przez Zamawiającego lub Wykonawcę rozwiązań, w tym
   w szczególności opis czynności do wykonania, przewidywaną pracochłonność oraz potencjalne ryzyka;

7. administrowaniem certyfikatami służącymi do integracji Systemu z innymi systemami zewnętrznymi i wewnętrznymi.

56. Wykonawca w terminie do 60 Dni Roboczych od dnia zawarcia Umowy zweryfikuje konfigurację i działanie obecnie wykorzystywanego u Zamawiającego narzędzia do monitorowania zasobów (Zabbix) oraz w przypadku konieczności wprowadzenia zmian w konfiguracji powyższego narzędzia wykona jego rekonfigurację. Wykonawca zobowiązany jest do przedstawienia raportu z wykonanych prac.

57. Wykonawca określi wszystkie parametry konfiguracyjne polityk archiwizacji danych Oprogramowania objętego 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.

58. Wykonawca zobowiązany jest do okresowego analizowania i weryfikowania 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 kalendarzowych 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 Roboczych od otrzymania protokołu zaakceptuje go lub zgłosi uwagi. W terminie do 10 Dni Roboczych 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.

59. Wykonawca zobowiązany jest do przeprowadzania okresowych testów procedur odzyskiwania Systemu 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 kalendarzowych 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 10 Dni Roboczych 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.

60. W przypadku uznania, że procedury odzyskiwania Systemu po Awarii lub scenariusze “Disaster recovery” są niekompletne, Wykonawca w ramach ATiK zobowiązany jest do aktualizacji wyżej wymienionych dokumentów w terminie 10 Dni Roboczych od dnia podpisania przez Zamawiającego Protokołu Odbioru bez zastrzeżeń.

10. Wymagania dotyczące Rozwoju Systemu Pwind

[Wymagania ogólne]

W ramach Rozwoju Systemu Wykonawca zobowiązany jest do:

1. Opracowywania i wdrażania nowych funkcjonalności Systemu oraz dokonywania wszelkich innych zmian w Systemie w zakresie wskazanym przez Zamawiającego,
   w tym wynikających ze zmian przepisów prawa, zaleceń audytorów, kontrolerów, zmieniających się wymogów technologicznych oraz optymalizacji procesów biznesowych i systemowych (np. parametryzację słowników, algorytmów).

2. Dokonywania zmian w Systemie na potrzeby integracji z innymi systemami wykorzystywanymi przez Zamawiającego.

3. Utrzymania wartości parametrów związanych z Rozwojem na warunkach opisanych w Załączniku nr 5 do Opisu Przedmiotu Zamówienia.

[Zasady realizacji Rozwoju]

4. Wykonawca nie może odmówić realizacji złożonego Wniosku i Zlecenia, poza przypadkami, gdy ich realizacja spowoduje przekroczenie limitu Roboczogodzin lub terminu realizacji Umowy.

5. Zamawiający może wstrzymać lub zakończyć realizację każdego z etapów Rozwoju
   w dowolnie wybranym momencie. W razie zakończenia realizacji w trybie określonym w zdaniu poprzednim, Wykonawcy przysługuje wynagrodzenia za udokumentowane prace, z zastrzeżeniem postanowień UMR-26.

6. Zamawiający szacuje wykorzystanie w ramach jednego miesiąca maksymalnie do 3000 Roboczogodzin. Wykonawca zobowiązany jest do dysponowania zespołem projektowo-programowym umożliwiającym prace w powyższym zakresie. Jednocześnie Zamawiający zastrzega sobie możliwość zwiększenia lub zmniejszenie ww. liczby Roboczogodzin w uzgodnieniu z Wykonawcą.

7. 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 modyfikacji w ramach zmian Systemu realizowanych metodyką Kaskadową (ang. Waterfall) oraz nie więcej niż 2 Sprinty zachodzące na siebie.

8. W przypadku, gdy do realizacji prac w ramach Rozwoju niezbędne jest użycie licencji, Wykonawca zobowiązany jest do wykorzystania licencji typu open source. Stosowanie płatnych licencji dopuszczalne jest wyłącznie w sytuacji braku odpowiedniej licencji typu open source. W takim przypadku Wykonawca udzieli Zamawiającemu lub zagwarantuje udzielenie na rzecz Zamawiającego przez podmioty trzecie, przenoszalnych, bezterminowych i niewyłącznych licencji na korzystanie z takiego Oprogramowania, zgodnie z postanowieniami Umowy po udzieleniu przez Zamawiającego zgody na zastosowanie takiej licencji lub po dostarczeniu jej przez Zamawiającego. Koszt pozyskania licencji spoczywa na Wykonawcy. Zgoda Zamawiającego wymagana jest również w przypadku konieczności zastosowania oprogramowania open-source.

9. Zrealizowane prace nie mogą prowadzić do naruszenia struktur i integralności danych, do utraty danych lub wpływać negatywnie na funkcjonowanie Systemu lub innych składników infrastruktury Zamawiającego. W przypadku, gdy wykonanie prac wiąże się z ryzykiem utraty danych, Wykonawca zobowiązany jest poinformować o tym Zamawiającego przed przystąpieniem do realizacji prac w ramach Rozwoju.

10. W przypadku, gdy realizacja prac spowoduje pojawienie się Wady w Systemie, Wykonawca zobowiązany jest do wstrzymania prac w ramach Rozwoju, do czasu skutecznego usunięcia Wady.

11. Wykonawca zobowiązany jest do zapewnienia zgodności Produktów przekazywanych w ramach realizacji Rozwoju ze standardem WCAG oraz zaleceniami zawartymi w Załączniku nr 3 do Opisu Przedmiotu Zamówienia.

12. Wszystkie Wnioski i Zlecenia oraz inne materiały z realizacji Rozwoju (w tym
    z testów) muszą być przez Strony rejestrowane i prezentowane w Portalu Serwisowym, chyba że Zamawiający postanowi inaczej.

13. Spotkanie inicjujące Rozwój zostanie zorganizowane w formie i terminie ustalonym prze Strony, w terminie do 10 dni kalendarzowych od dnia zawarcia Umowy, chyba że Strony uzgodnią inny termin.

14. Rozwój Systemu będzie realizowany w oparciu o metodykę Scrum lub Waterfall
    w zależności od potrzeb Zamawiającego. Decyzja o sposobie realizacji Rozwoju należy do Zamawiającego.

[Wymogi dotyczące realizacji Rozwoju Systemu w metodyce Scrum]

15. W czasie spotkania, o którym mowa w pkt UMR-13:

1. Zamawiający zapozna zespół Wykonawcy między innymi z:

• artefaktami analitycznymi opisującymi System,

• aktualnym Product Backlog,

• zagadnieniami rozwojowymi,

• z Repozytorium Projektowym.

2. Strony ustalą harmonogram spotkań analitycznych dla 1 Sprintu realizacyjnego.

16. Zadania do realizacji w trybie zwinnym będą zbierane w postaci Product Backloga.

17. Tryb zwinny realizowany będzie w formie Sprintów.

18. Zadania Sprintu do poszczególnych Sprintów wybierane będą z Product Backloga, po wcześniejszym uszczegółowieniu i priorytetyzacji przez Właściciela Produktu oraz zaakceptowaniu przez Zamawiającego wyceny w Roboczogodzinach za realizację historii wchodzących w zakres danego Sprintu.

19. Każdy Sprint będzie przekazywany do realizacji na podstawie odrębnego Zlecenia. Wzór Zlecenia Sprintu stanowi Załącznik nr 5 do Umowy.

20. Cel Sprintu zostanie wskazany przez Właściciela Produktu w Zleceniu. Załącznikiem do Zlecenia będzie każdorazowo wykaz historii wchodzących w skład danego Zlecenia.

21. Odbiór Sprintu następuje wyłącznie po osiągnięciu celu Sprintu oraz po przeprowadzeniu przez Zamawiającego procedury odbiorowej, w tym testów akceptacyjnych.

22. Wykonawca w ramach każdego Sprintu zobowiązany jest na bieżąco aktualizować Dokumentację Systemu oraz Kodów Źródłowych przechowywanych
    w Repozytorium Projektu, zgodnie z wymaganiami opisanymi w Pkt. 15 Opisu Przedmiotu Zamówienia. Wykonawca wraz ze zgłoszeniem gotowości do Odbioru Sprintu ma obowiązek dostarczyć zaktualizowaną Dokumentację Systemu i Kody Źródłowe oraz wskazać zmiany, jakie zostały wprowadzone w ramach Sprintu.

23. Opis metody prowadzenia procesu wytwórczego w ramach Rozwoju stanowi Załącznik nr 1 do OPZ.

24. Wykonawca, w terminie uzgodnionym z Zamawiającym lub w innym uzgodnionym terminie, zobowiązany jest przeprowadzić warsztaty instruktażowe on-line
    z funkcjonalności Systemu Pwind dla Użytkowników i przedstawicieli Zamawiającego, jeżeli Zlecenie zawiera takie zapotrzebowanie. Zamawiający zastrzega sobie prawo do realizacji warsztatów również w lokalizacji Zamawiającego. Platformę szkoleniową do przeprowadzenia warsztatów typu MS Teams zapewni Zamawiający, chyba że Wykonawca będzie chciał wykorzystać
    w tym celu własne narzędzie.

[Wymogi dotyczące realizacji Rozwoju Systemu z wykorzystaniem modelu Waterfall]

25. Procedura realizacji Rozwoju Systemu z wykorzystaniem Waterfall składa się
    z etapów:

• Etap 1 – Analiza Wstępna Zlecenia,

• Etap 2 – Projekt Zmian,

• Etap 3 - zawarcie i realizacja Zlecenia.

[Wymagania na realizację Etapu 1 (Analiza Wstępna Zlecenia) oraz Etapu 2 (Projekt Zmian)]

26. Upoważniony Pracownik Zamawiającego tworzy Wniosek w Portalu Serwisowym zawierające: krótki opis (koncepcje) procesu biznesowego, w miarę możliwości: funkcjonalności oraz zakres danych oraz inne informacje mogące mieć wpływ na realizację Zlecenia.

27. Wykonawca zobowiązany jest, by w terminie 5 Dni Roboczych od dnia zgłoszenia Wniosku w Portalu Serwisowym dostarczyć nieodpłatnie wynik realizacji Analizy Wstępnej. Analiza Wstępna ma zawierać co najmniej: harmonogram realizacji Etapu 2, wstępny harmonogram realizacji Etapu 3, wycenę Etapu 2
    w Roboczogodzinach, szacowaną wycenę Etapu 3 w Roboczogodzinach, ogólną koncepcję zmian Systemu oraz ogólny zakres dziedziny Systemu/funkcjonalności Systemu, które będą przedmiotem Etapu 3. Akceptacja Analizy Wstępnej przez Zamawiającego warunkuje realizację Etapu 2. Wykonawca przystępuje do realizacji Etapu 2 (pkt UMR-28) dopiero po przekazaniu przez Zamawiającego informacji
    o akceptacji Analizy Wstępnej w Portalu Serwisowym. Zamawiający zastrzega sobie prawo do rezygnacji z realizacji Etapu 2 i 3 po Analizie Wstępnej.

Zamawiający zastrzega sobie prawo do zlecenia Wykonawcy realizacji Etapu 3 bez konieczności przeprowadzenia Etapu 2 w sytuacjach uzasadnionych przedmiotem Zlecenia.

28. Wykonawca zgodnie z harmonogramem przedstawionym w Analizie Wstępnej, przedstawi Zamawiającemu projekt zmian w warstwach logiki biznesowej, danych, uprawnień, architektury fizycznej i logicznej Systemu, konfiguracji komponentów sprzętowych, zawierający w szczególności (w zależności od przedmiotu Zadania) (dalej jako „Projekt Zmian”):

1. opis dziedziny Systemu oraz specyfikację wymagań w obszarze funkcjonalnym
   i (poza funkcjonalnym), które będą przedmiotem prac programistycznych;

2. opis architektury Systemu po zmianach (głównie perspektywa biznesowa, perspektywa logiczna, oraz perspektywa danych), o ile dotyczy,

3. projekty wszystkich modułów, które będą przedmiotem prac o ile dotyczy. Minimalny zakres informacji to:

• opis elementów struktury (tj. komponentów, podmodułów itp.),

• opis głównych scenariuszy działania a w tym opis algorytmów po zmianach,

• opis i makiety interfejsów po zmianach,

• opis logicznego modelu danych wykorzystywanych w modułach,

• opis modelu wdrożenia;

4. wycenę realizacji Etapu 3 w Roboczogodzinach z rozbiciem na poszczególne zadania składowe (podzadania) w podziale uzgodnionym z Zamawiającym;

5. zakres niezbędnego współdziałania Zamawiającego;

6. harmonogram realizacji prac;

7. informację o wpływie realizacji prac w ramach Rozwoju na integralność, wydajność oraz bezpieczeństwo Systemu;

8. wykaz niezbędnych licencji do uruchomienia zmian, o ile będą wymagane;

9. wykaz zmian w infrastrukturze informatycznej Systemu, o ile dotyczy;

10. propozycję przeprowadzenia warsztatów z nowych funkcjonalności dla Użytkowników i przedstawicieli Zamawiającego, o ile Zlecenie je obejmuje.

29. Wycena, o której mowa w pkt UMR-28 powyżej musi zawierać, odrębnie dla każdej niżej wymienionej pozycji szacunkową liczbę Roboczogodzin niezbędną do przeprowadzenia między innymi (zakres wyceny będzie uzależniony od Zlecenia):

1. prac analitycznych,

2. prac programistycznych,

3. zmian w Kodzie Źródłowym,

4. testów,

5. warsztatów z nowych funkcjonalności dla Użytkowników i przedstawicieli Zamawiającego, jeśli Zlecenie zawiera takie zapotrzebowanie.

30. W uzasadnionych przypadkach, Wykonawca może zwrócić się do Zamawiającego
    z wnioskiem o zmianę terminów dostarczenia Produktów Etapu 1 lub Etapu 2. Decyzja o akceptacji wniosku należy do Zamawiającego.

31. Strony mogą ustalić inny wykaz i zakres dla dokumentacji, o której mowa w UMR -28 dostarczanej w ramach Etapu 2.

32. Dopuszcza się by w ramach Zlecenia na Rozwój wytwarzane były inne Produkty będące częścią składową Systemu lub powiązane z Systemem, nie będące oprogramowaniem. W takim przypadku Strony mogą ustalić indywidualny tryb
    i zakres realizacji Zlecenia.

33. Jeśli w ramach realizacji Rozwoju istnieje techniczna możliwość zastąpienia komercyjnego rozwiązania autorstwa podmiotu trzeciego lub Wykonawcy przez oprogramowanie otwartoźródłowe, Wykonawca jest zobowiązany uwzględnić ten fakt w przedstawionym Projekcie Zmian, stwarzając Zamawiającemu możliwość podjęcia decyzji w zakresie doboru konkretnego rozwiązania. Szczegółowe zasady dotyczące oprogramowania otwartoźródłowego będzie określała Umowa.

34. Zamawiającemu przysługuje prawo weryfikacji i akceptacji sposobu oraz czasochłonności wykonania przez Wykonawcę prac, który został przedstawiony przez Wykonawcę w Etapie 2 (Projekcie Zmian). Ostateczna akceptacja wyceny czasochłonności prac należy do Zamawiającego. W przypadku zaistnienia różnicy zdań między Stronami dotyczącej wiarygodności przedstawionych rozliczeń i szacunków czasochłonności, Strony zobowiązują się do podporządkowania się opinii niezależnego od Stron biegłego i rozliczenia prac zrealizowanych w ramach Zlecenia według podanych przez niego wskazań. Biegły zostanie wybrany przez Strony metodą zapewniającą bezstronność, a także będzie osobą posiadającą potwierdzoną certyfikatami wiedzę z zakresu wymiarowania przedsięwzięć informatycznych. Biegły będzie wybierany z listy osób wpisanych na listę rzeczoznawców Polskiego Towarzystwa Informatycznego, przy czym pod uwagę będą brane jedynie osoby wpisane na listę nie później niż w dniu publikacji ogłoszenia. Koszt sporządzenia opinii ponosi strona przeciwna tej, do racji której biegły się przychyli. Jeśli biegły nie przychyli się do racji żadnej ze Stron, obie Strony ponoszą koszt sporządzenia opinii po połowie.

35. Zamawiający zobowiązany jest do przekazania Wykonawcy informacji czy akceptuje, czy odrzuca przedstawiony przez Wykonawcę Projekt Zmian zrealizowany w ramach Etapu 2.

36. Strony mogą dokonywać zmian i uzupełnień Projektu Zmian w trybie roboczym.

37. Wycena wykonania Zlecenia uzgodniona w Etapie 2 (pkt UMR-28) będzie

stanowić podstawę wyliczenia wynagrodzenia za wykonanie danego Zlecenia. Jeżeli Zamawiający odstąpi od realizacji Etapu 3 po pozytywnym Odbiorze przez Xxxxxxxxxxxxx Projektu Zmian, o którym mowa w UMR-28, Wykonawcy będzie przysługiwało wynagrodzenie obliczone na podstawie wyceny Projektu Zmian,
o której mowa w Etapie 1 (UMR-27) i będzie płatne na podstawie podpisanego przez Zamawiającego bez zastrzeżeń protokołu odbioru oraz prawidłowo wystawionej faktury VAT.

38. Zamawiający ma prawo zrezygnować z realizacji Etapu 3 albo zlecić jego realizację Wykonawcy.

39. Projekt Zmian przygotowany w ramach Etapu 2 podlega odbiorowi na zasadach opisanych w Umowie.

[Etap 3 zawarcie i realizacja Zlecenia – inicjowana przez Zamawiającego]

40. Wykonawca przystępuje do realizacji Etapu 3 po otrzymaniu od Zamawiającego Zlecenia za pośrednictwem Portalu Serwisowego.

41. W trakcie trwania Etapu 3, ale przed przekazaniem Produktów tego Etapu do Odbioru, Zamawiający może zgłosić wniosek o zmianę wymagań, a Wykonawca zobowiązany jest uwzględnić zgłoszone zmiany wymagań. W takim przypadku Wykonawca przedstawi Zamawiającemu poprawkę do Projektu Zmian zawierającą zgłoszone zmiany wymagań, wycenę ich wykonania oraz wpływ na harmonogram realizacji Zlecenia w terminie 5 Dni Roboczych od dnia otrzymania od Zamawiającego wniosku o zmianę wymagań, o ile Strony nie postanowią inaczej.

42. W uzasadnionych przypadkach Zamawiający dopuszcza zmianę terminów określonych w Projekcie Zmian danego Zlecenia, w tym przekazania produktu do Odbioru, w stosunku do terminów uzgodnionych w Zleceniu. Każdorazowa zmiana terminu w harmonogramie wymaga zgody Zamawiającego w formie dokumentowej. Zamawiający nie wyrazi zgody na zmianę terminu określonego
    w harmonogramie bez uzasadnienia Wykonawcy w sytuacji, gdy Wykonawca wnosi o przesunięcie terminu.

43. Wykonawca przeprowadza testy wewnętrzne zgodnie z wymaganiami opisanymi w załączniku nr 5 do OPZ na Środowisku Testowym według przygotowanych przez siebie scenariuszy testowych i potwierdza Zamawiającemu ich wykonanie poprzez wprowadzenie stosownej informacji do Portalu Serwisowego oraz zamieszczenie dokumentu Raportu z Testów (RT) w Repozytorium Projektowym.

44. Po przeprowadzeniu testów wewnętrznych Wykonawca zgłasza w formie dokumentowej Zamawiającemu gotowość do testów akceptacyjnych.

45. Poinformowanie Zamawiającego w formie dokumentowej o gotowości do zainstalowania przez Wykonawcę Pakietu Aktualizacji na Środowisku Testowym uznaje się za zgłoszenie przez Wykonawcę gotowości do Odbioru realizowanego Zlecenia.

46. Wykonawca wraz z przekazaniem przedmiotu Zlecenia do Odbioru, zobowiązany jest dostarczyć zaktualizowaną zgodnie z wymogami opisanymi w Pkt. 15 Opisu Przedmiotu Zamówienia, kompletną zaktualizowaną Dokumentację Systemu. Przekazana zaktualizowana Dokumentacja Systemu musi zawierać wszelkie informacje pozwalające Zamawiającemu lub podmiotom wybranym przez Zamawiającego na samodzielne korzystanie z Produktów, a także na ich samodzielne utrzymywanie i rozwój. Przekazanie przez Wykonawcę zaktualizowanej Dokumentacji Systemu jest warunkiem niezbędnym do dokonania Odbioru.

47. Po zgłoszeniu gotowości Odbioru Zamawiający przystąpi niezwłocznie do weryfikacji Pakietu Aktualizacji oraz zaktualizowanej Dokumentacji Systemu.

48. Zamawiający ma prawo do weryfikacji należytego wykonania Zlecenia dowolną metodą. Zamawiający ma prawo przeprowadzić testy za pomocą samodzielnie zdefiniowanych scenariuszy testowych.

49. Wykonawca ma obowiązek dostarczyć Zamawiającemu dokumenty, w tym raporty, scenariusze testowe, najpóźniej w momencie zgłoszenia Zamawiającemu przez Wykonawcę gotowości do Odbioru (patrz pkt UMR-46).

50. Po weryfikacji przedmiotu Odbioru Zamawiający niezwłocznie potwierdzi wykonanie (Odbiór pozytywny) lub stwierdzi niewykonanie Zlecenia (Odbiór negatywny). W przypadku Odbioru negatywnego Produkt Zlecenia podlega dalszym pracom, do czasu jego należytego wykonania. Kara umowna z tytułu nienależytego wykonania przedmiotu Zlecenia zostanie naliczona Wykonawcy po Odbiorze negatywnym jednej iteracji odbiorowej.

51. Bez uszczerbku dla innych postanowień Umowy, jeżeli Wykonawca nie wykona Zlecenia w terminie wskazanym w Zleceniu, Zamawiający może:

1. wydłużyć termin wykonania Zlecenia na pisemną prośbę Wykonawcy zawierającą uzasadnienie i zmianę terminu Zlecenia, o ile Wykonawca prośbę skieruje przed upływem terminu wykonania Zlecenia;

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

52. Wykonawca po zakończeniu testów akceptacyjnych przez Zamawiającego
    i dokonaniu Odbioru pozytywnego ma obowiązek, w terminie 3 Dni Roboczych, chyba że Zamawiający postanowi inaczej, instalacji Pakietu Aktualizacji na wszystkich Środowiskach Zamawiającego.

53. Wykonawca przed Instalacją Pakietu Aktualizacji na Środowiskach Produkcyjnym, w terminie uzgodnionym z Zamawiającym lub w innym uzgodnionym terminie, zobowiązany jest przeprowadzić warsztaty instruktażowe on-line z funkcjonalności dla Użytkowników i przedstawicieli Zamawiającego, jeżeli Zlecenie zawiera takie zapotrzebowanie. Zamawiający zastrzega sobie prawo do realizacji warsztatów również w lokalizacji Zamawiającego. Platformę szkoleniową do przeprowadzenia warsztatów typu MS Teams zapewni Zamawiający, chyba że Wykonawca będzie chciał wykorzystać w tym celu własne narzędzie.

54. Instalacja Pakietu Aktualizacji na wszystkich środowiskach Zamawiającego realizowana będzie w czasie Okna Serwisowego, o ile Strony nie uzgodnią inaczej.

55. Zamawiający zastrzega sobie prawo rezygnacji z instalacji Pakietu Aktualizacji.

56. Warunkiem zakończenia realizacji Zlecenia jest:

1. Pozytywny Odbiór Zlecenia;

2. zainstalowanie przez Wykonawcę Pakietu Aktualizacji na wszystkich Środowiskach Zamawiającego, chyba że Zamawiający postanowi inaczej;

3. dostarczenie Zamawiającemu przez Wykonawcę zaktualizowanej Dokumentacji Systemu (patrz pkt UMR-47);

4. przeprowadzenie przez Wykonawcę warsztatów, o których mowa w pkt UMR-54 (o ile Zlecenie obejmuje warsztaty).

57. Zakończenie realizacji Zlecenia potwierdzane jest poprzez zamknięcie Zadania
    w Portalu Serwisowym przez upoważnionego pracownika Zamawiającego.

58. Zamknięcie Zadania w Portalu Serwisowym oznacza możliwość ujęcia Zlecenia
    w Protokole Odbioru Rozwoju, którego wzór zawiera Załącznik nr 3 do Umowy.

59. Podpisanie Protokołu Odbioru, o którym mowa w pkt UMR-58 powyżej, przez Zamawiającego bez zastrzeżeń jest podstawą do wystawienia przez Wykonawcę faktury. Jeżeli w danym miesiącu dokonano Odbioru więcej niż jednego Zlecenia, Xxxxxx dopuszczają możliwość wystawienia faktury obejmującej kilka Zleceń.

60. Z chwilą zainstalowania przez Wykonawcę Pakietu Aktualizacji na Środowiskach Zamawiającego, Wykonawca obejmuje go Usługą Asysty Technicznej i Konserwacji oraz gwarancją, bez zmiany wynagrodzenia przysługującego z tytułu realizacji ATiK. W przypadku zidentyfikowania po Odbiorze wad w przekazanej w ramach Zlecenia Dokumentacji Systemu będą one zgłaszane jako Usterkę w ramach ATiK-u.

61. Protokół Odbioru zawierać będzie informację o liczbie Roboczogodzin zrealizowanych, w ramach Zlecenia/Zleceń. Liczba Roboczogodzin wskazana
    w zaakceptowanym przez Zamawiającego Protokole Odbioru będzie podstawą do rozliczenia limitu Roboczogodzin z tytułu Rozwoju określonego w niniejszej Umowie.

11. Dostosowanie Systemu Pwind do wymagań zgodnych z WCAG 2.1 na poziomie AA

Implementacja WCAG w obecnie wykorzystywanym Systemie wymaga przebudowy wszystkich formularzy - ok. 300 (aplikacja jest cały czas rozwijana, liczba formularzy może ulec zwiększeniu maksymalnie o 10%). System został zbudowany przy zastosowaniu stosu technologicznego Java J2EE, technologia jest przestarzała, wymaga nieustannej komunikacji pomiędzy przeglądarką, a serwerem aplikacyjnym. Zamawiający wymaga zmiany stosu technologicznego, na taki stos technologiczny, gdzie aplikacja jest renderowana całkowicie w przeglądarce, a przeglądarka komunikuje się z serwerem tylko w celu pobrania danych. Ogólne wymagania dotyczące WCAG zawiera Załącznik nr 3 do OPZ.

[Wymogi dotyczące realizacji dostosowania Systemu Pwind do wymagań zgodnych z WCAG 2.1 na poziomie AA]

1. W celu niezakłóconej pracy Systemu Pwind podczas dostosowania do wymagań zgodnych z WCAG, niezbędne jest:

   1. Założenie, że „dotychczasowy” i „nowy” System Pwind będą wykorzystywać tą samą bazę danych,

   2. na początku projektu, zostanie określony plan modyfikacji „dotychczasowego” Systemu.

2. „Nowa” aplikacja będzie powstawać moduł po module. Kolejność wyboru modułu do wykonania będzie zsynchronizowana z planem modyfikacji „dotychczasowej” aplikacji, tak aby uniknąć wykonywania tych samych modyfikacji w dwóch aplikacjach.

3. Zamawiający zakłada, że gdzie będzie to możliwe moduł migrowany będzie do „nowej” aplikacji, a dopiero później będą dokonywane modyfikacje już na „nowej” wersji aplikacji.

4. Jeżeli modyfikacja wynikająca z planu modyfikacji będzie obejmować moduł jeszcze nieprzeniesiony, to nastąpi odsunięcie w czasie takiej modyfikacji,
   a w przypadku braku takiej możliwości (np. zmiany prawne), zostanie wykonana
   w „starej” wersji, a dopiero później moduł zostanie przeniesiony do „nowej” wersji.

5. Po wykonaniu i odebraniu przez Zamawiającego modułu w „nowej” wersji, zostanie jego funkcjonalność ograniczona (brak widoczności funkcjonalności po wprowadzeniu dodatkowych profili uprawnień) w „dotychczasowej” aplikacji.
   W ten sposób, użytkownicy będą w coraz większym stopniu wykorzystywać moduły w „nowej” aplikacji.

6. „Nowy” modułu będzie podlegał procesowi odbioru pod względem zgodności wykonania z wymaganiami WCAG 2.1 poziom AA.

7. Wszystkie dokumenty generowane z „nowego” systemu muszą być dostępne cyfrowo.

8. Całą dokumentację do Systemu Pwind należy dostosować, tak by była dostępna cyfrowo. Kryteria zostały opisane w Załączniku nr 6 do OPZ.

9. Proces odbioru będzie przeprowadzany przez ekspertów z Departamentu Dostępności w PFRON, przy wsparciu lub przez ekspertów zewnętrznych wspierających Zamawiającego w zakresie dostępności. Kryteria zostały opisane
   w Załączniku nr 7 do OPZ.

12. Informacje o Systemie Pwind

System Pwind służy do kompleksowej obsługi postępowań windykacyjnych w trybie administracyjnym i cywilnym w tym upadłości, restrukturyzacji, planów ratalnych w ramach postępowań restrukturyzacyjnych i upadłościowych oraz ugód cywilnych i administracyjnych.

Proces rozliczania zadłużenia polega na odpowiednim przyporządkowaniu wniesionych wpłat, z uwzględnieniem odpowiedniej ich klasyfikacji oraz naliczenia ewentualnych odsetek. Odpowiednie przyporządkowanie wpłat odbywa się w stosunku do zobowiązania dłużnika.

Informacje o wniesionych wpłatach pochodzą z elektronicznych wyciągów bankowych.

Efektem procesu rozliczeń są zapisy na kontach rozrachunkowych prowadzonych analitycznie dla poszczególnych dłużników. Zapisy te stanowią podstawę do określenia salda zobowiązań dłużników oraz do generacji miesięcznych not sumarycznych dla centralnego systemu finansowo-księgowego PFRON.

System obsługiwany jest przez pracowników z Biura PFRON.

Serwery zlokalizowane są w Biurze PFRON w Warszawie, xx. Xxxx Xxxxx XX 00.

PFRON posiada prawa majątkowe do kodu źródłowego i dokumentacji Systemu Pwind,
w tym do wykonywania zależnego prawa autorskiego.

Kod źródłowy oraz pełna Dokumentacja Systemu zostanie udostępniona Wykonawcy po podpisaniu Umowy.

13. Elementy Systemu Pwind

    1. Funkcjonalność ogólna całego Systemu obejmuje następujące zakresy:

       1. Ewidencja dłużników:

          1. ewidencja danych dłużników,

          2. ewidencja adresów bieżących i archiwalnych w różnych typach (prowadzenia działalności, korespondencyjny…),

          3. ewidencja danych kontaktowych (telefony, adresy e-mail,…),

          4. ewidencja danych osób reprezentujących dłużnika,

          5. ewidencja danych dłużników solidarnych,

          6. rejestracja zdarzeń prawnych związanych z dłużnikiem, komunikacja
             z Systemem PAWOR (pobieranie informacji o zadłużeniu).

       2. Ewidencja wniesionych wpłat:

          1. obsługa wyciągów elektronicznych z rachunków bankowych PFRON,

          2. analiza i klasyfikacja przelewów,

          3. przekształcanie wpłat w zapisy księgowe (rozliczenia wpłat).

       3. Obsługa pomocniczej księgi rozrachunkowej:

          1. prowadzenie księgowych kont rozrachunkowych,

          2. wystawianie dowodów księgowych,

          3. realizacja rozliczeń z pracodawcami z uwzględnieniem odsetek i wpłat ratalnych,

          4. generacja noty księgowej dla centralnego systemu finansowo-księgowego,

          5. obsługa odpisów aktualizacyjnych.

       4. Obsługa spraw w trybie cywilnym i administracyjnym:

          1. ewidencja i obsługa decyzji, postanowień, orzeczeń, umów,

          2. obsługa księgowa należności i kosztów związanych z procesami windykacyjnymi.

       5. Obsługa postępowań egzekucyjnych:

          1. ewidencja dokumentów postępowań,

          2. wystawianie upomnień,

          3. generacja tytułów wykonawczych,

          4. ewidencja i obsługa kosztów egzekucyjnych i komorniczych,

          5. obsługa zarzutów i zażaleń wnoszonych przez dłużników.

       6. Obsługa postępowań upadłościowych i restrukturyzacyjnych:

          1. ewidencja dokumentów postępowania,

          2. obsługa zgłoszeń wierzytelności,

          3. ewidencja planów podziału,

          4. generowanie i obsługa planów ratalnych i umorzeń,

          5. obsługa wpłat syndyka,

          6. rejestracja i półautomatyczna analiza MSiG (Internetowy Monitor Sądowy i Gospodarczy).

       7. Obsługa korespondencji i załączników:

          1. ewidencja pism wychodzących i przychodzących (e-PUAP, EZD, e-mail, listownie),

          2. rejestracja skanów dokumentów,

          3. generacja pism w oparciu o szablony,

          4. obsługa zwrotek potwierdzeń odbioru.

       8. Generacja raportów:

          1. generacja raportów wg zaimplementowanych szablonów i określanych kryteriów.

       9. Monitoring procesów administracyjnych:

          1. obsługa procesów workflow,

          2. obsługa procesów w oparciu o analizę zapisów księgowych,

          3. obsługa postepowań (spraw).

14. Moduły funkcjonalne Systemu Pwind

[Moduł Ewidencja dłużników, pełnomocników i osób trzecich.]

Ewidencjonowane podmioty zostały podzielone na 3 kategorie:

• Osoba fizyczna,

• Działalność gospodarcza,

• Firma.

Dane ewidencyjne są wersjonowane tzn. pamiętane są wszystkie ich poprzednie wersje.

Dłużnicy mogą być łączeni w grupy – w kontekście sprawy – jako dłużnicy solidarni.

Relacje pomiędzy dłużnikami definiowane są w oparciu o tzw. funkcje/relacje wzajemne. Relacje mogą być typu:

• osoba – osoba (np. współmałżonek),

• firma – firma (np. wspólnik),

• osoba- firma (np. właściciel lub prezes) – obejmuje również relacje działalność gospodarcza-osoba.

Rodzaje relacji są definiowane przez uprawnionych użytkowników.

Moduł obsługuje również funkcje anonimizacji danych. Polega ona na nadpisaniu danych ewidencyjnych dłużnika znakami xxxx – powiązane z rejestracją zlecenia anonimizacji danych.

[Moduł Ewidencja zadłużeń.]

Zadłużenia obejmują koszty i należności. Zadłużenia grupowane są w sprawy. Sprawa jest przypisana do dłużnika.

Składniki należności i koszty , mogą być również przypisane w formie tzw. limitów dla osób trzecich, odpowiadających solidarnie za te zadłużenia w ramach grupy dłużników solidarnych.

Ewidencja zadłużeń stanowi kluczowy element systemu. Wszystkie moduły systemu obsługują wyłącznie zadłużenia istniejące w ewidencji.

[Moduł Ewidencja wpłat.]

Wpłaty wczytywane są z pliku XML wyciągu bankowego.

Moduł pozwala na automatyzację rozpoznawania wpłat w oparciu o mechanizm analizy cech przelewu (rachunku źródłowego i opisu przelewu). Dla wpłat nierozpoznanych wymagane jest działanie użytkownika.

[Moduł Ewidencja i generacja pism.]

Moduł realizuje dwie równoległe funkcje:

• pozwala na ewidencjonowanie dokumentów przychodzących w formie skanów dołączonych do wybranych obiektów ewidencjonowanych w systemie,

• pozwala na generowanie pism w oparciu o szablony RTF i wskazany obiekt systemu.

[Moduł Rejestr korespondencji.]

Rejestr obsługuje korespondencję wychodzącą i przychodzącą, wewnętrzną i zewnętrzną oraz kanały komunikacji: tekstowy (poczta klasyczna) , e-mail i e-PUAP, EZD. Korespondencja współpracuje z module pism pozwalając na wysyłkę wygenerowanych pism oraz rejestracje przychodzących.

[Moduł Obsługa upomnień.]

Moduł pozwala na generację i ewidencjonowanie upomnień. Upomnienia generowane są w oparciu o wybrane z ewidencji zadłużeń sprawy dłużnika. Upomnienia mogą być generowane na dłużnika głównego jak i na osoby trzecie powiązane ze sprawą poprzez grupę dłużników solidarnych. Upomnienie generuje koszt przypisany do sprawy i zwiększa należności dłużnika co ma wpływ na sposób rozliczania wpłaty.

[Moduł Tytuły wykonawcze.]

Moduł ewidencjonuje tytuły wykonawcze. Generowane są dla wskazanych w ewidencji zadłużeń spraw. Tytuły mogą być generowane na dłużnika głównego jak i na osoby trzecie powiązane ze sprawą poprzez grupę dłużników solidarnych.

[Moduł WNOWE.]

Moduł służy do generowania i ewidencji wniosków o wszczęcie postępowania windykacyjnego w trybie administracyjnym i cywilnym.

[Moduł zabezpieczenia należności.]

Moduł obsługuje rejestr majątku, zapytania o majątek i ewidencje zabezpieczeń.

[Moduł Upadłości.]

Moduł obsługuje postepowania upadłościowe Zadłużenia objęte postepowaniem wybierane są ze spraw ewidencjonowanych w module zadłużeń. Moduł pozwala na stworzenie i ewidencjonowanie zgłoszeń oraz list wierzytelności, i realizację planów podziału. Generuje, ewidencjonuje i nadzoruje plany spłat, umorzenia dla upadłości konsumenckich.

[Moduł Restrukturyzacja/ugody/ulgi/postępowania DRP.]

Moduł obsługuje postępowania restrukturyzacyjne. Zadłużenia objęte postepowaniem wybierane są ze spraw ewidencjonowanych w module zadłużeń. Moduł pozwala na generację, ewidencję i monitorowanie realizacji planów ratalnych i umorzeniowych. Przywołanie listy szablonów pism pozwala na generacje pism opartych o dane wierzytelności.

[Moduł ugody/ulgi/postępowania DRP.]

Moduł obsługuje plany ratalne i umorzenia należności zaewidencjonowanych w module zadłużeń. Moduł pozwala na generację, ewidencję i monitorowanie realizacji planów ratalnych i umorzeniowych. Przywołanie listy szablonów pism pozwala na generacje pism opartych o dane wierzytelności.

[Moduł Raportowanie.]

Moduł realizuje raporty dotyczące różnych obiektów w systemie.

[Moduł Księgi pomocniczej rozliczeń.]

Odpowiedzialny jest za generowanie i ewidencjonowanie zapisów księgowych powstałych jako efekt tzw. dekretacji ewidencjonowanych w systemie obiektów lub zmiany ich statusu. Moduł generuje symulacje oraz notę księgową do systemu centralnego.

[Moduł analiza wyciągów bankowych.]

Działanie modułu oparte jest na analizie treści przelewu. Zadaniem analizy jest:

• identyfikacja dłużnika,

• ustalenie typu wpłaty.

Analizowane są następujące elementy przelewu:

• rachunek bankowy z którego wpłynął przelew,

• treść opisu przelewu.

Treść opisu analizowana jest w dwóch aspektach:

• wyszukiwanie sygnatur pism (decyzji, upomnień itp.) wskazanych w opisie przelewu,

• wyszukiwanie słów kluczowych pozwalających na identyfikację wpłaty.

Przy analizie rachunku bankowego wykorzystywana jest ewidencja rachunków bankowych dłużników.

15. Architektura fizyczna Systemu Pwind

Rys. 1 Architektura fizyczna

[Wirtualizator.]

System został zainstalowany w środowisku wirtualizatora VMware dostarczonym przez Zamawiającego, alokującym zasoby serwerów fizycznych wyposażonych (w zasoby analogiczne dla platformy fizycznej)

w 2 procesory klasy E5-2697A, 12 GB pamięci RAM, oraz macierz dyskową wyposażoną w dyski SSD.

[Serwer aplikacyjny.]

Serwer aplikacyjny J2EE został zaimplementowany w oparciu o oprogramowanie serwera aplikacji JBoss WildFly z openjdk 11 na systemie operacyjnym Linux RedHat.

[Serwer bazodanowy.]

Repozytorium danych zostało zaimplementowane w oparciu o oprogramowanie bazy danych PostgresSQL 10 na systemie operacyjnym Linux RedHat.

[Silnik raportowy.]

Silnik raportowy jest aplikacją typu „stand-alone”, bez interfejsu, przystosowaną do pracy na serwerze z systemem typu Unix z zainstalowaną platformą Java RE 11. Wykorzystuje technologie Java, Birt, J2EE, Spring, JDBC, SQL, operuje na bazie danych systemu PWIND i na systemie plików serwera.

[Silnik księgowy.]

Silnik raportowy jest aplikacją typu „stand-alone”, bez interfejsu, przystosowaną do pracy na serwerze z systemem typu Unix z zainstalowaną platformą Java RE 11. Wykorzystuje technologie Java, Spring, JDBC, SQL.

16. Dokumentacja Systemu Pwind

    1. W terminie 10 Dni Roboczych od uzyskania dostępu do Repozytorium Projektowego, Wykonawca zapozna się z dokumentacją i sposobem organizacji
       i zarządzania Repozytorium Projektowym oraz przedstawi Zamawiającemu propozycje optymalizacji ww. Repozytorium. Zamawiający zastrzega sobie prawo do wyboru poszczególnych propozycji przedstawionych przez Wykonawcę.

    2. Wykonawca w terminie 10 Dni Xxxxxxxxx od dnia zaakceptowania przez Zamawiającego propozycji optymalizacji Repozytorium Projektowego wprowadzi je do Repozytorium.

    3. Wykonawca zobowiązuje się do prowadzenia Repozytorium Projektowego
       w oparciu o środowisko dostarczone przez Zamawiającego. Środowisko zostanie skonfigurowane we wskazany przez Zamawiającego sposób, na wskazanej przez Zamawiającego infrastrukturze z wykorzystaniem wskazanego przez Zamawiającego środowiska systemu kontroli wersji (GIT), narzędziu typu case-tracker na przykład JIRA, narzędzia pracy grupowej na przykład Microsoft Teams, Sharepoint.

    4. W Repozytorium Projektowym, w sposób szczególny będą wyróżniane aktualne wersje dokumentacji projektowej. Dokumenty projektowe będą zawierały historię zmian oraz dane identyfikacyjne, w tym numer wersji.

    5. Wykonawca odpowiedzialny jest za sporządzanie notatek ze spotkań projektowych
       i umieszczanie ich w Repozytorium Projektowym.

    6. W uzupełnieniu do dokumentacji w Repozytorium Projektowym, Wykonawca prowadzi i utrzymuje następujące repozytoria i bazy wchodzące w jego skład:

       1. „Dokumentacja użytkownika” – zawiera dokumentację dla użytkowników Systemu, w szczególności:

          1. ogólne zasady obsługi Systemu;

          2. obsługa spraw i wpłat;

          3. ewidencja majątku;

          4. obsługa korespondencji;

          5. obsługa tytułów wykonawczych;

          6. obsługa upomnień i wezwań;

          7. postępowania restrukturyzacyjne;

          8. postępowania ulgowe;

          9. postępowania upadłościowe;

          10. raporty i silnik raportowy;

          11. wnioski o wszczęcie egzekucji;

          12. przedawnianie należności;

          13. zlecenia i zapisy księgowe;

          14. moduły pomocnicze (tworzenie załączników, zmiany statusów, szablony pism itp.).

       2. „Dokumentacja administracyjna” – zawiera informacje niezbędne do utrzymania oprogramowania, w szczególności:

          1. Architektura Systemu:

1. opis architektury fizycznej;

2. opis architektury funkcjonalnej z podziałem na warstwę ewidencyjną i księgową;

3. obsługa należności;

4. opis komponentów aplikacyjnych;

5. listę systemów wewnętrznych PFRON, z którymi komunikuje lub powinien komunikować się System;

6. lista systemów zewnętrznych, z którymi komunikuje lub powinien komunikować się System.

7. Instrukcja administratora:

8. instrukcja instalacji bazy danych;

9. instrukcja konfiguracji środowiska;

10. instrukcja instalacji aplikacji;

11. konfiguracja bazy danych;

12. konfiguracja aplikacji;

13. integracja z LDAP;

14. konfiguracja warstwy serwerów i sieci systemu;

15. startowanie, zatrzymywanie aplikacji;

16. startowanie zatrzymywanie bazy danych;

17. tworzenie kopii awaryjnej bazy danych;

18. odtworzenie bazy danych z kopii awaryjnej.

1. Instrukcja developera:

   1. budowanie elementów systemu;

   2. silnik księgowy – przygotowanie pakietu instalacyjnego, instalacja
      i konfiguracja;

   3. silnik raportowy – przygotowanie pakietu instalacyjnego, instalacja
      i konfiguracja.

   4. Interfejsy z innymi systemami:

   5. interfejs do systemu EPW-Neo;

   6. interfejs do systemu PAWOR;

   7. integracja z bramką SMS;

   8. integracja z systemem EZD PUW;

   9. integracja z systemem ePUAP;

   10. integracja z MSiG;

   11. integracja z rejestrem CEIDG;

   12. integracja z rejestrem REGON;

   13. integracja z ewidencją banków;

   14. integracja z systemem SOF.

2. Model ekranów systemu:

   1. zasady obsługi systemu;

   2. kategorie formularzy;

   3. lista formularzy Systemu Pwind;

   4. obsługa spraw;

   5. obsługa wpłat;

   6. pisma;

   7. egzekucja administracyjna;

   8. obsługa MSiG;

   9. postępowania restrukturyzacyjne;

   10. postępowania upadłościowe;

   11. księgowość (Pomocnicza Księga Rozliczeń);

   12. administracja (użytkownicy, role, bramki, słowniki, itp.);

   13. raporty (katalog raportów, kolejka zleceń raportowych).

3. Struktura oprogramowania:

   1. moduły Systemu Pwind;

   2. łączność z innymi systemami;

   3. biblioteka FLib (generowanie formularzy).

4. MiniDoc aplikacja dokumentacji elektronicznej w Systemie Pwind.

1. Dokumentacja musi spełniać wymagania dostępności dla dokumentów cyfrowych
   z następującymi założeniami:

   1. W dokumentach powinna być użyta czcionka Calibri o minimalnym rozmiarze 12 punktów,

   2. Dokument powinien mieć określony tytuł w pozycji Informacje na karcie Plik,

   3. Tekst dokumentu powinien być wyrównany do lewej,

   4. Język dokumentu powinien być określony dla fragmentów w języku innym niż preferowany, zgodnie z ich właściwością językową,

   5. W dokumencie nie można stosować dzielenia wyrazów,

   6. Tekst nie powinien być pisany kursywą i wersalikami – wielkimi literami,

   7. Podkreślenie powinno być stosowane wyłącznie dla tekstu, który jest linkiem,

   8. Linki powinny być dopasowane do kontekstu, a ich treść ukryta poprzez maskowanie, czyli skrócenie nazwy i nadanie jej przyjaznego wyglądu,

   9. Dokumenty są redagowane przy użyciu stylów nagłówkowych
      z następującymi założeniami:

      1. Styl Xxxxxxxx 0: czcionka Calibri, pogrubiona, rozmiar 18 punktów, odstępy przed 18 punktów, odstępy po 6 punktów, interlinia wielokrotność 1,15,

      2. Styl Xxxxxxxx 0: czcionka Calibri, pogrubiona, rozmiar 16 punktów, odstępy przed 12 punktów, odstępy po 6 punktów, interlinia wielokrotność 1,15,

      3. Styl Xxxxxxxx 0: czcionka Calibri, pogrubiona, rozmiar 14 punktów, odstępy przed 12 punktów, odstępy po 6 punktów, interlinia wielokrotność 1,15,

      4. Styl Xxxxxxxx 0: czcionka Calibri, pogrubiona, rozmiar 12 punktów, odstępy przed 12 punktów, odstępy po 6 punktów, interlinia wielokrotność 1,15,

      5. Styl Xxxxxxxx 0: czcionka Calibri, rozmiar 12 punktów, odstępy przed
         12 punktów, odstępy Po 6 punktów, interlinia wielokrotność 1,15,

      6. Styl Normalny: czcionka Calibri, rozmiar 12 punktów, odstępy przed
         0 punktów, odstępy po 6 punktów, interlinia wielokrotność 1,15, zaznaczona opcja „Nie dodawaj odstępów między akapitami o takim samym stylu”,

   10. W dokumencie powinna zostać zachowana hierarchia nagłówków przy założeniu, że tytuł dokumentu to styl Nagłówek 1, a tytuły rozdziałów to styl Nagłówek 2,

   11. Listy powinny być wykonane przy pomocy narzędzia Lista numerowana lub Lista punktowana w edytorze tekstu,

   12. Wszystkie elementy graficzne powinny posiadać opisy alternatywne, chyba że są ozdobnikami, wtedy powinny zostać oznaczone jako dekoracyjne,

   13. Kontrast koloru tekstu do tła - minimum 4,5:1, kontrast koloru elementu graficznego do tła – minimum 3,0:1,

   14. Tabele powinny służyć tylko prezentacji danych tabelarycznych,

   15. Tabele użyte w dokumentach powinny posiadać prostą strukturę – z taką samą liczbą komórek w każdym wierszu,

   16. Należy unikać scalania komórek w tabelach,

   17. W tabelach należy, we Właściwościach tabeli, na karcie Wiersz zaznaczyć opcję „Powtórz jako wiersz nagłówka na początku każdej strony”,

W kwestiach, które zostały tu niewymienione, a będą budzić wątpliwości Wykonawcy Zamawiający wyjaśni wątpliwości Wykonawcy w ciągu 5 dni roboczych.

Dokumentacja przechowywana w systemie ma organizację typu encyklopedycznego tzn. całość podzielona jest na artykuły (odpowiedniki haseł w encyklopedii). Artykuły stworzone są w ten sposób, że mogą stanowić jednocześnie pomoc kontekstową dla jednego formularza artykułów. Dodatkowo udostępniona została możliwość wprowadzania uwag do poszczególnych artykułów. Funkcja ta nie wymaga uprawnień ani autoryzacji i dostępna jest dla każdego użytkownika z poziomu przeglądarki. Wprowadzone uwagi mogą być okresowo przeglądane (przez użytkowników uprawnionych) i uwzględniane poprzez realizację zmian
w treści dokumentacji. Każdy artykuł jest odrębnie aktualizowany i wyposażony w notatkę opisującą datę i zakres ostatniej aktualizacji.

Wykonawca jest zobowiązany do bieżącego prowadzenia dokumentacji zgodnie opisaną strukturą i zakresem danych.

17. Organizacja, formatowanie, komentowanie i utrzymanie Kodu Źródłowego.

[Przechowywanie Kodu Źródłowego.]

Zamawiający prowadzi i nadzoruje Repozytorium Kodu Źródłowego. W przypadku projektów realizowanych przez firmy trzecie, pracownicy tych firm są odpowiedzialni za zarządzanie projektem i Kodem Źródłowym w repozytorium. W przypadku prac wykonywanych przez pracowników PFRON, taki obowiązek leży po stronie Funduszu. Repozytorium Kodu Źródłowego oparte jest na platformie GIT z wykorzystaniem interfejsu graficznego GitLab.

Zasady korzystania i prowadzenia repozytorium kodu źródłowego określają poniższe zapisy:

1. Każdy realizowany w PFRON projekt musi posiadać własną przestrzeń w systemie GitLab, tzw. projekt.

2. Projekt w GitLab musi mieć nazwę zgodną z nazwą projektu realizowanego
   w organizacji.

3. Kody źródłowe przekazywane są w formie zapewniającej kontrolę wersji.

4. Repozytorium kodu nie powinno być traktowane jako archiwum, wymagane jest ciągłe dostarczanie kolejnych wersji Kodu Źródłowego, zgodnie z procesem wytwórczym. Nie akceptowalna jest forma rzadkiego zatwierdzania commitów
   z dużą ilością linii Kodu Źródłowego.

5. W przypadku gdy, do aplikacji wykorzystane zostały Kody Źródłowe lub biblioteki innych dostawców a następnie zostały one zmodyfikowane na potrzeby projektu, bezwzględnie należy dodać do repozytorium kod wejściowy biblioteki lub modułu,
   a następnie wersjonować realizowane w nim zmiany.

6. Każdy commit powinien zawierać ogólny opis (jakiej funkcjonalności, pakietu dotyczy, do czego służy, dlaczego coś było modyfikowane - zmieniane) zmian oraz autora i wersję systemu, którego dotyczy.

7. Każdy commit powinien zawierać również informacje umożliwiające łatwe powiązanie poszczególnych aktualizacji Repozytorium Kodu Źródłowego z dokumentacją projektu, w tym dokumentacją zmian i dokumentacją Kodu Źródłowego.

[Organizacja Repozytorium Kodu Źródłowego.]

Struktura repozytorium powinna posiadać podział na moduły aplikacji, usługi integracyjne, konfiguracje i pliki specyficzne dla środowisk, strukturę bazy danych oraz obiekty bazodanowe, w tym pakiety, procedury, funkcje, wyzwalacze.

Strategia tworzenia gałęzi (ang. Branching Strategy) w narzędziu GitLab powinna być zgodna z zasadami GitFlow (xxxxx://xxxxxxxx.xxxxxx.xx/xxxxxxx/XxxxxxxxxxxXxxXxxx.xxxx). Główną gałęzią musi być master. Bieżące prace rozwojowe powinny być prowadzone w oddzielnej gałęzi, na przykład o nazwie develop. Wytwarzanie pojedynczych nowych funkcjonalności w ramach prac rozwojowych odbywać się powinno w gałęziach feature (ang. feature branches). Prace programistyczne związane z usuwaniem błędów prowadzone są na osobnej gałęzi, na przykład HotFIX. Po zakończeniu prac rozwojowych lub utrzymaniowych i wdrożeniu zmian na środowisko produkcyjne danego systemu kod źródłowy z odpowiedniej gałęzi musi być połączony z gałęzią master.

[Komentowanie Kodu Źródłowego.]

8. Projekty realizowane w PFRON muszą posiadać opracowaną i stosowaną w ramach danego projektu konwencję nazewniczą. Konwencja musi zapewnić minimum:

   1. Usystematyzowanie, uporządkowanie i ujednolicenie nazewnictwa w ramach danego projektu.

   2. Umożliwiać łatwe rozróżnianie (po nazwie) typu zmiennej, stałej, kolumny w bazie, wartości zwracanej przez funkcję, metodę itp.

   3. Nazwy mają być znaczące - informować o tym, do czego dany element jest wykorzystywany.

   4. Konwencja powinna być opracowana i opisana w taki sposób, by programista pisząc kod nie miał wątpliwości jakich nazw ma używać.

   5. Konwencja powinna uwzględniać instalacje testowe, tak aby nie wprowadzać chaosu pomiędzy np. nazwami/identyfikatorami elementów systemu dla instalacji testowej i produkcyjnej.

9. Opracowana konwencja nazewnicza musi uwzględniać minimum następujące elementy i twory programistyczne:

   1. Wszystkie elementy Kodu Źródłowego, w tym pakiety, biblioteki, klasy, metody, pola klas, stałe, zmienne, funkcje, procedury itp.

   2. Wszystkie składniki systemu baz danych, w tym nazwa baza danych, nazwy schematów, tabele, kolumny, funkcja, pakiet, wyzwalacz, tabele tymczasowe, zmienne itp.

   3. Innych składników systemu, takich jak API, zmiennych formatu XML oraz JSON itp.

Nazwy obiektów programistycznych i bazodanowych, w tym nazwy zmiennych, metod, klas muszą być intuicyjne, jednoznaczne i napisane w języku polskim. W przypadku gdy nazwy będą zapisywane w języku angielskim, ich polskie odpowiedniki muszą być zapisywane w komentarzu związanym z danym obiektem programistycznym lub bazodanowym. W przypadku nazw klas, metod, zmiennych, funkcji, obiektów bazodanowych (tabele, kolumny, procedury, funkcje, zmienne itp.) należy obowiązkowo unikać nazw jednoliterowych oraz skrótów zrozumiałych w danym momencie wyłącznie dla programisty piszącego dany kod.

Wyjątkiem od powyższych zasad jest kod źródłowy bibliotek i frameworków wytworzonych przez firmy trzecie i wykorzystywanych w ramach danego projektu. W przypadku modyfikacji ww. bibliotek lub frameworków, zmiany wprowadzone do kodu źródłowego muszą spełniać już wymagania opisane w niniejszym dokumencie.

[Formatowanie Kodu Źródłowego.]

Wszyscy, biorący udział w realizacji Umowy programiści muszą obligatoryjnie stosować jednolite formatowanie kodu źródłowego.

Kod źródłowy musi spełniać wymagania dotyczące kodu samo komentującego, powinien być sformatowany w sposób prosty, przejrzysty oraz jednolity.

Przykłady standardów formatowania dla Kodu Źródłowego:

• JAVA -Google Java Style Guide (xxxxx://xxxxxx.xxxxxx.xx/xxxxxxxxxx/xxxxxxxxx.xxxx)

• PHP – PSR PHP Standard Recommendations (xxxxx://xxx.xxx-xxx.xxx/xxx/)

• Python – PEP8 (xxxxx://xxx.xxxxxx.xxx/xxx/xxxx/xxx-0000/)

• PostgreSQL – Coding Standard for SQL and PL/SQL (xxxxx://xxx.xxxxxxxxxxxxxxxx.xxx/xxxxxxxxx/xxxxxxxxxxxxxxxxxxxx.xxxx)

[Komentowanie Kodu Źródłowego.]

Sposób komentowania i jakość samych komentarzy ma bezpośrednie znaczenie dla jakości Kodu Źródłowego danego systemu.

Główna reguła, która musi być stosowana w przypadku konstruowania komentarzy do kodu źródłowego brzmi następująco: Należy komentować Kod Źródłowy w taki sposób, jakiego tworzący komentarz programista sam by oczekiwał - co do zakresu, podejścia, zawartości, szczegółowości, konsekwencji w stylu, spójności konwencji itd.

Minimalne wymagania dotyczące komentowania Kodu Źródłowego:

• każda klasa (aplikacji, formularzy, raportów itd.) musi zawierać kilkuzdaniowy komentarz opisujący, jakiego rodzaju obiekty generuje i jaka jest ich semantyka,

• każdy atrybut każdej klasy musi zawierać komentarz opisujący jego znaczenie,

• każda metoda każdej klasy musi zawierać komentarz opisujący, do czego metoda służy, jakie ma parametry (co one oznaczają) oraz jaką wartość zwraca,

• każde wywołanie metody obiektu musi zawierać komentarz objaśniający, czemu służy,

• każde wykonanie instrukcji SQL musi zawierać komentarz objaśniający, czemu służy,

• każda tabela oraz kolumna musi posiadać komentarz objaśniający jakie dane są przechowywane w danej tabeli lub kolumnie, jeśli sama nazwa nie posiada odpowiedniej informacji,

• każdy obiekt bazodanowy, w tym, pakiet, funkcja, wyzwalacz itp. musi zawierać komentarz objaśniający, czemu służy.

Każdy obiekt programistyczny, taki jak pakiet, klasa, metoda, procedura, funkcja, pakiet bazodanowy, procedura bazodanowa, funkcja bazodanowa itp. zawiera opis nagłówkowy, zawierający przynajmniej poniższe informacje:

• autor,

• numer wersji obiektu,

• numer wersji systemu,

• data utworzenia i data ostatniej modyfikacji,

• lista i opis argumentów (jeśli takie posiada),

• opis zwracanej wartości (jeśli zwraca wartość) lub wyniku działania,

• krótki, ale wyczerpujący opis działania, słowny opis użytego algorytmu,

• zwracane nieobsłużone wyjątki (jeśli takie mogą się pojawić),

• ewentualnie odwołanie do dokumentacji systemu.

Komentarze wewnątrz pakietów, klas, procedur, funkcji, pakietów bazodanowych, procedur bazodanowych, funkcji bazodanowych itp. Muszą być umieszczone w przypadku, gdy:

• wyjaśnienie kodu, który nie jest oczywisty na pierwszy rzut oka,

• wyjaśnienie intencji, które ciężko ująć w kodzie,

• ostrzeżenie o konsekwencjach użycia danej funkcjonalności,

• wyjaśnienie niuansów procesów biznesowych, które realizuje program.

Komentarze Kodu Źródłowego należy uzupełniać o znaczniki wymagane przez narzędzia służące do automatycznego generowania dokumentacji Kodu Źródłowego wprost z plików źródłowych. W przypadku języka programowania PHP, komentarze powinny być opisane sposób pozwalający na wygenerowanie dokumentacji za pomocą narzędzia PHPDoc, phpDocumentor lub Doxygen. Dodatkowe wymagania dotyczące komentowania Kodu Źródłowego i znaczników interpretowanych przez dane narzędzie znajdują się w jego dokumentacji.

[Dokumentacja Kodu Źródłowego.]

Niezależnie od komentarzy znajdujących się w Kodzie Źródłowym i na tej podstawie wygenerowanej dokumentacji, wykonawcy realizujący projekty programistyczne
w Funduszu zobligowani są do utworzenia, aktualizacji i prowadzenia dokumentacji kodu źródłowego. Dokumentacja, o której mowa powyżej musi zawierać:

• wykaz (wraz z adresami w Git), wszystkich Kodów Źródłowych koniecznych do generowania określonej wersji systemu. Do Kodów Źródłowych zalicza się również wszelkie dodatkowe zasoby takie jak skrypty, dane konfiguracyjne, frameworki itp.,

• listę technologii wraz z wersją technologii, w których zostały wytworzone Kody Źródłowe. Dokumentacja musi być powiązana z konkretną wersją/wydaniem sytemu,

• wygenerowaną automatycznie na podstawie Kodu Źródłowego, dokumentację Kodu Źródłowego przy użyciu wybranego dedykowanego narzędzia (np. javadoc). Dokumentacja jest pozyskiwana na podstawie odpowiednich znaczników wpisywanych w komentarze (o składni zgodnej z regułami narzędzia),

• instrukcję generowania kodu wynikowego i tworzenia wersji instalacyjnej z wersji wynikowej (skompilowanej),

• instrukcję konfiguracji środowiska do generowania kodów wynikowych,

• specyfikację środowiska sprzętowo-systemowego wymaganego do przeprowadzenia procedury generacji kodu wynikowego,

• listę narzędzi do przygotowywania wersji instalacyjnych wytworzonego oprogramowania (wersji pełnej, aktualizacji, łat) wraz z dokumentacją użytkowania i licencjami, o ile są wymagane,

• w przypadku, gdy został wykorzystany framework firm trzecich, dokumentacja kodu źródłowego musi zawierać pełną dokumentację frameworka oraz instrukcję użytkownika i dla programistów,

• w przypadku wykorzystania własnych standardowych bibliotek lub frameworków przez wykonawców dokumentacja kodu źródłowego musi również zawierać dokumentację ww. elementów systemu.

[Weryfikacja Kodu Źródłowego - wewnętrzna.]

Częstotliwość weryfikacji Kodów Źródłowych –raz na kwartał.

W celu zweryfikowania zgodności Kodów Źródłowych z wymaganiami zawartymi
w niniejszym dokumencie należy przeanalizować Kod Źródłowy pod kątem poniższych zagadnień.

Lp.	Kryterium weryfikacji	Czy jest spełnione
1	Czy Kod Źródłowy jest przechowywany w GitLab?	Tak/Nie/Nie dotyczy
2	Czy projekt w GitLab ma nazwę zgodną z nazwą projektu?	Tak/Nie/Nie dotyczy
3	Czy sposób przechowywania Kodów Źródłowych zapewnia możliwość kontroli wersji?	Tak/Nie/Nie dotyczy
4	Czy commity wykonywane są z odpowiednią częstotliwością i są odpowiednio opisane?	Tak/Nie/Nie dotyczy
5	Czy Kody Źródłowe lub biblioteki innych dostawców znajdują się w GitLab?	Tak/Nie/Nie dotyczy
6	Czy struktura repozytorium w GitLab jest odpowiednio przygotowana i adekwatna do projektu?	Tak/Nie/Nie dotyczy
7	Czy są tworzone i utrzymywane odpowiednie gałęzie w repozytorium GitLab?	Tak/Nie/Nie dotyczy
8	Czy projekt ma ustaloną konwencję nazewniczą?	Tak/Nie/Nie dotyczy
9	Czy konwencja nazewnicza jest stosowana w projekcie?	Tak/Nie/Nie dotyczy
10	Czy konwencja nazewnicza spełnia wymagania zawarte w dokumencie Standard komentowania Kodu Źródłowego?	Tak/Nie/Nie dotyczy
11	Czy w projekcie został zdefiniowany standard formatowania Kodu Źródłowego?	Tak/Nie/Nie dotyczy
12	Czy standard formatowania jest stosowany w projekcie?	Tak/Nie/Nie dotyczy
13	Czy kod źródłowy spełnia wymagania dotyczące samo komentującego?	Tak/Nie/Nie dotyczy
14	Czy komentarze zawarte w Kodzie Źródłowym spełniają minimalne wymagania zawarte w dokumencie Standard komentowania Kodu Źródłowego?	Tak/Nie/Nie dotyczy
15	Czy została wytworzona dokumentacja Kodu Źródłowego?	Tak/Nie/Nie dotyczy
16	Czy dokumentacja Kodu Źródłowego jest aktualna?	Tak/Nie/Nie dotyczy
17	Czy dokumentacja Kodu Źródłowego zawiera elementy wskazane w dokumencie Standard komentowania Kodu Źródłowego?	Tak/Nie/Nie dotyczy

[Weryfikacja Kodu Źródłowego – audyt zewnętrzny.

Na wniosek Kierownika Projektu lub innej osoby decyzyjnej weryfikacja Kodu Źródłowego może być przeprowadzona przez podmiot zewnętrzny.

Zakres audytu zewnętrznego będzie obejmować następujące obszary:

• Obszar Kodu Źródłowego:

• inspekcja kodu (code review) i wykorzystanie obowiązujących praktyk;

• wykorzystanie przyjętych standardów komentowania i formatowania Kodu Źródłowego;

• wydajność Kodu Źródłowego i zapytań SQL;

• podatność na ataki;

• skalowalność Kodu Źródłowego;

• stopień odporności Kodu Źródłowego na wprowadzanie zmian, w tym refaktoryzację kodu (refactoring);

• zasięg i pokrycie testami automatycznymi;

• wykorzystane wzorce projektowe i poprawność ich użycia;

• optymalizacja i normalizacja bazy danych;

• ocena długu technologicznego.

• Obszar procesu wytwórczego i zagadnień projektowych.

• Architektura aplikacji.

• Wykorzystywana w projekcie technologia.

• Poprawność wykorzystania frameworków i bibliotek.

• Analiza potencjalnych kosztów wprowadzenia modyfikacji podczas fazy utrzymania
  i rozwoju systemu teleinformatycznego.

• Jakość przyjętego w projekcie procesu wytwórczego.

Powyższy zakres audytu zewnętrznego Kodu Źródłowego będzie dostosowywany do indywidualnych potrzeb w ramach każdego zlecenia.

Wynikiem audytu zewnętrznego Kodu Źródłowego będzie raport zawierający zidentyfikowane niezgodności, problemy oraz rekomendacje i zalecenia.

Załącznik nr 1 do OPZ - Metodyka procesu wytwórczego oprogramowania w oparciu o metodykę Scrum w ramach Rozwoju

Wskazane w niniejszym załączniku kwestie stanowią bazę do ustaleń Stron po zawarciu Umowy
[Komunikacja]w zakresie realizacji Rozwoju w oparciu o metodykę Scrum (zgodnie ze Scrum Guide 2020 xxxxx://xxxxxxxxxxx.xxx/xxxx/xxxxxxxxxx/x0000/0000-Xxxxx-Xxxxx-Xxxxxx.xxx).

Przyjęcie odmiennych uzgodnień, niż wskazane w niniejszym załączniku, nie będzie stanowić zmiany Umowy.

[Komunikacja]

1. Ustalenia organizacyjne i robocze podejmowane przez Strony dotyczące Sprintów będą rejestrowane w Portalu Serwisowym lub w inny sposób ustalony przez Strony po zawarciu Umowy, w tym dotyczące Zadań Sprintu przydzielonych do realizacji danemu Zespołowi Deweloperskiemu w poszczególnych Sprintach.

2. Stroną odpowiedzialną za prowadzenie i rejestrowanie w Portalu Serwisowym ustaleń związanych z Sprintem będzie Wykonawca pod nadzorem Zamawiającego. Zamawiający będzie weryfikował wprowadzane informacje i w razie ich nieprawidłowości lub niezgodności
   z ustaleniami, wezwie Wykonawcę do ich zmiany.

[Założenia organizacyjne]

3. Rozwój Systemu:

   1. Liczba zespołów analitycznych po stronie Wykonawcy maksymalnie 2.

   2. Liczba Zespołów Deweloperskich – Zamawiający zakłada utworzenie maksymalnie 2 Zespołów Deweloperskich.

   3. Zamawiający szacuje pojemność jednego Sprintu Rozwojowego na 200 - 1000 Roboczogodzin. Zamawiający zastrzega sobie możliwość zwiększenia lub zmniejszenie pojemności Sprintu Rozwojowego w uzgodnieniu z Wykonawcą.

4. Spotkania Statusowe – w ramach realizacji prac rozwojowych organizowane będą cykliczne spotkania projektowe Kierowników Projektu, Właściciela Produktu, Głównego Analityka, Głównego Architekta, przedstawicieli Zespołów Deweloperskich i Analityków oraz innych przedstawicieli Zamawiającego celem zebrania operacyjnego statusu prowadzonych prac oraz omówienia napotkanych problemów oraz zagadnień, którymi należy się zająć w najbliższym czasie.

[Artefakty SCRUM]

5. Rejestr Produktu (Product Backlog) – wykaz wszystkich funkcjonalności oczekiwanych do wytworzenia w Produkcie. Za dostarczenie wymagań w postaci Rejestru Produktu odpowiedzialny jest Właściciel Produktu. Rejestr Produktu jest spisem priorytetyzowanych wymagań w postaci historyjek do wykonania w ramach rozwoju Produktu. Historyjki tworzone są wspólnie przez Właściciela Produktu i/lub Pełnomocników Właściciela Produktu oraz Zespół Analityków Wykonawcy. Rejestr Produktu jest dokumentem wejściowym do Planowania Sprintu. Istnieje jeden Rejestr Produktu, który na potrzeby projektu będzie prowadzony w Portalu Serwisowym.

6. Rejestr Sprintu (Sprint Backlog) – uporządkowana lista historyjek i prac, które w procesie Planowania Sprintu zostały przyjęte przez Zespół Deweloperski do realizacji w Sprincie
   z Rejestru Produktu.

7. Przyrost (Increment) – wartości biznesowe (wymagania), które zostały zaimplementowane oraz przetestowane zgodnie z definicją ukończenia i są potencjalnie gotowe do wdrożenia
   w wyniku realizacji Sprintu.
   Wszystkie niezaimplementowane lub wykonane częściowo historyjki przewidziane w ramach danego Przyrostu wracają do Rejestru Produktu, gdzie są one powtórnie estymowane przez Zespół Deweloperski.

[Stosowane narzędzia informatyczne]

8. Portal Serwisowy – w szczególności: Rejestr Produktu i Rejestry Sprintów, historyjki użytkownika, scenariusze, rejestr zagadnień rozwojowych i przypadki testowe;

9. Teams – Cyfrowy Dziennik Projektu, Dokumentacja Systemu;

10. Planner – tablica zadań Kanban;

11. Git – Repozytorium Kodu Źródłowego;

12. Enterprise Architekt – repozytorium architektury

[Role projektowe, organizacja personelu]

Scrum Master

13. Wykonawca jest zobowiązany do zapewnienia roli Scrum Mastera, do którego obowiązków będzie należeć w szczególności:

    1. optymalizacja przebiegu procesu wytwórczego w ramach Rozwoju (w tym w szczególności pod kątem zgodności z dobrymi praktykami Scrum);

    2. bieżącego wsparcia Product Ownera, Zespołów Deweloperskich i Zespołu Analityków;

    3. uczestniczenia w spotkaniach scrumowych zgodnie z frameworkiem oraz czuwania nad ich prawidłowym przebiegiem;

    4. inne obowiązki wynikające wprost z framework Scrum wspierające efektywne prowadzenie projektu, np. organizacja codziennych spotkań zespołu Wykonawca-Zamawiający, udział w retrospektywie Sprintu.

Product Owner

14. Właściciel Produktu (Product Owner) – wskazana przez Zamawiającego i oddelegowana do pracy z Zespołami Scrumowymi osoba, która będzie:

    1. podejmowała bieżące decyzje co do wymagań opisanych w Rejestrze Produktu;

    2. ustalała priorytety dla wymagań opisanych w Rejestrze Produktu;

    3. brała czynny udział (osobiście lub poprzez Pełnomocników) w budowaniu opisu historyjek oraz uzupełniniu danych niezbędnych do przygotowania danej historyjki spełniającej definicję gotowości;

    4. uczestniczyła w Planowaniu Sprintu oraz jego akceptacji;

    5. dostępna dla Zespołu Scrumowego codziennie w celu rozwiązywania lub uszczegółowiania wymagań;

    6. dokonywała przerwania Sprintu.

15. Do obowiązków Właściciela Produktu w miarę potrzeb będzie również należeć angażowanie Interesariuszy, którzy będą w stanie udzielić wsparcia lub rozwiać wątpliwości co do kierunku, w którym powinien podążać rozwijany Produkt. Rola ta jest przypisana do jednej osoby po stronie Zamawiającego. Właściciel Produktu może delegować zadania Pełnomocnikom. Właściciel Produktu bierze odpowiedzialność za decyzje podjęte przez Pełnomocników.

16. W zakresie uzgodnień technicznych Właściciel Produktu jest wspierany przez pracowników pionu technicznego projektu. Pracownicy pionu technicznego projektu dokonują bezpośrednich ustaleń z Deweloperami w obszarze technicznym i technologicznym.

17. Pełnomocnicy Właściciela Produktu – osoby ze strony Zamawiającego (członkowie projektu) stale wspierające Właściciela Produktu w uszczegółowianiu i doprecyzowaniu wymagań i zadań.

Główny Architekt

18. Wykonawca zobowiązany jest zapewnić Głównego Architekta. Rolą Głównego Architekta będzie w szczególności koordynacja prac realizowanych w ramach Sprintu pod kątem zgodności z przyjętymi założeniami architektonicznymi i technologicznymi oraz bieżącego doradztwa Stronom.

19. Do kompetencji Głównego Architekta należy bieżąca kontrola postępu prac w ramach Sprintu pod kątem zgodności z przyjętymi z założeniami architektury Systemu, spójności wymagań, standardem tworzenia Kodu Źródłowego Systemu oraz koordynacja architektury Systemu. Ponadto Główny Architekt czuwa nad kompletnością Repozytorium Architektury.

Zespół deweloperski

20. Zespół ze strony Wykonawcy odpowiedzialny za Przyrost Produktu na podstawie Rejestru Produktu.

21. Wykonawca oświadcza, że wszyscy członkowie Zespołu Deweloperskiego będą posiadali:

    1. niezbędne kompetencje, wiedzę i doświadczenie niezbędne do prawidłowego wykonywania prac określonych Sprintem;

    2. inne umiejętności i doświadczenie gwarantujące należyte wykonanie obowiązków im powierzonych, przy zachowaniu wymogów wynikających z Umowy.

Główny Analityk

22. Wykonawca zobowiązany jest zapewnić Głównego Analityka. Rolą Głównego Analityka Wykonawcy będzie koordynacja prac Zespołu Analityków w ramach Doskonalenia Product Backlog oraz prac realizowanych w ramach Sprintu pod kątem zgodności z dokumentacją analityczną oraz bieżącego doradztwa Stronom.

23. Do kompetencji Głównego Analityka należy przede wszystkim: bieżąca kontrola nad kompletnością i jakością dokumentacji analitycznej wytwarzanej x.xx. w ramach Doskonalenia Product Backlog; zarządzanie dokumentacją analityczną w Cyfrowym Dzienniku Projektu; udzielanie rekomendacji odnośnie możliwych do przyjęcia rozwiązań, sygnalizowanie zagrożeń związanych projektowaniem rozwiązań mogących mieć negatywny wpływ na System (x.xx. na wydajność, bezpieczeństwo, dostępność, stabilność, itp.); rejestrowanie nowych wymagań (zagadnień rozwojowych) w Portalu Serwisowym; przygotowanie i zarządzanie harmonogramami spotkań analitycznych i realizowanych w ramach Doskonalenia Product Backlog (w tym wysyłanie zaproszeń do uczestników) oraz tworzenie notatek; uczestnictwo w innych spotkaniach uzgodnionych z Zamawiającym.

Zespół Analityków

24. Zespół Analityków Wykonawcy będzie składać się z osób dysponujących wiedzą
    i doświadczenie niezbędnym do prawidłowego wykonywania prac określonych Sprintem
    w liczbie niezbędnej do prawidłowej i terminowej realizacji Sprintu.

25. Zespół Analityków będzie współpracował z Product Ownerem, Kierownikami Projektu, Zespołami Deweloperskimi, Głównym Analitykiem oraz Głównym Architektem i ekspertami dziedzinowymi w przedmiocie ustalenia Wymagań do realizacji w ramach Sprintów oraz ewentualnych potrzeb korekt i modyfikacji w Product Backlogu. W szczególności Zespół Analityków będzie:

    1. uczestniczył w Planowaniach Sprintu oraz uzgadniał z Product Ownerem i Zespołem Deweloperskim zakres prac w danym Sprincie, a następnie także będzie współodpowiadał za prawidłowe sformułowanie Zadań Sprintu;

    2. wspierał Zespoły Deweloperskie w zakresie aktualizacji części analitycznej Repozytorium Kodu Źródłowego Systemu;

    3. na bieżąco aktualizował dokumentację analityczną w oparciu o ustalenia powstałe w ramach Doskonalenia Product Backlog.

Eksperci Funkcjonalni

Osoby ze strony Zamawiającego (osoby niebędące członkami zespołu projektowego) wspierające w miarę potrzeb Właściciela Produktu w uszczegółowianiu i doprecyzowaniu wymagań i zadań.

Interesariusze

Osoby ze strony Zamawiającego udzielające wsparcia merytorycznego oraz wyjaśnień
w sprawie wymagań Rejestru Produktu dla Właściciela Produktu. Mogące brać udział
w spotkaniach Doskonalenia Rejestru Produktu oraz Przeglądu Sprintu. Potrzeba udziału Interesariuszy, będzie zgłaszana przez Właściciela Produktu.

Inne role przewidziane w ramach realizacji projektu mogące występować po stronie Zamawiającego

26. Ekspert Infrastruktury,

27. Administrator SI,

28. Gestor SI,

29. Architekt SI,

30. Administrator Merytoryczny.

Wdrożenie – weryfikacja prac, procedura odbiorowa sprintu i zlecenia

31. Produkty prac Wykonawcy w danym Sprincie będą podlegać procedurze Odbiorowej.

32. Wraz z przekazaniem zgłoszenia gotowości do Odbioru Sprintu Wykonawca przedstawi raport z przeprowadzenia testów wewnętrznych (w tym zgodności WCAG) potwierdzający brak nienaprawionych wad wykrytych na tym etapie oraz poprawne działanie i brak zakłócania innych procesów (udane testy integracyjne i regresji). Wzór i zakres raportu zostanie ustalony z Zamawiającym przed uruchomieniem pierwszego Sprintu. Zgłoszenia gotowości do Odbioru Sprintu musi mieć miejsce nie później niż ostatniego dnia trwania danego Sprintu. Tester dokumentując swoją pracę musi (bez wyjątku) podać wersję testowanej aplikacji i scenariusz bądź kroki testowe (opis przypadku), który wykonał.

33. W trakcie procedury Odbiorowej sprawdzane będzie osiągnięcie celu Sprintu oraz szczegółowa weryfikacja spełnienia kryteriów akceptacji.

34. W trakcie procedury Odbiorowej prowadzone będą testy akceptacyjne przez Zamawiającego. Zamawiający zastrzega sobie możliwość realizowania testów także przez podmioty zewnętrzne.

35. Zamawiający będzie realizował testy również po każdym wydaniu cząstkowym Sprintu. Testy te będą elementem testów akceptacyjnych realizowanych w ramach procedury Odbiorowej.

36. Zamawiający będzie uprawniony do przeprowadzenia testów akceptacyjnych dowolnymi wybranymi przez siebie metodami, w tym według dowolnych metodyk.

37. Na życzenie Zamawiającego, Wykonawca weźmie udział w testach akceptacyjnych lub będzie udzielał Zamawiającemu potrzebnej asysty i konsultacji.

38. Zamawiający będzie w szczególności uprawniony do przeprowadzenia testów według scenariuszy testowych wymienionych przez Wykonawcę w jego raporcie z przeprowadzenia testów.

39. Zamawiający zgłosi Wykonawcy wszystkie wykryte podczas swoich testów akceptacyjnych Wady i nieprawidłowości w terminie nie dłuższym niż 5 Dni Roboczych od dnia zgłoszenia gotowości do odbioru. W uzasadnionych przypadkach Zamawiający może wydłużyć termin na wykonanie testów akceptacyjnych o czym poinformuje Wykonawcę.

40. Wykonawca będzie zobowiązany do naprawienia wszystkich Wad lub nieprawidłowości zidentyfikowanych podczas testów (przeprowadzonych przez niego lub Wykonawcę) w terminie 5 Dni Roboczych od zgłoszenia ich przez Zamawiającego. W uzasadnionych przypadkach Zamawiający może przedłużyć termin naprawy na wniosek Wykonawcy.

41. Po naprawieniu wszystkich zgłoszonych przez Zamawiającego Wad lub nieprawidłowości, Wykonawca powtórnie przygotuje do testów oprogramowanie podlegające Odbiorowi.

42. Zamawiający przeprowadzi retesty poprawionego oprogramowania w terminie 3 Dni Roboczych od dnia powtórnego przekazania oprogramowania do Odbioru. W uzasadnionych przypadkach Zamawiający może wydłużyć termin na wykonanie retestów akceptacyjnych o czym poinformuje Wykonawcę.

43. W przypadku pozytywnego zakończenia testów lub retestów akceptacyjnych oraz pozytywnej weryfikacji rezultatów prac Wykonawcy niepodlegającym testom Zamawiający dokona Xxxxxxx.

44. Wykonawca wraz z przekazaniem Sprintu do Odbioru, zobowiązany jest dostarczyć zaktualizowaną zgodnie z wymogami opisanymi w załączniku nr 4 Opisu Przedmiotu Zamówienia, kompletną zaktualizowaną Dokumentację Systemu. Przekazana zaktualizowana Dokumentacja Systemu musi zawierać wszelkie informacje pozwalające Zamawiającemu lub podmiotom wybranym przez Zamawiającego na samodzielne korzystanie z Produktów,
    a także na ich samodzielne utrzymywanie i rozwój. Przekazanie przez Wykonawcę zaktualizowanej Dokumentacji Systemu jest warunkiem niezbędnym do dokonania Odbioru Sprintu.

45. Z chwilą zainstalowania przez Wykonawcę Pakietu Aktualizacji na Środowiskach Zamawiającego, Wykonawca obejmuje go Usługą Asysty Technicznej i Konserwacji oraz gwarancją, bez zmiany wynagrodzenia przysługującego z tytułu realizacji ATiK.

46. W przypadku zidentyfikowania po Odbiorze wad w przekazanej w ramach Sprintu Dokumentacji Systemu będą one zgłaszane jako Usterkę w ramach ATiK-u.

47. Wykonawca zobowiązany jest wdrożyć przedmiotu Odbioru Sprintu na Środowisku Produkcyjnym w terminie wskazanym przez Zamawiającego, jednak nie krótszym niż 1 Dzień Roboczy. W przypadku niedotrzymania terminu, o którym mowa w zdaniu pierwszym Zamawiający naliczy Wykonawcy karę umowną.

Załącznik nr 1 do OPZ: Wymagania wydajnościowe

1. Wykonawca zapewni ciągłe funkcjonowanie Systemu przy założeniu, że System działa w trybie ciągłym 24 godziny na dobę, 7 dni w tygodniu, 365dni w roku, a jednocześnie korzysta z niego nie więcej niż 50 Użytkowników. System musi zapewnić ciągłe funkcjonowanie dla obciążeń miesięcznych na poziomie co najmniej 1000. przetwarzanych dokumentów pochodzących od Użytkowników.

2. Czas reakcji Systemu na zatwierdzenie formularza nie przekroczy 5 sekund. Podany czas nie dotyczy czasu wyszukiwania danych, wysyłania plików oraz generowania
   i dostępu do raportów oraz innych czynności związanych z wykonywaniem bardzo złożonych operacji na danych, które nie są wykonywane w trakcie codziennej, rutynowej pracy z Systemem.

3. Zamawiający jest uprawniony do prowadzenia testów sprawdzających dotrzymanie parametrów wydajnościowych Systemu. Ze strony Zamawiającego zostanie użyte narzędzie Apache JMeter (xxxx://xxxxxx.xxxxxx.xxx).

4. Wykonawca będzie prowadził działania prewencyjne mające na celu wydłużenie czasu bezawaryjnej pracy Systemu, w tym będzie wykonywał optymalizacje Systemu oraz przeglądy nie rzadziej niż raz na kwartał, a także na żądanie Zamawiającego.

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

6. Wszelkie planowane przerwy w działaniu Systemu związane z wykonywaniem optymalizacji muszą być uzgodnione z Zamawiającym.

Załącznik nr 2 do OPZ: Wymagania w zakresie WCAG

System powinien być całkowicie dostępny cyfrowo dla Użytkowników
z niepełnosprawnościami. Ze względu na rolę, jaką pełni PFRON, System powinien być wzorcowy w zakresie dostępności.

Wymóg dostępności Systemu Pwind wynika z:

• Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych,

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

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

Wykonawca, jest zobowiązany do dostarczenia Systemu, 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.

18. Ogólne wymagania w zakresie dostępności cyfrowej

Twoim obowiązkiem jest zapewnić dostępność cyfrową serwisu/systemu na poziomie WCAG 2.1 A oraz AA, zgodnie z załącznikiem nr 1 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).

Materiałami referencyjnym odnośnie spełnienia wytycznych WCAG 2.1 są:

• WCAG 2.1 (oficjalne tłumaczenie na język polski)

• 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 projektowania elementów interfejsów (np. menu, nawigacja, okna modalne, formularze, nawigacja okruszkowa, tabele, karuzele itp.) powinieneś korzystać z wzorców projektowych i dobrych praktyk, opublikowanych na stronach:

xxxxx://xxx.x0.xxx/XX/xxx-xxxx-xxxxxxxxx/

xxxxx://xxx.x0.xxx/XXX/xxxxxxxxx/

Wątpliwości dotyczące sposobów wdrażania dostępności cyfrowej będą rozstrzygane przez Zamawiającego na podstawie dokumentacji opracowanej przez xxx.x0.xxx.

Narzędzia wspierające budowę i testowanie dostępnych cyfrowo serwisów/systemów internetowych.

Niżej wymienione narzędzia wspierają tworzenie dostępnych cyfrowo serwisów/systemów oraz umożliwiają wczesne wykrycie części problemów z obszaru dostępności cyfrowej. Pamiętaj jednak, że narzędzia automatyczne nie wykrywają wszystkich niezgodności z WCAG 2.1 – dlatego konieczna jest weryfikacja audytora WCAG.

Propozycja listy narzędzi:

• NVDA – czytnik ekranu xxxxx://xxxx.xx/,

• VoiceOver - wbudowany w system Mac OS X mechanizm odczytywania komunikatów z ekranu - xxxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxx/xxxxx/_0000.xxxx,

• WAVE – narzędzie do wstępnej wizualnej ewaluacji zgodności strony z WCAG 2.1 xxxxx://xxxx.xxxxxx.xxx/,

• AXE Devtools - narzędzie wspomagające badanie dostępności, generujące wstępną listę potencjalnych błędów xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxx/xxxxxx/xxx-xxxxxxxx-xxx-xxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,

• ARC Toolkit – rozszerzenie do przeglądarki Chrome, wspierające badanie kodu strony -xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxx/xxxxxx/xxx toolkit/chdkkkccnlfncngelccgbgfmjebmkmce,

• XXXX – bookmarklet dla przeglądarki Chrome xxxxx://xxx.xxx.xxx/xxxxxxxxxxxxx/xxxx/xxxx/xxxxxxx.xxxx,

• Colour Contrast Analyser – narzędzie do weryfikowania kontrastu elementów strony xxxxx://xxx.xxxx.xxx/xxxxx-xxxxxxxx-xxxxxxx/,

• HeadingsMap – rozszerzenie pomagające określić strukturę oraz hierarchię nagłówków występujących na stronie xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxx/xxxxxx/xxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,

• Landmarks – rozszerzenie pomagające określić punkty orientacyjne (tak zwane landmarki) występujące na stronie xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxx/xxxxxx/xxxxxxxx navigation via k/ddpokpbjopmeeiiolheejjpkonlkklgp

• Text Spacing – narzędzie wspomagające symulację strony ze zwiększonymi odstępami w zakresie podanym w WCAG 2.1. xxxxx://xxxxxx.xxxxxx.xx/xxxxxxxxxxxx.xxxx

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

Poniższa część dokumentacji ma za zadanie zwrócić Twoją uwagę na kluczowe aspekty zapewnienia dostępności cyfrowej serwisu/systemu internetowego. Musisz wiedzieć, że są to tylko wytyczne wspierające Ciebie w realizacji kluczowych wytycznych WCAG 2.1, nie zaś pełna lista sposobów zapewnienia zgodności strony ze standardem WCAG 2.1.

Zgodność składni z walidatorem HTML

Wszystkie strony serwisu/systemu 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 możemy zaakceptować błędy HTML. Muszą to być jednak uzasadnione i udokumentowane przypadki, związane z niestabilnością specyfikacji HTML5, które będą działać np. na rzecz dostępności.

Uwaga: Poza zgodnością z walidatorem samych szablonów serwisu/systemu, 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/system powinieneś realizować w pełnej zgodności ze specyfikacją HTML5.

Przykłady poprawności semantycznej:

W ramach prac nad serwisem/systemem pamiętaj, że poszczególne elementy należy wykonać w określony sposób:

• Linki za pomocą znacznika <a>, czyli natywnego semantycznego znacznika HTML. Jeśli jest to niemożliwe dopuszczalne są również niesemantyczne elementy <div> wraz z odpowiednią rolą role=”link”;

• Nagłówki za pomocą znaczników <h1>...<h6> (przy czym nagłówek <h1> winien występować tylko raz), czyli natywnego semantycznego znacznika HTML. Jeśli jest to niemożliwe dopuszczalne są również niesemantyczne elementy <div> wraz z odpowiednią rolą, na przykład dla nagłówka poziomu 1 role=”heading” ARIA-level="1";

• Przyciski za pomocą znaczników <button> lub <input type="button">, czyli natywnego semantycznego znacznika HTML. Jeśli jest to niemożliwe dopuszczalne są również niesemantyczne elementy <div> wraz z odpowiednią rolą role=”button”;

• Listy za pomocą znaczników <ul>/<ol> i <li> dla poszczególnych elementów;

• Rozwijane listy formularzy za pomocą znaczników <select>/<option>.

Przykłady błędów semantycznych:

Unikaj poniższych rozwiązań.

• Link wykonany za pomocą <span> (oskryptowany JavaScript);

• Nagłówek w formie <p class="heading">;

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

Uzupełnienia semantyczne za pomocą ARIA

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

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

• Uzupełnienie głównych bloków serwisu/systemu o punkty orientacyjne;

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

Głównym źródłem informacji jak stosować ARIA powinna być dla Ciebie dokumentacja Aria Techniques for WCAG 2.1.

Niestety, nie jest to wystarczające źródło wiedzy. Nie ma jednego miejsca w Internecie zawierającego aktualną, pewną i gotową do stosowania wiedzę w zakresie ARIA.

Zastrzegamy sobie prawo do weryfikacji serwisu/systemu, w każdy dostępny sposób, pod względem zgodności ze specyfikacją ARIA w całym okresie obowiązywania Umowy. W przypadku stwierdzenia niezgodności ze specyfikacją ARIA będziesz zobowiązany do ich usunięcia na własny koszt w terminie wskazanym przez Zamawiającego.

Tytuły stron serwisu/systemu internetowego

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

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

Do uzgodnienia z Tobą 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 Wymaganiami dla Systemu Zarządzania treścią (CMS), opis dodatkowych modułów i funkcjonalności CMS oraz CMS serwisu - Redaktor musi mieć możliwość indywidualnego definiowania zawartości atrybutu metatagu title, niezależnie od tytułu redakcyjnego.

Oznaczenie języka strony i treści

Język naturalny treści na stronie powinieneś zawsze oznaczać odpowiednim atrybutem lang. W założeniu wszystkie strony serwisu/systemu będą miały atrybut lang o treści "pl" lub “pl-PL”.

Dodatkowo powinieneś zapewnić redaktorom serwisu w edytorze WYSIWYG możliwość oznaczenia takim atrybutem dowolnego ciągu znaków, tak by użytkownik korzystający z technologii asystujących mógł zorientować się, że treść jest w innym języku, niż domyślny język strony.

Nagłówki stałe

W serwisie będą stałe bloki treści i bloki funkcjonalne. Powinieneś je oznaczyć nagłówkami na odpowiednim poziomie.

Linki

W serwisie wszystkie linki powinny być zrozumiałe poza kontekstem tekstowym bądź wizualnym. W stałych częściach serwisu/systemu może oznaczać to potrzebę uzupełniania krótkich linków o treści uzupełniające. Linki powinny być uzupełniane przez treści niewidoczne dla użytkowników niekorzystających z czytników ekranu, na przykład za pomocą klasy sr-only czy visually-hidden.

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

Opisy alternatywne

Wszystkie grafiki, które zamieścisz w szablonach za pomocą znacznika <img> powinny mieć atrybut alt.

• W przypadku, gdy grafika nie będzie przekazywać żadnej treści (grafiki dekoracyjne), powinieneś je umieszczać 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ść, atrybut alt powinieneś uzupełnić o adekwatny opis.

• Jeśli grafika będzie linkiem, to w opisie alternatywnym powinieneś przekazywać funkcję linku, tak jakby to był link tekstowy lub zastosować opis ARIA-label lub ukrytą klasę np. <sr-only> do opisu celu linku. Jeśli zastosujesz drugie rozwiązanie atrybut alt powinien być pusty.

• Elementy, które zaimplementujesz za pomocą SVG powinny posiadać znacznik <title> </title>, w którym należy umieścić tekst alternatywny lub też dodać atrybut ARIA-hidden=”true”, jeśli ma to być grafika dekoracyjna.

Formularze — semantyka.

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

Powinieneś wiedzieć, 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 rozumiemy:

• użycie etykiet do wszystkich pól, etykiety mogą być ukryte lub widoczne,

• zrozumiałość etykiet,

• dostęp do wszelkich wskazówek bez konieczności patrzenia na ekran, np. za pośrednictwem czytnika ekranu (wskazówki, sugestie poprawy błędów, komunikaty błędów do obiektów formularzy powinny być powiązane semantycznie z tym obiektem, np. poprzez ARIA-describedby),

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

• zdefiniowanie atrybutu “autocomplete”,

• zdefiniowanie wymagalności pól (ARIA-required=”true/false” or required).

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 informacje o błędach.

W tym przypadku kieruj się następującym podejściem:

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

• jeśli formularz będzie tego wymagał, zastosuj atrybuty ARIA.

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

Nie rekomendujemy stosowania walidacji HTML. Prezentacja informacji w tym rozwiązaniu jest ograniczona czasem.

Przykłady poprawnych rozwiązań:

Przykład z użyciem role="alert"

• xxxxx://xxx.xxxxxxx00x.xxx/xxxxxxxx-xxxx-xxxxxx/

• Przykład wykorzystania aria-describedby:

xxxxx://xxx.x0.xxx/XXX/XXXX00/Xxxxxxxxxx/xxxx/XXXX0

Tabele.

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

Wskazówki, które pomogą Ci w tworzeniu dostępnych tabel znajdziesz na stronie xxxxx://xxx.x0.xxx/XXX/xxxxxxxxx/xxxxxx/.

Działanie serwisu/systemu za pomocą klawiatury.

Prawidłowe zastosowanie semantyki HTML powinno gwarantować dostępność za pomocą klawiatury każdego aktywnego elementu na stronie – zadbaj o to na etapie wdrożenia, aby zapewnić bezbłędne działanie tej funkcjonalności.

Programiści muszą stosować zarządzanie fokusem przez JavaScript w taki sposób, aby nie stworzyć tzw. pułapki klawiaturowej. Taki błąd powoduje barierę 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 i od góry do dołu. Na przykład, 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/systemu przez użytkowników z niepełnosprawnością wzroku.

Polecamy artykuły opisujące techniki ukrywania treści:

• xxxx://xxxxxx.xxx/xxxxxxxxxx/xxx/xxxxxxxxxxxxxxxx.

• xxxxx://xxxxxxxxxxxx.xxx/xxxx/0.0/xxxxxxx/xxxxxxxx-xxxxxx/

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.

Zabezpiecz formularz w taki sposób, aby nie stwarzał barier dla użytkownika serwisu/systemu.

W takim przypadku musisz 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 pozostaw po stronie serwera lub wykonaj zabezpieczenia tak aby nie wymagały dodatkowego działania po stronie użytkownika. Jeśli zaproponujesz rozwiązanie typu CAPTCHA, to będzie ono dokładnie testowane pod kątem dostępności dla wszystkich użytkowników.

Więcej informacji na temat rozwiązania CAPTCHA znajdziesz pod adresem:

xxxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxxxxxx/xxxx/xxxxxxxxx

Działanie filtrów / przeładowanie.

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

• filtrowanie,

• sortowanie,

• wyszukiwanie,

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

Przyjmij ogólną zasadę, że zmiany treści strony bez przeładowania stosujemy tylko w uzasadnionych sytuacjach.

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

Działanie w trybie wysokiego kontrastu (WINDOWS).

Serwis/system 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” (jeżeli takie elementy występują), które pomagają przeskoczyć fokusem bezpośrednio do głównej funkcjonalności danej strony. Najczęściej będzie to oznaczać przeskoczenie nawigacji lub też innych powtarzających się elementów na stronie. Takie elementy zaprojektuj i skonsultuj z zespołem zleceniodawcy.

19. Inne wymagania techniczne

Szybkość działania serwisu/systemu

Serwis/system 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:

• brak nadmiarowego kodu HTML / CSS / JS,

• nieobciążanie serwisu/systemu zbędnymi dodatkami JS,

• dobrą optymalizację grafiki,

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

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

Responsywność (RWD).

Przy budowaniu serwisu/systemu pamiętaj o urządzeniach mobilnych, które pełnią ważną rolę w odbiorze treści internetowych.

Serwis/system buduj w oparciu o najlepsze i aktualne praktyki tworzenia serwisów responsywnych.

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

Zwróć uwagę, aby obiekty nie zachodziły na siebie i nie przykrywały treści bądź funkcjonalności.

Przy projektowaniu widoków mobilnych uwzględnij minimalną wielkość fontów – 16 px. Jest to wartość ważna podczas analizy czytelności strony.

20. Szczegółowe wytyczne w zakresie dostępności (graficzne)

Kontrast treści.

Kontrast między kolorem tekstu a kolorem jego tła, musi wynosić minimum 4,5:1 lub 3:1 dla większego tekstu (krój pisma powyżej 18 punktów).

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

W związku z wymogami dotyczącymi kontrastu, nie powinieneś stosować elementów prezentujących tekst na tle niejednorodnym, np. bezpośrednio na tle zdjęcia. Istnieje możliwość dodania takiego tekstu wraz z zastosowaniem atrybutu CSS opacity o wartości mniejszej niż 1.

Możesz stosować kolorystykę o mniejszym kontraście, ale tylko w zakresie elementów dekoracyjnych w serwisie. Kryterium kontrastu nie obejmuje logo serwisu.

Identyfikacja linków.

Linki tekstowe muszą być łatwe do odnalezienia przez wszystkich użytkowników serwisu.

Muszą odróżniać się od tekstu zarówno kolorem jak i podkreśleniem. Niedopuszczalne jest zastosowanie tylko koloru do wyróżnienia linku.

Podkreślenia użyj w projekcie graficznym wyłącznie do oznaczenia linków. To samo dotyczy koloru linków. Nie może być on powtórzony na żadnym elemencie nieklikalnym i musi spełniać wymogi wskazane w punkcie “Kontrast treści”.

Po oznaczeniu linku kursorem myszy (hover) podkreślenie linku powinno 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/systemie. 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 przynajmniej 3:1.

Tak jak w przypadku linków, przyciski formularzy po oznaczeniu kursorem myszy bądź fokusem klawiatury muszą stawać się widoczne dla użytkowników (zwiększenie kontrastu między kolorem przycisku a kolorem tekstu przycisku).

Etykiety pól powinny być widoczne (w niektórych przypadkach mogą być ukryte, jednakże muszą być możliwe do przetworzenia przez narzędzia asystujące - na przykład <label> do elementu <input> wyszukiwarki ) i prezentowane bezpośrednio obok pola. Etykiety powinny być programistycznie powiązane z polami formularzy za pomocą atrybutów “for” i “id”.

Dodatkowe informacje, które ułatwią użytkownikowi wypełnić formularz powinny być powiązane z elementem <input> za pomocą atrybutu ARIA-labelledby.

Informacje o błędach powinny być prezentowane tekstowo, bezpośrednio obok pól których dotyczą (dodatkowo powiązane z polem poprzez ARIA-describedby) oraz pod nagłówkiem rozpoczynającym blok z formularzem. Powinien istnieć jeden, ogólny komunikat informujący użytkownika o błędnym wypełnieniu formularza wraz z rolą alert xxxxx://xxx.x0.xxx/XX/XXXX00-XXXXX/XXXX00.xxx

Fokus klawiatury.

Cały serwis będzie umożliwiał nawigację 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ół wybranego elementu.

Kolor ramki fokusu dobierz do schematu kolorystycznego serwisu tak aby był dobrze widoczny na oznaczonym elemencie (minimalny kontrast – 3:1).

Przykład dobrze widocznego fokusu możesz zobaczyć w serwisie xxx.xxxxx.xxx.xx - wystarczy zacząć nawigację w serwisie/systemie za pomocą przycisku TAB.

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

Typografia.

Czcionki, których użyjesz w serwisie/systemie powinny być bezszeryfowe, o wysokim poziomie czytelności - także przy dużym powiększeniu. Przykładami tego typu czcionek są: Lato, Open Sans czy PT Sans.

Liczbę czcionek (kroju i wielkości) powinieneś ograniczyć w projekcie graficznym serwisu do niezbędnego minimum.

Spójna identyfikacja.

W ramach serwisu/systemu zaplanuj i zaprezentuj widoki tekstowych elementów semantycznych, takich jak:

• nagłówek poziomu 1, ( każda strona powinna posiadać jeden nagłówek poziomu 1, pozostałe w odpowiedniej hierarchii, jeżeli treść jest wymagana.

• lista numerowana (uporządkowana),

• lista wypunktowana (nieuporządkowana),

• listy obu typów wielokrotnie zagnieżdżone,

• link,

• tekst podstawowy,

• tekst podstawowy wyróżniony,

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

• listy rozwijane (select),

• przyciski typu radio,

• pola wyboru,

• pole edycyjne.

Wielkość krojów pisma , których użyjesz w poszczególnych stylach powinna odpowiadać hierarchii tych stylów względem siebie. Dobrym rozwiązaniem jest, abyś przyjął zasadę, iż nagłówek poziomu 6 powinien być co najmniej wielkości kroju pisma podstawowego, tylko pogrubionego.

Minimalna wielkość kroju pisma, którą dopuszczamy w projekcie graficznym to 12 px., przy czym treść podstawowa powinna mieć wielkość minimum 16 px.

Dla treści nie powinieneś stosować formatowania wersalikami.

Odstępy między wierszami w akapitach powinieneś ustawić na co najmniej 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 innym przypadku powinieneś zapewnić możliwość zmiany wielkości, bez utraty treści (np. za pomocą Text Spacing – narzędzie wspomagające symulację strony ze zwiększonymi odstępami w zakresie podanym w WCAG 2.1.)

W jednym wersie powinieneś zaprezentować do 85 znaków.

Nie justuj (równoczesne wyrównanie do lewej i prawej) żadnej treści w projekcie graficznym. Dopuszczamy tylko wyrównanie do lewej, a w uzasadnionych sytuacjach wyśrodkowanie tekstu.

Tam, gdzie to możliwe, treść prezentuj w formie tekstu, a nie grafiki tekstu. Do osiągnięcia pożądanego wyglądu użyj odpowiednich stylów CSS.

Spójna identyfikacja to nie tylko spójność użycia krojów pisma lub stylów. Rozumiemy to jako jednolitą implementację tych samych elementów na różnych podstronach. Przykładem jest ten sam opis logo serwisu/systemu we wszystkich miejscach, w których występuje bądź też elementu ukazującego podpowiedź przy wypełnianiu formularza (nie może raz być to “otwórz podpowiedź”, a za innym razem “pomoc”).

Tabele.

Pamiętaj, że tabele z danymi prezentowane w projekcie graficznym powinny posiadać wyraźnie odróżniające się od reszty komórek wersy/kolumny nagłówkowe. Prawidłowa implementacja jest kluczowa dla zrozumienia tabeli przez narzędzia asystujące.

Musisz zwrócić szczególną uwagę na informowanie technologii asystującej na temat stanu sortowania/filtrowania oraz ilości danych w tabeli

Możliwość swobodnej zmiany wielkości widoku.

Pamiętaj, że 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 przeznaczonej dla tabletów i smartfonów) wszystkie treści i funkcje serwisu powinny być czytelne. Projekt graficzny musi umożliwiać zaprogramowanie w ten sposób serwisu.

Elementy rozwijane.

Wszystkim elementom, które są rozwijane powinieneś przypisać atrybut ARIA-expanded. Jego wartość należy ustawić z poziomu JS (true albo false) - w zależności czy element jest zwinięty czy rozwinięty: ARIA-expanded="true" jeśli jest rozwinięty, ARIA expanded="false” jeśli jest zwinięty. Dzięki temu użytkownicy korzystający z aplikacji asystujących będą wiedzieli jaka jest aktualna struktura zamieszczonych informacji.

Elementy zmienne.

Wszelkie elementy, które zmieniają swoją wartość, dzięki działaniu jakiegoś mechanizmu (na przykład kalkulatora czy formularza), powinny mieć atrybut ARIA-live. Dzięki niemu użytkownik jest informowany o zmianie treści na stronie. Przykłady działania atrybutu znajdziesz na stronie xxxxx://xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxx/xxxxxxxxxx-xxxxxxxxxx

Kolorystyka serwisu/systemu

Jedyne ograniczenia kolorystyczne w serwisie/systemie dotyczą logotypu Państwowego Funduszu Rehabilitacji Osób Niepełnosprawnych (patrz załącznik do wytycznych) oraz minimalnego kontrastu treści do tła oraz wymagania w 2.7. Spójna identyfikacja.

21. Zalecenia na poziomie AAA

Interfejs graficzny serwisu/systemu będzie zgodny z wytycznymi WCAG 2.1 poziomu A oraz AA. Dla wskazanych poniżej elementów interfejsu spełnione zostaną zalecenia na poziomie AAA:

Prezentacja wizualna:

• szerokość nie przekracza 80 znaków, tekst nie jest wyjustowany,

• interlinia to przynajmniej 150%, a odstęp pomiędzy paragrafami 1.5 razy wartości interlinii,

• tekst powiększony do 200% nie wymaga przesuwania horyzontalnego.

Cel łącza (z samego łącza): wymaganie opisaliśmy w punkcie Linki;

Rozmiar celu dotykowego: wielkość kontrolki (poziom AAA). Wielkość obiektu, który trzeba dotknąć lub kliknąć myszą, musi być na tyle duża, by Użytkownik mógł łatwo trafić palcem lub kursorem myszy.

22. Dokumenty

Wszystkie dokumenty, które będziesz publikował w Systemie, muszą spełniać wymagania WCAG w odniesieniu do dokumentów cyfrowych (zalecenia w tym zakresie dostępne są na stronie W3C opisujące techniki WCAG dla PDF - xxxxx://xxx.x0.xxx/XX/XXXX00-XXXXX/xxx).

Jesteś zobowiązany do każdorazowej adaptacji dokumentów dostarczanych przez Zamawiającego oraz prawidłowego (zgodnego z wytycznymi WCAG) przygotowania Dokumentacji Użytkownika.

Dokumentację Użytkownika przygotujesz zgodnie z zasadami prostego języka umieszczonymi w serwisie xxx.xx (xxxxx://xxx.xxx.xx/xxx/xxxxxxxxxxxxx/xxxxxx-xxxxx).

Załącznik nr 3 do OPZ – poziom świadczenia usługi (SLA)

Poniższe wartości parametrów obliczane są dla wartości SLA wymaganych przez Zamawiającego w SIWZ. W przypadku zaoferowania przez Wykonawcę innych wartości SLA (zgodnie z ofertą Wykonawcy) wartości parametrów w niniejszym załączniku zostaną zaktualizowane.

Wykonawca zobowiązuje się świadczyć usługi z zachowaniem następujących parametrów SLA (Service Level Agreement):

1. Usługa Asysty Technicznej i Konserwacji.

Kalendarz świadczenia usługi

W godzinach 7:00 - 17:00 w Dni Robocze – przyjmuje się średnią wartość 20 Dni Roboczych w miesiącu.

Czasy realizacji

Lp.	Nazwa	Czas Naprawy	Czas Obejścia
1.	Awaria	8 godzin (Zamawiający uzupełni zgodnie z danymi podanymi w ofercie Wykonawcy)	4 godziny
2.	Błąd	12 Godzin (Zamawiający uzupełni zgodnie z danymi podanymi w ofercie Wykonawcy)	12 godzin
3.	Xxxxxxx	00 godzin (Zamawiający uzupełni zgodnie z danymi podanymi w ofercie Wykonawcy)	Nie dotyczy
4.	Odpowiedź na pytania Zamawiającego	1 Dzień Roboczy	Nie dotyczy
5.	Błąd Użytkownika	12 Godzin Roboczych	Nie dotyczy

Definicje znajdują się w słowniku w pkt 1 Opisu Przedmiotu Zamówienia.

Poziom dostępności usługi

RPDS – rzeczywisty poziom dostępności Systemu dla Użytkowników

RPDS ≥ 95 %

RPDS obliczany jest wg wzoru:

(TD - ∑ TN) / TD x 100[%]

Gdzie:

TD – uzgodniony czas dostępności usługi, wynikający z kalendarza świadczenia usługi (20 Dni Roboczych w miesiącu (30 dni w miesiącu) po 10 Godzin Roboczych). (10 godzin zgodnie
z kalendarzem świadczenia usług).

TN – czas trwania niedostępności usługi – przyjmujemy dopuszczalnie łączny czas niedostępności usługi na poziomie 10 godzin w miesiącu . Czas niedostępności usługi mierzony jest w przedziale od 7:00 do 20:00 każdego Dnia Roboczego miesiąca.

Wyliczenie minimalnego progu RPDS:

TN = 10 godzin w miesiącu

TD = 20 Dni Roboczych x 10 godzin = 200 godzin (zgodnie z podanym kalendarzem świadczenia usługi).

RPDS = (200 godzin - 10 godzin) / 200 godzin x 100 = 95 %

Przykład 1:

W miesiącu nie wystąpiła niedostępność.

RPDS = (200 - 0) / 200 *100% = 100%

Przykład 2

W miesiącu wystąpiła jedna Awaria – naprawiona w 10 godzin.

RPDS = (200 - 10) / 200* 100% =95%.

Przykład 3

W miesiącu wystąpiły 2 Wady Systemu - Awaria naprawiona w 26

godzin + Awaria naprawiona w 6 godzin.

TN = 26 + 6 = 32

RPDS = (200- 32) /200* 100% = 84%.

Przykład 1 i 2 nie powoduje możliwości naliczenia kary umownej. Przykład 3

gdzie RPDS=87,69% jest poniżej wymaganego poziomu 95% - może być

naliczona kara umowna.

Czas Naprawy zostanie dostosowany do oferty Wykonawcy.

Terminowość

PDTN – poziom dotrzymania terminów naprawy lub odpowiedzi

PDTN ≤ 5

PDTN jest obliczany wg wzoru:

Σ (Wx * Px) / Σ Wx [%]

Gdzie:

Px – Łączny czas przekroczenia SLA dla danego typu Wady w danym okresie rozliczeniowym

Wx – waga danej Wady lub odpowiedzi.

W poniższej tabeli znajdują się wartości Wx i Px dla poszczególnych rodzajów Wad przyjęte do wyliczenia maksymalnej, dopuszczalnej wartości wskaźnika PDTN .

Nazwa Wady	Wx	Px[%]
Awaria	15	4
Błąd	10	8
Usterka	5	2

Wyliczenie maksymalnego progu PDTN (zaokrąglonego do dwóch miejsc

po przecinku):

PDTN = (15 * 4 + 10 * 8 + 5*2) / (15 + 10 + 5) = 5,00

Przykłady wyliczeń PDTN :

Przykład 1

Nazwa Wady	Nr zdarzenia	Wymagany Czas Naprawy Wcn	Faktyczny Czas Naprawy Fcn	Czas przekroczenia SLA (kolumna 3 – 4) (Jeżeli przekroczenie nie nastąpiło pozostawiamy puste pole)	Px	Wx
Awaria	1	8	13	5	5	15
Błąd	1	18	19	1	3	10
	2	18	20	2
	3	18	17

Zgodnie z wzorem:

PDTN = (15 * 5 + 10 * 3) / (15+ 10) = 4,20

Przykład 2

Nazwa Wady	Nr zdarzenia	Wymagany Czas Naprawy Wcn	Faktyczny Czas Naprawy Fcn	Czas przekroczenia SLA (kolumna 3 – 4) (Jeżeli przekroczenie nie nastąpiło pozostawiamy puste pole)	Px	Wx
Awaria	1	8	14	6	6	15
Błąd	1	18	22	4	12	10
	2	18	26	8
	3	18	9

Zgodnie z wzorem:

PDTN = (15 * 6 + 10 * 12) / (15 + 10) = 8,40

Przykład 3

Nazwa Wady	Nr zdarzenia	Wymagany Czas Naprawy Wcn	Faktyczny Czas Naprawy Fcn	Czas przekroczenia SLA (kolumna 3 – 4) (Jeżeli przekroczenie nie nastąpiło pozostawiamy puste pole)	Px	Wx
Awaria	1	8	9	1	1	15
Błąd	2	18	20	2	12	10
	3	18	28	10
	4	18	16
Usterka	5	36	48	10	10	5

Zgodnie z wzorem:

PDTN = (15 * 1 + 10 * 120 + 5*10) / (15 + 10 + 5) = 6,17

Przykład 1 nie powoduje możliwości naliczenia kary umownej. Przykład 2 i 3 gdzie PDTN=8,40 i PDTN=6.17 jest powyżej wymaganego poziomu 5,00 - może być naliczona kara umowna.

Przykłady wyliczenia PDTN zostaną dostosowane do Czasu Naprawy zaoferowanego przez Wykonawcę.

2. Modyfikacje i Rozwój.

Kalendarz świadczenia Modyfikacji i Rozwoju

Przez 24 godziny 7 dni w tygodniu 365 dni w roku („24/7/365”).

Przyjmowanie i obsługa: Dni Robocze w godzinach: 7:00 – 17:00

Czasy realizacji

Lp.	Nazwa	Czas realizacji
1.	Rozwój - etap I (analiza wstępna)	10 Dni Roboczych
2.	Rozwój etap I – analiza pełna	Ustalany indywidualnie
3.	Rozwój - etap II	Ustalany indywidualnie

Wskaźniki jakościowe

WJCR – wskaźnik jakościowy czasu realizacji.

WJCR jest obliczany wg wzoru:

Gdzie:

TZi – rzeczywisty czas realizacji etapu;

TWi – ustalony lub wymagany czas realizacji etapu;

i – każdy zakończony etap (dla wszystkich zadań modyfikacji i rozwoju wykonanych lub rozpoczętych) w okresie, dla którego liczony jest wskaźnik;

n – liczba etapów;

WJCR będzie:

< 1 jeśli Wykonawca wykonuje zadania przed terminem,

= 1 jeśli wykonuje zadania w terminie,

> 1 jeśli się spóźnia z wykonaniem zadania.

WJLB – wskaźnik jakościowy liczby błędów (wykrytych podczas odbioru)

WJLB jest obliczany wg wzoru:

Gdzie:

LB – liczba błędów wykrytych podczas odbioru;

Rb – liczba Roboczogodzin związana z harmonogramem zlecenia;

50 – oznacza, że badanie wskaźnika odbywa się na poziomie 50 Roboczogodzin.

WJLB będzie:

< 1 nie wystąpiły błędy podczas odbioru (na poziomie 50 Roboczogodzin),

= 1 błąd - dopuszczalny (na poziomie 50 Roboczogodzin),

> 1 zbyt duża liczba błędów (na poziomie 50 Roboczogodzin).

Za przekroczenie wskaźników jakościowych Zamawiający naliczy kary umowne.

Lista i częstotliwość raportów

Okres rozliczeniowy to jeden kwartał.

Poziom dotrzymania terminów usługi WJCR tj. wszystkich zakończonych etapów w okresie rozliczeniowym (kwartalnie).

Załącznik nr 4 do OPZ - Wymagania dotyczące testów.

1. Wykonawca zobowiązany jest do przeprowadzenia testów jednostkowych na Środowisku Developerskim. Po zakończeniu testów Wykonawca zobowiązany jest do przedstawienia raportu z testów wraz z logiem z narzędzia, za pomocą którego były przeprowadzane testy, potwierdzającym wykonanie i liczbę poprawnie i błędnie przeprowadzonych testów.

2. Wykonawca zobowiązany jest do wykonywania testów funkcjonalnych na Środowisku Testowym . Po zakończeniu testów Wykonawca jest zobowiązany do przedstawienia raportu z testów (RT) wraz ze scenariuszami testowymi (ST) oraz dowodów przeprowadzenia wyżej wymienionych testów. Dowodami mogą być zrzuty ekranu, wyciąg z logów Systemu, wyciąg z informacji z bazy danych Systemu.

3. Wykonawca zobowiązany jest do przeprowadzenia testów wydajnościowych na Środowisku Testowym. Po zakończeniu testów Wykonawca zobowiązany jest do przedstawienia raportu z testów.

4. Wykonawca zobowiązany jest do przeprowadzenia testów bezpieczeństwa na Środowisku Testowym. Po zakończeniu testów Wykonawca zobowiązany jest do przedstawienia raportu z testów.

Załącznik nr 5 do OPZ – Dostępność cyfrowa dokumentów, kryteria

Dokumenty tekstowe tworzone w programie Word

Kryterium	Opis	Weryfikacja pozytywna TAK/NIE	Uwagi
Język przekazu	Xxxxxx i zrozumiały. Zdania są krótkie, bez trudnych wyrazów.
Czcionka w dokumencie	Zgodna ze standardem graficznym w PFRON – Calibri, rozmiar pisma 12.
Wyróżnienia ważnych części dokumentu	Stosowanie dwóch rodzajów wyróżnienia (jeśli kolor to łącznie z pogrubieniem).
Akapity (1)	Brak kursywy dla całych akapitów.

Kryterium	Opis	Weryfikacja pozytywna TAK/NIE	Uwagi
Akapity (2)	Brak justowania.
Akapity (3)	Odstępy pomiędzy akapitami, nagłówkami i akapitem – wykonane bez użycia ENTER – za pomocą opcji Akapit>Odstęp przed/Odstęp po.
Tekst zawarty w grafice	Brak grafik, w których jest zawarty tekst (np. tabele jako obrazy). Wyjątkiem są np. wykresy lub infografiki – ale wówczas musi być zastosowany tekst alternatywny.
Tytuł dokumentu	Uzupełniona informacja w metadanych (Plik>Informacje>Tytuł).
Nagłówki	Nagłówki wykonane poprzez style. Zachowana jest struktura nagłówków (jeden nagłówek poziomu 1 – tytuł dokumentu, nagłówek poziomu 2 – rozdziały, części pisma, itd.).
Ramki tekstowe	Xxxx xxxxx tekstowych.
Dzielenie wyrazów	Brak dzielenia wyrazów.

Kryterium	Opis	Weryfikacja pozytywna TAK/NIE	Uwagi
Listy numerowane i nienumerowane	Listy wykonane za pomocą opcji punktory lub numerowanie (sekcja Akapit). Listy nie są wykonane ręcznie (poprzez wstawienie znaku minus).
Nagłówek i stopka	Brak umieszczania ważnych informacji w części roboczej dokumentu, jeśli nie są powtórzone (np. dane adresowe na końcu dokumentu).
Grafiki - opisy alternatywne	Wszystkie elementy graficzne (np. ilustracje, zdjęcia, wykresy, diagramy itp.) mają tekst alternatywny. Wyjątkiem są obiekty ozdobne – opcja „Oznacz jako dekoracyjne”.
Tabele	Wykorzystane są do przedstawienia danych tabelarycznych. Pierwszy wiersz jest nagłówkiem kolumn i jest oznaczona opcja we właściwościach wiersza „Powtórz jako wiersz nagłówka na początku każdej strony”.
Tabele	Komórki nie są scalone oraz zagnieżdżone.
Minimalny kontrast	Współczynnik kontrastu pomiędzy tekstem i tłem oraz informacją w postaci grafiki i tłem wynosi co najmniej 4.5:1 (współczynnik można zbadać za pomocą bezpłatnego programu Colour Contrast Analyser).
Kryterium	Opis	Weryfikacja pozytywna TAK/NIE	Uwagi
Linki	Na podstawie treści linku można stwierdzić, dokąd prowadzi (nie są używane linki typu „tutaj”, „pobierz”, „więcej”).
Linki	Linki mają podkreślenie. Uwaga: te treści, które nie są linkami nie powinny mieć podkreślenia.
Zwroty obcojęzyczne	Wyrazy lub fragmenty tekstu są oznaczone właściwym językiem (Recenzja – Język - Ustaw język sprawdzania).

Arkusze kalkulacyjne tworzone w programie Excel

Kryterium	Opis	Weryfikacja pozytywna TAK/NIE	Uwagi
Tabele	Układy komórek zostały przekształcone w tabelę (Wstawianie – Tabela).
Tabele	Zaznaczona opcja „Moja tabela ma nagłówki”.
Nazwy arkuszy	Domyślne nazwy arkuszy zmienione na adekwatne (np. Arkusz1 – Dane finansowe 2020).
Minimalny kontrast	Współczynnik kontrastu pomiędzy tekstem i tłem oraz informacją w postaci grafiki i tłem wynosi co najmniej 4.5:1 (współczynnik można zbadać za pomocą bezpłatnego programu Colour Contrast Analyser).
Grafiki - opisy alternatywne	Wszystkie elementy graficzne (np. ilustracje, zdjęcia, wykresy, diagramy itp.) mają tekst alternatywny. Wyjątkiem są obiekty ozdobne – opcja w tekst alternatywny „Oznacz jako dekoracyjne”.
Kryterium	Opis	Weryfikacja pozytywna TAK/NIE	Uwagi
Linki	Na podstawie treści linku można stwierdzić, dokąd prowadzi (nie są używane linki typu „tutaj”, „pobierz”, „więcej” itp.).
Linki	Linki mają podkreślenie. Uwaga: te treści, które nie są linkami nie powinny mieć podkreślenia.

Załącznik nr 6 do OPZ – Zgodność aplikacji z wymaganiami WCAG, kryteria

Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
1.1.1 Treść nietekstowa (Poziom A)
1.2.1 Tylko audio lub tylko wideo (Poziom A)
1.2.2 Napisy rozszerzone (Poziom A)
1.2.3 Audiodeskrypcja lub alternatywa dla mediów (Poziom A)
1.2.5 ‑ Audiodeskrypcja (nagranie) (Poziom AA)
1.3.1 Informacje i relacje (Poziom A)
1.3.2 Zrozumiała kolejność (Poziom A)
1.3.3 Właściwości zmysłowe (Poziom A)

Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
1.3.4 ‑ Orientacja - wyświetlanie treści w układzie poziomym, jak i pionowym (Poziom AA)
1.3.5 - Określenie prawidłowej wartości (Poziom AA)
1.4.1 Użycie koloru (Poziom A)
1.4.2 Kontrola i odtwarzania dźwięku (Poziom A)
1.4.3 Kontrast (Poziom AA)
1.4.4 Zmiana rozmiaru tekstu (Poziom AA)
1.4.5 Tekst w postaci grafiki (Poziom AA)
1.4.10 - Zawijanie tekstu (Poziom AA)

Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
1.4.11 - Kontrast dla treści niebędących tekstem (Poziom AA)
1.4.12 - Odstępy w tekście (Poziom AA)
1.4.13 - Treści spod kursora lub fokusa (Poziom AA)
2.1.1 Klawiatura (Poziom A)
2.1.2 Brak pułapki na klawiaturę (Poziom A)
2.1.4 - Jednoliterowe skróty klawiszowe (Poziom A)
2.2.1 Możliwość dostosowania czasu (Poziom A)
2.2.2: Wstrzymywanie (pauza), zatrzymywanie, ukrywanie (Poziom A)

Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
2.3.1 Trzy błyski lub wartości poniżej progu (Poziom A)
2.4.1 Możliwość pominięcia bloków (Poziom A) – nie dotyczy aplikacji mobilnej
2.4.2 Tytuły stron (Poziom A) – nie dotyczy aplikacji mobilnej
2.4.3 Kolejność fokusa (Poziom A)
2.4.4 Cel linka (Poziom A)
2.4.5 Wiele dróg (Poziom AA) – nie dotyczy aplikacji mobilnej
2.4.6 Nagłówki i etykiety (Poziom AA)
2.4.7 Widoczny fokus (Poziom AA)

Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
2.5.1 - Gesty punktowe (Poziom A)
2.5.2 - Anulowanie kliknięcia (Poziom A)
2.5.3 - Etykieta w nazwie (Poziom A)
2.5.4 - Aktywowanie ruchem (Poziom A)
3.1.1 Język strony (Poziom A)
3.1.2 Język części (Poziom AA) – nie dotyczy aplikacji mobilnej
3.2.1 Po oznaczeniu fokusem (Poziom A)
3.2.2 Wprowadzanie danych (Poziom A)

Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
3.2.3 Konsekwentna nawigacja (Poziom AA) – nie dotyczy aplikacji mobilnej
3.2.4 Konsekwentna identyfikacja (Poziom AA) – nie dotyczy aplikacji mobilnej
3.3.1 Identyfikacja błędu (Poziom A)
3.3.2 Etykiety lub instrukcje (Poziom A)
3.3.3 Sugestie korekty błędów (Poziom AA)
3.3.4 Zapobieganie błędom (Poziom AA)
4.1.1 Parsowanie (Poziom A)
4.1.2 Nazwa, rola, wartość (Poziom A)
Kryterium sukcesu	Poziom zgodności (wspiera, wspiera z wyjątkami, nie wspiera lub nie dotyczy – wybierz właściwe).	Uwagi i wyjaśnienia
4.1.3 - Komunikaty o stanie (Poziom AA) – nie dotyczy aplikacji mobilnej

Załącznik nr 2 do zapytania o wycenę szacunkową zamówienia

Formularz wyceny

Dane i adres Wykonawcy:

NIP: Regon

Osoba do kontaktów z Zamawiającym:

, e-mail: tel:

Wycena Wykonawcy:

W nawiązaniu do zapytania o wycenę szacunkową zamówienia na „Usługę Asysty Technicznej i Konserwacji, Modyfikacje i Rozwój Systemu Pwind”, przedstawiamy wycenę, zgodnie z poniższą tabelą:

Lp.	Rodzaj usług	Liczba	Cena jedn. netto odpowiednio za jeden miesiąc/ za jedną Roboczogodzinę	Wartość netto w PLN (kol. C x kol. D)	Stawka podatku VAT w %	Wartość brutto (kol. E + kol. F)
A	B	C	D	E	F	G
1.	Usługa Asysty Technicznej i Konserwacji Systemu Pwind zgodnie z OPZ	48 miesięcy1	…………… zł	………… zł	…………. %	………… zł
2	Modyfikacje i Rozwój Systemu Pwind zgodnie z OPZ	40 000 Roboczogodzin2	………….. zł	………… zł	…………..%	………… zł
3	Dostosowanie Systemu do wymagań zgodnych z WCAG 2.1 na poziomie AA	1	Nie dotyczy	………… zł	…………..%	………… zł
4	Łączna cena Dla ceny netto (suma poz. 1E, 2E i 3E) Dla ceny brutto (suma poz. 1G, 2G i 3G)	Nie dotyczy	Nie dotyczy	………… zł	…………..%	………… zł

Oświadczam, że :

Złożona przez nas wycena jest zgodna z treścią zapytania i obejmuje wszelkie koszty związane z należytą realizacją niniejszego zamówienia.

…………………………………………………… ……………………………………………………

Miejscowość i data podpisy uprawnionych

przedstawicieli Wykonawcy

1 48 miesięcy, w tym, 24 miesięcy w ramach zamówienia gwarantowanego i 24 miesięcy w ramach opcji.

2 40 000 Roboczogodzin, w tym 20 000 w ramach zamówienia gwarantowanego i 20 000 w ramach opcji.