OPIS PRZEDMIOTU ZAMÓWIENIA

Załącznik nr 1 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Strona 1 z 16

Spis treści 1. Wprowadzenie... 3 1.1. Zastosowane skróty i pojęcia... 3 1.2. Przedmiot zamówienia... 7 1.3. Cel zamówienia... 7 2. Etapy realizacji... 8 3. Wymagania... 8 3.1. Wymagania ogólne... 8 3.2. Wymagania funkcjonalne... 9 3.3. Wymagania pozafunkcjonalne... 12 3.4. Wymagania w zakresie dokumentacji... 12 3.5. Wymagania w zakresie odbioru produktów... 14 3.6. Wymagania w zakresie gwarancji... 15 3.7. Harmonogram realizacji przedmiotu zamówienia:... 16 Strona 2 z 16

1. Wprowadzenie Niniejszy dokument stanowi Opis Przedmiotu Zamówienia w zakresie stworzenia i dostarczenia Prototypu aplikacji mobilnej epuap na wybrany system operacyjny wskazany przez Zamawiającego. 1.1. Zastosowane skróty i pojęcia Skrót / pojęcie Błąd kategorii A Opis skrótu / pojęcia Błąd kategorii A dotyczy uniemożliwienia działania przynajmniej jednego z komponentów wytworzonego Prototypu aplikacji mobilnej epuap przez Wykonawcę, powodujący że Zamawiający nie może korzystać z Prototypu aplikacji mobilnej epuap i uzyskanie oczekiwanych efektów nie jest możliwe w inny sposób (obejście). Błąd kategorii B Wystąpił problem polegający na co najmniej jednym z poniższych: główne komponenty Prototypu aplikacji mobilnej epuap wytworzone bądź dostosowane przez Wykonawcę działają w sposób niezgodny z Dokumentacją powykonawczą, występują istotne ograniczenia w działaniu komponentów Prototypu aplikacji mobilnej epuap wytworzonych bądź dostosowanych przez Wykonawcę (ale nie powodujące jej przeciążenia), nastąpiła awaria powodująca ograniczenie wydajności Prototypu aplikacji mobilnej epuap lub jej komponentów wytworzonych bądź dostosowanych przez Wykonawcę, Zamawiający nie może korzystać z komponentów Prototypu aplikacji mobilnej epuap wytworzonych bądź dostosowanych przez Wykonawcę, ale uzyskanie oczekiwanych efektów jest możliwe w inny sposób (obejście). Błąd kategorii B nie obejmuje sytuacji określonych błędem kategorii A. Błąd kategorii C Oznacza pojawienie się usterki komponentów Prototypu aplikacji mobilnej epuap wytworzonych przez Wykonawcę o charakterze ergonomicznym, nie mającej wpływu na wynik pracy Użytkownika. Błąd kategorii C nie obejmuje sytuacji objętych błędem kategorii A i kategorii B. Strona 3 z 16

Skrót / pojęcie Opis skrótu / pojęcia Dokumentacja Wszelka dokumentacja sporządzana i dostarczana przez Wykonawcę w ramach realizacji Umowy. Dokumentacja powykonawcza Dokumentacja projektowa Dni Robocze Dostawa epuap epuap-wkp Etap Instalacja Modyfikacja NFC Dokumentacja zawierająca co najmniej cele i zakres przedmiotu Umowy, charakterystykę minimalnych wymagań sprzętowych i systemowych, opis architektury fizycznej Prototypu aplikacji mobilnej epuap, diagram kontekstowy zaproponowanego rozwiązania i model zachowania, instrukcje użytkownika, instrukcję bezpieczeństwa oraz politykę bezpieczeństwa, wyniki Testów Akceptacyjnych wraz z raportami, sporządzona przez Wykonawcę w zakresie i formie określonej szczegółowo w niniejszym dokumencie. Dokumentacja sporządzona przez Wykonawcę i dostarczoną Zamawiającemu w ramach realizacji Umowy w zakresie i formie określonej szczegółowo w Załączniku nr 2 do Umowy, w tym opis wymagań funkcjonalnych i pozafunkcjonalnych, PTA. Każdy dzień tygodnia od poniedziałku do piątku, za wyjątkiem dni ustawowo wolnych od pracy, w godz. od 8.00 do 16.00 Dostarczenie do siedziby Zamawiającego przez Wykonawcę Prototypu aplikacji mobilnej epuap wraz z odpowiednią Dokumentacją powykonawczą i projektową. elektroniczna Platforma Usług Administracji Publicznej, zbiór produktów projektu epuap-wkp rozwijanych w ramach projektu epuap2. Projekt zrealizowany w latach 2006-2008, którego rezultatem była budowa elektronicznej Platformy Usług Administracji Publicznej, w celu udostępnienia obywatelom usług świadczonych drogą internetową przez jednostki administracji publicznej. Część przedmiotu Umowy podlegającą odbiorowi na podstawie Protokołu Odbioru Etapu. Czynność umieszczenia i skonfigurowania Prototypu aplikacji mobilnej epuap w Urządzeniach mobilnych. Zmiana lub rozbudowa Prototypu aplikacji mobilnej epuap, w tym aktualizacja Dokumentacji projektowej i powykonawczej dokonana na podstawie RfC. Near Field Communication (ang. - komunikacja bliskiego zasięgu) krótkozasięgowy, wysokoczęstotliwościowy, radiowy standard komunikacji pozwalający na bezprzewodową wymianę danych na odległość do 20 centymetrów. Strona 4 z 16

