Elektroniczna Platforma Informacji o aktach sprawy eas

Transkrypt

1 WOJEWÓDZTWO PODKARPACKIE Projekt współfinansowany ze środków Unii Europejskiej z Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Podkarpackiego na lata Część B SIWZ Elektroniczna Platforma Informacji o aktach sprawy eas Szczegółowy Opis Przedmiotu Zamówienia

2 Spis treści 1. Zastosowane skróty i pojęcia Przedmiot zamówienia - informacje ogólne Wymagania w zakresie oznakowania platformy i dokumentacji Bezpieczeństwo Zasoby Wymagania dot. platformy eas Wymagania ogólne Wymagania funkcjonalne i architektoniczne Wymagania prawne Wymagania dot. wymiany danych pomiędzy eas a EOD Wymagania dot. interfejsu uŝytkownika/pracownika Wymagania dot. administrowania systemem Wymagania dot. wydajności Wymagania dot. testów Wymagania dot. dokumentacji Zakres zadań Zadanie I dokumentacja zarządcza Zadanie II analiza wymagań i projekt techniczny ZADANIE III WYKONANIE WERSJI PODSTAWOWEJ ZADANIE IV WYKONANIE SYSTEMU ZADANIE V TESTOWANIE I ODBIÓR ZADANIE VI PREZENTACJA PEŁNYCH MOśLIWOŚCI PLATFORMY eas ZADANIE VII - ASYSTA TECHNICZNA WYMAGANY HARMONOGRAM PRAC...30 OA-XVI Str. 2 z 30

3 1. Zastosowane skróty i pojęcia Skrót / pojęcie Opis skrótu / pojęcia Platforma eas, Elektroniczna Platforma Informacji o aktach sprawy eas. Jest nazywana równieŝ eas to platforma, utworzona w ramach realizacji wniosku lub platforma e-usług o dofinansowanie realizacji projektu ze środków Europejskiego eas Funduszu Rozwoju Regionalnego w ramach osi priorytetowych II-VII Regionalnego Programu Operacyjnego Województwa Podkarpackiego na lata , oś 3. Społeczeństwo informacyjne. Lider Wojewoda Podkarpacki reprezentowany przez Podkarpacki Urząd Wojewódzki w Rzeszowie. Partnerzy 1. Wojewódzka Stacja Sanitarno-Epidemiologiczna w Rzeszowie. 2. Wojewódzki Inspektorat Weterynarii z siedzibą w Krośnie. 3. Kuratorium Oświaty w Rzeszowie. 4. Wojewódzki Inspektorat Inspekcji Handlowej w Rzeszowie. 5. Wojewódzki Inspektorat Transportu Drogowego w Rzeszowie. 6. Wojewódzki Inspektorat Ochrony Środowiska w Rzeszowie. 7. Wojewódzki Inspektorat Ochrony Roślin i Nasiennictwa w Rzeszowie. 8. Wojewódzki Inspektorat Jakości Handlowej Artykułów Rolno- SpoŜywczych w Rzeszowie. 9. Wojewódzki Inspektorat Nadzoru Budowlanego w Rzeszowie. 10. Wojewódzki Urząd Ochrony Zabytków z siedzibą w Przemyślu. 11. Wojewódzki Inspektorat Farmaceutyczny w Rzeszowie. Podmioty uczestniczące Jest to lider oraz partnerzy. w projekcie epuap Elektroniczna Platforma Usług Administracji Publicznej zbiór produktów projektu epuap-wkp rozwijanych w ramach projektu epuap2. epuap2 Projekt, którego realizacja odbywa się w latach , OA-XVI Str. 3 z 30

4 stanowiący kolejny etap realizacji docelowej architektury platformy epuap. epuap-wkp Projekt zrealizowany w latach , 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. EOD system Elektronicznego Obiegu Dokumentów. W przedmiotowym dokumencie jest on toŝsamy z systemem EZD. EZD system Elektronicznego Zarządzania Dokumentacją zgodny z rozporządzeniem Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz. U. z dnia 20 stycznia 2011 r. z późn. zm.). UŜytkownik Jest to osoba fizyczna, która korzysta z platformy eas za pomocą władnego konta. Osoba fizyczna moŝe być równieŝ reprezentantem osoby prawnej lub pełnomocnikiem innej osoby fizycznej Pracownik Jest to pracownik podmiotu uczestniczącego w projekcie. Ma on za zadanie między innymi potwierdzać uprawnienie do wglądu do akt spraw dla UŜytkownika. Administrator Jest to pracownik podmiotu uczestniczącego w projekcie posiadający szczególne uprawnienia umoŝliwiające administrowanie Platformą eas. Administrator jest szczególnym przypadkiem Pracownika. Testy akceptacyjne testy, których celem jest weryfikacja i formalne potwierdzenie zgodności testowanego systemu (Platformy eas) z wymaganiami oraz zawartą umową pomiędzy Zamawiającym, a Wykonawcą. Testy akceptacyjne obejmują między innymi: weryfikację spójności oraz poprawności wykonywanych operacji w bazie danych testowanego systemu, odnalezienie miejsc w testowanym systemie, gdzie dane nie są bezpieczne lub pojawia się podatność na moŝliwy atak, wykrycie niespójności i niezgodności w dokumentacji OA-XVI Str. 4 z 30

5 analitycznej, technicznej oraz dokumentacji uŝytkownika, sporządzonej w ramach realizowanego projektu informatycznego, sprawdzenie poprawności działania wszystkich funkcji testowanego systemu oraz ich zgodności z wymaganiami, kontrolę poprawności współdziałania testowanego systemu z innymi, juŝ istniejącymi i wykorzystywanymi systemami; kontrola ukierunkowana jest głównie na sprawdzanie interfejsów działających pomiędzy nimi, oszacowanie stopnia spełnienia wymagań wydajnościowych przez testowany system poprzez kontrolowanie jego pracy przy wzrastającej ilości danych oraz liczbie uŝytkowników 2. Przedmiot zamówienia - informacje ogólne Przedmiotem zamówienia jest zaprojektowanie, wykonanie i wdroŝenie elektronicznej platformy, dostępnej kaŝdemu obywatelowi i instytucji, poprzez publiczny Internet, przy pomocy której będzie moŝna śledzić stan spraw, mieć dostęp do akt spraw zainicjowanych w podmiotach uczestniczących w projekcie, przez ich klientów. PowyŜsza potrzeba wynika z art. 6 ust. 1 pkt. 3 lit. e ustawy o dostępie do informacji publicznej. Zgodnie z tą literą prawa, podmioty zobowiązane do tworzenia stron BIP od 1 stycznia 2004 r. obowiązane są do prezentacji stanu spraw, kolejności ich załatwiania i rozstrzygania". Ponadto zgodnie z art k.p.a. organy administracji publicznej obowiązane są zapewnić stronom czynny udział w kaŝdym stadium postępowania, a przed wydaniem decyzji umoŝliwić im wypowiedzenie się co do zebranych dowodów i materiałów oraz zgłoszonych Ŝądań oraz art k.p.a. strona ma prawo wglądu w akta sprawy, sporządzania z nich notatek, kopii lub odpisów. Prawo to przysługuje równieŝ po zakończeniu postępowania Wymagania w zakresie oznakowania platformy i dokumentacji Mając na względzie, iŝ wytworzenie platformy eas jest współfinansowane ze środków wspólnotowych Zamawiający wymaga, by interfejs aplikacji zawierał logo Unii Europejskiej i informacje o źródle finansowania zgodnie z Wytycznymi Instytucji Zarządzającej OA-XVI Str. 5 z 30

