Zamówienie: Opracowanie „Dokumentacji technicznej Systemu Informacji Przestrzennej Województwa Wielkopolskiego”

Poniższe definicje odnoszą się wyłącznie do grupy kluczowych pojęć wykorzystywanych w niniejszym dokumencie, w tym definicji własnych stosowanych przez Zamawiającego.

Definicje / pojęcia dotyczące modelowania w języku UML zaczerpnięto z publikacji: Xxxxxxxxx Xxxxxx, Xxxxxxx Xxxxxxxxxxxx, Xxxxxxxxx Xxxxxxxxxxx „Język UML 2.0 w modelowaniu systemów informatycznych” - 2005 rok.

Nazwa	Definicja
Akcja	Elementarna jednostka specyfikacji zachowania, która reprezentuje transformację lub przetwarzanie w modelowanym systemie.
Aktor	Spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia.
Atrybut	Właściwość wyróżnienia lub obiektu określona przez nazwę tej właściwości i zakres wartości, jakie mogą być przypisane tej nazwie dla określenia tej właściwości.
Artefakt	Każdy sztucznie wytworzony produkt.
Asocjacja	Związek pomiędzy dwoma lub więcej klasyfikatorami, opisujący powiązania pomiędzy ich instancjami.
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 tym przypadku tj. w przypadku niniejszym zamówienia procesu modelowania oraz projektowania systemu informatycznego SIPWW.
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.
Diagram (lub diagram analityczny)	Technika wspomagająca język UML, która służy do dokumentowania wyników prac analitycznych i wczesnych prac projektowych.
Diagram czynności	Diagram czynności to diagram przedstawiający sekwencyjne i (lub) współbieżne przepływy sterowania i danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów.
Diagram klas	Diagram klas to diagram stanowiący obraz statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi.
Diagram komponentów	Diagram komponentów to rodzaj diagramu wdrożeniowego, który wskazuje organizację i zależności między komponentami.
Diagram komunikacji	Diagram komunikacji jest rodzajem diagramu interakcji, specyfikującym strukturalne związki pomiędzy biorącymi udział w interakcji instancjami klasyfikatorów oraz wymianę komunikatów pomiędzy tymi instancjami.
Diagram obiektów	Diagram obiektów to instancja diagramu klas, odwzorowująca strukturę systemu w wybranym momencie jego działania.
Diagram pakietów	Diagram pakietów to diagram przedstawiający logiczną strukturę dokumentacji systemu w postaci zestawu pakietów połączonych zależnościami i zagnieżdżeniami.
Diagram przypadków użycia	Diagram przypadków użycia to diagram przedstawiający występujące w danej dziedzinie przedmiotowej przypadki użycia, aktorów oraz związki między nimi.
Diagram rozlokowania	Diagram rozlokowania to rodzaj diagramu wdrożeniowego, który przedstawia sieć połączonych ścieżkami komunikowania węzłów z ulokowanymi na nich artefaktami.
Diagram sekwencji	Diagram sekwencji to rodzaj diagramu interakcji, opisujący interakcje pomiędzy instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi.
Dziedziczenie	Przyporządkowanie atrybutów i operacji klasom obiektów na podstawie hierarchicznej zależności między nimi.
Dzień Roboczy	Każdy kolejno po sobie następujący dzień od poniedziałku do piątku, z wyłączeniem dni ustawowo wolnych od pracy oraz dni wolnych określonych przez zarządzenia wewnętrzne Zamawiającego.
Etap	Nazwany, zdefiniowany określony ciąg działań Wykonawcy uwzględniający współdziałanie ze strony Zamawiającego, odnoszący się do spójnego merytorycznie zakresu prac objętego procesem zarządczym, w ramach, którego dostarczane są usługi i produkty związane z realizacją zamówienia. Wykonanie określonego Etapu prac potwierdzone odbiorem dostarczonych w ramach tego Etapu produktów i zrealizowanych usług stanowi podstawę do rozliczenia prac Wykonawcy.
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.
Harmonizacja bazy danych	Czynności polegające na zaprojektowaniu, dostosowaniu i / lub rozszerzeniu schematu aplikacyjnego bazy danych pzgik rozumiane, jako czynności, o których mowa w Art. 2 pkt 16 ustawy prawo geodezyjne i kartograficzne „… harmonizacja zbiorów danych — rozumie się przez to działania o charakterze prawnym, technicznym i organizacyjnym, mające na celu doprowadzenie do wzajemnej spójności tych zbiorów oraz ich przystosowanie do wspólnego i łącznego wykorzystywania”.
Interakcja	Wymiana bodźców, impulsów i komunikatów pomiędzy instancjami klasyfikatorów w systemie.
Interfejs	Zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent.
Iteracja	Wielokrotne, policzalne powtórzenie jednostki zachowania w systemie.
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, będące w zakresie użytkowania przez Zamawiającego.
Kanoniczny model danych	Model danych dla platformy integracyjnej np. szyny danych
Klasa	Uogólnienie zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie.
Klasyfikator	Abstrakcyjny byt, który stanowi generalizację kategorii modelowania języka UML służących do opisania cech statycznych i dynamicznych systemu.
Komponent	Hermetyczny, wymienny moduł oprogramowania systemu, realizujący określone jego usługi za pośrednictwem interfejsów.
Komunikat	Specyfikacja wymiany informacji między obiektami, zawierająca zlecenia wykonania określonej operacji.
Liczebność	Specyfikacja zakresu dopuszczalnej liczby obiektów danej klasy biorących udział w danym związku.
Metamodel	W założeniu, model definiujący składnię, semantykę i pragmatykę wprowadzonego modelu, notacji lub diagramu. Metamodel proponowany przez autorów UML ustala pewne elementy składni diagramów, ograniczenia typologiczne, klasyfikację pojęć oraz związki pomiędzy pojęciami.
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.
Xxxxxxxx MDA	MDA (ang. Model Driven Approach) metodyka stanowiąca zbiór określonych metod oparta w szczególności na modelu: pojęciowym / logicznym oraz fizycznym, gdzie model pojęciowy może zostać odwzorowany na specyfikacje modeli technologicznych, wykorzystujących do tego celu różne technologie informatyczne np. usługi sieciowe, relacyjne bazy danych, inne, które z kolei mogą zostać zaimplementowane (wdrożone) na różnych platformach sprzętowo-programowych. MDA stanowi również zbiór metod porządkujących proces tworzenia – modelowania i projektowania systemów informatycznych opartych na budowie modeli i ich transformacji.
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.
Model semantyczny	Zestaw pojęć, technik i notacji mający na celu odwzorowanie semantyki danych, czyli ich znaczenia w świecie zewnętrznym. Modele semantyczne wprowadzają w tym celu pojęcia, takie jak: generalizacja, specjalizacja, asocjacja, agregacja, klasyfikacja, własności temporalne, zdarzenia, własności behawioralne, itd. Przykładem prostego modelu semantycznego jest model encja-związek. Niekiedy terminem "model semantyczny" określa się również konkretny diagram (lub inną formę językowo-graficzną) odwzorowującą rzeczywistość opisywaną przez dane.
Modelowanie biznesowe	Sposób odwzorowywania i dokumentowania procesów biznesowych.
Norma	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
Normy ISO serii 19100	Rodzina norm ISO w dziedzinie informacji geograficznej. Wynik prac Komitetu Technicznego ISO/TC211, który pracuje nad wieloma projektami standaryzacji informacji przestrzennej w bardzo szerokim zakresie tej problematyki.
Obiekt	Każdy byt — pojęcie lub rzecz — mający znaczenie w kontekście rozwiązywania problemu w danej dziedzinie przedmiotowej.
Odbiór Końcowy	Procedura odbioru potwierdzająca wypełnienie przez Wykonawcę wszystkich zobowiązań, jakie zostały określone wobec Wykonawcy w ramach niniejszego zamówienia: Warunków Technicznych oraz umowy. Powyższe obejmuje również zobowiązania przyjęte przez Strony podczas realizacji zamówienia w formie obustronnie przyjętych dokumentów projektowych i notatek.
Ograniczenie	Wyrażenie semantyczne określające warunek bądź zastrzeżenie związane z ograniczanym elementem modelowania bądź grupą elementów.
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 Systemu, do którego Wykonawca posiada autorskie prawa majątkowe. Oprogramowanie Aplikacyjne obejmuje wszystkie moduły Systemu oraz opracowane przez Wykonawcę komponenty, procedury mające jakąkolwiek postać kodu wykonywalnego lub skryptu użytego do Wdrożenia Systemu.
Oprogramowanie Standardowe	Oprogramowanie Wykonawcy, co, do którego posiada on autorskie prawa majątkowe, będące częścią Oprogramowania Aplikacyjnego Systemu, które zostało wytworzone przed udzieleniem Wykonawcy niniejszego zamówienia, stanowiące zamkniętą określoną część lub całość modułu / komponentu programistycznego, konieczną do prawidłowego funkcjonowania Systemu, która zostanie przez Wykonawcę wykorzystana do Wdrożenia Systemu i została wskazana w jego Ofercie, jako Oprogramowanie Standardowe z podaniem: nazwy własnej, zakresu zastosowania, opisu funkcjonalności.
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 Systemu, stanowiące warstwę pośrednią - usługową pomiędzy Oprogramowaniem Aplikacyjnym a Systemowym, z wyłączeniem Oprogramowania Bazodanowego. W zakres tego oprogramowania wchodzą np. serwery mapowe, serwery WWW, serwery CMS, inne.
Oprogramowanie Systemowe	Oprogramowanie zapewniające podstawowe funkcje systemowe umożliwiające funkcjonowanie Infrastruktury Technicznej Zamawiającego zgodnie z jej przeznaczeniem. W skład tego oprogramowania wchodzi oprogramowanie do wirtualizacji oraz systemy operacyjne.
Oprogramowanie typu CASE	Oprogramowanie dostarczone przez Wykonawcę stanowiące gotowy komercyjny produkt lub produkt z grupy tzw. „wolnego oprogramowania” umożliwiający założenie i prowadzenie repozytorium projektu (tutaj Repozytorium projektu SIPWW), w którym zapisany zostanie analityczny i techniczny opis cech projektowanego systemu informatycznego, zgodnie z wybraną do tego celu notacją zapisu np. UML lub SysML. Oprogramowanie typu CASE należy do grupy Oprogramowania Narzędziowego.
Pakiet	Mechanizm ogólnego zastosowania, służący do organizowania elementów w grupy.
Partycja diagramu czynności	Mechanizm grupowania elementów diagramu czynności powiązanych przepływami sterowania i przepływami danych, pełniących określoną wspólną rolę na diagramie.
Plan Działania	Dokumentacja zarządcza wspomagająca i opisująca proces zarządzania projektem związany z realizacją niniejszej Umowy. Szczegółowy zakres opracowania Planu Działania określa niniejszy dokument. Minimalny zakres opracowania to: Harmonogram Prac, procedury komunikacji, procedury zarządzania zmianą oraz ryzykiem, opis uzgodnionej przez Strony metodyki projektowania SIPWW, w tym konspekt Projektu Technicznego SIPWW, plan zarządzania, jakością.
Plan Testów	Dokument organizacyjny służący zaplanowaniu procesu testów oprogramowania. Rolą Planu Testów jest połączenie wszystkich elementów związanych z testami: wymagań Zamawiającego, do których testy odwołują się, informacji o koniecznych zasobach testowych (ludzie, sprzęt) oraz przygotowaniu środowiska testowego, danych testowych i repozytorium testowego (bazy testowej).
Podetap (punkt kontrolny)	Wydzielona część Etapu, która może składać się z kilku zadań lub podzadań, dla której wyróżniono określony, nazwany tzw. punkt kontrolny, w którym możliwe jest dokonanie mierzalnej oceny stanu zaawansowania prac. Punkt kontrolny może odnosić się do stanu zakończenia realizacji danego zadania lub podzadania.
Projekt SIPWW	„System Informacji Przestrzennej Województwa Wielkopolskiego” rozumiany, jako wieloletnie, wieloetapowe przedsięwzięcie
Projekt (lub projekt)	Z punktu widzenia metod zarządzania projektami – niniejsze zamówienie; Nazwane zasoby Oprogramowania typu CASE identyfikowane poprzez tę nazwę (z małej litery), gromadzone w bazie danych programu nazywanej inaczej - „Repozytorium projektu”.
Projekt Techniczny SIPWW	Całość dokumentacji technicznej stanowiąca przedmiot Umowy, na którą składać się może kilka lub kilkanaście odrębnych dokumentów stanowiących integralną część tejże dokumentacji. Strukturę oraz konspekt „Projektu Technicznego SIPWW” Wykonawca jest zobowiązany określić podczas opracowania Planu Działania, przy czym istotną jego część stanowić będzie dokumentacja generowana z Repozytorium projektu SIPWW prowadzonego w programie CASE.
Prototyp SIPWW	Czasowe rozwiązanie informatyczne wspomagające proces weryfikacji i odbioru „Projektu Technicznego SIPWW”, na które składać się będę wyłącznie wybrane komponenty funkcjonalne dostarczone przez Wykonawcę, tożsame z zakresem funkcji projektowanego systemu SIPWW, stanowiące spójną całość w obszarze tzw. portalu mapowego, zapewniające ograniczony, niezbędny z punktu widzenia celu zakres funkcji, umożliwiający weryfikację - potwierdzenie poprawności opracowanego w ramach zamówienia modelu danych SIPWW dla wybranej klasy obiektów BDOT10k. Zakres prac związany z uruchomieniem prototypu nazywany jest pilotażem.
Przejście	Relacja między dwoma stanami, wskazująca, że obiekt znajdujący się w pierwszym stanie wykona pewne akcje i przejdzie do drugiego stanu, ilekroć zajdzie określone zdarzenie i będą spełnione określone warunki.
Przepływ sterowania	Relacja między dwoma czynnościami bądź akcjami, wskazująca, że po wykonaniu źródłowej czynności albo akcji sterowanie zostanie przekazane do docelowej czynności albo akcji.
Przypadek użycia	Specyfikacja ciągu akcji i ich wariantów, które system (lub inna jednostka) może wykonać poprzez interakcje z aktorami tego systemu.
Repozytorium projektu (inaczej Repozytorium projektu SIPWW)	Baza danych obsługiwana przez Oprogramowanie typu CASE zwierająca zapisy reprezentujące poszczególne schematy i notacje np. w języku UML lub SysML, w tym przypadku dokumentacji technicznej SIPWW. Innym pojęciem równoważnym i stosowanym w niniejszym opisie jest zwrot „repozytorium projektowe”, który nie musi odnosić się wyłącznie do Repozytorium projektu SIPWW. Repozytorium projektu będzie utrzymywane w Infrastrukturze Technicznej Zamawiającego i będzie okresowo, zgodnie z ustaleniami z Wykonawcą zasilane z repozytorium projektowego Wykonawcy, w którym tenże będzie prowadzić i aktualizował w sposób ciągu zapisy opracowywanego „Projektu Technicznego SIPWW”.
Rola	Powinność pełniona przez jedną klasę obiektu wobec drugiej klasy.
Rozlokowanie	Alokacja artefaktów lub instancji artefaktów w określonym węźle.
Schemat	Opis logicznej struktury bazy danych lub innego systemu związanego z danymi, np. interfejsu wymiany danych (XML Schema). Opis atrybutów wyróżnień lub bardziej dokładnie - specyficzny model atrybutów dla wyróżnień określony za pomocą elementarnych typów danych i ograniczeń dotyczących tych typów.
Schemat aplikacyjny	Schemat przeznaczony dla konkretnego systemu lub dla konkretnej dziedziny zastosowań.
Schemat implementacyjny	Schemat uwzględniający technologiczne środowisko, w którym będzie realizowana jego aplikacja. Na przykład zapisany w formie schematu XML.
Scenariusz	Określony ciąg akcji dokumentujący zachowanie.
Xxxx	Xxxxxxxxxxx lub sytuacja, w jakiej obiekt znajduje się w cyklu swojego życia, kiedy spełnia warunek, wykonuje czynność lub czeka na zdarzenie.
Standardy OGC	Techniczne dokumenty specyfikujące interfejsy i reguły zapisu danych geoprzestrzeniach. Stanowią one główne rezultaty działalności OGC (Open Geospatial Consortium) i są opracowywane przez zespoły złożone z członków OGC dla rozwiązywania różnorodnych problemów dotyczących interoperacyjności. Standardy OGC dzielą się na specyfikacje abstrakcyjne i standardy implementacyjne. Wiele z tych standardów zostało przyjęte przez komitet ISO/TC, 211 jako normy ISO, na przykład: 19107, 19115, 19119, 19123, 19125, 19128, 19136, 19139.
System	System Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW).
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ą).
Uogólnienie	Związek o charakterze taksonomicznym pomiędzy klasyfikatorem ogólnym a specjalizowanym.
Usługa sieciowa	Komponent, część oprogramowania, która realizuje pewne funkcje logiki systemu i może być wywołana zdalnie poprzez zdefiniowany interfejs.
Walidator	Program komputerowy sprawdzający poprawność dokumentu (np. XML) o określonej składni.
Warsztaty wymagań	Metoda definiowania, „wydobywania” wymagań systemu informatycznego 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ęzeł	Fizyczny lub logiczny zasób przetwarzający, na którym są osadzone artefakty użytkowanego systemu.
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 Systemu, przeprowadzenie migracji danych oraz świadczenie usług asysty technicznej na etapie uruchomienia poszczególnych części Systemu, celem doprowadzenia do normalnej, prawidłowej eksploatacji Systemu.
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.

