PROJEKT UMOWY. zwaną dalej Zamawiającym a. zwanym dalej Wykonawcą o następującej treści:

Transkrypt

1 PROJEKT UMOWY zawarta dnia. w Rzeszowie pomiędzy: Gminą Miasta Rzeszów Urząd Miasta Rzeszowa, ul. Rynek 1, Rzeszów, NIP: reprezentowaną przez zwaną dalej Zamawiającym a zwanym dalej Wykonawcą o następującej treści: 1 Przedmiotem Umowy jest: 1. dostawa i wdrożenie oprogramowania do zarządzania infrastrukturą danych elektronicznych z modułem archiwizowania dokumentów z wykorzystaniem funkcjonalności OCR w Urzędzie Miasta Rzeszowa i jednostkach organizacyjnych Gminy zwanego w dalszej części Systemem, zintegrowanego z elektroniczną platformą usług administracji publicznej epuap, zintegrowanego z Biuletynem Informacji Publicznej Urzędu Miasta Rzeszowa, zintegrowanego z oprogramowaniem do obsługi usług świadczonych drogą elektroniczną oraz zintegrowanego z oprogramowaniem elektronicznego rejestru dokumentów, oraz zintegrowanego z kompleksowym systemem administracji terenowej; 2. dostawa wraz z konfiguracją systemu poczty elektronicznej; 3. dostarczenie licencji do oprogramowania umożliwiającego tworzenie aktywnych formularzy PDF; 4. przeszkolenie przez Wykonawcę użytkowników wskazanych przez Zamawiającego z zakresu obsługi dostarczonych systemów. 5. Udzielenie asysty technicznej przez okres 18 miesięcy. W ramach asysty technicznej Wykonawca zobowiązany jest do: 1) pomocy i doradztwa w sprawie używania oprogramowania, świadczonej telefonicznie od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy w godzinach 8.00 do 15.00, lub owo lub w wymiarze max. 100 godz. w siedzibie Zamawiającego. 2) aktualizacji Programów wynikającą ze zmiany przepisów prawnych publikowanych w Dzienniku Ustaw lub Monitorze Polskim, bez potrzeby wnioskowania o takie dostosowanie ze strony Zamawiającego, dokonywaną nie później niż w dniu wejścia zmian w życie,

2 3) aktualizacje systemu w celu dostosowania go do nowych wersji przeglądarek, które pojawią się w okresie objętym gwarancją, nie później niż 15 dni roboczych od wydania nowej wersji przeglądarki 4) prawo do otrzymywania, w ramach wynagrodzenia za asystę, kolejnych wydań Programów i związanych z nimi zmian w dokumentacji użytkowej i administratora Szczegółowy opis przedmiotu umowy przedstawia Załącznik 1 2. Przedmiot Umowy zostanie wykonany w terminie: 1) etap I - dostawa licencji na dostarczone systemy do 1 miesiąca od daty podpisania umowy; 2) etap II - wdrożenie dostarczonego oprogramowania do 5 miesięcy od daty podpisania umowy; 3) etap III - przeszkolenie użytkowników do 7 miesięcy od daty podpisania umowy; 4) etap IV udzielenie asysty technicznej na okres 18 miesięcy licząc od dnia podpisania protokołu odbioru końcowego o którym mowa w 4 ust Szczegółowy harmonogram prac związanych z wykonaniem Przedmiotu Umowy przedstawia Załącznik nr 2 do niniejszej Umowy. 4. Wykonawca zobowiązuje się do terminowego wykonania Przedmiotu Umowy. 3 Zamawiający zobowiązuje się do współdziałania z Wykonawcą w stopniu umożliwiającym należyte wykonanie przez Wykonawcę przedmiotu niniejszej Umowy, w szczególności zobowiązuje się do udostępnienia infrastruktury technicznej, w której ma zostać wdrożone Oprogramowanie a także do dostarczenia wszystkich niezbędnych materiałów i informacji własnych koniecznych do wykonania przedmiotu Umowy Prace związane z wykonaniem Przedmiotu Umowy będą wykonywane i odbierane etapami zgodnie z harmonogramem przedstawionym w Załączniku nr 2 do niniejszej Umowy. 2. Procedura odbioru opisana w 4 ust. 3 do ust. 6 będzie wykonywana dla każdego etapu prac wymienionego w Załączniku nr 2 do niniejszej Umowy. 3. Po wykonaniu każdego etapu prac, Wykonawca zgłasza gotowość do odbioru Zamawiającemu.

3 4. Jeżeli Zamawiający uzna, że etap został zakończony to w porozumieniu z Wykonawcą wyznaczy termin odbioru częściowego. Zamawiający dokona odbioru częściowego w ciągu 7 dni, licząc od daty zgłoszenia. Z odbioru częściowego zostanie spisany protokół odbioru częściowego. 5. Jeżeli Zamawiający stwierdzi, że prace nie zostały zakończone lub są wadliwe to odmówi odbioru do czasu zakończenia prac i usunięcia wad. 6. Częściowe odebranie danych robót, nie oznacza końcowego i ostatecznego odbioru prac w tej części. Oznacza to w szczególności, że Zamawiający może żądać usunięcia przez Wykonawcę wszelkich usterek wykrytych lub powstałych w czasie ich prowadzenia a odebranych częściowo, również po odbiorze częściowym a także w ramach końcowego odbioru robót. 7. Strony przewidują odbiór końcowy przedmiotu umowy w zakresie etapów I, II, III po pisemnym zgłoszeniu przez Wykonawcę zakończenia realizacji etapów I, II, III. Zamawiający dokona odbioru końcowego w terminie 14 dni od dnia zgłoszenia. Jeżeli w toku czynności odbiorowych zostaną stwierdzone wady to Zamawiający może odmówić odbioru Na prawidłowe działanie oprogramowania będącego przedmiotem zamówienia Wykonawca udzieli Zamawiającemu 18 miesięcy gwarancji rozpoczynającej się z dniem podpisania protokołu odbioru końcowego o którym mowa w 4 ust W okresie gwarancji Wykonawca zobowiązuje się usunąć błędy zgłoszone na piśmie lub drogą elektroniczną w terminach liczonych od zgłoszenia: 1) 2 dni roboczych (tj. od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy) w przypadku błędów krytycznych uniemożliwiających Zamawiającemu korzystanie z funkcji Programów niezbędnych do bieżącej pracy, 2) 7 dni roboczych w pozostałych przypadkach, 3. Dokonanie przez Zamawiającego lub przez osobę trzecią jakichkolwiek zmian w oprogramowaniu, także jeżeli są one niezbędne z punktu widzenia potrzeb Zamawiającego, powoduje utratę gwarancji na Programy, chyba że Wykonawca wyraził na piśmie pod rygorem nieważności zgodę na dokonanie takich zmian. 4. Wykonawca nie odpowiada za nieprawidłowości działania oprogramowania wynikające z nieprawidłowego administrowania środowiskami systemów operacyjnych i bazy danych Do realizacji przedmiotu niniejszej umowy Wykonawca wyznacza następujące osoby: 1) Konsultant. 2) Deweloper.

