Zakres zmian funkcjonalnych w ramach rozbudowy II



Pobieranie 107,95 Kb.
Data23.10.2017
Rozmiar107,95 Kb.



Załącznik nr 1 do SIWZ

sprawa numer: 20/SISP/PN/2012



Zakres zmian oprogramowania Portalu Sprawozdawczego GUS

  1. Utworzenie podsystemu badań archiwalnych (części archiwalnej Portalu Sprawozdawczego), wsparcie podczas migracji zasobów archiwalnych edycji badań

Należy utworzyć podsystem badań archiwalnych przeznaczony do przechowywania oraz udostępniania zasobów zakończonych edycji badań. Podsystem ten będzie funkcjonował w ramach odrębnej infrastruktury sprzętowej zapewnionej przez Zamawiającego. Zamawiający przewiduje udostępnienie maksymalnie trzech serwerów (o parametrach: 4 CPU, 32 GB RAM) z zainstalowanym systemem operacyjnym Windows Server 2008 R2 Standard z dostępem do 2 TB macierzy dyskowej.

W ramach rozbudowy należy zapewnić możliwość wydzielenia z części produkcyjnej Portalu zasobów dotyczących zakończonych edycji badań oraz ich przeniesienia do podsystemu badań archiwalnych. W podsystemie tym nie przewiduje się instalowania aplikacji formularzowych, a jedynie składowanie i udostępnianie plików PDF z obrazem wydruków formularzy, plików xml z danymi formularza i danych dotyczących aktywności użytkowników.

Funkcjonalność zarządzania przenoszeniem zasobów do podsystemu badań archiwalnych powinna być dostępna w aplikacji AC.

Dostęp Sprawozdawców oraz Statystyków do zasobów podsystemu badań archiwalnych powinien być zapewniony z poziomu interfejsu aplikacji udostępnionych im w ramach produkcyjnej części Portalu.

W celu realizacji powyższych wymagań należy:


  • zapewnić mechanizm przenoszenia z portalu produkcyjnego do podsystemu archiwalnego, danych edycji badania (plik XML z danymi, log aktywności użytkownika, wykazy podmiotów objętych obowiązkami) wraz z wygenerowaniem wydruków formularzy w formacie PDF (przy użyciu definicji wydruku w formacie BIRT dostępnego dla każdego formularza)

  • umożliwić dostęp użytkownika do przeniesionych zasobów (plik XML z danymi, wydruk PDF, log aktywności użytkownika na sprawozdaniu) poprzez interfejs portalowy wraz z kontrolą dostępu

Należy przedstawić opis koncepcji takiego rozwiązania z uwzględnieniem:

  • Sposobu funkcjonowania i wydajności mechanizmu generowania wydruków

  • Sposobu składowania i udostępniania danych archiwalnych przy uwzględnieniu rocznego przyrostu liczby formularzy na poziomie 3 mln.

  • Zasad kontroli dostępu do danych archiwalnych

  • Interfejsu dostępu do danych archiwalnych

  • Architektury i zasobów podsystemu wraz z proponowanym oprogramowaniem

Wymaganym jest wsparcie (asysta techniczna) podczas odzyskiwania i przenoszenia do podsystemu archiwalnego, zasobów zakończonych edycji badań, które ze względów wydajnościowych zostały usunięte z produkcyjnej części Portalu (stan bazy danych sprzed operacji usuwania zasobów został zachowany). Operacja odzyskiwania zasobów i ich przenoszenia do podsystemu archiwalnego będzie wykonywana dla dwóch zachowanych stanów bazy danych.



  1. Zmiany funkcjonalne i ergonomiczne aplikacji użytkowych oraz środowiska projektowania formularzy w Portalu

    1. Należy zapewnić obsługę badań incydentalnych, tj. takich, gdzie nie funkcjonuje kartoteka badania, a obowiązek sprawozdawczy wynika z określonego zdarzenia (np. wypadku). Badania incydentalne obsługiwane w Portalu powinny posiadać atrybut wskazujący na ich obsługę w trybie badania incydentalnego. W interfejsie aplikacji Sprawozdawcy należy dodać przycisk wywołujący listę badań incydentalnych. Wskazanie badania oraz wywołanie funkcji dodania formularza powinno skutkować dodaniem obowiązku do aktualnej kartoteki tego badania (przewiduje się, iż w określonych odstępach czasowych np. co rok, tworzona będzie nowa kartoteka badania – nie zawierająca wpisów). Rozwiązanie to wymaga, aby badania te miały jednocześnie status wieloformularzowych, jednak w tym przypadku dodawanie kolejnych formularzy, „1”, „2” itd. powinno następować z poziomu okna z listą badań incydentalnych (automatycznie w momencie dodania formularza).