Skrót / pojęcie Oprogramowanie Oprogramowanie Aplikacyjne Oprogramowanie Standardowe Plan Testów Akceptacyjnych (PTA) Prototyp aplikacji mobilnej epuap RfC / Request for Change (pol. Prośba o Zmianę) Słownik Podmiotów Publicznych Umowa Urządzenia mobilne Opis skrótu / pojęcia Oprogramowanie Standardowe oraz wytworzone w ramach realizacji Umowy Oprogramowanie Aplikacyjne. Oprogramowanie i skrypty wraz z kompletnymi kodami źródłowymi wytworzone i dostarczone przez Wykonawcę w ramach realizacji Umowy wraz z Dokumentacją oraz Modyfikacjami i Dokumentacją do Modyfikacji, do których Wykonawca przeniesie autorskie prawa majątkowe na Zamawiającego i MAiC na warunkach i zasadach określonych w Umowie. Zamawiający za Oprogramowanie Aplikacyjne uznaje również oprogramowanie otrzymane przez Wykonawcę na bazie modyfikacji kodów źródłowych Oprogramowania Standardowego. Oprogramowanie powszechnie dostępne (systemowe, bazodanowe, pomocnicze), którego producentem jest Wykonawca lub podmiot trzeci, W przypadku oprogramowania, którego producentem nie jest Wykonawca, Wykonawca zapewnia udzielenie Zamawiającemu licencji przez producenta na zasadach określonych w Umowie oraz dostarcza to oprogramowanie wraz licencją producenta oraz Dokumentacją. W przypadku oprogramowania, którego producentem jest Wykonawca, Wykonawca dostarczając oprogramowanie wraz z Dokumentacją udziela licencji na warunkach i zasadach określonych w Umowie. Przygotowany przez Wykonawcę i zaakceptowany przez Zamawiającego Plan Testów Akceptacyjnych. Aplikacja zaprojektowana i stworzona w celu zademonstrowania wyselekcjonowanych funkcjonalności platformy epuap dla Urządzeń mobilnych. Czynności polegające na wprowadzaniu przez Wykonawcę zmian funkcjonalnych ponad określone w wymaganiach zawartych w Opisie Przedmiotu Zamówienia oraz czynności związane z Modyfikacjami wykonywane przez Wykonawcę w ramach zleceń zgodnie z oczekiwaniami Zamawiającego oraz Użytkowników lub zlecenia wykonania usług konsultacyjnych i asysty technicznej. Słownik podmiotów publicznych oparty na danych z rejestru REGON. Oznacza Umowę wraz z Załącznikami zawartą z Wykonawcą w celu realizacji przedmiotu zamówienia. Urządzenia przenośne takie jak smartfony, tablety działające na systemie operacyjnym Android. Strona 5 z 16

Skrót / pojęcie Użytkownik Opis skrótu / pojęcia Użytkownik korzystający z epuap w wersji standardowej lub poprzez Mobilną platformę epuap. Strona 6 z 16

