bip.zgkikm.wroc.plbip.zgkikm.wroc.pl/download/178/12006/Zalaczniknr1-OPZ... · Web viewdokumentacji...

Projekt „Podniesienie dostępności e-usług danych przestrzennych państwowego zasobu geodezyjnego i kartograficznego we Wrocławiu”

Załącznik nr 1 do SIWZ

Szczegółowy opis przedmiotu zamówienia

Zaprojektowanie i implementacja oraz wdrożenie metod harmonizacji danych PZGiK do modelu INSPIRE – temat Działki Katastralne

Strona 1 / 35


Spis treści:

1 Podstawowe pojęcia definicje i skróty...........................................................................................................3

1.1 Definicje, pojęcia...................................................................................................................................3

1.2 Skróty..................................................................................................................................................10

2 Ogólny opis przedmiotu zamówienia...........................................................................................................12

2.1 Tytuł zamówienia................................................................................................................................12

2.2 Ogólne informacje dotyczące zamówienia..........................................................................................12

3 Wymagania szczegółowe.............................................................................................................................15

3.1 Sposób realizacji zamówienia..............................................................................................................15

3.1.1 Etap 1: Przygotowanie organizacyjne i opracowanie „Planu Realizacji Zamówienia”.....................15

3.1.2 Etap 2: Opracowanie dokumentacji analityczno – projektowej (DAP)............................................17

3.1.3 Etap 3: Zaimplementowanie i wdrożenie narzędzi do aktualizacji danych w modelu INSPIERE.....20

3.1.4 Etap 4: Przeprowadzenie Odbioru Końcowego...............................................................................24

3.2 Wymagania prawne............................................................................................................................25

3.3 Wymagania wobec dostarczanej przez Wykonawcę dokumentacji....................................................26

1 Dodatek nr 1 – Założenia koncepcyjne i techniczne dotyczące infrastruktury technicznej w zakresie tzw. Szyny Usług..........................................................................................................................................................27

1.1 Ogólna architektura............................................................................................................................27

1.2 Założenia techniczne...........................................................................................................................28

4 Dodatek nr 2 – Usługi gwarancji i serwisu...................................................................................................30

4.1 Zdalny dostęp do Infrastruktury Technicznej Zamawiającego.............................................................30

4.2 Usuwanie błędów oprogramowania...................................................................................................30

5 Dodatek nr 3 – Testowanie prototypu komponentu LIIP.............................................................................33

Strona 2 / 35


1 Podstawowe pojęcia definicje i skróty

1.1 Definicje, pojęcia

Nazwa Definicja

Atrybut Właściwość danego obiektu określona przez jej nazwę oraz zakres przyjmowanych wartości, jakie mogą być jej przypisane.

Baza danych Zbiór powiązanych ze sobą logicznie danych, zaprojektowany dla zaspokojenia części lub całości potrzeb informacyjnych danej organizacji w określonym zakresie dziedzinowym.

CASE CASE (ang. Computer-Aided Software Engineering) lub (ang. Computer-Aided Systems Engineering) określenie rodzaju oprogramowania (klasy) tzw. narzędzi CASE, których zadaniem jest wspomaganie procesu projektowania, w przypadku niniejszego zamówienia modelowania w języku UML przypadków użycia, schematów interakcji dla budowanego komponentu LIIP.

Cecha Kategoria klasy, której zadaniem jest (w przypadku modeli danych) dostarczenie innej klasie określonych własności (atrybutów i powiązań z innymi klasami).

Czynność Czynność to określone zachowanie złożone z logicznie uporządkowanych ciągów podczynności, akcji oraz obiektów w celu wykonania pewnego procesu.

Dokumentacja Całość dostarczonej oraz opracowanej przez Wykonawcę dokumentacji analitycznej, technicznej i użytkowej w trakcie realizacji zamówienia, w szczególności dotyczy to dokumentacji analityczno projektowej, projektu technicznego i dokumentacji powykonawczej.

Dyrektywa INSPIRE(ang. Infrastructure for Spatial Information in Europe)

Infrastruktura Informacji Przestrzennych w Europie, idea i projekt, którego celem jest tworzenie zharmonizowanych baz danych przestrzennych oraz uzgodnienie jednolitej metody wymiany danych przestrzennych w Europie. Zgodnie z Dyrektywą 2007/2/WE Parlamentu Europejskiego i Rady z dnia 14 marca 2007 r. ustanawiającą infrastrukturę informacji przestrzennych we Wspólnocie Europejskiej (INSPIRE) będzie ona oparta na infrastrukturach ustanowionych i działających w Państwach Członkowskich.

Elektroniczna usługa publiczna, inaczej e-usługa

1) Usługa, która jest świadczona drogą elektroniczną za pomocą sieci Internet, której wykonanie z jednej strony jest w określonym zakresie jest zautomatyzowane i wymaga tylko niewielkiego udziału człowieka (jako usługobiorcy), a z drugiej strony w takim zakresie w jakim jest świadczone – wykonanie jej bez technologii informatycznej jest niemożliwe.

2) To usługa świadczona w sposób zautomatyzowany przez użycie technologii informacyjnych, za pomocą systemów teleinformatycznych w publicznych sieciach telekomunikacyjnych, na indywidualne żądanie usługobiorcy, bez jednoczesnej obecności stron (usługodawcy i usługobiorcy) w tej samej lokalizacji.

Element metadanych Dyskretna jednostka metadanych. Odpowiednik atrybutu w terminologii UML. Elementy metadanych są jednoznaczne w ramach encji metadanych.

Encja metadanych Zbiór elementów metadanych opisujących ten sam aspekt danych. Odpowiednik klasy

Strona 3 / 35


Nazwa Definicja

w terminologii UML. Może zawierać jedną lub więcej encji metadanych.

Etap Nazwany, zdefiniowany określony ciąg działań Wykonawcy zdefiniowany w Harmonogramie Prac

Geoportal Aplikacja sieciowa w postaci portalu internetowego o przyjaznym i graficznym interfejsie umożliwiająca użytkownikowi dostęp do danych przestrzennych za pośrednictwem przeglądarki internetowej.

Harmonizacja zbiorów danych przestrzennych

Zapewnienie wewnętrznej spójności logicznej i merytorycznej poszczególnych modeli pojęciowych, jak również zapewnienie takiej samej spójności pomiędzy oddzielnymi modelami.

Harmonogram Prac Aktualizowany harmonogram określający terminy realizacji zadań, podzadań wchodzących w zakres Etapów. Harmonogram Prac stanowi instrument zarządzania, kontroli i monitorowania postępu prac, w którym dopuszcza się zmiany terminów wykonania poszczególnych zadań i podzadań wchodzących w zakres Etapów, bez zmiany terminu etapów. Harmonogram Prac jest częścią dokumentacji zarządczej Planu Realizacji Zamówienia.

Infrastruktura Informacji Przestrzennej (IIP)

Opisane metadanymi zbiory danych przestrzennych oraz dotyczące ich usługi, środki techniczne, procesy i procedury, które są stosowane i udostępniane przez współtworzące infrastrukturę informacji przestrzennej organy wiodące oraz inne organy administracji i osoby trzecie.

interoperacyjność Zdolność różnych podmiotów (w szczególności podmiotów realizujących zadania publiczne) oraz używanych przez nie systemów teleinformatycznych i rejestrów publicznych do współdziałania na rzecz osiągnięcia wzajemnie korzystnych i uzgodnionych celów, z uwzględnieniem współdzielenia informacji i wiedzy przez wspierane przez nie procesy biznesowe realizowane za pomocą wymiany danych za pośrednictwem wykorzystywanych przez te podmioty systemów teleinformatycznych

Interfejs Zestaw operacji, które wyznaczają usługi oferowane przez daną klasę lub komponent.

Iteracja Wielokrotne, policzalne powtórzenie jednostki zachowania w systemie lub zachowania w czynnościach operacyjnych np. działań wykonawcy.

Infrastruktura Techniczna Zamawiającego

Sprzęt komputerowy (serwery, macierze, urządzenia aktywne i pasywne oraz pozostałe elementy instalacyjno – konfiguracyjne infrastruktury teleinformatycznej) jak również Oprogramowanie: Aplikacyjne, Systemowe, Narzędziowe, Bazodanowe, użytkowane przez Zamawiającego, w tym udostępnione do realizacji zamówienia – jak: licencja MS SQL Server 2014.

Komponent Hermetyczny, wymienny moduł lub część oprogramowania danego systemu, realizujący określone jego usługi za pośrednictwem interfejsów. W przypadku niniejszego zamówienia w kontekście LIIP Gminz Wrocław odnosi się do składowej LIIP, jaka zostanie opracowana i wdrożona przez Zamawiającego na podstawie dostarczonych przez Wykonawcę produktów (Oprogramowania).

Komunikat Specyfikacja wymiany informacji między obiektami, zawierająca zlecenia wykonania określonej operacji.

Krajowe Ramy Interoperacyjności (KRI)

Zbiór uzgodnionych definicji, wymagań, reguł architektury systemów teleinformatycznych oraz procedur i zasad, których stosowanie umożliwi współdziałanie systemów teleinformatycznych podmiotów realizujących zadania publiczne w procesach realizacji tych zadań drogą elektroniczną.

Strona 4 / 35


Nazwa Definicja

Krajowy zasób danych przestrzennych

Zbiór danych przestrzennych lub jego seria oraz usługa danych przestrzennych należąca do krajowej infrastruktury informacji przestrzennej. Zasób danych przestrzennych staje się częścią krajowej infrastruktury informacji przestrzennej poprzez jego ujawnienie w ewidencji zbiorów i usług danych przestrzennych.

Krajowy zasób danych przestrzennych INSPIRE

Zbiór danych przestrzennych lub jego seria oraz usługa danych przestrzennych należąca do krajowej infrastruktury informacji przestrzennej zgodny ze specyfikacjami INSPIRE i udostępniany na poziom europejski przez kraj członkowski.

Lokalna Infrastruktura Informacji Przestrzennej

Inaczej, zależnie od kontekstu Lokalna Infrastruktura Informacji Przestrzennej Miasta Wrocławia, w tym przypadku w zakresie kompetencji Zamawiającego - Realizatora tj. ZGKiKM we Wrocławiu. Z uwagi na fakt, iż opracowane przez Wykonawcę Rozwiązanie nie stanowi całości LIIP w opisie niniejszych wymagań używane będzie sformułowanie – „Komponenty LIIP Zamawiającego” lub zamiennie „Komponent LIIP”.

Metadane (ang. metadata)

Dane o danych [ISO 19115]; informacje, które opisują zbiory danych przestrzennych i usługi danych przestrzennych oraz umożliwiają odnalezienie, inwentaryzacje i używanie tych danych i usług.

Metodyka Zestaw pojęć, notacji, modeli formalnych, języków i sposobów postępowania służący do analizy rzeczywistości (stanowiącej przedmiot projektowanego systemu informatycznego) oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Zwykle metodyka jest powiązana z odpowiednią notacją (diagramami) służącymi do zapisywania wyniku poszczególnych faz projektu, jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem.

Model Odwzorowanie, uogólnienie rzeczywistości.

Model pojęciowy Model procesów lub model struktury danych odwołujący się do ludzkiej percepcji i wyobraźni, mający za zadanie prezentację problemu, udokumentowanie wyniku analizy lub projektu w czytelnej i abstrakcyjnej formie językowej oraz ułatwienie komunikacji w zespołach ludzkich.

Modelowanie biznesowe

Sposób odwzorowywania i dokumentowania procesów biznesowych.

Norma (specyfikacja techniczna)

Dokument przyjęty na zasadzie konsensusu i zatwierdzony przez upoważnioną jednostkę organizacyjną, ustalający zasady, wytyczne lub charakterystyki odnoszące się do różnych rodzajów działalności lub zmierzający do określenia i uzyskania optymalnego stopnia uporządkowania w określonym zakresie np. Normy ISO serii 19100.

Obiekt Każdy byt — pojęcie lub rzecz — mający znaczenie w kontekście rozwiązywania pro-blemu w danej dziedzinie przedmiotowej, jak również abstrakcyjna reprezentacja przedmiotu, zjawiska fizycznego lub zdarzenia związanego z określonym miejscem lub obszarem geograficznym

Oprogramowanie Oprogramowanie Aplikacyjne, Standardowe, Bazodanowe, Narzędziowe oraz Systemowe, rozumiane łącznie jak również każde z nich z osobna zależnie od kontekstu wystąpienia.

Oprogramowanie Aplikacyjne

Oprogramowanie opracowane i dostarczone przez Wykonawcę, stanowiące najwyższą warstwę w wielowarstwowej architekturze budowanego przez Wykonawcę

Strona 5 / 35


Nazwa Definicja

