Plan Komunikacji



Pobieranie 383,51 Kb.
Strona3/3
Data11.04.2018
Rozmiar383,51 Kb.
1   2   3

Skró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+,

Akronim 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:

  1. (F) Functionality - funkcjonalność w rozumieniu funkcji systemu, uwzględniająca również aspekt bezpieczeństwa (ang. security);

  2. (U) Usability – użyteczność, czyli kwestia ergonomii, zagadnienia dotyczące dokumentacji, systemu pomocy;

  3. (R) Reliability - niezawodność, mierzona np. częstością występowania błędów, zagadnienia dot. odzyskiwania, przewidywalności;

  4. (P) Performance - wydajność systemu określana również, jako czas odpowiedzi lub użycie zasobów, dostępność zasobów, warunki SLA;

  5. (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


  1. Ogólny opis przedmiotu zamówienia


  1. Przedmiotem zamówienia jest opracowanie „Dokumentacji technicznej Systemu Informacji Przestrzennej Województwa Wielkopolskiego (SIPWW), zwanej dalej Projektem Technicznym SIPWW”.

  2. 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”
      ;

  3. Zakres przedmiotowy „Projektu Technicznego SIPWW” określa „Koncepcja SIPWW”
    oraz niniejsza specyfikacja.

  4. 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.




  1. 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.

  2. 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: Poznań ul. Hawelańska 10, 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).

  3. Zamówienie musi zostać zrealizowane przez Wykonawcę, na podstawie jego Oferty
    oraz zgodnie z opracowanym przez Wykonawcę i zatwierdzonym przez Zamawiającego 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;

  4. 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.

  5. 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ą.

  6. 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 Strony zasadami odnoszącymi się między innymi do uwarunkowań wykonawczych Projektu.
  1. Wymagania szczegółowe