Badania incydentalne powinny być obsługiwane w ramach nowego ekranu aplikacji Sprawozdawcy, tak by obowiązki incydentalne były odseparowane od obowiązków w badaniach bieżących.

Analogiczny interfejs umożliwiający rejestrację sprawozdań w badaniach incydentalnych należy zapewnić w aplikacji UO. Monitorowanie oraz zarządzanie edycjami badań incydentalnych powinno się odbywać na dotychczasowych zasadach.



    1. Otwarcie do edycji formularza w stanie „zatwierdzone” powinno być możliwe po manualnej zmianie statusu na „wypełniane”. W tym celu należy wyświetlić stronę startową, która umożliwi wybranie trybu pracy z formularzem (edycja lub przeglądanie):

Formularz został zatwierdzony, jeśli chcesz modyfikować dane wciśnij przycisk „Odblokuj”, jeśli chcesz przeglądać dane wciśnij przycisk „Przeglądanie”

Po odblokowaniu powinien być wyświetlony dodatkowy komunikat:

Formularz został odblokowany do edycji, przypominamy o konieczności jego ponownego zatwierdzenia”


    1. Należy wprowadzić możliwość wysyłania uzupełniających powiadomień o obowiązku sprawozdawczym. Powiadomienia w trybie uzupełniającym byłyby wysyłane do JS, które nie otrzymały powiadomienia wysłanego w trybie automatycznym (np. JS dodane do kartoteki po wysłaniu powiadomienia automatycznego, w trakcie edycji badania). Funkcja ta powinna być dostępna w aplikacji KB, i powinna działać na zasadzie manualnego uruchomienia procesu, który najpierw wyświetla listę JS, które otrzymają powiadomienie uzupełniające i po akceptacji wysyła wiadomość o tej samej treści, jak w przypadku powiadomienia automatycznego.

    2. Należy zmienić zasadę definiowania terminów wysyłania monitów, w taki sposób, aby w poszczególnych badaniach możliwe było zdefiniowanych max. 5 terminów wysyłki monitów w sposób bezwzględny poprzez wskazanie dat wysyłki (nie na zasadzie ich wyznaczania poprzez algorytm).

Zdefiniowanie więcej niż jednego monitu będzie oznaczało wyznaczenie terminów pośrednich dostępności formularza w okresie monitowania (etapów monitowania) – tzn. data każdego kolejnego monitu będzie wyznaczała termin upływu poprzedniego etapu monitowania. Termin końcowy dostępności formularza nadal wyznaczać powinna data określona w kalendarzu badania w polu data_do_form_JS.

W oparciu o terminy monitów należy automatycznie wydłużać dostęp do formularza wg zasady, że JS, których sprawozdania są w stanie „nierozpoczęte” lub „wypełniane” mają możliwość ich edycji do upływu terminu danego etapu monitowania. JS, które w danym etapie monitowania zatwierdziły formularz nie będą miały możliwości jego edytowania w kolejnych etapach monitowania.



Terminy wysyłki monitów powinny być definiowane w kalendarzu edycji badania (strukturę kalendarza należy odpowiednio rozszerzyć). Modyfikacja dat monitów powinna być możliwa z poziomu interfejsu aplikacji KB.

    1. Data przypomnienia o obowiązku sprawozdawczym powinna być definiowana w sposób bezwzględny poprzez wskazanie daty wysyłki w kalendarzu edycji badania (strukturę kalendarza należy odpowiednio rozszerzyć). Modyfikacja daty przypomnienia powinna być możliwa z poziomu interfejsu aplikacji KB.

    2. Należy zapewnić możliwość wyłączenia z listy adresatów wiadomości automatycznych wskazanych podmiotów. Taka funkcja powinna być dostępna w aplikacji UO, w interfejsie Statystyka i AB/ABW w oknie „Lista Jednostek Sprawozdawczych przypisanych do edycji badania”. Operacja powinna być realizowana dla każdego badania niezależnie i w odniesieniu do aktualnej edycji.

