„Elektronicznych rejestrów mikroorganizmów i organizmów genetycznie zmodyfikowanych Ministra Klimatu i Środowiska”

Szacowanie wartości zamówienia polegającego na utworzeniu

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.

I. ZAMAWIAJĄCY

Ministerstwo Klimatu i Środowiska

xx. Xxxxxxxx 00/00 00-000 Xxxxxxxx

I. Szczegółowy opis przedmiotu zamówienia:

1. Wstęp

Elektroniczne rejestry mikroorganizmów i organizmów genetycznie zmodyfikowanych 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 (t.j. Dz.U. z 2021 r. poz. 117, ze zm.).

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).

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

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

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;

2. Użytkownicy i tryby dostępu

Użytkownik autoryzowany – 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 użytkowników autoryzowanych;

− 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. Osobami upoważnionymi do wprowadzania danych będą wyznaczeni pracownicy Departamentu Ochrony Przyrody Ministerstwa Klimatu i Środowiska – w tym celu zostanie utworzonych do 5 autoryzowanych kont użytkowników.

Użytkownik autoryzowany musi posiadać dostęp do logów z ostatnich 3 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.

Użytkownik nieautoryzowany – obywatel – może przeszukiwać wszystkie opublikowane w rejestrach 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ć export zestawienia do formatu pdf, csv oraz xml.

3. 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).

4. Elektroniczne Rejestry GMM i GMO

System zwany „elektronicznymi rejestrami GMM i GMO” składać się musi z dwóch części:

− aplikacji administracyjnej, służącej do wprowadzania przez autoryzowanych

użytkowników danych do bazy danych i ich publikowania,

− 7 rejestrów GMM i GMO:

o zamkniętego użycia organizmów genetycznie zmodyfikowanych (zwanych dalej rejestr GMO),

o zamkniętego użycia genetycznie zmodyfikowanych mikroorganizmów (zwanych dalej rejestr GMM),

o zamierzonego uwolnienia GMO do środowiska,

o zakładów inżynierii genetycznej (zwanych dalej rejestr zig),

o awarii,

o wprowadzenia do obrotu produktów GMO,

o upraw GMO,

zwanych dalej „rejestrami GMM i GMO”, prezentujących w Internecie opublikowane dane nieautoryzowanym użytkownikom (obywatelom).

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).

Użytkownik autoryzowany będzie mógł dodać nowy wzór kart dla danego rejestru oraz edytować lub 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 lub modyfikacja wzoru karty nie będzie powodować zmian w opublikowanych dotychczas kartach.

Do bazy danych przez aplikację administracyjną, 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 użytkowników autoryzowanych 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, użytkownik 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. Autoryzowany użytkownik będzie posiadał 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).

4.1. 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) lub tytuł załącznika (w przypadku załącznika zdefiniowanego jako „inne”. Obok każdego załącznika powinna być wyświetlana informacja o jego formacie i wadze.

Maksymalna wielkość plików zamieszczanych w rejestrach GMO to 20 MB, w przypadku próby zamieszczenia większych plików użytkownikowi 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).

4.2. Baza wnioskodawców i przedstawicieli wnioskodawców

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 użytkownika autoryzowanego.

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. Autoryzowany użytkownik 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 (pole obowiązkowe do uzupełnienia),

− miejscowość (pole obowiązkowe do uzupełnienia),

− xxxxx (xxxx xxxxxxxxxxx xx xxxxxxxxxxxx),

x 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.

Autoryzowany użytkownik 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ć autoryzowani użytkownicy zarówno z poziomu wydzielonej części administracyjnej bazy wnioskodawców i przedstawicieli, jak i z poziomu tworzenia karty wniosku. Podczas tworzenia i edycji karty autoryzowany użytkownik posiada możliwość wyszukania wnioskodawcy lub przedstawiciela wnioskodawcy (co najmniej przy pomocy nazwy lub części nazwy wnioskodawcy, adresu wnioskodawcy, nazwiska lub fragmentu nazwiska przedstawiciela 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 braku dodanie wpisu – uzupełnienie informacji o nowym wnioskodawcy lub przedstawicielu wnioskodawcy.

Użytkownicy autoryzowani powinni posiadać możliwość wyszukania:

- jakich 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 wpisu (walidacja).

4.3. Opcje zapisu

Opcja dostępna tylko dla użytkowników autoryzowanych: system umożliwia zapis stanu wpisywanych danych w dowolnym momencie: nie tylko po uzupełnieniu całej karty. Przy wyłączaniu aplikacji przez użytkownika autoryzowanego 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).

4.4. Powiązania z istniejącymi rejestrami