1.2Skróty

Skrót	Opis / wyjaśnienie
BDO	Baza danych ogólnogeograficznych
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
CAD	ang. Computer-aided design; komputerowe wspomaganie projektowania
CIM	ang. Computation Independenta Model; domenowy model biznesowej, niezależny od środków informatyki
CMS	ang. Content Management System; system zarządzania treścią
CSW	ang. Catalogue Service for the Web; katalog usług sieciowych
DML	ang. Data Manipulation Language; język przetwarzania danych – zbiór instrukcji języka zapytań używanych do przetwarzania danych z bazy danych
ESB	ang. Enterprise Service Bus; korporacyjna magistrala usług
FURPS+,	Xxxxxxx określający metodę - systematykę wymagań, wskazującą określone obszary oraz zasady związane ze zbieraniem wymagań. Zgodnie z tą metodą wymagania obejmują kilka obszarów charakteryzujących system - grup: (F) Functionality - funkcjonalność w rozumieniu funkcji systemu, uwzględniająca również aspekt bezpieczeństwa (ang. security); (U) Usability – użyteczność, czyli kwestia ergonomii, zagadnienia dotyczące dokumentacji, systemu pomocy; (R) Reliability - niezawodność, mierzona np. częstością występowania błędów, zagadnienia dot. odzyskiwania, przewidywalności; (P) Performance - wydajność systemu określana również, jako czas odpowiedzi lub użycie zasobów, dostępność zasobów, warunki SLA; (S) Supportability - niedająca się łatwo przetłumaczyć "wspieralność" uwzględniająca zdolność systemu do instalacji na różnych platformach, łatwość testowania, konfiguracji, utrzymania itd. Wyróżnione obszary są identyfikowane poprzez pierwszą literę tego obszaru.
GEMET	ang. General Multilingual Environmental Thesaurus; powszechny wielojęzyczny słownik synonimów w układzie pojęciowym dotyczący środowiska
GBDOT	Georeferencyjna baza danych obiektów topograficznych
GIS	ang. Geographic Information System; system informacji geograficznej
GML	ang. Geography Markup Language; język znaczników geograficznych, aplikacja języka (metajęzyka) XML przeznaczona do zapisu geoinformacji w celu przesyłania jej pomiędzy różnymi systemami - on-line, niezależnie od platformy sprzętowo-systemowej i niezależnie od charakteru i technologii systemu geoinformacyjnego.
GUGiK	Główny Urząd Geodezji i Kartografii
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
KE	Komisja Europejska
KIIP	Krajowa Infrastruktura Informacji Przestrzennej
KML	ang. Keyhole Markup Language; język znaczników
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
MTOM	ang. Message Transmission Optimization Method; metoda optymalizacji przekazu informacji – mechanizm efektywnego przekazywania danych binarnych z wykorzystaniem usług sieciowych (Web services)
NMT	Numeryczny model terenu
ODBC	ang. Open DataBase Connectivity; otwarte łącze baz danych – interfejs połączenia aplikacji z bazami danych
OGC	ang. Open Geospatial Consortium; międzynarodowa organizacja typu non-profit, zrzeszająca ponad 460 firm, agencji rządowych i uniwersytetów, współpracujących nad rozwijaniem i implementacją otwartych standardów dla danych i usług przestrzennych
PIM	ang. Platform Independent Model; model niezależny od platformy, abstrakcyjna specyfikacja systemu wykorzystująca metamodel
PSM	ang. Platform Specific Model; model odwzorowany dla konkretnej platformy rozwiązań
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
SAN	Storage Area Network; sieć pamięci masowej – obszar sieci komputerowej udostępniający zasoby pamięci masowych
SDI	infrastruktura danych przestrzennych
SLA	ang. Service Level Agreement; umowa na dostarczenie usługi na ustalonym poziomie – poziom jest określony stosownymi miernikami
SLD	ang. Styled Layer Descriptor; opis wyglądu warstwy
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
SPOF	ang. Single Point of Failure; pojedynczy punkt awarii
SSO	ang. Single sign-on; pojedyncze logowanie
TBD	Topograficzna Baza Danych
TCP	ang. Transmission Control Protocol; niezawodny, strumieniowy protokół komunikacyjny – TCP służy do wymiany danych pomiędzy aplikacjami uruchomionymi na różnych maszynach
TIN	ang. Triangular Irregular Network; sieci nieregularnych trójkątów
WCS	ang. Web Coverage Service; usługa sieciowa pokrycia
WCTS	ang. Web Coordinate Transformation Service; usługa sieciowa transformacji współrzędnych
WFS	ang. Web Feature Service; usługa sieciowa właściwości
WFSG	ang. Web Feature Service Gazetteer; usługa sieciowa właściwości Gazetteera
WMS	ang. Web Map Service; usługa sieciowa map
WMTS	ang. Web Map Tile Service; usługa sieciowa kafli map
WPS	ang. Web Processing Service; usługa sieciowa przetwarzania
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

2Ogólny opis przedmiotu zamówienia

Przedmiotem zamówienia jest opracowanie „Dokumentacji technicznej Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)”, zwanej dalej „Projektem Technicznym SIPWW”.
Zamówienie jest częścią planowanego w ramach Wielkopolskiego Regionalnego Programu Operacyjnego projektu: „System Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)”, opisanego w załączonym do niniejszej specyfikacji wyciągu z dokumentacji
pn. „Koncepcja Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)”.
1. Wyciąg z ww. dokumentacji stanowi Załącznik nr 7 do SIWZ, do którego przynależy jeszcze załącznik wewnętrzny wobec tego dokumentu, stanowiący integralną część „Koncepcji SIPWW”, tj.:
  1. Załącznik nr 1 - Wykaz przepisów regulujących wprost lub mających wpływ
    na zakres i sposób funkcjonowania Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW);
2. W dalszej części niniejszej dokumentacji wszystkie ww. dokumenty będą identyfikowane poprzez jedną wspólną nazwę własną: „Koncepcja SIPWW”.
3. Beneficjentem Projektu „System Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)” jest Samorząd Województwa Wielkopolskiego (SWW).
4. Celem niniejszego zamówienia jest opracowanie dokumentacji projektowej,
  tj. „Dokumentacji technicznej Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)”, na podstawie której Samorząd Województwa Wielkopolskiego będzie realizował (budował oraz wdrażał) projekt docelowy
  „System Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)”. Dokumentacji stanowiącej techniczną część wymagań jakie zostaną zawarte
  w opisie przedmiotu zamówienia na „Wykonanie i wdrożenie Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW)”, w skrócie „Wykonanie
  i wdrożenie SIPWW”;
Zakres przedmiotowy „Projektu Technicznego SIPWW” określa „Koncepcja SIPWW”
oraz niniejsza specyfikacja.
Zgodnie z pkt. 1, w dalszej części niniejszego dokumentu opracowana przez Wykonawcę dokumentacja techniczna SIPWW (jako całość) będzie identyfikowana poprzez nazwę własną - „Projekt Techniczny SIPWW”.
1. Z uwagi na kontekst opisu poszczególnych wymagań oprócz ww. pojęcia może
  być stosowane zamiennie pojęcie „dokumentacji technicznej SIPWW”, które zależnie
  od wystąpienia może w szczególności odnosić się do tej części dokumentacji technicznej, jaka będzie dostępna i generowana z Repozytorium projektu
  w oprogramowaniu typu CASE.

Zgodnie z powyższym pkt. 3 opracowany przez Wykonawcę „Projekt Techniczny SIPWW”:
1. stanowić będzie szczegółowy, techniczny i zestandaryzowany opis wymagań
  oraz założeń projektowych SIPWW, które zostaną opracowane według uznanych norm
  i specyfikacji technicznych, przy wykorzystaniu dostarczonego przez Wykonawcę Oprogramowania typu CASE zapewniającego wsparcie dla procesu modelowania
  i projektowania systemu informatycznego, w tym wsparcie dla systemu notacji w języku UML, zgodnie z Ofertą Wykonawcy;
2. musi przyszłemu Wykonawcy zadania pn. „Wykonanie i wdrożenie SIPWW” umożliwić implementację systemu SIPWW bez potrzeby przeprowadzenia dodatkowych, szczegółowych prac analitycznych doprecyzowujących opisane w przedmiotowej dokumentacji wymagania, jak również parametry techniczne, z zastrzeżeniem,
  iż z ww. reguły wyłączone są zagadnienia dotyczące:
  1. implementacji systemu, w których co do zasady nie rozstrzygnięto metod oraz technologii implementacji systemu z uwagi na kwestie zachowania neutralności technologicznej;
  2. doprecyzowania lub zmiany opisu wymagań i parametrów technicznych z uwagi
    na wystąpienie niezależnych, obiektywnych uwarunkowań mających wpływ
    na treść opracowanego „Projektu Technicznego SIPWW”, a wynikających między innymi ze:
    1. zmian w przepisach prawa,
    2. zmian organizacyjnych po stronie Zamawiającego,
    3. zmian w zakresie infrastruktury teleinformatycznej Zamawiającego.
Miejscem realizacji zobowiązań Wykonawcy w zakresie czynności wymagających współudziału ze strony Zamawiającego lub czynności związanych z przeprowadzeniem prac analitycznych, w tym wywiadów ze wskazanymi przez Zamawiającego Interesariuszami SIPWW, są następujące lokalizacje:
1. wyróżniona siedziba Zamawiającego: Xxxxxx xx. Xxxxxxxxxx 00, w której odbywać
  się będzie większość spotkań oraz prac Wykonawcy;
2. pozostałe lokalizacje stanowiące siedzibę Zamawiającego w Poznaniu;
3. siedziby Wojewódzkich Samorządowych Jednostek Organizacyjnych (WSJO)
  w Poznaniu, które objęte zostały rekomendacją do wsparcia ze strony SIPWW;
4. siedziby powiatów województwa wielkopolskiego na terenie województwa wielkopolskiego (starostwa powiatowe), wskazane przez Zamawiającego ( 3 – 5 ),
  w których niezbędne będzie przeprowadzenie wywiadów oraz prac analitycznych
  w zakresie niezbędnym do zdefiniowania wymagań dla procesu wymiany danych pomiędzy SIPWW a autonomicznymi systemami informacji przestrzennej poszczególnych powiatów, stanowiącymi część Regionalnej Infrastruktury Informacji Przestrzennej (RIIP).
Zamówienie musi zostać zrealizowane przez Wykonawcę, na podstawie jego Oferty
oraz zgodnie z opracowanym przez Wykonawcę i zatwierdzonym przez Xxxxxxxxxxxxx Planem Działania, w tym w szczególności, zgodnie z uzgodnionym przez Strony Harmonogramem Prac uwzględniającym co najmniej następujące etapy realizacyjne:
1. Etap 1: Przygotowanie organizacyjne i opracowanie Planu Działania;
2. Etap 2: Przygotowanie metodyczne, w tym analiza otoczenia SIPWW;
3. Etap 3: Opracowanie Projektu Technicznego SIPWW;
4. Etap 4: Przeprowadzenie procedury Odbioru Końcowego;
Wykonawca jest zobowiązany zrealizować zamówienie w terminie do 8 grudnia 2014 roku
z uwzględnieniem obowiązujących zasad odbioru określonych we wzorze umowy,
gdzie określono, iż terminem odbioru przedmiotu zamówienia jest termin podpisania protokołu odbioru.
Zamawiający wymaga, aby:
1. Etap 1 – został zrealizowany i odebrany nie później niż w ciągu 35 dni kalendarzowych od daty podpisania umowy;
2. Etap 2 – został zrealizowany i odebrany nie później niż w ciągu 75 dni kalendarzowych od daty podpisania umowy, przy czym:
  1. Zadanie: Dostawa oprogramowaniu typu CASE oraz przygotowanie repozytorium projektowego określone w Rozdziale 3.2.2.1 zostało zrealizowane oraz odebrane nie później niż w ciągu 15 dni kalendarzowych od daty podpisania umowy;
3. W ramach Etapu 3 Wykonawca określił 2 podetapy (punkty kontrolne)
  i określił dla nich obowiązujące terminy wykonania w Harmonogramie Prac.
  1. Zdefiniowane przez Wykonawcę punkty kontrolne muszą zapewnić weryfikację oraz ocenę osiągnięcia zakładanych rezultatów ilościowych i jakościowych, potwierdzając zarazem prawidłowe i terminowe wykonanie podetapu zgodnie
    z Harmonogramem Prac oraz obowiązującym, określonym w Planie Działania planem zarządzania jakością.
