Urząd przyjazny cudzoziemcom wzrost poziomu świadczonych usług poprzez wdrożenie nowoczesnych rozwiązań teleinformatycznych



Pobieranie 374,57 Kb.
Strona5/5
Data24.02.2019
Rozmiar374,57 Kb.
1   2   3   4   5

REJESTR WNIOSKÓW CUDZOZIEMCÓW


Rejestr Wniosków Cudzoziemców (RWC) stanowić będzie narzędzie wspomagające pracę oddziałów WSOC zajmujących się rozpatrywaniem wniosków cudzoziemców. Ma także usystematyzować i ułatwić prace pracownikom i kierownikom tych oddziałów. Dostęp do bazy wniosków i pełen przegląd aktualnych zadań pozwoli na usprawnienie procesu rozpatrywania wniosków, a możliwość szybkiego informowania cudzoziemców (poprzez powiązanie RWC z Portalem) wpłynie na zwiększenie liczby wydanych decyzji.

10.1. Podstawowe informacje na temat funkcjonowania Wydziału Spraw Obywatelskich i Cudzoziemców


  1. Z uwagi na fakt, że projekt dotyczy cudzoziemców niebędących obywatelami Unii Europejskiej, poniżej przedstawione zostanie funkcjonowanie oddziałów WSOC zajmujących się obsługą spraw tej grupy klientów;

  2. Przyjmowaniem i wstępną weryfikacją wniosków zajmują się pracownicy Oddziału Paszportowego i Obsługi Klienta (OPiOK);

  3. Merytorycznym rozpatrywaniem wniosków, kontaktami z wnioskodawcami i organami kontrolnymi oraz przygotowywaniem decyzji zajmują się pracownicy trzech Oddziałów Legalizacji Pobytu (OLP);

  4. Sprawami związanymi z ubieganiem się cudzoziemców o nadanie obywatelstwa polskiego zajmuje się Oddział Obywatelstwa Polskiego (OOP);

  5. Centralnym systemem, w którym przetwarzane są sprawy cudzoziemców jest system POBYT zarządzany i modernizowany przez Urząd do Spraw Cudzoziemców. Ze względu na fakt, że system działa w wydzielonej sieci WAN, która nie ma dostępu do Internetu, nie można wykorzystać systemu do wymiany korespondencji z klientami urzędu ani do organizacji pracy wewnątrz oddziałów WSOC;

  6. W DUW wdrożony jest System Elektronicznego Zarządzani Dokumentacją (EZD). Oddziały OLP Wykorzystują ten system jedynie do rejestracji spraw i wysyłki korespondencji. Autorzy EZD udostępnili interfejs API do integracji innych systemów z EZD. Wykonawca tworzonego systemu będzie mieć za zadanie, albo wykorzystać narzędzia API do wysyłania korespondencji przez EZD, albo opracować własną procedurę wysyłania dokumentów, w tym adresacji kopert i zwrotek oraz generowania pocztowej listy nadawczej.

  7. Rezerwacja wizyt i zarządzanie kolejką klientów realizowane są przez OPiOK z wykorzystaniem systemu kolejkowego. W celu ułatwienia cudzoziemcom kontaktu z urzędem poprzez utworzenie jednego portalu, na którym będą posiadać komplet niezbędnych narzędzi, Wykonawca Systemu musi zapewnić możliwość rezerwacji wizyt z poziomu PIO, w oparciu o API dostarczone przez dostawcę systemu kolejkowego;

  8. Uproszczony przebieg rozpatrywania spraw cudzoziemców jest następujący:

  1. Złożenie wniosku przez cudzoziemca;

  2. Rejestracja wniosku przez pracownika OPiOK;

  3. Dekretacja wniosku do kierownika OLP;

  4. Przekazanie wniosku pracownikowi merytorycznemu przez kierownika OLP;

  5. Weryfikacja formalna wniosku. Na tym etapie pracownik może wezwać klienta do uzupełnienia braków formalnych;

  6. Korespondencja ze stronami sprawy w celu zgromadzenia kompletnego materiału dowodowego w sprawie;

  7. Opracowanie i podpisanie decyzji;

  8. Wydanie decyzji;

  9. W przypadku decyzji negatywnej, cudzoziemiec ma prawo wnieść odwołanie od decyzji. Po wniesieniu odwołania pracownik przygotowuje niezbędną dokumentacje i przekazuje sprawę do II instancji.

10.2. Wymagania ogólne dla Rejestru Wniosków Cudzoziemców


  1. Moduł RWC będzie narzędziem wykorzystywanym w codziennej pracy oddziałów zajmujących się obsługą spraw cudzoziemców. Główne zadania modułu RWC są następujące:

  1. Wspomaganie kierowników oddziałów OLP w organizacji pracy oddziałów;

  2. Ujednolicenie informacji o wszystkich wnioskach cudzoziemców poprzez utworzenie centralnej bazy wniosków;

  3. Zarządzanie wnioskami cudzoziemców od momentu rejestracji do wydania decyzji.

  4. Usprawnienie i ułatwienie kontaktu z klientami poprzez możliwość przekazywania informacji za pośrednictwem Portalu Informacyjno-Operacyjnego i bramkę SMS;

  5. Pełne raportowanie pracy oddziałów dla kierownictwa Wydziału SOC;

  1. W Tabeli 8 zamieszczono ogólne wymagania dotyczące moduł RWC.

Tabela 8: Wymagania dla Rejestru Wniosków Cudzoziemców

Kod

Wymagania dotyczące minimalnej wartości parametru

RWC01

RWC musi być aplikacją dostępną przez przeglądarkę internetową

RWC02

RWC musi być ściśle zintegrowany z PIO. Oba moduły Systemu muszą działać na wspólnej bazie danych. Natomiast przepływ informacji jest jednostronny, tzn. informacje generowane w RWC mogą być widoczne na PIO

