Opis przedmiotu zamówienia
Załącznik nr 1 do zapytania o wycenę
Opis przedmiotu zamówienia
Spis treści:
2.6. Szczegółowe zasady realizacji zobowiązań Wykonawcy. 16
2.7. Zobowiązanie do stosowania regulacji wewnętrznych PFRON. 16
3. Informacje dotyczące Systemu SOW. 16
3.2. Architektura logiczna Systemu. 24
3.3. Architektura sprzętowa. 30
3.4. Aktualne wykorzystanie Systemu. 30
4.1 Wymagania dotyczące asysty technicznej i konserwacji. 31
4.1.2 Zasady obsługi Zgłoszeń. 33
4.1.3 Zasady udzielania stałych konsultacji. 36
4.1.4 Zasady aktualizacji Systemu. 37
4.1.5 Zasady zapewnienia kontroli i ciągłości działania Systemu oraz okresowych przeglądów. 38
4.2 Wymagania dotyczące rozwoju. 41
4.2.2 Zasady realizacji Rozwoju. 41
4.2.3 Etapy realizacji Rozwoju Systemu 42
5. Wymagania wydajnościowe i niezawodnościowe. 46
6. Wymagania w zakresie WCAG. 47
7. Wymagania dla Dokumentacji. 47
8. Wymagania dotyczące testów. 47
9. Poziom świadczenia usług SLA. 47
Załącznik nr 1: Podręcznik użytkownika wewnętrznego. 48
Załącznik nr 2: Podręcznik użytkownika zewnętrznego. 48
Załącznik nr 3: Wymagania wydajnościowe. 49
Załącznik nr 4: Wymagania WCAG 2.1 50
Załącznik nr 5: Wymagania dotyczące dokumentacji. 59
Załącznik nr 6: Wymagania dotyczące testów. 60
Załącznik nr 7: Poziom świadczenia Usług (SLA). 61
Termin | Definicja |
Awaria | Wada powodująca całkowite zatrzymanie lub poważne zakłócenie pracy Systemu, poszczególnych jego części lub modułów, dla której nie ma alternatywnej metody wykonania danej operacji w Systemie, uniemożliwiająca normalne korzystanie z podstawowych funkcji Systemu przez jego Użytkowników, polegająca w szczególności na braku możliwości realizacji co najmniej jednej z funkcji Systemu |
Błąd | Wada inna niż Awaria i Usterka powodująca istotne zakłócenia pracy Systemu lub poszczególnych ich części, która jednak nie uniemożliwia Użytkownikom korzystania z podstawowych funkcji Systemu, polegająca w szczególności na ograniczeniu realizacji lub uciążliwości w realizacji co najmniej jednej z funkcji Systemu. |
Czas Obejścia | Czas podawany w godzinach, liczony od momentu dokonania przez Zamawiającego Zgłoszenia Wady w Portalu Serwisowym do chwili dokonania Obejścia na Środowisku Produkcyjnym. |
Czas Naprawy | Czas podawany w godzinach, liczony od momentu dokonania Zgłoszenia Wady przez Zamawiającego w Portalu Serwisowym do chwili udostępnienia Zamawiającemu Naprawy na Środowisku Produkcyjnym. |
Dokumentacja Systemu | Dokumentacja opisująca System SOW i Kody Źródłowe Systemu SOW, dotycząca aspektów technicznych, funkcjonalnych i użytkowych związanych z korzystaniem z Systemu, ich działaniem i rozwojem, w tym dokumentacja Systemu w wersji elektronicznej w formacie edytowalnym oraz w wersji zoptymalizowanej do wydruku umieszczona w Repozytorium Projektowym. |
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 18:00 w Dni Robocze. |
IAAS | Określona przez Zamawiającego usługa chmury obliczeniowej wraz z usługami zarządzania i administrowania infrastrukturą IT. Usługa obejmuje zasoby platformy wirtualnej, tj. środowisko wirtualnych zasobów dostarczonych przez dostawcę infrastruktury sprzętowej wraz towarzyszącymi usługami (takich jak: pamięć operacyjna, moc obliczeniowa pamięć dyskowa, infrastruktura sieciowa, infrastruktura bezpieczeństwa) wraz towarzyszącymi usługami konfiguracji i administrowania. |
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 przetwarzane za pośrednictwem Systemu, wszelkie informacje finansowe, organizacyjne, technologiczne, dane |
osobowe oraz inne informacje o działalności jednej ze Stron Umowy, które posiadają wartość gospodarczą lub zostały udostępnione drugiej Stronie z zastrzeżeniem poufności. Szczegółowe zasady dotyczące zachowania poufności opisane zostały w paragrafie Umowy. | |
JST | Jednostka Samorządu Terytorialnego. |
Kierownik Projektu Strony (Zamawiającego/Wykonawcy) | Osoba 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 (zarządzająca operacyjnie projektem). |
Kody Źródłowe Systemu | Zestaw plików zawierających nieskompilowany kod oprogramowania napisany w języku programowania, wynikającym z przyjętej technologii rozwiązania oraz w formie czytelnej dla człowieka, 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 oraz niestandardowe biblioteki wykorzystywane przy produkcji Systemu oraz opis działania bibliotek ogólnie dostępnych wykorzystywanych przy produkcji Systemu), jak również dokumentacja niezbędna do użycia takiego kodu. Utrzymywane w systemie kontroli wersji GIT. |
Mikroraport | Raport z bazy danych Systemu lub logów Systemu zaprezentowany w formacie MS Excell. |
Naprawa | Trwałe usunięcie Xxxx poprzez usunięcie przyczyn powstania Wady skutkujące przywróceniem pełnej sprawności Systemu oraz przywrócenia utraconych w wyniku wady danych, w tym również zakończenie innych działań naprawczych. |
Odbiór | Czynności mające na celu potwierdzenie dostarczenia Zamawiającemu zamówionych usług i Produktów, w tym w szczególności modyfikacji i rozwoju, w ramach świadczenia przez Wykonawcę usług będących przedmiotem niniejszej Umowy na podstawie zaakceptowanego Protokołu Odbioru bez zastrzeżeń. |
Okno Serwisowe | Czas w ciągu dnia pomiędzy godziną 21:00 a 07:00 przeznaczony na wykonywanie wszelkich niezbędnych prac serwisowych, przeglądów, aktualizacji oprogramowania oraz wgrywania nowych wersji Systemu na środowisko produkcyjne. |
Oprogramowanie Standardowe / Oprogramowanie Obce | Wszelkie oprogramowanie obce firm trzecich , stanowiące składnik Systemu, na którego użycie w procesie budowy, rozwoju, konfiguracji, instalacji lub użytkowania Systemu Zamawiający wyraził zgodę. |
Oprogramowanie Systemowe i Narzędziowe | Oprogramowanie wykorzystywane na potrzeby Systemu, którego producentem nie jest Wykonawca, 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 wykorzystywane na potrzeby Systemu, które zapewnia Zamawiający, z uwzględnieniem aktualizacji tego oprogramowania dokonanych w trakcie trwania Umowy. |
Pakiet Aktualizacji | Przygotowane do instalacji uaktualnienie Systemu, służące usunięciu nieprawidłowości lub usprawnieniu pracy Systemu. wytworzone w wyniku modyfikacji i rozwoju oraz wytworzone w związku ze zmianami Sprzętu i Oprogramowania Systemowego i Narzędziowego. |
Portal Serwisowy | System informatyczny udostępniony przez Zamawiającego 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ą (Jira). |
Pracownik Zamawiającego | Osoba fizyczna lub osoba prowadząca jednoosobową działalność gospodarczą, świadcząca osobiście pracę na rzecz Zamawiającego na podstawie umowy o pracę lub umowy cywilnoprawnej (umowy o dzieło lub umowy zlecenia). |
Produkt | Wszelkie programy komputerowe, Dokumentacja i inne utwory, które powstają w toku wykonywania Umowy w wyniku prac Wykonawcy, a także materiały i informacje niepodlegające ochronie prawa autorskiego, stworzone |
lub dostarczone Zamawiającemu przez Wykonawcę w wykonaniu zobowiązań wynikających z Umowy. | |
Pytanie | Pytania dotyczącego działania Systemu w ramach świadczenia Usług Asysty Technicznej i Konserwacji. |
Protokół Odbioru | Dokument sporządzany przez Wykonawcę i podpisany przez Strony, potwierdzający prawidłowość i zakres wykonania konkretnych usług. Wzory Protokołów Odbioru Usług Asysty Technicznej i Konserwacji, Usług Modyfikacji i Rozwoju stanowią Załącznik nr …… do Umowy. |
Przypadki Szczególne | To takie, w których Użytkownik pomimo spełnienia wymogów określonych dla Systemu, dotyczących zainstalowanego środowiska na używanym komputerze oraz mimo wsparcia konsultantów, nie może skorzystać z dowolnej funkcji Systemu przewidzianej jako jedna z dostępnych możliwości. |
Raport | Dokument przedstawiony przez Wykonawcę i podpisany przez Xxxxxx, potwierdzający prawidłowość i zakres wykonania usług asysty technicznej i konserwacji. Raport stanowi załącznik do protokołu odbioru. |
Repozytorium Architektury | Część Repozytorium Projektowego służące do przechowywania modelu architektury. Forma, zawartość oraz zasady prowadzenia zostały opisane w załączniku nr 5 do Opisu Przedmiotu Zamówienia OPZ. Format plików musi być możliwy do poprawnego odczytania w narzędziu Sparx Enterprise Architekt w wersji co najmniej 12. Narzędzie Sparx Enterprise |
Architekt jest standardowym oprogramowaniem za pomocą którego Zamawiający zarządza repozytoriami eksploatowanych przez siebie systemów informatycznych. | |
Repozytorium Projektowe/Repozytorium Projektu | Środowisko służące do przechowywania Dokumentacji Systemu oraz do dokumentowania bieżących prac Wykonawcy. Forma, zawartość oraz zasady prowadzenia zostały opisane Załączniku nr 5 do Opisu Przedmiotu Zamówienia |
Repozytorium Wymagań | Część Repozytorium Projektowego służące do przechowywania wymagań funkcjonalnych i pozafunkcjonalnych. Forma, zawartość oraz zasady prowadzenia zostały opisane w Załączniku nr 5 do Opisu Przedmiotu Zamówienia . Format plików musi być możliwy do poprawnego odczytania w narzędziu Sparx Enterprise Architekt w wersji co najmniej 12. Narzędzie Sparx Enterprise Architekt jest standardowym oprogramowaniem za pomocą którego Zamawiający zarządza repozytoriami eksploatowanych przez siebie systemów informatycznych. |
Roboczogodzina | 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 wyznaczony przez Gestora do przywrócenia Systemu po Awarii (suma czasów przywrócenia systemu z umowy hostingowej i czasu usunięcia Awarii z Umowy Utrzymaniowej) |
RPO | Recovery Point Objective – punkt w czasie wyznaczony przez Gestora, do którego jest przywrócony System po awarii (przywrócenia danych z backupu, dane utracone od ostatniego wykonanego backupu bądź synchronizacji danych z backupowym storagem, odpowiedzialność Wykonawcy) |
SLA (Service Level Agreement) | Warunki poziomu świadczenia usług i sposobu jego pomiaru, określone w Załączniku nr 7 do Opisu Przedmiotu Zamówienia. |
System/System SOW | System informatyczny SOW utworzony w wyniku realizacji projektu w ramach Programu Operacyjnego Polska Cyfrowa na lata 2014 – 2020, Oś Priorytetowa nr 2 „E-administracja i otwarty rząd”, Działanie nr 2.1 „Wysoka dostępność i jakość e-usług publicznych obejmujący środowisko produkcyjne i testowe, rozwijany w ramach kolejnych umów. 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, Środowisko Testowe, Środowisko Demo) oraz dokumentacja dotycząca wszelkich aspektów procesów budowy, rozwoju instalacji, odtwarzania, konfiguracji, użytkowania, |
rozwoju i utrzymania Systemu, użytkowania, rozwoju i utrzymania Systemu. | |
Środowisko Deweloperskie | Infrastruktura sprzętowo – programowa Wykonawcy, która zapewnia Wykonawcy wykonywanie następujących czynności: - wprowadzania zmian do Kodu Źródłowego Systemu; - tworzenia i uzupełniania Dokumentacji Systemu oraz Kodów Źródłowych; - wytwarzania wykonywalnej i instalacyjnej wersji Systemu dla Środowiska Testowego i Środowiska Produkcyjnego; - przeprowadzania testów realizowanych przez Wykonawcę w wersji instalacyjnej Systemu przed przystąpieniem do testów akceptacyjnych w Środowisku Testowym. |
Środowisko Produkcyjne | Środowisko informatyczne, na którym jest używany System. |
Środowisko Testowe | Infrastruktura programowa Wykonawcy utworzona na środowisku wskazanym przez Zamawiającego. Środowisko informatyczne 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, służące do testów wewnętrznych Zamawiającego i Wykonawcy. |
Środowisko Demo | Infrastruktura programowa Wykonawcy utworzona na środowisku wskazanym przez Zamawiającego. Środowisko informatyczne 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, służące do testów dla użytkowników Zewnętrznych. | |
Tajemnica przedsiębiorstwa | W rozumieniu art. 11 ust. 2 ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji (Dz. U. z 2018 r., poz. 419 z późn. zm.) przez tajemnicę przedsiębiorstwa rozumie się informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, które jako całość lub w szczególnym zestawieniu i zbiorze ich elementów nie są powszechnie znane osobom zwykle zajmującym się tym rodzajem informacji albo nie są łatwo dostępne dla takich osób, o ile uprawniony do korzystania z informacji lub rozporządzania nimi podjął, przy zachowaniu należytej staranności, działania w celu utrzymania ich w poufności. |
Umowa | Umowa zawarta między Zamawiającym, a Wykonawcą wraz ze wszystkimi aneksami i Załącznikami do Umowy. |
Usługi Asysty Technicznej i Konserwacji/ATiK | Wszelkie usługi związane z zapewnieniem działania systemu zgodnego z podpisanym z Wykonawcą SLA działania Systemu, realizowane przez Wykonawcę według zakresu opisanego w Umowie. |
Rozwój | Wszelkie prace polegające na wprowadzaniu zmian w Systemie, realizowane przez Wykonawcę według zakresu opisanego w Zleceniu. |
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 zdolności operacyjnych Systemu. |
Użytkownik | Osoba korzystająca z Systemu lub jego poszczególnych części (Użytkownik może być wewnętrzny lub zewnętrzny względem PFRON). |
Wada | Jakiekolwiek zaburzenie pracy Systemu objawiające się poprzez jego działanie w sposób odmienny od ustalonego, przez co należy rozumieć między innymi: działanie odmienne od sposobu opisanego w Dokumentacji Systemu; działanie odmienne od standardów lub zwyczajów wynikających z praktyki ustalonej w toku bieżącej eksploatacji i administracji Systemu; 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 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ć typ: Awarii, Błędu lub Usterki. |
Wniosek | Przekazanie Wykonawcy zapotrzebowania w ramach Rozwoju poprzez utworzenie Zadania w Portalu Serwisowym. Otrzymanie Wniosku obliguje Wykonawcę do wykonania etapu I – „analiza i |
wycena”, czyli przygotowania analizy wraz z wyceną i przedstawienia jej wyników Zamawiającemu. | |
Wykonawca | Xxxxxxx, który ubiega się o wykonanie zamówienia, złoży ofertę na jego wykonanie lub zawrze z Zamawiającym Umowę w sprawie wykonania zamówienia a następnie ją realizuje. |
Zadanie | Zadanie w Portalu Serwisowym służące do obsługi Zgłoszeń, Wniosków, i Zleceń i , w tym: zamieszczania wyników prac przez Wykonawcę, akceptacji wyników prac przez Zamawiającego. |
Zgłoszenie | Przekazanie Wykonawcy zawiadomienia o Wadzie, zaleceń audytów, w tym audytu bezpieczeństwa i WCAG, złożenie Pytania lub złożenie zlecenia wykonania mikroraportu, poprzez utworzenie Zadania w Portalu Serwisowym, w ramach świadczenia Usług Asysty Technicznej i Konserwacji oraz w okresie gwarancji. |
Zlecenie | Przekazanie Wykonawcy zapotrzebowania na wykonanie określonych Produktów lub innych prac, poprzez utworzenie Zadania w Portalu Serwisowym, w ramach Rozwoju na podstawie analizy wykonanej przez Wykonawcę. |
Przedmiotem zamówienia jest:
• Usługa Asysty Technicznej i Konserwacji Systemu SOW,
• Rozwój.
Wykonawca udzieli Zamawiającemu gwarancji na okres 6 miesięcy od daty zakończenia
umowy. Zmawiający może zwolnić Wykonawcę ze świadczenia gwarancji pod warunkiem, że nowy Wykonawca przejmie świadczenie Usługi Asysty Technicznej i Konserwacji. Gwarancja będzie świadczona z takimi samymi parametrami jak usługa Usługą Asysty Technicznej i Konserwacji.
Wykonawca zobowiązuje się przenieść na Zamawiającego majątkowe prawa autorskie do Produktów oraz prawa zależne, z zastrzeżeniem postanowień Umowy o Oprogramowaniu Standardowym, w przypadku którego Wykonawca udziela oraz zapewnia Zamawiającemu udzielenie licencji, na zasadach określonych w paragrafie nr ….. Umowy.
Wykonawca zobowiązuje się zapewnić Zamawiającemu licencje na korzystanie z Produktów, na warunkach i zasadach opisanych szczegółowo w paragrafie nr ….. Umowy.
Wykonawca zobowiązuje się wykonać inne zobowiązania na rzecz Zamawiającego, określone w Umowie.
2.6. 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.
2.7. 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.
3. Informacje dotyczące Systemu SOW.
Dziedziną Systemu SOW jest obsługa pomocy finansowej oferowanej osobom
niepełnosprawnym oraz podmiotom działającym na ich rzecz ze środków pozostających w
gestii jednostek samorządu szczebla powiatowego i wojewódzkiego od złożenia wniosku po
rozliczenie otrzymanego dofinansowania.
System obsługuje komplet programów i zadań, których bezpośrednia realizacja odbywa się w jednostkach samorządu terytorialnego i oddziałach PFRON. W jego skład wchodzą między innymi programy Rady Nadzorczej PFRON (tzw. „programy celowe”), tj. „”Aktywny Samorząd” oraz „Program Wyrównywania Różnic Między Regionami III” oraz zadania z
zakresu realizacji zawodowej i społecznej określonych w ustawie o rehabilitacji zawodowej i społecznej oraz zatrudnianiu osób niepełnosprawnych i aktach wykonawczych.
System SOW wspiera x.xx. następujące procesy biznesowe:
1. Obsługa wniosków o dofinansowanie.
Dotyczy obsługi wniosków o dofinansowanie, poczynając od złożenia wniosku przez Wnioskodawców, poprzez ocenę, kontrolę w bazach zewnętrznych takich jak EKSMOoN, przyznanie dofinansowania, podpisanie umowy, fazę rozliczenia dotacji oraz wygenerowania paczki przelewów.
2. Obsługa ankiet informacyjnych poczynając od złożenia dokumentu przez
Wnioskodawcę, poprzez ocenę eksperta i kontakt zwrotny z Wnioskodawcą.
3. Obsługa wniosków o przekazanie środków PFRON
Dotyczy przepływów finansowych pomiędzy JST a PFRON poczynając od
wnioskowania o zaliczki, racjonalizowanie przekazywania środków finansowych w czasie, po rozbudowaną sprawozdawczość.
4. Rozdysponowanie limitów.
Proces obsługujący przydzielanie limitów finansowych dla JST w związku z
realizowanymi przez nie zadaniami obsługi wniosków o dofinansowanie oraz
kontrola realizacji limitu podczas wydawania decyzji.
W/w procesy biznesowe wspierane są x.xx. przez następujące funkcje i usługi aplikacyjne:
1. Raportowanie
2. Wymiana informacji przez Użytkowników Systemu poprzez wysyłanie wiadomości systemowych, wiadomości e-mail poprzez serwer oraz wiadomości sms poprzez bramkę.
3. Administracja uprawnieniami użytkowników na poziomie lokalnym w module Realizatora i centralnym w module PFRON.
4. Autoryzacja operacji i dokumentów profilem zaufanym lub podpisem
kwalifikowanym.
5. Weryfikacja danych Wnioskodawców i wymiana informacji z systemami lub
rejestrami takimi jak:
− EKSMOoN
− PESEL
− ZUS
− SODiR
− NEO
− SOF2
− EGW
6. Logowanie do Systemu z użyciem Węzła Krajowego.
7. Możliwość zgłaszania błędów w Systemie za pomocą dedykowanego formularza
zintegrowanego z projektem w JIRA.
8. Administracja listami słownikowymi, szablonami dokumentów, rolami w systemie,
rejestrami zdarzeń i logów.
9. Wsparcie procesów, które wykonują użytkownicy Systemu SOW podzieleni na następujące grupy/role:
− Wnioskodawcy – czyli osoby fizyczne i prawne aplikujące o środki dystrybuowane przez PFRON. Do tej grupy zaliczają się również osoby działające w imieniu osób fizycznych.
− Realizatorzy – pracownicy JST, które realizują proces obsługi wniosków w Systemie.
− PFRON – pracownicy PFRON obsługujący w imieniu Funduszu dystrybucję środków finansowych oraz sprawujący nadzór nad ich wydatkowaniem.
− Administratorzy – pracownicy JST oraz PFRON sprawujący nadzór nad eksploatacją SOW, szeroko pojętym bezpieczeństwem systemu, w tym bezpieczeństwem danych osobowych.
− Organizatorzy – pracownicy Organizatorów turnusów, którzy są częścią procesu obsługi jednego z wniosków.
− Pracownicy Oddziałów - pracownicy oddziałów PFRON odpowiedzialni za obsługę ankiet w ramach modułu CIDON.
Model Dziedziny diagram
+jest
Informacja wysyłany do
+jest 0..* uwzględniony w
+może
dotyczyć 0..1
+dzieli się 0..1 na
+Był obsługiwany
Wniosek
+odnosi się
+może brać pod uwagę
0..* 0..*
+dzieli się
0..*
+jest powiązany z
0..*
0..*
Limit środków na dotyczyć uwagę
Wiosek o
Limit środków na
algorytmowych
na bieżące 0..1
zadania
0..* archiwalny 0..* do
Aditum
+może +może brać pod
+jest realizowany za pomocą
WTZ/ZAZ
+może dotyczyć
0..1
+jest tworzony przez
przekazanie 0..1
0..* środków PFRON +może mieć
1
+jest przydzielany do
0..*
+Odnosi się do
+jest adresowana do
0..*
+jest przydzielany 1 do
0..*
0..* 0..*
Lista rankingowa +może
wniosków o zliczać +jest podstawą do
dofinansowanie 0..* obliczenia
+Wartość nie może
+zawiera 0..1 przekroczyć
Formularz
+jest opisany wniosku o
Wnioskodawca
w
1..
dofinansowanie
+może otrzymać
1
+Posiada
+jest
częścią 0..*
1
+stanowi 1 wzorzec
1
+jest
Limit środków na częścią
+dotyczy zadanie
0..*
0..1
1 +odnosi się
+składa
0..1 0..2
do
+posiada 1
1
+może Zadanie
posiadać
+może
posiadać
+jest wygenerowany dla
1
+Obsługiwała
1
+otrzymuje
+tworzy
+posiada 1
+może posiadać
+dotyczy 1..*
+wkazuje
+obsługuje wnioski wskazane w
1 1 1
+posiada
0..*
Kreator wniosku
0..*
Jednostka
Samorządu 1 +otrzymuje
1 Terytorialnego
1
+posiada
1
1
1
+może znajdować się na
+gromadzi 1..*
+realizuje +realizuje
+może posiadać
1..* 0..* 0..*
Pismo
+odnosi się do
0..*
0..*
0..*
+może posiadać
+jest realizowana
przez
+posiada
Wniosek o
0..*
1
Sprawa
+posiada
dofinansowanie
+odnosi
się do 0..*
0..1
+może posiadać
0..*
+posiada
1
0..1
1
1
0..*
0..*
0..*
0..*
0..1
0..* 0..* 0..*
Nabór
1
+ma przypisany
0..*
+jest wypłacona+zdaotyczy 0..1 0..1 pomocą
+dotyczy Płatność
+posiada
1 1
1
+jest obsługiwana przez
0..*
+posiada
0..*
+dotyczy
Ocena wniosku
+dotyczy
+jest realizowany
1
+dotyczy
+dotyczy 0..*
Zwrot do
0..1 Realizatora
Rozliczenie
+posiada
0..1
+dotyczy Kandydat na staż
zaw odowy
1..*
+dotyczy 0..*
+może
mieć 0..*
+dotyczy
Raport
Ocena
rozliczenia +dotyczy
1
+dotyczy 0..*
0..*
Umowa
+posiada
+dotyczy Aneks do umowy
+jest 0..*
adresatem
Użytkownik
+jest przypisany
+dotyczy 0..*
1
0..*
do
0..*
0..*
+jest
przypisany do
+może być 0..* przypisany do
+zakceptował
0..*
1
0..* 0..*
+moze mieć
+obsługuje
+może posiadać
+obsługuje
+realizuje 1
0..1
Realizator
+weryfikuje
0..*
0..1
Załącznik
0..*
0..1
0..1
0..1
0..1
Regulamin
+został zaakceptowany
0..1
+jest składana w ramach obsługi
+dotyczy
mieć
+może
+może mieć
0..1
+jest składane
1
do
0..*
1..*
Informacja o wyborze turnusu
rehabilitacyjnego +jest podstawą do
utworzenia
0..1
+dotyczy 1
Oświadczenie
0..1 Organizatora +jest podstawą do
+dotyczy
utworzenia
0..1
Informacja o
+dotyczy przebiegu
1 turnusu rehabilitacyjnego
1
+jest składane 1
przez
+składa 0..*
1
+jest składana przez
+składa
Organizator
0..*
+jest obsługiwane przez
+jest przypisana +jest podstawą do
do
obliczenia
0..1
0..*
+jest wskazany 1..* na
Ośrodek
0..1
Ankieta CIDON
Zgłoszenie CIDON
0..1
0..1
+jest skierowana do
+jest skierowane do
+obsługuje Oddział
0..*
+obsługuje
0..*
Paczka płatności
Polecenie przelew u lub przekazu
Limit środków niealgorytmowych na bieżące zadania
Zwrot środków do PFRON
0..*
+odnosi się do
Uprawnienie
NAZWA OBIEKTU
Aneks do umowy
OPIS OBIEKTU
Dokument pozwalający na zmianę kwoty dofinansowania podaną w zawartej wcześniej umowie.
Ankieta CIDON | Ankieta wypełniana przez beneficjentów (osoby z niepełnosprawnością, opiekunów, pracodawców, organizacje) zainteresowanych uzyskaniem informacji na temat wsparcia dla osób z niepełnosprawnością. |
Formularz wniosku o dofinansowanie | Formularz określający zestaw danych (pól) we wniosku o dofinansowanie. |
Informacja | Informacja przekazywana pomiędzy uczestnikami procesów. Rodzaje informacji: - telefoniczna/SMS - inna Informacja może dotyczyć informacji o wykonanej czynności w trakcie procesowania Sprawy. |
Informacja o przebiegu turnusu rehabilitacyjnego | Dokument składany przez Organizatora turnusu rehabilitacyjnego, po zakończeniu turnusu. Organizator informuje w nim, czy turnus się odbył i uczestnik w nim uczestniczył oraz opisuje przebieg turnusu. |
Informacja o wyborze turnusu rehabilitacyjnego | Dokument składany przez wnioskodawcę w procesie uzyskiwania dofinansowania do turnusu rehabilitacyjnego. Wnioskodawca wskazuje w nim organizatora turnusu, ośrodek oraz daty turnusu. |
Kandydat na staż zawodowy | Kandydat na staż zawodowy finansowany ze środków PFRON. Po przyznaniu miejsca na stażu, kandydat staje się stażystą otrzymującym wynagrodzenie za staż (stypendium). |
Kreator wniosku | Przewodnik zawierający informacje o możliwych formach wsparcia wnioskodawców. |
Limit środków algorytmowych na bieżące zadania | Limit środków na realizację bieżących zadań w ramach środków algorytmowych. Limit ten jest ustanawiany przez Administratora Systemu na poziomie PFRON dla poszczególnych Jednostek Samorządu terytorialnego: - Województwa, - Powiatu, - Miasta na prawach powiatu. |
Limit środków na WTZ/ZAZ | Limit przekazywany przez PFRON na |
zadanie warsztaty terapii zajęciowej albo zakłady aktywności zawodowej dla jednostki, która realizuje to zadanie. Wysokość limitu określana jest na podstawie podpisanych przez JST umów z organizatorami zajęć i znana jest najpóźniej ostatniego dnia roku poprzedzającego rok, w którym limit ma obowiązywać. | |
Limit środków na zadanie | Limit rozdysponowywany przez JST na realizację danego zadania w ramach limitu środków na bieżące zadania przydzielonych przez PFRON. JST decyduje, które z zadań określonych w ustawie, chce realizować i na zadania te rozdysponowuje limity. W ramach limitów na zadania muszą zostać rozdysponowane wszystkie środki (Limit) przekazane przez PFRON w środkach na bieżące zadania. |
Limit środków niealgorytmowych na bieżące zadania | Limit środków na realizację bieżących zadań w ramach środków niealgorytmowych: - Aktywny samorząd - Pomoc potrzebującym - Program wyrównywania różnic między regionami III - SAM Limit ten jest ustanawiany przez Administratora Systemu na poziomie PFRON dla poszczególnych Jednostek Samorządu terytorialnego: - Województwa, - Powiatu, - Miasta na prawach powiatu. Informacja o limicie dotyczącym Aktywnego samorządu oraz SAM może być zaimportowana z systemu zewnętrznego SOF2. |
Lista rankingowa wniosków o dofinansowanie | Lista rankingowa wniosków o wsparcie finansowe ze środków PFRON, które przeszły pozytywną weryfikację formalną przeprowadzaną przez Realizatora. |
Nabór | Nabór ogłaszany przez Realizatora, na który zbierane są Wnioski od Wnioskodawców. Nabór posiada: |
- Wskazanie na zadanie - Daty obowiązywania od, do | |
Ocena rozliczenia | Wynik oceny rozliczenia |
Ocena wniosku | Wynik oceny formalnej i merytorycznej wniosku |
Ośrodek | Ośrodek realizujący turnus rehabilitacyjny |
Oświadczenie Organizatora | Dokument składany przez organizatora turnusu rehabilitacyjnego w procesie obsługi wniosków o dofinansowanie do turnusu. Dokument zawiera oświadczenie dotyczące przyjęcia uczestnika na turnus oraz koszt turnusu. |
Paczka płatności | Zbiór zawierający informację o płatnościach realizowanych danego dnia lub w danym okresie lub dla danej osoby. |
Pismo | Obiekt w systemie tworzony w celu poinformowania Wnioskodawcy o podjętej decyzji (nie w rozumieniu KPA) w sprawie, która jest procesowana lub o koniecznym uzupełnieniu wniosku. Pismo w systemie jest drukowane w oparciu o szablon. |
Polecenie przelewu lub przekazu | Dokumenty przeznaczone do późniejszego wprowadzenia do systemu finansowo- księgowego, bankowego albo pocztowego. Dokument może przyjmować różne formaty, w szczególności: - elixir - videotel - mtms - txt - przekaz pocztowy |
Płatność | |
Raport | Wyliczone przez system dane dotyczące spraw obsługiwanych w Systemie. |
Realizator | Organizacja realizująca zadania w SOW w module Realizatora. |
Regulamin | Dokument opisujący zasady korzystania z Systemu. |
Rozliczenie | Element sprawy. Formularz wraz z załącznikami przekazywany przez Wnioskodawcę do Realizatora dokumentujący cel i datę wydatkowania pieniędzy. |
Rozliczenie przekazane przez Wnioskodawcę jest następnie opiniowane przez Realizatora. Rozliczenie w trakcie jego procesowania może przyjmować statusy: - Rozliczenie odrzucone. - Rozliczenie przekazane. - Rozliczenie do poprawy. - Rozliczenie do zatwierdzenia. - Rozliczenie zatwierdzone. - Dofinansowanie wypłacone. | |
Sprawa | Ogół dokumentów związany ze złożeniem, obsługą i realizacją Wniosku o dofinansowanie. |
Umowa | Dokument tworzony w ramach obsługi wniosku o dofinansowanie. W przypadku, gdy w naborze do którego został złożony wniosek przez Wnioskodawcę zdefiniowana jest umowa, to jej podpisanie przez Wnioskodawcę jest podstawą do wypłaty wsparcia finansowego ze środków PFRON. |
Uprawnienie | Uprawnienia do wykonywania określonych czynności np. podpisania umowy. |
Użytkownik | Użytkownik systemu w odpowiedniej roli. |
Wiosek o przekazanie środków PFRON | Wniosek składany przez JST w celu uzyskania środków od PFRON wymaganych na realizację zadań. Wniosek nie może zawierać wyższego zapotrzebowania niż dostępna kwota w ramach przyznanego przez PFRON limitu na realizację zadania, którego wniosek dotyczy (Kwota na wniosku <= Limit - wykorzystanie) |
Wniosek archiwalny Aditum | Zadanie realizowane przez Samorządową Jednostkę Organizacyjną finansowane w ramach środków przekazanych przez PFRON nie obsługiwane w SOW. |
Wniosek o dofinansowanie | Wniosek o wsparcie finansowe ze środków FPRON składane przez Wnioskodawcę w ramach określonego naboru. |
Wnioskodawca | Podmiot ubiegający się o wsparcie finansowe ze środków PFRON. Wnioskodawcą w systemie SOW może być: - Osoba niepełnosprawna - Opiekun/pełnomocnik osoby |
niepełnosprawnej (osoby działające w imieniu ON), - Przedsiębiorca, - Jednostka samorządu terytorialnego (szczebel wojewódzki i powiatowy), - Organizacja pozarządowa (podmioty działające na rzecz ON). | |
Zadanie | Zadanie realizowane przez Samorządową Jednostkę Organizacyjną finansowane w ramach środków przekazanych przez PFRON. |
Załącznik | Załącznik w formacie PDF JPG dołączany do dokumentu |
Zgłoszenie CIDON | Zgłoszenie potrzeby kontaktu w sprawie OzN z pracownikiem Oddziału. |
Zwrot do Realizatora | Szablon na podstawie, którego generowane są w systemie umowy. Szablon może podlegać edycji przez Administratora Realizatora. |
Zwrot środków do PFRON | Zwrot do PFRON środków niewykorzystanych lub błędnie przekazanych do JST. |
3.2. Architektura logiczna Systemu.
System aplikacyjny SOW podzielony jest na moduły funkcjonalne:
• Moduł Wnioskodawcy (moduł zawiera implementacje funkcji związanych z obsługą
Wnioskodawcy),
• Moduł Realizatora (moduł zawiera implementacje funkcji związanych z obsługą pracowników JST),
• Moduł PFRON (moduł zawiera implementacje funkcji związanych z obsługą pracowników PFRON),
• Moduł Zarządzający pełniący funkcję Kontrolera,
• Moduł Uwierzytelniania zarządzający procesem uwierzytelniania wszystkich użytkowników,
• Moduł Integracji, przy pomocy którego System aplikacyjny SOW komunikuje się z aplikacjami zewnętrznymi.
Moduły funkcjonalne korzystają z warstwy oprogramowania odpowiedzialnej za funkcjonowanie obiektów biznesowych, których atrybuty są odwzorowane we wspólnym repozytorium danych.
Architektura logiczna diagram
«system»
System SOW
PFRON
«moduł» AW.MP.Moduł PFRON
«moduł» AW.MZ.Moduł Zarządzający
Realizator
«moduł» AW.MR.Xxxxx Realizatora
«podsystem»
MI.Moduł Integracji
Organizator
«moduł» AW.MO.Moduł Organizatora
«moduł» AW.MU.Moduł Uwierzytelnienia
Wnioskodawca
«moduł» AW.MW.Moduł Wnioskodawcy
«podsystem»
WK.Węzeł Krajowy
Użytkownik niezalogowany
«moduł» AW.MC.Moduł CIDON
«podsystem»
ME.Moduł EPUAP
«komponent»
AW.BD.Repozytorium bazy danych
Systemy zewnętrzne
«System»
WK
«System»
EPUAP
Systemy PFRON
«System»
NEO
«System»
SODiR
«System»
ZUS
«System»
PESEL
«System»
KRUS
«System»
EGW
«System»
SOF2
«System»
EKSMOoN
«System»
MF
NAZWA | OPIS |
PFRON | Pracownik biura PFRON komunikuje się z modułem PFRON po uwierzytelnieniu się za pośrednictwem modułu uwierzytelnienia. Moduł PFRON może się ponadto komunikować: • z modułem zarządzającym po zleceniu przez pracownika biura PFRON masowej wysyłki wiadomości, • z modułem EPUAP w przypadku, gdy pracownik biura PFRON podpisuje dokument Profilem Zaufanym. |
Realizator | Realizator, będący pracownikiem: • Jednostki Samorządu Terytorialnego (JST) lub • Samorządowej Jednostki Organizacyjnej (SJO) lub • Oddziału Wojewódzkiego PFRON komunikuje się z modułem realizatora po uwierzytelnieniu się za pośrednictwem modułu uwierzytelnienia. Moduł realizatora może się ponadto komunikować: • z modułem integracji celem zweryfikowania wnioskodawcy w systemach zewnętrznych lub innych systemach PFRON, • z modułem CIDON w przypadku, gdy realizator pracuje w kontekście Oddziału Wojewódzkiego PFRON, • z modułem EPUAP w przypadku, gdy realizator podpisuje dokument Profilem Zaufanym. |
Organizator | Organizator, będący pracownikiem instytucji zajmującej się organizacją turnusów rehabilitacyjnych, komunikuje się z modułem organizatora po uwierzytelnieniu się za pośrednictwem modułu uwierzytelnienia. Moduł organizatora może się ponadto komunikować z modułem EPUAP w przypadku, gdy organizator podpisuje dokument Profilem Zaufanym. |
Wnioskodawca | Wnioskodawca składający wnioski obsługiwane przez system SOW komunikuje się z modułem wnioskodawcy po uwierzytelnieniu się za pośrednictwem modułu uwierzytelnienia lub Węzła Krajowego. Moduł wnioskodawcy może się ponadto komunikować z modułem EPUAP w przypadku, gdy wnioskodawca podpisuje dokument Profilem Zaufanym. |
Użytkownik niezalogowany | Użytkownik niezalogowany, będący potencjalnym wnioskodawcą, komunikuje się z modułem CIDON uruchamiając formularz zgłoszeniowy z poziomu strony xxxxx.xxx.xx |
EGW | EGW jest systemem zlokalizowanym w infrastrukturze PFRON. Na potrzeby integracji z systemem SOW system EGW wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
EKSMOoN | EKSMOoN jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW system EKSMOoN wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
EPUAP | ePUAP jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW system ePUAP wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
KRUS | KRUS jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW system KRUS wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
MF | MF jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW system MF wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
NEO | NEO jest systemem zlokalizowanym w infrastrukturze PFRON. Na potrzeby integracji z systemem SOW system NEO wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
PESEL | PESEL jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW system PESEL wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
SODiR | SODiR jest systemem zlokalizowanym w infrastrukturze PFRON. Na potrzeby integracji z systemem SOW system SODiR udostępnia widoki współdzielone z SOW. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
SOF2 | SOF2 jest systemem zlokalizowanym w infrastrukturze PFRON. Na potrzeby integracji z systemem SOW system SOF2 udostępnia widoki współdzielone z SOW. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
WK | Węzeł Krajowy jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW Węzeł Krajowy wystawia usługi dostępne przez webservice. Komunikacja między |
systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. | |
ZUS | ZUS jest systemem zewnętrznym, zlokalizowanym poza infrastrukturą PFRON. Na potrzeby integracji z systemem SOW system ZUS wystawia usługi dostępne przez webservice. Komunikacja między systemami odbywa się z wykorzystaniem połączenia tunelowego za pośrednictwem klienta VPN. |
AW.BD.Repozytorium bazy danych | Komponent umożliwiający trwały zapis danych. W przypadku systemu SOW używany jest silnik bazy mySQL. |
AW.MC.Moduł CIDON | Moduł przeznaczony dla użytkowników niezalogowanych i pracowników wojewódzkich oddziałów PFRON. Umożliwia realizację funkcjonalności dostępnych dla ww. grup użytkowników systemu poprzez interfejs graficzny. |
AW.MO.Moduł Organizatora | Moduł przeznaczony dla Organizatorów. Umożliwia realizację funkcjonalności dostępnych dla ww. grupy użytkowników systemu poprzez interfejs graficzny. |
AW.MP.Moduł PFRON | Moduł przeznaczony dla pracowników PFRON. Umożliwia realizację funkcjonalności dostępnych dla ww. grupy użytkowników systemu poprzez interfejs graficzny. |
AW.MR.Xxxxx Realizatora | Moduł przeznaczony dla Realizatorów. Umożliwia realizację funkcjonalności dostępnych dla ww. grupy użytkowników systemu poprzez interfejs graficzny. |
AW.MU.Moduł Uwierzytelnienia | Moduł uwierzytelniający wszystkich użytkowników systemu niezależnie od tego, do której grupy użytkowników należą (Wnioskodawcy, Organizatorzy, Realizatorzy, pracownicy PFRON). |
AW.MW.Moduł Wnioskodawcy | Moduł przeznaczony dla Wnioskodawców. Umożliwia realizację funkcjonalności dostępnych dla ww. grupy użytkowników systemu poprzez interfejs graficzny. |
AW.MZ.Moduł Zarządzający | Moduł realizujący czynności wykonywane w tle przy użyciu CRON-a. |
ME.Moduł EPUAP | Moduł umożliwiający podpisywanie dokumentów poprzez ePUAP. |
MI.Moduł Integracji | Moduł pośredniczący w komunikacji pomiędzy aplikacją webową i systemami: PFRON i zewnętrznymi. Moduł integruje się z ww. systemami poprzez webservice lub dostęp do współdzielonych widoków. |
WK.Węzeł Krajowy | Moduł umożliwiający podpisywanie dokumentów poprzez Węzeł Krajowy. |
3.4. Aktualne wykorzystanie Systemu.
Użytkownicy Systemu:
• pracownicy 380 jednostek samorządu terytorialnego, liczba użytkowników ponad
3500
• wnioskodawcy, łączna liczba użytkowników 315 000
• pracownicy 16 oddziałów PFRON, łączna liczba użytkowników 112
• pracownicy Centrali PFRON, łączna liczba użytkowników 88
• pracownicy 456 organizatorów turnusów rehabilitacyjnych, łączna liczba użytkowników 343
Liczby:
• Liczba użytkowników Systemu: ponad 320 000
• Liczba zarejestrowanych w Systemie wniosków: ponad 600 000
• Liczba szablonów wniosków ankiet i umów ponad 100
• Liczba zarejestrowanych szablonów dokumentów ponad 95 000
• Liczba utworzonych naborów na wnioski ponad 9300
Obciążenie Systemu wzrasta średnio o 30 % rocznie.
4.1 Wymagania dotyczące asysty technicznej i konserwacji.
W ramach Usług Asysty Technicznej i Konserwacji Wykonawca zobowiązany jest do:
prace serwisowe wymagające wyłączenia Systemu lub powodujące tymczasową niedostępność systemu i poszczególnych jego funkcjonalności.
ATK-02. Przyjmowania i obsługi Zgłoszeń Wad Systemu.
ATK-03. Usuwania Wad Systemu wszystkich kategorii zgodnie z wymaganiami opisanymi w pkt 4.1.2 Opisu Przedmiotu Zamówienia oraz Instalowanie na Środowisku Produkcyjny i Środowisku Demo Pakietów Aktualizacyjnych usuwających Wady
mając na uwadze, że na czas instalacji zawieszone jest ATK-01.
ATK-04. Instalacja Pakietu Aktualizacji 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.
ATK-05. Zapewnienia stałej opieki wyznaczonych przez Wykonawcę konsultantów i wsparcia przy rozwiązywaniu bieżących problemów związanych z funkcjonowaniem Systemu.
ATK-06. Zapewnienia utrzymania parametrów wydajnościowych Systemu na poziomie określonym w Załączniku nr 3 do Opisu Przedmiotu Zamówienia, pod warunkiem, że w tym czasie nie są prowadzone Prace Serwisowe
ATK-07. Utrzymania i administracji Sytemu w tym Oprogramowania Systemowego i
Narzędziowego oraz Oprogramowania Standardowego/Obcego
ATK-08. Aktualizację 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 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. Wymóg nie dotyczy aktualizacji, do których instalacji
ATK-09. Wydawania rekomendacji dotyczących przeprowadzania zmian, aktualizacji i
modernizacji Systemu.
ATK-10. Utrzymania wartości parametrów związanych z Usługą Asysty Technicznej i Konserwacji na warunkach opisanych w Załączniku nr 7 „Poziom świadczenia usług SLA” do Opisu Przedmiotu Zamówienia.
ATK-11. 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.
ATK-12. Wykonawca zobowiązany jest do 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
ATK-13. Realizacja Zgłoszeń dotyczących zaleceń powstałych w wyniku audytu WCAG oraz dostosowanie Systemu do wymagań opisanych w załączniku nr 4 do Opisu
ATK-14. Realizacja Zgłoszeń dotyczących Mikroraportów przy czym realizacja Zgłoszeń nie może przekraczać 10 godzin tygodniowo potrzebnych na ich realizację.
ATK-15. Bieżącej aktualizacji Dokumentacji Systemu oraz Kodów Źródłowych Systemu zgodnie z wymaganiami opisanymi w załączniku nr 5 do Opisu Przedmiotu Zamówienia. 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.
ATK-17. Przyjmowania Zgłoszeń i Naprawy Awarii Systemu.
ATK-18. W Dni Robocze w poza oknem serwisowym Wykonawca musi realizować usługi od
ATK-19. W Dni Robocze w Oknie Serwisowym Wykonawca musi realizować usługi XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00.
ATK-20. W Dni Świąteczne i Ustawowo Wolne Od Pracy Wykonawca musi realizować usługi:
XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, XXX-00.
ATK-21. W Dni Świąteczne i Ustawowo Wolne od pracy oraz w Oknie Serwisowym
Wykonawca musi realizować usługi: XXX-00, XXX-00, XXX-00, XXX-00, XXX-00, ATK- 16.
4.1.2 Zasady obsługi Zgłoszeń.
ATK-22. Zgłoszenie dokonywane jest za pośrednictwem Portalu Serwisowego przez upoważnionych Pracowników Wykonawcy oraz Zamawiającego wskazanych w Umowie.
ATK-23. 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.
ATK-24. 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.
ATK-25. 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.
ATK-26. 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.
ATK-27. Przyjmuje się, że do skutecznego Zgłoszenia Wady dochodzi z chwilą zarejestrowania Wady w Portalu Serwisowym i zaadresowanie jej do Wykonawcy z wyłączaniem sytuacji opisanej w ATK-28.
ATK-28. 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.
ATK-29. Po otrzymaniu Zgłoszenia Wykonawca potwierdzi istnienie i kategorię Wady oraz przystąpi do jej Naprawy.
ATK-30. Jeśli Wykonawca stwierdzi w trakcie działań naprawczych, że dla dokonania usunięcia Xxxx niezbędne jest podjęcie przez Xxxxxxxxxxxxx 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 usunięcia Wady.
ATK-31. 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.
ATK-32. Usunięcie Wady nie może powodować braku zgodności z zaleceniami WCAG 2.1 opisanymi w załączniku nr 4 do Opisu Przedmiotu Zamówienia.
ATK-33. Wykonawca przed zainstalowaniem Pakietu Aktualizacji na Środowisku Testowym wykona testy wewnętrzne zgodnie z załącznikiem nr 6 do Opisu Przedmiotu Zamówienia.
ATK-34. Zainstalowanie przez Wykonawcę Pakietu Aktualizacji usuwającego Wadę na Środowisku Testowym uznaje się za zgłoszenie przez Wykonawcę gotowości do Odbioru poprawki. 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.
ATK-35. Po zgłoszeniu gotowości Odbioru Pakietu Aktualizacji Zamawiający przystąpi niezwłocznie do weryfikacji poprawki.
ATK-36. 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.
ATK-37. 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. Do czasu obsługi Zgłoszenia nie są wliczane okresy potwierdzania przez Zamawiającego skuteczności dostarczonych poprawek.
ATK-38. Jeżeli Wykonawca nie dokona Naprawy / Obejścia w terminach, o których mowa w załączniku „Poziom świadczenia usług SLA” nr 7 Opisu Przedmiotu Zamówienia, 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 mogą być potrącone z wynagrodzenia przysługującego Wykonawcy lub z zabezpieczenia należytego wykonania przedmiotu Umowy;
2) obciążyć Wykonawcę karą umowną na zasadach opisanych w Umowie.
ATK-39. Potwierdzenie przez Xxxxxxxxxxxxx usunięcia Wady , upoważnia Wykonawcę do instalacji Pakietu Aktualizacji na Środowisku Produkcyjnym. Zakończenie instalacji na Środowisku Produkcyjnym kończy obsługę Zgłoszenia.
ATK-40. Zamknięcie Zgłoszenia w Portalu Serwisowym dokonywane jest po instalacji
poprawki na Środowisku Produkcyjnym i Środowisku Demo, przez upoważnionych Pracowników Zamawiającego wskazanych w Umowie.
ATK-41. 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.
ATK-42. W przypadku nie uzupełnienia zgłoszenia o wymagane w punkcie AT-41 informacje Zamawiający nie podpisze protokołu odbioru Usługi Asysty Technicznej i Konserwacji.
ATK-43. Po zamknięciu Zgłoszenia Wykonawca dostarcza zaktualizowaną Dokumentacje Systemu oraz zaktualizowaną wersje Kodów Źródłowych zgodnie z zasadami opisanymi w załączniku nr 5 Opisu Przedmiotu Zamówienia.
ATK-44. Wykonawca zobowiązany jest sporządzać comiesięczny Raport, który będzie określał liczbę oraz rodzaj zgłoszonych Wad wraz z opisem dotrzymania lub opóźnienia względem terminów wskazanych w Załączniku nr ….. do Umowy.
4.1.3 Zasady udzielania stałych konsultacji.
ATK-45. Konsultacje zgłaszane są w formie pytań za pośrednictwem Portalu Serwisowego przez upoważnionych Pracowników Zamawiającego wskazanych w Umowie
ATK-46. W wyjątkowych sytuacjach, gdy Portal Serwisowy jest niedostępny, Zamawiający dopuszcza możliwość przekazania Konsultacji drogą telefoniczną lub mailową, na adres wskazany do komunikacji pomiędzy Stronami oraz w ten sam sposób
zatwierdzenie Konsultacji i jej dalsze procedowanie. W chwili przywrócenia dostępności Portalu Serwisowego, Wykonawca jest zobowiązany do niezwłocznego uzupełnienia Konsultacji w Portalu Serwisowym.
ATK-47. Konsultacje udzielane są za pośrednictwem Portalu Serwisowego przez upoważnionych Pracowników Wykonawcy wskazanych w Umowie.
ATK-48. 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).
ATK-49. Przyjmuje się, że do skutecznego zawiadomienia dochodzi z chwilą zarejestrowania
i zaadresowania sprawy w Portalu Serwisowym.
ATK-50. Jeżeli Wykonawca nie będzie w stanie udzielić odpowiedzi w czasie określonym w załączniku „Poziom świadczenia usług SLA” nr 7 do Opisu Przedmiotu Zamówienia, jest zobowiązany powiadomić o tym fakcie Zamawiającego, z którym zostanie ustalony nowy termin udzielenia odpowiedzi.
ATK-51. 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ę.
ATK-52. W ramach udzielonych odpowiedzi dotyczących Przypadków Szczególnych,
Wykonawca opracuje i udostępni Zamawiającemu instrukcję opisującą rozwiązanie
danego przypadku.
4.1.4 Zasady aktualizacji Systemu.
ATK-53. 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 uaktualnień 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.
ATK-54. 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 uaktualnień 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.
ATK-55. Zasady aktualizacji Systemu obejmują również aktualizację Oprogramowania Systemowego i Narzędziowego oraz Oprogramowania Standardowego/Obcego.
ATK-56. 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 wewnętrznych i zewnętrznych o przerwie w działaniu Systemu i planowanym zakresie aktualizacji;
2) dostarczenie aktualizacji;
3) instalację aktualizacji na Środowisku Testowym;
4) instalację aktualizacji na Środowisku Produkcyjnym;
5) instalację na Środowisku Demo;
6) testy Systemu na Środowisku Produkcyjnym, Środowisku Testowym i Środowisku Demo;
7) wsparcie przy uruchamianiu Systemu na wyżej wymienionych środowiskach;
8) aktualizacje Dokumentacji Systemu oraz Kodów Źródłowych w formie
elektronicznej;
9) podniesienie numeru wersji Systemu.
4.1.5 Zasady zapewnienia kontroli i ciągłości działania Systemu oraz okresowych przeglądów.
ATK-57. W ramach przedmiotu zamówienia Wykonawca będzie realizował prace związane z utrzymaniem, konserwacją, administracją i aktualizacją systemów operacyjnych oraz oprogramowania firm trzecich (w tym w szczególności silników baz danych, serwerów aplikacyjnych oraz bibliotek programistycznych i narzędzi), które
wykorzystywane są do prawidłowego działania oprogramowania dziedzinowego podlegające usłudze utrzymania, a w szczególności będzie realizował prace
związane z:
1) monitorowaniem prawidłowości działania w/w systemów oraz
oprogramowania firm trzecich. W przypadku zidentyfikowania
niedostatecznej ilości zasobów Wykonawca zwróci się do Zamawiającego z wnioskiem o przydzielenie dodatkowych zasobów wraz ze wskazaniem ilości oraz określeniem powodu powstania w/w zapotrzebowania. Jeśli wskazane zasoby będą dostępne Zamawiający przydzieli zasoby w terminie nie dłuższym niż 10 dni roboczych od prawidłowo przedłożonego zapotrzebowania. Z
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 w/w 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 systemu operacyjnego, oprogramowania firm trzecich lub samego oprogramowania dziedzinowego. W/w czynności realizowane przez
Wykonawcę muszą zostać zrealizowane w terminie nie dłuższym niż 10 dni roboczych od momentu poinformowania Wykonawcy o dostępności dodatkowych zasobów,
2) uaktualnianiem systemu operacyjnego oraz oprogramowania firm trzecich do wersji aktualnie wspieranej. Przez uaktualnienie do wersji aktualnie
wspieranych Zamawiający rozumie czynności związane z podniesieniem wersji
systemu operacyjnego lub oprogramowania firm trzecich (w tym w
szczególności silnika bazy danych) oraz wykonanie testów na środowiskach Produkcyjnym, Testowym i Demo, 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 Standardowego, w tym dla systemów operacyjnych, serwerów aplikacyjnych,
serwerów bazodanowych, bibliotek programistycznych oraz oprogramowania firm trzecich wspierającego i niezbędnego do działania Systemu,
4) Zarządzaniem konfiguracją poszczególnych elementów Systemu oraz oprogramowania firm trzecich w celu optymalizowania działania i zapewnienia ciągłości działania,
5) administrowaniem systemem operacyjnym oraz oprogramowaniem firm trzecich, w tym w szczególności dostosowywanie w/w oprogramowania w zakresie zapewniania oczekiwanego poziomu optymalizacji działania
Oprogramowania, administrowania lokalnymi użytkownikami systemów
operacyjnych, przydzielanie lokalnych zasobów koniecznych do prawidłowego działania Oprogramowania,
6) analizowaniem oraz przygotowanie wytycznych w zakresie możliwości rozwojowych, realizacji zmian technologicznych mających na celu optymalizację pracy Oprogramowania z jednoznacznym wskazaniem
możliwości migracji do wskazanych przez Zamawiającego rozwiązań w tym w szczególności opis czynności do wykonania, przewidywaną pracochłonność oraz potencjalne występujące ryzyka.
7) administrowaniem certyfikatami służącymi do integracji Systemu z innymi systemami zewnętrznymi i wewnętrznymi.
ATK-58. Wykonawca zweryfikuje konfigurację i działanie obecnie wykorzystywanego narzędzia do monitorowania zasobów lub uruchomi i udostępni Zamawiającemu dostęp do interfejsu narzędzia do monitorowania parametrów eksploatacyjnych Systemu. W związku z tym Zamawiający wymaga, aby Wykonawca wykorzystał działające narzędzie diagnostyczne lub w przypadku jego niedostępności lub
niespełnienia wymagań, dostarczył narzędzie diagnostyczne, które za pomocą przeglądarki internetowej umożliwi:
1) monitorowanie maszyn wirtualnych, systemów baz danych, serwerów WEB pod kątem dostępności oraz wykorzystania ich zasobów,
2) monitorowanie serwerów aplikacyjnych, baz danych, serwerów WEB pod kątem wydajności,
3) generowanie w trybie ad-hoc zestawień dotyczących dostępności i wydajności wskazanych komponentów sprzętowo-programowych uzupełnionych o analizę wysycenia pasma łącza internetowego.
4.2 Wymagania dotyczące rozwoju.
W ramach Rozwoju Systemu Wykonawca zobowiązany jest do:
UMR-01. 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.
UMR-02. Dokonywania zmian w Systemie na potrzeby integracji z innymi systemami
wykorzystywanymi przez Xxxxxxxxxxxxx.
UMR-03. Utrzymania wartości parametrów związanych z Rozwojem na warunkach opisanych w załączniku nr 7 „Poziom świadczenia usług SLA” do Opisu Przedmiotu
Zamówienia.
4.2.2 Zasady realizacji Rozwoju.
UMR-04. Zamawiający nie jest zobowiązany do wykorzystania w całości limitu
Roboczogodzin, zgodnie z postanowieniami paragrafu nr ….. Umowy oraz zastrzega
sobie prawo wykorzystania dostępnych Roboczogodzin w dowolnym momencie trwania Umowy z zastrzeżeniem UMR-05 poniżej oraz UMR-06 poniżej.
UMR-05. Wykonawca nie może odmówić realizacji złożonego Wniosku i Zamówienia, poza przypadkami, gdy ich realizacja spowoduje przekroczenie limitu Roboczogodzin lub terminu świadczenia Rozwoju, o którym mowa w paragrafie nr ….. Umowy.
UMR-06. Zamawiający informuje, iż na trzy tygodnie przed upływem terminu realizacji umowy, Zamawiający nie będzie zlecał zmian modyfikujących System.
UMR-07. Zamawiający wymaga, aby Wykonawca przy realizacji prac w ramach Rozwoju dysponował zespołem projektowo-programowym, który może wykonać prace o zakresie nie mniejszym niż 3500 Roboczogodzin w trakcie jednego miesiąca.
UMR-08. 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 paragrafem nr
…… Umowy po udzieleniu przez Zamawiającego zgody na zastosowanie takiej
licencji lub po dostarczeniu jest przez Zamawiającego. Koszt pozyskania licencji
spoczywa na Wykonawcy.
UMR-09. 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.
UMR-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.
UMR-11. Wykonawca zobowiązany jest do zapewnienia zgodności Produktów
przekazywanych w ramach realizacji Rozwoju z zaleceniami zawartymi w załączniku nr 5 do Opisu Przedmiotu Zamówienia.
UMR-12. Wszystkie Wnioski i Zamówienia oraz inne materiały z realizacji Rozwoju (w tym z testów) muszą być przez Strony rejestrowane i prezentowane w Portalu
Serwisowym, w sposób pozwalający na archiwizację danych o czasie i treści Wniosków, Zamówień i ich realizacji.
4.2.3 Etapy realizacji Rozwoju Systemu
Procedura realizacji Rozwoju Systemu składa się z etapów:
• Etap I – analiza i wycena,
• Etap II - realizacja.
UMR-13. Zamawiający tworzy Zadanie w Portalu Serwisowym stanowiące Wniosek o dokonanie analizy, zawierający: podstawowe wymagania funkcjonalne i poza funkcjonalne oraz inne informacje mogące mieć wpływ na realizację Zadania.
UMR-14. Wykonawca w terminie do 10 Dni Roboczych od przekazania utworzonego Zadania, przedstawi Zamawiającemu w Portalu Serwisowym wynik analizy. Przy czym Strony mogą ustalić inny termin dostarczenia wyniku analizy przez
Wykonawcę. Ostateczna decyzja w tym zakresie należy do Zamawiającego.
UMR-15. Analiza powinna zawierać w szczególności (w zależności od przedmiotu Zadania):
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 biznesu,
perspektywa logiczna, oraz perspektywa danych),
3) projekty wszystkich modułów, które będą przedmiotem prac. 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 II 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,
UMR-16. Wycena, o której mowa w pkt UMR-15 powyżej musi zawierać, odrębnie dla każdej pozycji szacunkową liczbę Roboczogodzin niezbędną do przeprowadzenia:
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.
UMR-17. Zamawiającemu przysługuje prawo weryfikacji i akceptacji sposobu oraz czasochłonności wykonania przez Wykonawcę prac, który został przedstawiony przez Wykonawcę. Ostateczna akceptacja wyceny czasochłonności prac należy do Zamawiającego.
UMR-18. Zamawiający zobowiązany jest do przekazania Wykonawcy informacji czy
akceptuje, czy odrzuca przedstawiony przez Wykonawcę wynik etapu I.
UMR-19. Jeżeli Strony dokonają stosownych ustaleń przed rozpoczęciem realizacji Zadania, wycena Zadania (zadań składowych) może być aktualizowana w porozumieniu z Zamawiającym w miarę ustalania szczegółów realizacyjnych, które nie były znane
lub nie zostały doprecyzowane w chwili zlecania realizacji Zadania. Ostateczna akceptacja wyceny czasochłonności prac należy do Zamawiającego.
UMR-20. Zamawiający ma prawo zrezygnować z realizacji etapu II. Realizacja etapu I nie powoduje skutków finansowych dla Zamawiającego.
UMR-21. Końcowa wersja projektu realizacji Zadania zostaje uzgodniona w trybie
roboczym. Wycena realizacji prac w ramach Rozwoju uzgodniona w końcowej wersji projektu dotyczącej realizacji etapu II będzie stanowić podstawę wyliczenia wynagrodzenia za wykonanie Zadania.
UMR-22. W przypadku akceptacji projektu realizacji zadania Zamawiający może złożyć Zlecenie o realizację etapu II.
UMR-23. Wykonawca przystępuje do realizacji etapu II po otrzymaniu od Zamawiającego
Zlecenia etapu II.
UMR-24. Wykonawca przeprowadza testy wewnętrzne zgodnie z wymaganiami opisanymi w załączniku nr 6 do Opisu Przedmiotu Zamówienia na Środowisku Testowym
według przygotowanych przez siebie scenariuszy testowych i potwierdza Zamawiającemu ich wykonanie poprzez wprowadzenie stosownej informacji do Portalu Serwisowego.
UMR-25. Po przeprowadzeniu testów wewnętrznych Wykonawca zgłasza Zamawiającemu gotowość do testów akceptacyjnych.
UMR-26. Poinformowanie Zamawiającego 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.
UMR-27. Po zgłoszeniu gotowości Odbioru Zamawiający przystąpi niezwłocznie do
weryfikacji Pakietu Aktualizacji.
UMR-28. Zamawiający ma prawo do weryfikacji należytego wykonania usługi dowolną metodą. Zamawiający ma prawo przeprowadzić testy za pomocą samodzielnie zdefiniowanych scenariuszy testowych.
UMR-29. Zamawiający ma prawo żądać od Wykonawcy dostarczenia scenariuszy testowych
używanych przez Wykonawcę do prowadzenia testów wewnętrznych na
Środowisku Testowym. W przypadku gdy realizacja danego scenariusza testowego da wynik odmienny od zadeklarowanego przez Wykonawcę – Zamawiający naliczy Wykonawcy karę umowną, według zasad opisanych w paragrafie nr …… Umowy.
UMR-30. Po weryfikacji Pakietu Aktualizacji Zamawiający niezwłocznie potwierdzi
wykonanie lub stwierdzi niewykonanie usług. Usługa, która została odrzucona przez Zamawiającego podlega dalszym pracom, do czasu jej skutecznego wykonania.
UMR-31. Jeżeli Wykonawca nie wykona prac w terminach określonych w harmonogramie, o którym mowa w pkt UMR-15 powyżej, Zamawiający może:
1) wydłużyć termin wykonania Zlecenia na pisemną prośbę Wykonawcy zawierającą uzasadnienie i zmiany harmonogramu;
2) obciążyć Wykonawcę karą umowną na zasadach opisanych w Umowie.
UMR-32. Po zakończeniu testów akceptacyjnych Strony ustalają harmonogram instalacji Pakietu Aktualizacji na Środowisku Produkcyjnym i Środowisku Demo.
UMR-33. Nie później niż na 3 Dni Robocze przed Instalacja Pakietu Aktualizacji na
Środowisku Produkcyjnym Wykonawca dostarcza zaktualizowaną zgodnie z
wymogami opisanymi w załączniku nr 5 Opisu Przedmiotu Zamówienia, kompletną Dokumentację Systemu. Przekazany materiał 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.
UMR-34. Wykonawca nie później niż na 2 Dni Xxxxxxx przed Instalacja Pakietu Aktualizacji
na Środowisku Produkcyjnym zobowiązany jest każdorazowo przeprowadzić
warsztaty szkoleniowe on-line z nowych funkcjonalności dla Użytkowników i przedstawicieli Zamawiającego, jeśli Zlecenie zawiera takie zapotrzebowanie.
UMR-35. Instalacja Pakietu Aktualizacji na Środowisku Produkcyjnym realizowana będzie w czasie Okna Serwisowego, o ile Strony nie uzgodnią inaczej.
UMR-36. Zamawiający zastrzega sobie prawo rezygnacji z instalacji Pakietu Aktualizacji na Środowisku Produkcyjnym.
UMR-37. Zakończenie realizacji Zlecenia potwierdzane jest poprzez zamknięcie Zadania w
Portalu Serwisowym przez upoważnionego pracownika Zamawiającego wskazanego
w Umowie.
UMR-38. Zamknięcie Zadania w Portalu Serwisowym oznacza możliwość ujęcia Zadania w Protokole Odbioru Rozwoju, którego wzór zawiera Załącznik nr …… do Umowy.
UMR-39. Podpisanie Protokołu Odbioru, o którym mowa w pkt UMR-38 powyżej, bez zastrzeżeń jest podstawą do wystawienia przez Wykonawcę faktury.
UMR-40. Z chwilą potwierdzenia Protokołem Odbioru, bez zastrzeżeń wykonania Zlecenia, Wykonawca obejmuje Produkty, o których mowa w UMR-01, Usługami Asysty Technicznej i Konserwacji, oraz gwarancją, o której mowa w paragrafie nr ….
Umowy bez zmiany wynagrodzenia przysługującego z tytułu realizacji Umowy oraz przenosi na Zamawiającego autorskie prawa majątkowe oraz zależne prawa do
Produktu na zasadach opisanych w paragrafie nr …. Umowy.
UMR-41. Protokół Odbioru Produktów wykonanych w ramach Rozwoju zawierać będzie
informację o liczbie Roboczogodzin, w ramach których Produkty zostały wykonane.
Liczba Roboczogodzin wskazana w zaakceptowanym przez Zamawiającego Protokole Odbioru będzie podstawą do rozliczenia limitu Roboczogodzin na Rozwoju, określonego w niniejszej Umowie.
UMR-42. Wynagrodzenie z tytułu realizacji Rozwoju będzie płatne po odebraniu przez Zamawiającego wszystkich prac lub Produktów objętych danym Zleceniem, na podstawie prawidłowo wystawionej faktury VAT i odpowiedniego Protokołu Odbioru.
UMR-43. W szczególnych przypadkach za zgodą stron realizacje zlecenia może się odbyć w metodologii zwinnej na przykład Scrum lub Agile.
5. Wymagania wydajnościowe i niezawodnościowe.
Szczegółowe wymagania zawiera Załącznik nr 3 do Opisu Przedmiotu Zamówienia.
Szczegółowe wymagania zawiera Załącznik nr 4 do Opisu Przedmiotu Zamówienia.
7. Wymagania dla Dokumentacji.
Szczegółowe wymagania zawiera Załącznik nr 5 do Opisu Przedmiotu Zamówienia.
8. Wymagania dotyczące testów.
Szczegółowe wymagania zawiera Załącznik nr 6 do Opisu Przedmiotu Zamówienia.
9. Poziom świadczenia usług SLA.
Szczegółowy opis zawiera Załącznik nr 7 do Opisu Przedmiotu Zamówienia.
Załącznik nr 1: Podręcznik użytkownika wewnętrznego.
Dokument stanowi oddzielny załącznik do opisu przedmiotu zamówienia.
Załącznik nr 2: Podręcznik użytkownika zewnętrznego.
Dokument stanowi oddzielny załącznik do opisu przedmiotu zamówienia.
Załącznik nr 3: Wymagania wydajnościowe.
WSC-01. System musi móc efektywnie obsłużyć 20 000 pojedynczych sesji w ciągu doby.
WSC-02. Czas reakcji Systemu na zatwierdzenie formularza nie przekroczy 2 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.
WSC-03. 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).
WSC-04. 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.
WSC-05. 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.
WSC-06. Wszelkie planowane przerwy w działaniu Systemu związane z wykonywaniem optymalizacji muszą być uzgodnione z Zamawiającym.
Załącznik nr 4: Wymagania WCAG 2.1
WCA-01. Wykonawca jest zobowiązany zapewnić dostępność cyfrową serwisu na poziomie WCAG 2.1 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)
WCA-02. Materiałami referencyjnym odnośnie spełnienia wytycznych WCAG 2.1 są:
1) Web Content Accessibility Guidelines (WCAG) 2.1 – wersja polska: xxxxx://xxx.x0.xxx/Xxxxxxxxxxxx/XXXX00-xx/
2) Poradnik „Jak spełnić WCAG” – wersja polska: xxxxx://xxxx.xxxxxxxxx.xx/
3) Techniki WCAG – opis możliwych technik pozwalających spełnić poszczególne wytyczne WCAG 2.1: xxxxx://xxx.x0.xxx/XXX/XXXX00/Xxxxxxxxxx/#xxxxxxxxxx
WCA-03. W trakcie projektowania typowych elementów interfejsów, takich jak x.xx. menu, nawigacja, okna modalne, formularze, nawigacja okruszkowa, tabele, karuzele itp., Wykonawca powinien korzystać ze wzorców projektowych i dobrych praktyk opisanych na stronach:
1) xxxxx://xxx.x0.xxx/XX/xxx-xxxx-xxxxxxxxx/
2) xxxxx://xxx.x0.xxx/XXX/xxxxxxxxx/
WCA-04. Wątpliwości dotyczące sposobów wdrażania dostępności cyfrowej będą
rozstrzygane na podstawie dokumentacji opracowanej przez X0.xxx.
WCA-05. Niżej wymienione narzędzia wspierają tworzenie dostępnych cyfrowo serwisów oraz umożliwiają wczesne wykrycie części problemów z obszaru dostępności
cyfrowej. Należy jednak pamiętać, że narzędzia automatyczne nie wykrywają wszystkich niezgodności z WCAG 2.1 – konieczna jest weryfikacja przez wyspecjalizowanego audytora WCAG, lista narzędzi:
1) NVDA – czytnik ekranu xxxxx://xxxx.xx/
2) WAVE – narzędzie do wstępnej wizualnej ewaluacji zgodności strony z WCAG
3) ARC Toolkit – rozszerzenie do przeglądarki Chrome, wspierające badanie kodu
strony: xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxx/xxxxxx/xxx-xxxxxxx/
4) ANDI – bookmarklet dla przeglądarki Chrome: xxxxx://xxx.xxx.xxx/xxxxxxxxxxxxx/xxxx/xxxx/xxxxxxx.xxxx
5) Color Contrast Analyser – narzędzie do weryfikowania kontrastu elementów
strony xxxxx://xxx.xxxx.xxx/xxxxx-xxxxxxxx-xxxxxxx/
WCA-06. Wszystkie strony Serwisu muszą być bezbłędne pod względem jakości kodu HTML z
walidatorem xxxxx://xxxxxxxxx.x0.xxx/xx/.
W trakcie wdrożenia mogą się pojawić sytuacje, w których z jakichś przyczyn Zamawiający może zaakceptować błędy HTML. Muszą to być jednak udokumentowane i uzasadnione przypadki, które będą związane z niestabilnością specyfikacji HTML5 i będą działać np. na rzecz dostępności.
WCA-07. Serwis ma być realizowany w pełnej zgodności ze specyfikacją HTML5.
Przykłady poprawności semantycznej:
1) Linki powinny być wykonane za pomocą znacznika <a>;
2) Nagłówki powinny być wykonane za pomocą znaczników <h1>...<h6>;
3) Przyciski powinny być wykonane za pomocą znaczników <button> lub <input
type="button">;
4) Listy powinny być wykonane za pomocą znaczników <ul> / <ol> i <li> dla poszczególnych elementów;
5) Rozwijane listy formularzy powinny być wykonane za pomocą znaczników
<select> / <option>.
Przykłady błędów semantycznych:
1) Link wykonany za pomocą <span> (oskryptowany JavaScript);
2) Nagłówek w formie <p class="heading">;
3) Lista rozwijana w formularzu wykonana za pomocą znaczników listy <ul> / <li>.
WCA-08. Atrybuty ARIA muszą stanowić uzupełnienie semantyki HTML. Ta technologia jest przeznaczona przede wszystkim dla użytkowników czytników ekranu. Szczególnie ważne jest jej zastosowanie w komponentach stron internetowych, które opierają się na rozbudowanej interakcji JavaScript. Stosowanie atrybutów ARIA można podzielić na dwie części:
1) Uzupełnienie głównych bloków Serwisu o punkty orientacyjne;
2) Dodatki do formularzy lub takich komponentów stron, jak np. karuzele,
zakładki (tabs), menu rozwijane, bloki rozwijane, okna modalne, alerty, slidery.
Głównym źródłem informacji powinna być dokumentacja Aria Techniques for WCAG 2.2. xxxxx://xxx.x0.xxx/XXX/XXXX00/Xxxxxxxxxx/ Zamawiający
zastrzega sobie prawo do weryfikacji Serwisu, 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 specyfikacją ARIA Wykonawca zobowiązany jest do ich usunięcia na własny koszt w terminie wskazanym przez Zamawiającego.
WCA-09. Wszystkie tytuły stron Serwisu muszą być automatycznie generowane na podstawie informacji, które pozwolą Użytkownikowi dowiedzieć się, co jest treścią danej strony.
WCA-10. Język naturalny treści na stronie powinien być zawsze oznaczony odpowiednim atrybutem lang. W założeniu wszystkie strony Serwisu będą miały atrybut lang o treści "pl".
WCA-11. W Serwisie wszystkie linki powinny być zrozumiałe poza kontekstem tekstowym bądź wizualnym. W stałych częściach Serwisu może oznaczać to potrzebę
uzupełniania krótkich linków o treści uzupełniające.
WCA-12. Wszystkie grafiki zamieszczone w szablonach za pomocą znacznika <img> powinny mieć atrybut alt.
1) W przypadku, gdy grafika nie będzie przekazywać żadnej treści (grafiki dekoracyjne), powinny być umieszczane za pomocą CSS, czyli stosując
właściwość background-image. Inną metodą jest dodanie do <img> - pustego alt— zapis alt lub alt="".
2) Jeśli grafika będzie przekazywać treść, alt powinien być uzupełniony o
adekwatny opis.
3) Jeśli grafika będzie linkiem, to opis alternatywny powinien przekazywać funkcję linku, tak jakby to był link tekstowy.
WCA-13. Budowa formularzy pod względem dostępności musi się opierać o dobre praktyki HTML5. Trzeba uwzględnić, że formularze mogą być używane przez osoby
niewidome, niepełnosprawne ruchowo czy głucho-niewidome. W większości przypadków jako podstawy semantyki HTML dla formularzy rozumie się:
1) użycie etykiet do wszystkich pól,
2) zrozumiałość etykiet,
3) dostęp do wszelkich wskazówek bez konieczności patrzenia na ekran, np. za pośrednictwem czytnika ekranu (wskazówki, komunikat do obiektów
formularzy powinny być powiązane semantycznie z tym obiektem, np. poprzez
aria-describedby),
4) kolejność treści i pól formularzy wspierająca użyteczność i zrozumiałość.
WCA-14. Należy zadbać o właściwą dostępność informacji na formularzach dostarczając informację, w jaki sposób wypełnić pola oraz informacji o błędach.
1) wszystko, co możliwe, jest wykonane za pomocą podstawowych elementów HTML + JavaScript — im dalej będzie sięgać wsteczna kompatybilność, tym lepiej,
2) jeśli formularz będzie tego wymagał, mogą zostać zastosowane atrybuty ARIA.
3) Kolejność w powyższym wypunktowaniu jest ważna - Użytkownicy mogą korzystać z przestarzałego oprogramowania. Dlatego warto zagwarantować wsteczną kompatybilność w jak największym stopniu.
WCA-15. Kluczowe dla tabel jest stosowanie odpowiedniej składni i semantyki HTML. Czytniki ekranu wspierają obsługę tabel bardzo dobrze. Wskazówki w zakresie tworzenie dostępnych tabel: xxxxx://xxx.x0.xxx/XXX/xxxxxxxxx/xxxxxx/.
WCA-16. Należy stosować zarządzanie fokusem przez JavaScript w taki sposób, aby nie stworzyć tzw. pułapki klawiaturowej. Taki błąd powoduje utrudnienia dla
Użytkowników z niepełnosprawnością ruchu oraz korzystających z czytników
ekranu.
WCA-17. Fokus klawiatury powinien mieć kolejność wedle reguły od lewej do prawej oraz od góry do dołu. Przykładowo, po przejściu fokusem menu głównego, powinien on
trafić do głównego bloku treści lub lewej kolumny.
WCA-18. W niektórych przypadkach, np. w linkach, może być konieczne stosowanie ukrytej treści. Takie rozwiązanie wspiera korzystanie z Serwisu przez Użytkowników niewidomych. Polecamy artykuł opisujący techniki ukrywania treści:
xxxx://xxxxxx.xxx/xxxxxxxxxx/xxx/xxxxxxxxxxxxxxxx/ (techniki ukrywania treści).
WCA-19. Należy zabezpieczyć formularze w taki sposób, który nie stwarza barier oraz niewygód dla Użytkownika Serwisu. W tym przypadku trzeba będzie uważać z
rozwiązaniami typu CAPTCHA. Tego typu zabezpieczenia najczęściej nie są w stanie zapewnić dostępności dla wszystkich odbiorców. W miarę możliwości filtrowanie spamu i działań niepożądanych należy pozostawić po stronie serwera lub w sposób niewidoczny dla Użytkownika. Jeśli Wykonawca będzie proponował rozwiązanie
typu CAPTCHA, to będzie ono bardzo dokładnie testowane pod kątem dostępności dla wszystkich Użytkowników.
WCA-20. Wszelkie działania związane z przeładowaniem widoku takie jak:
• filtrowanie,
• sortowanie,
• wyszukiwanie.
muszą być dobrze przetestowane z czytnikami ekranu. W takich sytuacjach
kluczowy będzie komfort w obsłudze bezwzrokowej. Użytkownik powinien zawsze mieć pełną wiedzę na temat działania interfejsu i świadomość tego, że treść
strony została zaktualizowana. Należy także przyjąć ogólną zasadę, że zmiany
treści strony bez przeładowania stosowane są tylko w uzasadnionych sytuacjach. W niektórych przypadkach, po zmianie przefiltrowania może być też konieczna automatyczna zmiana tytułu strony <title>.
WCA-21. Serwis 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>.
WCA-22. Na każdej stronie Serwisu powinien działać link „Przejdź do wyszukiwania”,
„Przejdź do głównej treści”, które pomagają przeskoczyć fokusem bezpośrednio do głównej funkcjonalności danej strony. Najczęściej będzie to oznaczać przeskoczenie bloku nagłówkowego wraz z „okruszkami”. Po przeskoczeniu fokus najczęściej powinien zaczynać się w okolicy nagłówka <h2> - treść strony.
WCA-23. Serwis powinien być zbudowany z myślą o urządzeniach mobilnych, które coraz częściej pełnią ważniejszą rolę w odbiorze treści internetowych. Serwis powinien być zbudowany w oparciu o najlepsze i aktualne praktyki tworzenia serwisów responsywnych.
Wykonawca musi przygotować wszystkie projekty graficzne z zastosowaniem skoków responsywnych szerokości w odniesieniu do typów urządzeń (standardów):
• smartfon – z rozdzielczością 360x640 (wartość średnia) w wersji pionowej oraz poziomej (z uwzględnieniem wartości minimalnej 320 px),
• tablet - z rozdzielczością 768x1024 w wersji pionowej oraz poziomej,
• monitor komputerowy - z rozdzielczością 1366x768 (wartość średnia), z uwzględnieniem wartości minimalnej – 900 px oraz wartości maksymalnej - 1920 px.
Podczas realizacji należy zwrócić uwagę, aby w szczególności w wartościach minimalnych obiekty nie zachodziły na siebie i nie przykrywały treści bądź funkcjonalności.Projektując widoki mobilne należy uwzględnić minimalną wielkość fontów – 16 px. Jest to wartość ważna podczas analizy czytelności strony.
WCA-24. Działanie Serwisu będzie analizowane przy użyciu:
• popularnych czytników ekranu — NVDA, Jaws,
• powiększalników takich jak ZoomText,
• trybu wysokiego kontrastu Windows,
• urządzeń typu switch,
• urządzeń mobilnych z systemami Android / iOS, a w tych systemach z:
o czytnikami ekranu,
o rozwiązaniami typu switch,
o powiększaniem ekranu i tekstu.
Powyższe będzie weryfikowane przez Zamawiającego podczas warsztatów
odbiorczych.
WCA-25. Kontrast między kolorem tekstu a kolorem tła, na jakim jest on prezentowany,
musi wynosić minimum 4,5:1. Prostym narzędziem do analizy poziomu kontrastu jest Color Contrast Analyzer. Między innymi tym narzędziem będzie wykonywana weryfikacja zgodność projektu graficznego z zapisami Przedmiotu Umowy w
ramach warsztatów odbiorowych.
W związku z wymogami dotyczącymi kontrastu, nie powinny być w Serwisie stosowane elementy prezentujące tekst na tle niejednorodnym, np. bezpośrednio na tle zdjęcia. Stosowanie kolorystyki mniej kontrastowej jest dopuszczalne tylko w zakresie graficznych elementów dekoracyjnych w Serwisie.
WCA-26. Linki tekstowe muszą być jasno identyfikowalne przez wszystkich Użytkowników Xxxxxxx. Oznacza to, że muszą odróżniać się od tekstu zarówno kolorem jak i podkreśleniem. Podkreślenie powinno być użyte w projekcie graficznym wyłącznie do oznaczenia linków. To samo dotyczy koloru linków. Kolor ten nie może być powtórzony na żadnym elemencie nieklikalnym. Kolor ten musi również spełniać wymogi wskazane w punkcie “Kontrast treści”. Po oznaczeniu linku kursorem myszy (hover) podkreślenie linku ma znikać, a kolor linku zmieniać się na kolor o wyższym wskaźniku kontrastu do tła niż przy kolorze bazowym linku.
WCA-27. Wymóg widoczności dotyczy również formularzy stosowanych w Serwisie. W szczególności odnosi się to do widoczności ramek pól, etykiet pól oraz przycisków.
Wszystkie elementy formularzy muszą spełniać wymóg kontrastu w stosunku do
tła na poziomie minimum 3:1. Analogicznie jak w przypadku linków, także przyciski formularzy, po oznaczeniu kurosem myszy muszą stawać się bardziej widoczne dla Użytkowników (zwiększenie kontrastu między kolorem przycisku a kolorem tekstu przycisku). Etykiety pól powinny być widoczne i prezentowane bezpośrednio obok pola. W niektórych przypadkach etykieta może być ukryta, na przykład w funkcji wyszukiwarki. Informacje o błędach powinny być prezentowane tekstowo,
bezpośrednio obok pól (dodatkowo powiązane z polem poprzez ARIA), których dotyczą oraz pod nagłówkiem rozpoczynającym blok z formularzem.
WCA-28. Cały Serwis i każda jego funkcjonalność będą dostępne przy nawigacji za pomocą samej klawiatury. Fokus klawiatury powinien mieć formę wzmocnioną w stosunku do fokusu domyślnego przeglądarki i być widoczny przy nawigacji za pomocą
klawiatury w formie ramki, wokół aktualnie wybranego elementu. Kolor ramki fokusu powinien być dobrany do schematu kolorystycznego Serwisu, a jednocześnie bardzo dobrze widoczny na każdym oznaczonym elemencie
(minimalny kontrast – 3:1). Przykład dobrze widocznego fokusu można znaleźć w serwisie xxx.xxxxx.xxx.xx - wystarczy zacząć nawigację w serwisie za pomocą przycisku TAB. Do rozróżnienia fokusa klawiatury i myszki można wykorzystać
bibliotekę dostępną na stronie: xxxxx://xxxxxx.xxx/xxx0xxxxx/xxxx-xxxxx
WCA-29. Czcionka(i) użyta w Serwisie powinna być bezszeryfowa oraz zachowująca wysoki poziom czytelności także przy dużym powiększeniu. Przykładami tego typu
czcionek są np. Lato, Open Sans czy PT Sans.
Liczba czcionek (kroju i wielkości) powinna zostać ograniczona w projekcie graficznym Serwisu do niezbędnego minimum.
WCA-30. W ramach Serwisu zostaną zaplanowane i zaprezentowane widoki takich tekstowych elementów semantycznych jak:
• nagłówek poziomu 1,
• nagłówek poziomu 2,
• nagłówek poziomu 3,
• nagłówek poziomu 4,
• nagłówek poziomu 5,
• nagłówek poziomu 6,
• 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ść czcionek użytych w poszczególnych stylach powinna odpowiadać hierarchii tych styli względem siebie. Zalecamy przyjęcie zasady, iż nagłówek poziomu 6 powinien być co najmniej wielkości czcionki podstawowej, tylko
pogrubionej. Minimalna wielkość czcionki dopuszczalnej w projekcie graficznym to 12 px., przy czym treść podstawowa powinna mieć wielkość minimum 16 px. Dla treści nie powinno być stosowane formatowanie wersaliki.
Odstępy między wierszami w akapitach powinny wynosić przynajmniej 1,3-1,5 wysokości linii, a odległość między akapitami powinna być przynajmniej 1,5 razy
większa niż ta pomiędzy wierszami. W jednym wersie powinno być prezentowane maksymalnie 85 znaków. Żadna treść w projekcie graficznym nie powinna być justowana (równocześnie wyrównana do lewej i prawej). Dopuszczalne jest tylko
wyrównanie do lewej, a w uzasadnionych sytuacjach wyśrodkowanie tekstu. Tam,
gdzie tylko to możliwe, treść powinna być prezentowana w formie tekstu, a nie grafiki tekstu. Do osiągnięcia pożądanego wyglądu powinny być użyte odpowiednie style CSS.
WCA-31. Tabele z danymi prezentowane w projekcie graficznym powinny uwzględniać wyraźnie odróżniające się od reszty komórek wersy/kolumny nagłówkowe.
WCA-32. Koncepcja Serwisu zakłada możliwość swobodnej zmiany wielkości strony (Ctrl ++
oraz Ctrl + -). Przy każdej szerokości ekranu/poziomie powiększenia (nie tylko dedykowanej dla tabletów i smartfonów) wszystkie treści i funkcje Serwisu powinny być dostępne w czytelnej formie. Projekt graficzny musi umożliwiać zaprogramowanie w ten sposób Serwisu.
WCA-33. Elementy ruchome w Serwisie są dopuszczalne, ale tylko w połączeniu z
przyciskiem umożliwiającym Użytkownikowi zatrzymanie tego ruchu i ponowne uruchomienie. Żaden element Serwisu nie może migać.
WCA-34. Materiały wideo powinny być prezentowane za pomocą standardowego odtwarzacza YouTube. Projekt graficzny powinien uwzględniać zamieszczanie bezpośrednio pod materiałem wideo linku do transkrypcji tekstowej materiału.
Załącznik nr 5: Wymagania dotyczące dokumentacji.
DOK-01. W przeciągu 10 dni roboczych od podpisania umowy Wykonawca przedstawi w ramach Usługi Asysty Technicznej i Konserwacji koncepcję Repozytorium
Projektowego możliwą do realizacji z wykorzystaniem narzędzi będących w posiadaniu Zamawiającego.
DOK-02. 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 Xxxxxxxxxxxxx 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.
DOK-03. 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.
DOK-04. Wykonawca odpowiedzialny jest za sporządzanie notatek ze spotkań projektowych
i umieszczanie ich w Repozytorium Projektowym.
DOK-05. W uzupełnieniu do dokumentacji w Repozytorium Projektowym, Wykonawca prowadzi i utrzymuje następujące repozytoria i bazy wchodzące w jego skład:
• Repozytorium Architektury – zawierające model architektury, obejmujący
opis:
• Warstwy Podsystemowej.
• Architektury Logicznej.
• Architektury Fizycznej.
• Infrastruktury Sieciowej.
• Model dziedziny.
• Repozytorium zarządzania certyfikatami.
• Repozytorium procesów biznesowych.
• Opis integracji z systemami zewnętrznymi.
DOK-06. Repozytorium Architektury będzie x.xx. służyć jako źródło do generowania części lub całości dokumentacji Systemu omawianej w niniejszym Załączniku.
Repozytorium Architektury musi być prowadzone w narzędziu Sparx Enterprise
Architect.
Załącznik nr 6: Wymagania dotyczące testów.
WT 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.
WT2 - 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 wraz ze scenariuszami testowymi 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.
Załącznik nr 7: Poziom świadczenia Usług (SLA).
Wykonawca zobowiązuje się świadczyć usługi z zachowaniem następujących parametrów
SLA (Service Level Agreement):
1. Usługi Asysty Technicznej i Konserwacji.
Kalendarz świadczenia usługi | Przez 24 godziny 7 dni w tygodniu 365 dni w roku („24/7/365”). Okno serwisowe w godzinach: 21.00 – 7.00. Przyjmowanie i obsługa: Dni Robocze w godzinach: 7:00 – 18:00. | |||||
Czasy realizacji | Lp. | Nazwa Wady | Czas Naprawy | Czas Obejścia | ||
1. | Awaria | 8 godzin | 4 godziny | |||
2. | Błąd | 24 godzin | 12 godzin | |||
3. | Xxxxxxx | 00 godziny | Nie dotyczy | |||
4. | Pytanie | 32 godziny | Nie dotyczy | |||
Definicje znajdują się w słowniku w pkt 1 Opisu Przedmiotu Zamówienia. | ||||||
Poziom | RPDS – rzeczywisty poziom dostępności Systemu |
dostępności | RPDS ≥ 98,04% |
usługi | RPDS obliczany jest wg wzoru: |
(TD - ∑ TN) / TD *100[%] | |
Gdzie: | |
TD – uzgodniony czas dostępności usługi, wynikający z kalendarza | |
dostępności usługi, po odjęciu uzgodnionych okien serwisowych [w | |
godzinach]. | |
TN – czas trwania niedostępności usługi, zaistniałej w wyniku wystąpienia | |
Awarii [w godzinach]. | |
Wyliczenie minimalnego progu RPDS: | |
TN – czas trwania niedostępności usługi - przyjmujemy dopuszczalnie jedną | |
Awarię w miesiącu – gdzie Czas Naprawy to 11 godzin. | |
∑ TN = (1*10) = 10 godzin (zgodnie z podanymi wartościami parametru | |
niezawodności usługi). | |
TD = 30 dni * 17 godzin = 510 godzin (zgodnie z podanym kalendarzem | |
dostępności usługi). | |
RPDS = (510 godzin - 10 godzin) / 510 godzin * 100 = 98,04% | |
Przykłady wyliczeń RPDS: | |
Przykład 1 | |
W miesiącu nie wystąpiła niedostępność. | |
RPDS = (510 - 0) / 510 *100 = 100 %. | |
Przykład 2 | |
W miesiącu wystąpiła jedna Wada – naprawiona w 9 godzin. | |
RPDS = (510- 9) / 510* 100 =98,24 %. | |
Przykład 3 | |
W miesiącu wystąpiły 0 Xxxx Xxxxxxx - Xxxxxx naprawiona w 26 Godzin | |
Roboczych + Awaria naprawiona w 6 Godzin Roboczych. | |
TN = 26 + 6 = 32 | |
RPDS = (510- 32) / 510* 100 = 93,73%. |
Przykład 1 i 2 nie powoduje możliwości naliczenia kary umownej. Przykład 3 gdzie RPDS=93,73% jest poniżej wymaganego poziomu 98,04% - może być naliczona kara umowna zgodnie z tabelą zawartą w Umowie w § nr …. | |
Terminowość | PDTN – poziom dotrzymania terminów naprawy lub odpowiedzi PDTN ≥ 97,00% PDTN jest obliczany wg wzoru: Σ (Wx * Px) / Σ Wx [%] Gdzie: Px – wskaźnik dotrzymania terminów naprawy zgłoszeń serwisowych dla danej Wady lub odpowiedzi, obliczany wg wzoru: Ax / Bx * 100 [%]. Ax – liczba zgłoszeń serwisowych danej Wady lub odpowiedzi, dla których w danym miesiącu kalendarzowym nie został przekroczony Czas Naprawy. Bx – liczba wszystkich zgłoszeń serwisowych danej Wady lub odpowiedzi, zarejestrowanych w danym miesiącu kalendarzowym. Wx – waga zgłoszenia serwisowego danej Wady lub odpowiedzi. Wcn – wymagany czas Naprawy zgodny z przyjętymi Czasami realizacji. Fcn – faktyczny czas naprawy W poniższej tabeli znajdują się wartości Wx i Px dla poszczególnych rodzajów Wad lub odpowiedzi. Wyliczenie minimalnego progu PDTN: PDTN = (10 * 100 + 7 * 96 + 5 * 93 + 3 * 96) / (10 + 7 + 5 + 3) = 97,00% |
Nazwa Wady | Wx | Px [%] |
Awaria | 10 | 100,00 |
Błąd | 7 | 96,00 |
Xxxxxxx | 0 | 93,00 |
Pytanie | 3 | 96,00 |
Przykłady wyliczeń PDTN:
Przykład 1
Nazwa Wady | Nr zdarz enia | Wymagany czas naprawy Wcn | Faktyczny czas naprawy Fcn | Czy na czas >=0 w terminie, a <0 po terminie (kolumna 3 – 4) | Px | Wx |
Awaria | 1 | 4 | 4 | 0 | 100,00 | 10 |
Błąd | 1 | 15 | 13 | 2 | 100,00 | 7 |
2 | 15 | 8 | 7 | |||
3 | 15 | 10 | 5 | |||
Usterka | 1 | 23 | 10 | 13 | 100,00 | 5 |
Zgodnie z wzorem:
PDTN = (10 * 100 + 7 * 100 + 5 * 100) / (10 + 7 + 5) = 100%
Przykład 2
Nr
Nazwa
zdarz
Wady
enia
Wymagany czas naprawy
Wcn
Faktyczny czas naprawy
Fcn
Czy na czas >=0 w terminie,
a <0 po Px Wx terminie
(kolumna 3 – 4)
Awaria 1 4 4 0 100,00 10
1 15
Błąd
2 15
18 -3
5 10
66,67 7
3 | 15 | 9 | 6 | ||||||
Usterka | 1 | 23 | 10 | 13 | 100,00 | 5 | |||
Zgodnie z wzorem: PDTN = (10 * 100 + 7 * 66,67 + 5 * 100) / (10 + 7 + 5) = 89,40% Przykład 3 Zgodnie z wzorem: PDTN = (10 * 0 + 7 * 66,67 + 5 * 100) / (10 + 7 + 5) = 43,94% Przykład 1 nie powoduje możliwości naliczenia kary umownej. Przykład 2 i 3 gdzie PDTN=89,40 i PDTN=43,94% jest poniżej wymaganego poziomu 97,00% - może być naliczona kara umowna zgodnie z tabelą zawartą w Umowie w § nr …. | |||||||||
Niezawodność | Liczba incydentów o rodzaju Wady – Awaria ≤ 2 / miesiąc | ||||||||
Lista i częstotliwość raportów | • Miesięcznie | ||||||||
Nazwa Wady | Nr zdarz enia | Wymagany czas naprawy Wcn | Faktyczny czas naprawy Fcn | Czy na czas >=0 w terminie, a <0 po terminie (kolumna 3 – 4) | Px | Wx |
Awaria | 1 | 4 | 7 | -3 | 0,00 | 10 |
Błąd | 1 | 15 | 18 | -3 | 66,67 | 7 |
2 | 15 | 9 | 6 | |||
3 | 15 | 13 | 2 | |||
Usterka | 1 | 23 | 10 | 13 | 100,00 | 5 |
2. Rozwoju.
Kalendarz świadczenia Rozwoju | Przez 24 godziny 7 dni w tygodniu 365 dni w roku („24/7/365”). Okno serwisowe w godzinach: 21.00 – 7.00. Przyjmowanie i obsługa: Dni Robocze w godzinach: 7:00 – 18:00 | |||||||
Czasy realizacji | Lp. | Nazwa | Czas realizacji usługi | |||||
1. | Rozwój - etap I | 10 Dni Roboczych | ||||||
2. | Rozwój - etap II | Ustalany indywidualnie | ||||||
Wskaźnik: WJCR | WJCR – wskaźnik jakościowy czasu realizacji WJCR jest obliczany wg wzoru: ∑𝒏 𝑻𝒁𝒊 𝒊=𝟏 WJCR = 𝑻𝑾𝒊 𝒏 Gdzie: TZi – faktyczny czas realizacji etapu; TWi – ustalony lub wymagany czas realizacji etapu; i – każdy zakończony etap (dla wszystkich prac wykonanych lub rozpoczętych w ramach Rozwoju ) 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. Przykłady wyliczeń WJCR: Przykład 1 | |||||||
Nr | Etap I | Faktyczny czas - etap I | Etap II | Faktyczny czas - etap II | ||||
1 | 10 | 12 | 20 | 20 | ||||
2 | 10 | 11 | 20 | 19 | |||
3 | 10 | 10 | 10 | 8 | |||
Mamy 3 modyfikacje ustalone w etapie II odpowiednio na 20, 19, 15 dni. Faktyczne czasy dla 3 modyfikacji: 1. etap I 20 dni, etap II 20 dni, 2. etap I 11 dni, etap II 19 dni, 3. etap I 10 dni, etap II 15 dni, WJCR =((12 / 10 + 20 / 20) + (11 / 10 + 19 / 20) + (10 / 10 + 8 / 10)) / (2 + 2 + 2) = 1,01 Zgodnie z tabelą zawartą w Umowie w § nr….. wskaźnik = 0% dla prac nie powoduje możliwości naliczenia kary umownej. Przykład 2 Mamy 3 modyfikacje ustalone w etapie II odpowiednio na 8, 10, 15 dni. Faktyczne czasy dla 3 modyfikacji: 1. etap I 6 dni, etap II 11 dni, 2. etap I 5 dni, etap II 12 dni, 3. etap I 8 dni, etap II 10 dni, WJCR =((10 / 10 + 11 / 10) + (10 / 10 + 12 / 10) + (18 / 10 +10 / 10) / (2 + 2 + 2) = 1,18 Wartość wskaźnika wynosi 18% - może zostać naliczona kara umowna zgodnie z tabelą zawartą w Umowie w § nr ……… | |||||||
Lista i częstotliwość raportów | Okres Rozliczeniowy to jeden kwartał lub raz na 2000 Roboczogodzin w przypadku, gdy prace przekroczyły 2000 Roboczogodzin w kwartale. • Zestawienie informacji o usłudze (raport) musi być wykonywane przez Wykonawcę raz na jeden Okres Rozliczeniowy (kwartalnie). | ||||||
Nr | Etap I | Faktyczny czas - etap I | Etap II | Faktyczny czas - etap II |
1 | 10 | 10 | 10 | 11 |
2 | 10 | 10 | 10 | 12 |
3 | 10 | 18 | 10 | 10 |
• Poziom dotrzymania terminów WJCR tj. wszystkich zakończonych etapów dotyczących wszystkich Zleceń w ramach Rozwoju w Okresie Rozliczeniowym (kwartalnie).