4 3) Administrator 4) Projektant. 2. Osobą do kontaktów ze strony Zamawiającego jest: Zamawiający zobowiązuje się wypłacić Wykonawcy wynagrodzenie w wysokości. zł netto ( zł brutto): 1). zł netto ( zł brutto) za Etap I - Dostawa licencji, 2). zł netto ( zł brutto) za Etap II - Wdrożenie, 3). zł netto ( zł brutto) za Etap III - Przeszkolenie użytkowników. 4). zł netto ( zł brutto) w ramach udzielonej asysty technicznej płatne proporcjonalnie w ratach miesięcznych. 2. Wynagrodzenie o którym mowa w ust.1 pkt 1, 2, 3 płatne po odbiorze każdego z etapów w terminie 14 dni od dnia odebrania prawidłowo wystawionej faktury przelewem na rachunek bankowy wskazany w fakturze. 3. Wynagrodzenie o którym mowa w ust.1 pkt 4 płatne będzie w terminie 14 dni licząc od dnia odebrania prawidłowo wystawionej faktury przelewem na rachunek bankowy wskazany w fakturze. Faktura obejmująca asystę techniczną może zostać wystawiona nie wcześniej niż w ostatnim dniu roboczym każdego z miesięcy Zamawiający ma prawo do naliczania kary umownej: 1) w wysokości 0,2 % wynagrodzenia za etap za każdy dzień zwłoki w realizacji etapu, 2) w wysokości 10% całości wynagrodzenia w przypadku odstąpienia od Umowy przez którąkolwiek ze stron z przyczyn, za które odpowiedzialność ponosi Wykonawca 3) za opóźnienie w przesyłaniu poprawki usuwającej błąd - w wysokości 30,00 zł za każdy dzień opóźnienia, licząc od dnia, o którym mowa w 5 ust. 2. 4) za opóźnienie w przesyłaniu aktualizacji oprogramowania związanej ze zmianą przepisów prawnych - w wysokości 30,00zł za każdy dzień opóźnienia licząc od dnia następnego, o którym mowa w 1 ust. 5 pkt. 2. 5) za opóźnienie w przesyłaniu aktualizacji oprogramowania związanej z wydaniem nowej wersji przeglądarki internetowej w wysokości 30,00zł za każdy dzień opóźnienia licząc od dnia o którym mowa w 1 ust. 5 pkt 3.

5 2. Kwota o której mowa w ust.1 pkt 3, 4 i 5 może zostać potrącona przez Zamawiającego z wynagrodzenia przysługującego Wykonawcy, o którym mowa w 7 ust. 1 pkt Suma kar umownych należnych od Wykonawcy nie może przekroczyć 25 % wynagrodzenia. 4. Jeżeli szkody przekroczą kary umowne, Zamawiający może dochodzić na zasadach określonych Kodeksem Cywilnym odszkodowania uzupełniającego przewyższającego kary umowne, do wysokości poniesionej szkody nieprzekraczającego 100% wartości wynagrodzenia łącznego, o którym mowa w 7 niniejszej umowy Strony zobowiązują się do bezwzględnego zachowania tajemnicy państwowej, służbowej i handlowej, w której posiadanie weszły w związku z realizacją niniejszej umowy 2. Wykonawca oświadcza, że przysługują mu prawa autorskie do oprogramowania. 3. Zamawiającemu nie wolno ujawniać osobom trzecim otrzymanego oprogramowania, w całości lub części, ani ich dokumentacji o ile obowiązek taki nie wynika z przepisów prawa. Zamawiający zobowiązuje się nie wynajmować, nie oddawać w leasing, nie udzielać licencji, nie prowadzić dystrybucji, nie dokonywać transferu, nie odstępować nieodpłatnie, nie kopiować, nie reprodukować, nie modyfikować, bądź nie dzielić się oprogramowaniem lub jego dokumentacją, ani w inny sposób nie udostępniać ich osobom trzecim na podstawie jakiegokolwiek stosunku prawnego lub faktycznego. 4. Wykonawca zobowiązuje się do zachowania wymogów ustawy o ochronie danych osobowych. 5. Zamawiający zobowiązuje się do wykorzystywania oprogramowania wyłącznie na własnej konfiguracji sprzętowej przy zachowaniu warunków wynikających z posiadanych licencji. Zamawiający zobowiązuje się przedsięwziąć wszelkie kroki w celu zapobiegania jakimkolwiek naruszeniom przysługujących Wykonawcy praw autorskich Strony dopuszczają dokonanie zmian w zakresie terminu wykonania przedmiotu umowy w przypadku dokonania zmian statutu Miasta Rzeszowa, struktury organizacyjnej, regulaminu organizacyjnego Urzędu Miasta Rzeszowa lub regulaminów organizacyjnych jednostek organizacyjnych Gminy. 2. Wszelkie zmiany niniejszej Umowy wymagają zgodnego oświadczenia woli stron w formie pisemnej pod rygorem nieważności.

6 11 W sprawach nieuregulowanych niniejszą umową mają zastosowanie odpowiednie przepisy prawa. 12 Umowę sporządzono w dwóch jednobrzmiących egzemplarzach po jednym dla każdej ze stron.

7 Załącznik nr 1. Szczegółowy opis przedmiotu umowy Przedmiotem umowy jest: I. Dostawa, implementacja i wdrożenie oprogramowania do zarządzania infrastrukturą danych elektronicznych z modułem archiwizowania dokumentów z wykorzystaniem funkcjonalności OCR w Urzędzie Miasta Rzeszowa i jednostkach organizacyjnych Gminy, zwanego w dalszej części Systemem, zintegrowanego z elektroniczną platformą usług administracji publicznej epuap, zintegrowanego z Biuletynem Informacji Publicznej Urzędu Miasta Rzeszowa, zintegrowanego z oprogramowaniem do obsługi usług świadczonych drogą elektroniczną oraz zintegrowanego z oprogramowaniem elektronicznego rejestru dokumentów, oraz zintegrowanego z kompleksowym systemem administracji terenowej II. Dostawa wraz z konfiguracją systemu poczty elektronicznej. III. Dostarczenie licencji do programu do edycji aktywnych formularzy PDF. IV. Udzielenie asysty technicznej na okres 18 miesięcy 1. W ramach realizacji umowy Wykonawca zobowiązuje się do: 1) przeprowadzenia szczegółowej analizy wymagań, sporządzenia projektu funkcjonalnego oraz projektu technicznego (w tym projektów interfejsów użytkownika), 2) dostawy, implementacji i wdrożenia oprogramowania, 3) udzielenia Licencji do użytkowania Systemu przez Urząd Miasta Rzeszowa, Gminę Miasto Rzeszów i jednostki organizacyjne Gminy, 4) skonfigurowania infrastruktury technicznej (sieciowej i serwerowej) tak, aby spełniała wszystkie wymagania dostarczonego systemu oraz wymagania systemów zewnętrznych, z którymi dostarczony system musi być zintegrowany (elektroniczną platformą usług administracji publicznej epuap, Biuletyn Informacji Publicznej, oprogramowaniem do obsługi usług świadczonych drogą elektroniczną, mechanizmami uwierzytelniania użytkowników i infrastrukturą wykorzystywaną do podpisu elektronicznego) 5) dostarczenia oraz instalacji i uruchomienia w siedzibie Zamawiającego niezbędnego oprogramowania systemowego, aplikacyjnego i bazodanowego, w szczególności: a) serwerowych systemów operacyjnych stanowiących środowisko, w którym będzie uruchomiony zamawiany System, b) platformy bazodanowej wymaganej przez oferowany System, c) serwera aplikacji i serwera WWW, d) systemu poczty elektronicznej e) oprogramowania aplikacji składających się na oferowany System, f) zintegrowanie Systemu z elektroniczną platformą usług administracji publicznej epuap, g) zintegrowanie Systemu z Biuletynem Informacji Publicznej Urzędu Miasta Rzeszowa, h) zintegrowanie Systemu z oprogramowaniem do obsługi usług świadczonych drogą elektroniczną i) zintegrowanie Systemu z oprogramowaniem elektronicznego rejestru dokumentów j) zintegrowanie Systemu z kompleksowym systemem administracji terenowej k) zaimplementowanie mechanizmów bezpieczeństwa (uwierzytelniania użytkowników) umożliwiających wykorzystanie infrastruktury programowej i sprzętowej Urzędu Miasta Rzeszowa i jednostek organizacyjnych Gminy,