Nowopowstałe rejestry muszą uwzględniać dane zawarte w obecnie funkcjonujących rejestrach GMO/GMM. Należy dokonać importu danych wnioskodawców, przedstawicieli wnioskodawców oraz metadanych opisujących karty i dodane załączniki z obecnych rejestrów GMO/GMM.

Sposób wykonania importu danych zostanie uzgodniony z Zamawiającym. Import obejmować musi dane z okresu od roku 2015 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. Dostęp do systemu jest utrudniony. Kopia bazy danych obecnie funkcjonujących rejestrów stanowi załącznik do niniejszego zapytania ofertowego.

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.

4.5. Opcje wyszukiwania

Użytkownik systemu: nieautoryzowany (obywatel) oraz autoryzowany będzie miał 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 (jeden, wiele, wszystkie). 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 GMO/GMM będzie dostępna wyszukiwarka, która umożliwi przeszukanie wszystkich, dowolnie wybranych lub jednego wybranego rejestru według wybranego lub wielu kryteriów:

− wyszukiwanie pełnotekstowe, całości lub części tekstu,

− numeru karty (wyszukiwanie po numerze: albo cały numer karty albo po numerze rejestru oraz rok),

− 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 lub całości nazwy wnioskodawcy,

− części lub całości nazwiska przedstawiciela wnioskodawcy,

− nazwy miejscowości wnioskodawcy,

− nazwy województwa wnioskodawcy (lista rozwijalna).

Dla użytkowników autoryzowanych – możliwość wyszukania w rejestrze zamkniętego użycia GMO i rejestrze zamkniętego GMM, jakie 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.

4.6. 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ń.

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.

4.7. Raporty i zestawienia danych

W systemie powinna istnieć możliwość zestawienia danych na następujących zasadach:

− dane umieszczane są w tabeli, w wierszach lub kolumnach (do wyboru opcje: horyzontalnie/wertykalnie),

− możliwość wyboru kolejności kolumn.

Powinna istnieć możliwość eksportu danych do plików w formacie: xlsx, PDF, docx, 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.

5.1. Numeracja kart

5. Rejestry

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 GMO do środowiska

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.

5.2. 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:

o wniosek,

o oświadczenie o wpisaniu zakładu do wykazu jednostek hodowlanych,

o uchwała Komisji ds. GMO i GMM,

o decyzja,

o 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.

5.3. Rejestr zgód na zamknięte użycie GMO

− 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:

o wniosek,

o zgłoszenie,

o ocena zagrożenia,

o plan postępowania na wypadek awarii,

o uchwała Komisji ds. GMO i GMM,

o decyzja.

5.4. Rejestr zgód na zamknięte użycie GMM

− 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

− 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:

o wniosek,

o zgłoszenie,

o ocena zagrożenia,

o wewnętrzny regulamin bezpieczeństwa,

o szczegółowe informacje o sposobach przeciwdziałania skutkom awarii,

o plan postępowania na wypadek awarii,

o uchwała Komisji ds. GMO i GMM,

o decyzja,

o inne dokumenty

5.5. Rejestr zgód na zamierzone uwolnienie GMO

− 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:

o wniosek,

o ocena zagrożenia,

o techniczna dokumentacja,

o program działania na wypadek zagrożenia zdrowia ludzi lub środowiska,

o streszczenie wniosku i załączników (SNIF).

o decyzja

o inne dokumenty

5.6. Rejestr zezwoleń na wprowadzenie do obrotu produktów GMO

odpowiedniej treści, nie można go zignorować. Odpowiedni komunikat „wartość powtarza się” można zignorować.

− 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:

o wniosek, ocena zagrożenia,

o potwierdzenie wytworzenia,

o potwierdzenie braku zagrożenia.

o decyzja

o inne dokumenty

5.7. Rejestr upraw GMO

− 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:

o wniosek

o decyzja

o 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

o 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

o mapka lub szkic z oznaczeniem działki rolnej przeznaczonej pod uprawę GM

o dokumentacja potwierdzająca, że uprawa GMO, która ma być prowadzona, nie

będzie mieć negatywnego wpływu na bezpieczeństwo środowiska

o dokumentacja zawierająca informacje o celu uprawy GMO oraz o warunkach i sposobnie prowadzenia danej uprawy GMO

o inne dokumenty.

5.8. 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:

o 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”.

6. Wymogi techniczne

6.1. 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 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 licencję „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 w/w warstw na poziomie sprzętowym.

System ma być skalowalny, przy czym skalowanie może odbywać się przez:

a) dołączenie dodatkowych stanowisk (zwiększanie liczby Użytkowników),