Poza powyższym w ramach realizacji zamówienia Wykonawca jest zobowiązany między innymi do:
1. dostarczenia dwóch (2) licencji Oprogramowania typu CASE wspomagającego proces modelowania i projektowania SIPWW, spełniających wymagania określone
  w Rozdziale 3.4;
2. dostarczenia innych, niezbędnych licencji oprogramowania jakie są konieczne
  do prawidłowej pracy Oprogramowania typu CASE oraz uruchomienia tzw. prototypu SIPWW, dla których wymagania określono w Rozdziale 3.4.2 Oprogramowanie Bazodanowe oraz Rozdziale 3.4.3 Oprogramowanie Aplikacyjne, Standardowe, Narzędziowe i Systemowe;
3. opracowania projektu graficznego logotypu SIPWW oraz prezentacji multimedialnej podsumowującej uzyskane wyniki prac i prezentującej koncepcję oraz założenia SIPWW jak również oczekiwane rezultaty;
4. udzielenia gwarancji jakości wykonania zamówienia oraz rękojmi na okres
  nie krótszy niż 3 lata od daty Odbioru Końcowego, zgodnie ze złożoną przez Wykonawcę ofertą w zakresie określonym wzorem Umowy;
5. prowadzenia wspólnej z Zamawiającym polityki informacyjnej, zgodnej
  z ustalonymi przez Xxxxxx zasadami odnoszącymi się między innymi do uwarunkowań wykonawczych Projektu.

3Wymagania szczegółowe

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

3.1Wymagania dotyczące procesu projektowania SIPWW

Zakres opracowywanego „Projektu Technicznego SIPWW” z punktu widzenia organizacyjnego oraz technicznego (architektury logicznej) określa „Koncepcja SIPWW”,
w tym integralny, wewnętrzny jej Załącznik nr 1.
1. Należy jednak mieć na uwadze, iż podczas prac analitycznych Wykonawcy mogą
  zostać zidentyfikowane inne uwarunkowania wykonawcze oraz wymagania różniące
  się od wcześniej zidentyfikowanych, które mogą mieć i powinny mieć wpływ na zmianę wcześniejszych wymagań oraz uwarunkowań wykonawczych przez ich: zmianę, rozszerzenie lub odstąpienie. W takich przypadkach wiążące będą zawsze
  dla Wykonawcy bieżące ustalenia dotyczące stanu faktycznego i wynikające z nich konsekwencje dla projektowanego systemu, przy czym tak zidentyfikowane zmiany muszą być zawsze uzgodnione z Zamawiającym, zgodnie z przyjętymi procedurami określonymi w Planie Działania.
Szczegółowe wymagania dotyczące przedmiotu opracowania zawiera Dodatek nr 1: Proponowana przez Zamawiającego metodyka oraz inne wymagania.
Zawarte w ww. dodatku wymagania Wykonawca jest zobowiązany zastosować do realizacji niniejszego zamówienia, którego sposób przeprowadzenia określono poniżej.

3.2Sposób realizacji zamówienia

3.2.1Etap 1: Przygotowanie organizacyjne i opracowanie Planu Działania

W ramach Etapu 1 Wykonawca jest zobowiązany opracować oraz wdrożyć Plan Działania zawierający niezbędne dla prawidłowej i terminowej realizacji zamówienia uzgodnienia, w tym Harmonogram Prac.

Do opracowania Planu Działania Wykonawca powinien wykorzystać opracowany przez siebie dokument stanowiący część jego Oferty pn. „Koncepcja realizacji zamówienia”.

3.2.1.1Zadanie: Opracowanie Planu Działania

W ramach zadania Wykonawca jest zobowiązany opracować Plan Działania stanowiący uszczegółowienie sposobu realizacji zamówienia.
Wymagania Zamawiającego wobec zakresu oraz treści opracowanego przez Wykonawcę Planu Działania bazują na podejściu rekomendowanym przez powszechnie uznane metodyki zarządzania projektami takie jak: PRINCE2, czy też PMBOK.
Opracowany przez Wykonawcę Plan Działania musi zawierać co najmniej:
1. opis organizacji projektu, w tym:
  1. opis struktur organizacyjnych projektu uwzględniający uwarunkowania wskazane wzorem umowy;
  2. opis procedur:
    1. komunikacji;
    2. raportowania (na żądanie o stanie realizacji zamówienia);
    3. obsługi zagadnień projektowych, w tym zarządzania zmianą;
    4. zarządzania ryzykiem;
  3. opis sposobu prowadzenia prac analitycznych przez Wykonawcę oraz konsultacji
    i uzgodnień z Zamawiającym, w tym szablony notatek, ankiet inwentaryzacyjnych oraz ankiet do prowadzenia wywiadów;
2. uszczegółowiony opis metodyki modelowania i projektowania systemu SIPWW uwzględniający Ofertę Wykonawcy, w tym:
  1. opis struktury / układu oraz konspekt dokumentu „Projektu Technicznego SIPWW” odpowiadający na wymagania zdefiniowane w SIWZ;
  2. macierz „mapowania wymagań”, określająca w jaki sposób poszczególne elementy „Projektu Technicznego SIPWW” zdefiniowane w zakresie minimum w Rozdziale 4.3 Wymagany zakres „Projektu Technicznego SIPWW zostaną wypełnione przez Wykonawcę poprzez realizację metodyki zdefiniowanej przez pkt. 1-8 w Rozdziale 4.2 Rekomendowana metodyka modelowania oraz projektowania SIPWW, gdzie spełnienie takich wymagań:
    1. powinno być potwierdzone szczegółowo w opisie poszczególnych kolumn opracowanej przez Wykonawcę macierzy:
      1. 1 - w którym etapie realizacyjnym prac;
      2. 2 - czy według metody FUPRS+;
      3. 3 - czy w określonym modelu: CIM, PIM, PSM lub w inny sposób;
      4. 4 - przy wykorzystaniu jakiego diagramu lub notacji UML;
      5. 5 - w powiązaniu z jakim innym elementem, innego modelu;
      6. 6 - czy w oprogramowaniu typu CASE, czy też poza tym oprogramowaniem lub w połączeniu w obu tych źródłach opisu;
    2. łącznie wykaże kompletność opracowania „Projektu Technicznego SIPWW” na podstawie rekomendowanej metodyki oraz Oferty Wykonawcy.
  3. opis technik modelowania określający niezbędny zakres współudziału zespołu Zamawiającego;
  4. opis zasad prowadzenia, aktualizacji oraz dostępu do Repozytorium projektu
    w oprogramowaniu typu CASE dla przyjętej przez strony formuły prowadzenia oraz aktualizacji Repozytorium projektu w Infrastrukturze Technicznej Zamawiającego, przy uwzględnieniu i możliwości zastosowania zdalnego dostępu do zasobów Repozytorium projektu przez tzw. łącze VPN przy następujących uwarunkowaniach:
    1. dostęp dla Wykonawcy możliwy będzie wyłącznie po podpisaniu przez Wykonawcę oraz jego pracowników oświadczenia o zapewnieniu podczas realizacji zamówienia zasad obowiązującej w organizacji Zamawiającego Polityki Bezpieczeństwa Informacyjnego (PBI) powołanej Zarządzeniem Xxxxxxxxx Xxxxxxxxxxx Xxxxxxxxxxxxxxx xx 00 / 00 z dnia 8 maja 2009 roku, w sprawie wdrożenia Polityki Bezpieczeństwa Informacyjnego oraz Zasad Zarządzania Bezpieczeństwem Informacji i dokumentów z nimi związanych, przy czym przyjmuje się, że:
      1. zdalny dostęp do Repozytorium projektu zlokalizowanego
        na udostępnionym przez Zamawiającego serwerze poprzez łącze VPN, przy użyciu oprogramowania dostępowego używanego przez Zamawiającego, posiadać będzie wyłącznie określona liczba osób podana w wykazie osób: /imię/nazwisko/e-mail/tel/firma,
        co bezwzględnie obejmuje również wszystkich podwykonawców;
      2. dostęp jest realizowany na żądanie lub w trybie określonym przez harmonogram „okien czasowych” dostępu do Repozytorium projektu;
      3. dostęp do zasobów będzie realizowany poprzez VPN poprzez konta imienne aktywowane w oparciu o harmonogram zgodnie
        z Załącznikiem nr 2 do ww. Zarządzenia nr 22/09 z dnia 8 maja 2009 roku §17 Zarządzanie sieciami
        
        W związku z toczącym się procesem zmian, dostosowywania PBI do nowych uwarunkowań technologicznych i prawnych, Zamawiający zastrzega możliwość określenia innych zasad, rozwiązań w zakresie budowy kont, czy też zasad polityki dostępu VPN tożsamych z określonymi powyżej;
      4. w przypadku naruszenia przez Wykonawcę określonych przez PBI oraz przyjętych przez Strony zasad dostępu do Repozytorium projektu, Zamawiający może zablokować wcześniej uruchomiony dostęp,
        w takim przypadku Wykonawca jest zobowiązany aktualizować Repozytorium w terminach przewidzianych Harmonogramem prac
        tak, jakby posiadał cały czas dostęp online poprzez łącze VPN.
3. plan zarządzania jakością dla kluczowego produktu zamówienia tj. dla „Projektu Technicznego SIPWW”, który powinien zawierać co najmniej:
  1. diagram struktury produktów (ang. Product Breakdown Structure PBS)
    lub opracowany przez Wykonawcę diagram następstwa produktów (ang. Product Flow Diagram), czyli podział „Projektu Technicznego SIPWW” na produkty podrzędne, wraz z opisem każdego takiego produktu, co odnosi się do poszczególnych modeli, diagramów, notacji UML lub opisów stanowiących część składową opracowania zgodnie z zakresem i treścią konspektu „Projektu Technicznego SIPWW”;
  2. opis kryteriów jakościowych dla produktów lub klas produktów, ze szczególnym uwzględnieniem zakresu oraz liczby atrybutów opisujących modele UML oraz reguł kontroli składniowej, semantycznej zastosowanych na etapie modelowania przy wykorzystaniu oprogramowania typu CASE;
  3. opis procedur zarządzania jakością – minimum procedury przeglądu jakości oraz inspekcji.
Poza powyższym, Plan Działania musi zawierać Harmonogram Prac, który powinien:
1. definiować dla każdego etapu zarządczego (Etap 1-4) określone zadania i podzadania
  a dla Etapu 3 wyróżnione 2 punkty kontrolne – podetapy, które powinny odnosić się
  do różnych produktów procesu modelowania i projektowania SIPWW np. mogą dotyczyć wykonania różnych modeli CIM, PIM lub wyróżnionych w nich zadań i muszą być mierzalne według ustalonych dla nich (lub dla produktów, które je stanowią) reguł jakościowych, jakie zawarto w planie zapewnienia jakości;
2. zostać opracowany w formie schematu Gantta np. w formacie programu MS Project 2007-2012 lub klasy „open source” lub komercyjnym jak np. CELOXIS xxxx://xxx.xxxxxxx.xxx/ tak, aby zapewnić spójny oraz czytelny podział etapów
  na zadania i podzadania;
3. zawierać podział na etapy, zadania i podzadania uwzględniające istotne zdarzenia projektowe oraz uwarunkowania wykonawcze, jak również możliwe do zaplanowania zobowiązania Stron dotyczące np. przeprowadzenia warsztatów wymagań, przygotowania oraz przeprowadzania procedury odbioru, dostępności zasobów Zamawiającego: danych, Infrastruktury Technicznej, inne;
4. zostać uzupełniony opisem zadań, podzadań oraz zdarzeń projektowych, które zostały zawarte w Harmonogramie Prac, a nie mają swojego odpowiednika co do nazwy
  oraz opisu wymagań w niniejszym dokumencie.
Podczas opracowania Harmonogramu Prac Wykonawca jest zobowiązany uwzględnić wymaganie, iż Zamawiający nie dopuszcza zmiany czasu trwania oraz terminu wykonania etapów, zadań i podzadań, dla których ten czas lub termin lub kolejność określono
przez podanie dokładnej daty, czy też liczby dni lub wskazania określonego następstwa.
Faktem potwierdzającym wdrożenie procedur określonych w Planie Działania będzie przekazanie pierwszego raportu przez Wykonawcę – na żądanie Zamawiającego.

3.2.2Etap 2: Przygotowanie metodyczne, w tym analiza otoczenia SIPWW

W ramach Etapu 2 Wykonawca jest zobowiązany uruchomić Repozytorium projektu SIPWW oraz przeprowadzić szkolenia metodyczne dla Zamawiającego, jak również zainicjować
i przeprowadzić niezbędne prace przygotowawcze.
Prace w zakresie Etapu 2 Wykonawca może prowadzić równolegle do prac związanych
z wypełnieniem zobowiązań określonych dla Etapu 1.
1. Dla zadań związanych z przeprowadzeniem pierwszych prac analitycznych,
  w przypadku braku zatwierdzenia Planu Działania będącego jeszcze w trakcie opracowania, Wykonawca może podjąć prace analityczne po uzyskaniu pisemnej zgody Zamawiającego i przyjęciu przez Xxxxxx założeń dotyczących współpracy Wykonawcy
  z Zamawiającym (określenie zasad prowadzenia prac analitycznych, w tym komunikacji).
2. Wykonawca może gromadzić wyniki prac w Repozytorium projektu SIPWW. Niemniej jednak, pierwsze przedstawienie tych wyników oraz konsultacje z Zamawiającym
  w oparciu o dane zgromadzone w Repozytorium projektu w oprogramowaniu typu CASE muszą być poprzedzone niezbędnym szkoleniem pracowników Zamawiającego
  z podstaw metodyki modelowania i projektowania systemów informatycznych.

3.2.2.1Zadanie: Dostawa oprogramowaniu typu CASE oraz przygotowanie repozytorium projektowego

W ramach zadania Wykonawca jest zobowiązany:
1. dostarczyć 2 licencje Oprogramowania typu CASE poprzez dostarczenie klucza aktywacyjnego i podanie adresu strony do pobrania wersji elektronicznej oprogramowania lub poprzez dostarczenie klucza i nośników CD-ROM lub DVD-ROM do instalacji;
2. dostarczyć, zainstalować i skonfigurować do pracy Oprogramowanie Xxxxxxxxxx niezbędne do pracy oprogramowania typu CASE.
3. dostarczyć dokumentację do przedmiotowego, dostarczonego oprogramowania
  w postaci papierowej lub elektronicznej w liczbie egzemplarzy odpowiednio zgodnej
  z liczbą przekazanych licencji oprogramowania danego rodzaju;
4. zainstalować i skonfigurować oprogramowanie na wskazanym przez Zamawiającego sprzęcie komputerowym (fizycznym lub wirtualnym serwerze Zamawiającego);
5. utworzyć bazę danych projektu, inaczej Repozytorium projektu SIPWW;
6. przygotować oprogramowanie do prac projektowych oraz do planowanego szkolenia
  dla pracowników Zamawiającego, oddelegowanych do współpracy w ramach niniejszego zamówienia;