8 tj. czytników kart elektronicznych CryptoTech SCR 3310 oraz kart kryptograficznych CryptoCard multisign w oparciu interfejs PKCS#11. l) zaimplementowanie mechanizmów podpisu elektronicznego umożliwiających wykorzystanie infrastruktury programowej i sprzętowej Urzędu Miasta Rzeszowa i jednostek organizacyjnych Gminy, tj. czytników kart elektronicznych CryptoTech SCR 3310 oraz kart kryptograficznych CryptoCard multisign w oparciu interfejs PKCS#11. m) aplikacji do edycji aktywnych formularzy PDF. 6) dostarczenie dokumentacji użytkownika, 7) przeprowadzenie szkoleń funkcjonalnych z zakresu użytkowania systemu, 8) przeprowadzenie szkoleń dla Administratorów w zakresie administrowania systemem, 9) dostarczenie dokumentacji technicznej sporządzonej w notacji UML lub równoważnej i obejmującej cały obszar funkcjonalny systemu. Wymagane diagramy w dokumentacji to: Diagram przypadków użycia wraz z ustrukturyzowanymi scenariuszami głównymi i alternatywnymi dla przypadków użycia, diagramy klas, diagramy sekwencji i diagramy przejść stanów. Dokumentacja bazy danych musi zawierać diagram w notacji ERD lub równoważny z pełnym opisem atrybutów, funkcji i procedur. Dokumentacja kodu musi zawierać specyfikację wszystkich klas z listą metod i atrybutów oraz diagram wywołań funkcji pomiędzy klasami, 2. Dostarczony System musi spełniać następujące wymagania funkcjonalne i techniczne: 1) każdy użytkownik musi mieć dostęp do swojego profilu i może samodzielnie wprowadzać swoje dane oraz zmieniać hasło, 2) system musi mieć możliwość uwierzytelniania użytkowników przy pomocy bezpiecznego podpisu elektronicznego weryfikowanego przy pomocy kwalifikowanego certyfikatu, zarządzanego zgodnie z wymaganiami ustawy z 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz.1450) oraz towarzyszącymi jej rozporządzeniami. Mechanizm uwierzytelniania użytkowników poprzez kwalifikowane certyfikaty musi współpracować z kartą CryptoCard multisign działającą w oparciu o system operacyjny SetCOS w wersji ) System musi posiadać możliwość przypisywania kwalifikowanych certyfikatów do kont użytkowników, 4) system musi być przyjazny dla użytkowników tzn. charakteryzować się łatwością i intuicyjnością obsługi oprogramowania między innymi poprzez umożliwienie dokonywania wszelkich zmian struktury wprowadzanych danych poprzez mechanizmy Drag & Drop (Przeciągnij i upuść), 5) interfejs użytkownika systemu musi działać w przeglądarce internetowej (Internet Explorer, Mozilla Firefox, Chrome, Opera) bez żadnego przeładowania strony tak, aby zapewnić wysoki poziom interaktywności i komfortu pracy użytkownika z aplikacją, 6) system musi być w polskiej wersji językowej i obsługiwać polskojęzyczne formaty wartości (daty, liczby, waluty, sortowanie itp.), 7) system będzie umożliwiał prowadzenie ewidencji wielopoziomowej struktury organizacyjnej Urzędu Miasta Rzeszowa oraz oddzielnych jednostek organizacyjnych. Edycja ww. struktury będzie intuicyjna dla użytkownika w postaci wielopoziomowej struktury drzewiastej i zapewni dynamiczne doczytywanie elementów podrzędnych bez konieczności odświeżania/przeładowania strony. Wyżej wymieniona struktura musi być zintegrowana i na bieżąco aktualizowana ze wszystkimi zmianami struktury dokonywanymi w Biuletynie Informacji Publicznej,

9 oprogramowaniu do obsługi usług świadczonych drogą elektroniczną oraz oprogramowaniem elektronicznego rejestru dokumentów. 8) System musi umożliwiać pobieranie dokumentów elektronicznych wraz z załącznikami (dowolne pliki), które zostały złożone drogą elektroniczną. 9) System musi umożliwiać wysyłanie odpowiedzi wraz z załącznikami (dowolne pliki) do osób, które złożyły dokumenty drogą elektroniczną przez Biuletyn Informacji Publicznej Urzędu Miasta Rzeszowa. 10) System musi umożliwiać pobieranie elektronicznych dokumentów, które zostały złożone drogą elektroniczną przez platformę usług administracji publicznej epuap 11) System musi umożliwiać wysyłanie odpowiedzi (dokumentów) wraz z załącznikami (dowolne pliki) do osób, które złożyły dokumenty drogą elektroniczną przez zaufany profil w platformie usług administracji publicznej epuap. Odpowiedzi muszą być przesyłane bezpośrednio do skrzynki odbiorczej zaufanego profilu w systemie epuap. 12) System musi umożliwiać wysyłanie pism wraz z załącznikami (dowolne pliki) poprzez platformę epuap. 13) System musi umożliwiać podpisywanie wysyłanych dokumentów przy pomocy bezpiecznego podpisu elektronicznego weryfikowanego przy pomocy kwalifikowanego certyfikatu zarządzanego zgodnie z wymaganiami ustawy z 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz.1450) oraz towarzyszącymi jej rozporządzeniami. Mechanizm uwierzytelniania użytkowników poprzez kwalifikowane certyfikaty musi współpracować z kartą CryptoCard multisign działającą w oparciu o system operacyjny SetCOS w wersji posiadany przez Zamawiającego. 14) System musi umożliwiać weryfikację podpisu elektronicznego oraz profilu zaufanego, wiadomości pochodzących z epuap. 15) System obsługi epuap musi umożliwiać wybranie trybu wysyłania UPD / UPP (Urzędowe Poświadczenie Odbioru / Urzędowe Poświadczenie Przedłożenia). 16) System obsługi epuap musi umożliwiać odczyt UPP i UPD. 17) System musi umożliwiać pobieranie dokumentów z bieżącego i archiwalnego repozytorium plików i dokumentów oprogramowania do obsługi usług świadczonych drogą elektroniczną przez Urząd Miasta Rzeszowa. 18) System musi umożliwiać drukowanie odebranych i wysłanych dokumentów oraz korespondencji seryjnej w tym kopert (np. dokument z jedną sygnaturą i kilkuset różnymi odbiorcami). 19) System musi umożliwiać przesyłanie dokumentów, które wpłynęły drogą elektroniczną pomiędzy użytkownikami. W każdym momencie obsługi wniosku system musi mieć możliwość poinformowania użytkownika o bieżącym statusie wniosku i postępie w obsłudze sprawy, której wniosek dotyczy. 20) System musi zapewniać pełną historyzację i wersjonowanie elektronicznych dokumentów wraz z adnotacjami wszystkich użytkowników oraz odpowiedzi na wnioski i załączone w nich dokumenty. 21) System musi umożliwiać nadawanie statusów dla wniosków, dokumentów i spraw. 22) Wszystkie zdarzenia w systemie muszą być rejestrowane w rejestrze zmian systemu i muszą być zintegrowane z rejestrem zmian Biuletynu Informacji Publicznej. 23) System musi posiadać funkcjonalność tworzenia, edycji profili i nadawania uprawnień użytkownikom do wysyłania odpowiedzi wraz z załącznikami na wnioski, sprawy i dokumenty. 24) System musi umożliwiać budowę archiwum w strukturze drzewiastej. 25) System musi posiadać moduł elektronicznego archiwizowania dokumentów