Rozwiązania / Systemu, do którego Wykonawca posiada autorskie prawa majątkowe. Oprogramowanie Aplikacyjne obejmuje wszystkie opracowane przez Wykonawcę komponenty, procedury, metody mające jakąkolwiek postać kodu wykonywalnego lub skryptu użytego do wdrożenia budowanego Rozwiązania / Systemu.

Oprogramowanie Standardowe

Oprogramowanie Wykonawcy, co, do którego posiada on autorskie prawa majątkowe lub osoby trzeciej, do którego Wykonawca ma pełnię praw, a które zostało wytworzone przed udzieleniem Wykonawcy niniejszego zamówienia, stanowiące zamkniętą całość w formie modułu / komponentu / biblioteki programistycznej, i służy realizacji zamówienia.

Oprogramowanie Bazodanowe

Oprogramowanie zapewniające techniczne środki do bezpiecznego gromadzenia, autoryzowanego dostępu i przetwarzania danych w oparciu o relacyjną, obiektową lub obiektowo – relacyjną bazę danych.

Oprogramowanie Narzędziowe

Oprogramowanie zapewniające funkcje techniczne Rozwiązania / Systemu, stanowiące warstwę pośrednią - usługową pomiędzy Oprogramowaniem Aplikacyjnym / Standardowym a Systemowym, z wyłączeniem Oprogramowania Bazodanowego.

Oprogramowanie Systemowe

Oprogramowanie zapewniające podstawowe funkcje systemowe umożliwiające funkcjonowanie infrastruktury sprzętowej zgodnie z jej przeznaczeniem. W skład tego oprogramowania wchodzi: oprogramowanie do wirtualizacji oraz systemy operacyjne.

Organ wiodący Organ wskazany w Ustawie o Infrastrukturze Informacji Przestrzennej odpowiedzialny za określony zakres zadań lub obszar danych tematycznych

Osoba trzecia Osoba fizyczna, osoba prawna lub jednostka organizacyjna nieposiadająca osobowości prawnej, niebędąca organem administracji.

Plan Realizacji Zamówienia (PRZ)

Dokumentacja zarządcza wspomagająca i opisująca proces zarządzania projektem związany z realizacją danej umowy. Zakres opracowania PRZ zawiera takie elementy jak: Harmonogram Prac, procedury komunikacji, procedury zarządzania zmianą oraz ryzykiem, opis uzgodnionej przez Strony metodyki i / lub procesu wytwórczego, plan zarządzania jakością, inne (konspekt dokumentacji technicznej i powykonawczej).

Plan Testów Dokument organizacyjny służący zaplanowaniu testów akceptacyjnych odnoszący się do wymagań technicznych, zasobów testowych (ludzie, sprzęt, środowisko testowe, dane testowe – baza testowa), oraz sposobu opracowania i zakresu tzw. scenariuszy testowych inne.

Profil meta danych Podzbiór klas i elementów podstawowego standardu metadanych, ewentualnie rozszerzony o elementy metadanych niewystępujące w standardzie podstawowym, utworzony w celu zaspokojenia wymagań określonej grupy użytkowników.

Przypadek użycia Specyfikacja ciągu akcji i ich wariantów, które dany system (lub inna jednostka) może wykonać poprzez interakcje z aktorami tego systemu. W przypadku użycia wyróżnia się tzw. główne / podstawowe scenariusze oraz scenariusze alternatywne związane z zachowaniem Obiektów: aktora oraz danego systemu, opisujące określoną ścieżkę przetwarzania danych / komunikatów.

Punkt kontrolny Wyróżnione zdarzenie lub stan podzadania, zadania lub etapu, w którym następuje zweryfikowanie stan realizacji / zaawansowania prac, poprzez ocenę poziomu spełnienia ustalonych miar jakościowych i ilościowych odpowiednio dla podzadania, zadania lub etapu.

Strona 6 / 35


Nazwa Definicja

Rejestr publiczny Uoinf Art. 3 pkt. 5) rejestr publiczny – rejestr, ewidencję, wykaz, listę, spis albo inną formę ewidencji, służące do realizacji zadań publicznych, prowadzone przez podmiot publiczny na podstawie odrębnych przepisów ustawowych.

Rozwiązanie Opracowane i / lub dostarczone przez Wykonawcę produkty, stanowiące docelowy przedmiot realizacji zamówienia. Inaczej komponenty LIIP Zamawiającego.

Scenariusz (lub scenariusz podstawowy)

Określony ciąg akcji dokumentujący zachowanie. W tym przypadku dotyczący „podstawowego” procesu przetwarzania komunikatów i związanych z tym zdarzeń.

Scenariusz alternatywny

Określony ciąg akcji dokumentujący zachowanie związany z procesem „pobocznym” przetwarzania komunikatów i związanych z tym zdarzeń np. obsługą wyjątków, błędów.

Schemat aplikacyjny Schemat pojęciowy dla danych wykorzystywanych przez jedną lub więcej aplikacji.

Seria zbiorów danych (ang. spatial data set series)

Kolekcja zbiorów danych zgodnych z tą samą specyfikacją produktu [ISO 19115]

SOA (ang. Service-Oriented Architecture)

Architektura oparta na usługach – koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika. Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych mający na celu lepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi.

Stan Okoliczność lub sytuacja, w jakiej obiekt znajduje się w cyklu swojego życia, kiedy spełnia warunek, wykonuje czynność lub czeka na zdarzenie.

System teleinformatyczny

Uoinf Art. 3 pkt. 3) system teleinformatyczny – zespół współpracujących ze sobą urządzeń informatycznych i oprogramowania zapewniający przetwarzanie, przechowywanie, a także wysyłanie i odbieranie danych przez sieci telekomunikacyjne za pomocą właściwego dla danego rodzaju sieci telekomunikacyjnego urządzenia końcowego w rozumieniu przepisów ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (t.j. Dz. U. z 2014 r., poz. 243 z późn. zm.).

System informatyczny Wyodrębniona część systemu informacyjnego, która dla osiągnięcia przyjętych celów została poddana komputeryzacji poprzez zastosowanie metod i technik teleinformatycznych. System informatyczny składa się z:

infrastruktury sprzętowej np.: komputery, serwery, macierze dyskowe, inne,

oprogramowania systemowego, bazodanowego, aplikacyjnego oraz narzędziowego,

informacji reprezentowanej przez dane przechowywane w dedykowanej infrastrukturze sprzętowej przy wykorzystaniu oprogramowania bazodanowego – czyli w bazach danych,

produktów informacyjnych systemu (raportów, wykazów, map, list) będących wynikiem procesów przetwarzania danych tj. ich tworzenia, edycji, usuwania, publikowania i udostępniania,

procedur określających zasady prowadzenia systemu rejestrów, ewidencji będących przedmiotem danego systemu oraz procedur użytkowo-

Strona 7 / 35


Nazwa Definicjaadministracyjnych,

użytkowników systemu, tych wewnętrznych w ramach danej organizacji oraz zewnętrznych posiadających niejednokrotnie ograniczony dostęp do danych oraz produktów informacyjnych systemu.

Rysunek 1 Ideogram systemu informacyjnego

System PZGiK System teleinformatyczny wspierający realizację zadań Służby Geodezyjnej i Kartograficznej na poziomie powiatu / miasta na prawach powiatu. Definicję Systemu PZGiK zawiera Art. 7 ust. 3 Rozporządzenia Ministra Administracji i Cyfryzacji z dnia 5 września 2013 r. w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego(Dz.U. z 2013 r. poz. 1183 ze zm.): cytat: „System PZGiK stanowi uporządkowany i całościowy układ, zintegrowany z systemami teleinformatycznymi wykorzystywanymi do przetwarzania danych w odpowiadających im bazach danych, o których mowa w art. 4 ust. 1a pkt 1-5 i pkt 7-11 oraz ust. 1b, art. 7a pkt 16a, art. 24b ust. 1 pkt 1 ustawy, oraz w zintegrowanych kopiach baz danych, o których mowa w art. 4 ust. 1a pkt 8 ustawy, oraz z systemem do elektronicznego zarządzania dokumentacją, o którym mowa w przepisach wydanych na podstawie art. 6 ust. 2b ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz. U. z 2011 r. Nr 123, poz. 698 i Nr 171, poz. 1016), obejmujący: 1) bazy systemu PZGiK, w których gromadzi się: a) dane niezbędne do prowadzenia: rejestru zgłoszeń, ewidencji materiałów zasobu oraz rejestru wniosków o udostępnienie materiałów zasobu, b) materiały zasobu w postaci dokumentów elektronicznych, c) metadane; 2) kopie bezpieczeństwa baz, o których mowa w pkt 1, stanowiące kopie awaryjne; 3) urządzenia służące do przyjmowania, wizualizacji, udostępniania i teletransmisji danych i materiałów zasobu w postaci dokumentów elektronicznych.”

Szyna danych / szyna usług (ang. Enterprise Services Bus – ESB)

Infrastruktura zbudowana z oprogramowania narzędziowego opartą na standardach, zorientowaną na usługi sieciowe, zapewniająca możliwości łączenia setek punktów końcowych aplikacji. ESB łączy messaging, web services, XML, transformacje danych oraz zarządzanie łączeniem i koordynacją interakcji aplikacyjnych.

Tabela Struktura danych implementowana w relacyjnych bazach danych, często nazywana relacją. Tabela składa się z wierszy lub inaczej krotek. Należy zwrócić uwagę, że pomiędzy relacją (w sensie matematycznym) i tabelą występują dość istotne różnice koncepcyjne. Tabela jest wyposażona w nazwy kolumn, (które niosą informację semantyczną).

Temat danych przestrzennych

Powiązane ze sobą zbiory danych przestrzennych stosownie do załączników I, II oraz III dyrektywy INSPIRE.

Usługi (publiczne) Usługi świadczone przez organy administracji publicznej dla obywateli, podmiotów gospodarczych oraz organizacji, a także inne formy komunikacji pomiędzy organami administracji publicznej a obywatelami i organizacjami, służące realizacji zadań administracji publicznej lub wywiązywaniu się obywateli i organizacji z obowiązków wobec państwa

Usługa danych Usługa będąca operacjami, które mogą być wykonywane przy użyciu oprogramowania

Strona 8 / 35


Nazwa Definicja

przestrzennych (ang. spatial data services)

komputerowego na danych zawartych w zbiorach danych przestrzennych lub na powiązanych z nimi metadanych.

Usługa sieciowa Komponent, część oprogramowania, która realizuje pewne funkcje logiki systemu i może być wywołana zdalnie poprzez zdefiniowany interfejs.

Walidator Moduł / komponent sprawdzający poprawność dokumentu (np. XML) wobec określonej składni – definicji (np. XSD).

Warsztaty wymagań Metoda definiowania, „wydobywania” wymagań wobec projektowanego systemu polegająca na aktywnej współpracy zespołu Zamawiającego z Wykonawcą bazująca na takich technikach jak: prezentacja przykładowych, gotowych produktów lub opracowanych przez Wykonawcę prototypów docelowego rozwiązania, poparta formułą dyskusji / „burzy mózgów”, pytaniami / listami kontrolnymi lub omówieniem i wspólnym definiowaniem przypadków użycia lub zastosowaniem innych technik. Stroną odpowiedzialną za przeprowadzenie warsztatów wymagań jest Wykonawca, który musi adekwatnie do stanu zaawansowania prac oraz poziomu wiedzy i stopnia zaangażowania zespołu Zamawiającego dobrać odpowiednio techniki oraz ich liczność. W przypadku przedmiotowego zamówienia warsztaty wymagań mają również silnie formułę przekazu informacyjnego i budowania kompetencji / wiedzy u pracowników Zamawiającego z przedmiotu zamówienia. Tego rodzaju działania instruktażowe powinny poprzedzić etap uzgodnień budowania koncepcji technicznej oczekiwanego przez Zamawiającego Rozwiązania.

Węzeł Fizyczny lub logiczny zasób przetwarzający, na którym są osadzone artefakty użyt-kowanego systemu – w tym przypadku LIIP.

Wdrożenie Ciąg następujących po sobie lub występujących równolegle czynności takich jak: instalacja, konfiguracja, szkolenie użytkowników i administratorów, przygotowanie danych testowych, wykonanie testów weryfikacyjnych i wydajnościowych oraz współudział w testach akceptacyjnych, przygotowanie szablonów oraz scenariuszy testowych, opracowanie i dostarczenie dokumentacji użytkownika oraz dokumentacji technicznej Rozwiązania oraz świadczenie usług asysty technicznej – nadzoru autorskiego na etapie uruchomienia celem doprowadzenia do normalnej, prawidłowej eksploatacji Rozwiązania.

Zbiór danych przestrzennych (ang. spatial data set)