7. wdrożyć ustaloną formułę utrzymania aktualizacji i zgodności Repozytorium projektu SIPWW z repozytorium projektowym Wykonawcy przez przeprowadzenie odpowiednich testów oraz potwierdzenie poprawności funkcjonowania procesu dostępu i aktualizacji zdalnej, które, opcjonalnie - zgodnie z ustaleniami Stron może
  być aktualizowane w trybie ciągłym danymi z repozytorium projektowego Wykonawcy, zapewniając w ten sposób stały, bieżący dostęp do wyników prac Wykonawcy.
8. opracować i wdrożyć, zgodnie z Ofertą (o ile taką Xxxxxx złożył Wykonawca) dodatkowy pakiet 10 procedur kontroli – reguł projektowych, ponad funkcje kontroli standardowo dostępne w dostarczonym przez Wykonawcę Oprogramowaniu
  typu CASE.

3.2.2.2Zadanie: Przygotowanie zespołu Zamawiającego do współdziałania przy opracowaniu Projektu Technicznego SIPWW

Celem zadania jest zapewnienie niezbędnego przygotowania metodycznego dla pracowników Zamawiającego, jakie jest konieczne dla prawidłowego współdziałania Stron przy opracowaniu „Projektu Technicznego SIPWW”.
Na ww. zadanie składają się z dwa podzadania:
1. Przeprowadzenie szkolenia – prezentacji dla pracowników Zamawiającego;
2. Przeprowadzenie specjalistycznego, certyfikowanego szkolenia z oprogramowania
  typu CASE.
Ww. zadanie musi być w całości zrealizowane i odebrane przez Xxxxxxxxxxxxx przed przystąpieniem Stron do jakichkolwiek konsultacji i uzgodnień wymagających ze strony Zamawiającego niezbędnego przygotowania metodycznego.

3.2.2.2.1 Przeprowadzenie szkolenia – prezentacji dla pracowników Zamawiającego;

W ramach podzadania Wykonawca jest zobowiązany przeprowadzić szkolenie - prezentacje
z zakresu:
Realizacja szkolenia musi uwzględniać następujące uwarunkowania:
1. miejsce przeprowadzenia szkolenia zostanie wskazane przez Zamawiającego,
  który zapewni w tym względzie zabezpieczenie organizacyjne: sala, rzutnik LCD;
2. termin szkolenia musi być uzgodniony z Zamawiającym;
3. do przeprowadzenia szkolenia Wykonawca musi wykorzystać własny sprzęt komputerowy i oprogramowanie, co nie dotyczy przygotowanej przez niego
  i zainstalowanej w Infrastrukturze Technicznej Zamawiającego bazy testowo –szkoleniowej – czyli repozytorium projektowego w programie typu CASE;
4. każda osoba oddelegowana do szkolenia powinna otrzymać od Wykonawcy skrypt
  w formie niezbędnego skrótu / opisu wybranej przez Wykonawcę obiektowej metodyki modelowania i projektowania SIPWW, ze wskazaniem produktów, jakie stanowić będą jej rezultat, i odpowiednich do nich modeli w programie CASE;
5. materiały szkoleniowe muszą być udostępnione Zamawiającemu w wersji papierowej oraz elektronicznej na co najmniej 5 Dni Roboczych przed planowanym terminem szkolenia.
Dobór poziomu szczegółowości szkolenia, adekwatnie do wskazanych poniżej potrzeb, należy do decyzji Wykonawcy, który powinien w takim przypadku określić niezbędny zakres wiedzy jaki powinien podlegać przekazaniu pracownikom Zamawiającego (nie będących informatykami), aby w ten sposób zapewnić wystarczający współudział ze strony Zamawiającego w realizacji zamówienia, co w szczególności dotyczy czynności związanych z odbiorem wyników prac Wykonawcy.
Zakres szkolenia / prezentacji powinien obejmować co najmniej następujące zagadnienia:
1. wprowadzenie do modelowania i projektowania systemów informatycznych (podstawowe pojęcia);
2. wprowadzenie do analizy i projektowania obiektowego z wykorzystaniem języka modelowania UML w wersji co najmniej 2.0 odpowiednio do możliwości i zakresu wsparcia w tym obszarze ze strony dostarczonego przez Wykonawcę oprogramowania typu CASE;
3. metodyka MDA oraz metody CIM, PIM, PSM wybrane do realizacji zamówienia przez Wykonawcę wsparte przez określone rozwiązania i notacje w oprogramowaniu typu CASE;
4. podstawowe zagadnienia / pojęcia dotyczące modelowania i projektowania: modelowanie dziedziny, wymagania oraz przypadki użycia, diagramy: przypadków użycia, klas, komponentów, czynności, pakietów;
5. opcjonalnie ogólne zagadnienia dotyczące metod oraz techniki modelowania zwinnego, mające wpływ i rekomendowane do procesu implementacji systemu – cykl życia systemu: kaskadowy, spiralny (prototypowanie), inne.
Ponadto sposób przeprowadzenia szkolenia powinien uwzględniać następujące wymagania:
1. czas trwania szkolenia musi być uzgodniony z Zamawiającym, lecz nie powinien być krótszy niż dwa (2) cykle po nie mniej niż 4 efektywne godziny szkolenia dziennie dla grupy pracowników Zamawiającego nie większej niż 50 osób;
2. szkolenie może być prowadzone w oknie czasowym od godz. 9:00 do godz. 15:00 z wyłączeniem dni wolnych od pracy, z uwzględnieniem niezbędnych przerw
  w szkoleniu;
3. do przeprowadzenia szkolenia Wykonawca zagwarantuje przynajmniej 1 trenera;
4. po szkoleniu Wykonawca zapewni każdemu uczestnikowi szkolenia możliwość konsultacji z trenerem prowadzącym szkolenie poprzez kontakt telefoniczny lub konsultację drogą elektroniczną przez okres 15 Dni Roboczych od daty zakończenia szkolenia.
Zmiana zakresu przedmiotowego szkolenia możliwa jest wyłącznie na etapie opracowania Planu Działania i może odnosić się wyłącznie do zmian wynikających z zaakceptowanej przez Zamawiającego propozycji Wykonawcy związanej z zastosowaniem innego sposobu modelowania i projektowania systemu w wyniku zastosowania przez Wykonawcę równoważnych specyfikacji technicznych i norm, w tym innej niż UML notacji diagramów, czy też innego wynikającego z Oferty Wykonawcy podejścia do modelowania w ramach metodyki MDA.

3.2.2.2.2 Przeprowadzenie specjalistycznego, certyfikowanego szkolenia z oprogramowania typu CASE.

Wykonawca jest zobowiązany zapewnić lub przeprowadzić dla Zamawiającego specjalistyczne, certyfikowane szkolenie z Oprogramowania typu CASE połączone z nauką podstaw modelowania i projektowania systemów informatycznych przy wykorzystaniu przedmiotowego oprogramowania.
W związku z powyższym Wykonawca jest zobowiązany wykupić oraz dostarczyć Zamawiającemu 2 vouchery szkoleniowe dla dwóch osób, po jednym dla każdej z nich, zapewniające możliwość odbycia przez te osoby podstawowego, certyfikowanego szkolenia z wykorzystania dostarczonego przez Wykonawcę Oprogramowania typu CASE
oraz metodyki modelowania i projektowania systemów informatycznych.
Dostarczone przez Wykonawcę vouchery muszą:
1. być opłacone i powinny zapewniać dostęp i przeprowadzenie szkolenia
  w terminie jaki określono na realizację Etapu 2;
2. zapewniać odbycie szkolenia w certyfikowanym ośrodku szkoleniowym posiadającym w swoim portfolio pakiet szkoleń z zakresu oprogramowania CASE oferowanego przez Wykonawcę, w tym podstawowe szkolenia z użytkowania
  i modelowania systemów informatycznych w oparciu o tego typu oprogramowanie.
W przypadku wystąpienia trudności w zrealizowaniu wykupionego dla Zamawiającego szkolenia (vouchery) z przyczyn niezależnych od Zamawiającego, Wykonawca
jest zobowiązany we własnym zakresie zorganizować i przeprowadzić odpowiednio
w wymaganym terminie i w wymaganym zakresie certyfikowane szkolenie na swój koszt,
w ramach ustalonego wynagrodzenia za wykonanie przedmiotu zamówienia.
1. W przypadku nie zrealizowania szkolenia w ustalonym terminie, Zamawiający zleci realizację takiego szkolenia na koszt Wykonawcy, co może wpłynąć na rozliczenie się Wykonawcy z zobowiązań jakie określono wobec niego w ramach Etapu 2.

3.2.2.3Zadanie: Analiza uwarunkowań prawnych, organizacyjno – technicznych oraz otoczenia SIPWW

W ramach zadania Wykonawca jest zobowiązany wykonać następujące podzadania:
1. Przeprowadzenie analizy obowiązujących przepisów prawa w zakresie związanym przedmiotowo z SIPWW, co w szczególności odnosi się do ustaw oraz przepisów wykonawczych dotyczących: Ustawy o infrastrukturze informacji przestrzennej, Ustawy prawo geodezyjne i kartograficzne oraz Ustawy o informatyzacji podmiotów realizujących zadania publiczne, przy czym analizą należy objąć również:
  1. projekty nowelizacji aktów prawa będące w końcowej fazie procesu legislacyjnego oraz dyrektywy, rozporządzenia oraz wytyczne Komisji Europejskiej związane z wdrożeniem Dyrektywy INSPIRE;
  2. przepisy wewnętrzne Zamawiającego: statut, Zarządzenia Marszałka Województwa Wielkopolskiego, uchwały Zarządu Województwa Wielkopolskiego, Politykę Bezpieczeństwa Informacyjnego Urzędu Marszałkowskiego Województwa Wielkopolskiego oraz inne powiązane tematycznie z przedmiotem prac Wykonawcy dokumenty prawno – organizacyjne;
2. Wyniki ww. analizy muszą mieć postać pisemną w formie raportu, mają
  być umieszczone w Repozytorium projektu, jako wymagania.
3. Przeprowadzenie inwentaryzacji infrastruktury technicznej – teleinformatycznej Zamawiającego celem określenia zakresu i możliwości jej zastosowania
  lub modernizacji i rozbudowy do prac związanych z opracowaniem i wdrożeniem SIPWW przez zdefiniowanie niezbędnych wymagań i założeń, w tym ograniczeń / wyłączeń związanych z tak określonymi wymaganiami niefunkcjonalnymi wobec SIPWW.
  1. Zakres inwentaryzacji musi obejmować:
    1. Infrastrukturę Techniczną Zamawiającego (serwery, macierze,
      sieć lokalna oraz infrastruktura dostępowa);
    2. Oprogramowanie Systemowe, Bazodanowe, Narzędziowe i Aplikacyjne jakie może mieć zastosowanie w procesie budowy SIPWW, w tym inne systemy informatyczne (Aplikacyjne), z którymi należy zapewnić lub zakłada się, że powinna być zapewniona integracja i / lub wymiana danych
      jak np. planowany do wdrożenia w organizacji Zamawiającego System EZD;
    3. bazy danych w formie elektronicznej oraz analogowej;
    4. zasoby informacyjne w formie nieprzetworzonej, które mogą stanowić przedmiot przetworzenia do postaci elektronicznej na potrzeby SIPWW;
    5. systemy / usługi dostępne na platformach teleinformatycznych organów administracji rządowej.
  2. Wyniki analizy muszą mieć postać pisemną i powinny zostać opracowane
    w formie raportu. Poziom szczegółowości identyfikacji oraz opisu „infrastruktury” musi być adekwatny do potrzeb późniejszego mapowania metod i technologii.
4. Identyfikacja uwarunkowań mających wpływ na zakres i proces projektowania SIPWW, których źródłem może być tzw. otoczenie Projektu, a które należy uwzględnić na etapie specyfikacji wymagań lub projektowania i opracowania „Projektu Technicznego SIPWW”.

3.2.3Etap 3: Opracowanie Projektu Technicznego SIPWW

W ramach Etapu 3 Wykonawca zobowiązany jest przeprowadzić niezbędne prace analityczne i projektowe zgodnie z ustaloną, obowiązującą metodyką modelowania i projektowania systemu, aby skutecznie doprowadzić do opracowania „Projektu Technicznego SIPWW”
w określonym zakresie przedmiotowym oraz wskazanym przez Wykonawcę terminie.
W tym celu:
1. Wykonawca jest zobowiązany określić zakres systemu SIPWW przez potwierdzenie
  i aktualizację zakresu organizacyjnego i funkcjonalnego określonego w „Koncepcji SIPWW” oraz przez określenie nowych wymagań i uwarunkowań wykonawczych związanych z SIPWW;
2. wykorzystując wskazaną i wymaganą przez Zamawiającego metodę warsztatów wymagań oraz inne metody i techniki wybrane przez Wykonawcę np. wywiady, spotkania, konsultacje, inne, Wykonawca jest zobowiązany skutecznie doprowadzić
  do zdefiniowania przedmiotu systemu SIPWW i opracowania „Projektu Technicznego SIPWW”.
Za pisemną zgodą Zamawiającego, po przyjęciu założeń dotyczących współpracy Wykonawcy z Zamawiającym (określenie sposobu prowadzenia prac analitycznych), stanowiących część zagadnień zawartych w Planie Działania, Wykonawca może prowadzić prace równolegle w ramach Etapu 2 oraz Etapu 3, gromadząc wyniki prac w Repozytorium projektu SIPWW. Niemniej jednak, pierwsze przedstawienie wyników prac w oparciu
o dane zgromadzone w Repozytorium projektu w oprogramowaniu typu CASE musi
być poprzedzone niezbędnym szkoleniem pracowników Zamawiającego z podstaw metodyki modelowania i projektowania systemów informatycznych.

3.2.3.1Zadanie: Przeprowadzenie warsztatów wymagań

W ramach zadania Wykonawca jest zobowiązany do przeprowadzenia warsztatów wymagań, które w maksymalnie możliwym stopniu powinny być poparte gotowymi lub przykładowymi rozwiązaniami informatycznymi podmiotów trzecich lub Wykonawcy, prezentującymi
te same lub podobne usługi i funkcje co wstępnie określone dla SIPWW.
Celem warsztatów jest potwierdzenie i doprecyzowanie wymagań funkcjonalnych
oraz niefunkcjonalnych wobec projektowanego SIPWW, a przede wszystkim ułatwienie
ich wydobycia od przyszłych użytkowników Systemu.
Do prezentacji przykładowych usług i funkcji tożsamych z SIPWW, Wykonawca powinien wykorzystać:
1. dostępne publicznie portale mapowe województwa x.xx.: dolnośląskiego, opolskiego, małopolskiego, oraz system geoportal2.
2. oprogramowanie klasy „open source” lub oprogramowanie komercyjne klasy Desktop GIS, będące w posiadaniu Wykonawcy lub Zamawiającego, odpowiednio skonfigurowane i działające na przykładowych danych testowych, opracowanych lub odpowiednio dobranych i skonfigurowanych przez Wykonawcę tak, aby umożliwić zaprezentowanie działania, co najmniej kilkunastu różnych, przykładowych złożonych analiz przestrzennych.
  1. Do celów ww. prezentacji Zamawiający może udostępnić Wykonawcy na czas realizacji Zamówienia posiadane dane np. BDOT10k.
