OGÓLNY OPIS POTRZEB I WYMAGAŃ

Transkrypt

1 OGÓLNY OPIS POTRZEB I WYMAGAŃ Strona 1 z 34

2 Spis treści 1. Wprowadzenie Zastosowane skróty i pojęcia Cel zamówienia Przedmiot zamówienia Etapy realizacji Wymagania Wymagania w zakresie planu budowy systemu Wymagania funkcjonalne Wymagania pozafunkcjonalne Ergonomia systemu Dzienniki zdarzeń Wydajność systemu Dostępność Wymagania prawne Wymagania w zakresie specyfikacji oprogramowania standardowego Ograniczenia i zależności Wymagania w zakresie dokumentacji Wymagania w zakresie odbioru produktów Wymagania w zakresie zarządzania projektem Wymagania w zakresie gwarancji Strona 2 z 34

3 1. Wprowadzenie Niniejszy dokument stanowi OGÓLNY OPIS POTRZEB I WYMAGAŃ (OOPiW) w zakresie wytworzenia oraz wdrożenia Systemu dziedzinowego dla Portalu zbiórek publicznych Zastosowane skróty i pojęcia Skrót / pojęcie Opis skrótu / pojęcia Aktor Użytkownik lub zewnętrzny system, z którymi System dziedzinowy wchodzi w interakcje: Obywatel, Organizator zbiórki, Urzędnik MAC, Komponent epuap. Błąd kategorii A Wystąpił problem uniemożliwiający użytkowanie Systemu dziedzinowego. Błąd kategorii B Wystąpił problem co najmniej jeden z poniższych problemów: System dziedzinowy działa w sposób niezgodny z dokumentacją, występują istotne ograniczenia w działaniu Systemu dziedzinowego, nastąpiła awaria powodująca ograniczenie wydajności Systemu dziedzinowego, nie można korzystać z Systemu dziedzinowego, ale uzyskanie oczekiwanych efektów jest możliwe w inny sposób (obejście). Błąd kategorii B nie obejmuje sytuacji określonych jako Błąd kategorii A. Błąd kategorii C Oznacza pojawienie się usterki Systemu dziedzinowego 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. BPMN (ang. Business Process Modeling Notation) graficzna notacja służąca do modelowania procesów biznesowych. Strona 3 z 34

4 Skrót / pojęcie Opis skrótu / pojęcia CRD Centralne Repozytorium Wzorów Dokumentów (CRD) 1 Miejsce zapewniające jednolite i bezpieczne źródło informacji o dokumentach elektronicznych administracji publicznej. Dostęp do Centralnego Repozytorium Wzorów Dokumentów (zwanego także CRD) jest bezpłatny i umożliwia pobranie dowolnego, opublikowanego tam wzoru dokumentu elektronicznego. Edytor WYSIWYG Program pozwalający na tworzenie i edycję treści publikowanych na stronie WWW Systemu dziedzinowego przez Urzędnika MAC. Treść formatowana w edytorze jest wizualnie tożsama z treścią wyświetlaną Obywatelowi na stronie WWW. epuap Elektroniczna Platforma Usług Administracji Publicznej system informatycznych dostępny pod adresem zbiór produktów projektu epuap-wkp rozwijanych w ramach projektu epuap2. GUI Graficzny interfejs użytkownika Systemu dziedzinowego Komponent epuap Część Portalu zbiórek publicznych, która nie jest tworzona w ramach niniejszego zamówienia. Na Komponent epuap składają się w szczególności interaktywne formularze na platformie epuap wraz oprogramowaniem sterującym przepływem danych na platformie epuap i wysyłaniem danych poza platformę. Lista Jeden z trzech zbiorów danych w Systemie dziedzinowym: Lista zbiórek, Lista wnioskodawców i Lista wykluczeń. MAC Ministerstwo Administracji i Cyfryzacji Model Uproszczony obraz rzeczywistości. Prezentowany z pewnej perspektywy, na pewnym poziomie abstrakcji. PZP Plan Zarządzania Projektem Dokumentacja projektowa W skład dokumentacji projektowej wchodzą: projekt techniczny opisany wymaganiem WPBS.01 oraz dokumentacja wynikającą z wymagania WPBS URI: gyg93qwmlrydxa89go2cxyennim9yvydbureanmdpzw!!/ Strona 4 z 34

5 Skrót / pojęcie Portal zbiórek publicznych System dziedzinowy Środowisko produkcyjne KUP ESP Repozytorium plików RfC / Request for Change (pol. Prośba o Zmianę) Modyfikacja Zbiórka publiczna Opis skrótu / pojęcia System informatyczny wspierający cykl życia zbiórki publicznej. System ten pozwala na zgłaszanie informacji o zbiórkach publicznych, a także na prezentacje informacji o realizowanych i przeprowadzonych zbiórkach. Na Portal zbiórek publicznych składają się: System dziedzinowy i Komponent epuap. Wytworzone przez Wykonawcę w ramach niniejszego zamówienia oprogramowanie spełniające wymagania z OOPiW. Środowisko systemu epuap dostarczone przez Zamawiającego działające w czasie rzeczywistym, obsługujące rzeczywistych użytkowników i rzeczywiste dane w określonym reżimie SLA. Katalog Usług Publicznych Systemu epuap. Elektroniczna Skrzynka Podawcza Magazyn Systemu dziedzinowego służący do uporządkowanego przechowywania dokumentów XML, plików binarnych i plików poczty elektronicznej. 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 końcowych lub zlecenia wykonania usług konsultacyjnych. Zmiana lub rozbudowa Oprogramowania lub wprowadzanie zmian w konfiguracji Infrastruktury sprzętowej lub Dotychczasowej infrastrukturze, w tym aktualizacja Dokumentacji projektowej i powykonawczej w wyniku Zlecenia Modyfikacji, dokonana na podstawie Zlecenia. Zbiórką publiczną jest wszelkie zbieranie ofiar w gotówce lub w naturze, w miejscu publicznym, na określony, zgodny z prawem cel, pozostający w sferze zadań publicznych, o których mowa w art. 4 ust. 1 ustawy z dnia 24 kwietnia 2003 r. o działalności pożytku publicznego i o wolontariacie (Dz.U. z 2010 r. Nr 234, poz. 1536, z późn. zm. )) oraz na cele religijne. (definicja za art. 1 ust. 1 projektu z 25 lipca 2013 r. ustawy o zasadach prowadzenia zbiórek publicznych). Strona 5 z 34

