Opis Przedmiotu Zamówienia w zakresie części PODGiK

Transkrypt

1 Opis Przedmiotu Zamówienia w zakresie części PODGiK I. Wymagania względem przeprowadzenia projektu wdrożenia w zakresie PZGIK a. Koncepcja wdrożenia Komponentu e-usług Systemu PZGiK Zamawiający oczekuje, że w ramach realizacji zamówienia Wykonawca: zainstaluje i skonfiguruje dostarczone oprogramowanie m.in. narzędziowe oraz bazodanowe; dostarczy Komponent e-usług Systemu PZGiK do świadczenia e-usług u poszczególnych partnerów wraz z niezbędnymi licencjami; zainstaluje i skonfiguruje Komponent e-usług Systemu PZGiK dostarczone e-usługi publiczne oraz włączy do obecnie działającego Systemu PZGiK; zintegruje Komponent e-usług Systemu PZGiK z obecnie działającym Systemem PZGiK wskazanym dla danego Partnera w załączniku B.5; zintegruje Komponent e-usług Systemu PZGiK z obecnie działającym Systemem Obiegu Dokumentów (sugerowane punkty integracji oznaczono na schematach w Załączniku B.3 ikoną ) wskazanym dla danego Partnera w załączniku B.5; zintegruje Komponent e-usług Systemu PZGiK z uzgodnionym systemem płatności elektronicznych wybranym u danego Partnera; zintegruje Komponent e-usług Systemu PZGiK z usługami sieciowymi dostawcy tożsamości Profilu Zaufanego; dostarczy i wdroży Moduł Komornika, dostarczy i wdroży Moduł Rzeczoznawcy. Podstawowym założeniem koncepcji wdrożenia jest: dostarczenie skalowalnego (w poziomie i w pionie) rozwiązania bazującego zarówno na nowych jak i obecnie wykorzystywanych zasobach sprzętowo-programowych, autonomiczność węzła powiatowego w stosunku do całości systemu (węzeł powinien umożliwiać realizację e-usług nawet w przypadku awarii węzła centralnego), dostarczenia funkcjonalności w zakresie obsługi rzeczoznawców majątkowych oraz komorników pozwalających na uruchomienie e-usług na poziomie 4 opisanych w Załączniku B.3. 1

2 Na poniższym rysunku zaprezentowano ogólny schemat koncepcji węzła PODGiK w powiązaniu z CUW: *) Moduły FK planowane są do integracji w przyszłości. b. Etapy projektu Realizacja niniejszego zamówienia została podzielona na następujące etapy: Etap I Przygotowanie wdrożenia W ramach Etapu I przewiduje przeprowadzenie analizy przedwdrożeniowej oraz zaplanowanie wdrożenia Komponentu e-usług Systemu PZGiK. Wykonawca przygotuje koncepcję wdrożenia obejmującą w szczególności uzgodnienia dotyczące zmian przebiegu procesów biznesowych, według których realizowane będą wszystkie e-usługi. Zamawiający dopuszcza modyfikację i rozbudowę procesów opisanych w załączniku B.3. do OPZ po uzgodnieniu z Partnerem, w szczególności w zakresie: 2

3 Zakresu usługi realizowanej po za logowaniu / przed zalogowaniem, Powiązania bądź braku takiego powiązania z epuap, Szczegółów wybranego systemu płatności, Replikacji (lub braku) użytkowników tworzonych u Partnerów, Zakresu automatyzmu w rozpatrywaniu wniosku (zakres kontroli automatycznej / wykonywanej przez Pracownika). Wszystkie opracowane analizy będą stanowić podstawę do sporządzenia dokumentu Plan wdrożenia podlegający akceptacji Zamawiającego. Jako Planu wdrożenia Wykonawca przedstawi: Opis architektury Komponentu e-usług Systemu PZGiK; Harmonogram realizacji prac, uwzględniający: Etapy projektu przedstawione w niniejszym rozdziale. W ramach Etapów powinny zostać uwzględnione zadania oraz: o Spotkania w ramach poszczególnych zadań, o Produkty dostarczane w ramach poszczególnych zadań, o Czas dla Zamawiającego na weryfikację produktów, o Czas dla Wykonawcy na dostosowanie produktów po ich weryfikacji przez Zamawiającego, o Testy Kamienie milowe. Terminy zgodne z wyznaczonymi ramami czasowymi projektu, dla wszystkich elementów harmonogramu (czas rozpoczęcia i czas zakończenia). Projekt techniczny. Strategia Zarządzania Jakością. Strategia Zarządzania Konfiguracją. Strategia Zarządzania Komunikacją. Opracowany Harmonogram musi być spójny i musi uwzględniać terminy realizacji poszczególnych etapów oraz zadań wchodzących w zakres prac w ramach etapów Akceptacja Planu wdrożenia jest warunkiem koniecznym do rozpoczęcia kolejnego etapu. Etap I zakończy się sporządzeniem Protokołu odbioru częściowego. Etap II - Dostawa oprogramowania narzędziowego i bazodanowego W ramach Etapu II planuje się przeprowadzenie dostawy oraz instalacji oprogramowania narzędziowego, oprogramowania bazodanowego. 3

4 W ramach II Etapu nastąpi dostawa i wdrożenie Oprogramowania zapewniające transakcyjne i bezpieczne środowisko dla przetwarzania danych zgodnie z KRI obejmujące wykaz sprzętu komputerowego i oprogramowania niezbędnego do realizacji Projektu zgodnie z analizą potrzeb i stanu obecnych zasobów. Etap II zakończy się sporządzeniem Protokołu odbioru częściowego. Etap III Opracowanie i wdrożenie e-usług na podstawie wymagań przedstawionych w dalszej części niniejszego dokumentu. W ramach niniejszego etapu przewiduje się zweryfikowanie zakresu aktualnie funkcjonujących Systemów PZGiK w poszczególnych PODGiK pod kątem sformułowania wytycznych w zakresie dostosowania ich do obowiązujących przepisów prawnych wskazując: Zmiany, które mogą być skompensowane w ramach niniejszego projektu oraz Zmiany wymagające zmian w eksploatowanych systemach PODGiK Wykonawca przeprowadzi również wdrożenie e-usług, które dostarczane będą w sposób iteracyjny. W ramach niniejszego zadania należy wdrożyć e-usługi na 4 poziomie dojrzałości w ramach istniejących Systemów PZGiK u 12 Partnerów biorących udział w projekcie. Wdrożenie e-usług odbywać się będzie poprzez implementację dodatkowych funkcji w Systemach PZGiK na podstawie opisu procesów biznesowych zdefiniowanych w załączniku B3. Implementacja e-usług powinna cechować zgodność działania pod kątem umożliwienia wymiany danych w formacie GML określonym w obowiązujących przepisach dotyczących BDOT500, GESUT i EGiB lub też innymi metodami wymiany danych (np. WFS, WCS,CSW, WMS/WMTS). Szczegółowy zakres stanu obecnego posiadanego Systemu PZGiK u beneficjentów Projektu zawierają załącznik nr B.5 opisu przedmiotu zamówienia. Poza szczegółowymi wymaganiami OPZ, zakres prac jakie zobowiązany jest wykonać Wykonawca to: Zapewnienie wydawania i wczytywania danych w formacie GML zgodnie z zapisami rozporządzeń w sprawie EGiB, GESUT i BDOT500 Zapewnienie wymiany danych dotyczących kont użytkowników (w szczególności eksport i import kont i z Komponent e-usług Systemu PZGiK (KEU) do portalu Portal e-usług Województwa Opolskiego (PUWO)); Zapewnienie wymiany danych PZGIK (w szczególności eksport z Systemu PZGiK do Centralnej Bazy Danych CUW (CBD) celem zasilenia danych wojewódzkich oraz ); Zapewnienie do prowadzenia EGiB, BDOT500 i GESUT zgodnie z zapisami rozporządzeń w sprawie EGiB, GESUT i BDOT500. np. poprzez dostosowanie Systemów PZGiK lub inny sposób. 4