RWC03

Dostęp do RWC wymaga podania loginu i hasła

RWC04

Konta użytkowników RWC zakładane są przez Administratora Systemu. Administrator nadaje także uprawnienia do RWC

RWC05

Możliwość zakładania spraw przez pracowników WSOC, dołączania dokumentów do sprawy, zamykania i ponownego wznawiania biegu sprawy

RWC06

Możliwość dekretacji dokumentów przez użytkowników RWC, wycofywanie niewłaściwie zadekretowanych pism, zapisywanie w bazie danych historii dekretacji (od kogo?, do kogo?, kiedy?)

RWC07

System musi umożliwiać wyszukiwanie pisma, wskazywanie użytkownika, który je aktualnie posiada oraz śledzenie historii pisma od momentu jego zarejestrowania do bieżącego momentu

RWC08

Każdy pracownik ma dostęp do swoich spraw, kierownik ma możliwość podglądu spraw wszystkich swoich pracowników, Dyrekcja WSOC może widzieć wszystkie sprawy rejestrowane w systemie

RWC09

Musi istnieć mechanizm zastępstw. Ustanawianie zastępstw należy do kompetencji kierownika oddziału lub Administratora Systemu

RWC10

System musi rejestrować w bazie danych operacje dokonywane przez użytkowników RWC. Poziom szczegółowości gromadzonych danych musi być jednym z parametrów konfiguracyjnych Systemu, który może być zmieniany przez Administratora Systemu

RWC11

Wszystkie operacje wykonywane na koncie osoby zastępowanej muszą być jednoznacznie identyfikowalne, jako operacje dokonywane „w zastępstwie za…”

RWC12

Pracownik merytoryczny musi mieć możliwość wygenerowania informacji, która będzie wysłana do klienta i/lub umieszczona na jego koncie na PIO

RWC13

Pracownik musi mieć możliwość wysłania informacji SMS z poziomu RWC poprzez bramkę SMS

RWC14

System musi posiadać funkcjonalność umożliwiającą ustawienie granicznych terminów realizacji poszczególnych spraw i sygnalizowanie przekroczenia tych terminów

RWC15

RWC musi posiadać zaimplementowane szablony pism. Podczas tworzenia pisma przez pracownika, System powinien automatycznie uzupełniać niektóre pola danymi znajdującymi się w bazie danych (np. dane klienta, adres, klienta, numer sprawy, itp.)

RWC16

Administrator lub upoważniony użytkownik musi mieć możliwość edycji wizualnej szablonu, dołączania nowych szablonów do listy szablonów, usuwania szablonów z listy.

RWC17

System musi umożliwiać generowanie raportów, zestawień i statystyk obrazujących zarówno funkcjonowanie całego Systemu, jak i pracy poszczególnych oddziałów czy też pracowników. Administrator musi mieć dostęp do generatora raportów lub generatora zapytań SQL, umożliwiającego stworzenie niestandardowego raportu lub zestawienia

RWC18

System musi umożliwiać dostęp do terminarza, w którym pracownik może zarezerwować termin wizyty dla klienta. Informacja ta zostanie przekazana do PIO i umieszczona na koncie klienta

RWC19

Z poziomu RWC musi być możliwość rejestracji cudzoziemca w bazie klientów podczas wizyty tego ostatniego w urzędzie

RWC20

Powyższa opcja jest niezbędna w celu zachowania pełnej informacji o składanych wnioskach i ma zastosowanie, gdy klient przyniósł do urzędu jedynie odręcznie wypełniony wniosek

RWC21

System musi umożliwiać drukowanie adresów oraz tzw. „białych zwrotek” z poziomu RWC. Dodatkowo, System musi umożliwiać generowanie Pocztowej Książki Nadawczej zawierającej zbiorcze zestawienie listów przygotowanych do wysłania w danym dniu

RWC22

Obsługa RWC powinna w jak największym stopniu wykorzystywać dane słownikowe

RWC23

Każdy użytkownik RWC (pracownik WSOC) musi mieć możliwość wygenerowania listy klientów, których sprawy aktualnie prowadzi. Lista powinna zawierać także informacje o dacie wszczęcia sprawy, rodzaju wniosku i jego aktualnym statusie.

10.3. Procedura składania i rozpatrywania wniosków


  1. W Tabeli 9 opisany został przykładowy przebieg procesu złożenia i rozpatrzenia wniosku cudzoziemca. Rozpisane zostały kolejne kroki od momentu rejestracji klienta na Portalu Informacyjno-Operacyjnym do momentu wydania decyzji administracyjnej.

  2. Niektóre wymagania pojawiły się już wcześniej, jednakże dla spójności opisu wymagania te zostają w poniższej tabeli powtórzone;

  3. Wszystkie etapy tego procesu muszą mieć odwzorowanie w tworzonym Systemie.

Tabela 9: Wymagania dla procedury obsługi wniosków cudzoziemców

Kod

Wymagania dotyczące minimalnej wartości parametru

POW01

Dostęp do Modułu Operacyjnego PIO wymaga wcześniejszej rejestracji

POW02

Cudzoziemiec dokonuje rejestracji albo samodzielnie, albo przez pełnomocnika

POW03

Przy rejestracji klient musi podać przynajmniej następujące dane

  1. Nazwisko i nazwisko rodowe **

  2. Imię lub imiona **

  3. Imię ojca i matki

  4. Datę i miejsce urodzenia

  5. PESEL (o ile klient go posiada)

  6. Narodowość **

  7. Obywatelstwo **

  8. Rodzaj dokumentu tożsamości **

  9. Seria i numer dokumentu tożsamości **

  10. Data ważności dokumentu tożsamości **

  11. Adres zamieszkania (dane jak w bazie TERYT) **

  12. Adres e-mail **

  13. Telefon komórkowy

  14. Login

  15. Jedna z opcji: klient albo pełnomocnik