Rozpoznawalny ze względu na wspólne cechy zestaw danych przestrzennych.

Związek (relacja) W języku UML i w konsekwencji także w normach grupy ISO 19100 - semantyczne połączenie pomiędzy elementami modelu. Przykładami związków są agregacje, kompozycje (agregacje całkowite), powiązania i uogólnienia.

Strona 9 / 35


1.2 Skróty

Skrót Opis / wyjaśnienie BPEL ang. Business Process Execution Language; język wykonania procesów biznesowych

BPMN ang. Business Process Model and Notation; model i zapis procesu biznesowego

BPMS ang. Business Process Management System; system zarządzania procesami biznesowymi

ESB ang. Enterprise Service Bus; korporacyjna magistrala usług

GUI ang. Graphical User Interface; graficzny interfejs użytkownika

HA ang. High Availability; wysoka dostępność

IAM ang. Identity and Access Management; zarządzanie tożsamością i dostępem

KPI ang. Key Performance Indicator; kluczowy wskaźnik wydajności

LAN ang. Local Area Network – lokalna sieć komputerowa

LDAP ang. Lightweight Directory Access Protocol; lekki protokół usług katalogowych – protokół przeznaczony do korzystania z usług katalogowych, usługa katalogowa pozwalająca na wymianę informacji w sieci za pomocą TCP/IP

RDBMS ang. Relational Database Management System; system zarządzania relacyjną bazą danych

REST ang. Representational State Transfer; transfer bezstanowy – styl architektury usług sieciowych udostępniających bezstanowy mechanizm przesyłania danych z wykorzystaniem protokołu HTTP

SLA ang. Service Level Agreement; umowa na dostarczenie usługi na ustalonym poziomie – poziom jest określony stosownymi miernikami

SOA ang. Service-Oriented Architecture; architektura zorientowana na usługi

SOAP ang. Simple Object Access Protocol; protokół wywołania zdalnego dostępu do obiektów – protokół używający XML do kodowania transmisji

SSO ang. Single sign-on; pojedyncze logowanie

TCP ang. Transmission Control Protocol; niezawodny, strumieniowy protokół komunikacyjny – TCP służy do wymiany danych pomiędzy aplikacjami uruchomionymi na różnych maszynach

Uoinf Ustawa z dnia 17 lutego 2005 roku o informatyzacji działalności podmiotów realizujących zadania publiczne – tekst jednolity (Dz. U. z 2014 poz. 1114) oraz ustawa z dnia 10 stycznia 2014 roku o zmianie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne oraz niektórych innych ustaw (Dz.U. 2014 poz. 183).

UoD Umowa o Dofinansowanie

UDDI ang. Universal Description, Discovery and Integration - uniwersalny rejestr wykrywania i rejestrowania usług internetowych. UDDI zawiera tzw. ang. white pages, czyli dane kontaktowe o dostawcy usługi, tzw. ang. yellow pages, lokalizację usługi i tzw. ang. green pages, techniczny opis usługi, w tym semantyka: wersja XML, typ szyfrowania i Document Type Definition (DTD) standardu.

Strona 10 / 35


Skrót Opis / wyjaśnienie WSDL ang. Web Service Definition Language; język definiowania usług sieciowych – język

opisujący protokoły i formaty używane przez usługi sieciowe

XML ang. Extensible Markup Language; rozszerzalny język znaczników – uniwersalny język definiowania (reprezentowania) danych w ustrukturalizowany sposób

Strona 11 / 35


2 Ogólny opis przedmiotu zamówienia

2.1 Tytuł zamówieniaZaprojektowanie i implementacja oraz wdrożenie metod harmonizacji danych PZGiK do modelu INSPIRE – temat Działki Katastralne.

2.2 Ogólne informacje dotyczące zamówienia

1. Przedmiotem zamówienia jest opracowanie i wdrożenie narzędzi do harmonizacji danych PZGiK do modelu INSPIRE w zakresie danych ewidencji gruntów i budynków dla tematu Działki Katastralne.

1.1. Zamówienie obejmuje:

1.1.1. Usługi zaprojektowania, wdrożenia i udokumentowania oprogramowania do harmonizacji danych PZGiK do modelu INSPIRE.

1.1.2. Dostawę niezbędnego do realizacji zamówienia oprogramowania takiego, jak:

1.1.2.1. Oprogramowanie bazodanowe (system relacyjnej lub obiektowej bazy danych), gdzie przedmiotem dostawy może być oprogramowanie komercyjne lub „Open source”, przy czym do realizacji zamówienia Wykonawca może wykorzystać oprogramowanie udostępnione przez Zamawiającego - licencje MS SQL Server 2014;

1.1.2.2. Oprogramowanie narzędziowe: serwer ETL, serwer mapowy, szyna usług do zarządzania, monitorowania i uruchomienia usług INSPIRE, inne niezbędne w ocenie Wykonawcy oprogramowanie zgodnie z jego Ofertą, przy czym przedmiot dostawy może obejmować oprogramowanie komercyjne lub klasy „Open source”;

1.1.2.3. Oprogramowanie aplikacyjne – dedykowane oprogramowanie opracowane przez wykonawcę do aktualizacji i publikacji danych w modelu INSPIRE (o ile w ocenie Wykonawcy jest to niezbędne do realizacji zamówienia z uwagi na brak możliwości implementacji całości funkcjonalności oferowanego rozwiązania wyłącznie w oparciu o dostarczone oprogramowanie narzędziowe).

2. Zamawiającym jest Gmina Wrocław – Zarząd Geodezji Kartografii i Katastru Miejskiego we Wrocławiu (ZGKiKM).

3. Zamówienie jest częścią prowadzonego przez Zamawiającego projektu pn. „Podniesienie dostępności e-usług danych przestrzennych państwowego zasobu geodezyjnego i kartograficznego we Wrocławiu” (zwanego „Projektem”), realizowanego w ramach Regionalnego Programu Operacyjnego Województwa Dolnośląskiego (RPO WD) na lata 2014-2020: Osi Priorytetowej 2: „Technologie informacyjno - komunikacyjne” Działania 2.1 „E-usługi publiczne”, Poddziałanie 2.1.1 „E-usługi – horyzont” – nabór RPDS.02.01.01-IZ.00-02-219/17 – konkurs horyzontalny.

4. Zamówienie musi być zrealizowane przez Wykonawcę:

Strona 12 / 35


4.1. Nie później niż ciągu 5 miesięcy od daty zawarcia umowy , przy założeniu, że termin zrealizowania zamówienia jest równoznaczny z terminem podpisania Protokołu Odbioru Końcowego.

4.2. Zgodnie z niniejszym Opisem Przedmiotu Zamówienia (OPZ SIWZ), inaczej specyfikacją oraz opracowanym przez Wykonawcę i zatwierdzonym przez Zamawiającego: „Planem Realizacji Zamówienia”, w tym w szczególności zgodnie z uzgodnionym przez Strony Harmonogramem Prac zawierającym następujące, wymagane etapy realizacyjne będące przedmiotem odrębnych odbiorów:

4.2.1. Etap 1: Przygotowanie organizacyjne i opracowanie dokumentu zarządczego „Planu Realizacji Zamówienia”, w tym Harmonogramu Prac – nie później niż w ciągu 10 dni roboczych od daty zawarcia umowy na realizację zamówienia.

4.2.2. Etap 2: Opracowanie dokumentacji analityczno-projektowej (DAP) – w terminie wskazanym przez Wykonawcę zapewniającym prawidłową realizację zamówienia, w tym wypełnienie całości zobowiązań Wykonawcy, jednak nie później niż w terminie do 6 tygodni od daty zawarcia umowy na realizację niniejszego zamówienia.

4.2.3. Etap 3: Zaimplementowanie i wdrożenie narzędzi do aktualizacji, publikacji danych w modelu INSPIERE – w zakresie oraz w sposób określony w dokumentacji analityczno-projektowej (DAP) oraz w terminie ustalonym w obowiązującym Harmonogramie Prac, w tym udokumentowanie wyników prac w formie dokumentacji powykonawczej.

4.2.4. Etap 4: Przeprowadzenie Odbioru Końcowego – nie później niż na 5 dni roboczych przed ostatecznym terminem wykonania zamówienia.

4. Miejscem realizacji zamówienia jest siedziba Zamawiającego.

5. W realizacji zamówienia Wykonawca musi uwzględnić wszystkie zawarte w specyfikacji informacje oraz wymagania, uwzględniając w tym również wymagania zawarte we Wniosku o dofinansowanie realizowanego przez Zamawiającego Projektu, który stanowi zewnętrzny załącznik do SIWZ.

6. Zakres zobowiązań Wykonawcy obejmuje w szczególności:

6.1. Operacyjne zarządzanie i koordynację prac, w tym również w zakresie niezbędnego współdziałania z zespołem Zamawiającego, przy czym dobór właściwych metod i technik zarządzania dla realizacji celu oraz przedmiotu zamówienia leży po stronie Wykonawcy.

7. Z uwagi na realizację zamówienia w ramach Projektu Wykonawca jest zobowiązany do:

7.1. Prowadzenia wspólnej z Zamawiającym polityki informacyjnej, której podstawą dla Zamawiającego są wytyczne w zakresie promocji i polityki informacyjnej jakie nakłada na Zamawiającego, jako Beneficjenta Instytucja Zarządzająca http://rpo.dolnyslask.pl/zasady-promocja-i-oznakowanie-projektow-w-perspektywie-2014-2020/, co w szczególności dotyczy oznakowania pism, dokumentów zgodnie z obowiązującymi w tym zakresie wytycznymi publikowanymi;

7.2. Zapewnienia oddelegowanie i dostępność osoby odpowiedzialnej ze strony Wykonawcy za bieżące, operacyjne zarządzanie i koordynację prac (w nomenklaturze Projektu tzw. Kierownika Zadania).

7.2.1. Powyższe uwzględnia również niezbędną potrzebę współdziałania z podmiotem trzecim tzw. Inżynierem Kontraktu odpowiedzialnym za koordynację prac na poziomie Projektu, mogącym prowadzić na rzecz Zamawiającego czynności kontroli prac Wykonawcy.

7.3. Minimalny zakres współdziałania Wykonawcy to:

Strona 13 / 35

http://rpo.dolnyslask.pl/zasady-promocja-i-oznakowanie-projektow-w-perspektywie-2014-2020/

http://rpo.dolnyslask.pl/zasady-promocja-i-oznakowanie-projektow-w-perspektywie-2014-2020/


7.3.1. Raportowanie postępu prac na potrzeby składania przez Zamawiającego sprawozdań z realizacji Projektu do Instytucji Zarządzającej RPO WD.

7.3.2. Raportowanie Wykonawcy musi być prowadzone w cyklach miesięcznych przez przekazanie raportu zawierającego informacje wystarczające dla Zamawiającego do: oceny stopnia zaawansowania prac, określenia lub potwierdzenia terminu ich wykonania, wskazania zagrożeń i / lub identyfikowanych ryzyk oraz napotkanych problemów;

7.3.3. Czynności raportowania muszą być zaplanowane i wskazane w Planie Realizacji Zamówienia.

7.3.4. Uczestnictwo w spotkaniach zarządczych w stopniu ustalonym przez Strony na etapie opracowania Planu Realizacji Projektu, przy czym zakłada się, iż w okresie intensywnych prac wdrożeniowych Zamawiający może zażądać udziału Kierownika Zadania ze strony Wykonawcy w tzw. naradach koordynacyjnych 2 razy w miesiącu. Powyższe nie wyklucza możliwości wezwania Wykonawcy do udziału w spotkaniu w przypadku pojawiających się trudności w realizacji zamówienia.

Strona 14 / 35


3 Wymagania szczegółowe

Niniejsze rozdziały opisują przedmiot zamówienia oraz sposób jego realizacji, w tym ogólny podział na etapy, zadania i podzadania.

3.1 Sposób realizacji zamówienia

3.1.1 Etap 1: Przygotowanie organizacyjne i opracowanie „Planu Realizacji Zamówienia”

1. W ramach zadania, Wykonawca zobowiązany jest opracować „Plan Realizacji Zamówienia” stanowiący uszczegółowienie sposobu realizacji zamówienia głównie w zakresie planowania i prowadzenia prac przez Wykonawcę oraz koordynacji i współpracy z Zamawiającym.

2. Poniższe wymagania Zamawiającego wobec zakresu i treści opracowanego przez Wykonawcę dokumentu odnoszą się do wybranych, kluczowych zagadnień jakie są przedmiotem wymagań lub rekomendacji wg. powszechnie uznanych metodyk zarządzania projektami, takich jak np.: PMBOK, czy też PRINCE2 lub inne im równoważne. Zadaniem Wykonawcy jest właściwe dobranie metod i technik zarządzania do specyfiki zamówienia tak, aby wypełnić w tym zakresie jego kluczowe cele.