6 Regionalnym Programem Operacyjnym Województwa Podkarpackiego dla Beneficjentów w zakresie informacji promocji (aktualna wersja wytycznych z października 2011 r.) dostępnymi na stronie internetowej Ponadto Wykonawca zobowiązany jest do oznakowania wszelkiej dokumentacji związanej z projektem zgodnie z powyŝszymi wytycznymi. Oznakowanie podlega akceptacji Zamawiającego. 3. Bezpieczeństwo Zgodnie z obowiązującymi zasadami bezpieczeństwo danych zgromadzonych na Platformie eas powinno być analizowane pod kątem poufności, integralności i dostępności. NaleŜy zwrócić uwagę, Ŝe część danych na Platformie eas stanowią dane osobowe, których dotyczy ustawa o ochronie danych osobowych. W ramach analizy wymagań na etapie specyfikacji funkcjonalnej naleŝy uwzględnić wymagania wynikające z tej ustawy i rozporządzeń wydanych na jej podstawie. W szczególności naleŝy zapewnić moŝliwość weryfikacji zgromadzonych danych dotyczących osób korzystających z Platformy eas. Szczegółowe rozwiązania architektoniczne i techniczne muszą być zgodne z polityką bezpieczeństwa Podkarpackiego Urzędu Wojewódzkiego w Rzeszowie. Dotyczy to w szczególności zasad określania uprawnień, zasad identyfikacji uŝytkowników, itp. Podstawą do zapewnienia przywrócenia funkcjonowania Platformy eas po awarii musi być plan ciągłości jej działania uwzględniony w dokumentacji eksploatacyjnej Platformy eas. Bezpieczeństwo transmisji danych między eas a epuap i eas a EOD będzie zapewnione przez ustanowienie odpowiednich bezpiecznych kanałów transmisji. Funkcje wyszukiwania i przeglądania informacji na Platformie eas będą dostępne bezpośrednio przez stronę WWW. Platforma eas musi zapewnić odporność na ataki z Internetu, zarówno zagroŝenia dostępności (ataki Denial of Service), jak i próby włamania. Platforma eas powinna być zabezpieczona przed pobieraniem z niej danych nieudostępnionych w interfejsie uŝytkownika. System wyszukiwawczy oraz transakcyjny Platformy eas powinien być dostępny bez przerw, w trybie 7/24/ Zasoby Zasoby sprzętowe, na których będzie zainstalowana Platforma eas: 1. Serwer: IBM x3650 M4 3 szt. o parametrach: 1) pamięć 64 GB, OA-XVI Str. 6 z 30

7 2) dwa dyski 500 GB, 3) dwa zasilacze redundantne 750 W kaŝdy, 4) nagrywarka DVD, 5) 1 para portów kaŝdy 8 Gb FC 2. Macierz dyskowa: IBM V szt. 1) pojemność: powierzchnia w trybie tzw. surowym (raw) 21 TB 3. Switch SAN łączący serwery z macierzami: IBM SAN24 B-5 2 szt. 4. Wirtualne serwery: System operacyjny Windows SRV 2012 standard OLP NL Gov. 2 Proc. wraz z 10 lic. CAL per User. 6 szt. PowyŜszy sprzęt będzie rozlokowany w dwóch serwerowniach w tym samym budynku. Sprzęt pomiędzy serwerowniami połączony będzie poprzez switche IBM SAN24 siecią światłowodową. Całość będzie pracować na platformie wirtualizacyjnej Vmware vsphere 5. Macierz główna będzie pracować w serwerowni podstawowej a macierz zapasowa stanowiąca kopię macierzy głównej będzie pracować w serwerowni zapasowej. Zamawiający posiada dostęp do Internetu: 1. Podstawowy 40Mb/s symetryczny (światłowód) 2. Zapasowy 40Mb/s symetryczny (bezprzewodowy). Docelowo Zamawiający planuje zakup i wdroŝenie systemu archiwizacji do platformy eas. 5. Wymagania dot. platformy eas Platforma eas obejmuje swoim działaniem trzy obszary: epuap, EOD-y urzędów/pomiotów uczestniczących w projekcie oraz portal eas. Wszystkie wymienione obszary mają ze sobą współpracować. Współpraca pomiędzy obszarami ma odbywać się w następujących kontekstach: 1. EOD - epuap: Systemy EOD podmiotów uczestniczących w projekcie muszą w ramach utworzonego rozwiązania współpracować z epuap. 2. EOD - eas Portal eas musi współpracować z EOD wszystkich podmiotów uczestniczących w projekcie w zakresie pobierania z systemów EOD danych, o które pyta klient poprzez platformę eas. 3. epuap - eas OA-XVI Str. 7 z 30

8 Portal eas będzie korzystał z platformy epuap w procesie uwierzytelniania klienta, przy pomocy profilu zaufanego lub certyfikatu kwalifikowanego Wymagania ogólne Kod wymagania WO.01 WO.02 Opis wymagania eas musi być zintegrowany na poziomie usług z systemami EOD wykorzystywanymi w podmiotach uczestniczących w projekcie. Od momentu rejestracji pisma w EOD podmiotu uczestniczącego w projekcie, do którego zostało skierowane, klient musi mieć moŝliwość sprawdzenia stanu realizacji pisma lub sprawy oraz wgląd w akta spraw w następujący sposób: a) loguje się na platformę eas na konto zweryfikowane profilem zaufanym epuap lub podpisem kwalifikowanym (eas musi obsługiwać podpisy kwalifikowane wydane przez podmioty ujęte w rejestrze kwalifikowanych podmiotów świadczących usługi certyfikacyjne), b) obowiązkowo wybiera z listy dostępny podmiot, do którego złoŝył korespondencję, c) wyszukuje korespondencję lub wyszukuje sprawę, d) otrzymuje pełną informację, jak ta korespondencja jest przetwarzana w urzędzie i jakie sprawy w związku z nią zostały wszczęte, w jakim są stanie realizacji. Klient moŝe takŝe zapoznać się z aktami sprawy - jeŝeli są w postaci elektronicznej w EOD. Platforma eas ma realizować zadania wynikające z następujących przepisów prawa: art. 6 ust. 1 pkt 3 lit. e ustawy o dostępie do informacji publicznej. Zgodnie z tą literą prawa, podmioty zobowiązane do tworzenia stron BIP od 1 stycznia 2004 r. obowiązane są do prezentacji "stanu spraw, w kolejności ich załatwiania i rozstrzygania", art k.p.a. Organy administracji publicznej obowiązane są zapewnić stronom czynny udział w kaŝdym stadium postępowania, a przed wydaniem decyzji umoŝliwić im wypowiedzenie się co do zebranych dowodów i materiałów oraz zgłoszonych Ŝądań, art k.p.a. strona ma prawo wglądu w akta sprawy, sporządzania z nich notatek, kopii lub odpisów. Prawo to przysługuje równieŝ po zakończeniu postępowania. OA-XVI Str. 8 z 30