Niniejsze rozdziały opisują zakres zamówienia oraz sposób realizacji, w tym podział na etapy,
zadania i podzadania.
    1. Wymagania dotyczące procesu projektowania SIPWW


  1. 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.

  2. Szczegółowe wymagania dotyczące przedmiotu opracowania zawiera Dodatek nr 1: Proponowana przez Zamawiającego metodyka oraz inne wymagania.

  3. Zawarte w ww. dodatku wymagania Wykonawca jest zobowiązany zastosować do realizacji niniejszego zamówienia, którego sposób przeprowadzenia określono poniżej.
    1. Sposób realizacji zamówienia

      1. Etap 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”.
        1. Zadanie: Opracowanie Planu Działania


  1. W ramach zadania Wykonawca jest zobowiązany opracować Plan Działania stanowiący uszczegółowienie sposobu realizacji zamówienia.

  2. 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.

  3. 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 Marszałka Województwa Wielkopolskiego nr 22 / 09 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

            1. 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.

  4. 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 http://www.celoxis.com/ 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.

  5. 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.

  6. Faktem potwierdzającym wdrożenie procedur określonych w Planie Działania będzie przekazanie pierwszego raportu przez Wykonawcę – na żądanie Zamawiającego.
      1. Etap 2: Przygotowanie metodyczne, w tym analiza otoczenia SIPWW


  1. 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.

  2. 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 Strony 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.
        1. Zadanie: Dostawa oprogramowaniu typu CASE oraz przygotowanie repozytorium projektowego


  1. 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 Bazodanowe 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ą Ofertę złożył Wykonawca) dodatkowy pakiet 10 procedur kontroli – reguł projektowych, ponad funkcje kontroli standardowo dostępne w dostarczonym przez Wykonawcę Oprogramowaniu
      typu CASE.
        1. Zadanie: Przygotowanie zespołu Zamawiającego do współdziałania przy opracowaniu Projektu Technicznego SIPWW


  1. 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”.

  2. 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.

  3. Ww. zadanie musi być w całości zrealizowane i odebrane przez Zamawiającego przed przystąpieniem Stron do jakichkolwiek konsultacji i uzgodnień wymagających ze strony Zamawiającego niezbędnego przygotowania metodycznego.
          1. Przeprowadzenie szkolenia – prezentacji dla pracowników Zamawiającego;

  1. W ramach podzadania Wykonawca jest zobowiązany przeprowadzić szkolenie - prezentacje
    z zakresu:

      1. obiektowej metodyki modelowania i projektowania zgodnej z wymaganiami określonymi w niniejszej specyfikacji oraz zgodnej z przyjętą przez Wykonawcę metodyką realizacji zamówienia, opisaną w Planie Działania;

      2. procesu wytwórczego „Projektu Technicznego SIPWW”;

      3. głównych funkcji oraz cech użytkowych oprogramowania typu CASE.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.
          1. Przeprowadzenie specjalistycznego, certyfikowanego szkolenia z oprogramowania typu CASE.

  1. 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.

  2. 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.

  3. 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.

  4. 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.
        1. Zadanie: Analiza uwarunkowań prawnych, organizacyjno – technicznych oraz otoczenia SIPWW


  1. 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”.
      1. Etap 3: Opracowanie Projektu Technicznego SIPWW


  1. 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.

  2. 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”.

  3. 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.
        1. Zadanie: Przeprowadzenie warsztatów wymagań


  1. 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.

  2. 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.

  3. Do prezentacji przykładowych usług i funkcji tożsamych z SIPWW, Wykonawca powinien wykorzystać:

    1. dostępne publicznie portale mapowe województwa m.in.: 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.

  4. 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.

  5. Termin przeprowadzenia warsztatów musi być uzgodniony z Zamawiającym.

  6. Czas trwania warsztatów: 1 lub 2 cykle, łącznie do 4 godzin, dla grupy osób nie większej
    niż 50 osób.

  7. Do przeprowadzenia warsztatów Wykonawca musi wykorzystać własny sprzęt komputerowy i oprogramowanie oraz przygotowane dane - bazę testową.

  8. 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.

  9. 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.
        1. Zadanie: Opracowanie dokumentacji „Projektu Technicznego SIPWW”


  1. 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.

  2. 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.

  3. 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;

  4. 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.

  5. 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.
        1. Zadanie: Przygotowanie logotypu SIPWW oraz prezentacji multimedialnej podsumowującej wyniki prac


  1. 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.

  2. 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;

  3. 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 Zamawiającego.

    1. Zamawiający na dokonanie oceny i wybór scenariusza, a także na akceptację
      lub przedstawienie Wykonawcy uwag do scenariusza ma 3 Dni Robocze, a Wykonawca ma również 3 Dni Robocze na uwzględnienie wszystkich uwag Zamawiającego.

  4. 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.

  5. Opracowanie logotypu musi nastąpić na podstawie przygotowanych przez Wykonawcę minimum 3 różnych projektów, z których ostatecznie jeden zostanie zatwierdzony przez Zamawiającego.

    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 Robocze na uwzględnienie wszystkich uwag Zamawiającego.

  6. 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;

  7. 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 m.in.: kolory przewodnie, wybór czcionki/czcionek.
      1. Etap 4: Przeprowadzenie procedury Odbioru Końcowego


  1. 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ń.

  2. 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ą.

  3. Na żądanie Zamawiającego Wykonawca jest zobowiązany do zaprezentowania uzyskanych wyników prac przed Zarządem Województwa Wielkopolskiego.
    1. Wymagania dotyczące dokumentacji


  1. W każdym przypadku, kiedy następować będzie przekazanie dokumentacji opracowanej przez Wykonawcę, musi być ona przekazana w formie papierowej, w liczbie jednego egzemplarza z każdego rodzaju 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.

  2. 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.

  3. 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.
    1. Wymagania wobec Oprogramowania

      1. Oprogramowanie typu CASE


  1. 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#, VB.Net, 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.

  2. 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”.

  3. 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.
      1. Oprogramowanie Bazodanowe


  1. 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ę.
      1. Oprogramowanie Aplikacyjne, Standardowe, Narzędziowe i Systemowe


  1. 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.

  2. 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.

  3. 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.



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

    1. Założenia


  1. 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).

  2. 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+.

  3. 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.
    1. Rekomendowana metodyka modelowania oraz projektowania SIPWW

      1. Wytyczne: metoda FURPS+ oraz metodyka MDA


  1. 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);

  2. metodyka 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);

  3. 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+.

  4. 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.

  5. 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;

  6. 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.

  7. 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 – Annex II+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;

  8. 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;

  9. 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.

  10. 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;

  11. Na potrzeby pilotażu Zamawiający 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;

  12. 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.

  13. 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;
      1. Wytyczne ogólne


  1. 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”.

  2. 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.

  3. 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.

  4. 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.
    1. Wymagany zakres „Projektu Technicznego SIPWW”


  1. Struktura / układ oraz konspekt opracowania „Projektu Technicznego SIPWW” muszą
    być uzgodnione z Zamawiającym podczas opracowania Planu Działania.

  2. 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 Marszałka Województwa Wielkopolskiego nr 22 / 09 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).
    1. Rozszerzenie listy wymagań określonych w „Koncepcji SIPWW”


  1. 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.
    1. Wymagania dotyczące rekomendowanych norm dla procesu analizy, projektowania oraz implementacji SIPWW


  1. 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.

  2. 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

  1. Tabela 1 Wybrane normy serii ISO 19000 – dla zagadnień geoinformacji

  2. 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.
  1. Dodatek nr 2: Minimalny, zakres funkcji i usług dla prototypu SIPWW


  1. 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”.

  2. 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.

  3. 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 Marszałka Województwa Wielkopolskiego nr 22 / 09 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.
  1. Dodatek nr 3: PBI przepisy prawa oraz normy


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

  1. Ustawa z dnia 5 czerwca 1998 r. o samorządzie województwa (Dz. U. z 2013 r. poz. 596
    ze zm.).

  2. 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.).

  3. Norma PN-ISO/IEC 17799 Technika informatyczna, Techniki bezpieczeństwa - Praktyczne zasady zarządzania bezpieczeństwem informacji ze stycznia 2007 r.

  4. Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. nr 101, poz. 926 ze zm.).

  5. 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.).

  6. Ustawa z dnia 26 czerwca 1974 r. Kodeks pracy (Dz. U. z 1998 r. nr 21, poz. 94 ze zm.).

  7. Ustawa z dnia 29 września 1994 r. o rachunkowości (DZ. U. z 2013 r. poz. 330 ze zm.).

  8. 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.).

  9. 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.).

  10. Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2006 r.
    nr 90, poz. 631 ze zm.).

  11. Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. z 2001 r. nr 128, poz.1402
    ze zm.),

  12. Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz. U. z 2010 r. nr 182, poz. 1228 ze zm.).

  13. Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. 2013 r. poz. 262
    ze zm.).

  14. 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   2   3


©operacji.org 2017
wyślij wiadomość

    Strona główna