2.1. Zakres czynności dotyczący zarządzania dotyczy realizacji przedmiotowego zamówienia z punktu widzenia celu jakim jest jego terminowe i prawidłowe wykonanie poprzez właściwy dobór metod, technik oraz zasobów osobowych i technicznych po stronie Wykonawcy – oraz niezbędne współdziałanie z Zamawiającym.

3. Opracowany przez Wykonawcę „Plan Realizacji Zamówienia” musi zawierać co najmniej:

3.1. Opis struktury organizacyjnej powołanej do realizacji niniejszego zamówienia po stronie Wykonawcy oraz Zamawiającego uwzględniający w tym względzie minimalny skład zespołu Wykonawcy oraz oddelegowanie do współpracy ze strony Zamawiającego tzw. Zespołu Projektowego.

3.2. Harmonogram Prac zawierający czytelny podział zamówienia na etapy, zadania i podzadania, wskazujący następstwo określonych zdarzeń, uwzględniający istotne uwarunkowania wykonawcze, jak również planowane przez Wykonawcę działania, w tym działania przy współudziale Zamawiającego, terminy procedur odbioru, udostępnienia zasobów przez Zamawiającego itp.

3.2.1. Zaproponowany przez Zamawiającego podział na etapy oraz zadania jest wiążący dla Wykonawcy z punktu widzenia określonych w nim zakresów prac oraz zobowiązań.

3.2.2. Podczas opracowania Harmonogramu Prac Wykonawca jest zobowiązany:

3.2.2.1. Zdefiniować co najmniej 2 punkty kontrolne umożliwiające ocenę zaawansowania prac, określając zarazem dla nich obowiązujące terminy wykonania. Punkty kontrolne podlegają weryfikacji i ocenie stanu ich zaawansowania przez Zamawiającego, przy czym brak osiągnięcia ustalonego poziomu zaawansowania prac i zrealizowania celu szczegółowego dla punktu kontrolnego lub brak odbioru Planu Realizacji Zamówienia, może stanowić dla Zamawiającego podstawę do odstąpienia od realizacji umowy.

Strona 15 / 35


3.2.2.1.1. Punkty kontrolne muszą być wprowadzone do Etapu 2 oraz Etapu 3.

3.2.2.2. Określić terminy przeprowadzenia prac analitycznych i wdrożeniowych.

3.2.2.3. Uwzględnić fakt, iż Zamawiający:

3.2.2.3.1. nie dopuszcza zmiany czasu trwania oraz terminu wykonania Etapów, dla których czas lub termin określono w niniejszym dokumencie lub umowie poprzez podanie daty lub wskazanie określonej liczby dni, z wyłączeniem okoliczności stanowiących podstawę zmian - jakie zgodnie z obowiązującymi przepisami prawa, w tym w szczególności ustawą prawo zamówień publicznych Zamawiający dopuścił w zakresie realizacji przedmiotu zamówienia.

3.2.2.3.2. dopuszcza zmianę kolejności określonych zdarzeń / czynności / zadań, jakie wskazano w niniejszym opisie przedmiotu zamówienia pod warunkiem przedstawienia przez Wykonawcę uzasadnienia tych zmian oraz uzyskania w tym zakresie akceptacji ze strony Zamawiającego.

3.2.3. Zamawiający rekomenduje opracowanie Harmonogramu Prac w formie schematu Gantta np. w programie MS Project lub w innym oprogramowaniu równoważnym.

3.3. Opis wdrażanych przez Wykonawcę procedur zarządzania i koordynacji prac, takich jak:

3.3.1. procedura zarządzania zagadnieniami projektowymi w zakresie zarządzania zagadnieniami projektowymi, w tym problemem i zmianą;

3.3.2. procedura komunikacji, o ile propozycje zawarte w OPZ w tym zakresie są w ocenie Wykonawcy niewystarczające;

3.3.3. opcjonalnie procedura zarządzania ryzykiem, poprzedzona przeprowadzeniem analizy ryzyka, celem wskazania głównych czynników ryzyka realizacji zamówienia;

3.4. Uszczegółowiony konspekt dokumentacji analityczno-projektowej.

3.5. Inne uwarunkowania zidentyfikowane przez Wykonawcę, jako profesjonalistę w realizacji tego rodzaju zamówień, mające istotny wpływ lub niezbędne dla prawidłowej realizacji zamówienia oraz spełnienia wymagań Zamawiającego z punktu widzenia głównego celu zamówienia.

4. Podczas opracowania Planu Realizacji Zamówienia Wykonawca musi uwzględniać fakt, iż:

4.1. Wymaganie jest dokumentowanie procesu realizacji zamówienia przez Wykonawcę w formie notatek ze spotkań, uzgodnień, co powinno mieć swoje odzwierciedlenie w opracowanych i zaproponowanych przez Wykonawcę procedurach „planu Realizacji Zamówienia”. Minimalny zakres wymagań w tym zakresie to udokumentowanie faktu spotkania oraz przyjętych uzgodnień.

4.2. Opracowane przez Wykonawcę procedury powinny zapewnić czytelne monitorowanie procesu prowadzonych prac analitycznych i projektowych, w tym uzgodnień z Zamawiającym oraz możliwość uwzględnienia nawet w końcowym stadium realizacji zamówienia - zgłoszenia istotnych zmian do przedmiotu zamówienia planowanego projektu np. w zakresie dotyczącym opracowanej przez Wykonawcę i zatwierdzonej przez Zamawiającego „Dokumentacji Analityczno-Projektowej”.

Strona 16 / 35


4.3. Brak odbioru Etapu I nie wstrzymuje prac Wykonawcy oraz nie zmienia zakresu jego zobowiązań w realizacji zamówienia. W takim przypadku Wykonawca powinien realizować zamówienie w oparciu o obustronne, robocze uzgodnienia Przedstawicieli Stron wskazanych w umowie, zmierzając jednocześnie do odbioru wyników prac Etapu I, czyli zatwierdzenia przez Zamawiającego „Planu Realizacji Zamówienia".

3.1.2 Etap 2: Opracowanie dokumentacji analityczno – projektowej (DAP)

1. W ramach tego etapu Wykonawca jest zobowiązany opracować i uzgodnić z Zamawiającym niezbędną dla realizacji zamówienia dokumentację analityczno – projektową.

2. W trakcie opracowania przedmiotowej dokumentacji Wykonawca jest zobowiązany przeprowadzić nie mniej niż 3-4 dedykowane warsztaty wymagań, podczas których powinien omówić w formie prezentacji oraz dyskusji kluczowe zagadnienia harmonizacji danych PZGiK do modelu INSPIRE, cechy projektowanego Rozwiązania, w tym wymagania funkcjonalne oraz rezultaty prac analitycznych.

2.1. Prowadzone warsztaty muszą zapewniać przekaz informacyjny dla pracowników Zamawiającego, rozszerzając i pogłębiając wiedzę w temacie przedmiotu zamówienia w taki sposób, aby możliwe było usprawnienie procesu oceny poprawności oferowanego przez Wykonawcę Rozwiązania, co w szczególności powinno obejmować obszar wiedzy i nabycia niezbędnych kompetencji do prawidłowego użytkowania dostarczonego lub opracowanego przez Wykonawcę Oprogramowania. W tym celu Wykonawca powinien przygotować i przekazać Zamawiającemu w formie elektronicznej materiały informacyjne obejmujące omawiane na warsztatach zagadnienia.

2.2. Warsztaty w zakresie zagadnień dot. harmonizacji danych PZGiK do modelu INSPIRE muszą obejmować w szczególności zagadnienia dot. koncepcji, projektu technicznego oferowanego Rozwiązania oraz zasad działania zastosowanych do realizacji zamówienia usług oraz funkcji wykorzystanego w tym celu Oprogramowania.

2.3. Zakres omawianych zagadnień objętych warsztatami od strony metodycznej powinien uwzględniać między innymi:

2.3.1. wyjaśnienie czym jest harmonizacja danych przestrzennych i jaki jest jej cel;

2.3.2. wskazanie w strategii harmonizacji danych przestrzennych rezultatów takich jak: struktura danych XML/GML, usługi INSPIRE, metadane;

2.3.3. harmonizacja danych jako proces – strategia wybór metod i technik, poszczególne ertapy, kroki techniczne realizacji;

2.3.4. omówienie modelu danych źródłowych PZGiK oraz modelu Działki Katastralne;

2.3.5. wskazanie zasad przejścia z modelu źródłowego do modelu pojęciowego (schematu aplikacyjnego) INSPIRE;

2.3.6. opracowanie strategii przejścia (transformacji) ze struktury źródłowej do docelowej struktury XML/GML;

2.3.7. omówienie usług sieciowych OGC i INSPIRE (CSW, WMS, WMTS, WFS, ATOM, WCS), w tym wskazanie roli URL w kwestii standardu technicznego usługi;

Strona 17 / 35


2.3.8. omówienie najważniejszych elementów zawartości metadanych pliku capabilities usługi;

2.3.9. techniczne aspekty uruchomienia, instalacji, konfiguracji i monitorowania usług INSPIRE;

3. Dokumentację analityczno-projektową tworzyć będą następujące dokumenty składowe:

3.1. Zestawienie wymagań:

3.1.1. Dokument zawierający wymagania Zamawiającego przedstawione w niniejszej specyfikacji (OPZ SIWZ) wraz z uzgodnieniami wykonawczymi z Zamawiającym dotyczącymi sposobu ich spełnienia przez projektowane rozwiązania.

3.2. Model przypadków użycia, który musi zawierać co najmniej:

3.2.1. Dokument zawierający graficzną reprezentację (wraz z opisem) przypadków użycia, aktorów oraz związków między nimi, występujących w dziedzinie przedmiotowej objętej przedmiotem zamówienia. Zakres opracowania Modelu przypadków użycia powinien obejmować wymagania funkcjonalne przedstawione w [OPZ]. Model ten musi być opracowany zgodnie ze specyfikacją OMG UML 2.x i musi co najmniej zawierać:

3.2.1.1. Zestawienie aktorów, w tym podział użytkowników na grupy z przypisaniem ról oraz uprawnień.

3.2.1.2. Hierarchię przypadków użycia wraz z ich szczegółowym opisem (m.in. zawierającym dane wejściowe i wyjściowe, informacje sterujące, scenariusze działań, aktorów).

3.2.1.3. Mapowanie przypadków użycia na wymagania (tj. wskazanie, które wymagania są realizowane w ramach poszczególnych przypadków użycia).

3.2.1.4. Określenie kluczowych funkcji środowiska harmonizacji danych objętych Zamówieniem z uwzględnieniem różnych sposobów zasilania, walidacji i weryfikacji zbiorów danych przestrzennych, metadanych i usług sieciowych.

3.3. Projekt techniczny, który musi zawierać co najmniej:

3.3.1. Architekturę logiczną dostarczanego Rozwiązania opisującą podsystemy/moduły/komponenty wchodzące w skład rozwiązania, relacje między nimi oraz ich wewnętrzną budowę.

3.3.2. Opis interfejsów między podsystemami/modułami/komponentami dostarczanego Rozwiązania oraz interfejsów do systemów zewnętrznych.

3.3.3. Przedstawienie wykorzystywanych struktur baz danych (w tym np. diagramy ERD, podział bazy na schematy, określenie partycjonowania obiektów, określenie indeksów dla tabel, definicje sposobu i stopnia zrównoleglenia przetwarzania obiektów, etc.).

3.3.4. Przedstawienie schematu rozmieszczenia składników Oprogramowania Aplikacyjnego oraz Oprogramowania Narzędziowego w Infrastrukturze Technicznej Zamawiającego, w tym szczegółowe informacje nt. konfiguracji sprzętu i oprogramowania.

3.4. Metodykę harmonizacji, która musi zawierać, co najmniej:

3.4.1. Dokument określający zasady i tryb harmonizacji danych PZGIK w zakresie ewidencji gruntów i budynków (minimum dla działki ewidencyjnej) – w skrócie PZGiK EGiB w zakresie tematu danych

Strona 18 / 35


przestrzennych Działki katastralne do wymagań wynikających z Dyrektywy INSPIRE oraz Ustawy o Infrastrukturze Informacji Przestrzennej. Dokument ten musi, co najmniej zawierać:

3.4.1.1. Analizę zakresu tematycznego danych źródłowych pod kątem "pokrywania" przez nie wymagań, jakie są stawiane zasobowi danych przestrzennych przez przepisy wykonawcze do dyrektywy INSPIRE oraz specyfikacje danych dla tematu danych przestrzennych Działki katastralne. Analiza musi zostać rozszerzona o ewentualną identyfikację pokrywania przez dane źródłowe tematów danych przestrzennych nie wyspecyfikowanych w zamówieniu.