1.2. Przedmiot zamówienia Przedmiotem zamówienia jest: opracowanie i przygotowanie dokumentacji projektowej i powykonawczej, wykonanie Prototypu aplikacji mobilnej epuap i jego instalacja na Urządzeniach mobilnych posiadanych przez Zamawiającego, przeniesienie majątkowych praw autorskich na wytworzony Prototyp aplikacji mobilnej epuap wraz z jego Modyfikacjami, udzielenie licencji na oprogramowanie standardowe oraz jego aktualizacje, jeżeli zostanie ono dostarczone przez Wykonawcę, zapewnienie Modyfikacji Prototypu aplikacji mobilnej epuap w ramach RfC w wymiarze 50 roboczogodzin, od dnia podpisania protokołu odbioru końcowego do dnia 16.12.2013 r. lub wyczerpania przyjętego limitu roboczogodzin. świadczenie serwisu gwarancyjnego na dostarczony Prototyp aplikacji mobilnej epuap przez okres minimum 12 miesięcy licząc od dnia podpisania protokołu odbioru końcowego. 1.3. Cel zamówienia Celem zamówienia jest zbudowanie prototypowego rozszerzenia kanałów komunikacji umożliwiających załatwianie spraw urzędowych przez obywateli na platformie epuap za pomocą Urządzeń mobilnych. Strona 7 z 16

2. Etapy realizacji Wykonawca musi przeprowadzić prace w następujących etapach: Etap I opracowanie dokumentacji projektowej Prototypu aplikacji mobilnej epuap, opracowanie i przygotowanie Prototypu aplikacji mobilnej epuap na Urządzenia mobilne, instalacja Prototypu aplikacji mobilnej epuap na Urządzeniach mobilnych posiadanych przez Zamawiającego, przeniesienie autorskich praw majątkowych do Oprogramowania aplikacyjnego oraz Dokumentacji projektowej. Termin realizacji: 28 lutego 2013 r. Etap II opracowanie dokumentacji powykonawczej Prototypu aplikacji mobilnej epuap, przeniesienie autorskich praw majątkowych do Dokumentacji powykonawczej. Termin realizacji: 30 marca 2013 r. Wykonawca zobowiązuje się ponadto do zapewnienie Modyfikacji powdrożeniowych Prototypu aplikacji mobilnej epuap w ramach RfC w wymiarze 50 roboczogodzin. Termin realizacji: od dnia podpisania protokołu odbioru Etapu II do dn. 16 grudnia 2013 r. lub do wyczerpania przyjętego limitu roboczogodzin. 3. Wymagania 3.1. Wymagania ogólne Kod Opis wymagania wymagania WO.1 Prototyp aplikacji mobilnej epuap musi dostarczyć funkcjonalności co najmniej w zakresie: 1. Zakładania konta na platformie epuap. 2. Złożenia wniosku o profil zaufany. 3. Zarządzania kontem Użytkownika. 4. Wysłania pisma ogólnego do wybranego podmiotu publicznego za pomocą formularza wykorzystującego Słownik Podmiotów Publicznych z możliwością podpisania dokumentu profilem zaufanym. 5. Wyszukania urzędu w Słowniku Podmiotów Publicznych w oparciu o mapy dostawców map i dane adresowe. 6. Obsługi składu dokumentów. 7. Bazy filmów instruktażowych. Strona 8 z 16