9 WO.03 WO.04 WO.05 WO.06 WO.07 WO.08 WO.09 WO.10 WO.11 WO.12 WO.13 WO.14 WO.15 WO.16 Platforma elektroniczna dostępna publicznie poprzez stronę WWW. Funkcje eas będą dostępne po uwierzytelnieniu klienta, który zechce z tej platformy skorzystać. eas musi umoŝliwić poprzez publiczny Internet, sprawdzanie stanu załatwienia spraw zainicjowanych korespondencją skierowaną do podmiotów uczestniczących w projekcie, a takŝe prezentować udostępnione akta spraw. W procesie uwierzytelniania będzie wykorzystywany profil zaufany epuap lub podpis kwalifikowany. W tym zakresie eas musi być ściśle zintegrowany z epuap. Dostęp do konta uŝytkownika będzie wymagał wpisania loginu i hasła. Podczas tworzenia konta uŝytkownika dane uŝytkownika muszą być zweryfikowane przy pomocy podpisu kwalifikowanego lub profilu zaufanego epuap. Weryfikacja musi jednoznacznie potwierdzić, poprawność danych wpisanych przez uŝytkownika, które potwierdzają jego toŝsamość. Dane zweryfikowane nie mogą zostać zmieniane, a w przypadku zmiany muszą podlegać od nowa weryfikacji. Termin waŝności zweryfikowanych danych musi być taki sam jak termin waŝności podpisu, którym dane zostały zweryfikowane. Po tym terminie konto będzie zablokowane. UŜytkownik nie moŝe mieć więcej niŝ jedno konto aktywne na eas. Platforma eas nie moŝe dopuszczać do takiego stanu. UŜytkownik po zablokowaniu konta moŝe je odblokować przy pomocy podpisu kwalifikowanego lub profilu zaufanego epuap. MoŜe je równieŝ odblokować wyznaczony przez Administratora eas pracownik. Platforma eas musi posiadać mechanizm przypominania o loginie konta uŝytkownika. System musi być zintegrowany z epuap w zakresie weryfikacji podpisu kwalifikowanego, profilu zaufanego epuap w zakresie w jakim umoŝliwia to epuap. JeŜeli weryfikacja podpisu kwalifikowanego nie jest moŝliwa poprzez epuap zapewni to platforma eas. eas musi zapewniać obsługę komunikacji zwrotnej do uŝytkownika np. poprzez wiadomości . Wersje językowe eas: Portal wykonany będzie w polskiej wersji językowej. eas umoŝliwia dodawanie dowolnej ilości wersji językowych platformy. eas musi obsługiwać znaki standardowo wykorzystywane w imionach i nazwiskach cudzoziemców. Platforma eas musi posiadać wbudowaną obsługę błędów. OA-XVI Str. 9 z 30

10 WO.17 WO.18 WO.19 WO.20 WO.21 WO.22 WO.23 WO.24 WO.25 WO.26 WO.27 WO.28 WO.29 WO.30 Teksty muszą być sformatowane do czytania i wydruku. Strony muszą się drukować w sposób czytelny. Mając na względzie, iŝ wytworzenie platformy eas jest współfinansowane ze środków wspólnotowych Zamawiający wymaga, by interfejs aplikacji zawierał logo Unii Europejskiej i informacje o źródle finansowania. Dokładne wytyczne Zamawiający przekaŝe Wykonawcy na etapie uzgodnień w trakcie wykonywania oprogramowania. Style i podstawy projektowania: tekst musi być wyjustowany. Style i podstawy projektowania: uŝywać standardowych czcionek dostępnych domyślnie w systemach operacyjnych (np. Arial, Verdana, Tahoma, Times New Roman). Style i podstawy projektowania: unikać WIELKICH LITER w treści tekstu. Style i podstawy projektowania: nie uŝywać tekstu migającego. Za zgodą Zamawiającego jest to dopuszczalne. Style i podstawy projektowania: podkreślenie uŝywać tylko do zaznaczenia hiperłączy. Za zgodą Zamawiającego dopuszczalne jest wykorzystanie w innych przypadkach. Style i podstawy projektowania: unikać kombinacji koloru zielony/czerwony (ze względu na ograniczenia w postrzeganiu). Style i podstawy projektowania: kolor jest uŝywany jako podkreślenie waŝności, ale nie jako jedyny wyróŝnik. Strona musi zawierać sekcje "Kontakt" umoŝliwiający łatwy kontakt z właścicielem strony oraz sekcje "O projekcie" zawierającą informacje o platformie eas. Zamawiający zastrzega, Ŝe moŝe zmienić nazwę kaŝdej z sekcji oraz dodać kolejne sekcje. Administrator eas ma mieć moŝliwość edycji nazwy sekcji oraz treści w sekcji. Zamawiający dopuszcza zmianę wymagania po przedstawieniu przez Wykonawcę i zaakceptowaniu przez Zamawiającego innego równowaŝnego rozwiązania. Wykonawca dostarczy dokumentację niezbędną do zgłoszenia do GIODO - strukturę bazy danych. Zbiór danych platformy eas jest zarejestrowany przez GIODO, jako zbiór danych osobowych, w związku z czym Zamawiający wymaga, aby Platforma eas umoŝliwiała monitorowanie działań uŝytkowników zgodnie z wymaganiami określonymi w ustawie z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. Nr 101, poz. 926 z późn. zm.) oraz aktach OA-XVI Str. 10 z 30

11 wykonawczych wydanych na podstawie tejŝe ustawy Wymagania funkcjonalne i architektoniczne Kod wymagania WFiA.01 WFiA.02 WFiA.03 WFiA.04 WFiA.05 WFiA.06 WFiA.07 WFiA.08 WFiA.09 WFiA.10 Opis wymagania eas musi posiadać architekturę trójwarstwową. eas musi być w pełni transakcyjny i musi zabezpieczać dane przed zniszczeniem lub przypadkowym nadpisaniem w przypadku równoczesnego korzystania z tych danych przez wielu uŝytkowników. eas od strony technicznej musi zapewnić skalowalność w zakresie wydajności, pojemności oraz dołączania dodatkowych uŝytkowników i elementów infrastruktury sprzętowej. eas musi być interoperacyjny w warstwie aplikacyjnej i bazodanowej będzie pozwalał na uruchomienie w środowiskach systemowych bazujących na technologii Microsoft Windows oraz w środowiskach opartych na systemie Linux. Dostęp do platformy eas musi być realizowany poprzez dwa, odrębne interfejsy uŝytkownika. Jeden dedykowany dla administratorów aplikacji, drugi dla zwykłych jej uŝytkowników. System będzie umoŝliwiał definiowanie grup pracowników oraz dla kaŝdej z grup definiowanie uprawnień z podziałem na podmioty uczestniczące w projekcie. System platformy eas musi być odporny, posiadać odpowiednie zabezpieczenia chroniące przed atakami typu INJECTION, XSS, CSRF, BRUTE-FORCE oraz innymi znanymi technikami wykorzystywanymi w celu włamań do systemów aplikacji webowych. UŜytkownik jeŝeli nie znajdzie automatycznie pisma lub sprawy ma moŝliwość wysłania zapytania poprzez platformę eas w zakresie udostępnienia stanu sprawy lub wglądu do akt sprawy na podstawie interesującej go sprawy lub pisma do podmiotu uczestniczącego w projekcie, w którym realizowana jest interesująca go sprawa. Platforma eas ma posiadać mechanizm powiązania stałego lub czasowego sprawy lub pisma z UŜytkownikiem. Czasowe lub stałe powiązanie uŝytkownika ze sprawą ma być realizowane w oparciu o rejestr upowaŝnień, jeŝeli jest upowaŝnienie niezbędne. OA-XVI Str. 11 z 30