10 a) Zasady bezpieczeństwa Systemu oraz Instrukcja Bezpieczeństwa Systemu powinna określać cel, zakres, sposób przetwarzania informacji ogólnodostępnych i prawnie chronionych, w tym danych osobowych, wymogi ochrony tych informacji oraz środki techniczne i organizacyjne zapewniające ochronę informacji przetwarzanych w Systemie zgodnie z wymogami: i. rozporządzenia 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 r. Nr 100, poz.1024); ii. Polskiej Normy PN-ISO/IEC (Technika informatyczna, Techniki bezpieczeństwa, Praktyczne zasady zarządzania bezpieczeństwem informacji) lub równoważnej. b) Bezpieczeństwem informacji, w zakresie ochrony danych osobowych Systemu, musi zarządzać Administrator Bezpieczeństwa Informacji (ABI) c) Stabilność i ciągłość działania Systemu musi być poparta certyfikatem na zgodność z międzynarodową normą ISO 22301: Zarządzanie ciągłością działania lub równoważną. 26) System musi posiadać wyodrębniony moduł centralnego rejestru umów. Dostępność do funkcjonalności modułu musi być dostępna dla użytkowników wszystkich komórek organizacyjnych zgodnie z nadanymi przez administratora uprawnieniami. Repozytorium modułu musi być automatycznie przenoszone do systemu elektronicznego archiwum dokumentów oraz elektronicznego rejestru pism. Centralny rejestr umów powinien mieć także możliwość: a) podpięcia skanu umowy, aneksu np. w formacie pdf odstąpienia od umowy, w taki sposób, aby każda osoba po zalogowaniu mogła mieć dostępu do ww. dokumentu. b) wyszukiwania umów według dat zawarcia, podmiotu z którym zawarto umowę, rodzaju zamówienia, trybu zawarcia umowy, komórki odpowiedzialnej za realizację umowy, źródła finansowania, zawartych aneksów i odstąpień od umowy. Centralny rejestr umów powinien zawierać pola: Numer umowy Data zawarcia umowy Podmiot, z którym zawarto umowę nazwa i adres Nazwa zamówienia / Przedmiot zamówienia Rodzaj zamówienia: dostawa, usługa, robota budowlana Tryb zawarcia umowy w trybie ustawy Pzp np.: przetarg nieograniczony, przetarg ograniczony, licytacja elektroniczna, zamówienie z wolnej ręki, zapytanie o cenę, negocjacje bez ogłoszenia, negocjacje z ogłoszeniem poza ustawą Pzp. Okres obowiązywania umowy / termin realizacji umowy Wartość umowy netto / brutto Symbol komórki organizacyjnej Urzędu odpowiedzialnej za realizacje umowy Aneks do umowy nr i data zawarcia Odstąpienie od umowy data odstąpienia Uwagi / finansowanie ze źródeł zewnętrznych Skan umowy / aneksu / odstąpienia od umowy (plik pdf)

11 Data wpływu oryginału umowy / aneksu 27) System musi posiadać moduł obsługi Biura Rady Miasta Rzeszowa posiadający następujące cechy: a) baza użytkowników z rozbudowanym systemem uprawnień, nadawanych przez administratora, b) umożliwienie zdefiniowania grup użytkowników przez administratora np.: radni, komisje; c) historia zdarzeń systemowych z możliwością filtrowania czasu, osoby i rodzaju zdarzenia; d) możliwość zarządzania danymi w systemie z uwzględnieniem filtra kadencji (kadencja bieżąca, dane archiwalnych kadencji); e) zarządzanie słownikami danych wykorzystywanych w systemie np.: radni, komisje, departamenty, wydziały, osoby, sesje etc. f) kreator ogłoszeń posiedzeń komisji; g) kreator porządku obrad; h) kreator ogłoszeń dla logujących się użytkowników; i) możliwość automatycznego eksportu danych (uchwał/zarządzeń) wraz z informacją o przebiegu głosowania do Biuletynu Informacji Publicznej Miasta Rzeszowa; j) możliwość wyszukiwania podjętych uchwał. k) możliwość automatycznego eksportu danych do Systemu elektronicznego archiwum dokumentów, l) możliwość stosowania dowolnej ilości załączników (tekstowych oraz graficznych) dla każdego dokumentu będącego w trakcie przygotowania; m) wprowadzenie możliwości ustawienia statusu wykonania dla każdego dokumentu/projektu/uchwały; n) możliwość wprowadzenia terminu ważności dokumentu; o) możliwość przesłania powiadomienia na (zdefiniowany w polu informacji o użytkowniku) lub skrzynkę prywatną użytkownika (bądź ich grupy np. całej komisji/do wiadomości wszystkich) w obrębie systemu; p) możliwość przesyłania wiadomości prywatnych w obrębie systemu pomiędzy użytkownikami; q) umieszczenie kalendarza z możliwością zaznaczenia terminów spotkań/posiedzeń/sesji etc. i. kalendarz powinien być w pełni edytowalny przez moderatora/administratora, ii. powinien posiadać podział na komisje, iii. terminarze dla poszczególnych komisji powinny być widoczne tylko dla ich członków, przewodniczącego rady miasta oraz jego zastępców); r) Sekcję publiczną w postaci portalu dla radnych zawierający sekcje: i. dokumenty na najbliższą sesję, ii. porządek obrad, iii. dokumenty uchwał w toku z podziałem na komisje, iv. bazę interpelacji, v. terminy posiedzeń komisji oraz archiwum zawierające dokumenty z poprzednich sesji, a także takie, które z różnych powodów nie weszły do obrad sesji, ale zostały dodane do archiwum 28) System musi posiadać funkcjonalność repozytorium dokumentów elektronicznych w formie chmury spełniającą następuje wymagania: a) musi realizować dostęp do chmury (dokumentów elektronicznych) dla wszystkich użytkowników,