Powinna być też możliwa operacja odwrotna, tj. przywrócenie powiadamiania automatycznego. Dodatkowo należy zapewnić możliwość eksportu oraz importu w pliku csv numerów REGON JS, które zostaną wyłączone z listy adresatów wiadomości automatycznych. Niezbędnym jest też dziedziczenie pomiędzy edycjami (możliwość przeniesienia listy JS wyłączonych w edycji X do edycji Y).

    1. W momencie zatwierdzania formularza, który zawiera błędy uznaniowe, należy wyświetlać zbiorczą listę błędów uznaniowych oraz wygenerować ostrzeżenie "Sprawozdanie zawiera błędy uznaniowe. Czy na pewno zatwierdzasz sprawozdanie ? TAK/NIE". (TAK - zatwierdzenie i wyjście z formularza, NIE - powrót do trybu edycji).

    2. W aplikacji UO, na ekranie „Przedłużanie terminu sprawozdań” należy zapewnić możliwość przedłużania dostępności sprawozdania niezależnie od statusu, w jakim się znajduje.

    3. Eksport danych z Portalu powinien odbywać się z poziomu dodatkowej „bazy eksportów”, do której dane byłyby automatycznie replikowane z głównej bazy produkcyjnej wg przyjętego schematu (z określeniem w sposób bezwzględny dat replikacji). W celu utrzymania spójności stanów formularzy w obu bazach, należy w momencie replikacji zmieniać stany formularzy w bazie głównej na „wyeksportowane”. Dodatkowo w aplikacji UO należy zapewnić możliwość wykonania eksportu z poziomu bazy eksportów, a nie z bazy głównej (funkcje związane z importem wyników kontroli w systemach KL nie ulegają zmianie).

    4. Należy umożliwić eksport danych z różnych badań do jednej pośredniej bazy kontroli logicznej, wraz z logowaniem informacji o przebiegu eksportów.

    5. Funkcja eksportu danych do pliku dbf powinna opcjonalnie umożliwiać eksport do jednego pliku dbf (zbiór ogólnopolski).

    6. Do wiadomości wyświetlanych w Portalu należy dodać dane adresata (nazwa podmiotu oraz 14-cyfrowy numer Regon).

    7. Należy rozdzielić wyjątki przy logowaniu, tak by oddzielnie sygnalizowany był błąd komunikacji z bazą danych oraz błąd uwierzytelniania (konfigurowalne komunikaty dla obu przypadków).

    8. W szczegółach wiadomości należy dodać informację o PKD danej JS.

    9. W aplikacji UO, w oknie „Lista wiadomości” należy dodać pole PKD.

    10. W aplikacji UO, w oknie „Nowa informacja dodatkowa związana z badaniem” należy umożliwić filtrowanie wg województwa siedziby JS (dotychczasowe kryterium OTP pozostaje bez zmian).

    11. W aplikacji Sprawozdawcy (rola OZS) należy udostępnić funkcję generowania raportu (w postaci strony html) zawierającego zestawienie wszystkich jednostek i obsługujących je użytkowników w ramach poszczególnych badań - w trzech przekrojach: wg użytkowników, jednostek i badań.

    12. Próba zamknięcia okna przeglądarki z formularzem niezatwierdzonym powinna skutkować wyświetleniem komunikatu z ostrzeżeniem (możliwym do zdefiniowania).

    13. Dla pól słownikowych należy zapewnić obsługę słowników o zmiennej liczbie kolumn, należy umożliwić pobranie wartości dowolnej kolumny dla danego kodu oraz umożliwić na tej samej zasadzie filtrowanie zawartości.

    14. W polach słownikowych należy umożliwić dynamiczne zawężanie (filtrowanie) zawartości słownika, w zależności od wartości innego pola na formularzu, w oparciu o technologię AJAX bez konieczności przeładowywania strony.

    15. W aplikacji Sprawozdawcy, na ekranie powitalnym należy usunąć tabelę z listą nieodebranych wiadomości i zamiast tego umieścić informację o liczbie nieodebranych wiadomości wraz z linkiem umożliwiającym przejście do modułu „Wiadomości”.

    16. Należy udostępnić komponent będący pochodną komponentów Multisekcja i Tabular AJAX, który umożliwi efektywne wprowadzanie wielu (powyżej 1000) wierszy z danymi. Wymagane jest stronicowanie wprowadzanych danych (wg definiowalnego parametru). Prezentowane powinny być pełne wiersze z danymi, a ładowanie danych z następnych stron powinno odbywać się mechanizmem AJAX.

    17. W API aplikacji formularzowej należy udostępnić możliwość odwołania się do wiersza multisekcji jako obiektu będącego kolekcją pól.

    18. Należy zapewnić możliwość zmiany widoczności lub edycji pola w wierszu multisekcji dla poszczególnych wierszy.

    19. Należy zapewnić możliwość ustawienia „zamrożonego” nagłówka tabeli multisekcji - jako element konfiguracyjny komponentu.

    20. Należy zapewnić możliwość sortowania multisekcji - wg wybranego pola (zestawu pól) - po zapisie sprawozdania.

    21. Należy utworzyć nowe źródło danych dla aplikacji formularzowych – „dane zewnętrzne” przechowywane w bazie danych. Dostęp do tego źródła powinien być możliwy zarówno z poziomu języka formuł, jak i bezpośrednio z walidatora niestandardowego.

    22. Należy rozbudować webservice’y w Portalu o funkcję dodawania/usuwania pseudoobowiązku i składanie na ten pseudoobowiązek formularza dodatkowego.

    23. W aplikacji UO, w oknie „Lista jednostek sprawozdawczych przypisanych do edycji badania”, należy wprowadzić możliwość filtrowania wg:

  1. Numeru Regon (od..do)

  2. Daty i godziny ostatniego zapisu sprawozdania (w tym od..do)

  3. Klasy wielkości jednostki

  4. Podregionu *