5 Wykonawca opracuje Komponent e-usług Systemu PZGiK (KEU), działające w oparciu o technologie www, niezbędnych do elektronicznej obsługi najczęściej realizowanych usług publicznych skierowanych do beneficjentów końcowych. W ramach zamówienia zaprojektowane zostaną główne moduły portali wraz z opracowaniem szczegółowej dokumentacji wymiany danych odbieranych i wysyłanych z Systemów PZGiK funkcjonujących w PODGiK-ach. Komponent e-usług powinien być zrealizowany w taki sposób, żeby obsługę procesów od strony interesanta zapewnić na poziomie wojewódzkim bez konieczności wchodzenia przez interesanta do jakichkolwiek innych portali aniżeli Portal CUW. W ramach Komponentu e-usług Systemu PZGiK powinny zostać stworzone następujące elementy: Moduł e-usług (Pe) zarządzany z poziomu wojewódzkiego poprzez brokera e-usług, zawierający wykaz e-usług oraz wzory e-formularzy. W ramach KU powinien być stworzony spójny katalog e-usług dla każdego z Partnerów Projektu oraz wzory e-formularzy na podstawie wymagań e-usług wynikających z niniejszego dokumentu oraz opisu e-usług zawartych w załączniku B.3. Autoryzacji Klienta (AK) - służący do rejestracji i uwierzytelnienia wszystkich użytkowników, którzy będą chcieli korzystać z e-usług z wykorzystaniem profili zaufanych lub podpisów kwalifikowanych wykorzystujący usługę LDAP. Komponent Mapowy (KM) - wspomagający świadczenie e-usług 4 poziomu, poprzez możliwość zaznaczenia na mapie ewidencyjnej zakresu przestrzennego oraz wyszukiwanie po atrybutach. Obsługa Wniosków (OW) - służący do przyjmowania elektronicznych formularzy dla wszystkich realizowanych e-usług przez PZGiK. Płatności Internetowe (PI) - służący do realizacji płatności elektronicznych współpracujący z zewnętrznymi systemami bankowości elektronicznej i płatnościami elektronicznymi. Moduł replikacji i harmonizacji ETL (ETL) - odpowiedzialny będzie za harmonizację i przepływ danych przestrzennych dla i z wszystkich węzłów. Pomimo iż w każdym węźle występuje w różnym charakterze, jest to identyczne funkcjonalnie rozwiązanie zbudowane z wykorzystaniem oprogramowania ETL. Jego uszczegółowienie zależy od położenia modułu w architekturze Systemu oraz od zadań a dokładnie zbiorów danych które przetwarza. W zależności od źródła danych w ramach projektu powinny powstać odpowiednie schematy pobierania, aktualizacji, harmonizacji danych przestrzennych z każdego z węzłów powiatowych, oraz wojewódzkich. Wiele z tych schematów będzie powielona w wielu węzłach a szczególnie tam gdzie będą identyczne systemy wewnętrzne, źródłowe. Ze względu na uniwersalność narzędzia będzie możliwość rozszerzenia zakresu danych przestrzennych, które System będzie przetwarzał czy to na potrzeby lokalne czy na potrzeby 5

6 całego Systemu. Każdy schemat powstały w ramach owego Systemu powinien być przechowywany lokalnie zaś jego kopia przekazywana do repozytorium węzła centralnego. Zadaniem modułu powiatowego jest wystawienie za pomocą powiatowych komponentów ETL udostępnionych i przygotowanych danych PZGIK celem zapisu i harmonizowania danych w Centralnej Bazie Danych CUW. Koncepcje formaty i zakres danych w jakie będą udostępniane oraz sposób zapisu w CBD CUW zostanie uszczegółowiona z Zamawiającym na etapie analizy i projektu technicznego. Serwer metadanych - służący do replikacji metadanych zarządzanych na poziomie CUW. Zgodnie z założeniami w ramach węzła powiatowego integrującego e-usługi powinny integrować się z powiatowymi systemami obiegu dokumentów, powiatowymi systemami obsługi PZGiK oraz systemami płatności internetowych. W przypadku braków funkcjonalnych oprogramowania wykazanego w Załączniku B.5, Wykonawca powinien dokonać rozbudowy lub rozszerzenia węzła do funkcjonalności niezbędnej do świadczenia wyspecyfikowanych w Załączniku B.3 e-usług. Wykonawca opracuje i wykona wraz z Zamawiającym iteracyjne testy dostarczonych e-usług przeprowadzone w oparciu o przygotowane przez Wykonawcę scenariusze testowe. Testy zostaną przeprowadzone dla każdej e-usługi z uwzględnieniem wszystkich elementów Komponentu e-usług Systemu PZGiK. W ramach niniejszego etapu Wykonawca zobowiązany jest przeprowadzić szkolenia z obsługi Komponentu e-usług Systemu PZGiK dla pracowników powiatów w zakresie: Obsługi wdrażanego rozwiązania; Administracji. W ramach realizowanych usług niezbędne jest zapewnienie bezpieczeństwa przetwarzania i udostępniania danych zgodnie z Polityką Bezpieczeństwa Partnera. Wymaga się, aby w Planie Wdrożenia Wykonawca dokonał uszczegółowienia poszczególnych etapów o zadania i produkty oraz określił zasady komunikacji m.in. organizację spotkań projektowych. Etap III zakończy się sporządzeniem Protokołu odbioru częściowego. II. Wymagania wspólne dla części od 14 do 25 a. Wymagania ogólne 6

7 Id. PO.1. PO.2. Opis Wymagania Wymaga się, aby korzystanie z e-usług nie wymagało specjalistycznej wiedzy z zakresu systemów informatycznych. Wykonawca zobowiązany jest do opracowania ostatecznego przebiegu procesów biznesowych z wykorzystaniem oferowanego oprogramowania oraz uzgodnienia ich z Zamawiającym. Opis procesów biznesowych związanych z realizacją e-usług PODGiK zawiera Załącznik nr B.3 do OPZ ma charakter ramowy. b. Interoperacyjność Id. PI.1. PI.2. PI.3. Opis Wymagania Podstawą dla realizacji Systemu muszą być wymagania zawarte w rozporządzeniu 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 (KRI). Interoperacyjność Systemu musi być zagwarantowana poprzez jego budowę w modelu usługowym ( 8.1. KRI), zorientowanym na świadczenie e-usług (Service Oriented Architecture SOA), w którym wszystkie funkcjonalności systemu teleinformatycznego dostępne są z poziomu przeglądarki internetowej, bez konieczności instalowania jakiegokolwiek oprogramowania po stronie użytkownika korzystającego z Systemu. Interoperacyjność Systemu musi być osiąganą poprzez: jego jednolitość, rozumianą jako stosowanie kompatybilnych norm, standardów i procedur przez różne jednostki realizujące zadania publiczne, posiadające dostęp do Systemu, jego zgodność, rozumianą jako przydatność produktów, procesów lub usług przeznaczonych do ich wspólnego użytkowania. Interoperacyjność Systemu musi być osiągana na poziomach: organizacyjnym, gwarantującym: o dostęp do aktualnego Systemu, o przepływ informacji w Systemie, semantycznym, gwarantującym: o stosowanie struktur danych i znaczenia danych w tych strukturach, zgodnych z KRI, 7