Wykonawca jest zobowiązany przeprowadzić warsztaty wymagań przyjmując, iż:
1. uczestnikami warsztatów będą pracownicy Zamawiającego, oddelegowani
  do współpracy z Wykonawcą, stanowiący zarazem reprezentatywną grupę przyszłych użytkowników projektowanego SIPWW;
2. warsztaty wymagań zostaną przeprowadzone w siedzibie Zamawiającego;
3. miejsce do przeprowadzenia warsztatów oraz zabezpieczenie logistyczne, organizacyjne zapewni Zamawiający.
Termin przeprowadzenia warsztatów musi być uzgodniony z Zamawiającym.
Czas trwania warsztatów: 1 lub 2 cykle, łącznie do 4 godzin, dla grupy osób nie większej
niż 50 osób.
Do przeprowadzenia warsztatów Wykonawca musi wykorzystać własny sprzęt komputerowy i oprogramowanie oraz przygotowane dane - bazę testową.
Podczas warsztatów wymagań Wykonawca powinien za każdym razem dokonać odpowiedniego wprowadzenia metodycznego, a następnie omówić i zaprezentować „możliwości” rozwiązań GIS w zakresie dostępnych usług / funkcji, odnosząc
to do możliwości potencjalnego wdrożenia podobnych rozwiązań po stronie SIPWW.
W przypadku prezentowania i omawiania określonych rozwiązań produktowo – technologicznych, Wykonawca, podczas prezentacji jak również na etapie opracowania „Projektu Technicznego SIPWW” musi zachować zasady obiektywnej oceny eksperckiej omawianego rozwiązania, a docelowo zasadę neutralności technologicznej.

3.2.3.2Zadanie: Opracowanie dokumentacji „Projektu Technicznego SIPWW”

W ramach zadania Wykonawca jest zobowiązany prowadzić prace uwzględniając przy tym wymagania i rekomendacje Zamawiającego wskazane w Rozdziale 4 Dodatek nr 3.
Wyniki prac analitycznych i projektowych Wykonawca jest zobowiązany udokumentować przy użyciu dostarczonego oprogramowania typu CASE, zapewniającego modelowanie danych w języku UML.
Podczas opracowania „Projektu Technicznego SIPWW” Wykonawca jest zobowiązany uwzględniać w każdym przypadku obowiązujące przepisy prawa, w tym zidentyfikowane lokalne uwarunkowania organizacyjno - prawne, co odnosi się do przepisów prawa jakie:
1. wskazano w „Koncepcji SIPWW” Załącznik nr 1 - Wykaz przepisów regulujących wprost lub mających wpływ na zakres i sposób funkcjonowania Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW);
2. obowiązują w Polityce Bezpieczeństwa Informacyjnego (PBI) Zamawiającego,
  a które podano w Rozdziale 7. Dodatek nr 3;
W szczególności, w odniesieniu do powyższego Wykonawca jest zobowiązany uwzględnić przepisy wykonawcze do Ustawy o informatyzacji podmiotów realizujących zdania publiczne, a w szczególności wymagania określone przez § 15 ust. 1 Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2012 r. poz. 526) – zwane dalej „rozporządzeniem”, w których to wskazano na obowiązek zastosowania uznanych w obrocie profesjonalnym norm i standardów oraz metodyk
dla procesu projektowania systemu teleinformatycznego, co wskazuje, iż:
1. przyjęty format oraz sposób opisu powinien być ukierunkowany
  na udokumentowanie projektu docelowego systemu SIPWW zapewniając jednocześnie:
  1. „interoperacyjność” (§5 ust. 1-3 rozporządzenia);
  2. zastosowanie uznanych w obrocie profesjonalnym norm i standardów oraz metodyk (§ 15 ust. 1) w procesie projektowania, wdrażania, eksploatacji, celem zagwarantowania niezawodności, używalności, wydajności, przenoszalności i pielęgnowalności powstających systemów, co przekłada się na udokumentowany proces i procedury (§ 15 ust. 2 rozporządzenia), co uznaje się za spełnione, jeśli projektowanie, wdrażanie, eksploatowanie, monitorowanie, przeglądanie, utrzymanie i udoskonalanie zarządzania usługą podmiotu realizującego zadanie publiczne odbywa się z uwzględnieniem Polskich Norm: PN-ISO/IEC 20000-1 i PN-ISO/IEC 20000-2.
W Repozytorium projektu w oprogramowaniu typu CASE Wykonawca powinien zawrzeć
w maksymalnie możliwym stopniu wszystkie opisy i zagadnienia stanowiące treść „Projektu Technicznego SIPWW”.
1. Zamawiający dopuszcza gromadzenie dokumentacji, której przechowywanie
  w notacji UML jest niecelowe lub niemożliwe, np. obszerne opisy tekstowe wymagań
  w formacie odf lub doc, a tabele w formacie zgodnym z MS Excel,
  czy też schematy sieci teleinformatycznych w innych narzędziach.

3.2.3.3Zadanie: Przygotowanie logotypu SIPWW oraz prezentacji multimedialnej podsumowującej wyniki prac

W ramach zadania Wykonawca jest zobowiązany do opracowania:
1. prezentacji multimedialnej podsumowującej uzyskane wyniki prac projektowych oraz prezentującej koncepcje, założenia organizacyjne i techniczne SIPWW oraz oczekiwane rezultaty, uwypuklającej zarazem istotne zagadnienia dotyczące następnego etapu realizacji Projektu związanego z udzieleniem zamówienia na „Wykonanie
  i wdrożenie SIPWW”;
2. logotypu SIPWW.
Opracowana przez Wykonawcę prezentacja multimedialna musi:
1. umożliwić odtworzenie prezentacji w środowisku pakietu MS Power Point oraz bezpłatnych pakietów biurowych typu „open source” oraz zapewnić uruchomienie wersji wykonywalnej prezentacji w środowisku systemu operacyjnego MS Windows XP, 7, 8;
2. zawierać takie elementy multimedialne jak: muzyka, dźwięk, tekst, obrazy, animacje 2D, filmy, głos lektora oraz interaktywność pozwalającą na wybór określonej części prezentacji oraz możliwość powrotu do głównego menu;
3. trwać nie dłużej niż 8-10 minut;
Opracowanie prezentacji musi nastąpić na podstawie przygotowanych przez Wykonawcę minimum 2 różnych projektów scenariuszy, z których ostatecznie jeden zostanie zatwierdzony przez Xxxxxxxxxxxxx.
1. Zamawiający na dokonanie oceny i wybór scenariusza, a także na akceptację
  lub przedstawienie Wykonawcy uwag do scenariusza ma 3 Dni Xxxxxxx, a Wykonawca ma również 3 Dni Xxxxxxx na uwzględnienie wszystkich uwag Zamawiającego.
Opracowany przez Wykonawcę logotyp SIPWW musi:
1. stanowić kreację spójnego przekazu wizerunkowego – symbolu, który bezpośrednio odwołuje się do celów projektu lub systemu SIPWW lub nawiązuje
  do jego nazwy oraz przedmiotu lub – w sposób pośredni stanowi symbol kojarzony
  z SIPWW, w tym z jego charakterem oraz zakresem działania lub oddziaływania;
2. nawiązywać do herbu / logo województwa wielkopolskiego poprzez nawiązanie do elementów graficznych lub kolorystyki;
3. zapewnić możliwość zastosowania zarówno w wersji kolorystycznej
  jak i w wersji achromatycznej (czarno – białej);
  1. liczba kolorów do uzgodnienia z Zamawiającym, przy czym wstępnie zakłada się, że nie będzie to więcej niż 5 kolorów;
4. posiadać cechy łatwej identyfikacji , rozpoznawania i zapamiętania;
5. umożliwić szerokie zastosowanie w różnego rodzaju materiałach promocyjnych, w tym również wymagających „minimalizacji” rozmiaru znaku graficznego
  jak np. pen-drive, długopis.
Opracowanie logotypu musi nastąpić na podstawie przygotowanych przez Wykonawcę minimum 3 różnych projektów, z których ostatecznie jeden zostanie zatwierdzony przez Xxxxxxxxxxxxx.
1. Zamawiający na dokonanie oceny i wybór logotypu, a także na akceptację
  lub przedstawienie Wykonawcy uwag ma Dni Robocze, a Wykonawca ma również
  3 Dni Xxxxxxx na uwzględnienie wszystkich uwag Zamawiającego.
Przekazanie Zamawiającemu projektu logotypu musi nastąpić:
1. w formie elektronicznej na płycie CD lub DVD, w formacie wektorowym np. CDR lub SVG, w dwóch wersjach: podstawowej kolorowej oraz achromatycznej;
2. w formie papierowej na planszy formatu A4: w wersji podstawowej kolorowej oraz achromatycznej;
Włącznie z opracowaniem logotypu Wykonawca jest zobowiązany opracować i przekazać Zamawiającemu tzw. Księgę Znaków (ang. Brand book), w której powinien wskazać podstawowe zasady korzystania z logotypu x.xx.: kolory przewodnie, wybór czcionki/czcionek.

3.2.4Etap 4: Przeprowadzenie procedury Odbioru Końcowego

W ramach Etapu 4 Zamawiający przeprowadzi procedurę Odbioru Końcowego, podczas której dokona weryfikacji i potwierdzenia wypełnienia przez Wykonawcę wszystkich zobowiązań, jakie wyniknęły z realizacji zamówienia.
1. W pracach tych Wykonawca jest zobowiązany do ścisłego współdziałania
  z Zamawiającym celem skutecznego doprowadzenia do Odbioru Końcowego, w tym odbioru potencjalnie zaległych prac lub niezrealizowanych zobowiązań.
Odbiór wyników prac poszczególnych Etapów jak również Etapu 4 związanego z Odbiorem Końcowym musi być przeprowadzony zgodnie z określoną we wzorze umowy procedurą.
Na żądanie Zamawiającego Wykonawca jest zobowiązany do zaprezentowania uzyskanych wyników prac przed Zarządem Województwa Wielkopolskiego.

3.3Wymagania dotyczące dokumentacji

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 opracowania oraz w formie elektronicznej przekazana drogą elektroniczną, na adres Zamawiającego lub na nośniku CD-ROM przynajmniej w dwóch różnych formatach: edytowalnym np. w formacie odf oraz zabezpieczonym przed edycją formacie PDF.
Dla dokumentacji związanej z przedmiotem dostawy oprogramowania typu CASE,
do którego Wykonawca nie posiada autorskich praw majątkowych, Wykonawca
jest zobowiązany do dostarczenia dokumentacji zgodnie ze specyfikacją tego produktu, określoną przez producenta produktu lub przez jego dystrybutora.
Zamawiający nie akceptuje użycia do realizacji zamówienia licencji oprogramowania,
dla którego nie jest dostępna dokumentacja użytkownika w formie papierowej
lub elektronicznej np. formacie PDF.

3.4Wymagania wobec Oprogramowania

3.4.1Oprogramowanie typu CASE

Dostarczone przez Wykonawcę Oprogramowanie typu CASE musi zapewnić co najmniej:
1. tworzenie i gromadzenie w tzw. Repozytorium projektu zaawansowanych modeli analitycznych i projektowych zgodnie ze standardem notacji UML w wersji co najmniej 2. 0 dla wszystkich rodzajów diagramów UML;
2. modelowanie procesów biznesowych za pomocą BPMN 2.0;
3. wsparcie dla tworzenia modeli projektowanego systemu informatycznego zgodnie z metodyką MDA;
4. tworzenie dokumentacji na podstawie danych z Repozytorium projektu
  za pomocą edytora WYSIWYG opartego o predefiniowane szablony, z możliwością tworzenia własnych szablonów;
5. eksport i import plików wymiany danych w formacie XML, zgodnie
  ze standardem XMI w wersji 1.0, 1.1, 2.1, 2.2;
6. tworzenie plików XSD w oparciu o diagramy UML;
7. tworzenie modelu UML w oparciu o pliki zawierające schemat aplikacyjny
  w pliku XML (GML);
8. funkcje porównywania modeli;
9. definiowanie i zarządzanie wymaganiami:
  1. modyfikacja wymagań;
  2. łączenie wymagań z przypadkami użycia, komponentami, przypadkami testów;
10. wspomaganie procesu tworzenia i redakcji dokumentacji z projektu;
11. zarządzanie przypadkami testów, projektowanie testów jednostkowych, integracyjnych, systemowych, akceptacji i scenariuszy testów;
12. obsługa transformacji modeli MDA według zdefiniowanych szablonów:
  1. możliwość tworzenia i modyfikacji własnych szablonów transformacji;
  2. przynajmniej transformacja i generacja modelu PIM do modelu PSM, gdzie do jednego modelu PIM może być przypisanych wiele modeli PSM;
  3. wbudowane transformacje dla min. DDL, Java, C#, EJB, XSD;
13. wsparcie dla zarządzania projektem w zakresie:
  1. tworzenia wykresów Gantta;
  2. możliwości przydzielania zasobów do poszczególnych elementów projektu – komponentów, podsystemów, przypadków użycia itp.;
  3. definiowania zadań i kalendarza projektowego do zarządzania planowaniem i rozlokowaniem zasobów;
14. obsługę plików GML w wersji 3.2.1 i wersji niższych;
15. tworzenie plików WSDL dla definiowanych usług sieciowych, w tym:
16. automatyczną generację pliku WSDL w oparciu o model UML;
17. generację modelu UML w oparciu o istniejący plik WSDL;
18. współpraca ze środowiskiem narzędziowym (serwer aplikacji ) systemów GIS będącym w posiadaniu Zamawiającego , w tym generowanie z modelu danych struktury tabel dla bazy danych i wspieranej przez pakiet CASE technologii GIS;
19. generowanie struktury tabel dla modelu danych dla określonych systemów relacyjnej bazy danych, do co najmniej: udostępnionego przez Zamawiającego oraz opcjonalnie oferowanego przez Wykonawcę;
20. sprawdzanie poprawności modeli:
  1. za pomocą wybranych predefiniowanych reguł, przynajmniej w zakresie:
    1. dobrego sformułowania - czy zastosowane elementy, relacje, cechy
      i diagramy są poprawne zgodnie z UML i czy zastosowane diagramy zawierają wyłącznie poprawne elementy UML;
    2. kompozycji elementu - czy elementy posiadają poprawnych potomków, właściwą ich liczbę oraz czy nie występuje brak wymaganego potomka;
    3. poprawności właściwości - czy elementy, relacje i cechy mają poprawnie zdefiniowane właściwości UML oraz czy właściwości te nie zawierają niepoprawnych lub konfliktujących wartości;
    4. zdefiniowanych przez użytkownika reguł / ograniczeń za pomocą języka OCL;
  2. wprowadzanie własnych reguł projektowych (kontroli zapisów
    oraz tworzonych notacji), definiowanych za pomocą dedykowanego kreatora
    lub ręcznie, np. przy pomocy zapytań SQL do bazy projektu, mających zastosowanie do weryfikacji poprawności wprowadzonych opisów / informacji
    do Repozytorium projektu;
  3. możliwość eksportu wyniku weryfikacji do pliku typu CSV lub RTF;