* w przypadku pkt. c i d wymagane jest rozszerzenie profilu danych JS


    1. W aplikacji UO, w oknie „Lista jednostek sprawozdawczych przypisanych do edycji badania”, należy wprowadzić możliwość opcjonalnego wyświetlenia kolumn prezentujących następujące dane:

  1. Błędy - (brak błędów, błędy uznaniowe, błędy bezwzględne)

  2. Data i godzina ostatniego zapisu sprawozdania

  3. Klasa wielkości jednostki

Jednocześnie z zakresu domyślnie wyświetlanych kolumn należy usunąć kolumnę „Forma elektroniczna”

    1. W aplikacji UO, w oknie "Wybór edycji badania" należy zastosować sortowanie edycji malejąco począwszy od bieżącej edycji badania.

    2. W aplikacji UO, w „Szczegółach Jednostki Sprawozdawczej” należy dodać numer telefonu oraz adres email (w formie hiperłącza) do OSS.

    3. W aplikacji UO, na ekranie „Log sprawozdania” (okno „Lista operacji”) należy dodać informację o roli użytkownika, który wykonał daną operację (Statystyk / Sprawozdawca).

    4. Należy udostępnić użytkownikom AB i ABW możliwość importu danych z pliku xml.

    5. W aplikacji UO, na ekranie „Monitorowanie edycji badania” w oknie ”Raport kompletności”, po wybraniu opcji „Jednostki obsługiwane przez statystyka” należy zastosować sortowanie alfabetyczne wg nazwiska.

    6. W aplikacji Sprawozdawcy, w oknie „Szczegóły badania” należy umieścić informację o statystyku, któremu powierzono obsługę danej JS.

    7. W aplikacji Sprawozdawcy, w oknie „Lista aktualnych obowiązków sprawozdawczych” w polu "DATA DO" powinien znajdować się na stałe pierwotny termin przekazania danych (data_do_JS), niezależnie od tego, czy termin ten jest później przedłużany. Po upływie tego terminu, jeśli obowiązek sprawozdawczy nie został zrealizowany (sprawozdanie ma status „nierozpoczęte” lub „wypełniane”), należy wyeksponować tę datę (zmiana koloru i czcionki) oraz dodać tooltip z informacją o wydłużeniu terminu w ramach okresu monitowania (treść tej informacji powinna być definiowalna i powinna umożliwiać wyświetlenie aktualnej daty dostępności formularza w ramach danego etapu monitowania).

    8. Należy udostępnić funkcjonalność potwierdzania (z możliwością modyfikacji) danych kontaktowych wszystkich użytkowników JS. Funkcjonalność byłaby zarządzana przez AC i uruchamiana zgodnie z harmonogramem przygotowanym przez AC.