8. Bazy informacji o epuap. WO.2 WO.3 WO.4 WO.5 WO.6 Wykonawca zainstaluje Prototyp aplikacji mobilnej epuap na system operacyjny Android na Urządzeniach mobilnych posiadanych przez Zamawiającego (Samsung Galaxy SIII). Prototyp aplikacji mobilnej epuap musi być wykonany zgodnie z wytycznymi producenta systemu operacyjnego dla Urządzeń mobilnych Android. Wykonawca przygotuje Prototyp aplikacji mobilnej epuap na system operacyjny Android w wersji aktualnej w dniu podpisania protokołu odbioru. Wykonawca przygotuje min. 1 (jedną) propozycję interfejsu. Interfejs graficzny Prototypu aplikacji mobilnej epuap musi być zgodny z obecnie funkcjonującym systemem identyfikacji wizualnej platformy epuap. WO.7 Prototyp aplikacji mobilnej epuap musi realizować min. 1 (jedną) funkcjonalność wykorzystującą technologię NFC zaproponowana przez Wykonawcę. WO.8 WO.9 Prototyp aplikacji mobilnej epuap może być ograniczony do w pełni funkcjonalnego interfejsu użytkownika bez faktycznego połączenia ze standardową wersją platformy epuap w celu ukończenia poszczególnych procesów. Oprócz czynności opisanych w WO.2 Wykonawca przygotuje i dostarczy na nośniku CD wersję instalacyjną Prototypu aplikacji mobilnej epuap umożliwiającą jego instalację na Urządzeniach mobilnych działających na systemie operacyjnym Android przez Zamawiającego we własnym zakresie. 3.2. Wymagania funkcjonalne Kod wymagania Opis wymagania 1. Wymagania w zakresie zakładania konta na platformie epuap WF.1 WF.2 WF.3 Prototyp aplikacji mobilnej epuap musi imitować przejście procesu założenia konta użytkownika na platformie epuap. Prototyp aplikacji mobilnej epuap musi imitować sprawdzenie dostępności loginu na etapie jego wprowadzania. Prototyp aplikacji mobilnej epuap musi imitować uwierzytelnienie podczas logowania Użytkownika do systemu epuap w oparciu o login i hasło. WF.4 Prototyp aplikacji mobilnej epuap musi imitować rejestrację konta Strona 9 z 16

Użytkownika w oparciu o login i hasło. WF.5 Prototyp aplikacji mobilnej epuap musi w procesie rejestracji konta Użytkownika, imitować automatyczne złożenie wniosku o profil zaufany epuap. 2. Złożenie wniosku o profil zaufany. WF.6 Prototyp aplikacji mobilnej epuap musi imitować złożenie wniosku o profil zaufany. 3. Konto Użytkownika. WF.7 WF.8 Prototyp aplikacji mobilnej epuap musi imitować funkcjonalność składu dokumentów Użytkownika aktualnie działającej platformy epuap. Prototyp aplikacji mobilnej epuap musi imitować funkcje umożliwiające edycję ustawień konta Użytkownika w zakresie jego danych, adresu e-mail i zmiany hasła. Ze względu na możliwość posiadania profilu zaufanego przez Użytkownika, Prototyp aplikacji mobilnej epuapmusi informować Użytkownika, że konsekwencją zmiany danych w zakresie imienia, nazwiska i nr PESEL, jest utrata posiadanego profilu zaufanego. 4. Wysłanie pisma ogólnego do wybranego podmiotu publicznego za pomocą formularza wykorzystującego Słownik Podmiotów Publicznych z możliwością podpisania profilem zaufanym. WF.9 WF.10 WF.11 WF.12 WF.13 WF.14 Prototyp aplikacji mobilnej epuap musi imitować wysłanie pisma ogólnego do wybranego podmiotu publicznego ze Słownika Podmiotów Publicznych. Prototyp aplikacji mobilnej epuap musi imitować wybór podmiotu na podstawie podziału terytorialnego w postaci kilkustopniowego menu rozwijanego: województwo > powiat > gmina. Zawartość wykorzystywanej klasyfikacji terytorialnej musi być zgodna z rejestrem TERYT. Wykonawca przygotuje formularz pisma ogólnego dla Prototypu aplikacji mobilnej epuap Formularz musi pobierać dane Użytkownika (imię i nazwisko, adres) już wprowadzone przez Użytkownika do Prototypu aplikacji mobilnej epuap podczas rejestracji konta Użytkownika. Formularz musi wykorzystywać dane wprowadzone do Prototypu aplikacji mobilnej epuap przez podmioty publiczne (Słownik Podmiotów Publicznych, lub jego fragment dostarczony przez Zamawiającego do osadzenia w Prototypie aplikacji mobilnej epuap). Strona 10 z 16