POW04

Przy zaznaczeniu opcji „pełnomocnik”, cudzoziemiec musi podać dane pełnomocnika (vide wymaganie OPR07)

POW05

Przy danych adresowych System powinien wykorzystać dane z systemu TERYT, a poszczególne pola powinny być wypełniane poprzez wybór z listy wyboru.

POW06

System musi, tam gdzie to możliwe, umożliwiać wybór z danych słownikowych

POW07

System zapisuje dane użytkownika w „poczekalni” i wysyła na adres e-mail Kod ID klienta i hasło

POW08

Klient wprowadza otrzymane dane i potwierdza rejestrację

POW09

Dane klienta zostają zapisane w bazie klientów DUW

POW10

Jeżeli pełnomocnik zamierza dokonać jakieś czynności na koncie klienta, musi najpierw zalogować się na swoje konto, wybrać klienta z listy klientów i podać jego login.

POW11

Wybór formularza dokonuje się z listy formularzy. Przy wyborze klient może skorzystać z krótkiego opisu przeznaczenia formularza. Może też skorzystać z linku do stromy modułu informacyjnego, na której znajdzie szczegółowe informacje dotyczące tego formularza.

POW12

Przy wypełnianiu formularza klient ma dostęp do pomocy kontekstowej, szczególnie w miejscach, w których klienci popełniają najczęściej błędy

POW13

System musi automatycznie wypełnić pola formularza danymi zapisanymi w bazie danych, dlatego też po wypełnieniu każdego formularza System musi uzupełnić w bazie klientów wszystkie, dotychczas niezapisane dane na temat klienta.

POW14

Klient może zmienić niektóre swoje dane osobowe. Wtedy System musi wymusić potwierdzenie zmiany tych danych

POW15

System musi dokonywać walidacji wprowadzanych danych (np. dla kodu pocztowego, numeru telefonu, adresu e-mail, itp.)

POW16

Po wypełnieniu i zatwierdzeniu formularza przez klienta, dane z formularza zostają przesłane do „poczekalni wniosków”, Zostają uzupełnione metadanymi dotyczącymi formularza (ID formularza, rodzaj wniosku, data utworzenia, ID klienta, suma kontrolna, itp.)

POW17

Klient musi wydrukować formularz. Każda strona wydrukowanego formularza musi posiadać nagłówek, zawierający sumę kontrolną oraz kod kreskowy z numerem (ID) wniosku. Kod kreskowy wykorzystywany jest do szybkiego odnajdywania wniosku w module RWC

POW18

Klient może zarezerwować termin wizyty w systemie kolejkowym z poziomu Modułu Operacyjnego PIO.

POW19

W urzędzie cały proces dekretacji i weryfikacji wniosków odbywa się w module RWC

POW20

Podczas składania wniosku w urzędzie, pracownik OPiOK porównuje sumę kontrolną wniosku widniejącą na złożonym formularzu z danymi z bazy. Niezgodność sum powoduje automatyczne odrzucenie wniosku

POW21

Akceptacja wniosku przez pracownika OPiOK powoduje automatyczne przeniesienie wniosku z „poczekalni wniosków” do bazy wniosków.

POW22

Klient może złożyć wniosek wypełniony odręcznie. W tym przypadku pracownik OPiOK musi mieć możliwość zarejestrowania takiego wniosku w bazie danych podając jedynie imię i nazwisko klienta, rodzaj i numer dokumentu tożsamości. Pozostałe dane zostaną uzupełnione przez pracownika merytorycznego

POW23

Wniosek trafia do Dyrektora WSOC i zostaje zadekretowany na kierownika jednego z Oddziałów Legalizacji Pobytu (OLP). Dekretacja ta jest odwzorowana w Systemie

POW24

Kierownik dekretuje w Systemie wniosek na pracownika merytorycznego

POW25

Pracownik merytoryczny uzupełnia w Systemie brakujące dane dotyczące otrzymanego wniosku

POW26

Podczas weryfikacji wniosku pracownik merytoryczny może wysyłać do klienta wezwania o uzupełnienie braków formalnych lub złożenie wyjaśnień. Wezwania są generowane na wcześniej przygotowanych szablonach, System automatycznie uzupełnia wybrane pola (dane adresowe, numer sprawy, itp.). Pracownik wprowadza jedynie informacje merytoryczne. System drukuje etykietę adresową oraz, w razie konieczności, wypełnia „białą zwrotkę”, dodając jednocześnie pismo do Pocztowej Książki Nadawczej

POW27

Wersja elektroniczna monitu zostaje przesłana do modułu PIO i trafia na konto klienta.

POW28

Pracownik merytoryczny musi mieć także możliwość wysłania informacji do klienta za pośrednictwem bramki SMS

POW29

Pracownik merytoryczny wysyła także zapytania do innych jednostek. Postępowanie w tym przypadku jest podobne

POW30

Wszystkie operacje dokonywane przez pracownika są rejestrowane w bazie danych. Administrator Systemu musi mieć możliwość zmiany poziomu szczegółowości rejestrowanych czynności

POW31

Proces weryfikacji wniosku będzie podzielony na etapy. Etapy muszą być danymi słownikowymi.

POW32

Dla każdego wniosku musi być odnotowywany przez pracownika merytorycznego moment zakończenia kolejnego etapu. Baza danych powinna przechowywać takie dane (ID etapu i datę jego zakończenia)

POW33

W momencie rejestracji w Systemie zakończenia etapu, informacja ta musi być przesłana do PIO i pojawić się na koncie klienta

POW34

Pracownik merytoryczny musi mieć w Systemie możliwość rejestracji wizyt klientów i możliwość podglądu tych rejestracji (terminarz)