6 Skrót / pojęcie Opis skrótu / pojęcia Oprogramowanie standardowe Urzędowe Poświadczenie Odbioru, UPO Dane elektroniczne dołączone do dokumentu elektronicznego doręczonego podmiotowi publicznemu lub połączone z tym dokumentem w taki sposób, że jakakolwiek późniejsza zmiana dokonana w tym dokumencie jest rozpoznawalna, określające: a. pełną nazwę podmiotu publicznego, któremu doręczono dokument elektroniczny, b. datę i godzinę doręczenia dokumentu elektronicznego rozumiane jako data i czas wprowadzenia albo przeniesienia dokumentu elektronicznego do systemu teleinformatycznego podmiotu publicznego, c. datę i godzinę wytworzenia Urzędowego Poświadczenia Odbioru. Urzędowe Poświadczenie Odbioru (UPO) jest określone w Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 27 listopada 2006 r. w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych (Dz.U nr 227 poz. 1664). UPO jest wspólnym określeniem dla Urzędowego Poświadczenia Przedłożenia (UPP) i Urzędowego Poświadczenia Doręczenia (UPD). Lokalizacja plików aktualnie obowiązującego wzoru UPO: Plik schematu: d Plik wizualizacji: Plik wyróżnika: Strona 6 z 34

7 Skrót / pojęcie UPP - Urzędowe Poświadczenie Przedłożenia UPD - Urzędowe Poświadczenie Doręczenia PND - Poświadczenie Niedoręczenia Dokumentu Wzór dokumentu XML Opis skrótu / pojęcia Zgodnie z rozporządzeniem Prezesa Rady Ministrów w sprawie warunków organizacyjno-technicznych doręczania dokumentów elektronicznych podmiotom publicznym (Dz. U. z 2005 Nr 200, poz. 1651) i rozporządzeniem Ministra Spraw Wewnętrznych i Administracji w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych (Dz. U. z 2006 Nr 227, poz. 1664) urzędowe poświadczenie odbioru (UPO) jest dowodem na doręczenie pisma. Z uwagi na stronę wystawiającą takie poświadczenie, zostały wprowadzone (w epuap) dwa rodzaje poświadczeń: 1. UPP - gdy urząd (organ administracji) potwierdza odbiór pisma 2. UPD - gdy klient potwierdza odbiór pisma Oba te rodzaje potwierdzeń opierają się na tym samym wzorze UPO. Podział ten wprowadza (w epuap) jedynie łatwiejsze i jednoznaczne określenie potwierdzenia (w zależności od strony potwierdzającej) ale nadal są to zgodne z prawem urzędowe potwierdzenia odbioru (UPO). Z tego samego powodu (łatwiejsze i jednoznaczne określenie potwierdzenia) dodatkowo wprowadzono (w epuap) pojęcie PND. Definicja struktury dokumentu obejmująca określenie jego schematu (struktury), jego znaczenie oraz formy wizualizacji. Wzór dokumentu jest wystarczający dla jego prezentacji wizualnej oraz określenia znaczenia Cel zamówienia Celem zamówienia jest informatyczne wsparcie następujących zadań dotyczących zbiórek publicznych: 1. Przekazywanie zgłoszeń zbiórek publicznych. 2. Przekazywanie sprawozdań po zakończeniu zbiórek. 3. Przekazywanie sprawozdań z rozdysponowania zebranych ofiar. 4. Prezentacja ogólnych informacji o zbiórkach (w tym: podstawy prawne, aktorzy, procedury, dane kontaktowe, aktualności). 5. Prezentacja informacji o realizowanych zbiórkach (prowadzone, zakończone), a także o osobach i podmiotach prowadzących zbiórki oraz o wynikach zbiórek (po zakończeniu, po rozdysponowaniu ofiar). Strona 7 z 34

8 6. Przechowywanie informacji o osobach i podmiotach, które nie dopełniły w terminie obowiązku sprawozdawczego. Zadanie zostanie osiągnięte poprzez wytworzenie oraz wdrożenie Systemu dziedzinowego dla Portalu zbiórek publicznych. Portal zbiórek publicznych to system informatyczny wspierający cykl życia zbiórki publicznej. System ten pozwala na zgłaszanie informacji o zbiórkach publicznych, a także na prezentacje informacji o realizowanych i przeprowadzonych zbiórkach. Wśród aktorów Portalu zbiórek publicznych znajdują się: Organizator zbiórki, który zgłasza planowaną do przeprowadzenia zbiórkę, a następnie dostarcza sprawozdanie po zakończeniu zbiórki oraz sprawozdanie z rozdysponowania ofiar; Urzędnik MAC, który rozpatruje (pozytywnie lub negatywnie) zgłoszenie planowanej do przeprowadzenia zbiórki, ocenia poprawność dostarczanych sprawozdań, a także ma możliwość zapoznawania się z pełnymi danymi wszystkich zbiórek i ich modyfikacji; Obywatel, który ma możliwość zapoznawania się z wybranymi, powszechnie dostępnymi danymi zbiórek. Na Portal zbiórek publicznych składają się: Komponent epuap oraz System dziedzinowy. Pomiędzy Komponentem epuap a Systemem dziedzinowym są przekazywane dane w postaci plików XML. Przedmiotem niniejszego zamówienia jest wytworzenie wyłączne Systemu dziedzinowego. Komponent epuap będzie wytwarzany równolegle w ramach niezależnego projektu Przedmiot zamówienia Przedmiotem zamówienia jest wytworzenie oraz wdrożenie Systemu dziedzinowego dla Portalu zbiórek publicznych w szczególności poprzez: opracowanie i dostarczenie dokumentacji projektowej; wytworzenie oprogramowania aplikacyjnego Systemu dziedzinowego wraz z jego instalacją, konfiguracją i wdrożeniem w środowisku wraz z testami wewnętrznymi Strona 8 z 34

9 Wykonawcy oraz uzupełnieniem dokumentacji projektowej i dostarczeniem jej przez Wykonawcę; przeniesienie autorskich praw majątkowych do wytworzonego w ramach zamówienia oprogramowania aplikacyjnego Systemu dziedzinowego; dostarczenie oprogramowania standardowego wraz z jego instalacją i konfiguracją w środowisku wraz z testami wewnętrznymi Wykonawcy oraz uzupełnieniem dokumentacji projektowej i dostarczeniem jej przez Wykonawcę; udzielenie licencji na dostarczone w ramach zamówienia oprogramowanie standardowe; zapewnienie modyfikacji wytworzonego oprogramowania aplikacyjnego Systemu dziedzinowego w ramach RfC, w wymiarze 2000 roboczogodzin, możliwych do wykorzystania od dnia podpisania Umowy do wyczerpania przyjętego limitu roboczogodzin jednakże nie później niż do dnia roku; udzielenie gwarancji na wytworzone oprogramowanie aplikacyjne Systemu dziedzinowego oraz oprogramowanie standardowe, a także świadczenie serwisu gwarancyjnego na dostarczone oprogramowane aplikacyjne oraz oprogramowanie standardowe przez okres minimum 24 miesięcy licząc od dnia podpisania protokołu odbioru końcowego. Strona 9 z 34

