Szacowanie wartości zamówienia polegającego na utworzeniu „Elektronicznych rejestrów mikroorganizmów i organizmów genetycznie zmodyfikowanych Ministra Klimatu i Środowiska”
Szacowanie
wartości zamówienia polegającego na utworzeniu
„Elektronicznych
rejestrów mikroorganizmów i organizmów genetycznie zmodyfikowanych
Ministra Klimatu i Środowiska”
Celem zbadania oferty rynkowej oraz oszacowania wartości zamówienia, Ministerstwo Klimatu i Środowiska zwraca się z prośbą o przedstawienie informacji dotyczących szacunkowych kosztów realizacji niżej opisanego zamówienia.
UWAGA!
Niniejsze szacowanie wartości zamówienia nie stanowi oferty w rozumieniu art. 66 Kodeksu Cywilnego, jak również nie jest ogłoszeniem ani zapytaniem o cenę w rozumieniu ustawy Prawo Zamówień Publicznych. Informacja ta ma na celu wyłącznie rozpoznanie rynku i uzyskanie wiedzy na temat kosztów opisanej usługi.
ZAMAWIAJĄCY
Ministerstwo
Klimatu i Środowiska
xx.
Xxxxxxxx 00/00
00-000
Xxxxxxxx
Szczegółowy opis przedmiotu zamówienia:
Wstęp
Elektroniczne rejestry mikroorganizmów i organizmów genetycznie zmodyfikowanych (zwane dalej Systemem) są niezbędne w celu realizacji zadań Ministra Klimatu i Środowiska określonych w ustawie z dnia 22 czerwca 2001 r. o mikroorganizmach i organizmach genetycznie zmodyfikowanych (Dz.U. z 2022 r. poz. 546).
Główne funkcje systemu umożliwiające wykonywanie ww. zadań to:
wprowadzanie i przechowywanie danych dotyczących czynności związanych z mikroorganizmami genetycznie zmodyfikowanymi zwanymi dalej GMM i organizmami genetycznie zmodyfikowanymi zwanymi dalej GMO;
wyszukiwanie danych;
prezentowanie ww. danych w postaci raportów i zestawień,
publikowanie danych na portalu xxx.xxxxxxxxx.xx oraz na portalu Otwarte Dane (xxxxx://xxxx.xxx.xx).
Elektroniczne rejestry mikroorganizmów i organizmów genetycznie zmodyfikowanych Ministra Klimatu i Środowiska muszą być przygotowane w 2 etapach:
przeprowadzenie analizy UX, badania architektury informacji, analizę tree testing istniejących rejestrów GMM i GMO, przygotowanie interaktywnej makiety systemu,
opracowanie systemu, uruchomienie go na serwerach Zamawiającego i przeniesienie danych archiwalnych.
Wynagrodzenie Wykonawcy za każdy etap rozliczone zostanie po zakończeniu każdego etapu.
System musi być zgodny z Ustawą z dnia 17 lutego 2005 r. o informatyzacji podmiotów realizujących zadania publiczne (t.j. Dz.U. z 2021 r., poz. 670 z późn. zm) oraz jej aktami wykonawczymi, w szczególności z rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (t.j. Dz. U. z 2017 r., poz. 2247), zwanym dalej „Rozporządzeniem KRI” oraz z Ustawą z dnia 4 kwietnia 2019r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych - WCAG 2.1 ( Dz.U. 2019 poz. 848).
Ponadto system musi być zgodny z rozporządzeniem Ministra Administracji i Cyfryzacji z dnia 26 marca 2014 r. w sprawie zasobu informacyjnego przeznaczonego do udostępniania w Centralnym Repozytorium Informacji Publicznej (Dz.U. z 2018 r., poz. 1790), w szczególności umożliwiać eksport danych zawartych w rejestrach do formatów baz danych określonych w ww. rozporządzeniu (sformatowany arkusz kalkulacyjny lub CSV).
System musi umożliwiać udostępnianie danych w Centralnym Repozytorium Informacji Publicznej zgodnie z ustawą o otwartych danych i ponownym wykorzystywaniu informacji sektora publicznego, w szczególności poprzez interfejs API wykonany w oparciu o rekomendacje w zakresie opracowanych standardów otwartości danych.
System musi być zgodny z Ustawą z dnia 16 lipca 2004 Prawo telekomunikacyjne (t.j. Dz.U. z 2021 r., poz. 576), w szczególności z art. 173 tej ustawy;
Etap 1. – Przygotowanie interaktywnej makiety systemu
Makieta systemu musi obejmować sześć stron rejestrów GMM/GMO – 3 dla użytkowników zewnętrznych (strona z listą rejestrów, strona jednego rejestru z listą wniosków, strona karty wniosków) oraz 3 strony administracyjne/redakcyjne (strona z listą rejestrów, strona jednego rejestru z listą wniosków, strona karty wniosków), służące do wprowadzania przez Administratorów i redaktorów danych do bazy danych i ich publikowania oraz makiety 7 rejestrów GMM i GMO (patrz pkt. 4 Etap II). Przygotowanie makiety musi poprzedzić przeprowadzenie badania potrzeb i oczekiwań Zamawiającego wobec projektowanego systemu oraz przygotowanie architektury informacji. Końcowym produktem tego etapu musi być makieta zawierająca wszystkie treści i elementy, układ i rozmieszczenie poszczególnych elementów docelowego Systemu (logo, menu, treści, zdjęcia, formularze, wyszukiwarki, panele logowania itp.) oraz inne elementy konieczne do funkcjonowania systemu, spójna kolorystycznie i zawierająca elementy nawigacyjne.
W trakcie trwania etapu Wykonawca naniesie poprawki funkcjonowania i wyglądu makiety Systemu, wskazane przez Zamawiającego.
Etap I składa się z 3 części:
Przeprowadzenie analizy UX oraz analiza architektury informacji istniejących rejestrów GMM/GMO
Poniższe wymagania mają zastosowanie do audytu User Experience (użyteczności, jak i satysfakcji odbiorcy, dalej jako audyt UX) chyba, że w odniesieniu do konkretnego wymagania wskazano inaczej.
Audyt UX jest ekspercką metodą badania użyteczności stron internetowych lub aplikacji, podczas której grupa specjalistów dokonuje szczegółowego przeglądu zawartości strony i na jej podstawie identyfikuje jej problemy. Badanie opiera się na wybranych wcześniej wyznacznikach dobrego funkcjonowania strony (heurystykach), a każdy wykryty problem jest oceniany według skali jego istotności. Kluczowym elementem podczas tworzenia audytu UX jest wybranie odpowiednich heurystyk – z tego powodu audyt UX często nazywa się analizą heurystyczną (ang. heuristic evaluation).
Najbardziej uniwersalne i zarazem najbardziej popularne są tzw. heurystyki J. Nielsena. Stanowią one 10 wyznaczników, które wskazują na to, jakie warunki powinna spełniać strona, aby była prosta i zrozumiała dla użytkownika oraz zapewniała mu poczucie pewności i bezpieczeństwa. Komplementarnie, do heurystyk X. Xxxxxxxx, Wykonawca użyje 8 Złotych Xxxxx Xxxxxxxxxxxxx – biorąc pod uwagę zachowanie spójności, korzystanie ze skrótów, oferowanie informacji zwrotnej do odbiorcy, właściwe zaprojektowanie okien dialogowych, oferowanie prostej obsługi błędów, pozwolenie na odwrócenie działań, wzmacnianie wewnętrznego poczucia kontroli odbiorcy oraz zmniejszenie obciążenia pamięci krótkotrwałej.
Cele szczegółowe audytu:
analiza danych ilościowych,
ocena użyteczności obecnych rozwiązań, a w szczególności ocena, na ile architektura informacji, zastosowane rozwiązania w nawigacji i spójność kompozycyjna (paleta barw, proporcje kształtów, ikonografia) są zrozumiałe i atrakcyjne dla Zamawiającego,
logikę interfejsu bazującą na ludzkiej intuicji i powszechnych skojarzeniach,
grupowanie danych w sposób konsekwentny i ułatwiający ich wyszukiwanie,
udostępnianie tylko informacji potrzebnych w danej chwili użytkownikowi,
sprawdzenie zgodności stron z wymaganiami w zakresie dostępności cyfrowej.
Efektem analizy będą rekomendacje zoptymalizowania działania rejestrów GMM/GMO. Dodatkowo Wykonawca przedstawi zalecenia odnośnie do kluczowych funkcjonalności rejestrów GMM/GMO w postaci przykładowych benchmarków podobnych projektów pod kątem wizualnym i funkcjonalnym.
Przeprowadzenie analizy Tree Testing (testowanie drzewa) polegającej na kategoryzowaniu elementów menu na docelowej stronie internetowej, w celu wypracowania optymalnej architektury informacji.
Badanie eksploracyjne. Badaniem zostanie objęte 3 osób, stanowiących grupę użytkowników analizowanych serwisów. W trakcie badania uczestnicy dostarczą szczegółowe informacje dotyczące zakresu działania dotychczasowych rejestrów GMM/GMO. Efektem prac na tym etapie muszą być:
grupy użytkowników,
zakres uprawnień i panel administracyjny/redakcyjny,
docelowa architektura serwisów,
rekomendacje projektowe (wizualne i funkcjonalne).
Ten etap obejmuje cztery działania:
I. Opracowanie koncepcji funkcjonalnej i graficznej w formie „design sprint” - analiza aktualnych i archiwalnych rejestrów GMM/GMO oraz oczekiwań użytkowników, trendów oraz założeń funkcjonalnych dotyczących rejestrów GMM/GMO.
II. Opracowanie biblioteki elementów UI, która zostanie rozbudowana w trakcie kolejnych etapów projektu.
III. Projektowanie UX/UI (GUI): opracowanie w pełni funkcjonalnej makiety dla rejestrów GMM/GMO, w tym przygotowanie wersji graficznej rejestrów GMM/GMO, z uwzględnieniem obowiązującego Systemu Identyfikacji Wizualnej Ministerstwa Klimatu i Środowiska, architektury informacji rejestrów GMM/GMO, reguł interakcji/reguł projektowych i projektowania treści (ang. UX writing/microcopy). Szacunkowa ilość unikalnych ekranów do zaprojektowania wynosi 6 (ekran dla użytkownika zewnętrznego: ogólny z listą rejestrów, widok szczegółowy jednego rejestru, jedna karta rejestru, widok dla Administratora/redaktora: ogólny z listą rejestrów, widok szczegółowy jednego rejestru, jedna karta rejestru). Forma dostarczenia efektów pracy: pełna dokumentacja (przy czym pełna dokumentacja będzie zawierała x.xx. projekt graficzny wszystkich unikalnych podstron wraz z opisem interakcji i mikrointerakcji umożliwiający odpowiednie wdrożenie, przygotowany w ogólnie dostępnym narzędziu online do tworzenia makiet, interfejsów z możliwością̨ eksportu prac do plików graficznych, pdf oraz do kodu HTML i CSS np. Figma, Adobe XD, InVisionApp, Sketch, Zeplin, UxPin.
IV. Przeprowadzenia testów z użytkownikami typu RITE dla rejestrów GMM/GMO (testy RITE zostaną przeprowadzone na grupie 3 użytkowników).
Test RITE to metoda badawcza umożliwiająca wykrycie oraz poprawienie jak największej ilości błędów, w jak najkrótszym czasie. Taka dynamiczna formuła pozwala udoskonalać makietę na bieżąco i usuwać błędy w trakcie badania. Realizacja RITE wymagać będzie zapewnienia następujących zasobów po stronie Wykonawcy i Zamawiającego:
• 1 x projektant UX/UI – odpowiada za przygotowanie makiety oraz nanoszenie poprawek po sesjach badawczych,
• 1 x projektant UX/UI – notuje i obserwuje badania, a następnie facylituje mini-warsztaty przed kolejną sesją. To właśnie wtedy musi zapaść decyzja, jakie zmiany UX Designer ma wprowadzić przed kolejną iteracją,
• Badacz UX – przygotowuje scenariusze badawcze, zajmuje się (lub koordynuje) proces rekrutacji i ostatecznie przeprowadza badania,
• Przedstawiciel Zamawiającego.
Reprezentatywna grupa docelowa do testów to 3 osoby.
Obowiązki Wykonawcy związane z realizacją zamówienia obejmują następujące czynności:
● Uwzględnianie i konsultacja z Zamawiającym poszczególnych etapów oraz zakresu i harmonogramów audytów, badań, testów,
●
● Przygotowanie narzędzi badawczych, w tym scenariuszy testów z użytkownikami do testów RITE,
● Organizacja testów RITE,
● Przygotowanie pełnej dokumentacji projektowej oraz podsumowania testów RITE.
Wymagania dotyczące współpracy Xxxxxxxxxxxxx z Wykonawcą
W ramach współpracy z Zamawiającym Wykonawca i Zamawiający wyznaczają w swoich strukturach osoby prowadzące zamówienie oraz osoby zastępujące prowadzących zamówienie, w przypadku ich nieobecności. Wykonawca zobowiązany jest do sprawnej i terminowej realizacji zamówienia oraz stałej współpracy z Zamawiającym, w tym:
● pozostawania w stałym kontakcie (kontakt telefoniczny oraz drogą elektroniczną, spotkania z Zamawiającym w miarę potrzeb stacjonarne albo zdalne),
● bieżące konsultacje projektowe z Wykonawcą prac programistycznych i z Zamawiającym (regularne statusy i komunikacja na wybranym komunikatorze np. Webex lub MS Teams),
● informowania o stanie prac, pojawiających się problemach i innych zagadnieniach istotnych dla realizacji badań.
Sposób dostarczenia wyników/rezultatów
W terminie 1 miesiąca od podpisania umowy Wykonawca przedstawi Zamawiającemu:
• Wersję graficzną (hi-fi) - dostarczoną w wersji gotowej do wdrożenia/developmentu (ang. design handoff),
• W pełni funkcjonalną makietę,
• Bibliotekę stylów/elementów wizualnych (ang. style guide) oraz pełnego systemu projektowego (ang. design system),
• Raport po testach RITE,
• Rekomendacje dotyczące technologii programistycznej oraz ewentualne wytyczne dotyczące wykorzystywanych grafik (formaty i wielkości plików, rozdzielczości itp.),
• Szczegółową specyfikację prac programistycznych (makiety z opisem interakcji, responsywnością itd.).
Sposób prezentacji wyników:
Jako efekt badań Wykonawca przedstawi Zamawiającemu:
raport końcowy z wszystkich etapów realizacji przedsięwzięcia dotyczących pierwszego etapu zamówienia, zawierający zalecenia i rekomendacje,
listę wykonanych zadań,
wysokopoziomowe rekomendacje projektowe (w oparciu o badania oraz dobre praktyki rynkowe).
Etap 2 - Opracowanie systemu, uruchomienie go na serwerach Zamawiającego i przeniesienie danych archiwalnych
Wykonawca na podstawie produktów Etapu I przygotuje system elektronicznych rejestrów mikroorganizmów i organizmów genetycznie zmodyfikowanych Ministerstwa Klimatu i Środowiska.
Użytkownicy i tryby dostępu
Administrator – przedstawiciel Zamawiającego, musi posiadać możliwość:
wypełniania formularzy karty, modyfikacji i usuwania danych (przez dane należy rozumieć zarówno wprowadzone metadane, jak i załączniki);
publikacji karty,
podglądu wszystkich zamieszczonych danych i ich wyszukiwania;
tworzenia, modyfikacji i usuwania wnioskodawców i przedstawicieli wnioskodawców;
agregacji danych i eksportowania ich do innych plików np. arkusza kalkulacyjnego, pdf, csv, xml;
tworzenia zestawień oraz eksportowania ich do innych plików np. arkusza kalkulacyjnego, pdf, csv, xml.
tworzenia, modyfikowania i usuwania kont Administratorów;
tworzenia, modyfikowania nazw i usuwania rejestrów na liście rejestrów;
tworzenia, modyfikowania i usuwania listy kart danego rejestru;
tworzenia, modyfikowania i usuwania wzorów kart w ramach każdego z rejestrów.
Administrator musi posiadać dostęp do logów z ostatnich 2 lat. Starsze logi powinny być automatycznie usuwane. W logach powinny znajdować się dane pozwalające na zapewnienie rozliczalności systemu informatycznego, zgodnie z rozporządzeniem KRI.
Redaktor – przedstawiciel Zamawiającego, musi posiadać możliwość:
wypełniania formularzy karty, modyfikacji i usuwania danych (przez dane należy rozumieć zarówno wprowadzone metadane, jak i załączniki);
publikacji karty,
podglądu wszystkich zamieszczonych danych i ich wyszukiwania;
tworzenia, modyfikacji i usuwania wnioskodawców i przedstawicieli wnioskodawców;
agregacji danych i eksportowania ich do innych plików np. arkusza kalkulacyjnego, pdf, csv, xml;
tworzenia zestawień oraz eksportowania ich do innych plików np. arkusza kalkulacyjnego, pdf, csv, xml.
Administratorami i redaktorami będą wyznaczeni pracownicy Departamentu Ochrony Przyrody Ministerstwa Klimatu i Środowiska.
Użytkownik nieautoryzowany – użytkownik, który może przeszukiwać wszystkie opublikowane w rejestrach GMM/GMO dane. Posiada możliwość przeglądania metadanych i załączników w kartach, w tym pobrania załączników (pod warunkiem, że dane te przeznaczone są do publicznego udostępnienia). Posiada również możliwość tworzenia zestawień z opublikowanych danych. System powinien umożliwiać eksport zestawienia do formatu pdf, csv oraz xml.
Udostępnienie i wyświetlanie danych
Wyświetlanie danych, dostępnych dla danego użytkownika, musi być przeprowadzane w trzech etapach:
lista rejestrów (wyświetla wszystkie rejestry, umożliwia wejście do danego rejestru;
lista kart w danym rejestrze (umożliwia wyszukanie (domyślnie kart z rejestru, w którym znajduje się użytkownik), przejrzenie listy kart (w liczbie 20 wpisów na stronie, z możliwością zmiany na 50) i wejście do danej karty. Lista kart wizualizowana jest w formie tabelarycznej, z możliwością posortowania po wszystkich kolumnach (domyślne sortowanie następuje po numerze karty począwszy od kart ostatnio wprowadzonych). Zamawiający zdecyduje jakie dane powinny być widoczne na tym etapie (np. nazwa rejestru). Nawigacja powinna umożliwiać przejście do następnej, poprzedniej, pierwszej, ostatniej oraz wybranej strony listy kart oraz powrót do listy rejestrów;
podgląd wybranej karty (wyświetlane są szczegółowe informacje – metadane i załączniki dotyczące danej sprawy). Zamawiający zdecyduje jakie dane powinny być widoczne na tym etapie. Z ekranu podglądu karty użytkownik powinien mieć możliwość powrotu do listy kart (lub do listy wyszukanych kart, jeśli podgląd karty nastąpił wyszukaniu kart/karty).
Elektroniczne Rejestry GMM i GMO
System składać się musi z dwóch części:
panelu administracyjnego/redakcyjnego, służącego do wprowadzania przez Administratorów i redaktorów danych do bazy danych i ich publikowania,
7 rejestrów GMM i GMO:
zamkniętego użycia organizmów genetycznie zmodyfikowanych (zwanych dalej rejestr GMO),
zamkniętego użycia genetycznie zmodyfikowanych mikroorganizmów (zwanych dalej rejestr GMM),
zamierzonego uwolnienia GMO do środowiska,
zakładów inżynierii genetycznej (zwanych dalej rejestr zig),
awarii,
wprowadzenia do obrotu produktów GMO,
upraw GMO,
prezentujących w Internecie opublikowane dane nieautoryzowanym użytkownikom.
Każdy z poniżej opisywanych rejestrów musi stanowić odrębny zbiór danych, niemniej musi być zachowana łączność między nimi na potrzeby robienia raportów i zestawień, np. między rejestrami zakładów inżynierii genetycznej i rejestrów zgód na zamknięte użycie GMM i GMO, tak aby możliwe było stworzenie zestawienia, jakie badania zamkniętego użycia prowadzone są w danym zakładzie inżynierii genetycznej (połączenie rejestru zig i rejestrem GMM z rejestrem GMO).
Tworzenie i edycja listy rejestrów, listy kart danego rejestru oraz wzorów kart rejestrów
Zamawiający musi posiadać możliwość:
- dodawania nowych pozycji na liście rejestrów oraz edycji i usuwania istniejących pozycji rejestrów,
- tworzenia listy kart osobno dla każdego rejestru wraz z możliwością wyboru jakie dane mają być na liście widoczne,
- tworzenia wzorów kart osobno dla każdego z rejestrów.
Wzory kart będą generowane na podstawie formularzy xml, składających się ze standardowych pól używanych przy tworzeniu formularzy, np. pól tekstowych, obszarów tekstowych, list wyboru, pól daty oraz słowników. Wzory kart dla poszczególnych rejestrów opisane są w pkt 5. Wykonawca w porozumieniu z Zamawiającym przygotuje wzory kart dla rejestrów GMO i GMM wymagane prawem.
Przy tworzeniu/edycji wzoru kart dla danego rejestru będzie można zdefiniować dowolną, domyślną listę załączników. Lista załączników będzie wyświetlana na karcie poniżej metadanych. Szczegóły dotyczące tworzenia w formularzach list załączników znajdują się w pkt 4.2.
Przy tworzeniu/edycji wzoru kart dla danego rejestru, będzie istniała możliwość zaznaczenia wybranych pól, które będą umieszczone na liście kart (i będą stanowić wzór listy kart rejestru) oraz wybranie pól, które w kartach będą dostępne publicznie (pole zaznaczone do prezentowania na liście rekordów, ale nie zaznaczone jako publiczne, będzie widoczne na liście rekordów tylko dla użytkowników autoryzowanych).
Administrator/redaktor będzie mógł dodać nowy wzór kart dla danego rejestru oraz edytować albo usunąć istniejący wzór. Służyć do tego będą przyciski „Edytuj wzór karty” i „Usuń wzór karty” dostępne osobno dla każdego ze wzorów karty. Edycja wzoru karty pozwoli na dowolne edytowanie istniejących pól, ich usuwanie, dodawanie nowych oraz dowolną zamianę wskazanych pól miejscami.
Zapisanie wzoru karty będzie możliwe na każdym etapie jego tworzenia. Zapisany wzór karty w dowolnym momencie będzie możliwy później do edycji.
Opublikowanie wzoru karty będzie jednoznaczne z utworzeniem nowego lub modyfikacją istniejącego rejestru.
Usunięcie albo modyfikacja wzoru karty nie będzie powodować zmian w opublikowanych dotychczas kartach.
Do bazy danych przez aplikację administracyjną/redakcyjną, przy użyciu odpowiedniego wzoru, wprowadzane będą karty zawierające metadane opisujące wnioski wraz z załącznikami (np. wnioski, uchwały Komisji ds. GMO i GMM, zeskanowane decyzje). Karty mogą być publikowane przez Administratorów/redaktorów w rejestrach w dowolnym momencie, po kliknięciu na przycisk „Publikuj” (zapisanie karty wniosku będzie możliwe również w dowolnym momencie jej tworzenia i nie może powodować jej publikacji – powstaje robocza wersja karty wniosku). Przy publikacji, Administrator/redaktor powinien potwierdzić, że chce opublikować daną kartę.
Publikowane karty będą wersjonowane. Lista kolejnych opublikowanych wersji karty wraz z odpowiadającymi jej załącznikami będzie dostępna dla wszystkich użytkowników systemu. Administrator/redaktor będzie miał możliwość edycji i ponownej publikacji wcześniej opublikowanych wersji karty przy użyciu przycisku „Publikuj” (przycisk „Publikuj” będzie dostępny z poziomu edycji karty).
Dodawanie załączników i odnośników
Podczas tworzenia/edycji wzoru kart dla danego rejestru będzie istniała możliwość wybrania domyślnego zestawu załączników (lub odnośników), które będą dodawane do kart tworzonych w tym rejestrze. Podczas tworzenia zestawu załączników będzie istniała możliwość określenia liczby załączników oraz rodzaju każdego z nich. Oprócz tego podczas tworzenia karty musi także istnieć możliwość dodania dowolnej liczby dodatkowych załączników (np. kilku załączników określonych jako „Inne”). Podczas dodawania takiego załącznika z listy rozwijalnej należy określić rodzaj załącznika.
Dodanie załącznika będzie polegać na dodaniu pliku PDF (także podpisanego elektronicznie).
Określenie rodzaju załącznika będzie możliwe poprzez wybranie pozycji z listy jednokrotnego wyboru:
wniosek,
zgłoszenie,
ocena zagrożenia,
wewnętrzny regulamin bezpieczeństwa,
szczegółowe informacje o sposobach przeciwdziałania skutkom awarii,
oświadczenie o wpisaniu zakładu do wykazu jednostek hodowlanych,
plan postępowania na wypadek awarii,
techniczna dokumentacja,
program działania na wypadek zagrożenia zdrowia ludzi lub środowiska,
streszczenie wniosku i załączników (SNIF),
uchwała Komisji ds. GMO i GMM,
decyzja,
zgłoszenie awarii,
mapka lub szkic z oznaczeniem działki rolnej,
inne (z możliwością dodania tytułu załącznika);
określenie nazwy pliku lub odnośnika (pole tekstowe do 500 znaków) oraz określenie dostępności: publiczny / dla autoryzowanych użytkowników.
W karcie widoczna będzie nazwa załącznika (rodzaj załącznika) albo tytuł załącznika (w przypadku załącznika zdefiniowanego jako „inne”. Obok każdego załącznika powinna być wyświetlana informacja o jego formacie i wielkości.
Maksymalna wielkość plików zamieszczanych w rejestrach GMO to 20 MB, w przypadku próby zamieszczenia większych plików Administratorowi/redaktorowi wyświetli się stosowny komunikat.
W przypadku, gdy wielkość załącznika wyniesie 0 kB to wyświetli się stosowny komunikat.
W przypadku braku załącznika (pliku lub odnośnika) będzie automatycznie wyświetlana informacja „Brak załącznika”.
Będzie istniała możliwość zmiany załącznika (publikacja karty po zmianie załącznika lub odnośnika oznacza powstanie nowej wersji karty).
Baza wnioskodawców i przedstawicieli wnioskodawców musi być wspólna dla wszystkich rejestrów. Możliwość zapisania danych w bazie wnioskodawców i przedstawicieli wnioskodawców będzie możliwa z poziomu karty w każdym rejestrze. Wejście do bazy wnioskodawców i przedstawicieli wnioskodawców musi być także możliwe poprzez menu dostępne dla Administratora/redaktora.
Nazwa i adres wnioskodawcy oraz dane przedstawiciela wnioskodawcy są publicznie dostępne.
Nazwa i adres wnioskodawcy mogą być przypisane do wielu kart w różnych rejestrach GMO. Administrator/redaktor systemu ma możliwość wprowadzenia danych wnioskodawców: nazwy i danych teleadresowych tj.:
województwo (lista rozwijalna, jednokrotnego wyboru, pole obowiązkowe do uzupełnienia),
kod pocztowy (xxxx xxxxxxxxxxx xx xxxxxxxxxxxx),
xxxxxxxxxxx (xxxx obowiązkowe do uzupełnienia),
xxxxx (xxxx xxxxxxxxxxx xx xxxxxxxxxxxx),
xx xxxxxxx (xxxx obowiązkowe do uzupełnienia),
nr lokalu,
e-mail,
numer telefonu,
faks.
Po dodaniu do bazy telefonu i adresu e-mail, po kliknięciu powinna istnieć możliwość automatycznego wybrania numeru telefonu lub napisania wiadomości e-mail.
Przedstawiciel wnioskodawcy może być przypisany do wielu wnioskodawców w różnych rejestrach, a jeden wnioskodawca może mieć różnych przedstawicieli.
Administrator/redaktor systemu ma możliwość wprowadzenia danych dot. przedstawicieli wnioskodawców, takich jak:
tytuł naukowy,
imię (pole obowiązkowe do uzupełnienia),
nazwisko (pole obowiązkowe do uzupełnienia),
numer telefonu,
e-mail.
Powinna istnieć funkcja umożliwiająca dodawanie, edycję i dezaktywację (ukrywanie) danych dotyczących wnioskodawcy oraz przedstawiciela wnioskodawcy. Edycja (wersjonowanie) danych wnioskodawcy lub przedstawiciela wnioskodawcy nie może zmieniać danych w historycznych (opublikowanych) kartach.
Dostęp do podglądu, wyszukiwania i edycji wpisów w bazie wnioskodawców i przedstawicieli wnioskodawców powinni posiadać Administratorzy/redaktorzy zarówno z poziomu bazy wnioskodawców i przedstawicieli, jak i z poziomu tworzenia karty wniosku. Podczas tworzenia jak i edycji karty Administrator/redaktor ma możliwość wyszukania wnioskodawcy (co najmniej przy pomocy nazwy lub części nazwy wnioskodawcy, adresu wnioskodawcy, nazwiska lub fragmentu nazwiska wnioskodawcy). Nie są wyszukiwane dane, które zostały dezaktywowane. W przypadku nieaktualnych danych istnieje możliwość ich edycji w bazie wnioskodawców i przedstawicieli, a w przypadku ich braku dodanie wpisu – uzupełnienie informacji o nowym wnioskodawcy lub przedstawicielu wnioskodawcy.
Administratorzy/redaktorzy powinni posiadać możliwość wyszukania:
- których wnioskodawców reprezentuje wskazany przedstawiciel wnioskodawcy;
- wszystkich przedstawicieli wnioskodawcy, którzy reprezentują wybranego wnioskodawcę.
W przypadku, gdy istnieje już wpis dotyczący wnioskodawcy lub przedstawiciela wnioskodawcy system powinien przed zapisaniem danych wyświetlić ostrzeżenie i uniemożliwiać dodanie identycznego jak istniejący wpis (walidacja).
Opcje zapisu
Opcja dostępna tylko dla Administratorów/redaktorów – system umożliwia zapis stanu wpisywanych danych w dowolnym momencie a nie tylko po uzupełnieniu całej karty. Przy wyłączaniu aplikacji przez Administratora/redaktora z niezapisanymi danymi musi pojawić się ostrzeżenie o możliwości utraty danych. Po zapisaniu karty nie powstaje jej kolejna wersja (kolejna wersja powstaje po opublikowaniu karty).
Powiązania z istniejącymi rejestrami
Nowopowstałe rejestry muszą uwzględniać dane zawarte w obecnie funkcjonujących rejestrach GMM/GMO. Należy dokonać importu danych wnioskodawców, przedstawicieli wnioskodawców oraz metadanych opisujących karty i dodane załączniki z obecnych rejestrów GMM/GMO.
Sposób wykonania importu danych zostanie uzgodniony z Zamawiającym. Import obejmować musi dane z okresu od 1 stycznia 2015 r. do dnia podpisania umowy z Wykonawcą (rejestr zamkniętego użycia GMM, rejestr zamkniętego użycia GMO) oraz wszystkie dane z rejestru zamierzonego uwolnienia GMO do środowiska, rejestru zakładów inżynierii genetycznej i rejestru wprowadzenia do obrotu. Musi być możliwa edycja wszystkich zaimportowanych danych, tworzenie nowych wersji zaimportowanych kart. Zaimportowane dane o charakterze publicznym muszą być widoczne w nowych rejestrach.
Zamawiający nie posiada żadnej dokumentacji aktualnie funkcjonującego systemu. Obecnie funkcjonujące rejestry opublikowane są pod adresem: xxxx://xxx.xxx.xxx.xx.
Obecnie
dane przechowywane są w bazie danych MS SQL 2008, o wielkości
szacunkowej 50 MB, do której Zamawiający zapewni dostęp na czas
migracji danych. Liczba opublikowanych kart ok. 2500.
Opcje wyszukiwania
Nieautoryzowani Użytkownicy systemu oraz Administratorzy/redaktorzy będą mieli możliwość wyszukania i wyświetlenia danych zgromadzonych w systemie (także danych zaimportowanych z istniejących rejestrów). Będzie istniała możliwość wyszukiwania danych w obrębie wybranych rejestrów (po wybraniu z listy). W systemie będzie możliwość wyszukania danych, na następujących zasadach:
dane wpisywane ręcznie – przez wpisanie całego poszukiwanego rekordu lub fragmentu rekordu (wyszukiwanie pełnotekstowe),
dane w formacie daty można wyszukać, poza zwykłym wyszukaniem kart o danej dacie, na zasadzie przedziałów: od – do.
W rejestrach GMM/GMO będzie dostępna wyszukiwarka, która umożliwi przeszukanie wszystkich, dowolnie wybranych albo jednego wybranego rejestru według wybranego lub wielu kryteriów:
wyszukiwanie pełnotekstowe, całości albo części tekstu,
numeru karty (wyszukiwanie po numerze: cały numer karty albo po numerze rejestru oraz roku),
kategoria zagrożenia – lista jednokrotnego wyboru (wartości: I, II, III, IV),
daty złożenia wniosku (kalendarz, z możliwością zaznaczenia dat „od – do”),
daty wydania decyzji (kalendarz, z możliwością zaznaczenia dat „od – do”),
części albo całości nazwy wnioskodawcy,
części albo całości nazwiska przedstawiciela wnioskodawcy,
nazwy miejscowości wnioskodawcy,
nazwy województwa wnioskodawcy (lista rozwijalna).
Dla Administratorów/redaktorów istnieje możliwość wyszukania w rejestrze zamkniętego użycia GMO i rejestrze zamkniętego GMM, które karty zostały założone przez określony zakład inżynierii genetycznej (z rejestru zakładów inżynierii genetycznej) w określonym czasie.
Wyszukiwarka będzie umożliwiła wyszukanie wszystkich kart jednego wnioskodawcy z każdego rejestru.
Opcje drukowania
System umożliwi wydruk listy rejestrów, listy kart w danym rejestrze, wybranej karty i związanych z nim załączników, wygenerowanych zestawień – w danym okresie roku czy kategorii zagrożenia.
Będzie istnieć możliwość wydrukowania wypełnionej w systemie karty po kliknięciu przycisku „Generuj PDF”. Opcja drukowania będzie dostępna dla wszystkich typów użytkowników.
Raporty i zestawienia danych
W systemie powinna istnieć możliwość zestawienia danych na następujących zasadach:
dane umieszczane są w tabeli, w wierszach albo kolumnach (do wyboru opcje: horyzontalnie/wertykalnie),
możliwość wyboru kolejności kolumn.
Powinna istnieć możliwość eksportu danych do plików w formacie: xlsx, ods, PDF, docx, odt, xml.
Powinna istnieć możliwość udostępniania danych przez API w sposób przyjazny i możliwie łatwy do wykorzystania przez użytkowników, zgodnie z rekomendacjami Laboratorium Otwartych Danych, opisanymi w raporcie dotyczącym sposobów udostępniania danych przez API na portalu xxxx.xxx.xx.
Rejestry
Numeracja kart
Numer karty w rejestrach GMO np. 04-15/2021 składa się z 3 wartości, gdzie: 04 odpowiada numerowi danego rejestru, 15 to numer kolejny karty w danym rejestrze, 2021 – rok.
W celu utworzenia nowej karty należy wybrać z listy rejestrów odpowiedni rejestr:
01.1 – zamknięte użycie GMO
01.2 – zamknięte użycie GMM
02 – zamierzone uwolnienie
03 – wprowadzenie do obrotu
04 – zakład inżynierii genetycznej
05 – rejestr upraw
06 – rejestr awarii
Wybór rejestru, w którym wprowadzana jest karta zdefiniuje pierwszą wartość w numerze karty. Druga i trzecia wartość wprowadzana jest ręcznie w polu tekstowym.
Numeracja kart dla każdego rejestru będzie prowadzona odrębnie.
Rejestr zezwoleń na prowadzenie zakładu inżynierii genetycznej
Interfejs do wprowadzania danych powinien umożliwiać wprowadzanie danych w kolejności podanej poniżej (o ile nie podano inaczej: wartość nie może być pusta; o ile nie podano inaczej: wartość może się powtarzać). Gdy wartość nie może być pusta pojawia się komunikat o odpowiedniej treści, nie można go zignorować. Odpowiedni komunikat „wartość powtarza się” można zignorować.
numer karty – dane wg opisu z podpunktu „Numeracja kart”; wartość w obrębie rejestru nie może się powtarzać (w przypadku wpisania istniejącej wartości numeru karty, użytkownik otrzyma stosowny komunikat);
nazwa i adres wnioskodawcy – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
przedstawiciel wnioskodawcy - dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
kategoria zagrożenia – pole jednokrotnego wyboru (wartości: I, II, III, IV);
nazwa i adres zakładu inżynierii genetycznej – pole tekstowe, maksymalna wielkość 500 znaków, dane tekstowe;
data zgłoszenia – format daty: dd.mm.rrrr;
data upublicznienia – format daty: dd.mm.rrrr;
status wniosku – do wyboru z menu rozwijalnego: weryfikacja wniosku/ rozpatrzony/pozostawiony bez rozpoznania/;
numer decyzji – pole tekstowe;
data wydania decyzji – format daty: dd.mm.rrrr; wartość może być pusta;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO”; w przypadku tworzenia lub edycji karty w rejestrze zezwoleń na prowadzenie zakładu inżynierii genetycznej możliwe jest dodanie domyślnych załączników:
wniosek,
oświadczenie o wpisaniu zakładu do wykazu jednostek hodowlanych,
uchwała Komisji ds. GMO i GMM,
decyzja,
inne dokumenty.
Dane z rejestru zezwoleń na prowadzenie zakładu inżynierii genetycznej, przypisane do konkretnego wnioskodawcy, muszą być wyszukiwane z rejestrze zamkniętego użycia GMM i zamkniętego użycia GMO.
Rejestr zgód na zamknięte użycie GMO
Interfejs do wprowadzania danych powinien umożliwiać wprowadzanie danych w kolejności podanej poniżej (o ile nie podano inaczej: wartość nie może być pusta; o ile nie podano inaczej: wartość może się powtarzać). Gdy wartość nie może być pusta pojawia się komunikat o odpowiedniej treści, nie można go zignorować. Odpowiedni komunikat „wartość powtarza się” można zignorować.
numer karty – dane wg opisu z podpunktu „Numeracja kart”; wartość w obrębie rejestru nie może się powtarzać (w przypadku wpisania istniejącej wartości numeru karty, użytkownik otrzyma stosowny komunikat);
nazwa i adres wnioskodawcy – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
przedstawiciel wnioskodawcy – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
tytuł wniosku – pole tekstowe, maksymalna wielkość 512 znaków, dane tekstowe);
nazwa GMO – pole tekstowe, maksymalna wielkość 512 znaków, dane tekstowe);
kategoria zagrożenia – pole jednokrotnego wyboru (wartości: I, II);
data zgłoszenia – format daty: dd.mm.rrrr;
data upublicznienia – format daty: dd.mm.rrrr;
status wniosku – do wyboru z menu rozwijalnego: weryfikacja wniosku/ rozpatrzony/pozostawiony bez rozpoznania/wycofany;
data wydania decyzji – format daty: dd.mm.rrrr ; wartość może być pusta;
decyzja obowiązuje do – format daty: dd.mm.rrrr; wartość może być pusta;
miejsce wykonania decyzji – lista rozwijalna – dane z rejestru zezwoleń na prowadzenie zakładu inżynierii genetycznej (nr decyzji i data wydania decyzji). Po wybraniu zakładu inżynierii genetycznej wyświetlane będzie nr i data decyzji wraz z linkiem do karty w rejestrze zezwoleń zakładów inżynierii genetycznej;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO”; w przypadku tworzenia lub edycji karty w rejestrze zezwoleń na prowadzenie zakładu inżynierii genetycznej możliwe jest dodanie domyślnych załączników:
wniosek,
zgłoszenie,
ocena zagrożenia,
plan postępowania na wypadek awarii,
uchwała Komisji ds. GMO i GMM,
decyzja.
Rejestr zgód na zamknięte użycie GMM
Interfejs do wprowadzania danych powinien umożliwiać wprowadzanie danych w kolejności podanej poniżej (o ile nie podano inaczej: wartość nie może być pusta; o ile nie podano inaczej: wartość może się powtarzać). Gdy wartość nie może być pusta pojawia się komunikat o odpowiedniej treści, nie można go zignorować. Odpowiedni komunikat „wartość powtarza się” można zignorować.
numer karty – dane wg opisu z podpunktu „Numeracja kart”; wartość w obrębie rejestru nie może się powtarzać (w przypadku wpisania istniejącej wartości numeru karty, użytkownik otrzyma stosowny komunikat);
nazwa i adres wnioskodawcy – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
przedstawiciel wnioskodawcy - dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
nazwa GMO – pole tekstowe, maksymalna wielkość 512 znaków, dane tekstowe);
kategoria zagrożenia – pole jednokrotnego wyboru (wartości: I, II, III, IV);
data zgłoszenia – format daty: dd.mm.rrrr;
data upublicznienia – format daty: dd.mm.rrrr;
status wniosku – do wyboru z menu rozwijalnego: weryfikacja wniosku/ rozpatrzony/pozostawiony bez rozpoznania/wycofany;
data wydania decyzji – format daty: dd.mm.rrrr; wartość może być pusta;
decyzja obowiązuje do – format daty: dd.mm.rrrr; wartość może być pusta;
miejsce wykonania decyzji – lista rozwijalna – dane z rejestru zezwoleń na prowadzenie zakładu inżynierii genetycznej (nr decyzji i data wydania decyzji). Po wybraniu zakładu inżynierii genetycznej wyświetlane będzie nr i data decyzji wraz z linkiem do karty w rejestrze zezwoleń zakładów inżynierii genetycznej;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO”; w przypadku tworzenia lub edycji karty w rejestrze zezwoleń na prowadzenie zakładu inżynierii genetycznej możliwe jest dodanie domyślnych załączników:
wniosek,
zgłoszenie,
ocena zagrożenia,
wewnętrzny regulamin bezpieczeństwa,
szczegółowe informacje o sposobach przeciwdziałania skutkom awarii,
plan postępowania na wypadek awarii,
uchwała Komisji ds. GMO i GMM,
decyzja,
inne dokumenty
Rejestr zgód na zamierzone uwolnienie GMO
Interfejs do wprowadzania danych powinien umożliwiać wprowadzanie danych w kolejności podanej poniżej (o ile nie podano inaczej: wartość nie może być pusta; o ile nie podano inaczej: wartość może się powtarzać). Gdy wartość nie może być pusta pojawia się komunikat o odpowiedniej treści, nie można go zignorować. Odpowiedni komunikat „wartość powtarza się” można zignorować.
numer karty – dane wg opisu z podpunktu „Numeracja kart”; wartość w obrębie rejestru nie może się powtarzać (w przypadku wpisania istniejącej wartości numeru karty, użytkownik otrzyma stosowny komunikat);
nazwa i adres wnioskodawcy – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
przedstawiciel wnioskodawcy - dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
nazwa GMO – pole tekstowe, maksymalna wielkość 512 znaków, dane tekstowe);
kategoria zagrożenia – pole jednokrotnego wyboru (wartości: I, II);
data zgłoszenia – format daty: dd.mm.rrrr;
data upublicznienia – format daty: dd.mm.rrrr;
status wniosku – do wyboru z menu rozwijalnego: weryfikacja wniosku/ rozpatrzony/pozostawiony bez rozpoznania/wycofany ;
data wydania decyzji – format daty: dd.mm.rrrr;
decyzja obowiązuje do – format daty: dd.mm.rrrr;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO”; w przypadku tworzenia lub edycji karty w rejestrze zezwoleń na prowadzenie zakładu inżynierii genetycznej możliwe jest dodanie domyślnych załączników:
wniosek,
ocena zagrożenia,
techniczna dokumentacja,
program działania na wypadek zagrożenia zdrowia ludzi lub środowiska,
streszczenie wniosku i załączników (SNIF),
decyzja,
inne dokumenty.
Rejestr zezwoleń na wprowadzenie do obrotu produktów GMO
Interfejs do wprowadzania danych powinien umożliwiać wprowadzanie danych w kolejności podanej poniżej (o ile nie podano inaczej: wartość nie może być pusta; o ile nie podano inaczej: wartość może się powtarzać). Gdy wartość nie może być pusta pojawia się komunikat o odpowiedniej treści, nie można go zignorować. Odpowiedni komunikat „wartość powtarza się” można zignorować.
numer karty – dane wg opisu z podpunktu „Numeracja kart”; wartość w obrębie rejestru nie może się powtarzać (w przypadku wpisania istniejącej wartości numeru karty, użytkownik otrzyma stosowny komunikat);
nazwa i adres wnioskodawcy – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
przedstawiciel wnioskodawcy - dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
nazwa GMO – pole tekstowe, maksymalna wielkość 512 znaków, dane tekstowe);
data zgłoszenia – format daty: dd.mm.rrrr;
data upublicznienia – format daty: dd.mm.rrrr;
status wniosku – do wyboru z menu rozwijalnego: weryfikacja wniosku/ rozpatrzony/pozostawiony bez rozpoznania/wycofany;
data wydania decyzji – format daty: dd.mm.rrrr;
decyzja obowiązuje do – format daty: dd.mm.rrrr;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO”; w przypadku tworzenia lub edycji karty w rejestrze zezwoleń na prowadzenie zakładu inżynierii genetycznej możliwe jest dodanie domyślnych załączników:
wniosek, ocena zagrożenia,
potwierdzenie wytworzenia,
potwierdzenie braku zagrożenia,
decyzja,
inne dokumenty.
Rejestr upraw GMO
numer karty – dane wg opisu z podpunktu „Numeracja kart”; wartość w obrębie rejestru nie może się powtarzać (w przypadku wpisania istniejącej wartości numeru karty, użytkownik otrzyma stosowny komunikat);
nazwa i adres wnioskodawcy – dane wpisywane ręcznie; wartość może się powtarzać;
nazwa rośliny GMO – pole tekstowe (maksymalna wielkość 512 znaków, dane tekstowe);
powierzchnia uprawy – pole tekstowe (maksymalna wielkość 512 znaków, dane tekstowe);
cel i sposób prowadzenia uprawy GMO;
nazwa miejscowości, w której ma być prowadzona uprawa GMO;
planowana powierzchnia uprawy GMO, wyrażona w [ha];
numer działki ewidencyjnej, na której ma być prowadzona uprawa – pole tekstowe, (maksymalna wielkość 512 znaków, dane tekstowe);
termin na jaki ma być dokonany wpis uprawy GMO do Rejestru Upraw GMO;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO”; w przypadku tworzenia lub edycji karty w rejestrze upraw GMO możliwe jest dodanie domyślnych załączników:
wniosek,
decyzja,
pisemne oświadczenia właścicieli albo użytkowników wieczystych nieruchomości położonych w odległości do 30 km od granicy gruntu rolnego, na którym ma być prowadzona uprawa GMO,
pisemne oświadczenia pszczelarzy lub związków pszczelarzy, których pasieki znajdują się w odległości do 30 km od granicy gruntu rolnego,
mapka lub szkic z oznaczeniem działki rolnej przeznaczonej pod uprawę GMO,
dokumentacja potwierdzająca, że uprawa GMO, która ma być prowadzona, nie będzie mieć negatywnego wpływu na bezpieczeństwo środowiska,
dokumentacja zawierająca informacje o celu uprawy GMO oraz o warunkach i sposobnie prowadzenia danej uprawy GMO,
inne dokumenty.
Rejestr zgłoszonych awarii
Interfejs do wprowadzania danych powinien umożliwiać wprowadzanie danych w kolejności podanej poniżej (wartość nie może być pusta; o ile nie podano inaczej: wartość może się powtarzać – odpowiedni komunikat „wartość powtarza się” można zignorować). W interfejsie powinna znaleźć się informacja: „stan na …” w której data będzie się zmieniała się zgodnie z obowiązującym kalendarzem, niezależnie od wprowadzonych danych:
data zgłoszenia – format daty dd.mm.rrrr;
data wystąpienia awarii – format daty dd.mm.rrrr;
rodzaj awarii – pole tekstowe do 2000 znaków;
nazwa i adres zgłaszającego – dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
przedstawiciel zgłaszającego - dane wg opisu z punktu „baza wnioskodawców i przedstawicieli wnioskodawców”;
załączniki – dane wg opisu z podpunktu „Dodawanie załączników i odnośników” z punktu „Tworzenie i edycja rejestrów GMO/GMM”; w przypadku tworzenia lub edycji karty w rejestrze zezwoleń na prowadzenie zakładu inżynierii genetycznej możliwe jest dodanie domyślnego załącznika zgłoszenie awarii.
Jeśli do 31 grudnia danego roku w rejestrze awarii nie zostanie dokonany żaden wpis, rejestr musi wyświetlić informację „W roku … do ministra właściwego do spraw środowiska nie zgłoszono awarii”.
Wymogi techniczne
Architektura Systemu, wymagania ogólne
Wszelkie prace instalacyjne Wykonawca przeprowadzi po uprzednim uzgodnieniu terminu z Zamawiającym przy asyście administratorów technicznych systemu informatycznego Zamawiającego. Zamawiający umożliwi wykonywanie prac także w sposób zdalny za pomocą połączenia SSL VPN, z wykorzystaniem systemu nagrywającego wykonywane czynności.
Zamawiający rekomenduje zaproponowanie rozwiązania bazującego na systemie operacyjnym opartym na licencji „open source”.
System musi zostać stworzony w architekturze trójwarstwowej, z wyróżnieniem warstw aplikacji, danych i prezentacji z możliwością pełnego rozdzielenia ww. warstw na poziomie sprzętowym.
System ma być skalowalny, przy czym skalowanie może odbywać się przez rozbudowę warstwy prezentacyjnej, aplikacyjnej i bazodanowej.
Wszystkie elementy systemu muszą posiadać interfejs w języku polskim. Jako element interfejsu zamawiający określa również elementy konfiguracji poszczególnych części składowych systemu. W języku polskim muszą być również wyświetlane wszystkie komunikaty przekazywane przez system, włącznie z komunikatami o błędach. System musi mieć zastosowaną stronę kodową zapewniającą poprawne wyświetlanie tekstu z polskimi znakami.
Wszystkie elementy systemu muszą umożliwiać pracę poprzez najnowsze wersje przeglądarek internetowych na czas oddania systemu. W przypadku korzystania ze starszych przeglądarek, na stronie powinien wyświetlić się komunikat o sposobie poprawnego wyświetlania serwisu oraz wersji przeglądarek, do których jest zoptymalizowany.
System musi posiadać możliwość współpracy z silnikiem bazy danych opartym o licencje „open source” lub z wykorzystywanym przez Zamawiającego silnikiem bazodanowym Microsoft SQL Server 2019. W przypadku niewykorzystania rozwiązań „open source” Zamawiający może zagwarantować dostęp do przygotowanego środowiska produkcyjnego z licencją Windows Server 2019 (zgodnie z pkt. 5.2) oraz do wspomnianego wyżej silnika bazodanowego.
Na każdej stronie system powinien wyświetlać w stopce odnośnik do deklaracji dostępności stron internetowych. Po kliknięciu powinna zostać wczytana strona z pełnym teksem deklaracji. System powinien umożliwiać edycję strony zawierającej treść deklaracji dostępności.
Każdy element graficzny na stronie powinien posiadać tekst alternatywny, możliwy do odczytania po najechaniu myszką przez czytnik głosowy.
Czcionka na stronach powinna być bezszeryfową w wielkości minimum 14 pkt bez justowania.
System powinien umożliwiać na stronach ustawienie wersji kontrastowej, zmiany wielkości liter i odstępów między nimi (minimalny odstęp to 1,5).
System powinien umożliwiać przechodzenie poprzez elementy stron za pomocą klawisza Tab. Po najechaniu kursorem na menu stron, nr telefonu i adres e-mail do kontaktu powinny wyświetlać się dymki. Tekst w dymkach powinien być możliwy do przeczytania przez czytnik głosowy.
System musi posiadać mechanizm umożliwiający wyświetlenie zaprojektowanej przez Wykonawcę informacji o czasowej niedostępności serwisu z powodów technicznych.
System powinien być zgodny z dobrymi praktykami dotyczącymi bezpieczeństwa – standard OWASP-ASVS na poziomie 2 (Open Web Application Security Project):
xxxxx://xxxxx-xxxxx.xxxxxxxxxxx.xx/xx/xxxxxx/xxxxx0.xxxx
System musi posiadać wbudowane zabezpieczenia, w tym:
odporność na ataki typu Brute Force; ochronę przed próbami nieautoryzowanego dostępu do panelu administracyjnego/redakcyjnego i kont użytkowników (np. blokowanie konta po trzech próbach błędnego wpisania hasła redaktora);
odporność na próby uzyskania dostępu poprzez znane formy włamań;
odporność na zmiany treści za pomocą specjalnych skryptów i manipulacji:
ataki semantyczne na adres URL;
ataki związane z ładowaniem plików;
ataki typu cross-site scripting;
ataki typu CSRF;
podrabianie zatwierdzenia formularza;
sfałszowanie żądania http;
wstrzykiwanie kodu SQL;
ujawnienie danych przechowywanych w bazie;
kradzież cookies;
przechwytywanie sesji;
wstrzykiwanie sesji;
zafiksowanie sesji;
trawersowanie katalogów;
wstrzykiwanie poleceń systemowych;
ujawnianie kodu źródłowego np. plików .inc, „template” itp.
System musi posiadać zgodność kodu stron z rekomendacją W3C HTML 5 oraz jego weryfikację przy pomocy narzędzi udostępnianych przez W3C pod adresami: xxxx://xxxxxxxxx.x0.xxx i xxxx://xxxxxx.x0.xxx/xxx-xxxxxxxxx/
System powinien być zgodny z WCAG 2.1 „Wytyczne dla dostępności treści internetowych 2.1 stosowane dla stron internetowych i aplikacji mobilnych w zakresie dostępności dla osób niepełnosprawnych” do Ustawy z dnia 4 kwietnia 2019 r. o dostępności stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) w szczególności:
wszystkie elementy graficzne powinny mieć zwięzły tekst alternatywny (alt), który opisuje co znajduje się na grafice lub, jeśli grafika jest odnośnikiem – dokąd prowadzi ten odnośnik. Jeśli grafiki są czysto dekoracyjne, powinny mieć „pusty atrybut alt”;
w miarę możliwości należy mieć na uwadze, że animowane elementy, poruszające się teksty mogą rozpraszać wszystkich użytkowników nie tylko niepełnosprawnych. Niektóre, szczególnie agresywnie i szybko animowane grafiki, mogą stanowić zagrożenie dla osób cierpiących na padaczkę fotogenną;
teksty powinny być opublikowane w czytelny sposób – podzielone na paragrafy, listy i inne sekcje; nie justowane do prawej strony; skróty literowe powinny być rozwinięte w pierwszym wystąpieniu na każdej stronie. Tekst powinien być uzupełniony o nagłówki (h1-h6) , aby osoby słabowidzące mogły sprawnie przejść do interesującej ich sekcji;
nawigacja (menu) powinna być spójna, logiczna i niezmienna w obrębie serwisu. Nawigacja w obrębie całego serwisu powinna być dostępna z poziomu klawiatury, tj. przy użyciu takich klawiszy jak x.xx: Tab , Shift + Tab;
wszystkie elementy aktywne, takie jak odnośniki, banery czy pola formularza powinny mieć wyraźny wizualny fokus (zwykle w postaci ramki widocznej w trakcie nawigacji po stronie klawiszem Tab). Zaleca się wzmocnienie domyślnego fokusa, tak, aby był dobrze widoczny także dla osób niedowidzących.
Wykonawca opracuje scenariusze testowe i przeprowadzi (w terminie ustalonym z Zamawiającym) testy:
techniczne systemu;
funkcjonalności systemu;
dostępności systemu pod kątem zgodności ze standardem WCAG 2.1;
zgodności ze standardem bezpieczeństwa OWASP-ASVS, co najmniej na poziomie 2.
Wykonawca przedstawi wyniki testów oraz udostępni system do przetestowania Zamawiającemu. Należy mieć na uwadze, że niespełnienie wymogów zgodnie z conajmniej ze standardem 2 powoduje brak możliwości odebrania systemu przez Zamawiającego i konieczność przygotowania systemu do ponownych testów oraz odbioru.
Zakres testów powinien obejmować x.xx. następujące elementy:
walidacja danych wejściowych;
odporność na ataki typu:
ataki semantyczne na adres URL;
ataki związane z ładowaniem plików;
ataki typu cross-site scripting;
ataki typu CSRF;
podrabianie zatwierdzenia formularza;
sfałszowanie żądania http;
wstrzykiwanie kodu SQL;
ujawnienie danych przechowywanych w bazie;
kradzież cookies;
przechwytywanie sesji;
wstrzykiwanie sesji;
zafiksowanie sesji;
trawersowanie katalogów;
wstrzykiwanie poleceń systemowych;
ujawnianie kodu źródłowego np. plików .inc, „template” itp.;
weryfikacja mechanizmów uwierzytelniających (udostępniania zasobów nieautoryzowanym użytkownikom);
błędy transmisji i ich wpływ na spójność danych;
bezpieczeństwo protokołów komunikacyjnych, weryfikację konfiguracji parametrów TLS/SSL;
weryfikacja podatności utraty integralności, poufności i dostępności danych;
dostępność systemu w zakresie, w jakim może być on postrzegany, rozumiany i przeglądany przez wszystkich użytkowników, niezależnie od ich cech lub upośledzeń, a także niezależnie od właściwości używanego przez nich oprogramowania i sprzętu.
System musi zapobiegać jednoczesnej edycji tych samych danych przez wielu użytkowników (osoba, która chciałaby edytować modyfikowane dane otrzymuje stosowny komunikat).
System musi posiadać mechanizm identyfikacji i uwierzytelniania użytkowników za pomocą formularza logowania. System wymusi cykliczną zmianę hasła użytkownika po upływie okresu zdefiniowanego przez administratora technicznego (domyślnie 30 dni). Zmiana hasła będzie możliwa po wpisaniu aktualnego hasła i dwukrotnym podaniu nowego hasła.
Zamawiający wymaga, aby dane z formularza logowania do systemu były przesyłane do serwera w postaci zaszyfrowanej.
System musi umożliwiać wylogowanie Administratora/redaktora bez konieczności wylogowania z systemu operacyjnego i ponowne zalogowanie poprzez formularz logowania.
Logowanie do systemu musi odbywać się w sposób bezpieczny za pośrednictwem protokołu HTTPS.
Zgodność z posiadanym przez Ministerstwo Klimatu i Środowiska zapleczem technicznym oraz oprogramowaniem, zabezpieczenie na wypadek awarii.
Zamawiający dysponuje własnym zapleczem sprzętowym opartym o infrastrukturę vMware vSphere 7, na którym ma zostać uruchomiony system, zatem zakup sprzętu nie jest przedmiotem niniejszego postępowania.
W ramach posiadanego środowiska wirtualnego Zamawiający zobowiązuje się udostępnić maszynę wirtualną o parametrach, które zostaną uzgodnione w porozumieniu z Wykonawcą.
Oprogramowanie dodatkowe wchodzące w zakres przedmiotu zamówienia – serwerowe, bazodanowe, systemowe, klienckie.
Zamawiający wymaga, aby Wykonawca, którego oferta zostanie wybrana przedłożył pełną listę oprogramowania, które będzie wykorzystywane do budowy systemu, a którego Wykonawca nie jest producentem (nie posiada pełnych praw). Lista musi zawierać takie informacje jak:
producent oprogramowania,
nazwa i wersja oprogramowania,
system operacyjny, na którym działa,
rodzaj licencjonowania (bezpłatne, płatne itp.),
sposób licencjonowania (na procesor, na rdzeń procesora, stanowiskowa, na użytkownika itp.),
ilość licencji niezbędnych do funkcjonowania systemu zgodnie z założeniami w SIWZ.
Zamawiający wymaga, aby oprogramowanie wraz z bezterminowymi licencjami zostało dostarczone przez Wykonawcę w ramach tego postępowania. Wykonawca udzieli Zamawiającemu wyłącznej, nieodwoływalnej, na czas nieograniczony, licencji (lub sublicencji) dla nieograniczonej liczby użytkowników, na użytkowanie wytworzonego systemu informatycznego wraz ze wszystkimi elementami narzędziowymi niezbędnymi do uruchomienia i użytkowania systemu informatycznego, wytworzonego i dostarczonego w ramach projektu oraz uaktualnień do licencji lub sublicencji (w tym do oprogramowania systemowego i narzędziowego dostarczonego w ramach realizacji projektu), zgodnie z odnośnymi warunkami licencyjnymi.
Ergonomia systemu
Zamawiający wymaga, aby wszystkie pola, w których jest to możliwe, służące do wprowadzania danych we wszystkich modułach systemu, wyposażone były w maskę wprowadzania.
Zamawiający wymaga, aby w system wbudowane było narzędzie „Pomoc” dostępne dla użytkowników, zapewniające pomoc kontekstową.
Wydajność i dostępność systemu
System musi cechować się wysoką wydajnością i dostępnością usług. System będzie umożliwiał komfortową i wydajną pracę wszystkim użytkownikom (zakłada się jednoczesną pracę maksymalnie 30 użytkowników nieautoryzowanych).
Aplikacja ma być dostępna w trybie 24x7, przynajmniej 99,8% czasu pomiędzy godziną 7:00 a 19:00 z pojedynczą przerwą serwisową nie dłuższą niż 2 godziny tygodniowo w godzinach pomiędzy 19:00 a 7:00.
Wymagania dotyczące gwarancji
Zamawiający wymaga, aby Wykonawca świadczył usługi gwarancyjne przez okres 3 lat od dnia podpisania protokołu końcowego odbioru prac bez zastrzeżeń.
Zamawiający wymaga, aby w ramach gwarancji Wykonawca nieodpłatnie usuwał wszelkie dostrzeżone wady, awarie i usterki dostarczonego systemu. Serwis gwarancyjny będzie świadczony w miejscu instalacji aplikacji albo poprzez dostęp zdalny zapewniony przez Zamawiającego. Ewentualny dojazd będzie się odbywał na koszt Wykonawcy. W ramach świadczenia serwisu gwarancyjnego Wykonawca będzie zobowiązany do zapewnienia przez okres trwania gwarancji:
telefonicznej linii serwisowej z automatyczną rejestracją zgłoszeń,
pracownika zapewniającego serwis gwarancyjny,
diagnozowania przyczyn błędu,
usuwania błędów w oprogramowaniu,
uaktualniania dokumentacji projektowej, jeżeli usunięcie błędu spowoduje taką konieczność.
Dla celów świadczeń gwarancyjnych dokonuje się podziału błędów na poniższe klasy:
- błąd krytyczny – uniemożliwia realizację przez system podstawowych funkcji biznesowych albo powoduje on nie przejście któregoś ze scenariuszy testowych. Podstawowe funkcje biznesowe zostaną określone wspólnie przez Zamawiającego i Wykonawcę w początkowej fazie realizacji projektu (przy określaniu głównych przypadków użycia), za błąd krytyczny będzie uznawany również błąd oprogramowania lub konfiguracji oprogramowania powodujący zmniejszenie wydajności pracy systemu do poziomu mniejszego niż 50% zakładanej wydajności systemu;
- błąd niekrytyczny – błąd, który nie jest błędem krytycznym, oznaczający brak funkcjonalności tych elementów systemu, które nie są niezbędne z punktu widzenia realizowanych przez system podstawowych funkcji biznesowych (w tym narzędzi pomocniczych i administracyjnych). Kontynuowanie pracy systemu z mniejszą wydajnością (do poziomu 50% wydajności systemu w pełni sprawnego) uważa się również za błąd niekrytyczny.
Maksymalny czas reakcji serwisowej od zgłoszenia błędu krytycznego wynosi 48 godzin, a w przypadku błędu niekrytycznego – 96 godziny. Zamawiający będzie dokonywał zgłoszenia błędu za pośrednictwem telefonicznej linii serwisowej Wykonawcy z automatyczną rejestracją zgłoszeń, elektronicznego systemu obsługi i zgłaszania błędów albo ogólnej linii telefonicznej Wykonawcy. Za reakcję uważa się nawiązanie kontaktu ze zgłaszającym błąd pracownikiem Zamawiającego przez pracownika Wykonawcy.
Czas przywrócenia funkcjonalności systemu:
- dla błędów krytycznych – do 48 godzin od przyjęcia zgłoszenia przez Wykonawcę,
- dla błędów niekrytycznych – do 4 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę.
Do naruszeń ww. terminów znajdują zastosowanie kary umowne, które zostaną określone w umowie.
Gwarancja nie obejmuje:
błędów wynikających z awarii sprzętu, na którym zostało zainstalowane oprogramowanie.
Zamawiający będzie zobowiązany do:
zapewnienia zgodnych z wymaganiami producenta sprzętu warunków pracy sprzętu, na którym zostanie zainstalowany system,
zapewnienia gwarantowanego zasilania sprzętu teleinformatycznego,
zapewnienia dostępu Wykonawcy w celu wykonania napraw w systemie wykonanym przez Wykonawcę, w którym wystąpiły błędy,
zapewnienia legalności instalacji i użytkowania posiadanych przez siebie poszczególnych elementów systemu.
Wymagania dotyczące asysty technicznej
Zamawiający wymaga, aby Wykonawca zapewnił bezpłatną asystę techniczną przez okres nie krótszy niż 24 (słownie: dwadzieścia cztery) miesiące od dnia podpisania protokołu końcowego odbioru prac bez zastrzeżeń.
Zamawiający wymaga, aby w ramach asysty technicznej Wykonawca poświęcił 100 (słownie: dwieście) roboczogodzin na prace rozwojowe systemu i szkolenie użytkowników.
Wymagania dotyczące dokumentacji
Wykonawca przygotuje kompletną dokumentację, a w tym: kody źródłowe wraz z informacją o konfiguracji środowiska produkcyjnego, podręcznik administratora oraz redaktora; instrukcję obsługi dla użytkownika nieautoryzowanego.
Identyfikacja wizualna projektu
Każdy produkt wytworzony podczas realizacji niniejszego projektu musi być opatrzony logo wraz ze stosowną informacją o finansowaniu przedsięwzięcia oraz logo Ministerstwa.
Zgodnie z art. 13 ust. 1 i 2 rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz. Urz. UE L 119 z 04.05.2016, str. 1), dalej „RODO”, informuję, że:
Administratorem Pani/Pana danych osobowych jest Minister Klimatu i Środowiska, xx. Xxxxxxxx 00/00, 00-000 Xxxxxxxx, tel. 000 00 00 000;
Kontakt z inspektorem ochrony danych w Ministerstwie Klimatu i Środowiska jest możliwy pod adresem e-mail xxxxxxxxx.xxxxxxx.xxxxxx@xxxxxx.xxx.xx;
Pani/Pana dane osobowe przetwarzane będą w celu oszacowania wartości zamówienia na podstawie art. 6 ust. 1 lit. c RODO oraz ustawy z dnia 11 września 2019 r. Prawo Zamówień Publicznych (Dz. U. z 2019 r. poz. 1843), a także w celu spełnienia obowiązku archiwizacji dokumentów na podstawie ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym
i archiwach (Dz. U. z 2020 r. poz. 164);Odbiorcami Pani/Pana danych osobowych będą osoby lub podmioty, z którymi Ministerstwo zawarło umowy na świadczenie usług informatycznych i pocztowych. Dane pozyskiwane
w związku z postępowaniem o udzielnie zamówienia publicznego mogą być także przekazywane wszystkim zainteresowanym podmiotom i osobom, gdyż co do zasady postępowanie o udzielenie zamówienia publicznego jest jawne;Pani/Pana dane osobowe będą przechowywane przez okres ….1 lat od dnia zakończenia postępowania o udzielenie zamówienia;
Podanie przez Panią/Pana danych osobowych w związku z szacowaniem wartości zamówienia jest dobrowolne;
W odniesieniu do Pani/Pana danych osobowych decyzje nie będą podejmowane w sposób zautomatyzowany, stosownie do art. 22 RODO;
Posiada Pani/Pan:
na podstawie art. 15 RODO prawo dostępu do danych osobowych dotyczących Pani/Pana oraz uzyskania ich kopii;
na podstawie art. 16 RODO prawo do sprostowania Pani/Pana danych osobowych;
na podstawie art. 18 RODO prawo żądania od administratora ograniczenia przetwarzania danych osobowych z zastrzeżeniem przypadków, o których mowa w art. 18 ust. 2 RODO;
na podstawie art. 17 RODO prawo do usunięcia danych osobowych z zastrzeżeniem przypadków, o których mowa w art. 17 ust. 3 lit. b, d lub e RODO;
prawo do wniesienia skargi do Prezesa Urzędu Ochrony Danych Osobowych, gdy uzna Pani/Pan, że przetwarzanie danych osobowych Pani/Pana dotyczących narusza przepisy RODO.
W przypadku przekazywania danych do państwa trzeciego lub organizacji międzynarodowej, należy umieścić następujący punkt:
Pani/Pana dane osobowe będziemy przekazywać do państwa trzeciego lub organizacji międzynarodowej ……………………………………………………………………………
(podać jakie to państwo lub organizacja – jeśli dotyczy)
1 podać okres przechowywania danych. Okres przechowywania danych, obejmuje czas obowiązywania umowy o udzielenie zamówienia publicznego, na potrzeby którego wykonywano szacowanie wartości zamówienia oraz okres archiwizacji danych zgodny z JRWA MKiŚ.
xx. Xxxxxxxx 00/00, 00-000 Xxxxxxxx; tel. (00) 00-00-000, faks (00) 00-00-000, xxx.xxx.xx/xxxxxx
Działamy zgodnie z EMAS - zarządzając instytucją dbamy o środowisko