POW35

Kierownik OLP musi mieć możliwość:

  1. podglądu wszystkich spraw prowadzonych przez jego podwładnych;

  2. ustanawiania zastępstw;

  3. przekazania sprawy innemu pracownikowi;

  4. weryfikacji terminowości realizacji spraw

  5. dostępu do raportów obrazujących prace jego oddziału

POW36

Po wydaniu decyzji negatywnej, klient ma możliwość złożenia odwołania. System musi zarejestrować ten fakt w bazie danych



  1. MODUŁ ADMINISTRATORA SYSTEMU


Moduł Administratora Systemu przeznaczony jest do codziennego nadzorowania pracy całego Systemu, jego bazy danych i poszczególnych modułów. Poniżej podano minimalne wymagania dla tego modułu.

Tabela 10: Wymagania dla modułu administracyjnego Systemu

Kod

Wymagania dotyczące minimalnej wartości parametru

ADM01

Administrator ma dostęp do Modułu Administratora Systemu poprzez przeglądarkę internetową albo konsolę administracyjną

ADM02

Administrator musi mieć pełny dostęp do wszystkich modułów oraz bazy danych Systemu

ADM03

Administrator musi mieć możliwość tworzenia i modyfikacji kont użytkowników RWC (pracowników WSOC)

ADM04

Administrator musi mieć możliwość odzwierciedlenia w Systemie struktury organizacyjnej Wydziału SOC.

ADM05

System musi umożliwić zapisanie w bazie danych przynajmniej następujących informacji o pracowniku::imię lub imiona,, nazwisko lub nazwiska, stanowisko, symbol oddziału, numer pokoju, numer telefonu, login i hasło

ADM06

System musi umożliwiać zarządzanie rolami w systemie, przy czym Wykonawca musi przygotować podstawowe role do każdego z modułów Systemu.

ADM07

Każda z ról systemu musi posiadać listę uprawnień wraz z opisami uprawnień.

ADM08

Administrator musi mieć możliwość dodania dowolnej roli w systemie i przypisania jej dowolnej listy uprawnień. Musi mieć także możliwość zarządzania rolami przypisanymi do pracowników

ADM09

System ról, uprawnień i użytkowników musi posiadać interfejs użytkownika, który umożliwia ergonomiczne i efektywne zarządzanie tym zakresem.

ADM10

System musi posiadać funkcję „przeładowania uprawnień” w trybie rzeczywistym systemu. Przeładowanie uprawnień polega na wymianie listy uprawnień na serwerze aplikacyjnym w trakcie sesji zalogowanego użytkownika, co pozwala na zarządzanie dostępami bez konieczności wylogowywania użytkowników Systemu.

ADM11

System musi posiadać miejsce do zarządzania wszelką parametryzacją Systemu, gdzie:

  1. Pogrupowane są obszary parametryzacji Systemu

  2. Każdy z parametrów posiada funkcję edycji

  3. Każdy z parametrów charakteryzowany jest przez opis, nazwę i wartość

ADM12

System musi posiadać sparametryzowane m.in.: dane urzędu, obsługę SMS, email

ADM13

System musi mieć obszar zarządzania zastępstwami w organizacji, gdzie będzie istniała możliwość:

  1. dodania zastępstwa charakteryzowanego przez parę osoba zastępowana, - osoba zastępująca;

  2. dni „od – do”;

  3. zdefiniowania szczegółowego dostępu do danych dla danego zastępstwa,

  4. zakończenia zastępstwa

ADM14

Administrator musi posiadać możliwość przeglądania rejestru operacji wykonanych w Systemie. Przegląd rejestru operacji możliwy jest do przeszukania m.in. według daty i czas od – do, użytkownika, który dokonał operacji, typu obiektu i rodzaju operacji wykonywanej (np. aktualizacja danych, błąd, modyfikacja danych, usunięcie danych, import, etc.)

ADM15

Zarówno dla klienta (PIO), jak i pracownika (RWC), System musi umożliwiać przeglądanie rejestru czynności wykonywanych przez wybranego użytkownika z wyróżnieniem daty i czasu wykonania czynności oraz obiektu w systemie, którego to dotyczy

ADM16

Administrator musi mieć możliwość tworzenia kopii zapasowej Systemu i przywracania Systemu z utworzonej kopii

ADM17

System musi umożliwiać Administratorowi generowanie niestandardowych raportów i zestawień poprzez udostępnienie generatora raportów lub generatora zapytań SQL z poziomu Modułu Administratora Systemu
  1. WYMAGANIA DOTYCZĄCE ELEMENTÓW PROCESU WDRAŻANIA SYSTEMU


Zamawiający wymaga, by proces tworzenia i wdrażania Systemu przebiegał według scenariusza opisanego poniżej. Szczegółowy harmonogram realizacji prac zostanie uzgodniony na etapie tworzenia PTW i stanowić będzie jego integralną część.

12.1. Zalecany scenariusz prac jest następujący:


W Tabeli 11 podano zalecany scenariusz realizacji projektu.
Tabela 11: Zakres prac do wykonania w trakcie realizacji projektu

Lp.

Zadanie

Minimalny zakres prac do zrealizowania przez Wykonawcę

1..

Opracowanie Projektu Techniczno-Wykonawczego Systemu

Przeprowadzenie niezbędnych uzgodnień z Zamawiającym, ustalenie szczegółów realizacji projektu;

Opracowanie i przekazanie Zamawiającemu wstępnej wersji Projektu Techniczno-Wykonawczego (PTW);

Ustalenie z Zamawiającym ostatecznego kształtu PTW;

Dostarczenie do zatwierdzenia ostatecznej wersji PTW;

Dostarczenie do zatwierdzenia Harmonogramu Realizacji Projektu.