10 2. Etapy realizacji Termin realizacji Umowy nie później niż do dnia roku. Warunki realizacji przedmiotu zamówienia przez Wykonawcę są określone w niniejszym Opisie Przedmiotu Zamówienia Etap I obejmuje: opracowanie i dostarczenie dokumentacji projektowej w terminie do dni kalendarzowych od daty podpisania Umowy; Etap II obejmuje: dostawę i udzielenie licencji na dostarczane w ramach zamówienia oprogramowanie standardowe; wytworzenie oprogramowania aplikacyjnego Systemu dziedzinowego wraz z instalacją, konfiguracją i wdrożeniem w, wraz z testami wewnętrznymi Wykonawcy oraz uzupełnieniem dokumentacji projektowej i dostarczeniem jej przez Wykonawcę; przeniesienie autorskich praw majątkowych do wytworzonego w ramach zamówienia oprogramowania aplikacyjnego; instalację, konfigurację i wdrożenie rozbudowanego oprogramowania aplikacyjnego w wraz z testami wewnętrznymi Wykonawcy oraz uzupełnieniem dokumentacji projektowej i dostarczeniem jej przez Wykonawcę; w terminie do dni kalendarzowych od podpisania Umowy. Etap III obejmuje: instalację, konfigurację i wdrożenie oprogramowania aplikacyjnego Systemu dziedzinowego w wraz z testami wewnętrznymi Wykonawcy, wykonanie testów akceptacyjnych oraz opracowanie i dostarczenie dokumentacji powykonawczej; w terminie do dni kalendarzowych od podpisania Umowy. 3. Wymagania 3.1. Wymagania w zakresie planu budowy systemu Wymaganie WPBS.01 Wykonawca opracuje i dostarczy projekt techniczny wytworzenia oprogramowania aplikacyjnego Systemu dziedzinowego zgodnie z Strona 10 z 34

11 wymaganiami zawartymi w niniejszym dokumencie Wymagania funkcjonalne Kod Budowa systemu zgodnie z modelami procesów biznesowych WF.1 Oprogramowanie realizuje biznesowy model analityczny zamieszczony w basenie System dziedzinowy następujących modeli procesów: 1. Zgłoszenie informacji o zbiórce; 1.1. Wypełnienie wniosku albo sprawozdania; 2. Sprawozdanie po zakończeniu zbiórki albo z rozdysponowania ofiar; 3. Prezentacja i edycja informacji o zbiórkach; 3.1. Przeglądanie informacji o zbiórkach. Modele procesów stanowią Załącznik nr 1 do OOPiW. Komunikacja pomiędzy systemami, tworzenie i zapisywanie plików oraz danych WF.2 System dziedzinowy komunikuje się z Komponentem epuap poprzez webservice w celu przekazywania plików XML: z Komponentu epuap do Systemu dziedzinowego, z Systemu dziedzinowego do Komponentu epuap. WF.2.1 WF.2.2 Komunikacja pomiędzy Systemem dziedzinowym a Komponentem epuap jest zgodna z webservice opisanym pod adresem System dziedzinowy otrzymuje pliki XML (z załącznikami binarnymi i bez załączników binarnych) z Komponentu epuap. Pliki XML są tworzone w Komponencie epuap na podstawie wzorów dokumentów z CRD oraz: 1. treści z formularzy wypełnionych przez Organizatora zbiórki albo przez Urzędnika MAC albo 2. informacji systemowych stanowiących zawartość UPO. Strona 11 z 34

12 Kod W Komponencie epuap dokumenty są tworzone na podstawie wzorów dokumentów CRD i następujących formularzy: 1. Zgłoszenie albo aktualizacja danych zbiórki publicznej; 2. Sprawozdanie albo korekta sprawozdania z przeprowadzonej zbiórki publicznej; 3. Sprawozdanie albo korekta sprawozdania z rozdysponowania zebranych ofiar. 4. Akt założycielski Komitetu społecznego. 5. Decyzja negatywna Urzędnika MAC. 6. Odwołanie Organizatora zbiórki od decyzji negatywnej Urzędnika MAC. 7. Wezwanie do uzupełnienia dokumentów. 8. Akceptacja zbiórki przez Urzędnika MAC. Opis formularzy stanowi Załącznik nr 2 do OOPiW. Wzór dokumentu dla UPO znajduje się w Centralnym Repozytorium Wzorów Dokumentów pod adresem: WF.2.3 System dziedzinowy wysyła pliki XML (bez załączników binarnych) do Komponentu epuap. Pliki XML są tworzone w Systemie dziedzinowym bez udziału człowieka na podstawie zawartości: Listy zbiórek; Listy wnioskodawców; Listy wykluczeń; Stoperów. System dziedzinowy wysyła pliki XML do Komponentu epuap w ramach aktywności lub zdarzeń czasowych (stoperów) wskazanych w modelu procesów. Wykonawca w uzgodnieniu z Zamawiającym przedstawi strukturę, zawartość i wizualizację plików XML wysyłanych przez System dziedzinowy. Strona 12 z 34

13 Kod WF.3 System dziedzinowy wysyła pocztę elektroniczną do Organizatora zbiórki zgodnie z modelem procesów. Wykonawca w uzgodnieniu z Zamawiającym przedstawi strukturę, zawartość i wizualizację poczty elektronicznej wysyłanej przez System dziedzinowy. WF.4 WF.5 Wszystkie pliki XML (z załącznikami binarnymi i bez załączników binarnych) oraz pliki poczty elektronicznej, w których mowa w wymaganiach WF.2 i WF.3, są przechowywane w Repozytorium plików Systemu dziedzinowego. Oprogramowanie przechowuje wybrane dane pobrane z plików, o których mowa w wymaganiu WF.4, w Liście zbiórek, Liście wnioskodawców i Liście wykluczeń. Zawartość Listy zbiórek, Listy wnioskodawców i Listy wykluczeń stanowi Załącznik nr 3 do OOPiW. WF.6 WF.7 Pozycje Listy zbiórek, Listy wnioskodawców i Listy wykluczeń posiadają dowiązania do dokumentów z Repozytorium plików. Pozycje Listy zbiórek, Listy wnioskodawców i Listy wykluczeń są ze sobą powiązane. Bazowe powiązania pomiędzy Listami zawiera Załącznik nr 4 do OOPiW. Urzędnik MAC: Zarządzanie danymi z List oraz plikami WF.8 WF.8.1 System dziedzinowy pozwala Urzędnikowi MAC na zarządzanie danymi z Listy zbiórek, Listy wnioskodawców i Listy wykluczeń oraz plikami z Repozytorium plików poprzez własny Graficzny interfejs użytkownika (GUI) strony WWW. Zarządzanie danymi oraz plikami w Systemie dziedzinowym jest możliwe jedynie dla Urzędników MAC. Urzędnik MAC to osoba posiadająca aktywne konto na platformie epuap, dodana do organizacji Ministerstwo Administracji i Cyfryzacji, z nadaną rolą w systemie uprawnień epuap o nazwie Zarządzający zbiórkami publicznymi. WF.8.2 Dostęp do Systemu dziedzinowego jest możliwy dla Urzędników MAC po Strona 13 z 34

