szczegółowy opis przedmiotu zamówienia w postępowaniu o

Transkrypt

Załącznik 5 do SIWZ
SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA
W POSTĘPOWANIU O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO PROWADZONYM
W TRYBIE PRZETARGU NIEOGRANICZONEGO
NA
BUDOWĘ NOWOCZESNEGO SYSTEMU INFORMATYCZNEGO NA POTRZEBY OBSŁUGI
INTERESANTÓW ORAZ JEDNOSTEK ORGANIZACYJNYCH MIASTA ZAWIERCIE PN
WIRTUALNE BIURO OBSŁUGI INWESTORA
Specyfikacja Istotnych Warunków Zamówienia
1.
WPROWADZENIE .................................................................................................................................................. 3
1.1.
1.2.
1.3.
2.
Załącznik 5
CHARAKTERYSTYKA ZAMAWIAJĄCEGO .............................................................................................................. 3
CEL OGÓLNY ZAMÓWIENIA .................................................................................................................................. 3
CELE SZCZEGÓŁOWE ZAMÓWIENIA ...................................................................................................................... 3
SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA ................................................................................. 3
2.1.
MIEJSCE REALIZACJI ZAMÓWIENIA ...................................................................................................................... 3
2.2.
POGLĄDOWY OPIS DOCELOWEGO SYSTEMU ......................................................................................................... 3
2.3.
WYMAGANIA FUNKCJONALNE DLA OPROGRAMOWANIA ...................................................................................... 4
2.3.1.
Podstawowe wymagania funkcjonalne ....................................................................................................... 4
2.3.2.
Dodatkowe wymagania funkcjonalne dotyczące rozwiązań systemowych dla zarządzania danymi
przestrzennymi. ........................................................................................................................................................... 5
2.3.2.1. Struktura i zakres informacyjny bazy danych oraz jej minimalna konfiguracja powinna zapewniać: .... 5
2.3.2.2. Serwer danych przestrzennych. Minimalne wymagana funkcjonalność serwera danych przestrzennych:
6
2.3.3.
Moduł zasilania bazy danych. Minimalne wymagania funkcjonalne zasilania bazy danych ...................... 6
2.3.4.
Prezentacja i kompozycja map . Minimalne wymagania funkcjonalne dotyczące prezentacji i kompozycji
map
7
2.3.5.
Portal Inwestora. Minimalne wymagana funkcjonalność Portalu Inwestora:............................................ 7
2.4.
WYMAGANIA POZAFUNKCJONALNE ..................................................................................................................... 7
2.4.1.
Bezpieczeństwo systemu .............................................................................................................................. 7
2.4.2.
Neutralność technologiczna ........................................................................................................................ 8
2.4.3.
Przenośność ................................................................................................................................................ 8
2.4.4.
Elastyczność ................................................................................................................................................ 9
2.4.5.
Wydajność ................................................................................................................................................... 9
2.4.6.
Dane Przestrzenne ...................................................................................................................................... 9
2.5.
WYMAGANIA DOTYCZĄCE SPRZĘTU .................................................................................................................. 10
2.6.
INNE WYMAGANIA ............................................................................................................................................. 10
2.6.1.
Proces wytwórczy oprogramowania ......................................................................................................... 10
2.6.2.
Testy systemu ............................................................................................................................................ 10
2.6.2.1. Plan testów ............................................................................................................................................ 11
2.6.2.2. Specyfikacja testów .............................................................................................................................. 11
2.6.2.3. Uruchomienie testów i dokumentacja uruchomienia testów ................................................................. 12
2.6.2.4. Wykonanie i raportowanie testów......................................................................................................... 12
2.6.3.
Dokumentacja ........................................................................................................................................... 12
2.6.4.
Warunki gwarancji ................................................................................................................................... 13
2.6.5.
Równoważność rozwiązań ........................................................................................................................ 13
2.7.
SZCZEGÓŁOWY OPIS ZADAŃ .............................................................................................................................. 14
2.7.1.
Ramowy harmonogram prac..................................................................................................................... 14
2.7.1.1. Etap 1 .................................................................................................................................................... 14
2.7.1.2. Etap 2 .................................................................................................................................................... 14
2.7.1.3. Etap 3 .................................................................................................................................................... 14
2.7.1.4. Etap 4 .................................................................................................................................................... 15
2.7.1.5. Odbiór całościowy Systemu.................................................................................................................. 15
3.
INFORMACJE ZWIĄZANE Z REALIZACJĄ PRZEDMIOTU ZAMÓWIENIA ......................................... 15
3.1.
3.2.
SPOSÓB ORGANIZACJI PROJEKTU ....................................................................................................................... 15
MIEJSCA DOSTAW SPRZĘTU ............................................................................................................................... 15
Znak sprawy: Zp.341/118/2010
2
Załącznik 5
1. WPROWADZENIE
1.1. Charakterystyka Zamawiającego
Gmina Zawiercie
ul. Leśna 2; 42-400 Zawiercie
tel.: +48 32 67 216 61, tel./fax: +48 32 67 215 13, +48 32 67 226 84
http://www.zawiercie.eu/
email: [email protected]
1.2. Cel ogólny zamówienia
System będzie świadczył usługi dla następujących kategorii użytkowników; osób fizycznych planujących lub nie
planujących rozpoczęcia działalności gospodarczej, oraz osób fizycznych przyjeżdżających do Zawiercia w celach
turystycznych. Dodatkowo system będzie obsługiwał przedsiębiorców i potencjalnych inwestorów zarówno z terenu
gminy jak i z poza niej. Dla każdej z tych grup użytkowników system będzie realizował specyficzne funkcjonalności.
1.3. Cele szczegółowe zamówienia
Przedmiotem projektu będzie budowa nowoczesnego systemu informatycznego na potrzeby obsługi interesantów (osób
fizycznych, instytucji i podmiotów gospodarczych) oraz jednostek organizacyjnych miasta Zawiercie. System ten
będzie wspomagał pozyskiwanie nowych inwestorów dla terenu miasta Zawiercie.
2. SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA
2.1. Miejsce realizacji zamówienia
Całość projektu będzie realizowana w siedzibie Zamawiającego w budynku Urzędu Miejskiego, ul. Leśna 2, Zawiercie.
2.2. Poglądowy opis docelowego systemu
Przedmiotem realizowanego projektu jest budowa nowoczesnego systemu informatycznego na potrzeby obsługi
interesantów (osób fizycznych, instytucji i podmiotów gospodarczych) oraz jednostek organizacyjnych miasta,
wspieranych przez System Informacji o Terenie (SIT).
System Informacji o Terenie będzie dotyczył geodezji i gospodarki gruntami, którego integralną częścią będą dane z
elektronicznej ewidencji gruntów, budynków, lokali oraz plan sieci uzbrojenia terenu. Projekt jest bezpośrednio
skierowany do obywateli, przedsiębiorców, jak również do urzędników pracujących w Urzędzie Miejskim w Zawierciu
oraz jednostek organizacyjnych podległych Miastu, a także jednostek gospodarczych nadzorujących infrastrukturę
techniczną miasta.
System, Informacji o Terenie (SIT) zwany potocznie GIS czyli "Geographical Information System", który zostanie
zrealizowanym w ramach niniejszego projektu będzie posiadał następujące, niżej wymienione cechy:
 udostępnianie mechanizmów wprowadzania, gromadzenia i przechowywania danych przestrzennych oraz
zarządzania nimi, zapewnia ich integralność i spójność oraz pozwala na ich wstępną weryfikację.
 na podstawie zgromadzonych w systemie danych możliwe będzie przeprowadzenie specyficznych analiz
opierających się m.in. na relacjach przestrzennych między obiektami.
 wyniki analiz przestrzennych i operacji charakterystycznych dla programów bazodanowych przedstawione
będą w postaci opisowej (tabelarycznej) lub graficznej (mapa, diagramy, wykresy, rysunki), stąd cechą GIS
jest wizualizacja i udostępnianie informacji przestrzennych w żądanej postaci.
Wymaga się aby powstały system był zgodny z następującymi regulacjami:








Ustawą Prawo geodezyjne i kartograficzne z dnia 17 maja 1989 r.
Ustawą Dostęp do informacji publicznej z dnia 6 września 2001 r.
Ustawą Prawo ochrony środowiska z dnia 27 kwietnia 2001 r.
Ustawą O samorządzie gminnym z dnia 8 marca 1990 r.
Ustawą Administracja rządowa w województwie z dnia 5 czerwca 1998 r.
Ustawą Planowanie i zagospodarowanie przestrzenne z dnia 27 marca 2003 r.
Ustawą Gospodarka nieruchomościami z dnia 21 sierpnia 1997 r.
Ustawą o niektórych formach wspierania działalności innowacyjnej z dnia 29 lipca 2005 r.
3











Załącznik 5
Ustawą Informatyzacja działalności podmiotów realizujących działania publiczne z dnia 17 lutego 2005 r.
Ustawą Ochrona informacji niejawnych z 22 stycznia 1999 r.
Ustawa o podpisie elektronicznym z dnia 18 września 2001 r.
Ustawa o ochronie danych osobowych z dnia 29 sierpnia 1997 r.
Ustawa o świadczeniu usług drogą elektroniczną z dnia 18 lipca 2002 r.
Ustawa o ochronie baz danych z dnia 27 lipca 2001 r.
Ustawą Prawo budowlane z dnia 7 lipca 1994 r.
Ustawa o infrastrukturze informacji przestrzennej z dnia 7 marca 2010 r..
wraz z ich aktami wykonawczymi;
Zgodność z instrukcjami i wytycznymi GUGIK;
Zgodność z normami ISO:
o model metadanych dla zbiorów danych przestrzennych musi być zgodny z
ISO19115:2003/cor.1:2006;
o model metadanych dla serwisów geoinformacyjnych musi być zgodny z ISO
o 19119:2005/DAmd 1;
o implementacja modelu metadanych musi być zgodna z ISO19139:2007;
System powinien składać się z komponentów takich jak:


System Biuro Obsługi Inwestora – zawierający moduły realizujące zadania związane z obsługą inwestorów
o Moduł – portal internetowy /intranetowy
o Moduł – obsługi spraw
o Moduły pozostałe niezbędne do realizacji zadań związanych z obsługą inwestora
System dla prezentacji i edycji Danych Przestrzennych
o Moduł Plan Miasta Zawiercie
o Moduły pozostałe niezbędne do zarządzania danymi przestrzennymi dla Systemu „Biuro Obsługi
Inwestora”
Wszystkie komponenty powinny być zintegrowane wokół Portalu Internetowego oraz wykorzystywać bazę danych. To
Wykonawca w ramach opisu koncepcji rozwiązania powinien określić zakres modułowy niezbędny do realizacji
Systemów „Biura Obsługi Inwestora” oraz Systemu do prezentacji i edycji Danych Przestrzennych.
Wszystkie komponenty rozwiązania w tym systemy oraz moduły, o których mowa w tej specyfikacji nie mogą opierać
się na oprogramowaniu, którego wykorzystanie przez Zamawiającego w dowolnej ilości co do użytkowania i instalacji
lub przez inne podmioty, którym Zamawiający użyczy to oprogramowania, uzależnione byłoby od konieczności
uzyskania płatnych licencji od osób trzecich.
2.3. Wymagania funkcjonalne dla oprogramowania
2.3.1. Podstawowe wymagania funkcjonalne
System powinien spełnić warunek elastyczności oraz zapewniać możliwość rozbudowy poprzez zapewnienie
architektury trójwarstwowej.
2. System powinien posiadać budowę modułową, logicznie rozdzielającą grupy funkcjonalne.
3. Interfejs użytkownika zewnętrznego Systemu powinien być oparty na przeglądarce internetowej.
4. W ramach wspomnianego interfejsu użytkownik posiadać powinien możliwość korzystania ze wszystkich
funkcjonalności, które są dla niego udostępnione poprzez moduł uprawnień.
5. System powinien zapewnić poprawne działanie konsoli administracyjnej oraz części serwisu służącej
publikacji treści z poziomu przeglądarki internetowej (typy przeglądarek internetowych obsługujących owo
wymaganie zostanie określone na etapie analizy).
6. System powinien zapewnić zarządzanie i kontrolę uprawnień dla jego poszczególnych modułów, formularzy,
funkcji i elementów repozytorium.
7. Serwer aplikacji systemu powinien umożliwić pracę pod kontrolą różnych systemów operacyjnych z rodziny
MS Windows oraz Linux.
8. Serwer aplikacji systemu powinien wspierać architekturę SOA (Architektura zorientowana na usługi ang.
Service Oriented Architecture).
9. System powinien umożliwić przechowywanie danych w bazie danych.
10. System powinien spełnić wymagania technologiczne:
a. JAVA lub równoważny język programowania
b. JEE lub technologia równoważna
c. XML
d. XSLT
1.
4
Załącznik 5
11. System powinien być zgodny ze standardami:
a. WAI – jest inicjatywą W3C (World Wide Web Consortium), której głównym założeniem jest
zwiększenie szeroko rozumianej dostępności stron www. W ramach tych działań ustalane są
wytyczne mające na celu umożliwienie dostępu do treści osobom niepełnosprawnym (z wadami
wzroku lub słuchu), użytkowników łącz o niskiej przepustowości, narzędzi mobilnych (palmtopy,
telefony komórkowe) lub przestarzałych.
b. XHTML (ang. Extensible HyperText Markup Language) jest opisanym w specyfikacji W3C językiem
służącym do tworzenia stron www ogólnego przeznaczenia. Dokumenty stworzone zgodnie ze
standardem XHTML, są jednocześnie poprawnymi dokumentami XML, co pozwala na generowanie
lub przekształcanie ich w inne dokumenty XML za pomocą języka transformacji dokumentów XSLT.
Walidacja (X)HTML zapewnia poprawne i szybkie wyświetlanie stron WWW.
c. CSS (ang. Cascading Style Sheets) – kaskadowe arkusze stylów są stworzonym przez W3C językiem
służącym do opisu sposobu renderowania stron WWW. Walidacja CSS zapewnia poprawne
wyświetlenie strony w przeglądarkach.
d. UTF-8 – system kodowanie w standardzie Unicode, uznany przez W3C za obowiązujący w
odniesieniu do tworzonych stron internetowych.
12. Schemat nawigacji portalu powinien być spójny i intuicyjny.
13. Rdzeniem Portalu Internetowego powinien być Content Management System.
14. Narzędzie CMS powinno umożliwiać pełne zarządzanie strukturą portalu (działami i wiadomościami),
tworzenie stron portalu na podstawie zdefiniowanych szablonów a także późniejsza modyfikację tych stron.
15. Każda wiadomość winna być akceptowana przez uprawnioną osobę przed publikacją.
16. System powinien zapewnić możliwość archiwizowania publikacji treści.
17. System powinien zapewnić możliwość zarządzania użytkownikami i ich uprawnieniami, a także możliwość
zdefiniowania uprawnień do poszczególnych zasobów, sekcji, modułów i czynności.
18. Edycja stron www powinna być możliwa z dowolnego komputera w sieci wyposażonego w przeglądarkę
internetową i nie wymaga od użytkownika żadnej wiedzy technicznej, w szczególności tej dotyczącej języka
HTML.
19. Funkcjonalność modułu CMS powinna dawać pełną kontrolę nad procesem publikacji stron www oraz
pozwalać wydzielić obszary uprawnień dla osób odpowiedzialnych za utrzymanie serwisu.
20. Redagowanie treści powinni odbywać się w trybie WYSIWYG (What You See Is What You Get), co oznacza,
że edytujący widzi na bieżąco jak strona będzie wyglądała po opublikowaniu w serwisie.
21. Bardziej zaawansowani użytkownicy powinni móc przełączyć się z trybu WYSIWYG w tryb tekstowy, w
którym to można bezpośrednio edytować źródło HTML.
22. Zarządzanie serwisem www (modyfikacja treści, rozbudowa struktury) powinna być dostępna tylko dla
autoryzowanych użytkowników.
23. Edycja treści powinna być wspierana przez rozbudowany mechanizm zatwierdzania i publikacji informacji.
24. Użytkownicy powinni być podzieleni wg ról, praw i obszarów serwisu, do których mają dostęp.
25. Każda modyfikacja zawartości portalu powinna być związana z procesem zatwierdzania oraz publikacji.
26. Integralną częścią platformy Portalu powinny być usługi indeksowania i przeszukiwania treści.
27. Funkcjonalności obsługi inwestora powinny sprzyjać pozyskaniu inwestorów dla regionu. Dzięki szczegółowej
ofercie inwestycyjnej oraz opisie procesu inwestycyjnego potencjalny inwestor powinien mieć możliwość
wybrania miejsca inwestycji oraz zapoznania się ze sposobem załatwiania spraw w urzędach.
28. Funkcjonalności obsługi inwestora powinny umożliwiać prezentacje i dystrybucję informacji dotyczących
zwiększania aktywności gospodarczej, rozszerzania przedsiębiorczości, aktywizacji inwestycyjnej.
29. Funkcjonalności Obsługi inwestora powinny być narzędziem pozyskiwania inwestorów i prezentacji ofert
inwestycyjnych.
30. Moduł powinien posiadać interfejs w języku polskim i angielskim.
31. Całość rozwiązań informatycznych powinna zapewniać realizację otwartej architektury systemu informacji
przestrzennej gwarantując ich rozbudowę czyli powiększenie w dowolnym czasie jego zakresu tematycznego o
nowe bazy danych i nowe warstwy informacyjne, oraz jego zasięgu terytorialnego o nowe, nie uczestniczące
wcześniej w systemie, jednostki osadnicze i administracyjne.
32. System WBOI powinien zapewniać gromadzenie danych w relacyjnej bazie danych.
33. System powinien posiadać mechanizmy umożliwiające automatyczne oraz ręczne zasilanie danymi
przestrzennymi pochodzącymi z innych systemów.
2.3.2. Dodatkowe wymagania funkcjonalne dotyczące rozwiązań systemowych dla zarządzania danymi
przestrzennymi.
2.3.2.1. Struktura i zakres informacyjny bazy danych oraz jej minimalna konfiguracja powinna
zapewniać:
1.
Obsługiwać nielimitowaną (nieograniczona licencją) liczbę obsługiwanych użytkowników
5
Załącznik 5
Obsługiwać nielimitowaną (nieograniczona licencją) liczbę obsługiwanych instalacji (serwerów,
procesorów).
3. Zarządzanie dostępem do danych,
4. Przechowywanie i udostępnianie przestrzennych danych wektorowych i rastrowych, danych opisowych
jak również dokumentów i plików obrazu,
5. Pełną integrację danych geometrycznych i opisowych,
6. Możliwość tworzenia powiązań pomiędzy dokumentami i obrazami gromadzonymi w bazie a obiektami
przestrzennymi,
7. Zachowanie ciągłości danych przestrzennych dla całego obszaru objętego projektem,
8. Bezpieczną edycję danych w trybie wielodostępu,
9. Możliwość przechowywania wielu wersji danych oraz pracy w trybie długich transakcji,
10. Możliwość rejestrowania i przechowywania historii dokonywanych zmian,
11. Możliwość zadawania zapytań obejmujących wszystkie typy danych zgromadzone w bazie (w tym dane
przestrzenne) przy pomocy standardowego języka zapytań SQL,
12. Możliwość definiowania reguł poprawności danych na poziomie modelu danych, w szczególności: reguł
poprawności topologicznej danych wektorowych, reguł poprawności merytorycznej poprzez konstrukcję
odpowiednich słowników i domen atrybutów, określanie obowiązkowości wypełnienia atrybutów oraz
budowanie relacji pomiędzy poszczególnymi klasami obiektów.
2.
2.3.2.2. Serwer danych przestrzennych. Minimalne wymagana funkcjonalność serwera danych
przestrzennych:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Obsługiwać nielimitowaną (nieograniczona licencją) liczbę obsługiwanych użytkowników.
Powinien spełniać wymagania i standardy Open GIS Consortium OGIS.
Powinien mieć budowę modularną, opartą o platformę programistyczną, umożliwiającą tworzenie nowych
aplikacji (rozszerzeń), wykorzystujących dane przestrzenne, relacyjne bazy danych i technologie
internetowe.
Powinien umożliwiać w dowolnym momencie dodanie nowego modułu (aplikacji) do istniejącej
konfiguracji wzbogacając System o nowe funkcjonalności, bez konieczności wymiany całego systemu.
Powinien umożliwiać dostęp użytkowników końcowych Systemu w modelu klient-serwer poprzez
przeglądarkę internetową z zastosowaniem mechanizmów autoryzacji użytkowników oraz przydzielania
im uprawnień do różnych funkcjonalności systemu.
Powinien posiadać interfejs dostępu do danych przestrzennych i opisowych zawartych w bazie danych
Systemu poprzez dedykowany interfejs graficzny (ang.: GUI – Graphical User Interface)
Posiadać opcje działania w dwóch trybach tzw. serwisu dynamicznego, czyli generującego kolejne
widoki mapy na „żądanie” klienta (przeglądarki) oraz w trybie serwisu „cache’owanego” i „ciętego”,
który powinien przyspieszyć działanie portalu,
Powinien posiadać możliwość bezpośredniego odczytu następujących formatów danych wektorowych
OGC WMS, OGC WFS: geobaza, shapefiles, SDC, VPF, Web Services,
W zakresie analiz przestrzennych:
a. możliwość wykonania analiz sieciowych (Network Analyst)
b. możliwość wykonania analiz przestrzennych (Spatial Analyst)
c. możliwość wykonania analiz geostatystycznych (Geostatistical)
2.3.3. Moduł zasilania bazy danych. Minimalne wymagania funkcjonalne zasilania bazy danych
1.
2.
Powinien umożliwiać import oraz poprawną interpretację co najmniej następujących formatów
danych:
a. dane przestrzenne (mapowe), o charakterze wektorowym co najmniej w formatach SHP+DBF,
SWDE, CAD, Mapinfo (mif), MicroStation (dgn), GML 2.0, 3.1, 3.2 i rastrowym co najmniej w
formacie GeoTIFF,
b. dane opisowe (tekstowe), o uporządkowanej strukturze w postaci tabel co najmniej w formatach
XLS,
c. dane w postaci plików zapisanych w znanym formacie/standardzie wymiany danych (m.in.: pliki
SWDE lub elektroniczne dokumenty XML),
d. dane multimedialne, do których można zaliczyć obrazy (zdjęcia, rysunki, schematy, mapy
poglądowe, inne), pliki dźwiękowe oraz pliki wideo.
Powinien posiadać możliwość zasilania bazy danych systemu
a. wsadowego ładowania danych przez zastosowanie standardowych formatów wymiany danych
(np.: GML, SWDE, SHP+DBF, MAP+TAB, Mapinfo (mif), MicroStation (dgn), GML 2.0, 3.1,
3.),
6
Załącznik 5
konfiguracji systemu określającej ścieżki dostępu do danych graficznych (wektorowych,
rastrowych) i opisowych (tabelarycznych), które mają być ładowane do systemu w procesie jego
aktualizacji w określonych interwałach czasu lub po pojawieniu się nowej wersji pliku
źródłowego,
c. osobistego zarządzania warstwami przez administratora lub użytkownika z odpowiednimi
uprawnieniami, polegającego na możliwości pobierania warstw graficznych z centralnej bazy
danych Systemu w celu jej edycji (aktualizacji), a następnie zaimportowanie jej powtórnie do
systemu
Powinien posiadać możliwość realizowania procedur zasilania bazy danych Systemu, jako procedur
automatycznych lub / i półautomatycznych (wykonywanych przez system na żądanie administratora)
Powinien posiadać możliwość ładowania danych do Systemu metodą zastosowania dedykowanych
skryptów, wykonujących operacje SQL wprost na bazie danych
b.
3.
4.
2.3.4. Prezentacja i kompozycja map . Minimalne wymagania funkcjonalne dotyczące prezentacji i
kompozycji map
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Powinien posiadać zestaw narzędzi do swobodnego poruszania się po mapie
Powinien posiadać możliwość swobodnego i łatwego komponowania treści mapy
Powinien umożliwiać obsługę dowolnej ilości warstw wektorowych i rastrowych
Powinien posiadać możliwość definiowania globalnych i indywidualnych ustawień graficznych
poszczególnych warstw tematycznych
Powinien posiadać możliwość opisywania obiektów i obsługi ich włączania i wyłączania
(etykietowanie)
Powinien posiadać funkcję optymalizacji prezentowanych warstw tematycznych i interaktywnego
reagowania na działania użytkownika
Powinien umożliwiać obsługę wielu układów współrzędnych
Powinien posiadać mechanizmy łatwej i różnorodnej selekcji obiektów jednej lub wielu warstw
tematycznych jednocześnie
Powinien posiadać możliwość szybkiego uzyskiwania informacji na temat wyszukanych obiektów
Powinien posiadać narzędzia wykonywania różnorodnych pomiarów na mapie
Powinien posiadać możliwość zastosowania różnych scenariuszy działania systemu w zależności od
wspieranego procesu zarządczego lub decyzyjnego (np.: predefiniowane układy warstw tematycznych
o określonej symbolice i kolorystyce, inne)
Powinien umożliwiać korzystanie przez użytkownika ze zdefiniowanych przez administratora systemu
standardowych zapytań, wspomagających proces zarządczy lub decyzyjny.
Powinien umożliwiać Korzystanie przez użytkownika ze zdefiniowanych przez administratora systemu
standardowych formularzy, raportów, wspomagających proces zarządczy lub decyzyjny.
2.3.5. Portal Inwestora. Minimalne wymagana funkcjonalność Portalu Inwestora:
1.
2.
3.
4.
5.
6.
Powinien być wykonany w technologii CMS (ang.: Content Management System).
Powinien posiadać postać wielofunkcyjnego portalu GIS, wzbogaconego o prostą w obsłudze
interaktywną mapę.
Powinien prezentować wybrane dane referencyjne ładowane z bazy danych (bezpośrednio lub z
dedykowanej kopii bazy danych) i aktualizowane automatycznie lub na żądanie administratora.
Powinien umożliwiać prezentację danych przestrzennych różnego typu: rastrowych, wektorowych,
punktowych, zdjęć, opisów tekstowych, itp..
Powinien umożliwiać integrację informacji opisowych i graficznych prezentowanych w oknie portalu
o nieruchomościach gminy.
Powinien być włączony w strukturę oficjalnego serwisu internetowego Urzędu i dostępny z poziomu
głównej strony WWW. Wejście do niego nie może nakładać na internautę konieczności pobierania i
instalowania dodatkowego oprogramowania (np. środowiska JRE, ActiveX itp.)
2.4. Wymagania pozafunkcjonalne
2.4.1. Bezpieczeństwo systemu
Wymaga się, żeby zarówno cały system, jak i jego poszczególne części składowe charakteryzowały się wysokim
poziomem bezpieczeństwa. Bezpieczeństwo obejmuje odporność na ataki oraz wykrywanie ataków zewnętrznych i
wewnętrznych. System i wchodzące w jego skład dostarczone przez Wykonawcę oprogramowanie standardowe
umożliwi instalowanie poprawek podnoszących bezpieczeństwo systemu.
7
Załącznik 5
Komunikacja pomiędzy Systemem i podmiotami zewnętrznymi korzystającymi z danych gromadzonych w Systemie
będzie odbywać się m.in. poprzez powszechnie dostępną sieć Internet. Wymaga się, żeby cała komunikacja z systemem
prowadzona poprzez Internet była szyfrowana i chroniona za pomocą metod kryptograficznych. Wymagane jest aby
Wykonawca zaprojektował i zaimplementował odpowiednie mechanizmy zabezpieczeń i autoryzacji dostępu do
Systemu.
2.4.2. Neutralność technologiczna
Na każdym etapie budowy systemu powinny być przestrzegane zasady neutralności technologicznej tak aby docelowe
rozwiązanie było systemem otwartym, który wykorzystuje otwarte standardy, opublikowane przez uznane organizacje
standaryzacyjne. Specyfikacja wykorzystanych protokołów komunikacyjnych, interfejsów i formatów danych powinna
być publicznie dostępna.
Definicje interfejsów, protokołów i formatów danych muszą być opracowane w taki sposób, by dowolny podmiot
zewnętrzny był w stanie w prosty sposób stworzyć własne komponenty komunikujące się z systemem, z zachowaniem
wymogów bezpieczeństwa systemu.
Wszystkie zewnętrzne interfejsy systemu muszą wykorzystywać standardowe (a co najmniej otwarte) formaty danych i
protokoły, przez co rozumie się:



W obszarach stosowalności standardów wymienionych w Rozporządzeniu Rady Ministrów z dnia 11
października 2005 roku w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2005 nr
212 poz. 1766), stosowane się te standardy,
W obszarach nie objętych rozporządzeniem, dla których istnieją powszechnie akceptowane otwarte standardy
stosowane są te standardy,
W obszarach, gdzie nie ma powszechnie akceptowanych otwartych standardów:
o stosowane są komercyjne de-facto standardy (powszechnie stosowane specyfikacje) pod warunkiem,
że ich właściciele udostępniają publicznie specyfikacje niezbędne dla implementacji standardu i nie
nakładają żadnych ograniczeń, ani nie pobierają opłat za ich wykorzystanie i implementacje, lub
o stosowane są specyfikacje specyficzne (własne) spełniające warunek określony powyżej, rozszerzony
również o brak ograniczeń i opłat dotyczących modyfikacji i rozszerzania tych specyfikacji;
W żadnym wypadku nie mogą być stosowane specyfikacje które stanowią tajemnicę (nie zostały i nie mogą być podane
do publicznej wiadomości) lub których wykorzystanie oraz implementacja podlega ograniczeniom lub opłatom
związanym z prawami autorskimi lub pokrewnymi.
Aby standard można było uznać za otwarty, musi on spełniać następujące warunki:
 Standard jest zatwierdzony i jest utrzymywany przez organizację nie nastawioną na zysk (non-profit), a jego
ciągły rozwój odbywa się na zasadzie procedury podejmowania decyzji w otwartym gronie zainteresowanych
uczestników (przez porozumienie lub głosowanie itp.),
 Standard jest opublikowany, a dokument go specyfikujący jest dostępny nieodpłatnie lub za symboliczną
opłatą. Jego kopiowanie, dystrybucja i stosowanie (w całości, w części lub w zmodyfikowanej postaci)
powinno być dozwolone dla wszystkich zainteresowanych – bez opłaty albo za opłatą symboliczną,
 Prawa autorskie, w tym ewentualne zawarte w standardzie patenty zostały w nieodwołalny sposób
udostępnione jako wolne od opłat licencyjnych.
2.4.3. Przenośność
System musi cechować się przenośnością, rozumianą jako łatwość adaptacji systemu informatycznego do
zmieniających się rozwiązań sprzętowych i programowych. Podstawowymi metodami osiągnięcia przenośności są:
 Zastosowanie szeroko dostępnych i znanych języków oprogramowania i środowisk (platform) wspieranych na
wielu platformach sprzętowo-systemowych,

Brak ograniczeń licencyjnych w zakresie wykorzystywania oprogramowania wytworzonego i standardowego
na innych niż dostarczone przez Wykonawcę platformach sprzętowo-systemowych przy zachowaniu
ograniczeń na liczbę komputerów i procesorów, na których wykonywane jest oprogramowanie,

Konstrukcja modułowa systemu, umożliwiająca wymianę poszczególnych modułów na nowe moduły zgodne
pod względem interfejsów z dotychczasowymi, z zachowaniem pełnej funkcjonalności systemu,