8 o stosowanie jednolitych i zgodnych modeli danych Systemu, o wzajemną referencyjność i harmonizację danych Systemu, technologicznym, gwarantującym: o jednolitość zastosowanych rozwiązań technologicznych Systemu, neutralność technologiczną Systemu. PI.4. Interoperacyjność zbiorów danych przestrzennych musi być zapewniona poprzez stosowanie regulacji zawartych w przepisach odrębnych, a w przypadku ich braku uwzględnienia postanowień odpowiednich Polskich Norm, norm międzynarodowych lub standardów uznanych w drodze dobrej praktyki przez organizacje międzynarodowe ( KRI), w tym: zapewniać dostęp do danych przestrzennych zawartych w Systemie zgodnie ze standardami OGC, gwarantując wyświetlanie/edycje map z wykorzystaniem standardowych e-usług WMS/WFS, zapewniać integrację danych przestrzennych zawartych w Systemie zgodnie ze standardami OGC, gwarantując tworzenie dowolnych kompozycji mapowych z wykorzystaniem standardowych e- usług WMS/WFS pozwalając, zapewniać stosowanie otwartych i jawnych formatów zapisu danych przestrzennych zgodnie z normą PN-EN-ISO Informacja geograficzna Środki dostępu do obiektów prostych (odpowiednik - Standard OGC: OpenGIS Simple Features - SQL - Types and Functions), gwarantującą neutralność technologiczną i jawność używanych standardów i specyfikacji zapisu danych przestrzennych w Systemie. PI.5. PI.6. System musi zapewniać realizację zasadę re-use, czyli rozwiązania z zakresu ponownego wykorzystania informacji na wielu poziomach, w tym na poziomie organizacyjnym, semantycznym i technologicznym. System musi pozwalać na wzajemne udostępnianie online danych Systemu, tak, aby nie kopiować i nie powielać zasobów utrzymywanych przez poszczególne Moduły, a tym bardziej uniknąć ich wielokrotnego i kosztownego opracowywania, a jednocześnie zapewniać ich wiarygodność i aktualność. PI.7. System musi zapewniać zgodność z dyrektywą INSPIRE i Ustawą z dnia 4 marca 2010 r. o infrastrukturze informacji przestrzennej. c. Wymagania dotyczące Komponentu e-usług Systemu PZGiK Identyfikator Opis Wymagania 8

9 Pe.1. W przypadku, gdy wdrożenie Komponentu e-usług Systemu PZGiK będzie wymagało ingerencji np. wymiany lub modyfikacji innego dowolnego komponentu Systemu PZGiK Wykonawca jest zobowiązany: Do zapewnienia wszystkich funkcjonalności, które zostały zaimplementowane w Systemie PZGiK w niezmienionej postaci; Do zapewnienia pełnej integracji z Systemem PZGiK; Do przeprowadzenia pełnej migracji baz danych, o ile zajdzie taka konieczność w celu zapewnienia spójności; Przeprowadzenia szkoleń w zakresie niezbędnym do sprawnego funkcjonowania PODGiK; Dostarczenia wszystkich niezbędnych licencji pozwalających na korzystanie z Systemu PZGiK zgodnie z jego przeznaczeniem i potrzebami PODGiK. Pe.2. Pe.3. Pe.4. Pe.5. Pe.6. Wykonawca zapewni mechanizm przekazania i zapisu wszystkich wniosków powstałych podczas działania e-usług w bazie danych Systemu PZGiK w postaci dokumentów elektronicznych w formacie zgodnym z rozporządzeniem w sprawie KRI. Każdy użytkownik Systemu PZGiK musi być opisywany za pomocą wszystkich atrybutów niezbędnych do nadania uprawnień do realizacji e-usług. Dokumentacja Komponentu e-usług Systemu PZGiK musi zawierać definicje i opis interfejsów oraz struktur danych na potrzeby integracji z innymi systemami. Wykonawca jest zobowiązany do dostarczenia Komponentu e-usług Systemu PZGiK zgodnie z przedstawioną lub własną koncepcją spełniającą wszystkie przedstawione wymagania. W szczególności Wykonawca może pogrupować funkcjonalności i wymagania w innym układzie obejmującym jeden lub więcej elementów Komponentu e-usług Systemu PZGiK. Wymaga się aby w ramach docelowej integracji Modułu PODGIK z Systemem Obiegu Dokumentów, podczas obsługi wniosku, po pierwszym wprowadzeniu danych, w sposób automatyczny były wymieniane pomiędzy systemami co najmniej następujące informacje: numer wniosku lub zgłoszenia w systemie EZD, imię i nazwisko lub Nazwa wnioskodawcy lub wykonawcy prac geodezyjnych, adres miejsca zamieszkania lub siedziby wnioskodawcy lub wykonawcy prac geodezyjnych, Identyfikator wnioskodawcy (PESEL lub REGON) lub wykonawcy prac 9

10 geodezyjnych, dane kontaktowe wnioskodawcy lub wykonawcy prac geodezyjnych: numer telefonu lub adres poczty elektronicznej, skrzynka epuap interesanta i ile podano data na piśmie, oraz data wpływu, rodzaj dokumentu Komponent Mapowy (KM) KM.1. Komponent Mapowy KM musi wizualizować mapę obszaru powiatu objętego e- usługami. KM.2. KM.3. KM.4. KM.5. Komponent Mapowy KM musi posiadać możliwość wyszukiwania danych i metadanych po zakresie przestrzennym, warstwach tematycznych oraz innych atrybutach mapy. Komponent Mapowy KM musi prezentować dane pochodzące z bazy PZGIK. Komponent Mapowy KM musi prezentować dane bazy EGiB zgodnie z symboliką kartograficzna treści mapy zasadniczej oraz Rozporządzenia Ministra Administracji i Cyfryzacji z dnia 2 listopada 2015 r. w sprawie bazy danych obiektów topograficznych oraz mapy zasadniczej (Dz.U poz. 2028). Komponent Mapowy KM musi umożliwiać zaznaczenie na mapie zakresu minimum jednej lokalizacji. W celu właściwego oznaczenia przedmiotu wniosku Komponent Mapowy KM musi obsługiwać: a. zapytania przestrzenne (dane w układzie 2000 oraz innych układach w tym 1992): poprzez narysowanie przez interesariusza obszaru (poligonu) na wyświetlonej mapie w celu wybrania obiektów, po wskazaniu punktowym, po współrzędnych (zapisanych w pliku tekstowym), wczytywanie obszaru zapisanego w pliku graficznym (shp, dxf, KML), wczytywanie zakresu z pliku gml. b. wyszukiwanie obiektów wg atrybutów: jednostek podziału terytorialnego, wykazu godeł arkuszy map, 10