14 Kod uwierzytelnieniu i autoryzacji na epuap. System dziedzinowy wykorzystuje do uwierzytelniania i autoryzacji Urzędników MAC wyłącznie mechanizmy epuap. Urzędnik MAC: Prezentacja i edycja danych z list WF.8.3 System dziedzinowy prezentuje Urzędnikowi MAC dane z Listy zbiórek, Listy wnioskodawców i Listy wykluczeń. WF System dziedzinowy umożliwia przeglądanie, sortowanie oraz stronicowanie danych. WF System dziedzinowy umożliwia wyszukiwanie danych z możliwością wyboru opcji wyszukiwania według dowolnej pozycji z Listy. WF System dziedzinowy umożliwia wyszukiwanie z funkcją autouzupełniania po wprowadzeniu trzech znaków do pola zapytania. WF System dziedzinowy umożliwia Urzędnikowi MAC odczyt, zmianę i usuwanie danych w Liście zbiórek, Liście wnioskodawców i Liście wykluczeń. WF System dziedzinowy zapewnia wersjonowanie danych w Liście zbiórek, Liście wnioskodawców i Liście wykluczeń. Żadne dane i dokumenty nie są usuwane z systemu. WF System dziedzinowy umożliwia Urzędnikowi MAC pobranie danych z Listy zbiórek, Listy wnioskodawców i Listy wykluczeń w formacie XML i CSV. Wykonawca w uzgodnieniu z Zamawiającym zaprojektuje mechanizm pobierania danych z List. Urzędnik MAC: Prezentacja plików z Repozytorium plików WF.8.4 System dziedzinowy prezentuje Urzędnikowi MAC pliki XML, pliki binarne i pliki poczty elektronicznej z Repozytorium plików. WF System dziedzinowy umożliwia przeglądanie, sortowanie oraz stronicowanie informacji o plikach. WF System dziedzinowy umożliwia wyszukiwanie informacji o plikach z funkcją autouzupełniania po wprowadzeniu trzech znaków w pole zapytania. WF Pliki XML są wizualizowane na podstawie: Strona 14 z 34

15 Kod wzoru dokumentu z Centralnego Repozytorium Wzorów Dokumentów Elektronicznych (CRD), danych ze słownika TERYT z Komponentu epuap. WF Pliki binarne są udostępniane do pobrania z wyjątkiem tych, które mogą być zaprezentowane w GUI (np. pliki graficzne w formatach JPG, PNG itp.). WF Pliki poczty elektronicznej są prezentowane w GUI w formacie HTML. WF System dziedzinowy umożliwia Urzędnikowi MAC pobranie kompletu plików XML, plików binarnych i plików poczty elektronicznej dołączonych do wybranej pozycji z Listy zbiórek, Listy wnioskodawców lub Listy wykluczeń jako archiwum ZIP. Log systemowy WF.9 WF.9.1 Wszystkie działania Systemu dziedzinowego na danych w tym wszystkie działania Urzędnika MAC są składowane w logu systemowym Systemu dziedzinowego. Log systemowy zawiera w szczególności: datę działania na danych, zakres działania na danych, oznaczenie (w przypadku Systemu dziedzinowego) albo tożsamość (w przypadku osoby) wykonującego działanie na danych. System dziedzinowy umożliwia pobranie Logu systemowego w formacie XML i CSV. Wykonawca w uzgodnieniu z Zamawiającym przedstawi strukturę i zawartość logu systemowego. WF.9.2 Dostęp do logu w trybie odczytu ma każdy Urzędnik MAC. WF.9.3 System dziedzinowy zabezpiecza log systemowy przed zmianą przez Urzędnika MAC. Zdarzenia czasowe (stopery), wpisanie na Listę wykluczeń WF.10 Dla każdej zaakceptowanej przez Urzędnika MAC zbiórki publicznej System dziedzinowy uruchamia: stoper dla dostarczenia Sprawozdania po zakończeniu zbiórki, stoper dla dostarczenia Sprawozdania z rozdysponowania ofiar. WF.11 System dziedzinowy zatrzymuje: Strona 15 z 34

16 Kod stoper dla dostarczenia Sprawozdania po zakończeniu zbiórki, stoper dla dostarczenia Sprawozdania z rozdysponowania ofiar, po otrzymaniu odpowiedniego sprawozdania. WF.12 WF.12.1 System dziedzinowy wysyła Organizatorowi zbiórki pocztą elektroniczną powiadomienia o zbliżającym się oraz o przekroczonym terminie dostarczenia Sprawozdania po zakończeniu zbiórki i Sprawozdania z rozdysponowania ofiar. Termin powiadomienia o zbliżającym się terminie dostarczenia sprawozdania i termin dostarczenia sprawozdania są konfigurowalne przez Urzędnika MAC osobno dla: Sprawozdania po zakończeniu zbiórki, Sprawozdania z rozdysponowania ofiar. WF.13 System dziedzinowy w przypadku przekroczenia terminu dostarczenia Sprawozdania po zakończeniu zbiórki lub Sprawozdania z rozdysponowania ofiar zbiórki wpisuje Organizatora zbiórki na Listę wykluczeń. WF.13.1 W przypadku ponownego przekroczenia terminu dostarczenia sprawozdań System dziedzinowy dopisuje dla Organizatora kolejne pozycje na Liście wykluczeń. Urzędnik MAC: Zarządzanie treścią na stronie WWW WF.14 WF.14.1 WF.14.2 WF.14.3 Urzędnik MAC może zamieszczać w Systemie dziedzinowym artykuły, ilustracje oraz załączniki do artykułów. System dziedzinowy umożliwia tworzenie artykułów w Edytorze WYSIWYG. Artykuł składa się z tytułu, główki (lead), treści głównej, metadanych i załączników. Edytor WYSIWYG umożliwia następujące formatowanie główki i treści głównej artykułów: 1. wytłuszczenie, kursywa; 2. przekreślenie, indeks górny, indeks dolny; 3. kolor tekstu, kolor tła tekstu; 4. wyrównanie do lewej, wyśrodkowanie, wyrównanie do prawej, wyjustowanie; Strona 16 z 34