b) rozbudowę warstwy prezentacyjnej, aplikacyjnej i bazodanowej (zwiększenie zasobów komputerów obsługujących warstwę poprzez rozbudowę pamięci, zwiększenie liczby procesorów oraz zwiększanie liczby maszyn, zwiększenie pojemności pamięci masowych). 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 są 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, w tym przeglądarek dla systemów mobilnych (których udział w zestawieniu na stronie xxx.xxxxxxx.xx dla przeglądarek używanych przez internautów łączących się z polskimi witrynami z obszaru Polski jest większy niż 0,5% w dniu przedstawiania przez Wykonawcę makiety funkcjonalnej systemu) 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ć licencję Windows Server 2019 oraz na wspomniany wyżej silnik bazodanowy.

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:

a) odporność na ataki typu Brute Force; ochronę przed próbami nieautoryzowanego dostępu do panelu administracyjnego i kont użytkowników (np. blokowanie konta po trzech próbach błędnego wpisania hasła redaktora/użytkownika);

b) odporność na próby uzyskania dostępu poprzez znane formy włamań;

c) 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 internetowychi aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) w szczególności:

1) 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”;

2) 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ą;

3) 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;

4) 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;

5) 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 scenariusz testowe i przeprowadzi (w terminie ustalonym z

Zamawiającym) testy:

1) techniczne systemu;

2) funkcjonalności systemu;

3) dostępności systemu pod kątem zgodności ze standardem WCAG 2.1;

4) 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 co najmniej ze standardem 2 powoduje brak możliwości odebrania systemu przez Zamawiającego i konieczność przygotowania systemu do ponownych testów oraz odbioru.

1. Zakres testów powinien obejmować x.xx. następujące elementy:

1) walidacja danych wejściowych;

2) odporność na ataki typu:

a) ataki semantyczne na adres URL;

b) ataki związane z ładowaniem plików;

c) ataki typu cross-site scripting;

d) ataki typu CSRF;

e) podrabianie zatwierdzenia formularza;

f) sfałszowanie żądania http;

g) wstrzykiwanie kodu SQL;

h) ujawnienie danych przechowywanych w bazie;

i) kradzież cookies;

j) przechwytywanie sesji;

k) wstrzykiwanie sesji;

l) zafiksowanie sesji;

m) trawersowanie katalogów;

n) wstrzykiwanie poleceń systemowych;

o) ujawnianie kodu źródłowego np. plików .inc, „template” itp.;

3) weryfikacja mechanizmów uwierzytelniających (udostępniania zasobów nieautoryzowanym użytkownikom);

4) błędy transmisji i ich wpływ na spójność danych;

5) bezpieczeństwo protokołów komunikacyjnych, weryfikację konfiguracji parametrów TLS/SSL;

6) weryfikacja podatności utraty integralności, poufności i dostępności danych;

7) 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 użytkownika 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.

6.2. 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ą.

6.3. 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 jakim 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łalnej, 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.

6.4. Ergonomia systemu

System musi umożliwiać pracę minimum w trzech standardowych rozdzielczościach ekranu: 1366x768 1280x800, 1280x1024 bez zmiany układu widoku.

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ą.

6.5. 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 4 użytkowników autoryzowanych/min i 30 użytkowników

nieautoryzowanych/min.) Wydajność będzie mierzona po wykonaniu importu wszystkich danych z aktualnie funkcjonującego systemu. Maksymalne czasy wydajności w odniesieniu do wskazanych operacji zostaną zaproponowane przez Wykonawcę i ustalone z Zamawiającym. Aplikacja ma być dostępna w trybie 24x7 przynajmniej 99,1% 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.

6.6. 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 lub 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 16 godzin, a w przypadku błędu niekrytycznego – 24 godziny. Zamawiający będzie dokonywał zgłoszenia błędu przy użyciu telefonicznej linii serwisowej z automatyczną rejestracją zgłoszeń, elektronicznego systemu obsługi i zgłaszania błędów lub 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 24 godzin od przyjęcia zgłoszenia przez Wykonawcę,

- dla błędów niekrytycznych – do 2 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 wprowadzonych przez Zamawiającego zmian sprzętowych do systemu, które nie zostały uzgodnione z Wykonawcą,

− 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 do w aplikacji wykonanych przez Wykonawcę, w których wystąpiły błędy,

− zapewnienia legalności instalacji i użytkowania posiadanych przez siebie poszczególnych elementów systemu.

6.7. 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ł 200 (słownie: dwieście) roboczogodzin na prace rozwojowe systemu i szkolenie użytkowników.

6.8. Wymagania dotyczące szkoleń dla pracowników Ministerstwa Klimatu i

Środowiska

Zamawiający wymaga, aby Wykonawca przeprowadził szkolenia dla wszystkich

użytkowników autoryzowanych systemu wskazanych przez Xxxxxxxxxxxxx (do 5 osób).

Zamawiający wymaga, aby Wykonawca zapewnił we własnym zakresie:

− Pełną dokumentację systemu wraz z procedurami eksploatacyjnymi.