11 jednostek podziału kraju stosowanych w EGiB (jednostki ewid., obręby ewid., działki ewid.), adresu nieruchomości, nr jednostki rejestrowej, nr księgi wieczystej (dostępne dla zalogowanego użytkownika). KM.6. KM.7. KM.8. KM.9. KM.10. Komponent Mapowy KM musi umożliwiać użytkownikowi wyszukiwanie zgodnie z nadanymi uprawnieniami dostępu do danych. Komponent Mapowy KM ma posiadać okno z legendą mapy. Komponent Mapowy KM musi posiadać funkcjonalności oparte na przeglądaniu mapy: a. możliwość przybliżania i oddalania skokowego poprzez zmianę skali o zdefiniowaną wielkość lub poprzez wybór z listy predefiniowanych skal, b. powiększanie i pomniejszanie na mapie za pomocą przycisków + - oraz za pomocą przycisku scroll na myszce, c. powiększanie i pomniejszanie na mapie poprzez wskazanie myszką danego obszaru, d. przesuwanie mapy w dowolnym kierunku, e. pomiaru powierzchni, odległości, f. drukowania wybranego obszaru. Komponent Mapowy KM w zakresie identyfikacji obiektów, musi umożliwiać odczytywanie informacji opisowych wybranego obiektu w oparciu o wybór bezpośredni na mapie. Komponent Mapowy KM musi umożliwiać użytkownikowi dokonanie zapisu wybranych danych identyfikatorów i ewentualnych załączników w e-formularzu wniosku. Autoryzacja Klienta (AK) AK.1. AK.2. Autoryzacji Klienta (AK) musi zapewniać możliwość uwierzytelniania użytkownika za pomocą profilu zaufanego lub certyfikatu kwalifikowanego oraz loginu i hasła. Moduł AK musi zapewniać automatyczną synchronizację danych użytkownika posiadającego już konto w Systemie CUW lub PZGiK. Uwaga! Szerszy opis komponentu autoryzacji znajduje się w opisie w zakresie 11

12 CUW. AK.3. Moduł AK musi zapewnić możliwość zakładania konta nowego użytkownika i jego rejestracji w Systemie CUW lub PZGiK. Każde konto utworzone w CUW w momencie wyboru usługi z danego powiatu musi się replikować w systemie PZGIK powiatu, chyba że w odniesieniu do danego typu konta (np. komornicy) ograniczono replikację. Uwaga! Szerszy opis komponentu autoryzacji znajduje się w opisie w zakresie CUW. AK.4. AK.5. AK.6. AK.7. AK.8. AK.9. Po pozytywnej autoryzacji użytkownika za pomocą Profilu Zaufanego, AK musi automatycznie zweryfikować istnienie jego konta w bazie danych Systemu CUW i PZGiK. W przypadku, gdy użytkownik loguje się pierwszy raz za pomocą Profilu Zaufanego, AK musi automatycznie założyć konto w bazie danych Systemu CUW i PZGiK. AK musi umożliwiać wprowadzanie zmian danych zarejestrowanego użytkownika w bazie danych Systemu CUW lub PZGiK. AK musi umożliwiać użytkownikowi bezpieczną zmianę hasła oraz jego odzyskanie poprzez nadanie nowego hasła. AK musi umożliwiać uzupełnianie informacji o załączniki w postaci dokumentów elektronicznych potwierdzających uprawnienia lub pełnomocnictwa. AK musi umożliwiać weryfikacje i autoryzację utworzonego konta użytkownika przez pracownika PODGiK lub WODGIK. Uwaga! Szerszy opis komponentu autoryzacji znajduje się w opisie w zakresie CUW. AK.10. AK.11. AK musi umożliwiać zapisanie wniosku o założenie konta użytkownika wraz z załącznikami w bazie danych Systemu. AK musi umożliwiać edycję i zmiany metadanych konta przez użytkownika. Płatności Internetowe (PI) PP.1. Element Płatności Internetowych (PI) musi zapewniać wykonanie płatności 12

13 internetowych dla wszystkich e-usług wymagających wniesienia opłat. PP.2. PP.3. Wymaga się aby zmodernizowany i rozbudowany system teleinformatyczny PZGiK umożliwiał współpracę z co najmniej jednym uzgodnionym ze Stroną Umowy, serwisem płatności elektronicznych np.: DotPay, Transferuj.pl, PayU, PayByNet, PayLane, ecard, Homepay. Po dokonaniu przez użytkownika płatności elektronicznej, element Płatności Internetowych musi posiadać możliwość sprawdzenia statusu płatności. E-Usługi EU.1. E-usługi muszą być realizowana na 4 poziomie dojrzałości. EU.2. W ramach realizacji przedmiotu zamówienia wykonawca dostarczy i wdroży e- usługi, których szczegóły zostały opisane w załączniku nr B.3 do SIWZ. EU.3. Wykonawca w ramach e-usług dostarczy i wdroży odpowiednie podprocesy e- usług opisane w załączniku nr B.3 do SIWZ. EU.4. E-usługi muszą udostępniać formularze wniosku wraz z możliwością określenia rodzaju obiektów lub i obszaru, dla którego mają być udostępnione dane. Wymaga się, aby walidacja poprawności formularza wniosku została dokonana automatycznie. d. Wymagania dotyczące Modułu Rzeczoznawcy 1. Zalogowanym użytkownikom, system musi umożliwiać odfiltrowanie danych według następujących kryteriów: a. Jednostki ewidencyjnej, b. przedziału dat transakcji, c. typu transakcji (obrót, wycena, inny), d. rodzaju nieruchomości, e. zawężenia do transakcji zawierających wyłącznie działki lub budynki, lub lokale. 2. System musi umożliwić zaznaczenie (odznaczenie) transakcji, które interesują użytkownika w celu zamówienia kompletnej informacji (z cenami i wartościami) występującymi w danych transakcjach. 13

14 3. System musi umożliwić użytkownikowi decydowanie o celu udostępniania danych: do wyceny (współczynnik K=0.5) lub do działalności gospodarczej (współczynnik CL>1). 4. Po wyborze parametrów i zatwierdzeniu zamówienia System powinien automatycznie generować: Formularz P, Formularz P4 oraz DOO. Dane z formularza powinny być zapisane w systemie dziedzinowym do prowadzenia PZGiK, w rejestrze wniosków o udostępnienie zasobu. 5. Po zamówieniu danych zalogowany użytkownik powinien mieć możliwość dokonania płatności. 6. Po odnotowaniu płatności, generowana jest licencja i odblokowywany jest dostęp do niewidocznych wcześniej cen i wartości nieruchomości występujących w poszczególnych transakcjach. System musi umożliwić zapis tych danych minimum w formacie HTML i TXT. 7. System musi umożliwić wyszukiwanie i zamawianie w sposób automatyczny, bez udziału pracownika ośrodka dokumentacji (operatora w urzędzie) w trybie 24/7. 8. System umożliwi dokonanie płatności online. e. Wymagania dotyczące Modułu Komornika 1. Zalogowanym użytkownikom (np. komornikom) System powinien umożliwić: a. Wyszukiwanie osoby co najmniej po imieniu i nazwisku w powiązaniu z imieniem matki i ojca. b. Wyszukiwanie po numerze PESEL, c. Wyszukiwanie po fragmencie nazwy, d. Wyszukiwanie po nr REGON, NIP 2. W wyniku weryfikacji musi zwrócić jedną z trzech informacji: a. w bazie EGIB brak osoby/podmiotu spełniającego podane kryteria b. w bazie EGIB występuje n osób/podmiotów spełniających podane kryteria c. w bazie EGIB już nie występuje w stanie aktualnym żadna osoba/podmiot spełniająca podane kryteria 3. Każde zadane do bazy danych EGiB zapytanie musi być zapamiętywane, tak aby można było w dowolnym momencie stwierdzić, kto, kiedy, jakie zapytanie sformułował do bazy danych. 4. Po potwierdzeniu, że dana osoba/podmiot spełnia zadane kryteria, system ma umożliwić bezpłatne udostępnienie lub odpłatne udostępnienie danych wypisu z bazy danych EGiB. 5. Wypis będzie dostępny tylko po uprzednim opłaceniu usługi wg obowiązujących cenników w przypadku weryfikacji odnośnie poniesienia opłaty. 14