12 WFiA.11 WFiA.12 WFiA.13 WFiA.14 WFiA.15 WFiA.16 WFiA.17 WFiA.18 WFiA.19 WFiA.20 WFiA.21 Wypełniony formularz upowaŝnienia lub pełnomocnictwa musi być dołączony, w postaci podpisanego podpisem kwalifikowanym lub profilem zaufanym epuap pliku XML, do akt spraw. Wówczas uŝytkownik moŝe poprzez platformę eas wnioskować o dostęp do akt spraw, do których uzyskał czasowe lub stałe upowaŝnienie. Wykonawca dostarczy wzór formularza upowaŝnienia i pełnomocnictwa, który podlega zatwierdzeniu przez Zamawiającego. UpowaŜnienie lub pełnomocnictwo moŝe być równieŝ dostarczone w formie skanu podpisanego podpisem kwalifikowanym lub profilem zaufanym epuap. Platforma eas ma umoŝliwiać klientowi wgląd w stan realizacji spraw lub akta sprawy, które zostały zainicjowane w podmiotach uczestniczących w projekcie. UŜytkownik posiada dostęp do przeglądanych wcześniej przez siebie spraw lub stanów spraw z moŝliwością ponownego wglądu do aktualnych danych dot. stanu sprawy lub udostępnionych akt sprawy bez potrzeby ponownego wyszukania interesującej uŝytkownika informacji. UŜytkownik ma moŝliwość ręcznego usuwania powiązania z własnymi sprawami. Platforma eas musi posiadać rejestr upowaŝnień uzupełniany przez wyznaczonych przez Administratora eas pracowników. eas nie moŝe przetwarzać dokumentów (plików zawierających dokumenty) w sposób, który naruszałby spójność i integralność plików, a w szczególności uniemoŝliwiający ich odczytanie w aplikacji źródłowej. UŜytkownik ma dostępny mechanizm umoŝliwiający wyszukanie interesującego go pisma, a na jego podstawie wglądu w stan sprawy/spraw lub udostępnienie akt spraw. Ma moŝliwość wyszukania pisma wg róŝnych kryteriów zgromadzonych w bazie EOD wg: zakresu dat lub wg dokładnej daty pisma, czego dotyczy, znaku pisma, nadawcy oraz innej identyfikacji korespondencji. Klient decyduje o tym czy pobrana jest wyłącznie metryka sprawy czy równieŝ dokumenty z nią związane. UŜytkownik musi mieć moŝliwość wybrania dokumentów do pobrania. Pobieranie dokumentów związanych ze sprawą w tym co najmniej dokumentów w formatach: txt, doc, docx, xls, xlsx, rtf, odt, xps, pdf, jpg, tif. Wykonawca opracuje w formie elektronicznej pełną instrukcję obsługi interfejsu dla uŝytkownika/pracownika i dla administratora, która będzie dostępna z poziomu interfejsu. OA-XVI Str. 12 z 30

13 WFiA.22 WFiA.23 Wymaga się, aby była moŝliwość wykorzystania na wyświetlanych tabelach mechanizmów szybkiej filtracji po dowolnie wybranej kolumnie oraz moŝliwości wyszukiwania po kilku parametrach. UŜytkownik i pracownik musi być ostrzegany o przedawnieniach tzn. koniec sesji, limit czasu operacji itp Wymagania prawne Platforma eas musi być zgodna z minimum następującymi aktami prawnymi: Kod wymagania WP.01 WP.02 WP.03 WP.04 WP.05 WP.06 WP.07 WP.08 WP.09 Opis wymagania Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz.U. z 2013 r., poz. 267). Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz.U. z 2011 r. Nr 123, poz. 698, z późn. zm.). Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. z 2002 r. Nr 101, poz. 926, z późn. zm.). Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz.U. Nr 112, poz. 1198, z późn. zm.). Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. z 2013 r., poz. 262). Ustawa z dnia 5 lipca 2002 r. o ochronie niektórych usług świadczonych drogą elektroniczną opartych lub polegających na dostępie warunkowym (Dz.U. Nr 126, poz. 1068, z późn. zm.). Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. Nr 144, poz. 1204, z późn. zm.). Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2013 r., poz. 235). Rozporządzenie Ministra Kultury z dnia 16 września 2002 r. w sprawie postępowania z dokumentacją, zasad jej klasyfikowania i kwalifikowania oraz zasad i trybu przekazywania materiałów archiwalnych do archiwów państwowych (Dz.U. Nr 167, poz. 1375). OA-XVI Str. 13 z 30

14 WP.10 WP.11 WP.12 WP.13 WP.14 WP.15 WP.16 WP.17 WP.18 WP.19 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. Nr 100, poz. 1024). Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. Nr 205, poz. 1692). 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. Nr 217, poz. 1836). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz.U. Nr 206, poz. 1517). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. Nr 206, poz. 1518). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz.U. Nr 206, poz. 1519). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 stycznia 2007 r. w sprawie Biuletynu Informacji Publicznej (Dz.U. Nr 10, poz. 68). Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz. U. Nr 14, poz. 67, z późn. zm.). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 kwietnia 2011 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U. Nr 93, poz. 546). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 kwietnia 2011 r. w sprawie zasad potwierdzania, przedłuŝania waŝności, wykorzystywania i uniewaŝniania profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz.U. Nr 93, poz. 547). OA-XVI Str. 14 z 30