21. tworzenie macierzy związków w obrębie danego pakietu lub pomiędzy elementami dwóch wybranych pakietów;
  1. filtrowanie relacji ze względu na:
    1. typ i kierunek relacji;
    2. typ elementu źródłowego i docelowego;
    3. pakiety, do których należy element źródłowy i docelowy;
  2. możliwość tworzenia, modyfikacji i usuwania relacji z poziomu macierzy;
22. tworzenie i uruchamianie symulacji procesów na podstawie BPMN;
23. generowanie kodu BPEL na podstawie diagramów BPMN;
24. tworzenie symulacji modeli zgodnie z SysML w wersji 1.1, 1.2 i 1.3;
25. integrację z oprogramowaniem deweloperskim w celu wsparcia procesu implementacyjnego - przynajmniej MS Visual Studio i Eclipse;
26. tworzenie i debugowanie skryptów JScript, VBScript, JavaScript;
27. generowanie zasadniczej części kodu źródłowego oparte na szablonach:
  1. możliwość tworzenia własnych szablonów;
  2. wbudowane wsparcie dla min. C++, Java, C#, XX.Xxx, Visual Basic, Delphi, PHP, Python i ActionScript;
28. integrację i wsparcie dla systemów kontroli wersji – Subversion, CVS;
29. śledzenie zależności pomiędzy kolejnymi, powiązanymi elementami modelu;
30. zapisywanie tworzonych diagramów i dokumentacji w formacie PDF;
31. dostosowywanie interfejsu oprogramowania do własnych preferencji – modyfikowalne paski narzędzi, dokowane okna z możliwością ustawienia opcji
  auto-ukrywania.
Oprogramowanie typu CASE musi być dostarczone włącznie z dostępnymi na rynku IT
dla tego Oprogramowania typu CASE dedykowanymi rozszerzeniami zapewniającymi dodatkowe funkcje kontroli i weryfikacji projektu (z minimum jedną tego typu licencją, o ile dla Oprogramowania typu CASE istnieją tego typu rozszerzenia).
1. Wymagane jest, aby Wykonawca takie rozszerzenia dostarczył, zainstalował razem z podstawową licencją Oprogramowania typu CASE i włączył do procesu wytwórczego „Projektu Technicznego SIPWW”.
Dostarczona przez Wykonawcę licencja musi zapewnić poprawną pracę we własnym środowisku bazodanowym lub przy wykorzystaniu licencji udostępnionej przez Zamawiającego lub innej zaoferowanej przez Wykonawcę.
1. Z ww. powodu Zamawiający nie specyfikuje wymagań dla systemu zarządzania relacyjną bazą danych pozostawiając w tym zakresie dobór określonego produkt Wykonawcy, który poprzez ocenę złożoności „Projektu Technicznego SIPWW” powinien dobrać właściwą do tego celu licencję Oprogramowania Bazodanowego.

3.4.2Oprogramowanie Bazodanowe

Zastosowane przez Wykonawcę, a udostępnione przez Zamawiającego Oprogramowanie Bazodanowe lub dostarczone przez Wykonawcę musi zapewnić poprawną pracę oprogramowania typu CASE, w tym musi zapewnić integralność i spójności zapisów
w Repozytorium projektu.
1. Zamawiający nie określa dedykowanych wymagań dla systemu zarządzania relacyjną bazą danych pozostawiając w tym względzie dobór rozwiązania do decyzji Wykonawcy, który poprzez ocenę złożoności Repozytorium projektu dla zapisów dokumentacji technicznej „Projektu Technicznego SIPWW” powinien wybrać właściwą do tego celu licencję Oprogramowania Bazodanowego.
2. Zamawiający dopuszcza zastosowanie do tego celu:
  1. licencji udostępnionych przez Zamawiającego;
  2. licencji oprogramowania dostępnych na ogólnych zasadach licencji „open source”;
3. Zastosowana przez Wykonawcę licencja do obsługi Oprogramowania typu CASE może być użyta również do uruchomienia tzw. pilotażu, o którym mowa w Rozdziale 4.2.1 Wytyczne: metoda FURPS+ oraz metodyka MDA , o ile zapewni jego poprawną pracę.

3.4.3Oprogramowanie Aplikacyjne, Standardowe, Narzędziowe i Systemowe

Dostarczone przez Wykonawcę Oprogramowanie niezbędne do uruchomienia tzw. prototypu SIPWW w ramach pilotażu, o którym mowa w Rozdziale 4.2 Rekomendowana metodyka modelowania oraz projektowania SIPWW, a zainstalowane na udostępnionych przez Zamawiającego serwerach wirtualnych, musi składać się z Oprogramowania Bazodanowego, o którym mowa w Rozdziale 3.4.2, oraz z:
1. Oprogramowania Aplikacyjnego i / lub Standardowego Wykonawcy;
2. Oprogramowania Narzędziowego udostępnionego przez Zamawiającego, lub innego dostarczonego przez Wykonawcę o ile udostępnione przez Zamawiającego licencje okażą się niewystarczające do uruchomienia prototypu SIPWW w zakresie prac objętym pilotażem lub uruchomienie prototypu SIPWW jako „rozwiązania Wykonawcy”, na bazie Oprogramowania Aplikacyjnego i Standardowego Wykonawcy wymaga innych licencji oprogramowania niż może to zapewnić w tym zakresie Zamawiający;
3. Oprogramowania Systemowego, dostarczonego przez Wykonawcę – 2 licencje.
Skonfigurowane Oprogramowanie Aplikacyjne i Standardowe Wykonawcy oraz użyte Oprogramowanie Narzędziowe, Bazodanowe oraz Systemowe muszą łącznie zapewnić dostępności funkcji oraz usług jakie wskazano dla prototypu SIPWW w Rozdziale 5 Dodatek nr 2: Minimalny, zakres funkcji i usług dla prototypu SIPWW.
Dostarczone przez Wykonawcę Oprogramowanie Systemowe musi zapewnić co najmniej:
1. prawidłową pracę maszyny wirtualnej udostępnionej przez Zamawiającego w oprogramowaniu do wirtualizacji tj. VMware Enterprise 4;
2. poprawną pracę dostarczonego lub wykorzystanego przez Wykonawcę, a udostępnionego przez Zamawiającego Oprogramowania Narzędziowego, Bazodanowego;
3. poprawną pracę dostarczonego lub opracowanego przez Wykonawcę Oprogramowania Standardowego i Aplikacyjnego;
4. obsługę systemów wieloprocesorowych dla platformy x86-64;
5. usługi HA - tworzenie systemu wysokiej dostępności: klaster „active – active” oraz typu fail-over;
6. możliwość użytkowania w ramach podstawowej, dostarczonej
  przez Wykonawcę licencji bez ograniczeń dostępowych
  dla pracowników Zamawiającego korzystających z zasobów lub usług zlokalizowanych bezpośrednio na danej maszynie wirtualnej lub pośrednio poprzez zainstalowane i uruchomione na tym serwerze inne oprogramowanie.

4Dodatek nr 1: Proponowana przez Zamawiającego metodyka oraz inne wymagania

4.1Założenia

Poniższy opis przedstawia wymagany, minimalny zakres opracowania „Projektu Technicznego SIPWW” z punktu widzenia celu, jakim jest opracowanie dokumentacji technicznej na potrzeby przyszłej implementacji systemu.
1. Zakres wymagań podany poniżej nie wyczerpuje wszystkich wymagań, jakie zostały nałożone na Wykonawcę „Projektu Technicznego SIPWW” w ramach niniejszego zamówienia (SIWZ).
Do opracowania „Projektu Technicznego SIPWW” Zamawiający rekomenduje wykorzystanie podejścia metodycznego bazującego na metodyce MDA (ang. Model Driven Architecture), notacji UML określonej przez specyfikację normy ISO/TS 19103 oraz metodzie identyfikacji wymagań FURPS+.
Zamawiający dopuszcza realizację zamówienia bazującą na podejściu równoważnym
do powyższego związaną z zastosowaniem innej specyfikacji i metody notacji wymagań
i modelu systemu, pod warunkiem wykazania przez Wykonawcę równoważności takiego rozwiązania i uzyskania przez Zamawiającego tych samych cech użytkowych produktu końcowego zamówienia, jak również osiągnięcia celu, jakiemu służy opracowanie „Projektu Technicznego SIPWW”.
1. O ile Wykonawca złożył Ofertę na opracowanie „Projektu Technicznego SIPWW” bazującą na innym podejściu metodycznym niż powyżej rekomendowane przez Zamawiającego, wówczas na etapie opracowania Planu Działania jest zobowiązany szczegółowo opisać proponowaną przez siebie metodykę modelowania i projektowania systemu SIPWW oraz powiązaną z nią notację, potwierdzając zarazem spełnienie wymagań Zamawiającego.

4.2Rekomendowana metodyka modelowania oraz projektowania SIPWW

4.2.1Wytyczne: metoda FURPS+ oraz metodyka MDA

Zamawiający wymaga, aby proces modelowania i projektowania SIPWW został oparty
o metodę FURPS+ oraz metodykę MDA (ang. Model Driven Architecture), gdzie:
1. metoda FURPS+ dostarcza systematykę wymagań i dzieli te wymagania na określone grupy:
  1. wymagania funkcjonalne, w tym związane z interfejsami (ograniczenia nakładane przez interfejsy zewnętrznych systemów);
  2. wymagania związane z użytecznością (czynnik ludzki, pomoc, dokumentacja),
    w tym prawne (licencje);
  3. wymagania związane z niezawodnością (odporność na awarie, odzyskiwanie);
  4. wymagania wydajnościowe (czas reakcji, przepustowość, dostępność, wykorzystanie zasobów);
  5. wymagania związane z rozszerzalnością produktu (możliwości dostosowania, utrzymania, konfiguracja), w tym operacyjno - implementacyjne (zarządzanie systemem w środowisku operacyjnym, związane z zasobami, narzędziami, sprzętem);
xxxxxxxx MDA wyróżnia trzy perspektywy widzenia oraz opisu modelowanego - projektowanego systemu – trzy modele:
1. CIM (ang. Computation Independent Model);
2. PIM (ang. Platform Independent Model );
3. PSM (ang. Platform Specific Model);
Zamawiający zakłada, że Oprogramowanie typu CASE musi wspierać metodykę MDA
oraz modelowanie i zapis wymagań według ustalonej systematyki, w tym przypadku FURPS+.
Proces modelowania i projektowania obejmuje model CIM i PIM w zakresie określonym
w dalszej części opracowania. Model PSM w tym przypadku wiąże się z przeprowadzeniem wstępnych, bardzo ograniczonych prac implementacyjnych potwierdzających pewne założenia techniczne budowanego rozwiązania w ramach tzw. pilotażu.
Zamawiający dopuszcza możliwość iteracyjnego, dynamicznego budowania poszczególnych diagramów UML, adekwatnie do identyfikowanych przez Wykonawcę uwarunkowań wykonawczych – potrzeb oraz zdarzeń projektowych.
1. Powyższe ma zastosowanie do czynności Wykonawcy na każdym etapie realizacji zamówienia, a nie tylko i w szczególności podczas potwierdzenia zakresu SIPWW, gdzie Wykonawca na etapie analizy i budowy modelu CIM powinien przeprowadzić analizę 90 zadań / procesów, które zgodnie z „Koncepcją SIPWW” powinny
  być wspierane przez SIPWW.
  1. Do analizy ww. zadań Wykonawca może wykorzystać wybrane przez siebie diagramy UML np. diagramy przypadków użycia rozszerzone o diagramy czynności dla złożonych scenariuszy przypadków użycia lub diagramy procesów BPMN;
  2. W wyniku analizy powinno zidentyfikować się co najmniej: aktorów, źródła danych wejściowych oraz dane wejściowe, dane wyjściowe oraz magazyny danych, usługi oraz związane z tym reguły przetwarzania;
Zamawiający wymaga, aby Wykonawca zapewnił w procesie modelowania i projektowania systemu możliwość prowadzenia analizy wpływu i śledzenia zależności pomiędzy poszczególnymi elementami diagramów UML.
Wymagany zakres opisu modelowanego systemu oraz powiązanych z tym innych wymagań zawierają poniższe zapisy:
1. Model CIM jako wynik tzw. analizy biznesowej stanowi wysokopoziomowy model biznesowy systemu, który opisuje dziedzinę (domenę) systemu poprzez identyfikację wysokopoziomowych wymagań i reprezentujących je artefaktów. W przypadku SIPWW model CIM powinien potwierdzić lub doprecyzować ostatecznie zakres systemu.
2. Model CIM powinien zawierać:
  1. słownik terminów związanych z dziedziną systemu;
  2. katalog aktorów,
  3. katalog wymagań – na tym etapie minimum wymagań funkcjonalnych;
  4. opis przypadków użycia – zawierający wyczerpujący i szczegółowy opis słowny oraz jego rozwinięcie w formie usystematyzowanej zawierające takie atrybuty
    jak: nazwa przypadku użycia, poziom ważności, aktorzy, scenariusze, warunki wstępne oraz warunki końcowe, scenariusze alternatywne, specjalne wymagania, uwagi;
  5. diagramy przypadków użycia;
  6. opcjonalnie - model encji biznesowych oraz kanoniczny model danych
    (bez specyfikowania atrybutów);
  7. inne diagramy UML, notacje związane np. z opisem zadań / procesów wspieranych przez SIPWW oraz ze zidentyfikowanymi elementami / wymaganiami systemu;
3. Model PIM jako wynik tzw. analizy systemowej opisuje zachowanie systemu
  w oderwaniu od metod, które to zachowanie implementują. Model PIM powinien zawierać:
  1. katalog aktorów (rozszerzony o identyfikowane systemy zewnętrzne);
  2. diagramy komponentów definiujące magazyny danych, usługi aplikacyjne
    oraz usługi systemowe, włącznie z wprowadzeniem niezbędnej systematyki
    dla każdej z ww. grup modelu, porządkującej proces modelowania oraz ułatwiającej weryfikację wyników;
  3. model zachowania systemu zawierający diagramy czynności opisujące kluczowe scenariusze dla przypadków użycia, na których – o ile jest to niezbędne i wynika
    z analizy - powinny zostać uwzględnione:
    1. przekaźniki danych (agregujące dane) wraz ze szczegółowym opisem, umożliwiającym określenie - przypisanie do dokumentów wejściowych / wyjściowych;
    2. partycje, zawierające wydzieloną część diagramu czynności, pogrupowane według wspólnych cech i opatrzone odpowiednim opisem – gdzie kryterium wydzielenia stanowi jednorodny proces, zjawisko lub ustalona zmienna;
  4. logiczny model danych (typy danych, klasy, związki klas, słowniki) uwzględniający przynajmniej:
    1. zdefiniowanie wymaganych klas obiektów, przypisanie utworzonym klasom co najmniej: atrybutów i metod oraz określenie ich typów;
    2. utworzenie związków między klasami, agregacji, określenie liczebności związków wraz z utworzeniem odpowiedniego diagramu klas;
    3. uporządkowanie klas w pakiety, utworzenie schematu aplikacyjnego (diagramu pakietów);
    4. zgodność (o ile jest to wymagane przepisami prawa) z modelem danych przestrzennych INSPIRE (Annex I spatial data themes - oraz jeśli zajdzie taka potrzeba – Xxxxx XX+III, biorąc pod uwagę również możliwość zmiany wskazanych powyżej wzorców);
  5. diagram pakietów i rozlokowania z „perspektywy wdrożenia” określający architekturę logiczną systemu;
  6. opcjonalnie inne diagramy, notacje UML;