15 III. Wymagania poza funkcjonalne Dokumentacja wdrożeniowa PF.1. PF.2. PF.3. PF.4. PF.5. Dopuszcza się aby zakres dokumentacji został dostosowanych do specyfiki wdrożenia realizowanego dla Strony Umowy. Wymaga się aby terminy przekazywania poszczególnych elementów dokumentacji były uzgodnione ze Stroną Umowy i dostosowane do Harmonogramu wdrożenia. Wykonawca będzie przekazywał dokumentację co najmniej w formatach PDF oraz formacie umożliwiającym edycję np..doc,.docx. najpóźniej w dniu zgłoszenia gotowości do odbioru. Na żądanie Strony Umowy Wykonawca przekaże dokumentację w postaci wydruku w ilości egzemplarzy uzgodnionych ze Stroną Umowy. Bezwzględnie wymaga się aby cała dokumentacja wytworzona w ramach projektu i przekazywana formalnie została oznakowana zgodnie z wymaganiami EFRR RPO WO Plan wdrożenia PF.6. PF.7. PF.8. PF.9. PF.10. W terminie do 60 dni kalendarzowych od podpisania umowy, Wykonawca opracuje i przekaże Stronie Umowy Plan wdrożenia, będący efektem analizy przedwdrożeniowej, wykonanej przez Wykonawcę przy współudziale Strony Umowy. W terminie do 10 dni roboczych od przekazania Strona Umowy przy udziale Inżyniera Projektu dokona weryfikacji Projektu technicznego wdrożenia. Wykonawca będzie miał 5 dni roboczych na poprawę i dostarczenie poprawionego dokumentu. Poprawiony dokument zostanie zweryfikowany w terminie do 10 dni roboczych od momentu jego dostarczenia. Przed odbiorem danego etapu zamówienia, Wykonawca powinien wykonać przegląd Plan wdrożenia i Harmonogramu wdrożenia i jeśli to zasadne dokonać aktualizacji obu dokumentów w porozumieniu ze Stroną Umowy. W terminie do 10 dni roboczych od dnia podpisania umowy, Wykonawca opracuje i przekaże Stronie Umowy do akceptacji Harmonogram wdrożenia stanowiący podstawowe narzędzie planowania i monitorowania prac projektowych. W terminie 5 dni roboczych Strona Umowy uzgodni przekazany Harmonogram wdrożenia. Harmonogram realizacji prac, uwzględniający: 15

16 PF.11. Etapy projektu przedstawione w niniejszym rozdziale. W ramach Etapów powinny zostać uwzględnione zadania oraz: o Spotkania w ramach poszczególnych zadań, o Produkty dostarczane w ramach poszczególnych zadań, o Czas dla Zamawiającego na weryfikację produktów, o Czas dla Wykonawcy na dostosowanie produktów po ich weryfikacji przez Zamawiającego, o Testy Kamienie milowe. Terminy zgodne z wyznaczonymi ramami czasowymi projektu, dla wszystkich elementów harmonogramu (czas rozpoczęcia i czas zakończenia). Wymaga się aby Projekt techniczny wdrożenia uwzględniał co najmniej następujące elementy: Opis uwarunkowań technicznych realizacji zakresu zamówienia Opis technologii zastosowanych do realizacji zamówienia Opis architektury systemu Opis i charakterystyka danych i baz danych Opis wymaganych integracji z systemami dziedzinowymi oraz projekt przepływu danych : Zestawienie i charakterystyka systemów Strony Umowy, które będą podlegać integracji z wdrażanym rozwiązaniem, Opis technologii i standardów integracji z systemami Strony Umowy, Opis procedury i zakresu integracji wdrażanego rozwiązania z systemami Strony Umowy, Opis procedur i zakresu integracji wdrażanego rozwiązania z platformą e-puap, Opis procedur i zakresu integracji wdrażanego rozwiązania z systemami płatności elektronicznych, Schemat przepływu danych pomiędzy systemami, Zestawienie interfejsów wymiany danych pomiędzy systemami. Opis technicznej realizacji e-usług wdrażanych w ramach przedmiotowego przedsięwzięcia: 16

17 Opis interfejsów użytkownika i kluczowych funkcjonalności systemu Strategia Zarządzania Jakością. Strategia Zarządzania Konfiguracją. Strategia Zarządzania Komunikacją. Dokumentacja powdrożeniowa PF.12. Dokumentacja powdrożeniowa zawierać: PF.13. Podręczniki administratora PF.14. Podręczniki użytkownika PF.15. Ostateczna wersja Projektu technicznego wdrożenia PF.16. Dokumentację/zrzut struktur baz danych wdrożonego rozwiązania, PF.17. Planu testów, PF.18. Dokumentacja szkoleń PF.19. Inne materiały i dokumenty wynikające ze specyfiki wdrożenia IV. Szkolenia a. Zakres szkoleń Wykonawca zobowiązany jest do przeprowadzenia szkoleń z zakresu obsługi oraz administrowania dostarczonymi modułami Systemu odrębnie dla: Administratorów systemu, Użytkowników. w terminie wynikającym z harmonogramu projektu. Szkolenia odbędą się w siedzibie danego zamawiającego lub poprzez zdalny pulpit. Wykonawca zapewni wszelkie niezbędne materiały szkoleniowe. b. Organizacja szkoleń 1. Szkoleniem objęci zostaną pracownicy partnerów projektu w zależności od numeru części zamówienia, zgodnie z poniższą tabelą: Lp. Powiat Liczba osób Liczba osób więcej/mniej do przeszkolenia I. Powiat Brzeski