12 b) musi umożliwiać prowadzenie bazy dokumentów, kontaktów i kalendarzy, c) dostęp do plików musi być zapewniony przez: i. przeglądarkę internetową, ii. Protokół WebDAV d) Musi posiadać możliwość zainstalowania oprogramowania klienckiego dla następujących systemów: i. Windows ii. Mac OS X iii. Linux iv. Android v. ios e) Musi posiadać możliwość wymiany danych z urządzeniami zewnętrznymi przez protokoły caldav i carddav. f) Musi posiadać funkcjonalność wersjonowania dokumentów, g) Musi pozwalać na szyfrowanie całych zbiorów dokumentów dla użytkownika. 29) System musi zapewnić kontrolę nad dokumentami poprzez stworzenie grup użytkowników z określonymi prawami dostępu do konkretnych zasobów 30) System zapewni pełne bezpieczeństwo przechowywanych informacji (dostęp do dokumentów chroniony jest rozbudowanymi funkcjami, skutecznie zapobiegającymi przed nieuprawnionym ich użyciem) 31) System musi zapewniać stały dostęp do dokumentów, w tym również do takich, które zostały już zarchiwizowane w Systemie 32) System musi umożliwiać integrację z pocztą elektroniczną pozwalającą na automatyczne pobieranie wiadomości z oferowanego serwera pocztowego opisanego w dalszej części. 33) System musi zostać wyposażony w dokumentację użytkownika końcowego, techniczną i administratora 34) System musi mieć zaimplementowany mechanizm ochrony przed całkowitym usunięciem dokumentów przez osoby inne niż Administrator Systemu. Usunięte przez użytkownika dokumenty powinny pozostać w buforze dokumentów do usunięcia 35) System musi posiadać funkcjonalność OCR (rozpoznający język polski pismo drukowane) 36) OCR musi umożliwiać rozpoznawanie tekstu wg określanych przez administratora systemu harmonogramów (określenie godzin uruchamiania i zakończenia przetwarzania OCR) 37) System musi umożliwiać sprawne wyszukiwanie pełnotekstowe wśród dokumentów wcześniej przetworzonych przez OCR 38) System musi umożliwiać analizę OCR dokumentów graficznych 39) Dokumenty muszą być trzymane w systemie plików w taki sposób, aby do dokumentów niejawnych nie było dostępu z poziomu systemu operacyjnego 40) System musi posiadać możliwość zabezpieczenia wybranych dokumentów (np. szyfrowanie dokumentów w repozytorium) 41) System musi uniemożliwiać wprowadzanie i modyfikację danych w sposób anonimowy. 42) Architektura systemu powinna zakładać jedną centralną bazę danych, która będzie przetwarzana w głównej siedzibie Zamawiającego. 43) System musi umożliwiać wersjonowanie dokumentów 44) System musi umożliwiać cofanie aktualnej wersji do wersji historycznej 45) System musi umożliwiać zastosowanie XML, jako standardu wymiany danych

13 46) System musi umożliwiać jednoczesny dostępu do danych przez wielu użytkowników, z ochroną tych danych przed utratą spójności lub zniszczeniem 47) System musi posiadać zabezpieczenia danych przed niepowołanym dostępem, dzięki możliwości przydzielania zakresu uprawnień poszczególnym użytkownikom, grupom użytkowników lub zewnętrznym systemom 48) System musi współpracować z eksploatowanym przez Zamawiającego pakietem Office na poziomie przygotowania i edycji dokumentów. System ma umożliwić otwarcie dokumentu w Office z poziomu Systemu 49) System musi umożliwić tworzenie, przeglądanie, edycję, usuwanie i drukowanie utworzonych dokumentów poprzez uprawnione osoby 50) System musi umożliwiać szybką i sprawną aktualizację systemu z zachowaniem środków bezpieczeństwa przed utratą danych 51) System musi posiadać mechanizm zapewniający, że podczas aktualizacji oprogramowania nie zostaną utracone żadne zgromadzone dane oraz nie dojdzie do ich uszkodzenia bądź przekłamania nawet w wówczas, gdy aktualizacja przebiegnie błędnie lub wystąpi awaria 52) System musi charakteryzować się otwartą architekturą, zapewniającą możliwość integracji z innymi bazami danych funkcjonującymi w ramach działalności Zamawiającego (min. poprzez ODBC, integrację plikową XML). 53) System musi umożliwiać tworzenie kopii zapasowych z zadanym harmonogramem w razie konieczności przywrócenia danych systemowych. 54) System musi prowadzić ewidencję użytkowników systemowych 55) Interfejs dla administratora Systemu powinien umożliwiać administrowanie min. 3 użytkownikom jednocześnie. 56) System powinien posiadać moduł komunikacyjno - integracyjny. 57) System powinien pracować w oparciu o dostarczoną wraz z systemem bazę danych. Wymaga się dostarczenie bazy danych pracującej na serwerze wyposażonym w procesor 4-rdzeniowy. System bazy danych musi spełniać następujące wymagania: Kompresja kopii zapasowych: System zarządzania relacyjną bazą danych (RDBMS) powinien pozwalać na kompresję kopii zapasowej danych (backup) od razu w czasie jej tworzenia. Powinna to być cecha RDBMS niezależna od systemu operacyjnego ani od sprzętowego rozwiązania archiwizacji danych. Możliwość zastosowania reguł bezpieczeństwa obowiązujących w przedsiębiorstwie: Wsparcie dla zdefiniowanej w przedsiębiorstwie polityki bezpieczeństwa (np. automatyczne wymuszanie zmiany haseł użytkowników lub zastosowanie mechanizmu weryfikacji dostatecznego poziomu komplikacji haseł wprowadzanych przez użytkowników). Możliwość definiowania zasad administracyjnych dla serwera lub grupy serwerów: System RDBMS powinien mieć możliwość automatyzacji zadań administracyjnych przez definiowanie reguł wymuszanych potem przez system. Przykłady takich reguł: - uniemożliwienie użytkownikom tworzenia obiektów (np. tabel, procedur, baz danych, widoków) o zdefiniowanych przez administratora nazwach lub ich fragmentach. Powinna być możliwa rejestracja i raportowanie niezgodności ze wskazanymi regułami działającego systemu bez wpływu na jego funkcjonalność. Rejestrowanie zdarzeń silnika bazy danych w czasie rzeczywistym: System RDBMS powinien pozwalać na definiowanie rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych bez ujemnego wpływu na wydajność rozwiązania. Przykłady takich zdarzeń to:

14 - odczyt lub zapis danych na dysku dla wyszczególnionego zapytania (w celu wychwytywania zapytań znacząco obciążających system) -wykonanie zapytania lub procedury trwające dłużej niż zdefiniowany czas (wychwytywanie długo trwających zapytań lub procedur) - para zdarzeń zablokowanie/zwolnienie blokady na obiekcie bazy takim jak np. tabela (w celu wychwytywania długotrwałych blokad obiektów bazy) Rejestracja zdarzeń powinna pozwalać na selektywne ich wychwytywanie (rejestrowanie tylko zdarzeń spełniających zdefiniowane warunki filtrujące, np. dotyczących tylko wskazanego obiektu) Zarządzanie serwerem za pomocą skryptów: System RDBMS powinien udostępniać mechanizm zarządzania silnikiem bazy danych za pomocą skryptów administracyjnych, które pozwolą zautomatyzować rutynowe czynności związane z zarządzaniem serwerem. Wysoka dostępność: System RDBMS powinien posiadać mechanizm pozwalający na duplikację bazy danych między dwiema lokalizacjami (podstawowa i zapasowa) przy zachowaniu następujących cech: - bez specjalnego sprzętu (rozwiązanie tylko programowe oparte o sam RDBMS) - niezawodne powielanie danych w czasie rzeczywistym (potwierdzone transakcje bazodanowe) - klienci bazy danych automatycznie korzystają z bazy zapasowej w przypadku awarii bazy podstawowej bez zmian w aplikacjach - czas przełączenia na system zapasowy poniżej 10 sekund. System RDBMS powinien również umożliwiać tworzenie klastrów niezawodnościowych. Możliwość automatycznej aktualizacji systemu: System RDBMS powinien umożliwiać automatyczne ściąganie i instalację wszelkich poprawek (redukowania zagrożeń powodowanych przez znane luki w zabezpieczeniach oprogramowania). Definiowanie nowych typów danych w RDBMS: System RDBMS powinien umożliwiać definiowanie nowych typów danych wraz z definicją specyficznej dla tych typów danych logiki operacji. Logika operacji nowego typu danych powinna być implementowana w zaproponowanym przez Dostawcę języku programowania. Nowe typy danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji. Wsparcie dla technologii XML: System RDBMS powinien udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. W szczególności powinien: - udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli - udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD - udostępniać język zapytań do struktur XML - udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie i modyfikację zawartości struktur XML) - udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań Obsługa błędów w kodzie zapytań: Język zapytań i procedur w systemie RDBMS powinien umożliwiać zastosowanie mechanizmu przechwytywania błędów wykonania procedury (na zasadzie bloku instrukcji TRY/CATCH) tak jak w klasycznych językach programowania.

15 Możliwość tworzenia rekursywnych zapytań do bazy danych: System RDBMS powinien udostępniać wbudowany mechanizm umożlwiający tworzenie rekursywnych zapytań do bazy danych bez potrzeby pisania specjalnych procedur i wywoływania ich w sposób rekurencyjny. Dedykowana sesja administracyjna: System RDBMS powinien pozwalać na zdalne połączenie sesji administratora systemu bazy danych w sposób niezależny od normalnych sesji klientów. Wsparcie dla danych przestrzennych: System RDBMS powinien zapewniać wsparcie dla geometrycznych i geograficznych typów danych pozwalających w prosty sposób przechowywać i analizować informacje o lokalizacji obiektów, dróg i innych punktów orientacyjnych zlokalizowanych na kuli ziemskiej, a w szczególności: - zapewniać możliwość wykorzystywania szerokości i długości geograficznej do opisu lokalizacji obiektów, - powinien oferować wiele metod, które pozwalają na łatwe operowanie kształtami czy bryłami, testowanie ich wzajemnego ułożenia w układach współrzędnych oraz dokonywanie obliczeń takich wielkości, jak pola figur, odległości do punktu na linii, itp. - obsługa geometrycznych i geograficznych typów danych powinna być dostępna z poziomu języka zapytań do systemu RDBMS, - typy danych geograficznych powinny być konstruowane na podstawie obiektów wektorowych, określonych w formacie Well-Known Text (WKT) lub Well-Known Binary (WKB), (powinny być to m.in. takie typy obiektów jak: lokalizacja (punkt), seria punktów, seria punktów połączonych linią, zestaw wielokątów, itp.), Raportowanie zależności między obiektami: System RDBMS powinien udostępniać obiekty systemowe do raportowania zależności między obiektami baz danych. Mechanizm ten powinien umożliwiać m.in. uzyskanie informacji o referencjach między obiektami, czyli które obiekty bazy danych odwołują się do innych obiektów. Mechanizm blokowania planów wykonania zapytań do bazy danych: System RDBMS powinien udostępniać mechanizm pozwalający na zablokowanie planu wykonania zapytania przez silnik bazy danych (w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam sposób). Efektywne zarządzanie pustymi wartościami w bazie danych: System RDBMS powinien efektywnie zarządzać pustymi wartościami przechowywanymi w bazie danych (NULL). W szczególności puste wartości wprowadzone do bazy danych powinny zajmować minimalny obszar pamięci. System transformacji danych: System powinien posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to powinno pozwalać na przygotowanie definicji transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora. Transformacje powinny posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom Powinna być także zapewniona możliwość tworzenia własnych transformacji. Środowisko tworzenia transformacji danych powinno udostępniać m.in. - mechanizm debuggowania tworzonego rozwiązania, - mechanizm stawiania pułapek (breakpoints), - mechanizm logowania do pliku wykonywanych przez transformację operacji, - możliwość wznowienia wykonania transformacji od punktu, w którym przerwano jej wykonanie (np. w wyniku pojawienia się błędu),

16 - możliwość cofania i ponawiania wprowadzonych przez użytkownika zmian podczas edycji transformacji (funkcja undo/redo) - mechanizm analizy przetwarzanych danych (możliwość podglądu rekordów przetwarzanych w strumieniu danych oraz tworzenia statystyk, np. histogram wartości w przetwarzanych kolumnach tabeli), - mechanizm automatyzacji publikowania utworzonych transformacji na serwerze bazy danych (w szczególności tworzenia wersji instalacyjnej pozwalającej automatyzować proces publikacji na wielu serwerach), - mechanizm tworzenia parametrów zarówno na poziomie poszczególnych pakietów, jak też na poziomie całego projektu, parametry powinny umożliwiać uruchamianie pakietów podrzędnych i przesyłanie do nich wartości parametrów z pakietu nadrzędnego, - mechanizm mapowania kolumn wykorzystujący ich nazwę i typ danych do automatycznego przemapowania kolumn w sytuacji podmiany źródła danych, System analityczny: System powinien posiadać moduł pozwalający na tworzenie rozwiązań służących do analizy danych wielowymiarowych (kostki OLAP). Powinno być możliwe tworzenie: wymiarów, miar. Wymiary powinny mieć możliwość określania dodatkowych atrybutów będących dodatkowymi poziomami agregacji. Powinna być możliwość definiowania hierarchii w obrębie wymiaru. Przykład: wymiar Lokalizacja Geograficzna. Atrybuty: miasto, gmina, województwo. Hierarchia: Województwo->Gmina. System powinien mieć możliwość wyliczania agregacji wartości miar dla zmieniających się elementów (członków) wymiarów i ich atrybutów. Agregacje powinny być składowane w jednym z wybranych modeli (MOLAP wyliczone gotowe agregacje rozłącznie w stosunku do danych źródłowych, ROLAP agregacje wyliczane w trakcie zapytania z danych źródłowych). Pojedyncza baza analityczna powinna mieć możliwość mieszania modeli składowania, np. dane bieżące ROLAP, historyczne MOLAP w sposób przezroczysty dla wykonywanych zapytań. Dodatkowo powinna być dostępna możliwość drążenia danych z kostki do poziomu rekordów szczegółowych z bazy relacyjnych (drill to detail). System powinien pozwalać na dodanie akcji przypisanych do elementów kostek wielowymiarowych (np. pozwalających na przejście użytkownika do raportów kontekstowych lub stron WWW powiązanych z przeglądanym obszarem kostki). System powinien posiadać narzędzie do rejestracji i śledzenia wykonywanych zapytań spójne z analogicznym narzędziem dla systemu RDBMS. System powinien obsługiwać wielojęzykowość (tworzenie obiektów wielowymiarowych w wielu językach w zależności od ustawień na komputerze klienta). System analityczny powinien udostępniać rozwiązania Data Mining ( m.in. algorytmy reguł związków (Association Rules), szeregów czasowych (Time Series), drzew regresji (Regression Trees), sieci neuronowych (Neural Nets) oraz Naive Bayes). Dodatkowo system powinien udostępniać narzędzia do wizualizacji danych z modelu Data Mining oraz język zapytań do odpytywania tych modeli. System powinien pozwalać na dodawanie własnych algorytmów oraz modułów wizualizacji modeli Data Mining. Tworzenie głównych wskaźników wydajności KPI (Key Performance Indicators): System powinien udostępniać użytkownikom możliwość tworzenia wskaźników KPI (Key Performance Indicators) na podstawie danych zgromadzonych w strukturach wielowymiarowych. W szczególności powinien pozwalać na zdefiniowanie takich