17 Kod 5. tworzenie list: numerowana, nienumerowana; 6. wstawianie linków, obrazów (osadzanie ilustracji w tekście i oblewanie tekstem) oraz załączników, 7. wstawianie tabel, edycja wierszy i kolumn, edycja komórek. System dziedzinowy system automatycznie prezentuje wielkość załącznika w MB z dokładnością do jednej cyfry po przecinku, typ załączonego pliku i ikonę skojarzoną z typem. WF.14.4 WF.14.5 Edytor WYSIWYG będzie oferował skróty klawiszowe co najmniej dla funkcji wskazanych w WF.14.3 pkt 1. Każdy artykuł jest opatrzony metadanymi: data wytworzenia, tożsamość osoby wytwarzającej, data publikacji, tożsamość osoby publikującej. Metadane są pobierane z Systemu dziedzinowego z możliwością edycji. WF.14.6 WF.14.7 Każda zmiana artykułu skutkuje powstaniem nowej wersji artykułu. Zdarzenie takie będzie odnotowywane w Logu systemowym. Artykuły są prezentowane na liście zawierającej tytuł, datę wytworzenia oraz główkę. WF Do pełnej treści artykuły prowadzą odsyłacz: tytuł oraz więcej. Odsyłacz więcej znajdujące się pod główką artykułu. wybranie odsyłacza prowadzi do pełnej treści artykułu. WF.15 WF.14.8 Urzędnik MAC może tworzyć i zamieszczać na stronie ankiety. WF.15.1 Obywatel: Prezentacja danych z list i z Repozytorium plików, prenumerata powiadomień WF.16 System dziedzinowy udostępnia Obywatelowi wybrane informacje o zbiórkach poprzez własny Graficzny interfejs użytkownika (GUI) strony WWW. WF.16.1 WF.16.2 Zakres prezentowanych informacji z Listy zbiórek, Listy wnioskodawców i Repozytorium plików określa Załącznik nr 5 do OOPiW. System dziedzinowy umożliwia przeglądanie, sortowanie oraz stronicowanie danych. Strona 17 z 34

18 Kod WF.16.3 WF.16.4 WF.16.5 System dziedzinowy umożliwia wyszukiwanie danych i informacji o plikach z możliwością wyboru wyszukiwania po dowolnej pozycji z listy. System dziedzinowy umożliwia wyszukiwanie z funkcją autouzupełniania po wprowadzeniu trzech znaków w pole zapytania. System dziedzinowy umożliwia Obywatelowi pobranie danych z Listy zbiórek oraz Listy wnioskodawców w formacie XML i CSV. Wykonawca w uzgodnieniu z Zamawiającym zaprojektuje mechanizm pobierania danych z list. WF.16.6 Pliki XML są wizualizowane na podstawie: wzoru dokumentu z Centralnego Repozytorium Wzorów Dokumentów Elektronicznych (CRD), danych ze słownika TERYT z Komponentu epuap. WF.16.7 WF.16.8 WF.16.9 Pliki binarne są udostępniane do pobrania z wyjątkiem tych, które mogą być zaprezentowane na stronie WWW. System dziedzinowy umożliwia prezentację informacji na wykresach. System dziedzinowy udostępnia skrót informacji w kanałach RSS, w tym: informacje o artykułach, informacje o zbiórkach. Wykonawca w uzgodnieniu z Zamawiającym przedstawi liczbę i zakres danych prezentowanych w kanałach RSS. WF.17 System dziedzinowy umożliwia prenumeratę powiadomień pocztą elektroniczną o publikacji Zgłoszeń zbiórek publicznych. WF.17.1 Obywatel może zapisać się na prenumeratę poprzez podanie adresu oraz wskazanie interesujących go Celów zbiórki publicznej. Cele zbiórki publicznej określone są w dokumencie Zgłoszenie albo aktualizacja danych zbiórki publicznej. WF.17.2 Obywatel może wypisać się z prenumeraty poprzez kliknięcie linka Wypisuje się z prenumeraty powiadomień o Zbiórkach publicznych (link znajduje się w poczcie elektronicznej prenumeraty) albo poprzez podanie w Systemie Strona 18 z 34

19 Kod dziedzinowym swojego adresu i wybranie polecenia wypisania się. WF.17.3 Wykonawca w uzgodnieniu z Zamawiającym zaprojektuje strukturę, zawartość i wizualizację informacji znajdujących się w poczcie elektronicznej prenumeraty. WF.17.4 Urzędnik MAC może zapoznać się w Systemie dziedzinowym z listą adresów prenumeratorów i wybranymi przez nich Celami zbiórek publicznych. Lista pozwala na przeglądanie, sortowanie oraz stronicowanie. Statystyki WWW WF.18 System dziedzinowy zapewnia Urzędnikowi MAC pobranie powyższej listy w formacie XML i CSV. System dziedzinowy udostępnia Urzędnikowi MAC statystyki strony WWW. WF Wymagania pozafunkcjonalne Ergonomia systemu WERG.1 WERG.2 WERG.3 Wykonawca opracuję architekturę informacji Systemu dziedzinowego osobno dla wersji standardowej i mobilnej. Na podstawie architektury informacji, o której mowa w WERG.1, Wykonawca przygotuje statyczne makiety interfejsu użytkownika zapisane w postaci plików PNG osobno dla wersji standardowej i mobilnej. Na podstawie statycznych makiet interfejsu użytkownika, o których mowa w WERG.2, Wykonawca przygotuje interaktywny prototyp interfejsu użytkownika wykonany w technologii HTML osobno dla wersji standardowej i mobilnej. Strona 19 z 34

20 WERG.4 Na podstawie interaktywnego prototypu interfejsu użytkownika, o którym mowa w WERG.3, Wykonawca przygotuje projekt graficzny interfejsu użytkownika w wersji domyślnej i w wersji wysokokontrastowej. Projekt graficzny będzie zgodny z Web Content Accessibility Guidelines (WCAG 2.0) z uwzględnieniem co najmniej poziomu AA. Projekt graficzny zostanie przygotowany osobno dla wersji standardowej i mobilnej. WERG.5 Wykonawca przygotuję księgę komunikatów Systemu dziedzinowego dla wersji standardowej oraz wersji mobilnej, zawierającą w szczególności: a. Rodzaje komunikatów (typ, opis, typowe zastosowania, ikona). b. Prototyp układ komunikatu. c. Sposoby wyświetlania komunikatów, w tym: a. podział komunikatów ze względu na lokalizację na stronie: komunikaty modalne, komunikaty nagłówkowe, komunikaty w treści. b. podział komunikatów ze względu na przekazywaną informację: komunikaty błędów, potwierdzenia, informacje o sukcesie, informacje inne (np. neutralna, oczekiwanie na działanie), d. Opis konstrukcji i miejsca wyświetlania w systemie komunikatów, e. Prototypy, przyciski i ikony dla komunikatów, f. Treść komunikatów. WERG.6 Wykonawca przygotuje GUI użytkownika zgodnie z rekomendacjami z dokumentu Metody i narzędzia prowadzenia analizy SEO - optymalizacja witryn dla wyszukiwarek internetowych, w szczególności w zakresie: Optymalizacji struktury adresów URL, Optymalizacji nawigacji wewnętrznej, Optymalizacji metatagów opisowych, Optymalizacji grafik, Optymalizacji kodu strony, Optymalizacja indeksacji poprzez zastosowanie sitemapy i pliku robots.txt. Dokument stanowi załącznik nr 6 do OOPiW. Strona 20 z 34