18 Powiat Kędzierzyńsko 10 II. -Kozielski 2 III. Powiat Kluczborski 18 3 IV. Powiat Krapkowicki 11 2 V. Powiat Namysłowski 13 2 VI. Powiat Nyski 22 2 VII. Powiat Oleski 17 3 VIII Powiat Opolski 10 2 IX. Powiat Prudnicki 9 2 X. Powiat Strzelecki 14 3 XI. Miasto Opole 23 2 XII. Powiat Głubczycki 8 1 Szkolenia administratorów powinny objąć po dwie osoby dla każdego partnera. 2. Szczegółowy harmonogram szkoleń Wykonawca uzgodni z Zamawiającym. 3. Każdy uczestnik będzie brał udział w 16 godzinach szkolenia (dwa dni). 4. Szkolenia prowadzone będą w formie wykładów i zajęć praktycznych. Zajęcia praktyczne będą stanowiły około ¾ czasu szkolenia. 5. Szkolenia prowadzone będą w dni robocze w godzinach od 8 do 16. Dzienny maksymalny wymiar zajęć powinien wynosić nie mniej niż 6 i nie więcej niż 9 godzin szkoleniowych, wliczając przerwy (1 godzina szkoleniowa 45 minut). 6. Zajęcia prowadzone będą w maksymalnie 10 osobowych grupach. Szkolenia dla Administratorów i Użytkowników odbywają się oddzielnie, według indywidualnych planów. 7. W czasie zajęć praktycznych przy jednym stanowisku komputerowym pracować będzie jedna osoba (uczestnik szkolenia). 8. Wykonawca zapewni stanowisko komputerowe, dla każdego uczestnika danego szkolenia. 9. Zajęcia praktyczne przeprowadzane będą na sprzęcie komputerowym z wykorzystaniem oprogramowania zapewnionego przez Wykonawcę. 10. Zakres i program szkolenia musi być dostosowany do rodzaju szkolenia oraz do potrzeb poszczególnych partnerów projektu (w uzgodnieniu z Zamawiającym). 11. Każde szkolenie zakończone będzie testem sprawdzającym (treść testu zostanie uzgodniona z Zamawiającym). 12. Uczestnicy otrzymają imienne certyfikaty udziału w szkoleniu. 13. Zakres szkoleń Użytkowników obejmować będzie zagadnienia z zakresu wdrażanych i rozwijanych w ramach projektu e-usług odpowiednio dla danego Partnera. 18

19 14. Zakres szkoleń dla administratorów będzie obejmował zagadnienia zarządzania systemem. c. Rekrutacja i dokumentacja szkoleniowa 1. Szkolenia zostaną zorganizowane w sposób umożliwiający nieprzerwaną pracę wydziałów geodezji. Wykonawca przedstawi propozycję co najmniej 2 terminy szkolenia. 2. Rekrutację uczestników szkoleń przeprowadzi Wykonawca w uzgodnieniu z Zamawiającym 3. W ramach prowadzenia rekrutacji Wykonawca odpowiada za: a. przyjmowanie zgłoszeń, b. potwierdzanie i anulowanie udziału w szkoleniach, c. kontakt z uczestnikami w sprawie szkoleń, d. przestrzeganie ustawy o ochronie danych osobowych, e. na każde wezwanie Zamawiającego informowanie go o stanie rekrutacji grup szkoleniowych oraz bieżących postępach z realizacji zamówienia. 4. Wykonawca przekaże Zamawiającemu listy uczestników szkoleń. Listy powinny zawierać: imię i nazwisko, , telefon, dane jednostki którą reprezentuje. 5. Na zakończenie każdego szkolenia uczestnicy otrzymają do wypełnienia anonimową ankietę ewaluacyjną, mającą na celu ocenę programu, sposobu organizacji i przeprowadzenia szkolenia. 6. Wykonawca po przeprowadzeniu każdego szkolenia przekaże Zamawiającemu: podpisane listy obecności, potwierdzenia otrzymania materiałów szkoleniowych, potwierdzenia otrzymania certyfikatu udziału w szkoleniu oraz wypełnione ankiety ewaluacyjne. 7. Po każdym szkoleniu Wykonawca przygotuje raport z jego przeprowadzenia, zawierający: termin i miejsce szkolenia oraz jego szczegółowy zakres. 8. Na zakończenie Wykonawca przygotuje raport końcowy z realizacji zamówienia. 9. Wykonawca jest zobowiązany przekazać raporty, o których mowa w pkt 8 w ciągu 7 dni roboczych od daty zakończenia danego szkolenia oraz raport końcowy w terminie 14 dni roboczych od daty zakończenia zadania. 10. Treść i forma raportów zostanie zaproponowana przez Wykonawcę i uzgodniona z Zamawiającym. 11. Wykonawca zobowiązany będzie do bieżącego przekazywania Zamawiającemu informacji na temat stanu realizacji zamówienia. d. Miejsce szkoleń 1. Zamawiający udostępni wykonawcy salę odpowiednią do przeprowadzenia szkoleń. 19

20 2. Wykonawca jest zobowiązany do ustalenia terminu planowanych szkoleń w ścisłej współpracy z zamawiającym. 3. Każdy uczestnik szkolenia powinien mieć zapewnione stanowisko komputerowe z oprogramowaniem umożliwiającym instalację i obsługę oprogramowania, na którym prowadzone będą zajęcia praktyczne, z dostępem do Internetu, niezbędnymi licencjami oraz oprogramowaniem antywirusowym 4. W miejscu szkolenia Wykonawca zapewni w każdym dniu szkolenia, wyżywienie obejmujące: a. całodzienny serwis kawowy podczas 2 dni szkolenia, składający się z co najmniej: kawy z zaparzacza lub ekspresu, herbaty (co najmniej trzy rodzaje, w tym jedna czarna i jedna owocowa), wody mineralnej (gazowanej i niegazowanej), soków, przekąsek słonych i słodkich, b. dwa dwudaniowe obiady (w pierwszy i drugi dzień szkolenia) w formie zupy i drugiego dania. Szczegółowe menu zostanie uzgodnione z Zamawiającym na 5 dni przed planowanym terminem szkolenia. 5. Wykonawca nie pokrywa kosztów dojazdów uczestników na szkolenia. 6. W miejscu szkolenia Wykonawca umieści informację o finansowaniu szkolenia ze środków Regionalnego Programu Operacyjnego Województwa Opolskiego na lata oraz zapewni w czasie trwania szkolenia warunki odpowiadające przepisom z zakresu bezpieczeństwa i higieny pracy oraz p.poż. e. Materiały szkoleniowe 1. Wykonawca przygotuje dla uczestników szkoleń materiały szkoleniowe oraz przekaże je każdemu uczestnikowi nie później niż w dniu rozpoczęcia zajęć. 2. Wykonawca zaproponuje i uzyska akceptację Zamawiającego w zakresie materiałów szkoleniowych, obejmujących minimum: - podręcznik - obejmujący zakres projektu wraz z omówieniem zagadnień związanych z tematyką szkoleń, - prezentacje multimedialne obejmujące zakres projektu, wykłady, ćwiczenia szkoleniowe, - teczka typu aktówka formatu A4, - notatnik z długopisem, 3. Wykonawca przekaże Zamawiającemu materiały szkoleniowe w formie źródłowej w wersji edytowalnej oraz w formacie pdf. V. Testy 20