Dokładne udokumentowanie protokołów współpracy poszczególnych modułów,

Zastosowanie otwartych standardów.
8
Załącznik 5
Wykonawca jest zobowiązany w ramach realizacji przedmiotu zamówienia do sporządzenia szczegółowej dokumentacji
wszystkich komponentów systemu w taki sposób, aby dokumentacja ta gwarantowała możliwość przeniesienia
modułów systemu na inną platformę sprzętowo-programową. W szczególności Wykonawca zobowiązany jest do
udokumentowania struktury systemu (podział na moduły), zakresu i formatu danych przechowywanych w
poszczególnych elementach składowych systemu (moduły, aplikacje standardowe, aplikacje dedykowane), oraz
interfejsów wymiany danych pomiędzy elementami składowymi systemu, oraz pomiędzy systemem a otoczeniem.
2.4.4. Elastyczność
System musi cechować się dużą elastycznością, rozumianą jako możliwość dostosowania systemu do zmieniających się
wymagań funkcjonalnych wynikających ze zmieniającego się stanu prawnego i zmieniających się warunków
praktycznych i przepisów prawnych oraz do nowych wymagań poza funkcjonalnych, szczególnie w obszarze
wydajności, bezpieczeństwa i komunikacji z systemami zewnętrznymi.
Z tego względu system musi mieć konstrukcję modułową, w której dokładnie określono sposoby komunikacji
poszczególnych modułów z pozostałymi modułami, tak że możliwa jest zmiana lub udoskonalenie jednego z modułów
bez konieczności modyfikacji pozostałych składników systemu. W szczególności elastyczność systemu powinna być
rozumiana także jako możliwość rozbudowy systemu i rozszerzania jego zakresu funkcjonalnego.
Z podobnych powodów niezbędne jest zachowanie szerokich możliwości konfiguracji systemu za pomocą plików
konfiguracyjnych i parametrów w taki sposób, aby zapewnić możliwość utrzymania technicznej i merytorycznej
żywotności systemu przez długi okres przy jednoczesnej minimalizacji liczby koniecznych modyfikacji kodów
źródłowych.
2.4.5. Wydajność
System powinien cechować się wydajnością wystarczającą dla sprawnej pracy minimum jednoczesnych 100
użytkowników wewnętrznych systemu, zlokalizowanych w Urzędzie Miejskim, korzystających z pełnej
funkcjonalności systemów, oraz 150 jednoczesnych użytkowników zewnętrznych systemu, łączących się przez sieć
Internet, przy uwzględnieniu typowych warunków pracy użytkowników.
2.4.6. Dane Przestrzenne
W ramach realizacji przedmiotu zamówienia zamawiający będzie zobowiązany dostarczyć niezbędne dane przestrzenne
atrybutowe i graficzne dla:
 Mapa zasadnicza dla miasta Zawiercie
 Plan miasta Zawiercie
 Plan miasta Łazy
 Plan miasta Poręba
 Plan miasta Ogrodzieniec
 Mapa topograficzna szczegółowa powiatu zawierciańskiego w skali 1:10 000
 Mapa kodów pocztowych powiatu zawierciańskiego
 Mapa punktów POI (Points of Interest - punktów szczególnych )
 Ortofotomapa miasta Zawiercie w skali 1:10 000
 Inne niezbędne do realizacji koncepcji Wykonawcy
Plany miast powinny zawierać dane przestrzenne i atrybutowe (szczegółowość treści odpowiada mapie w skali
1:10 000) zawierające:
 Drogi
siatka dróg wraz z nazwy dróg, rond, placów, skwerów,
informacją o kierunkowości dróg, ulic
typologię dróg - drogi są hierarchizowane pod względem ich ważności (ulica: przelotowa, główna,
przejazdowa), wyróżnione są drogi o ograniczonej przejezdności (gruntowe, pasaże, chodniki, odcinki
objęte zakazem ruchu)
o informację o specyficznych odcinkach - wyróżniono m.in. wiadukty, mosty, tunele, promy
o krajową i międzynarodową numerację dróg
o podział na kategorie administracyjne dróg - rozróżniono drogi krajowe, wojewódzkie oraz powiatowe
z gminnymi
o informację o trójwymiarowym układzie skrzyżowań - atrybut ten opisuje czy droga jest powyżej,
poniżej czy na tym samym poziomie, co odcinek z którym się krzyżuj
 Linie kolejowe wraz z typami kolei - wyróżniono koleje naziemne i kolej podziemną (o ile występuje).
o
o
o
9
Załącznik 5
 zieleń miejska i tereny przemysłowe w tym nazwy własne parków miejskich, cmentarzy, ogrodów działkowych,
lotnisk, stadionów, tereny sportowych, obiektów sportowych, wyrobisk przemysłowych, oraz typologię terenów
zielonych i przemysłowych - wyróżniono m.in.: parki, lasy,
 wody powierzchniowe w tym nazwy własne wód powierzchniowych oraz ich typologię - wyróżniono m.in.: rzeki,
jeziora, stawy, kanały, baseny, oczyszczalnie ścieków
 granice administracyjne w tym nazwy jednostek administracyjnych
Mapa Punktów szczegółowych (POI ) powinna zawierać dane przestrzenne i atrybutowe o ile zawierają się w
wymaganym regionie :
Dealer samochodów, Warsztat samochodowy, Wypożyczalnia samochodów, Bankomat, Placówka banku, Centrum
konferencyjne, Centrum targowe, Firma, Bar, Fast Food, Restauracja, Centrum handlowe, Hipermarket, Sklep,
Cmentarz katolicki/komunalny, Kościół rzymskokatolicki, Centrum kultury, Kasyno, Kino, Kręgielnia, Muzeum,
Opera, Sala koncertowa, Teatr, Zoo, Biblioteka, Szkoła wyższa, Camping, Hotel, Schronisko, Jaskinia, Jezioro/Zbiornik
wodny, Przełęcz, Szczyt, Parking naziemny, Parking podziemny, Zwolnij, Basen, Centrum sportu/rekreacji, Kort
tenisowy, Lodowisko, Pole golfowe, Ośrodek sportów wodnych, Stadion/Boisko, Tor wyścigowy, Wyciąg narciarski,
Stacja paliw, Dworzec kolejowy, Międzynarodowy port lotniczy, Terminal promowy, Przejście graniczne, Przystań
żeglarska/wioślarska, Stacja metra, Informacja turystyczna, Punkt widokowy, Administracja, Ambasada, Poczta,
Policja, Sad, Apteka, Szpital, Weterynarz, Agroturystyka/Pokoje gościnne, Pijalnia piwa/Pub, Kawiarnia/Herbaciarnia,
Protestancki ośrodek religijny, Meczet, Cerkiew prawosławna, Żydowski ośrodek religijny, Buddyjski ośrodek
religijny, Inny ośrodek religijny, Cmentarz prawosławny, Cmentarz żydowski, Cmentarz protestancki, Wulkanizacja,
Krajowy port lotniczy, Lotnisko sportowe, Park/Skwer miejski, Ogród botaniczny, Kąpielisko, Las/Bór/Puszcza, Zarząd
Parku Narodowego, Wejście do Parku Narodowego, Park Narodowy, Myjnia samochodowa, Pomnik/Rzeźba/Fontanna,
Zamek/Pałac/Dworek, Inny obiekt historyczny, Most zabytkowy, Ratusz/Kamienica/Dom, Klif, Rynek/Część miasta,
Miasto/Wieś, Fort/Twierdza, Przeprawa promowa, Punkt poboru opłat drogowych, Dworzec autobusowy, Biurowiec,
Market budowlany, Rezerwat przyrody, Planetarium/Obserwatorium, Park Rozrywki, Stadnina koni, Kolejka linowa,
Port, Nurkowanie, Klub/Dyskoteka, Przychodnia lekarska, Sanatorium, Straż Pożarna, Kwiaciarnia, Księgarnia,
Klasztor/Opactwo, (o ile występują w zadanym obszarze).
Wszystkie dane przestrzenne powinny posiadać wykupioną licencję lub prawa do nieograniczonej publikacji w
Internecie na okres min 5 lat od podpisania protokołu odbioru.
2.5. Wymagania dotyczące sprzętu
Wymagania dotyczące liczby sztuk oraz parametrów minimalnych dostarczanego sprzętu zawarte zostały w Załączniku
6 do SIWZ.
2.6. Inne wymagania
Świadczone przez Wykonawcę usługi musza spełniać standardy systemu jakości określonego normami PN-EN ISO
9001:2001, PN-EN ISO 14001:2005, PN-EN ISO 180012004, PN-EN ISO 27001:2007 lub równoważnymi.
2.6.1. Proces wytwórczy oprogramowania
Zamawiający wymaga, aby Wykonawca w wytwarzaniu oprogramowania stosował udokumentowany proces
wytwórczy oprogramowania zapewniający:
1. Precyzyjne określenie ról (kto), zadań (jak), artefaktów (co) i działań (kiedy)
2. Identyfikację, dokumentowanie i uzgadnianie wymagań w ścisłej współpracy z Zamawiającym
3. Skuteczne mechanizmy gwarantujące spełnienie tych wymagań poprzez ścisłe kierowanie się nimi w trakcie
projektowania, implementacji i testowania
4. Identyfikację zagrożeń o charakterze biznesowym i technicznym oraz zarządzanie nimi
5. Mechanizmy zarządzania projektem wytwórczym, a także zarządzania zmianami i konfiguracją
6. Systemowe podejście do testowania oprogramowania gwarantujące Zamawiającemu obiektywną walidację
oprogramowania pod kątem zgodności z uzgodnionymi wymaganiami
2.6.2. Testy systemu
Wykonawca przedstawi w projekcie technicznym koncepcję realizacji testów funkcjonalnych, testów zabezpieczeń,
testów wydajnościowych, testów przeciążeniowych, testów niezawodności, testów użyteczności i innych, które uważa
za właściwe w kontekście realizowanego projektu.
10
Załącznik 5
2.6.2.1. Plan testów
Wykonawca opracuje i przedstawi w projekcie technicznym Plan Testów zawierający:
Listę elementów podlegających testowaniu.
Kategorie wykonywanych testów odnoszące się do zidentyfikowanych elementów podlegających testowaniu. Plan
testów powinien uwzględniać co najmniej następujące kategorie testów:
1) Testy funkcjonalne
 Testy przeprowadzone zostaną dla wszystkich wymagań funkcjonalnych określonych w dokumencie analizy