WF.15 WF.16 WF.17 Prototyp aplikacji mobilnej epuap musi imitować podpisanie formularza profilem zaufanym Użytkownika. Prototyp aplikacji mobilnej epuap musi imitować dodanie załącznika z zasobów Urządzenia mobilnego. Prototyp aplikacji mobilnej epuap musi imitować wysyłkę formularza bez konieczności składania podpisu elektronicznego. WF.18 Silnik formularza musi udostępniać flagę poprawności wypełnienia formularza w oparciu o zastosowane mechanizmy walidacyjne oraz uniemożliwiać przejście do dalszego etapu obsługi formularza, w przypadku gdy wszystkie pola nie zostały poprawnie walidowane zgodnie z zastosowanymi regułami (z wyłączeniem zapisów wymagania WF.18). WF.19 Silnik formularza musi umożliwiać wybór adresata dokumentu w oparciu o Słownik Podmiotów Publicznych dostarczony przez Zamawiającego do osadzenia w Prototypie aplikacji mobilnej epuap. 5. Wykonanie zdjęcia dokumentu z możliwością wysyłki jako załącznik do pisma ogólnego. WF.20 WF.21 WF.22 Prototyp aplikacji mobilnej epuap musi umożliwiać wykonanie zdjęcia dokumentu i jego zapis w formacie JPG oraz udostępniać funkcjonalność wykrywania krawędzi dokumentu, zmianę koloru (zdjęcie kolorowe/czarnobiałe) i obrotu w pionie i poziomie. Prototyp aplikacji mobilnej epuap musi imitować wysyłkę zdjęcia jako załącznik do pisma ogólnego do wybranego urzędu w oparciu o Słownik Podmiotów Publicznych podmiotu publicznego dostarczony przez Zamawiającego do osadzenia w Prototypie aplikacji mobilnej epuap. Prototyp aplikacji mobilnej epuap musi automatycznie skalować dołączone zdjęcia do ograniczenia wielkości załączników epuap (3.5MB) oraz do wielkości całej wiadomości wraz z załącznikami (5MB). 6. Wyszukanie urzędu w Słowniku Podmiotów Publicznych. WF.23 WF.24 WF.25 Prototyp aplikacji mobilnej epuap musi umożliwiać wyszukanie urzędu realizującego wybraną usługę na podstawie Słownika Podmiotów Publicznych dostarczony przez Zamawiającego do osadzenia w Prototypie aplikacji mobilnej epuap oraz dedykowanego słownika dla usługi potwierdzania profilu zaufanego lista punktów potwierdzeń profilu zaufanego). Prototyp aplikacji mobilnej epuap musi prezentować wyniki w postaci listy z podstawowymi danymi: nazwa urzędu, dane teleadresowe. Prototyp aplikacji mobilnej epuap musi prezentować wyniki na mapie, w Strona 11 z 16

szczególności w postaci wskazania drogi od miejsca, w którym znajduje się Użytkownik do najbliższego/szych urzędów na podstawie Słownika Podmiotów Publicznych dostarczony przez Zamawiającego do osadzenia w Prototypie aplikacji mobilnej epuap. 7. Baza filmów instruktażowych. WF.26 WF.27 Prototyp aplikacji mobilnej epuap musi umożliwiać wybór i odtworzenie we wbudowanym odtwarzaczu filmów instruktażowych znajdujących się w zasobach urządzenia. Wykonawca musi dostosować dostarczone przez Zamawiającego pliki do wymagań aplikacji mobilnej pod kątem rozdzielczości i wielkości. 8. Baza informacji dot. epuap. WF.28 WF.29 Prototyp aplikacji mobilnej epuap musi umożliwiać dostęp do dokumentów i treści dotyczących epuap znajdujących się w zasobach urządzenia. Wykonawca musi dostosować dostarczone przez Zamawiającego dokumenty do wymagań prototypu aplikacji mobilnej epuap w zakresie wielkości plików i formatowania treści. 3.3. Wymagania pozafunkcjonalne Kod wymagania Opis wymagania Wymagania w zakresie interfejsu graficznego WPF.1 Ilość i wielkość informacji wyświetlanych za pomocą aplikacji musi być dostosowana do rodzaju Urządzenia mobilnego. 3.4. Wymagania w zakresie dokumentacji Kod wymagania Opis wymagania DOC.1 Zamawiający wymaga, aby Wykonawca przygotował, zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania, następujące rodzaje dokumentacji bezpośrednio związanej z przedmiotem zamówienia: DOC.2 Dokumentacja projektowa zawierająca, co najmniej następujące informacje: 1. Specyfikację wymagań funkcjonalnych, 2. Specyfikację wymagań pozafunkcjonalnych, Strona 12 z 16