21 Dzienniki zdarzeń WMD Dane dzienników zdarzeń przechowywane są w sposób zapewniający integralność. W szczególności oznacza to poziom bezpieczeństwa zapewniający możliwość użycia dzienników zdarzeń jako dowód w przypadku sporów sądowych. 2. Dane z dzienników zdarzeń nie są usuwane. 3. Dane z dzienników zdarzeń mogą być przeglądane, eksportowane. 4. Zakres danych przechowywanych w dziennikach zdarzeń podlega konfiguracji. Dostęp do danych podlega autoryzacji Wydajność systemu Wymaganie WP.W.01 Wydajność Systemu dziedzinowego: zapewnia obsługę bieżących, ustabilizowanych potrzeb produkcyjnych systemu (obsługa użytkowników, obsługa usług wspólnych i infrastrukturalnych, procesów własnych systemu), uwzględnia potencjalne przejściowe wzrosty obciążenia związane z przejściowymi wzrostami aktywności użytkowników. Wymaganie to powinno być spełnione zarówno dla całego Systemu dziedzinowego, jak i dla każdego z komponentów oddzielnie Dostępność Wymaganie WP.D.1 System dziedzinowy pracuje w reżimie 24 godzinnym przez 365 dni w roku. Strona 21 z 34

22 Jako wyjściowy parametr niezawodnościowy zakłada się, że potrzebna i wystarczająca dostępność systemu (SLA) wynosi 99,5% - tzn. łączny czas awarii w ciągu roku wynosi do ok. 44 godzin (nie wlicza się tutaj planowych przerw na okna serwisowe) oraz nie mniej niż 99% kwartalnie. Dostępność poszczególnych komponentów oprogramowania aplikacyjnego Systemu epuap powinna być na tyle wysoka, by zapewnić poziom 99,5% dla całego Systemu dziedzinowego. WP.D.2 WP.D.3 System dziedzinowy posiada zabezpieczenia przed sytuacją, w której skutkiem błędu w konfiguracji lub awaryjnej sytuacji w otoczeniu Systemu dziedzinowego, któryś z komponentów Systemu dziedzinowego zaczyna w niekontrolowany zużywać możliwości systemu (capacity), zakłócając w ten sposób działanie pozostałych elementów. System dziedzinowy jako całość oraz każdy z komponentów oddzielne stosuje limity ograniczające wykorzystanie zasobów (przestrzeni i mocy obliczeniowej) przez poszczególne podmioty. Limity są stosowane co najmniej dla funkcji przeznaczonych do masowego wykorzystania (przez liczne podmioty) Wymagania prawne Wykonany i dostarczony przez Wykonawcę System dziedzinowy musi zapewnić zgodność z wymaganiami prawnymi lub w przypadku zmiany - z aktualnie obowiązującymi, a w szczególności z poniższymi: Wymaganie WPR.1 WPR.1 WPR.2 Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2005 r. Nr 64, poz. 565). Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. z 2011, Nr 206, poz. 1216) Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych Strona 22 z 34

23 wymagań dla systemów teleinformatycznych (Dz.U z 2012, poz. 526) WPR.3 Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania.(dz.u. z 2005, Nr 217, poz. 1836) WPR.4 Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz.U. z 2000 r. Nr 98, poz z późn. zm.) WPR.5 Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym. (Dz.U. 2001, nr 130, poz z późn. zm.) WPR.6 Rozporządzenie Rady Ministrów w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego (D.U. z 2002 r. Nr 128, poz.1094) WPR.7 WPR.8 WPR.11 WPR.12 WPR.13 Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. z 2002 r, Nr 144, poz z późn. zm) Ustawa z dnia 10 grudnia 2003 r. o czasie urzędowym na obszarze Rzeczypospolitej Polskiej (D.U. z 2004 r. Nr 16, poz. 144) Ustawa z 6 września 2001 r. o dostępie do informacji publicznej (Dz. U. z 2001 nr 112 poz z późn. zm.). Ustawa z dnia 23 kwietnia 1964 r. Kodeks cywilny (Dz. U. z 1964 Nr 16, poz. 93) Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. z 2002, Nr 101, poz. 926 z późn. zm.) WPR.14 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 Nr 100, poz.1024). Strona 23 z 34

24 Wymagania w zakresie specyfikacji oprogramowania standardowego Wymaganie WOS.01 WOS.02 WOS.03 WOS.04 Wykonawca musi dostarczyć, zainstalować i skonfigurować oprogramowanie standardowe. Wykonawca musi udzielić licencji niewyłącznej Zamawiającemu oraz MAiC rozciągającej się na całe terytorium Rzeczpospolitej Polskiej i nieograniczonej czasowo na korzystanie z oprogramowania standardowego, którego producentem jest Wykonawca, oraz z jego Modyfikacji na następujących polach eksploatacji określonych w Umowie. Wykonawca musi zapewnić udzielenie licencji niewyłącznej Zamawiającemu oraz MAiC rozciągającej się na całe terytorium Rzeczpospolitej Polskiej i niegraniczonej czasowo na korzystanie z Oprogramowania Standardowego, którego producentem nie jest Wykonawca, której warunki przekaże Zamawiającemu Wykonawca. Warunki licencji nie mogą być mniej korzystne niż określone w Umowie. Wykonawca musi zapewnić aktualizacje oprogramowania standardowego, w tym wyższe wersje (update/upgrade), patche i programy korekcji błędów oprogramowania standardowego i udzielenie licencji na aktualizacje w okresie min. 24 miesięcy Ograniczenia i zależności Wymaganie WO.01 WO.02 Wykonawca musi przenieść na Zamawiającego majątkowe prawa autorskie na polach eksploatacji wymienionych w Umowie Minimalne wersje wspieranych przeglądarek internetowych to: Mozilla Firefox w wersji 5.0 i nowszych, Internet Explorer w wersji 8.0 i nowszych, Opera w wersji 11 i nowszych, Google Chrome w wersji 12 i nowszych oraz Safari w wersji 5 i nowszych. Strona 24 z 34