wymagań.
 Testy przeprowadzone zostaną dla podzbioru reprezentującego pełny zakres dopuszczalnych wartości
wejściowych i wyjściowych oraz stanów.
2) Testy zabezpieczeń
 Testy wykażą poprawność działania wszystkich wymagań bezpieczeństwa
 Testy wykażą, że system jest odporny na podstawowe ataki, których listę Wykonawca powinien wykonać
metodą ekspercką. Lista ta będzie zawierać co najmniej ataki typu DoS (Denial of Service), DDoS (Distributed
Denial of Service), DRDoS (Distribiuted Reflecion Denial of Service), SQL Injection, Code Injection, Buffer
Overflow oraz powinna określać, czy i w jakim stopniu poszczególne części systemu narażone są na ataki
danego typu.
 Testy potwierdzą zachowanie integralności systemu oraz jego zgodną z założeniami reakcję przy próbie
wysyłania uszkodzonych komunikatów lub komunikatów z danymi o niedopuszczalnej zawartości.
3) Testy wydajnościowe
 Wykonane zostaną charakterystyki czasów odpowiedzi dla pojedynczego użytkownika w zależności od mocy
(i liczby) procesorów, przepustowości łącza, wielkości komunikatu. Testy powinny wykazać, że wydajność
systemu spełnia wymagania określone przez Zamawiającego.
 Wykonane zostaną charakterystyki czasów odpowiedzi w zależności od ilości użytkowników w zakresie od 1
do co najmniej 150% maksymalnej ich liczby przy zadanej mocy procesorów, przepustowości łącza i
wielkości komunikatu. Testy wykażą osiągnięcie żądanej wydajności systemu przy obciążeniu maksymalną
liczbą użytkowników, przy zadanej mocy procesorów, wielkości komunikatu i przepustowości łącza.
4) Testy niezawodności
 Testy potwierdzą poprawność funkcjonalną działania systemu obciążonego pełną liczbą użytkowników przy
zadanej mocy procesorów, wielkości komunikatów i przepustowości łącza.
 Testy potwierdzą zachowanie integralności systemu oraz jego zgodną z założeniami reakcję przy symulacji
awarii łącza sieciowego.
5) Testy przeciążeniowe
 Testy potwierdzą poprawną i mieszczącą się w założonych ramach czasowych reakcję systemu przy próbie
obciążenia ilością użytkowników co najmniej 3-krotnie przekraczającą zakładaną maksymalną ilość
użytkowników.
6) Testy użyteczności
 Komponenty systemu, w których występuje interakcja z użytkownikiem przetestowane zostaną na zgodność z