3. Ograniczenia rozwiązania, założenia i zależności, 4. Opis wymagań sprzętowych i programowych, 5. Instrukcję instalacji Prototypu aplikacji epuap na Urządzeniach mobilnych posiadanych Zamawiającego. DOC.3 Dokumentację powykonawczą, zawierającą co najmniej następujące informacje: 1. Diagram kontekstowy wdrożonego rozwiązania i model zachowania, 2. Specyfikację wymagań funkcjonalnych, 3. Specyfikację wymagań pozafunkcjonalnych, 4. Ograniczenia rozwiązania, założenia i zależności, 5. Instrukcje użytkownika, w tym, 6. Wyniki testów akceptacyjnych wraz z raportami, 7. Wersje instalacyjne, 8. Kody źródłowe. DOC.4 Dokumentacja zostanie przygotowana w oparciu o dostarczone przez Zamawiającego szablony dokumentów i będzie oznakowana zgodnie z wytycznymi, dotyczącymi oznaczania projektów w ramach Programu Operacyjnego Innowacyjna Gospodarka, tj. będą zawierać m.in. logo Programu Operacyjnego Innowacyjna Gospodarka, logo Unii Europejskiej z podpisem: Unia Europejska Europejski Fundusz Rozwoju Regionalnego. Oznakowanie materiałów powinno zawierać również logo epuap2. Logotypy zostaną przekazane przez Zamawiającego. Dokumenty wytworzone w ramach umowy nie będą oznaczone logiem Wykonawcy. DOC.5 Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się wysoką jakością, na którą będą miały wpływ, takie czynniki jak: 1. Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób. 2. Zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu. 3. Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia. Strona 13 z 16

4. Spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu. DOC.6 Zamawiający wymaga, aby cała dokumentacja, o której mowa powyżej, podlegała jego akceptacji, a także, aby została dostarczona w języku polskim, w wersji elektronicznej w niezabezpieczonym/edytowalnym formacie Word, PDF (na płycie CD-ROM lub innym równoważnym nośniku danych) i drukowanej, co najmniej w 3 egzemplarzach (dopuszcza się inne formaty zapisu dokumentacji np. diagramy UML lub formaty wektorowe jak DWG, DXF, należy jednak dołączyć przeglądarkę obsługującą wykorzystane formaty). Diagramy UML sporządzone za pomocą narzędzi CASE powinny być dostarczone w formacie EAP. Dostarczone wykresy Gantta powinny być dostarczone w formacie MPP lub w formacie XLS umożliwiającym import do MS Project. DOC.7 Do Dokumentacji zostaną przeniesione majątkowe prawa autorskie na polach eksploatacji określonych w umowie. 3.5. Wymagania w zakresie odbioru produktów Kod wymagania OD.01 OD.03 Opis wymagania Wszystkie dostarczone w ramach Umowy produkty i świadczone usługi będą podlegały procedurom w zakresie testów akceptacyjnych, odbioru ilościowego i jakościowego. Do protokołu odbioru końcowego dołączone będą: OD.05 OD.05.01 wykaz oprogramowania, dokumentacja projektowa i powykonawcza wraz z niezbędnymi instrukcjami, zgodnie z wymaganiami Zamawiającego, wyniki przeprowadzonych testów, protokoły odbioru poszczególnych etapów. O gotowości do przekazania przedmiotu zamówienia do odbioru Wykonawca powiadomi Zamawiającego (Kierownika Umowy) na co najmniej 3 dni robocze przed jego przekazaniem, przesyłając informację pisemnie, faksem lub pocztą e-mail. Zamawiający przeprowadzi procedurę odbiorczą i zgłosi ewentualne uwagi lub zastrzeżenia najpóźniej w terminie do 5 dni roboczych od dnia zgłoszenia przez Wykonawcę gotowości do przekazania przedmiotu zamówienia. Strona 14 z 16