17 elementów, jak: wartość aktualna, cel, trend, symbol graficzny wskaźnika w zależności od stosunku wartości aktualnej do celu. System raportowania: System RDBMS powinien posiadać możliwość definiowania i generowania raportów. Narzędzie do tworzenia raportów powinno pozwalać na ich graficzną definicję. Raporty powinny być udostępnianie przez system protokołem HTTP (dostęp klienta za pomocą przeglądarki) bez konieczności stosowania dodatkowego oprogramowania po stronie serwera. Dodatkowo system raportowania powinien obsługiwać: - raporty parametryzowane - cache raportów (generacja raportów bez dostępu do źródła danych) - cache raportów parametryzowanych (generacja raportów bez dostępu do źródła danych z różnymi wartościami parametrów) - współdzielenie predefiniowanych zapytań do źródeł danych - wizualizację danych analitycznych na mapach geograficznych (w tym import map w formacie ESRI Shape File) - możliwość opublikowania elementu raportu (wykresu, tabeli) do współdzielonej biblioteki, z której mogą korzystać inni użytkownicy, tworząc nowy raport ze znajdujących się w bibliotece elementów raportowych - możliwość wizualizacji wskaźników KPI, - możliwość wizualizacji danych w postaci obiektów sparkline Środowisko raportowania powinno być osadzone i administrowane z wykorzystaniem mechanizmu Web Serwisów (Web Services). Wymagane jest generowanie raportów w formatach: XML, PDF, Microsoft Excel (od wersji 1997 do 2010), Microsoft Word (od wersji 1997 do 2010), HTML, TIFF. Dodatkowo raporty powinny być eksportowane w formacie Atom data feeds, które można będzie wykorzystać, jako źródło danych w innych aplikacjach. System RDBMS powinien umożliwiać rozbudowę mechanizmów raportowania m.in. o dodatkowe formaty eksportu danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas generowania raportu (np. nowe funkcje agregujące), mechanizmy zabezpieczeń dostępu do raportów. System RDBMS powinien umożliwiać wysyłkę raportów drogą mailową w wybranym formacie (subskrypcja). System raportowania powinien posiadać rozszerzalną architekturę oraz otwarte interfejsy do osadzania raportów oraz do integrowania rozwiązania z różnorodnymi środowiskami IT. Zintegrowanie narzędzia do zarządzania systemem: System powinien dostarczać zintegrowane narzędzia do zarządzania i konfiguracji wszystkich usług wchodzących w skład systemu (baza relacyjna, usługi analityczne, usługi raportowe, usługi transformacji danych). Narzędzia te powinno udostępniać możliwość tworzenia i wykonywania skryptów zarządzających RDBMS oraz silnikiem baz wielowymiarowych OLAP. Możliwość tworzenia funkcji i procedur w innych językach programowania: System powinien umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania, niż standardowo obsługiwany język zapytań danego RDBMS. System powinien umożliwiać tworzenie w tych językach m.in. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo powinien udostępniać środowisko do debuggowania. 58) System musi umożliwiać monitorowanie zdefiniowanych katalogów sieciowych oraz automatycznego deponowania plików w tych katalogach.

18 59) System musi odczytywać oraz przechowywać, jako wartość identyfikującą ten dokument zawartość kodu kreskowego. 60) System musi obsługiwać kody kreskowe jedno wymiarowe przynajmniej w formatach Code 39, Code 128, EAN ) System musi umożliwiać odczyt kodu kreskowego z dokumentów graficznych w formacie JPG, PNG, BMP oraz pliki wielostronicowe TIFF oraz PDF 62) System musi udostępniać w pełni udokumentowany, interfejs programistyczny API udostępniany poprzez webservice. 63) Interfejs musi udostępniać funkcje pozwalające na zarządzanie przechowywanymi w repozytorium dokumentów (dodanie dokumentów, usuwanie dokumentów, zarządzanie wersjami dokumentów, wyszukiwanie dokumentów po ID oraz danych pełnotekstowych, pobieranie dokumentów). 64) Dostęp do dokumentów repozytorium poprzez interfejs programistyczny powinien być możliwy po podaniu nazwy właściwego użytkownika i hasła. 65) Wszystkie operacje wykonywane z wykorzystaniem interfejsu programistycznego w obrębie repozytorium dokumentów powinny być rejestrowane. 66) System musi zapewniać możliwość pracy z systemem, co najmniej 1500 użytkownikom o dowolnie zdefiniowanych poziomach dostępu, 67) System powinien zapewnić stabilną pracę, co najmniej 100 użytkownikom, wykonującym w tym samym czasie zapytania do motoru bazy danych, 68) aplikacja użytkownika musi posiadać standardowe cechy aplikacji webowej, 69) administracja i zarządzanie użytkownikami musi odbywać się poprzez przeglądarkę internetową, 70) dostęp do aplikacji przez użytkowników powinien odbywać się przy użyciu przeglądarki internetowej, 71) aplikacja użytkownika ma pracować z rozdzielczością ekranu stacji roboczej. Okna i zakładki interfejsu użytkownika muszą skalować się do rozdzielczości, co najmniej 1920x1080px. Cały obszar ekranu musi być wykorzystany przestrzenią roboczą Aplikacji tj. opisy, pola formularzy, okna dialogowe itp. Niedopuszczalne jest, aby po zmaksymalizowaniu okna aplikacji do pełnego ekranu powiększało się wyłącznie okno, a obszar ekranu, który wykorzystywała aplikacja pozostawał niezmienny, 72) System musi umożliwiać tworzenie bieżących i archiwalnych raportów w zakresie dokumentów elektronicznych z uwzględnieniem kryteriów czasu, statusu, osób obsługujących. Raporty musza być generowane do formatu CSV rozdzielany średnikami i formatu HTML 73) System musi umożliwiać autoryzacje, uwierzytelnianie i rozgraniczanie dostępu użytkowników przy wykorzystaniu mechanizmów bezpieczeństwa kwalifikowanych certyfikatów. 74) System musi umożliwić wykorzystanie infrastruktury technicznej i programowej podpisu elektronicznego wykorzystywanego w Urzędzie Miasta Rzeszowa i jednostkach organizacyjnych Gminy, tj. czytników kart elektronicznych CryptoTech SCR 3310 oraz kart kryptograficznych CryptoCard multisign w oparciu interfejs PKCS# Dostarczony system musi zostać zintegrowany z elektroniczną platformą usług administracji publicznej epuap, Biuletynem Informacji Publicznej Urzędu Miasta Rzeszowa, oprogramowaniem do obsługi usług świadczonych drogą elektroniczną wykorzystywanym przez Urząd Miasta Rzeszowa, oraz oprogramowaniem elektronicznego rejestru korespondencji wykorzystywanym przez Urząd Miasta Rzeszowa.