2.

Wykonanie platformy serwerowej Systemu

W przypadku wyboru środowiska maszyn wirtualnych:

  1. Dostarczenie wszystkich wymaganych licencji (system operacyjny, silnik DBMS, inne aplikacje niezbędne do funkcjonowania Systemu) wraz z 3-letnim okresem wsparcia (w przypadku licencji terminowych);

  2. Instalacja i uruchomienie niezbędnych serwerów wirtualnych, w tym instalacja systemów;

  3. Instalacja, konfiguracja i uruchomienie oprogramowania bazy danych.

W przypadku dostarczenia serwera fizycznego:

  1. Dostarczenie i montaż serwera w szafie serwerowej DUW;

  2. Instalacja i uruchomienie oprogramowania bazowego;

  3. Instalacja, konfiguracja i uruchomienie oprogramowania bazy danych;

  4. Dostarczenie wszystkich niezbędnych licencji i gwarancji producentów dostarczonego sprzętu i oprogramowania wraz z 3-letnim okresem wsparcia.

W celu ujednolicenia zapisów, w dalszej części opisu oba warianty nosić będą wspólną nazwę „środowiska serwerowego Systemu”.

3..

Wykonanie Rejestru Wniosków Cudzoziemców

Wykonanie wszystkich opisanych w PTW komponentów oprogramowania RWC;

Instalacja oprogramowania w środowisku serwerowym Systemu;

Wstępne uruchomienie oprogramowania;

Prezentacja działania RWC przedstawicielom Zamawiającego.

Dokonanie zmian funkcjonowania RWC w oparciu o wniesione sugestie Zamawiającego;

Uruchomienie testowe RWC.



4.

Wykonanie Portalu Informacyjno-Operacyjnego

Opracowanie i przedstawienie wstępnego projektu graficznego i funkcjonalnego portalu;

Dokonanie poprawek w projekcie uwzględniającego uwagi Zamawiającego;

Wykonanie PIO w oparciu o dostarczony przez Zamawiającego lub własny CMS;

Wstępne uruchomienie PIO na serwerach Zamawiającego;

Prezentacja PIO przedstawicielom Zamawiającego.

Dokonanie zmian funkcjonowania PIO w oparciu o wniesione sugestie Zamawiającego;

Uruchomienie testowe PIO.


5..

Wdrożenie systemu.

Integracja obu portali;

Wprowadzenie do bazy danych predefiniowanych danych (struktura organizacyjna, dane słownikowe, itp.);

Wstępne uruchomienie całości systemu.


6..

Testy funkcjonalne + wykonanie poprawek i uzupełnień

Opracowanie scenariuszy testów sprawdzających działanie Systemu;

Przekazanie scenariuszy testów do zatwierdzenia Zamawiającemu;

Przeprowadzenie testów funkcjonalnych Systemu na wybranych stacjach roboczych w DUW;

Przeprowadzenie testów modułu CMS;

Przeprowadzenie testów współpracy z aplikacjami zewnętrznymi, w tym z systemem kolejkowym;

Przeprowadzenie testów bezpieczeństwa systemu;

Dokonanie niezbędnych korekt błędów i nieprawidłowości w działaniu wszystkich testowanych modułów.

Instalacja poprawionych wersji oprogramowania.

Opracowanie i wdrożenie procedur Disaster Recovery oraz przeprowadzenie odpowiednich testów funkcjonowania Systemu w przypadku wystąpienia sytuacji awaryjnych.


7..

Przeprowadzenie szkoleń

Opracowanie i dostarczenie Instrukcji Administratora i Instrukcji Użytkownika Systemu;

Przeprowadzenie szkoleń dla administratorów systemu;

Przeprowadzenie szkoleń stanowiskowych dla pracowników WSOC;

Przeprowadzenie szkoleń stanowiskowych z obsługi modułu CMS dla redaktorów PIO.



8..

Opracowanie i dostarczenie dokumentacji odbiorowej

Dostarczenie dokumentacji funkcjonalnej Systemu, w tym pełnej struktury bazy danych (opis tablic, atrybutów i relacji);

Dostarczenie instrukcji użytkownika RWC;

Opracowanie instrukcji użytkownika PIO (w tym także zamieszczenie tej instrukcji na portalu);

Dostarczenie instrukcji redaktora PIO (w tym obsługi modułu CMS);

Dostarczenie instrukcji administratora Systemu;


9..

Uruchomienie produkcyjne systemu

Wstępne uruchomienie wersji produkcyjnej Systemu;

Zasilenie inicjacyjne bazy danych (przeniesienie danych z bazy danych wersji testowej);

Wstępna konfiguracja uprawnień użytkowników;

Instalacja w środowisku serwerowym Systemu wszystkich opracowanych szablonów dokumentów (pism, decyzji, wezwań, itp.);

Pełne uruchomienie Systemu.


10.

Testy końcowe i odbiór systemu

Zgłoszenie gotowości do testów końcowych Systemu;

Przeprowadzenie, w obecności przedstawicieli Zamawiającego całości testów w oparciu o zatwierdzony scenariusz testów;

Przeprowadzenie testów wydajnościowych przy pełnym obciążeniu;

Poprawa zgłoszonych błędów i usterek Systemu;

Przeprowadzenie ponownych testów;

Zgłoszenie Systemu do odbioru.

Udzielenie Zamawiającemu bezterminowej gwarancji na system „Przybysz” w zakresie przewidzianym w umowie;

Przeprowadzenie w obecności obu stron, odbioru końcowego;

Podpisanie Końcowego Protokołu Odbioru Prac.