3.4.1.2. Analizę zasad podziału na zbiory danych i serie danych przestrzennych udostępniane w ramach infrastruktury informacji przestrzennej, dla których zasobem źródłowym będą dane PZGIK EGIB, a określonych w rozporządzeniu w sprawie ewidencji gruntów i budynków oraz rozporządzeniu dot. prowadzenia PZGIK.

3.4.1.3. Zdefiniowanie szczegółowych zasad przyporządkowania (mapowanie) obiektów i ich cech z zasobów źródłowych PZGIK EGIB do typów obiektów i ich cech (atrybutu, role asocjacyjne) specyfikowanych w modelach pojęciowych tematu danych przestrzennych Działki katastralne.

3.4.1.4. Zasady mapowania muszą co najmniej zawierać szczegółowe instrukcje tworzenia instancji typów obiektów modeli pojęciowych INSPIRE oraz ich cech na podstawie instancji typów obiektów modelu źródłowego.

3.4.1.5. Opisu transformacji jakim podlegają dane źródłowe (np. zmiana typu danych, zmiana wartości słownikowych, przeliczanie wartości źródłowych atrybutów na wartości określone w modelu INSPIRE, łączenie wartości kilku atrybutów, rozbijanie wartości atrybutu na kilka, inne wykorzystywane podczas harmonizacji danych).

3.4.1.6. Określenie częstotliwości aktualizacji zbiorów danych INSPIRE danymi źródłowymi.

3.4.1.7. Opracowanie tabeli mapowania w formie tabelarycznej.

3.4.1.7.1. Tabele mapowania powinny, co najmniej zawierać: z lewej strony model pojęciowy INSPIRE, zaś z prawej strony zasady ich utworzenia na podstawie obiektów i ich cech z danych źródłowych wraz, jeżeli będzie to zasadne, opisem sposobu ich transformacji (np. zmiana typu danych, zmiana wartości słownikowych, przeliczanie wartości źródłowych atrybutów na wartości określone w modelach INSPIR, łączenie wartości kilku atrybutów, rozbijanie wartości atrybutu na kilka, inne wykorzystywane podczas harmonizacji danych).

3.4.1.8. Zdefiniowanie zasad tworzenia zewnętrznego identyfikatora obiektu oraz unikalnego identyfikatora zasobu zgodnie z wytycznymi INSPIRE, najlepszymi praktykami stosowanymi w krajowych i światowych infrastrukturach informacji przestrzennej. Identyfikator obiektu musi być zgodny ze schematem HTTP URI.

3.4.1.9. Zdefiniowanie stylów wyświetlania dla publikacji danych za pomocą standardu SLD.

3.5. Opracowanie strategii implementacji usługi pobierania INSPIRE dla zidentyfikowanych zbiorów danych z uwzględnieniem następujących wariantów usługi: WMS, ATOM, WFS, WFS, Hybrydowa: ATOM+WFS.

3.6. Opracowanie i weryfikacja metody eksportu danych do formatu GML.

Strona 19 / 35


4. Wykonawca Zamówienia jest zobowiązany do bieżącego śledzenia aktualność wymagań związanych z implementacją Dyrektywy INSPIRE w szczególności modeli pojęciowych, schematów aplikacyjnych, wytycznych ramowych (General Conceptual Model) oraz formatów wymiany danych w zakresie tematu Działki katastralne.

4.1. W trakcie realizacji zamówienia wykonawca jest zobowiązany do aktualizacji dokumentu DAP, w tym w szczególności metodyki harmonizacji, o ile nastąpią zmiany w wymaganiach wynikających z wdrażania Dyrektywy INSPIRE.

3.1.3 Etap 3: Zaimplementowanie i wdrożenie narzędzi do aktualizacji danych w modelu INSPIERE

Zadanie: Opracowanie prototypu rozwiązania

1. W ramach zadania Wykonawca stworzy laboratorium (inaczej też środowisko testowe) Systemu LIIP w infrastrukturze Zamawiającego wyposażone w odpowiednie narzędzia do harmonizacji i publikacji zbiorów danych przestrzennych, w którym możliwe będzie przetestowanie założeń przygotowywanych w ramach metodyki harmonizacji. Laboratorium musi być skonfigurowane i uruchomione na podstawie zaoferowanego przez Wykonawcę Oprogramowania.

1.1. Dla zagadnień dot. modelowania w UML dopuszcza się użycie oprogramowania CASE, które nie stanowi przedmiotu dostawy dla Zamawiającego.

2. Testowanie przeprowadzone zostanie na podstawie wybranych przez Zamawiającego zbiorów danych źródłowych z zakresu tematu Działki katastralne.

3. Laboratorium testowe musi obejmować procedury harmonizacji i publikacji danych reprezentatywne dla wszystkich wytypowanych wariantów implementacji usług pobierania, o których mowa jest DAP.

4. Prace laboratorium testowego będą przebiegać równolegle do prac Zadania Opracowanie dokumentacji analityczno-projektowej oraz będą mieć charakter iteracyjny.

5. Testowanie musi weryfikować wyniki założeń procedury harmonizacji oraz dostarczać informacje umożliwiające dostosowywanie jej założeń do rzeczywistych problemów napotkanych podczas testowania.

6. Testowanie ma charakter iteracyjny, zakłada się maksymalnie 2-3 iteracje dla procedury harmonizacji i publikacji dla każdego wytypowanego zbioru danych, przy czym ostatnia iteracja może mieć już charakter (częściowego) odbioru prac.

7. W wyniku każdej z iteracji powstanie dokument raport z testowania zawierający co najmniej szczegółowy opis wytypowanych zbiorów danych oraz działań o charakterze transformacyjnych i integracyjnych, jakie przeprowadzono na tych zbiorach danych. Dokument musi zawierać również podsumowanie zastosowania metodyki harmonizacji w postaci wniosków do jej ewentualnej modyfikacji.

8. Decyzję o uruchomieniu określonej iteracji podejmuje Zamawiający na podstawie wyników z raportu z testów.

9. Produktem ostatniej iteracji będą zbiory danych przestrzennych wytypowane do testowania opublikowane za pomocą usługi sieciowej przeglądania i pobierania zgodnie z wymaganiami INSPIRE.

Strona 20 / 35


10. Produkt ostatniej iteracji będzie podlegać odbiorowi przez Zamawiającego. Wówczas testy mają charakter testów akceptacyjnych i ich wynik stanowi podstawę odbioru prac Wykonawcy.

11. Testy Rozwiązania tj. komponentu LIIP muszę być prowadzone z uwzględnieniem wymagań, jakie określa w tym zakresie Dodatek nr 3 – Testowanie prototypu komponentu LIIP.

Zadanie Wytworzenie, dostarczenie, instalacja, konfigurowanie i wdrożenie narzędzi do harmonizacji danych INSPIRE

1. W ramach tego zadania Wykonawca wytworzy i dostarczy niezbędne narzędzia do harmonizacji i publikacji za pośrednictwem usług sieciowych zbiorów danych przestrzennych określonych w metodyce harmonizacji w DAP. Niniejsze zadanie Wykonawca musi wykonywać w oparciu o wyniki zadani dot. Opracowania prototypu rozwiązania.

2. W ramach tego zadania Wykonawca dostarczy lub opracuje w szczególności:

2.1. Oprogramowanie do harmonizacji źródłowych zbiorów danych objętych zamówieniem dostarczające funkcjonalności w zakresie technologii ETL (ang. Extract, Transform, Load), co najmniej umożliwiające:

2.1.1. Zastosowanie metodyki harmonizacji, o której mowa w DAP.

2.1.2. Modelowanie procesów przepływów agregacji, transformacji i ładowania danych (na podstawie określonych parametrów) z różnych heterogenicznych źródeł danych mających różne formaty, w tym:

2.1.2.1. Import danych źródłowych z plików wymiany lub bezpośrednio z baz danych;

2.1.2.2. Obsługa systemów zarządzania bazą danych (odczyt): Oracle, MySQL, MS SQL Server, PostgreSQL, MS Access;

2.1.2.3. Obsługa formatów danych MDB, DBF, XLS, TXT, CSV, XML, GML (odczyt);

2.1.2.4. Obsługa systemu zarządzania bazą wykorzystywanych przez serwery usług danych przestrzennych (zapis).

2.1.3. Konfigurację i graficzne modelowanie procesów, w szczególności wczytanie struktur danych źródłowych i wynikowych oraz wykonanie mapowania danych wraz ze zdefiniowaniem warunków ich przetwarzania i konwersji.

2.1.4. Załadowanie, przetwarzanie, aktualizacja oraz usunięcie danych w docelowej bazie danych za pośrednictwem procesów ETL.

2.1.5. Wykonanie wszystkich niezbędnych transformacji i przekształceń dla celów harmonizacji.

2.1.6. Uruchamianie procedury aktualizacji w następujących trybach: wywołanie „ręcznie” przez administratora (np. po przekazaniu danych), wywołanie z poziomu systemu dziedzinowego (np. po aktualizacji danych w systemie), wywołanie automatyczne, zgodnie ze zdefiniowanym harmonogramem aktualizacji.

2.1.7. Wykonanie:

2.1.7.1. transformacji warunkowych;

Strona 21 / 35


2.1.7.2. transformacji układów współrzędnych zdefiniowanych w rozporządzeniu Rady Ministrów z 15 października 2012 r. w sprawie państwowego systemu odniesień przestrzennych (Dz. U. z 2012 r. poz. 1247) oraz wymaganych przez dyrektywę INSPIRE.

2.1.7.3. nowych transformacji i zmiany konfiguracji istniejącej transformacji;

2.1.7.4. modyfikacji/aktualizacji/usuwania istniejących danych zgromadzonych w bazie publikacyjnej;

2.1.7.5. przetwarzania danych pozwalające na uzgadnianie identyfikatorów obiektów, tworzenie referencji do obiektów, wykonywanie operacji przestrzennych na danych;

2.1.7.6. konwersji danych pozwalająca na geokodowanie danych, zmianę formatu geometrii;

2.1.7.7. tworzenia warunków kontroli poprawności danych źródłowych.

2.1.8. Wykonanie kontroli danych wejściowych obejmującą co najmniej następujące czynności:

2.1.8.1. Kontrola schematu danych;

2.1.8.2. Kontrola reguł poprawności atrybutów opisowych:

2.1.8.2.1. wypełnienie wymaganych atrybutów;

2.1.8.2.2. unikalność atrybutów;

2.1.8.2.3. relacje między obiektami;

2.1.8.2.4. zgodność atrybutów ze słownikami;

2.1.8.2.5. inne reguły poprawności atrybutów opisowych (np. wartości minimalnych lub maksymalnych danego atrybutu, zależności między różnymi atrybutami, wymaganego formatu atrybutu);

2.1.8.3. Kontrolę topologii danych geometrycznych;

2.1.8.4. Kontrolę zgodności cech geometrycznych lub położenia obiektów z wartościami atrybutów opisowych (np. kontrola czy obiekt znajduje się w obrębie gminy, której nazwę ma wpisaną w atrybucie opisowym).

2.1.8.5. Kontrole jakości danych w zakresie możliwości utworzenia zharmonizowanych zbiorów danych zgodnie z metodyką harmonizacji.

2.1.9. Raportowanie z procesu kontroli, zasilania i aktualizacji zasobów danych zawierające szczegółowe informacje dot. zaistniałych błędów tj. zwracające identyfikator obiektu wraz z operacją zwracającą błąd.

2.1.10. Cykliczną aktualizację zharmonizowanych danych zgodnie z zasadami zdefiniowanymi w rozporządzeniach wykonawczych oraz wytycznych technicznych do Dyrektywy INSPIRE.

2.2. Infrastrukturę szyny usług, której implementacja zapewni spełnienie wymagań, jakie zawiera Dodateknr 1 – Założenia koncepcyjne i techniczne dotyczące infrastruktury technicznej w zakresie tzw. SzynyUsług ;

Strona 22 / 35


2.3. Generator plików GML umożliwiający generowanie plików GML zgodnych ze schematami aplikacyjnymi GML właściwymi dla tematu danych przestrzennych Działki katastralne, co najmniej umożliwiające:

2.3.1. Integrację procesu generowania plików GML z procesem aktualizacji danych w docelowej bazie danych.

2.3.2. Automatyczne generowanie zestawu plików GML dla wszystkich danych objętych pojedynczym zbiorem danych przestrzennych.

2.3.3. Generowanie plików GML dla danych przechowywanych w docelowej bazie danych.

2.3.4. Konfigurowalność generowanych zestawów plików GML, co najmniej w zakresie wynikającym ze standardu ISO 19143:2010 - Geographic information – Filter encoding.