− Sprzęt niezbędny do przeprowadzenia szkolenia.

− Program szkolenia zawierający części: teoretyczną i praktyczną.

− Materiały szkoleniowe dla każdego z uczestników szkoleń.

Zamawiający wymaga, aby wykonawca przeprowadził odrębne szkolenia dla minimum 2 (słownie: dwóch) administratorów technicznych systemu, których zakres pozwoli na samodzielne zarządzenie systemem np. zakładanie kont użytkowników, przydzielanie uprawnień, analizę zdarzeń systemowych, zarządzanie systemem kopii zapasowych etc.

Zamawiający wymaga, aby Wykonawca nieodpłatnie przekazał materiały szkoleniowe na

użytek Zamawiającego.

Zamawiający wymaga, aby szkolenia odbyły się przed uruchomieniem wersji produkcyjnej systemu.

Zamawiający wymaga, aby szkolenia odbyły się w siedzibie Ministerstwa Klimatu i

Środowiska lub zdalnie.

6.9. Wymagania dotyczące dokumentacji

Wykonawca przygotuje kompletną dokumentację, a więc: kody źródłowe, podręcznik administratora oraz użytkownika autoryzowanego; instrukcję obsługi dla użytkownika nieautoryzowanego – obywatela.

6.10. Identyfikacja wizualna projektu

Każdy produkt wytworzony podczas realizacji niniejszego projektu musi być opatrzony logo NFOŚiGW wraz ze stosowną informacją o finansowaniu przedsięwzięcia oraz logo Ministerstwa Klimatu i Środowiska.

II. SPOSÓB SKŁADANIA WYCENY:

Wyceny należy składać za pośrednictwem poczty elektronicznej, na formularzu stanowiącym załącznik do niniejszego szacowania, na adres e-mail: xxxxxx.xxxxx@xxxxxxxxxx.xxx.xx

III. TERMIN SKŁADANIA WYCENY:

do 21.01.2022 r. do godz. 12.00

IV. INFORMACJE DODATKOWE:

1. Wykonawca poniesie koszty związane z przygotowaniem i złożeniem wyceny.

2. Ministerstwo Klimatu i Środowiska otrzymało certyfikat Zarządzania Środowiskowego, zgodny z rozporządzeniem EMAS, w oparciu o Politykę Środowiskową, zatwierdzoną przez Ministra Środowiska. W związku z tym, zaleca się aby Wykonawca zapoznał się z treścią Polityki Środowiskowej dostępną na stronie MŚ (xxxxx://xxx.xxx.xx/xxx/xxxxxxxxxx/xxxx-x- ministerstwie).

3. Kary umowne

a) W przypadku niewykonania lub nienależytego wykonania umowy lub jej części przez

Wykonawcę Zamawiający będzie naliczał kary umowne.

b) Zamawiającemu przysługuje prawo potrącenia naliczonych kar umownych z wynagrodzenia

należnego Wykonawcy.

4. Termin płatności

a) Wynagrodzenie będzie płatne maksymalnie w trzech transzach po zrealizowaniu każdego etapu umowy, w terminie 30 dni od dnia przedłożenia przez Wykonawcę Zamawiającemu faktury, przelewem na rachunek bankowy Wykonawcy wskazany na przedłożonej fakturze

b) Warunkiem wystawienia faktury jest wykonanie umowy potwierdzone podpisaniem przez Xxxxxx protokołu zdawczo-odbiorczego stwierdzającego należyte wykonanie danego etapu umowy.

c) Za dzień zapłaty wynagrodzenia uważa się dzień złożenia przez Zamawiającego dyspozycji przelewu na rachunek bankowy Wykonawcy.

Potwierdzam zgodność kopii wydruku z dokumentem elektronicznym:

Identyfikator dokumentu	1653875.6718157.5382498
Nazwa dokumentu	GMO Szacowanie wartosci zamowienia 13.01.pdf
Tytuł dokumentu	GMO Szacowanie wartosci zamowienia 13.01
Sygnatura dokumentu	DOP-GMO.601.163.2021
Data dokumentu	2022-01-13
Skrót dokumentu	53D7A0A20F7007E4BFE7921C95F8BA7DBEFABFC3
Wersja dokumentu	1.3
Data podpisu	2022-01-13 15:45:45
Podpisane przez	Xxxxxx Xxxx; Ministerstwo Klimatu i Środowiska Dyrektor

EZD 3.104.37.37.20575

Data wydruku: 2022-01-14

Autor wydruku: Xxxxx Xxxxxx (Główny Specjalista)

Document Metadata

Table of Contents

„Elektronicznych rejestrów mikroorganizmów i organizmów genetycznie zmodyfikowanych Ministra Klimatu i Środowiska”

Document Metadata