OD.05.02 Wykonawca uwzględni wszystkie uwagi Zamawiającego do przedmiotu zamówienia najpóźniej w terminie do 3 dni roboczych. OD.05.03 Wszystkie czynności związane z dokonaniem odbioru muszą zakończyć się w terminie wykonania poszczególnych etapów i Umowy. OD.06 Zamawiający wymaga, aby Wykonawca przygotował Plan Testów Akceptacyjnych, podlegający zaakceptowaniu przez Zamawiającego zgodnie z szablonem PTA, stanowiącym załącznik do Umowy. OD.07 OD.08 Zamawiający zastrzega sobie prawo do rezygnacji z części zapisów zawartych w PTA, dotyczących rodzaju testów Plan Testów Akceptacyjnych musi zostać przygotowany z uwzględnieniem: opisu sposobu organizacji testów, opisu przypadków testowych oraz kryteriów akceptacji, scenariuszy testowych uwzględniających przebieg podstawowy dla usługi i przebiegi alternatywne. Przed przeprowadzeniem testów akceptacyjnych Wykonawca przeprowadzi testy wewnętrzne i przekaże Zamawiającemu raport z testów wewnętrznych zawierający także opis metody przeprowadzenia testów wewnętrznych. OD.09 OD.10 Zamawiający zastrzega sobie prawo do udziału w prowadzonych przez Wykonawcę testach wewnętrznych. Zamawiający przeprowadzi na podstawie dostarczonych przez Wykonawcę narzędzi testy akceptacyjne. Warunki ogólne niezbędne do przeprowadzenia testów akceptacyjnych każdego typu, to m.in.: 1. Warunki rozpoczęcia pierwszej iteracji testów zaakceptowana dokumentacja testowa, zaakceptowany harmonogram testów, przeprowadzone testy wewnętrzne Wykonawcy i przekazany Zamawiającemu raport z testów wewnętrznych. 2. Warunki rozpoczęcia kolejnych iteracji testów naprawione błędy wykryte podczas poprzedniej iteracji, modyfikacja dokumentacji testowej w zakresie wynikającym z poprzedniej iteracji testów. 3.6. Wymagania w zakresie gwarancji Wykonawca musi zapewnić minimum 12 miesięczną gwarancję na oprogramowanie aplikacyjne i oprogramowanie standardowe. Strona 15 z 16

Na dostarczone oprogramowane aplikacyjne Wykonawca musi zapewnić minimum 12 miesięczną gwarancję liczoną od podpisania protokołu odbioru końcowego. W ramach gwarancji Wykonawca musi zapewnić co najmniej: Wsparcie techniczne polegające na stałym kontakcie (w formie wskazanej przez Zamawiającego, w szczególności: przez e-mail, telefonicznie, bezpośrednio w siedzibie Zamawiającego) w celu udzielania konsultacji administratorom wskazanych przez Zamawiającego, w dni robocze w godz. 8-16. przyjmowanie zgłoszeń gwarancyjnych w dni robocze w godz. 8-16; zgłoszenia mogą być dokonywane: faksem, telefonicznie, e-mailem. czasy obsługi zgłoszeń gwarancyjnych: o dla błędów kategorii A 1 dzień kalendarzowy, o dla błędów kategorii B 4 dni kalendarzowe, o dla błędów kategorii C 14 dni kalendarzowych. Na dostarczone oprogramowane standardowe Wykonawca musi zapewnić minimum 12 miesięczną gwarancję liczoną od podpisania protokołu odbioru końcowego w ramach gwarancji Wykonawca musi zapewnić co najmniej: aktualizacje oprogramowania standardowego, w tym wyższe wersje (update/upgrade), patche i programy korekcji błędów oprogramowania standardowego i udzielenie licencji na w/w aktualizacje na warunkach określonych w OPZ i Umowie; doprowadzanie do spełnienia deklarowanych przez producenta parametrów i/lub funkcji użytkowych oprogramowania standardowego; usuwanie usterek i błędów funkcjonalnych w działaniu oprogramowania standardowego; usuwanie błędów oprogramowania standardowego zgodnie z zasadami gwarancyjnymi określonymi przez producenta oprogramowania w szczególności określającymi sposób przekazywania Zamawiającemu oprogramowania aktualizacyjnego usuwającego dotychczas wykryte błędy w funkcjonowaniu Oprogramowania. 3.7. Harmonogram realizacji przedmiotu zamówienia: Strona 16 z 16