2.4. Serwer danych przestrzennych umożliwiający zarządzanie i publikację usług sieciowych.

2.4.1. Serwer usługi ATOM - komponent systemu odpowiedzialny za zarządzanie i udostępnianie (publikację) usług ATOM, jako usługi pobierania INSPIRE predefiniowanych zbiorów danych. Serwer usługi ATOM musi:

2.4.1.1. wspierać funkcjonalność serwera usługi ATOM zgodnego z wymaganiami zdefiniowanymi w Technical Guidance for the implementation of INSPIRE Discovery Services ver.3.1. oraz Technical Guidance for implementation of INSPIRE Download Services ver. 3.1.

2.4.1.2. umożliwiać działanie wielu instancji usługi ATOM.

2.4.1.3. opublikowanie predefiniowanych zbiorów danych w postaci GML (w wersji wymaganej w INSPIRE, w tym w postaci plików danych generowanych przez Generator plików GML).

2.4.1.4. zapewniać konfigurację poprzez dedykowane narzędzie GUI (interfejs użytkownika) oraz konfigurację elementów Top Atom Feed i Dataset Atom Feed.

2.4.1.5. wspierać wymagania związane z implementacją standardu OpenSearch.

2.4.2. Serwer usługi WFS - komponent sytemu odpowiedzialny za zarządzanie i udostępnianie (publikację) usług WFS, jako usługi pobierania INSPIRE predefiniowanych zbiorów danych oraz z bezpośrednim dostępem do obiektów. Serwer usługi WFS musi:

2.4.2.1. wspierać funkcjonalność serwera usługi WFS, zgodnego z wymaganiami zdefiniowanymi w Technical Guidance for the implementation of INSPIRE Discovery Services ver.3.1 oraz wymaganiami standardu OpenGIS Web Feature Service 2.0 Interface Standard – With Corrigendum.

2.4.2.2. umożliwiać utworzenie wielu instancji usługi WFS.

2.4.2.3. zapewnić konfigurację elementów Capabilities

2.4.2.4. zapewniać zarządzanie zakresem publikowanych danych z bazy publikacyjnej w strukturach zgodnych z modelem INSPIRE.

2.4.3. Serwer usługi WMS - komponent sytemu odpowiedzialny za zarządzanie i udostępnianie (publikację) usług WMS, jako usługi przeglądania INSPIRE. Serwer usługi WFS musi:

Strona 23 / 35


2.4.3.1. wspierać funkcjonalność serwera usługi WFS, zgodnego z wymaganiami zdefiniowanymi w Technical Guidance for the implementation of INSPIRE Discovery Services ver.3.1.

2.4.3.2. umożliwiać utworzenie wielu instancji usługi WMS.

2.4.3.3. zapewnić konfigurację elementów Capabilities

2.4.3.4. zapewniać zarządzanie zakresem publikowanych danych z bazy publikacyjnej w strukturach zgodnych z modelem INSPIRE.

Zadanie Opracowanie metadanych

1. W ramach tego zadania Wykonawca opracuje metadane dla:

1.1. zbiorów danych przestrzennych określonych w metodyce harmonizacji w DAP;

1.2. zaimplementowanych usług sieciowych.

2. Pliki metadanych zostaną utworzone w formacie XML zgodnie z Rozporządzeniem Komisji (WE) nr 1205/2008 z dnia 3 grudnia 2008 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie metadanych oraz wytycznymi technicznymi INSPIRE (Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 v2.0.1) lub innym, który będzie obowiązywać na datę przekazania plików do Zamawiającego

2.1. Pliki metadanych przed przekazaniem do Zamawiającego muszą być poprawnie zwalidowane za pomocą walidatora metadanych Komisji Europejskiej (http://inspire.ec.europa.eu/validator/).

Zadanie Uruchomienie procesu harmonizacji danych INSPIRE

1. W ramach tego zadania Wykonawca wykona harmonizację i publikację za pośrednictwem usług sieciowych zbiorów danych przestrzennych określonych w metodyce harmonizacji w DAP. Zadanie to zostanie wykonane, w oparciu o zdefiniowaną, przetestowaną metodykę harmonizacji, za pomocą zaimplementowanych narzędzi i wykonanej konfiguracji dostarczonego rozwiązania.

2. Przed uruchomieniem procesu harmonizacji danych Wykonawca przeprowadzi dla Zamawiającego instruktaż techniczny w formie prezentacji z opracowanych, dostarczonych narzędzi do harmonizacji danych INSPIRE.

3.1.4 Etap 4: Przeprowadzenie Odbioru Końcowego

1. W ramach Odbioru Końcowego Zamawiający dokona weryfikacji oraz potwierdzenia wypełnienia przez Wykonawcę wszystkich zobowiązań, jakie były przedmiotem realizacji niniejszego zamówienia.

2. W trakcie tych czynności Wykonawca jest zobowiązany do ścisłego współdziałania z Zamawiającym, w tym składania niezbędnych wyjaśnień oraz skutecznego i niezwłocznego wypełnienia potencjalnie niezrealizowanych, zaległych zobowiązań.

3. W trakcie Odbioru Końcowego zamówienia, Wykonawca udzieli Zamawiającemu gwarancji jakości wykonania usługi zgodnie z Ofertą Wykonawcy na okres co najmniej 3 lat od daty odbioru zamówienia, liczony od daty Odbioru Końcowego. Jednocześnie Wykonawca złoży oświadczenie, iż wykonane przez niego usługi realizują cele przedmiotowego zamówienia, są kompletne z punktu widzenia przedmiotu oraz,

Strona 24 / 35

http://inspire.ec.europa.eu/validator/

http://eur-lex.europa.eu/legal-content/PL/AUTO/?uri=celex:32008R1205


iż zostało prawidłowo wykonane zgodnie z wymaganiami określonymi w OPZ, a także zgodnie z wytycznymi jakie zostały przekazane Wykonawcy przez Zamawiającego w trakcie realizacji zamówienia.

4. W ramach udzielonej gwarancji i okresie jej obowiązywania Wykonawca jest zobowiązany do świadczenia usług gwarancyjnych i serwisowych na zasadach określonych w Dodatku nr 1 do niniejszej specyfikacji.

5. Wszelkie niezbędne korekty, uzupełnienia, jakie wynikają z wezwania Zamawiającego, Wykonawca jest zobowiązany wprowadzić do przedmiotu zamówienia (produktów i rezultatów zamówienia) i przekazać Zamawiającemu w terminie i w formie właściwej, jaka została określona w opisie przedmiotu zamówienia w SIWZ.

3.2 Wymagania prawne

1. Przedmiot realizacji zamówienia w każdym zakresie musi być zgodny z obowiązującymi przepisami prawa, co w szczególności dotyczy takich przepisów prawa jak:

Ustawa z 17 maja 1989 r. Prawo geodezyjne i kartograficzne (t.j. Dz. U. z 2020 r. poz. 276, z późn. zm.),

Ustawa z 4 marca 2010 r. o infrastrukturze informacji przestrzennej (t.j. Dz. U. z 2020 r., poz. 177 z późn. zm.),

Ustawa z 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (t.j. Dz. U. z 2020 r. poz. 346 z późn. zm.),

Ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. z 2019 r. poz. 848),

Rozporządzenia:

Rozporządzenie Ministra Rozwoju Regionalnego i Budownictwa z 29 marca 2001 r. w sprawie ewidencji gruntów i budynków (t.j. Dz. U. z 2019 r., poz. 393 z późn. zm.),

Rozporządzenie Rady Ministrów z 15 października 2012 r. w sprawie państwowego systemu odniesień przestrzennych (Dz. U. z 2012 r. poz. 1247),

Rozporządzenie Rady Ministrów z 10 stycznia 2012 r. w sprawie państwowego rejestru granic i powierzchni jednostek podziałów terytorialnych kraju (Dz. U. z 2012 r. poz. 199),

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),

Rozporządzenie Ministra Administracji i Cyfryzacji z 14 lutego 2012 r. w sprawie państwowego rejestru nazw geograficznych (Dz. U. z 2015 r. poz. 219 ),

Rozporządzenie Rady Ministrów z 17 lipca 2001 r. w sprawie wykazywania w ewidencji gruntów i budynków danych odnoszących się do gruntów, budynków i lokali, znajdujących się na terenach zamkniętych (Dz. U. z 2001 r. Nr 84, poz. 911),

Rozporządzenie Rady Ministrów z 12 września 2012 r. w sprawie gleboznawczej klasyfikacji gruntów (Dz. U. z 2012 r. poz. 1246),

Rozporządzenia Ministra Administracji i Cyfryzacji z 5 września 2013 r. w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego (Dz. U. z 2013 r. poz. 1183),

Rozporządzenie Rady Ministrów z 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz. U. z 2018 r. poz. 29),

Rozporządzenie Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (KRI), minimalnych wymagań dla rejestrów publicznych i wymiany informacji w

Strona 25 / 35


postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2017 r. poz.2247),

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z 20 października 2010 r. w sprawie ewidencji zbiorów i usług danych przestrzennych objętych infrastrukturą Informacji przestrzennej (Dz. U. z 2010 r. Nr 201, poz. 1333 z późn. zm.),

Przepisy unijne:

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) zwane dalej RODO,

Dyrektywa 2007/2/WE Parlamentu Europejskiego i Rady z 14 marca 2007 r. ustanawiająca infrastrukturę Informacji przestrzennej we Wspólnocie Europejskiej (INSPIRE) (Dz. U. UE. L. 2007.108.1 z późn. zm.),

Rozporządzenie Komisji (WE) NR 976/2009 z dnia 19 października 2009 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie usług sieciowych i Rozporządzeniem Komisji (WE) NR 1205/2008 z dnia 3 grudnia 2008 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie metadanych,

Rozporządzenie Komisji (UE) nr 1089/2010 z dnia 23 listopada 2010 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie interoperacyjności zbiorów i usług danych przestrzennych (tekst skonsolidowany)

Specyfikacja danych dla tematu Działki katastralne - INSPIRE Technical Documentation for “D2.8.I.6 Data Specification on Cadastral Parcels – Technical Guidelines” version 3.1 https://inspire.ec.europa.eu/id/document/tg/cp

3.3 Wymagania wobec dostarczanej przez Wykonawcę dokumentacji

1. W każdym przypadku, kiedy następować będzie przekazanie dokumentacji opracowanej przez Wykonawcę, musi być ona przekazana w formie papierowej, w liczbie jednego egzemplarza z każdego rodzaju oraz w formie elektronicznej przesłana drogą elektroniczną na adres e-mail Zamawiającego, Przedstawiciela Zamawiającego lub przekazana na nośniku CD-ROM, i tak dla:

1.1. dokumentacji w formie opracowania w formacie edytowalnym: odf lub doc / docx oraz zabezpieczonym przed edycją formacie PDF dla programu Acrobat Reader.

1.2. wyników prac w formie arkusza kalkulacyjnego w formacie MS Excel w formacie XLS, XLSX.

1.3. modelu UML w formacie natywnym używanego przez Wykonawcę oprogramowania CASE oraz w formacie wymiany danych UML – UXF lub innym równoważnym.

Strona 26 / 35

https://inspire.ec.europa.eu/id/document/tg/cp


1 Dodatek nr 1 – Założenia koncepcyjne i techniczne dotyczące infrastruktury technicznej w zakresie tzw. Szyny Usług

1.1 Ogólna architektura Jednym z podstawowych założeń budowy infrastruktury informacji przestrzennej jest jej zorientowanie na usługi. Architektura tych usług bazuje na koncepcji SOA, gdzie szczególną rolę pełni magistrala usług (ang. Service Bus), na której poszczególne węzły udostępniają własne usługi lub też za pośrednictwem, której uzyskują dostęp do usług wystawionych przez inne węzły. Magistrala ma charakter generyczny – co oznacza, że usługi są bytami wykorzystywanymi przez aplikacje. Użytkownik IIP „widzi je” poprzez graficzny interfejs aplikacji posiadającej zdolność do komunikacji z usługami, zgodnie z określonymi protokołami oraz interfejsami programowymi usług.

Rysunek 2 Architektura usług sieciowych INSPIRE [Źródło: Recommendations for INSPIRE Spatial Data Services v1.1, 2011]Wymagania wobec usług oraz pośrednio Szyny Usług określa w szczególności:

a. Rozporządzenie Komisji (UE) nr 1088/2010 z dnia 23 listopada 2010 r. zmieniające rozporządzenie (WE) nr 976/2009 w zakresie usług pobierania i usług przekształcania. http://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32010R1088

b. Rozporządzenie Komisji (UE) nr 976/2009 z dnia 19 października 2009 r. w sprawie wykonania dyrektywy 2007/2/WE Parlamentu Europejskiego i Rady w zakresie usług sieciowych, które określa wymogi dotyczące tworzenia i utrzymywania usług sieciowych.