25 Wszystkie wymagania funkcjonalne i pozafunkcjonalne muszą być w pełni realizowalne na w/w typach przeglądarek www, oraz w ramach tych przeglądarek i ich wersji najnowszych stabilnych wydawanych na dzień odbioru oprogramowania aplikacyjnego. WO.03 Oprogramowanie aplikacyjne ma być wykonane w architekturze opartej na usługi (SOA ang. Service-Oriented Architecture) Wymagania w zakresie dokumentacji Kod wymagania DOC.01 DOC.02 DOC.02.1 Wykonawca musi dokonać analizy wymagań zawartych w opisie przedmiotu zamówienia: opracować dokumentację projektową i powykonawczą dotyczącą oprogramowania aplikacyjnego i przedstawić do akceptacji Zamawiającego. 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: Dokumentacja projektowa zawierająca, co najmniej następujące informacje: 1. Szczegółową specyfikację wymagań dla oprogramowania aplikacyjnego, projektowanego w ramach realizacji zamówienia, 2. Diagram kontekstowy realizacji przedmiotu zamówienia, 3. Procesy kierujące realizacją przedmiotu zamówienia, 4. Struktura i zawartość planów realizacji przedmiotu zamówienia, 5. Techniki zarządzania realizacją przedmiotu zamówienia, 6. Ograniczenia rozwiązania, założenia i zależności, 7. Opis wymagań funkcjonalnych i niefunkcjonalnych oprogramowania aplikacyjnego, 8. Specyfikację wymagań funkcjonalnych, 9. Specyfikację wymagań niefunkcjonalnych, 10. Opis wymagań sprzętowych i programowych, 11. Specyfikację wymagań sprzętowych, 12. Specyfikację wymagań programowych, 13. Opis i specyfikację interfejsów, 14. Opis sposobu realizacji przedmiotu zamówienia zależny od zastosowanych metod, tj. metod obiektowych lub strukturalnych, Strona 25 z 34

26 Kod wymagania 15. Program przebiegu testów akceptacyjnych i sposób oszacowania niezawodności zaproponowanego rozwiązania, w tym propozycję raportów z testów, zgodny z modelem PTA przedstawionym przez Zamawiającego. 16. Zestaw elementów sterujących zarządzaniem i jakością, w tym tworzona dokumentacja obejmująca również działania zarządcze, tj. planowanie, monitorowanie i raportowanie prac w ramach realizacji przedmiotu zamówienia, w sytuacjach normalnych i wyjątkowych, a także działania specjalistyczne determinowane przez zakres i cele umowy/przedmiotu zamówienia, opisujące prace niezbędne do wytworzenia produktów, które mają powstać w ramach realizacji przedmiotu zamówienia. 17. Z dokumentu musi jednoznacznie wynikać sposób działania oprogramowania aplikacyjnego zarówno w skali globalnej, jak i sposób funkcjonowania poszczególnych jego komponentów, opis sposobu komunikacji pomiędzy poszczególnymi komponentami. 18. Opracowanie szczegółowej koncepcji wdrożenia i uruchomienia oprogramowania aplikacyjnego. DOC.02.2 Dokumentację powykonawczą, zawierającą co najmniej następujące informacje: 1. Wprowadzenie opisujące cele i zakres przedmiotu zamówienia, 2. Diagram kontekstowy wdrożonego rozwiązania i model zachowania, 3. Ograniczenia rozwiązania, założenia i zależności, 4. Ogólna charakterystyka użytkowników, 5. Opis wymagań funkcjonalnych i niefunkcjonalnych, 6. Specyfikację wymagań funkcjonalnych, 7. Specyfikację wymagań niefunkcjonalnych, 8. Specyfikację wymagań sprzętowych, 9. Specyfikację wymagań programowych, 10. Opis i specyfikację interfejsów, 11. Wyniki testów akceptacyjnych wraz z raportami, 12. Kody źródłowe, 13. Procedury utrzymaniowe. Strona 26 z 34