19 Wszystkie interfejsy integracyjne muszą być tak skonfigurowane, że nie będzie możliwości połączenia się z nimi, ani zakłócenia ich pracy z komputerów zlokalizowanych poza siedzibą Zamawiającego. 1) Dostarczony system będzie zintegrowany z Biuletynem Informacji Publicznej Urzędu Miasta Rzeszowa w następującym zakresie i formie: a) konta użytkowników: i. dostęp do Systemu będzie możliwy przy pomocy tych samych loginów i haseł, oraz w oparciu o poziomy dostępu zdefiniowane w Biuletynie Informacji Publicznej Urzędu Miasta Rzeszowa, ii. wszelkie zmiany w profilu użytkownika (takie jak hasło, adres , dane osobowe) będą niezwłocznie synchronizowane pomiędzy dostarczonym Systemem a Biuletynem Informacji Publicznej. Synchronizacja będzie dwustronna, tj. wszelkie zmiany profilu użytkownika w Systemie będą propagowane do BIP, oraz wszelkie zmiany profilu w BIP będą wykrywane przez System, b) struktura wydziałów Urzędu Miasta Rzeszowa oraz struktura jednostek organizacyjnych Gminy, zdefiniowana w Biuletynie Informacji Publicznej Urzędu Miasta Rzeszowa będzie dwustronnie synchronizowana ze strukturą wydziałów we wdrażanym Systemie, c) wszystkie elektroniczne dokumenty wprowadzone do oferowanego Systemu będą zintegrowane z repozytorium plików i aktów prawnych BIP, d) System musi umożliwiać użytkownikom publikację aktualnego i archiwalnego własnego repozytorium dokumentów bezpośrednio w Biuletynie Informacji Publicznej. Użytkownik musi mieć możliwość automatycznego opublikowania każdego dokumentu znajdującego się w repozytorium oferowanego Systemu w zadanym miejscu w strukturze Biuletynu informacji Publicznej. e) wszelkie operacje wykonywane przez użytkowników Systemu, będą rejestrowane w dzienniku zdarzeń Biuletynu Informacji Publicznej Urzędu Miasta Rzeszowa. 2) Dostarczony system będzie zintegrowany z elektroniczną platformą usług administracji publicznej epuap w następującym zakresie i formie: a) system musi posiadać interfejs do komunikacji z platformą usług administracji publicznej epuap umożliwiający uwierzytelnianie w systemie epuap zgodne z rozwiązaniami technologicznymi udostępnianymi przez platformę epuap, b) System musi umożliwiać pobieranie dokumentów elektronicznych przesłanych na skrzynkę w platformie epuap. c) Wszystkie pobierane z epuap dokumenty muszą być automatycznie rejestrowane w: i. dostarczonym Systemie ii. oprogramowaniu elektronicznego rejestru dokumentów wykorzystywanym w Urzędzie Miasta Rzeszowa d) System musi umożliwić wysyłanie odpowiedzi na dokumenty elektroniczne dostarczone ze skrzynek systemu epuap. Odpowiedzi wraz z załącznikami muszą być wysyłane bezpośrednio do skrzynki odbiorczej zaufanego profilu w systemie epuap. Odpowiedzi oraz załączone dokumenty wysyłane na skrzynki profili użytkowników systemu epuap muszą być podpisywane przy pomocy bezpiecznego podpisu elektronicznego weryfikowanego przy pomocy kwalifikowanego certyfikatu zarządzanego zgodnie z wymaganiami ustawy z 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz.1450) oraz towarzyszącymi jej rozporządzeniami. Mechanizm uwierzytelniania użytkowników poprzez kwalifikowane certyfikaty musi współpracować z kartą CryptoCard multisign działającą

20 w oparciu o system operacyjny SetCOS w wersji posiadanymi przez Zamawiającego e) System musi implementować mechanizm WS-Security, w ramach. którego przesłane wiadomości SOAP, stanowiące wywołanie operacji będą podpisane certyfikatem zarejestrowanym w systemie DRACO. W odpowiedziach zwrotnych weryfikowana będzie obecność tokenu, zgodnie z wymaganiami dla interfejsów zewnętrznych systemu epuap, f) System musi weryfikować podpis epuap we wszystkich dokumentach, 3) Dostarczony System będzie zintegrowany z oprogramowaniem do obsługi usług świadczonych drogą elektroniczną wykorzystywanym w Urzędzie Miasta Rzeszowa i jednostkach organizacyjnych Gminy w następującym zakresie i formie: a) obsługa elektronicznych dokumentów i korespondencji - System musi umożliwiać powiązanie elektronicznych dokumentów z otrzymanymi wcześniej wnioskami i dokumentami. b) dostęp do Systemu będzie możliwy przy pomocy tych samych loginów i haseł, oraz w oparciu o poziomy dostępu zdefiniowane w oprogramowaniu do obsługi usług świadczonych drogą elektroniczną wykorzystywanym przez Urząd Miasta Rzeszowa i jednostki organizacyjne Gminy, c) wszelkie zmiany w profilu użytkownika (takie jak hasło, adres , dane osobowe) będą niezwłocznie synchronizowane pomiędzy dostarczonym Systemem a oprogramowaniem do obsługi usług świadczonych drogą elektroniczną wykorzystywanym przez Urząd Miasta Rzeszowa i jednostki organizacyjne Gminy. Synchronizacja będzie dwustronna, tj. wszelkie zmiany profilu użytkownika w Systemie będą propagowane do oprogramowania do obsługi usług świadczonych drogą elektroniczną, oraz wszelkie zmiany profilu w oprogramowaniu do obsługi usług świadczonych drogą elektroniczną będą wykrywane przez System, 4) Dostarczony System będzie zintegrowany z centralną bazą rejestru dokumentów w następującym zakresie i formie: a) Wszystkie dokumenty przychodzące muszą być automatycznie rejestrowane w oprogramowaniu (bazie danych) rejestru korespondencji przychodzącej wykorzystywanej przez Urząd Miasta Rzeszowa. b) wszystkie dokumenty wychodzące muszą być automatycznie rejestrowane w oprogramowaniu (bazie danych) rejestru korespondencji wychodzącej wykorzystywanej przez Urząd Miasta Rzeszowa. c) System musi przekazywać do oprogramowania rejestru dokumentów wszystkie dane w strukturze, zgodnej z projektem Rozporządzenia Prezesa Rady Ministrów w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych wraz z załącznikami. 5) System musi posiadać interfejs wymiany danych oparty o protokół SOAP lub równoważny umożliwiający integrację z zewnętrznym autonomicznym Systemem Elektronicznego Obiegu Dokumentów (SEOD). Zakres funkcjonalny interfejsu wymiany danych musi obejmować: a) Dodawanie, usuwanie i edycję klientów, b) Dodawanie, usuwanie i edycję dokumentów wraz z całą historią, ścieżkami obiegu/dekretacji oraz załącznikami,