Uwagi::


  1. Powyższy zakres prac jest jedynie podziałem zadań niezbędnych do pełnego zrealizowania przedsięwzięcia. Wykonawca, podczas tworzenia Projektu Techniczno-Wykonawczego (PTW), będzie musiał opracować i przedstawić do zatwierdzenia Harmonogram Realizacji Projektu (HRP);

  2. Maksymalny czas realizacji projektu wynosi 7 (siedem) miesięcy od daty podpisania umowy z Wykonawcą. Termin wykonania zadania jest jednym z kryteriów oceny ofert i Wykonawca może zadeklarować jego skrócenie.

  3. Opracowanie, dostarczenie i zatwierdzenie PTW wraz z HRP musi nastąpić nie później niż w terminie 14 dni + 6 dni roboczych od daty zawarcia umowy z Wykonawcą;

  4. Zamawiający wymaga, żeby prace były podzielone na etapy;

  5. Realizacja każdego etapu będzie kończyć się odbiorem częściowym i potwierdzane podpisanym przez obie strony stosownym dokumentem, wymienionym w tabeli 12;

  6. Zakończenie ostatniego etapu będzie potwierdzone Protokołem Końcowego Odbioru Prac.


Tabela12: Etapy realizacji projektu i protokoły potwierdzające ich ukończenie

Etap

Dokument potwierdzający należyte wykonanie etapu

Opracowanie Projektu Techniczno-Wykonawczego Systemu

Protokół Przekazania Projektu Techniczno-Wykonawczego

Wykonanie Rejestru Wniosków Cudzoziemców

Protokół Instalacji Rejestru Wniosków Cudzoziemców

Wykonanie Portalu Informacyjno-Operacyjnego

Protokół Instalacji Portalu Informacyjno-Operacyjnego

Opracowanie Scenariuszy Testów Funkcjonalnych Systemu

Protokół Przekazania Scenariuszy Testów Funkcjonalnych Systemu

Testy funkcjonalne + wykonanie poprawek i uzupełnień

Protokół Przeprowadzenia Testów Funkcjonalnych wraz z Kartą Akceptacji Testów Funkcjonalnych

Przeprowadzenie szkoleń

Protokół Przeprowadzenia Szkoleń

Opracowanie i dostarczenie dokumentacji

Protokół Przekazania Dokumentacji

Testy końcowe i odbiór systemu

Protokół Końcowego Odbioru Prac



12.2. Testy Systemu


W celu potwierdzenia poprawnego i w pełni zgodnego z opisanymi w niniejszym dokumencie wymaganiami Zamawiającego działania wdrożonego Systemu, Wykonawca ma obowiązek przeprowadzić – w obecności przedstawicieli Zamawiającego – testy funkcjonalne Systemu.

Poniżej zostały podane wymagania Zamawiającego dotyczące sposobu przygotowania i przeprowadzenia testów.


Tabela 13: Wymagania dotyczące testów Systemu

Kod

Wymagania dotyczące minimalnej wartości parametru

TST 01

Przed rozpoczęciem testów funkcjonalnych i testów bezpieczeństwa Systemu, Wykonawca musi opracować i dostarczyć Zamawiającemu do zatwierdzenia zestaw scenariuszy testów

TST02

Każdy scenariusz powinien zawierać przynajmniej następujące pola:

  1. rodzaj testów (np. testy Rejestru Wniosków Cudzoziemców, testy środowiska bazodanowego, itp.);

  2. cel scenariusza testów (np. weryfikacja funkcjonowania procesu dekretacji w RWC);

  3. opis czynności i kryteria poprawności;

  4. oczekiwane wyniki

TST03

Scenariusze testów muszą być dostarczone nie później niż 7 dni przed planowanym rozpoczęciem testów wynikających z Harmonogramu Realizacji Zadania

TST04

Zamawiający może wnieść uwagi do scenariuszy, które Wykonawca musi uwzględnić w ostatecznej wersji scenariuszy

TST05

Akceptacja scenariuszy testów zostanie potwierdzona podpisaniem Protokołu Przekazania Scenariuszy Testów Funkcjonalnych Systemu

TST06

Każdy test musi potwierdzać nie tylko bezbłędne działanie testowanej funkcjonalności ale również spełnienie warunków, założeń i parametrów określonych w niniejszym dokumencie

TST07

Każdy test musi być udokumentowany na Karcie Akceptacji Testu, na której będzie zapisana ocena testu oraz uwagi Zamawiającego

TST08

W razie jakichkolwiek uwag, Wykonawca musi dokonać modyfikacji działania Systemu i powtórzyć test

TST09

W momencie akceptacji wszystkich testów zostanie podpisany Protokół Przeprowadzenia Testów Funkcjonalnych

12.3. Szkolenia


Jednym z kluczowych elementów pełnego wdrożenia każdego systemu jest jak najlepsze przygotowanie do pracy użytkowników Systemu. W przypadku obecnego zadania, poza szkoleniami pracowników DUW, istotnym elementem szkoleń użytkowników PIO będzie instrukcja obsługi PIO dla cudzoziemców.

Poniżej podano podstawowe (minimalne) wymagania dotyczące szkoleń:



Tabela 14: Wymagania dotyczące szkoleń użytkowników i administratorów Systemu

Kod

Wymagania dotyczące minimalnej wartości parametru

SUA01

Przeprowadzenie szkoleń dla 2 osób z zakresu administrowania Systemem, w tym zarządzania użytkownikami i uprawnieniami, zabezpieczania i odtwarzania danych, administracji i konfiguracji zaoferowanego systemu bazodanowego (instalacja i konfiguracja bazy danych, obsługa narzędzi administratora, architektura systemu, zagadnienia związane z zachowaniem bezpieczeństwa, integralności i zabezpieczenia przed utratą danych, przywracaniem danych po awarii)

SUA02

Przeprowadzenie szkoleń dla 2 osób z zakresu administrowania Platformą Informacyjno-Operacyjną i obsługi modułu CMS