15 WP.20 WP.21 WP.22 WP.23 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, wzorców i kopii dokumentów elektronicznych (Dz.U. Nr 206, poz. 1216). Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 21 kwietnia 2011 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny słuŝący do identyfikacji uŝytkowników (Dz.U. Nr 93, poz. 545). Rozporządzenie Ministra Finansów z dnia 5 marca 2012 r. w sprawie wzoru i sposobu prowadzenia metryki sprawy (Dz.U. z 2012 r., poz. 246). Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2012 r., poz. 526) Wymagania dot. wymiany danych pomiędzy eas a EOD Kod wymagania WWD.01 WWD.02 WWD.03 Opis wymagania eas musi posiadać ustandaryzowane interfejsy zewnętrzne, obejmujące udostępnianie usług integracyjnych (m.in. wymiany danych) Systemu Elektronicznego Obiegu Dokumentów systemom zewnętrznym poprzez: usługi Web Services (np. w oparciu o standardy SOAP, WSDL); moŝliwość komunikacji z wykorzystaniem plików XML. eas i kaŝdy EOD muszą rejestrować wszystkie czynności komunikacji w obie strony, w tym równieŝ rejestrować szczegółową informację o wymienionych danych. W celu zapewnienia prawidłowej komunikacji pomiędzy eas, a EOD, jak teŝ umoŝliwienia integracji z innymi systemami EOD w przyszłości, funkcjonalność eas w zakresie wymiany danych musi być zgodna z przepisami prawa. W szczególności Zamawiający wymaga, aby architektura eas oraz uŝyte rozwiązania technologiczne zapewniały jego interoperacyjność zarówno w wymiarze informacyjnym jak i technicznym. OA-XVI Str. 15 z 30

16 WWD.04 WWD.05 WWD.06 WWD.07 WWD.08 WWD.09 WWD.10 WWD.11 Interoperacyjność informacyjna ma zapewnić zdolność eas do efektywnej wymiany i uŝycia zunifikowanej informacji z EOD bez względu na ich architekturę i wykorzystywane technologie. W celu zapewnienia interoperacyjności informacyjnej zastosowane zostaną standardowe rozwiązania w zakresie wymiany plików, zbiorów znaków, kodowania, struktury logicznej i fizycznej plików, współdzielenia danych, opisu metadanych, kontekstu (znaczenia) danych. Interoperacyjność techniczna zapewni zdolność eas do osiągnięcia skutecznej i bezpiecznej współpracy z EOD na poziomie technicznym. W celu zapewnienia interoperacyjności technicznej wykorzystane zostaną stosowane powszechnie protokoły i standardy wymiany danych, opisu zasobów, prezentacji informacji, opisu metadanych dla procesów, danych i web serwisów. Web serwis musi być zaprojektowany i wykonany wraz ze szczegółowym opisem technicznym dla integratorów EOD-ów. W celu testowania połączenia systemów EOD z platformą eas Wykonawca przygotuje środowisko testowe. Komunikacja pomiędzy EOD-ami a platformą eas będzie się odbywać za pośrednictwem Internetu i będzie zapewniona poprzez połączenie VPN. Platforma eas musi umoŝliwiać autoryzację EOD-ów Zabezpieczenia komunikacji. Poszczególne komponenty dostarczonego oprogramowania muszą komunikować się ze sobą oraz z systemami zewnętrznymi w sposób zapewniający poufność danych. Dopuszcza się jako rozwiązanie wykorzystanie protokołu SSL lub połączenia VPN. Platforma eas musi posiadać rejestr udostępnionych spraw oraz stanów spraw Wymagania dot. interfejsu uŝytkownika/pracownika Kod wymagania WIUP.01 Opis wymagania Interfejs graficzny platformy eas musi być wynikiem prac zgodnych z zasadami metodologii projektowania zorientowanego na uŝytkownika (UCD). NaleŜy dąŝyć do maksymalnego uproszczenia, zachowania przejrzystości, OA-XVI Str. 16 z 30