Model PSM jako proces mapowania metod i technologii stanowi opis metod implementujących funkcjonalność systemu.
1. Model PSM powinien zawierać artefakty wytworzone w ramach zadań wchodzących
  w skład projektowania, bazujące na modelu wytworzonym w ramach analizy systemowej.
2. W przypadku przedmiotowego zamówienia model PSM powinien odnosić
  się do wskazania sposobu implementacji architektury logicznej SIPWW na architekturę fizyczną, w tym na określone komponenty funkcjonalne bazujące na identyfikowanych metodach i technologiach, dla których należy na podstawie analizy porównawczej
  (ang. benchmarking) ustalić minimalne wymagania wobec tych metod i technologii.
3. Opracowany model PSM powinien zawierać:
  1. definicję architektury systemu przynajmniej z perspektywy implementacyjnej – diagram rozlokowania z uwzględnieniem uwarunkowań Infrastruktury Technicznej Zamawiającego (sieć lokalna, infrastruktura dostępowa, środowisko
    do wirtualizacji zasobów, inne);
  2. model komponentów funkcjonalnych wraz z interfejsami programistycznymi
    dla usług aplikacyjnych zapewniających integrację SIPWW z innymi systemami informatycznymi Zamawiającego lub systemami otoczenia SIPWW (np. systemy informatyczne RIIP po stronie powiatów);
  3. opcjonalnie wstępny model interfejsu użytkownika dla oprogramowania aplikacyjnego, w tym model (lub wymagania) interfejsu dla serwera CMS;
  4. opcjonalnie inne diagramy, notacje UML;
4. Wszelkie czynności związane z doborem cech oraz parametrów technicznych dla metod oraz technologii muszą być poparte przeprowadzoną analizą porównawczą dostępnych na rynku IT rozwiązań / produktów oraz przyjęte z uwzględnieniem uwarunkowań, jakie nakłada w tym obszarze ustawa Prawo zamówień publicznych tj.:
  1. Art. 29 ust.3 ustawy Pzp, zakazujący opisu przedmiotu zamówienia przez wskazanie znaków towarowych, patentów lub pochodzenia, chyba że jest
    to uzasadnione specyfiką przedmiotu zamówienia i nie można opisać przedmiotu zamówienia za pomocą dostatecznie dokładnych określeń, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”;
    1. powyższe oznacza, iż w każdym przypadku, kiedy w „Projekcie Technicznym SIPWW” wystąpi konieczność wskazania znaków towarowych, patentów lub pochodzenia – wówczas, „co do zasady” należy opisać
      te wymagania poprzez określenie minimalnych wymagań, jakim mają odpowiadać rozwiązania (oferty) równoważne;
  2. Art. 30 ust. 1-4 ustawy Pzp wskazujący kolejność ustawową stosowania norm, aprobat, specyfikacji technicznych i systemów odniesienia, jak również
    ich przywołania, co nakłada na zamawiającego obowiązek dopuszczenia rozwiązania równoważnego opisywanym;
Czynności związane z opracowaniem modelu PSM Wykonawca powinien zakończyć przeprowadzeniem tzw. pilotażu dla określonej części modelu PSM, przez potwierdzenie
i zweryfikowanie założeń projektowych SIPWW dla wybranej grupy komponentów systemu, określonych poniżej.
Zakres pilotażu obejmować będzie:
1. klasy obiektów (część modelu danych), odnoszące się do wcześniej zidentyfikowanych, a na tym etapie udostępnionych na potrzeby pilotażu danych BDOT10k;
2. komponenty funkcjonalne zapewniające uruchomienie w Infrastrukturze Technicznej Zamawiającego funkcji portalu mapowego zgodnie z zakresem określonym w Rozdziale 5 Dodatek nr 2: Minimalny, zakres funkcji i usług dla prototypu SIPWW,
  a dostępnych dzięki przekazaniu przez Wykonawcę niezbędnych do tego celu licencji oprogramowania;
Na potrzeby pilotażu Xxxxxxxxxxx może udostępnić Wykonawcy następujące zasoby:
1. licencję oprogramowania: systemu zarządzania relacyjną bazą danych: Oracle 11g SE dla trzech (3) nazwanych użytkowników;
2. licencję ArcGIS Server 10.2 w wersji Enterprise Standard;
3. 2 serwery wirtualne w środowisku oprogramowania do wirtualizacji VMware Enterprise 4 o następujących parametrach technicznych: 2 rdzenie, 10GB RAM;
4. zasoby dyskowe – nie więcej niż 100 GB;
Realizując zadanie pilotażu Wykonawca powinien:
1. wygenerować z Repozytorium projektu modelową bazę danych SIPWW
  dla zakresu danych objętych pilotażem, uwzględniając przy tym kwestie ewentualnego zastosowania dodatkowych narzędzi GIS dla potrzeb przetwarzania danych przestrzennych oraz:
  1. włączenie (części) modelu danych PIM w strukturę danych wybranego przykładowego oprogramowania (w wersji testowej);
  2. zmianę nazw i typów atrybutów - jeśli jest to wymagane oraz określenie kluczy głównych i kluczy obcych, jak również wprowadzenie klas realizujących związki „wiele-do-wiele”, inne;
2. zasilić bazę danych danymi BDOT10k (całość lub wybrane warstwy);
3. skonfigurować środowisko rozwiązania prototypowego;
4. zaprezentować rozwiązanie oraz wskazać zgodność rozwiązania dla ustalonych, wybranych parametrów modelu PSM.
Wdrożenie pilotażowego rozwiązania ma na celu wyłącznie:
1. wsparcie procesu odbioru „Projektu Technicznego SIPWW”,
2. weryfikację wybranych założeń projektowych;
3. potwierdzenie możliwości zastosowania określonych rozwiązań produktowych
  i technologii GIS;
4. prezentację i (czasowy) dostęp do określonych zasobów danych przestrzennych wchodzących w zakres SIPWW;
5. poszerzenie wiedzy oraz budowanie kompetencji oraz ich doskonalenie po stronie Zespołu ds. SIPWW oraz struktur organizacyjnych odpowiedzialnych za utrzymanie
  i rozwój SIPWW;

4.2.2Wytyczne ogólne

Przedmiotem pogłębionej analizy oraz decyzji projektowych Wykonawcy podczas opracowania „Projektu Technicznego SIPWW” muszą być objęte wszystkie obiekty, wymagania, uwarunkowania wykonawcze oraz komponenty funkcjonalne jakie zostały zidentyfikowane i opisane w „Koncepcji SIPWW”.
Z uwagi na konieczność zachowania ciągłości i spójności prac pomiędzy pierwszym etapem Projektu związanym z opracowaniem „Koncepcji SIPWW” a obecnie realizowanym „Projektem Technicznym SIPWW’, Wykonawca jest zobowiązany stosować te same pojęcia, zwroty oraz nomenklaturę, jakie zostały przyjęte w „Koncepcji SIPWW”. Wyłącznie
w uzasadnionych przypadkach, za zgodą Zamawiającego, dopuszcza się wprowadzenie nowej nomenklatury, o ile będzie to miało swoje uzasadnienie merytoryczne lub praktyczne.
Celem wykazania poprawności przeprowadzenia prac w zakresie modelowania
i projektowania systemu Wykonawca jest zobowiązany do opracowania i uzgodnienia
z Zamawiającym listy kontrolnej (np. w formie macierzy), na podstawie której wykaże,
iż w pracach nad opracowaniem „Projektu Technicznego SIPWW” uwzględniono wszystkie uwarunkowania wykonawcze wskazane w „Koncepcji SIPWW” definiujące zakres SIPWW, o których mowa w pkt. 1.
Podczas prowadzenia prac analitycznych, projektowych i tworzenia zapisów w Repozytorium projektu Wykonawca musi zapewnić, iż:
1. każdy wprowadzony do Repozytorium projektu opis, stanowiący np. opis cechy obiektu, klasy, pakietu, diagramu lub innego elementu składowego modelu UML, będzie jednoznaczny, wyczerpujący w treści oraz poprawny merytorycznie, zgodnie
  z przeznaczeniem;
2. zapewnione zostaną ustalone kryteria jakości określone przez Wykonawcę w Planie Działania, bazujące również na dostępnych w oprogramowaniu typu CASE narzędziach kontrolnych i raportujących, w tym opracowanych przez Wykonawcę narzędziach inspekcji i raportowania poprawności składniowej modelu w Repozytorium projektu.
  1. Do opracowania ww. narzędzi Wykonawca powinien wykorzystać dostępne rozwiązania techniczne Oprogramowania typu CASE umożliwiające parametryzację wbudowanych funkcji kontrolnych Oprogramowania typu CASE jak również własne reguły projektowe (o ile takie określił w Ofercie lub Planie Działania), zdefiniowane za pomocą kreatora lub ręcznie, np. przy pomocy zapytań SQL do bazy projektu lub w oparciu o dedykowane rozszerzenia programowe pakietu CASE
3. decyzje projektowe mające wpływ na zakres SIPWW lub koszty, termin opracowania SIPWW lub wiążące się z określonym ryzykiem wykonawczym Wykonawca musi zawsze konsultować z Zamawiającym, przed ich podjęciem i wprowadzeniem określonych zmian do Repozytorium projektu;
4. o ile okaże się to niezbędne z uwagi na zakres i złożoność systemu, Wykonawca
  jest zobowiązany dokonać dekompozycji systemu poprzez zdefiniowanie określonych, spójnych ze sobą części systemu, z których każda może potencjalnie stanowić odrębny przedmiot przyszłych prac realizacyjnych (implementacji i wdrożenia).
  1. Punktem wyjścia do takiej oceny powinna być zidentyfikowana złożoność systemu określona przez np. liczbę klas, jakie należy zaimplementować w systemie,
    dla których nie ma gotowych - komercyjnie dostępnych produktów na rynku IT,
    co tym samym wskazywać będzie na konieczność implementacji tej części systemu, jako wyłącznie rozwiązania dedykowanego. Decyzje takie Wykonawca
    jest zobowiązany podejmować w uzgodnieniu z Zamawiającym;
5. w przypadku wydzielenia z SIPWW określonych podsystemów (części systemu SIPWW) wskazanych do realizacji oddzielnie, wymagane jest utworzenie odrębnych modeli podsystemów w Repozytorium projektu.
  1. Celem ww. podejścia jest zapewnienie możliwości elastycznego zarządzania dokumentacją SIPWW w Repozytorium projektu tak, aby możliwe było wydzielenie wyłącznie niezbędnej części dokumentacji systemu związanej
    z implementacją danego podsystemu.

4.3Wymagany zakres „Projektu Technicznego SIPWW”

Struktura / układ oraz konspekt opracowania „Projektu Technicznego SIPWW” muszą
być uzgodnione z Zamawiającym podczas opracowania Planu Działania.
Minimalny zakres opracowania „Projektu Technicznego SIPWW” – konspekt - obejmuje takie zagadnienia jak:
1. koncepcja SIPWW – ogólne założenia, w tym odniesienie do pierwotnego opracowania przez potwierdzenie lub modyfikację przyjętych założeń „Koncepcji SIPWW;
2. wyniki analizy przepisów prawa oraz uwarunkowań organizacyjno – prawnych
  po stronie Zamawiającego, jak również uwarunkowań otoczenia SIPWW;
3. opracowane poszczególne specyfikacje techniczne:
  1. zbiór wszystkich modeli, diagramów, notacji jakie zostały założone
    w Repozytorium projektu zgodnie z wymaganiami SIWZ , co w szczególności powinno zapewnić opis takich zagadnień jak:
    1. model zadań / procesów wspieranych przez system;
    2. katalog aktorów;
    3. katalog magazynów danych i źródeł danych, włącznie z określeniem harmonizacji oraz migracji danych, poparty oceną ilościową, jakościową danych odnoszącą się do niezbędnych w tym zakresie: kontroli, czynności związanych z przeprowadzeniem harmonizacji i migracji danych oraz działaniami wspomagającymi, związanymi z tworzeniem, tłumaczeniem, aktualizacją słowników dla określonych klas obiektów;
    4. zbiór wymagań FURPS+, w tym w szczególności wymagania dotyczące
      i odnoszące się do tzw. „Polityki Bezpieczeństwa Informacyjnego” jakie nakłada w tym zakresie na system oraz procesy przetwarzania i gromadzenia danych Polityka Bezpieczeństwa Informacyjnego wprowadzona Zarządzeniem Xxxxxxxxx Xxxxxxxxxxx Xxxxxxxxxxxxxxx xx 00 / 00 z dnia
      8 maja 2009 roku, w sprawie wdrożenia Polityki Bezpieczeństwa Informacyjnego oraz Zasad Zarządzania Bezpieczeństwem Informacji
      i dokumentów z nimi związanych;
    5. przypadki użycia oraz model przypadków użycia;
    6. diagramy czynności dla złożonych scenariuszy przypadków użycia;
    7. katalog dokumentów wejściowych (wnioski, podania, formularze);
    8. katalog dokumentów wyjściowych: raporty, wydruki, wyniki przetwarzania danych w formie analiz;
    9. model danych / schemat aplikacyjny SIPWW;
    10. przepływy danych prezentujące proces przetwarzania danych osobowych celem spełnienia wymagań polityki bezpieczeństwa informacji;
    11. diagram perspektywy wdrożeniowej systemu - rozlokowanie komponentów, usług, magazynów na poziomie logicznym;
    12. diagram perspektywy implementacji systemu (poziomu architektury fizycznej) – wymagania wobec metod i technologii uwzględniające uwarunkowania Infrastruktury Technicznej Zamawiającego;
  2. założenia dotyczące utworzenia katalogu metadanych, wraz z określeniem „zakresu” metadanych dla zbiorów oraz serii danych / baz danych, przez określenie minimalnego zestawu metadanych oraz niezbędnych usług zgodnie
    z obowiązującymi, w tym zakresie przepisami wykonawczymi, w tym
    z uwzględnieniem opublikowanych, obowiązujących profili metadanych
    dla objętych przez SIPWW grup tematycznych;
  3. opis wymagań wobec Infrastruktury Technicznej SIPWW, w tym wskazanie kluczowych parametrów i cech wydajnościowych Systemu odnoszących
    się do cech środowiska systemowego, które mogą mieć wpływ na wydajność
    i skalowalność systemu, w tym dobór i konfigurację podstawowych parametrów
    tej infrastruktury (serwery, zasoby dyskowe - macierze, urządzenia do archiwizacji danych, urządzenia sieciowe, inne) poparty:
    1. określeniem parametrów technicznych stanowiących zbiór kryteriów
      i miar w tym zakresie;
    2. zeskalowaniem liczby i typu infrastruktury odpowiednio do ustalonych kryteriów, w tym np. liczby użytkowników systemu;
    3. opis rozwiązań infrastruktury dostępowej do sieci publicznej Internet zapewniających niezawodność, wydajność oraz bezpieczeństwo zarówno
      na styku z Internetem jak i po stronie wewnętrznej sieci LAN;
  4. założenia dotyczące procedur i mechanizmów tworzenia kopii bezpieczeństwa danych, w tym zalecenia dotyczące obsługi danych wrażliwych;
  5. założenia dot. projektu graficznego interfejsu SIPWW, w tym głównie dla serwisów CMS;
  6. “polityka bezpieczeństwa” w zakresie utrzymania zdolności organizacyjnej
    i technicznej do zapewnienia ciągłości świadczenia usług przez SIPWW;
  7. założenia dotyczące przeprowadzenia testów akceptacyjnych, testów wydajnościowych w formie założeń do planu testów;
  8. warunki techniczne (dla Partnerów Zewnętrznych SIPWW, o których mowa
    w „Koncepcji SIPWW”) opisujące wymagania wobec tworzonych elementów składowych SIPWW współpracujących bezpośrednio z systemem takich jak: komponenty funkcjonalne lub dane wchodzące w zakres modelu danych SIPWW;
  9. inne uwarunkowania, jakie powinny być wskazane i opisane na tym etapie
    prac z punktu widzenia celu, jakiemu służy dokumentacja techniczna
    SIPWW, zapewniające prawidłowe zrealizowanie w przyszłości zamówienia
    na „Opracowanie i wdrożenie SIPWW”;