21 W ramach weryfikacji wdrożonych rozwiązań, Strona Umowy wymaga przygotowania i przeprowadzenia testów realizowanych przy udziale Wykonawcy, Inżyniera Projektu oraz Strony Umowy. W ramach realizacji etapu III, wymaga się przygotowania i przeprowadzenia testów w zakresie: Testy Akceptacyjne obejmujące potwierdzenie, że rozbudowany i zmodernizowany System spełnia wymagania funkcjonalne oraz pozafunkcjonalne (w szczególności bezpieczeństwa, powiązania z innymi obszarami funkcjonalnymi/systemami). Testy Akceptacyjne będą prowadzone w środowisku testowym. Zakończenie Testów Akceptacyjnych będzie warunkiem rozpoczęcia wdrożenia docelowego. Testy Zatwierdzające obejmujące potwierdzenie, że rozbudowany i zmodernizowany system PZGiK spełnia wymagania funkcjonalne oraz pozafunkcjonalne. Testy Zatwierdzające będą prowadzone po zakończeniu wdrożenia masowego w środowisku produkcyjnym. Po testach wymagane jest przywrócenie systemu za stan sprzed testów zatwierdzających Wykonawca zaproponuje metodykę testów z uwzględnieniem uzgodnienia i uruchomienia wersji testowej i produkcyjnej całego rozwiązania i poszczególnych komponentów. Wykonawca powinien przygotować Plan Testów opisujący zasady organizacji i realizacji testów akceptacyjnych i zatwierdzających wdrażanego rozwiązania z uwzględnieniem: przygotowania, przeprowadzenia, dokumentowania przebiegu testów wdrażanego rozwiązania. Plan Testów jest dokumentem organizacyjno technicznym służącym zaplanowaniu testów, opracowanym przez Wykonawcę. Rolą Planu Testów jest przygotowanie do przeprowadzenia testów dla dostarczonego przez Wykonawcę rozwiązania w takim zakresie, aby możliwe było zweryfikowanie i potwierdzenie jego zgodności z Zamówieniem. Plan Testów musi zawierać co najmniej scenariusze testowe z poziomu klienta wewnętrznego, z poziomu klienta zewnętrznego obejmujące wszystkie e-usługi dostarczone w ramach niniejszego zamówienia. Każdorazowo przed przystąpieniem do kolejnej tury testów, nie później niż na 5 dni roboczych przed rozpoczęciem testów, Wykonawca ze Stroną Umowy oraz Inspektorem Nadzoru, uzgodni techniczne warunki realizacji testów, Plan testów, konieczne dostępy do środowiska testowego/preprodukcyjnego/produkcyjnego, użytkowników testowych. 21