17 WIUP.02 WIUP.03 WIUP.04 WIUP.05 WIUP.06 WIUP.07 WIUP.08 WIUP.09 WIUP.10 czytelności interfejsu uŝytkownika, co przełoŝy się relatywnie na intuicyjną jego obsługę, uŝytkowanie. Dodatkowo projekt musi dawać moŝliwość łatwej dalszej rozbudowy. System musi wspierać uŝytkownika poprzez wbudowany ogólny (skorowidz haseł) oraz kontekstowy system pomocy. Wykonywanie dłuŝszych operacji musi być w wyróŝniony sposób sygnalizowane przez system. Sygnalizowanie niewykonalności operacji. Struktura wysyłanych wiadomości mailowych musi być zgodna z przyjętymi zasadami tak aby filtry antyspamowe nie klasyfikowały tychŝe wiadomości jako SPAM. eas ma umoŝliwiać prezentowanie danych w tym prezentacje dokumentów oraz podpisów, jak równieŝ sprawdzenia poprawności podpisanych dokumentów. Prezentacja dokumentów udostępnianych poprzez eas nie moŝe wymuszać instalowania dodatkowego płatnego oprogramowania na stanowisku uŝytkownika. Dopuszcza się wykorzystywanie standardowego oprogramowania umoŝliwiającego prezentacje dokumentów oraz podpisów. Komunikacja eas z uŝytkownikiem musi być realizowana wyłącznie poprzez przeglądarkę internetową. Platforma eas musi być poprawnie obsługiwana przez popularne przeglądarki internetowe, w szczególności: Mozilla Firefox, Google Chrome, Opera oraz Safari w wersjach aktualnych na okres rozpoczęcia realizacji projektu. Dodatkowo w odniesieniu do przeglądarki Microsoft Internet Explorer wymagana jest kompatybilność platformy począwszy od wersji 8.0 wzwyŝ. Kod warstwy prezentacji musi być zgodny z standardami XHTML1.0 lub XHTML1.1 oraz CSS2.1. Do weryfikacji poprawnej walidacji kodu strony słuŝyć będą narzędzia oraz Interfejs eas musi być poprawnie wyświetlany na ekranach monitora w rozdzielczości min. 1024x768 pikseli. Grafika i kolory nawiązujące do aktualnej szaty graficznej strony Lidera projektu ( W projekcie naleŝy zadbać o czytelność warstwy tekstowej zapewniając odpowiedni jej kontrast jak i typ oraz rozmiar czcionki. Nie naleŝy uŝywać koloru jako jedynej metody do przekazywania treści i rozróŝniania elementów wizualnych. Linki muszą odróŝniać się od elementów i tekstu, które je otaczają. JeŜeli kolor wykorzystywany jest do wyróŝnienia linków, naleŝy zastosować dodatkowy sposób, aby je wyróŝnić (np. naleŝy je podkreślić po OA-XVI Str. 17 z 30

18 najechaniu na link kursorem myszki). WIUP.11 WIUP.12 WIUP.13 WIUP.14 Wymaga się, aby interfejs pracownika i uŝytkownika eas stosował wyróŝnienia obowiązkowo wypełnianych pól poprzez wyróŝnienie pola innym kolorem. Obowiązkowo wypełniane pola muszą mieć dostępny system podpowiedzi w jaki sposób te pola powinny zostać poprawnie wypełnione. Podpowiedź musi być dostępna obok wypełnionych pól. Wymaga się ograniczenia do minimum wykorzystania mechanizmu wyskakujących okien (pop-up). W sytuacjach, w których ich wykorzystanie jest konieczne, celem poprawnego ich wyświetlania w przeglądarkach z aktywną opcją blokady wyskakujących okienek, okna dialogowe (pop-up) w swoim działaniu nie mogą korzystać z okna samej przeglądarki internetowej, muszą działać w oparciu o dodatkowe rozszerzenia działające po stronie uŝytkownika. Dodatkowo okna dialogowe (w szczególności okna informacyjne) muszą posiadać w prawym górnym rogu czytelną opcję (np. w formie przycisku, krzyŝyka) ich zamknięcia. Moduł menu głównego aplikacji jako podstawowy element nawigacyjny musi posiadać następujące cechy: 1.Dostępność waŝnym jest aby menu platformy eas było widoczne na kaŝdej jej stronie i wszystkich podstronach, 2. Łatwość i intuicyjność obsługi sposób korzystania z menu musi być łatwy, intuicyjny wręcz oczywisty dla potencjonalnego uŝytkownika systemu. NaleŜy unikać skomplikowanych rozwiązań, animowanych efektów, które to mogłyby utrudniać jego obsługę, 3. Funkcja informacyjna etykiety wykorzystane w menu muszą być zrozumiałe, informować o zawartości strony / podstrony docelowej, do której prowadzą. 4. Oznaczenie stanu poszczególne elementy menu mają reagować na akcję uŝytkownika, w tym celu naleŝy rozróŝnić 3 stany (domyślny brak reakcji uŝytkownika, wskazanie elementu najechanie na dany element kursorem myszki, aktywność elementu dział / sekcja strony w której uŝytkownik aktualnie się znajduje), wszystkie te stany powinny zostać odpowiednio oznaczone (np. poprzez styl ich wyglądu), 5. Prawidłowa organizacja elementów menu musi odzwierciedlać hierarchię poszczególnych pozycji, tzn. w przypadku menu rozwijanego, pierwszy jego poziom powinny stanowić główne działy aplikacji, kolejne poziomy powinny odwzorowywać dalszą strukturę stron, z kolei w przypadku menu w formie listy OA-XVI Str. 18 z 30

19 stron, strony działów głównych powinny wyróŝniać się na tle pozostałych, 6. Opcja powrotu do strony głównej - naleŝy zapewnić link, który umoŝliwi ominięcie nawigacji i innych powtarzających się elementów na podstronach i powrót do strony głównej platformy eas. Sekwencje zadań realizowanych przez uŝytkownika, pracownika, powinny być moŝliwe do ukończenia przy pomocy narzędzi podobnych we wszystkich procesach. Przyciski akcji powinny być umieszczone zawsze w tym samym miejscu ekranu, kolejność kroków powinna być o ile to moŝliwe zbliŝona (np. logowanie, formularz z danymi, potwierdzenie, podpisanie, wysłanie). WIUP.15 Wprowadza to pewien standard budowania procesów biznesowych, a dokładniej przechodzenia przez te procesy, tak by uŝytkownik nauczywszy się jak przejść jeden z procesów znalazł jego analogię w innych. Czyni to całość interfejsu uŝytkownika i pracownika łatwiejszym w obsłudze. Spójne formatowanie treści podstron (zachowanie szablonów wyglądu i formatowania). Skuteczne wykorzystanie łącz: treść nie moŝe zawierać nadmiaru łącz WIUP.16 (w stosunku do reszty tekstu). Rozmiar obszaru głównego strony (prezentacji danych) nie moŝe być szerszy niŝ okno przeglądarki internetowej uŝytkownika, tym samym nie dopuszczalna jest konieczność pojawienia się / uŝywania suwaka poziomego przeglądarki celem uzyskania dostępu do poszczególnych elementów strony. Jednym WIUP.17 wyjątkiem jest sytuacja, gdy uŝytkownik wykorzystuje okno przeglądarki w rozmiarze mniejszym niŝ 1024px szerokości. Obszary, w których treść jest dłuŝsza niŝ dostępna wysokość przeglądarki, oprócz standardowego suwaka pionowego wymagana jest moŝliwość uŝywania rolki myszki w celu przewijania treści. W przypadku prezentowania obszernych treści, które w stopniu znacznym WIUP.18 wydłuŝają obszar strony zalecane jest wykorzystanie mechanizmu podziału treści na mniejsze ich bloki (np. poprzez mechanizm stronicowania). Elementy graficzne posiadające wyłącznie funkcję ozdobną powinny być WIUP.19 wykorzystywane tylko w uzasadnionych przypadkach. WIUP.20 Platforma eas ma być w pełni zgodna ze standardem WCAG 2.0. Wymagane jest takŝe przygotowanie osobnej wersji interfejsu uŝytkownika z podwyŝszonym kontrastem dedykowanej osobom niepełnosprawnym (słabo WIUP.21 widzącym). Strona musi być przygotowana w trybie tekstowym, a więc pozbawiona elementów graficznych. NaleŜy uŝyć odpowiednio większego OA-XVI Str. 19 z 30

20 WIUP.22 rozmiaru czcionki w kolorze kontrastowym w stosunku do tła. Proponujemy wykorzystanie białego lub Ŝółtego koloru czcionki na czarnym tle. Dostęp do wersji tekstowej uŝytkownik powinien uzyskać po kliknięciu w ikonę / przycisk umieszczony na stronie startowej platformy. Platforma eas musi dodatkowo posiadać odpowiednią wersję mobilną (po stronie uŝytkownika), która musi być przystosowana do wyświetlania na róŝnorodnych urządzeniach mobilnych takich jak: telefony komórkowe, smartfony czy palmtopy. Interfejs wersji mobilnej aplikacji musi cechować się / być: 1. Dopasowany do wygodnej nawigacji w telefonie z dotykowym ekranem, 2. Przejrzysty, a jednocześnie maksymalnie uproszczony, 3. Ergonomicznym zagospodarowaniem obszaru treści, naleŝy unikać przeładowania strony zbyt duŝą ilością informacji, treści, 4. Elementy graficzne powinny być wykorzystywane tylko w uzasadnionych przypadkach Wymagania dot. administrowania systemem Kod wymagania WAS.01 WAS.02 WAS.03 WAS.04 Opis wymagania Interfejs administratora musi umoŝliwiać określanie uprawnień uŝytkowników (urzędników i administratorów) do czynności i danych, z moŝliwością delegowania uprawnień. Administrator musi mieć moŝliwość aktywacji i dezaktywacji połączenia z wybranym EOD-em. Administrator musi mieć moŝliwość dodania kolejnego systemu EOD jednostki bez dokupywania dodatkowych licencji. eas musi posiadać mechanizm kontrolujący stałe połączenie z systemami EOD, które sprawdza poprawność połączenia, w tym równieŝ kontroli transmisji danych pomiędzy eas a EOD w zadanym przez administratora interwale czasowym. W przypadku wystąpienia awarii eas musi informować poprzez wysłanie wiadomości na wskazane przez administratora adresy. Administrator musi mieć moŝliwość samodzielnego definiowania ww. adresów. MoŜliwość wykonywania testów na Ŝądanie dla wszystkich połączeń lub OA-XVI Str. 20 z 30

21 WAS.05 WAS.06 WAS.07 WAS.08 WAS.09 WAS.10 WAS.11 WAS.12 WAS.13 WAS.14 WAS.15 WAS.16 WAS.17 WAS.18 pojedynczych. Testy wykonywanie równolegle lub szeregowo. Przedmiotowe mechanizmy muszą równieŝ umoŝliwiać wysyłanie wiadomości do administratorów EOD, gdy ich system stracił połączenie z platformą eas. W panelu administracyjnym moŝliwe będzie prowadzenie dziennika zdarzeń i dostępu do obiektów danych, spraw i dokumentów, umoŝliwiający odtwarzanie historii aktywności poszczególnych uŝytkowników systemu. System umoŝliwia eksport dziennika zdarzeń do pliku. Panel administracyjny umoŝliwia realizację podstawowych zadań administracyjnych (obejmujące m.in. definiowanie uŝytkowników i ich uprawnień, parametryzowanie systemu, definiowanie raportów) przez graficzny interfejs. eas musi posiadać wbudowany mechanizm zdalnej asysty technicznej pozwalający na wsparcie uŝytkowników platformy eas przez uprawnionych do tego administratorów Panel administracyjny umoŝliwia wymuszanie ustawiania hasła z uwzględnieniem wybranego przez administratora poziomu bezpieczeństwa. Panel administracyjny umoŝliwia określenie minimalnej liczby znaków w haśle z uwzględnieniem poziomu bezpieczeństwa oraz wymogów przyjętej Polityki Bezpieczeństwa. Panel administracyjny umoŝliwia określenie maksymalnej liczby nieudanych prób logowania. Panel administracyjny umoŝliwia generowania hasła dla kaŝdego uŝytkownika. Panel administracyjny umoŝliwia odzyskanie utraconego hasła poprzez wygenerowanie nowego hasła. Panel administracyjny umoŝliwia ustawienie daty waŝności konta. Administrator eas globalnie definiuje złoŝoność hasła dla kont uŝytkowników i kont pracowników. Panel administracyjny umoŝliwia prezentację listy aktualnie zalogowanych uŝytkowników i pracowników. Administrator eas globalnie definiuje liczbę błędnych logowań na konto uŝytkownika i konto pracownika. Panel administracyjny umoŝliwia import uŝytkowników z pliku CSV o określonej strukturze. Administrator eas lub osoba uprawniona ma moŝliwość odblokowania konta uŝytkownika i konta pracownika oraz nadania hasła jednorazowego. OA-XVI Str. 21 z 30

22 WAS.19 WAS.20 WAS.21 WAS.22 WAS.23 Panel administracyjny umoŝliwia prezentację ostatniego logowania się w systemie. Platforma eas musi umoŝliwiać administratorowi eas nadawanie uprawnień dla kont pracowników. NaleŜy dostarczyć narzędzia umoŝliwiające administrowanie platformą eas w trybie tekstowym do wykorzystywania tego trybu w sytuacjach awaryjnych. Platforma eas musi prezentować (np. w module administratora) historię aktualizacji wersji oprogramowania wraz z informacją na temat zmian wprowadzonych w kolejnych wersjach. Interfejs administratora musi wyglądem oraz nawigacją być toŝsamy z interfejsem uŝytkownika/pracownika Wymagania dot. wydajności Kod wymagania WWS.01 WWS.02 WWS.03 Opis wymagania Wykonawca wykona optymalizację kodu, plików graficznych, animacji, struktury bazodanowej pod kątem znacznego ruchu na portalu: min. 50 jednoczesnych operacji wykonywanych przez uŝytkowników/pracowników na portalu eas, obsługa min osób kont uŝytkowników portalu. Wykonawca zagwarantuje odpowiednią wydajność. Odpowiednia wydajność oznacza, Ŝe system zapewnia odpowiednio szybką reakcję na działania uŝytkowników średni czas odświeŝania/odbudowy ekranu po czynności wykonanej przez uŝytkownika nie moŝe być dłuŝszy niŝ 3 sek. Warunek ten nie dotyczy funkcji, które są związane z wykonywaniem globalnych operacji na bazie danych takich, jak np. sporządzanie raportów, prac serwisowych. Warunek jest spełniony przy jednoczesnym dostępie do danych dla min. 75 uŝytkowników. eas nie moŝe mieć ograniczenia dot. jednoczesnego dostępu do danych dla uŝytkowników oraz musi zapewniać ochronę tych danych przed utratą spójności lub zniszczeniem. OA-XVI Str. 22 z 30

23 5.8. Wymagania dot. testów Kod wymagania WT.01 WT.02 Opis wymagania Wykonawca musi ustalić i zatwierdzić z Zamawiającym wykaz testów akceptacyjnych dla kaŝdego z przypadku uŝycia. Wykaz testów musi zawierać dodatkowo scenariusze testowe weryfikujące zgodność rozwiązania z wymaganiami na Platformę eas. Scenariusze poszczególnych testów muszą składać się co najmniej z sekwencji kolejnych czynności wykonywanych przez uŝytkownika/administratora i opisu oczekiwanej reakcji Platformy eas w odpowiedzi na wykonaną czynność. Zamawiający moŝe zaproponować przygotowane przez siebie testy Wymagania dot. dokumentacji Kod wymagania WD.01 WD.02 WD.03 WD.04 WD.05 Opis wymagania Dokumentacja musi uŝywać terminologii zrozumiałej dla uŝytkownika. Instrukcja musi zawierać wykaz czynności (co najmniej na poziomie przypadków uŝycia), wykonywanych przez uŝytkownika pełniącego daną rolę oraz szczegółowy sposób realizacji tych czynności (kolejne kroki) wraz ze zrzutami ekranów. Instrukcja dla administratorów musi zawierać reguły diagnozowania przyczyn awarii. Wykonawca po zaprojektowaniu i wykonaniu Platformy dostarczy pełną dokumentację powykonawczą platformy eas, która musi stanowić zaktualizowaną dokumentację podstawową. Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji umowy charakteryzowały się wysoką jakością, na którą będzie miała wpływ: - struktura dokumentu (rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób), - kompletność dokumentu (rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia) OA-XVI Str. 23 z 30

24 WD.06 WD.07 WD.08 WD.09 - spójność i niesprzeczność dokumentu (wzajemna zgodność pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, brak logicznych sprzeczności pomiędzy informacjami zawartymi we fragmentach tego samego dokumentu jak i we wszystkich dokumentach przekazanych Zamawiającemu). Zamawiający wymaga, aby dokumentacja podstawowa, wykonawcza 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 podpisana kwalifikowanym podpisem elektronicznym. Cała dokumentacja musi być uaktualniana na bieŝąco, a po wprowadzeniu kaŝdej istotnej zmiany przekazywana w komplecie Zamawiającemu. Mając na względzie, iŝ wytworzenie platformy eas jest współfinansowane ze środków wspólnotowych Zamawiający wymaga, by cała dokumentacja zawierała logo Unii Europejskiej i informacje o źródle finansowania. Wzory oznaczenia Zamawiający przekaŝe Wykonawcy po podpisaniu umowy. Zamawiający wymaga, aby Wykonawca przygotował całą dokumentację o której mowa powyŝej, zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania. (Dz.U. z dnia 2011, Nr 206, poz. 1216). 6. Zakres zadań Niniejszy rozdział zawiera listę zadań do realizacji przez Wykonawcę przedmiotu zamówienia wraz z określeniem ich głównych produktów Zadanie I dokumentacja zarządcza Zadanie obejmuje opracowanie następujących produktów stanowiących dokumentację zarządczą: 1. Plan Projektu (PP) obejmujący m.in. proponowany harmonogram prac z podziałem na etapy zarządcze z zachowaniem terminów podanych w Harmonogramie prac - pkt 7, opis etapów, wykres Gantta, diagram następstwa produktów (modułów), tolerancje na czas i jakość oraz plan rezerwowy; OA-XVI Str. 24 z 30

25 2. Plan Komunikacji (PK) obejmujący m.in. propozycję procedur komunikacji wraz z listą kontaktową osób biorących udział w projekcie oraz określeniem ich ról w projekcie, metody i formy komunikacji, format, częstotliwość; 3. Rejestr Ryzyk (RR) obejmujący m.in. wstępną identyfikację ryzyk projektowych wraz z oceną ich wpływu na projekt oraz propozycją działań zaradczych, prawdopodobieństwo, oddziaływanie, bliskość ryzyka oraz określenie właściciela zagroŝenia; 4. Rejestr Zagadnień (RZ) obejmujący m.in. wstępną identyfikację zagadnień projektowych wraz z oceną ich wpływu na realizacje przedmiotu zamówienia oraz propozycją działań zaradczych, określenie rodzaju, autora zgłaszającego zagadnienie, opis zagadnienia jego priorytet oraz status; 5. Plan Jakości Projektu (PJP) obejmujący m.in. określenie metod i narzędzi kontroli jakości na kaŝdym z etapów zarządczych oraz określenie kryteriów akceptacji; 6. Plan realizacji wykonania etapów Platformy eas obejmujący co najmniej: podział na etapy techniczne, proponowany harmonogram prac (wymagany wykres Gantta), planowane zasoby ze strony Wykonawcy, zaleŝności zewnętrzne, w tym potrzeby w zakresie dostępności osób, środowisk i sprzętu ze strony Zamawiającego, opisy głównych produktów wraz z proponowanymi kryteriami akceptacji, proponowane metody kontroli jakości dla głównych produktów na etapie realizacji przedmiotu zamówienia, sposób realizacji, sposób kontrolowania i nadzorowania Wykonawcy w zakresie wykonania Platformy eas; 7. Szablony dokumentów obejmujące przygotowanie i uzgodnienie co najmniej następujących szablonów dokumentów: Lista produktów (modułów), Notatki ze spotkania, Raport z punktu kontrolnego, Raport końcowy etapu, Raport końcowy projektu. OA-XVI Str. 25 z 30

26 PowyŜsze produkty przedstawiają minimalny zakres wymaganej dokumentacji zarządczej projektu ze strony Wykonawcy. Wszystkie powyŝsze produkty powinny być przygotowane zgodnie z zaleceniami metodyki PRINCE2 lub równowaŝnej. Wykonawca zobowiązany będzie do utrzymania i bieŝącej aktualizacji dokumentacji zarządczej w trakcie całego okresu trwania umowy zgodnie z zaleceniami metodyki PRINCE 2 lub równowaŝnej Zadanie II analiza wymagań i projekt techniczny W ramach Zadania II Wykonawca przedstawi funkcje i projekt techniczny Platformy eas, a w szczególności: 1. Opis architektury Platformy eas. 2. Wymagania funkcjonalne, obejmujące, co najmniej: a) przedstawienie szczegółowej listy procesów związanych ze śledzeniem stanu sprawy, udostępnianiem akt sprawy, jak i czynności wykonywane przez uŝytkowników/pracowników i administratorów Platformy eas wraz z opisem, b) opis przypadków uŝycia Platformy eas oraz opracowanie listy testów akceptacyjnych, w tym dla kaŝdego z przypadków uŝycia, c) specyfikację struktury bazy danych Platformy eas, d) przedstawienie potrzeb w zakresie wykorzystania zasobów serwerowych Zamawiającego na potrzeby środowiska testowego i produkcyjnego oraz przedstawienie potrzeb w zakresie dostępu sieciowego do ww. zasobów, 3. Projekt techniczny modułu wymiany danych pomiędzy eas a EOD wraz z propozycją niezbędnych zmian funkcjonalnych w systemach EOD, które naleŝy wykonać w celu uruchomienia ich współpracy z Platformą eas. 4. Projekt techniczny modułu współdziałania z platformą epuap. 5. Szczegółową specyfikację wymagań związanych z zapewnieniem bezpieczeństwa Platformy eas obejmującą, co najmniej: a) zabezpieczenie przed nieuprawnionym dostępem do danych przetwarzanych na Platformie eas, b) zabezpieczenie przed nieuprawnioną zmianą, c) zabezpieczenie przed utratą danych, d) ochronę danych osobowych. 6. Szczegółową specyfikację narzędzi programowych, w tym w szczególności: a) system operacyjny, OA-XVI Str. 26 z 30