27 Kod wymagania DOC.03 Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji umowy 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, w tym notacji UML, 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, 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.04 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 oraz HTML (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.05 Wszelka Dokumentacja wytworzona w ramach realizacji przedmiotu Zamówienia musi być zgodna z wytycznymi dot. opracowania Dokumentacji projektowej opisanymi w Zasadach promocji projektów dla beneficjentów Programu Operacyjnego Innowacyjna Gospodarka tzn. musi być opatrzona logotypami: Programu Operacyjnego Innowacyjna Gospodarka, Unia Europejska z odniesieniem słownym do Europejskiego Funduszu Rozwoju Strona 27 z 34

28 Kod wymagania Regionalnego, logo Beneficjenta projektu epuap2. Szablony Dokumentacji zostaną przekazane Wykonawcy przez Zamawiającego. DOC.06 Do Dokumentacji oraz jej modyfikacji w ramach RfC zostaną przeniesione przez Wykonawcę majątkowe prawa autorskie na polach eksploatacji określonych w umowie Wymagania w zakresie odbioru produktów Kod wymagania OD.01 OD.03 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 OD OD OD wykaz oprogramowania wraz z rodzajem i liczbą, 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 każdego z etapów 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ą . Zamawiający przeprowadzi procedurę odbiorczą i przyjmie przedstawiony przedmiot zamówienia albo zgłosi ewentualne uwagi lub zastrzeżenia najpóźniej w terminie do 20 dni roboczych od dnia zgłoszenia przez Wykonawcę gotowości do przekazania przedmiotu zamówienia. Wykonawca uwzględni wszystkie uwagi Zamawiającego do przedmiotu zamówienia najpóźniej w terminie do 5 dni roboczych. Wszystkie czynności związane z dokonaniem odbioru muszą zakończyć się w terminie wykonania etapu i Umowy. Wykonawca musi przedstawić szczegółowy harmonogram odbiorów każdego z produktów Umowy, tak aby zapewnić odpowiedni czas Zamawiającemu na Strona 28 z 34

29 weryfikację produktu. OD.06 Zamawiający wymaga, aby Wykonawca przygotował Plan Testów Akceptacyjnych, podlegający zaakceptowaniu przez Zamawiającego zgodnego z szablonem PTA, stanowiącym załącznik do Umowy. OD.07 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: OD.08 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 z udziałem Wykonawcy. 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 Strona 29 z 34

30 3.4. Wymagania w zakresie zarządzania projektem ZP.01 Wymaganie Wymaga się od Wykonawcy, aby: organizacja przedsięwzięcia związanego z przedmiotem zamówienia i jego etapów, procesy kierujące przedsięwzięciem, struktura i zawartość planów projektu, techniki zarządzania projektem, zestaw elementów sterujących zarządzaniem i jakością, w tym cała tworzona dokumentacja, ZP.02 były oparte o ogólnie znaną metodykę projektową (PRINCE2 albo PMBoK) lub inną zaproponowaną przez Wykonawcę i zaakceptowaną przez Zamawiającego, uwzględniającą konkretne techniki, narzędzia i notacje, a także zapewniającą osiągnięcie zamierzonych celów jakościowych przy jednoczesnej minimalizacji możliwości niepowodzenia projektu. W przypadku wykorzystywania przez Wykonawcę innej metodyki zarządzania projektem niż PRINCE2 czy PMBoK wymaga się, aby uwzględniała ona co najmniej następujące elementy: sposób zarządzania projektem, w tym proces kontroli postępu prac w zakresie kosztów, pracochłonności i zgodności z harmonogramem projektu, a także częstotliwość punktów kontrolnych, raportowanie o postępach w realizacji projektu oraz sposób zarządzania problemami w realizacji projektu, proces przygotowania planu realizacji projektu i planu jakości projektu, analizę ryzyka przed rozpoczęciem projektu i zarządzanie ryzykiem w trakcie jego realizacji, politykę jakości projektu zawierającą wymagania jakościowe oraz kryteria jakości (np. związane z testowaniem), kontrolę jakości, w tym audyty wewnętrzne i zewnętrzne projektu oraz przeglądy projektu, sposób zarządzania konfiguracją, w tym identyfikacja elementów konfiguracji, kontrola wersji, informowanie uczestników projektu o zmianach, Strona 30 z 34

31 sposób zarządzania zmianami, w tym rodzaje modyfikacji (poprawki, aktualizacje, rozbudowa, udoskonalenia) oraz procedury kontroli zmian, bezpieczeństwo realizacji projektu, w tym poufność dokumenty wrażliwe, deklaracje poufności dla uczestników projektu oraz sposób rejestracji dostępu do dokumentów wrażliwych. ZP.03 ZP.04 W przypadku wykorzystywania przez Wykonawcę innej metodyki zarządzania projektem niż PRINCE2 czy PMBoK, Wykonawca jest zobowiązany dostarczyć Zamawiającemu wraz z ofertą opis metodyki w języku polskim, w wersji elektronicznej, w formacie PDF (dopuszcza się inne formaty zapisu należy jednak dołączyć przeglądarkę obsługującą wykorzystane formaty), na płycie CD-ROM lub innym równoważnym nośniku danych i drukowanej, w co najmniej 3 (trzech) egzemplarzach. W przypadku wykorzystywania przez Wykonawcę innej metodyki zarządzania projektem niż PRINCE2 czy PMBoK, Wykonawca jest zobowiązany przewidzieć w harmonogramie projektu czas (nie krótszy niż 5 dni roboczych) potrzebny Zamawiającemu na zapoznanie się z przedstawioną metodyką. Strona 31 z 34

32 ZP.05 Wykonawca przedstawi do akceptacji Zamawiającego ustanowione i udokumentowane działania, jakie należy wykonać w celu osiągnięcia zamierzonych celów zamówienia w terminie, przy określonych kosztach, wymaganej jakości i poziomie wykonania. Wymaga się, aby działania te, podobnie jak wszystkie pozostałe zadania realizowane w niniejszym zamówieniu, zostały podzielone na etapy, które występują jeden po drugim i pozwolą lepiej sterować projektem oraz ograniczyć ryzyko niepowodzenia projektu. Ponadto wymaga się, aby dla każdego etapu Wykonawca przedstawił do akceptacji Zamawiającego udokumentowane procedury zapewniające, że: postępowanie ze wszystkimi zagadnieniami projektowymi, szczególnie w zakresie wprowadzanych zmian, będzie pod kontrolą, na każdym etapie realizacji przedmiotu zamówienia będą dokonywane sprawdzenia w zakresie jakości wykonywanych prac, na podstawie ustanowionych i udokumentowanych procedur sterowania i weryfikacji, w celu spełnienia postawionych wymagań, przy czym procedury sterowania i weryfikacji, w tym przyjęta metodyka prowadzenia projektu, powinny być regularnie poddawane ocenie na podstawie obiektywnych kryteriów, niniejsze postępowanie będzie prowadzone w sposób skuteczny i efektywny, a wszystkie zmiany będą przed ich wprowadzeniem zidentyfikowane, udokumentowane, poddane przeglądom i zatwierdzone przez Zamawiającego. ZP.06 ZP.07 Wykonawca przygotuje i dostarczy, w nieprzekraczalnym terminie 7 Dni Roboczych od dnia podpisania Umowy, do zatwierdzenia przez Zamawiającego Plan Zarządzania Projektem zawierający w szczególności informacje wskazane w załączniku do Umowy wzór Planu Zarządzania Projektem. Wykonawca przygotuje i dostarczy łącznie z Planem Zarządzania Projektem do zatwierdzenia przez Zamawiającego harmonogram bazowy projektu. Harmonogram bazowy projektu musi uwzględniać m.in.: Wyznaczenie prac, które będą wykonywane w ramach niniejszego zamówienia przez Wykonawcę. Wskazanie zakresu prac realizowanych w poszczególnych etapach określonych przez Zamawiającego w OOPiW. Wyznaczenie punktów kontrolnych. Zaplanowanie prac dotyczących realizacji, kontroli i odbioru każdego Strona 32 z 34

33 z etapów Umowy. Inne ograniczenia projektu uwzględnione w Opisie Przedmiotu Zamówienia Wymagania w zakresie gwarancji Wykonawca musi zapewnić minimum 24 miesięczną gwarancję na oprogramowanie aplikacyjne i oprogramowanie standardowe. Na dostarczone oprogramowane aplikacyjne Wykonawca musi zapewnić minimum 24 miesięczną gwarancję liczoną od podpisania protokołu odbioru końcowego. W ramach gwarancji Wykonawca musi zapewnić co najmniej: Wsparcie techniczne polegające nastały kontakt w celu udzielania konsultacji Administratorom, w dni robocze w godz przyjmowanie zgłoszeń gwarancyjnych w trybie 24/7/365 (24 godz. na dobę, 7 dni w tygodniu, 365 dni w roku); zgłoszenia mogą być dokonywane: faksem, telefonicznie, em, poprzez Elektroniczny System Zgłoszeniowy dostarczony przez Wykonawcę. Wykonawca zarejestruje wszystkie zgłoszenia w Elektronicznym Systemie Zgłoszeniowym. Szczegółowe tryby i kanały komunikacji Wykonawca uzgodni z Zamawiającym w PZP. czasy obsługi zgłoszeń gwarancyjnych: - dla błędów kategorii A 4 godziny, - dla błędów kategorii B 2 dni kalendarzowe, - dla błędów kategorii C 14 dni kalendarzowe. Na dostarczone oprogramowane standardowe Wykonawca musi zapewnić minimum 24 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 OOPiW 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 Strona 33 z 34