Załącznik nr 4

Centralna Ewidencja Pojazdów i Kierowców - CEPiK

Opis przedmiotu zamówienia na wykonanie, wdrożenie oraz na obsługę eksploatacyjną i rozwój

systemu informatycznego

wraz z robotami budowlanymi (adaptacyjnymi) pomieszczeń przeznaczonych na ten cel

Warszawa, 24 lipca 2003 r.

Spis treści

1. Wstęp

1. Wstęp

1. Cel i znaczenie dokumentu

Dokument zawiera opis przedmiotu zamówienia na budowę, wdrożenie i obsługę eksploatacyjną systemu Centralnej Ewidencji Pojazdów i Kierowców (CEPiK). Opis jest załącznikiem do Specyfikacji Istotnych Warunków Zamówienia na wykonanie i wdrożenie oraz obsługę eksploatacyjną i rozwój systemu CEPiK.

2. Odbiorcy dokumentu

Odbiorcami dokumentu są podmioty uczestniczące w postępowaniu o udzielenie przedmiotowego zamówienia publicznego.

3. Struktura dokumentu i przyjęte konwencje opisu

Dokument podzielony został na następujące rozdziały:

1. Wstęp— rozdział zawierający elementarne informacje o przedmiocie zamówienia oraz informacje o strukturze dokumentu, znaczeniu pewnych pojęć, itp.

2. Streszczenie— przedstawiający najważniejsze elementy koncepcji systemu oraz zakresu prac objętych zamówieniem

3. Cel systemu— rozdział zawierający sformułowanie celu systemu

4. Obecny system ewidencji pojazdów i kierowców— rozdział zawierający informacje o obecnych regulacjach i sytuacji w obszarze działania systemu.

5. Ogólna specyfikacja systemu CEPiK— rozdział określający zakres systemu CEPiK: wskazujący wspierane przez system procesy i zakres ich wsparcia, zakres informacyjny systemu, formułujący wymagania pozafunkcjonalne oraz pokazujący koncepcję techniczną, według której ma być budowany system CEPiK.

6. Migracja danych— rozdział opisujący zakres prac dotyczących migracji danych ze źródeł obecnie prowadzących ewidencje informacji dotyczących pojazdów i kierowców.

7. Wdrożenie rozdział opisujący zakres dostaw i usług związanych z wdrożeniem systemu CEPiK.

8. Przebieg prac i organizacja przedsięwzięcia— rozdział opisujący zakładany przez Zamawiającego przebieg i organizację prac oraz produkty projektowe, które w ich wyniku zostaną wytworzone.

9. Usługi utrzymania systemu— rozdział zawierający wymagania dotyczące usług utrzymania systemu po jego wdrożeniu.

Wymagania Zamawiającego, dotyczące szczególnych wymagań zostały zebrane w wydzielonych opracowaniach stanowiących załączniki do opracowania:

- Załącznik nr 4.1 - [Bezpieczeństwo]

- Załącznik nr 4.2. -[Wymagania techniczne]

Załącznik nr 4.3. -[Wymagania dot. Tymczasowego Centrum Podstawowego].

2. Streszczenie

Przedmiotem zamówienia jest realizacja następujących prac związanych z komputerowym systemem obsługi Centralnej Ewidencji Pojazdów i Kierowców (zwanym dalej systemem CEPiK):

1. uruchomienie Centralnej Ewidencji Pojazdów (CEP) - tzn. zmigrowanie danych o pojazdach z WEP - i przygotowanie do udostępnienia danych uprawnionym podmiotom - 01.01.2004 r.

2. rozpoczęcie eksploatacji CEP - 01.01.2004 r. [zakres eksploatacji będzie wzrastał wraz z postępem wdrożenia kolejnych elementów systemu],

3. przygotowanie do wdrożenia pełnej funkcjonalności do obsługi starostw - za wyjątkiem sterowania przepływem pracy - w zakresie CEP - 31.03.2004 r

4. pilotażowe wdrożenie CEP w wybranym starostwie - 31.03.2004 r.

5. przedstawienie koncepcji migracji danych z systemu KIEROWCA oraz gromadzenia danych o kierowcach - 31.05.2004 r.

6. wdrożenie CEP w starostwach - łącznie ze sterowaniem przepływem pracy - 31.12.2004 r. [do eksploatacji przekazywany jest system wdrożony we wszystkich starostwach danego województwa],

7. uruchomienie Centralnej Ewidencji Kierowców (CEK) - z migracją danych z systemu KIEROWCA - 31.07.2004 r.

8. uruchomienie usługi infolinii dla obsługi obywateli - 01.07.2004 r.

9. wdrożenie Centralnej Ewidencji Pojazdów Specjalnych (CEP-S) - 01.01.2005 r.

10. pilotowe uruchomienie systemu analityczno-raportowego - 01.07.2005 r.

11. zakończenie procesu weryfikacji danych o pojazdach - 31.12.2005 r.

12. produkcyjne uruchomienie systemu analityczno-raportowego - 31.12.2005 r.

13. wdrożenie pozostałej funkcjonalności systemu - 31.12.2005 r.

14. eksploatacja i rozwój systemu - 01.01.2004 - 31.12.2009 r.

Za zakres minimalny rozumie się zadania 1 - 4.

Cel przedsięwzięcia

Przedsięwzięcie budowy systemu CEPiK jest elementem narodowego programu zwalczania przestępczości. Celem przedsięwzięcia jest ochrona interesów Państwa i obywateli w zakresie bezpieczeństwa pojazdów i ich właścicieli oraz bezpieczeństwa ruchu drogowego. Cel ten w odniesieniu do systemu CEPiK przekłada się na szereg celów szczegółowych wyliczonych w rozdziale 3. Cele te związane są przede wszystkim z poprawą szeroko rozumianej jakości procesów obsługi ewidencji pojazdów i kierowców oraz szerszym wykorzystaniem pozyskiwanych w tych procesach informacji.

Obecnie funkcjonujące rozwiązania (zwłaszcza w obszarze ewidencji pojazdów) stanowią istotną przeszkodę w realizacji tak postawionych celów. Obecnie ewidencja jest rozproszona i nie zintegrowana. Brak wiarygodnych źródeł danych skutecznie utrudnia pracę organom ścigania i wymiaru sprawiedliwości oraz sprzyja działalności przestępczej i korupcji. Bliższy opis obecnie funkcjonujących rozwiązań znajduje się w rozdziale 4.

System CEPiK

System CEPiK, poprzez swoją konstrukcję „centralną” (likwidacja ewidencji lokalnych) realizuje swoje cele poprzez:

— automatyzację i sterowanie przebiegiem procesów produkujących dane do ewidencji pojazdów,

— weryfikacje danych wprowadzanych do systemu (m. in. z uwzględnieniem źródeł referencyjnych, np. PESEL, REGON, itp.),

— udostępnianie wysokiej jakości danych instytucjom uprawnionym do dostępu do nich.

Najważniejsze elementy zakresu systemu CEPiK w sposób schematyczny zaprezentowano na załączonym diagramie. Całość zakresu podzielona jest na zakres minimalny, który ma być zbudowany i wdrożony do 31.03.2004 r., oraz zakres docelowy, który będzie przedmiotem prac konstrukcyjnych i wdrożeniowych w latach 2004-2005.

Strategiczne kierunki rozwoju systemu CEPiK związane są z integracją europejską oraz z rozwojem inicjatyw typu e-government. Konieczne jest zatem wykorzystanie w konstrukcji systemu koncepcji technicznej czyniącej system łatwym w rozbudowie o mechanizmy integracji z instytucjami europejskimi czy też kanały G2B/G2C. Zakładana techniczna koncepcja systemu ogólnie przedstawiona jest na załączonym rysunku.

Więcej informacji nt. zakresu systemu oraz jego koncepcji technicznej znajdują się w rozdziale 5 dokumentu.

Diagram Zakres systemu CEPiK

Diagram Koncepcja techniczna systemu CEPiK (uwzględniająca strategiczne kierunki rozwoju).

Migracja danych

Zakres prac obejmuje również wykonanie migracji danych objętych zakresem informacyjnym systemu z obecnie dostępnych źródeł. Dane do migracji dostarczane będą przez Zamawiającego w zbiorach o ustalonym, we wstępnej fazie projektu, formacie. Wszystkie dane spełniające elementarne kryteria jakości trafią do tzw. bazy migracyjnej tj. specjalnego obszaru danych w systemie CEPiK przechowującego wszystkie dane z migracji bez względu na ich jakość. W dalszej kolejności te dane, których jakość na to pozwoli przeniesione zostaną do ewidencji centralnej. Po uruchomieniu system CEPiK wykorzystuje oba zasoby danych.

Pozyskanie danych o pojazdach stanowi istotny problem, ze względu na nałożenie się dwóch czynników:

— dla skutecznego działania systemu potrzebne jest dokonanie migracji znakomitej większości danych,

— w obecnym stanie ewidencja składa się z wielu rozproszonych i niespójnych wewnętrznie i pomiędzy sobą źródeł danych.

Zamawiający będzie sukcesywnie dostarczał dane migracyjne począwszy od początku projektu (niezwłocznie po ustaleniu szczegółowych zasad migracji danych), aż do terminu uzgodnionego w fazie planowania migracji i poprzedzającego termin produkcyjnego startu systemu o czas potrzebny na przetworzenie tych danych oraz umieszczenie ich w bazach danych systemu przed jego produkcyjnym rozruchem. Zamawiający oczekuje od Dostawcy przetwarzania dostarczanych danych i raportów dotyczących jakości danych ze szczegółowymi wskazaniami sytuacji wymagających wyjaśnienia.

Migracja danych o kierowcach nie stanowi tak poważnego problemu, ze względu na mniejsze znaczenie tych danych dla celu systemu, istnienie ogólnopolskiego systemu gromadzącego te dane (system „Kierowca”) oraz trwający proces wymiany wszystkich praw jazdy, który spowoduje, że do końca 2004 roku wszystkie dane nieznajdujące się obecnie w systemie „Kierowca” znajdą się w CEPiK skutkiem normalnej realizacji procedur wymiany dokumentów przez starostwa. Więcej szczegółów na temat zakresu prac związanych z migracją danych znajduje się w rozdziale 6. „Migracja danych”.

Wdrożenie

Zadaniem Dostawcy jest wdrożenie systemu CEPiK w zakresie minimalnym i wdrożenie w zakresie docelowym. Zakres wdrożenia każdego zakresu obejmuje następujące elementy:

— dostawy wszystkich koniecznych elementów infrastruktury (z wyłączeniem tych, których dostarczenie zapewnia Zamawiający),

— instalacja i uruchomienie elementów infrastruktury,

— wsparcie wdrożeniowe,

— szkolenia użytkowników.

W 2009 roku Dostawca przeprowadzi również szkolenia personelu Zamawiającego, który przejmie od niego utrzymanie i rozwój systemu. Bardziej szczegółowe informacje dotyczące wdrożenia znajdują się w rozdziale 7

Przebieg prac i organizacja przedsięwzięcia

Przedsięwzięcie prowadzone jest w warunkach istnienia silnych ograniczeń czasowych nałożonych na Zamawiającego aktami prawnymi wysokiej rangi. Ze względu na to przedsięwzięcie prowadzone będzie w szczególny sposób, którego najistotniejsze cechy to:

— wytwarzanie systemu małymi przyrostami kończącymi się powstaniem wersji systemu o ograniczonym zakresie, w pełni sprawnej, przetestowanej, zaakceptowanej i gotowej do wdrożenia,

— redukcja procesu zatwierdzania ustaleń poprzez konstrukcje mieszanych zespołów zadaniowych złożonych z osób o odpowiednich kompetencjach, których uzgodnienia nie wymagają niczyjej więcej akceptacji.

Tak zorganizowane przedsięwzięcie wymagać będzie ścisłej współpracy oraz dużej elastyczności Zamawiającego i Dostawcy, jak również znaczącego zaangażowania w prace projektowe przedstawicieli Zamawiającego i innych zainteresowanych instytucji publicznych.

Więcej informacji o planowanym sposobie prowadzenia przedsięwzięcia znajduje się w rozdziale 8. „Przebieg prac i organizacja przedsięwzięcia”.

Utrzymanie systemu

Po uruchomieniu CEP z danych zmigrowanych z WEP, tzn. od 01.01.2004 r., Dostawca przystąpi już do utrzymania systemu. Następne przejmowanie do eksploatacji przez Dostawcę lub podmiot wskazany przez Dostawcę będzie miało miejsce po wdrożeniu kolejnych zakresów funkcjonalnych. Zakres tych usług obejmuje przede wszystkim zapewnienie niezakłóconego funkcjonowania procesów wspieranych przez system. Dodatkowo podmiot utrzymujący system będzie świadczył na rzecz Zamawiającego usługi związane z niestandardowym przetwarzaniem danych zgromadzonych w systemie. Zakres usług utrzymania systemu i wymagane poziomy ich realizacji dokładniej opisane są w rozdziale 9. „Usługi utrzymania systemu”.

3. Cel systemu

Zamawiający określa następujący cel generalny związany z wdrożeniem systemu CEPiK, którym jest

ochrona interesów Państwa i jego obywateli w zakresie bezpieczeństwa pojazdów i ich właścicieli oraz bezpieczeństwa ruchu drogowego.

Cel ten przekłada się na następujące cele szczegółowe, które powinny być zrealizowane w ramach przedsięwzięcia oraz związanymi z nim działaniami organizacyjno-prawnymi innych podmiotów:

— poprawa sprawności i bezpieczeństwa procesów rejestracji pojazdów i kierowców oraz dokumentów z nimi związanych,

— zwiększenie efektywności pracy Policji poprzez odpowiednie do jej potrzeb udostępnianie zasobów informacyjnych systemu CEPiK,

— znaczne ograniczenie negatywnych zjawisk takich jak kradzieże samochodów, nielegalny obrót częściami samochodowymi, kradzieże dokumentów, oszustwa celne, oszustwa podatkowe, oszustwa ubezpieczeniowe itp.,

— poprawa bezpieczeństwa ruchu drogowego poprzez wsparcie monitorowania realizacji obowiązku kontroli poziomu technicznego pojazdów i formalnych uprawnień do kierowania pojazdami,

— podniesienie poziomu bezpieczeństwa ruchu drogowego,

— podniesienie bezpieczeństwa dokumentów związanych z pojazdami i uprawnieniami do kierowania nimi,

— usprawnienie prac organów administracji publicznej w zakresie wydawania dokumentów związanych z pojazdami i uprawnieniami do ich użytkowania, poprzez uporządkowanie i ujednolicenie procedur rejestracyjnych,

— podniesienie jakości i bezpieczeństwa obsługi obywateli i firm przez organy administracji publicznej w obszarze objętym działaniem systemu wynikające z nowoczesnych metod dostępu do zintegrowanych i wiarygodnych danych,

— dostosowanie rozwiązań polskich do rozwiązań stosowanych w krajach Unii Europejskiej i włączenie się do europejskich systemów ewidencji (EUCARIS, EUROTAX).

Wymienione cele powinny być realizowane poprzez stworzenie zintegrowanych warunków organizacyjno-prawnych i technicznych związanych z nabywaniem i posiadaniem pojazdów, z dopuszczaniem ich do ruchu i obrotu gospodarczego na terytorium Polski oraz z wydawaniem formalnych uprawnień do kierowania pojazdami.

Zamawiający zakłada, że realizacja wymienionych celów powinna przynieść również wymierne efekty ekonomiczne w postaci:

— zwiększonych wpływów budżetowych z tytułu efektywniejszego poboru podatków, opłat skarbowych, opłat celnych,

— zmniejszonych strat instytucji ubezpieczeniowych z tytułu wypłat nienależnych odszkodowań, a tym samym obniżenie indywidualnych opłat ubezpieczeniowych,

— lepszej pozycji rynkowej producentów pojazdów i legalnych importerów, a tym samym ustabilizowanie a być może i wzrost zatrudnienia w tych podmiotach.

Przedstawione wyżej cele i efekty o charakterze ogólnospołecznym, powinny być przez Dostawcę realizowane w ramach przedsięwzięcia w zakresie docelowym poprzez:

— uszczelnienie oraz standaryzację procesu rejestracyjnego pojazdów oraz wydawania praw jazdy,

— zapewnienie wysokiej kompletności, spójności i aktualności danych o pojazdach i kierowcach oraz zapewnienie możliwości ich efektywnej analizy,

— zapewnienie wysokiej dostępności danych z zachowaniem wymaganych mechanizmów ich ochrony,

a w zakresie docelowym, przewidzianym do wdrożenia na etapie eksploatacji i rozwoju systemu, poprzez:

— podniesienie jakości i bezpieczeństwa obsługi obywateli i firm przez organy administracji publicznej w obszarze objętym działaniem systemu, wynikającym z nowoczesnych metod dostępu do zintegrowanych i wiarygodnych danych,

— stworzenie warunków do zwiększenia efektywności, zmniejszenia kosztów procesu rejestracji oraz skutecznego wykrywania nieprawidłowości poprzez udostępnienie i pogłębioną analizę danych dotyczących tego procesu.

4. Obecny system ewidencji pojazdów i kierowców

Stosowane obecnie rozwiązania informatyczne wykorzystywane przy ewidencji pojazdów i kierowców są bardzo zróżnicowane i są jedynie rozwiązaniami lokalnymi terytorialnie.

Ustawa prawo o ruchu drogowym z 20 czerwca 1997 roku, z dniem 30 czerwca 1999 roku zakończyła funkcjonowanie Wojewódzkich Ewidencji Pojazdów (WEP). W związku z tym niektóre istniejące bazy wojewódzkie zaprzestały działania, gdyż starostwa nie miały obowiązku aktualizacji tej bazy. Dopiero ustawa z 31 marca 2000 roku przywróciła funkcjonowanie baz wojewódzkich, z obowiązkiem ich aktualizacji przez starostwa, ale nastąpiła prawie roczna przerwa i brak ciągłości w rejestracji danych w WEP. Oznacza to, że istnieją różnice pomiędzy informacjami zawartymi w ewidencjach pojazdów w WEP, a informacjami posiadanymi przez starostwa. Różnice te pogłębia fakt, że zgodnie z Rozporządzeniem Ministra z dnia 14 grudnia 2000 roku w prawie szczegółowych czynności związanych z dopuszczeniem pojazdu do ruchu (par. 3, pkt 3) w bazie starostwa są rejestrowane dodatkowe dane charakteryzujące pojazd, które nie muszą być przekazywane do WEP.

W obecnym stanie ewidencja pojazdów ma charakter rozproszony i składają się na nią zarówno ewidencje powiatowe jak i ewidencje wojewódzkie, które jednak nie zawierają kompletu informacji ze starostw z danego województwa.

Ponadto, z analizy rozwiązań teleinformatycznych wykorzystywanych aktualnie zarówno w WEP jak i w starostwach wynika, że są to rozwiązania bardzo zróżnicowane. Różnorodność stosowanych rozwiązań przedstawia poniższa tabela:

języki programowania		systemy operacyjne		środowiska bazodanowe
Clipper (dominujący)		DOS (dominujący)		DBase (dominujący)
Pascal		Novell Net Ware		Informix
Informix		MVS		BTRIVE
PLI		UNIX		ADABAS
Magic		WINDOWS		FOX
Natural		OS-400		Rozwiązania własne
Inne		SOLARIS

Tabela Zestawienie obecnie wykorzystywanych do ewidencji pojazdów rozwiązań informatycznych.

W zdecydowanej większości przypadków dane nie są szyfrowane. Około 1/3 eksploatowanych systemów nie posiada funkcji eksportu danych. Z 2/3 systemu można eksportować dane do formatu .TXT lub .DBF.

Niemal wszystkie systemy stosują słowniki marek i modeli, ale w większości przypadków są to jednak słowniki własne, a nie słowniki ITS.

Prawie wszystkie systemy stosują numer ewidencyjny PESEL/REGON jako identyfikator właściciela pojazdu, ale są zapisy — zwłaszcza archiwalne — nie zawierające tego typu identyfikatora.

Dowody rejestracyjne i pozwolenia czasowe sporządzane są w starostwach, przez naniesienie danych na gotowe papierowe formularze.

Około 20% starostw nie posiada sieci LAN łączącej stanowiska robocze do rejestracji pojazdów, a w około 30% sieć ta wymaga modernizacji.

W zakresie ewidencji kierowców, funkcjonuje system „Kierowca” obejmujący wszystkie starostwa, wykonany na zlecenie Ministerstwa Infrastruktury, zrealizowany przez Państwową Wytwórnię Papierów Wartościowych i innych podwykonawców. System funkcjonuje od roku 2001. Przesyłanie danych ze starostw do PWPW odbywa się poprzez zainstalowany system łączności satelitarnej VSAT. Starostwa zostały wyposażone w serwery i stanowiska robocze pracujące w sieci LAN oraz w potrzebne drukarki i skanery. Funkcjonalność systemu sprowadza się do formatowania i przekazywania zleceń produkcyjnych na wyprodukowanie prawa jazdy do PWPW oraz do rejestracji innych wydarzeń związanych z kierowcą (utrata uprawnień, ich odzyskanie, itd.).

Charakterystyki ilościowe

Poniżej podano dane opisujące szacowaną, na podstawie dotychczasowych doświadczeń, liczbę wykonywanych przez system operacji w ciągu roku:

— wydanie karty pojazdu —410 000,

— rejestracja pojazdu — 2 900 000,

— wydanie pozwolenia czasowego — 1 140 000,

— wydanie tablic rejestracyjnych — 1 500 000,

— wydanie prawa jazdy — 1 700 000,

— rejestracja OC — 15 000 000,

— wymiana prawa jazdy (na nowe) — 2 055 000 (tylko do końca 2006 r.),

— badanie techniczne — 8 500 000.

Rozkład liczby pojazdów, według danych z WEP, z podziałem na pojazdy czynne i archiwalne, w podziale na poszczególne województwa ilustruje poniższa tabela:

lp.	województwo	liczba pojazdów czynnych	liczba pojazdów archiwalnych
	Dolnośląskie	1 042 000	1 892 000
	Kujawsko-Pomorskie	915 282	151 341
	Lubelskie	1 528 521	979 894
	Lubuskie	424 106	379 742
	Łódzkie	1 222 558
	Małopolskie	1 443 310	221 323
	Mazowieckie	3 489 979	3 484 424
	Opolskie	435 070	650 590
	Podkarpackie	1 067 662	1 954 418
	Podlaskie	424 402	969 891
	Pomorskie	1 164 049	108 749
	Śląskie	1 680 000
	Świętokrzyskie	585 724	1 080 550
	Warmińsko-Mazurskie	759 047	208 374
	Wielkopolskie	1 792 289	1 243 628
	Zachodniopomorskie	689 050	527 859
razem		18 663 049	13 852 783

Tabela Aktualna liczba pojazdów zarejestrowanych w poszczególnych województwach wg danych WEP.

Ponieważ, wg szacunków Ministerstwa Infrastruktury ilość zarejestrowanych pojazdów w Polsce wynosi około 16 mln i szacunek ten pokrywa się z szacunkami firmy SAMAR, można zakładać, że ogólna liczba ponad 18,5 mln pojazdów zarejestrowanych w WEP-ach nie jest wiarygodna.

Zamawiający dysponuje szczegółowymi danymi określającymi dla każdego powiatu i każdej gminy warszawskiej: liczbę dziennie wydawanych praw jazdy, liczbę dziennie wydawanych dowodów rejestracyjnych oraz liczbę posiadanych stanowisk obsługujących. Z danych tych wynika, że maksymalna ilość wydawanych dziennie praw jazdy wynosi ok. 120 (powiat krakowski) a maksymalna ilość wydawanych dziennie dowodów rejestracyjnych wynosi 630 (powiat łódzki). Największa ilość stanowisk do obsługi klientów wynosi 20 (powiat łódzki). Średnio, liczba wydawanych praw jazdy wynosi 17, a liczba wydawanych dowodów rejestracyjnych — 30. Łącznie, wydawanych jest dziennie w całym kraju 6250 praw jazdy i 30000 dowodów rejestracyjnych.

Strumień informacji i danych, jakie są obecnie przekazywane z WEP jednostkom Policji, szacowany jest na:

rodzaj danych	średnia liczba sprawdzeń w ciągu			liczba zapytań w godzinach nocnych (21.00-6.00)	przewidywany wzrost liczby zapytań do roku 2008
		doby	tygodnia			miesiąca
Sprawdzenie w celu potwierdzenia bądź ustalenia właściciela — on-line	6 000	42 000	170-2220 tys.	ok. 40%	ok. 40%
Sprawdzenie w celu uzyskania danych historycznych pojazdu (np. poprzedni właściciel, poprzednie tablice, zmiana podzespołów) -on-line	1 000	7 000	28-35 tys.	ok. 25%	ok. 40-50%
Typowanie określonej grupy pojazdów na podstawie kryterium (off-line)	600	4 200	17-21 tys.	ok. 30-40%	ok. 40-50%

Tabela Szacunkowa wielkość informacji przekazywanych z WEP jednostkom Policji Państwowej.

Strumień informacji i danych, jakie są obecnie przekazywane z WEP jednostkom Straży Granicznej, szacowany jest na:

rodzaje zapytań	oczekiwana forma odpowiedzi	maksymalna liczba zapytań w ciągu
				doby	miesiąca
	Pytania dotyczące konkretnego pojazdu z odpowiedzią „TAK/NIE”	on-line	5 500	50 000
		off-line	80	700
		fax	60	550
	Pytania dotyczące konkretnego pojazdu z odpowiedzią specyfikującą jego cechy.	on-line	4000	36 000
		off-line	150	1 350
		papierowa	400	3 700
		fax	65	600
	Pytania o grupę pojazdów spełniających podany warunek z odpowiedzią „tylko liczba”.	on-line	190	1 700
		off-line	30	270
		papierowa	30	270
	Pytania o grupę pojazdów spełniających podany warunek z odpowiedzią specyfikująca pojazdy w grupie.	on-line	390	3 500
		off-line	40	260
		papierowa	100	900
		fax	1	10

Tabela Szacunkowa wielkość informacji przekazywanych z WEP jednostkom Straży Granicznej.

Na tle przedstawionych wyżej wartości, dane przekazywane innym podmiotom (Żandarmeria Wojskowa, Wojskowe Służby Informacyjne, Agencja Bezpieczeństwa Wewnętrznego, Ministerstwa Obrony Narodowej, Biuro Ochrony Rządu,...) mają charakter marginalny w stosunku do szacowanego całkowitego obciążenia systemu.

5. Ogólna specyfikacja systemu CEPiK

Niniejszy rozdział zawiera ogólną specyfikację systemu informatycznego, którego budowa, wdrożenie, utrzymanie i rozwój jest przedmiotem zamówienia.

1. Podstawy prawne

Komponenty aplikacyjne, realizujące opisaną w niniejszym rozdziale funkcjonalność powinny być zgodne z polskim ustawodawstwem, w tym w szczególności z:

• Ustawą z dnia 20 czerwca 1997 r. — Prawo o ruchu drogowym (Dz. U. 1997 Nr 98, poz. 602 z późn. zmianami).

• Ustawą o ubezpieczeniach obowiązkowych, Ubezpieczeniowym Funduszu Gwarancyjnym i Polskim Biurze Ubezpieczeń Komunikacyjnych.

— Ustawą z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. 1997 Nr 133, poz. 883 z późn. zmianami).

• Ustawą z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych (Dz. U. 1999 Nr 11, poz. 95 z późn. zmianami).

• Ustawą z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. 2001 Nr 130, poz. 1450),

• Ustawą prawo budowlane z dnia 7 lipca 1994 (Dz.U. 00.106.1126 z późniejszymi zmianami).

wraz z odpowiednimi aktami wykonawczymi.

Zamawiający zobowiązuje Dostawcę aby do końca 2005 roku dostosowywał system do zmian w przepisach prawa, a w szczególności do zmian ustawy prawo o ruchu drogowym, ustawy o ubezpieczeniach obowiązkowych, Ubezpieczeniowym Funduszu Gwarancyjnym i Polskim Biurze Ubezpieczeń Komunikacyjnych oraz aktów wykonawczych do tych ustaw, jeśli zmiany te wprowadzają zmiany w funkcjonowaniu systemu - pod warunkiem, że zostanie on poinformowany przez Zamawiającego o tych zmianach. Dostawca jest zobowiązany do dostosowania systemu do zmienionych uwarunkowań prawnych w terminie 2 miesięcy od daty poinformowania go zmianach przez Zamawiającego.

1. Funkcje systemu

Niniejsza sekcja zawiera ogólny opis procesów, w których uczestniczy system CEPiK oraz wskazuje rolę tego systemu w realizacji opisywanych procesów z uwzględnieniem jego zakresu minimalnego i docelowego. Przeznaczeniem tego rozdziału jest przede wszystkim opis kontekstu systemu, jego styków z otoczeniem, zakresu realizowanych funkcji oraz zakresu wykorzystywanych usług z otoczenia systemu. Niniejszy rozdział nie specyfikuje technicznej, fizycznej ani geograficznej struktury systemu. System CEPiK rozumiany jest tutaj jako jeden komponent techniczny, podzielony jedynie ze względu na świadczone dla otoczenia usługi.

Zawarty w niniejszym rozdziale opis funkcji systemu podzielony jest na obszary. W każdym z obszarów znajduje się ogólny opis procesu ze wskazaniem zakresu w jakim system CEPiK wspiera elementy tego procesu. Opisy te dotyczą stanu docelowego (uzyskanego po realizacji pełnego zakresu systemu). Dodatkowo przy każdym z obszarów znajduje się sekcja Elementy zakresu wyszczególniająca bardziej elementarne składniki zakresu systemu, które w dalszej części dokumentu są narzędziem planowania zakresów wdrożeniowych systemu, a w trakcie realizacji kontraktu mogą być wykorzystane jako narzędzie planowania poszczególnych cykli wytwórczych oprogramowania (patrz rozdział 8. Przebieg prac i organizacja przedsięwzięcia).

Znajdujące się tu opisy procesów i procedur oraz funkcji systemu mają charakter ogólny, ich przeznaczeniem jest opis funkcjonalności systemu widocznej dla jego otoczenia bez wskazywania konkretnych rozwiązań w zakresie konstrukcji systemu oraz bez podawania parametrów ilościowych charakteryzujących usługi systemu.

W dalszej części rozdziału znajdują się opisy funkcjonowania poszczególnych obszarów, w których działa system CEPiK.

1. Obsługa ewidencji pojazdów w powiatach i innych podmiotach zobowiązanych ustawowo

Procesy zasilające ewidencję pojazdów w CEP realizowane są przez wydziały komunikacji starostw i upoważnione jednostki organizacyjne innych podmiotów zobowiązanych ustawowo - zwanych dalej punktami rejestracyjnymi. Są to:

• jednostki właściwe do rejestracji pojazdów z powiatu warszawskiego,

• wojewoda mazowiecki dla pojazdów dyplomatycznych.

Celem procesów realizowanych w punktach rejestracyjnych jest świadczenie usług na rzecz następujących podmiotów:

— właściciela pojazdu,

— jednostek uprawnionych do podejmowania decyzji lub wykonywania czynności dotyczących pojazdu lub jego dokumentów.

Usługi realizowane przez uprawnione punkty rejestracji są wyszczególnione w ustawie Prawo o ruchu drogowym - patrz Tabela 5- Lista podmiotów współpracujących z systemem CEPiK - wg ustawy prawo o ruchu drogowym.

Do najważniejszych takich usług należą:

• czasowa rejestracja pojazdu,

• wpisanie zastrzeżeń do dowodu rejestracyjnego,

• wydanie karty pojazdu,

• przeniesienie własności pojazdu,

• wyrejestrowanie pojazdu,

• nadanie i wybicie numeru silnika i/lub nadwozia,

• utrata/odnalezienie tablic, dowodu rejestracyjnego, ...,

• badania techniczne.

Wszystkie procesy realizacji podstawowej usługi rejestracyjnej powinny przebiegać w podobny sposób, w następujących krokach:

1. Pre-rejestracja transakcji przez obywatela za pośrednictwem publicznego Internetu z wykorzystaniem aplikacji pozwalającej obywatelowi samodzielnie przepisać część lub wszystkie dane z posiadanych dokumentów przed udaniem się do urzędu (krok ten jest opcjonalny, obywatel może ale nie musi dokonać pre-rejestracji, podobnie zakres wprowadzanych informacji jest pozostawiony do decyzji obywatela; nie mniej aplikacja pre-rejestracji powinna umieć dokonać wstępnej oceny kompletności i wewnętrznej spójności wprowadzonych danych i informować obywatela o jej wynikach.

2. Gromadzenie (z ewentualnym odszukaniem w systemie CEPiK odpowiedniej transakcji pre-rejestracyjnej), wstępna (ręczna) ocena dokumentów właściwych dla załatwienia sprawy oraz odmowa kontynuacji sprawy w razie stwierdzenia niezgodności czy niekompletności lub przekazanie danych do warstwy centralnej systemu.

3. Ocena zgodności danych z zasobami informacyjnymi CEPiK oraz z zasobami innych systemów zintegrowanych z CEPiK - w tym w szczególności zgodności z referencyjnymi rejestrami PESEL, REGON, TERYT, kontrola unikalności i poprawności numeru VIN i/lub numerów zespołów numerowanych, zgodności z Katalogiem ITS modeli i typów pojazdów. W przypadku pojazdu rejestrowanego przez Wojewodę Mazowieckiego nie można badać zgodności z rejestrami PESEL i REGON. Przekazanie wyników weryfikacji na stanowisko jw

4. W razie otrzymania komunikatu o niezgodności — ocena stwierdzonej niezgodności oraz podjęcie jednej z następujących decyzji:

• odmowy realizacji danej czynności,

• wszczęcie postępowania wyjaśniającego stwierdzone niezgodności z ew. podjęciem tymczasowej decyzji (tam gdzie dopuszczają taką możliwość przepisy); w szczególności jeżeli niezgodność dotyczy modelu/typu pojazdu, kierowane jest pytanie do ITS o wyjaśnienie niezgodności.

W razie otrzymania komunikatu o zgodności— realizacja danej czynności w sposób zgodny z właściwą procedurą oraz ewidencja podjętych decyzji w CEPiK, co w zależności od realizowanych czynności może obejmować:

— produkcję (personalizację) dokumentów, która z punktu widzenia systemu polega na zadrukowaniu pustego blankietu na drukarce znajdującej się w punkcie rejestracyjnym i zaewidencjonowanie tego faktu w systemie.

— wydanie dokumentów, tablic rejestracyjnych i/lub znaków legalizacyjnych oraz ewidencja tych faktów w CEPiK,

• dokonanie odpowiednich wpisów w dokumentach pojazdu oraz ich ewidencja w CEPiK.

Kroki postępowania przy realizacji powyższych usług i związanych z nimi czynności ewidencyjnych powinny zostać zdefiniowane na etapie szczegółowych prac projektowych.

Punkty rejestracyjne prowadzą postępowania wyjaśniające faktyczny stan prawny pojazdów, traktując to postępowanie jako element ww procedury rejestracyjnej, lub jako postępowanie niezależne - jeśli wymaga tego sytuacja. Postępowanie takie przebiega w następujących krokach:

1. wszczęcie postępowania,

2, analiza dokumentów papierowych i/lub wymiana informacji z innymi jednostkami administracji,

3. ewidencja wyników postępowania wyjaśniającego w systemie CEPiK, w tym ew. ewidencja korekt (w razie stwierdzenia błędów w bazach danych systemu CEPiK).

Elementy zakresu

1. Ewidencja podjętych w punkcie rejestracyjnym decyzji, działań i wydanych dokumentów (tylko z weryfikacją spójności wewnętrznej ewidencjonowanej informacji) - element może być dodatkowo podzielony ze względu na zakres czynności i działań podlegających ewidencji.

2. Weryfikacja spójności danych z zasobami CEPiK (ewidencjami pojazdów oraz bazą migracyjną).

3. Personalizacja dokumentów.

4. Weryfikacja zgodności z danymi referencyjnymi - element może być dodatkowo podzielony ze względu na źródło danych (np. PESEL, REGON, TERYT).

5. Pre--rejestracja operacji przez klienta - element może być dodatkowo podzielony ze względu na rodzaj operacji podlegającej pre--rejestracji.

6. Wsparcie postępowań wyjaśniających poprzez mechanizmy wymiany korespondencji z innymi punktami rejestracyjnymi, centralą CEPiK oraz instytucją utrzymującą katalog modeli i typów pojazdów.

7. Wprowadzanie przez punkt rejestracyjny korekt zapisów w CEPiK (w zakresie kompetencji danego punktu rejestracyjnego) w wyniku postępowań wyjaśniających.

8. Wsparcie całości procesu obsługi klienta i sterowanie przepływem pracy w ramach tego procesu—element może być dodatkowo podzielony ze względu na czynności, których obsługa objęta jest takim całościowym wsparciem.

1. Obsługa ewidencji polis OC

W zakresie działania CEPiK znajduje się ewidencja zawieranych umów obowiązkowego ubezpieczenia odpowiedzialności cywilnej posiadaczy pojazdów oraz dostarczanie do UFG danych o pojazdach. Procesy przebiegają w następujących krokach:

1. System CEPiK w trybie wsadowym tworzy replikę danych o pojazdach i ich właścicielach (wg zakresu informacyjnego jak w art. 102 ustawy o ubezpieczeniach obowiązkowych...) i przekazuje te replikę do systemu UFG - codziennie w godzinach najmniejszego obciążenia systemu - patrz opis trybu automatycznego-subskrypcyjnego w rozdziale 5.2.6. Udostępnianie informacji.

2. System CEPiK otrzymuje z systemu UFG dane o ostatnio zawartych umowach OC w postaci plików wsadowych, tzn. zawartych i jeszcze nie przesłanych do CEPiK (wg zakresu informacyjnego jak w art. 102 ustawy o ubezpieczeniach obowiązkowych...) - z wykorzystaniem interfejsu centralnego - patrz rozdział 5.5.1. Interfejsy z użytkownikami systemu

3. System CEPiK weryfikuje odebrane z UFG dane o umowach OC i wysyła do systemu UFG wynik weryfikacji przekazanych danych.

Format danych powinien być uzgodniony w trakcie prac projektowych. Ustalony standard danych powinien - po uruchomieniu systemu UFG - obowiązywać przy przekazywaniu danych z Zakładów Ubezpieczeń do systemu UFG.

W ramach aplikacji obsługującej wymianę informacji pomiędzy systemem CEPiK a UFG, należy przewidzieć przekazywanie przez UFG do systemu CEPiK informacji o skierowaniu pojazdu - przez Zakład Ubezpieczeń - do badania kontrolnego (ustawa o ubezpieczeniach obowiązkowych..., art.. 148, pkt 3, litera a).

Elementy zakresu

1. Budowa i przekazanie do UFG repliki danych z CEP o pojazdach.

2. Ewidencja danych OC z pomocą obsługi technicznej systemu.

3. Weryfikacja danych OC z zasobami CEPiK z pomocą obsługi technicznej systemu.

4. Weryfikacja danych OC z zasobami danych referencyjnych z pomocą obsługi technicznej systemu - element może być dzielony ze względu na zakres danych referencyjnych (np. PESEL, REGON, TERYT, itp.).

5. Automatyczne przyjmowanie i ewidencja informacji dot. OC przychodzących z UFG.

6. Automatyczna weryfikacja danych OC przychodzących z UFG z zasobami CEPiK.

7. Automatyczna weryfikacja danych OC przychodzących z UFG z danymi referencyjnymi - element może być dzielony ze względu na zakres danych referencyjnych.(np. PESEL, REGON, itp.).

1. Obsługa ewidencji badań technicznych

System CEPiK uczestniczy w procesie ewidencji badań technicznych pojazdów. Zamawiający wymaga, aby w tym procesie możliwa była rejestracja ze Stacji Kontroli Pojazdu i z właściwego punktu rejestracyjnego. Oznacza to, że proces ten powinien przebiegać następująco:

1. Stacja Kontroli Pojazdów (SKP) wykonuje właściwą dla siebie czynność w odniesieniu do określonego pojazdu.

2. SKP wprowadza dane o przeprowadzonym badaniu technicznym pojazdu do CEPiK z wykorzystaniem aplikacji przeglądarkowej dostępnej w Internecie. Dane te są przez system traktowane jako pre-rejestracja tych danych.

3. Pracownik punktu rejestracyjnego wprowadza dane do CEPiK z dokumentów przekazanych przez SKP (ew. odszukując i wykorzystując właściwą transakcję pre-rejestracyjną).

4. System CEPiK przeprowadza weryfikacje informacji i ew. informacje o stwierdzonych niespójnościach wysyła do punktu rejestracyjnego (szczegółowy zakres i zasady weryfikacji będą przedmiotem ustaleń w trakcie prac projektowych).

5. W razie braku niespójności system CEPiK zastępuje dane pre-rejestracyjne danymi rejestracyjnymi.

6. W razie stwierdzenia niespójności wydział komunikacji odbiera taką informacje od systemu CEPiK i wszczyna postępowanie wyjaśniające.

Postępowania wyjaśniające wszczynane w ramach realizacji tego procesu przebiegają identycznie jak postępowania wyjaśniające związane z obsługą ewidencji pojazdów w punktach rejestracyjnych.

Aplikacja zainstalowana w warstwie centralnej systemu CEPiK powinna monitorować relacje pomiędzy zbiorem pre-rejestracji wykonania badań technicznych a zbiorem zgłoszeń faktycznych.

Opisana funkcjonalność jest realizowana poprzez interfejs centralny - z ew. wykorzystaniem Portalu Informacyjnego CEPiK - patrz opis Portal Informacyjny CEPiK (PIC) w rozdziale 5.5.1.

Elementy zakresu

1. Wprowadzanie informacji o badaniu technicznym do ewidencji w punkcie rejestracyjnym (bez weryfikacji wykraczających poza wewnętrzną spójność i kompletność informacji).

2. Pełna weryfikacja wprowadzanych informacji o badaniu technicznym.

3. Pre-rejestracja operacji przez SKP.

4. Wsparcie procesu w punkcie rejestracyjnym tj. obsługa powiadomienia o badaniu technicznym i sterowanie przepływem pracy w ramach tego procesu.

1. Obsługa ewidencji złomowań pojazdów

System CEPiK uczestniczy w procesie ewidencji złomowania pojazdów. Zamawiający wymaga, aby proces ten był zgodny z przygotowywaną ustawą o zmianie niektórych ustaw w związku z recyklingiem pojazdów zużytych lub nie nadających się do użytkowania oraz aby przebiegał on następująco:

1. Punkt Utylizacji (PU) przyjmuje pojazd do utylizacji.

2. PU wprowadza dane o przyjęciu pojazdu do utylizacji do CEPiK z wykorzystaniem aplikacji przeglądarkowej dostępnej w Internecie. Dane te są przez system traktowane jako pre-rejestracja tych danych.

3. Właściciel pojazdu zgłasza fakt przekazania pojazdu do utylizacji we właściwym dla niego punkcie rejestracyjnym.

4. Pracownik punktu rejestracyjnego wprowadza dane do CEPiK z dokumentów przedstawionych przez właściciela pojazdu (ew. odszukując i wykorzystując właściwą transakcję pre-rejsytracyjną).

5. System CEPiK przeprowadza weryfikacje informacji i ew. informacje o stwierdzonych niespójnościach wysyła do punktu rejestracyjnego. W procesie weryfikacji jest wykorzystany katalog uprawnionych PU.

6. W razie braku niespójności system CEPiK zastępuje dane pre-rejestracyjne danymi rejestracyjnymi i dokonuje odpowiednich zmian w bazach danych (wyrejestrowanie pojazdu).

7. W razie stwierdzenia niespójności punkt rejestracyjny odbiera taką informacje od systemu CEPiK i wszczyna postępowanie wyjaśniające.

Postępowania wyjaśniające wszczynane w ramach realizacji tego procesu przebiegają identycznie jak postępowania wyjaśniające związane z obsługą ewidencji pojazdów w punktach rejestracyjnych.

Aplikacja zainstalowana w warstwie centralnej systemu CEPiK powinna monitorować relacje pomiędzy zbiorem pre-rejestracji o oddaniu pojazdów do utylizacji a zbiorem zgłoszeń faktycznych.

Opisana funkcjonalność jest realizowana poprzez interfejs centralny - z ew. wykorzystaniem Portalu Informacyjnego CEPiK - patrz opis Portal Informacyjny CEPiK (PIC) w rozdziale 5.5.1.

Elementy zakresu

1. Wprowadzanie informacji o złomowaniu do ewidencji w punkcie rejestracyjnym (bez weryfikacji wykraczających poza wewnętrzną spójność i kompletność informacji).

2. Pełna weryfikacja wprowadzanych informacji o złomowaniu.

3. Pre-rejestracja operacji przez PU.

4. Wsparcie procesu w punkcie rejestracyjnym tj. obsługi powiadomienia o złomowaniu i sterowanie przepływem pracy w ramach tego procesu.

1. Eksport danych do naliczania podatku od środków transportu.

System CEPiK bierze udział w naliczaniu podatku od środków transportu. Proces ten ma miejsce raz na rok i jest wspierany przez CEPiK poprzez przygotowanie eksportów danych dla poszczególnych starostw z podziałem na gminy w starostwie, zawierających dane pozwalające na naliczenie zobowiązań podatkowych (pojazdy przyporządkowywane są do gmin na podstawie adresu zameldowania osoby fizycznej lub siedziby podmiotu, która(--y) jest właścicielem pojazdu).

1. MSWiA zleca dostawcy usług utrzymania systemu przeprowadzenie ekstrakcji danych na potrzeby naliczania podatku od środków transportu.

2. Dostawca usług utrzymania systemu produkuje dla każdego starostwa z podziałem na gminy w starostwie CD--ROM (lub zestaw CD--ROM--ów) zawierający dane potrzebne do naliczania podatku od środków transportu (tą część tych danych, która jest w zakresie informacyjnym CEPiK). Dane te powinny być w takim formacie (lub w dwóch wersjach w różnych formatach), aby było możliwe zarówno ich wydrukowanie w czytelnej dla ludzi postaci, jak również ich automatyczne przetwarzanie w systemach informatycznych (szczegóły będą przedmiotem ustaleń w trakcie prac projektowych) oraz zawierać wszystkie informacje potrzebne danej gminie do ustalenia zobowiązań podatkowych (w szczególności informacje o okresie w minionym roku, w którym pojazd był zarejestrowany w sposób przypisujący go do danej gminy).

3. Dostawca usług utrzymania systemu dystrybuuje wyprodukowane CD--ROM--y do starostw właściwych terytorialnie dla poszczególnych gmin. (szczegółowe warunki dystrybucji będą przedmiotem ustaleń w trakcie prac projektowych).

4. Starostwa dystrybuują CD--ROM--y do poszczególnych gmin.

Elementy zakresu

1. Produkcja ekstraktów oraz CD--ROM--ów wykorzystywanych do naliczania podatku przez obsługę techniczną systemu.

2. Udostępnianie informacji

Zamawiający udostępnia informacje z zasobów CEPiK dwóm rodzajom instytucji:

— podmiotom niekomercyjnym (głównie jednostkom administracji publicznej, organom ścigania, służbom specjalnym, organom wymiaru sprawiedliwości, itp.),

— podmiotom komercyjnym (głównie instytucjom o charakterze badawczym i statystycznym).

Proces udostępniania informacji na zasadach komercyjnych i niekomercyjnych przebiega w różny sposób.

Niezależnie od charakteru udostępniania informacji (komercyjnie czy niekomercyjnie) proces udostępniania informacji zawsze polega na odpowiedzi na pewne zapytanie. Ze względu na przebieg procesu obsługi, zapytania są dzielone na:

— standardowe, dla realizacji których system CEPiK ma gotowe aplikacje (realizacja tych zapytań nie wymaga udziału dostawcy usług utrzymania systemu),

— niestandardowe, które nie mogą być zrealizowane samodzielnie przez użytkownika za pomocą gotowej aplikacji (realizacja tych zapytań wymaga udziału dostawcy usług utrzymania systemu).

Zapytania standardowe, ze względu na swój charakter dzielone są na:

— zapytania proste — pytania o pojedyncze obiekty znajdujące się w ewidencji wykonywane z użyciem jednego z dostępnych identyfikatorów (możliwe jest formułowania zapytań prostych na kilku poziomach obszerności oczekiwanych odpowiedzi, np. tylko weryfikacja danych, tylko obecne dane pojazdu lub dane obecne wraz z całą historią, itp.),

— typowania — pytania o zbiory obiektów pasujące do pewnej częściowej charakterystyki obiektu danego rodzaju. Zakłada się, że niektóre typowania również będą traktowane jak zapytania niestandardowe. Odnosi się do tych typowań, których wynik może być bardzo licznym zbiorem obiektów (szczegółowe reguły realizacji typowań w sposób standardowy lub niestandardowy będą przedmiotem ustaleń w trakcie prac projektowych).

Niekomercyjne udostępnianie informacji

Proces niekomercyjnego udostępniania informacji będzie realizowany w dwóch zasadniczych trybach:

— w trybie urzędowym,

— w trybie automatycznym.

Dodatkowo w specjalny sposób realizowane będzie udostępnianie informacji na potrzeby wydziałów komunikacji starostw.

Udostępnianie informacji w trybie urzędowym

W trybie urzędowym obsługiwane mogą być zarówno zapytania standardowe jak i niestandardowe. Proces udostępniania informacji w trybie urzędowym przebiega w następujących krokach:

1. Instytucja żądająca informacji, przesyła w trybie urzędowym odpowiedni wniosek do MSWiA.

2. Pracownicy MSWiA oceniają zasadność wniosku, możliwości jego realizacji, ew. odmawiają jego realizacji formułując uzasadnienie odmowy (co kończy proces), ew. potwierdzają jego realizację ze wskazaniem terminu (krok ten obejmuje konsultacje z dostawcą usług utrzymania systemu, zwłaszcza gdy wniosek zawiera nie standardowe zapytanie).

3. Urzędnik MSWiA przygotowuje odpowiedni raport (jeśli wniosek dotyczy udostępnienia odpowiedzi na jedno ze standardowych zapytań, wtedy również nie występują dwa następne kroki procesu) lub kieruje zlecenie wygenerowania odpowiedniego raportu do dostawcy usług utrzymania systemu (jeśli wniosek dotyczy udostępnienia niestandardowego raportu).

4. W razie obsługi niestandardowego zapytania dostawca usług utrzymania systemu generuje odpowiedni raport (lub ekstrakt) i odsyła go urzędnikowi MSWiA (ten krok nie występuje przy obsłudze standardowego zapytania).

5. W przypadku niestandardowego zapytania urzędnik MSWiA odbiera raport wygenerowany przez dostawcę usług utrzymania systemu i sprawdza zgodność jego zawartości z obsługiwanym zapytaniem (w razie niezgodności ponownie kieruje zlecenie do dostawcy usług utrzymania systemu).

6. Urzędnik MSWiA formułuje odpowiedź na wniosek, załączając wygenerowany raport i zamyka sprawę.

Udostępnianie informacji w trybie urzędowym może również przybierać formę subskrypcji, tj. urzędnik podejmuje decyzję o regularnym dostarczaniu pewnych danych konkretnemu podmiotowi. Jeżeli dane te można uzyskać jako odpowiedź na standardowe zapytanie, to proces udostępniania w formie subskrypcji będzie realizowany przez MSWiA. Jeżeli dane mogą być uzyskane tylko przy pomocy niestandardowego przetwarzania, to MSWiA zleca okresową realizację takiego przetwarzania dostawcy usług utrzymania systemu, który po każdorazowym jego wykonaniu przekazuje wyniki MSWiA (a MSWiA wysyła je odpowiedniej instytucji).

Zamawiający wymaga, aby w procesie wdrażania systemu obiegu dokumentów (WorkFlow) uwzględniona została automatyzacja urzędowego trybu udzielania informacji.

Udostępnianie informacji w trybie automatycznym

Udostępnianie informacji w trybie automatycznym zapewnia podmiotowi, dla którego taki tryb jest dostępny, możliwość pozyskiwania informacji bezpośrednio z systemu (bez pośrednictwa urzędników MSWiA). System będzie udostępniał taką usługę kilkunastu podmiotom szczebla centralnego. Poszczególne podmioty będą różnić się zakresem uprawnień w tym obszarze. Różnice w uprawnieniach dotyczą:

--- ewidencji, do których podmiot ma dostęp: ewidencja kierowców, ewidencja pojazdów (cywilnych), ewidencja pojazdów specjalnych,

--- trybów, w których udostępniane są informacje z poszczególnych ewidencji (patrz niżej),

--- rodzajów zapytań, jakie mogą być zadawane do poszczególnych ewidencji.

W trybie automatycznym obsługiwane są jedynie zapytania standardowe. Proces obsługi zapytań w trybie automatycznym realizowany jest w następujących wariantach:

— udostępnianie informacji w trybie automatycznym-dochodzeniowym,

— udostępnianie informacji w trybie automatycznym-operacyjnym,

— udostępnianie danych w trybie automatycznym-subskrybcyjnym.

Udostępnienie informacji w trybie automatycznym-dochodzeniowym jest procesem odbywającym się w następujących krokach:

1. Pracownik (funkcjonariusz) podmiotu żądającego informacji formułuje zapytanie i wysyła je do systemu CEPiK za pośrednictwem systemu eksploatowanego przez instytucję, której jest funkcjonariuszem (z wyjątkiem wydziałów komunikacji starostw w odniesieniu do zapytań o pojazdy, które są wysyłane bezpośrednio do CEPiK za pomocą specjalnej aplikacji).

2. System CEPiK wyszukuje potrzebne informacje, formułuje i odsyła odpowiedź (w pewnych sytuacjach system może udzielać nieprawdziwej odpowiedzi i/lub przed odesłaniem jej podmiotowi żądającemu informacji wykonywać dodatkowe kroki związane z potrzebą ochrony pojazdów specjalnych opisaną obszerniej w rozdziale 5.2.10. Obsługa pojazdów specjalnych).

3. Pracownik (funkcjonariusz) podmiotu żądającego informacji odbiera komunikat z odpowiedzią, odczytuje go i ew. drukuje (również za pośrednictwem systemu eksploatowanego przez jego instytucję, chyba że jest to zapytanie dot. pojazdów z wydziału komunikacji starostwa, którego pracownicy korzystają ze specjalnej aplikacji systemu CEPiK).

Komunikacja w procesie realizowana jest w sposób asynchroniczny, a całość procesu jest rozciągnięta w czasie (tj. funkcjonariusz po wysłaniu zapytania porzuca proces i dopiero po pewnym czasie do niego powraca sprawdzając, czy nadszedł komunikat z odpowiedzią systemu).

Udostępnienie informacji w trybie automatycznym-operacyjnym jest procesem, przebiegającym w takich samych krokach jak proces opisany wyżej (łącznie z zastosowaniem odpowiednich mechanizmów ochrony pojazdów specjalnych). Różnica polega na tym, że komunikacja w tym procesie jest synchroniczna, całość procesu realizowana jest w bardzo krótkim czasie, podczas którego funkcjonariusz zadający pytanie czeka na odpowiedź systemu (przy stanowisku, z którego zapytanie zostało wysłane) a odpowiedź prezentowana jest mu natychmiast po jej otrzymaniu.

Udostępnianie informacji w trybie automatycznym-subskrypcyjnym przeznaczone jest dla podmiotów (organów administracji publicznej), które potrzebują utrzymywać replikę danych określonych zasobów CEPiK. Może być realizowane w sposób ciągły lub okresowy (w zależności od wymagań podmiotu i ustaleń pomiędzy nim i MSWiA). Realizacja w sposób ciągły polega na tym, że po każdej modyfikacji danych w zasobach CEPiK system wysyła do zasubskrybowanego systemu informatycznego innej instytucji odpowiedni komunikat identyfikujący obiekt i zawierający nową wersję jego danych. Realizacja w trybie okresowym polega na tym, że CEPiK automatycznie (wg ustalonego harmonogramu) uruchamia procedurę, w której generuje ekstrakt z danymi zmodyfikowanymi od czasu generacji ostatniego ekstraktu (lub ekstrakt ze wszystkimi danymi) i wysyła go do zasubskrybowanego systemu informatycznego. Procesem towarzyszącym udostępnianiu danych w trybie automatycznym subskrypcyjnym, jest sam proces subskrypcji systemów informatycznych. Przebiega on w następujących krokach:

1. Instytucja planująca utrzymywanie repliki danych CEPiK, składa taki wniosek w MSWiA.

2. Urzędnicy MSWiA oceniają zasadność wniosku, możliwości techniczne jego realizacji (w porozumieniu z dostawcą usług utrzymania systemu), spełnienie odpowiednich wymagań technicznych i bezpieczeństwa przez instytucję wnioskującą o rejestracje subskrypcji i podejmują decyzję o rejestracji subskrypcji (ew. odmawiają rejestracji subskrypcji wraz z uzasadnieniem).

3. W razie pozytywnego rozpatrzenia wniosku, MSWiA kieruje zlecenie utworzenia i uruchomienia subskrypcji dostawcy usług utrzymania systemu.

4. Dostawca usług utrzymania systemu we współpracy z personelem obsługi subskrybowanego systemu rejestruje i uruchamia subskrypcję, przekazuje raporty z realizacji tych czynności MSWiA.

5. Po uruchomieniu subskrypcji, dostawca usług utrzymania systemu utrzymuje ją w ruchu.

Typowym przykładem trybu automatycznego-subskrypcyjnego jest dostarczanie danych do UFG.

Wszystkie opisywane w niniejszej sekcji usługi udostępniane są przez system CEPiK jedynie poprzez interfejsy aplikacyjne (pozwalające na przyjmowanie/wysyłanie komunikatów i realizację wywołań z zewnętrznych aplikacji lub systemów informatycznych). System CEPiK (centrala systemu CEPiK) nie udostępnia żadnych interfejsów użytkownika pozwalających na korzystanie z tych usług (interfejsy takie są elementem Portalu Informacyjnego CEPiK, patrz rozdział 5.5.1. Interfejsy z użytkownikami systemu). Interfejsy dla poszczególnych podmiotów są w sensie technicznym i logicznym identyczne. Różnice polegają jedynie na prawach do poszczególnych usług oraz zakresie ich działania. Prawa do usług i zakresy ich działania (w sensie ewidencji, do których możliwy jest dostęp) są dla poszczególnych podmiotów konfigurowane zgodnie z decyzjami MSWiA dotyczącymi uruchomienia usług dla poszczególnych podmiotów. W szczególności, system CEPiK identyfikuje i autentykuje poszczególne instytucje (dokładniej - eksploatowane przez nie systemy), a nie poszczególnych funkcjonariuszy czy urzędników.

Udostępnianie informacji dla wydziałów komunikacji starostw

System CEPiK udostępnia wydziałom komunikacji starostw (i innym punktom rejestracji „cywilnych” pojazdów) aplikacje (interfejs użytkownika) pozwalający kierować do systemu CEPiK standardowe zapytania dotyczące pojazdów zarejestrowanych w danym powiecie. Działanie tych aplikacji ograniczone jest tylko do zbioru danych przypisanych do określonego powiatu lub punktu rejestracyjnego (szczegółowe określenie zakresu danych „widocznych” w ten sposób dla urzędników punktu rejestracyjnego będzie przedmiotem szczegółowych ustaleń w trakcie prac projektowych).

Komercyjne udostępnianie informacji

Proces komercyjnego udostępniania informacji, przebiega w sposób podobny do procesu zawierania kontraktów handlowych i realizowany jest w dwóch zasadniczych odmianach:

— na zasadzie jednorazowej,

— na zasadzie stałej współpracy.

W przypadku udostępniania na zasadzie jednorazowej, proces udostępniania przebiega w następujących krokach:

1. Instytucja potrzebująca informacji składa w MSWiA oficjalne zapytanie określając w nim o jakie informacje chodzi.

2. Pracownicy MSWiA oceniają prawne i techniczne możliwości realizacji żądanej usługi (w konsultacji z dostawcą usług utrzymania systemu), a następnie składają ofertę obejmującą propozycje zakresu i zasad realizacji usługi oraz propozycję cenową (ew. formułują odpowiedź na zapytanie, w której odmawiają realizacji usługi, wraz z uzasadnieniem, co kończy proces).

3. Następują negocjacje zakresu, zasad i ceny realizacji usługi pomiędzy instytucją składającą zapytanie i MSWiA (MSWiA konsultuje się na bieżąco z dostawcą usług utrzymania systemu), skutkiem których zawierana jest umowa (ew. negocjacje kończą się bez zawarcia umowy, co kończy proces).

4. MSWiA kieruje zlecenie wygenerowania odpowiedniego raportu do dostawcy usług utrzymania systemu CEPiK.

5. Dostawca usług utrzymania systemu, generuje raport i przekazuje go MSWiA.

6. MSWiA ocenia zgodność raportu ze zleceniem (w razie niezgodności, kieruje zlecenie ponownie do dostawcy usług utrzymania systemu).

7. MSWiA wystawia ostateczną fakturę i przekazuje raport wraz z fakturą instytucji zamawiającej usługę.

8. Instytucja składająca zamówienie odbiera raport i podpisuje fakturę (ew. wszczyna spór na gruncie prawa handlowego, jeżeli uznaje, że wykonana przez MSWiA usługa nie jest wykonana zgodnie z postanowieniami zawartej umowy, który to spór może oznaczać konieczność powtórzenia części lub całości procesu).

Uzgodniony w umowie harmonogram płatności może przewidywać inne niż opisane zasady fakturowania i płatności (np. częściowe lub całkowite płatności przed realizacją usługi).

Udostępnianie informacji na zasadzie stałej współpracy odbywa się na mocy zawartej umowy ramowej i przebiega w następujących krokach:

1. Instytucja potrzebująca dostępu do informacji, składa zapytanie ofertowe podobnie jak w poprzednim przypadku, z zaznaczeniem, że zainteresowana jest stałą współpracą w zakresie udostępniania opisanych informacji.

2. Pracownicy MSWiA podobnie jak w poprzednim przypadku składają ofertę, z tym, że oferta cenowa może mówić nie tyle o konkretnej cenie, co o zasadach ustalania ceny, w realizacji poszczególnych zamówień.

3. Następują negocjacje, skutkiem których podpisywana jest umowa ramowa stanowiąca, że konkretne usługi realizowane są na podstawie zamówień i regulująca zasady składania, wyceny, realizacji i płatności.

4. Kolejne raporty dla danej instytucji realizowane są na podstawie zamówień, w podobnych krokach jak świadczenie usługi na zasadzie jednorazowej (patrz wyżej), z tym, że zamiast zapytania ofertowego funkcjonuje zamówienie oraz brak jest faz oferowania i negocjacji (lub są bardzo zredukowane, zależnie od postanowień umowy ramowej).

Dane udostępniane komercyjnie będą zawsze danymi nie pozwalającymi na identyfikacje poszczególnych obiektów, których dotyczą (w szczególności niektóre raporty będą generowane jako raporty „depersonalizowane”).

Elementy zakresu

1. Możliwość realizacji przez obsługę techniczną systemu (w procesie udostępniania informacji w trybie urzędowym) zleceń dotyczących niestandardowych raportów z baz danych systemu CEPiK (do czasu wdrożenia odpowiednich aplikacji — również zapytań standardowych) - element zakresu może być dzielony ze względu na ewidencje, której dotyczą.

2. Możliwość samodzielnej realizacji przez MSWiA procesu udostępniania informacji w trybie urzędowym w zakresie zapytań standardowych - element zakresu może być dzielony ze względu na ewidencję, do której aplikacja zapewnia dostęp, oraz rodzaje zapytań, których realizację umożliwia (zapytania proste, typowania, itp.).

3. Udostępnianie informacji w trybie automatycznym-dochodzeniowym - element zakresu może być dzielony ze względu na ewidencję, której dotyczy oraz realizowane rodzaje zapytań (zapytania proste, typowania, itp.).

4. Udostępnianie informacji w trybie automatycznym-operacyjnym - element zakresu może być dzielony ze względu na ewidencję, której dotyczy oraz realizowane rodzaje zapytań (zapytania proste, typowania, itp.).

5. Możliwość udostępniania informacji w trybie automatycznym--subskrybcyjnym - element zakresu może być dzielony ze względu na ewidencję, której dotyczy.

6. Udostępnianie informacji dla wydziałów komunikacji starostw (i innych „cywilnych” punktów rejestracyjnych) - element zakresu może być dzielony ze względu na rodzaje wspieranych zapytań.

7. Możliwość realizacji przez obsługę techniczną systemu CEPiK (w procesie komercyjnego udostępniania informacji) zleceń dotyczących niestandardowych raportów z baz danych systemu CEPiK z uwzględnieniem zabezpieczeń przed identyfikacją poszczególnych obiektów - element zakresu może być dzielony ze względu na ewidencje, której dotyczy.

3. Obsługa ewidencji czynności Policji

CEPiK ewidencjonuje rozmaite czynności wykonywane przez Policję dotyczące pojazdu lub kierowcy (zgłoszenia kradzieży, umorzenia śledztw, zatrzymanie dokumentów pojazdu lub kierowcy, itp.). Kompletna lista zdarzeń podlegających ewidencji w CEPiK wynika z obowiązującego prawa.

Proces ewidencji tego typu zdarzeń przebiega w następujących krokach:

1. Policja w trakcie swoich działań operacyjnych lub dochodzeniowych otrzymuje informacje lub wykonuje czynności podlegające ewidencji w CEPiK.

2. Policja (funkcjonariusz Policji) wprowadza odpowiednie informacje do systemu informatycznego eksploatowanego przez Policję Państwową.

3. System eksploatowany przez Policję przesyła odpowiedni komunikat do systemu CEPiK.

4. System CEPiK weryfikuje komunikat od strony formalnej oraz od strony zgodności z innymi informacjami z jego zasobów lub zasobów rejestrów PESEL, REGON i TERYT (szczegółowy zakres weryfikacji będzie przedmiotem ustaleń w trakcie prac projektowych) i wysyła do systemu ZSIP ew. informacje o wykrytych błędach (szczegółowe zasady współpracy systemów będą przedmiotem ustaleń w trakcie prac projektowych).

5. System CEPiK ewidencjonuje zgłoszone zdarzenie (być może zależnie od wyniku weryfikacji, szczegółowe reguły ewidencji tej informacji, będą przedmiotem ustaleń w trakcie prac projektowych).

Istotną cechą opisywanego procesu jest pośrednictwo (w przekazywaniu informacji do CEPiK) systemu informatycznego eksploatowanego przez Policję oraz brak jakichkolwiek interfejsów użytkownika służących do wprowadzania tych informacji do systemu CEPiK.

Elementy zakresu

1. Odbiór odpowiednich komunikatów oraz automatyczna ewidencja określonych czynności policji w systemie CEPiK.

2. Automatyczna weryfikacja otrzymywanych od Policji informacji z zasobami systemu CEPiK.

3. Automatyczna weryfikacja otrzymywanych od Policji informacji z danymi referencyjnymi - element zakresu może być podzielony ze względu na zakres danych referencyjnych, do których się odnosi (REGON, PESEL, TERYT, itp.).

4. Obsługa centralnej ewidencji kierowców

Procesy zasilające ewidencję kierowców realizowane są przede wszystkim w wydziałach komunikacji startostw. W procesach tych będzie uczestniczył system KIEROWCA (eksploatowany obecnie przez wszystkie powiaty), który zostanie przez jego dostawcę dostosowany do współpracy z systemem CEPiK. Procesy, w realizacji których uczestniczy CEPiK związane są z realizacją przez starostwo wszystkich czynności, których przebieg lub wynik podlega ewidencji w CEPiK (na mocy obowiązującego prawa).

CEPiK nie wspiera procesów związanych z realizacją ww. czynności w sposób bezpośredni. Czynności te realizowane są w wydziałach komunikacji starostw przy wsparciu systemu KIEROWCA. System CEPiK wyłącznie udostępnia systemowi KIEROWCA interfejsy aplikacyjne pozwalające na:

--- Odpytywanie systemu CEPiK (dokładanie takie same interfejsy jak te opisane w rozdziale 5.2.6. Udostępnianie informacji w zakresie takim, jakiego wymagają przepisy oraz procedury działania w trakcie realizacji czynności wspieranych przez system KIEROWCA),

--- Przesyłanie do ewidencji w CEPiK informacji podlegających takiej ewidencji zgodnie z przepisami obecnie obowiązującego w tym obszarze prawa (szczegółowe zasady i protokoły będą przedmiotem szczegółowych ustaleń w trakcie projektu).

System CEPiK weryfikuje dane przesyłane do ewidencji ze względu na wewnętrzną spójność, zgodność z innymi zapisami w CEPiK oraz zgodność z danymi rejestrów PESEL, REGON czy TERYT (szczegółowe zasady weryfikacji i ewidencji danych będą przedmiotem ustaleń w trakcie prac projektowych).

Niezależnie od struktury geograficznej systemu KIEROWCA system CEPiK współpracuje z jednym ośrodkiem systemu KIEROWCA (za odpowiednie rozsyłanie i koncentrację komunikatów odpowiedzialny jest system KIEROWCA).

Dodatkowo specjalnie uprawniony użytkownik (instytucja) wskazana przez Zamawiającego wprowadza dane dot. kierowców bezpośrednio do systemu CEPiK za pomocą specjalnej aplikacji. Aplikacja ta służy wyłącznie do wprowadzania danych do systemu (w szczególności nie realizuje żadnych funkcji związanych z personalizacją dokumentów, sterowaniem przepływem pracy, itp.).

Zamawiający wymaga również od Dostawcy opracowania i wdrożenia aplikacji do rejestracji zaświadczeń ADR pozwalających kierowcy na przewóz materiałów niebezpiecznych poprzez portal G2B z wykorzystaniem interfejsu centralnego.

Elementy zakresu

1. Przyjmowanie z systemu KIEROWCA komunikatów i ewidencja odpowiednich informacji w systemie CEPiK.

2. Automatyczna weryfikacja informacji otrzymywanych od systemu KIEROWCA z zasobami systemu CEPiK.

3. Automatyczna weryfikacja otrzymywanych od systemu KIEROWCA informacji z danymi referencyjnymi - element zakresu może być podzielony ze względu na zakres danych referencyjnych, do których się odnosi (REGON, PESEL, TERYT, itp.).

4. Bezpośrednie wprowadzanie danych do ewidencji kierowców przez wyznaczoną instytucję.

5. Wykrywanie, analiza i wyjaśnianie nieprawidłowości

Na poziomie centrali sytemu CEPiK realizowany będzie ciągły proces monitorowania stanu systemu w poszukiwaniu nieprawidłowości. Wyszukiwane będą dwa zasadnicze rodzaje nieprawidłowości:

— uchybienia polegające na niezgodności pomiędzy pewnymi danymi w systemie, które mogą być skutkiem błędów systemu czy też błędów lub nadużyć urzędników, lub nawet być przejawem działalności przestępczej,

— anomalie, które nie są wprawdzie uchybieniami, tym nie mniej stanowią albo sytuacje bardzo nietypowe, albo sytuacje zidentyfikowane jako towarzyszące działalności przestępczej.

Proces monitorowania stanu systemu realizowany będzie na dwa sposoby:

— przez pracowników Zamawiającego, którzy stale zajmować się będą wyszukiwaniem nieprawidłowości w danych systemu,

— przez automatyczne procesy — „demony” pracujące w systemie, które zgodnie ze zdefiniowanymi wcześniej regułami identyfikować będą sytuacje wymagające oceny przez urzędników Zamawiającego.

Pierwszym krokiem w obu realizacjach procesu jest wykrycie nieprawidłowości przez pracownika Zamawiającego lub przez jeden z „demonów”, krokiem ostatnim jest wszczęcie postępowania wyjaśniającego przez urzędnika Zamawiającego (nie koniecznie tego samego, który wykrył nieprawidłowość), pomiędzy pierwszym i ostatnim krokiem może występować pewna liczba kroków akceptacji decyzji o wszczęciu postępowania wyjaśniającego (może to być zależne od rodzaju wykrytej nieprawidłowości).

Postępowania wyjaśniające wykryte nieprawidłowości prowadzone są przez właściwy podmiot i przebiegają w trzech krokach:

1. Wszczęcie postępowania.

2. Analiza danych, dokumentów papierowych i/lub wymiana informacji z innymi jednostkami administracji.

3. Podjęcie stosownych decyzji dotyczących wyjaśnianej sprawy, ew. wprowadzenie zapisów korygujących do systemu CEPiK i zamknięcie postępowania.

Dodatkowo w sposób ciągły realizowany jest proces analizy danych w systemie CEPiK zawansowanymi metodami statystycznymi (przez analityków Zamawiającego i podmiot eksploatujący system), którego celem jest identyfikacja nowych, skuteczniejszych, bardziej niezawodnych sposobów wyszukiwania nieprawidłowości.

Elementy zakresu

1. Możliwości raportowania, analizy i eksploracji danych przez pracowników Zamawiającego, celem wsparcia procesu wykrywania nieprawidłowości - rozległy element zakresu możliwy do podzielenia w sposób, który trudno przewidzieć na obecnym etapie budowy systemu.

2. Kilkadziesiąt „demonów” wykrywających typowe nieprawidłowości oraz możliwość instalacji nowych demonów—jw.

3. Wsparcie postępowań wyjaśniających przy pomocy mechanizmów wymiany korespondencji z punktami rejestracji pojazdów oraz podmiotem utrzymującym katalog modeli i typów pojazdów.

4. Możliwość wprowadzania korekt zapisów w CEPiK.

5. Wsparcie całego całego procesu obsługi nieprawidłowości od momentu jej wykrycia przez pracownika MSWiA lub automatycznego wykrycia przez system CEPiK.

6. Obsługa pojazdów specjalnych

Pojazdami specjalnymi są pojazdy wykorzystywane przez następujące instytucje:

— Policję,

— Ministerstwo Obrony Narodowej,

— Wojskowe Służby Informacyjne,

— Żandarmerię Wojskową,

— Biuro Ochrony Rządu,

— Agencję Bezpieczeństwa Wewnętrznego,

— Straż Graniczną,

— Agencję Wywiadu.

Każda z tych instytucji ma specyficzne dla siebie procedury ewidencji pojazdów oraz pewną liczbę punktów rejestracyjnych (łącznie kilkadziesiąt punktów rejestracyjnych). Istotną wspólną cechą wszystkich tych procesów jest występowanie w nich kroku weryfikacji wniosku o wykonanie pewnej czynności w ewidencji, kroku podjęcia pewnej decyzji i jej ewidencji oraz ew. kroków związanych z realizacją decyzji (wydanie numerów, znaków legalizacyjnych, dokumentów). System CEPiK udostępnia wspomnianym punktom rejestracyjnym aplikacje pozwalające na realizację poszczególnych kroków, funkcjonalność tych aplikacji jest uproszczona w stosunku do aplikacji eksploatowanych w powiatach ze względu na mniejszą różnorodność czynności realizowanych w odniesieniu do pojazdów specjalnych oraz specyficzny (pod wieloma względami uproszczony) zakres weryfikacji wprowadzanych informacji (szczegóły będą przedmiotem ustaleń w trakcie prac projektowych).

Informacje o pojazdach specjalnych stanowią wydzielony zestaw danych podlegający szczególnej ochronie (we wszystkich aspektach, od fizycznych i technicznych, aż po prawne i organizacyjne).

Niektóre pojazdy specjalne mogą być wykorzystywane w celach operacyjnych. Informacje o takich pojazdach wymagają specjalnej ochrony przez system. Ochrona ta wymaga od systemu realizacji następujących funkcji:

--- wskazywania pojazdów, które wymagają specjalnego traktowania,

--- wprowadzanie danych sterujących zachowaniem systemu przy próbach dostępu do informacji o takich pojazdach (np. różnego rodzaju „fałszywych” informacji),

--- modyfikacje funkcji systemu związanych z dostępem do danych o pojazdach tak, aby nie mogło poprzez ich wykorzystanie nastąpić ujawnienie pojazdu biorącego udział w działaniach operacyjnych (z wykorzystaniem informacji, o których wyżej),

--- udostępnienia specjalnego stanowiska, na które będą trafiać informacje o pewnych sytuacjach, wymagających ew. szybkich działań celem zachowania bezpieczeństwa prowadzonych działań operacyjnych,

--- wprowadzanie do normalnego funkcjonowania systemu zaburzeń (np. czasowych) pozwalających na ukrycie specjalnych działań systemu i jego obsługi związanych z ochroną pojazdów biorących udział w działaniach operacyjnych.

Szczegóły rozwiązań w tym obszarze są informacją bardzo wrażliwą i będą przedmiotem ustaleń w trakcie prac projektowych.

Aplikacja do obsługi pojazdów specjalnych powinna również uwzględniać następujące sytuacje, nią występujące w ewidencji pojazdów „normalnych”:

• Przewiduje się dodatkowy status pojazdu, tzn wycofanie pojazdu z ewidencji pojazdów specjalnych. Pojazd taki może być ponownie przedmiotem obrotu i przedmiotem ponownej (cywilnej) rejestracji.

• Ze względu na fakt, że niektóre podmioty rejestrujące (np. Policja, Straż Graniczna) chcą prowadzić własną ewidencję pojazdów z sobie właściwym zakresem informacyjnym, aplikacja rejestrująca powinna być przygotowana również w wersji pozwalającej na przejmowanie CEPiK-owej transakcji rejestracyjnej ( np. w postaci pliku wsadowego z takimi transakcjami) przez odpowiednią aplikację takiego podmiotu. Chodzi o to, aby dane o pojeździe raz wprowadzone, mogły być wykorzystane poza systemem CEPiK. Dostawca nie odpowiada za „zewnętrzne” wykorzystanie transakcji. Procedura taka nie może być realizowana w wydziałach komunikacji starostw.

Elementy zakresu

1. Ewidencja podjętych w punkcie rejestracyjnym (dla pojazdów specjalnych) decyzji, działań i wydanych dokumentów objętych zakresem ewidencji pojazdów specjalnych (tylko z weryfikacją wewnętrznej spójności ewidencjonowanej informacji).

2. Weryfikacja spójności z zasobami CEPiK.

4. Ochrona pojazdów specjalnych wykorzystywanych w działaniach operacyjnych - specyficzny element zakresu potencjalnie skutkujący również modyfikacjami innych funkcji systemu.

1. Obsługa ewidencji pojazdów nowych

System CEPiK uczestniczy w procesie ewidencji nowych pojazdów wyprodukowanych na terenie kraju lub zaimportowanych do Polski z zagranicy. Proces ten składa się z następujących kroków:

1.Producent/importer pojazdu wystawia kartę pojazdu.

2. Producent/importer pojazdu przekazuje informacje o wystawionej karcie pojazdu do systemu CEPiK.

3.System CEPiK weryfikuje informacje, zapisuje w ewidencji i ew. odsyła do producenta/importera informacje o stwierdzonych niezgodnościach (szczegółowe zasady weryfikacji i zapisu tych informacji będą przedmiotem ustaleń w trakcie prac projektowych).

4. Producent/importer wyjaśnia ew. wykryte przez CEPiK niezgodności i przesyła informacje korygujące.

Dane pomiędzy producentem/importerem pojazdów a systemem CEPiK są przekazywane w postaci plików na nośnikach magnetycznych.

Dane o pojazdach nowych - jeszcze nie zarejestrowanych przez potencjalnego nabywcę - muszą być w systemie specjalnie oznaczone.

Elementy zakresu

1. Automatyczne przyjmowanie, weryfikacja i ewidencja informacji od producenta/importera pojazdów dotyczących nowo wystawionych kart pojazdów.

2. Ewidencja podmiotów uczestniczących w obrocie pojazdami

System CEPiK uczestniczy w procesie ewidencji podmiotów uczestniczących w obrocie pojazdami (np. punktów utylizacji pojazdów, stacji badań technicznych, podmiotów uprawnionych do wydawania świadectw kwalifikacji, podmiotów uprawnionych do wystawiania świadectw ADR). Organ rejestrujący lub cofający rejestrację tego typu podmiotu (np. w przypadku złomowisk jest to wojewoda) będzie powiadamiał o tym fakcie starostwo właściwe terytorialnie dla podmiotu, które to starostwo wprowadzać będzie taką informację do CEPiK. Proces ten przebiega w następujących krokach:

1. Organ uprawniony wydaje decyzję dotyczącą rejestracji (zezwolenia) lub cofnięcia rejestracji (zezwolenia) dla danego podmiotu i przekazuje informację o tym do wydziału komunikacji właściwego terytorialnie starostwa.

2. Pracownicy wydz. komunikacji starostwa wysyłają tę informacje do systemu CEPiK.

3. System CEPiK weryfikuje i ewidencjonuje informacje oraz odsyła do wydziału komunikacji informację o wykrytych niezgodnościach.

W razie stwierdzenia przez CEPiK niezgodności wydział komunikacji wszczyna postępowanie wyjaśniające.

Szczegółowy wykaz takich podmiotów oraz zakresy informacji opisujących te podmioty we właściwych dla nich katalogach zostaną opracowane przez Dostawcę, we współpracy z Zamawiającym w trakcie prac projektowych.

Zamawiający wymaga, aby opracowana została funkcjonalność alternatywna w stosunku do wyżej opisanej, polegająca na tym, że podmiot uprawniony przekazuje dane o wydanych uprawnieniach bezpośrednio do systemu CEPiK - bez pośrednictwa wydziału komunikacji starostwa.

Elementy zakresu

1. Możliwość wprowadzania modyfikacji do wykazu podmiotów dostępna dla obsługi technicznej systemu.

2. Możliwości modyfikacji wykazu podmiotów dostępna w wydziałach komunikacji starostw (i ew. innych punktach rejestracyjnych).

3. Pozyskiwanie danych referencyjnych

Dane referencyjne pochodzą z zewnętrznych w stosunku do CEPiK źródeł:

— z rejestru PESEL,

— z rejestru REGON,

— z rejestru TERYT,

— z katalog modeli i typów pojazdów

Dla poszczególnych źródeł stosowane będą specyficzne scenariusze uzyskiwania dostępu do danych:

— PESEL: weryfikacja on-line,

— REGON i TERYT (rozwiązanie wstępne): ręczna aktualizacja repliki danych,

— REGON i TERYT (rozwiązanie docelowe): automatyczna okresowa replikacja danych,

— Katalog modeli i typów pojazdów: utrzymywanie danych w zasobach CEPiK.

Weryfikacja on-line

Proces uzyskiwania dostępu do danych rejestru w trybie weryfikacji on-line, przebiegałby następująco (jest to zawsze fragment procedury weryfikacji danych, będącej składnikiem któregoś z większych procesów wspieranych przez system):

1. System CEPiK rozpoczyna weryfikacje zgodności identyfikatora (numeru PESEL) z pozostałymi danymi osoby fizycznej (np. kierowcy).

2. System CEPiK przesyła do systemu PESEL badany numer oraz posiadane dane osoby fizycznej.

3. System PESEL sprawdza w swoich bazach danych, czy istnieje osoba o wskazanym numerze PESEL i zgodnych z przysłanymi przez system CEPiK danymi i odsyła systemowi CEPiK sygnał pozytywnej weryfikacji, jeśli taka osoba istnieje i negatywnej w przeciwnym wypadku.

4. System CEPiK odbiera komunikat z wynikiem weryfikacji i kończy weryfikacje zgodności numeru PESEL z wynikiem takim jak przysłany przez rejestr PESEL.

Proces ten może być realizowany w trybie synchronicznym (tj. CEPiK inicjuje sesję komunikacji i oczekuje na szybką odpowiedź systemu PESEL w tej samej sesji) lub asynchronicznym (tj. CEPiK inicjuje sesję komunikacji wysyła zapytanie i zamyka sesję, a oczekuje odpowiedzi w innej sesji współpracy, inicjowanej przez system PESEL).

Przy takiej realizacji procesu wymagane jest również utrzymywanie przez CEPiK pamięci podręcznej, w której będzie on składował wyniki tego typu zapytań zadawanych w ostatnim czasie, i z której mógłby korzystać dla przyspieszenia procedur weryfikacji danych lub też w razie nie dostępności rejestru.

Ręczna okresowa replikacja danych

Przy zastosowaniu tego sposobu uzyskiwania dostępu do danych określonego rejestru system CEPiK będzie utrzymywał częściową replikę danych tego rejestru. Proces pozyskiwania danych uruchamiany i sterowany jest „ręcznie” przez personel obsługujących oba systemy i polega na wykonywaniu w ustalonych odstępach czasu, następującej procedury:

1. Pracownik obsługujący system utrzymujący dany rejestr uruchamia procedurę ekstrakcji danych z tego systemu dla systemu CEPiK (może to odbywać się np. po otrzymaniu odpowiedniego zamówienia od obsługi systemu CEPiK albo od MSWiA).

2. System utrzymujący dany rejestr przygotowuje dla systemu CEPiK ekstrakt zawierający dane, które zostały zmodyfikowane od czasu generacji poprzedniego ekstraktu (lub też ekstrakt całości danych rejestru) i zapisuje go na nośniku(-ach) magnetycznych lub optycznych. (dane nie są szyfrowane).

3. Pracownicy obsługujący dany rejestr przekazują tak wyprodukowany dysk, pracownikom (w sposób odpowiedni do czułości informacji na nim zawartych) obsługującym system CEPiK.

4. Pracownicy obsługujący system CEPiK przy pomocy odpowiedniej aplikacji lub narzędzia wprowadzają otrzymany ekstrakt do systemu CEPiK.

5. System CEPiK aktualizuje swoją replikę danych rejestru na podstawie otrzymanego ekstraktu.

Proces ten nie wymaga istnienia zautomatyzowanego interfejsu pomiędzy obydwoma systemami. Wymaga natomiast wyposażenia obu systemów w odpowiednie narzędzia (aplikacje) służące do generacji ekstraktów (po stronie systemu źródłowego) i wprowadzania ekstraktów (po stronie systemu CEPiK).

Dodatkowo przed rozpoczęciem okresowej replikacji z wykorzystaniem opisanej procedury, konieczne jest dokonanie inicjalnej całościowej repliki odpowiedniego obszaru danych.

Automatyczna okresowa replikacja danych

Przy zastosowaniu tego sposobu uzyskiwania dostępu do danych określonego rejestru system CEPiK będzie utrzymywał częściową replikę danych tego rejestru. Proces pozyskiwania danych uruchamiany jest automatycznie w pewnym cyklu czasowym i polega na wykonywaniu w ustalonych odstępach czasu, następujące procedury:

1. System obsługujący dany rejestr przygotowuje dla systemu CEPiK ekstrakt zawierający dane, które zostały zmodyfikowane od czasu generacji poprzedniego ekstraktu (lub też ekstrakt całości danych rejestru).

2. System obsługujący dany rejestr wysyła do systemu CEPiK przygotowany ekstrakt.

3. System CEPiK odbiera ekstrakt z systemu obsługującego dany rejestr, a następnie aktualizuje na jego podstawie posiadaną replikę potrzebnych danych z rejestru.

Ze względu na to, że proces ten polega na wyłącznie jednokierunkowej komunikacji (bez żadnych odpowiedzi ze strony systemu CEPiK), komunikacja w tym procesie jest z natury rzeczy asynchroniczna.

Utrzymywanie danych w zasobach CEPiK

Rozwiązanie to polega na tym, że system CEPiK utrzymuje całość określonego rejestru (tu: Katalogu modeli i typów pojazdów), w swoich zasobach informacyjnych, a instytucji, której zadaniem jest utrzymywanie rejestru, udostępnia aplikacje (interfejs użytkownika) służącą do modyfikacji zawartości rejestru.

Wymagania infrastrukturalne

Do utrzymywania replik baz referencyjnych w stosunku do systemu CEPiK, Zamawiający wymaga od Dostawcy dostawy, instalacji i wdrożenia do eksploatacji macierzy dyskowej o parametrach określonych w Załącznik nr 4.2. -[Wymagania techniczne] część B. do niniejszego opracowania. Macierz ta jest dedykowana tylko do obsługi współpracy z rejestrami referencyjnymi.

Elementy zakresu

1. Integracja z systemem PESEL (w trybie weryfikacji on--line),

2. Integracja z rejestrem REGON w trybie ręcznej okresowej replikacji danych,

3. Integracja z rejestrem TERYT w trybie ręcznej okresowej replikacji danych,

4. Integracja z rejestrem REGON w trybie automatycznej okresowej replikacji danych,

5. Integracja z rejestrem TERYT w trybie automatycznej okresowej replikacji danych,

6. Katalog modeli i typów pojazdów utrzymywany w zasobach CEPiK wraz z możliwością jego modyfikacji przez wskazaną instytucję.

4. Szacunek zobowiązań dot. środka specjalnego

Zamawiający wymaga, aby Dostawca wykonał i wdrożył moduł do szacowania stanu zobowiązań po stronie przychodów dla środka specjalnego.

Przewidywane przychody tego środka powinny być rejestrowane w oparciu o realizację poszczególnych czynności ewidencyjnych i zawieranych umów OC, opisanych wyżej oraz w oparciu o tabelę opłat towarzyszącym tym czynnościom. Tabela ta powinna być zgodna ze zmienioną ustawą o ubezpieczeniach obowiązkowych oraz ze zmienioną ustawą prawo o ruchu drogowym.

Ewidencja zobowiązań powinna być podstawą do monitorowania stanu tych zobowiązań w podziale na podmioty zobowiązane do przekazywania środków na konto ww środka, tzn. w podziale na starostwa, stacje badań technicznych i UFG (wydruki, formatki ekranowe).

Elementy zakresu

1. Szacowanie wielkości wpływów na konto środka specjalnego.

2. Monitorowanie stanu szacunku środka specjalnego.

1. Wymiana informacji pomiędzy podmiotami i pomiędzy nimi a centrum

Zamawiający wymaga od Dostawcy opracowania i wdrożenia aplikacji do wymiany informacji pomiędzy punktami rejestracyjnymi o których mowa w rozdziale: 5.2.1. „Obsługa ewidencji pojazdów w powiatach i innych podmiotach zobowiązanych ustawowo, pomiędzy tymi podmiotami a warstwą centralną systemu CEPiK oraz pomiędzy tymi podmiotami a podmiotem odpowiedzialnym za utrzymanie katalogów modeli i typów pojazdów.

Wymiana informacji pomiędzy podmiotami powinna mieć charakter „1 ⇔ 1”, tzn. starostwo komunikuje się z wybranym starostwem lub z ze zdefiniowaną wcześniej grupą starostw. Nie jest dopuszczalna wymiana informacji pomiędzy podmiotami rejestrującymi pojazdy specjalne, za wyjątkiem specjalnie uprawnionego użytkownika Zamawiającego (patrz rozdział 5.2.10. „Obsługa pojazdów specjalnych”), który może wymieniać komunikaty z dowolnymi podmiotami rejestrującymi.

Wymiana informacji pomiędzy warstwą centralną systemu a podmiotami rejestrującymi, powinna mieć charakter „1 ⇔ N”, gdzie N oznacza dowolną (w szczególnym przypadku wszystkie) liczbę punktów rejestracyjnych.

Wymiana informacji w komunikacji pomiędzy punktami rejestracyjnymi a podmiotem odpowiedzialnym za utrzymanie katalogów modeli i typów pojazdów powinna mieć charakter „1 ⇔ 1” z punktu rejestracyjnego i
„1 ⇔ N” do punktu rejestracyjnego.

Wymianę informacji powinien obsługiwać portal G2G z wykorzystaniem interfejsu rozproszonego. Wymieniane informacje powinny mieć ustalony format (tekst, XML,...) i długość (np. 500 znaków).

Równocześnie, dla usprawnienia komunikacji pomiędzy podmiotami współpracującymi w systemie, Zamawiający zleca Dostawcy instalację i uruchomienie linii drukująco-kopertującej o parametrach jak w Załącznik nr 4.2. -[Wymagania techniczne] cz. D:

Elementy zakresu

1. Obsługa wymiany informacji pomiędzy podmiotami rejestrującymi.

2. Obsługa wymiany informacji pomiędzy podmiotami rejestrującymi i warstwą centralną systemu CEPiK.

3. Obsługa wymiany informacji pomiędzy podmiotami rejestrującymi a podmiotem odpowiedzialnym za utrzymanie katalogu modeli i typów pojazdów.

1. Podział funkcjonalności systemu na zakresy wdrożeniowe

Wszędzie, gdzie jest mowa o zakresie minimalnym, Zamawiający rozumie następujący zakres funkcjonalny i wdrożeniowy:

1. Uruchomienie Centralnej Ewidencji Pojazdów z danych zmigrowanych z Wojewódzkich Ewidencji Pojazdów i mechanizmów ich udostępnienia.

2. Przygotowanie do wdrożenia pełnej funkcjonalności właściwej dla obsługi wydziałów komunikacji starostw w odniesieniu do rejestracji pojazdów według specyfikacji wymagań funkcjonalnych, opisanych w poprzednich podrozdziałach rozdziału 5. - za wyjątkiem sterowania przepływem pracy.

3. Pilotowe wdrożenie funkcjonalności jw. w co najmniej jednym starostwie

Zamawiający wymaga, aby zakres minimalny został wdrożony do 31.03 2004 r.

Zamawiający wymaga, aby pozostała funkcjonalność systemu, opisana w niniejszym materiale, została podzielona na kolejne zakresy wdrożeniowe z przypisanymi im przez Dostawcę terminami- i wdrożenia jej w nieprzekraczalnym terminie do końca 2005 roku. Zamawiający zastrzega sobie prawo współdecydowania o kolejności wdrożeń. W szczególności - Zamawiający wymaga, aby:

• wdrożenie CEP w starostwach - łącznie ze sterowaniem przepływem pracy - 31.12.2004 r. [do eksploatacji przekazywany jest system wdrożony we wszystkich starostwach danego województwa].

• wdrożenie Centralnej Ewidencji Kierowców nie nastąpiło później niż do 31.07.2004 r.

• wdrożenie Centralnej Ewidencji Pojazdów Specjalnych nie nastąpiło później niż do 01.01.2005 r.

• uruchomienie pilotowe systemu analityczno-raportowego nie nastąpiło później niż do 01.07.2005.

• eksploatacyjne wdrożenie systemu analityczno-raportowego nie nastąpiło później niż do 31.12.2005 r.

Ponadto Zamawiający wymaga, aby Dostawca był przygotowany do zagospodarowania sprzętowego Komputerowego Centrum Zapasowego na trzy miesiące przed jego oddaniem do eksploatacji przewidzianym na 01.01.2005 r.

1. Zakres systemu

Zakres informacyjny i podmiotowy jest określony w aktach prawnych zawartych w rozdziale 5.1. Podstawy prawne i towarzyszących im aktach wykonawczych. W przypadku wykrycia w trakcie prac projektowych niespójności związanych z zakresami informacyjnymi określonymi w przepisach prawa Dostawca powinien zaproponować sposób usunięcia tych niespójności, a Zamawiający zobowiązuje się do przygotowania projektów odpowiednich aktów prawnych uwzględniających te propozycje i wystąpienia z inicjatywą legislacyjną.

Zakres danych o pojeździe, przechowywanych w centralnej ewidencji pojazdów, za które odpowiada starosta i którymi administruje minister właściwy do spraw administracji jest określony w art. 80 b ustawy „Prawo o ruchu drogowym” oraz w art. 148 ustawy ubezpieczeniach obowiązkowych, Ubezpieczeniowym Funduszu Gwarancyjnym i Polskim Biurze Ubezpieczycieli Komunikacyjnych. Zakres danych o kierowcach reguluje ustawa prawo o ruchu drogowym, art. 100b.

Ponadto, system powinien zapewniać możliwość przechowywania i przetwarzania danych dotyczących:

— badań technicznych,

— pojazdów, które zostały zgłoszone przez producentów i importerów samochodów, w zakresie odpowiadającym treści Karty Pojazdu,

— danych o przekazaniu pojazdu na złom.

System musi także przechowywać dla każdego pojazdu informacje dotyczące historii zmian danych:

— identyfikatorów numerowanych podzespołów pojazdu,

— właściciela pojazdu,

— innych zdarzeń związanych z pojazdem, od momentu jego pierwszej ewidencji w systemie do momentu jego złomowania.

Informacyjny i podmiotowy zakres systemu określają przepisy uporządkowane i zebrane w poniższej tabeli

Tabela - Zakres podmiotowy i informacyjny systemu CEPiK- wg ustawy prawo o ruchu drogowym i Ustawy o ubezpieczeniach obowiązkowych, Ubezpieczeniowym Funduszu Gwarancyjnym i Polskim Biurze Ubezpieczeń Komunikacyjnych

Lp.	Podmiot	Kod	Rodzaj współpracy	Art. ustawy	Uwagi
	Starosta	C	Uprawnienia do nadawania pojazdowi cech identyfikacyjnych	Art. 66a, ust.2	Producent-art.66a, ust.1
				C	Określenie podstawy rejestracji pojazdu	Art. 72
				C	Zobowiązanie do rejestracji pojazdów	Art. 73. ust. 1 i 2
				C	Zobowiązane do czasowej rejestracji pojazdów i uwarunkowania	Art. 74
				A	Upoważnienie do wpisów zastrzeżeń do dowodu rejestracyjnego	Art. 75
				C	Zobowiązanie do wydania karty pojazdu	Art. 77 ust. 3
				C	Upoważnienie do wpisu do karty pojazdu przeniesienia własności pojazdu	Art. 78
				C	Upoważnienie do wyrejestrowania pojazdu i uwarunkowania	Art. 79
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1 oraz art. 148 ustawy OC
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ..)	Art. 80b, ust.2 pkt.2 lit c
				B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt 10
				A	Zobowiązanie do utrzymania katalogu uprawnionych stacji badań technicznych na terenie powiatu	Art. 83, ust.1
				A	Wprowadzenie terminu badania technicznego	Art. 80b, ust. 2
				A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji-	Art. 82, ust. 1
				A	Zobowiązanie do wprowadzania do CEP informacji o skierowaniu pojazdu na badania kontrolne	Art. 81, ust.8
				A	Wprowadzenie danych do katalogu SKP o specjalnych uprawnieniach stacji opisanych w art. 83, ust. 4, pkt 2 (tzw okręgowe SKP)	Art. 83, ust. 5
				C	Zobowiązanie do wydawania uprawnień do kierowania pojazdami	Art. 97, ust. 1
				A	Zobowiązanie do wprowadzenie danych o wydanym wtórniku uprawnienia do kier. pojazdami	Art. 98. ust.2
				A	Zobowiązanie do wprowadzania danych do CEK jak w art. 100b, ust.1 pkt. 1-9	Art.. 100b. Ust.2 pkt. 1
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a.art. 137
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. b (cofnięcie/przywrócenie uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. b, art. 140
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. c (utrata/odnalezienie uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. c
				B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt 8
				A	Wprowadzanie do CEK danych o wydanych świadectwach kwalifikacji	Art. 115b, ust.2
				A	Wprowadzenie do CEK informacji o skierowaniu posiadacza uprawnienia na sprawdzenie kwalifikacji	Art. 114, ust.1
				A	Wprowadzenie do CEK informacji o zdaniu egzaminu przywracającego kwalifikacje do wydania uprawnienia	Art. 114. ust. 4
				A	Wprowadzenie do CEK informacji o skierowaniu kierowcy na badania lekarskie/psychologiczne	Art. 122 i 124
			Producenci/ importerzy	C	Zobowiązanie do wydania świadectwa homologacji dla nowego typu pojazdu	Art. 68
				C	Upoważnienie do nadawania pojazdom cech identyfikacyjnych	Art. 66a, ust.1
				C	Zobowiązanie do wydania karty pojazdu	Art. 77 ust. 1 i 2
			Siły Zbrojne	C	Zobowiązanie do rejestracji pojazdów w CEP-S	Art. 73. ust.3	Brak uprawnień ustawowych do otrzymywania danych z CEPiK
				C	Określenie podstawy rejestracji pojazdu w CEP-S	Art. 72
				A	Zobowiązanie do wprowadzenia do CEP-S danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1
				A	Zobowiązanie do wprowadzenia do CEP-S danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
				C	Upoważnienie do wyrejestrowania pojazdu z CEP-S i uwarunkowania	Art. 79
				A	Zobowiązanie do wprowadzenia do CEP-S danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ...)	Art. 80b, ust.2 pkt.2 lit c, oraz art. 148 ustawy OC
				A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji w CEP-S	Art. 82, ust. 1
					Zobowiązanie do rejestracji polis OC dla grup pojazdów specjalnych
				A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów Sił Zbrojnych	Art. 86
				C	Zobowiązanie do wydawania uprawnień żołnierzom służby zasadniczej	Art. 97. ust.3	Wydają dowódcy j.w. ale jest to uprawnienie służbowe a nie przedmiotowe
				A	Zobowiązanie do wprowadzania danych do CEK jak w art. 100b, ust.1 pkt. 1-9	Art.. 100b. Ust.2 pkt. 1
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. b (cofnięcie/przywrócenie uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. b
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. c (utrata/odnalezienie uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. c
				A	Zobowiązanie do wprowadzania do CEK informacji o skierowaniu na badania psychologiczne	Art.124, ust.1 pkt 6
			Policja	C	Zobowiązanie do rejestracji pojazdów	Art. 73. ust.3
				C	Określenie podstawy rejestracji pojazdu	Art. 72
				C	Upoważnienie do wyrejestrowania pojazdu i uwarunkowania	Art. 79
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1 oraz art. 148 ustawy OC
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
				A	Zobowiązanie do wprowadzania do CEP danych jak w art. 80b, ust.1 pkt 6 lit.b (dane o kradzieży/odnalezieniu pojazdu )	Art. 80b, ust.2 pkt.2 lit b
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ...))	Art. 80b, ust.2 pkt.2 lit c
				A	Zobowiązanie do wprowadzania do CEP informacji o skierowaniu pojazdu na badania kontrolne	Art. 81, ust.8
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust.pkt.6, lit.d (dane o zatrzymaniu/zwrocie dowodu rejestracyjnego lub pozwolenia czasowego)	Art. 80b, ust.2, pkt.2 lit.d, art. 132, art.133
				B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1
				B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
				A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów Policji	Art. 86
				A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji w CEP-S	Art. 82, ust. 1
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a, art. 129, art.135
				B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt 1
			Agencja Bezpieczeństwa Wewnętrznego	C	Zobowiązanie do rejestracji pojazdów	Art. 73. ust.3
				C	Określenie podstawy rejestracji pojazdu	Art. 72
				C	Upoważnienie do wyrejestrowania pojazdu i uwarunkowania	Art. 79
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ...))	Art. 80b, ust.2 pkt.2 lit c oraz art. 148 ustawy OC
		B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1 , pkt 4
		B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2,
		A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów ABW	Art. 86
		A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji	Art. 82, ust. 1
		B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt4
	Agencja Wywiadu	C	Zobowiązanie do rejestracji pojazdów	Art. 73. ust.3
		C	Określenie podstawy rejestracji pojazdu	Art. 72
		C	Upoważnienie do wyrejestrowania pojazdu i uwarunkowania	Art. 79
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1 oraz art. 148 ustawy OC
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ...))	Art. 80b, ust.2 pkt.2 lit c
		B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1 , pkt 4
		B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
		A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów AW	Art. 86
		A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji	Art. 82, ust. 1
		B	Udostępnianie danych z CEK	Art. 100c. ust.1 pkt. 4
	Straż Graniczna	C	Zobowiązanie do rejestracji pojazdów	Art. 73. ust.3
		C	Określenie podstawy rejestracji pojazdu	Art. 72
		C	Upoważnienie do wyrejestrowania pojazdu i uwarunkowania	Art. 79
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ...))	Art. 80b, ust.2 pkt.2 lit c oraz art. 148 ustawy OC
		B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt 3
		B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
		A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów SG	Art. 86
		A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji	Art. 82, ust. 1
		A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 129, ust.4a	Tylko w obszarze przygranicznym
		B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt 3
	Wojewoda mazowiecki	C	Zobowiązanie do rejestracji pojazdów inst. dyplomatycznych	Art. 73 ust.4
		C	Określenie podstawy rejestracji pojazdu	Art. 72
		C	Upoważnienie do wyrejestrowania pojazdu i uwarunkowania	Art. 79
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1 do 5 (dane o pojeździe, dokumentach i właścicielu)	Art. 80b, ust.2,pkt.1 oraz art. 148 ustawy OC
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. a (dane o nadaniu i wybiciu numeru nadwozia lub silnika)	Art. 80b, ust.2 pkt.2 lit a
		A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust. 1, pkt 6 lit. c (dane o utracie/odnalezieniu dowodu rejestracyjnego, tablic, ...))	Art. 80b, ust.2 pkt.2 lit c
		A	Wprowadzenie terminu badania technicznego pojazdu przy jego rejestracji	Art. 82, ust. 1
		C	Zobowiązanie do wydawania uprawnień do kierowania pojazdami dla personelu placówek dypl.	Art. 97. ust.3
		A	Wprowadzenie danych o wydanym wtórniku uprawnienia do kier. Pojazdami dla personelu placówek dypl.	Art. 98. ust.5
		A	Zobowiązanie do wprowadzania danych do CEK jak w art. 100b, ust.1 pkt. 1-9	Art.. 100b. Ust.2 pkt. 1
		A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a
		A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. b (cofnięcie/przywrócenie uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. b, art. 140
		A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. c (utrata/odnalezienie uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. c
		A	Wprowadzenie do CEK informacji o skierowaniu posiadacza uprawnienia na sprawdzenie kwalifikacji	Art. 114, ust.1
		A	Wprowadzenie do CEK informacji o zdaniu egzaminu przywracającego kwalifikacje do wydania uprawnienia	Art. 114. ust. 4
		A	Wprowadzenie do CEK informacji o wydaniu świadectwa kwalifikacji	Art. 115b, ust.2
		A	Wprowadzenie do CEK informacji o skierowaniu kierowcy na badane lekarskie/psychologiczne	Art. 122, ust.3, Art. 124
	Wojewoda	A	Zobowiązanie do utrzymania katalogu przedsiębiorstw utylizacji pojazdów	Art. 79
	P-stwo utylizacji	A	Wprowadzanie do systemu informacji o przyjęciu pojazdu do utylizacji		Brak zob. ustawowych
	Inspekcja Transportu Drogowego	A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust.pkt.6, lit.d (dane o zatrzymaniu/zwrocie dowodu rejestracyjnego lub pozwolenia czasowego)	Art. 80b, ust.2, pkt.2 lit.d. art. 134a
				A	Zobowiązanie do wprowadzania do CEP informacji o skierowaniu pojazdu na badania kontrolne	Art. 81, ust. 8
				B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt 1a
				B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a, art. 129a, art. 139, ust.4 (też art. 132, art. 133, art. 135 ust. 1, art. 136 ust.1, art. 139)
				B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt 1a
			Żandarmeria Wojskowa	A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust.pkt.6, lit.d (dane o zatrzymaniu/zwrocie dowodu rejestracyjnego lub pozwolenia czasowego)	Art. 80b, ust.2, pkt.2 lit.d, art. 134 oraz art. 148 ustawy OC
				A	Zobowiązanie do wprowadzania do CEP informacji o skierowaniu pojazdu na badania kontrolne	Art. 81, ust.8
				B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt 1a
				A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów ŻW	Art. 86
				B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a, art. 129, ( też art139, ust.3, art. 132, art. 133,art. 135 ust. 1, art. 136 ust. 1, art. 139)
				B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt 2
			Stacja Kontroli Pojazdów	A	Zobowiązanie do wprowadzenia do CEP danych o terminie badania technicznego	Art. 80b, ust.2, pkt.1 Art. 82, ust.2
				A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust.pkt.6, lit.d (dane o zatrzymaniu dowodu rejestracyjnego lub pozwolenia czas.)	Art. 80b, ust.2, pkt.2 lit.d, art. 132, ust.4
				C	Warunki przeprowadzania badań technicznych	Art. 81
			Wojskowe Służby Informacyjne	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt 5
				B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
				B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt 5
			Sądy	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 6
				B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a, art. 137 ust. 1 pkt. 2
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. d (środek karny-zakaz prowadzenia pojazdów)	Art. 100b, ust. 2, pkt.2 lit. d
				B	Udostępnianie danych z CEK	Art. 100c. ust.1 pkt. 6
			Prokuratury	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 7
				B	Uprawnienie do korzystania z danych z CEP-S	Art. 80c, ust.2
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 100b, ust. 2, pkt.2 lit. a, art. 137 ust. 1 pkt. 1
				B	Udostępnianie danych z CEK	Art. 100c, ust.1, pkt. 7
			Organy celne	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 8
				A	Zobowiązanie do wprowadzania danych jak w art. 100b, ust.1 pkt. 10 lit. a (zatrzymanie/zwrot uprawnienia)	Art. 129, ust.4a	Tylko w obszarze przygranicznym
				B	Udostępnianie danych z CEK	Art. 100c, ust.1 pkt. 10
	Organy Kontroli Skarbowej	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 8
	Ubezpieczeniowy Fundusz Gwarancyjny	A	Zobowiązanie do wprowadzenia do CEP danych jak w art. 80b, ust.pkt.7, lit.d (dane o ubezpieczeniach obowiązkowych)	Art. 80b, ust.2, pkt.3 i art. 102, pkt. 2 ustawy OC	Wg ustawy ten obowiązek spoczywa na zakł. ubezp
				A	Uprawnienie do wprowadzania do CEP informacji o skierowaniu pojazdu do badania kontrolnego		Wg ustawy o ubezp. obowiązkowych, art. 148
				B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 9
			Szef Krajowego Centrum Informacji Kr.	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 11
				B	Udostępnianie danych z CEK	Art. 100c. ust.1, pkt. 9
	Komornicy sądowi	B	Uprawnienie dostępu do danych z CEP	Art. 80c, ust.1, pkt. 12
	Inne podmioty i osoby fizyczne	B	Możliwość dostępu do danych z CEP za zgodą ministra SWiA	Art. 80c, ust.3-6
				B	Udostępnianie danych z CEK za zgoda ministra SWiA	Art. 100c. Ust.3
	Państwowa Straż Pożarna	A	Zobowiązanie do utrzymywania katalogu uprawnionych stacji badań technicznych dla pojazdów PSP	Art. 86	Brak innych zobowiązań ustawowych
	Minister SWiA	A	Zobowiązanie do utrzymywania katalogu przedsiębiorstw do specjalistycznych badań technicznych	Art. 80f, ust.4
	Instytut Transportu Samochodowego	A	Utrzymywanie słowników modeli, typów, marek, kolorów - brak zobowiązań ustawowych		Brak zobowiązań ustawowych
	Główny Urząd Statystyczny	A	Utrzymywanie rejestrów referencyjnych: REGON, TERYT		Brak zobowiązań ustawowych
	Biuro Informacyjne Krajowego Rejestru Karnego	A	Polecenie usunięcia z CEK danych jak w art. 100b, ust.1 pkt 10, lit. d	Art. 100b, ust. 3
	Podmioty prowadzące specjalistyczne badania techniczne pojazdów	A	Zobowiązanie do wprowadzania danych o wydanych świadectwach oryginalności pojazdów	Art. 80i, ust. 1, pkt 5	wymagane zezwolenie MSWiA (art. 80f - 80i)
	Właściciel lub posiadacz pojazdu powierzonego przez zagraniczną osobę fizyczną lub prawną (art. 73 ust. 5)	B	Uprawnienie dostępu do CEP na jego wniosek	Art. 80c ust. 3
	Podmiot uprawniony do wystawiania świadectw ADR	A	Zobowiązanie do dostarczania do CEK danych o zaświadczeniach ADRh	Art. 100b, ust. 2, pkt 3
	Marszałek województwa	A	Utrzymywanie listy podmiotów uprawnionych do wydawania zaświadczeń ADR	Art. 12, ust.1 ustawy o przewozie drogowym materiałów niebezpiecznych

1. Wymagania pozafunkcjonalne

Niniejszy rozdział przedstawia dodatkowe wymagania i założenia dotyczące funkcji systemu lub ich grup, które nie definiują samych funkcji, lecz jedynie pewne wymagania, dotyczące sposobu ich realizacji.

1. Interfejsy z użytkownikami systemu

Wszystkie automatyczne interfejsy z użytkownikami systemu są realizowane jako możliwość przyjmowania, obsługi i wysyłania komunikatów o ustalonym formacie i znaczeniu drogą teletransmisji poprzez ustalone kanały komunikacyjne umożliwiające wykorzystanie protokołów TCP/IP.

Zamawiający oczekuje przygotowania i wdrożenia następujących interfejsów pomiędzy systemem CEPiK a podmiotami współpracującymi z tymi zasobami:

1. Interfejs rozproszony - patrz diagram 3.

Diagram Interfejs rozproszony

Według tego interfejsu:

1. Aplikacja do obsługi funkcjonalności właściwej dla stanowiska jest uruchamiana przez Dostawcę na stanowisku użytkownika końcowego. Aplikacja ta powinna obsługiwać funkcjonalność właściwą dla tego stanowiska.

2. Aplikacja do współpracy ze stanowiskami końcowymi (autentykacja stanowiska i jego uprawnień, odbiór danych, ich weryfikacja, sformułowanie i przekazanie komunikatu dla stanowiska) jest zainstalowana w warstwie centralnej systemu.

3. Komunikacja pomiędzy stanowiskami końcowymi a warstwą centralną systemu odbywa się poprzez dedykowaną dla systemu sieć telekomunikacyjną. Łącze zapasowe stanowi sieć satelitarna VSAT, wykorzystywana do obsługi systemu KIEROWCA. Zamawiający wymaga, aby aplikacje obsługujące ten typ interfejsu mogły pracować na sieci zapasowej.

4. Użytkownicy końcowi uwiarygadniają swój dostęp do systemu i są autoryzowani przez aplikację zainstalowaną w warstwie centralnej systemu.

Dla użytkowników współpracujących z systemem CEPiK według interfejsu rozproszonego Dostawca jest zobowiązany do:

• Opracowania i wdrożenia aplikacji o funkcjonalności jw. dla warstwy centralnej.

• Opracowania i wdrożenia aplikacji o funkcjonalności jw. dla użytkowników końcowych.

• Instalacji niezbędnego software'u na serwerach warstwy centralnej jak i na stanowiskach użytkowników.

• Eksploatacji aplikacji jw. do końca roku 2009.

2. 
   Interfejs centralny - patrz diagram 4

Diagram Interfejs centralny

Według tego interfejsu:

1. W warstwie centralnej systemu są zainstalowane aplikacje do:

• obsługi funkcjonalności właściwej dla podmiotu,

• autentykacji i weryfikacji uprawnień serwera podmiotu.

Administrator serwera podmiotu jest odpowiedzialny za autentykację stanowisk (osób) i ich uprawnienia.

Komunikacja pomiędzy stanowiskami końcowymi a warstwą centralną systemu odbywa się poprzez dedykowaną dla systemu sieć telekomunikacyjną.

Dane przekazywane pomiędzy warstwą centralną systemu CEPiK a serwerem komunikacyjnym podmiotu mają wspólny format, ustalony przez Dostawcę w trakcie szczegółowych prac projektowych. Dostosowanie formatu komunikatów do formatu obowiązującego w CEPiK należy do podmiotu i nie jest przedmiotem zamówienia.

Dla użytkowników współpracujących z systemem CEPiK według interfejsu centralnego Dostawca jest zobowiązany do opracowania i wdrożenia aplikacji dla warstwy centralnej wg funkcjonalności jw.

Portal Informacyjny CEPiK (PIC)

Interfejs centralny może być realizowany poprzez Portal Informacyjny CEPiK (PIC).

Zakresem zamówienia objęta jest budowa takiego portalu. PIC jest systemem, przeznaczonym do eksploatacji przez te instytucje administracji publicznej, które nie mają własnych systemów informatycznych, możliwych do integracji z systemem CEPiK poprzez interfejs centralny. PIC uczestniczy w procesie niekomercyjnego udostępniania informacji w trybie automatycznym-dochodzeniowym oraz w trybie automatycznym-operacyjnym na rzecz instytucji, która go eksploatuje.

Zakresem zamówienia objęta jest budowa oprogramowania PIC, przygotowanie szczegółowych instrukcji jego instalacji i eksploatacji oraz dostarczanie w okresie do końca 2009 roku modyfikacji oprogramowania PIC będących skutkiem usuwania błędów wykrytych w trakcie eksploatacji oraz realizacji kolejnych etapów prac nad systemem.

Zakresem zamówienia nie są objęte instalacje i wdrożenia PIC w poszczególnych instytucjach (z wyjątkiem uruchomienia odpowiednich interfejsów po stronie ośrodków centralnych CEPiK).

Portal informacyjny CEPiK uczestniczy w procesie nie komercyjnego udostępniania informacji w trybach automatycznym-dochodzeniowym oraz automatycznym-operacyjnym występując w nim w roli zewnętrznego systemu eksploatowanego przez daną instytucje, a jego funkcje wynikają z tej roli zgodnie z opisem w rozdziale Udostępnianie informacji w trybie automatycznym.

Wspierając proces udostępniania informacji w trybie automatycznym-dochodzeniowym PIC udostępnia użytkownikom następujące funkcje:

--- Wysyłanie zapytań do systemu CEPiK,

--- Odbieranie i wydruk odpowiedzi z systemu CEPiK.

Wspierając udostępnianie informacji w trybie automatycznym - PIC udostępnia użytkownikom funkcję zapytania do systemu CEPiK z natychmiastowym wyświetleniem odpowiedzi.

Elementy zakresu PIC

1. Wsparcie procesu udostępniania informacji w trybie automatycznym-dochodzeniowym - element zakresu może być podzielony ze względu na ewidencję, której dotyczy, oraz rodzaje wspieranych zapytań (zapytania proste, typowania, itp.).

3. Wsparcie procesu udostępniania informacji w trybie automatycznym-operacyjnym - element zakresu może być podzielony analogicznie jak poprzedni (ze względu na ewidencje oraz ze względu na rodzaj zapytań).

Architektura PIC

PIC ma architekturą wielowarstwową, w której użytkownicy uzyskują dostęp do PIC za pomocą przeglądarek WWW. Wszystkie wymienione niżej wymagania dotyczące architektury PIC odnoszą się do oprogramowania serwerów PIC (to samo dotyczy również wymagań wydajnościowych).

Konstrukcja PIC zapewnia spełnienie następujących wymagań:

--- Umożliwia zainstalowanie i eksploatacje PIC na maszynach opartych na procesorach INTEL,

--- Umożliwia zainstalowanie i eksploatacje PIC na przynajmniej dwóch innych architekturach sprzętowych (innych niż oparta na procesorach INTEL),

--- W przypadku architektury opartej na procesorach INTEL umożliwia instalację i eksploatację pod kontrolą dwóch różnych systemów operacyjnych (przy czym chodzi tu o dwa zupełnie różne systemy, nie mogą to być dwie różne wersje, odmiany lub dystrybucje tego samego systemu operacyjnego, w szczególności Windows 98, NT, 2000, XP itp. w rozumieniu tego wymagania nie są różnymi systemami operacyjnymi, podobnie jak różne dystrybucje systemu Linux czy też różne odmiany BSD Unixa; są natomiast różnymi systemami operacyjnymi np. dostarczane przez różnych dostawców odmiany systemu UNIX, np. AIX, HP-UX, Linux, BSD, itp.),

--- W przypadku architektury opartej na procesorach INTEL umożliwia instalację i eksploatację w środowisku w całości zbudowanym z oprogramowania licencjonowanego w sposób nie wymagający od jednostek administracji publicznej w Polsce zakupu licencji (łącznie z systemem operacyjnym),

--- Zapewni możliwość instalacji i eksploatacji pojedynczej instancji PIC w środowisku zbudowanym z wielu maszyn, w sposób zapewniający odporność na awarię pojedynczego elementu takiej instalacji (bez konieczności zapewnienia niezawodności sesji) oraz zapewniający możliwie zbliżony do liniowego wzrost przepustowości PIC wraz z rozbudową instalacji o kolejne maszyny (identyczne) (konkretny sposób i moment weryfikacji tego wymagania będzie przedmiotem ustaleń w trakcie realizacji kontraktu, w szczególności może zostać ograniczony do audytu konstrukcji aplikacji). Środowisko takie może wymagać wykorzystania konkretnego oprogramowania, którego eksploatacja wymaga zakupu licencji i/lub dodatkowych urządzeń.

Definicje wymagań wydajnościowych - Warunki pomiarowe

Sformułowane poniżej wymagania wydajnościowe odnoszą się do referencyjnej instalacji PIC, która charakteryzuje się następującymi własnościami i parametrami:

--- wszystkie elementy oprogramowania niezbędne do eksploatacji PIC zainstalowane na jednej maszynie opartej na procesorze INTEL o parametrach nie lepszych niż: 1 procesor Pentium Xeon 2,4 GHz, 512 kB Cache, 2 GB RAM 200Mhz, 40 GB HDD SCSI,

--- nie mniej niż 200 użytkowników, z których każdy średnio raz na 10 minut kieruje zapytanie do systemu CEPiK (szczegółowy plan testów zawierający rozkłady różnego rodzaju zapytań, będzie przedmiotem prac i uzgodnień w trakcie realizacji kontraktu),

Definicje wymagań wydajnościowych - Narzut PIC

Średni narzut PIC w stosunku do czasów odpowiedzi centrali CEPiK, nie powinien przekraczać 2 sekund lub 5% średnich czasów realizacji wymaganych dla konkretnych usług od centrali systemu CEPiK, a narzut maksymalny 15 sekund lub 10% średnich czasów realizacji wymaganych dla konkretnych usług od centrali systemu CEPiK (wielkości nie uwzględniają opóźnień wynikających z przekazywania informacji przez sieci komputerowe, szczegółowe zasady pomiaru opóźnień w odniesieniu do różnego rodzaju zapytań i trybów pracy, będą przedmiotem prac i ustaleń w trakcie realizacji kontraktu).

Ergonomia PIC

Do oprogramowania PIC odnoszą się te same wymaganie dotyczące ergonomii interfejsów użytkownika, co do wszystkich aplikacji systemu CEPiK

Zarządzanie użytkownikami PIC

Każda instalacja PIC utrzymuje własny katalog użytkowników oraz przypisanych im uprawnień niezależny od katalogu w centrali CEPiK, na własną rękę identyfikuje i autentykuje użytkowników, jak również może udostępniać poszczególnym użytkownikom węższy zestaw usług niż ten, który jest udostępniany przez centralę CEPiK (wynikający z uprawnień przydzielonych całej instytucji w centrali systemu CEPiK). Zakłada się, że możliwości ograniczania dostępu dla poszczególnych użytkowników są analogiczne jak w przypadku uprawnień dla instytucji na poziomie centrali CEPiK (rozdział Udostępnianie informacji w trybie automatycznym).

4. 
   
   
   
   
   
   
   
   Interfejs podmiotowy - patrz diagram 5

Diagram Interfejs podmiotowy

Według tej architektury:

1. W warstwie centralnej systemu są uruchomione aplikacje do obsługi funkcjonalności właściwej dla komunikacji z aplikacją zainstalowaną na serwerze podmiotu oraz do autentykacji i weryfikacji uprawnień serwera podmiotu.

2. Na serwerze podmiotu jest uruchomiona aplikacja do:

• Obsługi funkcjonalności właściwej dla podmiotu.

• Współpracy z aplikacją centralną.

• Obsługi procesu autentykacji i weryfikacji użytkowników końcowych podmiotu.

• Środowisko software'owe, niezbędne do obsługi aplikacji - ogólnie dostępne na rynku IT

3. Komunikacja pomiędzy stanowiskami końcowymi a warstwą centralną systemu odbywa się poprzez dedykowaną dla systemu sieć telekomunikacyjną.

4. Dane przesyłane pomiędzy warstwą centralną systemu CEPiK a serwerem podmiotu są szyfrowane/deszyfrowane z wykorzystaniem urządzeń specjalizowanych.

Dla użytkowników współpracujących z systemem CEPiK według interfejsu podmiotowego Dostawca jest zobowiązany do:

• Opracowania i wdrożenia aplikacji o funkcjonalności jw. dla warstwy centralnej.

• Opracowania i wytestowania aplikacji o funkcjonalności jw. dla podmiotu.

• Dostawy i instalacji serwera dla podmiotu i Intelowych stanowisk końcowych.

Aplikacja dla podmiotu, środowisko software'owe, serwer i stanowiska końcowe są - po przeprowadzeniu testów - przekazywane podmiotowi, który jest odpowiedzialny za ich eksploatację.

Zastosowanie interfejsów

Interfejsy będą przypisywane funkcjom realizowanym przez podmioty a nie podmiotom. Może to oznaczać, że ustalony podmiot będzie współpracował z systemem CEPiK w oparciu o trzy różne interfejsy.

Zamawiający zakłada, że:

1. Interfejs rozproszony będzie miał zastosowanie:

1. w kontaktach z podmiotami, o których mowa w 5.2.1. Obsługa ewidencji pojazdów w powiatach i innych podmiotach zobowiązanych ustawowo

2. przy obsłudze współpracy z podmiotem odpowiedzialnym za utrzymanie katalogów marek i typów pojazdów

Przewiduje się, że zastosowanie tego interfejsu będzie dotyczyć około 2800 stanowisk.

2. Interfejs centralny będzie miał zastosowanie dla obsługi współpracy z podmiotami, które będą zadawać do systemu CEPiK pytania w trybie automatycznym oraz dostarczają dane do CEPiK (Policja, Żandarmeria Wojskowa, Inspekcja Transportu Samochodowego, Straż Graniczna).

3. Interfejs podmiotowy będzie miał zastosowanie w kontaktach z podmiotami rejestrującymi pojazdy specjalne (Policja, Dowództwo Wojsk Lądowych, Straż Graniczna, Agencja Bezpieczeństwa Wewnętrznego, Agencja Wywiadu, Biuro Ochrony Rządu). Zamawiający przewiduje, że ze względu na specyfikę wyspecyfikowanych podmiotów, Dostawca opracuje i wdroży jeden interfejs dla ww podmiotów poza podmiotem uprawnionym do obsługi pojazdów operacyjnych (patrz: rozdział 5.2.10. Obsługa pojazdów specjalnych) i drugi - dla tego podmiotu.

Zamawiający wymaga, aby we wszystkich rodzajach interfejsów możliwe było wprowadzanie, kodowanie i prezentacja wielonarodowych znaków diakrytycznych, wywodzących się z alfabetu łacińskiego, zgodnie z normami ISO (UFT-8 lub UNIKOD).

1. Bezpieczeństwo systemu

Wymagania dotyczące bezpieczeństwa systemu zostały zawarte w wydzielonym dokumencie pt. Error! Reference source not found.. do niniejszego opracowania.

2. Wydajność, ergonomia i wolumetria systemu

Niniejsza sekcja zawiera informacje charakteryzujące wielkość obciążenia systemu przetwarzaniem oraz składowaniem danych, jak również wymagania dotyczące czasów trwania realizacji różnych funkcji systemu.

Obciążenie systemu

Liczba końcówek użytkowników

Zakłada się, że w skład systemu będą wchodzić stanowiska użytkowników w następujących ilościach:

• 2800 końcówek w wydziałach komunikacji starostw, w punkcie rejestracyjnym wojewody mazowieckiego i w dzielnicach warszawskich,

• 120 końcówek w instytucjach prowadzących ewidencję pojazdów specjalnych,

• 50 końcówek w MSWiA,

• po 20 końcówek użytkowników w Centrum Podstawowym i w Centrum Zapasowym.

Obsługa ewidencji pojazdów w powiatach

Poniższa tabelka prezentuje analizę oczekiwanego obciążenia centrali systemu wsparciem procesu obsługi ewidencji pojazdów realizowanego w powiatach.

ewidencja pojazdów w powiatach
Liczba wydawanych kart pojazdu w ciągu roku [szt.]	530 000,00
Liczba rejestrowanych pojazdów w ciągu roku [szt.]	2 900 000,00
Liczba pozwoleń czasowych w ciągu roku [szt.]	1 200 000,00
Liczba wydanych tablic rejestracyjnych w ciągu roku [szt.]	1 500 000,00
Liczba ewidencjonowanych badań technicznych w ciągu roku [szt.]	10 000 000,00
Łączna liczba czynności w ciągu roku [szt.]	16 130 000,00
Liczba wykonywanych czynności dziennie [szt.]	64 520,00
Przeciętna liczba odwołań do warstwy centralnej systemu (transakcji) na czynność [szt.]	8,00
Dane przesyłane przy jednym odwołaniu (w obie strony) [kB]	4,00
Średnie obciążenie sieci [kB/s] (8 godzin pracy)	71,69
Liczba wywołań (transakcji)/min w centrali [tpm] (8 godzin pracy)	1 075,33

Tabela 6 Ewidencja pojazdów w powiatach — szacowane obciążenia centrali systemu.

Obsługa ewidencji kierowców w powiatach

Poniższa tabelka prezentuje analizę oczekiwanego obciążenia centrali systemu wsparciem procesu obsługi ewidencji kierowców realizowanego w powiatach.

ewidencja kierowców w powiatach
Liczba wymian praw jazdy na nowe w ciągu roku (do 2006) [szt.]	3 500 000,00
Liczba innych czynności w ciągu roku [szt.]	2 000 000,00
Łączna liczba czynności	5 500 000,00
Liczba wykonywanych czynności dziennie [szt.]	22 000,00
Liczba odwołań systemu „Kierowca” do sytemu CEPiK na czynność [szt.]	7,00
Dane przesyłane przy jednym odwołaniu (w obie strony) [kB]	4,00
Średnie obciążenie sieci [kB/s] (8 godz.)	21,39
Liczba wywołań/min [tpm] (8 godz)	320,83

Tabela 7 Ewidencja kierowców w powiatach — szacowane obciążenia centrali systemu.

Ewidencja polis OC

Poniżej prezentowana jest analiza obciążenia systemu wynikającego z ewidencji polis OC, przy założeniu jej fizycznego prowadzenia w CEPiK.

ewidencja polis OC (przy założeniu „fizycznej” ewidencji OC w CEPiK)
Liczba zawieranych ubezpieczeń/rok [szt.]	15 000 000,00
Liczba zawieranych ubezpieczeń/dzień [szt.]	60 000,00
Rozmiar przesyłanych danych/ubezpieczenie [kB]	6,00
Łączny dzienny rozmiar danych [MB]	351,56
Czas przesyłania danych [h]	8,00
Średnie obciążenie sieci [kB/s]	12,50
Liczba zapisów (transakcji)/minutę [tpm]	125,00

Tabela 8 Ewidencja polis OC — szacowane obciążenia centrali systemu.

Naliczanie podatku od środków transportu

Poniżej przedstawiona jest analiza obciążenia systemu produkcją CD-ROM-ów z danymi potrzebnymi do naliczania podatków od środków transportu. Ze względu na to, że operacje ekstrakcji danych realizowane są w sposób nietransakcyjny i odbywają się bezpośrednio w środowisku odpowiednich baz danych, jako wielkość najlepiej charakteryzująca obciążenie procesem ekstrakcji wyliczono tempo ekstrakcji danych. Zakłada się, że operacja będzie wykonywana poza godzinami urzędowania starostw, w czasie, gdy system nie musi udostępniać usług związanych ze wsparciem obsługi ewidencji pojazdów i kierowców w powiatach.

produkcja CD-ROM-ów z danymi do naliczania podatku od środków transportu
Czas trwania ekstrakcji dla wszystkich powiatów [h] (3 weekendy)	144,00
Ogólna liczba pojazdów w kraju [szt.]	20 000 000,00
Średni rozmiar kompletu danych o pojeździe [kB]	30,00
Tempo ekstrakcji [kB/s]	1 157,41

Tabela 9 Udostępnianie informacji na poziomie powiatów — okresowa ekstrakcja danych — szacowane obciążenia centrali systemu.

Niekomercyjne udostępnianie informacji na szczeblu centralnym

Poniżej przedstawione są tabele zawierające analizę najważniejszych składników obciążenia związanego ze wsparcie procesu udostępniania informacji na szczeblu centralnym.

automatyczne udostępnianie danych na potrzeby Policji
Liczba zapytań prostych dziennie [szt.]	7 000,00
Liczba odwołań (transakcji)/jedno zapytanie [szt.]	3,00
Dane przesyłane przy jednym odwołaniu [kB]	5,00
Średnie obciążenie sieci [kB/s] (24 godziny)	1,22
Liczba wywołań (transakcji)/min [tpm] (24 godziny)	14,58
Liczba typowań dziennie [szt.]	1 000,00
Liczba typowanych pojazdów [szt.]	200,00
Dane jednego pojazdu [kB]	3,00
Średnie obciążenie sieci [kB/s] (24 godziny)	6,94
Liczba wywołań (transakcji)/min [tpm] (odczytów danych pojazdu, 24 godziny)	138,89
Łączna liczba transakcji na minutę	153,47
Łączna obciążenie sieci [kB/s]	8,16

Tabela 10 Automatyczne udostępnianie danych na potrzeby Policji — szacowane obciążenia centrali systemu.

automatyczne udostępnianie danych na potrzeby UFG (przy założeniu trybu automatycznego-dochodzeniowego)
Liczba zapytań dziennie [szt.]	60 000,00
Liczba odwołań/jedno zapytanie [szt.]	3,00
Dane przesyłane przy jednym odwołaniu [kB]	5,00
Średnie obciążenie sieci [kB/s] (8 godzin pracy)	31,25
Liczba wywołań/min [tpm] (8 godzin)	375,00

Tabela 11 Automatyczne udostępnianie danych na potrzeby UFG — szacowane obciążenia centrali systemu.

automatyczne udostępnianie danych na potrzeby UFG (przy założeniu trybu automatycznego-subskrybcyjnego)
Liczba zmian w CEP dziennie [szt.]	65 000,00
Dane przesyłane powiadomieniu o zmianie jednym odwołaniu [kB]	5,00
Średnie obciążenie sieci [kB/s] (8 godzin pracy)	11,28
Liczba transakcji/min [tpm] (8 godzin)	135,42

Tabela 12 Automatyczne udostępnianie danych na potrzeby UFG — szacowane obciążenia centrali systemu.

automatyczne udostępnianie danych na potrzeby Straży Granicznej
Liczba zapytań prostych dziennie [szt.]	10 000,00
Liczba odwołań (transakcji)/jedno zapytanie [szt.]	3,00
Dane przesyłane przy jednym odwołaniu [kB]	5,00
Średnie obciążenie sieci [kB/s] (24 godziny)	1,74
Liczba wywołań (transakcji)/min [tpm] (24 godziny)	20,83
Liczba typowań dziennie [szt.]	600,00
Liczba typowanych pojazdów [szt.]	200,00
Dane jednego pojazdu [kB]	3,00
Średnie obciążenie sieci [kB/s] (24 godziny)	4,17
Liczba wywołań (transakcji)/min [tpm] (odczytów danych pojazdu, 24 godziny)	83,33
Łączna liczba transakcji na minutę	104,17
Łączna obciążenie sieci [kB/s]	5,90

Tabela 13 Automatyczne udostępnianie danych na potrzeby Straży Granicznej — szacowane obciążenia centrali systemu.

automatyczne udostępnianie informacji dla wydz. komunikacji starostw
Liczba powiatów	380,00
Liczba prostych zapytań dziennie na przeciętny powiat [szt.]	15,00
Liczba zapytań prostych dziennie ogółem [szt.]	5 700,00
Liczba odwołań (transakcji)/jedno zapytanie [szt.]	5,00
Dane przesyłane przy jednym odwołaniu [kB]	5,00
Średnie obciążenie sieci [kB/s] (8 godz.)	4,09
Liczba wywołań (transakcji)/min [tpm] (8 godz.)	49,06
Liczba typowań dziennie na przeciętny powiat [szt.]	3,00
Liczba typowań dziennie ogółem[szt.]	942,00
Liczba typowanych pojazdów [szt.]	100,00
Dane jednego pojazdu [kB]	3,00
Średnie obciążenie sieci [kB/s] (24 godziny)	3,27
Liczba wywołań (transakcji)/min [tpm] (odczytów danych pojazdu, 24 godziny)	65,42
Łączna liczba transakcji/min [tpm]	114,48
Łączne obciążenie sieci [kB/s]	7,36

Tabela 14 Udostępnianie informacji dla wydziałów komunikacji starostw — szacowane obciążenia centrali systemu.

Dodatkowe obciążenia systemu

Zakłada się, że wszystkie nie objęte powyższymi analizami aktywności systemu, stanowią łącznie co najwyżej takie samo obciążenie, jak procesy ujęte w powyższych analizach.

Spodziewany wzrost obciążenia

Zakłada się, że do końca 2009 roku łączny wzrost obciążenia systemu nie będzie większy niż dwukrotny.

Pojemność zapasowa

Ze względu na możliwość występowania spiętrzeń o charakterze sezonowym lub związanych z porą dnia, zakłada się, że w ujęciu średnim długookresowym (np. rocznym) system powinien wykorzystywać pojemność (w sensie intensywności przetwarzania) wszystkich elementów infrastruktury dostarczanej przez Dostawcę (maszyny, dyski, urządzenia sieciowe LAN w starostwach) w stopniu nie większym niż 15% (mierzone dla każdego elementu osobno). Przy czym odnosi się to oddzielnie do obciążenia w godzinach pracy urzędów oraz poza nimi.

Charakterystyki wydajnościowe działania systemu

Czasy odpowiedzi systemu na wywołania synchroniczne (interaktywne)

W trybie komunikacji synchronicznej wymaga się od systemu szybkich odpowiedzi spełniających następujące charakterystyki czasowe:

— średni czas odpowiedzi systemu przy transakcjach nie wprowadzających zapisu do ewidencji i odnoszących się do pojedynczych obiektów (pojazdów lub kierowców) nie przekracza 5 sekund, a czas maksymalny 20 sekund - przy założeniu, że system musi obsłużyć ok. 2000 takich zapytań równocześnie,

— średni czas odpowiedzi systemu przy transakcjach wprowadzających do ewidencji zapisy dotyczące pojedynczych obiektów nie przekracza 10 sekund, a czas maksymalny 30 sekund,

— średni czas odpowiedzi dla transakcji odczytujących dane dotyczące nie więcej niż 1000 obiektów (pojazdów lub kierowców) nie przekracza 30 sekund, a czas maksymalny nie przekracza 120 sekund

Przez czas odpowiedzi systemu CEPiK rozumie się czas upływający od momentu wykonania przez użytkownika na końcówce systemu akcji wyzwalającej działanie systemu (naciśnięcie odpowiedniego do sytuacji klawisza lub kontrolki w oknie aplikacji, itp.) do momentu uzyskania oczekiwanych wyników tej akcji na końcówce użytkownika pomniejszony o czas transportu komunikatów w elementach infrastruktury nie będących przedmiotem dostaw od Dostawcy systemu oraz czas przetwarzania w systemach zewnętrznych w stosunku do systemu CEPiK (gdy dla realizacji danej akcji takie przetwarzanie jest konieczne).

Wskazane wyżej charakterystyki podyktowane są przede wszystkim potrzebą utrzymania odpowiednich wydajności procesów wspieranych przez system, wygodą użytkowników oraz potrzebami wynikającymi ze specyfiki operacyjnej działalności niektórych z nich.

Charakterystyki czasowe związane ze zlecaniem realizacji usług w trybie asynchronicznym

Czasy reakcji systemu przy operacjach przyjmowania zleceń:

— średni czas przyjęcia zlecenia asynchronicznego przetwarzania danych (komunikatu) od użytkownika, gdy zlecenie to zawiera jako parametry pojedyncze dane elementarne (do kilkunastu), nie przekracza 5 sekund, a czas maksymalny nie przekracza 20 sekund,

— średni czas przyjęcia zlecenia asynchronicznego przetwarzania danych od użytkownika, gdy zlecenie to zawiera pewien zestaw danych dotyczących pojedynczych obiektów (np. do wpisania do ewidencji) lub wzorzec wyszukiwania, obiektów nie przekracza 7 sekund, a czas maksymalny nie przekracza 25 sekund

Wskazane wyżej charakterystyki podyktowane są przede wszystkim potrzebą utrzymania odpowiednich wydajności procesów wspieranych przez system i wygodą użytkowników.

Efektywność wykorzystania zasobów ludzkich przez system CEPiK

Średni udział czasu traconego przez bezpośrednich użytkowników systemu CEPiK w oczekiwaniu na akcje ośrodków systemu CEPiK, w odniesieniu do całego ich czasu pracy (przy zastosowaniu uzgodnionej w trakcie prac projektowych organizacji pracy) nie powinien być większy niż 10%, a udział maksymalny nie większy niż 30%.

Wydajność w obszarze wsparcia obsługi klienta

System powinien posiadać wydajność taką, aby średni udział czasu realizacji akcji w systemie CEPiK (z pominięciem opóźnień w komunikacji pomiędzy stanowiskiem a ośrodkiem centralnym systemu oraz opóźnień wynikających z oczekiwania na działania zewnętrznych systemów) w całym czasie obsługi klienta nie przekraczał 2 minut lub10%, a maksymalny nie przekraczał 10 minut lub 30%.

Ergonomia interfejsów użytkownika systemu CEPiK

Interfejsy użytkownika systemu CEPiK powinny umożliwiać osiągnięcie następujących poziomów wydajności i jakości wprowadzania informacji:

— średni czas wprowadzania danych (przez dobrze przeszkolonego i doświadczonego w pracy z daną aplikacją systemu użytkownika) powinien być nie większy niż czas wpisywania tych samych danych do edytora tekstu na komputerze osobistym (z zachowaniem ustalonej postaci formularza),

— średnia liczba błędów wprowadzania danych (przez użytkownika j.w.) powinna być nie wyższa niż średnia liczba błędów wpisywania tych samych danych do edytora tekstu na komputerze osobistym (przy zachowaniu ustalonej postaci formularza i bez stosowania słowników).

Wolumetria baz danych

Ewidencja pojazdów

Poniższa tabela przedstawia informacje wolumetryczne dot. danych składowanych w centralnej ewidencji pojazdów (bez uwzględnienia indeksów):

ewidencja pojazdów — stan początkowy
Obecna liczba pojazdów [szt.]	16 000 000,00
Średni czas „życia” pojazdu (w obecnym stanie ewidencji) [lat]	10,00
Średnia liczba badań technicznych/pojazd [szt.]	7,00
Średnia liczba umów OC na pojazd [szt.]	10,00
Średnia liczba innych zdarzeń na pojazd [szt.]	7,00
Średni rozmiar danych o zdarzeniu [kB]	2,00
Łączny obecny rozmiar danych [MB] (razem z OC)	750 000,00
Łączny obecny rozmiar danych [MB] (bez OC)	437 500,00
ewidencja pojazdów — roczny przyrost
Liczba rejestrowanych polis OC na rok [szt.]	15 000 000,00
Liczba innych zdarzeń na rok [szt.]	16 000 000,00
Średni rozmiar danych o zdarzeniu [kB]	2,00
Łączny przyrost danych w CEPiK na rok [MB] (łącznie z OC)	60 547,00
Łączny przyrost danych w CEPiK na rok [MB] (bez OC)	31 250,00

Tabela 15 Szacowana wielkość danych systemu — ewidencja pojazdów.

Ewidencja kierowców

Poniżej przedstawione są informacje wolumetryczne dot. danych o kierowcach.

ewidencja kierowców — stan początkowy
Obecna liczba zapisów w systemie „Kierowca” [szt.]	7 000 000,00
Średni rozmiar danych o zdarzeniu [kB]	2,00
Łączny rozmiar początkowy ewidencji kierowców [MB]	13 672,00
ewidencja kierowców — przyrost roczny do 2006r
Liczba zdarzeń na rok [szt.]	5 500 000,00
Średni rozmiar danych o zdarzeniu	2,00
Łączny przyrost danych rocznie [MB]	10 742,00
ewidencja kierowców — przyrost roczny po 2006r
Liczba zdarzeń na rok [szt.]	2 000 000,00
Średni rozmiar danych o zdarzeniu	2,00
Łączny przyrost danych rocznie [MB]	3 906,00

Tabela 16 Szacowana wielkość danych systemu — ewidencja kierowców.

Ewidencja pojazdów specjalnych

Zakłada się, że rozmiar informacji o pojazdach specjalnych nie przekroczy 10% rozmiaru informacji o pojazdach cywilnych.

Dane systemu sterowania przepływem pracy

W niektórych obszarach działania w zakresie systemu znajduje się sterowanie przepływem pracy w procesach urzędowych. Związane jest to z koniecznością ewidencji zdarzeń związanych z przebiegiem tych procesów w odpowiednim obszarze danych systemu CEPiK. Inicjalny rozmiar danych systemu sterowania przepływem pracy jest zerowy. Spodziewany roczny przyrost tych danych jest porównywalny do rocznego przyrostu danych o pojazdach (nie przewiduje się archiwizacji tych danych). Konkretne rozmiary mogą być silnie zależne od przyjętych rozwiązań technicznych.

Dane referencyjne

W zależności od przyjętych metod pozyskiwania danych referencyjnych (szczegółowe decyzje w trakcie trwania projektu) może być wymagane składowanie w systemie replik rejestrów PESEL, NIP, REGON i TERYT. Szacowane rozmiary początkowe i przyrosty roczne tych danych podano poniżej:

— PESEL — rozmiar inicjalny ok. 25GB, roczny przyrost ok. 200MB,

— REGON — rozmiar inicjalny ok. 3GB, roczny przyrost ok. 200MB,

— TERYT — rozmiar inicjalny ok. 100MB, brak rocznego przyrostu.

W ew. replikach rejestrów system CEPiK utrzymuje jedynie aktualny stan rejestru (nie składuje historii zmian jego zawartości).

1. Koszty utrzymania systemu

Wymaga się, aby wykorzystywane w konstrukcji systemu sprzęt i oprogramowanie, były licencjonowane w sposób zapewniający:

— brak konieczności ponoszenia kosztów opłat licencyjnych lub innych opłat za używanie sprzętu lub oprogramowania po przejęciu systemu przez Zamawiającego (z zachowaniem wersji oprogramowania przekazanego),

• brak konieczności ponoszenia dodatkowych kosztów opłat licencyjnych związanych ze zwiększeniem liczby końcówek systemu, liczby zarejestrowanych lub równoczesnych użytkowników czy też zwiększeniem obciążenia systemu innych niż ew. koszty licencji oprogramowania systemowego tych końcówek (przy założeniu braku innych zmian w infrastrukturze systemu, ani zmian w jego architekturze)

1. Koncepcja techniczna systemu

Niniejszy rozdział w sposób ogólny przedstawia koncepcję techniczną, wg której budowany będzie system CEPiK. Omówione są w nim poszczególne komponenty systemu oraz ich rola w realizacji funkcji systemu.

Strategiczne kierunki rozwoju systemu CEPiK związane są z integracją europejską oraz z rozwojem inicjatyw typu e-government. Konieczne zatem jest wykorzystanie w konstrukcji systemu koncepcji technicznej czyniącej system łatwym w rozbudowie o mechanizmy integracji z instytucjami europejskimi czy też kanały B2B/B2C.

Proponowana architektura uwzględnia zalecenia Komisji Europejskiej (Architecture Guidelines for Trans—European Telematics Networks for Administrations, ver. 6.1, http://www.europa.eu.int/ispo.ida), co ułatwi późniejszy rozwój zbudowanego systemu w kierunku współpracy z instytucjami Unii Europejskiej i jej państw członkowskich.

Istotnym i krytycznym z punktu widzenia celów systemu założeniem architektury systemu jest postulat składowania wszelkich trwałych danych systemu (takich, których trwałość wykracza poza jedną sesję użytkownika lub sesję współpracy pomiędzy systemami) w centralnych ośrodkach systemu.

W skład architektury systemu wchodzą następujące komponenty:

— infrastruktura integracyjna systemu obejmująca:

— broker integracyjny,

— system sterowania procesem (Business Process Manager),

— serwer usług,

— portale,

— ewidencja pojazdów,

— ewidencja kierowców,

— baza danych referencyjnych,

— system analityczno-raportowy,

— baza migracyjna,

— system bezpieczeństwa.

Rola i sposób współpracy powyższych składników architektury systemu opisana jest w dalszej części dokumentu.




Diagram Ogólna koncepcja architektury systemu realizacji funkcji objętych zakresie funkcjonalnym systemu zgodnie z zamieszczoną w innym miejscu dokumentu specyfikacją funkcji.

1. Infrastruktura integracyjna

Infrastruktura integracyjna jest centralnym elementem systemu, steruje ona pracą całego systemu. Składa się ona z trzech zasadniczych komponentów:

— broker integracyjny,

— system sterowania procesem,

— serwer usług.

Podział ten jest umowny i w zależności od konkretnych rozwiązań technicznych może on być mniej lub bardziej wyraźny. Np. możliwe są rozwiązania, w których te trzy składniki realizowane są z wykorzystaniem oddzielnych narzędzi (być może nawet pochodzących od różnych dostawców), jak również rozwiązania, w których mamy jeden komponent pełniący funkcje wszystkich trzech pozostałych.

Broker integracyjny

Broker integracyjny:

— steruje komunikacją pomiędzy pozostałymi komponentami systemu,

— koordynuje transakcje,

— umożliwia bezpośrednie „wpięcie” zewnętrznych systemów.

Broker integracyjny stanowi centrum komunikacji wewnątrz systemu. Wszystkie komunikaty oraz wywołania usług pomiędzy pozostałymi komponentami systemu odbywają się za pośrednictwem brokera. Oznacza to, że żaden z komponentów nie komunikuje się bezpośrednio z żadnym innym, wszystkie komunikaty i wywołania usług kieruje do brokera (poza wyjątkami, które będą wskazane w dalszej części dokumentu). Po otrzymaniu takiego komunikatu lub wywołania usługi broker decyduje gdzie go skierować oraz dokonuje ew. transformacji komunikatu lub wywołania na postać odpowiednią dla komponentu, do którego komunikat lub wywołanie powinno trafić. Zadaniem brokera integracyjnego jest również koordynacja transakcji rozproszonych pomiędzy poszczególnymi komponentami systemu.

System sterowania procesem (Business Process Manager)

System sterowania procesem:

— przechowuje definicje procesów wspieranych przez system,

— przechowuje i udostępnia informacje (stan, dane, dokumenty) związane z konkretnymi sprawami,

— steruje przebiegiem procesów, kieruje poszczególne zadania do realizacji przez poszczególne osoby,

— kieruje zadania automatyzowane do automatycznej realizacji przez serwer usług.

System sterowania procesem przechowuje definicje procesów wspieranych przez CEPiK oraz ich instancje wraz ze wszystkimi potrzebnymi danymi i dokumentami elektronicznymi związanymi z taką instancją. Śledzi przebieg pracy w poszczególnych instancjach procesów, aktywuje poszczególne kroki procesów, kieruje je do wykonania automatycznego przez serwer usług lub ręcznego przez konkretne osoby. Udostępnia za pośrednictwem brokera informacje o stanie procesów, ich dane i dokumenty. Zawiera również odpowiednie narzędzia do definiowania procesów.

Serwer usług

Serwer usług:

— realizuje w pełni zautomatyzowane kroki procesów,

— realizuje logikę biznesową dla aplikacji systemu,

— realizuje te usługi systemu, które udostępniane są systemom zewnętrznym w trybie synchronicznej komunikacji (tj. są w pełni automatyczne i wymagają natychmiastowej odpowiedzi systemu).

Serwer usług jest komponentem systemu, który (za pośrednictwem brokera) udostępnia usługi przeznaczone do realizacji automatyzowanych kroków procesów, do realizacji logiki aplikacji systemu oraz do realizacji on-line usług systemu. Usługi udostępniane przez serwer usług wywoływane będą przez system sterowania procesem lub przez aplikacje osadzone w portalu.

2. Portale

Portale są komponentami systemu, za pośrednictwem których następuje komunikacja systemu z otoczeniem tj. z użytkownikami oraz z systemami zewnętrznymi. W skład systemu wchodzić będą wymienione niżej portale, które mogą być oddzielnymi portalami lub też stanowić części tego samego portalu.

Portal G2G

Użytkownicy

Za pomocą tego portalu system komunikuje się z innymi organami administracji publicznej:

— urzędnikami starostw,

— pracownikami innych organów administracji publicznej,

— systemami komputerowymi eksploatowanymi przez inne organy administracji publicznej.

Usługi

Portal G2G udostępnia następujące usługi:

— aplikacje organizujące pracę oraz wspomagające użytkowników w realizacji poszczególnych zadań w procesach wspieranych przez system,

— usługi systemu CEPiK udostępniane bezpośrednio przez system innym organom administracji,

— wysyłanie i odbieranie komunikatów do/z innych systemów (wg potrzeb wynikających z zakresu systemu),

— aplikacje służące do wprowadzania do systemu plików z danymi przez zobowiązane do tego przepisami organa administracji publicznej (wg potrzeb wynikających z zakresu systemu oraz ustalonych z zewnętrznymi instytucjami sposobów dostarczania danych).

Kanały komunikacji

Portal G2G w udostępnia usługi systemu CEPiK za pośrednictwem dedykowanej do tego celu niepublicznej sieci PESEL-NET (dla starostw) oraz za pośrednictwem dedykowanych łączy telekomunikacyjnych (dla innych organów administracji) przy pomocy protokołów stosu TCP/IP.

Dostęp użytkowników do aplikacji odbywa się za pośrednictwem stanowisk wyposażonych w przeglądarki WWW. Portal G2G współpracuje również z drukarkami znajdującymi się w lokalizacjach, w których pracują jego użytkownicy. Dopuszczalnym rozwiązaniem jest również taka konstrukcja portalu, która przewiduje obecność pewnego dodatkowego oprogramowania (ponad to, co wymagane jest na stanowisku użytkownika) w lokalizacji, w której znajdują się użytkownicy systemu, z zachowaniem warunku, że wszystkie trwałe dane składowane są w centrali systemu CEPiK (żadnych trwałych danych w zdalnych lokalizacjach systemu).

Portal komunikuje się z innymi systemami zewnętrznymi w formacie XML przy pomocy protokołów SMTP i/lub HTTP (zgodnie z zaleceniami IDA). W przypadku konieczności wymiany bardzo dużych plików danych (np. przesyłania aktualizacji rejestru państwowego takiego jak PESEL czy REGON) wykorzystywany będzie protokół FTP (również zgodnie z zaleceniami IDA).

W przyszłości portal G2G będzie rozszerzany o kolejne kanały komunikacji (np. sieci teleinformatyczne wykorzystywane przez organa administracji Unii Europejskiej).

Portal G2E

Użytkownicy

Użytkownikami portalu G2E są pracownicy spółki utrzymującej, rozwijającej CEPiK oraz ew. oddelegowani do pracy w przy obsłudze systemu urzędnicy państwowi.

Usługi

Portal G2E udostępnia swoim użytkownikom aplikacje niezbędne do realizacji ich zadań (wg potrzeb wynikających z zakresu systemu oraz przyjętych procedur działania, np. aplikacje dla serwisu, aplikacje służące do generacji standardowych raportów i monitorowania systemu, aplikacje wspomagające realizację pewnych zadań związanych z migracją danych, itp.).

Kanały komunikacji

W minimalnym zakresie systemu usługi portalu G2E dostępne będą wyłącznie w wewnętrznej sieci CEPiK na terenie ośrodków centralnych CEPiK. W przyszłości mogą się pojawić również inne kanały dostępu (wg potrzeb).

Portal G2B

Podana niżej charakterystyka opisuje pewne cechy planowanego portalu G2B.

Użytkownicy

Portal G2B będzie wykorzystywany do współpracy CEPiK z podmiotami gospodarczymi uczestniczącymi w jakiś sposób w obrocie pojazdami podlegającymi ewidencji w CEPiK, dotyczyć to może przykładowo takich podmiotów jak:

• stacje diagnostyczne,

• złomowiska,

• producenci,

• pośrednicy (komisy, giełdy, dealerzy),

• importerzy,

• podmioty uprawnione do wydawania zaświadczeń ADR,

• zakłady ubezpieczeń,

• banki.

Usługi

Zakres współpracy użytkowników z portalem, będzie zależał od roli konkretnych użytkowników w procesach związanych z obrotem pojazdami i może polegać na:

— udostępnianiu przez CEPiK pewnych informacji dla podmiotu,

— udostępnianiu lub wprowadzaniu przez podmiot gospodarczych pewnych informacji dla CEPiK,

— uczestnictwa danego podmiotu w procesach wspieranych i sterownych przez system (tj. realizacja pewnych kroków w takich procesach).

Kanały komunikacji

Portal G2B będzie korzystał z różnorodnych kanałów komunikacji dostosowanych do możliwości i specyfiki poszczególnych użytkowników.

Portal G2C

Użytkownicy

Użytkownikami portalu G2C będą wszyscy obywatele i mieszkańcy kraju oraz podmioty gospodarcze korzystające z usług administracji publicznej w zakresie ewidencji pojazdów i kierowców.

Usługi

Portal G2C docelowo będzie udostępniał wszelkie usługi administracji publicznej w zakresie ewidencji pojazdów i kierowców. Za jego pomocą będzie możliwe m.in. załatwienie wszystkich (lub większości) spraw, które w chwili obecnej załatwiane są w wydziałach komunikacji startostw. Portal ten powinien obsługiwać procedury prerejestraycjne i procedury sprawdzenia przez właściciela danych o jego pojeździe. Szczegóły wymaganej przez zamawiającego procedury sprawdzenia danych o pojeździe będą opracowane w trakcie prac projektowych.

Kanały komunikacji

Jako że portal G2C przewidziany jest jako sposób na maksymalne ułatwienie i zapewnienie wygody dostępu do usług administracji publicznej, będzie on docelowo korzystał z bardzo wielu i bardzo różnorodnych kanałów komunikacji, wykorzystując potencjalnie wszystko, co współczesna (i przyszła) technologia w tym zakresie oferuje.

1. Ewidencja pojazdów

Komponent architektury odpowiedzialny za gromadzenie udostępnianie i aktualizację danych dotyczących pojazdów. Składa się on z:

— bazy danych o pojazdach,

— adaptera udostępniającego usługi odczytu i zapisu danych,

— procedur masowego ładowania danych z bazy migracyjnej,

— procedur ekstrakcji danych dla systemu analityczno-raportowego.

Zasadniczym elementem ewidencji pojazdów jest sama baza danych przechowująca zawartość ewidencji. Cechą proponowanej architektury jest brak bezpośredniego dostępu do zawartości tej bazy danych dla innych komponentów systemu. Wszelki dostęp odbywa się z wykorzystaniem usług udostępnianych przez adapter lub też ew. z wykorzystaniem procedur masowego ładowania i ekstrakcji danych (masowe ładowania i ekstrakcja danych są wyjątkami od ogólnej reguły komunikacji wewnątrz systemu wyłącznie poprzez brokera).

Zadaniem adaptera jest udostępnianie usług zapisu i odczytu danych o pojazdach z zapewnieniem bezpieczeństwa i integralności danych oraz obsługą transakcji. Z usług tych (za pośrednictwem brokera) korzystają komponenty implementujące usługi serwera usług.

Zadaniem procedur masowego ładowania i ekstrakcji danych jest dostarczenie wydajnego i bezpiecznego (w tym ze względu na integralność danych) sposobu zapisywania i odczytu dużych ilości danych z/do bazy danych o pojazdach.

2. Ewidencja kierowców

Komponent architektury odpowiedzialny za gromadzenie udostępnianie i aktualizację danych dotyczących kierowców. Składa się on z:

— bazy danych o kierowcach,

— adaptera udostępniającego usługi odczytu i zapisu danych,

— procedur masowego ładowania danych z bazy migracyjnej,

— procedur ekstrakcji danych dla systemu analityczno-raportowego.

Zasadniczym elementem ewidencji kierowców jest sama baza danych przechowująca zawartość ewidencji. Cechą proponowanej architektury jest brak bezpośredniego dostępu do zawartości tej bazy danych dla innych komponentów systemu. Wszelki dostęp odbywa się z wykorzystaniem usług udostępnianych przez adapter lub też ew. z wykorzystaniem procedur masowego ładowania i ekstrakcji danych (masowe ładowania i ekstrakcja danych są wyjątkami od ogólnej reguły komunikacji wewnątrz systemu wyłącznie poprzez broker).

Zadaniem adaptera jest udostępnianie usług zapisu i odczytu danych z zapewnieniem bezpieczeństwa i integralności danych oraz obsługą transakcji. Z usług tych (za pośrednictwem brokera) korzystają komponenty implementujące usługi serwera usług.

Zadaniem procedur masowego ładowania i ekstrakcji danych jest dostarczenie wydajnego i bezpiecznego (w tym ze względu na integralność danych) sposobu zapisywania i odczytu dużych ilości danych z/do bazy danych.

3. Baza danych referencyjnych

Komponent architektury systemu służący do gromadzenia danych, które:

— nie wchodzą w skład ewidencji pojazdów lub kierowców,

— pochodzą z zewnętrznych źródeł,

— nie są udostępniane przez źródła w sposób automatyczny w trybie odpowiednim do potrzeb systemu CEPiK (lub też ze względu na parametry techniczne, wydajności, bezpieczeństwa lub niezawodności nie mogą być w ten sposób wykorzystywane).

Typowo dane referencyjne zawierają sporządzoną wg potrzeb systemu kopię (replikę) części danych z rejestrów państwowych (np. PESEL, REGON).

Baza danych referencyjnych jako komponent architektury składa się z:

— bazy danych zawierającej dane referencyjne,

— adaptera udostępniającego usługi dostępu to tych danych innym komponentom systemu,

— ew. procedur ekstrakcji danych do systemu analityczno-raportowego (wg potrzeb),

— ew. procedur masowego ładowania danych (wg potrzeb).

Zasadniczym elementem jest sama baza danych. Żaden inny komponent architektury nie ma bezpośredniego dostępu danych referencyjnych. Wszelki dostęp odbywa się za pomocą adaptera lub procedur masowego ładowania i ekstrakcji danych.

Zadaniem adaptera jest udostępnianie usług dostępu do danych referencyjnych, przy czym w zależności od danych usługi odczytu mogą być ograniczone tylko do weryfikacji zgodności danych. Usługi zapisu danych udostępniane są w odniesieniu do danych podlegających ciągłej aktualizacji na podstawie komunikatów otrzymywanych z zewnętrznych systemów.

Procedury masowego ładowania danych służą do aktualizacji danych referencyjnych tych, które podlegają okresowej aktualizacji. Dane te są w czasie takiej aktualizacji w sposób masowy ładowane albo z zewnętrznych nośników (dostarczonych nie elektronicznymi kanałami) albo z plików dostarczonych przez portal (jest to kolejny wyjątek od reguły komunikacji wyłącznie za pośrednictwem brokera integracyjnego).

Procedury ekstrakcji danych odgrywają analogiczną rolę jak procedury ekstrakcji danych z ewidencji pojazdów lub kierowców.

4. System analityczno-raportowy

System analityczno raportowy jest komponentem architektury służącym do analizy danych zgromadzonych w systemie, do sporządzania raportów o charakterze statystycznym oraz innych niestandardowych zapytań. Komponent będzie wykorzystywany przede wszystkim dla wsparcia procesów udostępniania informacji oraz procesów wykrywania i analizy nieprawidłowości.

Zasadniczym składnikiem systemu analityczno-raportowego jest zestaw analitycznych baz danych (w zależności od przyjętych szczegółowych rozwiązań i potrzeb mogą one odpowiadać pewnym warstwom i/lub obszarom tematycznym). Analityczne bazy danych zawierają „kopie” danych systemu, które mogą różnić się od oryginału pod następującymi względami (w zależności od potrzeb i zastosowanych szczegółowych rozwiązań):

— strukturą danych, która w systemie analityczno-raportowym optymalizowana jest pod kątem potrzeb analiz i raportowania statystycznego,

— poziomem agregacji,

— zawartością (pewne dane mogą być odpersonalizowane, przekodowane na potrzeby specyficznych metod analitycznych itp.),

— aktualnością (dane w bazach analitycznych nie muszą być bardzo aktualne, w zależności od potrzeb konkretne dane mogą być wg stanu z poprzedniego dnia, sprzed tygodnia, miesiąca czy nawet roku).

Dodatkowo w systemie analityczno raportowym stosowane są odmienne metody dostępu do danych oraz inne metody zapewnienia ich bezpieczeństwa.

Poza analitycznymi bazami danych w skład systemu analityczno raportowego wchodzi system zasilania, którego zadaniem jest zapewnienie wymaganej (wg potrzeb) aktualności danych w bazach analitycznych. System zasilania otrzymuje dane z innych komponentów systemu za pośrednictwem ekstraktów produkowanych przez te komponenty (wyjątek od zasady komunikacji za pośrednictwem brokera).

W środowisku systemu analityczno-raportowego eksploatowane są zawansowane aplikacje analityczne, tj. aplikacje wykorzystywane do produkcji niestandardowych raportów lub wykonywania analiz i raportów z wykorzystaniem zawansowanych metod analizy danych (matematycznych, statystycznych, neuronowych, metod inżynierii wiedzy, itp.), aplikacje implementujące procesy automatycznego wykrywania nieprawidłowości, itp. , jak również wykonywane są przez Podmiot Utrzymania niestandardowe raporty, ekstrakty danych dla zewnętrznych systemów i inne zadania, które nie wymagają bardzo aktualnych danych, a których realizacja w środowisku baz danych ewidencji, mogłaby zakłócić działanie innych funkcji systemu.

Proste aplikacje analityczne (np. standardowe raporty) mogą być również udostępniane przez portale systemu. Na potrzeby aplikacji tego typu system analityczno-raportowy udostępnia pewne usługi poprzez broker integracyjny.

5. Baza migracyjna

Baza migracyjna odpowiedzialna jest za składowanie danych pochodzących z migracji, których jakość nie pozwala na normalną eksploatację w sposób identyczny jak dane w ewidencjach pojazdów i kierowców.

Zasadniczym elementem tego komponentu systemu jest baza danych pochodzących z migracji. Ponadto w skład bazy migracyjnej wchodzi adapter udostępniający potrzebne usługi dostępu do danych.

W środowisku bazy migracyjnej Podmiot Utrzymania realizuje również przetwarzanie związane z usługami dotyczącymi migracji danych.

6. System obsługi specjalnej

System obsługi specjalnej jest całkowicie oddzielnym (na poziomie fizycznym) systemem o analogicznej architekturze jak system podstawowy (opisany wcześniej), z pominięciem komponentów nie potrzebnych z punktu widzenie zakresu wsparcia procesów obsługi pojazdów specjalnych (np. brak ewidencji kierowców), jego zadaniem jest bezpośrednie wsparcie procesów ewidencji pojazdów specjalnych. System obsługi specjalnej ma osobne wszystkie elementy infrastruktury (łącznie z osobnym przyłączeniem do dedykowanej do systemu sieci telekomunikacyjnej). Jego zadaniem jest prowadzenie ewidencji pojazdów specjalnych oraz wsparcie procesów związanych z pojazdami specjalnymi. System obsługi specjalnej ma własny portal (w tym przypadku tylko G2G) za pomocą, którego komunikuje się ze swoimi użytkownikami. Systemy obsługi specjalnej i system podstawowy również komunikują się jedynie za pośrednictwem swoich portali G2G i oraz dedykowanej do tego celu infrastruktury komunikacyjnej traktując siebie nawzajem jak zewnętrzne systemy.

7. Topologia systemu

Poniżej załączony jest rysunek pokazujący ośrodki systemu, sieci komputerowe wykorzystywane przez system, stanowiska użytkowników systemu współpracujące oraz połączenia pomiędzy nimi.




Diagram Topologia systemu CEPiK

6. Migracja danych

1. Uwarunkowania dot. danych o pojazdach

Projekt powinien uwzględniać migrację danych z systemów wojewódzkich, powiatowych i dzielnic warszawskich. Ustawa Prawo o ruchu drogowym z 20 czerwca 1997 roku, z dniem 30 czerwca 1999 roku zakończyła funkcjonowanie wojewódzkich ewidencji pojazdów. W związku z tym niektóre istniejące bazy wojewódzkie zaprzestały funkcjonowania gdyż starostwa nie miały obowiązku aktualizacji tych baz. Dopiero ustawa z 31 marca 2000 roku przywróciła funkcjonowanie wojewódzkich baz pojazdów, z obowiązkiem ich aktualizacji przez starostwa, ale nastąpiła prawie roczna przerwa i brak ciągłości danych w Wojewódzkiej Ewidencji Pojazdów (WEP). Uniemożliwia to oparcie migracji wyłącznie o źródła wojewódzkie.

2. Uwarunkowania dot. danych o kierowcach

Dane o kierowcach posiadających prawa jazdy nowego wzoru zgromadzone są w zasobach systemu „Kierowca”, eksploatowanego przez wszystkie starostwa w kraju. Migracji podlegać będą dane zgromadzone w tym systemie do chwili uruchomienia systemu CEPiK w zakresie docelowym. Dane o kierowcach, którzy do momentu produkcyjnego startu systemu w zakresie docelowym, będą jeszcze posiadać prawa jazdy starego wzoru, nie będą podlegać migracji. Wszystkie dane o tych kierowcach trafią do systemu CEPiK stopniowo w trakcie realizacji w starostwach czynności wymiany praw jazdy, do których zobowiązani są wszyscy kierowcy najpóźniej do końca roku 2004.

3. Koncepcja migracji danych o pojazdach

Migracja danych do bazy CEP powinna przebiegać w dwóch etapach:

• Etap I - migracja danych z Wojewódzkich Ewidencji Pojazdów (WEP); prowadzonych dotychczas przez Wojewodów i administrowanych przez Wojewódzkie Ośrodki Informatyki (WOI)

• Etap II - migracja danych z baz Punktów Rejestracyjnych (PR).

Założenie podstawowe:

1. Migracja danych - w każdym z etapów - ma być realizowana w oparciu o tzw. pliki migracyjne o ustalonym formacie - XML Schema.

2. Ostateczna struktura pliku, definiująca zawartość pliku migracyjnego może ulec zmianie (modyfikacji) po rozpoczęciu prac projektowych, ale powinna zostać ostatecznie uzgodniona najpóźniej do 31.10.2003 r.

3. Koncepcja zakłada uregulowania prawne zapewniające realizację zadań wskazanych w rozdziale 6.6.

4. Do czasu udostępnienia Centrum Zapasowego będzie wykonywana kopia bazy migracyjnej CEP oraz bazy operacyjnej CEP na nośniki magnetyczne/optyczne i przechowywana w ustalonym miejscu.

5. W ramach realizacji procedury awaryjnej - od 1.01.2004 r. i najpóźniej do 31.12.2004 r. - co 2 tygodnie będą przygotowywane kopie CEP (z bazy migracyjnej i operacyjnej) ograniczone do województwa (16 podzbiorów) i przekazywane do upoważnionego przez Wojewodę podmiotu, w formie plików o strukturze identycznej jak pliki migracyjne (określane dalej jako wojewódzkie pliki aktualizacyjne z CEP). Wojewódzkie pliki aktualizacyjne z CEP mają stanowić - od czasu wdrożenia co najmniej jednego starostwa (tj. PR) w danym województwie - bazę do aktualizacji przez upoważniony przez Wojewodę podmiot (UP) Wojewódzkiej Części Ewidencji Pojazdów (WCEP).

6. Suma baz WCEP (od 1.01.2004 r.) oraz rozszerzona od 1.04.2004 r. o sumę przekazanych wojewódzkich plików aktualizacyjnych z CEP do UP stanowi dodatkową kopię bezpieczeństwa, umożliwiającą od 1.01.2004 r udostępnianie danych.

7. Udzielanie informacji dla podmiotów uprawnionych (zgodnie z ich przygotowaniem technologicznym) będzie mogło odbywać się z bazy CEP i/lub z UP.

8. Pliki migracyjne inicjalne zawierają komplet posiadanych danych w WEP.

9. Pliki migracyjne kolejne zawierają dane przyrostowe w stosunku do ostatniej wersji bazy WEP/WCEP

10. Wojewódzkie pliki aktualizacyjne z CEP zawierają komplet posiadanych danych w CEP, ograniczony do tych PR województwa, które zostały wdrożone w ramach II etapu. Wojewódzkie pliki aktualizacyjne z CEP są przygotowywane odrębnie dla każdego województwa.

11. Pliki migracyjne (inicjalne, kolejne migracyjne z WCEP), pliki migracyjne z PR i wojewódzkie pliki aktualizacyjne z CEP będą przekazywane na CD.

1. Etap I - kolejne czynności i przyjęte założenia:

1. Pierwsza inicjalna migracja danych z WEP (inicjalny plik migracyjny z WEP) ze stanem na dzień 30.11.2003 r. musi być zrealizowana do 31.12.2003 r.

2. Inicjalna migracja danych obejmuje:

1. Przekazania inicjalnych plików migracyjnych do Dostawcy najpóźniej do 15.12.2003 r.

2. Zasilenia bazy migracyjnej inicjalnymi plikami migracyjnymi najpóźniej do 31.12.2003 r.

3. Zapewnienie gotowości bazy migracyjnej do przyjmowania kolejnych plików migracyjnych z UP od dnia 1.01.2004 r.

3. Od 1.01.2004 r. - zgodnie z ustalonym harmonogramem - będą przygotowywane przez UP kolejne pliki migracyjne, zawierające stan zmian, aktualny na ustalony dzień emisji w stosunku do stanu bazy WEP/WCEP po ostatniej emisji aktualizującego pliku migracyjnego, przekazywane do Dostawcy, w celu zasilenia nim bazy migracyjnej. Zakładany jest dwutygodniowy cykl przysyłania plików (zgodnie z ustalonym harmonogramem), przy czym pierwszy przysłany plik może zawierać dane zaktualizowane za okres od 1.12.2003 r. do daty pierwszego zrzutu po zrzucie inicjalnym.

4. Od czasu wdrożenia pierwszego PR w ramach województwa, UP otrzymuje pliki aktualizacyjne z CEP, których używa do aktualizacji bazy WCEP w zakresie aktualizacji tylko tych PR, które są przyłączone on-line do CEP (por. etap II).

5. Po podłączeniu on-line do CEP wszystkich PR w ramach województwa (por. etap II) UP zaprzestaje przysyłanie plików migracyjnych.

6. UP udostępnia dane z WCEP upoważnionym użytkownikom, korzystając z dotychczasowych kanałów komunikacji.

7. CEP udostępnia dane upoważnionym użytkownikom korzystając z nowych automatycznych kanałów komunikacji, jeżeli danych użytkownik jest do tego przygotowany.

8. Udostępnianie informacji w trybie urzędowym będzie odpowiedzialnością Wojewody i będzie realizowane na poziomie wojewódzkim najdłużej do 31.12.2004 r.

9. Udostępnianie informacji w trybie urzędowym z CEP będzie odpowiedzialnością ministra właściwego ds. administracji i będzie stopniowo realizowane od 1.04.2004 r.

10. Kolejne pliki migracyjne przysyłane z UP powinny zostać wczytane do bazy migracyjnej. Przy zasilaniu bazy migracyjnej CEP należy pominąć wszystkie zapisy dotyczące PR, który został już wdrożony w ramach II etapu.

11. Plik migracyjny z UP (inicjalny i kolejny) podlega kontroli przy wczytywaniu do bazy migracyjnej - według minimalnych kryteriów (ustalonych w fazie projektowej), których niespełnienie wymaga zdefiniowania procedury administracyjnej. Wynikiem kontroli będzie odpowiednie oznaczenie rekordów błędnych w bazie migracyjnej i przygotowanie raportu zawierającego wykaz tych rekordów, osobno dla każdego województwa.

12. W przypadku stwierdzenia błędów w pliku migracyjnym nadesłanym przez UP, otrzymuje on protokół (zgodnie z procedurą wskazaną w poprzednim punkcie) uzupełnioną o wykaz rekordów błędnych ze wskazaniem klasy błędu.

2. Etap II - kolejne czynności i przyjęte założenia:

1. Migracja danych z co najmniej jednego PR powinna zostać zakończona do 31.03.2004r.

2. Migracja danych z PR (czyli wdrożenie PR) obejmuje kolejno:

1. Przygotowanie pliku migracyjnego z PR w formacie zgodnym z plikiem migracyjnym z UP ze stanem na ostatni dzień roboczy poprzedzający weekend przed podłączeniem PR on-line do bazy CEP i dostarczenie do Dostawcy do końca tego dnia (do 24-ej).

2. Zasilenie bazy migracyjnej CEP plikiem migracyjnym z PR - najpóźniej do ostatniego dnia weekendu.

3. Kontrolę danych z PR i przeniesienie danych z bazy migracyjnej do bazy operacyjnej CEP - najpóźniej do ostatniego dnia weekendu.

4. Kontrola powinna uwzględniać weryfikację rekordów pod względem:

• spełnienia szczegółowych kryteriów, uzgodnionych po rozpoczęciu prac projektowych

• spójności z danymi pozyskanymi wcześniej z UP

• zgodności z rejestrami PESEL, REGON i TERYT oraz słownikami ITS.

1. Jeżeli kontrola wypadnie negatywnie, powinno nastąpić odpowiednie zaznaczenie błędnych rekordów w bazie operacyjnej CEP.

2. Podłączenie PR on-line do CEP, umożliwiające pracę na bazie operacyjnej (zgodnie ze specyfikacją zakresu wskazaną w rozdziale 5).

• Harmonogram wdrożenia jednego PR powinien uwzględniać konieczność synchronizacji czasowej danych przesłanych z UP (plik migracyjny i jego wczytanie do bazy migracyjnej) i z PR (plik migracyjny z PR) w celu zapewnienia:

1. wprowadzenia do bazy migracyjnej najbardziej aktualnych danych

2. ciągłości pracy PR od pierwszego dnia roboczego po podłączeniu PR on-line do CEP.

1. Zadania wynikające z przyjetej koncepcji

Przedstawiony niżej podział zadań ma charakter funkcjonalny. Z punktu widzenia niniejszego postępowania, za zadania Wojewody i PR odpowiada Zamawiający.

Zadania Zamawiającego:

1. Przygotowanie całości otoczenia formalno-prawnego i organizacyjnego, pozwalającego na realizację opisanej koncepcji (rozporządzenia, porozumienia z Wojewodami, itp.)

2. Nadzór nad wszystkimi uczestnikami procesu, ich dyscyplinowanie, rozwiązywanie konfliktów

3. Uzgodnienie z Dostawcą struktury plików migracyjnych oraz reguł ich poprawności i zasad kontroli

4. Uzgodnienie z Dostawcą struktury wojewódzkich plików aktualizacyjnych z CEP

5. Uzgodnienie z Dostawcą postaci raportów z informacjami o błędach w plikach migracyjnych

Zadania Dostawcy:

1. Uzgodnienie z Zamawiającym struktury plików migracyjnych oraz reguł ich poprawności i zasad kontroli

2. Uzgodnienie z Zamawiającym struktury wojewódzkich plików aktualizacyjnych z CEP

3. Uzgodnienie z Zamawiającym postaci raportów z informacjami o błędach w plikach migracyjnych

4. Utworzenie bazy migracyjnej (w zakresie danych o pojazdach)

5. Inicjalne zasilenie bazy migracyjnej zawartością inicjalnych plików migracyjnych do 31 grudnia 2003 r.

6. Przyjmowanie i wprowadzanie do bazy migracyjnej w cyklu dwutygodniowym, plików migracyjnych aktualizujących w okresie od 1 stycznia 2004 do momentu wdrożenia CEP we wszystkich punktach rejestracyjnych z uwzględnieniem następujących uwarunkowań:

1. Dane z każdego WCEP dostępne są w oddzielnym pliku migracyjnym

2. Każdy plik migracyjny, zawiera dane aktualizujące z WCEP, pochodzących z punktów rejestracyjnych, w których nie nastąpiło jeszcze wdrożenie CEP

3. Podczas przetwarzania pliku migracyjnego należy pominąć zawarte w nim informacje odnoszące się do punktów rejestracyjnych, w których został już wdrożony CEP.

4. Cały proces nie może ograniczać dostępności innych funkcji systemu lub wpływać na poprawność ich realizacji (w szczególności, funkcje wykorzystujące dane w bazie migracyjnej nie mogą działać na danych częściowo zaktualizowanych)

5. Pliki migracyjne z poszczególnych UP będą przekazywane i przetwarzane do momentu wdrożenia CEP we wszystkich punktach rejestracyjnych objętych zakresem danego województwa.

7. Produkcja plików aktualizacyjnych dla poszczególnych UP - w okresie od momentu wdrożenia CEP w pierwszym z punktów rejestracyjnych do końca 2004 roku - w cyklu dwutygodniowym, z uwzględnieniem następujących uwarunkowań:

1. Dane dla każdego UP znajdować się będą w oddzielnym pliku aktualizacyjnym

2. Plik dla konkretnego UP zawierał będzie komplet danych dla wszystkich punktów rejestracyjnych w zakresie danego województwa, w których nastąpiło wdrożenie CEP (nie więcej i nie mniej)

3. Cały proces nie może wpływać na realizację innych funkcji systemu.

4. Pliki aktualizacyjne dla poszczególnych UP będą produkowane i przekazywane od momentu wdrożenia CEP w pierwszym z punktów rejestracyjnych w zakresie danego województwa.

8. Przyjmowanie, wprowadzenie do bazy migracyjnej, a następnie przenoszenie do bazy operacyjnej CEP danych z plików migracyjnych, dotyczących konkretnych punktów rejestracyjnych, w sposób zsynchronizowany z wdrożeniem CEP w danym punkcie, z uwzględnieniem następujących uwarunkowań:

1. Plik migracyjny używany w tej sytuacji ma taką samą strukturę, jak pliki migracyjne zawierające dane z WCEP i zawiera komplet danych z danego punktu rejestracyjnego (aczkolwiek może być szerszy)

2. Podczas przetwarzania takiego pliku uwzględniane są tylko dane dotyczące danego punktu rejestracyjnego

3. Po wprowadzeniu danych do bazy migracyjnej, dane te są szczegółowo sprawdzane (na kompletność, zgodność z innymi zapisami, zgodność ze słownikami i rejestrami), a następnie przenoszone do CEP (zapisy zawierające błędy są odpowiednio oznaczane oraz produkowany jest raport z ich wykazem)

4. Całość procesu realizowana będzie w czasie weekendu, w związku z tym należy zapewnić ciągłość pracy punktu rejestracyjnego od początku następnego tygodnia oraz odpowiednią synchronizacje z procesem zasilania bazy migracyjnej z WCEP.

Zadania Wojewodów:

Zadania Wojewodów to zadania upoważnionych przez nich do realizacji niżej wymienionych prac podmiotów upoważnionych (UP).

1. Przygotowanie do 15 grudnia 2003 inicjalnych plików migracyjnych zawierających stan WEP na koniec listopada 2003 r., przy uwzględnieniu przekodowania używanych kodów na wartości (w przypadku używania słowników ITS i TERYT - kody i wartości).

2. Przygotowywanie w okresie od 1 stycznia 2004 do momentu wdrożenia CEP w ostatnim punkcie rejestracyjnym danego województwa, w cyklu dwutygodniowym, plików migracyjnych, do aktualizacji bazy migracyjną systemu i przekazywanie ich Dostawcy.

3. Przyjmowanie i wprowadzanie do WCEP w okresie od wdrożenia CEP w pierwszym z punktów rejestracyjnych w danym województwie do końca 2004 roku, w cyklu dwutygodniowym, plików aktualizacyjnych przygotowywanych przez Dostawcę.

4. Realizacja zadań związanych z udostępnianiem informacji od początku 2004 roku, do momentu przejęcia ich przez MSWiA (najpóźniej do końca 2004 roku).

Zadania Punktów Rejestracyjnych:

1. Przygotowanie pliku migracyjnego z danymi dotyczącymi danego punktu rejestracyjnego ze stanem na ostatni dzień roboczy pracy w dotychczasowym systemie i dostarczenie go dostawcy do końca tego dnia (do północy).

1. Migracja danych o pojazdach specjalnych i o kierowcach

Migracja danych o kierowcach nie jest działaniem krytycznym ze względu na uwarunkowania opisane w rozdziale 6.2. Dane będą migrowane z jednego źródła i proces tej migracji będzie dużo prostszy od procesu opisanego w rozdziale 6.3., ale musi spełniać podstawowe założenie: dane będą migrowane do bazy migracyjnej i dopiero po ich weryfikacji zostaną przeniesione do bazy operacyjnej CEK. Biorąc pod uwagę fakt, że system obsługi CEK ma być zakończony do 31.07.2004, Zamawiający oczekuje od Dostawcy propozycji budowy takiego modelu z określeniem jego architektury i zobowiązań Zamawiającego, Dostawcy i dotychczasowych posiadaczy danych o kierowcach - w terminie zabezpieczającym utrzymanie ww terminu.

Migracja danych o pojazdach specjalnych, ze względu na specyfikę tej grupy pojazdów będzie prowadzona osobno z każdego podmiotu, prowadzącego aktualnie taka ewidencję. Migracja ta będzie przedmiotem szczegółowych ustaleń w trakcie prowadzenia szczegółowych prac projektowych. Zamawiający oczekuje od Dostawcy propozycji modelu takiej migracji w przedprojektowej fazie prac. Propozycja powinna spełniać podstawowe wymaganie sprowadzające się do fizycznego wydzielenia bazy migracyjnej pojazdów specjalnych od analogicznej bazy pojazdów. Zamawiający wymaga, aby proces migracji danych zakończył się na tyle wcześnie, aby można było dotrzymać terminu wdrożenia centralnej ewidencji pojazdów specjalnych - przewidzianego na 01.01. 2005 r.

7. Wdrożenie

Niniejszy rozdział opisuje zakres prac i dostaw związanych z wdrażaniem kolejnych wersji systemu CEPiK. W ramach zamówienia realizowane będą dwa wdrożenia. Wdrożenie pierwszej wersji systemu realizującej jego zakres minimalny ma być zakończone do 31.03.2004 r. Wdrożenie drugiej wersji systemu realizującej jego zakres docelowy będzie zakończone do końca 2005 roku.

1. Infrastruktura systemu

Przez infrastrukturę systemu rozumie się, następujące elementy:

— wszelki sprzęt, osprzęt, wyposażenie, pomieszczenia i ich wyposażenie, sieci komputerowe, elementy zasilania energetycznego wykorzystywane przez system,

— wszelkie oprogramowanie systemowe, komunikacyjne, narzędziowe, sieciowe oraz middleware i platformy bazodanowe wykorzystywane przez system.

Infrastruktura systemu częściowo dostarczana jest przez Dostawcę systemu, a częściowo zapewniana przez Zamawiającego. Niniejszy rozdział opisuje w dwóch poniższych sekcjach zakres dostaw infrastruktury oczekiwanych od Dostawcy oraz specyfikuje elementy infrastruktury systemu zapewniane przez Zamawiającego. Obie strony dostarczają w ramach wdrożenia te elementy infrastruktury, które są potrzebne do eksploatacji danej wersji systemu (tj. nie wszystkie elementy infrastruktury muszą być dostarczone w ramach wdrożenia systemu w zakresie minimalnym).

1. Zakres dostaw elementów infrastruktury

Zamawiający rozróżnia dwie warstwy infrastruktury systemu CEPiK: warstwę centralna i warstwę lokalną.

Przez warstwę centralną systemu CEPiK należy rozumieć tę część systemu, która odpowiada za:

• przejmowanie danych ze starostw i innych punktów rejestracyjnych pojazdów,

• utrzymanie Centralnej Ewidencji Pojazdów i Centralnej Ewidencji Kierowców,

• współpracę z innymi rejestrami państwowymi,

• współpracę z katalogami utrzymywanymi przez Instytut Transportu Samochodowego,

• współpracę z bazami podmiotów zewnętrznych,

• udostępnianie danych podmiotom uprawnionym,

Przez infrastrukturę techniczną warstwy centralnej Zamawiający rozumie wyposażenie Centrum Podstawowego w serwery i urządzenia towarzyszące (drukarki, stacje dysków, stacje taśmowe) od których wymagać się będzie następującej funkcjonalności:

1. utrzymywanie fizycznych baz danych, w tym utrzymywanie wydzielonych baz danych pojazdów specjalnych,

2. obsługa aplikacji w warstwie centralnej, wg specyfikacji funkcjonalnej opisanej w rozdziale 5.

3. kontrola poziomów uprawnień on-line,

4. kontrola poziomów uprawnień off-line,

5. zbieranie danych ze źródeł zewnętrznych od podmiotów przekazujących je w trybie off-line,

6. obsługa komunikacji pomiędzy zasobami informacyjnymi systemu CEPiK a zasobami informacyjnymi podmiotów zewnętrznych w sytuacji, kiedy zasoby te połączone są na zasadzie „serwer <->serwer”,

7. obsługa portali G2G, G2C, G2E, G2B

8. zapewnienie bezpieczeństwa systemu i jego zasobów informacyjnych, zarówno w sensie ich integralności jak i ataków na te zasoby z otoczenia systemu, wg opisu w załączniku 4.1.

Do środowiska technicznego warstwy centralnej Zamawiający zalicza również:

1. systemy operacyjne, pozwalające na pełną współpracę serwerów centrum,

2. systemy bazodanowe do utrzymywania baz relacyjnych,

3. środowiska do obsługi procesów brokerskich,

4. środowiska narzędziowe, pozwalające na wykonywanie sortowania zbiorów, ich przeszukiwania, diagnozowania, itp.,

5. środowiska do rozwoju aplikacji w postaci generatorów programów, kompilatorów językowych, debugerów, generatorów raportów.

Zamawiający wymaga, aby wszystkie elementy wyposażenia technicznego warstwy centralnej systemu były skalowalne (wymagane zwymiarowanie) i otwarte.

Zadaniem Dostawcy w tym obszarze będzie:

1. Ustalenie konfiguracji serwerów dla warstwy centralnej.

2. Ustalenie konfiguracji urządzeń towarzyszących.

3. Ustalenie konfiguracji potrzebnych środowisk software'owych.

4. Dostawa i instalacja serwerów i urządzeń towarzyszących w Centrum Podstawowym.

5. Dostawa i zainstalowanie na serwerach oprogramowania systemowego, bazodanowego, narzędziowego i rozwojowego.

6. Pełne wyskalowanie i uruchomienie infrastruktury systemowej (SW) i hardware'owej (HW).

7. Dostawa i uruchomienie urządzeń zapewniających bezpieczeństwo zasobów informacyjnych wg zał. 4.1.

8. Dostawy i instalacje dla Centrum Zapasowego w takiej konfiguracji aby Centrum to mogło:

• przejąć obsługę funkcji realizowanych przez CP na czas usunięcia awarii CP,

• przejąć część funkcji realizowanych przez CP w przypadku przeciążenia CP wyrażającego się spadkiem wydajności o której mowa w rozdziale 5.5.3.

• realizować zadania szkoleniowe, rozwojowe i laboratoryjne.

Zamawiający informuje, że:

• Centrum Zapasowe będzie zlokalizowane w odległości około 35 km od siedziby Zamawiającego.

• Centrum Podstawowe przejściowo będzie mieścić się w obiekcie przy ul. Pawińskiego 17/21. Zamawiający zleca Dostawcy wykonanie prac adaptacyjnych obiektu według wymagań które są zawarte w Załącznik nr 4.3. -[Wymagania dot. Tymczasowego Centrum Podstawowego]do niniejszego opracowana. Docelowa lokalizacja CP to nowy obiekt przy ul. Batorego. Przygotowanie obiektu docelowego nie jest przedmiotem zamówienia.

• Prace związane z przygotowaniem budynków do pełnienia roli CZ i CP nie wchodzą w zakres niniejszego postępowania.

• Po oddaniu do użytku docelowego CP Dostawca jest zobowiązany do przeniesienia zasobów z CP tymczasowego do docelowego.

• Po oddaniu do dyspozycji Dostawcy pomieszczeń przewidzianych na Centrum Zapasowe, Dostawca będzie musiał w terminie nie późniejszym niż trzy miesiące od tego przekazania dokonać niezbędnej alokacji zasobów do Centrum Zapasowego z Centrum Podstawowego i przygotować Centrum Zapasowe do jego właściwej roli.

Obydwa centra (CP i CZ) będą połączone światłowodową magistralą telekomunikacyjną. Budowa tego połączenia nie jest przedmiotem niniejszego zamówienia.

Konfiguracja warstwy centralnej systemu musi być zgodna z architekturą systemu opisaną w rozdziale 5.6 Koncepcja techniczna systemu.

Przez warstwę lokalną systemu CEPiK należy rozumieć tę część systemu CEPiK, która odpowiada za:

1. obsługę procesów rejestracyjnych dla pojazdów i kierowców,

2. rejestrację zdarzeń związanych ze zmieniającym się statusem pojazdu lub kierowcy,

3. przygotowywanie danych źródłowych dla warstwy centralnej systemu CEPiK w przedmiotowym zakresie,

4. odbiór danych z warstwy centralnej systemu (dotyczących diagnozy wcześniej przekazanych do tej warstwy danych).

5. obsługę podmiotów współpracujących z systemem CEPiK - wg specyfikacji jak w rozdziałach 5.2. - 5.4.

Zamawiający zobowiązuje Dostawcę do realizacji następujących dostaw dla tej warstwy:

• Stanowiska PC z przeglądarkami www do obsługi rejestracji pojazdów. Ilość stanowisk powinna być dostosowana do ilości transakcji w starostwie (ilość stanowisk PC - patrz 5.5.3. Wydajność, ergonomia i wolumetria systemu). Zamawiający wymaga aby monitory stanowiskowe odpowiadały specyfikacji jak w Zał. 4.2. cz. C

• Urządzenia dostępowe do sieci LAN wydziału komunikacji starostwa do sieci WAN - wg wymagań jak w Załącznik nr 4.2. -[Wymagania techniczne] cz. A. do niniejszego dokumentu.

• Budowa gigabajtowej sieci Ethernet LAN w 50% wydziałów komunikacji starostw, dla około 1400 stanowisk (średnio po 7 stanowisk na sieć).

• Specjalizowane stanowisko do druku dowodów rejestracyjnych z możliwością druku kodu OCRB zgodnie z normą ICAO - ISO1073/II/DO -średnio 2 stanowiska na 7 stanowisk rejestracyjnych ale nie mniej niż jedno stanowisko dla punktu rejestracyjnego.

• Drukarka do innych wydruków niezbędnych do pracy punktu rejestracyjnego - jedna dla każdego punktu rejestracyjnego (laser, wydajność 10.str/min)

• Urządzenia do zabezpieczenia danych - wg wymagań sformułowanych w Załącznik nr 4.1 - [Bezpieczeństwo]

Dla obydwu warstw: centralnej i lokalnej, Dostawca ma dostarczyć aplikacje o funkcjonalności opisanej w rozdziałach 5.2. - 5.6. Aplikacje do obsługi warstwy lokalnej powinny być zainstalowane na serwerach podmiotów współpracujących z CEPiK lub na serwerach w warstwie centralnej - zgodnie z opisem interfejsów - patrz rozdział: 5.5.1. „Interfejsy z użytkownikami systemu”.

1. Infrastruktura zapewniana przez Zamawiającego

Zamawiający zapewnia Dostawcy:

• Infrastrukturę sieciową doprowadzoną do routerów brzegowych (patrz- Zał. 4.2.) wydziałów komunikacji starostw i serwerów podmiotów współpracujących, pozwalającą na eksploatację systemu CEPiK przez wszystkie wydziały komunikacji starostw - z wymaganiami wydajnościowymi opisanymi w rozdziale 5.5.3. „Wydajność, ergonomia i wolumetria systemu”-, przy założeniu, że z przewidywanego czasu na obsługę transakcji (5 sec), z czego 2 sec. to opóźnienie w ruchu po sieci (1 sec. na przekazanie danych i 1 sec. na przekazanie odpowiedzi).

• Pomieszczenia do instalacji HW/SW/NW w wydziałach komunikacji starostw,

• Połączenia serwerów warstwy centralnej systemu CEPiK z serwerami podmiotów o których była mowa przy opisie funkcjonalności i architektury systemu

• Centrum Podstawowe (CP) i Centrum Zapasowe (CZ) z pełną infrastruktura techniczną, pozwalającą na instalację sprzętu i oprogramowania.

• Połączenie telekomunikacyjne pomiędzy CP i CZ.

1. Usługi wdrożeniowe

Zakres usług wdrożeniowych obejmuje realizację następujących prac:

— instalacja dostarczanych elementów infrastruktury w dedykowanych dla nich lokalizacjach,

— instalacja wszystkich komponentów oprogramowania systemu na dedykowanych dla nich elementach infrastruktury systemu,

— umieszczenie zawartości będącej wynikiem migracji w odpowiednich bazach danych systemu,

— konfiguracja i uruchomienie całości systemu,

— konfiguracja i uruchomienie (po stronie systemu CEPiK i po stronie użytkownika) interfejsów do współpracy z użytkownikami systemami,

— wsparcie personelu obsługi zewnętrznych systemów współpracujących w zakresie uruchomienia interfejsów do systemu CEPiK,

• przeprowadzenie testów poinstalacyjnych i powdrożeniowych systemu (zgodnie z planami takich testów przygotowanymi w trakcie prac projektowych).

• Asysta wdrożeniowa we wszystkich lokalizacjach w ilości 5 osobo-dni dla lokalizacji.

1. Usługi szkoleniowe

Zakresem prac związanych z wdrożeniem systemu objęte jest przeprowadzenie szkoleń całego personelu, który w bezpośredni sposób kontaktuje się z systemem. Personel ten składa się z następujących grup osób:

— pracownicy wydziałów komunikacji starostw zajmujący się obsługą ewidencji pojazdów — 2800 osób,

— pracownicy MSWiA uczestniczący w procesach udostępniania informacji i wykrywania nieprawidłowości — 50 osób,

— pracownicy Policji, MON i innych służb uczestniczący w procesach ewidencji pojazdów specjalnych i ich ochrony przed dekonspiracją — 50 osób,

— personel, który przejmie utrzymanie systemu po 2009 roku — 10 osób,

— personel, który przejmie rozwijanie systemu po 2009 roku — 10 osób.

Cykle szkoleń użytkowników systemu towarzyszyć będą procesowi wdrożeniowemu systemu. Zakres szkoleń w ramach każdego z wdrożeń będzie dostosowany do zakresu wdrażanej wersji systemu (w szczególności w ramach pierwszego wdrożenia nie wszyscy docelowi użytkownicy systemu będą szkoleni, a ramach drugiego wdrożenia niektórzy z użytkowników będą szkoleni powtórnie w zakresie nowych elementów systemu).

1. Szkolenia dla personelu wydziałów komunikacji

Zakresem szkoleń obejmuje:

— organizację pracy z systemem,

— obsługę aplikacji systemu eksploatowanych w wydziałach komunikacji,

— postępowanie w sytuacjach awaryjnych.

Zakłada się, że osoby zgłaszające się do szkolenia, mają podstawową wiedzę i kwalifikacje związane z technologią informatyczną, na poziomie Europejskiego Komputerowego Prawa Jazdy (ECDL — European Computer Driving Licence, http://www.ecdl.com.pl/). Dostawca może przed szkoleniem kwalifikacje te w pełnym zakresie lub w pewnym obszarze sprawdzić (pod warunkiem przeprowadzania takiego egzaminu przez egzaminatorów certyfikowanych przez Polskie Biuro ECDL, http://www.ecdl.com.pl/).

Szkolenie powinno obejmować końcowy sprawdzian kwalifikacji oraz wydanie certyfikatu. W starostwach z systemu będą mogli korzystać jedynie certyfikowani użytkownicy.

2. Szkolenia pozostałych użytkowników systemu

Zakres szkoleń obejmuje:

— organizację pracy z systemem,

— obsługę aplikacji systemu eksploatowanych przez poszczególne grupy użytkowników,

— postępowanie w sytuacjach awaryjnych.

Warunki prowadzenia szkoleń analogiczne jak w przypadku szkoleń dla personelu wydziałów komunikacji. Nie mniej w MSWiA, Policji i innych służbach z systemu mogą korzystać również użytkownicy niecertyfikowani.

3. Szkolenia dla personelu przejmującego utrzymanie systemu

Zakres szkoleń obejmuje kwalifikację i wiedzę potrzebne do realizacji funkcji I i II linii wsparcia (patrz rozdział dot. usług utrzymania systemu). Szczegółowe wstępne warunki dla osób, które mają być w tym zakresie przeszkolone, zostaną uzgodnione w trakcie prac projektowych.

4. Szkolenia dla personelu przejmującego rozwój systemu

Zakres szkoleń obejmuje kwalifikacje i wiedzę potrzebne do realizacji funkcji III linii wsparcia (patrz rozdział dot. usług utrzymania systemu) oraz dalszej rozbudowy systemu. W szczególności zakresem systemu objęta jest wewnętrzna konstrukcja systemu, schematy baz danych, wewnętrzne interfejsy, itp. Szczegółowe wstępne warunki dla osób, które mają być w tym zakresie przeszkolone oraz zakres szkolenia, zostaną uzgodnione w trakcie prac projektowych.

8. Przebieg prac i organizacja przedsięwzięcia

1. Wprowadzenie

Silne ograniczenia czasowe projektu, wymagają zastosowania szczególnych środków organizacyjnych, redukujących ryzyko nie możności stworzenia na czas możliwej do wdrożenia produkcyjnego wersji systemu. Środki te obejmują następujące praktyki:

— Zastąpienie tradycyjnego, kaskadowego podejścia do wytwarzania oprogramowania, adaptacyjnym cyklem wytwórczym charakteryzującym się:

— możliwie krótką fazą wstępnej analizy, planowania architektury i planowania prac,

— szybkimi (1-2 miesięcznymi) iteracjami dostarczającymi kolejne gotowe do wykorzystania wersje produktów,

— koncentracją na wytwarzaniu oprogramowania oraz minimalizacją liczby i rozmiaru powstających dokumentów projektowych,

— budową oprogramowania z uwzględnieniem najpierw jego zasadniczych funkcji (zwykle stosunkowo prostych), a później (w dalszych iteracjach) funkcji bardziej wyrafinowanych.

— Rezygnację z wymogu tworzenia szczegółowych formalnych specyfikacji oprogramowania przed przystąpieniem do jego realizacji (zakłada się, że konkretne wymagania mogą być formułowane w trakcie prac odpowiednich zespołów i dokumentowane).

• Redukcja komunikacji „papierowej” na rzecz pracy grupowej, a zwłaszcza ograniczenie procedur tworzenia i akceptacji dokumentów przez kolejne zainteresowane strony i instytucje, na rzecz grupowego przygotowywania produktów z udziałem tych osób, które w przeciwnym wypadku (przy stosowaniu „klasycznego” podejścia) opiniowałyby dla swojej macierzystej organizacji dany produkt. Akceptacja powstającego ten sposób produktu jest uzyskiwana w momencie, gdy wszyscy członkowie zespołu zadaniowego dedykowanego do przygotowania tego produktu, będą zgodni, co do treści i formy dokumentu. Dla organizacji pracy grupowej Zamawiający zleca Dostawcy dostawę, instalację i wdrożenie systemu CIRCA, wg specyfikacji zawartej na stronie http://forum.europu.eu.int/Public/irc/ida/Home/main

— Ciągłe utrzymywanie i w razie potrzeby rewidowanie planu przedsięwzięcia (Planu projektu), jak również koncepcji i architektury systemu, planów i procedur związanych z zarządzaniem jakością, itp.

Zastosowanie wymienionych praktyk oznacza konieczność zaangażowania przez Zamawiającego znacznych zasobów (w tym również zasobów innych instytucji, od których zależy powodzenie przedsięwzięcia) oraz znaczącej elastyczności dotyczącej sposobu działania oraz angażowanych zasobów. Nie mniej ich przyjęcie jest konieczne z punktu widzenia realizacji wyznaczonych celów w narzuconym terminie.

Zgodnie z powyższymi przesłankami w pierwszej kolejności budowane będą najbardziej podstawowe funkcje systemu. W kolejnych cyklach będą one rozbudowywane o dalsze elementy zakresu docelowego systemu. Szczegółowa kolejność realizacji poszczególnych funkcji systemu będzie ustalana przez Zespół planowania i zapisywana w Planie projektu.

W tej części dokumentu opisane są oczekiwania Zamawiającego odnośnie sposobu organizacji i przebiegu prac. Zamawiający dopuszcza sytuację, w której Dostawca przedstawi własną koncepcję przebiegu prac i organizacji przedsięwzięcia.

Poniżej znajdują się rozdziały poświęcone:

— strukturze organizacyjnej projektu,

— przebiegowi prac (procesowi wytwórczemu),

— produktom powstającym w trakcie prac.

1. Struktura organizacyjna

Proponowana struktura organizacyjna projektu nastawiona jest na realizację wspomnianego wcześniej postulatu redukcji skali komunikacji przy pomocy dokumentów projektowych na rzecz bezpośredniej komunikacji w ramach prac w zespołach. Istotnymi elementami tej koncepcji są wyraźnie określone zespoły zadaniowe o mieszanym składzie (w sensie reprezentowanych w nich instytucji) tworzone wszędzie tam gdzie potrzebne jest przygotowanie produktu wymagającego uzgodnień pomiędzy wieloma zainteresowanymi stronami. Zgodnie z opisaną strategią zakłada się, że w skład takiego zespołu wchodzą wszystkie osoby, które są zainteresowane danym produktem, oraz że osoby te mają od instytucji, które reprezentują pozwolenie na podejmowanie ostatecznych decyzji dotyczących zagadnień, dla których dedykowany jest dany zespół.

Niżej wymienione i opisane są poszczególne, istotne z punktu widzenia współpracy Dostawcy i Zamawiającego elementy struktury organizacyjnej projektu. Część z nich przypisana jest do poszczególnych wątków prac, ze względu na swoją kluczową rolę w danym wątku, nie mniej niektóre z nich mimo tego pełnią role również w innych wątkach prac (dotyczy to np. Zespołu zarządzania jakością).

I tak struktury organizacyjne na poziomie ogólnym projektu obejmują:

— Komitet sterujący,

— Generalny Przedstawiciel Zamawiającego,

— Generalny Przedstawiciel Dostawcy,

— Kierownik projektu ze strony Zamawiającego,

— Kierownik projektu ze strony Dostawcy,

— Zespół planowania,

Strukturami kluczowymi dla wątku konstrukcji systemu, są:

— Zespół wykonawczy,

— Zespół użytkowników,

— Zespół zarządzania jakością,

— Zespół architektury systemu.

Strukturami kluczowymi dla wątku definicji procedur urzędowych są:

— Zespół ds. ewidencji pojazdów,

— Zespół ds. ewidencji kierowców,

— Zespoły ds. współpracy z… w zakresie….

Kluczową strukturą dla wątku migracji jest Zespół ds. migracji danych.

Struktura organizacyjna dla wątku wdrożenia powinna zostać zaproponowana przez Dostawcę.




Diagram Ogólna koncepcja schematu organizacyjnego projektu.

1. Komitet sterujący

Komitet Sterujący Projektu (KSP) jest powoływany przez kierownictwo odpowiedniego szczebla Zamawiającego oraz Dostawcy w celu sprawowania ogólnego zarządzania i nadzoru nad projektem. KSP jest całkowicie odpowiedzialny za powodzenie projektu i władny podejmować decyzje dotyczące projektu.

KSP zatwierdza wszystkie istotne plany dotyczące projektu i istotne odstępstwa od nich. KSP stwierdza zakończenie etapu projektu i wydaje zgodę na rozpoczęcie następnego etapu. Zapewnia przydział potrzebnych zasobów, rozstrzyga konflikty wewnątrz projektu i negocjuje rozwiązania problemów powstających między projektem a jego otoczeniem. Dodatkowo KSP zatwierdza nominację i zakres obowiązków Kierowników Projektu ze strony Zamawiającego oraz Dostawcy i delegacje swoich własnych obowiązków w dziedzinie nadzoru nad projektem.

KSP jest odpowiedzialny za nadzór nad projektem prowadzący do zapewnienia jego powodzenia, tj. wytworzenia i dostarczenia produktów spełniających wymagania jakościowe określone założeniami techniczno-ekonomicznymi zdefiniowanymi w Planie Projektu.

W razie potrzeby w posiedzeniach KSP mogą uczestniczyć osoby nie będące stałymi członkami KSP, w szczególności Kierownicy Projektu ze strony Zamawiającego oraz Dostawcy. Te osoby mają w KSP status obserwatorów. Decyzje mogą podejmować wyłącznie stali członkowie KSP.

Pracami Komitetu sterującego kieruje Generalny Przedstawiciel Zamawiającego.

2. Generalny Przedstawiciel Zamawiającego

Generalny przedstawiciel Zamawiającego reprezentuje interesy Zamawiającego i może podejmować decyzje w kwestiach kluczowych dla przebiegu projektu. Jest to osoba z grona naczelnego kierownictwa, odpowiedzialna przed nim za powodzenie projektu. Osoba ta:

— decyduje o przydziale zasobów pozostających w gestii Zamawiającego dla projektu,

— jest odpowiedzialna za ustanowienie celów przedsięwzięcia, określenie głównych wymagań, problemów i roli tworzonych produktów oraz wyznaczenie organizacyjnego i merytorycznego zakresu prac,

— podejmuje decyzje w kluczowych kwestiach dotyczących projektu.

3. Generalny Przedstawiciel Dostawcy

Generalny przedstawiciel Dostawcy reprezentuje interesy Dostawcy i może podejmować decyzje w kwestiach kluczowych dla przebiegu projektu. Jest to osoba posiadająca formalne uprawnienie kierownictwa Dostawcy, odpowiedzialna przed nim za powodzenie projektu. Osoba ta:

— decyduje o przydziale zasobów pozostających w gestii Dostawcy dla projektu,

— jest odpowiedzialna za ustanowienie celów przedsięwzięcia, określenie głównych wymagań, problemów i roli tworzonych produktów oraz wyznaczenie organizacyjnego i merytorycznego zakresu prac,

— podejmuje decyzje w kluczowych kwestiach dotyczących projektu.

4. Przedstawiciele resortów

W pracach Komitetu Sterującego powinni brać udział przedstawiciele pełnomocni wszystkich resortów i agencji rządowych zainteresowanych tym projektem. Szczegółowa lista tych przedstawicieli zostanie określona przez Generalnego przedstawiciela Dostawcy przed pierwszym posiedzeniem Komitetu Sterującego.

Zamawiający zobowiązuje się, że wszyscy przedstawiciele resortów delegowani do prac związanych z projektem będą w pełni dyspozycyjni, a w szczególności zadania wykonywane na rzecz projektu będą miały najwyższy priorytet.

W związku z tym niedopuszczalna jest sytuacja, w której przedstawiciel resortu nie może wykonać w terminie zadań na rzecz projektu z powodu zaangażowania w inne sprawy służbowe niezwiązane z projektem.

5. Przedstawiciele powiatów

Związek Powiatów powinien wydelegować swojego przedstawiciela pełnomocnego do prac w ramach Komitetu Sterującego.

Wszyscy przedstawiciele delegowani do prac związanych z projektem powinni być w pełni dyspozycyjni, w szczególności zadania wykonywane na rzecz projektu powinny mieć najwyższy priorytet i niedopuszczalna jest sytuacja, w której przedstawiciel powiatu nie może wykonać w terminie zadań na rzecz projektu z powodu zaangażowania w inne sprawy służbowe niezwiązane z projektem.

6. Zespół audytorski

Generalny Przedstawiciel Zamawiającego, może wykorzystywać przedstawicieli Zespołu Audytorskiego do kontroli przebiegu prac nad systemem, w szczególności audytorzy biorą udział w charakterze obserwatorów w spotkaniach wszystkich zespołów zadaniowych. Głównymi zadaniami Zespołu jest nadzór nad poprawnością przebiegu:

— prac projektowych,

— działań organizacyjnych oraz wymianą informacji pomiędzy zespołami,

— odbioru produktów projektowych,

— migracji danych,

— prac wdrożeniowych.

7. Kierownik projektu ze strony Zamawiającego

Kierownik Projektu ze strony Zamawiającego jest osobą odpowiedzialną przed Komitetem Sterującym, a w szczególności przed Generalnym przedstawicielem Zamawiającego za realizację celów.

Do jego obowiązków należą w szczególności:

— wspólne z Kierownikiem Projektu ze Strony Dostawcy zapewnienie właściwej organizacji projektu, jego planowanie oraz monitorowanie,

— zarządzanie kontaktami pomiędzy Zespołami Dostawcy i Zamawiającego,

— zapewnienie udostępnienia przez Zamawiającego zasobów niezbędnych dla realizacji projektu,

— analiza ryzyka w projekcie,

— zarządzanie zmianami,

— merytoryczny nadzór nad projektem, propozycje rozwiązań dostosowane do specyficznych potrzeb Zamawiającego,

Kierownik Projektu ze strony Zamawiającego ma do swej dyspozycji Biuro Zarządzania Projektem, w skład którego wchodzą eksperci z zakresu Zarządzania Projektem. W szczególności, Kierownik Projektu może delegować na nich zadania koordynacji danego wątku projektu. Jednocześnie podlegają mu członkowie poszczególnych Zespołów Zadaniowych ze strony Zamawiającego.

8. Kierownik projektu ze strony Dostawcy

Kierownik Projektu ze Strony Dostawcy jest przedstawicielem podmiotów realizujących projekt, odpowiedzialnym przed Generalnym Przedstawicielem Zamawiającego za wykonywanie prac w projekcie na poziomie operacyjnym.

Jest on w szczególności odpowiedzialny za:

— planowanie i kontrolę projektu we wszystkich jego obszarach,

— przydzielanie zadań członkom zespół zadaniowych,

— za terminowy przebieg projektu,

— reprezentuje Zespół Dostawcy w czasie odbioru prac.

Jednocześnie podlegają mu członkowie poszczególnych Zespołów Zadaniowych ze strony Dostawcy.

9. Zespół planowania

Zadaniem zespołu jest przygotowanie i utrzymywanie Planu projektu. W skład zespołu wchodzą:

— Kierownik projektu ze strony Zamawiającego,

— Kierownik projektu ze strony Dostawcy,

— Przedstawiciel(-e) zespołu zarządzania architekturą,

— Przedstawiciel(-e) zespołu zarządzania jakością,

— Przedstawiciel(-e) zespołów zajmujących się migracją danych,

— Przedstawiciel(-e) zespołów zajmujących się przygotowaniem i przeprowadzaniem wdrożeń,

— Kierownicy powiązanych przedsięwzięć w innych instytucjach szczebla centralnego (np. Policji, MI, UFG, PWPW),

— Przedstawiciele wydziałów komunikacji.

Prace zespołu organizowane są przez kierownika projektu ze strony Dostawcy, który odpowiedzialny jest m.in. za przygotowanie dokumentu Plan projektu i jego kolejnych rewizji.

10. Zespół zarządzania architekturą

W skład tego zespołu wchodzą architekci Dostawcy i Zamawiającego. Stanowi on wsparcie dla Kierownika Projektu w zarządzaniu projektem w zakresie: zarządzania zakresem systemu, jakością powstających produktów, śledzeniem ryzyk technicznych oraz technicznych wymagań. W przeciwieństwie do większości innych zespołów zadaniem tego zespołu jest ciągłe monitorowanie sposobu realizacji systemu oraz ocena czy przyjmowane rozwiązania są zgodne z celem i ogólną architektura systemu. Zadania zespołu obejmują:

— przygotowanie i utrzymywanie Koncepcji i architektury systemu,

— budowa i utrzymywanie modelu systemu,

— planowanie prac w wątku konstrukcji systemu (udział w okresowych rewizjach Planu projektu),

— utrzymywanie spójności produktów powstających w różnych zespołach oraz ich zgodności z architekturą i koncepcją systemu (poprzez udział w ich pracach).

Zespołem kieruje wyznaczony przedstawiciel Dostawcy.

11. Zespół zarządzania jakością

Zespół zarządzania jakością tworzony jest zespołem mieszanym tworzonym przez przedstawicieli Zamawiającego i Dostawcy. Zadania zespołu obejmują:

— utrzymywanie repozytorium błędów i ich statusów,

— definiowanie wymagań jakościowych dla poszczególnych dokumentów i produktów projektu (udział w przygotowaniu Planu projektu, w tym zakresie),

— definiowanie i utrzymywanie standardów procedur zarządzania konfiguracją, zarządzania zmianami, komunikacji (udział w przygotowaniu Planu projektu),

— dbanie o zgodność powstających produktów zatwierdzonymi wymaganiami jakościowymi (m.in. poprzez udział w pracach innych zespołów).

Prace zespołu organizują przedstawiciele Dostawcy.

12. Zespół użytkowników

Zespół ten tworzą:

— ze strony Dostawcy — Analitycy, Projektanci systemu i Projektanci testów, ich rolą jest spisywanie notatek, merytoryczne przygotowywanie i moderowanie spotkań, tworzenie dokumentów projektowych oraz organizacja prac zespołu,

— przyszli użytkownicy systemu (reprezentujący m.in. wydziały komunikacji, Policję, UFG, PWPW), którzy są źródłem szczegółowych informacji dotyczących oczekiwanego sposobu działania systemu,

— prawnicy ze strony Zamawiającego, MI, UFG, Policji oraz reprezentujący Wydziały Komunikacji, których rolą jest czuwanie nad legalnością przyjętych w trakcie prac zespołu rozwiązań,

— przedstawiciel kierownika projektu ze strony Zamawiającego, którego rolą jest czuwanie nad zgodnością przyjmowanych szczegółowych rozwiązań ze strategicznymi celami systemu, obserwacja jakości współpracy pomiędzy przedstawicielami poszczególnych instytucji oraz ew. interwencje poza zespołem w razie powstawania sytuacji zagrażających projektowi,

— reprezentant zespołu zarządzania jakością, którego rolą jest czuwanie nad zgodnością produktów z normami zdefiniowanymi przez zespół zarządzani jakością i przyjętymi w Planie projektu jako obowiązujące,

— reprezentant(-ci) zespołu zarządzania architekturą systemu, którego rolą jest czuwania nad zgodnością przyjmowanych rozwiązań z ogólną koncepcją i architekturą systemu oraz z innymi produktami (w szczególności z produktami wątku definicji procedur urzędowych).

Zadania i odpowiedzialność zespołu obejmują:

— formułowanie szczegółowych wymagań dotyczących działania systemu,

— przygotowywanie planów testów akceptacyjnych systemu,

— nadzór na testami akceptacyjnymi oraz odbiór ich wyników (odbiór oprogramowania).

Zespół odgrywa kluczową rolę w procesie szczegółowego definiowania systemu i angażuje wiele stron. W trakcie realizacji konkretnych prac zespół może być podzielony nad podzespoły, zajmujące się konkretnymi zagadnieniami. Niezależnie od podziału na mniejsze zespoły zawsze musi być przestrzegana zasada uczestnictwa w nich wszystkich osób, które potencjalnie mogłyby wnieść sprzeciw przeciw konkretnym szczegółowym rozwiązaniom w danym obszarze. Odpowiedzialność za organizację prac zespołu ponoszą analitycy i projektanci ze strony Dostawcy.

13. Zespół wykonawczy

Zespół w całości tworzony przez Dostawcę systemu, którego odpowiedzialnością będzie:

— wytwarzanie oprogramowania,

— przeprowadzanie testów akceptacyjnych oprogramowania,

— stworzenie końcowej Dokumentacji Technicznej Systemu,

— stworzenie końcowej Specyfikacji Systemu,

— utrzymywanie aktualnej wersji roboczej systemu.

14. Zespół ds. ewidencji pojazdów

Zadaniem zespołu ds. ewidencji pojazdów jest przygotowanie i utrzymywanie produktów Definicja procedury… oraz przygotowanie projektów zmian w przepisach prawa umożliwiających realizację ewidencji pojazdów w sposób określony w trakcie prac zespołu.

W skład zespołu wchodzą:

— ze strony Dostawcy — analitycy (procesów), których rolą jest spisywanie notatek, merytoryczne przygotowywanie i moderowanie spotkań, tworzenie dokumentów projektowych oraz organizacja prac zespołu,

— prawnicy Zamawiającego i MI, których rolą jest identyfikowanie wymagających zmiany przepisów, projektowanie koniecznych zmian, czuwanie nad legalnością definiowanych procedur i proponowanych zmian prawnych,

— przedstawiciele powiatów (kierownictw Wydziałów Komunikacji),

— przedstawiciel kierownika projektu ze strony Zamawiającego, którego rolą jest czuwanie nad zgodnością przyjmowanych szczegółowych rozwiązań ze strategicznymi celami systemu, obserwacja jakości współpracy pomiędzy przedstawicielami poszczególnych instytucji oraz możliwość interwencji u Generalnego Przedstawiciela Zamawiającego w razie powstawania sytuacji zagrażających projektowi,

— ekspert policyjny w zakresie przestępczości samochodowej, którego rolą jest opiniowanie definiowanych procedur pod kątem istnienia w nich luk możliwych do wykorzystania w działalności przestępczej,

— przedstawiciel zespołu zarządzania jakością, którego rolą jest czuwanie nad zgodnością powstających produktów z normami przyjętymi w Planie projektu,

— przedstawiciel zespołu zarządzania architekturą, którego rolą jest czuwanie nad zgodnością przyjmowanych rozwiązań z Koncepcją i architekturą systemu.

Zespołem kieruje wyznaczony przedstawiciel Zamawiającego.

15. Zespół ds. ewidencji kierowców

Zadaniem zespołu jest przygotowanie i utrzymywanie produktu Zasady współpracy z Wydziałami Komunikacji i systemem „Kierowca” w zakresie ewidencji kierowców. W skład zespołu wchodzą:

— ze strony Dostawcy — analitycy, których rolą jest spisywanie notatek, merytoryczne przygotowywanie i moderowanie spotkań, tworzenie dokumentów projektowych oraz organizacja prac zespołu,

— prawnicy Zamawiającego i MI, których rolą jest identyfikowanie wymagających zmiany przepisów, projektowanie koniecznych zmian, czuwanie nad legalnością definiowanych procedur (w sensie przepisów, których nie można zmienić),

— przedstawiciele Wydziałów Komunikacji ds. merytorycznych dot. ewidencji kierowców,

— przedstawiciele dostawcy systemu „Kierowca”, których rolą jest ustalanie technicznych aspektów współpracy,

— przedstawiciel kierownika projektu ze strony Zamawiającego, którego rolą jest czuwanie nad zgodnością przyjmowanych szczegółowych rozwiązań ze strategicznymi celami systemu, obserwacja jakości współpracy pomiędzy przedstawicielami poszczególnych instytucji oraz możliwość interwencji u Generalnego Przedstawiciela Zamawiającego w razie powstawania sytuacji zagrażających projektowi,

— przedstawiciel zespołu zarządzania jakością, którego rolą jest czuwanie nad zgodnością powstających produktów z normami przyjętymi w Planie projektu

— przedstawiciel zespołu zarządzania architekturą, którego rolą jest czuwanie nad zgodnością przyjmowanych rozwiązań z Koncepcją i architekturą systemu.

Zespołem kieruje wyznaczony przedstawiciel Zamawiającego.

16. Zespół ds. współpracy z… w zakresie…

Zadaniem zespołu jest przygotowanie i utrzymywanie produktu Zasady współpracy z… w zakresie…

W skład zespołu wchodzą:

— ze strony Dostawcy — analitycy, których rolą jest spisywanie notatek, merytoryczne przygotowywanie i moderowanie spotkań, tworzenie dokumentów projektowych oraz organizacja prac zespołu,

— prawnicy Zamawiającego oraz innych zainteresowanych stron, których rolą jest identyfikowanie wymagających zmiany przepisów, projektowanie koniecznych zmian, czuwanie nad legalnością definiowanych procedur (w sensie przepisów, których nie można zmienić),

— przedstawiciele zainteresowanych stron ds. merytorycznych dot. zakresu współpracy,

— przedstawiciele zainteresowanych stron ds. technicznych,

— przedstawiciel kierownika projektu ze strony Zamawiającego, którego rolą jest czuwanie nad zgodnością przyjmowanych szczegółowych rozwiązań ze strategicznymi celami systemu, obserwacja jakości współpracy pomiędzy przedstawicielami poszczególnych instytucji oraz możliwość interwencji u Generalnego Przedstawiciela Zamawiającego w razie powstawania sytuacji zagrażających projektowi,

— przedstawiciel zespołu zarządzania jakością, którego rolą jest czuwanie nad zgodnością powstających produktów z normami przyjętymi w Planie projektu,

— przedstawiciel zespołu zarządzania architekturą, którego rolą jest czuwanie nad zgodnością przyjmowanych rozwiązań z Koncepcją i architekturą systemu.

Zespołem kieruje wyznaczony przedstawiciel Zamawiającego.

17. Zespoły wdrożeniowe

W skład zespołów będą wchodzili przedstawiciele wszystkich stron zaangażowanych w Projekt, których udział pozwoli na zapewnienie realizacji celów wątku wdrożeniowego.

Zespołem kieruje wyznaczony przedstawiciel Dostawcy.

18. Zespół migracyjny

Zadaniem zespołu jest przygotowanie i utrzymywanie produktu Plan migracji oraz udział w wytworzeniu aplikacji wspomagającej pozyskiwanie danych (jej specyfikacja i odbiór). Szczegółowo skład zespołu ustalony zostanie w fazie przygotowanie projektu i zapisany w Planie projektu.

Zespołem kieruje wyznaczony przedstawiciel Dostawcy.

2. Przebieg prac

Całość prac przebiegać będzie w czterech wątkach:

a) wątek konstrukcji systemu — którego celem jest wyprodukowanie i przygotowanie do wdrożenia oprogramowania systemu CEPiK,

b) wątek definicji procedur urzędowych — którego celem jest przygotowanie definicji procesów do wykorzystania w wątku budowy systemu oraz projektów zmian w przepisach prawa umożliwiających wdrożenie zdefiniowanych procedur,

c) wątek migracji danych — którego celem jest przeniesienia danych ze źródeł, których obecnie się one znajdują do zasobów systemu CEPiK,

d) wątek wdrożeniowy — którego celem jest instalacja, konfiguracja i uruchomienie systemu, przeszkolenie użytkowników i administratorów, wątek ten po wdrożeniu systemu przerodzi się w proces jego utrzymania.

Prace rozpoczną się fazą przygotowania wspólną dla wszystkich czterech wątków prac. Faza ta powinna trwać nie dłużej niż jeden miesiąc.

1. Faza przygotowania

W trakcie tej fazy prac uzgodnione zostaną rozmaite organizacyjne i zarządcze aspekty projektu, co w szczególności obejmuje:

a) określenie struktury organizacyjnej przedsięwzięcia i przypisanie konkretnych osób do poszczególnych ról w tej strukturze (w tym personalne określenie składów zespołów),

b) określenie form i procedur raportowania, komunikacji, zarządzania zmianami, zgłaszania problemów, itp.,

c) uzgodnienie wspólnego rozumienia poszczególnych produktów ich konkretnych form oraz kryteriów ich odbioru,

d) uzgodnienie harmonogramu prac (w tym określenie kolejności realizacji poszczególnych funkcji systemu).

Uzgodnienia te zostaną zawarte w przygotowanym przez Zespół planowania produkcie „Plan projektu”.

W tej fazie prac powstaną również pewne początkowe produkty najbardziej krytycznych dla budowy systemu wątków prac:

a) „Koncepcja i architektura systemu” — dla wątku konstrukcji systemu (również dla wątku definiowania procedur urzędowych), przygotowywany przez Zespół zarządzania architekturą,

b) „Plan migracji danych” — dla wątku migracji danych, przygotowywany przez Zespół migracyjny we współpracy z Zespołem Planowania.

2. Wątek konstrukcji systemu

Wątek konstrukcji systemu, podzielony będzie na szereg szybkich iteracji (zwanych dalej cyklami), które powinny trwać nie dłużej niż 2 miesiące. W trakcie jednego takiego cyklu, przeprowadzane są następujące prace:

a) szczegółowa dyskusja wymagań, zaplanowanie testów akceptacyjnych i przygotowanie testów, którego produktami są:

1. szereg notatek stanowiących dla zespołu wykonawczego szczegółowe specyfikacje wymagań na oprogramowanie przygotowywany przez Zespół użytkowników lub też inne przewidziane Planem projektu produkty o charakterze specyfikacji użytkowych własności oprogramowania,

2. „Cykl ? — Plan testów akceptacyjnych wersji systemu” przygotowywany przez Zespół użytkowników,

3. środowisko testowe, repozytoria testów, automaty testujące, itp. przygotowywane przez Zespół wykonawczy.

b) konstrukcja wersji systemu, której produktem jest wersja systemu gotowa do testów akceptacyjnych. Produkt ten przygotowywany jest przez (a wcześniej zaproponowany w ofercie) Zespół wykonawczy,

c) testy akceptacyjne wersji systemu, których produktem jest „Cykl ? — Zaakceptowana wersja systemu”, wykonywane przez Zespół wykonawczy pod nadzorem Zespołu użytkowników.

d) audyt wewnętrznej konstrukcji systemu pod kątem zgodności z wytycznymi zawartymi w „Koncepcji i architekturze systemu” i „Planie projektu”, który jest wykonany przez Zespół zarządzania architekturą. Wyniki tego audytu mogą być powodem odmowy akceptacji wersji systemu przez Zamawiającego niezależnie od wyników testów akceptacyjnych. Zamawiający może odstąpić w danym cyklu od audytu.

Zalecane jest równoległe wykonywanie kroków a) i b) oraz ew. c) i d).

W razie potrzeby modyfikacji ulega produkt „Koncepcja i architektura systemu” i „Plan projektu”, modyfikacje takie wprowadzane są przez odpowiednio Zespół zarządzania architekturą oraz Zespół planowania.

Po zakończeniu cyklu następuje rewizja „Planu projektu”. W szczególności rewizji i uszczegółowieniu podlega harmonogram w odniesieniu do następnych cykli konstrukcji systemu. Rewizja ta wykonywana jest przez Zespół planowania.

W trakcie cyklu zespół wykonawczy przygotowuje również inne produkty projektowe zgodnie ze stosowaną przez siebie i opisaną w planie projektu metodyką. Produkty te nie podlegają wprawdzie odbiorowi przez Zamawiającego, nie mniej Dostawca zobowiązany jest do postępowania zgodnie z przyjętą metodyką i przygotowywania oraz archiwizowania zdefiniowanych w niej produktów. Sprawdzenie stosowania przez Dostawcę deklarowanej metodyki może być przedmiotem audytu projektu zleconego przez Zamawiającego.

Warunki przeprowadzania testów akceptacyjnych

a) Przed rozpoczęciem testów zaakceptowania w ramach Zespołu użytkowników uzgadniany jest szczegółowy opis przeprowadzenia testów.

b) Testy przeprowadza zespół wykonawczy zgodnie z zaakceptowanym szczegółowym opisem przeprowadzenia testów, pod nadzorem Zespołu użytkowników.

c) Zaistniałe w czasie testów zdarzenia są ewidencjonowane w Dzienniku testów.

d) Poszczególne testy są dokumentowane Raportem przebiegu testu.

e) Zespół użytkowników ma podczas wykonania testu pełny dostęp do odczytu konfiguracji elementów środowiska testowego, zawartości skryptów testowych, stanu zużycia zasobów elementów konfiguracji testowej.

f) Zakłada się, że wszystkie wartości mierzone w trakcie wykonywania testów będą udostępnione w ogólnie uznanym formacie, bez konieczności używania do ich odczytu specjalizowanych, trudno dostępnych lub drogich narzędzi.

g) Wszystkie wyniki testów, skrypty testowe oraz dane o konfiguracji elementów środowiska testowego są utrwalane w dwóch kopiach, na nośnikach optycznych, niezwłocznie po wykonaniu testu, jedną kopię otrzymuje przedstawiciel Zamawiającego po utrwaleniu.

h) Analiza wyników testów będzie oparta o dane utrwalone zgodnie z opisaną wyżej procedurą.

i) Przedstawiciele Zamawiającego mają podczas wykonania testu pełny dostęp do aplikacji i systemu ze stacji roboczych (w trybie administratora i użytkownika) obsługiwanych przez przedstawicieli Dostawcy, z udostępnioną pełną funkcjonalnością, służące do podglądu wykonania zadań, administrowania systemem, dostępu do bazy danych, uruchamiania funkcji aplikacji, itp.

Formy i sposoby spełnienia powyższych warunków będą szczegółowo opisane w „Planie projektu” i ew. „Planie testów akceptacyjnych” dla danego cyklu budowy systemu.

Przygotowanie dokumentacji technicznej

Po wdrożeniu każdej z wersji systemu Dostawca przekazuje zamawiającemu produkty „Specyfikacja systemu” i „Dokumentacja techniczna systemu”, przygotowane samodzielnie przez Zespół wykonawczy zgodnie z uzgodnieniami zawartymi w „Planie projektu”. Produkty te są odbierane przez Zamawiającego.

3. Wątek migracji danych

Wątek migracji danych przebiega w cyklach wyznaczanych przez dostarczane przez Zamawiającego porcje danych do migracji - patrz rozdział 6.3. W każdym takim cyklu dane te podlegają wstępnemu przetwarzaniu przez Dostawcę systemu celem sprawdzenia zgodności z ustalonymi w „Planie migracji danych” warunkami technicznymi i merytorycznymi. Dostawca przekazuje zamawiającemu dokumentację opisującą wyniki tej kontroli. Szczegółowe procedury i formy współpracy oraz produkty wymienione pomiędzy stronami w zakresie migracji danych określone są w „Planie migracji danych”. Po każdym cyklu następuje rewizja „Planu migracji danych”, która w szczególności obejmować może uzgodnione pomiędzy Dostawcą i Zamawiającym zmiany w procedurach współpracy w zakresie migracji lub zmiany reguł przetwarzania danych.

Przed wdrożeniem produkcyjnym systemu wszystkie dane przekazane przez Zamawiającego mają trafić do systemu lub zostać odrzucone zgodnie z regułami ustalonymi w „Planie migracji danych”. Dane, które trafią do systemu trafią albo do tzw. bazy migracyjnej, dodatkowo ta część danych z bazy migracyjnej, której jakość będzie na to pozwalać (zgodnie z regułami analogicznymi jak dla danych nowo wprowadzanych do systemu), będzie przeniesiona do odpowiednich ewidencji.

Ponadto w pierwszej fazie prac (zaraz po przygotowaniu planu migracji) Dostawca dostarczy narzędzia wspomagające pozyskiwanie danych. Szczegółowe wymagania dotyczące funkcji tych narzędzi zostaną zdefiniowane we wstępnej fazie prac nad nią przez odpowiednio powołany zespół. Narzędzia te wraz z dokumentacją użytkową zostanie przez Zamawiającego rozdystrybuowana do podmiotów będących źródłami danych do migracji. Dostawca zapewni wsparcie techniczne jej użytkowników..

Odpowiedzialność za jakość danych przekazywanych do migracji przez Zamawiającego spoczywa w całości na Zamawiającym.

4. Wątek definicji procedur urzędowych

W wątku definicji procedur powstają definicje wszystkich procedur urzędowych, które mają być wspierane przez system oraz określone zostają zasady współpracy z podmiotami będącymi źródłami danych dla CEPiK. Każda taka definicja powstaje jako dokument ”Definicja procedury…” lub „Zasady współpracy z… w zakresie…”, który przygotowywany jest przez odpowiednie zespoły (Zespół ds. ewidencji pojazdów, Zespół ds. ewidencji kierowców lub jeden z Zespołów ds. współpracy z… w zakresie…, szczegóły w rozdziale 8. „Przebieg prac i organizacja przedsięwzięcia”) zgodnie z ustalonymi w „Planie projektu” wymaganiami. Każda ”Definicja procedury…” jest oddzielnym produktem. Wątek definicji procedur rozpoczyna pracę od zdefiniowana najczęściej wykonywanych procedur. Przy czym co najmniej jedna taka procedura zostanie zdefiniowana przed rozpoczęciem drugiego cyklu w wątku konstrukcji systemu. Do końca 2003 roku zostaną zdefiniowane wszystkie procedury urzędowe wspierane przez system oraz zasady współpracy ze wszystkim źródłami i odbiorcami informacji CEPiK. Po zdefiniowaniu wszystkich procedur zostaną one przełożone przez Zamawiającego na projekty zmian w przepisach prawa, które zostaną wprowadzone w życie w chwili produkcyjnego startu systemu.

Odpowiedzialność za przygotowanie i wprowadzenie w życie potrzebnych zmian legislacyjnych spoczywa w całości na Zamawiającym.

5. Wątek wdrożeniowy

Wątek wdrożeniowy systemu będzie prowadzony przez członków Zespołów wdrożeniowych, przy czym dla każdego kolejnego wdrożenia prace w tym wątku będą obejmować dwa etapy:

1) szczegółowe zaplanowanie wdrożenia,

2) przeprowadzenie wdrożenia obejmujące prace i dostawy opisane w rozdziale 7. Wdrożenie

6. Zapewnienie i kontrola jakości

Podstawowym dokumentem opisującym działania Dostawcy związane z zapewnienie i kontrolą jakości prac nad stworzeniem systemu jest plan jakości projektu.

Plan jakości powinien określać sposób, w jaki Dostawca zamierza zapewnić jakość powstających produktów, uwzględniając nie tylko kontrolę gotowego produktu, ale także działania zapobiegające powstawaniu błędów w tracie prac nad nim. Powinien on także uwzględniać działania umożliwiające szybkie eliminowanie błędów powstających w trakcie prac, a nie tylko działania związane z kontrolą jakości w trakcie testowania i wdrażania systemu.

Plan zapewnienia jakości jest podstawą do podejmowania działań kontrolnych w ramach przedsięwzięcia oraz powinien służyć jako podstawowy materiał do przygotowania niezależnego audytu zewnętrznego przedsięwzięcia.

W Planie zapewnienia jakości powinny się znaleźć:

— określenie zakresu odpowiedzialności za jakość prac w zespołach projektowych,

— określenie działań pro jakościowych podejmowanych w czasie prac,

— opis produktów powstających w projekcie wraz z kryteriami ich oceny (w przypadku produktów standardowych wystarczy odwołanie się do metodyki, a w przypadku produktów niestandardowych niezbędny jest szczegółowy opis),

— odniesienia do standardów, metodyk i notacji wykorzystywanych w projekcie,

— opis organizacji zespołu kontroli jakości i procedur jego działania,

— harmonogram działań związanych z zapewnieniem jakości wkomponowany w harmonogram przedsięwzięcia,

— harmonogram kontroli jakości wkomponowany w harmonogram przedsięwzięcia,

— plan testów akceptacyjnych przy odbiorze systemu.

Planowana kontrola jakości powinna obejmować następujące zadania:

— identyfikację produktów podlegających kontroli,

— identyfikację celów i zakresu kontroli,

— identyfikację atrybutów jakości,

— określenie formy kontroli (przegląd strukturalny, przegląd wzajemny, inspekcja).

Ogólny opis przedstawionych powyżej elementów powinien się znaleźć w ofercie, natomiast szczegółowe doprecyzowanie Planu jakości powinno nastąpić w fazie projektowania.

7. Zarządzanie zmianami

Celem zarządzania zmianami zakresu jest:

— umożliwienie formalnych zmian zakresu prac w obrębie ustaleń wynikających z umowy,

— zapewnienie mechanizmów oceny wniosku o dokonanie zmiany,

— zapewnienie metod weryfikacji bieżącej wersji zakresu projektu i śledzenia historii zmian, poczynając od pierwotnej wersji zakresu projektu,

— zapewnienie zgodności między wersją zakresu projektu wg umowy wraz z późniejszymi aneksami z aktualnym stanem jego zmian.

Do złożenia wniosku o zmianę zakresu i jego oceny stosowany jest formularz zgłoszenia żądania zmiany zakresu projektu.

Cykl życia żądania zmiany jest następujący: po złożeniu wniosku oczekuje on na ocenę i analizę przez Zespół Planowania. Po ocenie podejmuje on decyzję co do realizacji wniosku, chyba że zmiana istotnie wpływa na harmonogram lub budżet projektu, wtedy musi być przedstawiona do decyzji Komitetowi Sterującemu.

Ustalenia przyjmowane w trakcie prac projektowych jako rozwiązania tymczasowe powinny być opatrzone komentarzem ustalającym jego status oraz czas, do jakiego ma obowiązywać. Zmiana tego typu ustalenie po czasie jego obowiązywania nie jest uważana na zmianę zakresu.

Szczegółowy opis procedury powinnien być określony w „Planie projektu”.

8. Zarządzanie konfiguracją

Zarządzanie konfiguracją to proces obejmujący identyfikowanie i określanie elementów konfiguracji w systemie, rejestrowanie i raportowanie odnośnie elementów konfiguracji oraz wniosków o wprowadzenie zmian, oraz weryfikowanie kompletności i prawidłowości elementów konfiguracji. Jest integralną częścią wszystkich innych procesów zarządzania.

Do zadań związanych z zarządzaniem konfiguracją należą:

— zainstalowanie i administrowanie narzędziami do kontroli wersji dokumentacji i oprogramowania,

— założenie i utrzymywanie (w tym archiwizowanie) repozytorium projektu,

— utrzymywanie informacji o sposobie przechowywania danych w repozytorium,

— ustaleniu sposobu i egzekwowanie jego przestrzegania dla wprowadzania zmian w danych repozytorium, oraz sposobu rozwiązywania konfliktów,

— ustalenie sposobu i egzekwowanie jego przestrzegania dla dokumentowania zmian,

— ustalenie sposobu i egzekwowanie jego przestrzegania oraz moderowanie rozsyłania informacji o zmianach,

— tworzenie baseline-ów i zatwierdzanie stabilnych wersji produktów,

— przydzielanie uprawnień dla użytkowników repozytorium.

Od oferenta oczekuje się określenia sposobu rozwiązania następujących problemów:

— wprowadzanie zmian,

— dokumentowanie zmian,

— informowanie o zmianach,

— zachowywanie starych wersji obiektów repozytorium.

3. Produkty projektu

W trakcie prac projektowych zostaną przygotowane następujące produkty:

1. Plan projektu

Jest kluczowym dokumentem w projekcie regulującym wszystkie zagadnienia organizacyjne projektu i część zagadnień merytorycznych. Dokument przygotowywany jest i uzgadniany w ramach prac Zespołu planowania.

W szczególności dokument powinien zawierać:

a) cel i zakres projektu (krótki opis celów przedsięwzięcia i głównych produktów, kluczowych czynności i kamieni milowych; potrzebnych zasobów; ogólnego harmonogramu; opis związków z innymi projektami oraz kontekstu przedsięwzięcia),

b) opisy produktów projektowych oraz procedury i kryteria ich odbioru (formy i metody dostarczania produktów, kryteria i terminy odbiorów, sposób współdziałania z audytorami),

c) opis procesu wytwórczego,

d) główne założenia, współzależności i ograniczenia projektowe,

e) harmonogramy prac (ramowy harmonogram całego projektu oraz szczegółowe harmonogramy prac dla najbliższego cyklu),

f) opis struktury organizacyjnej projektu (opis ról i ich zakresów odpowiedzialności oraz przypisanie konkretnych osób do tych ról),

g) zakres przedsięwzięcia i powiązania z innymi organizacjami (w szczególności szczegółowe wskazanie osób w innych organizacjach, z którymi należy się kontaktować przy realizacji projektu),

h) plan komunikacji (definicje, elementy objęte komunikacją w projekcie związane z zarządzaniem i kontrolą projektu),

i) opis metod zarządzania problemami i zarządzania ryzykiem (opis ryzyk przedsięwzięcia, ustalenie sposobów ich śledzenia, procedury rozwiązywania problemów, itp.),

j) określenie metod zapewnienia i kontroli jakości (stosowane w projekcie środki, metody i procedury zapewnienia i kontroli jakości, zakresy odpowiedzialności różnych uczestników projektu za jakość prac, m.in. zarządzanie konfiguracją, zarządzanie wersjami, zarządzanie zmianami, strategia testowania),

k) zasady przygotowywania, przeprowadzania testów oraz analizy wyników,

l) zasady kontroli przebiegu i postępu prac,

m) zasady pielęgnacji planu projektu (przewidywane rewizje, procedury, role i zakres odpowiedzialności z tym związanej).

2. Plan migracji danych

Produkt jest dokumentem powstającym w fazie przygotowanie projektu. Przygotowywany jest przez Zespół Migracyjny we współpracy z Zespołem Planowania.

W szczególności dokument powinien zawierać:

a) strategię migracji danych,

b) zasady współpracy Dostawcy i Zamawiającego w zakresie migracji danych,

c) formy, szczegółowa zawartość i postaci produktów oraz przekazywanych danych,

d) reguły poprawności danych (być może na wielu poziomach abstrakcji),

e) plany awaryjne związane z ewentualną niemożnością dokonania migracji danych w wyznaczonym terminie.

Produkt ten podlega rewizji po każdym cyklu związanym z przetwarzaniem danych dostarczonych przez Zamawiającego, w ramach, których wprowadzane są do niego zmiany uzgodnione pomiędzy Dostawcą i Zamawiającym. Zmiany wprowadza Dostawca, a zrewidowany dokument podlega odbiorowi przez Zamawiającego.

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

3. Aplikacja wspomagająca pozyskiwanie danych — plan testów akceptacyjnych

Produkt powstaje jako jeden z produktów w wątku migracji danych podczas przygotowywania aplikacji wspomagającej pozyskiwanie danych. Jest to dokument (z ew. elektronicznymi załącznikami z danymi testowymi), którego przeznaczeniem jest określenie szczegółowych warunków akceptacji wersji systemu przez zamawiającego na podstawie wyników testów systemu. Dokument przygotowywany jest przez Zespół migracyjny. Kontekst dla dokumentu stanowią ustalenia dotyczące sposobu realizacji testów akceptacyjnych zawarte w „Planie projektu”.

W szczególności dokument powinien zawierać:

a) specyfikację środowiska i organizacji testów (ew. tylko te elementy, które nie są opisane w „Planie projektu”),

b) opis założeń, jakie przyjęto przy planowaniu testów,

c) scenariusze, przypadki i dane testowe (ew. w elektronicznych załącznikach),

d) określenie wyników oczekiwanych dla poszczególnych przypadków testowych,

e) kryteria akceptacji wyników testów.

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

4. Aplikacja wspomagająca pozyskiwanie danych — wersja zaakceptowana

Jest to produkt złożony będący łącznym wynikiem specyfikacji aplikacji, jej konstrukcji systemu przez Dostawcę, testów akceptacyjnych przeprowadzonych zgodnie z „Planem testów akceptacyjnych”.

W skład produktu wchodzą następujące elementy:

a) aktualna wersja produktu „Aplikacja wspomagająca pozyskiwanie danych — Plan testów akceptacyjnych”,

b) oprogramowanie zainstalowane, uruchomione, przetestowane i zaakceptowane zgodnie z planem testów akceptacyjnych,

c) kod źródłowy oprogramowania.

Warunki, jakie musi spełniać zaakceptowana wersja aplikacji szczegółowo określa „Plan projektu”.

5. Koncepcja i architektura systemu

Produkt jest dokumentem powstającym w fazie przygotowania projektu. Przygotowywany jest on przez Zespół zarządzania architekturą. Przeznaczeniem dokumentu jest określenie i uporządkowanie zakresu systemu, analiza powiązań pomiędzy różnymi jego elementami oraz wskazanie w sposób ogólny konkretnych rozwiązań technicznych i narzędzi, przy pomocy których (z których) system będzie budowany. Dokument w znacznej części będzie powtórzeniem informacji zawartych w SIWZ-ie i w ofercie Dostawcy, a jego rolą w odniesieniu do tych informacji będzie potwierdzenie ich zgodnego rozumienia przez Dostawcę i Zamawiającego. Dokument ten powstaje równocześnie z „Planem projektu”, gdyż z jednej strony jego zakres i kryteria odbioru są w właśnie w planie projektu zdefiniowane, z drugiej zaś zawiera on informacje niezbędne do zaplanowania projektu.

W szczególności dokument powinien zawierać:

a) wyliczenie i ogólne opisy głównych encji CEPiK (koncepcyjny model danych CEPiK),

b) wyliczenie i ogólne opisy procedur urzędniczych sterowanych przez system,

c) wyliczenie i ogólne opisy usług informacyjnych świadczonych przez system (produktów informacyjnych),

d) wyliczenie i ogólna charakterystyka zewnętrznych źródeł informacji dla systemu oraz planowanego sposobu współpracy z nimi,

e) koncepcję systemu bezpieczeństwa i odniesienie jej do polityki bezpieczeństwa przedstawionej przez Zamawiającego,

f) architekturę techniczną systemu (w tym wskazanie konkretnych narzędzi, platform, protokołów, głównych komponentów itp.),

g) zasady realizacji różnych elementów zakresu przy przyjętej architekturze technicznej (rola poszczególnych komponentów, przyjęte wzorce projektowe, itp.),

h) wymagania dotyczące infrastruktury systemu (tj. inne niż zawartość informacyjna poszczególnych encji systemu, funkcjonalność i zakres informacyjny usług informacyjnych oraz przebieg i sposób realizacji konkretnych procedur urzędniczych),

i) zależności pomiędzy poszczególnymi elementami zakresu (w szczególności zależności pomiędzy procedurami urzędowymi i encjami, pomiędzy encjami i usługami informacyjnymi systemu, pomiędzy encjami i zewnętrznymi źródłami informacji itp.).

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

6. Cykl ? — Plan testów akceptacyjnych

Produkt powstaje jako jeden z produktów w cyklu budowy systemu. Jest to dokument (z ew. elektronicznymi załącznikami z danymi testowymi), którego przeznaczeniem jest określenie szczegółowych warunków akceptacji wersji systemu przez zamawiającego na podstawie wyników testów systemu, obejmujących co najmniej testy funkcjonalne, wydajności i bezpieczeństwa. Dokument przygotowywany jest przez Zespół użytkowników. Podstawę do wytworzenia dokumentu stanowią ustalenia dotyczące sposobu realizacji testów akceptacyjnych zawarte w „Planie projektu”.

W szczególności dokument powinien zawierać:

a) specyfikację środowiska i organizacji testów (ew. tylko te elementy, które nie są opisane w „Planie projektu”),

b) opis założeń, jakie przyjęto przy planowaniu testów,

c) scenariusze, przypadki i dane testowe (ew. w elektronicznych załącznikach),

d) określenie wyników oczekiwanych dla poszczególnych przypadków testowych,

e) kryteria akceptacji wyników testów.

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

7. Cykl ? — Zaakceptowana wersja systemu

Produkt jest końcowym produktem cyklu budowy systemu. Jest to produkt złożony będący łącznym wynikiem specyfikacji systemu, konstrukcji systemu przez Dostawcę, testów akceptacyjnych przeprowadzonych zgodnie z „Planem testów akceptacyjnych” oraz ew. audytu wewnętrznej konstrukcji systemu.

W skład produktu wchodzą następujące elementy:

a) aktualna wersja produktu „Cykl ? — Plan testów akceptacyjnych wersji systemu”,

b) wersja systemu zainstalowana, uruchomiona, przetestowana i zaakceptowana zgodnie z planem testów akceptacyjnych,

c) kod źródłowy oprogramowania,

d) ew. raport z audytu wewnętrznej konstrukcji systemu.

Warunki jakie powinna spełniać „Zaakceptowana wersja systemu” szczegółowo określa „Plan projektu”.

8. Zasady współpracy z… w zakresie…

Produkt powstaje w wątku definicji procedur urzędowych. Przygotowywany jest przez Zespół ds. współpracy z… w zakresie… Przeznaczeniem produktu jest opisanie uzgodnionego z zewnętrznym podmiotem dostarczającym danych do systemu CEPiK sposobu współpracy celem implementacji po stronie systemu CEPiK.

W szczególności dokument powinien określać:

a) procedurę współpracy opisaną na poziomie logicznym (tj. harmonogram współpracy, stronę inicjującą przesłanie informacji, wymieniane potwierdzenia, organizacyjne aspekty bezpieczeństwa komunikacji, itp.),

b) zawartość informacyjną wymienianych danych na poziomie logicznym (abstrahując od ich fizycznej reprezentacji w komunikacji),

c) techniczne aspekty współpracy (protokoły, formaty danych, techniczne mechanizmy bezpieczeństwa, itp.),

d) ekspertyzę prawną ustalającą zgodność z prawem opisanej procedury i/lub ew. opisującą wymagane zmiany w przepisach prawa.

Dokument ten nie określa sposobu wykorzystania pozyskiwanych informacji przez CEPiK.

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

9. Definicja procedury…

Produkt powstaje w wątku definicji procedur urzędowych. Przygotowywany jest przez Zespół ds. ewidencji pojazdów.

Przeznaczeniem produktu jest opisanie ustalonych na podstawie ekspertyz prawnych oraz uzgodnień z zainteresowanymi instytucjami administracji publicznej szczegółowych wzorców postępowania w trakcie realizacji procedur, które mają być sterowane przez system celem implementacji tych procedur w CEPiK.

W szczególności dokument powinien zawierać:

a) jednoznaczny i deterministyczny opis sposobu realizacji procedury, który:

1. jest spójny pojęciowo z innymi procedurami,

2. sporządzony zgodnie z ustaloną w „Planie projektu” notacją,

3. opisujący wszystkie możliwe ścieżki postępowania,

4. wskazujący wszystkie wykorzystywane i pozyskiwane (lub produkowane) w poszczególnych krokach informacje,

5. wskazujący wszystkie reguły decyzyjne,

6. przygotowany jest na poziomie szczegółowości charakteryzującym się niepodzielnością poszczególnych kroków procedury ze względu na Dostawcę (poszczególne role pracowników w powiatach, system CEPiK, poszczególne instytucje zewnętrzne) oraz ze względu na podejmowane decyzje (w jednym kroku co najwyżej jedna decyzja),

b) ekspertyzę prawną zawierającą analizę zgodności zdefiniowanej procedury z prawem i ew. opis potrzebnych zmian w przepisach prawa.

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

10. Specyfikacja systemu

Produkt jest dokumentem przygotowywanym po realizacji ostatniego cyklu budowy systemu, każdej z wdrażanych wersji systemu. Przygotowywany jest on przez samodzielnie przez Zespół wykonawczy podlega odbiorowi przez Zamawiającego. Przeznaczeniem dokumentu jest szczegółowe opisanie funkcji systemu na potrzeby dalszych procesów zarządzania zmianami.

W szczególności dokument powinien zawierać:

a) szczegółowy logiczny opis struktur danych CEPiK (logiczny model danych CEPiK),

b) specyfikacja przebiegu procedur urzędowych (kroki, ich kolejność, dane sterujące procesem, reguły wyboru odpowiednich ścieżek, itp.),

c) specyfikacja poszczególnych kroków w procedurach urzędowych (scenariusz interakcji z użytkownikiem lub zewnętrznym systemem w ramach realizacji kroku; zawartość informacyjna ekranów, formularzy, wydruków, komunikatów wysyłanych i odbieranych do/z zewnętrznych systemów oraz ew. bazy migracyjnej itp.),

d) specyfikacja produktów informacyjnych dostarczanych przez system (scenariusz interakcji z użytkownikiem lub zewnętrznym systemem, zawartość informacyjna ekranów, formularzy, komunikatów wysyłanych/odbieranych do/z zewnętrznych systemów, zakres konfiguracji produktu, itp.),

e) szczegółowa techniczna specyfikacja komunikatów wysyłanych i odbieranych do/z zewnętrznych systemów (w ramach realizacji procedur urzędniczych źródeł/lub produktów informacyjnych),

f) specyfikacja źródeł informacyjnych integrowanych w danym cyklu (scenariusz interakcji z użytkownikiem lub zewnętrznym systemem, zawartości informacyjna ekranów, formatek, komunikatów, techniczna specyfikacja komunikatów),

g) katalog szczegółowych wymagań powiązanych z elementami opisywanymi w punktach a-f.

Forma i wymagana zawartość produktu zostanie szczegółowo określona w „Planie projektu”.

11. Dokumentacja techniczna systemu

Produkt powstaje w wątku konstrukcji systemu. Przygotowywany jest samodzielnie przez Zespół wykonawczy i odbierany przez Zamawiającego. Odbiór tego produktu dokonywany jest przez zamawiającego, trwa do 20 dni roboczych i może polegać na przeprowadzeniu przez Zamawiającego przy współpracy Dostawcy audytu wewnętrznej konstrukcji systemu pod kątem zgodności z „Dokumentacją techniczną systemu”. O przeprowadzeniu lub nie przeprowadzeniu takiego audytu decyduje Zamawiający. Przeznaczeniem produktu jest opisanie wewnętrznej konstrukcji systemu w sposób ułatwiający przejęcie utrzymania i rozwoju systemu przez organizację nieuczestniczącą w projekcie jego budowy.

W szczególności dokument powinien zawierać:

a) szczegółowy opis technicznej architektury systemu,

b) szczegółowe fizyczne modele danych przechowywanych w systemie,

c) szczegółowy wykaz komponentów oprogramowania,

d) szczegółowy opis komunikatów wymienianych pomiędzy poszczególnymi komponentami systemu,

e) szczegółowy opis sposobu implementacji przepływu pracy w procedurach urzędowych,

f) szczegółowy opis wszystkich reużywalnych lub potencjalnie reużywalnych (ze względu na ich techniczną realizację) elementów kodu (klas, funkcji, procedur, usług, itp.) obejmujący sposób komunikacji z nimi, dane informacje przechowywane przekazywane do/z takiego komponentu, opis funkcji realizowanej(-ych) przez taki komponent oraz wskazanie ewentualnych innych komponentów wykorzystywanych do realizacji tej funkcji,

g) szczegółowy opis zakładanej konfiguracji oprogramowania narzędziowego i systemowego istotnej z punktu widzenia realizacji funkcji systemu,

h) inne elementy istotne z punktu widzenia przeznaczenia dokumentacji.

Dokumentacja w szczególności nie musi zawierać szczegółowych algorytmicznych opisów realizacji poszczególnych funkcji komponentów chyba, że taki opis jest wygodniejszy i bardziej zrozumiały niż opis o charakterze deklaratywnym.

Forma i zawartość dokumentu wynika z przyjętej architektury technicznej i wykorzystywanych wzorców projektowych i zostanie szczegółowo określona w „Planie projektu”.

9. Usługi utrzymania systemu

Zakresem zamówienia objęte są usługi utrzymania systemu w okresie od 1 stycznia 2004 r. do końca roku 2009.

Z dniem 1.01.2004 r. Podmiot Utrzymania jest odpowiedzialny za eksploatację bazy CEP z danych zmigrowanych z WEP z ich aktualizacją ze skonsolidowanych plików wojewódzkich zawierających dane aktualizujące ze starostw i z przygotowywaniem odpowiedzi na pytania podmiotów uprawnionych.

Niniejsza sekcja określa parametry i wartości, które musi zapewnić dostawca usług utrzymania systemu, w różnych obszarach. Podmiot Utrzymania nie jest odpowiedzialny za odchylenia od zadanych wartości spowodowanych przez awarie i zakłócenia pracy infrastruktury, systemów informatycznych i telekomunikacyjnych nie będących przedmiotem dostaw systemu, dotyczy to m.in.:

— awarii i zakłóceń funkcjonowania sieci PESEL-NET lub dedykowanych połączeń z innymi organami administracji,

— awarii i zakłóceń funkcjonowania zewnętrznych systemów, z którymi współpracuje system CEPiK,

— awarii i zakłóceń funkcjonowania dostarczonej przez Zamawiającego infrastruktury w lokalizacjach, w których działa system (okablowanie, urządzeń sieciowych, sieci energetycznej, klimatyzacji, itp.).

1. Wydajność systemu

Podmiot Utrzymania musi zapewnić spełnianie charakterystyk wydajnościowych systemu (opisanych w ogólnej specyfikacji systemu i ew. uszczegółowionych w trakcie prac projektowych), przy założeniu obciążenia systemu i wolumetrii danych nie przekraczających wielkości podanych w ogólnej specyfikacji systemu.

2. Dostępność usług systemu

Poniższa tabelka pokazuje okresy eksploatacji, oraz maksymalne czasy niedostępności systemu w tych okresach, dla usług wspierających poszczególne obszary funkcjonowania systemu.

	Okres dostępności usług	Maksymalny czas jednej przerwy w świadczeniu usług (w godz. dostępności)	Maksymalny łączny czas niedostępności systemu na rok
Obsługa ewidencji pojazdów w powiatach	dni robocze, 7:00-18:00	2 godz.	30 godzin
Obsługa ewidencji kierowców w powiatach	dni robocze, 7:00-18:00	2 godz.	30 godzin
Udostępnianie informacji dla Policji i Straży Granicznej — tryb automatyczny-operacyjny	non-stop	2 godz.	10 godzin
Obsługa pojazdów specjalnych — ewidencja	dni robocze, 7:00-18:00	33 godz.	150 godzin
Obsługa pojazdów specjalnych — ochrona przed dekonspiracją	non-stop	2 godz.	10 godzin
Produkcja CD-ROM-ów z danymi do naliczenia podatku od środków transportu	raz w roku, na czas potrzebny do wyprodukowania wszystkich CD	nie dotyczy	nie dotyczy
Udostępnianie informacji — tryb urzędowy	dni robocze, 7:00-18:00	22 godz.	150 godzin
Udostępnianie informacji dla UFG	dni robocze, 7:00-18:00	2 godz.	30 godzin
Udostępnianie informacji tryb automatyczny-dochodzeniowy	dni robocze, 7:00-18:00	22 godz.	150 godzin
Ewidencja polis OC	dni robocze, 7:00-18:00	2 godz.	30 godzin
Ewidencja czynności Policji	non-stop	2 godz.	30 godzin
Komercyjne udostępnianie informacji	dni robocze, 7:00-18:00	77 godz.	200 godzin
Pozyskiwanie danych referencyjnych	wg potrzeb innych procesów	wg potrzeb innych procesów	wg potrzeb innych procesów
Ewidencja podmiotów uczestniczących w obrocie pojazdami	7:00-18:00	22 godz.	150 godzin

Tabela 17 Zestawienie zakładanych parametrów dostępności usług systemu.

3. Parametry serwisu i wsparcia technicznego

Niniejszy rozdział przedstawia wymagania dotyczące czasów reakcji serwisu na różnego rodzaju zdarzenia. Rozdział ten składa się z kilku wymagań opisujących kolejne fazy obsługi zgłoszenia serwisowego oraz związane z nimi charakterystyki czasowe. Ze względu na różne wymagane poziomy usług w odniesieniu do wsparcia poszczególnych procesów wymagania podane są w sposób parametryczny, tj. zawierają symbole A, B, C, D, itd., którym konkretne wartości dla poszczególnych obszarów działania systemu przypisuje tabelka załączona na końcu tego rozdziału. Pojęcia wielkości średnich i maksymalnych mają analogiczne znaczenie jak w wymaganiach wydajnościowych w ogólnej specyfikacji systemu. Zakłada się, że serwis dostępny jest (możliwe jest zgłaszanie problemów) w godzinach dostępności danego obszaru funkcji systemu oraz że wspiera on tylko certyfikowanych użytkowników systemu oraz obsługę techniczną systemów współpracujących.

1. Kanał komunikacji z serwisem systemu

Kanałem służącym do zgłaszania napotykanych w funkcjonowaniu lub obsłudze systemu problemów jest kanał telefoniczny. Kanał ten powinien posiadać pojemność i wydajność pozwalającą uzyskać średni czas oczekiwania na połączenie z serwisem nie przekraczający A (od momentu wybrania numeru przez podsystemy telekomunikacyjne), a czas maksymalny B.

2. I linia wsparcia

Pierwszą linię wsparcia stanowią konsultanci odbierający telefony serwisowe. Zadaniem pierwszej linii wsparcia jest:

— rozwiązywanie problemów z obsługą systemu (odpowiadanie na pytania użytkowników aplikacji systemu, dotyczące sposobów jej obsługi),

— identyfikacja problemów spowodowanych błędnym działaniem systemu i kierowanie ich do dalszych linii wsparcia.

Działanie I linii wsparcia kończy się albo odpowiedzią na pytanie użytkownika, albo skierowaniem sprawy do II linii wsparcia.

3. II linia wsparcia

II linia wsparcia zajmuje się problemami związanymi ze stwierdzonym nieprawidłowym działaniem systemu. Konsultanci II linii wsparcia kontaktują się z użytkownikiem zgłaszającym problem w średnim czasie nie dłuższym niż C i maksymalnym nie dłuższym niż D, od zgłoszenia problemu (do I linii).

Zadaniem II linii wsparcia jest:

— rozwiązywanie wszelkich problemów, o charakterze konfiguracyjnym i administracyjnym oraz usuwanie awarii infrastruktury systemu (elementów dostarczonych przez Dostawcę)

— identyfikacja problemów spowodowanych błędami w konstrukcji systemu, ich klasyfikacja i kierowanie do III linii wsparcia i/lub zespołów rozwijających system,

— identyfikacja problemów spowodowanych niewłaściwym działaniem zewnętrznych systemów informatycznych lub infrastruktury nie będącej przedmiotem dostaw przez Dostawcę, kierowanie zgłoszeń do obsługi tych systemów oraz współpraca z tą obsługą w trakcie rozwiązywania przez nią problemu.

Działanie II linii wsparcia kończy się rozwiązaniem problemu, skierowaniem zgłoszenia błędu w systemie do III linii wsparcia i/lub zespołów rozwijających system lub skierowaniem problemu do obsługi innego systemu czy też elementu infrastruktury.

Średni czas identyfikacji przyczyny problemu (i ew. skierowania problemu gdzie do III linii, zespołów rozwojowych lub obsługi innego systemu) nie powinien przekraczać E, a czas maksymalny F.

Średni czas rozwiązywania problemu o charakterze konfiguracyjnym lub administracyjnym liczony od momentu jego zgłoszenia do II linii wsparcia nie powinien przekraczać G, a czas maksymalny H.

4. Błędy krytyczne

Szczegółowe zasady klasyfikacji błędów będą przedmiotem ustaleń w trakcie projektu. W szczególności klasyfikacja ta musi dzielić znalezione błędy na krytyczne i nie krytyczne. Błędami krytycznymi są błędy, których występowanie uniemożliwia realizacje funkcjonalności opisanej w rozdziale 5. (konieczne jest stosowanie procedur awaryjnych) lub, których występowanie powoduje istotny spadek wydajności wspieranych procesów (w sensie czasu obsługi lub wykorzystania zasobów ludzkich).

5. III linia wsparcia (obsługa błędów krytycznych)

Zadaniem III linii wsparcia jest poprawianie błędów krytycznych w konstrukcji systemu i wdrażanie wersji systemu likwidującej dany problem.

Przy założeniu, że błąd ma charakter niezgodności działania systemu z ustalonymi w trakcie prac projektowych szczegółowymi wymaganiami (tj. jego poprawienie nie wymaga prac analitycznych), średni czas usunięcia błędu krytycznego systemu nie powinien przekraczać I od momentu jego zgłoszenia, czas maksymalny J.

W przypadku, gdy poprawienie błędu wymaga przeprowadzenia prac analitycznych, III linia wsparcia powiadamia o tym Zamawiającego (wraz ze wskazaniem kompetencji osób potrzebnych do prac analitycznych ze strony zamawiającego) w średnim czasie nie przekraczającym K i maksymalnym nie przekraczającym L od momentu zgłoszenia problemu. Powoływany jest specjalny zespół mieszany, którego zadaniem jest poczynienie ustaleń koniecznych do rozwiązania problemu.

Przedstawiciele dostawcy są wyznaczeni i gotowi do rozpoczęcia prac w zespole średnio w ciągu M od zgłoszenia problemu (maksymalnie N).

Gdy zespół poczyni konieczne ustalenia, dostawca poprawia błąd krytyczny i wdraża poprawioną wersję systemu w czasie nie przekraczającym średnio O od momentu poczynienia ustaleń, a maksymalnie P.

Ustalenia zespołu mogą dotyczyć, również czasu i sposobu rozwiązania problemu (uchylając działanie powyższego wymagania), w tym również zmiany klasyfikacji problemu.

6. Obsługa błędów niekrytycznych

Błędy niekrytyczne kierowane są do zespołów rozwojowych systemu (zespołów pracujących nad kolejnymi elementami zakresu systemu), uwzględniane w planie projektu przez zespół planowania prac, realizowane i wdrażane zgodnie z tym planem.

4. Śledzenie i ewidencja przebiegu obsługi serwisowej

Podmiot Utrzymania prowadzi szczegółową ewidencję zgłoszeń serwisowych oraz zdarzeń związanych z ich obsługą. Szczegółowe zasady prowadzenia tej ewidencji ustalone będą w trakcie prac projektowych.

5. Niezawodność systemu

Liczba czynności, których poprawne wykonanie zostało uniemożliwione skutkiem błędów w oprogramowaniu operacyjnym, narzędziowym, bazodanowym i aplikacyjnym systemu oraz skutkiem usterek sprzętowych nie może przekraczać 0,1% wszystkich czynności wspieranych przez system (zarówno w odniesieniu do każdej czynności z osobna, dowolnych grup czynności jak i całego systemu).

Podmiot Utrzymania zobowiązany jest do ciągłego monitorowania tej wielkości (na podstawie ewidencji prowadzonej przez serwis oraz dzienników systemu) i dostarczania w cyklu miesięcznym raportów dotyczących tego zagadnienia (szczegółowa forma i zawartość raportów zostaną ustalone w trakcie prac projektowych).

W razie stwierdzenia istotnego statystycznie przekroczenia tego poziomu (w pewnym obszarze funkcjonowania systemu) Dostawca musi przygotować i przeprowadzić dodatkowe testy funkcjonalne w tym obszarze. Szczegółowe plany testów i kryteria akceptacji oprogramowania opracowywane będą w takim przypadku przez specjalnie do tego powołany zespół mieszany na zasadach podobnych jak plany testów w procesie budowy systemu. Zespół ten również nadzoruje realizację testów. Testy trwają do momentu spełnienia przez system ustalonych w planie testów kryteriów akceptacji.

6. Usługi szkoleniowe

Usługi utrzymania systemu obejmują swoim zakresem szkolenie nowych użytkowników systemu pojawiających się skutkiem rotacji personelu wydziałów komunikacji i innych instytucji, w których znajdują się bezpośredni użytkownicy systemu. Zakłada się, że liczby osób szkolonych w ten sposób nie przekraczają w skali roku 15% liczb podanych w rozdziale 7.3. „Usługi szkoleniowe”.

7. Przetwarzanie niestandardowe

W ramach realizacji procesów udostępniania danych (niekomercyjnego w trybie urzędniczym i komercyjnego) Podmiot Utrzymania realizuje na zlecenie Zamawiającego niestandardowe raporty i ekstrakty danych z systemu.

8. Migracja danych

W ramach kontynuacji procesu migracji danych (w razie gdyby nie udało się go zakończyć przed pierwszym wdrożeniem systemu) Podmiot Utrzymania dokonuje przetwarzania danych zgodnego z ustaleniami podjętymi w trakcie prac projektowych i przekazuje Zamawiającemu odpowiednie raporty. Przetwarzaniu temu podlegać będą rekordy przechowywane obecnie w bazach wojewódzkich i powiatowych.

9. Centrum informacyjne dla obywateli

Zamawiający oczekuje od Dostawcy organizacji i utrzymania Centrum Informacyjnego dla Obywateli - Call Center - zwanego dalej CC.

CC powinno pełnić rolę „pomocy na telefon” i powinno obsłużyć dziennie około 500 pytań dotyczących uprawnień do kierowania pojazdami i 100 pytań dotyczących rejestracji pojazdów.

CC powinno być wyposażone w stanowiska robocze pozwalające na przekazywanie obywatelom informacji na temat:

1. spraw które można załatwić w punktach rejestracji

2. dokumentów wymaganych dla każdej sprawy

3. sposobu korzystania z usług pre-rejestracji

Telefoniczne centrum informacyjne dostępne ma być w godzinach od 8-18 oraz zapewniać, że 90% połączeń w godzinach dostępności centrum odebrane zostanie przed upływem 50 sekund od momentu wybrania numeru. Stopa błędnych odpowiedzi udzielanych przez call--center nie powinna przekraczać 1%.

Zamawiające zastrzega sobie możliwość monitorowania poziomów obsługi w tym obszarze poprzez wyrywkową kontrolę raportów (ekstraktów danych) z urządzeń i oprogramowania telekomunikacyjnego call--center oraz nagrań rozmów. Infrastruktura wykorzystywana przez dostawcę w call--center musi pozwalać na dostarczenie Zamawiającemu wymienionych raportów i nagrań.

10. Produkcja i dystrybucja CD-ROM-ów z danymi do naliczania podatku od środków transportu

Raz w roku Podmiot Utrzymania produkuje na zlecenie Zamawiającego zestaw CD-ROM-ów z danymi potrzebnymi do naliczenia podatku od środków transportu oraz dokonuje ich dystrybucji do starostw (szczegółowe zasady dystrybucji będą przedmiotem ustaleń w trakcie prac projektowych). Czas realizacji tego zlecenia nie powinien przekraczać sześciu tygodni, licząc od mementu jego przekazania przez Zamawiającego do dostarczenia wyprodukowanych CD-ROM-ów do odpowiednich starostw.

Średni czas oczekiwania na połączenie z I linią wsparcia (A)

Maksymalny czas oczekiwania na połączenie z I linią wsparcia (B).

Średni czas reakcji II lini wsparcia ( C )

Maksymalny czas reakcji II linii wsparcia (D).

Średni czas identyfikacji przyczyny problemu ( E )

Maksymalny czas identyfikacji przyczyny (F)

Średni czas likwidacji problemów konfiguracyjnych i administracyjnych (G).

Maksymalny czas likwidacji problemów konfiguracyjnych i administracyjnych (H).

Średni czas usuwania błędu krytycznego niewymagającego ustaleń (I).

Maksymalny czas usuwania błędu krytycznego niewymagającego ustaleń (J).

Średni czas identyfikacji błędu krytycznegoi wymagającego ustaleń (K).

Maksymalny czas identyfikacji błędu krytycznego wymagającego ustaleń (L)

Średni czas gotowości do prac analitycznych (M)

Maksymalny czas gotowości do prac analitycznych (N).

Średni czas naprawy błędu krytycznego po poczynieniu ustaleń (O).

Maksymalny czas naprawy błędu krytycznego po poczynieniu ustaleń (P).

Obsługa ewidencji pojazdów w powiatach, ew. badań techn. i złomowań

30 s

180 s

15 min.

1 h

30 min.

1,5 h

1 h

24 h

24 h

72 h

8 h

24 h

12 h

36 h

24 h

72 h

Obsługa ewidencji kierowców w powiatach

30 s

180 s

15 min.

1 h

30 min.

1,5 h

1 h

24 h

24 h

72 h

8 h

24 h

12 h

36 h

24 h

72 h

Udostępnianie informacji dla Policji i Straży Granicznej — tryb automatyczny—operacyjny

30 s

180 s

15 min.

1 h

30 min.

1,5 h

1 h

24 h

24 h

72 h

8 h

24 h

12 h

36 h

24 h

72 h

Obsługa pojazdów specjalnych — ewidencja

2 min.

5 min.

4 h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Obsługa pojazdów specjalnych — ochrona przed dekonspiracją

30 s

180 s

15 min.

1 h

30 min.

1,5 h

1 h

24 h

24 h

72 h

8 h

24 h

12 h

36 h

24 h

72 h

Udostępnianie informacji — tryb urzędowy

2 min.

5 min.

4 h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Udostępnianie informacji dla UFG

30 s

180 s

15 min.

1 h

30 min.

1,5 h

1 h

24 h

24 h

72 h

8 h

24 h

12 h

36 h

24 h

72 h

Udostępnianie informacji — tryb automatyczny-dochodzeniowy

2 min.

5 min.

4 h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Ewidencja polis OC

2 min.

5 min.

4 h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Ewidencja czynności Policji

30 s

180 s

15 min.

1 h

30 min.

1,5 h

1 h

24 h

24 h

72 h

8 h

24 h

12 h

36 h

24 h

72 h

Komercyjne udostępnianie informacji

2 min.

5 min.

4 h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Pozyskiwanie danych referencyjnych^*

2 min.

5 min.

4 h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Ewidencja podmiotów uczestniczących w obrocie pojazdami

2 min.

5 min.

4h

24 h

6 h

30 h

8 h

72 h

72 h

7 dni

48 h

5 dni

72 h

5 dni

72 h

7 dni

Tabela 18 Zestawienie zakładanych charakterystyk czasowych serwisu systemu CEPiK.

^* Parametry serwisu w obszarze pozyskiwania danych referencyjnych dotyczą problemów zgłaszanych przez obsługę systemów źródłowych lub przez personel MSWiA uczestniczący w ręcznych procedurach pozyskiwania danych. W przypadku problemów zgłaszanych przez użytkowników innych procesów, obowiązują parametry odpowiednie dla tych procesów.

Słownik pojęć

?-cykl systemu	Zakres aplikacyjny systemu, który został przygotowany do wdrożenia, niekoniecznie obejmujący pełną projektowaną funkcjonalność systemu. Inaczej - kolejna iteracja w procesie dochodzenia do pełnej projektowanej funkcjonalności systemu.
Aktualizacja centralnych baz danych	Ostatni etap transakcji bazodanowej, w którym następuje modyfikacja zapisów w bazie danych, tzn. następuje zastąpienie danej inną, dana jest usuwana, dana jest dodawana.
Alokacja zasobów	Alokacja zasobów z CZ do CP oznacza alokację danych a nie alokację sprzętu. Konfiguracje sprzętowe, poprzedzające tę alokację, w obydwu centrach powinny być ewentualnie poprawione i doprowadzone do docelowego stanu oczekiwanego.
Analityczna baza danych	Hurtownia danych.
Analiza ryzyka	Proces identyfikacji ryzyka, określenia jego wielkości i identyfikowania obszarów wymagających zabezpieczeń
Autentyczność	Właściwość zapewniająca, że tożsamość podmiotu lub zasobu jest taka, jak deklarowana. Odnosi się do użytkowników, procesów, systemów i informacji.
Badania techniczne	Okresowe, obowiązkowe badania prowadzone przez uprawnione Stacje Badań Technicznych, dopuszczające pojazd do ruchu.
Baza danych	Zbiór danych zorganizowany zgodnie z pojęciową strukturą opisującą charakterystyki tych danych oraz związki między ich odpowiednimi elementami, stosowany w jednym lub wielu zastosowaniach.
Bezpieczeństwo systemu informatycznego	Wszystkie aspekty związane z definiowaniem, osiąganiem i utrzymywaniem poufności, integralności, dostępności, rozliczalności, autentyczności i niezawodności
Centralne bazy danych	Bazy utrzymywane na serwerach w CP, na które składają się: centralna ewidencja pojazdów, centralna ewidencja pojazdów specjalnych, centralna ewidencja kierowców.
Centrum przetwarzania danych	Centrum komputerowe: budynek lub jego wydzielona część, w którym posadowiono centralna część systemu CEPiK wraz z pełną infrastrukturą techniczna i administracyjno-gospodarczą, zabezpieczająca jego funkcjonalność
CP	Centrum Podstawowe - podstawowe centrum przetwarzania danych, obsługujące warstwę centralną systemu.
CZ	Centrum Zapasowe - zapasowe centrum przetwarzania danych, obsługujące warstwę centralną systemu w przypadku awarii centrum podstawowego.
Dostępność	Właściwość bycia dostępnym i możliwym do wykorzystania na żądanie, w założonym czasie, przez autoryzowany podmiot
Demon	Złożone w swojej konstrukcji zapytanie SQL do bazy danych, pracujące w „tle”, tzn. niezależnie od obsługi administracyjnej systemu.
Eksploatacja Systemu	Czynności związane z eksploatacją systemu, w tym głównie: konserwacja prewencyjna, serwis sprzętu, obsługa zgłoszeń serwisowych, utrzymanie oprogramowania systemowego i narzędziowego, utrzymanie oprogramowania aplikacyjnego, wsparcie użytkowników, administrowanie systemem, zabezpieczanie danych, usuwanie awarii, budowa i realizacja planów awaryjnych, strojenie i optymalizacja systemu, zarządzanie konfiguracją systemu, zarządzanie środkami trwałymi przekazanymi przez Zamawiającego Dostawcy w użyczenie.
HW	Sprzęt komputerowy (serwery i sprzęt towarzyszący).
Integralność	Właściwość zapewniająca, że dane nie zostały zmienione lub zniszczone w sposób nieautoryzowany.
Kierowca	Osoba posiadająca uprawnienia do kierowania pojazdami
Kontrola kompletności danych	Ciąg czynności, najczęściej wbudowanych w transakcję bazodanową, którego celem jest sprawdzenie, czy w kontrolowanej partii danych są wszystkie potrzebne, przewidziane w projekcie, dane.
Kontrola zgodności danych	Ciąg czynności, najczęściej wbudowanych w transakcję bazodanową, którego celem jest sprawdzenie, czy w kontrolowanej partii danych dane są zgodne z przyjętym kryterium zgodności.
Kontrola zgodności danych z rejestrami referencyjnymi	Ciąg czynności, najczęściej wbudowanych w transakcję bazodanową, którego celem jest sprawdzenie, czy w kontrolowanej partii danych dane są zgodne z danymi o kontrolowanym obiekcie zapisanymi w innych bazach danych według przyjętego kryterium zgodności. W wyniku niezgodności dane mogą być w transakcji „nadpisane” z bazy referencyjnej lub transakcja może być uznana za niezgodną.
Kontrola zgodności ze słownikami ITS	Ciąg czynności, najczęściej wbudowanych w transakcję bazodanową, którego celem jest sprawdzenie, czy w kontrolowanej partii danych o pojeździe dane dotyczące marki, typu, koloru nadwozia pojazdu istnieją w katalogach ITS.
MCEK	Migracyjna baza danych kierowców
MCEP	Migracyjna baza danych pojazdów (normalnych)
MCEP-S	Migracyjna baza danych pojazdów specjalnych
Niezawodność	Właściwość oznaczająca spójne, zamierzone zachowanie i skutki
NIP	Rejestr zawierający dane o płatnikach podatku, identyfikowane unikalnym kluczem.
Oprogramowanie aplikacyjne	Zestaw programów lub program przeznaczony do rozwiązania konkretnego problemu
Oprogramowanie narzędziowe -	Zestaw programów lub program, który wspomaga rozwijanie, utrzymanie lub użytkowanie innego oprogramowania, a także wykazuje cechy ogólnie użyteczne, niezależne od konkretnych zastosowań.
Oprogramowanie systemowe	Oprogramowanie niezależne od zastosowań, które wspomaga działanie oprogramowania aplikacyjnego.
PESEL	Rejestr państwowy zawierający dane o obywatelach zamieszkałych na terenie RP, identyfikowane unikalnym kluczem.
Pojazd	Jeżeli nie obok niego przymiotnika „specjalny” to oznacza to normalny, cywilny pojazd, którego właścicielem jest osoba prywatna lub instytucja cywilna.
Pojazd specjalny	Pojazd zarejestrowany i użytkowany przez: Policję Straż Graniczną, Straż Pożarną, MON, Żandarmerię Wojskową, Wojskowe Służby Informacyjne, Agencję Bezpieczeństwa Wewnętrznego, Biuro Ochrony Rządu.
Portal	W znaczeniu tego opracowania może to być zarówno witryna internetowa jak również inny kanał komunikacyjny umożliwiający wejście uprawnionego podmiotu do uprawnionych zasobów.
Procedura administracyjna	Uporządkowany zestaw czynności, potrzebny do załatwienia sprawy obywatela lub sprawy w sprawie obywatela wniesionej z urzędu.
Przepływy między-serwerowe	Przekazywanie danych z jednego serwera do innego poprzez łącze telekomunikacyjne dedykowane dla tych serwerów. W znaczeniu tego opracowania przepływy tego typu będą miały miejsce pomiędzy serwerem komunikacyjnym systemu CEPiK a serwerami wielu podmiotów zewnętrznych (Policja, UFG, SG, ...).
REGON	Rejestr państwowy, zawierający dane o instytucjach i firmach działających na terenie RP, identyfikowane unikalnym kluczem.
Rozliczalność	Właściwość zapewniająca, że działania podmiotu mogą być przypisane w sposób jednoznaczny tylko temu podmiotowi.
Rozwój Systemu	Na rozwój systemu składają się dwie grupy prac: Prace projektowo-wdrożeniowe konieczne dla przejścia z funkcjonalności minimalnej do funkcjonalności docelowej wykonywane w ramach przedsięwzięcia. Do prac tych należy zaliczyć prace projektowe, budowa aplikacji, prace instalacyjne, konfiguracyjne, optymalizacyjne, integracyjne. Prace poprawiające wydajność systemu, dostosowujące go do zmian legislacyjnych oraz do istotnych zmian technologicznych z zakresu IT. Prace te mają charakter ciągły.
Ryzyko	Prawdopodobieństwo, że określone zagrożenie wykorzysta podatność zasobu lub grupy zasobów, aby spowodować straty lub zniszczenie zasobów
Sieć LAN w wydziale komunikacji starostwa	Lokalna teleinformatyczna sieć, łącząca stanowiska robocze z serwerem lokalnym w wydziale komunikacji starostwa, wykorzystywana do realizacji procedur administracyjnych związanych z rejestracją kierowców.
Sieć PESEL-NET	Sieć PESEL-NET jest rozległą siecią resortu spraw wewnętrznych i administracji, obejmującą swoim zasięgiem obszar całego kraju, wykorzystywaną do transmisji danych, charakteryzującą się m.innymi następującymi cechami: jest siecią dedykowana dla transmisji danych; ma ogólnokrajowy zasięg; posiada topologię gwiazdy bardzo wygodną dla budowy systemów teleinformatycznych o centralnej architekturze - jeden serwer bazodanowy i wielu rozproszonych użytkowników; może być w miarę potrzeb w prosty sposób rozbudowywana; wykorzystuje protokoły sieciowe X.25 i FRAME-RELAY; jest siecią wydzieloną, zarządzaną i administrowaną przez MSWiA, co gwarantuje bezpieczeństwo posadowionych na niej systemów.
Skalowalność	Możliwość zwiększenia wydajności systemu lub jego poszczególnych składników, poprzez ich rozbudowę (up'grade).
SLA	Service Level Agreement - umowa poziomu usług serwisowych regulująca relacje pomiędzy Zamawiającym a Podmiotem Utrzymania.
Słowniki ITS	Utrzymywane przez Instytut Transportu Samochodowego i udostępniane użytkownikom aktualne katalogi (pliki) marek i typów pojazdów oraz kolorów lakierów.
Stacje Badań Technicznych	Uprawnione przez starostę zakłady na terenie powiatu, które mają prawo prowadzić okresowe, obowiązkowe badania techniczne.
TERYT	Rejestr państwowy zawierający dane o jednostkach terytorialnych RP, identyfikowane unikalnym kluczem.
Transakcja bazodanowa	Ciąg czynności wykonywanych przez aplikację, zaczynający się od identyfikacji zawartości informacyjnej a kończący się ustaleniem statusu zakończenia, którym może być w szczególności potwierdzenie transakcji i aktualizacja zawartości bazy danych lub odmowa przyjęcia danych.
Transakcja rozproszona	Transakcja bazodanowa, która w trakcie realizacji korzysta z rozproszonego środowiska sprzętowego, systemowego lub aplikacyjnego.
Tryb bezpośredni (on-line)	Przetwarzanie rekordu bezpośrednio po jego wprowadzeniu do pamięci, bez pośrednictwa pliku.
Tryb wsadowy (off-line)	Przetwarzanie sekwencji rekordów zapisanych w pliku, wprowadzonych do pliku dowolnie wcześnie w stosunku do momentu przetwarzania.
Typowanie	Pytanie kierowane do systemu, którego wynikiem jest zbiór danych (pojazdów/kierowców), spełniających zadane kryteria.
Warstwa Centralna Systemu	Infrastruktura narzędziowa, systemowa, hardware'owa i oprogramowanie aplikacyjne, pozwalające na realizację funkcji przypisanych dla CP i CZ
Warstwa Lokalna Systemu	Infrastruktura narzędziowa, systemowa, hardware'owa i oprogramowanie aplikacyjne, pozwalające na realizację funkcji przypisanych: starostwom i innym organom uprawnionym do obsługi obywateli i instytucji w zakresie rejestracji pojazdów i wydawania praw jazdy, stacjom badań technicznych w zakresie ewidencji badań pojazdów.
WEP	Wojewódzka Ewidencja Pojazdów.
Weryfikacja	Pytanie skierowane do systemu w celu udzielenie odpowiedzi, czy zestaw danych dotyczący opisywanego obiektu jest zgodny z informacjami zawartymi w systemie i rejestrach referencyjnych.
Wykonanie Systemu	Wykonanie systemu obejmujące: pogłębioną analizę obszaru systemu, projekt techniczny, zarządzanie przedsięwzięciem (po stronie Dostawcy), dostawę sprzętu, oprogramowania systemowego, narzędziowego oraz wykonanie i udokumentowanie oprogramowania aplikacyjnego
Zabezpieczenie	Praktyka, procedura lub mechanizm redukujący ryzyko.
Zagrożenie	Potencjalna przyczyna niepożądanego incydentu, którego skutkiem może być szkoda dla systemu lub instytucji.

Spis tabel

Spis diagramów

Załącznik nr 4.1 - [Bezpieczeństwo]

do „Opisu przedmiotu zamówienia

na wykonanie, wdrożenie

oraz obsługę eksploatacyjną i rozwój

systemu informatycznego wraz z robotami budowlanymi (adaptacyjnymi) przeznaczonymi na ten cel”

Wymagania bezpieczeństwa

dla systemu teleinformatycznego CEPiK

1. Polityka bezpieczeństwa systemu CEPiK

Zamawiający oświadcza, że wobec dostawców, wykonawców, użytkowników i podmiotu eksploatującego system stosowane będą wszelkie przepisy polskiego prawa państwowego w zakresie przestrzegania tajemnicy, w tym szczególnie tajemnicy służbowej, we wszystkich etapach budowy i eksploatacji systemu. Zamawiający odpowiedzialny jest za przestrzeganie tych przepisów. Dostawcy, wykonawcy, użytkownicy i podmiot odpowiedzialny za obsługę eksploatacyjną i serwisowanie systemu, zobowiązani są do przestrzegania przepisów prawa.

Niezależnie od powyższego, Zamawiający stwierdza, że będzie wymagał przestrzegania aspektów bezpieczeństwa określonych w niniejszym dokumencie, a szczególnie wynikających z realizacji tych aspektów - sformułowanych już na etapie budowy systemu, procedur jego bezpiecznej eksploatacji.

1.1. Bezpieczeństwo strategiczne systemu

Zamawiający wymaga od Dostawcy systemu informatycznego zapewnienia pełnego bezpieczeństwa oferowanego rozwiązania, a w szczególności bezpieczeństwa strategicznego systemu. Bezpieczeństwo strategiczne systemu w rozumieniu niniejszego dokumentu, oznacza brak silnego uzależnienia systemu od konkretnych firm, dostawców technologii wykorzystywanych w jego konstrukcji. Uzależnienie to przejawiać się może przede wszystkim w potrzebie wsparcia technicznego, usuwania błędów i unowocześniania produktów.

Zamawiający oczekuje od Dostawcy zaproponowania i zastosowania takich rozwiązań technicznych, organizacyjnych, prawnych i/lub w innych koniecznych obszarach, które w dłuższym horyzoncie czasu zapewnią wymaganą niezależność systemu od wsparcia i utrzymania produktów przez ich dostawców. Zamawiający zaleca rozwiązanie tego problemu w sferze architektury systemu, która powinna być tak dobrana, aby ewentualna zmiana dostawcy technologii w działającym systemie, była przedsięwzięciem o charakterze migracji systemu (niewymagającym rozległej jego przebudowy). Zalecanym sposobem osiągnięcia tego celu jest zastosowanie rozwiązań zgodnych ze standardami zdefiniowanymi przez powszechnie uznane organizacje i grupy (np. J2EE, CORBA, XML, X/Open, SQL92, WfMC, itp.) oraz przenośnych ze względu na platformy systemowe i sprzętowe.

Zamawiający dopuszcza też inne sposoby rozwiązania problemu strategicznego bezpieczeństwa systemu zarówno w obszarze architektury systemu (np. uwzględnienie w architekturze systemu odpowiednich warstw abstrakcji od znajdującej się „pod spodem” technologii), jak również w obszarze prawno-organizacyjnym (np. udostępnienie lub zdeponowanie na określonych warunkach kodów źródłowych i wewnętrznej dokumentacji technicznej zastosowanych produktów). Oferenci w proponowanych przez siebie rozwiązaniach technicznych, muszą wskazać sposób zapewnienie strategicznego bezpieczeństwa systemu w odniesieniu do poszczególnych proponowanych do wykorzystania produktów.

1.2. Realizatorzy polityki bezpieczeństwa na etapie budowy systemu

Na etapie budowy systemu, w realizacji polityki bezpieczeństwa uczestniczą:

• Generalny Przedstawiciel Zamawiającego,

• Kierownik Projektu ze strony Zamawiającego,

• Specjaliści MSWiA (Departamentu Rejestrów Państwowych, Biura Ochrony Informacji Niejawnych, Biura Administracyjno - Gospodarczego),

• wskazani przez Zamawiającego audytorzy,

• Dostawca systemu informatycznego,

• Dostawca systemu teletransmisyjnego,

• wykonawca zapasowego centrum komputerowego,

• wykonawca podstawowego centrum komputerowego,

• starostowie,

• podmioty współpracujące (UFG, Policja, MON, WSI, ŻW, Straż Graniczna, BOR, ABW, AW).

1.3. Wykonawcy polityki bezpieczeństwa na etapie eksploatacji systemu

Na etapie eksploatacji systemu, w realizacji polityki bezpieczeństwa uczestniczą:

• Grupa specjalistów Departamentu Rejestrów Państwowych MSWiA i Biura Ochrony Informacji Niejawnych MSWiA - sprawująca funkcje kontrolne i koordynujące w zakresie realizacji polityki bezpieczeństwa,

• podmiot odpowiedzialny za obsługę eksploatacyjną systemu - w zakresie bezpiecznej eksploatacji systemu,

• użytkownicy systemu - każdy z nich w zakresie elementów systemu znajdujących się w ich kompetencji:

• współpracujący z systemem niekomercyjnie (w trybach urzędowym i automatycznym):

• użytkownicy systemu,

• użytkownicy systemu obsługi specjalnej,

• współpracujący z systemem komercyjnie:

• uzyskujący informacje na zasadzie jednorazowej,

• uzyskujący informacje na zasadzie stałej współpracy,

• inne podmioty uprawnione do uzyskiwania informacji z systemu (obywatele, instytucje).

• wybrany przez pełnomocnika ochrony informacji niejawnych MSWiA audytor (okresowo) - w zakresie każdorazowo zdefiniowanych do wykonania granic audytu,

• wydzielony w okresie wdrażania systemu z pracowników MSWiA i Dostawcy `systemu informatycznego zespół, zapewniający funkcjonowanie systemu kryptograficznej ochrony informacji (w tym infrastruktury PKI) - w zakresie funkcjonowania elementów ochrony kryptograficznej.

1.4. Zakres realizacji polityki bezpieczeństwa systemu

System teleinformatyczny CEPiK należy do klasy systemów rozległych, a jego elementy będą zlokalizowane na obszarze całego kraju. Zobowiązuje to właściwe terenowo podmioty do podejmowania ustawowych działań w zakresie ochrony informacji dotyczących elementów systemu znajdujących się w ich kompetencji, a dostawców elementów systemu, do ścisłej współpracy z pionami ochrony właściwych terenowo podmiotów, na etapie budowy i eksploatacji systemu.

System CEPiK będzie wytwarzał, przetwarzał, przechowywał i przekazywał informacje niejawne stanowiące tajemnicę służbową, przy czym dla informacji przetwarzanych przez użytkowników systemu na poziomie starostw oraz innych podmiotów i instytucji wymieniających z systemem dane w trybie automatycznym, (za wyjątkiem procesu udostępniania pojedynczych informacji czyli prostych zapytań standardowych w trybie automatyczno - dochodzeniowym i automatyczno - operacyjnym), przyjęto klauzulę „zastrzeżone”. Podmioty uzyskujące dane z systemu w trybie urzędowym, również zobowiązane są do przestrzegania prawa o ochronie tajemnicy - szczególnie w zakresie postępowania z dokumentami zawierającymi informacje niejawne. Dla informacji przetwarzanych przez użytkowników systemu obsługi specjalnej, przyjęto klauzulę „poufne”, z wyjątkiem jednego z użytkowników, który zostanie określony w trakcie budowy systemu. W celu zbudowania elementów systemu dla tego wyodrębnionego użytkownika, który będzie przetwarzać w systemie informacje stanowiące tajemnicę państwową o klauzuli „tajne”, może być przeprowadzone odrębne zamówienie publiczne.

Ustalenia powyższe, zobowiązują właściwe terytorialnie organa administracji publicznej oraz inne podmioty i instytucje będące użytkownikami systemu, do stosowania przepisów prawa o ochronie informacji niejawnych, w tym szczególnie ustawy z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych (Dz. U. Nr 11, poz. 95 z późn. zmianami) oraz rozporządzenia Prezesa Rady Ministrów z dnia 25 lutego 1999 r. w sprawie podstawowych wymagań bezpieczeństwa systemów i sieci teleinformatycznych (Dz. U. nr 18, poz. 162). Oznacza to, że wymienione organy oraz podmioty i instytucje muszą zapewnić bezpieczeństwo teleinformatyczne dla budowanych i eksploatowanych elementów systemu, poprzez realizację określonych w powyższym prawie zadań (szczególnie ochrony fizycznej, kryptograficznej oraz kontroli dostępu do urządzeń) i wytycznych pionu ochrony systemu CEPiK, które zostaną sformułowane na kolejnych etapach budowy systemu.

Zakres realizacji polityki bezpieczeństwa systemu teletransmisyjnego CEPiK, ze szczególnym uwzględnieniem zadań przewidzianych do realizacji przez dostawców i wykonawców, przedstawiono poniżej.

1.4.1. Ochrona fizyczna systemu

Ochrona fizyczna systemu CEPiK będzie realizowana poprzez:

• wyznaczenie strefy administracyjnej i strefy bezpieczeństwa, stosownie do klauzuli informacji przetwarzanych w elementach systemu,

• wyznaczenie pomieszczeń posadowionych w strefach systemu i instalację środków zabezpieczających te pomieszczenia przed nieuprawnionym dostępem, podglądem lub podsłuchem, stosownie do klauzuli informacji przetwarzanych w tych elementach systemu,

• umieszczenie urządzeń elementów systemu w pomieszczeniach strefy administracyjnej lub strefy bezpieczeństwa, stosownie do klauzuli informacji przetwarzanych w elementach systemu,

• organizację i zapewnienie funkcjonowania kontroli dostępu do stref i pomieszczeń w których zainstalowano urządzenia elementów systemu, stosownie do klauzuli przetwarzanych informacji.

Odpowiedzialnymi za realizację powyższych przedsięwzięć są:

• na etapie budowy systemu:

• w wydziałach komunikacji - właściwy starosta - zgodnie z obowiązującym prawem i wytycznymi Zamawiającego (MSWiA),

• w innych organach, podmiotach i instytucjach - właściwy kierownik (szef) organu, podmiotu lub instytucji - zgodnie z obowiązującym prawem i wytycznymi Zamawiającego (MSWiA),

• w zapasowym centrum komputerowym - wykonawca zapasowego centrum komputerowego w ścisłej współpracy z Dostawcą systemu informatycznego i Dostawcą systemu teletransmisyjnego oraz wyznaczonym przez Zamawiającego pionem ochrony,

• w podstawowym centrum komputerowym - wykonawca podstawowego centrum komputerowego w ścisłej współpracy z Dostawcą systemu informatycznego i Dostawcą systemu teletransmisyjnego oraz wyznaczonym przez Zamawiającego pionem ochrony,

• na etapie eksploatacji systemu:

• w wydziałach komunikacji - właściwy starosta - zgodnie z procedurami bezpiecznej eksploatacji,

• w innych organach, podmiotach i instytucjach - właściwy kierownik (szef) organu, podmiotu lub instytucji - zgodnie z procedurami bezpiecznej eksploatacji,

• w zapasowym centrum komputerowym - podmiot odpowiedzialny za obsługę eksploatacyjną systemu, w ścisłej współpracy z wyznaczonym przez Zamawiającego pionem ochrony - zgodnie z procedurami bezpiecznej eksploatacji,

• w podstawowym centrum komputerowym - podmiot odpowiedzialny za obsługę eksploatacyjną systemu, w ścisłej współpracy z wyznaczonym przez Zamawiającego pionem ochrony - zgodnie z procedurami bezpiecznej eksploatacji.

Dostawcy i wykonawcy zobowiązani są do ścisłej współpracy z wyznaczonym przez Zamawiającego pionem ochrony - ze szczególnym uwzględnieniem procesu opracowywania przez Zamawiającego „Szczególnych wymagań bezpieczeństwa systemu” i wynikających z tego dokumentu, procedur bezpiecznej eksploatacji systemu.

Pozostałe wymagania Zamawiającego dotyczące elementów ochrony fizycznej, zawierają kolejne podrozdziały.

1.4.1.1. Ochrona fizyczna części centralnej systemu

Część centralna systemu posadowiona będzie w dwóch rozdzielonych fizycznie ośrodkach: zapasowym zlokalizowanym w zbudowanym do tego celu budynku około 40 km od Warszawy i podstawowym zlokalizowanym w Warszawie na terenie MSWiA. Budowa obydwóch obiektów zrealizowana będzie przez MSWiA Przewiduje się w pierwszej kolejności uruchomienie i eksploatację zapasowego centrum komputerowego a w następnej, podstawowego centrum komputerowego. Podjęto decyzję, że informacje przetwarzane w zapasowym i podstawowym centrum komputerowym a także zainstalowany w tych centrach sprzęt (zasoby materialne systemu), stanowią tajemnicę służbową o klauzuli „poufne”- muszą być zatem chronione zgodnie z przepisami prawa i wymaganiami przedstawionymi we wstępie rozdziału 1.4. i w podrozdziale 1.4.1.

Szczegółowe wymagania ochrony fizycznej zapasowego centrum komputerowego, nie stanowią przedmiotu niniejszego zamówienia i będą realizowane:

• przez Zamawiającego w zakresie:

• wyznaczenia i organizacji stref bezpieczeństwa,

• zapewnienia funkcjonowania służb ochrony osobowej i kontroli (w tym kontroli gości),

• zabezpieczenia dokumentów i nośników informacji,

• zabezpieczenia przed sabotażem i terroryzmem,

• przez wykonawcę zapasowego centrum komputerowego, według wymagań Zamawiającego w zakresie:

• zabezpieczeń architektonicznych i budowlanych,

• zabezpieczeń mechanicznych,

• elektronicznych systemów alarmowych wspierających kontrolę stref bezpieczeństwa,

• zabezpieczenia przed podglądem, podsłuchem i ulotem elektromagnetycznym,

• spełnienia wymagań wynikających z przepisów o ochronie przeciwpożarowej.

Szczegółowe wymagania ochrony fizycznej podstawowego centrum komputerowego są w

warstwie organizacyjnej i technicznej identyczne. Ewentualne zmiany zaproponowane przez wykonawcę, mogą jedynie poprawiać poziom bezpieczeństwa i będą wzięte pod uwagę na etapie projektowania centrum podstawowego.

Niezależnie od realizacji powyższych wymagań, Zamawiający przewiduje budowę przez wykonawcę zapasowego centrum komputerowego budynku (z wydzielonym przyziemiem), który zawierał będzie pomieszczenia bezpośrednio i pośrednio istotne dla zlokalizowania elementów systemu informatycznego.

1.4.1.2. Ochrona fizyczna elementów systemu zlokalizowanych w starostwach oraz innych podmiotach i instytucjach uzyskujących dane w trybie automatycznym

Ochrona fizyczna elementów systemu zlokalizowanych w starostwach oraz innych podmiotach i instytucjach uzyskujących dane w trybie automatycznym, będzie zrealizowana zgodnie z zasadami określonymi w punkcie 1.4.1. i nie stanowi przedmiotu niniejszego zamówienia.

1.4.1.3. Ochrona fizyczna elementów systemu zlokalizowanych w Policji, MON, WSI, ŻW, SG, BOR, ABW, AW, służących do obsługi bazy specjalnej pojazdów

Ochrona fizyczna elementów systemu (w tym serwerów dedykowanych specjalnych) zlokalizowanych w Policji, MON, WSI, ŻW, SG, BOR, ABW, AW, służących do obsługi bazy specjalnej pojazdów, będzie zrealizowana zgodnie z zasadami określonymi w punkcie 1.4.1. i nie stanowi przedmiotu niniejszego zamówienia. Serwer dostępowy obsługujący serwery dedykowane specjalne w/w podmiotów będące ich własnością, zlokalizowany będzie w strefie części centralnej systemu, zgodnie z wymaganiami dla części centralnej.

1.4.2. Ochrona kryptograficzna i ochrona dostępu do systemu przez osoby upoważnione

Ochrona kryptograficzna stanowi najważniejszy element realizacji polityki bezpieczeństwa MSWiA w odniesieniu do systemu teleinformatycznego CEPiK. Wnioski z z analizy ryzyka przeprowadzonej przez Zamawiającego, wskazują możliwość wystąpienia następujących zagrożeń dla bezpiecznej eksploatacji systemu:

• podsłuch - nielegalne przejęcie informacji zawartych w dokumencie lub danych identyfikujących użytkownika systemu poprzez monitorowanie łącza telekomunikacyjnego,

• modyfikacja - nieuprawniona zmiana treści dokumentu podczas przesyłania środkami telekomunikacyjnymi,

• maskarada - podszycie się pod legalnego nadawcę lub adresata (wysyłanie lub odbieranie dokumentów z nieautoryzowanego adresu w imieniu legalnego użytkownika systemu),

• powtarzanie - ponowne przesyłanie zarejestrowanej z łącza telekomunikacyjnego wiadomości, w celu uzyskania nienależnych świadczeń lub spowodowanie zakłóceń w systemie,

• opóźnienie - zarejestrowanie przesyłanego dokumentu i przesłanie do adresata z opóźnieniem powodującym straty,

• zaprzeczenie - wypieranie się wysłania dokumentu (np. polecenia służbowego, zlecenia produkcji, itp.),

W celu uniknięcia przedstawionych zagrożeń i osiągnięcia bezpieczeństwa przesyłania dokumentów elektronicznych, Zamawiający wymaga zastosowania mechanizmów kryptograficznych klucza publicznego PKI, gwarantujących realizację następujących aspektów bezpieczeństwa:

• poufność, czyli ochronę przed ujawnieniem informacji nieuprawnionemu odbiorcy,

• integralność danych, czyli zabezpieczenie przed modyfikacją, zniekształceniem lub zniszczeniem wiadomości przez osobę nieuprawnioną,

• integralność systemu informatycznego, czyli zabezpieczenie przed nieautoryzowaną zmianą jego zamierzonych funkcji,

• autentyczność, czyli weryfikację tożsamości użytkowników systemu i prawdziwości przesyłanej wiadomości,

• rozliczalność, czyli określenie i weryfikowanie odpowiedzialności za działania, usługi i funkcje realizowane za pośrednictwem systemu.

Przedmiotem niniejszego zamówienia, w kontekście założeń polityki bezpieczeństwa dla Centralnej Ewidencji Pojazdów i Kierowców, jest zaprojektowanie, wykonanie i wdrożenie do eksploatacji infrastruktury klucza publicznego PKI spełniającego zachowanie powyższych aspektów.

Zakłada się, że system kryptograficznej ochrony informacji oparty na infrastrukturze klucza publicznego PKI, będzie obsługiwał około 4 000 urządzeń końcowych (około 5 500 użytkowników) z uprawnionych podmiotów rejestrujących (określonych w rozdziale 5.5.3. „Opisu przedmiotu zamówienia”) i musi posiadać własne - zlokalizowane w części centralnej systemu, centrum certyfikacji i generacji kluczy. Centrum powinno być wyposażone docelowo w dwa komplety urządzeń, przeznaczonych do realizacji jego funkcji w ramach systemu CEPiK (urządzenia zlokalizowane w zapasowym i podstawowym centrum komputerowym).

Zamawiający oczekuje od dostawcy, że elementy infrastruktury PKI pracujące w powyższym systemie, będą spełniać następujące wymagania:

• w zakresie Centrum Certyfikacji i Generacji Kluczy:

Centrum Certyfikacji i Generacji Kluczy musi realizować następujące funkcje:

• generowanie kluczy dla użytkowników systemu (algorytm RSA o długości minimalnej 1024 bity lub DSA o długości minimalnej 1024 bity),

• przyjmowanie i obsługa zgłoszeń certyfikacyjnych,

• wydawanie i zarządzanie certyfikatami (wersja certyfikatu X.509 v.3),

• tworzenie i publikowanie listy unieważnionych certyfikatów i zaświadczeń certyfikacyjnych.

Centrum Certyfikacji i Generacji Kluczy musi realizować powyższe funkcje dla certyfikatów kluczy wykorzystywanych do:

• usługi uwierzytelnienia - podpis elektroniczny

• usługi poufności - szyfrowanie.

Centrum Certyfikacji i Generacji Kluczy musi umożliwiać zapisywanie kluczy prywatnych i publicznych, oraz certyfikatu i zaświadczenia certyfikacyjnego na karty mikroprocesorowe.

Centrum Certyfikacji i Generacji Kluczy musi umożliwiać realizowanie usług certyfikacyjnych w ramach co najmniej pięciu polityk certyfikacji.

Centrum Certyfikacji i Generacji Kluczy musi posiadać ośrodek zapasowy zdolny przejąć pełną funkcjonalność ośrodka podstawowego.

Organizacja, infrastruktura techniczna i teleinformatyczna, w tym urządzenie służące do generowania kluczy oraz wydawania certyfikatów muszą spełniać wymagania określone dla bezpiecznego podpisu elektronicznego w:

• ustawie z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. 2001 Nr 130, poz. 1450),

• rozporządzeniu Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego,

• ustawie z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych wraz z późniejszymi zmianami (Dz.U. Nr 11, poz. 95),

• rozporządzeniu Prezesa Rady Ministrów z dnia 25 lutego 1999 r. w sprawie podstawowych wymagań bezpieczeństwa systemów i sieci teleinformatycznych (Dz.U. Nr 18, poz. 162).

Wymaga się, aby urządzenia służące do generowania kluczy oraz wydawania certyfikatów wykorzystywanych dla informacji poufnych, posiadały certyfikat o klauzuli „poufne” wydany przez właściwą służbę ochrony Państwa.

• w zakresie realizacji systemu uwierzytelnienia i autoryzacji:

System uwierzytelnienia i autoryzacji powinien składać się z:

• karty mikroprocesorowej , personalizowanej dla każdego użytkownika systemu, generującej klucze o długości min. 1024 bity,

• czytnika umożliwiającego współpracę z wyżej wymienioną kartą (wymagana zgodność ze standardem PC/SC,),

• komunikacja karty i czytnika z systemem musi być zgodna ze standardem PKCS#11

• oprogramowania klienckiego współpracującego z aplikacją systemu CEPiK i wspomagającego logowanie do systemu,

• serwera uwierzytelnienia znajdującego się w centralnej części systemu,

• systemu wydawania i zarządzania kartami.

System uwierzytelnienia i autoryzacji powinien spełniać co najmniej następujące wymagania:

• zapewnienie bezpiecznego logowania do systemu;

• autoryzowanie dostępu do odpowiednich dla danego użytkownika danych;

• podpisywanie informacji wysyłanych;

• weryfikacja podpisu informacji odebranej;

• szyfrowanie informacji wysyłanych z wykorzystaniem PKI;

• odszyfrowanie informacji odebranych;

• pobieranie aktualnej listy unieważnionych certyfikatów;

• pobieranie nowego klucza publicznego centrum certyfikacji i generacji kluczy;

• wyjęcie karty z czytnika powoduje „zamrożenie systemu”, a wznowienie pracy z systemem możliwe jest dopiero po ponownym jej włożeniu i podaniu hasła.

• system może wykorzystywać algorytmy kryptograficzne:

• asytmetryczne: RSA, DSA,

• symetryczne: DES, 3DES, narodowe algorytmy kryptograficzne

• funkcje skrótu: MD5, SHA-1,

• inne standardowe algorytmy.

Wymaga się by logowanie do systemu i autoryzacja dostępu do zasobów były realizowane z wykorzystaniem podpisu elektronicznego;

Wymaga się by wszystkie transakcje dokonywane przez użytkownika systemu były podpisane, a informacje przesyłane do bazy danych zaszyfrowane;

Ważnym jest zapewnienie bezpieczeństwa klucza prywatnego użytkownika, tj. wszystkie operacje kryptograficzne z jego wykorzystaniem powinny odbywać się wewnątrz komponentu sprzętowego (urządzenie kryptograficzne lub karta mikroprocesorowa);

W systemie należy zastosować bezpieczne urządzenia do składania i weryfikacji podpisu elektronicznego spełniające wymagania Ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. 2001 Nr 130, poz. 1450),

System uwierzytelnienia i autoryzacji powinien gwarantować wysoką wydajność pracy i brak opóźnień spowodowanych kumulacją zapytań do serwera uwierzytelniającego. W związku z powyższym zaleca się wykorzystać rozwiązanie umożliwiające skalowalność serwera i możliwość pracy w „klastrze wydajnościowym”.

Zamawiający wymaga, aby wszystkie powyższe funkcje infrastruktury klucza publicznego PKI, zastosowane były w stosunku do uprawnionych użytkowników i urządzeń końcowych systemu, zlokalizowanych w strukturach podmiotów wymienionych w podrozdziałach: 1.4.2.1., 1.4.2.2., 1.4.2.3., 1.4.2.4. i 1.4.2.5 załącznika w zakresie określonym w tych podrozdziałach. Sposób dostępu do systemu dla użytkowników określonych w podrozdziałach 1.4.2.6. i 1.4.2.7., powinien wykorzystywać jedynie wybrane funkcje PKI, pozwalające na zapewnienie autentyczności uprawnionych użytkowników.

Zamawiający wymaga, aby urządzenia i narzędzia kryptograficzne zastosowane w części centralnej systemu, były certyfikowane przez służbę ochrony państwa. Takie same wymagania będą zastosowane w stosunku do serwerów dedykowanych specjalnych, będących własnością podmiotów przetwarzających informacje niejawne stanowiące tajemnicę służbową o klauzuli „poufne” posadowionych w środowiskach lokalnych tych podmiotów.

1.4.2.1. Ochrona kryptograficzna transakcji polegających na uzupełnianiu bazy danych CEPiK

Transakcje polegające na uzupełnianiu bazy danych, obejmują realizację następujących procesów systemu CEPiK (procesy współrealizowane są przez podmioty określone w nawiasach):

• obsługa ewidencji pojazdów w powiatach (wydziały komunikacji starostw),

• obsługa ewidencji polis OC (Ubezpieczeniowy Fundusz Gwarancyjny),

• obsługa ewidencji badań technicznych i złomowań (uprawnione podmioty - stacje badań technicznych i złomowiska za pośrednictwem wydziałów komunikacji starostw),

• obsługa ewidencji czynności Policji (Policja poprzez własny ZSIP),

• obsługa ewidencji pojazdów specjalnych (podmioty wymienione w punkcie 1.4.1.3. załącznika),

• obsługa ewidencji podmiotów uczestniczących w obrocie pojazdami (organ rejestrujący lub cofający rejestrację pojazdu - za pośrednictwem wydziałów komunikacji starostw),

• bieżąca obsługa systemu przez upoważnionych pracowników w warstwie centralnej.

Największe znaczenie w procesach uzupełniania bazy danych, będzie miał proces obsługi ewidencji pojazdów w powiatach - będzie on najbardziej wpływał na integralność danych CEPiK.

Dodatkowo, ze względu na fakt, że pozostałe powyższe procesy w sposób bezpośredni również wpływają na integralność bazy danych CEPiK, a informacje przetwarzane w trakcie tych procesów stanowią tajemnicę służbową, realizacja wszystkich tych procesów powinna być chroniona za pomocą infrastruktury klucza publicznego PKI.

Powyższe procesy (z wyjątkiem wskazanego powyżej procesu obsługi ewidencji pojazdów w powiatach), pogrupowano według kryteriów udostępniania informacji, opisując sposób ochrony tych procesów w kolejnych podrozdziałach (1.4.2.2. do 1.4.2.7.).

1.4.2.2. Ochrona kryptograficzna obsługi ewidencji pojazdów specjalnych

Obsługa ewidencji pojazdów specjalnych poprzez serwery podmiotów określonych w podrozdziale 1.4.1.3. ze względu na fakt wytwarzania, przetwarzania, przechowywania i przekazywania w trakcie tego procesu danych stanowiących tajemnicę służbową o klauzulach „poufne”, wymaga zastosowania do ochrony tych danych oraz ochrony dostępu do nich, infrastruktury klucza publicznego PKI, zgodnie z wymaganiami określonymi w podrozdziale 1.4.2.

1.4.2.3. Ochrona kryptograficzna udostępniania informacji w trybie automatycznym (zapytania niestandardowe, standardowe typowania, replikacje danych w trybie automatyczno-subskrypcyjnym)

Udostępnianie informacji w powyższych trybach, jest realizacją procesu niekomercyjnego udostępniania informacji w trybie automatycznym i ze względu na przewidywaną wartość przesyłanych danych i ich zbiorów, musi podlegać ochronie polegającej na zastosowaniu do przekazywania tych danych, infrastruktury klucza publicznego PKI. Omawiane dane i ich zbiory, to informacje stanowiące tajemnicę służbową o klauzuli „zastrzeżone”. Przewiduje się udostępnianie informacji w powyższych trybach następującym podmiotom:

• wydziałom komunikacji starostw,

• wymienionym w punkcie 1.4.1.3. załącznika,

• Ubezpieczeniowemu Funduszowi Gwarancyjnemu,

• innym podmiotom, w ramach oddzielnych porozumień - będą one wyspecyfikowane w trakcie prac projektowych (np. sądy, prokuratura, podmioty komercyjne).

1.4.2.4. Ochrona kryptograficzna procesu pozyskiwania danych referencyjnych

Pozyskiwanie danych referencyjnych z innych baz danych (PESEL, REGON, TERYT), ze względu na wartość pozyskiwanych danych oraz konieczność zachowania ich integralności, musi podlegać ochronie polegającej na zastosowaniu do ich przekazywania, infrastruktury klucza publicznego PKI. Dane referencyjne to informacje stanowiące tajemnicę służbową o klauzuli „zastrzeżone”.

W przypadku podjęcia decyzji o organizacji pozyskiwania przez CEPiK danych referencyjnych z w/w baz danych według scenariuszy on-line lub automatycznych (określonych w podrozdziale 5.2.13. „Opisu przedmiotu zamówienia”), infrastruktura PKI powinna zapewnić co najmniej identyfikację serwera współpracującej bazy danych referencyjnych oraz szyfrowanie przesyłanych danych.

Ochrona danych pozyskiwanych z bazy danych POLTAX będzie uregulowana na podstawie oddzielnego porozumienia, zrealizowanego w kolejnym etapie projektu.

Ochrona danych pozyskiwanych z bazy danych Instytutu Transportu Samochodowego, nie wymaga stosowania infrastruktury klucza publicznego PKI.

1.4.2.5. Ochrona kryptograficzna obsługi ewidencji kierowców w powiatach (współpraca z systemem „Kierowca”)

Przewidywana współpraca z systemem „Kierowca” polegająca na weryfikacji informacji tego systemu przez system CEPiK, wymaga, aby punkt styku pomiędzy systemami określony w rozdziale 5.2.8. „Opisu przedmiotu zamówienia”, chroniony był poprzez zastosowanie infrastruktury klucza publicznego PKI. Dane wymieniane pomiędzy systemem „Kierowca” i systemem CEPiK, to informacje stanowiące tajemnicę służbową o klauzuli „zastrzeżone”.

1.4.2.6. Ochrona dostępu w trakcie procesu udostępniania pojedynczych informacji (prostych zapytań standardowych w trybie automatyczno-dochodzeniowym i automatyczno-operacyjnym)

Proces udostępniania pojedynczych informacji on-line w trybie automatyczno - dochodzeniowym i trybie automatyczno - operacyjnym, realizowany jest poprzez system informatyczny eksploatowany przez podmiot żądający dostępu do informacji. Pojedyncze informacje mogą być również udostępniane uprawnionym użytkownikom, poprzez serwer własnego podmiotu, z wykorzystaniem telefonów GSM - poprzez usługi dostępowe do internetu lub SMS. Informacja przesyłana w powyższy sposób nie wymaga szyfrowania - a więc zastosowania pełnej infrastruktury PKI. Jedynie dostęp upoważnionego użytkownika do CEPiK (poprzez serwer własnego podmiotu) powinien być w tym przypadku chroniony za pomocą haseł dostępu do systemu, które muszą zapewnić identyfikację użytkownika, zakres udostępnianej informacji oraz czas udostępnienia.

Za identyfikację osób upoważnionych do dostępu do systemu i autoryzacje wykonywanych przez nie operacji, odpowiedzialny jest dysponent systemu współpracującego w tym zakresie z CEPiK.

Eksploatator systemu współpracującego z systemem CEPiK, zobowiązany jest do archiwizowania logów systemowych i okresowego ich przekazywania do CEPiK zgodnie z procedurami, które zostaną ustalone w trakcie realizacji zamówienia.

Zadaniem systemu CEPiK w procesie udostępniania pojedynczych informacji, jest jedynie identyfikacja serwera podmiotu, któremu udostępnia się informacje.

Zadanie ochrony udostępniania pojedynczych informacji określone w tym podrozdziale, nie stanowi przedmiotu niniejszego zamówienia - za wyjątkiem zadania identyfikacji serwera podmiotu, któremu udostępnia się informacje.

Powyższe zasady nie dotyczą uzyskiwania pojedynczych informacji przez podmioty eksploatujące infrastrukturę PKI (np. wydziały komunikacji starostw). Podmioty te, uzyskują niezbędne informacje z CEPiK, z wykorzystaniem zasad przyjętych w trybach udostępniania chronionych za pomocą infrastruktury PKI.

Przewiduje się udostępnianie informacji w powyższych trybach podmiotom:

• Policji (główny „konsument” informacji) - poprzez Zintegrowany System Informacji Policji (ZSIP),

• innym podmiotom, w ramach oddzielnych porozumień - będą one wyspecyfikowane w trakcie prac projektowych.

1.4.2.7. Ochrona dostępu do systemu przez upoważnionych pracowników zapewniających bieżącą obsługę części centralnej systemu

Dostęp do systemu przez upoważnionych pracowników zapewniających bieżącą obsługę w warstwie centralnej, musi być realizowany poprzez wielopoziomowy system dostępu, z wykorzystaniem infrastruktury klucza publicznego PKI, zapewniającej ochronę informacji stanowiących tajemnicę służbową o klauzulach „poufne” i „zastrzeżone”. Ilość i zakres poziomów dostępu oraz wykaz upoważnionych osób funkcyjnych, zdefiniowane zostaną w trakcie prac projektowych.

1.4.2.8. Ochrona danych udostępnianych z systemu CEPiK komercyjnym i niekomercyjnym podmiotom w trybie urzędowym z wykorzystaniem wydruków lub nośników informacji

Dane udostępniane w powyższych trybach, mogą stanowić tajemnicę służbową o klauzuli „zastrzeżone” lub „poufne” (każdorazowo definiuje to wykonawca ekstraktu danych) i jako takie podlegają przekazywaniu ich, zgodnie z zasadami określonymi w ustawie o ochronie informacji niejawnych i wynikających z niej aktach wykonawczych dotyczących obiegu dokumentów niejawnych (zasady te, wymuszają organizację i wykorzystanie w obiegu dokumentów zawierających informacje stanowiące tajemnicę służbową, kancelarii i środków przekazywania tych dokumentów w sposób zapewniający bezpieczeństwo). Powyższe, dotyczy również danych do naliczania i przekazywania do starostw podatku od środków transportu. Organizacja sposobu przekazywania powyższych danych, nie stanowi przedmiotu niniejszego zamówienia.

1.4.2.9. Ochrona styku podstawowego i zapasowego centrum komputerowego ze wszystkimi sieciami zewnętrznymi

Zamawiający oczekuje, że dostawca zapewni odpowiedni system zabezpieczający centrum podstawowe i zapasowe od wszystkich sieci zewnętrznych (w tym sieci PESEL-NET).

System zabezpieczeń składać się powinien z następujących elementów:

• System zaporowy Firewall

• System wykrywania włamań i nadużyć (IDS)

• System antywirusowy skanujący w czasie rzeczywistym ruch SMTP, HTTP, FTP

• Platformy sprzętowo-systemowej dla wymienionych wyżej elementów

- System zaporowy Firewall spełniający poniższe wymagania:

• system musi chronić sieć wewnętrzną, wymagana licencja na nielimitowaną ilość adresów IP,

• Zasady bezpieczeństwa edytowane przez administratora systemu zaporowego powinny stanowić jedną centralną listę dla wszystkich używanych modułów firewalla,

• Wszystkie połączenia zawiązywane poprzez system zaporowy muszą być chronione poprzez zdefiniowaną politykę bezpieczeństwa,

• System zaporowy powinien dokonywać analizy ruchu w warstwie sieciowej modelu TCP/IP OSI dokonując rozróżnienia na ruch wejściowy (ang. inbound), wyjściowy (ang. outboud) oraz w obydwu kierunkach (ang. eitherbound).

• System zaporowy powinien zapewniać kontrolę zawartości sesji: SMTP, FTP oraz HTTP (ActiveX, Java, DoS, SYN Flood, Port Scan, Spoofing). System zaporowy powinien posiadać mechanizmy uwierzytelniania użytkowników (User, Session and Client Authentication).

• System zaporowy powinien wykrywać podstawowe ataki (port scanning, land attack, login failure, successive alerts, syn attack) na system zaporowy oraz powinien zapewniać aktywną obronę przeciw nim poprzez blokowanie wyspecyfikowanych połączeń w systemie zaporowym niezależnie od zdefiniowanej polityki bezpieczeństwa.

• System zaporowy powinien umożliwiać rozliczanie (tzw. accounting) ustawiane na definiowane w polityce bezpieczeństwa zasady. Dane dotyczące sesji (skąd, dokąd, o której godzinie, długość pakietu) powinny być przesyłane do centralnego pliku ze zdarzeniami.

• System zaporowy powinien posiadać możliwość wysyłania w czasie rzeczywistym alertów do administratora systemu poprzez alarm na konsoli, informację za pośrednictwem poczty elektronicznej, SNMP lub wykonanie dowolnego skryptu systemu operacyjnego (powinno istnieć sprzężenie wysyłania alertów np. z wysyłaniem komunikatów SMS).

- System wykrywania włamań i nadużyć (IDS) spełniający poniższe wymagania:

• Analizatory ruchu sieciowego powinny być zlokalizowane w newralgicznych segmentach sieci. Ich działanie polegać ma na przechwytywaniu pakietów przesyłanych w sieci i analizowaniu ich zawartości pod kątem wykrywania znanych wzorców włamań. System powinien identyfikować m.in. skanowanie portów serwerów sieciowych, próby nieautoryzowanego dostępu do zasobów oraz różnego rodzaju ataki destrukcyjne typu Exploit. Po wykryciu niedozwolonych działań, Analizator powinien mieć możliwość wykonania następujących działań:

• wysłać alarm do konsoli zarządzającej,

• zapisać notatkę o wystąpieniu zdarzenia w centralnym pliku zdarzeń,

• zapisać całość sesji sieciowej,

• zarejestrować przebieg sesji sieciowej (umożliwiając późniejsze odtworzenie jej przebiegu),

• "zabić" sesję sieciową (wysłać pakiet RESET do klienta i serwera TCP),

• wysłać komunikat do systemu zaporowego firewall w celu modyfikacji jego polityki bezpieczeństwa,

• zamknąć sesję użytkownika w systemie operacyjnym i zablokować jego konto na określony czas,

• bezwarunkowo zablokować konto użytkownika w systemie operacyjnym (odblokowania konta może dokonać tylko administrator),

• przekazać informacje o zdarzeniu do administratora (pocztą E-Mail, komunikat SMS),

• wysłać komunikat do konsoli SNMP,

• wyświetlić ostrzeżenie dla użytkownika,

• wykonać inne działania zdefiniowane przez administratora.

• System IDS powinien składać się z następujących komponentów:

• Analizator ruchu sieciowego,

• Analizator logów systemowych,

• Centralne zarządzanie.

• System IDS musi współdziałać z systemem zaporowym Firewall w taki sposób aby po wykryciu niedozwolonych działań automatycznie (bez interwencji administratora) dokonywał wymaganych modyfikacji polityki bezpieczeństwa systemu zaporowego firewall.

• Liczba i sposób umieszczenia analizatorów ruchu sieciowego powinny zapewnić pełne monitorowanie dostępu do zasobów centrum podstawowego i zapasowego.

- System antywirusowy skanujący w czasie rzeczywistym, spełniający poniższe wymagania:

• System antywirusowy ma za zadanie ochronę sieci centrum podstawowego i zapasowego przed wirusami i innymi niebezpiecznymi modułami przechodzącymi przez pomost do sieci zewnętrznych. Rozwiązanie musi gwarantować integrację z systemem zaporowym FireWall.

• Rozwiązanie powinno zapewniać poniższą funkcjonalność:

• Pełna zgodność z systemem firewall,

• Skanowanie ruchu m.in. HTTP, FTP i SMTP (wraz z załącznikami) w czasie rzeczywistym,

• Automatyczne "leczenie" zainfekowanych plików, opcjonalne kasowanie zainfekowanych plików,

• Wykrywanie niebezpiecznych kontrolek ActiveX i apletów Java. Opcjonalne blokowanie wszystkich kontrolek ActiveX i apletów Java ,

• Wykrywanie i usuwanie znanych i nieznanych wirusów makr "w locie",

• Wysyłanie komunikatów do nadawcy, odbiorcy i administratora ,

• Możliwość automatycznego, periodycznego uaktualniania bazy wirusów i oprogramowania poprzez sieć .

• Archiwizacja informacji o wykrytych wirusach

• Graficzny interfejs GUI i interfejs ISAPI/GDI do konfiguracji za pośrednictwem przeglądarki WWW

• Inteligentne skanowanie: Motor skanujący powinien pracować zarówno w trybie rozpoznawania reguł jak i wzorców wirusów. System powinien także obsługiwać większość formatów kompresujących i analizować pliki zawarte w skompresowanych archiwach. Dodatkowo, system powinien wykrywać i usuwać znane i nieznane wirusy makr (np. w plikach MS-OFFICE).

- Platforma sprzętowo-systemowa dla wymienionych wyżej elementów Firewall, IDS, System antywirusowy, spełniającej poniższe wymagania:

• Platforma sprzętowo-systemowa dla systemów: Firewall, IDS i Systemu antywirusowego powinna stanowić jedno fizyczne, modularne urządzenie centralnie zarządzane poprzez dedykowany, bezpieczny port ethernet. Powinna ona posiadać budowę modułową zapewniającą możliwości rozbudowy w zakresie zarówno zwiększania przepustowości całego systemu lub dla wybranych jego fragmentów (Firewall, ISD, system antywirusowy) jak również pod względem ilości dostępnych interfejsów sieciowych typu FastEthernet i Gigabit Ethernet. Rozbudowa systemu, poprzez dokładanie dodatkowych modułów, powinna być możliwa w trakcie pracy systemu. Każda z platform sprzętowo-systemowych musi być wyposażona w redundantne moduły zarządzające i aplikacji oraz interfejsów sieciowych. Należy zapewnić możliwość konfiguracji redundatnych płyt w trybie hot-standby.

• Możliwość bezpiecznego zarządzania poprzez konsolę znakową: CLI/SSH oraz WebGUid(HTTPS),

• System powinien spełniać wymagania wysokiej dostępności - wymagany stosunek czasu sprawnej pracy do czasu niedostępności systemu - 99,9%,

• System powinien umożliwić:

• instalację interfejsów sieciowych FastEthernet i GigabitEthernet,

• instalację w szafie telekomunikacyjnej 19",

• dystrybucję obciążeń pomiędzy poszczególne moduły pracujące w konfiguracji klastrowej,

• zdefinowanie dowolnego trybu pracy modułów: Active-Active, Hot-Standby, Active-Standby.

1.4.3. Ochrona elektromagnetyczna systemu

Ochronę elektromagnetyczną systemu informatycznego zapewni Zamawiający poprzez umieszczenie urządzeń warstwy centralnej systemu w strefach bezpieczeństwa gwarantujących spełnienie odpowiednich wymogów zabezpieczenia elektromagnetycznego. Dodatkowo -w trakcie prac projektowych, niezbędne będą konsultacje ze służbami ochrony państwa - głównie laboratorium kompatybilności elektromagnetycznej Agencji Bezpieczeństwa Wewnętrznego.

Biorąc pod uwagę powyższe, Zamawiający dopuszcza zastosowanie do przetwarzania informacji w warstwie centralnej systemu urządzeń kategorii 4, to znaczy sprzętu informatycznego powszechnego użytku (wyłączając z tego urządzenia i narzędzia kryptograficzne), zgodnego z europejską normą związaną ze znakiem CE. Powyższe wymagania dotyczą zapasowego centrum komputerowego. Wymagania na podstawowe centrum komputerowe w zakresie urządzeń, są identyczne. Wymagania dla ochrony elektromagnetycznej serwerów specjalnych zlokalizowanych w strukturach podmiotów określonych w punkcie 1.4.1.3. załącznika, zostaną sformułowane oddzielnie i nie stanowią przedmiotu niniejszego zamówienia.

Wymagania ochrony elektromagnetycznej dotyczą jedynie elementów systemu biorących udział w przetwarzaniu informacji zawierających tajemnicę służbową o klauzuli „poufne” Nie dotyczą one elementów systemu biorących udział w przetwarzaniu informacji zawierających tajemnicę służbową o klauzuli „zastrzeżone”.

1.4.4. Bezpieczeństwo transmisji

Bezpieczeństwo transmisji zostanie osiągnięte poprzez zastosowanie dwupoziomowego systemu ochrony. Pierwszym poziomem będzie wykorzystanie wydzielonej sieci Pesel-Net oraz wydzielonych kanałów teletransmisyjnych (łączy dedykowanych) - zgodnie z przedstawioną w rozdziale 5.6.9. „Opisu przedmiotu zamówienia ...”, topologią systemu (wykorzystanie sieci Pesel-Net, jest przedmiotem oddzielnego zamówienia publicznego).

Drugim poziomem będzie zastosowanie modułów bezpieczeństwa w zdalnych sieciach LAN zapewniających szyfrowaną transmisję danych „end-to-end” w trybie online. Przewiduje się, że komunikacja aplikacji użytkownika z serwerem będzie odbywała się z wykorzystaniem bezpiecznego protokołu SSL/TLS. W związku z powyższym wymaga się zastosowania rozwiązania kryptograficznego, które będzie zabezpieczało transmisję na poziomie sesji tcp w trybie „end to end” (sesja zawiązywana pomiędzy komputerem użytkownika końcowego i serwerem).

Urządzenie powinno wykorzystywać usługi Infrastruktury Klucza Publicznego i posiadać następującą funkcjonalność:

• powinno realizować protokół TLS 1.0, szyfrowana sesja zawiązywana jest pomiędzy stacją roboczą użytkownika i kończy się na serwerze aplikacji,

• obsługa co najmniej 10 sesji TLS (jedno urządzenie może być wykorzystywane przez kilku użytkowników);

• bezpieczny nośnik kluczy w postaci karty chipowej;

• wbudowany czytnik kart i klawiatura umożliwiająca bezpieczne podanie hasła co pozwoli na pełną administrację systemem - inicjalizacja systemu, w tym umożliwienie pracy wszystkim stacjom roboczym w zdalnej lokalizacji odbywa się poprzez włożenie przez administratora karty do urządzenia i podanie hasła;

• wyjęcie karty musi powodować utratę możliwości komunikacji pomiędzy aplikacją na stacjach użytkowników i serwerem;

• klucze sesyjne nie mogą wydostawać się poza urządzenie;

• bezpieczna obudowa antypenetracyjna i autonomiczny wewnętrzny system zasilania;

• logi aktywności i zdarzeń dostępne tylko dla administratora systemu;

• urządzenie powinno być zgodne z wymaganiami FIPS 140-1 poziom 3;

• interfejs sieciowy: minimum FastEthernet 10Base-T;

Rozwiązanie spełniające powyższe wymagania ma zapewnić bezpieczną transmisję danych i zagwarantować pełną rozliczalność transakcji w systemie zarówno na poziomie danej lokalizacji zdalnej jak i na poziomie użytkownika.

1.4.5. Bezpieczeństwo energetyczne systemu

Na obecnym etapie prac, przedstawione zostały wymagania dotyczące zapasowego centrum komputerowego. Wymagania dla podstawowego centrum komputerowego będą podobne i nie będą w sposób istotny odbiegać od niniejszych wymagań.

Wymagania dla zasilania serwerów podmiotów współpracujących z systemem CEPiK, nie powinny odbiegać od powszechnie przyjętych standardów i nie stanowią przedmiotu niniejszego zamówienia.

Zamawiający zapewni na terenie budynku zapasowego centrum komputerowego, następujące urządzenia energetyczne nie stanowiące przedmiotu niniejszego zamówienia, gwarantujące bezpieczne zasilanie elementów systemu informatycznego:

• rozdzielnicę niskiego napięcia, której zasilanie będzie doprowadzone dwiema liniami niskiego napięcia z dwóch kierunków,

• rezerwowe źródło zasilania - agregat prądotwórczy, dołączony do szyn zbiorczych rozdzielnicy, spełniający następujące podstawowe kryteria:

• pełną automatykę rozruchu, pracy i wyłączania współpracujący z centralnym komputerowym systemem kontroli i nadzoru,

• szybki start wraz ze sterowaniem obrotami w funkcji obciążenia i napięcia wyjściowego,

• 72 - godzinny czas nieprzerwanej pracy,

• zasilanie następujących elementów:

• zasilacza bezprzerwowego UPS,

• urządzeń informatycznych,

• urządzeń kontroli dostępu (dostępu fizycznego),

• instalacji alarmowych,

• sieci teleinformatycznych,

• wydzielonej klimatyzacji,

• systemu telekomunikacyjnego.

• sieć elektryczną napięcia gwarantowanego zasilającą serwerownię, spełniającą następujące wymagania:

• sieć zasilająca serwerownię będzie wykonana w systemie TN-S przewodami w izolacji bezhalogenowej,

• wszystkie urządzenia w serwerowni zostaną przyłączone do szafy rozdzielczej umieszczonej na hali (serwerowni) i zasilonej z zasilacza bezprzerwowego UPS,

• szafa będzie umieszczona na hali komputerowej w takim miejscu aby było możliwe dokonywanie zmian ustawienia urządzeń w dowolny sposób; szafa będzie posiadać rezerwę umożliwiającą przyłączenie dodatkowych urządzeń,

• szafa rozdzielcza będzie współpracować z centralką ppoż. i wyłączać zasilanie urządzeń w przypadku zagrożenia pożarowego,

• w przypadku zagrożenia całej powierzchni adaptowanych pomieszczeń wyłączenie wszystkich źródeł zasilania nastąpi na poziomie rozdzielni głównej,

• zastosowane rozwiązania będą umożliwiać integrację z innymi systemami.

• sieć elektryczną napięcia gwarantowanego zasilającą punkty dostępowe, spełniającą następujące wymagania:

• sieć zasilająca punkty dostępowe będzie swoim zasięgiem obejmować cały budynek,

• sieć będzie wykonana w systemie TN-S; jako standard należy przyjąć za punkt dostępowy 4 gniazda elektryczne 230 V i 2 gniazda RJ kat. 5,

• gniazda elektryczne będą umożliwiać przyłączanie tylko urządzeń informatycznych,

• główna rozdzielnica sieci napięcia gwarantowanego będzie znajdować się w pomieszczeniu rozdzielni głównej obiektu; zasilanie do niej będzie doprowadzone z zasilacza bezprzerwowego UPS,

• na poszczególnych kondygnacjach będą rozmieszczone rozdzielnice piętrowe z których zostaną wyprowadzone obwody do punktów dostępowych. Ilość rozdzielnic będzie tak dobrana, aby:

• zapewniać spadki napięć na możliwie najniższym realnym poziomie,

• odległość do odbiorników była możliwie jak najkrótsza.

• rozdzielnice będą współpracować z instalacją ochrony przeciwpożarowej.

• zasilacz bezprzerwowy UPS, spełniający wymagania:

• zerowy czas przejścia z pracy sieciowej na pracę z baterii,

• cicha praca - określona parametrem <55 dB w odległości 1 m,

• niski poziom emisji ciepła (małe straty do otoczenia),

• małe wymiary,

• praca bezawaryjna w okresie 7 lat,

• izolacja galwaniczna obciążenia od sieci,

• możliwość pracy równoległej,

• czas podtrzymania pracy zasilacza bezprzerwowego z baterii, 15 minut przy pełnym obciążeniu,

• zastosowanie baterii bezobsługowych, szczelnych o trwałości 10 lat z wyposażeniem w czujniki umożliwiające temperaturową kompensację napięcia ładowania baterii,

• odporność zasilacza na typowe pola elektromagnetyczne,

• pełna komunikacja logiczna z sieciami komputerowymi oraz oprogramowanie umożliwiające monitorowanie systemu (napięcia, prądy, częstotliwość, stany pracy UPS-u w tym stany alarmowe, prowadzenie logów zdarzeń, graficzne przedstawienie wyników z możliwością wydruku),

• integracja z centralnym systemem kontroli i nadzoru,

• zdalna tablica wskaźników,

• adapter SNMP,

• wyłącznik awaryjny,

• współpraca z agregatem prądotwórczym,

• elektroniczny By-pass,

• sprawność powyżej 96%,

• parametry wejściowe:

• napięcie zasilania 400/230 V w systemie TN-S,

• tolerancja napięcia wejściowego: ⁺/_- 15% z możliwością programowania,

• częstotliwość wejściowa: 50 Hz z tolerancją < 4% z możliwością programowania
  co ⁺/_- 0,5%.

• parametry wyjściowe:

• napięcie 400/230 V w systemie TN-S,

• tolerancja napięcia: ⁺/_-1% obciążenie statyczne symetryczne, ⁺/_- 3% obciążenie statyczne asymetryczne, ⁺/_- 5% obciążenie dynamiczne od 0-100% P_n.

• zniekształcenie napięcia wyjściowego: < 3% dla obciążenia liniowego,
  < 5% dla obciążenia nieliniowego.

• częstotliwość: 50 Hz zsynchronizowana z siecią,

• przeciążalność: 150 % przez 30 sekund przy pracy z baterii, 125 % przez 10 minut przy pracy sieciowej.

• sieć ochrony przed przepięciami atmosferycznymi - zewnętrzną i wewnętrzną,

• sieć uziemiającą o rezystancji uziomu technologicznego w przedziale 1 Ohma,

• instalacje elektryczne wewnętrzne dla odbiorów administracyjnych.

2. Procedury postępowania

Zamawiający wymaga od Dostawcy przedstawienia przed wdrożeniem systemu i jego elementów składowych, propozycji procedur postępowania uprawnionych użytkowników, zapewniających bezpieczną eksploatację systemu CEPiK, szczególnie propozycji dokumentów dla następujących użytkowników:

• w warstwie centralnej systemu:

• instrukcji dla inspektora bezpieczeństwa teleinformatycznego systemu,

• instrukcji bezpiecznej eksploatacji dla administratora systemu,

• instrukcji bezpiecznej eksploatacji dla operatorów części centralnej,

• instrukcji bezpiecznej eksploatacji dla osób funkcyjnych obsługujących centralne elementy infrastruktury PKI,

• instrukcji bezpiecznej eksploatacji dla innych zaproponowanych przez Dostawcę osób funkcyjnych, biorących udział w eksploatacji systemu,

• w warstwie lokalnej systemu (w strukturach podmiotów eksploatujących urządzenia końcowe systemu):

• instrukcji dla inspektorów bezpieczeństwa teleinformatycznego,

• instrukcji bezpiecznej eksploatacji dla administratorów (zarządzających) zespołem urządzeń końcowych (np. w ramach wydziału komunikacji starostwa),

• instrukcji bezpiecznej eksploatacji dla użytkowników końcowych wykorzystujących infrastrukturę PKI,

• instrukcji bezpiecznej eksploatacji dla użytkowników końcowych, realizujących proces udostępniania pojedynczych informacji w trybie „on-line”,

• instrukcji bezpiecznej eksploatacji dla innych zaproponowanych przez Dostawcę osób funkcyjnych, biorących udział w eksploatacji systemu.

Zamawiający oczekuje od dostawcy ścisłej współpracy, w zakresie wypracowania, wprowadzenia i modernizacji procedur bezpiecznej eksploatacji systemu CEPiK, we wszystkich etapach jego budowy, zatwierdzania bądź akceptacji przez służby ochrony państwa, wdrażania i eksploatacji.

3. Przepisy prawa

Zamawiający wymaga aby w procesie projektowania i implementacji procedur bezpieczeństwa Dostawca uwzględniał uregulowania prawne, normy i przyjęte standardy, w tym w szczególności:

• Ustawa z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych, (Dz.U. z dnia 08.02.1999 r., Nr 11, poz. 95 z późn. zmianami),

• ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. 2001 Nr 130, poz. 1450),

• Rozporządzenie Rady Ministrów z dnia 25 lutego 1999 r. w sprawie podstawowych wymagań bezpieczeństwa systemów i sieci teleinformatycznych (Dz.U. z dnia 05.03.1999 r., Nr 18, poz. 162),

• Polska Norma PN-I-13335 - 1 Technika Informacyjna. Wytyczne do zarządzania bezpieczeństwem systemów informatycznych. Pojęcia i modele bezpieczeństwa systemów informatycznych (PKN, styczeń 1999 r.),

• Ustawa z dnia 29.08.1997 r. o ochronie danych osobowych (Dz.U. Nr 133. poz. 883 z późn. zmianami),

• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 3.06.1998 r. w sprawie określenia podstawowych warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. Nr 80. poz. 521),

• Rozporządzenie Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpieczeństwa urządzeń służacych do składania i weryfikacji podpisu elektronicznego,

• BS 7799-2:1999 — Information security management, British Standards Institution, 1999.

Załącznik nr 4.2. -[Wymagania techniczne]

do „Opisu przedmiotu zamówienia

na wykonanie, wdrożenie

oraz obsługę eksploatacyjną i rozwój

systemu informatycznego wraz z robotami budowlanymi (adaptacyjnymi) pomieszczeń przeznaczonych na ten cel”

Szczegółowe wymagania techniczne dla wybranych elementów

infrastruktury systemu CEPiK

A. Punkty styku systemu z siecią rozległą oraz wymagania na router dostępowy do sieci WAN CEPiK

1. Wstęp

Niniejszy załącznik definiuje wymagania techniczno-eksploatacyjne dla routera dostępowego (RD) do sieci WAN CEPiK, będącego częścią infrastruktury sieciowej warstwy lokalnej systemu CEPiK. Router RD, zlokalizowany w Powiatowym Wydziale Komunikacji, będzie pełnił rolę urządzenia pośredniczącego między infrastrukturą sieci teletransmisyjnej (WAN CEPiK) a lokalną siecią komputerową Powiatowego Wydziału Komunikacji. Będzie on również dostarczał zapasowe łącze dla obecnie pracujących w starostwach węzłów sieci Centralnej Ewidencji Kierowców (CEK).

Załącznik definiuje także punkt styku pomiędzy siecią WAN CEPiK a centralną strukturą systemu.

2. Wymagania podstawowe

W rozdziale tym wymienione są wymagania, które muszą być spełnione w całości.

Zastosowanie

Poniższy rysunek przedstawia implementację routera RD w sieci CEPiK.




Wymagane jest wyposażenie routera RD w takie interfejsy i niezbędne moduły, aby można było zrealizować następujące połączenia:

1. Połączenie struktury lokalnej CEPiK z siecią WAN CEPiK zrealizowane za pomocą łącza stałego.

2. Zapasowe połączenie struktury lokalnej CEPiK z siecią WAN CEPiK zrealizowane za pomocą dodatkowego połączenia linią stałą lub połączenia ISDN Dial-up.

3. Do routera RD poprzez interfejs Ethernet dołączona zostanie część sieci lokalnej Wydziału Komunikacji, w której znajdą się końcówki systemu CEPiK.

4. Drugi interfejs Ethernet zostanie wykorzystany do celów redundancji lub dołączenia innych sieci lokalnych starostwa korzystających z usług sieci WAN CEPiK.

5. Poprzez interfejs WAN zostanie również dołączona sieć CEK. Połączenie to będzie wykorzystywane przez CEK jako połączenie zapasowe w przypadku zaniku połączenia podstawowego, jakim dla CEK jest połączenie do PWPW poprzez sieć VSAT.

Modularność

Dostarczony router musi być urządzeniem modularnym, dającym się rozbudowywać w miejscu zainstalowania poprzez dołożenie kart rozszerzeń i ewentualne ich aktywowanie za pomocą narzędzi zarządzających.

Interfejsy

Oferowany router w podstawowej, dostarczanej i instalowanej u Zamawiającego konfiguracji musi posiadać następujące interfejsy:

Interfejs	Minimalna ilość portów	Komentarz
LAN	2	10BaseT lub 100BaseT
WAN	2	V.35/FR lub RJ48T/G703/G704 o przepustowości 2 Mbps
Backup	1	WAN lub ISDN. Wymagana funkcjonalność łącza zapasowego

Router RD musi mieć możliwość zastosowania zamiennie interfejsów V.35/FR lub G.703/G.704 poprzez wymianę karty rozszerzeń. Specyfikacja rodzajów interfejsów WAN routerów RD zostanie sprecyzowana przez Zamawiającego na etapie składania zamówienia. Zmiana rodzaju interfejsu WAN na etapie zamówienia nie może powodować zmiany ceny oferowanego urządzenia.

Router RD musi mieć możliwość zastosowania w roli interfejsu łącza zapasowego zamiennie interfejsów WAN (V.35/FR lub G.703/G.704) lub ISDN poprzez wymianę karty rozszerzeń. Specyfikacja rodzajów interfejsów zapasowych routerów RD zostanie sprecyzowana przez Zamawiającego na etapie składania zamówienia. Zmiana rodzaju interfejsu zapasowego na etapie zamówienia nie może powodować zmiany ceny oferowanego urządzenia.

Posiadający komplet wyżej wymienionych interfejsów router będzie posiadał ponadto przynajmniej jeden niewykorzystany slot na karty rozszerzeń, zapewniający możliwość dalszej rozbudowy o co najmniej dwa interfejsy sieci WAN.

Zamawiający otrzyma wykaz wszystkich możliwych do zainstalowania w oferowanym routerze kart rozszerzeń i modułów wraz z regułami ich doboru i konfigurowania oraz ewentualnymi ograniczeniami w ich stosowaniu.

Router RD zostanie dostarczony wraz z zainstalowanym oprogramowaniem i licencjami niezbędnymi do uruchomienia wyżej wymienionych interfejsów i funkcjonalności.

Zasilanie

Dostarczony router musi być przystosowany do zasilania źródłem prądu przemiennego o napięciu 220-230 V. Oferent określi poziom zapotrzebowania routera RD na energię elektryczną oraz dostarczy i zainstaluje zasilacze awaryjne zapewniające, w przypadku zaniku głównego zasilania, podtrzymanie pracy routera przez co najmniej 2 godziny.

Obudowa

Dostarczony router będzie posiadał możliwość zainstalowania w standardowej szafie telekomunikacyjnej 19” bez konieczności instalowania dodatkowych półek. Szafa telekomunikacyjna o wysokości 42U oraz elementy i śruby mocujące router w tej szafie są częścią dostawy routera.

Dokumentacja techniczna.

Oferent dostarczy pełną dokumentację techniczno-eksploatacyjną oferowanych urządzeń.

Gwarancja.

Oferent przedstawi propozycję w zakresie gwarancji i okresu pogwarancyjnego dla oferowanych urządzeń:

• długości okresu gwarancyjnego (nie krócej jednak niż jeden rok)

• programu usług gwarancyjnych realizowanych nieodpłatnie,

• programu usług opcjonalnych, które realizowane będą w zależności od uwarunkowania w postaci przyczyny uszkodzenia.

• świadczenia usług pogwarancyjnych.

3. Wymagania funkcjonalne.

W poniższych podrozdziałach przedstawiono listę funkcjonalności, których spełnienie jest wymagane przez Zamawiającego. Zamawiający wymaga od Dostawcy wyspecyfikowania dodatkowych modułów lub licencji na oprogramowanie, jeśli dla osiągnięcia zgodności z którymś z wymagań konieczny jest ich zakup lub instalacja.

a) IP wersja 4

Lp	Funkcjonalność	Komentarz
1	Możliwość przypisania wielu adresów IP jednemu interfejsowi fizycznemu	Dotyczy wszystkich interfejsów sieciowych LAN/WAN. Dostawca musi podać listę interfejsów spełniających, jaki i nie spełniających to wymaganie
2	Port Address Translation (PAT)	Dotyczy wszystkich interfejsów sieciowych LAN/WAN. Dostawca musi podać listę interfejsów spełniających, jaki i nie spełniających to wymaganie
3	Network Address Translation (NAT)	Dotyczy wszystkich interfejsów sieciowych LAN/WAN. Dostawca musi podać listę interfejsów spełniających, jaki i nie spełniających to wymaganie
4	Classless Inter-domain Routing (CIDR)
5	RIP1 i RIP2
6	OSPF	Jeśli spełnia, należy również podać numery RFC
7	BGP4
8	DVMRP	Opcjonalny
9	Real-Time Transport Protocol (RTP)
10	Compressed Real-Time Transport Protocol (CRTP)

b) Quality of Service

Lp	Funkcjonalność	Komentarz
1	IP ToS
2	CBQ	Opcjonalny
3	Priority Queuing
4	WFQ
5	WRED
6	DiffServ
7	Packet Classification
8	Policy Based Routing
9	Bandwidth on Demand
10	802.1P
11	802.1Q VLAN Routing	Dotyczy wszystkich interfejsów Ethernet. Dostawca musi podać listę interfejsów spełniających, jaki i nie spełniających to wymaganie

c) Point-to-Point Protocol

Lp	Funkcjonalność	Komentarz
1	Asynchroniczny interfejs PPP
2	Synchroniczny interfejs PPP
3	Multi-Link PPP

d) High Level Data Link Control

Lp	Funkcjonalność	Komentarz
1	HDLC (Cisco)

e) X.25

Lp	Funkcjonalność	Komentarz
1	X.25 Switching (DCE)	Opcjonalny
2	X.25 DTE	Opcjonalny
2	RFC 877/1356 (IP)	Opcjonalny

f) Frame Relay

Lp	Funkcjonalność	Komentarz
1	Frame Relay DTE
2	Frame Relay DCE
3	RFC 1490
4	LMI
5	FRF.8
6	FRF.12
7	Frame Relay Traffic Shaping (FRTS)

g) Autentyfikacja

Lp	Funkcjonalność	Komentarz
1	PAP/CHAP
2	Radius (klient)
3	Wsparcie dla PKI

h) Głos

Lp	Funkcjonalność	Komentarz
1	VoIP	Opcjonalny
2	VoFR	Opcjonalny
3	G.723.1	Opcjonalny
4	G.729a	Opcjonalny
5	G.711	Opcjonalny
6	Sygnalizacja H.323	Opcjonalny. Proszę podać wersję

i) IP VPN

Lp	Funkcjonalność	Komentarz
1	Tunelowanie IPSec	Opcjonalny
2	Tunelowanie GRE	Opcjonalny
3	DES	Opcjonalny
4	3DES	Opcjonalny
5	AES	Opcjonalny. Proszę podać długość klucza
6	IKE	Opcjonalny
7	X.509	Opcjonalny. Proszę podać wersję
8	Stateless Packet Filtering	Opcjonalny
9	Statefull Packet Filtering	Opcjonalny

j) Interfejsy

Lp	Funkcjonalność	Komentarz
1	V.35
2	G.703
3	G.704
4	10BaseT	Wymagany jest jeden z interfejsów: 10BaseT lub 100BaseT
5	100BaseT	Wymagany jest jeden z interfejsów: 10BaseT lub 100BaseT
6	Full duplex (Ethernet)	Opcjonalnie
7	Autonegocjacja (Ethernet/FastEthernet)	Opcjonalny
8	Autonegocjacja (Half/Full Duplex)	Opcjonalny
9	ISDN ST	Wymagana funkcjonalność backupu łącza

k) Interfejsy zarządzające

Lp	Funkcjonalność	Komentarz
1	HTTP	opcjonalny
2	Telnet
3	ssh	opcjonalny
4	Terminal poprzez RS232
5	SNMP	Podać wersje
6	Interfejs RMON	Podać które grupy
7	Kontrola dostępu i uprawnień na poziomie użytkownika
8	syslog
9	Zapisywanie i przechowywanie zdarzeń w pamięci nieulotnej (zmiana konfiguracji, zmiana statusu interfejsu, logowanie użytkownika, błędy)	Opcjonalny

Odpowiedź musi być przedstawiona w formie tabeli zawierającej następujące kolumny:

• „Oznaczenie wymagania” - należy wpisać oznaczenie wymagania (litery a-k oraz numer wymagania)

• „Wymaganie”  - należy wpisać funkcjonalność odpowiadającą podanemu „Oznaczeniu wymagania”

• „Stopień spełnienia wymagania” - należy określić stopień spełnienia wymagania według zasad przedstawionych poniżej;

• „Uwagi” - należy wpisać wyjaśnienia dotyczące odpowiedzi; jeżeli wyjaśnienia znajdują się w odrębnych załącznikach, należy wpisać odpowiednie odnośniki jednoznacznie lokalizujące wyjaśnienie.

W kolumnie „Stopień spełnienia wymagania” należy umieścić następujące sformułowania:

• „Spełnione” - oznacza, że wymaganie jest w pełni spełnione na dzień 15.07.2003r;

• „Niespełnione” - oznacza, że wymaganie jest niespełnione; w kolumnie „Uwagi” można przedstawić uzasadnienie tego stanu;

• „Częściowo spełnione” - oznacza, że wymaganie jest częściowo spełnione; w kolumnie „Uwagi” należy określić obszary niezgodności;

• „W opracowaniu” - oznacza, że wymaganie będzie spełnione w przyszłości; w kolumnie „Uwagi” należy określić termin spełnienia i wersję produktu;

• „Propozycja alternatywna” - oznacza propozycją alternatywną do wymagania, która oferuje podobne funkcjonalności; w kolumnie „Uwagi” należy opisać szczegółowo propozycję;

• „Przyjęte do wiadomości” - oznacza, że Dostawca przyjął do wiadomości podaną informację.

4. Wymagania eksploatacyjne

Szkolenia.

Dostawca zaoferuje szkolenia dla personelu obsługującego sieć WAN CEPiK w zakresie utrzymania i zarządzania oferowanymi routerami.

Wsparcie techniczne.

Dostawca musi zapewnić minimalny zbiór świadczonych usług gwarancyjnych według poniższej listy:

1. Telefoniczna gorąca linia: usługa powinna być dostępna od poniedziałku do piątku w godzinach 9.00 - 17.00 we wszystkie dni w roku, usługa powinna umożliwiać dostarczenie informacji technicznych, które nie muszą być uzyskane w sposób pilny odnośnie dokumentacji, procesu odbioru, świadczonych usług, szkoleń itd.

2. Wsparcie dotyczące sytuacji wymagających natychmiastowego uzyskania informacji technicznych:

1. Dostawca powinien zagwarantować istnienie centrum wsparcia technicznego, umożliwiającego dostęp do najwyższej klasy specjalistów,

2. centrum wsparcia technicznego powinno być dostępne przez 24 godziny na dobę, przez 365 dni w roku,

3. awaryjne wsparcie techniczne powinno byś dostępne telefonicznie poprzez specjalny numer w sieci PSTN na terenie Polski,

4. specjalny awaryjny numer wsparcia technicznego powinien umożliwiać uzyskanie natychmiastowej odpowiedzi na zadane pytania od dyżurnego eksperta,

5. Dostawca powinien zapewnić możliwość korzystania z usług eksperta bezpośrednio w miejscu zainstalowania sprzętu w czasie nie dłuższym niż 24 godziny od momentu zaistnienia awarii.

Montaż i uruchomienie.

Dostawca przeprowadzi montaż i uruchomienie routerów RD w siedzibach Powiatowych Wydziałów Komunikacji.

Pod pojęciem montaż należy rozumieć dostarczenie routera, zasilacza awaryjnego oraz szafy telekomunikacyjnej o wysokości co najmniej 42U i niezbędnych materiałów instalacyjnych, a także instalację szafy i routera zasilaczem awaryjnym w miejscu wskazanym przez Zamawiającego.

Pod pojęciem uruchomienia należy rozumieć doprowadzenie zasilania oraz sprawdzenie poprawności działania routera podłączonego do zasilania.

5. Punkt styku pomiędzy siecią WAN CEPiK a centralną strukturą systemu.

Interfejsem na styku pomiędzy WAN CEPiK a strukturą centralną systemu będzie w warstwie drugiej Ethernet a w warstwie trzeciej protokół IP.

B. Wymagania do macierzy dyskowej

1. Pojemność macierzy minimum 2 TB.

2. Dostępne technologie RAID 1, RAID 5, RAID 1 ze strippingiem.

3. Interface'y FC min. 2 (Fiber Channel AL, SW),

FWDSCSI min. 2,

ESCON,

FICON.

4. Możliwość współpracy z systemami klasy mainframe i systemami dostarczonymi przez Dostawcę.

5. Możliwość dynamicznej zmiany konfiguracji (ilości i wielkości wolumenów i użytych poziomów RAID, migracji danych między dyskami).

6. Możliwość rozbudowy macierzy minimum do 15 TB (w jednej obudowie).

7. Pamięć CACHE 8 GB z możliwością rozbudowy minimum do 16 GB.

8. Macierz powinna być odporna na awarie zasilania.

9. Zdublowane przyłącza wewnętrznych napędów dyskowych.

10. Zabezpieczenie pamięci CACHE kopią lustrzaną.

11. Odporność na awarię komponentów macierzy.

12. Możliwość wymiany poszczególnych komponentów, dokonywania rozbudowy macierzy oraz uaktualnień i wprowadzania poprawek bez konieczności wstrzymania pracy.

13. Wsparcie dla rozwiązań klastrowych (IBM AIX, SUN Solaris, HP-UX i inne).

14. Interface wewnętrzny FC, równoważny lub lepszy.

15. Możliwość zarządzania macierzą przy pomocy oprogramowania firmware i firm trzecich (CA Unicenter, HP OpeView, Tivoli itp...).

16. Macierz powinna mieć możliwość replikacji danych i realizacji połączeń dla disaster recovery.

17. Możliwość wykorzystania do replikacji następującej infrastruktury:

• ESCON,

• IP,

• Łącza telekomunikacyjne (E1, E3, ATM).

18. Możliwość tworzenia wielu kopii roboczych z poziomu HW.

19. Możliwość tworzenia przyrostowej kopii oraz dodatkowych kopii roboczych w zdalnych ośrodkach.

20. Możliwość wykonywania kopii między środowiskiem mainframe a systemami otwartymi z wykorzystaniem wewnętrznych mechanizmów macierzy.

21. Możliwość bezkonfliktowej współpracy z OLTP i DSS.

22. Wsparcie dla systemów operacyjnych HP-UNIX, Linux, Microsoft Windows 2000 i NT, Z/OS.E oraz innych, które Dostawca określi w ofercie..

C. Wymagania dla monitorów na stanowiskach w punktach rejestracyjnych

Typ monitora	LCD
Rozdzielczość	128*1024 (SXVGA)
Wielkość piksela	0.264 mm(H)*0,264mm(V)
Przekątna widoczna	17''
Kąt widzenia (H/V)	150/140
Sygnał	Analog / R.G.B., 0.7 Vp-p
Kontrast	400:1
Jasność	250 cd/m^2
Pobór mocy	30 W Saving Mode: 5W
Czas reakcji	25 ms
Gwarancja	Na czas trwania kontraktu (na wszystkie podzespoły), gwarancja braku martwych pikseli (czarny, biały, czerwony, zielony, niebieski)

D. Wymagania dotyczące linii drukująco - kopertującej

• druk 450 000 stron dokumentów rocznie,

• wkładanie do koperty 1 - 5 stron,

• 300 000 kopert rocznie,

• połączenie z Centrum Podstawowym poprzez dedykowany serwer i łącze TCP/IP,

• software niezbędny do obsługi linii,

• linia powinna być obsługiwana przez dedykowany dla niej serwer, który będzie umożliwiał zarządzanie procesem drukująco-kopertujacym w ramach systemu CEPiK jak również konsolidację z innymi rejestrami, które są w gestii Zamawiającego.

Załącznik nr 4.3. -[Wymagania dot. Tymczasowego Centrum Podstawowego]

do „Opisu przedmiotu zamówienia

na wykonanie, wdrożenie

oraz obsługę eksploatacyjną i rozwój

systemu informatycznego wraz z robotami budowlanymi (adaptacyjnymi) pomieszczeń przeznaczonych na ten cel”

Wymagania techniczne dotyczące pomieszczeń adaptowanych na Tymczasowe Centrum Podstawowe CEPiK

Tymczasowe Centrum Podstawowe zostanie zlokalizowane w:

1. Pomieszczeniu istniejącej hali komputerowej, w której umieszczone zostaną serwery. Pomieszczenie to wyposażone jest w:

1. instalację bardzo wczesnej detekcji dymu,

2. stałą instalację gaśniczą,

3. instalację kontroli dostępu,

4. instalację napięcia gwarantowanego,

5. sieć logiczną,

6. instalację sygnalizacji włamania,

7. instalację oświetleniową i gniazd wtykowych,

8. zasilanie serwerów,

9. klimatyzację,+

10. wentylację mechaniczną,

oraz dysponuje zapasem mocy chłodniczej.

1. Pomieszczeniu magazynowym o powierzchni 75 m² wyposażonym w:

1. standardową instalację sygnalizacji pożaru,

2. instalację kontroli dostępu,

3. instalację napięcia gwarantowanego,

4. sieć logiczną,

5. instalację sygnalizacji włamania,

6. instalację oświetlenia i gniazd wtykowych,

7. instalację cieplną.

• konieczność wyposażenia w klimatyzację.

1. Pokojach nr: 3, 4, 9, 10, 11, 12, 13, 15, 16 i 25 o łącznej powierzchni użytkowej 335,0 m² znajdujących się w przyziemiu hali EMC - przeznaczonych na pomieszczenia techniczne.

W pomieszczeniach tych należy wykonać:

• instalację sygnalizacji pożaru,

• instalację kontroli dostępu,

• instalację antywłamaniową,

• instalację napięcia gwarantowanego,

• instalację oświetleniową,

• klimatyzację,

• antywłamaniową stolarkę okienną z szybą co najmniej P3,

• drzwi antywłamaniowe o odpowiedniej odporności ogniowej,

• roboty ogólnobudowlane.

2. Pokojach nr 17, 21, 22, 23 i 24 o łącznej powierzchni użytkowej 98,0 m² znajdujących się w przyziemiu hali EMC - przeznaczonych na pomieszczenia biurowe.

W pomieszczeniach tych należy wykonać standardowe prace budowlane wraz z doprowadzeniem sieci napięcia gwarantowanego i wymianą stolarki drzwiowej i okiennej.

3. Pokojach nr 405÷413, 419 i 421 o łącznej powierzchni użytkowej 207,m² znajdujących się na IV piętrze budynku LIPSK I - przeznaczone na pomieszczenia biurowe.

Są to pomieszczenia hotelowe, które należy zaadaptować na pokoje biurowe.

Wszystkie remontowane pomieszczenia należy wykonać zgodnie z przepisami Prawa budowlanego i Polskimi Normami.

W celu określenia precyzyjnego zakresu prac zaleca się, by oferent dokonał wizji lokalnej pomieszczeń przeznaczonych na zaadaptowanie.

A- podmiot wprowadza dane do CEPiK

B -podmiot otrzymuje dane z CEPiK

C -ważniejsze zobowiązania, uwarunkowania proceduralne, wymogi dokumentacyjne

Jeżeli brak jest odniesienia do ustawy z której pochodzi cytowany artykuł, to chodzi o ustawę Prawo o ruchu drogowym, w przeciwnym przypadku jest odniesienie do ustawy o ubezpieczeniach obowiązkowych, UFG i PBUK - oznaczonej jako ustawa OC.

Kursywa (też kolor niebieski) oznacza odniesienie do CEK, druk normalny (kolor czarny) - odniesienie do CEP

Inne niż określone w art. 80c, ust 1, w tym również posiadacze pojazdu powierzonego przez zagraniczna osobę fizyczną lub prawną (art. 73. ust.5)

400 punktów rejestracyjnych * średnio 7 stanowisk w punkcie

85 stanowisk w Policji ((17 KWP+1 KGP+1 Szkoła Policyjna)*5) + po 5 stanowisk w pozostałych 5 podmiotach uprawnionych

Przy sporządzaniu poniższej analizy (i kolejnych podobnych) przyjęto następujące konwencje:

— przez czynność rozumie się wykonanie całej procedury administracyjnej (np. rejestracji pojazdu czy też wydania prawa jazdy),

— przez zapytanie rozumie się pytanie kierowane do systemu dotyczące jednego pojazdu/kierowcy,

— przez typowanie rozumie się pytanie kierowane do systemu, którego wynikiem jest zbiór pojazdów/kierowców spełniający zadane kryteria,

— pogrubioną czcionką zaznaczono przyjęte założenia liczbowe, czcionką zwykła — wielkości wyliczone na podstawie założeń, czcionką pochyłą — zaznaczono te założenia, które wynikają z czynników zewnętrznych w stosunku do systemu (np. skala „obrotu” pojazdami, skala działań Policji, liczba samochodów w kraju).

Przez średni czas w rozumieniu tego dokumentu rozumie się wielkość średnią długookresową (np. roczną).

Przez określenie „pojedyncze” obiekty tu i w innych wymaganiach dotyczących czasowych charakterystyk systemu rozumie się do 10 obiektów wskazywanych przy pomocy identyfikatorów (np. w przypadku pojazdów — nr rejestracyjny, VIN, nr nadwozia, nr dowodu rejestracyjnego itp.).

Przez czas maksymalny w niniejszym dokumencie rozumie się taką wielkość, która jest przekraczana przez nie więcej niż 1% zdarzeń (chyba, że w sposób wyraźny zaznaczono inaczej).

1000 pytań z Policji + 1000 z innych podmiotów (SG, ITD.)

„Odczytywanie danych dotyczących obiektu” w rozumieniu tego zapisu nie obejmuje dostępów do danych, których jedynym celem jest wyszukanie obiektów, których dotyczyć ma właściwa operacja.

Bez uwzględnienia czasu przesyłu komunikatów przez elementy infrastruktury niebędące przedmiotem dostaw od Wykonawcy systemu oraz ew. czasu oczekiwania systemu CEPiK na akcje innych systemów.

Tzn. takich, które są opisane w metodykach i standardach, na które dostawca powołuje się w ofercie.

Strona 29z 138

Użytkownik końcowy

Aplikacja lokalna do kontaktu z warstwą centralną

Warstwa centralna CEPiK

Aplikacja centralna do kontaktu z warstwą lokalną i do autoryzacji dostępu

Użytkownik końcowy

Aplikacja lokalna do kontaktu z warstwą centralną

Użytkownik końcowy pracujący we właściwym dla podmiotu środowisku IT lub z wykorzystaniem PIC

Warstwa centralna CEPiK

Aplikacja do autoryzacji serwera podmiotu

Aplikacja do obsługi właściwej funkcjonalności

Serwer komunikacyjny podmiotu

Użytkownik końcowy pracujący we właściwym dla podmiotu środowisku IT lub z wykorzystaniem PIC

Serwer komunikacyjny i aplikacyjny podmiotu

Użytkownik końcowy pracujący w środowisku dostarczonym przez Dostawcę

Użytkownik końcowy pracujący w środowisku dostarczonym przez Dostawcę

Warstwa centralna CEPiK

Aplikacja do autoryzacji serwera podmiotu

Aplikacja do obsługi właściwej funkcjonalności

---