27 b) system zarządzania bazami danych, c) oprogramowanie portalowe, d) oprogramowanie wykorzystywane do wykonania Platformy eas, testów, e) inne oprogramowanie narzędziowe, NaleŜy wyspecyfikować niezbędne licencje oraz sposoby ich licencjonowania. Wynikiem zadania będzie projekt techniczny Platformy eas stanowiący podstawę wykonania Platformy oraz raport z wykonania zadania. Opracowane w ramach zadania produkty stanowić będą załączniki do wyŝej wymienionego raportu ZADANIE III WYKONANIE WERSJI PODSTAWOWEJ Zadanie obejmuje: 1. Wykonanie i wdroŝenie wersji podstawowej Platformy eas (w zakresie uzgodnionym w ramach Zadania II). 2. Wykonanie dokumentacji wersji podstawowej Platformy eas: a) dla pracowników obsługujących Platformę eas, b) dla uŝytkowników korzystających z Platformy eas, c) dla administratorów Platformy eas, d) techniczną oprogramowania Platformy eas, e) techniczną komunikacji eas z platformą epuap, f) techniczną komunikacji eas z systemami EOD, zgodnie z pkt 5.9. Wymagania dot. dokumentacji. 3. Przygotowanie szczegółowych scenariuszy testów akceptacyjnych dla wersji podstawowej zgodnie z pkt 5.8. Wymagania dot. testów. 4. Wykonanie testów akceptacyjnych dla wersji podstawowej Platformy eas. 5. Opracowanie raportu z testów akceptacyjnych wersji podstawowej Platformy eas. Wynikiem zadania będzie uruchomiona i wdroŝona wersja podstawowa Platformy eas gotowa do przeprowadzenia szkoleń i testów oraz raport z testów akceptacyjnych wersji podstawowej Platformy eas. Wnioski wynikające z raportu stanowić będą materiał do określenia zmian w projekcie technicznym oraz powinny zostać uwzględnione w trakcie wykonania Platformy eas. Opracowane w ramach zadania produkty stanowić będą załączniki do wyŝej wymienionego raportu. OA-XVI Str. 27 z 30