SUA03

Przeprowadzenie szkoleń stanowiskowych dla użytkowników Rejestru Wniosków Cudzoziemców. Wstępnie planuje się przeprowadzenie 6 tur szkoleń w siedzibie Zamawiającego. W każdej turze uczestniczyć będzie 15-20 użytkowników

SUA04

W przypadku szkoleń przeprowadzanych przez Wykonawcę, czas poszczególnych szkoleń nie może być krótszy niż:

  1. 8 godzin w przypadku szkoleń administratorów Systemu;

  2. 4 godziny – szkolenia z zarządzania platformą PIO i obsługą modułu CMS;

  3. 4 godziny na każdą turę szkoleń użytkowników RWC

SUA05

Wszystkie szkolenia prowadzone przez Wykonawcę muszą być potwierdzone Certyfikatem Ukończenia Szkolenia dla każdego uczestnika

SUA06

Zamawiający przewiduje publiczną prezentację funkcjonowania Portalu Informacyjno-Operacyjnego dla użytkowników PIO

SUA07

Szkolenia będą przeprowadzane w pomieszczeniach i na sprzęcie Zamawiającego

SUA08

Zamawiający nie dopuszcza zastąpienia szkoleń tradycyjnych szkoleniami e-learninfowymi

SUA09

Terminy i miejsce przeprowadzenia szkoleń Wykonawca każdorazowo będzie uzgadniać z Zamawiającym

SUA10

Po zakończeniu wszystkich szkoleń podpisany zostanie Protokół Przeprowadzenia Szkoleń

12.4. Dokumentacja odbiorowa


Jednym z warunków, które musi spełnić Wykonawca, będzie opracowanie i dostarczenie-na różnych etapach realizacji zadania – dokumentacji wykonanych prac.

Wymagania Zamawiającego w odniesieniu do dokumentacji są następujące:



Tabela 15: Wymagania dotyczące dokumentacji odbiorowej

Kod

Wymagania dotyczące minimalnej wartości parametru

DOK01

W trakcie realizacji zamówienia Wykonawca musi opracować, i dostarczyć przynajmniej następujące dokumenty:

  1. Projekt Techniczno-Wykonawczy Systemu;

  2. Harmonogram Realizacji Zadania;

  3. Scenariusze Testów Funkcjonalnych Systemu;

  4. Dokumentację funkcjonalną Systemu;

  5. Instrukcję użytkownika Rejestru Wniosków Cudzoziemców;

  6. Instrukcję użytkownika Portalu Informacyjno-Operacyjnego;

  7. W przypadku dostarczenia własnego oprogramowania CMS – instrukcję użytkownika CMS.

  8. Instrukcję Administratora Systemu

DOK02

W skład Dokumentacji Powykonawczej Systemu powinny wejść co najmniej następujące elementy:

  1. pełna struktura bazy danych Systemu (opis tabel, atrybutów i relacji);

  2. schemat logiczny połączeń najważniejszych modułów funkcjonalnych Systemu;

  3. opis konfiguracji Systemu, w tym lista parametrów konfiguracyjnych ze wskazaniem wartości standardowych (default values);

  4. opis procedur dotyczących bezpieczeństwa Systemu, w tym procedur przywracania działania Systemu po zdarzeniach krytycznych - Disaster Recovery.

DOK03

Dokumentacja wytworzona przez Wykonawcę powinna być dostarczona zarówno w formie wydrukowanej w co najmniej 2 kopiach, jak również w postaci cyfrowej - na płycie CD/DVD

DOK04

Do dokumentacji odbiorowej zalicza się także:

  1. karty Akceptacji Testów, w tym testów funkcjonalnych i testów bezpieczeństwa Systemu. Liczba Kart musi być zgodna z liczbą testów przewidzianych w zatwierdzonych scenariuszach;

  2. wszystkie Protokoły przewidziane w Tabeli 12;

  3. wszystkie licencje dla oprogramowania firm trzecich, które jest niezbędne dla prawidłowego działania Systemu;

  4. nielimitowana i bezterminowa licencja Wykonawcy na dostarczony System;

  5. dokument gwarancyjny Wykonawcy na dostarczony System na okres 60 miesięcy od daty podpisania Protokołu Końcowego Odbioru Prac

DOK05

Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji zamówienia charakteryzowały się wysoką jakością, na którą będą miały wpływ, takie czynniki jak:

  1. kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia;

  2. struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób;

  3. zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu;

  4. spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.

DOK06

Dokumentacja odbiorowa musi być dostarczona najpóźniej w dniu zgłoszenia przez Wykonawcę gotowości do odbioru

DOK07

Kompletność i merytoryczna zawartość Dokumentacji Odbiorowej będzie jednym z elementów oceny przez Komisję Odbiorową realizacji zamówienia
  1. Wymagania dotyczące gwarancji i asysty powdrożeniowej


Świadczenie usługi gwarancji ma na celu zapewnienie ciągłości sprawnego działania Systemu poprzez realizację działań naprawczych wynikających z analizy ujawnionych problemów, wykrytych błędów i wad systemów, niewłaściwego działania systemu, spadku wydajności.

Asysta powdrożeniowa Wykonawcy ma na celu wsparcie Administratorów i użytkowników Systemu w ich codziennej pracy w Systemie, pomocy w rozwiązywaniu problemów oraz udzielania porad i wskazówek w celu pełnego wykorzystania możliwości Systemu.



Zamawiający wymaga od Wykonawcy świadczenia usług gwarancji na przedmiot zamówienia oraz usługi asysty powdrożeniowej (wsparcia). Wymagania Zamawiającego w tym zakresie są następujące::

Tabela 16: Wymagania dla gwarancji i asysty powdrożeniowej

Kod

Wymagania dotyczące minimalnej wartości parametru