22 Na zakończenie procesu testowania Wykonawca dostarczy Stronie Umowy ora raport z testów wraz z załącznikami umożliwiającymi weryfikacje testów, najpóźniej do 10 dni roboczych od zakończenia testów. Niezależnie od wyżej opisanych scenariuszy Strona Umowy zastrzega sobie prawo do przeprowadzenia testów według dodatkowych scenariuszy. VI. Gwarancja Wykonawca zobowiązany jest do świadczenia serwisu gwarancyjnego przez okres wskazany w umowie, przy czym: 1. Okres świadczenia serwisu gwarancyjnego rozpoczyna się z dniem podpisania przez Strony końcowego protokołu odbioru bez uwag. 2. W okresie gwarancji Zamawiający nie ponosi dodatkowych kosztów związanych z korzystaniem z Systemu. Koszty te Wykonawca uwzględnia w cenie za realizację przedmiotu zamówienia. 3. W okresie trwania serwisu gwarancyjnego Wykonawca jest zobowiązany do wykonywania świadczeń gwarancyjnych polegających na: a. skutecznym rozwiązywaniu Zgłoszeń, b. dostarczaniu, instalacji i wdrażaniu niezbędnych lub celowych poprawek (w tym tzw. łat programowych - ang. patch") Systemu, c. podnoszenie wersji bazy w ramach serwisu gwarancyjnego, d. innych koniecznych działaniach zapewniających prawidłowe - tzn. nieograniczone czasowo i funkcjonalnie działanie Systemu. 4. Wszelkie świadczenia dostarczone przez Wykonawcę w ramach serwisu gwarancyjnego będą wykonywane przez wykwalifikowany i posiadający wystarczającą wiedzę na temat Systemu personel. 5. Wykonawca jest zobowiązany zrealizować wszelkie świadczenia w ramach serwisu gwarancyjnego w taki sposób, aby zapewnić pełną funkcjonalność Systemu w trakcie i po zrealizowaniu świadczenia. 6. Wszelkie działania związane ze świadczeniem serwisu gwarancyjnego muszą być wykonywane z wiedzą i akceptacją Zamawiającego. 7. W okresie trwania serwisu gwarancyjnego Wykonawca zobowiązany jest do: a. dostarczania nowych wersji lub uaktualnienia oprogramowania wchodzącego w skład Systemu w przypadku, gdy nastąpią zmiany w obowiązującym prawodawstwie, wymagające nowszej wersji lub uaktualnienia oprogramowania, 22

23 b. instalacji nowych wersji lub uaktualnień oprogramowania w terminach uzgodnionych z Zamawiającym, c. usprawniania obsługi Systemu poprzez wprowadzanie autorskich udoskonaleń w technologii i funkcjonalności oprogramowania. d. Szkolenia użytkowników i administratorów z zakresu nowych funkcjonalności, o których mowa w ppkt. a-c oraz aktualizacja Dokumentacji w tym zakresie. 8. Awarie, problemy, incydenty i zdarzenia w działaniu Systemu będą usuwane przez Wykonawcę na podstawie zgłoszeń dokonywanych przez Zamawiającego na piśmie, wysłanych na adres Wykonawcy lub w formie elektronicznej poprzez system helpdesk bądź pocztę elektroniczną na wskazany przez wykonawcę adres . W zgłoszeniu Zamawiający zobowiązany będzie do podania opisu błędu. Zgłoszenia przesłane do Wykonawcy po godzinie danego dnia będą traktowane jako zgłoszenia wpływające następnego dnia roboczego. 9. Usuwanie zgłoszeń będzie następowało w zależności od jego typu w następujących terminach: a. w przypadku awarii krytycznej Wykonawca przystąpi niezwłocznie do jej usunięcia i usunie ją lub zastosuje rozwiązanie zastępcze umożliwiające pracę systemu w terminie nie dłuższym niż 2 dni robocze, licząc od dnia następnego po dniu, w którym nastąpiło zgłoszenie do Wykonawcy. W przypadku zastosowania rozwiązania zastępczego Wykonawca usunie błąd w terminie nie dłuższym niż 5 dni roboczych, licząc od dnia następnego po dniu, w którym zostało zastosowane rozwiązanie zastępcze, b. w przypadku pozostałych zgłoszeń Wykonawca przystąpi do ich usunięcia nie później niż w ciągu 5 dni roboczych i usunie je w terminie nie dłuższym niż 5 dni roboczych, licząc od dnia zgłoszenia Wykonawcy. 10. W przypadku, gdy realizacja zgłoszenia wymaga przeprowadzania przez Wykonawcę prac za pomocą bezpiecznego połączenia sieciowego z systemem (VPN lub innego ustalonego pomiędzy Stronami), zainstalowanym w infrastrukturze teleinformatycznej Zamawiającego, terminy określone w ppkt. 9 a i b, przewidziane na usunięcie błędów w działaniu wskazanych elementów przedmiotu Umowy, ulegają zawieszeniu do czasu udostępnienia przez Zamawiającego bezpiecznego połączenia. 11. Dodatkowo w okresie wdrażania oraz w ramach serwisu gwarancyjnego będzie świadczył usługi obejmujące: a. Konsultacje dotyczące funkcjonowania Systemu: konsultacje telefoniczne, w każdy dzień roboczy, dotyczące rozwiązywania bieżących problemów użytkowników Systemu, 23

24 konsultacje za pośrednictwem poczty elektronicznej na wskazany przez Wykonawcę adres ( ), dotyczące rozwiązywania bieżących problemów użytkowników Systemu, konsultacje za pomocą bezpiecznego połączenia sieciowego z Systemem (VPN lub innego ustalonego pomiędzy Stronami), zainstalowanym w infrastrukturze teleinformatycznej Zamawiającego. b. Konsultacje oraz udzielenie porad w zakresie zainstalowania nowej wersji lub uaktualnień oprogramowania. VII. Podstawowe wymagania prawne Wykonawca oprócz uwarunkowań szczegółowych zawartych w niniejszym dokumencie musi uwzględniać: 1. Przepisy ogólne służące powstaniu infrastruktury informacji przestrzennej we Wspólnocie Europejskiej, które ustanowiła: a. Dyrektywa INSPIRE - dyrektywa 2007/2/WE Parlamentu Europejskiego i Rady UE z 14 marca 2007 r. ustanawiająca infrastrukturę informacji przestrzennej we Wspólnocie Europejskiej (INSPIRE); (Dz. U. Unii Europejskiej nr L 108/1); Dyrektywa INSPIRE i które zostały zaimplementowane do warunków polskich. W konsekwencji powstała: b. Ustawa o IIP - ustawa z 4 marca 2010 r. o infrastrukturze informacji przestrzennej (Dz. U. z 2017 r. poz z późn. zm.). 2. Przepisy branżowe, które zostały zmienione po ustanowieniu przepisów ogólnych, tj.: a. ustawa PGiK - ustawa Prawo geodezyjne i kartograficzne z 17 maja 1989 r. (tekst jednolity Dz. U. z 2017 r., poz. 2101) oraz nowe akty wykonawcze: rozporządzenie EGiB - rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z 29 marca 2001 r. w sprawie ewidencji gruntów i budynków (tekst jednolity Dz.U. z 2016 r., poz. 1034) rozporządzenie zmieniające EGiB rozporządzenie Ministra Infrastruktury i Budownictwa z 27 września 2017 r zmieniające rozporządzenie w sprawie ewidencji gruntów i budynków (Dz.U. 2017, poz. 1990) rozporządzenie EMUiA - rozporządzenie Ministra Administracji i Cyfryzacji z 9 stycznia 2012 r. w sprawie ewidencji miejscowości, ulic i adresów (Dz. U. z 2012 r., poz. 125) 24

25 rozporządzenie BTOT500 - rozporządzenie Ministra Administracji i Cyfryzacji z 2 listopada 2015 r. w sprawie bazy danych obiektów topograficznych oraz mapy zasadniczej (Dz.U. z 2015 r., poz. 2028) rozporządzenie GESUT - rozporządzenie Ministra Administracji i Cyfryzacji z 21 października 2015 r. w sprawie powiatowej bazy GESUT i krajowej bazy GESUT (Dz.U. z 2015 r., poz. 1938) rozporządzenie BDSOG - rozporządzenie Ministra Administracji i Cyfryzacji z 14 lutego 2012 r. w sprawie osnów geodezyjnych, grawimetrycznych i magnetycznych (Dz.U. z 2012 r., poz. 352) rozporządzenie PZGiK - rozporządzenie Ministra Administracji i Cyfryzacji z 5 września 2013 w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego (Dz.U. z 2013 r., poz. 1183), które weszło w życie 7 stycznia 2014 r. rozporządzenie w sprawie standardów - rozporządzenie Ministra Spraw Wewnętrznych i Administracji z 9 listopada 2011 r. w sprawie standardów technicznych wykonywania geodezyjnych pomiarów sytuacyjnych i wysokościowych oraz opracowywania i przekazywania wyników tych pomiarów do państwowego zasobu geodezyjnego i kartograficznego (Dz.U. z 2011 r. nr 263, poz. 1572) rozporządzenie w sprawie uwierzytelniania - rozporządzenie Ministra Administracji i Cyfryzacji z 8 lipca 2014 r. w sprawie sposobu i trybu uwierzytelniania przez organy Służby Geodezyjnej i Kartograficznej dokumentów na potrzeby postępowań administracyjnych, sądowych lub czynności cywilnoprawnych (Dz. U. z 2014 r., poz. 914) rozporządzenie w sprawie formularzy - rozporządzenie Ministra Administracji i Cyfryzacji z 8 lipca 2014 r. w sprawie formularzy dotyczących zgłaszania prac geodezyjnych, zawiadomienia o wykonaniu tych prac oraz przekazywania ich wyników do państwowego zasobu geodezyjnego i kartograficznego (Dz. U. z 2014 r. poz. 924) rozporządzenie w sprawie udostępniania - rozporządzenie Ministra Administracji i Cyfryzacji z 9 lipca 2014 r. w sprawie udostępniania materiałów państwowego zasobu geodezyjnego i kartograficznego, wydawania licencji oraz wzoru Dokumentu Obliczenia Opłaty (Dz. U. z 2014 r., poz. 917). rozporządzenie zmieniające rozporządzenie w sprawie udostępniania rozporządzenie Ministra Infrastruktury i Budownictwa z 13 września zmieniające 25

26 rozporządzenie w sprawie udostępniania materiałów państwowego zasobu geodezyjnego i kartograficznego, wydawania licencji oraz wzoru Dokumentu Obliczenia Opłaty (Dz. U. z 2017 r. poz. 1989). 3. Przepisy dotyczące ogólnych zasad informatyzacji Państwa, które nie zostały zaimplementowane w przepisach branżowych, a głównie: a. Ustawa z 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (t. j. Dz. U. z 2017 r., poz. 570) oraz przepisach wykonawczych: rozporządzenie Rady Ministrów z 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 (t. j. Dz. U. z 2017 r., poz. 2247) rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych z rejestru publicznego - art. 15 ust. 3 ustawy (Dz. U. Nr 2005, poz. 1692) rozporządzenie Rady Ministrów z 6 października 2016 r. zmieniające rozporządzenie w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U z 2016 r. poz.1634) rozporządzenie Ministra Cyfryzacji z 5 października 2016 r. w sprawie profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz.U r., poz.1633) rozporządzenie Ministra Cyfryzacji z 5 października 2016 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do uwierzytelniania użytkowników (Dz.U r., poz.1626) rozporządzenie Ministra Cyfryzacji z 5 października 2016 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U r., poz.1626) b. Ustawa z 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (t. j. Dz. U. z 2017 r., poz. 1219) c. Ustawa z 29 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz. U. z 2016 r., poz. 1579). Wykonawca przy tworzeniu aplikacji powinien uwzględniać nie tylko schematy aplikacyjne, które zostały opublikowane w przepisach branżowych wymienionych w punkcie 2., ale również schematy 26

27 aplikacyjne, które mogą być publikowane w repozytorium interoperacyjności, o którym mowa w przepisach wydanych na podstawie art. 18 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne. Udostępnianie danych powinno być możliwe w formacie GML z zastosowaniem schematów aplikacyjnych oraz systemów zapewniających minimalne wymagania dla systemów teleinformatycznych, zapewniając tym samym interoperacyjność semantyczną i technologiczną. 27