Jeśli adres email jest modyfikowany, należy dezaktywować konto oraz wygenerować emaila z linkiem ponownie je aktywującym. Do czasu otwarcia emaila i kliknięcia w link zalogowanie nie powinno być możliwe.

    1. W aplikacji UO, na „Liście Jednostek Sprawozdawczych przypisanych do edycji badania” należy dodać ikony umożliwiające dostęp do wiadomości wysłanych do konkretnej JS oraz do wiadomości przysłanych przez nią.

    2. W aplikacji UO, dla roli AB i ABW należy udostępnić możliwość odblokowania sprawozdania (na takiej zasadzie, jak w przypadku roli „Statystyk”).

    3. W aplikacji UO, na ekranie "Arkusz przyporządkowania Jednostek Sprawozdawczych" należy wprowadzić możliwość filtrowania wg:

  1. Numeru Regon (od..do)

  2. Klasy wielkości jednostki

  3. Podregionu

    1. Należy zapewnić użytkownikom OZS i AL możliwość wydrukowania Loginu i Hasła w przypadku tworzenia użytkownika lub zmiany jego hasła.



  1. Upgrade środowiska PS

Należy dokonać następujących zmian w obrębie środowiska tworzenia formularzy oraz oprogramowania systemowego Portalu:

    1. Zmiana w pluginie formularzowym umożliwiająca tworzenie aplikacji formularzowych w środowisku Eclipse bez konieczności wykorzystywania funkcjonalności BEA Workshop.

    2. Upgrade bibliotek: Hibernate w wersji 3.2.0 oraz Spring w wersji 2.0 do nowszych wersji, gwarantujących stabilność działania systemu na obecnym poziomie.

    3. Optymalizacja wydajnościowa funkcji generowania wydruków, w tym migracja środowiska BIRT (Business Intelligence and Reporting Tools) w wersji 2.1.0 do wersji 2.6.x lub nowszej, niewymagającej zmian w istniejących definicjach wydruków.

    4. Optymalizacja javascript w celu zwiększenia jego wydajności i zapewnienia poprawnej pracy w przeglądarkach nowych generacji.

Użyte skróty:

JS – jednostka sprawozdawcza (podmiot, na który nałożono obowiązek sprawozdawczy)

OZS – osoba zarządzająca sprawozdawczością w jednostce sprawozdawczej

OSS – osoba sporządzająca sprawozdania w jednostce sprawozdawczej

UO – użytkownik operacyjny (pracownik urzędu statystycznego), który w Portalu może działać w roli Statystyka albo administratora Badania (AB), albo Wojewódzkiego Administratora Badania (ABW)

system KL – system, do którego eksportowane są dane z Portalu Sprawozdawczego w celu dalszego przetwarzania

KB – koordynator badania (pracownik GUS lub urzędu statystycznego odpowiedzialny za koordynację prac przy realizacji badania w środowisku Portalu Sprawozdawczego)

AL – administrator lokalny Portalu Sprawozdawczego (pracownik urzędu statystycznego zarządzający użytkownikami oraz zasobami Portalu na poziomie lokalnym)



AC – administrator centralny Portalu Sprawozdawczego


Projekt SISP  współfinansowany przez Unię Europejską z Europejskiego  Funduszu Rozwoju Regionalnego oraz ze środków budżetu państwa. 7. Oś Priorytetowa: Społeczeństwo informacyjne
– budowa elektronicznej administracji


str.




©operacji.org 2017
wyślij wiadomość

    Strona główna