GWA01

Wykonawca zobowiązany jest świadczyć usługi asysty powdrożeniowej przez okres wskazany w ofercie, nie krótszy jednak n,iż 36 miesięcy od daty podpisania Protokołu Końcowego Odbioru Prac

GWA02

Wykonawca zobowiązuje się do dostarczania wolnych od wad kolejnych wersji Systemu

GWA03

Wykonawca musi dokonywać modyfikacji oprogramowania w celu dostosowania go do zmian w obowiązujących przepisach prawa

GWA04

Wykonawca zapewnia dostosowanie do obowiązujących przepisów nie później niż w dniu ich wejścia w życie

GWA05

Wykonawca zobowiązuje się do aktualizacji dokumentacji Użytkownika i/lub Administratora

GWA06

Wykonawca musi informować Zamawiającego o dostępnych aktualizacjach i poprawkach Systemów

GWA07

Wykonawca zobowiązuję się do instalacji i konfiguracji nowych wersji oprogramowania bazowego (systemu operacyjnego, silnika DBMS, itp.)

GWA08

Wykonawca zobowiązuję się do świadczenia konsultacji dla Administratorów w zakresie niezbędnych zmian w konfiguracji systemu.

GWA09

Wykonawca zapewni usługi wsparcia Administratorów i użytkowników Systemu. Wsparcie użytkowników obejmuje świadczenie usługi wsparcia technicznego, merytorycznego oraz konsultacji w celu utrzymania poprawnej pracy systemu zgodnego z wymaganiami zamówienia. W ramach usługi Wykonawca zobowiązany jest do udzielania odpowiedzi na pytania Użytkowników i Administratorów związane z bieżącą eksploatacją Systemu

GWA10

Usługi wsparcia będą świadczone w dni robocze w godzinach 8.00 -16.00

GWA11

Użytkownicy będą mogli zgłaszać problemy telefonicznie, pocztą elektroniczną lub faksem.

GWA12

W razie konieczności Wykonawca zobowiązany jest do udzielenia wsparcia w siedzibie Zamawiającego

GWA13

Wykonawca udzieli Zamawiającemu gwarancji na przedmiot zamówienia. Okres, na jaki Wykonawca udzieli gwarancji, jest jednym z kryteriów oceny ofert, nie może być jednak krótszy niż 36 miesięcy od daty podpisania Protokołu Końcowego Odbioru Prac, zapewniając jednocześnie odpowiedni serwis.

GWA14

W ramach gwarancji Wykonawca zobowiązany jest do nieodpłatnego:

  1. usuwania Błędów wynikających z przyczyn zawinionych przez Wykonawcę będących konsekwencją wystąpienia: błędu w Systemie, błędu lub wady fizycznej pakietu aktualizacyjnego lub instalacyjnego, błędu w dokumentacji administratora lub w dokumentacji użytkownika, błędu w wykonaniu usług przez Wykonawcę;

  2. usuwania Błędów związanych z realizacją usługi wdrożenia Systemu;

  3. usuwania Błędów spowodowanych aktualizacjami Systemu.

GWA15

Zamawiający ustala 3 kategorie błędów – błędy krytyczne, błędy istotne i błędy nieistotne

GWA16

Jako „Błąd krytyczny” rozumie się sytuację, w której nie jest możliwe prawidłowe użytkowanie Systemu z powodu uszkodzenia lub utraty spójności danych, struktur danych, błędnego funkcjonowania platformy systemowo-sprzętowej lub innej przyczyny powodującej, że system nie działa zgodnie z wymaganiem zamówienia. Jednocześnie nie jest znane obejście umożliwiające realizację celu zadania.

GWA17

Jako „Błąd” istotny rozumie się niezgodne z dokumentacją użytkową lub wymaganiami Zamawiającego określonymi w niniejszym OPZ lub innych dokumentach wytworzonych w czasie wdrożenia, działanie oprogramowania Systemu lub działania innego oprogramowania (np. standardowego), w skutek, którego niezgodnie zadziałało oprogramowanie Systemu. Jednocześnie znane jest obejście umożliwiające realizację celu zadania.

GWA18

Jako „Błąd nieistotny ” rozumie się zakłócenie działania oprogramowania, sprzętu polegające na nienależytym działaniu jego części, nie ograniczające działania całego Systemu; nie mające istotnego wpływu na zastosowanie Systemu

GWA19

Zgłaszanie błędu dokonywać będzie Administrator Systemu lub upoważnieni użytkownicy. Zgłoszenie musi być wysłane drogą elektroniczną lub faksem. Powinno zawierać opis Błędu oraz wstępną klasyfikację poziomu istotności Błędu .

GWA20

Wykonawca zobowiązany jest do potwierdzenia w ciągu 4 godzin w czasie okna dostępności usługi gwarancyjnej przyjęcie zgłoszenia. Potwierdzenie zostanie wysłane przez Wykonawcę do zgłaszającego.

GWA21

Wykonawca zobowiązany jest do usunięcia Błędów w następujących terminach:

  1. Błąd krytyczny - w terminie do 2 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę.

  2. Błąd istotny - w terminie do 5 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę,

  3. Błąd nieistotny - w terminie do 10 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę.

GWA22

W każdym przypadku Zgłaszający i Wykonawca mogą uzgodnić inny czas dostarczenia rozwiązania niż określono w warunkach gwarancji. W takim przypadku niezbędne jest potwierdzenie ustalonego terminu w formie pisemnej, faksem lub e-mailem

GWA23

Wykonawca zobowiązany jest dokonywać okresowego (kwartalnego) przeglądu systemu, w celu zachowania pełnej sprawności i wydajności wszystkich jego komponentów;




1   2   3   4   5


©operacji.org 2017
wyślij wiadomość

    Strona główna