wymaganiami użyteczności określonymi w SIWZ.
7) Inne testy, wynikające z atrybutów jakościowych systemu.
2.6.2.2. Specyfikacja testów
Wykonawca opracuje specyfikację testów zawierającą przypadki testowe odnoszące się do wymagań określonych w
wymaganiach funkcjonalnych i pozafunkcjonalnych, z zachowaniem planowanych kategorii testów oraz z
uwzględnieniem zakładanych wartości wskaźników jakości testów. Parametry testów zostaną uzgodnione z
Zamawiającym na etapie analizy. Każdy przypadek testowy zawierać będzie wyszczególnienie nazwy i wersji elementu
podlegającego testowaniu, unikalny identyfikator przypadku testowego, priorytet zgodny z harmonogramem testów,
ważność, pełną informację o sposobie wykonania testu i danych testowych oraz jednoznacznie określać oczekiwany
wynik testu.
Każda rozbieżność pomiędzy oczekiwanym wynikiem testu, a wynikiem otrzymanym podczas wykonywania testów,
stanowi podstawę do zgłoszenia niezgodności, a w przypadku przypadków testowych o ważności określonej jako
krytyczna, podstawę do wstrzymania testów do czasu wprowadzenia odpowiedniej poprawki do systemu.
Wykonawca dostarczy analizę pokrycia wymagań przez wyspecyfikowane przypadki testowe.
Specyfikacja testów wejdzie w skład projektu technicznego i podlega uzgodnieniu i akceptacji przez Zamawiającego.
Zamawiający ma prawo do dodania do specyfikacji dodatkowych testów, których celem jest potwierdzenie spełnienia
przez system wymagań funkcjonalnych i pozafunkcjonalnych.
11
Załącznik 5
2.6.2.3. Uruchomienie testów i dokumentacja uruchomienia testów
Wykonawca przed dokonaniem ostatecznego odbioru systemu zainstaluje i uruchomi oprogramowanie wchodzące w
skład systemu i przeprowadzi testy w uzgodnieniu z Zamawiającym i pod jego nadzorem.
Wykonawca przygotuje i przekaże Zamawiającemu dokumentację wykonania testów.
Testy zapewnią symulację wszystkich systemów zewnętrznych względem systemu testowanego.
Wykonawca zapewni przeprowadzenie testów, w tym zapewni oprogramowanie i infrastrukturę służącą do
zrealizowania wszystkich testów opisanych w specyfikacji testów.
Opracowane testy wykonane zostaną na dedykowanym zbiorze danych testowych przygotowanych przez Wykonawcę
na podstawie specyfikacji testów.
Wykonawca przygotuje oprogramowanie umożliwiające zautomatyzowane ładowanie i przywracanie zbioru inicjalnych
danych testowych, niezbędnych do rozpoczęcia testów oraz procedurę przywracania stanu środowiska testowanego
systemu do stanu początkowego.
2.6.2.4. Wykonanie i raportowanie testów
W uzgodnionym z Zamawiającym terminie przeprowadzane zostaną testy akceptacyjne, prowadzone na podstawie
przypadków testowych i danych testowych przygotowanych przez Wykonawcę w obecności uprawnionych
przedstawicieli Zamawiającego.
W przypadku wystąpienia błędu krytycznego, który nie pozwala na kontynuację testów Zamawiający i Wykonawca
mogą uzgodnić przerwanie testów, co skutkuje sporządzeniem raportu z testów stwierdzającego ten fakt; przerwanie
testów z powodu wystąpienia błędu krytycznego nie wpływa na termin zakończenia testów.
Testy kończą się podpisaniem przez przedstawiciela Zamawiającego i Wykonawcy raportu wyników testów
przedstawiającego zakres przeprowadzonych testów, rzeczywiście osiągnięte wskaźniki jakości testów oraz informacje
o wykrytych błędach wraz z ich kategoryzacją.
Poprawnie przeprowadzone testy potwierdzające zgodność dostarczonego systemu z wymaganiami SIWZ, są
warunkiem dokonania odbioru końcowego przez Zamawiającego.
2.6.3. Dokumentacja
1.
W ramach realizacji zamówienia Wykonawca jest zobowiązany do wykonania dokumentacji dostarczonych
oraz opracowanych przez siebie i wdrożonych systemów informatycznych Wymaga się, aby cała
dokumentacja była napisana w języku polskim.
2.
W zakresie produktów innych producentów (np. oprogramowania firm trzecich), dostarczonych przez
Wykonawcę w ramach niniejszego zamówienia, Zamawiający dopuszcza dostarczenie oryginalnej, kompletnej
dokumentacji producenta (np.: instrukcje techniczne, podręczniki użytkownika, inne) z zastrzeżeniem, że ma
ona być w języku polskim.
3.
W zakresie produktów opracowanych samodzielnie i wdrożonych przez Wykonawcę na potrzeby realizacji
niniejszego zamówienia wymagane jest opracowanie i przekazanie Zamawiającemu dokumentacji zawierającej
co najmniej:
a. szczegółowy Podręcznik Administratora zawierający:
i. opis wszystkich procedur oraz funkcji konfiguracyjnych możliwe do wykonania przez
administratora systemu;
ii. opis konfiguracyjny wszystkich modułów systemowych oraz usług sieciowy;
iii. procedury tworzenia użytkowników w systemie, bazach danych i nadawania im
odpowiednich uprawnień,
iv. procedury archiwizacji danych oraz tworzenia kopii zabezpieczających całego wdrożonego
systemu
12
Załącznik 5
v. procedury odtwarzania systemu po wystąpieniu awarii (np.: zakładania struktury centralnej
bazy danych, instalacji i konfiguracji wdrożonego oprogramowania, ładowania danych,
inne),
vi. dokumentację dotycząca diagnostyki i rozwiązywania problemów,
vii. określenie innych procedur dotyczących administracji systemem;
viii. instrukcje obsługi do każdego z dostarczonych elementów sprzętowych
szczegółowy Podręcznik Użytkownika opisujący wszystkie procedury oraz funkcje możliwe do
wykonania przez użytkownika systemu;
c. szczegółową listę użytych haseł do wszystkich elementów wchodzących w skład systemu, które
podlegają zabezpieczeniu przed nieautoryzowanym dostępem, w tym bazy danych oraz wszystkie
moduły administracyjne;
d. szczegółowy opis wykorzystanych zabezpieczeń sprzętowych/programowych mających na celu
zabezpieczenie systemu przed włamaniem lub innymi atakami.
e. szczegółową politykę bezpieczeństwa opisującą w spójny i precyzyjny sposób reguły i procedury,
według których wytworzony system będzie zarządzał oraz udostępniał zasoby obejmującą wskazanie
możliwych rodzajów naruszenia bezpieczeństwa, scenariusze postępowania i działania w takich
sytuacjach;
f. opis sposobu integracji aplikacji z istniejącymi elementami infrastruktury technicznej;
g. inne procedury i czynności niezbędne z punktu widzenia Wykonawcy potrzebne do poprawnej
eksploatacji całego wdrożonego systemu.
Opracowana przez Wykonawcę dokumentacja ma zostać przekazana w formie papierowej w 5 egzemplarzach
dla każdego systemu oraz w formie elektronicznej na nośnikach CD-ROM w formacie PDF i DOC (z prawami
do drukowania treści dokumentów) w 4 egzemplarzach. Kompletna dokumentacja dostarczona ma zostać
przez Zamawiającemu najpóźniej w dniu odbioru całego zamówienia.
Szczegóły w zakresie dokumentacji systemu zostaną ustalone z Wykonawcą na etapie zatwierdzania Projektu
technicznego wdrożenia.
b.
4.
5.
Dokumentacja dostarczonego sprzętu powinna zawierać zestawienie wszystkich elementów sprzętowych (z podaniem
co najmniej typu urządzenia, nazwy, numeru seryjnego).
2.6.4. Warunki gwarancji
Zakres gwarancji oraz warunki jej świadczenia określa wzór umowy, stanowiący załącznik nr 7 do SIWZ.
2.6.5. Równoważność rozwiązań
Wszędzie tam, gdzie przedmiot zamówienia jest opisany poprzez wskazanie znaków towarowych, patentów lub
pochodzenia, Zamawiający dopuszcza zastosowanie przez Wykonawcę rozwiązań równoważnych w stosunku do
opisanych w niniejszym załączniku, oraz w Załączniku 6 do SIWZ, pod warunkiem, że będą one posiadały, co najmniej
takie same lub lepsze parametry techniczne i funkcjonalne, i nie obniżą określonych w niniejszym załączniku, oraz w
Załączniku 6 do SIWZ standardów.
W przypadku, gdy Wykonawca zaproponuje urządzenia, instalacje, materiały i inne elementy równoważne,
zobowiązany jest wykonać i załączyć do oferty zestawienie wszystkich zaproponowanych urządzeń, instalacji,
materiałów oraz innych elementów równoważnych i wykazać ich równoważność w stosunku do urządzeń, instalacji,
materiałów i innych elementów opisanych w niniejszym załączniku, oraz w Załączniku 6 do SIWZ, ze wskazaniem
nazwy, strony i pozycji, których dotyczy, oraz podaniem parametrów oferowanego równoważnego rozwiązania.
Wszystkie zaproponowane przez Wykonawcę równoważne urządzenia, instalacje, materiały lub inne elementy muszą:
o posiadać parametry techniczne i funkcjonalne nie gorsze od określonych w niniejszym załączniku,
oraz w Załączniku 6 do SIWZ,
o zapewniać pełną kompatybilność sprzętową i programową z rozwiązaniami określonymi w
niniejszym załączniku, oraz w Załączniku 6 do SIWZ,
o gwarantować sposób administrowania i zarządzania systemami, wynikający wprost z rozwiązania
projektowego zawartego w niniejszym załączniku, oraz w Załączniku 6 do SIWZ,
o posiadać stosowne dopuszczenia i atesty.
13
Załącznik 5
2.7. Szczegółowy opis zadań
2.7.1. Ramowy harmonogram prac
Zamawiający przewiduję wykonanie Projektu w następujących etapach:
1.
2.
3.
4.
Etap 1 - dostarczyć i zainstalować urządzenia zgodnie z SIWZ, w czasie do 6 tygodni
Etap 2 - przeprowadzić analizę wymagań, sporządzić dokumentację analizy oraz projekt techniczny modułów
dedykowanych oraz struktur danych i przedłożyć do zatwierdzenia przez Zamawiającego, w czasie do 4
tygodni
Etap 3 -wykonać "pod klucz", na podstawie zatwierdzonego dokumentu analizy i dokumentu projektu
technicznego dedykowane moduły Systemu i struktury danych, w czasie do 20 tygodni
Etap 4 - dostarczyć dokumentację Systemu zgodnie z SIWZ, w czasie do 2 tygodni
Wykonawca jest zobowiązany sporządzić harmonogramu z uwzględnieniem zaangażowania sił i środków.
Harmonogram powinien uwzględniać powyższe etapy projektu i przedstawiać alokację sił i środków definiując liczbę
niezbędnych osób liczbę osobodni zaangażowanych na każdym etapie realizacji projektu, oraz kalkulacje kosztową prac
i dostarczanego sprzętu.
Zamawiający zastrzega sobie możliwość wnoszenia uwag do przedłożonego mu do zatwierdzenia dokumentu analizy i
projektu technicznego. Kontynuacja projektu przez Wykonawcę będzie możliwa dopiero po pozytywnym zatwierdzeniu
dokumentu analizy i projektu technicznego przez Zamawiającego.
2.7.1.1. Etap 1
W ramach tego etapu Wykonawca zobowiązany jest do dostarczenia i zainstalowania zaoferowanego sprzętu w
lokalizacjach wskazanych w rozdziale 3.2 "Miejsca dostaw" niniejszego załącznika, oraz zgodnie z zapisami załącznika
nr 6 do SIWZ.
2.7.1.2. Etap 2
W ramach tego etapu Wykonawca przeprowadzi analizę wymagań w odniesieniu do proponowanego przez Wykonawcę
rozwiązania. Analiza zostanie przeprowadzona na podstawie oferty Wykonawcy, zapisów SIWZ (w szczególności
rozdziałów 2.2, 2.3 i 2.4 niniejszego załącznika), a także na podstawie wymagań zdefiniowanych w oparciu o ustalenia
z Zamawiającym. W trakcie etapu Wykonawca zobowiązany jest do dokonania analizy wymagań poprzez
zorganizowanie warsztatów analitycznych z udziałem pracowników Zamawiającego. Zamawiający zastrzega, że SIWZ
nie obejmuje wyczerpującego katalogu wymagań niezbędnych do realizacji przedmiotu zamówienia. W trakcie analizy
wymagań Zamawiający może zgłaszać wymagania, które zostaną przez Wykonawcę poddane analizie w kontekście
SIWZ. Wykonawca uwzględni te uwarunkowania przy planowaniu i realizacji przedmiotu zamówienia, kierując się
swoją wiedzą i doświadczeniem, oraz dążąc do zachowania najwyższej staranności wymaganej od podmiotu
profesjonalnego.
Dokument analizy wymagań zostanie przedstawiony Zamawiającemu do zatwierdzenia. Zamawiający zatwierdzi lub
zgłosi uwagi do przedstawionego dokumentu w ciągu 5 dni roboczych. Wykonawca uwzględni przedstawione uwagi w
ciągu 2 dni roboczych i ponownie przedstawi Zamawiającemu dokument do akceptacji.
Na podstawie zatwierdzonej dokumentacji analizy Wykonawca sporządzi projekt techniczny Systemu zawierający
projekt techniczny modułów dedykowanych, projekt interfejsu użytkownika, projekt struktur danych, oraz specyfikację
testów. Dokument projektu technicznego zostanie przedstawiony Zamawiającemu do zatwierdzenia. Zamawiający
zatwierdzi lub zgłosi uwagi do przedstawionego dokumentu w ciągu 5 dni roboczych. Wykonawca uwzględni
przedstawione uwagi w ciągu 2 dni roboczych i ponownie przedstawi Zamawiającemu dokument do akceptacji.
2.7.1.3. Etap 3
Na podstawie zatwierdzonych przez Zamawiającego dokumentów analizy oraz projektu technicznego, Wykonawca
wykona i wdroży dedykowane moduły Systemu i zaimplementuje struktury danych w bazach danych Systemu.
Wykonawca w ramach tego etapu przeprowadzi testy opisane w rozdziale 2.6.2 niniejszego załącznika, zgodnie ze
specyfikacją testów zatwierdzoną przez Zamawiającego w ramach dokumentacji projektu technicznego.
14
Załącznik 5
Poprawne zrealizowanie testów jest warunkiem przedstawienia Systemu do odbioru. Zgodność przedstawionego do
odbioru Systemu z wymaganiami i projektem technicznym oraz dokumentacją analizy Zamawiający potwierdzi
protokołem odbioru etapu.
2.7.1.4. Etap 4
W ramach tego etapu Wykonawca dostarczy dokumentację zgodną z zapisami rozdziału "2.6.3. Dokumentacja".
2.7.1.5. Odbiór całościowy Systemu
Na podstawie sporządzonych protokołów odbioru etapów 1-5 Zamawiający dokona odbioru całościowego przedmiotu
zamówienia co potwierdzi protokołem odbioru końcowego.
Od momentu dokonania odbioru końcowego Wykonawca jest zobowiązany zapewnić gwarancję jakości w odniesieniu
do całości przedmiotu zamówienia zgodnie z zapisami rozdziału " 2.6.5. Warunki gwarancji".
3. INFORMACJE ZWIĄZANE Z REALIZACJĄ PRZEDMIOTU ZAMÓWIENIA
3.1. Sposób organizacji projektu
Projekt będzie realizowany przez Urząd Miejskim w Zawierciu zgodnie z założeniami metodyki PRINCE2
Realizację projektu będzie nadzorował wyznaczony przez Zamawiającego kierownik projektu jako osoba
reprezentująca Zamawiającego i odpowiedzialna za jego działalność. Nadzór będzie prowadzony w oparciu o raporty
postępu oraz spotkania kontrolne.
Strategiczne decyzje dotyczące Zarządzania projektem będzie podejmował Komitet Sterujący, na czele którego stoi
Przewodniczący. Komitet Sterujący będzie składał się z pozostałych członków Zamawiającego oraz zewnętrznych
ekspertów z poszczególnych dziedzin istotnych z punktu widzenia realizacji projektu (od 2 do 4 osób). Komitet
Sterujący będzie działał na bieżąco, a decyzje będą podejmowane w oparciu o sprawozdawczość projektu. W skład
Komitetu Sterującego wchodzić będzie także Główny Użytkownik - osoba reprezentująca potrzeby i wymagania
zakładów, które będą korzystały z budowanej w ramach projektu infrastruktury. W skład Komitetu Sterującego wejdzie
także osoba występująca jako Główny Dostawca, będzie to reprezentant wykonawcy - firmy, która zostanie wyłoniona
w drodze postępowania przetargowego i będzie odpowiedzialna z dostarczenie i wdrożenie infrastruktury
teleinformatycznej będącej przedmiotem projektu.
Osobą odpowiedzialną za realizację projektu będzie Kierownik Projektu. Do obowiązków Kierownika Projektu będzie
należało ustalanie zakresu prac dla poszczególnych zespołów zadaniowych, współpraca z Komitetem Sterującym,
bieżące zarządzanie realizacją i rozliczaniem projektu na poziomie operacyjnym, a także odbiór poszczególnych etapów
prac. Kierownik Projektu będzie miał do pomocy Biuro Projektu składające się z oddelegowanych na całość lub cześć
etatu pracowników z następujących dziedzin:
 Księgowość,
 prace biurowe i sekretarskie.
Zespół projektowy będzie składał się z wyodrębnionych zespołów zadaniowych odpowiedzialnych za poszczególne
działania w ramach projektu. Liderzy poszczególnych zespołów zadaniowych będą odpowiadali przed kierownikiem za
zakres powierzonych im prac.
3.2. Miejsca dostaw sprzętu
Miejsce dostawy elementów infrastruktury systemu opisanych w Załączniku 6 do SIWZ: Urząd Miejski w Zawierciu,
ul. Leśna 2.
15

szczegółowy opis przedmiotu zamówienia w postępowaniu o

Transkrypt

Podobne dokumenty

Załącznik nr 4 - inf

Załącznik nr 10 do SIWZ Oświadczenie o części

Wykaz części zamówienia, których realizację Wykonawca zamierza

2 4 0 T ł uszcz Opis przedmiotu

6. Informacje z otwarcia ofert

WYKONAWCA Nazwa firmy: . REGON . NIP . adres firmy: . tel/fax

Pytania i odpowiedzi.

ZAŁĄCZNIK NR 4 DO SIWZ- wykaz podwykonawców