Zgodnie z Artykuł 3 rozporządzenia (nr 976/2009), usługi sieciowe muszą spełniać ustalone wymogi w zakresie jakości świadczenia usług określone w załączniku 1 do przedmiotowego rozporządzenie (w zakresie zmienionym rozporządzeniem nr 1088/2010), w którym to zdefiniowano wymagania wobec jakości, wydajności, przepustowości oraz dostępności usług. Zapewnienie tak określonych wymagań oraz ustalonych dla nich ilościowych kryteriów jakościowych miało na celu uniknięcie „ … potencjalnego obniżenia jakości ze względu na efekt kaskadowy …”. Treść tych istotnych wymagań przywołano poniżej w całości w pierwotnej ich postaci, zgodnie z treścią załącznika nr 1 rozporządzenia zmieniającego:

Strona 27 / 35

http://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32010R1088

http://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32010R1088


„ 1. WYDAJNOŚĆ - Normalne warunki to warunki panujące poza okresami szczytowego obciążenia. Przyjmuje się, że występują one przez 90 % czasu. Czas odpowiedzi potrzebny do przesłania odpowiedzi wstępnej na polecenie usługi wyszukiwania wynosi maksymalnie 3 sekundy w normalnych warunkach.W przypadku obrazu wielkości 470 kilobajtów (np. 800 × 600 pikseli przy głębi koloru 8 bitów) czas potrzebny do przesłania odpowiedzi wstępnej na polecenie »Uzyskaj mapę« w usłudze przeglądania wynosi maksymalnie 5 sekund w normalnych warunkach.W przypadku operacji »Uzyskaj metadane usługi pobierania« czas potrzebny do przesłania odpowiedzi wstępnej wynosi maksymalnie 10 sekund w normalnych warunkach.W przypadku operacji »Uzyskaj zbiór danych przestrzennych« i operacji »Uzyskaj obiekt przestrzenny« oraz zapytania zawierającego wyłącznie prostokąt ograniczający czas potrzebny do przesłania odpowiedzi wstępnej wynosi maksymalnie 30 sekund w normalnych warunkach, a dla usługi pobierania, również w normalnych warunkach, utrzymuje się stałą szybkość odpowiedzi większą niż 0,5 megabajta na sekundę lub większą niż 500 obiektów przestrzennych na sekundę.W przypadku operacji »Opisz zbiór danych przestrzennych« i operacji »Opisz typ obiektu przestrzennego« czas potrzebny do przesłania odpowiedzi wstępnej wynosi maksymalnie 10 sekund w normalnych w warunkach, a dla usługi pobierania, również w normalnych warunkach, utrzymuje się średnią szybkość odpowiedzi większą niż 0,5 megabajta na sekundę lub większą niż 500 opisów obiektów przestrzennych na sekundę.2. PRZEPUSTOWOŚĆMinimalna liczba obsługiwanych jednocześnie poleceń dotyczących usługi wyszukiwania zgodnie z jakością usługi w zakresie kryteriów wydajności wynosi 30 na sekundę.Minimalna liczba obsługiwanych jednocześnie poleceń dotyczących usługi przeglądania zgodnie z jakością usługi w zakresie kryteriów wydajności wynosi 20 na sekundę.Minimalna liczba obsługiwanych jednocześnie poleceń dotyczących usługi pobierania zgodnie z jakością usługi w zakresie kryteriów wydajności wynosi 10 na sekundę. Liczbę jednocześnie realizowanych poleceń można ograniczyć do 50.Minimalna liczba obsługiwanych jednocześnie poleceń dotyczących usługi przekształcania zgodnie z jakością usługi w zakresie kryteriów wydajności wynosi 5 na sekundę.3. DOSTĘPNOŚĆPrawdopodobieństwo uzyskania dostępu do usługi sieciowej w danym czasie wynosi 99 %.”

1.2 Założenia techniczne W tak przedstawionej koncepcji infrastruktura komunikacyjna usług danych przestrzennych, inaczej Szyna Usług jest centralnym elementem systemu świadczącego usługi danych przestrzennych IIP.Szyna pośredniczy w komunikacji pomiędzy poszczególnymi komponentami / systemami dziedzinowymi oraz systemami zewnętrznymi poprzez udostępnienie usług sieciowych, a w szczególności usług danych przestrzennych. W takim rozwiązaniu infrastruktura komunikacyjna Szyny Usług musi spełniać wymagania techniczne jakie wynikają z obowiązujących w tym zakresie przepisów prawa tak, aby zapewnić osiągnięcie mierzalnych ilościowo kryteriów jakości świadczenia usług danych przestrzennych, dostarczając w tym celu:

narzędzia do zarządzania usługami,

mechanizmy zapewnienia ciągłości ich działania,

narzędzia do monitorowania,

mechanizmy zapewnienia skalowalności usług, co odnosi się do skalowalności infrastruktury systemowej, na której zostanie oparta implementacja szyny usług (np. jednym z rozwiązań może być instancyjność usług – obsługa wielu instancji maszyn wirtualnych szyny danych przestrzennych).

Strona 28 / 35


Powyższe ogólne wymagania wskazują, iż typowa szyna usług ESB (ang. Enterprise Service Bus) w swoim „standardowym rozwiązaniu” może nie spełnić tak określonych wymagań w obszarze chociażby:

ciągłego przesyłania danych binarnych, co dla protokołów takich jak WMS, WMST stanowi podstawę ich działania;

stałego przesyłania dużych paczek danych tekstowych np. dla usług pobierania takich jak np. ATOM i przesyłanych dużych plików GML;

działania w trybie synchronicznym, co w przypadku protokołu WMTS i serwisów cache jest kluczowym element wpływającym na opóźnienie dostarczenia odpowiedzi do klienta usługi (przeglądarki).

Uwzględnienie powyższych tego rodzaju wymagań, przekłada się na szerszy zakres funkcji i rozwiązań, niż ten jaki dostarcza typowa infrastruktura ESB – głównie chodzi tutaj o dedykowane do tego celu usługi obsługi określonych protokołów (jak WMS, WMTS) w zakresie obsługi komunikacji, bezpieczeństwa, transformacji, konwersji i walidacji usług. Dodatkowo, uwzględniając w koncepcji budowy rozwiązań Szyny Usług optymalizację kosztów tworzenia infrastruktury IIP oraz tworzenia infrastruktury Systemu PZGiK, w tym potrzeby rozliczalności świadczenia usług, o których mowa w przepisach Rozporządzenia Ministra Administracji i Cyfryzacji w sprawie organizacji i trybu prowadzenia państwowego zasobu geodezyjnego i kartograficznego z dnia 5 września 2013 r. (Dz.U. z 2013 r. poz. 1183), gdzie między innymi § 7.2 ppkt. 7) przedmiotowego rozporządzenia nakłada obowiązek na System PZGIK w zakresie „ …wsparcia procesów udostępniania materiałów zasobu, w tym drogą elektroniczną, a w szczególności za pomocą usług sieciowych” - można wskazać, iż Szyna Usług musi spełniać również następujące dodatkowe funkcje infrastruktury komunikacyjnej szyny danych / usług jak:

1. Dowolne konfigurowanie punktów końcowych (endpoint) usług (routing),

2. Obsługę proxy dla wystawianych usług (sieciowych, w tym w szczególności danych przestrzennych);

3. Monitorowanie pracy infrastruktury (usług), przepływów, treści przesyłanych wiadomości, włącznie z stałym procesem generowania statystyk oraz wizualizacji statystyk. Funkcje monitorowania powinny zapewniać możliwość bieżącego monitorowania (online) poszczególnych usług w zakresie ilości zapytań oraz ilości przesłanych danych oraz wizualizacja tych danych na w formie wykresu. Statystyki powinny być dostępne dla wybranego zakresu czasu i usług w formie zestawień zawierających min. następujące informacje nt.:

Ilości zapytań (requestów) do danej usługi w jednostce czasu wraz z ilością przesłanych danych, Lista najbardziej aktywnych adresów IP wraz liczbą requestów oraz ilością przesłanych danych, Możliwość zapisywania statystyk do pliku zewnętrznego celem udokumentowania funkcji

raportowania (format: PDF, DOCX) 4. Konwersję - zmianę protokołu dla wspieranych/obsługiwanych protokołów, możliwość konwersji

pomiędzy wymaganymi formatami,

5. Zrównoważenie obciążenia usług poprzez rozłożenie ruchu na wiele instancji usług (loadbalancing),

6. Zabezpieczenie infrastruktury przed awariami związanymi z atakami hackerów,

7. Weryfikację tożsamości użytkownika lub systemu przez uwierzytelnienie oraz autoryzację w oparciu o ustalony (wymagane) jeden system zabezpieczenia usług oparty np. o protokół SAML oraz mechanizmy jednokrotnego logowania, bazujące w tym zakresie o usługi katalogowe wielu lub jednego katalogu LDAP (np. DNS, Open LDAP, innych), inaczej WebSSO (Przy takim podejściu zakłada się, że wszyscy użytkownicy mogą posiadać pojedyncze dane uwierzytelniające (np. zachowane w katalogu LDAP), co skracałoby czas poświęcany na rejestrację i logowanie dla użytkownika. Poza tym wszystkie procesy mogłyby wtedy używać wspólnej bazy służącej do uwierzytelnienia i autoryzacji użytkowników).

Dodatkowo tak rozumiana infrastruktura Szyny Usług, w zakresie wsparcia usług danych przestrzennych musi zapewnić z punktu widzenia rozliczalności usług - dostępność „funkcji ograniczających”, takich jak:

Strona 29 / 35


zasięg przestrzenny udostępnianych danych;

okres i czas świadczenia usługi;

opcjonalnie - wykorzystanie danych przez wprowadzenie znaku wodnego dla publikowanych danych binarnych.

Funkcje te muszą być konfigurowalne dla każdej jednostkowo uruchamianej usługi.

Strona 30 / 35


4 Dodatek nr 2 – Usługi gwarancji i serwisu

4.1 Zdalny dostęp do Infrastruktury Technicznej ZamawiającegoZamawiający może zapewnić Wykonawcy zdalny dostęp do jego Infrastruktury Technicznej celem realizacji przez niego przedmiotu zamówienia oraz świadczenia usług gwarancyjnych i serwisowych pod następującymi warunkami dostęp dla Wykonawcy możliwy będzie wyłącznie po podpisaniu przez Wykonawcę oświadczenia o zapewnieniu i wypełnieniu podczas realizacji zamówienia zasad określonych przez obowiązującą w organizacji Zamawiającego politykę bezpieczeństwa informacji (PBI), przy uwzględnieniu, iż:

zdalny dostęp do Infrastruktury Technicznej poprzez łącze VPN posiadać będzie wyłącznie określona liczba osób podana w przekazanym i zaakceptowanym przez Zamawiającego wykazie osób: /imię/nazwisko/e-mail/tel/firma – o ile jest to podwykonawca;

dostęp będzie realizowany na żądanie lub w trybie określonym przez harmonogram ustalonych „okien czasowych”;

dostęp do zasobów będzie realizowany poprzez VPN poprzez konta imienne aktywowane w oparciu o harmonogram;

naruszenie przez Wykonawcę przyjętych przez niego zasad dostępu może skutkować stałym lub czasowym zablokowaniem dostępu zdalnego.

4.2 Usuwanie błędów oprogramowaniaNa potrzeby świadczenia usług z zakresu udzielonej przez Wykonawcę gwarancji jakości wykonania Umowy, w tym zapewnienia usług serwisowych Zamawiający określa poniżej główne zasady świadczenia przedmiotowych usług. Wszystkie działania Wykonawcy w zakresie usuwania błędów i nieprawidłowego działania dostarczonego, opracowanego Rozwiązania (komponentu LIIP) objęte niniejszą procedurą, mieszczą się w ramach należnego i zapłaconego Wykonawcy wynagrodzenia.

1. Do obsługi usług gwarancyjnych i serwisowych przyjmuje się następujące kategorie błędów:

1.1. B1 – błędy krytyczne – to stan, w którym nie jest możliwe korzystanie z wdrożonego przez Wykonawcę Rozwiązania / komponentu LIIP w zakresie Oprogramowania lub występuje jego nieprawidłowe działanie niezgodnie z Dokumentacją ograniczające możliwości z jego korzystania w taki sposób, iż przestaje ono spełniać cele i podstawowe funkcje Rozwiązania. Do błędów krytycznych mających szerokie, negatywne oddziaływanie należy zaliczyć w szczególności błędne działania lub brak działania infrastruktury Szyny Usług. Błędy te wymagają natychmiastowej interwencji Wykonawcy związanej z zidentyfikowaniem ich przyczyny oraz usunięciem błędu lub wprowadzeniem rozwiązania zastępczego w formie tzw. „Obejścia”, przez rekonfigurację, wymianę oprogramowania lub inne zaproponowane przez Wykonawcę rozwiązanie zapewniające dostępność Systemu lub określonej jego części w zakresie funkcjonalności.