4. raporty z Etapów (do decyzji Zamawiającego w formie załączników lub suplementu);
5. pozostała dokumentacja projektowa (notatki, pisma, itp. - w formie suplementu).

4.4Rozszerzenie listy wymagań określonych w „Koncepcji SIPWW”

Z uwagi na fakt, iż SIPWW stanowić będzie system o architekturze zorientowanej na usługi (ang. Service Oriented Architecture – SOA):
1. SIPWW należy traktować jako kolekcję autonomicznych jednostek przetwarzania zintegrowanych siecią komunikacyjną, a punkty przetwarzania i tworzące
  je komponenty usług identyfikować jako tzw. węzły, które powinny komunikować
  się ze sobą za pomocą standardowych, zdefiniowanych usług (komunikatów);
2. SIPWW musi posiadać cechy zapewniające skalowalność rozwiązania oraz niezbędny stopień autonomii, tak, aby wyłączenie i brak dostępności jednego z węzłów lub wystąpienie stanu błędu w danym węźle nie wpływało na działanie pozostałej części sieci systemu – unieruchamiając inne węzły;
3. każda logicznie wydzielona część SIPWW musi być udostępniana jako usługa zarówno w komunikacji zewnętrznej, jak i wewnętrznej;
4. usługi muszą być zdefiniowane w oparciu o przyjęte standardy (W3C, OASIS) zapewniając interoperacyjność projektowanego Systemu, co w szczególności dotyczy zastosowania specyfikacji Open Geospatial Consortium (OGC);
5. usługi sieciowe SIPWW muszą być udostępnione zgodnie ze specyfikacjami
  Web Services (SOAP/HTTP) lub REST;
6. sposób komunikacji - interfejs usługi nie może wskazywać na szczegóły implementacji usługi i powinien być niezależny od platformy systemowej, na której usługa jest osadzona;
7. usługi SIPWW, dla których wymagane jest monitorowanie (np. usługi sieciowe INSPIRE) muszą być udostępniane poprzez jednorodny interfejs szyny usług (ESB), która musi zapewnić monitorowanie wybranych parametrów usług oraz zdarzeń
  w czasie rzeczywistym, umożliwiając ich rozliczalność, co wiąże się z zapewnieniem persystencji statystyk działania Systemu;
8. SIPWW musi zapewnić zarządzanie usługami, w tym możliwość dynamicznego dodawania nowych usług do rejestru, ich przekierowania (routingu), czy też usuwania
  z rejestru usług;
9. usługi muszą być zabezpieczone przez mechanizm uwierzytelnienia klienta usługi
  oraz autoryzacji usługi, działające jako odrębne usługi SIPWW, przy czym uwierzytelnienie i autoryzacja muszą być zaimplementowane w oparciu o Infrastrukturę Klucza Publicznego przy użyciu uznanych standardów np. WS-Security.

4.5Wymagania dotyczące rekomendowanych norm dla procesu analizy, projektowania oraz implementacji SIPWW

W procesie modelowania oraz projektowania SIPWW celem zapewnienia oczekiwanej wysokiej jakości powstających produktów, w tym również oczekiwanej jakości docelowego produktu, jakim jest SIPWW, Zamawiający wymaga, aby Wykonawca uwzględnił odpowiednio w Ofercie i w Planie Działania rekomendowane przez Zamawiającego,
a następnie wybrane przez Wykonawcę do zastosowania w procesie wytwórczym normy
i specyfikacje techniczne.
1. Przy wypełnieniu powyższego wymagania Wykonawca powinien uwzględnić następującą regułę związaną z zapewnieniem zastosowania rozwiązań „równoważnych”:
  1. Dla każdego wskazanego przez Zamawiającego znaku towarowego (marki), patentu, normy, aprobaty, specyfikacji technicznej lub systemu odniesienia,
    o których mowa w art. 30 ust. 1-3 ustawy Prawo zamówień publicznych, Zamawiający dopuszcza oferowanie rozwiązań "równoważnych" w stosunku
    do wskazanych, pod warunkiem, iż zapewnią one uzyskanie parametrów technicznych nie gorszych od założonych w niniejszym opisie przedmiotu zamówienia.
Rekomendowane przez Zamawiającego normy oraz specyfikacje techniczne obejmują:
1. Normy IEEE (ang. Electrical and Electronic Engineers) czyli – normy / dokumenty Stowarzyszenia Inżynierów Elektryków i Elektroników, które stanowią wytyczne
  dla typów, formatów i zawartości dokumentów projektu oprogramowania, a także działań podejmowanych w cyklu prac rozwojowych.
  1. Normy IEEE co do zasady są pomyślane jako normy instruktażowe, wyjaśniające raczej szczegółowo poszczególne działania niż podające ogólne zasady;
2. Normy ISO serii 19000 – związane z geoinformacją rekomendowane przez przepisy wykonawcze do Dyrektywy INSPIRE.

Zestawienie norm ISO serii 19000 przyjętych metodą tłumaczenia, jako normy PN

PN-EN ISO 19107: 2010 Informacja geograficzna - Schemat przestrzenny

PN-EN ISO 19108: 2010 Informacja geograficzna - Schemat czasowy

PN-EN ISO 19109: 2009 Informacja geograficzna - Reguły schematów aplikacyjnych

PN-EN ISO 19110: 2010 Informacja geograficzna - Metodyka katalogowania obiektów

PN-EN ISO 19111; 2010 Informacja geograficzna - Odniesienia przestrzenne za pomocą współrzędnych

PN-EN ISO 19113: 2009 Informacja geograficzna - Podstawy opisu, jakości

PN-EN ISO 19115: 2010 Informacja geograficzna - Metadane

PN-EN ISO 19117: 2010 Informacja geograficzna - Prezentacja

PN-EN ISO 19119: 2010 Informacja geograficzna - Usługi

PN-EN ISO 19123: 2010 Informacja geograficzna - Schemat geometrii i funkcji pokryć

PN-EN ISO 19125-1: 2010 Informacja geograficzna - Środki dostępu do obiektów prostych - Część 1: Wspólna architektura

PN-EN ISO 19125-2: 2010 Informacja geograficzna - Środki dostępu do obiektów prostych Część 2: Opcja SQL

PN-EN ISO 19128: 2010 Informacja geograficzna - Interfejs internetowego serwera map

PN-EN ISO 19135: 2010 Informacja geograficzna - Procedury rejestracji pozycji informacji geograficznej

Tabela 1 Wybrane normy serii ISO 19000 – dla zagadnień geoinformacji
W każdym przypadku, kiedy Wykonawca wskazał zastosowanie określonej normy
lub specyfikacji technicznej lub rozwiązania im równoważnego, podając w Ofercie
oraz na etapie opracowania Planu Działania ich sygnaturę, nazwę oraz przedmiot regulacji – musi podać zakres ich zastosowania, nawet, jeżeli wiąże się to z wycinkowym zastosowaniem w realizacji niniejszego zamówienia jak np. prowadzenie inspekcji danego modelu – diagramu - notacji przez identyfikację poprawności odwzorowania w tym modelu / diagramie / notacji danego zagadnienia.

5Dodatek nr 2: Minimalny, zakres funkcji i usług dla prototypu SIPWW

Utworzony przez Wykonawcę prototyp portalu mapowego bazujący na dostarczonym przez Wykonawcę oprogramowaniu dostosowany do potrzeb weryfikacji „Projektu Technicznego SIPWW” dla części modelu PSM, odnoszącego się do schematu aplikacyjnego SIPWW bazy danych BDOT10k i „prezentacji” tych danych poprzez prototyp portalu mapowego, musi zapewnić podzbiór funkcji i usług jaki wskazano dla tego typu rozwiązania w „Koncepcji SIPWW”.
W skład tego minimalnego pakietu funkcji i usług („standardowego” dla tej klasy rozwiązań) powinny wchodzić następujące funkcje i usługi:
1. posiadać funkcjonalność nawigacyjną: powiększanie, pomniejszanie, przesuwanie mapy, pomiar powierzchni różnych obiektów występujących na mapie w postaci poligonów (np. budynków), wielosegmentowy pomiar odległości, selekcję obiektów przez: zaznaczanie / selekcję obiektów linią lub poligonem, zaznaczanie / selekcję jednego lub wielu obiektów przez wskazanie ich kursorem, ustawienia skali;
2. zapewniać dostęp i możliwość podłączenia do portalu lub wydzielonego w nim serwisu mapowego usług sieciowych publikowanych przez inne serwery – dotyczy to usług sieciowych zgodnych z wymaganiami OGC: WMS, WMTS, WFS;
3. opcjonalnie - zapewniać obsługę i transformację „w locie” obowiązujących przepisami prawa układów współrzędnych, w tym co najmniej WGS84, 1992, 2000;
4. posiadać narzędzia wydruku kompozycji mapowej w zakresie:
  1. drukowania widocznego obszaru mapy wraz z legendą i podkładem mapy z podaną skalą;
  2. zapisu wydruku do pliku do formatu MS Word (DOC), w standardzie Adobe Acrobat (PDF) lub RTF oraz Open Office;
5. zawierać funkcje identyfikacji obiektów na mapie;
6. posiadać podstawowe narzędzia do wyszukiwania klas obiektów z zaimplementowanego modelu danych poprzez wyszukiwanie poprzez ich identyfikator;
7. prezentować zawartość tematyczną układu warstw portalu lub danego serwisu mapowego w postaci drzewa, z podziałem na pogrupowane tematycznie warstwy,
  z możliwością zwijania i rozwijania danej warstwy oraz włączania / wyłączania warstw na drzewie, jaki i z uaktywnianiem wybranej warstwy;
8. umożliwiać edytowanie atrybutów opisowych, przy stosownie skonfigurowanych
  do tego uprawnieniach użytkownika;
9. posiadać możliwość działania w dwóch trybach tzw. serwisu dynamicznego, czyli generującego kolejne widoki mapy na „żądanie” klienta (przeglądarki) oraz w trybie serwisu z buforem map, inaczej „cache’em”, który musi przyspieszyć działanie portalu, co oznacza, że serwer mapowy GIS musi zapewnić obsługę funkcji „kafelkowania”
  oraz buforowania (cache);
10. zapewnić prowadzenie statystyk, zawierających informacje nt. sposobu
  i częstości wykorzystania portalu;
11. zapewnić możliwość podłączenia do portalu, serwisu mapowego innych zewnętrznych źródeł danych dostępnych w ustalonych formatach jak np. SHP, DXF.
Uruchomiony przez Wykonawcę prototyp:
1. musi spełniać w zakresie minimum wymagania jakie nakłada na systemy informatyczne tzw. „Polityka Bezpieczeństwa Informacyjnego” wprowadzona Zarządzeniem Xxxxxxxxx Xxxxxxxxxxx Xxxxxxxxxxxxxxx xx 00 / 00 z dnia 8 maja 2009 roku,
  w sprawie wdrożenia Polityki Bezpieczeństwa Informacyjnego oraz Zasad Zarządzania Bezpieczeństwem Informacji i dokumentów z nimi związanych, co w szczególności dotyczy zakresu wymagań określonych przez Rozdział 8 Rozwój i utrzymanie systemu;
2. musi zapewnić poprawną pracę na każdym stanowisku pracy Zamawiającego
  (stacji roboczej) poprzez przeglądarkę internetową MS Explorer, Firefox, Chrome,
  bez konieczności instalacji dodatkowego, jakiegokolwiek oprogramowania.

6Dodatek nr 3: PBI przepisy prawa oraz normy

Treść załącznika nr 2 do Polityki Bezpieczeństwa Informacyjnego (PBI):

Ustawa z dnia 5 czerwca 1998 r. o samorządzie województwa (Dz. U. z 2013 r. poz. 596
ze zm.).
Rozporządzenie Komisji (WE) nr 885/2006 z dnia 21 czerwca 2006 r. ustanawiające szczegółowe zasady stosowania Rozporządzenia Rady (WE) nr 1290/2005 w zakresie akredytacji agencji płatniczych i innych jednostek, jak również rozliczenia rachunków EFGR i EFRROW (Dz. U. UE. L. nr 171 poz. 90 ze zm.).
Norma PN-ISO/IEC 17799 Technika informatyczna, Techniki bezpieczeństwa - Praktyczne zasady zarządzania bezpieczeństwem informacji ze stycznia 2007 r.
Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. nr 101, poz. 926 ze zm.).
Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz. U. z 2001 r. nr 112, poz. 1198 ze zm.).
Ustawa z dnia 26 czerwca 1974 r. Kodeks pracy (Dz. U. z 1998 r. nr 21, poz. 94 ze zm.).
Ustawa z dnia 29 września 1994 r. o rachunkowości (DZ. U. z 2013 r. poz. 330 ze zm.).
Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia z 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. 2004 r. nr 100 poz. 1024 ze zm.).
Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2013 r. poz. 235 ze zm.).
Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2006 r.
nr 90, poz. 631 ze zm.).
Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. z 2001 r. nr 128, poz.1402
ze zm.),
Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz. U. z 2010 r. nr 182, poz. 1228 ze zm.).
Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. 2013 r. poz. 262
ze zm.).
Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych
(Dz. U. 2012 r. poz. 526 ze zm.).

Strona 1 / 47

Document Metadata

Table of Contents

Zamówienie: Opracowanie „Dokumentacji technicznej Systemu Informacji Przestrzennej Województwa Wielkopolskiego”

Document Metadata