1.2. B2 – błędy poważne, powodujące niepoprawne funkcjonowanie Rozwiązania / Systemu LIIP lub dostarczonych przez Wykonawcę komponentów i usług sieciowych, niezaliczone do klasy B1;

1.3. B3 – usterki / wady przejawiające się niewłaściwą ergonomią pracy lub błędną logiką obsługi, niewpływające na rezultat działania usług, funkcji Systemu LIIP, niezaliczane do kategorii błędów B1

Strona 31 / 35


lub B2 np. wydłużenie czasu autoryzacji lub uwierzytelnienia usługi, brak spełnienia wymagań wydajnościowych, niespełnienie wymagań dot. ergonomii pracy, inne.

2. Podana powyżej kategoryzacja błędów może być doprecyzowana przez Wykonawcę i zaakceptowana przez Zamawiającego podczas opracowania „Planu Realizacji Zamówienia”.

3. Każda z ww. kategorii błędów wymaga interwencji Wykonawcy związanej z zidentyfikowaniem przyczyny oraz usunięciem błędu lub wprowadzeniem tzw. „Obejścia” przez rekonfigurację Oprogramowania lub uruchomienia usług po stronie infrastruktury „Punktu Końcowego” lub inne podejście zaproponowane przez Wykonawcę mające na celu rozwiązanie powstałego problemu, zapewniające dostępność oraz działanie usług Rozwiązania / komponentu LIIP.

4. Dla ww. kategorii błędów ustala się następujące czasy reakcji oraz czasy usunięcia błędu, liczone odpowiednio od daty / godziny przesłania zgłoszenia przez Zamawiającego dla czasu reakcji oraz od daty / godziny przyjęcia przez Wykonawcę zgłoszenia i końca biegu czasu reakcji:

4.1. B1 – czas reakcji – 8 Godziny Roboczych, czas usunięcia błędu – 24 Godziny Robocze,

4.2. B2 – czas reakcji – 8 Godzin Roboczych, czas usunięcia błędu – 5 Dni Roboczych,

4.3. B3 – czas reakcji – 8 Godzin Roboczych, czas usunięcia błędu – 10 Dni Roboczych.

5. Zgłoszenie błędu kierowane jest do Wykonawcy na adres i kontakt podany w umowie lub może być wprowadzone i zarejestrowane w systemu „Help Desk” Wykonawcy, o ile taki system został przez niego wskazany w ramach Oferty lub został wskazany na etapie opracowania Planu Realizacji Zamówienia.

5.1. Przyjęcie w ramach niniejszej procedury rozwiązań opartych o system Help Desk Wykonawcy jest możliwe wyłącznie w przypadku kiedy system ten zapewni działanie przedmiotowej procedury w zakresie nie sprzecznym z określonym w tym dokumencie i na warunkach nie gorszych niż te określone przez SIWZ, w tym w szczególności zapewni niezaprzeczalność zdarzeń: zgłoszenia błędu, potwierdzenie – i jego naprawy.

6. Potwierdzeniem wykonania usługi serwisowej i usunięciem usterki jest podpisany przez Strony protokół lub jednostronny protokół podpisany przez przedstawiciela Zamawiającego dokonującego odbioru czynności usunięcia błędu. Czynności związane z podpisem protokołu odbioru mogę odbyć się drogą elektroniczną za potwierdzeniem odbioru wiadomości przez każdą ze Stron.

7. Zgłoszenia będą przekazywane przez Zamawiającego do wskazanego przez Wykonawcę systemu HelpDesk, który musi zapewnić niezaprzeczalność zapisów zgłoszeń oraz ich ciągle monitorowanie. Wymaganym uzupełnieniem kierowanego przez Zmawiającego zgłoszenia do Wykonawcy jest wysłanie informacji do Wykonawcy o dokonaniu zgłoszenia na ustalony w systemie HelpDesk Wykonawcy numer telefonu komórkowego.

8. W świadczeniu usług serwisowych obowiązują następujące definicje:

8.1. Czas reakcji – to czas liczony od daty i godziny potwierdzenia przez Wykonawcę otrzymania zgłoszenia błędu od Zamawiającego, przy czym potwierdzenie to nie może nastąpić później niż w ciągu godziny od daty wysłania zgłoszenia przez Zamawiającego. Potwierdzenie Wykonawcy określa datę i godzinę przystąpienia do usunięcia błędu. W przypadku braku potwierdzenia ze strony Wykonawcy przyjmuje się, jako obowiązujące potwierdzenie zgłoszenia Zamawiającego - godzinę po dacie i czasie zgłoszenia przez Zamawiającego.

Strona 32 / 35


8.2. Czas Naprawy – to czas od daty i godziny przystąpienia Wykonawcy do usunięcia błędu, a datą i godziną dostarczenia poprawki do Oprogramowania usuwającej Błąd w Systemie LIIP. W przypadku dostarczenia poprawki, która nie usuwa Błędu, Czas Naprawy uważa się za niedochowany, chyba, że Zamawiający wcześniej zaakceptuje propozycję „Obejścia”.

8.3. Obejście – przywrócenie działania Oprogramowania do stanu sprzed wystąpienia Błędu, z możliwymi ograniczeniami sposobu korzystania z Oprogramowania, nieuniemożliwiającymi jednak realizację pełnej funkcjonalności Systemu LIPP. Obejście nie stanowi usunięcia Błędu, lecz – o ile zostanie zaakceptowane przez Zamawiającego to wstrzymuje bieg czasu na Naprawę błędu na uzgodniony przez Strony okres czasu - działania „Obejścia” jednak nie dłuższy niż 10 dni roboczych.

9. W sytuacji, w której przyczyna błędu Systemu nie leży bezpośrednio w zakresie możliwości interwencji Wykonawcy, tj. źródłem błędu Systemu są błędy po stronie Infrastruktury Technicznej Zamawiającego - środowiska systemowego niezbędnego do funkcjonowania komponentu LIIP, wówczas na uzasadniony wniosek Wykonawcy, Zamawiający może uzgodnić z Wykonawcą inny, ustalony przez Strony dla danej kategorii błędu czas naprawy. Podstawą do takich działań jest wskazanie przez Wykonawcę bezpośrednio źródła powstania błędu.

Strona 33 / 35


5 Dodatek nr 3 – Testowanie prototypu komponentu LIIP 1. Dla opracowanego prototypu komponentu LIIP Zamawiającego, Wykonawca jest zobowiązany przygotować

Plan Testów zawierający opis scenariuszy testowych dla wszystkich przypadków użycia, jakie zostały zdefiniowane podczas prac analitycznych w Dokumentacji analityczno – projektowej.

2. Plan Testów musi obejmować scenariusze dla ścieżki podstawowej oraz przynajmniej jednej ścieżki alternatywnej.

3. Testy muszą obejmować również weryfikację wymagań funkcjonalnych i niefunkcjonalnych komponentu LIIP, jakie zostały zdefiniowane przez Wykonawcę na podstawie wymagań zawartych w niniejszej specyfikacji oraz tych jakie wynikają bezpośrednio z zapisów OPZ, dotyczy to w szczególności:

3.1. walidacji usług INSPIRE, walidacji danych i metadanych

3.2. weryfikacji wymagań dot. komponentu LIIP w zakresie serwera usług danych przestrzennych oraz Szyny Usług, gdzie wymagania niefunkcjonalne dot. wydajności i / lud dostępność usług powinny być przeprowadzone przy wykorzystaniu dedykowanego do tego celu oprogramowania jak np. Apache Jmeter.

4. Zamawiający wymaga, aby przed rozpoczęciem testów Wykonawca udokumentował przeprowadzenie przez siebie testów wewnętrznych. Testy wewnętrzne mogą być przeprowadzone przez Wykonawcę dla danej konfiguracji komponentu LIIP w Infrastrukturze Technicznej Zamawiającego lub w środowisku systemowym Wykonawcy cechującym się taka samą konfiguracją produktów i usług.

5. Wykonawca jest zobowiązany przygotować i uruchomić laboratorium w terminie wskazanym w Harmonogramie Prac, przy czym, na co najmniej 5 dni roboczych przed datą rozpoczęcia testów prototypu (określonej iteracji), Wykonawca jest zobowiązany przekazać do weryfikacji Zamawiającego Plan Testów oraz dane testowe. Czynności weryfikacji Planu Testów Zamawiający przeprowadzi przez okres nie dłuższy niż 5 dni roboczych, od daty przekazania opracowania.

5.1. Brak akceptacji Planu Testów z uwagi na niepełnie pokrycie przypadków użycia przez przypadki testowe, czy też niepełne pokrycie przez przypadki testowe zidentyfikowanych wymagań komponentu LIIP lub niestaranność opracowania uniemożliwiająca przeprowadzenia testów i jednoznaczną ocenę wyników testów – stanowi istotną wadę realizacji zamówienia – i wymaga korekty.

6. Testy prowadzone są przez Wykonawcę przy udziale Zamawiającego.

7. Po zakończeniu testów, po każdej iteracji Wykonawca jest zobowiązany opracować raport z testów weryfikacyjnych.

8. Negatywne wyniki testów, identyfikujące przyczyny leżące po stronie dostarczonego lub opracowanego przez Wykonawcę rozwiązania zobowiązują Wykonawcę do wprowadzenia niezbędnych korekt w terminie uzgodnionym z Zamawiającym.

9. Podczas prowadzenia testów Wykonawca jest zobowiązany do:

9.1. instalowania nowych wersji Oprogramowania pozbawionych błędów i umożliwiających dalsze prowadzenie testów;

Strona 34 / 35


9.2. udzielania wyjaśnień oraz konsultacji technicznych Zamawiającemu;

9.3. usuwania błędów opracowanych rozwiązań programowych;

9.4. przedstawienia na żądanie Zamawiającego, wyników przeprowadzonych przez siebie wewnętrznych testów regresyjnych, które potwierdzą usunięcie zidentyfikowanych wcześniej błędów;

10. Na potrzeby procesu testowania prototypu Rozwiązania, jak również późniejszej eksploatacji komponentu LIIP, Zamawiający wprowadza klasyfikację błędów, która ma zastosowanie głównie na etapie testów akceptacyjnych. Definicja kategorii błędów została zawarta w Dodatku nr 2 – Usługi gwarancji i serwisu.

11. W przypadku, kiedy podczas testów źródło powstania błędu (wg Wykonawcy) leży po stronie trzeciej, Wykonawca jest zobowiązany do wykazania (udowodnienia) Zamawiającemu, iż niepoprawne działanie Rozwiązania wynika z niepoprawnego działania np. Infrastruktury Technicznej i / lub jej komponentów, za które odpowiedzialna jest strona trzecia. Niewykazanie źródła powstawania błędu – nie zmienia kwalifikacji i kategorii powstałego błędu oraz zobowiązań Wykonawcy do jego usunięcia.

12. Zakończenie procedury testów z wartością wskaźnika liczby błędów mieszczącą się dla określonych kategorii błędów w dopuszczalnym przedziale progowym, określonym w Planie Testów, daje tytuł Zamawiającemu do (warunkowej) akceptacji wykonania danej iteracji.

12.1. Zamawiający dopuszcza odbiór oraz warunkowe zakończenie fazy testów akceptacyjnych, w którym dla poszczególnych kategorii błędów określono następujące wartości progowe:

12.1.1. B1 – liczba błędów jest równa zero;

12.1.2. B2 – liczba błędów nie jest większa niż 3% ogółu wszystkich przypadków testowych;

12.1.3. B3 – liczba zidentyfikowanych usterek nie jest większa niż 5% ogółu wszystkich przypadków testowych.

13. Przeprowadzenie testów zgodnie z powyższą procedurą nie wyłącza uprawnień Zamawiającego do przeprowadzenia i udokumentowania testów akceptacyjnych w trybie „ad hoc” w zakresie nie objętym Planem Testów, a także do powtórzenia wybranych przypadków testowych na podstawie określonych przez siebie warunków brzegowych oraz danych. Wyniki tak przeprowadzonych testów wchodzą w zakres oceny wyników testów, o których mowa powyżej w pkt. 12.

Strona 35 / 35

bip.zgkikm.wroc.plbip.zgkikm.wroc.pl/download/178/12006/Zalaczniknr1-OPZ... · Web viewdokumentacji...

Documents

Transcript of bip.zgkikm.wroc.plbip.zgkikm.wroc.pl/download/178/12006/Zalaczniknr1-OPZ... · Web viewdokumentacji...